208 Chapter 16 / Relational Database Design would have been correct to bury the relationships, but from an architectural point of view I wanted to isolate dependencies between subject areas. 16.3 Mapping Qualified Relationships There are four possible situations for qualified relationships. • One-to-optional after qualification. This is the most common situation (Figure 16.6). The underlying relationship is one-to-many without the qualifier and you should bury the source entity type key and the qualifier in the “many” table. The combination of the source entity type plus the qualifier is unique. Figure 16.5 Ordered relationship: Mapping. Use the same mapping as without ordering. The source entity type plus a sequence number is unique. IDEF1X model UML model ListedCourse name ListedLesson name scheduledDuration * 1 {ordered} listedCourseID ListedCourse listedCourseName listedLessonID ListedLesson listedLessonName scheduledDuration listedCourseID (FK) (AK1.1) sequenceNumber (AK1.2) Figure 16.6 Qualified relationship, one-to-optional: Mapping. Bury fields in the “many” table. The source entity type plus the qualifier is unique. IDEF1X model UML model PublishedFlight frequency effectiveDate airlineCode {unique} airlineName Airline 0 11 expirationDate flightNumber publishedFlightID PublishedFlight frequency effectiveDate expirationDate airlineID (FK) (AK1.1) flightNumber (AK1.2) airlineID Airline airlineCode (AK1.1) airlineName 16.3 Mapping Qualified Relationships 209 • Optional-to-optional after qualification. This situation is also common (Figure 16.7). Bury the source entity type key and the qualifier in the table that is “many” without qual- ification. In the example, one record (the root of the tree has a null parentID) keeps the source entity type plus the qualifier from being unique. (As an alternative, you can pro- mote the relationship to a table and then the qualified relationship has a unique key.) • Many-to-optional after qualification. These qualified relationships seldom occur (Figure 16.8). Promote the relationship to a table with a primary key of the source entity type plus the qualifier. Note that the combination of the related entity types (assemblyID and componentID in Figure 16.8) need not be unique; the same component part may be used multiple times for the same assembly. For example, a wiper may be used for the left windshield, right windshield, and rear window. <Node><Tree> child parent root 0 1 1 0 1 0 1 nodeName treeID rootID (FK) (AK1.1) nodeID parentID (FK) Tree Node nodeName Figure 16.7 Qualified relationship, optional-to-optional: Mapping. Bury fields in the “many” table. The source entity type plus the qualifier is not unique. IDEF1X model UML model Contains quantity assembly component role * 0 1 CatalogPart modelNumber Figure 16.8 Qualified relationship, many-to-optional: Mapping. Promote the relation- ship to a table with a primary key of the source entity type plus the qualifier. IDEF1X model UML model catalogPartID CatalogPart modelNumber Catalog_assemblyComp assemblyID (FK) role componentID (FK) quantity 210 Chapter 16 / Relational Database Design • Optional-to-many after qualification. These qualified relationships also seldom occur (Figure 16.9). Bury the source entity type key and the qualifier in the “many” table. In the example the “ordered” constraint yields an alternate key — the combination of the source entity type plus the qualifier plus a sequence number is unique. If “ordered” was omitted from the model, there would still be a buried source entity type key plus the qualifier, but no alternate key constraint. 16.4 Mapping: Generalizations Generalization organizes entity types by their similarities and differences. This book only considers single inheritance—a generalization for which a subtype has one supertype. (Chapter 8 recommends that data models avoid multiple inheritance—a generalization for which a subtype has multiple supertypes.) As Figure 16.10 shows, I recommend that you map the supertype and each subtype to a table. The tables share common primary key values. The discriminator indicates the appro- priate subtype table for each supertype record. Views can be helpful for consolidating the data of an entity across generalization levels. Relational databases only partially support generalization. Relational databases cannot express the generalization partition, that each supertype record is further described by exact- ly one subtype. Also referential integrity is a one-way mechanism and cannot enforce the two-way correspondence between records of a supertype and a subtype. (Section 16.6 elab- orates.) Applications must compensate with additional programming. PublishedFlightLeg scheduledDepartureTime scheduledDuration ActualFlightLeg actualDepartureTime actualDuration departureDate 0 1 * {ordered} Figure 16.9 Qualified relationship, optional-to-many: Mapping. Bury fields in the “many” table. The source entity type plus the qualifier alone is not unique. IDEF1X model UML model publishedFlightLegID PublishedFlightLeg scheduledDepartureTime scheduledDuration actualFlightLegID ActualFlightLeg actualDepartureTime actualDuration publishedFlightLegID (FK) (AK1.1) departureDate (AK1.2) sequenceNumber (AK1.3) 16.4 Mapping: Generalizations 211 Several alternative mappings are sometimes helpful for generalization. • Elimination. You can optimize away tables that have no attributes other than a primary key. This reduces the number of tables but provides an irregular implementation. • Push supertype attributes down. You can eliminate the supertype table and duplicate supertype attributes for each subtype. This has the advantage of describing each entity in one table. However, it causes redundancy of structure and you may need to search multiple subtype tables to find an entity. • Push subtype attributes up. As a third alternative, you can eliminate the subtype tables and store all subtype attributes in the supertype table. Each record populates the relevant columns. This describes each entity in one table, but violates third normal form. • Generalization table. Use separate tables for the supertype and the subtypes and im- plement the generalization itself as a table. This can be helpful if you are merging two databases, one of which has the supertype and the other which has subtypes. Figure 16.10 Generalization (single inheritance): Mapping: Map the supertype and each subtype to a table. IDEF1X model UML model Opportunity name status RawLead inquiryDate Deal closeDate source probabilityOfClosing QualifiedLead qualificationDate opportunityDiscrim QualifiedLead qualifiedLeadID (FK) qualificationDate RawLead rawLeadID (FK) inquiryDate Deal dealID (FK) opportunityID Opportunity opportunityName status probabilityOfClosing opportunityDiscrim source closeDate 212 Chapter 16 / Relational Database Design 16.5 Design Identity Chapter 11 discussed intrinsic identity — the ability to start from outside a database and find data with fields that have application meaning. In contrast, design identity is the ability to find data within a database. Databases implement design identity with primary keys. A pri- mary key is a candidate key that is chosen for internal (foreign key) references. A table nor- mally has a primary key, and has at most one primary key. There are several approaches to implementing primary keys. Of these approaches I favor existence-based identity and existence-based identity + lookups. • Existence-based identity. An artificial number (called an ID) is the primary key of each entity table (Figure 16.11). The major DBMS products can generate such numbers; ex- amples include Oracle sequences and the SQL Server identity property. With existence- based identity all primary keys are single attribute, small, and uniform in size. One of the few downsides is that the IDs can complicate debugging. (When debugging you have to dereference IDs to see meaningful fields.) • Existence-based identity + lookups. Another option (Figure 16.12) is to use a mne- monic abbreviation for lookup tables, and existence-based identity for everything else. “Lookup” data means metadata such as AccountType that is often implemented as a pick list in a user interface. Lookup tables have a small number of records (usually no more than tens of records) that are seldom updated. Figure 16.11 Existence-based identity (recommended): Example. A system- generated field is the primary key of the table for each entity. IDEF1X model Bank name {unique} Account UML model Region name {unique} * 1 1 AccountType name {unique} 1 * accountID Account bankID (FK) (AK1.1) accountNum (AK1.2) accountTypeID (FK) bankID Bank bankName (AK1.1) regionID (FK) accountTypeID AccountType accountTypeName (AK1.1) regionID Region regionName (AK1.1) accountNum 0 1 . else. “Lookup” data means metadata such as AccountType that is often implemented as a pick list in a user interface. Lookup tables have a small number of records (usually no more than tens of records). from outside a database and find data with fields that have application meaning. In contrast, design identity is the ability to find data within a database. Databases implement design identity. can be helpful for consolidating the data of an entity across generalization levels. Relational databases only partially support generalization. Relational databases cannot express the generalization