Database Design 20120423

Databases 1
Database Design
Wilfried Wuyts & Kristof Nuyts

Technologie Geel Bachelor in Elektronica-ICT
2011
Inhoud
Data vs informatie Deel 1: ontwerp van een ERD
Entiteiten, instanties, attributen, identifiers ERD Relaties ERD-tekenafspraken Super- en subtypes Business rules (structural en procedural) Relationship transferability Relatietypes Redundante relaties Veel op veel-relaties oplossen Unique identifiers
Databases 1 Database Design 2
Inhoud
Deel 1: ontwerp van een ERD (vervolg)
Normalisatie (eerste, tweede en derde norm.-vorm) Hierarchie, recursive relationships Tijdsafhankelijke gegevens
Deel 2: van ERD naar databasemodel

Primary, foreign en unique key ERD-omzetting (+ terminologie)
Relaties Super- en subtypes
Databases 1 Database Design
Data versus informatie

Allerhande data kan bewaard worden in een database Enkel data die achteraf nuttig blijkt te zijn moet bewaard worden Deze cursus: wat en vooral hoe moet dit gebeuren Data en informatie worden meestal als synoniemen gebruikt
Data: Ruw materiaal, hieruit kan informatie gehaald worden Informatie: kennis, intelligentie, is meestal het resultaat van het combineren, vergelijken of uitvoeren van berekeningen op data
Voorbeeld:
Data: Alle punten van het vak databases 1 Informatie: gemiddelde score op dit vak, aantal geslaagden,
Data versus informatie

Wat is een database
Een gecentraliseerde en gestructureerde hoeveelheid data op een computersysteem Het is mogelijk om met de database gegevens op te vragen, toe te voegen, aan te passen en te verwijderen De database maakt het mogelijk om informatie uit deze data te halen De database wordt meestal door een database administrator beheerd (DBA)
Overzicht
In deze cursus worden Data Modeling en Database Design bekeken. De fase Database Build gebeurt pas later in SQL Server en werd al bekeken in MS Access De klant die een database nodig heeft zal zorgen voor een conceptual model (beschrijving van het probleem) Wij zullen hiervan een physical model moeten maken Dit physical model moet vervolgens omgezet worden naar een database-ontwerp
Deel 1: ontwerp van een ERD
Deel 1: ontwerp van een ERD
Entiteiten
Entiteiten (Entities) zijn de dingen waarover data bewaard worden
Voorbeelden over een school: STUDENTen, DOCENTen, VAKken, LOKA(A)L(en) Meestal zelfstandige naamwoorden
Instanties
Instanties: de elementen aanwezig in een entiteit
Voorbeelden bij de entiteit STUDENT: S5042451, Jefke Verhagen, 2ELO/ICT3 S5044234, Bert Sauviller, 2ELO/ICT1 PERSOON: President Obama PRODUCT: Volkswagen Golf PRODUCT TYPE: Schoen BEROEP: Kok DIER: Hond
Er zijn veel entiteiten

Sommige hebben vele instanties, andere weinig (voorbeelden?)
Instanties
Is HOND een instantie of een entiteit?
Als het gaat over soorten dieren dan zal de entiteit DIER een aantal instanties kunnen hebben zoals hond, kat, paard, Als het gaat over een hondenkennel dan kan de entiteit HOND een aantal instanties kunnen bevatten zoals terrir, poedel, labrador,
10
Attributen
Attributen (Attributes) geven meer informatie over de entiteiten
Ze helpen om op zoek te gaan naar specifieke data Voorbeelden Entiteit STUDENT: studentID, naam, adres, klas, Entiteit VAK: benaming, studiepunten, examenvorm,
Een attribuut is een bepaald stukje informatie

Dat een entiteit beschrijft Dat de hoeveelheid van een entiteit bepaalt Dat een entiteit indeelt
Describes, quantifies, qualifies, classifies and specifies an entity
Een attribuut bevat slechts n waarde (bvb. het adres van een persoon kan maar 1 waarde bevatten)
11
Attributen
Voorbeelden van attributen
KLANT: voor- en familienaam, leeftijd, schoenmaat, adres, emailadres AUTO: model, gewicht, catalogusprijs JOBOVEREENKOMST: startdatum, loon
De waarde van een attribuut kan een getal, tekst, datum, afbeelding, zijn. Dit moet aangegeven worden met een datatype (integer, text, boolean, image,) Sommige attribuutwaarden zijn veranderbaar (in de tijd), bvb. leeftijd, schoenmaat, Andere zijn niet-wijzigbaar, bvb. besteldatum, geboortedatum Als je de keuze hebt, kies dan de niet-wijzigbare (geboortedatum i.p.v. leeftijd)
Attributen
Sommige attributen moeten een waarde bevatten (mandatory), bvb. De naam van een student Anderen zijn niet verplicht om een waarde te bevatten (optional, mogen de waarde NULL bevatten), bvb. GSMnummer Geef enkele attributen van de entiteit BOEK
13
Identifier
Unique Identifiers (UID) zijn nodig om de instanties van elkaar te onderscheiden
Voorbeelden: studentnummer, rijksregisternummer Meestal een fictief ID (oplopend getal) zoals bij een bankoverschrijving, offertenummer
UIDs kunnen een attribuut zijn of een combinatie van attributen
14
ERD
Een Entity Relationship Diagram of ERD is een tool dat (de verbanden tussen) data kan weergeven, ongeacht welke type database later gaat gebruikt worden Een ERD is dus implementationfree 4 doelstellingen van een ERD
Alle benodigde data moet aanwezig zijn Data mag maar n keer voorkomen Geen data bewaren die kan afgeleid worden Plaats data op een voorspelbare logische plaats
15
Relaties
Niet alleen entiteiten zijn belangrijk binnen een ERD maar ook de relaties ertussen hebben een belangrijke rol Elke relatie
vormt een belangrijke schakel in het model geeft aan hoe entiteiten aan elkaar gelinkt worden bestaat tussen twee entiteiten of tussen dezelfde entiteit heeft steeds twee kanten is langs beide kanten benoemd heeft een optionality heeft een graad of cardinaliteit (geeft een aantal aan)
16
Relaties: voorbeelden
Voorbeeld 1 (vliegtuigreis)
Elke zetel kan aan n of meerdere passagiers verkocht worden (overbooking is mogelijk) Elke passagier kan n zetel kopen
Voorbeeld 2 (muziek)
Elke muzieknummer wordt geplaatst binnen n TYPE (rock, jazz, pop,) Optionaliteit: moet of kan?
Elk lied MOET ondergebracht worden in n type Elk type KAN n of meerdere liedjes omvatten
Kardinaliteit: hoeveel?
Elk lied moet ondergebracht worden in EXACT N type Elk type kan N OF MEERDERE liedjes omvatten
Kunnen types bestaan zonder dat er liedjes toe behoren? Is dit logisch? Afgesproken regels bepalen de kardinaliteit
waarom mag een lied maar tot n type behoren? Als een lied tot meerdere types mag behoren: Elk lied moet ondergebracht worden in N OF MEERDERE types
18
Bespreek optionaliteit en kardinaliteit
Elke bestelling moet door exact n klant gebeuren Elke klant kan n of meerdere bestellingen doen
19
Een relatie kan een entiteit aan zichzelf koppelen
In een bedrijf werken managers en werknemers. Elke werknemer heeft n manager. Elke manager kan meerdere werknemers cordineren. Aangezien een manager ook een werknemer is van het bedrijf blijft er maar n entiteit over: WERKNEMER Elke werknemer kan n of meerdere werknemers cordineren Elke werknemer kan gecordineerd worden door n werknemer Waarom staat in beide voorgaande zinnen kan en niet moet?
20
ERD: tekenafspraken
Entiteiten worden voorgesteld door een softbox (afgeronde rechthoek) De namen van de entiteiten worden bovenaan de softbox geplaatst (in enkelvoud en in drukletters)
SONG
TYPE
21
ERD: tekenafspraken
Attributen worden onder de entiteitsnaam geplaatst Verplichte attributen worden aangegeven met een asterisk, * Optionele attributen worden aangegeven met een cirkel, o Unieke identifiers worden aangegeven met een hekje, #
SONG # songID * title * duration * artist songwriter
CLIENT # number * first name * last name * phone number email address
22
ERD: tekenafspraken
Relaties worden door lijnen voorgesteld die de entiteiten met elkaar verbinden De lijnen
kunnen vol of onderbroken zijn eindigen in een single toe of een crows foot
23
Relaties
Relaties verklaren:
Elke relatie kan onderverdeeld worden in een 6-tal delen 1. Elke 2. Entiteit A 3. Optionaliteit
Moet: volle lijn Kan: onderbroken lijn
4. Naam van de relatie 5. Kardinaliteit

exact n: single toe n of meerdere: crows foot
6. Entiteit B Aangezien een relatie twee uiteinden heeft , kan de relatie tweemaal besproken worden (links=>rechts, rechts=>links)
Relaties
WERKNEMER AFDELING
Elke werknemer moet werken in exact n afdeling Elke afdeling kan de kostenplaats zijn voor n of meerdere werknemers Noteer zelf twee aan elkaar gekoppelde entiteiten en schrijf de verklarende zinnen op
25
Supertypes en subtypes
Soms bevatten instanties van entiteiten een aantal attributen of relaties die andere instanties niet bevatten Voorbeeld: betalingen
Klanten kunnen betalen via: cash, cheque en kredietkaart Alle betalingen hebben een aantal gemeenschappelijke attributen: betaaldatum, bedrag, Kredietkaart: ook het kredietkaartnummer moet bewaard worden Bij kredietkaart en cheque moet bijgehouden worden welke klant de betaling deed Oplossing?
En entiteit: BETALING Drie aparte entiteiten (maar wat als er een vierde betaalmogelijkheid bijkomt?)
Soms is het handig om een entiteit onder te verdelen in subtypes, hoofdentiteit wordt dan het supertype (te vergelijken met overerving in OO-programmering) Een subtype
Erft alle attributen n relaties van het supertype Heeft meestal nog eigen attributen of relaties Wordt binnen het supertype getekend Bestaat nooit alleen (er is steeds een tweede subtype) Kan zelf ook nog subtypes bevatten
DIER GEWERVELDE ONGEWERVE LDE

Supertype : EXAM Subtypes: MIDTERM, FINAL en QUIZ Relatie tussen EXAM en STUDENT Relatie tussen BONUS QUESTION en (enkel!) QUIZ FINAL bevat bvb. 6 attributen
28
Er zijn altijd minstens twee subtypes: dit leidt tot twee regels
Exhaustive : elke instantie van een supertype is ook altijd een instantie van n van de subtypes Mutually exclusive: elke instantie van een supertype behoort tot exact n subtype
Soms kan een extra subtype OTHER handig zijn
29
Business rules
Niet alle business rules (afspraken over de functionaliteiten van de database) kunnen in een ERD worden weergegeven. Deze moeten achteraf bijgeprogrammeerd worden Structural business rules: geven aan welke informatie moet bewaard worden en hoe deze aan elkaar gelinked is.
Kunnen meestal in een ERD worden weergegeven
Procedural business rules: geven workflow of businessgerelateerde processen aan

Moeten meestal geprogrammeerd worden
30
Structural business rules

Voorbeelden
Elke bestelling moet door exact n medewerker afgehandeld worden Er is dus geen self-service
Elke leraar moet over een geldig teaching certificate number beschikken
TEACHER # id * name * address * Teaching certificate number

31
Procedural business rules

Voorbeelden
Studenten moeten eerst een credit behaald hebben op databases 1 voor ze databases 2 kunnen aanvatten
VAK
STUDENT
Een werknemer die meer dan 2 overuren per week doet moet 1,5 keer zijn uurloon verkrijgen Klanten die hun facturen na 30 dagen nog niet betaald hebben kunnen geen nieuwe bestellingen plaatsen Geef enkele voorbeelden op beide soorten business rules
Relationship transferability
Kan een klas die aan een docent gekoppeld is (les krijgt) later een andere docent krijgen? Kan je je duurbetaalde fitness-abonnement doorgeven aan een vriend? Kan je het type/genre van een lied achteraf wijzigen?
33
Transfereerbare relaties
Een student kan na een bepaalde tijd overstappen naar een andere klas
Niet-transfereerbare relaties (ruit op de relatie / diamond)

Een student die een examen heeft afgelegd (punten heeft behaald) kan deze punten niet doorgeven aan een andere student
EXAMEN
STUDENT
34
Andere voorbeelden?
35
Relatietypes
Kan een PERSOON meerdere CDs bezitten? Kan een CD in het bezit zijn van meerdere PERSONEN? De antwoorden op bovenstaande vragen hebben een effect op het ERD Er zijn drie types van relaties
n op veel (one-to-many) Veel op veel (many-to-many) n op n (one-to-one)
36
Relatietypes
n op veel-relatie
komen het meest voor in een ERD
WERKNEMER
AFDELING
37
Relatietypes
Veel op veel-relatie
Komen veel voor in de ontwerpfase van een ERD maar worden in latere stadia vervangen door n op veel-relaties
38
Relatietypes
n op n-relatie
Komen voor in de ontwerpfase van een ERD maar worden meestal weggewerkt
39
Redundante relaties
Een redundante relatie kan afgeleid worden van een andere relatie uit het model Linkerschema
Het land waarin de persoon woont kan afgeleid worden via de twee zwarte relaties (grijze) relatie is dus overbodig Rechterschema De relatie tussen persoon en land is anders dan in het linkerschema en kan niet afgeleid worden
Veel op veel-relaties oplossen

Medewerkers van een bedrijf worden ingezet bij events Als extra attribuut willen we de status van hun job bijhouden (wat is de status van iemand bij een bepaald event?) Bij welke entiteit moet dit attribuut geplaatst worden? Een derde entiteit is nodig. Dit wordt de intersection entity genoemd
41

De originele veel op veelrelatie is omgezet naar twee n op veel-relaties Wat zou de unique identifier worden van deze nieuwe entiteit? De UID wordt de combinatie van de UIDs van de originele relaties (in dit geval: combinatie van PARTNERid en EVENTid) Het wordt aangegeven via de barred relationships, dwarse lijnen op de relatie
Intersection entity

Voorbeeld: TV-show
Oplossing:
43

Voorbeeld: schoonmaakbedrijven / poetsdiensten.
Oplossing:
44
Unique Identifiers
Een Unique Identifier is de waarde (of combinatie van waardes) die het mogelijk maakt voor de gebruiker om een uniek item uit alle instanties van een entiteit te halen Enkelvoudige UID
Een UID die maar n attribuut omvat
Samengesteld UID
Een UID die bestaat uit twee (of zelden nog meer) attributen
45
Unique Identifiers
Artificile UIDs zijn attributen die worden toegevoegd omdat in de entiteit geen volwaardig UID beschikbaar is
Voorbeelden:
Studentnummer, rijksregisternummer,
46
Unique Identifiers
Soms is de UID de combinatie van een attribuut en een relatie In onderstaand voorbeeld moet in gedachten gehouden worden dat een bankrekeningnummer bij meerdere banken kan gebruikt worden, bvb bankrek.nr 1256 kan bij bank A voorkomen maar ook bij bank B
Bij een overschrijving zal dus zowel het bankrek.nr als het banknummer moeten opgegeven worden
Unique Identifiers
UIDs van barred relationships (veel op veel-relaties opgelost) De UID van PLAY LIST ITEM is afkomstig van EVENT en SONG, dus combinatie van EVENTid en SONGid De bars trekken de UIDs naar PLAY LIST ITEM en vormen daar samen het nieuwe UID
48
Unique Identifiers
Het is ook mogelijk om een artificieel UID te gebruiken
Geef een voorbeeld van een intersection entity en bepaal hiervoor de UID
49
Unique Identifiers
Soms bestaan er meerdere attributen in een entiteit die zouden kunnen doorgaan voor UID. In dat geval spreekt men van kandidaat-UIDs Degene die gekozen wordt: Primary UID De andere kandidaten: Secundary UIDs n primary UID (studentID) en n secundary UID (badge number)
n primary UID (studentID) en twee secundary UIDs

badge number Combinatie van first name en last name
Unique Identifiers
ERD : Database model :
Unique identifiers Primary keys
51
Normalisatie
Normaliseren is het proces waarbij redundante gegevens in een database vermeden worden Er zijn drie normaalvormen (normalisatiestappen van Codd) die n voor n moeten doorlopen worden Na deze drie stappen: genormaliseerde database
52
Normalisatie: eerste normaalvorm

Eerste normaalvorm vereist dat er geen meerdere waarden mogelijk zijn bij een attribuut Nakijken dat elk attribuut maar n waarde bevat voor elke instantie van een entiteit Classroom kan meerdere waarden bevatten voor een specifiek schoolgebouw Schending van eerste normaalvorm Oplossing: haal dit attribuut uit de entiteit en maak er een aparte entiteit van (met een n op veel-relatie)
53

Schenden onderstaande ERDs de eerste normaalvorm?
HUIS # id * straat * huisnummer * postcode * gemeente * bewoner
DOCENT # id * naam * adres * vak
54

Oplossingen
HUIS # id * straat * huisnummer * postcode * gemeente
DOCENT BEWONER # id * naam * geb_datum tel_nummer # id * naam * adres
VAK # id * benaming * Studiepunten ECTS-fiche
Welke attributen in de intersection entity?

Normalisatie: Tweede normaalvorm

Wat is de UID van de entiteit LESOPDRACHT?
DOCENT # id * naam * adres DOCENT # id * naam * adres DOCENT # id * naam * adres LESOPDRACHT # tijdstip * lokaal # semester * LESOPDRACHT initiaalDocent * tijdstip Of * lokaal * semester * initiaalDocent LESOPDRACHT # lesopdrachtID * tijdstip * lokaal * semester * initiaalDocent attribuut staat niet VAK # id * benaming * studiepunten ECTS-fiche VAK # id * benaming * studiepunten ECTS-fiche VAK # id * benaming * studiepunten ECTS-fiche
Welk
op zijn plaats?
56

DOCENT # id * naam * adres LESOPDRACHT # tijdstip * lokaal # semester * initiaalDocent VAK # id * benaming * studiepunten ECTS-fiche
Tweede normaalvorm
Enkel na te kijken bij een meervoudige UID
LESOPDRACHT # id Definitie: alle niet-UID-attributen mogen enkel afhankelijk # id # tijdstip zijn * naam van het ganse UID * benaming * adres Voorbeeld * DOCENTid initiaalDocent * lokaal bovenaan: initiaaldocent # semester DOCENT VAK
worden
is enkel afhankelijk van ECTS-fiche en moet dan ook naar die entiteit verplaatst
* studiepunten
57

UID van entiteit ACCOUNT is combinatie van accountnumber en banknumber bank location is enkel afhankelijk van banknumber en moet bijgevolg verplaatst worden naar entiteit BANK
58

Een DJ houdt in een database alle songs bij en de playlists die hij speelde op events duration is enkel afhankelijk van de entiteit SONG event date is enkel afhankelijk van de entiteit EVENT Beide zijn schendingen van de tweede normaalvorm
59
Normalisatie: Derde normaalvorm

Derde normaalvorm
Definitie: geen enkel niet-UID-attribuut mag afhankelijk zijn van een ander niet-UID-attribuut
Voorbeeld: per CD houd je bij in welke winkel je deze gekocht hebt

Het adres van de winkel is afhankelijk van de winkelnaam
Als ooit het adres zou wijzigen van de winkel dan moet dit bij alle CDs aangepast worden

Oplossing: maak een nieuwe entiteit en verplaats beide attributen
Schending van derde normaalvorm?
Oplossing:
61
Schending van derde normaalvorm? Oplossing:
Niet echt een verbetering!
62
Hierarchie, recursive relationships

Recursive relationship
Hierarchische structuur
Waarom streeplijnen als relaties?

Tijdsafhankelijke gegevens
Vele eigenschappen wijzigen in de loop der tijd: schoenmaat, loon, verhuurgegevens videotheek, procesgegevens in een bedrijf, Voorbeeld: loon bij werknemers
Via onderstaande entiteit kan enkel het huidige loon bewaard worden
Voor tijdsafhankelijke gegevens is steeds een extra entiteit vereist

Wat is de UID van de entiteit SALARY HISTORY? Combinatie van salary start date en EmployeeID
Waarom is het attribuut salary end date optioneel? Voor het huidige loon is de einddatum nog niet gekend
65
Een winkel verhuurt juwelen aan beroemdheden. Men wil per juweel de verhuurgeschiedenis kennis Via onderstaand ERD wordt enkel de huidige huurder bewaard
Hoe zou jij dit probleem oplossen?
66
Je komt uit op een veel op veel-relatie
, welke vervolgens omgezet wordt naar:
Wat is de UID van de entiteit RENTAL HISTORY?
67
Oplossing:
68
Voor elke aankoop in onze groentenwinkel houden we gegevens bij:
We zouden het verband willen zien tussen aankoopgedrag en max- en min-temperatuur van die dag om zo beter aan stockbeheer te kunnen doen: Probleem: we zondigen tegen een normaalvorm, welke? De derde normaalvorm: Temperaturen zijn afhankelijk van datum
Oplossing:
Een gelijkaardige structuur is nodig voor gegevens die van kostprijs wijzigen
70
Oefening 1
Noteer voor elke relatie zowel van links naar rechts als omgekeerd de verklarende zin Geef voor elke entiteit de UID
71
Oefening 2
Noteer voor elke relatie zowel van links naar rechts als omgekeerd de verklarende zin Geef voor elke entiteit de UID
72
73
Primary key
Een relationele database is een database waarbij de tweedimensionale tabellen aan elkaar gelinkt zijn d.m.v. relaties De primary key (primaire sleutel) is de kolom of combinatie van kolommen die een rij in een tabel uniek maakt
Een primary key kan nooit de waarde NULL bevatten

Foreign key
Een foreign key (FK, refererende sleutel) is een kolom in n tabel die gekoppeld is aan een primary key-kolom in een andere tabel De foreign key-kolom kan enkel waarden bevatten die in de primary-kolom van de andere tabel voorkomen (referentile integriteit)
75
Unique key
Een tabel kan soms meerdere primary keys bevatten
Kies n primaire sleutel De andere sleutels worden unique keys (UK) of kandidaatsleutels genoemd
76
Foreign key
Als een foreign key deel uitmaakt van een primary key dan kan deze FK niet NULL zijn
77
Omzetting van ERD naar database-model

Omzetting van ERD naar database-model (of van conceptueel model naar fysisch model)
pk: primary key fk: foreign key uk: unique key

Terminologie bij omzetting

ERD
Entiteit Instantie Attribuut Primary UID Secundary UID Relatie Tabel-diagram notatie
Tabelnamen zijn de meervouden van de entiteitsnamen, Vb. Entiteit STUDENT wordt tabel STUDENTEN
Database model
Tabel Rij of record Kolom of veld Primary key Unique key Foreign key veld
Omzetting van ERD naar database-model

Voorbeeld:
80
Omzetting van relaties

Een relatie in een ERD zorgt voor n of meerdere foreignkey kolommen in de tabel aan de veel-kant De foreign key-kolom is verplicht of optioneel net zoals de relatie dit was. Het primary key-veld wordt als het ware naar de crowfoot-tabel getrokken
81

Er is geen verschil in database-ontwerp als de n-kant van een relatie verplicht is in plaats van optioneel. Er is extra programmatie nodig om dit te eisen Men kan via de tabellen niet eisen dat elke BAND voorkomt in de tabel MUSICIANS
82

Het is in het database-model niet aan te geven dat een relatie niet-tranfereerbaar is.
Via extra programmatie moet aangegeven worden dat het foreign key-veld niet kan ge-update worden
83

Bij een barred relationship zal het UID van de n-kant zowel een primary key worden als in de gerelateerde tabel een deel van de primary key Voorbeeld:
Bank_number is de primary key in de tabel BANKS Bank_number vormt samen met Account_number de primary key in de tabel ACCOUNTS

Veel op veel-relaties worden opgelost d.m.v. een intersection entity (dit wordt in het databasemodel een intersection table of koppeltabel). Deze tabel zal foreign keys bevatten die gelinkt zijn aan de originele tabellen
85

n op n-relaties worden meestal opgelost door alle attributen van beide entiteiten onder te brengen in n tabel Zelden wordt gekozen om er twee aparte tabellen van te maken zoals in onderstaand voorbeeld. n van beide tabellen zal dan het foreign key-veld bevatten
86
Omzetting van super- en subtypes

Supertype implementatie
Er wordt gebruik gemaakt van n tabel Regels
Er wordt n tabel aangemaakt, onafhankelijk van het aantal subtypes De tabel bevat evenveel velden als het aantal attributen van de supertype-entiteit, met de originele optionaliteit De tabel krijgt voor elk attribuut uit de subtype-entiteiten een kolom, deze is altijd optioneel n verplicht veld is nodig om te kunnen bepalen van welk soort subtype de instantie is UIDs worden in het databasemodel primary en unique keys Relaties aan het supertype worden gewoon omgezet zoals in voorgaande slides werd uitgelegd Relaties aan het subtype worden omgezet naar optionele foreign key-velden

Salary en hourly rate zijn verplicht in het ERD, echter optioneel in het databasemodel. Daarom: extra te programmeren
Als epe-type=full time

Salary is not null Hourly rate is null Agy_id is null
Als epe-type=part time

Supertype implementatie
Vul zelf aan

88

Subtype implementatie
Er wordt gebruik gemaakt van evenveel tabellen als subtypes Regels
Er wordt een tabel aangemaakt per subtype Elke tabel bevat een veld voor elk attribuut uit het supertype met dezelfde optionaliteit De tabel krijgt voor elk attribuut uit het eigen subtype een veld met dezelfde optionaliteit De primary UID uit het supertype wordt een primary key in elke tabel. Secundary UIDs van het supertype worden unique keys in elke tabel Alle tabellen krijgen een foreign key-veld voor elke relatie met het supertype, met de originele optionaliteit Relaties aan een subtype worden enkel omgezet naar een foreign key in de tabel die hoort bij dat subtype (met originele optionaliteit)
89

Subtype implementatie
90

Welke keuze maken? Kiezen voor Supertype implementatie
De meeste attributen behoren tot het supertype De meeste relaties hangen aan het supertype
Kiezen voor Subtype implementatie

De subtypes hebben weinig kenmerken gemeenschappelijk Er zijn weinig supertype-attributen maar meerdere subtypeattributen De meeste relaties hangen aan de subtypes
91
Oefening 1
Geef de tabellen voor elke entiteit met de attributen die erbij horen. Zorg voor een goede tabelnaam en afkorting tussen haakjes. Geef aanduidingen van primary key, unique key, foreign key, verplicht, optioneel.
92

Database Design 20120423

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Database Design 20120423

Uploaded by

Copyright:

Available Formats

Databases 1

Wilfried Wuyts & Kristof Nuyts

Deel 2: van ERD naar databasemodel

Databases 1 Database Design

Data versus informatie

Databases 1 Database Design

Data versus informatie

Databases 1 Database Design

Deel 1: ontwerp van een ERD

Deel 1: ontwerp van een ERD

Databases 1 Database Design

Databases 1 Database Design

Er zijn veel entiteiten

Databases 1 Database Design

Databases 1 Database Design

Een attribuut is een bepaald stukje informatie

Databases 1 Database Design

Databases 1 Database Design

UIDs kunnen een attribuut zijn of een combinatie van attributen

Databases 1 Database Design

Databases 1 Database Design

Databases 1 Database Design

Databases 1 Database Design

Databases 1 Database Design

Databases 1 Database Design

Databases 1 Database Design

SONG # songID * title * duration * artist songwriter

Databases 1 Database Design

Databases 1 Database Design

4. Naam van de relatie 5. Kardinaliteit

Databases 1 Database Design

DIER GEWERVELDE ONGEWERVE LDE

Databases 1 Database Design

Soms kan een extra subtype OTHER handig zijn

Databases 1 Database Design

Procedural business rules: geven workflow of businessgerelateerde processen aan

Databases 1 Database Design

Structural business rules

TEACHER # id * name * address * Teaching certificate number

Databases 1 Database Design

Procedural business rules

Databases 1 Database Design

Niet-transfereerbare relaties (ruit op de relatie / diamond)

Databases 1 Database Design

Databases 1 Database Design

Databases 1 Database Design

Databases 1 Database Design

Databases 1 Database Design

Databases 1 Database Design

Veel op veel-relaties oplossen

Databases 1 Database Design

Veel op veel-relaties oplossen

Veel op veel-relaties oplossen

Databases 1 Database Design

Veel op veel-relaties oplossen

Databases 1 Database Design

Databases 1 Database Design

Databases 1 Database Design

Databases 1 Database Design

Het is ook mogelijk om een artificieel UID te gebruiken

Databases 1 Database Design

n primary UID (studentID) en twee secundary UIDs

ERD : Database model :

Unique identifiers Primary keys