Entity-Relationship Modeland

Enhanced Entity-Relation Model

Outline

• Data Models• Notation basics• Understanding types of relationship• Generalization/Specialization hierarchies

Data Models

Data Models : a collection of conceptual tools for describing data, data relationships, data semantics, and consistency constraints.

The Entity-Relationship ModelThe Relational Model

Entity-Relationship Model (ER Model)

เป็�นโมเดลที่�ช่ วยในการออกแบบระบบฐานข้�อม�ลโดยรวม (Overall Logical Structure) ให้�ก�บองค์!กร

E-R Model เป็�นโมเดลที่�มป็ระโยช่น! และมค์วามสำ#าค์�ญมาก เพราะสำามารถแสำดงค์วามห้มาย และค์วามสำ�มพ�นธ์!ข้องข้�อม�ลตามสำภาพที่�เป็�นจร+ง (real world) ข้ององค์!กรห้น,�งได�อย างช่�ดเจน สำ#าห้ร�บการออกแบบในระด�บห้ล�กการ (Conceptual Level)

Entity-Relationship Model (ER Model)

Entity-Relationship Model (ER Model): perceives the real world as consisting of basic objects, called entities, and relationships among these objects.

E-R Model was developed to facilitate database design by allowing specification of an enterprise schema, which represents the overall logical structure of a database.

E-R Model is very useful because it can represent the meaning and relationship between objects of real world enterprise onto conceptual schema.

Components of ER Model

1. Entity set is a set of entities of the same type that share the same properties, or attributes. An entity is a thing or object in the real world that is distinguishable from all other objects.

2. Relationship set is a set of relationships of the same type. Each relation is a row which represents the relations among several entities from n entity sets (n >= 2).

1. Entity set : เป็�นเซ็/ตข้อง entities ที่�มโค์รงสำร�างข้�อม�ลแบบเดยวก�น (บางค์ร�0งเราเรยกแต ละ entity ว า object ห้ร1อ thing)

2. Relationship set : เป็�นเซ็/ตข้องค์วามสำ�มพ�นธ์! (relationships) ระห้ว าง Entity sets ที่�มโค์รงสำร�างข้�อม�ลแบบเดยวก�น โดยที่�แต ละrelationship ค์1อแต ละแถวที่�แสำดงค์วามสำ�มพ�นธ์!ระห้ว าง entities ที่�มาจาก n entity sets (n >= 2).

องค์�ประกอบของ ER Model

An entity is represented by a set of Attributes

Attributes are descriptive properties possessed by each member of an entity set. Attribute ค์1อข้�อม�ลที่�แสำดงล�กษณะ และค์4ณสำมบ�ต+ข้อง entity เช่ น เลข้ป็ระจ#าต�ว ช่1�อ-นามสำก4ล สำ วนสำ�ง ห้ม� เล1อด ว�นเด1อนป็6เก+ด …. เป็�นต�น

Student

Std_ID Name

Height

BloodDoB

Std_ID Name Height

Blood DoB

50100200

xxxxxx 175 A 12/2/33

50100422

yyyyy 165 AB 25/10/33

ER Model Relational Model

Attribute value : ค์�าของ attribute

Each entity has a value for each of its attributes. For instance, a particular student entity may have the value 50051044 for Std_ID, the value Kanchana Boonmak for Std_Name, and the value 3.12 for GPA.

For each attribute, there is a set of permitted values, called the domain, or value set of that attribute. For instance, the domain of attribute GPA might be the set of real number whose value is not greater than 4.0

Attribute Type

An attribute, as used in the E-R model, can be characterized by the following attribute types :

Simple and composite :

Simple : The attribute is a simple attribute if its value can not be divided into subparts. For example Std_ID, Std_Name, GPA.

Composite : The attribute is a composite attribute if its value can be divided into subparts. For example Name, Address.

Attribute Type (cont..)

Single-valued and Multivalued :

Single-valued : The attribute is a single-valued attribute if it has only one value for a particular entity.

Multivalued : The attribute is multivalued attribute if it has a set of values for a particular entity.

Derived:

The attribute is a derived attribute if its value can be derived from the values of other related attributes or entities.

Entity-Relationship Diagrams

Lecturer

Lec_ID

FirstName

LastName

Dept

Add_No Stree

CityZipcod

e

Sec

Age

Sub_name

Sub_type

Sub_code

Specialization

Address

TTeach Subject

Relationship type

M M

Relationship type

Credit

Compositeattribute

Multivaluedattribute

Derivedattribute

Key attribute

Descriptive

attribute

Constraints

An E-R schema may define certain constraints to which the contents of a database must conform. Such constraints are as following :

Mapping cardinalities constraintsKey constraints

Mapping Cardinalities

Mapping cardinalities or cardinality ratios, express the number of entities to which another entity can be associated via a relationship set.

Degree of relationship : The number of participating in a relationship.

• A relationship of degree two is called binary relationship.• A relationship of degree three is called ternary relationship.• A relationship of degree four is called Quarternary relationship

Degree of relationship : The number of participating in a relationship.

A relationship of degree two is called binary relationship.

person carowns

A relationship of degree three is called ternary relationship.

P-ID

FirstName

LastName

Addr

Person

License

Car

Year

Model

participated

Accident

Rept_no

Location

Date

Damage_cost

A relationship of degree four is called Quarternary relationship.

P-ID

FirstName

LastName

Addr

License

Car

Person

Model

Tparticipated

Accident

Rept-NoLocation

Date

Policy-NoAmount

Start_Date

Year

Insurance

Mapping cardinalities are most useful in describing binary relationship sets, (although they can contribute to the description of relationship sets that involve more than two entity sets as mentioned above 2 slides.)

Now, only binary relationship sets must be concentrated. For a binary relationship set R between entity sets A and B, the mapping cardinality must be one of the following:

One-to-oneOne-to-many (or many-to-one)Many-to-many

Binary Relationship

One-to-one mapping

An entity in A is associated with at most one entity in B, and an entity in B is associated with at most one entity in A.

Std_ID

FirstName

LastName

GPA

Proj_name

Proj_No

Twork Project1 1

Budget

Student

One-to-many mapping

An entity in A is associated with any number (zero or more) of entities in B. However, An entity in B can be associated with at most one entity in A.

L_ID

FirstName

LastName

Dept

Firstname

Std_ID

Tadvise Student1 M

GPA

Lecturer

Lastname

Many-to-many mapping

An entity in A is associated with any number (zero or more) of entities in B and an entity in B is associated with any number (zero or more) of entities in A.

L_ID

FirstName

LastName

Dept

Sub_name

Sub_code

TTeach SubjectM M

Lecturer

Credit

sec

Crow’s Foot notation for ERD

Crow’s Foot is a useful notation to become familiar with, as it is easy to understand and is supported by many of the CASE tools students may encounter in their database career

Basic Symbols

Entity Typesymbol Relationship

symbol

Primary Key

AttributesRelationship

name

Entity Typename

CourseNoCrsDescCrsUnits

Course

OfferNoOffLocationOffTime

Offering

Has

CardinalitiesCardinalities

Course Offering

Course1 Offering1

Course2

Course3

Offering2

Offering3

Offering4

Cardinality NotationCardinality Notation

Inside symbol:minimum cardinality

CourseNoCrsDescCrsUnits

Course

OfferNoOffLocationOffTime

Offering

Has

Perpendicular line:one cardinality

Outside symbol:maximum cardinality

Circle: zerocardinality

Crow's foot: manycardinality

Comparison to Access NotationComparison to Access Notation

CourseNoCrsDescCrsUnits

Course

OfferNoOffLocationOffTime

Offering

Has

ERD (Crow's Foot)

CourseCoursenoCrsDescCrsUnits

1 8OfferingOfferNoCourseNoOffLocationOffTime...

Access Relationship Diagram

Key in Database System

We must have a way to specify how entities within a given entity set are distinguished. Conceptually, individual entities are distinct, however, the difference among them must be expressed in terms of their attributes.

Therefore, the value of the attribute must be such that it can uniquely identify the entity. In other words, no two entities in an entity set are allowed to have exactly the same value for all attributes.

A key allows us to identify a set of attributes that enough to distinguish entities from each other. Keys also help uniquely identify relationships, and thus distinguish relationships from each other.

Key type in Database System

Candidate Key : In each entity set, there can be more than one attribute whose value can distinguish one entity from all other entities in the same entity sets. These attributes are known as candidate key.

Primary Key : PK denotes a candidate key that is chosen.

Foreign Key : FK is an attribute which is used to reference from one relation to another relation.

Candidate key

Prov_ID and ProvName are candidate keys because they can uniquely identify a specific entity.

A candidate key, which is chosen, is primary key. Therefore, Prov_ID is primary key.

Primary key

Province

Prov_ID

ProvName Region

Area

Conversion of ER Diagram to Relational Model

One-to-one mapping

Std_ID

FirstName

LastName

GPA

Proj_name

Proj_No

Twork Project1 1

Budget

Student

Year

Std_ID FirstName

LastName

GPA Proj_No Proj_Name Budget Year

Std_ID FirstName

LastName

GPA Proj_No Proj_No Proj_Name Budget Year

Std_ID FirstName

LastName

GPA Proj_No Proj_Name

Budget

Year Std_ID

Conversion of ER Diagram to Relational Model

One-to-many mapping

L_ID

FirstName

LastName

Dept

Firstname

Std_ID

Tadvise Student1 M

GPA

Lecturer

Lastname

Case 1: No descriptive attributes associated with relationship.

L_ID FirstName LastName Dept

L1 Yuen Poovaravan

CPE

L2 Kietiyuth Kaveeyan EE

Primary key

Std_ID FirstName LastName GPA L_ID

S1 Panita Komolpat 5.4 L2

S2 Pranom Sangswang

2.2 L2

S3 Kasom Chaleerat 1.8 L1

….. ….. ….. …..

Primary key

Foreign key

Conversion of ER Diagram to Relational Model

One-to-many mapping

Case 2: Descriptive attributes associated with relationship.

accountID

firstName lastName

addr

title

videotapeID

Trents Videotape1 M

rating

Customer

genre

costdateRented

dateDue

length

accountID

firstName

LastName

addr

acct1 Napat Chusang xxxxx

acct2 Ittikorn Meemak yyyy

acct3 Varaporn Mektavorn

zzzz

accountID

videotapeID

Title genre rating length dateRented

dateDue

Cost

acct1 V01 Xmen Part I

action R 2 12 Jan 2010

20 Jan 2010

70

V02 Star War I

Sci Fi PG 13 2.5

V05 Harry Potter I

fantasi PG 13 3

acct2 V04 Ghost Ryder

action R 2 7 Mar 2010

27 Mar 2010

70

Schema I

Case 2: Descriptive attributes associated with relationship.

accountID

firstName

addr

title

videotapeID

Videotape1 M

rating

Customer

genre

costdateRented

dateDue

length

LastName

Change relationship to Weak Entity Set

Rentalhas

has

1 1

Participation contraint

Weak entity class

Identifying relationship

type

accountID

firstName

LastName

addr

acct1 Napat Chusang xxxxx

acct2 Ittikorn Meemak yyyy

acct3 Varaporn Mektavorn zzzz

videotapeID

Title genre rating length

V01 Xmen Part I

action R 2

V02 Star War I

Sci Fi PG 13 2.5

V04 Harry Potter I

fantasi PG 13 3

Schema II

accountID

videotapeID

dateRented

dateDue

Cost

acct1 V01 12 Jan 2010

20 Jan 2010

70

acct2 V04 7 Mar 2010

27 Mar 2010

70

acct3 V02 1 Apr 2010

7 Apr 2010

40

acct4 V06 5 Jun 2010 5 Jun 2010

40

Conversion of ER Diagram to Relational Model

Many-to-many mapping

L_ID

FirstNameLastNam

e

Dept

Sub_name

Sub_code

TTeach SubjectM MLecturer

Credit

secL_ID firstNam

eLastNam

eDept

L1 Yuen Poovaravan

CPE

L2 Kietiyuth Kaveeyan EE

…….. ……. …… ……

Sub_code

Sub_Name Credit

01204211

Discrete Math

3

01204212

Abstract Data

3

01205201

ElectroMecha

2

….. ….. …..L_ID Sub_code

sec

L1 01204211

1

L3 01204211

2

L2 01205201

1

…… ….. …..

Primary keyFK

FK

Weak and Strong Entity Sets

An entity set may not have sufficient attributes to form a primary key. Such an entity set is termed a weak entity set. An entity set that has a primary key is termed a strong entity set.

For a weak entity set to be meaningful, it must be associated with another entity set, called the identifying or owner entity set. Every weak entity must be associated with and identifying entity; that is, the weak entity set is said to be existence dependent on the identifying entity set. The identifying entity set is said to own the weak entity set that it identifies. The relationship associating the weak entity set with the identifying entity set is called the identifying relationship. The identifying relationship is many to one from the weak entity set to the identifying entity set, and the participation of the weak entity set in the relationship is total.

Videotape1 M

Customer

costdateRented

dateDue

Rentalhas

has

1 1

Participation contraint

Weak entity class

Identifying relationship

type

Videotape1 M

Customer

costdateRented

dateDue

Rentalhas

has

1 1

Participation contraint

Weak entity class

Identifying relationship

type

A customer may have many rentals.A rental must have one customer.A videotape may have one rental.A rental must have one videotape.

A Rental object cannot exist without being related to a Customer and a Videotape, and no combination of attributes of class Rental is unique. Rental must be an example of a weak entity class.

A rental is identified by its relationship to a videotape. The related videotape is considered the owner of the rental. Without that relationship, the rental cannot exist. The key for a Rental entity is the VideotapeID attribute, which is the key of the owner videotape.

Problems with ER Models

The problems normally occur due to a misinterpretation of the meaning of certain relationships. These problems are referred to as Connection traps which are divided into 2 subtypes :

• Fan traps• Chasm traps

To identify connection traps, we must ensure that the meaning of a relationship is fully understood and clearly defined. If we do not understand the relationships we may create a model that is not a true representation on the real world.

BranchStaff

Division

SG37

SA9

SL21

r1

r2

r3

D1

D2

r4

r5

r6

B3

B7

B5

IsAllocated

relationship

Staffentities

Divisionentities

Operatesrelationsh

ip

Branchentities

IsAllocated

operates

1

M M

1

Fan Traps: Where a model represents a relationship between entity types, but the pathway between certain entity occurrences is ambiguous.

r4

r5

r6

StaffDivision

Branch

r1

r2

r3

D1

D2

SG37

SA9

SL21

B3

B7

B5

IsAllocated

relationship

Staffentities

Divisionentities

Operatesrelationsh

ip

Branchentities

OperatesIsAllocate

d

1

M

M

1

How to correct Fan Traps problem:

r4

r5

Property_for_rentBranch

Staff

r1

r2

r3

PG36

PG14

PL94

SG37

SA9

SL21

B3

B7

B5

IsAllocatedrelationshi

p

Staffentities

Property_for_rententities

Overseesrelationshi

p

Branchentities

IsAllocated

Oversees

1

M

M

1

Chasm Traps : Where a model suggests the existence of a relationship between entity types, but the pathway does not exist between certain entity occurrences

r4

r5

Property_for_rentBranch

Staff

R1

R2

r3

PG36

PG14

PL94

SG37

SA9

SL21

B3

B7

B5

IsAllocatedrelationshi

p

Staffentities

Property_for_rententities

Overseesrelationshi

p

Branchentities

IsAllocated

Oversees

1

M

M

1

How to solve the Chasm Traps problem:

Has1 M

r6

r7

r8

Hasrelationship

The Enhanced Entity-Relationship Model

The basic concepts of ER modeling are not sufficient to represent the requirements of the newer, more complex applications. The stimulated the need to develop additional semantic model concepts.

The ER model supported with additional semantic concepts is called the Enhanced Entity-Relationship (EER) model.

The EER model includes all the concepts of the original ER model together with the additional concepts of specialization/generalization.

The concepts of specialization/generalization

Specialization : (Top-Down Approach) The process of finding and specifying differences among objects of a single class. A single class is divided into one or more specialized subclasses. The set of subclasses is defined on the basis of some distinguishing characteristics of the entities in the superclass. When we identify a set of subclasses, we then associated attributes specific to each subclass.

Generalization : (Bottom-up Approach) The process of minimizing differences between entities by identifying their common features. The process of generalization can be viewed as the reverse of the specialization process.

ISA

Standard

Min_balance

Account-number

Senior

Num_checks

balance

Account

Checking_ccount

Saving_account

ISA Interest_rate

Overdraft-amount

Gold

Interest_payment

Date-of-birth

The concepts of specialization/generalization

The concepts of ER specialization/generalization are associated with the related concepts of entity sets described as superclass and subclass and the process of attribute inheritance.

Superclass : An entity set that included distinct subclasses that require to be represented in a data model.

Subclass : A subclass is also an entity set that has a distinct role and is also a member of a superclass.

ISA

Officer

Hours_worked

ID

Secretary

Office_number

name

address

Person

Employee Customer

ISA Credit_rating

Salary

Teller

Station_number

Wage

Attribute Inheritance

A crucial property of the higher and lower level entities created by specialization and generalization is attribute inheritance. The attributes of the higher-level entity sets are said to be inherited by the lower-level entity sets.

Whether a given portion of an E-R model was arrived by specialization or generalization, the outcome is basically the same :

• A high-level entity set with attributes and relationships that apply to all of its lower-level entity sets.

• Lower-level entity sets with distinctive features that apply only within a particular lower-level entity set.

There are 2 important reasons for introducing the concepts of Superclasses and Subclasses into an ER Model

1. To avoid describing different types of entities with possibly different

attributes within a single entity set.2. To avoid describing similar concepts more than once,

thereby saving time for designer and making the ER diagram more readable.

3. To add more semantic information to design in a form that is familiar to many people.

Constraints on Specialization and Generalization

A second type of constraint relates to whether or not entities may belong to more than one lower-level entity set within a single generalization. The lower-level entity sets may be one of the following:

• Disjoint : A disjointness constraint requires that an entity belong to no more than one lower-level entity set. e readable.

• Overlapping : The same entity may belong to more than one lower-level entity set within a single generalization.

Officer

commision-_rate

ID

Account

Teller

Daily_saleBonus

name

address

O

Personemployee

SiteA

Customer

A final constraint, the completeness constraint on a generalization or specialization, 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 the generalization/specialization. This constraint may be one the following

• Total generalization or specialization : Each higher-level entity must belong to a lower-level entity set.

• Partial generalization or specialization : Some higher-level entities may not belong to any lower-level entity set.

SiteA

commission-_rate

ID

Account

SiteB

Daily_saleBonus

name

address

O

Staff

Manager

IsAllocated

Typing_speed

O

Fname

Lname

Name

Address

Secretary Sales_Personnel

Staff

Bonus

Manages

Branch

Sales_area

Car_allowance

M

1

1

1

Staff-No

Manager

IsAllocated

Typing_speed

O

Fname

Lname

Name

Address

Sales_Personnel

Staff

Bonus

Manages

Branch

Salary_

Scale

Car_allowance

M

1

1

Staff-No

Part_Time_Temporary

Holiday_allowance

d

Secretary

Sales_area

Full_Time_Permanen

t

Hourly_rate

Example 1:

homeidstreetcitystatezipnobedrmsnobathssqftownoccupied

home

ssnownnamespousenameprofessionspouseprofess

owner

owns

owner (ssn , ownname, spousename, ……. );home (homeid, street, city, ……. , ssn);

foreign key (ssn) references owner

Example 2: homeid

streetcitystatezipnobedrmsnobathssqftownoccupiedcommissionsalesprice

home

ssnownnamespousenameprofessionspouseprofess

owner

owns

agentidagentnameofficeidphone

agent

lists

owner (ssn , ownname, spousename, ……. );home (homeid, street, city, ……. , ssn, agentid);

foreign key (ssn) references ownerforeign key (agentid) refences agent

agent (agentid, agentname, phone);

phone

homeidstreetcitystatezipnobedrmsnobathssqftownoccupiedcommissionsalesprice

home

ssnownnamespousenameprofessionspouseprofess

owner

owns

agentidagentnamephone

agent

lists

officeidaddressmgrnamephone

office

worksat

Example 3:

owner (ssn , ownname, spousename, ……. );home (homeid, street, city, ……. , ssn, agentid);

foreign key (ssn) references ownerforeign key (agentid) refences agent

agent (agentID, agentname, officeid, phone);foreign key (officeid) refences office

office(officeid, address, mrgname, phone)

ContrNoContrName

Contractor

SpecNoSpecName

SpecialtyProjNoProjName

Project ProjectNeeds

FulFillsHas

ProvidedBy

Supplies

proiect(projno, …) specialty(specno, …) contractor(contrno, specno, …)

FOREIGN KEY(specno) REFERENCES specialty projectneeds(projno, specno)

FOREIGN KEY(projno) REFERENCES project FOREIGN KEY(specno) REFERENCES specialty providedby(contrno, projno, specno)

FOREIGN KEY(projno, specno) REFERENCES projectneeds FOREIGN KEY(contrno) REFERENCES contractor

Example 4:

AcctidAcctNameBalance

Account DecomposedPartNoPartDescColor

Part Contains

part(partno, partdesc, color) account(acctid, acctname, balance) decomposed(acctid, parent_acctid)

FOREIGN KEY(acctid) REFERENCES accountFOREIGN KEY(parent_acctid) REFERENCES account

 contains(super_partno, sub_partno)

FOREIGN KEY(super_partno) REFERENCES part FOREIGN KEY(sub_partno) REFERENCES part

Example 5:

Patient

PatNoPatFirstNamePatLastNamePatCityPatStatePatZipPatHealthPlan

Visit

VisitNoVisitDateVisitPayMethodVisitCharge

Attends

Physician

PhyEMailPhyHospitalPhyCertification

Treats

Nurse

NursePayGradeNurseTitle

Item

ItemNoItemDescItemTypeItemPrice

VisitDetail

VisitDetailNoDetailChargeContains

Provides

UsedIn

Provider

ProvNoProvFirstNameProvLastNameProvPhoneProvSpecialty

D,C

patient(patno, …) provider(provno, …) physician(provno, …)

FOREIGN KEY(provno) REFERENCES provider ON DELETE CASCADE nurse(provno, …)

FOREIGN KEY(provno) REFERENCES provider ON DELETE CASCADE item(itemno, …) visit(visitno, patno, provno, …)

FOREIGN KEY(patno) REFERENCES patientFOREIGN KEY(provno) REFERENCES physician

 visitdetail(visitno, visitdetailno, provno, itemno)

FOREIGN KEY(visitno) REFERENCES visitFOREIGN KEY(provno) REFERENCES nurseFOREIGN KEY(itemno) REFERENCES item

 provides(visitno, visitdetailno, provno)

FOREIGN KEY(visitno, visitdetailno) REFERENCES visitdetail FOREIGN KEY(provno) REFERENCES nurse