Normalisatie Relationeel databaseontwerp: voorkom redundatie, want dat geeft problemen bij toevoegen bij wijzigen bij verwijderen ER diagram lost veel op in ontwerpen Normalisatie, kijken naar afhankelijkheden - nog dingen over het hoofd gezien? - bij analyseren bestaande oude database

Sleutels Superkey set attributen die de rest bepaalt Sleutel minimale set attributen die de rest bepaalt Primaire sleutel de sleutel die je kiest als identificatie van entiteiten uit je tabel Alternatieve sleutel andere mogelijke sleutels van je tabel

Normalisatie: 1e normaalvorm Het verwijderen van velden die niet atomair zijn (bv een veld ‘auteurs’ of ‘hobbies’) is de eerste stap naar normalisatie, De volgende stappen zorgen dat eventuele redundantie in de gegevens verdwijnt, ze houden zich bezig met informatieve attributen (die zelf niet tot een sleutel behoren).

Opsplitsen van tabellen: NV 1 Pas op dat je geen informatie kwijtraakt: Stel je hebt tabel {AuID, AuName, meerdere ISBNs} Voor NV1 moet de tabel gesplitst. Splits dan niet in {AuID, AuName} en {AuName, ISBN} Want AuID is de echt unieke sleutel, er kunnen twee Auteurs met dezelfde naam voorkomen! De juiste oplossing: {AuID, AuName} en {AuID, ISBN}

Functionele afhankelijkheid X Y Een attribuut Y is functioneel afhankelijk van een ander attribuut X als er voor elke waarde van X slechts één waarde van Y is Twee records met gelijke X hebben dus gelijke Y Voor X en/of Y mag je ook lezen: set van attributen!

2e normaalvorm Stel je hebt een tabel van woningen om waarde te bepalen: Woning : Woonpl, Straat, Huisnummer, Aantal kamers, Grootte woonpl Wat is de primaire sleutel voor de woning? Grootte woonplaats is afhankelijk van slechts een deel van deze sleutel: Woonpl Grootte woonpl Het attribuut geeft geen informatie over de entiteit (woning) Dit geeft redundantie van gegevens Een informatief (niet-sleutel) attribuut moet functioneel afhankelijk zijn van de gehele sleutel.

Oplossing voor 2 NV Maak een aparte tabel voor de functionele afhankelijkheid, dus: Woning: Woonpl, Straat, Huisnummer, Aantal kamers Plaatsgrootte: Woonpl, Grootte

3e normaalvorm Stel je hebt een tabel Boek: Titel, PubID, Aantal pagina’s, Prijs stel nu dat de prijs door het aantal pagina’s bepaald wordt. Aantal pagina’s Prijs dan heb je weer redundantie Een informatief attribuut mag alléén functioneel afhankelijk zijn van de sleutel, oftewel: geen transitieve afhankelijkheden. Hoe zou je de prijs kunnen verwerken in deze database?

NV 1, 2 en 3 NV1 NV2 NV3 NV2 en 3 samengevat: Elk veld bevat slechts één waarde, is atomair NV2 Niet-sleutel attributen (=zuiver informatieve attributen) kunnen niet afhankelijk zijn van een deel van de sleutel NV3 Niet-sleutel attributen zijn alleen afhankelijk van de sleutel NV2 en 3 samengevat: Elk niet-sleutelattribuut is alleen afhankelijk van de volledige sleutel.

Boyce-Codd Normaalvorm BCNF Stel je hebt de tabel Lokatie: Stad, Straat, Huisnr, Postcode Twee mogelijke (alternatieve) sleutels voor een unieke lokatie: Stad, Straat, Huisnr en Postcode, Huisnr dus geen enkel attribuut is zuiver informatief Meerdere afhankelijkheden: Stad, Straat, Huisnr Postcode Postcode Stad, Straat BCNF: Bij iedere functionele afhankelijkheid moet links een sleutel staan (geldt dus niet alleen voor afhankelijke niet-sleutelattributen) Oplossing?

Oplossing Twee afzonderlijke tabellen: Lokatie{Postcode, Huisnr} Postcode{Postcode, Stad, Straat} en gebruik je een LokID voor lokatie: Lokatie{LokID, Postcode, Huisnr} Postcode+huisnr blijft dan een alternatieve sleutel voor lokatie: combinatie moet ook uniek zijn.

Tot slot - 1 Normalisatie is essentieel in database ontwerp, het voorkomt redundantie en de bijbehorende problemen, werkt efficient en spaart veel geheugen en diskruimte door “lossless decomposition” oftewel: opsplitsing zonder dataverlies maar er zijn nog steeds situaties denkbaar waarin redundantie problemen en “update anomalies” of “delete anomalies” ontstaan die niet via normalisatie zijn op te lossen. Chris Date: “Most of database design is still an art, not a science” (uit: Whitehorn & Marklyn 2001)

Tot slot -2 Normalisatie is essentieel in database ontwerp, maar in grote toepassingen worden bepaalde opsplitsingen soms bewust achterwege gelaten om de performance (snelheid, efficiëntie) van het systeem te verbeteren (geen join nodig). voorbeeld: wel hele adres I.p.v. de opsplitsing om de regels bewust te kunnen overtreden moet je ze wel eerst kennen en goed kunnen toepassen!