ER-modeling Datamodellering 2008 1 Wat is ER-modeling? ER-modelleren: top-down benadering bedacht door P. Chen 1976, paper in ACM Transactions on Database Systems Codd (Relationeel Model) aanvankelijk tegen, reageerde met RM/T (een semantisch databasemodel) veel uitbreidingen Extended E-R Model lange historie varianten in notatie kern: entiteitsklassen (= entity types) met attributen relaties tussen deze entiteitsklassen Zeer geschikt om requirements te modelleren - ERD te lezen als verzameling beweringen (assertions) over samenhang in UoD 2/26 ERD & relationeel model ER-benadering kan de complexiteit van de werkelijkheid vastleggen zonder de beperkende regels van het relationele model ERD rijke semantiek Transformeren t.b.v. implementatie: conceptueel en logisch model verschillend 3/26 DMO 2008 1
Varianten in notatie Entiteiten en relaties Entiteit met attribuut Relatie met attribuut De notatie met de kraaiepoot is eenvoudiger, maar ook beperkter (relaties geen attributen) 4/26 Voorbeeld ERD (Crow s foot) optionaliteit entiteitsklasse mag ook attribuutnamen bevatten, i.h.b. PK en FK Deze notatie is (min of meer) die van Information Engineering (wij gebruiken deze in de cursus) De Barker-notatie lijkt hierop Hoe het diagram te lezen? relatie met cardinaliteit (connectivity) en labels 5/26 Voorbeeld ERD (Chen) Let op de verschillende notatiestijl 6/26 DMO 2008 2
Voorbeeld ERD (UML) 1:N-relatie: 7/26 Entity class en entity Entity class: Something that can be identified and the users want to track - vereist steeds een duidelijke definitie (documentatie) Entity: instance van de class ER zoals Chen het zelf illustreert: 8/26 Attributen Beschrijven kenmerken van de entiteit Alle entiteiten van een bepaalde klasse hebben de zelfde attributen Bijzondere soorten attributen composite (b.v. straat + huisnummer) relationele multi-valued (repeating groups) model! identifiers (eventueel composite) afgeleide (berekende) attributen: wel vermelden in ERD in pseudocode documenteren Een attribuut heeft een domein van waarden 9/26 DMO 2008 3
Simple & composite attributes Customer_address simple en composite ( aparte velden) 10/26 Multi-valued attribute Implementeren als 1:N-relatie 11/26 Indentifiers Elke entiteitsklasse moet een identifier (PK) hebben Primary key is steeds uniek is nooit NULL moet stabiel zijn kan migreren naar een ander entiteitstype FK natural key of surrogate key Foreign key heeft waarde van PK (is referentie) of is in zijn geheel NULL Geen geschikte PK, dan artificial key (= surrogate key, system-generated key), b.v. volgnummer 12/26 DMO 2008 4
Soorten entiteitsklassen Fundamentele: basisconcepten Onafhankelijk afhankelijk weak entity, zie volgende slide Transferable non-transferable (semantiek!) Associatieve = intersection entitytypes ontstaan b.v. bij M:N 2 x 1N Attributieve: categoriseren van andere entiteitsklassen b.v. soort_bedrijf en bedrijf 13/26 Strong vs. weak entity class independent = strong entitytype identifying relationship dependent = weak entitytype PK beoordeling? verwar dit niet met tranferability (zie Simsion) 14/26 Relaties tussen entiteiten Graad (degree) van de relatie = aantal deelnemende entiteiten (b.v. ternair: b) Meest gangbare: binair Wij beperken ons in de cursus hiertoe! 15/26 DMO 2008 5
M:N-relatie M:N 2 x 1:N (van conceptueel naar fysiek) t.b.v. implementatie intersectie tabel = associatieve tabel 16/26 Recursieve relatie Self-referencing (bij implementatie dus binnen één tabel): 1:N (boom = hierarchie) b.v. een team chef medewerkers M:N (netwerk) b.v. remsysteem veel onderdelen geplaatst in veel auto s 17/26 Implementeren rec. relatie HEEFT_CHEF PersNr 1 2 3 Chef 2 NULL 2 ONDERDEEL Nr Omschrijving 1 A 2 B 3 C Persoon 1 en 2 hebben persoon 3 als chef. CONSTRUCTIE Nr Bevat 1 2 1 3 2 NULL 3 3 NULL 4 2 2 1 4 18/26 DMO 2008 6
N-ary relaties oplossen N-ary relaties binaire relaties 19/26 Geen redundante relaties Redundante relaties verwijderen 20/26 Generalisatie (IS-A) Een generalisatie-hierarchie (IS-A relatie): om entiteitsklassen aan elkaar te relateren die een aantal attributen gemeenschappelijk hebben en in anderen verschillen voor het conceptualiseren van de overerving van die gemeenschappelijke attributen beperkt tot single inheritance te onderscheiden van rollen (zie Simsion) 21/26 DMO 2008 7
Let op! ook hier verschil met UTexas Subtypes Subtypes non-overlapping exhaustive minstens één attribuut of een relatie die alleen geldt voor het subtype 22/26 Subtype discriminator Ieder supertype moet een subtype discriminator bevatten: als niet-sleutelattribuut of als foreign key 23/26 Implementeren generalisatie Verschillende opties alleen tabel voor supertype met subtype-kolom met specifieke velden voor subtype alleen tabellen voor subtypes herhaling van velden tabel voor supertype én voor subtypes 24/26 DMO 2008 8
Rol concept Overlappende subtypes vermijden 25/26 Oefening Een supermarkt plaatst orders (OrderNr, Datum) bij een leverancier (Naam, Adres, Plaats, Telefoon, Contactpersoon). Een order betreft producten (ProdNr, Omschrijving, Hoeveelheid, Prijs) Maak een genormaliseerd ERD 26/26 DMO 2008 9