16.5 Design Identity 213 • 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 account 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 214 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 10 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 16.5 Design Identity 215 Figure 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) CustomerBank MonthlyStatement bankID (FK) closingBalance accountNumber (FK) statementDate Transaction bankID1 (FK) accountNumber1 (FK) bankID2 (FK) accountNumber2 (FK) statementDate (FK) OwnsHolds 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) 216 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 supertype. 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 16.6 Referential Integrity 217 • 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 Va lu e- 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. . 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. 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 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