Uit Wikipedia, de vrije encyclopedie Databasenormalisatie is een techniek bij het ontwerpen van databases. Ze dient twee doelen: het spaarzaam omgaan met opslagruimte en het vermijden van meervoudige vastlegging van dezelfde data, een potentiële bron van fouten.
1. Relationele databases
De techniek van databasenormalisatie wordt in het bijzonder gebruikt in relationele databases. Het woord “relationeel” geeft aan dat de relatie tussen de gegevens deel uit maakt van de database. In computerdatabases worden de relaties tussen de gegevens bewaakt door een software-tussenlaag, het RDBMS.
2. Normaalvormen
Hiërarchie van normaalvormen
Er bestaan verschillende manieren om dubbelingen uit databases te verwijderen, dit proces wordt normaliseren genoemd, de oplossingen noemt men normaalvormen. De normalisatie leidt ertoe dat elke regel in elke tabel met behulp van een unieke identificatie, een sleutel, 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.
2.1 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 ?
2.2 Eerste normaalvorm (1NV)
Elke tabel met gegevens die voldoet aan de definitie van een relatie is in de eerste normaalvorm (1NV). 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
Ter vergelijking: tabel uit het personeelsbestand van een fictief bedrijf in 0NF:
| Naam | Adres | Salaris | Afdeling |
|---|---|---|---|
| P.Jansen | Stationsweg 14 Venlo | Schaal 2: € 1503,00 | Boekhouding |
| W.de Vries | ’t Steegke 23 Epe | Schaal 1: € 1245,00 | Kantine |
| T.Oud | Dorpsstraat 1 Ons Dorp | Schaal 3: € 1789,00 | Boekhouding |
Diezelfde tabel uit het personeelsbestand van een fictief bedrijf in 1NF:
| Naam | Voorvoegsel | Initialen | Straat | Nr | Plaats | Afdeling | Schaal | Salaris |
|---|---|---|---|---|---|---|---|---|
| Jansen | NULL | P. | Stationsweg | 14 | Venlo | Boekhouding | 2 | 1503 |
| Vries | de | W. | ’t Steegke | 23 | Epe | Kantine | 1 | 1245 |
| Oud | NULL | T. | Dorpsstraat | 1 | Ons Dorp | Boekhouding | 3 | 1789 |
2.3 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 volledig functioneel afhankelijk van de primaire sleutel.
Een voorbeeld
Ter vergelijking: tabel uit het personeelsbestand van een fictief bedrijf in 1NF:
| Naam | Voorvoegsel | Initialen | Straat | Nr | Plaats |
|---|---|---|---|---|---|
| Jansen | NULL | P. | Stationsweg | 14 | Venlo |
| Vries | de | W. | ’t Steegke | 23 | Epe |
| Vries – Zeilstra | de | A. | ’t Steegke | 23 | Epe |
| Oud | NULL | T. | Dorpsstraat | 1 | Ons Dorp |
Diezelfde data uit het personeelsbestand van een fictief bedrijf in 2NF:
|
|
Het attribuut Adres_ID is nu een vreemde sleutel die verwijst naar de primaire sleutel in de tabel Adres. Adres is ondergebracht in een nieuwe tabel, omdat een adres niet onlosmakelijk verbonden is aan een persoon. Er kunnen immers meerdere personen op een adres wonen en mensen kunnen verhuizen.
2.4 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
Een voorbeeld
Ter vergelijking: tabellen uit het personeelsbestand van een fictief bedrijf in 2NF:
| Werknemer_ID | Naam | Voorvoegsel | Initialen | Adres_ID |
|---|---|---|---|---|
| 77 | Jansen | NULL | P. | 34 |
| 78 | Vries | de | W. | 45 |
| 79 | Vries – Zeilstra | de | A. | 45 |
| 80 | Dijk | NULL | D. | 47 |
| Adres_ID | Straat | Nr | Plaats | Provincie | Land |
|---|---|---|---|---|---|
| 34 | Stationsweg | 14 | Venlo | Limburg | Nederland |
| 45 | ’t Steegke | 23 | Epe | Gelderland | Nederland |
| 47 | Straatweg | 1 | Apeldoorn | Gelderland | Nederland |
Niet-sleutel Land hangt hier af van niet-sleutelattribuut Provincie en is in het geval van Gelderland dus redundant opgeslagen. Diezelfde data uit het personeelsbestand van een fictief bedrijf in 3NF:
| Werknemer_ID | Naam | Voorvoegsel | Initialen | Adres_ID |
|---|---|---|---|---|
| 77 | Jansen | NULL | P. | 34 |
| 78 | Vries | de | W. | 45 |
| 79 | Vries – Zeilstra | de | A. | 45 |
| 80 | Dijk | NULL | D. | 47 |
| Adres_ID | Straat | Nr | Plaats | Provincie_ID |
|---|---|---|---|---|
| 34 | Stationsweg | 14 | Venlo | 12 |
| 45 | ’t Steegke | 23 | Epe | 6 |
| 47 | Straatweg | 1 | Apeldoorn | 6 |
| Provincie_ID | Provincie | Land |
|---|---|---|
| 12 | Limburg | Nederland |
| 6 | Gelderland | Nederland |
In dit voorbeeld is geen enkel niet-sleutelattribuut (grijze cellen) afhankelijk van een niet-sleutelattribuut.
2.5 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, dus geen enkele sleutel bevat informatie over een andere sleutel binnen dezelfde tabel, behalve over de gehele primaire sleutel
Een voorbeeld
Een tabel uit een database met aannemers. In dit voorbeeld wordt aangenomen dat een werknemer niet bij twee aannemers hetzelfde werk mag doen, maar dat hij wel verschillende werkzaamheden mag uitvoeren bij verschillende bedrijven.
| Naam | Werk | Aannemer |
|---|---|---|
| Janssen | Loodgieter | B.V. De Loden Gieter |
| Zeilstra | Loodgieter | B.V. De Loden Gieter |
| Zeilstra | Elektromonteur | Elektrobedrijf B.V. |
In deze tabel zijn twee mogelijkheden voor primaire sleutels, namelijk de combinatie van Naam en Aannemer en de combinatie van Naam en Werk. In beide gevallen zal het overgebleven niet-sleutelattribuut informatie bevatten over een deel van de primaire sleutel en niet over de gehele primaire sleutel. Diezelfde data uit een database met aannemers in BCNV:
| Naam | Aannemer |
|---|---|
| Janssen | B.V. De Loden Gieter |
| Zeilstra | B.V. De Loden Gieter |
| Zeilstra | Elektrobedrijf B.V. |
| Aannemer | Werk |
|---|---|
| B.V. De Loden Gieter | Loodgieter |
| Elektrobedrijf B.V. | Elektromonteur |
In dit voorbeeld bevat ieder niet-sleutelattribuut enkel informatie over de gehele primaire sleutel (blauw).
2.6 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
2.7 Vijfde normaalvorm (5NV)
- voldoet aan de vierde normaalvorm
- elke afhankelijkheid bevat een sleutel voor de relatie
3. Referenties
- Omhoog ↑ 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
- Omhoog ↑ 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
- Omhoog ↑ Codd, E.F., Recent Investigations into Relational Data Base Systems, Proc. IFIP Congress, Stockholm, 1974
- Omhoog ↑ Fagin, R., Multivalued Dependencies and a New Normal Form for Relational Databases, ACM Transactions on Database Systems 2 (3), sept 1977
- Omhoog ↑ Fagin, R., Normal Forms and Relational Database Operators, ACM SIGMOD International Conference on Management of Data, May 31-June 1, 1979, Boston, Mass.