DBDA Session 2

7/25/2019 DBDA Session 2

1/35


2/35

Chapter 3

Data Modeling Using theEntity-Relationship Model

Copyright 2004 Elmasri and Navathe.


3/35

Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition

Copyright 2004 Elmasri and Navathe.Chapter 3-3

Data Modeling Using

the ER Model and its extensionsExample Database Application (C!"AN#$E% !odel Concepts

& Entities and Attrib'tes

& Entity ypes) *al'e +ets) and ,ey Attrib'tes

& %elationships and %elationship ypes

& -ea Entity ypes& %oles and Attrib'tes in %elationship ypes

E% Diagrams/ Notation

%elationships o 1igher Degree

Extended Entity/%elationship (EE%$ !odel

Notation is based on %. Elmasri and +.3. Navathe) 5'ndamentals o Database +ystems)6 Ed. 7.) Addison -esley)

2000) Chapters 7.4.


4/35



SUMMARY OF ER-DIAGRAM

NOAION!eaning

EN8# #"E

-EA, EN8# #"E

%E9A8N+18" #"E

8DEN85#8N: %E9A8N+18" #"E

A%83;E

,E# A%83;E

!;98*A9;ED A%83;E

C!"+8E A%83;E

DE%8*ED A%83;E

A9 "A%8C8"A8N 5 E28N %

CA%D8NA98# %A8


5/35



E!a"ple COM#ANY

Data$ase

%e='irements o the Company (oversimpliied or

ill'strative p'rposes$

& he company is organi>ed into DE"A%!ENs.Each department has a name) n'mber and an

employee ?ho manages the department. -e eep

trac o the start date o the departmentmanager.

& Each departmentcontrols a n'mber o "%@ECs.Each proect has a name) n'mber and islocated at a

single location.


6/35



E!a"ple COM#ANY Data$ase

%Cont&'

&-e store each E!"9#EEBs social sec'rity n'mber)address) salary) gender) and birthdate. Each employeeworks forone department b't may work onseveral

proects. -e eep trac o the n'mber o ho'rs per?ee that an employee c'rrently ?ors on eachproect. -e also eep trac o the direct supervisoroeach employee.

&Each employee may havea n'mber oDE"ENDENs. 5or each dependent) ?e eep traco their name) sex) birthdate) and relationship toemployee.


7/35



ER DIAGRAM FOR (E COM#ANYDAA)ASE


8/35



ER Model Concets!

Entities and "ttributes

Entities / are speciic obects or things in the mini/?orldthat are represented in the database or example) theE!"9#EE @ohn +mith) the %esearch DE"A%!EN)

the "rod'ct "%@ECAttrib'tes are properties 'sed to describe an entity or

example) an E!"9#EE entity may have a Name) ++N)Address) +ex) 3irthDate

A speciic entity ?ill have a val'e or each o its attrib'tesor example) a speciic employee entity may haveNameF@ohn +mithB) ++NF


9/35



#yes of "ttributes

+imple Each entity has a single atomic val'e or the attrib'te or

example ++N or +exComposite he attrib'te may be composed o several components or

example) Address (AptL) 1o'seL) +treet) City) +tate) MipCode) Co'ntry$or Name(5irstName) !iddleName) 9astName$. Composition may orma hierarchy ?here some components are themselves composite.

!'lti/val'ed An entity may have m'ltiple val'es or that attrib'te orexample) Color o a CA% or "revio'sDegrees o a +;DEN. Denotedas ColorO or "revio'sDegreesO.

8n general) composite and m'lti/val'ed attrib'tes may be nestedarbitrarily to any n'mber o levels altho'gh this is rare. 5or example)"revio'sDegrees o a +;DEN is a composite m'lti/val'ed attrib'te

denoted by "revio'sDegrees(College) #ear) Degree) 5ield$O.


10/35



Entity #yes and $ey "ttributes

Entities ?ith the same basic attrib'tes are gro'ped or typed into anentity type. 5or example) the E!"9#EE entity type or the"%@EC entity type.

An attrib'te o an entity type or ?hich each entity m'st have a'ni='e val'e is called a ey attrib'te o the entity type. 5orexample) ++N o E!"9#EE.

A ey attrib'te may be composite. 5or example) *ehicleagN'mberis a ey o the CA% entity type ?ith components (N'mber) +tate$.

An entity type may have more than one ey. 5or example) the CA%entity type may have t?o eys

& *ehicle8dentiicationN'mber (pop'larly called *8N$ and& *ehicleagN'mber (N'mber) +tate$) also no?n as licensePplate n'mber.


11/35



ENIY Y#E CAR *I(

ARI)UES

car1((A3C


12/35



Relationshis and Relationshi #yes

A relationship relates t?o or more distinct entities ?ith a speciic

meaning or example) E!"9#EE @ohn +mith ?ors on the"rod'ct "%@EC or E!"9#EE 5ranlin -ong manages the%esearch DE"A%!EN.

%elationships o the same type are gro'ped or typed into arelationship type. 5or example) the -%,+PN relationship type in

?hich E!"9#EEs and "%@ECs participate) or the !ANA:E+relationship type in ?hich E!"9#EEs and DE"A%!ENsparticipate.

he degree o a relationship type is the n'mber o participating entitytypes. 3oth !ANA:E+ and -%,+PN are binary relationships.

!ore than one relationship type can exist ?ith the same participatingentity types or examples) !ANA:E+ and -%,+P5% aredistinct relationships bet?een E!"9#EE and DE"A%!ENparticipate.


13/35



%ea& Entity #yesAn entity that does not have a ey attrib'te

A ?ea entity m'st participate in an identiying relationship type ?ith ano?ner or identiying entity type

Entities are identiied by the combination o

& A partial ey o the ?ea entity type

& he partic'lar entity they are related to in the identiying entity

typeExample:

+'ppose that a DE"ENDEN entity is identiied by the dependentBs irstname and birthdate) andthe speciic E!"9#EE that the dependent isrelated to. DE"ENDEN is a ?ea entity type ?ith E!"9#EE as its

identiying entity type via the identiying relationship typeDE"ENDENP5


14/35



ER Model and Data

A$stra+tion

A3+%AC8N

Classiication

Aggregation

8dentiication

:enerali>ation

E% !odel Concept Entity Type- a grouping o

mem!er entitie"

#elation"hip Type - agrouping o mem!er

relation"hip"

%elationship ypeis anaggregation o (over$ its

participating entity types

-ea Entity ype

QQQQQQQQ


15/35



Constraints on "ggregation

Cardinality Constraints on %elationship ypes

& ( Also no?n as ratio constraints $

& !axim'm Cardinality ne/to/one

ne/to/many

!any/to/many

& !inim'm Cardinality (also called participation orexistence dependency constraints$

>ero (optional participation) not existence/dependent$

one or more (mandatory) existence/dependent$


16/35



One-to-"any%,N' or Many-to-one %N,'

RE.AIONS(I#

e<

e2

e7

e4

eG

eH

eI

E!"9#EE

r

Documents

DBDA Session 2