Databasenormalisatie
Databasenormalisatie is een hulpmiddel bij het ontwerpen van gegevensbanken. Oorspronkelijk begonnen als noodzaak om data in een database te kunnen opslaan in het beperkte geheugen van de toenmalige computers, heeft databasenormalisatie zijn eigen rechtvaardiging gekregen.
Door herhaalde gegevens in een tabel apart op te slaan in een gerelateerde tabel is het mogelijk niet alleen het dubbel opslaan van gegevens te vermijden, maar vooral ook is het mogelijk foute verdubbelingen te voorkomen. Zo kunnen plaatsnamen bij adresgegevens in een aparte tabel opgenomen worden waardoor verkeerde spelling vermeden kan worden. Maar ook kunnen naam-, adres- en woonplaatsgegevens (NAW) apart opgeslagen worden van order- of abonnementsgegevens. Hierdoor kan vermeden worden dat een klant of abonnee twee gelijke rekeningen krijgt voor een eenmalig afgenomen product.
Inhoud |
[bewerken] Relationele databanken
Relationele databases maken het mogelijk gegevens in een tabel dwingend te koppelen aan een andere tabel. Dit gebeurt door de database-engine en er is geen bijzondere code voor nodig.
[bewerken] Normaalvormen
Er zijn vele manieren om overbodige gegevens (redundantie) te beperken (dit is een database normaliseren). Deze oplossingen noemt men normaalvormen. Een normaalvorm is een fase in het ontwerp van een relationele database waarbij in stappen naar een verantwoorde wijze van gegevensopslag wordt toegewerkt. Belangrijke punten hierbij zijn het voorkomen van dubbele opslag van gegevens (redundantie) en dat elke regel in elke tabel met behulp van een unieke identificatie opgevraagd kan worden. Elke normaalvorm stelt bepaalde eisen aan de manier waarop de gegevens zijn opgeslagen (zoals eisen aan de geldende functionele afhankelijkheden).
Er zijn meerdere normaalvormen bekend, maar de meest gebruikte zijn de zogenaamde eerste, tweede, derde en vierde normaalvorm. De gegevens staan in een bepaalde normaalvorm wanneer aan een aantal voorgeschreven voorwaarden voldaan is. Gegevens staan bijvoorbeeld in de tweede normaalvorm als en slechts als ze voldoen aan de eerste normaalvorm en aan een aantal extra regels.
Ted Codd formuleerde het idee van normalisatie in A Relational Model of Data for Large Shared Data Banks[1] in 1970.
- There is, in fact, a very simple elimination* procedure which we shall call normalization. Through decomposition nonsimple domains are replaced by "domains whose elements are atomic (nondecomposable) values."
- * Zijn term elimineren is enigszins misleidend: er gaat geen informatie verloren tijdens normalisatie; hij doelde waarschijnlijk op de wiskundige betekenis van het elimineren van complexiteit of redundantie
De eerste drie normaalvormen (1NF, 2NF en 3NF) werden gedefinieerd door Codd in Further normalization of the Data Base Relational Model [2]
Alle genormaliseerde gegevens staan minstens in 1NF. Sommige gegevens staan ook in 2NF, sommige zelfs in 3NF. Codd gaf aan dat gegevens in 2NF wenselijker waren dan deze in 1NF, 3NF was nog wenselijker. 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 herbekeken en versterkt door Boyce en Codd in Recent Investigations into Relational Data Base Systems [3]. 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 versterking van de voorwaarden van de oude 3NF.
Later introduceerde Ron Fagin nog enkele sterke normaalvormen. In Multivalued Dependencies and a New Normal Form for Relational Databases[4] definieerde hij een nieuwe vierde normaalvorm (in die tijd werd de latere BCNF nog steeds de derde normaalvorm genoemd). In Normal Forms and Relational Database Operators[5] definieerde hij nog een nieuwe normaalvorm, de projection-join normal form (PJ/NF) of vijfde normaalvorm.
[bewerken] Niet-genormaliseerde gegevens
Ieder niet gestructureerd gegevensbestand is in de nulde normaalvorm (0NF) of niet-genormaliseerd. Gegevens van verschillende soorten kunnen op elke regel voorkomen, bijgevolg kunnen deze niet in kolommen worden opgedeeld.
Een voorbeeld:
verg. BRZZ, laptop mee ! di: combi naar garage Jos jarig ?
[bewerken] Eerste normaalvorm (1NV)
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 geen twee telefoonnummers bevatten); indien een attribuut meerdere waarden bevat zouden deze waarden in een andere tabel moeten worden ondergebracht.
- geen enkel attribuut wordt herhaald
- alle attributen blijven constant in de tijd
- Een voorbeeld, uit het personeelsbestand van een fictief bedrijf:
Tabel: Personeel Naam Straat Nr Plaats Afdeling Schaal Salaris P.Jansen Stationsweg 14 Venlo Boekhouding 2 1503 W.de Vries 't Steegke 23 Epe Kantine 1 1245 T.Oud Dorpsstraat 1 Ons Dorp Boekhouding 3 1789
[bewerken] Tweede normaalvorm (2NV)
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.
- voldoet aan de eerste normaalvorm
- alle niet-sleutelattributen zijn functioneel totaal afhankelijk van de primaire sleutel.
[bewerken] Derde normaalvorm (3NV)
Een relatie is in 3NF indien ze in 2NF is en geen transitieve afhankelijkheid kent.
- voldoet aan de tweede normaalvorm
- alle attributen die niet tot een sleutel behoren hangen niet af van een niet-sleutelattribuut
[bewerken] Boyce-Codd-normaalvorm (BCNV)
Een relatie is in BCNF (Boyce-Codd Normal Form) als elke determinant een kandidaatsleutel is.
- voldoet aan de derde normaalvorm
- er zijn geen transitieve afhankelijkheden.
[bewerken] Vierde normaalvorm (4NV)
Een relatie is in 4NF als ze in BCNF staat en geen meerwaardige afhankelijkheden kent.
- voldoet aan de Boyce-Codd-normaalvorm
- bevat geen enkele meervoudige functionele afhankelijkheid
[bewerken] Vijfde normaalvorm (5NV)
- voldoet aan de vierde normaalvorm
- elke afhankelijkheid bevat een sleutel voor de relatie
[bewerken] Referenties
- ↑ Codd, E.F., A Relational Model of Data for Large Shared Data Banks, in Communications of the ACM 13 (6), pp 377-387, juni 1970
- ↑ Codd E.F., Further normalization of the Data Base Relational Model in Rustin, Randall J. (ed.), Data Base Systems, Courant Computer Science Symposia Series 6. Englewood Cliffs, N.J., Prentice-Hall, 1972
- ↑ Codd, E.F., Recent Investigations into Relational Data Base Systems, Proc. IFIP Congress, Stockholm, 1974
- ↑ Fagin, R., Multivalued Dependencies and a New Normal Form for Relational Databases, ACM Transactions on Database Systems 2 (3), sept 1977
- ↑ Fagin, R., Normal Forms and Relational Database Operators, ACM SIGMOD International Conference on Management of Data, May 31-June 1, 1979, Boston, Mass.
[bewerken] Zie ook
| Databanken | ||||||||
|---|---|---|---|---|---|---|---|---|
|
Databasemanagementsysteem · Databankmodel · Databasenormalisatie · Referentiële integriteit · Relationele algebra · Relationele database · Relationeel model
|
