Databasenormalisatie

Uit Wikipedia, de vrije encyclopedie
Ga naar: navigatie, zoeken

Databasenormalisatie is een techniek bij het ontwerpen van gegevensbanken. Ze dient twee doelen: het spaarzaam omgaan met opslagruimte en het vermijden van meervoudige vastlegging van dezelfde data, een potentiele bron van fouten.

Relationele gegevensbanken[bewerken]

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.

Normaalvormen[bewerken]

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.

Niet-genormaliseerde gegevens[bewerken]

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 ?

Eerste normaalvorm (1NV)[bewerken]

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[bewerken]

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

Tweede normaalvorm (2NV)[bewerken]

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[bewerken]

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:

Werknemer
Werknemer_ID Naam Voorvoegsel Initialen Adres_ID
77 Jansen NULL P. 34
78 Vries de W. 45
79 Vries - Zeilstra de A. 45
80 Oud NULL T. 67
Adres
Adres_ID Straat Nr Plaats
34 Stationsweg 14 Venlo
45 't Steegke 23 Epe
67 Dorpsstraat 1 Ons Dorp

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.

Derde normaalvorm (3NV)[bewerken]

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[bewerken]

Ter vergelijking: tabellen uit het personeelsbestand van een fictief bedrijf in 2NF:

Werknemer
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
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
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
Adres_ID Straat Nr Plaats Provincie_ID
34 Stationsweg 14 Venlo 12
45 't Steegke 23 Epe 6
47 Straatweg 1 Apeldoorn 6
Provincie
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.

Boyce-Codd-normaalvorm (BCNV)[bewerken]

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[bewerken]

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.

Aannemers
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:

Medewerkers
Naam Aannemer
Janssen B.V. De Loden Gieter
Zeilstra B.V. De Loden Gieter
Zeilstra Elektrobedrijf B.V.
Aannemers
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).

Vierde normaalvorm (4NV)[bewerken]

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

Vijfde normaalvorm (5NV)[bewerken]

  • voldoet aan de vierde normaalvorm
  • elke afhankelijkheid bevat een sleutel voor de relatie

Referenties[bewerken]

  1. 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
  2. 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
  3. Codd, E.F., Recent Investigations into Relational Data Base Systems, Proc. IFIP Congress, Stockholm, 1974
  4. Fagin, R., Multivalued Dependencies and a New Normal Form for Relational Databases, ACM Transactions on Database Systems 2 (3), sept 1977
  5. Fagin, R., Normal Forms and Relational Database Operators, ACM SIGMOD International Conference on Management of Data, May 31-June 1, 1979, Boston, Mass.

Zie ook[bewerken]