Databasenormalisatie is een techniek bij het ontwerpen van databases. Ze dient twee doelen: het spaarzaam omgaan met opslagruimte en het vermijden van meervoudig vastleggen van dezelfde gegevens. Bij het normaliseren dient men zich er bewust van te zijn dat er geen informatie verloren gaat. Er bestaan algoritmen die deze normaalvormen automatisch uitwerken voor een willekeurige database. Het meervoudig vastleggen van dezelfde gegevens wordt redundantie genoemd en is een mogelijke bron van fouten.
De techniek van databasenormalisatie wordt in het bijzonder gebruikt in relationele databases. Het woord relationeel geeft aan dat de relatie tussen de gegevens deel uitmaakt van de database. In computerdatabases worden de relaties tussen de gegevens door een software-tussenlaag beheerd, door het RDBMS.
Geschiedenis Ted Codd formuleerde het idee van normalisatie in A Relational Model of Data for Large Shared Data Banks, A Relational Model of Data for Large Shared Data Banks, in Communications of the ACM 13 (6), pp 377-387, juni 1970 in 1970.
De eerste drie normaalvormen (1NF, 2NF en 3NF) werden gedefinieerd door Codd in Further normalization of the Data Base Relational Model., Further normalization of the Data Base Relational Model in (ed.), Data Base Systems, Courant Computer Science Symposia Series 6. Englewood Cliffs, N.J., Prentice-Hall, 1972 Alle genormaliseerde gegevens staan minstens in 1NF. Sommige gegevens staan ook in 2NF, sommige zelfs in 3NF. Codd gaf aan dat gegevens in 2NF de voorkeur kregen boven deze in 1NF, maar dat 3NF nog geschikter was. De ontwerper van de database zou dus moeten streven naar gegevens in 3NF.
Codds oorspronkelijke definitie van 3NF bleek later niet volmaakt. De definitie werd herzien en door Boyce en Codd in hun Recent Investigations into Relational Data Base Systems verbeterd., Recent Investigations into Relational Data Base Systems, Proc. IFIP Congress, Stockholm, 1974 Gegevens in 3NF in deze nieuwe definitie voldeden ook aan de oude definitie, maar gegevens die aan 3NF voldeden volgens de oude definitie voldeden niet noodzakelijk aan de nieuwe. De nieuwe definitie was dus sterker dan de oude en werd later de Boyce-Codd-normaalvorm genoemd als een verbetering van de voorwaarden van de oude 3NF. De Boyce-Codd-normaalvorm telt nog wel als 3NF.
Ron Fagin introduceerde later nog twee keer een sterkere normaalvorm. In Multivalued Dependencies and a New Normal Form for Relational Databases, Multivalued Dependencies and a New Normal Form for Relational Databases, ACM Transactions on Database Systems 2 (3), sept 1977 definieerde hij de vierde normaalvorm en in Normal Forms and Relational Database Operators, Normal Forms and Relational Database Operators, ACM SIGMOD International Conference on Management of Data, May 31-June 1, 1979, Boston, Mass. definieerde hij nog een nieuwe normaalvorm, de projection-join normal form (PJ/NF) of vijfde normaalvorm.
Normaalvormen thumb|Hiërarchie van normaalvormen
Er bestaan verschillende normaalvormen, waarbij in de eerste normaalvorm (1NF) de eenvoudigste variant is en de vijfde (5NF) de meest complexe. Hoe hoger de normaalvorm, hoe meer eisen er gesteld worden aan het ontwerp. Wanneer aan geen van de eisen voldaan is spreekt men van 0NF. De database is dan dusdanig slecht ontworpen dat deze in de praktijk beperkt bruikbaar is.
De verschillende normaalvormen zijn: 1e Normaalvorm (1NF) 2e Normaalvorm (2NF) 3e Normaalvorm (3NF) Boyce-Codd-Normalform (BCNF) 4e Normaalvorm (4NF) 5e Normaalvorm (5NF) Waarvoor geldt: .
De normalisatie leidt ertoe dat elke regel in elke tabel met behulp van een unieke identificatie, een index of sleutel, kan worden opgevraagd. Elke normaalvorm stelt daartoe bepaalde eisen aan de manier waarop de gegevens zijn opgeslagen, zoals eisen aan de geldende functionele afhankelijkheden. De gegevens staan in een bepaalde normaalvorm wanneer aan een aantal voorgeschreven voorwaarden voldaan is. Gegevens staan bijvoorbeeld in de tweede normaalvorm dan en slechts dan als ze aan de eerste normaalvorm voldoen en aan een aantal extra regels.
Bij 1NF worden de gegevens in een of meer tabellen opgeslagen, maar men maakt zich niet druk om de structuur, niet om de gebruikte schijfruimte en ook niet over het feit dat een gegeven meermaals is opgeslagen. Bij 5NF is weer sprake van het tegenovergestelde, elk gegeven is maar één keer opgeslagen en er wordt zo weinig mogelijk schijfruimte gebruikt. Bij 5NF zijn de data voor een gebruiker lastiger te doorzoeken. Vaak wordt voor een tussenvorm gekozen, namelijk de 3NF.
Denormalisatie is het omgekeerde van datanormalisatie en wordt toegepast om de hoeveelheid disktoegang te beperken.
Redenen Om te normaliseren bestaan verschillende redenen en bij de keuze tot een bepaalde normaalvorm zal altijd een afweging gemaakt worden, maar de keuze hangt sterk samen met de complexiteit van de data. Zoals eerder gesteld is 1NF de minimale vereiste voor een bruikbare database. Problemen die men door middel van een hogere normaalvorm voorkomt zijn: Update-anomalie: Wanneer dezelfde gegevens op meer plekken worden opgeslagen dan zal dit bij een aanpassing ook op meer plaatsen moeten gebeuren. Als het adres van een klant in vijf tabellen opgeslagen is dan kan men dit bij een adreswijziging zomaar op vier plekken aanpassen en vergeten dat er nog een vijfde plek is. Er is dan sprake van een update-anomalie. Insert-anomalie: Bij een slecht ontworpen database kan men tegen het probleem aanlopen dat een gegeven pas ingevoerd kan worden wanneer ook andere gegevens bekend zijn. Bijvoorbeeld, als de verkoopgegevens en de klantgegevens in dezelfde tabel staan dan kan een klant pas opgevoerd worden wanneer deze ook al iets besteld heeft. Omgekeerd geldt hetzelfde, een nieuw product kan pas opgevoerd worden als het al door iemand besteld is. Verwijder-anomalie: Dit probleem draagt het probleem van de vorige anomalie in zich. Het verwijderen van een product kan leiden tot het verwijderen van klanten.
Ook het beperken van schijfruimte en efficiënt gebruik van rekenkracht kunnen een reden zijn. Deze dragen echter geen fouten in zich mee. Een zoekopdracht die wat langer duurt zal immers niet tot foute resultaten leiden.
Nulde normaalvorm (0NF) Ieder ongestructureerd gegevensbestand is in de nulde normaalvorm (0NF) oftewel niet-genormaliseerd. Gegevens van verschillende soorten kunnen op elke regel voorkomen, waardoor deze niet in kolommen kunnen worden opgedeeld en de data niet goed te doorzoeken zijn.
Voorbeeld Cd van Anastacia met de titel Not That Kind uit 2000 heeft de nummers Not That Kind, I’m Outta Love Wish You Were Here van Pink Floyd met Shine On You Crazy Diamond, uitgebracht in 1975 Pink Floyd is actief sinds 1965 en Anastacia zingt pas vanaf 1999
Ook wanneer de gegevens in een tabel worden gezet kan er nog steeds sprake zijn van 0NF, zoals hieronder te zien is. De gegevens zijn niet atomair want in de kolom Album worden zowel het album, het verschijningsjaar als het jaar van het eerste optreden genoemd. En de kolommen zijn niet uniek want de kolom Track komt wel drie keer voor.
+ Cd_Lied Album Verschijningsjaar Track Track Track Anastacia (1999) – Not That Kind 2000 Not That Kind I’m Outta Love Cowboys & Kisses Pink Floyd (1965) – Wish You Were Here 1975 Shine On You Crazy Diamond Anastacia (1999) – Freak of Nature 2001 Paid my Dues
Eerste normaalvorm (1NF) Elke tabel met gegevens die voldoet aan de definitie van een relatie is in de eerste normaalvorm 1NF. Wanneer gegevens aan een relatie voldoen zijn ze dus reeds genormaliseerd.
elk attribuut is atomair, en bevat dus één enkele waarde (bijvoorbeeld een telefoonnummer-attribuut mag slechts een telefoonnummer bevatten); indien een attribuut meerdere waarden bevat zouden deze waarden in een ander attribuut moeten worden ondergebracht. geen enkel attribuut wordt herhaald alle attributen blijven constant in de tijd
Kortom, als alle data in een of meer tabellen zijn ondergebracht, is er al sprake van de eerste normaalvorm. Er is dan wel sprake van een vaste structuur voor de data, maar er is nog niet goed nagedacht over welke data in welke tabel komen. Alle data van een bedrijf zouden bijvoorbeeld in één platte tabel geplaatst kunnen worden. Bij een tabel waarin de aankopen van klanten worden bijgehouden, zou je dan bij elke aankoopregel ook het adres aantreffen, met als gevolg dat bij elke nieuwe aankoop ook het adres van de klant weer ingevoerd wordt, waardoor één adres wellicht honderden malen in de tabel opduikt.
Voorbeeld De gegevens van de platenzaak in 0NF:
+ Cd_Lied CD_ID Album Verschijningsjaar Track1 Track2 Track3 4711Anastacia (1999) – Not That Kind 2000 Not That Kind I’m Outta Love Cowboys & Kisses4712Pink Floyd (1965) – Wish You Were Here 1975 Shine On You Crazy Diamond Null Null 4713Anastacia (1999) – Freak of Nature 2001 Paid my Dues Null Null
Bovenstaande data staan weliswaar in een tabel, maar deze voldoet nog niet aan 1NF. Naam van de artiest en het eerste optreden staan samen in één kolom én voor de tracks zijn meerdere kolommen aangemaakt. Om te voldoen aan de 1NF zouden alle verschijningsjaren, artiesten en hun eerste optreden in een aparte kolommen en records moeten worden geplaatst en de tracks moeten onder elkaar in één kolom. Om het niet onnodig complex te maken, gaan we ervan uit dat een lied slechts op één cd voor kan komen en dat een cd slechts één artiest heeft.
+ Cd_Lied CD_ID Albumtitel Artiest Actief sinds Verschijningsjaar Track Single 4711 Not That Kind Anastacia 1999 2000 1 Not That Kind 4711 Not That Kind Anastacia 1999 2000 2 I’m Outta Love 4711 Not That Kind Anastacia 1999 2000 3 Cowboys & Kisses4712 Wish You Were Here Pink Floyd 1965 1975 1 Shine On You Crazy Diamond4713 Freak of Nature Anastacia 1999 2001 1 Paid my Dues
In bovenstaande tabel staan de data nu wel in 1NF. Voordeel: De data zijn nu door middel van een SELECT-statement te doorzoeken. Nadeel: Er kunnen zich de volgende problemen voordoen. Wanneer de naam van een cd gewijzigd moet worden, moet deze wijziging op verschillende regels worden uitgevoerd, wanneer een cd wordt opgevoerd maar de tracks zijn nog onbekend, dan kan dat alleen als in de kolom Track ook null-waarden worden toegestaan. Wanneer alle nummers van een cd verwijderd worden dan verdwijnt de hele cd uit de tabel.
Tweede normaalvorm (2NF) Een relatie is in 2NF als alle attributen die niet in de sleutel zijn opgenomen, functioneel afhankelijk zijn van de gehele sleutel (geen gedeeltelijke afhankelijkheid) . Een relatie met één attribuut als sleutel is automatisch in 2NF. Oftewel, repeterende attributen worden opgenomen in een aparte tabel.
voldoet aan de eerste normaalvorm alle niet-sleutelattributen zijn volledig functioneel afhankelijk van de primaire sleutel.
Voorbeeld Hieronder nogmaals de tabel in 1NF van de platenzaak.
+ Cd_Lied CD_ID Albumtitel Artiest Sinds Verschijningsjaar Track Single 4711 Not That Kind Anastacia 1999 2000 1 Not That Kind 4711 Not That Kind Anastacia 1999 2000 2 I’m Outta Love 4711 Not That Kind Anastacia 1999 2000 3 Cowboys & Kisses 4712 Wish You Were Here Pink Floyd 1965 1975 1 Shine On You Crazy Diamond 4713 Freak of Nature Anastacia 1999 2001 1 Paid my Dues
De kolommen met betrekking tot de albums (in roze) kunnen als repeterende attributen gezien worden. Om te voorkomen dat deze data meerdere malen opgeslagen (of gewijzigd) moeten worden, komen deze in een aparte tabel. In de tabel met de overige velden (de singles) komt een verwijzing naar de cd waar deze op staan.
+ Cd CD_ID Albumtitel Artiest Sinds Verschijningsjaar 4711 Not That Kind Anastacia 1999 2000 4712 Wish You Were Here Pink Floyd 1965 1975 4713 Freak of Nature Anastacia 1999 2001+ Lied CD_ID Track Single 4711 1 Not That Kind 4711 2 I’m Outta Love 4711 3 Cowboys & Kisses 4712 1 Shine On You Crazy Diamond 4713 1 Paid my Dues