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 enti
Trang 1208 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 1 1
expirationDate flightNumber
publishedFlightID
PublishedFlight
frequency effectiveDate expirationDate airlineID (FK) (AK1.1) flightNumber (AK1.2)
airlineID
Airline
airlineCode (AK1.1) airlineName
Trang 2• 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)
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
Trang 3210 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)
Trang 4Several 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
Trang 5212 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