Database Design Using Entity-Relationship Models

Mapping E-R models into relationsFour common data structures

Mapping E-R Models to Tables

We may not be familiar with all notationsThere may be E-R constructs that cannot

be translated directly Multi-valued attributes Ternary relationships

We may need to change the data model Change a relationship into an entity Change an entity into an attribute Collapse two entities Make a strong entity weak

Basic Conversion Rules

A database conforming to an E-R diagram can be represented by a collection of tables.

Converting an E-R diagram to a table format is the basis for deriving a relational database design from an E-R diagram. Primary keys allow entities and relationships to

be expressed uniformly as tables. For each entity and many-to-many relationship

there is a unique table, named after it. Each table has columns (generally corresponding

to attributes) with unique names.

Representing Entities as Tables

A strong entity set reduces to a table with the same attributes

CUSTOMER (CustNumber, CustName, Address, City,State, Zip, ContactName, PhoneNumber)

Representing Entities

We then may need to normalize the table if it is not in DK/NF

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

Weak entity sets must be documented by referential integrity constraints

An ID-dependent weak entity set becomes a table that includes a column for the primary key of the identifying strong entity

The table corresponding to the weak relationship is redundant

Representing HAS-A Relationships

1:1 - Place key of one relation into other Perhaps they should be combined!

1: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

Intersectionrelation

Error!

Recursive Relationships

Same as non-recursive relationships

One participant instead of two

E.g., 1:1 Remember two

alternatives Foreign key can have

NULL values (when?)

Recursive Relationships

What about 1:N and M:N recursive? Give an example of each, not from book :) How many tables do you end up with, in

each case? How is this different from the non-recursive

case? What is the domain of the foreign key?

Higher-order Relationships

Treat as combination of binary relationshipsBinary constraints must be enforced with

business rulesTypes of constraints:

MUST (ORDER:CUSTOMER:SALESPERSON)ORDER(OrdNo, CustNo, SalespersonNo, ...)CUSTOMER(CustNo, SalespersonNo, ...)SALESPERSON(SalespersonNo, ...)

MUST NOT (PRESCRIPTION:DRUG:PATIENT) MUST COVER (AUTO:REPAIR:TASK)

Representing IS-A Relationships

Specialization method Form a table for each sub-type entity No table for generalized (super-type) entity Common attributes are repeated

Representing IS-A Relationships

Generalization method Form a table for the super-type entity Form a table for each sub-type entity (include

primary key of generalized entity set, 1:1) Common attributes are inherited

Need this?Usually same key

Trees (hierarchies)

Nodes are entitiesOnly 1:N relationships

(branches)Each child has a

unique parent Root: unique node

without parent Siblings: children

sharing parentObvious relational

representation

Root

Simple Networks

Only 1:N relationships

But a child can have more than one parent (of different types)

Obvious relational representation

Complex Networks

A child can have multiple parents of the same type

At least one N:M relationshipNeed intersection relations(s)

Bills of Materials

A special case of networksM:N recursive relationshipsForeign keys in intersection

relation have same domain

Example: Practice!...

Another Example: Overhead

EMPLOYEE: SSN, Fname, Minit, Lname, BirthDate, Address, JobTypeSECRETARY: SSN, TypingSpeedTECHNICIAN: SSN, TGradeENGINEER: SSN, EngType

EMPLOYEE: SSN, Fname, Minit, Lname, BirthDate, Address, JobType, TypingSpeed, Tgrade, EngType

Another Example: Overhead

CAR: VehicleID, LicensePlateNo, Price MaxSpeed, NoOfPassengers

TRUCK: VehicleID, LicensePlateNo, Price, NoOfAxles, Tonnage

PART: PartNo, Description, MFlag, DrawingNo, ManufactureDate, BatchNo, PFlag, SupplierName, ListPrice

Another Example: Overhead

PERSON: 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