Database Design Using Entity-Relationship Models zMapping E-R models into relations zFour common data structures
Mapping E-R Models to Tables zWe may not be familiar with all notations zThere may be E-R constructs that cannot be translated directly yMulti-valued attributes yTernary relationships zWe may need to change the data model yChange a relationship into an entity yChange an entity into an attribute yCollapse two entities yMake a strong entity weak
Basic Conversion Rules z A database conforming to an E-R diagram can be represented by a collection of tables. zConverting an E-R diagram to a table format is the basis for deriving a relational database design from an E-R diagram. yPrimary keys allow entities and relationships to be expressed uniformly as tables. y For each entity and many-to-many relationship there is a unique table, named after it. yEach table has columns (generally corresponding to attributes) with unique names.
Representing Entities as Tables zA strong entity set reduces to a table with the same attributes CUSTOMER (CustNumber, CustName, Address, City, State, Zip, ContactName, PhoneNumber)
Representing Entities zWe then may need to normalize the table if it is not in DK/NF zDe-normalize? CUSTOMER (CustomerNumber, Address, Zip, ContactName) ZIP-TABLE (Zip, City, State) CONTACT (ContactName, PhoneNumber) Interrelation (integrity) constraints: CUSTOMER[Zip] ZIP-TABLE[Zip] CUSTOMER[ContactName] CONTACT[ContactName] CUSTOMER (CustNumber, CustName, Address, City, State, Zip, ContactName, PhoneNumber)
Representing Weak Entities zWeak entity sets must be documented by referential integrity constraints zAn ID-dependent weak entity set becomes a table that includes a column for the primary key of the identifying strong entity zThe table corresponding to the weak relationship is redundant
Representing HAS-A Relationships z1:1 - Place key of one relation into other yPerhaps they should be combined! z1:N - Place key of parent into child Foreign key!
Representing HAS-A Relationships M:N - Build a table with columns for primary keys of two participating entity sets May add descriptive attributes of relationship set Intersection relation Error!
Recursive Relationships zSame as non-recursive relationships zOne participant instead of two zE.g., 1:1 yRemember two alternatives yForeign key can have NULL values (when?)
Recursive Relationships zWhat about 1:N and M:N recursive? yGive an example of each, not from book :) yHow many tables do you end up with, in each case? yHow is this different from the non-recursive case? yWhat is the domain of the foreign key?
Higher-order Relationships zTreat as combination of binary relationships zBinary constraints must be enforced with business rules zTypes of constraints: yMUST (ORDER:CUSTOMER:SALESPERSON) xORDER(OrdNo, CustNo, SalespersonNo,...) xCUSTOMER(CustNo, SalespersonNo,...) xSALESPERSON(SalespersonNo,...) yMUST NOT (PRESCRIPTION:DRUG:PATIENT) yMUST COVER (AUTO:REPAIR:TASK)
Representing IS-A Relationships zSpecialization method yForm a table for each sub-type entity No table for generalized (super-type) entity Common attributes are repeated
Representing IS-A Relationships zGeneralization method yForm a table for the super-type entity yForm a table for each sub-type entity (include primary key of generalized entity set, 1:1) yCommon attributes are inherited Need this? Usually same key
Trees (hierarchies) zNodes are entities zOnly 1:N relationships (branches) zEach child has a unique parent yRoot: unique node without parent ySiblings: children sharing parent zObvious relational representation Root
Simple Networks zOnly 1:N relationships zBut a child can have more than one parent (of different types) zObvious relational representation
Complex Networks zA child can have multiple parents of the same type zAt least one N:M relationship zNeed intersection relations(s)
Bills of Materials zA special case of networks zM:N recursive relationships zForeign keys in intersection relation have same domain