Database Reference
In-Depth Information
Here are my thoughts during this grouping process:
•
The subtypes are dependent entities to their supertype, and therefore frequently we
roll subtypes up to supertypes and add type codes to the supertype such as
custom-
erTypeCode
and
accountTypeCode
.
•
We have a one-to-one relationship between
Check
and
CheckDebit
, which is a
great candidate, therefore, for embedding
Check
into
CheckDebit
.
•
The documents, such as
WithdrawalSlip
, and their corresponding transactions,
such as
WithdrawalDebit
, have similar volatility and therefore are good candid-
ates for embedding. I would not initially embed these transactions and documents
into
Account
because of the high difference in volatility with
Account
. We might
have millions of transactions, yet only 1,000 accounts that change on a regular
basis, for example.
•
Assuming stable branch data, we can embed
Branch
in
Account
.
•
For now,
Customer
and
Account
remain separate collections. Often many-to-
many relationships become references instead of embedded collections because of
the complexities of storing a complex relationship in one structure.
Here is the completed relational PDM after making these changes:
For Dimensional
