In the previous activity, FD/RD/DD resources were defined
to model pertinent Objects (logical files) within the
application. To complete this process, Systems 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.
The objective of this activity is to:
- Determine if a relationship exists between two objects, and;
- If so, define the type of relationship.
Expressing these 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 "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:
<![CDATA[
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.
<![CDATA[
---------------- ---------------- -----------------
| 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?
<![CDATA[
---------------- ---------------- -----------------
| 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,
Systems Engineering prepares the following graphics:
- ALDBM Objects Matrix - a table consisting of
columns and rows that express relationships between logical files
(as deduced from their views).
- ALDBM Views Matrix - a table consisting of
columns and rows that express relationships between logical
records.
- ALDBM Diagram - a diagram expressing relationships
between objects (as deduced from their views).
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
Systems Engineering assures that all of the Phase 2
activities and materials have been properly completed. A Phase
Review Checklist is available for this purpose. A formal Phase
2, "ALDBM Design Manual" is then prepared. The manual
is reviewed and checked by Quality Assurance prior to distribution
to management for review.
The Phase 2 Manual contains the following items:
- Phase Cover Page - including a Table of Contents,
along with a distribution/approval list.
- Application Logical Files Discussion - as prepared
in Activity A.
- ALDBM Objects Matrix - as prepared in this activity.
- ALDBM Views Matrix - as prepared in this activity.
- ALDBM Diagram - as prepared in this activity.
- Data Structure Display - as prepared in Activity A.
- 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.