2. Database Design Using Entity-Relationship Models zMapping E-R models into relations zFour common data structures

3. 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

4. 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.

5. 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)

6. 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)

7. 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

8. 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!

9. 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!

10. 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?)

11. 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?

12. 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)

13. 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

14. 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

15. 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

16. Simple Networks zOnly 1:N relationships zBut a child can have more than one parent (of different types) zObvious relational representation

17. Complex Networks zA child can have multiple parents of the same type zAt least one N:M relationship zNeed intersection relations(s)

18. Bills of Materials zA special case of networks zM:N recursive relationships zForeign keys in intersection relation have same domain

19. Example: Practice!...

20. Another Example: Overhead zEMPLOYEE: SSN, Fname, Minit, Lname, BirthDate, Address, JobType SECRETARY: SSN, TypingSpeed TECHNICIAN: SSN, TGrade ENGINEER: SSN, EngType zEMPLOYEE: SSN, Fname, Minit, Lname, BirthDate, Address, JobType, TypingSpeed, Tgrade, EngType

21. Another Example: Overhead zCAR: VehicleID, LicensePlateNo, Price MaxSpeed, NoOfPassengers TRUCK: VehicleID, LicensePlateNo, Price, NoOfAxles, Tonnage zPART: PartNo, Description, MFlag, DrawingNo, ManufactureDate, BatchNo, PFlag, SupplierName, ListPrice

22. Another Example: Overhead zPERSON: SSN, Fname, Minit, Lname, BDate, No, Street, AptNo, City, State, Zip EMPLOYEE: SSN, Salary, Rank, Office, Phone STUDENT: SSN, Class, Gflag GRAD_DEGREES: SSN, Year, Degree, College INSTRUCTOR_RESEARCHER: SSN