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

Example: Practice!...

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

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

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