The Entity-Relationship Model

CS3431: C-Term 2013 1

The Entity-Relationship Model

Part II.

Instructor: Mohamed Eltabakh [email protected]

2

Entities with Different Attribute Types (Recap)

Composite Attribute: address

Multivalued Attribute: major

major

sta testree t

address

city

Derived Attribute: Age

AgeAge

Student entity typewith all its attributes

S tudent

sN am esN um ber

sA ge

m ajor

sta testree t

address

city

AgeAge

DoBDoB

Primitive Attribute: sNumber

sNumbersNumber

Binary Relationships (Recap)

3

suppliersupplier

sNamesName

sLocsLoc

consumerconsumer

cNamecName

cLoccLoc

productproduct

pNumber

pNumber sNamesName

sPricesPrice

suppliessupplies buysbuys

datedatequantityquantity

Attributes can be attached to Entity Sets or Relationships

4

Multi-Way Relationships (Recap)

Supplier

sName

sLoc

Consumer

cName

cLoc

Supply

price

Product

pName pNumber

qty

Model the relationship Supplier supplies Products to Consumers

Ternary relationship(three-way)

5

Recursive Relationship Types and Roles

Refer to the same entity set in the relationship

Recursive relationship type : Part-Subpart

Roles: There are Parts that play the role of superPartThere are Parts that play the role of subPart

Contains

Part

pName pNumber

subPartsuperPart

quantity

If two entities in the same entity set have a relationship Recursive relationship

If two entities in the same entity set have a relationship Recursive relationship

Recursive Relationships: Another Example

6

Employees & Managers

Employee

ID

Name

Supervisesupervisor

supervised

More Elements in ER Model

Key Constraints

Cardinality Constraints

Weak Entities

Subclass Entities (ISA Relationships)

Principles for Good Design

7

Keys of Entity Sets

Remember entity set is a group of entities with the same type

Key of Entity Set Set of attributes that uniquely identify each entity

Examples: “Car” VIN “Person” SSN “WPI Student” University ID “US Student” UniversityName + UnivesityID

A key has to be unique within the scope of your application Does not have to be globally unique

8

Customer

Car

Types of Keys

A super key of an entity set is a set of one or more attributes whose values uniquely determine each entity “Person” SSN, SSN + FirstName “Account” AccountNumber + AccountType

A candidate key of an entity set is a minimal super key “Person” SSN “Account” AccountNumber “US Student” SSN, UniversityName + UnivesityID

Each candidate key is a super key but not vice versa

A primary key is one from, possibly several, candidate keys Pick one and declare it as “primary key” “Student” SSN, StudentID, FirstName + MiddleName + LastName

9

Keys Summary

Key combination of one or more attributes that uniquely identify an entity

Types: Super key Candidate key Primary key

10

Only primary keys are modeled in ERDOnly primary keys are modeled in ERD

Primary Keys in ERD Select only one key to be the primary key

Primary key is modeled by “underline” under its set of attributes

Good Practice: Select singleton and number fields whenever possible

11

12

Multi-Attributes Primary Key

Key for Student is sNumber

Student

sNumber

sName

Key for Movie is <title, year>

Movie

title

year

We can represent key for entity set consisting of more than one attribute (e.g.: Movie)

Keys of Relationships

Relationship without attributes The combination of primary keys of the participating entity

sets forms a key of a relationship set

(customer_id, load_number) is the key of borrower

13

Keys of Relationships (Cont’d)

Relationship with attributes Attributes of the relationship may (not always) participate inside

the key + the external keys

(sNumber, cNumber) is the key of Taken

14

Student

sNumber

sName

Course

cNumber

title

HasTaken

DateDateprojectproject

GradeGrade

Keys of Relationships (Cont’d)

Relationship with attributes Attributes of the relationship may (not always) participate inside

the key + the external keys

(sNumber, cNumber, Date) is the key of Taken

15

Student

sNumber

sName

Course

cNumber

title

HasTaken

DateDateprojectproject

GradeGrade

In this ERD: student can take the same course on different dates

In this ERD: student can take the same course on different dates


Key Constraints


Weak Entities



16


Express the number of entities to which another entity can be associated via a relationship set

Most useful in describing binary relationship sets

For a binary relationship set the mapping cardinality must be one of the following types: One to one One to many Many to one Many to many

17

Mapping Cardinalities

18

Mapping Cardinalities (Cont’d)

19

Representing Cardinalities in ERD

In a relationship: “ ” : Represent “many” (including 0) “ ” : Represent “one” (including 0) “ ”: Represent “one” (must be one)

20

Student

sNumber

sName

Course

cNumber

title

HasTaken

A student is taking “many” courses.

A course can be taken by “many” students.

One-To-Many Relationship

21

One-To-Many Relationship

In the one-to-many relationship a loan is associated with at most one customer via borrower, a customer is associated with many (including 0) loans via borrower

22

A customer can take many loans

A loan can be taken by one (and at least one) customer

Many-To-One Relationship

23

Many-To-One Relationship

In a many-to-one relationship a loan is associated with many (including 0) customers via borrower, a customer is associated with at most one loan via borrower

24

A customer can take at most one loan

A loan can be taken by many customers

Many-To-Many Relationship

In a many-to-many relationship a loan is associated with many (including 0) customers via borrower, a customer is associated with many loan via borrower

25

26

Degree of Cardinalities

How : Expressed using (min, max)

Student

sNumber

sName

Course

cNumber

title

HasTaken

(2, 3) (0, *)

Student can take many courses, and a course can be taken by many students

Student can take 0 to 5 courses, and a course can be taken by 3 to 60 students

(3, 60)(3, 60) (0, 5)(0, 5)

27

Cardinality Constraints for Recursive Relationships

A Part may contain many subpartsA Part can be subpart in many superParts

Contains

Part

pName pNumber

subPartsuperPart

quantity

28

Cardinality Constraints for Recursive Relationships

A Part can have many subPartsA Part can be subpart for at most one superPart

Contains

Part

pName pNumber

Is-subpartsuperPart

quantity

(0, 1)(0, *)

Revisit this example…

29

Employees & Managers ….. Add cardinalities

Employee

ID

Name

Supervisesupervisor

supervised

Semantics:Manager can supervise many employeesEmployee is supervised by one manager

30

Cardinality Constraints for Multi-way Relationships

Every Supplier supplies some Product to some Consumer

Supplier

sName

sLoc

Consumer

cName

cLoc

Supply

price

Product

pName pNumber

qty

To add degree constraints, introduce a new entity set and create multiple binary relationships !!!

To add degree constraints, introduce a new entity set and create multiple binary relationships !!!

Adding Cardinality Constraints to Multi-way Relationships

31

Supplier

sName

sLoc

Consumer

cName

cLoc

price

Product

pName pNumber

qty

Supp_Cons_Prod

What is the key of this entity ??? (Weak Entity)

suppliesconsumes

in


Key Constraints


Weak Entities



32

Weak Entity Sets An entity set that does not have a primary key is referred to as a weak

entity set Its attributes are not enough to form a key

The existence of a weak entity set depends on the existence of an identifying entity set It must relate to the identifying entity set via a total, one-to-many relationship set from

the identifying to the weak entity set

33

Course number is unique only within the departmentWeak entity set

Identifying entity set

Dept Offers Course

dNamedNumber cNamecNumber

(1, 1)(0, *)

Weak Entity Sets Discriminator (or partial key) of a weak entity set

The set of attributes that uniquely identify a weak entity given its identifying entity

Primary key of a weak entity set The composition of the primary key of the identifying entity set + the weak entity set’s

discriminator

Identifying entity has to exist for each weak entity Cannot have a course without a corresponding department

(dNumber, cNumber) is the primary key for Course

34

discriminator

Dept Offers Course


(1, 1)(0, *)

Representing a Weak Entity Set Weak entity set is represented by double rectangles

Weak relationship (supporting relationship) is represented by double diamonds

Weak relationship is one-many from the weak entity to the identifying entity

35

Dept Offers Course


(1, 1)(0, *)

Again: It Depends on Your Application/Assumptions

If you assume the course number is unique within a department “Course” is a weak entity set

If you assume the course number is unique across all departments “Course” is a strong entity set

36

Dept Offers Course


(1, 1)(0, *)CourseCourseoffersoffers

Stating your assumptions in text is very important !!!Stating your assumptions in text is very important !!!

Revisit Previous Example …

37

Supplier

sName

sLoc

Consumer

cName

cLoc

price

Product

pName pNumber

qty

Supp_Cons_Prod

Weak Entity

suppliesconsumes

in

What about an Exercise !!!

Lets interactively design a database for a Hotel

38

Example: Hotel Database A Hotel has many branches

Hotel name, logo, address of HQ, Tel., manager, star rating Branch Id, address, Tel., Total capacity

Each branch has many rooms with different types and numbers. A room type defines Room size, Number of beds Has TV or not, Has Balcony or not

Guests can stay in a hotel for a period of time Guests have unique ID, name, address, Tel. We need to capture, the length of the stay, start date, end date, money paid

39

40

Hotel

NameHQ Add. Manager

RatingTel.

Branch

ID

Add.

Tel.

Capacity

Room

Num

Type

Num Beds

Capacity

Has TV

Has Balcony

Ver. 1

Observations:•Room type is modeled as attribute (causes redundancy) •Room number, is it numeric like 1001? If so, how come to be unique across branches?

41

Hotel

NameHQ Add. Manager

RatingTel.

Branch

ID

Add.

Tel.

Capacity

Type

Type

Num Beds

Capacity

Has TV

Has Balcony

Ver. 2

Observations:•Lets add relationships

RoomNum

42

Hotel

NameHQ Add. Manager

RatingTel.

Branch

ID

Add.

Tel.

Capacity

Type

Type

Num Beds

Capacity

Has TV

Has Balcony

Ver. 3

RoomNum

has

Of type

contains

Common mistake: Do not add “Branch ID” as an attribute to “Room” entity set. It is already captured by the weak relationship “contains”.

Back to the Requirements A Hotel has many branches

Hotel name, logo, address of HQ, Tel., manager, star rating Branch Id, address, Tel., Total capacity

Each branch has many rooms with different types and numbers. A room type defines Room size, Number of beds Has TV or not, Has Balcony or not

Guests can stay in a hotel for a period of time Guests have unique ID, name, address, Tel. We need to capture, the length of the stay, start date, end date, money paid

43

44

Hotel

NameHQ Add. Manager

RatingTel.

Branch

ID

Add.

Tel.

Capacity

Type

Type

Num Beds

Capacity

Has TV

Has Balcony

Ver. 4

RoomNum

has

Of type

contains

Guest

IDAdd.

Tel.

Name

Money Paid

Length of stayStart date

End date

Observations:•“Stay” attributes should not be part of “Guest”

45

Hotel

NameHQ Add. Manager

RatingTel.

Branch

ID

Add.

Tel.

Capacity

Type

Type

Num Beds

Capacity

Has TV

Has Balcony

Ver. 5

RoomNum

has

Of type

contains

Guest

IDAdd.

Tel.

Name

Money Paid


End dateStays inObservations:

•Still not quite right..•“Stays-in” 1-M or M-M??(Guest should be able to stay in diff. rooms)

46

Hotel

NameHQ Add. Manager

RatingTel.

Branch

ID

Add.

Tel.

Capacity

Type

Type

Num Beds

Capacity

Has TV

Has Balcony

Ver. 6

RoomNum

has

Of type

contains

Guest

IDAdd.

Tel.

Name

Money Paid



•Not done yet…•In this model, a guest cannot stay in the same room over diff visits!!!

47

Hotel

NameHQ Add. Manager

RatingTel.

Branch

ID

Add.

Tel.

Capacity

Type

Type

Num Beds

Capacity

Has TV

Has Balcony

Ver. 7

RoomNum

has

Of type

contains

Guest

IDAdd.

Tel.

Name

Money Paid



•Start_date part of key•Length of stay derived attribute


Key Constraints


Weak Entities



48

ISA Relationship Types Similar to “subclass” concept in Object-Oriented

languages

Entity sets share some common attributes but differ in others

Sometimes called “Specialization/Generalization”

Example Students can be UGStudents or GradStudents

UGStudents take undergrad Classes GradStudents can be TAs or RAs GradStudents are advised by Professors

49

ISA Example

50

All attributes of “student” are inherited in the other entity sets

Each entity set, e.g., “Freshman”, can have its own additional attributes

ISA Relationship Types (Cont’d) Top-down design process

Build entities with the common attributes, then build sub-entities with distinctive attributes from other entities in the set

These sub-entities become lower-level entity sets that have attributes or participate in relationships that do not apply to the general higher-level entity set

In ERD, represented by a triangle component labeled ISA (E.g. customer “is a” person)

Attribute inheritance Lower-level entity set inherits all the attributes and relationship participation of

the higher-level entity set to which it is linked

51

More Complete Example

52

More Complete Example

53

Attributes of Person:

Attributes of Student:

Attributes of Technician:

SSN, Name, DOB

SSN, Name, DOB, GPA, StartDate

SSN, Name, DOB, Salary, Department, Specialization

Multiple ISA Relationships Can have multiple specializations of an entity set

based on different features

54

Permanent Emp

Permanent Emp

Temporary Emp

Temporary Emp

ISA

ISA Relationship: Constraints

Three types of constraints Membership: To which entity set an entity belongs

Overlapping: can an entity belong to multiple subclasses or not

Completeness: Does each super entity have to belong to one (or

more) subclasses

55

ISA Relationship: Membership Constraint on which entities can be members of a given lower-level

entity set Denoted in ERD on the ISA edge

56

Year = 1

Year = 2 Year = 3

Year = 4

Year

ISA Relationship: Overlapping Constraint on whether or not entities may belong to more than one lower-level

entity set within a single generalization. Disjoint

An entity can belong to only one lower-level entity set Overlapping

An entity can belong to more than one lower-level entity set

Denoted in ERD by writing “disjoint” or “overlapping” next to ISA triangle, by default “disjoint”

57

disjoint

ISA Relationship: Completeness

Specifies whether or not an entity in the higher-level entity set must belong to at least one of the lower-level entity sets within a generalization

Total : An entity must belong to one of the lower-level entity sets

Partial: An entity need not belong to one of the lower-level entity sets

58

Total

Another Example

59

Partial, Overlapping

ISA Relationship: Multiplicity

ISA relationship is always 1-1 (even though its notation is arrows without heads)

60

ISA Relationship: Keys Key of sub-entities is inherited from the super entities

61

SSN is the primary key for Person, Student, Employee, Freshman, Technician, and all other sub-entities


Key Constraints


Weak Entities



62

Summary of Symbols used in ERD

63

64

Coming up with a good design for your application

No single right design, there can be many…

Put clear, reasonable assumptions and make a design that captures the assumptions Without stating the assumptions, others can claim your design is wrong !!!

It is like art, common sense and experience make a difference

The simplest design that captures the requirements is the best

65

Guidelines Toward a Good Design (I)

Convey “real” application requirements

Utilize meaningful names for Entity sets, attributes, relationships

Avoid redundancy, do not store the same data in multiple places

Be as precise as possible (E.g., cardinality constraints)

Don’t over specify (limits input)

Know when to add attributes to entity sets vs. relationships

Examples

66

Room

Num

Type

Num Beds

Capacity

Has TV

- The room “capacity, Num Beds, has TV” attributes they all depend on the type. So why repeat them with each room.

- The “type” should be a separate entity set (slide 42)

- The room “capacity, Num Beds, has TV” attributes they all depend on the type. So why repeat them with each room.

- The “type” should be a separate entity set (slide 42)

CustomerLoan

Bank

take

offer

Num SSN

ID

- The relationship “lend” is redundant and should not be there

- The relation between a customer and a bank is already captured by the two other relationships

- The relationship “lend” is redundant and should not be there

- The relation between a customer and a bank is already captured by the two other relationships

lendX

M-M Relationships vs. An Entity Set

67

StudentCourse

taking

Num

M-M Relationship between E1 and E2 can be always broken to: A new entity set E3 (usually weak entity set) 1-M relationship between E1 and E3 1-M relationship between E2 and E3

Both are correct use either one

ID

Date grade

StudentCourse

Num ID

Date grade

Registration

Involveinclude

Do not overuse ISA relationship

68

• There are always some commonalities between things this does not mean they should inherit from common ancestor

• Use it only if there is a substantial overlap in attributes (and possibly relationships)

StudentProf

- No need for an entity set “Person” from which both “Prof” and “Student” inherit- No need for an entity set “Person” from which both “Prof” and “Student” inherit

Strong vs. Weak Entity Sets Avoiding weak entities is better (If no semantics is lost) You may add unique keys

69

Hotel

Branch

has

ID

Name Hotel

Branch

has

ID

Name

- Should always favor the left design over the right one (unless explicitly stated otherwise)- Should always favor the left design over the right one (unless explicitly stated otherwise)

Do not overuse multi-way relationships

They are harder to understand and interpret Can be broken by introducing new entity set and several 1-

M relationships

Avoid multi-way relationship

Avoid weak entity set

ERD Cannot Capture Everything…

Some business constraints will not be captured in the design. For example: For a customer to get a load, the sum of the previous loans

to him/her must be < MaxLoan

A student cannot take the same course more than 2 times

A student cannot re-take a course that (s)he already passed

71

Find the wrong things ???

72

carcar

ColorNameColorName

colorIDcolorID

VINVINMakeMake ModelModel

CustomerCustomer

IDIDDoBDoB NameName

Car-featureCar-feature

FeatureNameFeatureName

containscontains

buysbuys

DateDate

CarMilesCarMiles

AgeAge

PricePrice

LoanLoan

amountamount

numbernumber

BankBank

takestakes

DateDate

= A customer can buy many cars= A customer may take a loan to buy a specific car

From the Previous Example ColorId & ColorName (cause redundancy & inconsistency)

Car can have one feature (wrong cardinality)---should be many

Car-feature has one attribute (should not be an entity)---make it attr.

CarMiles should be attached to the car (not to the relationship)

Age should be a derived attribute

A car should be bought by one (or zero) customers (the arrow head should be closed)

Loan and Car are not linked together (buys should be 3-way) Or create a new entity set “Contract” and link it to the three entity sets

73

74

Summary of ER Model

Concepts Entity, Entity Sets, Weak Entity Sets Relationships Types

binary, ternary, multi-way, recursive, weak, ISA Attributes

For entity sets or relationship types Simple, composite, derived, multi-valued

Constraints – key, cardinality

Guidelines for Good Design

Documents

The Entity-Relationship Model