"PRIDE"-Data Base Engineering Methodology (DBEM)

PRIDE

-DBEM

Data Base Engineering Methodology
PHASE 3 - ENTERPRISE LOGICAL DATA BASE DESIGN
ACTIVITY B - DESIGN ENTERPRISE LOGICAL DATA BASE MODEL

EXAMPLES TOOLS & TECHNIQUES FUNCTIONAL MATRIX CHECKLIST FORMS

TRANSLATE THIS PAGE TO... Chinese (simple) Japanese Dutch French German Italian
Free Translation courtesy of ALS Chinese (traditional) Korean Portuguese Russian Spanish

CONTENTS

This section contains the following:

BUSINESS PURPOSE

OVERVIEW

STEPS IN EXECUTION

SUPPLEMENTAL INFORMATION (separate sections)
- Phase 3 Review Checklist

BUSINESS PURPOSE

The purpose of this activity is to establish the relationships between objects and to package the deliverables for review in the next activity. It is performed by Data Engineering and is patterned after the steps in Phase 3, Activity B. If the DBEM project is in support of an EEM project, this activity is not necessary.

OVERVIEW

In the previous activity, FD/RD/DD resources were defined to model pertinent Objects (logical files) within the enterprise. To complete this process, Data Engineering must now explicitly define the relationships between the various objects. This should be a relatively simple task if the last activity was performed correctly.

Expressing object relationships fundamentally represents business rules; for example, a Customer can place many Orders; a Billing relates to a single Customer, etc. These rules help establish integrity constraints for the physical data base to implement.

The objective of this activity is to define the relationships between objects as derived from the various ALDB Models. A logical file within the ELDBM represents a complete "global" description of an object. Whereas, there may be multiple versions of the same object in different ALDB Models, there can only be one version of an object in the ELDBM. In other words, there may be many versions of the "Customer Object" in various ALDB Models, but there can only be one "Customer Object" in the ELDBM. Because of this, the relationships between objects in the ELDBM cannot be different than the rules represented in the ALDBM. This also means that there cannot be any conflicts in object relationships between various ALDB Models. To illustrate, one ALDBM may dictate that a Customer can place only one Order; another ALDBM may conflict with this rule by stating that a Customer can place many Orders. It is Data Engineering's responsibility to resolve these relationship inconsistencies. This should have been accomplished in Phase 2, but must be clarified in this activity.

The "basic grouping" of logical views and the fact/event phenomenon are extremely useful for determining the existence of relationships between objects. An "event" represents some form of interaction between two fact-related objects. In other words, the "event" is the catalyst that bridges the two facts. Consequently, it is the "Relationship View" within the event object that represents the go-between of the fact-related Objects. The "basic grouping" of the "Relationship View" should define the fundamental relationship. For example, within an "Order Object," the basic grouping for the "Relationship View" may consist of:

ORDER NUMBER <-- primary basic grouping for the Order Object CUSTOMER NUMBER <-- foreign key to the Customer Object PRODUCT NUMBER <-- foreign key to the Product Object

This implies relationships between a Customer and an Order and a Product.

---------------- ---------------- ----------------- | CUSTOMER | | ORDER | | PRODUCT | |IDENTIFICATION|-------| RELATIONSHIP |-------|IDENTIFICATION | | VIEW | | VIEW | | VIEW | ---------------- ---------------- -----------------

Now that these relationships have been established, it is necessary to explicitly define the type of relationships. For example:

Can a Customer place many Orders or only one?
Does an Order relate to a single Customer or to many?
Does an Order relate to only one Product or many?
Does a Product relate to many Orders or just one?

---------------- ---------------- ----------------- | CUSTOMER | | ORDER | | PRODUCT | |IDENTIFICATION|<---->>| RELATIONSHIP |<<--->>|IDENTIFICATION | | VIEW | | VIEW | | VIEW | ---------------- ---------------- ----------------- 1:M M:M

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 Order/Product Relationship expresses a many-to-many relationship; a single Order may be for many Products, and one Product may be used by many Orders.

Relationships between objects are defined using the RD/RD Relationship in the IRM. This means that the relationship between views is the primary means by which objects are related, not by FD/FD Relationships. In other words, to properly understand the relationship between logical files, you must examine their subordinate logical records, and their relationships to other logical records.

GRAPHICS

To represent the relationships between the objects, Data Engineering prepares the following graphics:

ELDBM Objects Matrix - a table consisting of columns and rows that express relationships between logical files (as deduced from their views).
ELDBM Views Matrix - a table consisting of columns and rows that express relationships between logical records.
ELDBM Diagram - a diagram expressing relationships between objects (as deduced from their views).
NOTE: Due to the size of the ELDBM, it may not be practical to produce this diagram in its entirety; rely on the matrices instead.

PROJECT MANAGEMENT CONSIDERATIONS

Activity B also provides the opportunity to review the Project Plan and the Project Estimate/Schedule Recap. These deliverables were initially prepared in Phase 1, Activity F. They are now reviewed and updated as required.

PREPARING FOR REVIEW

Data Engineering assures that all of the Phase 3 activities and materials have been properly completed. A Phase Review Checklist is available for this purpose. A formal Phase 3, "ELDBM Design Manual" is then prepared. The manual is reviewed and checked by Quality Assurance prior to distribution to management for review.

The Phase 3 Manual contains the following items:

Phase Cover Page - including a Table of Contents, along with a distribution/approval list.
ELDBM Narrative - as prepared in Activity A.
ELDBM Objects Matrix - as prepared in this activity.
ELDBM Views Matrix - as prepared in this activity.
ELDBM Diagram - as prepared in this activity.
NOTE: Due to the size of the ELDBM, it may not be practical to produce this diagram in its entirety; rely on the matrices instead.
Data Structure Display - as prepared in Activity A.
ALDBM/ELDBM Objects Matrix - as prepared in this activity.
NOTE: If this is an EEM related project, this matrix is not pertinent.
ALDBM/ELDBM Views Matrix - as prepared in this activity.
NOTE: If this is an EEM related project, this matrix is not pertinent.
Project Plan - as prepared in this activity.
Project Estimate/Schedule Recap - as prepared in this activity.
Phase Review Checklist - specifying acceptance criteria for the deliverables mentioned above.

STEPS IN EXECUTION

Data Engineering defines the relationships between objects via "Relationship Views." These relationships are depicted using ELDBM Matrices and the ELDBM Diagram.

Data Engineering consults the relationships between objects as expressed in related ALDB Models. If conflicting object relationships are encountered between ALDB Models, they are resolved by the Data Engineer.

Data Engineering and Project Management review the Project Plan and Project Estimate/Schedule Recap. If necessary, both are updated at this time.

Data Engineering and Project Management prepares a formal Phase 3 manual, "ELDBM Design Manual."

Quality Assurance reviews the "ELDBM Design Manual" for consistency. Data Engineering and Project Management implement changes accordingly.

Data Engineering schedules a Phase 3 review meeting with Data Resource Management, Project Management, and Data Base Administration. Copies of the "ELDBM Design Manual" are distributed to management prior to the review meeting.