Opleiding AI cursus Databases Tweede college Donderdag 17 februari 2004 Drs. F. de Vries

Database ontwerp & normalisatie Rolland, “The Essence of Databases”, Hoofdstuk 4

Database ontwerp Ontwerp van een conceptueel database schema Top-down benadering. E/R model stapsgewijs transformeren naar database schema. Bottum-up benadering. Normalisatie van gegevensbestanden naar een efficiënte structuur.

Van E/R model naar database schema Creëer een E/R model. Transformeer in 8 stappen naar een verzameling relaties met specificatie van attributen, domeinen en sleutels. Controleer op “normalisatie”.

Stap1: sterke entiteiten Voor elke sterke entiteit: Maak een ‘base-relation’ met de naam van die entiteit, Maak een kolom voor elk (eenvoudig) attribuut, Het sleutelattribuut van de entiteit wordt de primaire sleutel van de tabel.

E/R model: (sterke) entiteiten Entiteiten-Relatie model van Peter Chen (1976) (Ook wel EAR = entiteiten – attributen – relaties) Meest bekende model van de drie Entiteit = “items in the real world that are capable of a unique existence” [ je kunt ook zeggen: een abstractie, waarvan instanties te maken zijn..] Voorbeeld: bank, Klant, Rekening Afbeelding: box met naam ENTITEIT in hoofdletters Attribuut = eigenschappen van de entiteit Afbeelding: ovaal met naam met hoofdletter Onderstreping: sleutel Evt gecombineerde sleutel mogelijk Relatie = benoemde verbinding tussen entiteiten

Stap 2: zwakke entiteiten Voor elke zwakke entiteit: Maak een ‘base-relation’ met de naam van die entiteit, Maak een kolom voor elk (eenvoudig) attribuut, Voeg – als verwijssleutel(s) – de(het) sleutelattribu(u)t(en) toe van de entiteit(en) waarvan deze zwakke entiteit afhangt, De primaire sleutel wordt de verzameling van deze verwijssleutels.

E/R model : zwakke entiteit Relaties die zelf entiteit kunnen worden: [ vgl associatieklasse bij UML] Voor elke rekening van elke klant wordt een registratie vastgelegd, deze is uniek voor de combinatie klant-rekening Deze kan zelf eigenschappen hebben: datum Dit is een zwakke entiteit, omdat deze alleen bestaat bij de gratie van een rekening en een klant Let op: de cardinaliteit wordt opgesplitst in 2 keer 1-op-m Afbeelding: dubbele box

Stap 3: 1-M relaties Voor elke 1-M relatie: Voeg in de M-relatie een extra kolom toe die – als verwijssleutel – het verband representeert. Gebruik de naam van het verband als kolomnaam. Het domein van deze kolom (de verwijssleutel-waarden) moet zijn: de verzameling van primaire sleutelwaarden uit de tabel waarnaar verwezen wordt.

E/R model: 1:M relatie Relatie Benoemde verbinding tussen entiteiten [naam leest 1 kant op: bank behandelt rekeningen, maar niet: rekening behandelt bank, zie volgende sheet?!? ..] Cardinaliteit: 1-op-m, wel twee kanten op lezen Bank behandelt meerdere accounts – een account hoort bij slechts 1 bank

Stap 4: 1-1 relaties Voor elke 1-1 relatie: Maak een kolom in één relatie (en ook echt maar in één!) die de verwijzing representeert. Aan beide zijden leidt tot dataredundantie !!! Deze kolom bevat een verwijssleutel naar de relatie waarmee het verband bestaat. Bij voorkeur verwijssleutel opnemen in de entiteit met de (meest) volledige deelname, Voorkomt een overdaad aan NULLs. Gebruik de naam van het verband als kolomnaam.

x Recursieve relatie: Supervisie relatie: Elke werknemer heeft supervisie = een baas Managed-by relatie: bank-werknemer 1-op-1 manager Wat is er nog niet uitgedrukt: de manager van een set werknemers = de manager van de bank Dit wordt opgelost met Enhanced ER model, Dmv subtyping en verfijningen ervan

Stap 5: M-N relaties Voor elke M-N relatie: Maak een nieuwe tabel die het verband representeert. Voeg als kolommen verwijssleutels toe naar de bijbehorende relaties. De primaire sleutel wordt de verzameling van deze verwijssleutels. Voeg eventuele attributen van het verband toe als kolommen aan deze tabel.

E/R model : M:N relatie Cardinaliteit: m-op-n, twee kanten op lezen: 1- een klant kan meerdere rekeningen hebben 2- een rekening kan door meerdere klanten gedeeld worden [ Let op: Dit leest niet goed: account-handles-bank Een rekening wordt behandeld door een bank < is handled by> zou mooier zijn ] Cardinaliteit: 1-op-1: voorbeeld [ niet op de sheet] Een bankafdeling heeft 1 manager, en elke manager behoort bij 1 en slechts 1 bankafdeling

Stap 6a: Multi-valued attributen Voor elk multi-valued attribuut: Maak een ‘base-relation’ met de naam van het verband. Voeg verwijssleutel naar de bijbehorende entiteit toe. Maak een kolom voor het attribuut. De primaire sleutel bestaat uit de combinatie van verwijssleutel en attribuut.

Stap 6b: Samengestelde attributen Voor elk samengesteld attribuut: Maak, in plaats van een kolom met de naam van het samengestelde attribuut, een stel kolommen met namen van de samenstellende attribuut-delen.

Stap 7: n-ary relations Voor elke n-ary relation: Maak een ‘base-relation’ met de naam van het verband. Voeg verwijssleutels toe naar de bijbehorende relaties. De primaire sleutel wordt de verzameling van deze verwijssleutels. Voeg eventuele attributen van het verband toe als kolommen aan deze tabel. N.B.: Dit kan eenvoudiger als er 1-1 of 1-M verbanden bestaan!

x Wordt hier gebruikt: specialiseren van werknemers EMPLOYEE in gewone = EMP en speciale = MANAGER [ let ook weer op de leesrichting: niet: bank-employed at- employee, maar andersom] Opgelost: nu is de manager ook degene met de supervisie Let ook op de ternary (drie-heid) relation

Stap 8: Subtype relaties Voor elke sub-type relatie: Als het subtype een subset is met een specifieke attribuutwaarde: Gebruik een view. Als het subtype nieuwe attributen heeft: Maak een nieuwe ‘base-relation’ voor het sub-type. Voeg een verwijssleutel toe naar het supertype van deze relatie. Dit is tevens de primaire sleutel van deze relatie. Voeg kolommen toe met de attributen van dit sub-type

E-E/R model: subtyping Subtyping: specialisatie en generalisatie van entiteiten

Par 4.2 Normalisatie

Doel normalisatie Ontwikkelen van een verzameling van relationele tabellen met “wenselijke eigenschappen” gegeven de betekenis van de gegevens in de organisatie. Meestal uitgevoerd als een serie tests op een relationele tabel. Belangrijk doel bij ontwerp van een relationele database is het minimaliseren van redundantie in de gegevens. Normalisatie bewerkstelligt dit. Redundantie leidt tot: onderhoudsproblemen (update anomalies). verspilling van opslag capaciteit.

Normalisatie onderwerpen Doel van normaliseren. problemen bij tabellen in niet-normaalvorm. Het begrip “Functionele afhankelijkheid”. Het normalisatie-proces. 1e normaalvorm (1NF), 2e normaalvorm (2NF), 3e normaalvorm (3NF) en de Boyce-Codd normaalvorm (BCNF), (4e normaalvorm (4NF) en 5e normaalvorm (5NF).)

ER modellering  Normalisatie ER modellering: top-down benadering. Normalisatie: meer bottum-up (vanuit de bestaande datastructuren). of als aanvullende check op een relationeel model afgeleid uit ER-modellering.

Voorbeeld gegevens redundantie

Update anomalies Toevoegen: staflid toevoegen  branch gegevens toevoegen (dupliceren?). Weghalen: laatste staflid van een afdeling weg?  afdelingsgegevens weg. Veranderen: tel_no van afdeling wijzigen  mogelijk vele plaatsen wijzigen (inconsistenties!).

Normalisatie intuïties (zoveel mogelijk) voorkomen van redundantie. kleine tabellen met steeds betekenisvol samenhangende attributen (ER-modellering leidt “vanzelf” tot RDB in 3e normaalvorm!). decomponeren van tabellen in deeltabellen: zodat zonder verlies oorspronkelijke tabel gereproduceerd kan worden. zonder dat afhankelijkheden tussen attributen verloren raken.

Decompositie van tabellen Zonder verlies van gegevens (nonloss-decomposition) Met verlies van gegevens

Afhankelijkheden Normalisatie heeft alles met (functionele) afhankelijkheden tussen attributen te maken S#  STATUS S#  CITY STATUS  CITY

Functionele afhankelijkheden Centraal begrip bij normalisatie! Beschrijft relatie(s) tussen attributen in een relatie. Voorbeeld: ALS R(A,B) waarin A en B verzamelingen van attributen van de relatie R voorstellen, DAN is B functioneel afhankelijk van A als elke waarde van B eenduidig vastligt vanuit de waarden voor A.

Functionele afhankelijkheid Functioneel want: de eenduidigheid van het reaultaat hangt af van de betekenis van de attributen! Notatie: determinanten van de functionele afhankelijkheid links van de pijl. Een functionele afhankelijkheid is een M:1 relatie tussen twee verzamelingen attributen.

Voorbeeld functionele afhankelijkheid

Functionele afhankelijkheden -Vb 1) {S#, P#}  {QTY} 2) {S#, P#}  {CITY} 3) {S#, P#}  {CITY, QTY} 4) {S#, P#}  {S#} 5) {S#, P#}  {S#, P#, CITY, QTY} 6) {S# }  {CITY} 7) {S# }  {QTY} 8) {QTY }  {S#} 9) … …  … … 4) is triviale afhankelijkheid (oninteressant) 5) Moet zo zijn als {S#, P#} primaire sleutel zijn 7) & 8) zijn “toevallig” (niet functioneel) 2) is redundant t.o.v. 6) [en 1) t.o.v. 7), maar de laatste is “toevallig”]

1e normaalvorm (1NF) Elke “cel” bevat precies één waarde 0NF  1NF: door toevoegen van extra tuples of door de zich herhalende groep(en) in een aparte tabel te zetten

Bestand in 0NF

Voorbeeld 0NF  1NF  extra tuples, duplicering van studentnummer en naam afsplitsing van tabel 

2e normaalvorm (2NF) Een relatie is in de 2e normaalvorm als: de tabel is in de 1e normaalvorm EN elk (niet-sleutel)attribuut is volledig functioneel afhankelijk van de volledige primaire sleutel. 1NF  2NF: afsplitsen van de attributen die afhangen van een gedeelte van de primaire sleutel in een aparte tabel.

Voorbeeld 1NF  2NF

3e normaalvorm (3NF) Een relatie is in de 3e normaalvorm als: de tabel in de 2e normaalvorm is EN elk (niet sleutel-)attribuut is volledig functioneel ONafhankelijk van alle overige attributen (m.a.w. er is géén indirecte sleutelafhankelijkheid) 2NF  3NF afsplitsen van de indirect afhankelijke attributen in een aparte tabel

Voorbeeld 2NF  3NF

Boyce-Codd normaalvorm (BCNF) Tot nu alleen gekeken naar afhankelijkheden met de primaire sleutel (d.w.z. geen gedeeltelijke afhanke-lijkheden en geen indirecte afhankelijkheden) Maar zulke afhankelijkheden kunnen er ook bestaan met andere kandidaat sleutels (als ze er zijn!). Een relatie is in de BCNF normaalvorm als:alle determinanten zijn minimaal kandidaat-sleutels … geen afhankelijkheden meer van niet sleutels.

3NF !! ; BCNF ?? Client_No + IDate  ITime, Staff_No, Room Staff_No +IDate + ITime  Client_No, Room Room + IDate + ITime  Client_No, Staff_No Staff_No + IDate  Room

3NF  BCNF 

Nogmaals 3NF !! ; BCNF ?? Veronderstel: Dan: voor elke cursus en voor elke student geldt dat deze cursus voor hem door slechts één docent onderwezen worden; elke docent geeft slechts één cursus. Dan: Student + Cursus  Docent Docent  Cursus Student Cursus Docent

Nogmaals 3NF !! ; BCNF ?? Wel in 3NF, maar niet in BCNF want er zijn 2 kandidaat-sleutels: Student + Cursus Student + Docent en ... Cursus wordt al gedetermineerd door Docent alleen ... Problemen: o.a. als je ‘de Boer’ bij `MCI’ weghaalt Student Cursus Docent

BCNF Maar … … toevoegen: Smid + de Vries mag niet! Want de Vries geeft MCI en dat krijgt Smid al van docent Wielinga … … Deze afhankelijkheid wordt echter niet meer afgedwongen! (is verloren geraakt).

BCNF altijd wenselijk? Soms bestaat er een functionele afhankelijkheid die verloren raakt … Dan een keuze maken tussen twee “kwaden”: redundante informatie mogelijk verlies van een functionele (betekenisvolle ?) afhankelijkheid bijvoorbeeld: {Room#, Int_date, Int_Time}  {Staff#, Client#}

Relaties uit het boek

Normaliseren Par 4.2 p.72-85

ongenormaliseerd

1 NF

2NV  3NV

3NV

Hoe zoek je een order voor een rekening bij elkaar? - door orders en orderregel te vermenigvuldigen - en op een ordernummer te selecteren, bv O1 - je krijgt dan een tabel met twee tuples met stocknr S1 en S2 - deze vermenigvuldig je met de tabel stock, - je krijgt dan een invulling van s1 en s2 Je kunt in deze tabel een nieuwe kolom maken met bedrag = sprice * hoeveelheid Je kunt de bedragen optellen

Voorbeeld vereisten Rock Solid banking Corporation heeft de volgende vereisten opgesteld: Elke rekening bij de bank heeft: klantgegevens (referentienr, naam, adres, status), een rekeningnummer, bedrag (balance) 2. Er zijn 2 soorten rekeningen: spaarrekening (deposit) en betaalrekening (current) 3. Klanten mogen meerdere rekeningen hebben 4. Een rekeningnummer is uniek 5. Rekeningen kunnen door klanten gedeeld worden 6. Elke klant heeft een uniek referentienummer 7. Elke rekening hoort bij 1 afdeling van de bank 8. Afdelingsgegevens van de bank (naam, adres, manager) 9. De naam van de bankafdeling is uniek