BUSINESS PURPOSE
The purpose of this activity is to define the Enterprise
Logical Data Base Model (ELDBM). This includes the Objects,
Views and Data Elements required to support all applications
within the enterprise. It is performed by Data Engineering
and is patterned after the steps in Phase 2, Activity A.
OVERVIEW
If Phase 2 has been performed correctly, this activity
should represent nothing more than a merger of comparable
objects as defined in the various ALDB Models. However, if the
DBEM project is in support of an EEM project, the intent of this
activity is to define skeletal objects, identification views,
and primary/indicative data elements to represent "primary basic
groupings."
The purpose and use of logical Objects is described in the
Methodology Overview. They consist of logical Views
(perspectives about the Objects), which in turn are composed of
data elements. ELDBM Objects represent the facts and events of
interest to the whole enterprise, not just one Information
System. Whereas the ELDBM represents all logical data
resources, the ALDBM represents a subset to accommodate a
single system.
The development of the ELDBM follows an evolutionary
process. As ALDB Models are developed they are merged into the
global model, thereby synchronizing the corporate data base with
all applications. Over time, the ELDBM will grow until it
becomes a very stable model. It will only change if:
- New objects, views, and primary data elements are introduced
via an ALDBM.
- Business policies force a change in object relationships
(e.g., a many-to-many relationship is converted to a one-
to-many relationship). This too will be introduced through
an ALDBM.
The very first ALDBM will become the basis for establishing
the first set of objects within the ELDBM. As additional ALDB
Models are introduced over time, the ELDBM will be updated as
required. The main task of Data Engineering thereby is to
semantically identify each ALDBM Object and match it to the
corresponding global enterprise fact or event in the ELDBM.
This may be very simple in some cases, when the objects (and
their names) represent familiar concepts, but can turn into
difficult decisions that involve a deep knowledge of the
enterprise. For example, an ALDBM may contain a Salesman
Object, which would be easily matched to an ELDBM Employee
Object. However, whether a "Surgical Procedure" Object for an
Accounts Receivable system should be considered as the same
Object as a "Surgical Procedure" Object of a physician training
program is a much harder decision, which involves a basic
knowledge of the hospital business. Consequently, Systems
Engineering or Enterprise Engineering may need to be consulted
to resolve definition of terms and relationships.
RULES FOR OBJECT DEFINITION
Objects within the ELDBM must satisfy the following
properties:
- All Objects must relate to a single FD representing the
overall Enterprise Logical Data Base Model (ELDBM).
This is based on the FD/FD Relationship.
- The FD representing the ELDBM must be related to its
host enterprise; not a business function. The ELDBM
is related to the enterprise via the FE/FD Relationship.
- Each Object is clearly described in business terms on
the corresponding FD resource definition. Objects may
either represent "facts" (name/location related), or
"events" (date/time related).
- An Object must be uniquely identified by a single indicative
data element. This is commonly referred to as the "primary
basic grouping" data element of the object. The "primary
basic grouping" is also used to group views (logical
records) together into a logical file.
- All Objects must have an "Identification View" (logical
record) to uniquely identify the Object.
- A fact-related Object may or may not have one or more
"Characteristic Views" (logical records) that are used to
describe the Object internally. The "basic grouping" for
the view consists of the "primary basic grouping" element,
followed by one or more "view identifiers" (not a "foreign
key").
- An event-related Object must have one or more "Relationship
Views" (logical records) to express some form of interaction
between two fact related Objects. The "basic grouping" for
the view consists of the "primary basic grouping" element,
followed by "foreign keys" to the other fact-related
Objects. No more than two fact-related Objects can be
associated with a single "Relationship View." Relationships
between views are explicitly defined using RD/RD
Relationships.
- Views will contain only primary data elements (not
generated) that are either descriptive or quantitative
in nature (not indicative). The "basic grouping" of the
view adds meaning to the subordinate data (for example,
when "Name" is related to "Customer Number," it represents
"Customer Name." Further, the "basic grouping" of the view
must allow no more than one occurrence of a data element
(thus creating a dependency).
- Views in the ALDBM must be related to their corresponding
views in the ELDBM. In other words, an "Identification
View" for the Customer Object in the ALDBM should be linked
to the "Identification View" of the Customer Object in the
ELDBM. This is required for all views, regardless if they
are an "Identification View," "Characteristic View," or a
"Relationship View."
EEM CONSIDERATIONS
To get a head-start on the development of the ELDBM, an
EEM related project may trigger a DBEM project. Under this
scenario, Data Engineering simply identifies logical files to
represent the objects, logical records to represent
"Identification Views," and primary/indicative data elements
to represent the "primary basic grouping" of the object. Any
additional views, data elements, or relationships would simply
represent a guess by the Data Engineer which could be wrong.
The Data Engineer, therefore, should be discouraged from
speculating on the design of the ELDBM without the ALDBM to
provide guidance.
STEPS IN EXECUTION
- Data Engineering reviews the specifications resulting
from Phase 1 and 2. Based on the specifications, Data
Engineering prepares a Detail estimate and schedule to
complete the phase. This is based, in part, on the
Order-of-Magnitude estimate/schedule resulting from Phase
1. The Detail estimate/schedule is reviewed with Project
Management for approval.
- Data Engineering defines the objects, views, and data
elements associated with the ELDBM using FD, RD, and
DD resource definitions in the IRM. Systems Engineering
and Enterprise Engineering is consulted during resource
definition.
NOTE: If Phase 2 was performed correctly,
Data Engineering should not have to invent any new data
elements.
- Data Engineering relates the logical files (objects) to
the ELDBM (as represented by a single FD resource). The
ELDBM should be linked to the host enterprise.
- Data Engineering prepares an "ELDBM Narrative" to describe
the objects within the data base, along with a "Data
Structure Display." These deliverables are retained for
inclusion in the final Phase 3 design manual.