8/9/2019 22 ER Design

1/28

ER continued, and

ER to RelationalMappingsR&G Chapters 2, 3

Lecture 22

8/9/2019 22 ER Design

2/28

Administrivia

• Homework 4 ue !uesda"

• !oda"# More on the ER Model & $ esign

• %e t week# Concurrenc" Control &Reco'er"

8/9/2019 22 ER Design

3/28

Review: the ER Model

• Entities and Entit" (et )*o es+• Relationships and Relationship sets )diamonds+

– binary– n-ary

• e" constraints )-.-,-.M, M.%, arrows on - side+• /articipation constraints )*old 0or !otal+• 1eak entities . re uire strong entit" 0or ke"

• %e t, a couple more ad'anced concepts5

lotname

agepname

DependentsEmployees

ssn

Policy

cost

8/9/2019 22 ER Design

4/28

8/9/2019 22 ER Design

5/28

A re ation*sed to model a

relationshi#involvin arelationship set &

Allows $s to treata relationshi#set as an entityset 'or #$r#oses

o' #arti!i#ationin (other)relationshi#s&

Aggregation vs. ternaryrelationship 7

Monitors is a distin!trelationshi# with a des!ri#tiveattrib$te&

until

Employees

Monitors

lotname

ssn

budgetdidpid

started_on

pbudgetdname

DepartmentsProjects Sponsors

since

8/9/2019 22 ER Design

6/28

+on!e#t$al ,esi n *sin the ERModel

• ER modeling can get trick":• esign choices#

– Sho$ld a !on!e#t be modeled as an entity or an attrib$te

– Sho$ld a !on!e#t be modeled as an entity or arelationshi#– Identi'yin relationshi#s: .inary or ternary A re ation

• %ote constraints o0 the ER Model#– A lot o' data semanti!s !an (and sho$ld) be !a#t$red&– .$t some !onstraints !annot be !a#t$red in ER dia rams&

• /e’ll re%ne thin s in o$r lo i!al (relational) desi n

8/9/2019 22 ER Design

7/28

Entity vs& Attrib$te

• (hould address *e#– attrib$te o' Em#loyees or– an entity (related to Em#loyees)

• epends upon use o0 address in0ormation, andthe semantics o0 the data#

• I' several addresses #er em#loyee address m$stbe an entity (sin!e attrib$tes !annot be set-

val$ed)&

• I' str$!t$re (!ity street et!&) is im#ortant address m$st be modeled as an entity (sin!e attrib$te

val$es are atomi!)&

8/9/2019 22 ER Design

8/28

Entity vs& Attrib$te (+ont&)

• 1orks68n2 does notallow an emplo"ee towork in a department

0or two or moreperiods;

• (imilar to the pro*lemo0 wanting to recordse'eral addresses 0oran emplo"ee# we wantto record severalvalues of thedescriptive attributesfor each instance ofthis relationship.

name

Employees

ssn lot

orks_In!

"rom todname

budgetdid

Departments

dnamebudgetdid

name

Departments

ssn lot

Employees orks_In#

Duration"rom to

8/9/2019 22 ER Design

9/28

Entity vs& Relationshi#01 as lon as a

mana er ets ase#aratedis!retionary b$d et(dbudget ) 'or ea!hde#t&

/hat i' mana er’sdbudget !overs allmana ed de#ts

(!an re#eat val$e b$ts$!h red$ndan!y is#roblemati!)

Manages!

name dnamebudgetdid

Employees Departments

ssn lot

dbudgetsince

Employees

since

name

dnamebudgetdid

Departments

ssn lot

Mgr_Appts

is_manager

dbudget

apptnum

managed_b y

8/9/2019 22 ER Design

10/28

"hese thin s et #retty hairy2

• Man" E.R diagrams co'er entire walls:• 9 modest e ample#

8/9/2019 22 ER Design

11/28

A +adastral E-R ,ia ram

cadastral$ showing or recording property boundaries, subdivision lines,buildings, and related details

So$r!e: *S ,e#t& Interior .$rea$ o' 3and Mana ement4ederal 5eo ra#hi! ,ata +ommittee +adastral S$b!ommitteehttp://www.fairview-industries.com/standardmodule/cad-erd.htm

8/9/2019 22 ER Design

12/28

,emo o' a Real "ool

8/9/2019 22 ER Design

13/28

6e7t: Ma##in ER Models toRelational S!hemas

8/9/2019 22 ER Design

14/28

8/9/2019 22 ER Design

15/28

Relationshi# Sets to "ables

• 8n translating a man".to.man" relationship set to a relation,attri*utes o0 the relation must include#

– 1eys 'or ea!h #arti!i#atin entity set (as 'orei n =eys)&• "his set o' attrib$tes 'orms a superkey 'or the

relation &– All des!ri#tive attrib$tes&

lot

name

Employees

ssn

orks_In

sincedname

budgetdid

Departments

8/9/2019 22 ER Design

16/28

Relationshi# Sets to "ables

+REA"E "A.3E /or=s>In( ssn + AR (8) did I6"E5ER sin!e ,A"E ;RIMAR< 1E< (ssn did) 40REI56 1E< (ssn)

RE4ERE6+ES Em#loyees 40REI56 1E< (did)

RE4ERE6+ES ,e#artments )

ssn did since123-22-3666 51 1/1/"1

123-22-3666 56 3/3/"3

231-31-5368 51 2/2/"2

lotname

Employees

ssn

orks_In

since

dnamebudgetdid

Departments

8/9/2019 22 ER Design

17/28

Review: 1ey +onstraints

• Each dept has atmost one manager,according to thekey constraint on

Manages;

Translation torelational model?

Many%to%Many&%to%& &%to Many Many%to%&

dname

budgetdid

since

lot

name

ssn

ManagesEmployees Departments

8/9/2019 22 ER Design

18/28

!wo approaches#• Map relationship set

to a ta*le#

– 6ote that did is the=ey now2– Se#arate tables 'or

Em#loyees and,e#artments&

• (ince eachdepartment has auni ue manager, wecould insteadcom*ine Manages

and epartments;

+REA"E "A.3E Mana es( ssn + AR(88) did I6"E5ER

sin!e ,A"E ;RIMAR< 1E< (did) 40REI56 1E< (ssn) RE4ERE6+ES Em#loyees 40REI56 1E< (did) RE4ERE6+ES,e#artments )+REA"E "A.3E ,e#t>M r(

did I6"E5ER dname + AR(9 ) b$d et REA3 m r> ssn + AR(88) sin!e ,A"E ;RIMAR< 1E< (did)

40REI56 1E< (m r>ssn) RE4ERE6+ES Em#loyees (ssn) )

dname

budgetdid

since

lot

name

ssn

ManagesEmployees Departments

8/9/2019 22 ER Design

19/28

Review: ;arti!i#ation +onstraints• oes e'er" department ha'e a manager7

– I' so this is a participation constraint : the#arti!i#ation o' ,e#artments in Mana es is said tobe total (vs& partial )&

• I' Mana es be!omes a table (8 st a##roa!h) everydid val$e in ,e#artments table m$st a##ear in arow o' the Mana es table (with a non-n$ll ssn val$e2)

lotname dname

budgetdid

sincename dname

budgetdid

since

Manages

since

DepartmentsEmployees

ssn

orks_In

8/9/2019 22 ER Design

20/28

;arti!i#ation +onstraints in S?3

• 1e can capture participation constraintsin'ol'ing one entit" set in a *inar" relationship,*ut little else )without resorting to CHEC constraints+;

+REA"E "A.3E ,e#t>M r( did I6"E5ER dname + AR(9 ) b$d et REA3 m r>ssn + AR(88) 60" 6*33 sin!e ,A"E ;RIMAR< 1E< (did) 40REI56 1E< (m r>ssn) RE4ERE6+ES Em#loyees (ssn) 06 ,E3E"E 60 A+"I06 )

8/9/2019 22 ER Design

21/28

Review: /ea= Entities

• 9 weak entity can *e identi

8/9/2019 22 ER Design

22/28

"ranslatin /ea= Entity Sets

• 1eak entit" set and identi0"ingrelationship set are translated into asingle ta*le;– /hen the owner entity is deleted all owned

wea= entities m$st also be deleted&+REA"E "A.3E ,e#>;oli!y ( #name + AR(9 ) a e I6"E5ER

!ost REA3 ssn + AR(88) 60" 6*33 ;RIMAR< 1E< (#name ssn) 40REI56 1E< (ssn) RE4ERE6+ES Em#loyees 06 ,E3E"E +AS+A,E )

8/9/2019 22 ER Design

23/28

Review: ISA ierar!hies

Contract_Emps

namessn

Employees

lot

hourly_wagesISA

Hourly_Emps

contractid

hours_worked

As in +@@ or other ;3sattrib$tes are inherited&

I' we de!lare A 8(9 . everyA entity is also !onsidered tobe a . entity&

• Overlap constraints # Can =oe *e an Hourl"6Emps as wellas a Contract6Emps entit"7 ) Allowed/disallowed +

• Covering constraints # oes e'er" Emplo"ees entit"also ha'e to *e an Hourl"6Emps or a Contract6Empsentit"7 (Yes/no)

8/9/2019 22 ER Design

24/28

"ranslatin ISA ierar!hies toRelations

• General approach:– relations: Em#loyees o$rly>Em#s and +ontra!t>Em#s&

• Hourly_Emps : Every em#loyee is re!orded in Em#loyees&4or ho$rly em#s e7tra in'o re!orded in o$rly>Em#s(hourly_wages hours_worked ssn) B m$st delete

o$rly>Em#s t$#le i' re'eren!ed Em#loyees t$#le isdeleted)&

• ?$eries involvin all em#loyees easy those involvin C$sto$rly>Em#s reD$ire a Coin to et some attrib$tes&

• 9lternati'e# =ust Hourl"6Emps and Contract6Emps;

– Hourly_Emps : ssn name, lot, hourly_wages, hours_worked– !ontract_Emps: ssn, name, lot, contractid– Ea!h em#loyee m$st be in one o' these two s$b!lasses

8/9/2019 22 ER Design

25/28

"ernary Relationshi#s (!ont&)

• Man".Man".Man"relationship

• (ame as man".man"# create ta*leContract with0oreign ke"s toother 3 ta*les

Suppliers

(ty

DepartmentsContractParts

8/9/2019 22 ER Design

26/28

S$mmary o' +on!e#t$al ,esi n• !onceptual design 'ollows re"uirements analysis

–

8/9/2019 22 ER Design

27/28

S$mmary o' ER (+ont&)

• Several =inds o' inte rity !onstraints:– key constraints– participation constraints– o#erlap$co#ering 'or ISA hierar!hies&

• Some foreign key constraints are also im#li!it inthe de%nition o' a relationshi# set&

•Many other !onstraints (notably functionaldependencies ) !annot be e7#ressed&

• +onstraints #lay an im#ortant role in determininthe best database desi n 'or an enter#rise&

8/9/2019 22 ER Design

28/28

S$mmary o' ER (+ont&)• ER desi n is sub%ecti#e &

– o'ten many ways to model a iven s!enario2

• Analy in alternatives !an be tri!=y es#e!ially 'or a lar eenter#rise& +ommon !hoi!es in!l$de:

– Entity vs& attrib$te– entity vs& relationshi#– binary or n-ary relationshi#– whether or not to $se ISA hierar!hies– a re ation&

• Ens$rin ood database desi n: res$ltin relational s!hemasho$ld be analy ed and re%ned '$rther&– 4$n!tional ,e#enden!y in'ormation and normali ation

te!hniD$es are es#e!ially $se'$l&