Entity-Relationship Model & Converting to Tables

1

ER Tools

´ yEd: http://www.yworks.com/en/products_yed_about.html

´ Dia http://dia-installer.de/

´ Others:

´draw.io:https://www.draw.io/

´omniGraffle (Mac)Freetrialorbuyit

http://www.omnigroup.com/products/omnigraffle/

´Visio

´…

2

Weak Entity Set

´ Weakentityset– doesn’thavesufficientattributes toformaprimarykey.Itisdependant onthestrongentityset itisassociated with.Theweakentitysetstillneeds someformofidentifier: thediscriminator

3

Weak Entity Set´ Payment– althougheachpaymententity isdistinct, paymentsfor

differentloansmaysharethesamepaymentnumber(multiple payment#1’s,2’s,etc…)

´ Discriminator – althoughnoprimarykey,weneedameansofdistinguishing amongthoseentities intheentitysetthatdependononeparticularstrongentity(e.g.payment-number)

´ Discriminator – represented likeaprimarykey,exceptwithadashedunderline

´ Note:wedoNOTputl-number inpayment!

´ Bydefinition, theremustbetotalparticipation between theweakentitysetandits identifying relationship

4

ISA

´ Entitysets=likeclasses inOO

´ Therearesuper-classes andsub-classes.

´ They’recalled “IS-A”(ISA)relationships

´ **Thetriangle pointstothespecialization **

´ Generalization – “PERSON”

´ Specialization –

“Faculty”,“Student”,“Staff”

5

´ Thespecialization (subclass) setshaveeverythingthegeneralization(superclass) sethasbutmore.

“Astudent IS-Aperson”,“Afacultymemberisaperson”

Decisions to make…

´Entitysetvs.Attributes´Ifhasmoredata à entityset

´Ifisthedata à attribute

´Entitysetvs.Relationshipset´Verbargument:

´Entityset: nouns (students, faculty,loans,…)

´Relationship: possession verbs (teaches,advises, battles,owns,loanpayment,…)

6

Decisions to make…

´ Binaryvs.n-ary Relationship sets

´ Specialization/Generalization formodularity

´ Aggregationformodularity

7

Converting E-R Diagrams to Tables´ Primarykeysallowentitysets andrelationship sets tobeexpressed

uniformlyastableswhichrepresentthecontents ofthedatabase

´ AdatabasewhichconformstoanE-Rdiagramcanberepresented byacollection oftables

´ Foreachentity setandrelationship setthere isaunique tablewhichisassigned thenameofthecorrespondingentitysetorrelationship set

´ Eachtablehasanumberofcolumns(generallycorresponding toattributes),whichhaveunique names

´ ConvertinganE-Rdiagramtoatableformatisthebasis forderivingarelational database designfromanE-Rdiagram

8

Strong entity set

´ StrongEntitySet(E)– attributes {a1,a2,…,an}:

´ Tablewithprimarykeyandattributes ascolumns

´ Primarykey:sameasinentityset

´ e.g. student(ID, name, tot_credit) ß Schemastatement

9

Strong entity set (with composite attribute)

´ Createseparateattributes foreachcomponent– don’tinclude thehigher levelattribute“Name”

´ Namebecomes: first_name,middle_name, andlast_name

´ e.g. instructor(ID, first_name, middle_name, last_name, x, y, z)

10

Strong entity set (with multivalued attribute)

´ AttributeM(e.g.phone)onanentitysetE(e.g.Instructor)isrepresented byaseparatetable called EM(e.g.Instructor_phone) thatis,theconcatenation ofthetwotablesnames,oftenseparatedbyanunderscore“_”

´ EMhasattributes: primarykeyofE(“ID”),andattributes correspondingtomultivalued attributeM

´ Primarykeyofthistable:ALL attributes(theprimarykeyofentitysetEandtheattributeM)

´ e.g.Instructor_phone(ID, phone_number)

11

Weak entity set

´ WeakEntitySet(A)

´ IfAisaweakentityset,andBisthe identifying strongentitysetonwhichAdepends

´ Table: primarykeyofBandallA’sattributes

´ Primarykey:combination ofprimarykeyofB(strongentityset)anddiscriminator ofA

´ e.g. payment(l-number, payment-number, payment-amount, date)

12

Relationship set´ Many-to-many

´Table: primarykeysofthetwoparticipating entitysets andanyattributes ontherelationship itself (mayhavedupshere)

´Primarykey:theprimarykeysaddedfromtheparticipating entitysets

´ One-to-many/many-to-one´ Iftotalparticipation onthemany side´Table:addingextraattribute(theprimarykeyoftheone side)tothemanyside

´ Think:whichsidetakestheprimarykeyoftheother?Sideofmany

´Primarykey:Originalprimarykeyofentity setofmanyside

13

Example: nurse and department

´ Scenario1:

belongsIn(nID, deptID)

´ ForScenario2:(many-to-oneorone-to-manymappingbetweentwostrongentitysets)

´ Theprimarykeyoftheentitysetonthe“many”side(nurse)istheprimarykeyoftherelationship. So:

´ belongsIn(nID, deptID)

14

´ Scenario2:

belongsIn(nID, deptID)

TotalParticipation(double line)

Let’s start with this scenario

Example: nurse and department´ Scenario1:

belongsIn(nID, deptID)

´ ForScenario1:

´ Duetothetotalparticipation, youcanchoose torepresent thisrelationship (belongsIn) inadifferentway:

´ Canchoosetoaddtheprimarykeyoftheoneside(dept)tothenurseentitysetsincewithtotalparticipation EVERYnursemust‘belong in’adepartment ((many side gets PK of other))

´ Therefore,youcouldchoosetocreatethenursetable like:

´ nurse(nID, fname, lname, …, deptID) (PKwillstillbenID)

15

´ Scenario2:

belongsIn(nID, deptID)

TotalParticipation(double line)

Example: nurse and department´ Scenario1:

belongsIn(nID, deptID)

´ ForScenario1:

´ Duetothetotalparticipation, youcanchoose torepresent thisrelationship (belongsIn) inadifferentway:

´ Canchoosetoaddtheprimarykeyoftheoneside(dept)tothenurseentitysetsincewithtotalparticipation EVERYnursemust‘belong in’adepartment ((many side gets PK of other))

´ Therefore,youcouldchoosetocreatethenursetable like:

´ nurse(nID, fname, lname, …, deptID) (PKwillstillbenID)

16

´ Scenario2:

belongsIn(nID, deptID)

TotalParticipation(double line)

In this case, you will *no longer* need to create

a “belongsIn” table[This is the difference when we see total participation

on the many side]

Relationship set

´ One-to-one

´Table: Eithersidecanactasthe“many”side,addingtheprimarykeyoftheother

´Whichone?Doesn’tmatter– whicheverseems tomakethemostsense

´Primarykey:Originalprimarykeyofentity setyouchosetoaddtheprimarykeyoftheother

17

Summary

If relation one has prikeyA and relation two has prikeyB, then…If the relationship is´ 1:1 pickONEofthetwotobetheprimarykeyoftherelationship

´ m:m BOTHoftheprimarykeysbecometheprimarykeyoftherelationship

´ 1:m theprimarykeyontheMANYside istheprimarykeyoftherelationship

18

Look out for…

´ Ifpartialparticipation onthemany side,watchfornull values´ DONOTdothisforidentifying relationship sets

´ Whatifyouspecify limits? Those limits havetobemanagedprogrammatically – NOTintheDB.There isn’tagoodwaytomanagethatinthedatabase.

19

Pay attention to this situation“teaches” relationship set

´ “section” isaweakentityset

´ “course”isastrongentitysetwhichsection relies on

´ Remember:weakentitysetprimarykeyis:primarykeyofstrongentityset+itsdiscriminator

´ teaches(ID, course_id, sec_id, semester, year)

ID=instructor;course_id=course;rest:thediscriminatorofsection(whichhappens tobeallthreeattributes)

20

Specialization (ISA’s)

Method1: aka…Keep Everything…creates table for generalization set and specialization sets

´ Formatableforthehigher levelentity

´ Formatableforeachlowerlevelentityset, including primarykeyofthehigher levelentitysetandlocalattributes

´ Drawback:getting infoaboutlowerlevels requiresaccessingmoretables

21

Specialization (ISA’s)

Method2: aka…Keep Specialization entity sets only

create tables for specialization sets and no table for generalization set

´ Formatableforeachentitysetwithall localandinherited attributes.

´ Ifspecialization istotal (allmustbespecialized), table forgeneralizedentity isnotrequiredtostoreinfo

´ Drawback:people thataremorethanonespecialization willhaverepetition ofsomeinfo(workerandcustomer)

22

Specialization (ISA’s)

´ Toughdecision – depends onhowmanyattributes eachonehas

´ Method3?aka…Keep generalization set only´ Let’sassume PERSONhasalltheattributes andFaculty/Student/Staff

haveone attribute different

´ YouwouldprobablymakethePerson tableandjusthave3attributes attheendthatwouldbenull intheothercases

´ It’snotprettybutitsless duplication ofdata

23

Specialization (ISA’s)

´ Ifbalanced – createall four--- method 1´ Ifmoreattributes inspecialization --- method 2

´ Ifmoreattributes ingeneralization --- method 3

Tosumup:

´ Designdecision – basedonnumberofattributes

´ DBadministrator’sdecision

´ Goal:minimizeduplication (there isnoone “correct”way)

24

Aggregation

´ [Reviewthismaterialonyourown]

´ Createatablewith´primarykeyofaggregatedrelationship,

´primarykeyoftheassociatedentityset,

´plusanydescriptiveattributes

25