The purpose of this phase is to design or modify the Enterprise Logical Data Base Model (ELDBM). Several events occur during this phase:
METHODOLOGY NAVIGATION
For normal application development projects, a Phase 3
is performed following Phase 2. The one exception to this is
when a special project is subsequently performed from an
EEM related project. The phase 3, therefore, is used to
define a preliminary set of enterprise level objects.
There is a one-to-one relationship between Phase 3 and
the Enterprise Logical Data Base Model as represented by an
FD resource in the IRM. As such, the Project Manager may
bind the FD number to the project/phase key. For example:
The formal deliverable resulting from Phase 3 is an "ELDBM
Design Manual" consisting of a description of the Enterprise
Logical Data Base Model. This is reviewed with Data Resource
Management who must decide whether to:
Following Phase 3, the DBEM project will normally proceed
to Phase 4, "Enterprise Physical Data Base Design," where
physical file structures will be created to implement the
logical data base design. If EEM related, the project will
then proceed to the Phase 6 DBEM Evaluation.
GENERAL DISCUSSION
The Enterprise Logical Data Base Model represents a global
view of all Objects currently of interest to the enterprise, as
well as the relationships between them. It is intended to
present a unified, agreed upon, view of the major facts and
events that the enterprise must keep track of in conducting
business. As such, there is only one ELDBM associated with a
single enterprise.
The model is designed in such a way that it can be
built through an evolutionary process and when completed,
becomes very stable, in the sense that new Objects need be
created only as the enterprise changes its areas of business
operation.
The ELDBM is composed of a set of interrelated Objects,
each of which represents a certain type of enterprise fact or
event, which may be as concrete or abstract as one desires, and
is uniquely identifiable by a single indicative data element.
Objects consist of logical records (views), which in turn are
composed of data elements. A detailed discussion on Objects,
Views and Data Elements is presented in both the Methodology
Overview and Phase 2.
To satisfy the requirements of Data Base Engineering, the
Enterprise Logical Data Base Model must be:
When completed, the ELDBM contains all Objects of interest
to the Enterprise along with their relationships, records and
data elements. When supporting an EEM project, such detail will
not necessarily be possible. In this situation, the ELDBM will
consist of nothing more than skeletal file descriptions, with
their primary basic grouping, and identification view. Details
about the objects, including their relationships, will be
established later as a result of normal DBEM Phase 2 activity.
ENTERPRISE LOGICAL DATA BASE MODEL (ELDBM) BASIC CONSTRUCTS
NOTES: The pointers represent relationships
between the various resources as physically recorded in the IRM.
The relationship between the Order and the Customer would
be used to indicate types of relationships between views
(e.g., 1:M, M:M). Also, it implies a relationship to a
Product Identification View.
ALDBM/ELDBM RELATIONSHIP
Normally, Phase 3 represents a merging of the various ALDB
Models. This means, for example, that there may be many
"Customer" objects defined in the various ALDB Models, yet only
one global "Customer" object in the ELDB Model.
As part of this merging of the various objects, Data
Engineering reviews and referees discrepancies in object
relationships. Although this is a normal part of Phase 2,
the Data Engineer must eliminate such inconsistencies during
Phase 3.
If DBEM is performed correctly, Data Engineering should not
have to define any additional data elements in Phase 3 (other
than those defined by Systems Engineering in Phase 2). The only
exception to this is when a DBEM project follows an EEM project,
instead of ISEM. To satisfy the tentative model, Data
Engineering may have to define indicative data elements for use
as "primary basic grouping" items in objects.
Each ALDBM Object corresponds to an ELDBM Object. In this
way, each ALDBM Object can be considered a subset of a
corresponding ELDBM Object. To illustrate:
This means that there may be many different types of
Employee Objects which contain subsets of data to describe the
object for a particular system. However, there may be only one
"global" Employee Object expressed by the ELDBM to accommodate
all ALDB Models. This "application" versus "enterprise" view
implies an evolutionary approach to data base design, which is
natural.
The integration of ALDBM Objects into the ELDBM is
developed through an iterative process of reviews and
modifications to either model by Data Engineering. Since
Objects are identified through the same criteria for both
logical models, they should be compatible. In fact, in a
hypothetical situation of a completely new enterprise, the first
Application Logical Data Base Model becomes the Enterprise
Model.
ELDBM TO EPDBM RELATIONSHIPS
During Phase 4, Data Base Administration will design and
develop the Enterprise Physical Data Base Model (EPDBM). This
will consist of physical files and records that must store the
data needed to satisfy the ELDBM. There is not always a one-to-
one relationship between logical and physical structures. One
logical file may be implemented by multiple physical files.
Conversely, one physical file may implement many logical files.
As we will see in the physical design phases (4 and 5), physical
implementation is based on what is cost-effective and may take
many forms (e.g., indexed files, indexed sequential, flat files,
hierarchical/network/relational DBMS, etc.). The point is, the
relationships between logical and physical must be mapped in the
IRM to demonstrate that the physical implementation satisfies
the logical. Again, this mapping is performed in Phase 4.
RECORD DESCRIPTION (RD)
As this discussion indicates, the Record Description (RD)
resource in the IRM is used for a variety of purposes. In a
logical context, the RD represents a "View"; in a physical
context, the RD represents a "Record." The RD is also used to
represent other physical structures, such as: screen panels,
print maps, input transactions, output data, messages, tables,
etc. All of these structures exhibit the same characteristics;
all require some form of unique key, and all contain data
elements.
The File Description (FD) is used to represent logical
files (Objects), physical files, and data bases. Files consist
of records, thereby an FD/RD relationship is required. A data
base represents a global view of data, therefore an FD/FD
relationship is used to map all of the files within a data base.
The RD is also the primary resource used to map the
relationships between all four data base models. Although the
File Description (FD) provides for FD-to-FD relationships, it is
the RD that is used to connect the models.
The following diagram illustrates all of the BASIC
relationships needed to map the four data base models in the
IRM. Additional pointers are available for different purposes,
particularly for complicated physical file structures.
IRM RESOURCE RELATIONSHIPS - MAPPING THE FOUR DATA BASE MODELS
This diagram illustrates all of the BASIC relationships needed to map the four data base models. Additional pointers are available for different purposes, particularly for complicated physical file structures. ELDBM REPRESENTATION There are two complementary ways to graphically express the ELDBM:
The first relationship between Customer/Order represents a one-to-many relationship; a Customer can place many Orders, but an Order pertains to a single Customer. The second relationship expresses a many-to-many relationship; an Order may be for many different Products, and a Product can relate to many Orders.
Two types of ELDBM Matrices are available. The ELDBM Views Matrix expresses the relationships between logical records. The ELDBM Objects Matrix expresses the relationships between logical files; this is deduced from subordinate record relationships.
DESCRIPTION OF PHASE ACTIVITIES
Activity A - Define Enterprise Objects
Data Engineering reviews either:
Activity B - Design Enterprise Logical DB Model
Data Engineering defines the relationships between
Objects using RD-to-RD relationships.
Data Engineering then assembles the deliverables produced
in the phase and packages them into a single phase review
document which is evaluated by Quality Assurance prior to
conducting the formal phase review with management.
Data Engineering conducts a formal review of the
Phase 3 deliverables with Data Resource Management,
Project Management, and Data Base Administration.
The review is used to evaluate the work performed thus
far and revise as required. At this time, management
will review the formal Phase 3 "ELDBM Design
Manual" consisting of:
** May be considered optional due to the nature of the project.
Based on this report and subsequent review meeting,
management may elect to revise parts of the report,
discontinue the project, or approve it for continuation.
| |||||
