An advantage of value-based identity is that primary keys have intrinsic meaning.. With value-based identity and referential integrity, the two paths lead to two copies of bankID and acc
Trang 1• Value-based identity A combination of application attributes identify each entity In
Figure 16.13 names identify Region, Bank, and AccountType Account is identified by bankName combined with accountNum An advantage of value-based identity is that
primary keys have intrinsic meaning
However primary key values can be difficult to change — a change to a primary key may require propagation to many foreign keys Some entities lack natural real-world identifiers Also primary keys can become lengthy, from the foreign keys of a se-ries of related tables as Figure 16.14 illustrates Figure 16.15 shows an awkward situation
for Transaction With value-based identity and referential integrity, the two paths lead to two copies of bankID and accountNumber With value-based identity developers must
abandon referential integrity to have a single copy of the fields
• Hybrid identity A schema can combine existence-based identity with value-based
identity In Figure 16.16 Region, Bank, and AccountType have artificial identity and Ac-count has identity derived from a bank reference combined with an acAc-count number.
• Propagated identity Identity can also propagate from one entity type to another In
Figure 16.17 the primary key of Exercise is also the primary key for Answer (A book
can have many exercises; an exercise may have an answer.) This is seldom a good idea
as there is a “leakage” of information from one entity type to the other
Bank
name {unique}
Account
Region
name {unique}
*
1
1
AccountType
name {unique}
1
*
accountNum 0 1
Figure 16.12 Existence-based + lookups (recommended): Example
Another option is to use a mnemonic abbreviation for look-ups and existence-based identity for everything else
IDEF1X model
accountID
Account
bankID (FK) (AK1.1) accountNum (AK1.2) accountTypeName (FK)
bankID
Bank
bankName (AK1.1) regionID (FK)
accountTypeName
AccountType
regionID
Region
regionName (AK1.1)
UML model
Trang 2214 Chapter 16 / Relational Database Design
Bank
name {unique}
Account
Region
name {unique}
*
1
1
AccountType
name {unique}
1
*
accountNum 0 1
UML model
IDEF1X model
bankName
Bank
regionName (FK)
accountTypeName
AccountType
regionName
Region
Figure 16.13 Value-based identity (discouraged): Example A combination
of application attributes identify each entity
Account
bankName (FK) accountNum accountTypeName (FK)
cityName stateProvinceName
Country
countryName
1 0 1
1 0 1
StateProvince
streetAddress
Address 0 1 1
StateProvince
countryName (FK) stateProvinceName
Figure 16.14 Value-based identity: Flaw A sequence of foreign keys
can lead to lengthy primary keys
UML model
IDEF1X model
countryName
Country
City
countryName (FK) stateProvinceName (FK) cityName
Address
countryName (FK) stateProvinceName (FK) cityName (FK)
streetAddress
City
Trang 3Figure 16.15 Value-based identity: Flaw The two paths lead to two copies
of bankID and accountNumber for Transaction You must
abandon referential integrity to have a single copy
bankID
bankName (AK1)
customerID customerName address
accountNumber accountStartDate currentBalance balanceDate customerID (FK)
transactionID transactionDate amount transactionType
BankAccount
bankID (FK)
Customer Bank
MonthlyStatement
bankID (FK)
closingBalance
accountNumber (FK) statementDate
Transaction
bankID1 (FK) accountNumber1 (FK) bankID2 (FK)
accountNumber2 (FK) statementDate (FK)
Owns Holds
Has
Posts
Lists
Bank
name {unique}
Account
Region
name {unique}
*
1
1
AccountType
name {unique}
1
*
accountNum 0 1
UML model
IDEF1X model
bankID
Bank
bankName (AK1.1) regionID (FK)
accountTypeID
AccountType
accountTypeName (AK1.1) regionID
Region
regionName (AK1.1)
Figure 16.16 Hybrid identity (discouraged): Example A schema can
combine existence-based identity with value-based identity
Account
bankID (FK) accountNum accountTypeID (FK)
Trang 4216 Chapter 16 / Relational Database Design
Table 16.1 summarizes the approaches to design identity and their trade-offs
16.6 Referential Integrity
Once the IDEF1X model is in place, you should define referential integrity actions to enforce the model’s meaning Referential integrity is a database mechanism that ensures that refer-ences to data really exist and that there are no dangling foreign keys Normally you should let a DBMS enforce referential integrity constraints rather than write custom application code If you use existence-based identity, there are no primary key updates to propagate and referential integrity actions are only needed for deletions
Neither the UML model nor the IDEF1X model specify referential integrity precisely,
so you will have to rely on your application understanding I recommend the following guidelines for deletions
• Generalization Cascade deletions for foreign keys that arise from generalization For
example, in Figure 16.18 OwnedAsset is a subtype of Asset and ownedAssetID
referenc-es assetID Upon deletion, an Asset record and an OwnedAsset record should both be
deleted Given separate supertype and subtype tables, there should be a on delete cas-cade clause for each subtype reference to the supertype
A relational DBMS can propagate deletion downward from the supertype to the subtypes However, a relational DBMS cannot propagate deletion upward from a
sub-type toward the supersub-type For example, the deletion of an Asset record could cause the deletion of the corresponding OwnedAsset Then the deletion of an OwnedAsset could cause deletion of its RentedAssets But deletion of a RentedAsset record cannot propa-gate upward to Asset Consequently, it is necessary to first delete the Asset records that are RentedAssets and then delete the Asset record for the OwnedAsset.
Some organizations forbid cascaded deletions as a matter of policy (fearful of inad-vertent errors) In that case there will have to be additional programming code to prop-agate a deletion from a supertype record to descendant subtype records
Figure 16.17 Propagated identity (discouraged): Example Identity can
also propagate from one entity type to another
UML model
IDEF1X model
Exercise
exerciseNumber exerciseText
Answer
answerText
1 0 1
exerciseID
Exercise
exerciseNumber exerciseText
Answer
exerciseID {FK) answerText
Trang 5• Buried relationship, minimum multiplicity of zero There are two choices — either
set the foreign key to null or forbid deletion The choice depends on a model’s meaning
For example in Figure 10.23, upon deletion of a Facility the references in the corre-sponding Locations should be set to null In contrast, it is appropriate to forbid the de-letion of a Document with child Documents via DocumentFlow (Figure 10.15).
• Buried relationship, minimum multiplicity of one Forbid the deletion or cascade the
effect of a deletion For example, in Figure 10.1 it should not be possible to delete an
AccountType that is referenced by Accounts In Figure 10.5 the deletion of an Address
Identity
approach Definition Advantages Drawbacks
Recommen-dation
Existence-based
An artificial
number is the
primary key of
each entity
• PKs are single attribute, small, and uniform in size
• Handles entities without real-world identifiers
• IDs can compli-cate debugging
A good choice
Existence-based +
lookups
A mnemonic for
lookups and
existence-based
for everything
else
• PKs are single attribute, small, and uniform in size
• Handles entities without real-world identifiers
• Simpler debug-ging than with existence-based identity alone
A good choice
Value-based
A combination
of application
attributes
identi-fies each entity
• PKs have intrinsic meaning
• Propagated PK values are diffi-cult to change
• Some entities lack real-world identifiers
• Can have multi-ple paths for the same FK
Seldom a good idea
Hybrid
Schema
com-bines
existence-based and
value-based identity
• Irregular approach that lacks rigor
A poor option
Propagated
PK of an entity
comes from a
relationship
• Awkward depen-dency between entities
A poor option
Table 16.1 Summary of Approaches to Design Identity
Note: I recommend the use of existence-based identity or existence-based + lookups.