Chapter 2 Entity-Relationship Model Chapter 11 & 12 in Textbook.

Chapter 2

Entity-Relationship Model

Chapter 11 & 12 in Textbook

2

Database Design

Steps in building a database for an application:

1. Understand real-world domain being captured.

2. Specify it using a database conceptual model (E/R,OO).

3. Translate specification to model of DBMS (relational).

4. Create schema using DBMS commands (DDL).

5. Load data (DML).

Real-world domain

Conceptualmodel

DBMS data model

Create Schema

(DDL)

Load data(DML)

ER Model

3

Entity-Relationship Model (E/R)A picture is worth a thousand words

The Entity-Relationship model (ER) is a high-level description of the structure of the DB.

The Entity-Relationship Diagram (ERD) is a graphical model for representing the conceptual model for the data.

A E/R models the DB using three element types:- Entities- Attributes- Relationships

ER Model

ERD Example

enroll-in

SCHOOL

DEPARTMENT

COURSECLASSSTUDENT

PROFESSOR

advise

offer

operate

chairs

teach

belong-to

has

dean of

1 1

1

1

M

1

M

M

1

1

M1MMN

1

M

(0,*)

(0,*)

(1,1)

(1,*)

(1,1)(0,1)(0,4)

(1,1)

(0,1)

(1,1)

(0,*)

(1,1) (0,*)(0,*)

(1,1)

name

number

DOB

hrscode

(1,*)

(1,1)

1

(1,*)

(1,1)

5

Entities & Entity Type

Entity is an object that exists and is distinguishable from other objects.

e.g. person, company, course, university

Entity Type is a set of entities of the same type that share the same properties.

e.g. set of all persons, companies, trees, courses

COURSESTUDENT

ER Model

Relationships & RelationshipTypes

• A relationship associates 2 or more entities.

• A relationship type is a set of associations between entity types.

COURSEstudySTUDENT

ER Model

STUDENT study COURSE

S001 r1 CO1

S002 r2 CO2

S003 r3

7

Degree of Relationship Type

Degree of relationship refers to number of participating entity types in a relationship.

• A relationship of degree two (2 entity types) are binary.

• A relationship of degree three (3 entity types) are ternary.

ER Model

8

Degree of Relationship Type

A relationship of degree two (2 entity types) are binary.

COURSEstudySTUDENT

ER Model

9

Degree of Relationship Type

A relationship of degree three (3 entity types) are ternary.

e.g. registration of a student in a course by a staff.

COURSEregisterSTUDENT

STAFF

ER Model

10

Recursive Relationship

Recursive relationship is a relationship type where the same entity type participates more than once in a different role. It is a unary relationship.

COURSE

require

ER Model

STUDENT

lead

11

Roles

Role indicates the purpose that each participating entity type plays in a relationship. (e.g. prerequisite, requester)

COURSE

require

requester prerequisite

ER Model

STUDENT

lead

leader member

12

Roles

Role can be used when two entities are associated through more than one relationship to classify the purpose of each relationship.

STAFF

allocated

Manager

Staff member

BRANCH

Branch office

Branch office

manages

ER Model

13

Attributes

Attributes are descriptive properties for an entity type or a relationship type.

All entities in one entity type have the same attributes.

STUDENT

St_no

name DOB

Tel_no

ER Model

14

Attributes of Entities

COURSEstudySTUDENT

St_no

name DOB

Tel_no number

namehours

ER Model

15

Attributes of Relationships

All relationships in one relationship type have the same attributes.

Relationships can be distinguished not only by their attributes but also by their participating entities.

contract

Start EndObject

ER Model

CompanyEmployee

16

Simple & Composite Attributes

Simple attribute is an attribute that have a single value with an independent existence.

e.g. salary, age, gender,...

ER Model

17

Simple & Composite AttributesComposite attribute is an attribute composed of multiple distinct components, each with an independent existence.

e.g. address (street, area, city, post code)

name (First name, initial, Last name)

phone no. (area code, number, exchange no)

STUDENT

St_no

name DOB

Tel_no

LNameinitial FName

Area_cdno

EX

ER Model

18

Single-valued & Multi-valued Attributes

Single-valued attribute is an attribute that holds a single value for a single entity. It is not necessarily a simple attribute.

e.g. student_no, age, gender,...

ER Model

19

Single-valued & Multi-valued Attributes

Multi-valued attribute is an attribute that may hold multiple values, of the same type, for a single entity.

e.g. tel_no, degrees,…

STUDENT

St_no

name DOB

Tel_no

LNameinitial FName

Area_cdno

EX

ER Model

20

Derived Attributes

Derived attribute is an attribute that represents a value that is derived from the value of a related attribute,not necessarily in the same entity type.

e.g. age is derived from date_of_birth

total_cost is derived from quantity*unit_price

STUDENT

St_no

name DOB

Tel_no

age

ER Model

21

Keys

Candidate key (CK) is the minimal set of attributes that uniquely identifies an entity. It cannot contain null.

e.g. student_no, social_security_no, branch_no…

Primary Key (PK) is a candidate key that is selected to uniquely identify each entity.

Alternate Key (AK) is a candidate key that is NOT selected to be the primary key.

ER Model

22

Keys Example

ELEMENT(symbol, name, atomic_no)

ER Model

23

Keys Example

ELEMENT(symbol, name, atomic_no)

Primary Key Alternate Keys

Candidate Key

ER Model

24

Choice of PK

Choice of Primary Key (PK) is based on:

• Attribute length• Number of attributes required• Certainty of uniqueness

ER Model

25

Primary Key in ERD

ageSTUDENT

St_no

name DOB

Tel_no

LNameinitial

FNameArea_cd

no

EX

ER Model

26

Keys

A key can be:

- simple key is a candidate key of one attribute.

e.g. student_no, branch_no…

- composite key is a candidate key that consists of two or more attributes.

e.g. STUDENT (Lname, Fname, Init)

CLASS (crs_code, section_no)

ADVERT (property_no, newspaperName, dateAdvert)

ER Model

27

Composite Key in ERD

CLASS

crs_code

Section_no name

hours

ER Model

28

Strong & Weak Entity Types

A strong entity type is NOT existence-dependent on some other entity type. It has a PK.

A weak entity type is an entity type that is existence-dependent on some other entity type. It does not have a PK.

ER Model

29

Weak Entity Type

• The existence of a weak entity type depends on the existence of a strong entity set; it must relate to the strong entity type via a relationship type called identifying relationship.

• The PK of a weak entity set is formed by the PK of its strong entity type, plus a weak entity type discriminator attribute.

EMPLOYEE

emp_no

LName FName

DOBdep_no FName

DEPENDENThas

ER Model

30

Cardinalities

Cardinality ratio expresses the number of relationships an entity can participate in.

Most useful in describing binary relationship types.

For a binary relationship type the mapping cardinality must be one of the following types:

– One to one (1:1) – One to many(1:M)

– Many to one (M:1) – Many to many (M:N)

ER Model

31

One-To-One Relationship

A professor chairs at most one department; and a department is chaired by only one professor.

DEPARTMENTchairsPROFESSOR1 1

PROFESSOR chair DEPARTMENT

P1 r1 D002 P2 P3 r2 D001

ER Model

32

One-To-Many Relationship

A course is taught by at most one professor; a professor teaches many courses.

COURSEteachPROFESSOR1 M

PROFESSOR teach COURSE P1 r1 C01

r2 C02 P2 r3 C03 P3 C04

ER Model

33

Many-To-One Relationship

A class requires one room; while a room can be scheduled for many classes.

ROOMrequireCLASSM 1

CLASS require ROOM C1 r1 R001

C2 r2 R002 C3 r3 R003 R004

ER Model

34

Many-To-Many Relationship

A class enrolls many students; and each student is enrolled in many classes.

STUDENTenrollCLASSM N

CLASS enroll STUDENT C1 r1 S1

C2 r2 S3 C3 r3 S4 r5 S5

ER Model

35

Multiplicity

Multiplicity is the number (range) of possible entities that may relate to a single association through a particular relationship.

It is best determined using sample data.

Takes the form (min#, max#)

ER Model

36

Multiplicity

BRANCHmanageSTAFF1 1

(0,1) (1,1)

STAFF manage BRANCH

SG1 r1 B002

SG2

SG3 r2 B001

ER Model

37

Multiplicity

PROPERTYoverseeSTAFF1 M

(0,10) (0,*)

(0,1)

STAFF oversee PROPERTY

SG1 r1 P1

r2 P2

SG2 r3 P14

SG3 P6

ER Model

38

Multiplicity

PROPERTYadvertiseNEWSPAPERM N

(0,*) (0,*)

Newspaper advertise PROPERTY

Al-Riyadh r1 P1

r2 P13

Al-Bilad r3

Al-Madinah r4 P6

Al-Sharq P4

ER Model

39

Participation Constraints

Participation constraints determine whether all or only some entities participate in a relationship.

Two types of participation:

- Mandatory (total)

- Optional (partial)

ER Model

40

Participation Constraints

• Mandatory (total) (1:*): if an entity’s existence requires the existence of an associated entity in a particular relationship (existence-dependent).

e.g. CLASS taught-by PROFESSOR

i.e. CLASS is a total participator in the relation.

A weak entity always has a mandatory participation constraints but the opposite not always true.

ER Model

41

Participation Constraints

• Optional (partial) (0:*): if an entity’s existence does not require a corresponding entity in a particular relationship. (Not existence-dependent).

e.g. PROFESSOR teach CLASS i.e. PROFESSOR is a partial participator in the relation.

ER Model

ER Case Study

Each bank has a unique name.

Each branch has a number, name, address (number, street, city), and set of phones.

Customer includes their name, set of address (P.O. Box, city, zip code, country), set of phones, and social security number.

Accounts have numbers, types (e.g. saving, checking) and balance. Other branches might use the same designation for accounts. So to name an account uniquely, we need to give both the branch number to which this account belongs to and the account number.

Not all bank customers must own accounts and a customer may have at most 5 accounts in the bank.

An account must have only one customer.

A customer may have many accounts in different branches. 

Class exercise: Banks Database

Customer

Account

Branch

Bank has

allocate

has

own

name

name

Bno

address

phone

street

city

num

Acct_no type balance

name

SSN

address

phone

P.O.box

city

zipcountry

1

M

M

1

1

N

M M

(1,1)

(1,1)(1,1)

(1,*)

(1,*)

(0,*) (0,*)

(0,5)

ER Case Study

Homework: Television Series Database

A Television network wishes to create a database to keep track of its TV series. A television series has one or more episode. Television series identified by name and season number, and includes their production company name and Num_of_Episodes ( i.e. total number of episodes in a specific season of a series ).

Episode of a specific season of a series is identified by episode number and has a title and a length. No episode can exist without a corresponding television series. Also each episode has only one writer. A writer is identified by name, and also has birth date and a literary agency that represents him or her.

An actor appears as a performer in a television series or a guest star on an episode. An actor is identified by name and also has a nationality and birth date. An actor plays a particular character in a television series or episode.

45

Problems with ER ModelConnection Traps

Connection traps are problems that occur due to misinterpretation of the meaning of certain relationships.

Types of connection traps:– Fan Trap– Chasm Trap

ER Model

46

Fan Trap

has operateDIVISION

STAFF BRANCH

1

M

1

M

STAFF has DIVISION operate BRANCH

SG1 r1 D1 r4 B002

SG3 r2 r5 B003

SG2 r3 D2 r6 B004

ER Model

47

Fan Trap

operate hasBRANCH

DIVISION STAFF

M

M

1

1

DIVISION operate BRANCH has STAFF

D1 r1 B002 r4 SG1

r2 B003 r5 SG3

D2 r3 B004 r6 SG2

ER Model

48

Fan Trap

Fan trap where a model represents a relationship between entity types, but the pathway between certain entity occurrence is ambiguous.

Exists where 2 or more 1:M relationships fan out from the same entity.

ER Model

49

Chasm Trap

has overseeSTAFF

BRANCH PROPERTY

M

M

1

1

BRANCH has STAFF oversee PROPERTY

B001 r1 SG1 r4 P1

B003 r2 SG2 P14

B002 r3 SG3 r6 P5

(1:*)

(1:1) (0:*)

(0:1)

ER Model

50

Chasm Trap

has overseeSTAFF

BRANCH PROPERTY

M

M

1

1

BRANCH has STAFF oversee PROPERTY

B001 r1 SG1 r4 P1B003 r2 SG2 P14

B002 r3 SG3 r5 P5

offer r6 r7 r8

offer1 M

(0:*)

(0:1)

(1:1)

(1:*)

ER Model

51

Chasm Trap

Chasm trap where a model suggests the existence of a relationship between entity types, but the pathway does not exist between certain entities.

Exists when partial participating entity is part of the pathway between related entities.

ER Model

52

What makes a good DB design?

• Faithfulness. Entity types, attributes & relationship types should reflect reality.

BRANCH

Hourly-rate

EMPLOYEE managers-in BRANCH1 1

(a)

(b)

ER Model

53

What makes a good DB design?

• Avoid Redundancy. Say everything only once.

Biz-name

PERSON own BUSINESSM N

name

ER Model

54

What makes a good DB design?

• Simplicity. Avoid introducing more elements into your design than is absolutely necessary.

PERSON represent OWNER1 1

own

BUSINESS

1

M

Example 1

ER Model

55

What makes a good DB design?

PERSON

own

run

BUSINESS

Example 2

ER Model

56

What makes a good DB design?

EMPLOYEE work COMPANYM 1

own

PERSON

M

1

Example 3

contract

1

1

ER Model

57

What makes a good DB design?

• Pick the right kind of element.

STUDENT allocate DEPARTMENTM 1

STUDENTdegrees

dpt_name

degreesdpt_name

Example 1

ER Model

58

What makes a good DB design?

BUSINESS contract SUPPLIER1 M

LAWYER

1

Example 2

CONTRACT Sup-makeBiz-make

Law-make

BUSINESS

LAWYER

SUPPLIER1 M M 1

M

1

(business, lawyer, supplier)

Biz-make (business, contract)

Sup-make (supplier, contract)

Law-make (lawyer, contract)

(a)

(b)

59

Enhanced Entity-Relationship Model (EER)

EER is an ER model supported with additional semantic concepts.

Semantic concepts supported:

- Specialization

- Generalization

- Aggregation

ER Model

60

Specialization

• Top-down design process; we designate sub-groupings within an entity type that are distinctive from other entities in the set.

• These sub-groupings (subclasses) become lower-level entity types that have attributes or participate in relationships that do not apply to the higher-level entity set (superclass).

ER Model

61

Specialization/Generalization

STAFF

MANAGER SECRETARYSALES

PERSONNELSubclass

Superclass

IS_A relationship 1:1

ER Model

62

Generalization

• A bottom-up design process – combine a number of entity types that share the same features into a higher-level (superclass) entity type.

• Specialization and generalization are simple inversions of each other; they are represented in an EER diagram in the same way.

ER Model

63

Inheritance

A subclass entity type inherits all the attributes and relationship participation of the superclass entity type to which it is linked.

ER Model

64

Inheritance

STAFF

SALESPERSONNEL

Unsharedattributes

Superclass

addressDOBname

SalesareaCar

allowance

sharedattributes

Subclass require CAR

Unsharedrelationship

contract COMPANY

Sharedrelationship

ER Model

65

Constraints on Specialization/Generalization

Participation constraint determines whether every member in the superclass must participate as a member of a subclass.

Two types of participation constraints:

- Mandatory (total)

- Optional (partial)

ER Model

66

Participation Constraints

Mandatory (total) participation where every member in the superclass must also be a member of a subclass.

STAFF

FULL-TIMESTAFF

PART-TIMESTAFF

salary Hourly-rate

ER Model

67

Participation Constraints

Optional (partial) participation where a member in the superclass need not belong to any of its subclasses.

STAFF

MANAGER SECRETARYSALES

PERSONNEL

ER Model

68

Constraints on Specialization/Generalization

Disjoint constraint describes the relationship between members of the subclasses & indicates whether it is possible for a member of a subclass to be a member of one or more subclasses.

Two types of disjoint constraints:

- Disjoint

- Non-Disjoint

ER Model

69

Disjoint Constraints

Disjoint constraint when an entity can be a member of only one of the subclasses of the specialization.

STAFF

FULL-TIMESTAFF

PART-TIMESTAFF

salary Hourly-rate

d

ER Model

70

Disjoint Constraints

Non-disjoint constraints: a subclass is a member of more than one subclass of specialization. Entity types may overlap.

STAFF

MANAGER SECRETARYSALES

PERSONNEL

o

ER Model

71

Aggregation

• Represents a “part-of” relationship between entity types, where one represents the ‘whole’ and the other the ‘part’.

• No inherited attributes; each entity has its own unique set of attributes.

ER Model

72

Aggregation

TEAM

MEMBER

ER Model

73

Summary of ERD notations (1)

ENTITY

WEAK ENTITY

RELATIONSHIP

IDENTIFYING RELATIONSHIP

ATTRIBUTE

KEY ATTRIBUTE

MULTI-VALUED

COMPOSITE

DERIVED

ER Model

74

Summary of ERD notations (2)

CARDINALITYRATION

PARTICIPATIONCONSTRAINTS

1 M

(min,max)

ER Model

75

Summary of EERD notations (3)

Disjoint constraintd

o Non-Disjoint constraint

Total Participation

Optional Participation

ER Model