Chapter 2

Chapter 2

Entity-Relationship Entity-Relationship ModelModel

Chapter 11 & 12 in Textbook

Lilac Safadi E/R Model

2

Database DesignDatabase DesignSteps 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)


3

Entity-Relationship Model (E/R)Entity-Relationship Model (E/R)A picture is worth a thousand wordsA 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


4

ERD ExampleERD Example

enroll

SCHOOL

DEPARTMENT

COURSECLASSSTUDENT

PROFESSOR

advise

offer

operate

chairsteach

generate

has

dean of

assigned

11

1

1

M

1

1

M

1

M

M

1

1

M

1MMN

1

M(0,*)

(0,*)

(1,1)

(1,*)

(1,1)(0,1)

(0,4)

(0,1)

(0,1)

(1,1)

(0,*)

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

(1,1)

name

number

DOB

hrscode


5

Entities & Entity TypeEntities & 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


6

Relationships & RelationshipRelationships & RelationshipTypesTypes

• A relationship associates 2 or more entities

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

COURSEstudySTUDENT


7

Degree of Relationship TypeDegree 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.


8


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

COURSEstudySTUDENT


9


A relationship of degree three (3 entity types) are ternary. (e.g.registration of a student in a course by a staff)

COURSEregisterSTUDENT

STAFF


10

Recursive RelationshipRecursive 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


11

RolesRoles

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

COURSE

require

requester prerequisite


12

RolesRolesRole 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


13

AttributesAttributes 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


14

Attributes of EntitiesAttributes of Entities

COURSEstudySTUDENT

St_no

name DOB

Tel_no number

namehours


15

Attributes of RelationshipsAttributes 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


16

Simple & Composite AttributesSimple & Composite Attributes

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

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


17

Simple & Composite AttributesSimple & Composite Attributes

Composite 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


18

Single-valued & Multi-valued Single-valued & Multi-valued AttributesAttributes

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


19

Single-valued & Multi-valued Single-valued & Multi-valued AttributesAttributes

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


20

Derived AttributesDerived 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


21

KeysKeys

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.


22

Keys ExampleKeys Example

ELEMENT(symbol, name, atomic_no)


23

Keys ExampleKeys Example

ELEMENT(symbol, name, atomic_no)

Primary Key Alternate Keys

Candidate Key


24

Choice of PKChoice of PK

Choice of Primary Key (PK) is based on:

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


25

Primary Key in ERDPrimary Key in ERD

ageSTUDENT

St_no

name DOB

Tel_no

LNameinitial FName

Area_cdno

EX


26

KeysKeysA 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)


27

Composite Key in ERDComposite Key in ERD

CLASS

crs_code

Section_no name

hours


28

Strong & Weak Entity TypesStrong & 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.


29

Weak Entity TypeWeak 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


30

CardinalitiesCardinalities

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)


31

One-To-One RelationshipOne-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


32

One-To-Many RelationshipOne-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


33

One-To-Many RelationshipOne-To-Many 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


34

Many-To-Many RelationshipMany-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 C4 r4 S5

S2


35

MultiplicityMultiplicity

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#)


36


BRANCHmanageSTAFF1 1

(0,1) (1,1)

STAFF manage BRANCH

SG1 r1 B002

SG2

SG3 r2 B001


37


PROPERTYoverseeSTAFF1 M

(0,10) (0,*)

(0,1)

STAFF oversee PROPERTY

SG1 r1 P1

r2 P2

SG2 r3 P14

SG3 P6


38


PROPERTYadvertiseNEWSPAPERM N

(0,*) (0,*)

Newspaper advertise PROPERTY

Al-Riyadh r1 P1

r2 P13

Al-Bilad r3

Al-Madinah r4 P6

Al-Sharq P4


39

Participation ConstraintsParticipation Constraints

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

Two types of participation:

- Mandatory (total)

- Optional (partial)


40


• 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)

CLASS is a total participator in the relation

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


41


• 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)PROFESSOR is a partial participator in the relation


42

E/R Case StudyE/R Case StudyDesign a database for a bank with the following description: 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.An account must have only one customer.A customer may have many accounts and in different branches.A customer may have at most 5 accounts in the bank.


43

Problems with ER ModelProblems with ER ModelConnection TrapsConnection Traps

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

Types of connection traps:– Fan Trap– Chasm Trap


44

Fan TrapFan 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


45

Fan TrapFan 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


46

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


47

Chasm TrapChasm 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)


48


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 r5 P5

offer r6 r7 r8

offer1 M

(0:*)

(0:1)

(1:1)

(1:*)


49


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.


50

What makes a good DB design?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)


51


• Avoid Redundancy. Say everything only once

Biz-name

PERSON own BUSINESSM N

name


52

What makes a good DB design?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


53


PERSON

own

run

BUSINESS

Example 2


54


EMPLOYEE work COMPANYM 1

own

PERSON

M

1

Example 3

contract

1

1


55

What makes a good DB design?What makes a good DB design?• Pick the right kind of element.

STUDENT allocate DEPARTMENTM 1

STUDENTdegrees

dpt_name

degreesdpt_nameExample 1


56


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)


57

Enhanced Entity-Relationship Enhanced Entity-Relationship Model (EER)Model (EER)

EER is an ER model supported with additional semantic concepts.

Semantic concepts supported:

- Specialization

- Generalization

- Aggregation


58

SpecializationSpecialization

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


59

Specialization/GeneralizationSpecialization/Generalization

STAFF

MANAGER SECRETARYSALES

PERSONNELSubclass

Superclass

IS_A relationship 1:1


60

GeneralizationGeneralization

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


61

InheritanceInheritance

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


62

InheritanceInheritance

STAFF

SALESPERSONNEL

Unsharedattributes

Superclass

addressDOBname

SalesareaCar

allowance

sharedattributes

Subclass require CAR

Unsharedrelationship

contract COMPANY

Sharedrelationship


63

Constraints on Constraints on Specialization/GeneralizationSpecialization/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)


64


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


65


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

STAFF


PERSONNEL


66

Constraints on Constraints on Specialization/GeneralizationSpecialization/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


67

Disjoint ConstraintsDisjoint 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


68

Disjoint ConstraintsDisjoint Constraints

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

STAFF


PERSONNEL

o


69

AggregationAggregation

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


70

AggregationAggregation

TEAM

MEMBER


71

Summary of ERD notations (1)Summary of ERD notations (1)

ENTITY

WEAK ENTITY

RELATIONSHIP

IDENTIFYING RELATIONSHIP

ATTRIBUTE

KEY ATTRIBUTE

MULTI-VALUED

COMPOSITE

DERIVED


72

Summary of ERD notations (2)Summary of ERD notations (2)

CARDINALITYRATION

PARTICIPATIONCONSTRAINTS

1 M

(min,max)


73

Summary of EERD notations (3)Summary of EERD notations (3)

Disjoint constraintd

o Non-Disjoint constraint

Total Participation

Optional Participation

Documents

Chapter 2