Beschrijving van basisbeginselen van databasenormalisatie

Vertaalde artikelen Vertaalde artikelen
Artikel ID: 283878 - Bekijk de producten waarop dit artikel van toepassing is.
Nieuwe gebruikers: voor deze materie moet u vertrouwd zijn met de gebruikersinterface op computers die bedoeld zijn voor één gebruiker.

Klik op de volgende koppeling voor een Microsoft Access 2002-versie van dit artikel: 209534.
Klik op de volgende koppeling voor een Microsoft Access 95- of Microsoft Access 97-versie van dit artikel: 100139.
Alles uitklappen | Alles samenvouwen

Op deze pagina

Samenvatting

In dit artikel wordt voor nieuwe gebruikers de terminologie uitgelegd die wordt gehanteerd bij het normaliseren van een relationele database. Basiskennis van deze terminologie is zinvol bij het bespreken van het ontwerp van een relationele database.

Opmerking Microsoft heeft ook een WebCast gepubliceerd waarin de basisbeginselen van databasenormalisatie aan bod komen. Ga naar de volgende Microsoft-website als u deze WebCast wilt bekijken:
http://support.microsoft.com/servicedesks/webcasts/wc060600/wc060600.asp?fr=1

Meer informatie

Wat is normalisatie?

Normalisatie is het proces van het ordenen van gegevens in een database. Dat betreft het maken van tabellen en het instellen van relaties tussen die tabellen op basis van regels die als doel hebben de gegevens te beveiligen en de database flexibeler te maken door redundantie en inconsistente afhankelijkheid te voorkomen.

Redundantie (dubbel opgeslagen gegevens) betekent verspilling van schijfruimte en veroorzaakt onderhoudsproblemen. Als gegevens moeten worden aangepast die op verschillende locaties zijn opgeslagen, moeten de gegevens op alle locaties op exact dezelfde manier worden gewijzigd. Het wijzigen van het adres van een klant is veel eenvoudiger als de adresgegevens alleen zijn opgeslagen in de tabel Klanten en nergens anders in de database.

Wat is een 'inconsistente afhankelijkheid'? Hoewel het voor een gebruiker logisch is het adres van een bepaalde klant op te zoeken in de tabel Klanten, is het niet logisch dat in dezelfde tabel ook het salaris kan worden gevonden van de werknemer die bij die klant op bezoek gaat. Het salaris van de werknemer is namelijk afhankelijk van de werknemer en moet dus in de tabel Werknemers staan. Inconsistente afhankelijkheden kunnen tot gevolg hebben dat gegevens moeilijk te vinden zijn omdat het pad naar de gegevens mogelijk ontbreekt of verbroken is.

Er zijn enkele regels voor databasenormalisatie. Elke regel wordt een 'normaalvorm' genoemd. Als aan de eerste regel wordt voldaan, bevindt de database zich in de 'eerste normaalvorm'. Als aan de eerste drie regels wordt voldaan, bevindt de database zich in de 'derde normaalvorm'. Hoewel er andere normalisatieniveaus mogelijk zijn, wordt de derde normaalvorm gezien als het hoogste niveau dat nodig is voor de meeste toepassingen.

Net als bij veel formele regels en specificaties, is het in praktijksituaties niet altijd mogelijk aan alle gestelde eisen te voldoen. Over het algemeen zijn voor normalisatie extra tabellen nodig, iets wat niet door alle klanten op prijs wordt gesteld. Als u daarom besluit een van de eerste drie normalisatieregels te negeren, is het belangrijk dat er in de toepassing rekening wordt gehouden met eventuele problemen die kunnen optreden, zoals dubbel opgeslagen gegevens en inconsistente afhankelijkheden.

De volgende beschrijvingen bevatten enkele voorbeelden.

Eerste normaalvorm

  • Elimineer herhalende groepen in afzonderlijke tabellen.
  • Maak een afzonderlijke tabel voor elke set gerelateerde gegevens.
  • Identificeer elke set gerelateerde gegevens met een primaire sleutel.
Gebruik binnen dezelfde tabel geen verschillende velden voor het opslaan van vergelijkbare gegevens. Het bijhouden van een voorraadartikel dat wordt geleverd door twee verschillende leveranciers is bijvoorbeeld mogelijk met een voorraadrecord met daarin velden voor Leverancier 1 en Leverancier 2.

Wat gebeurt er als u een derde leverancier toevoegt? Het toevoegen van een veld is geen oplossing. Hiervoor zijn programma- en tabelwijzigingen noodzakelijk en het aantal leveranciers kan nog steeds niet dynamisch worden aangepast. Een betere oplossing is alle leveranciersgegevens op te slaan in een afzonderlijke tabel (Leveranciers) en de voorraadtabel via een artikelnummer te koppelen aan deze tabel. Een alternatief is leveranciers via een leverancierscode te koppelen aan artikelen.

Tweede normaalvorm

  • Maak afzonderlijke tabellen voor sets met waarden die van toepassing zijn op verschillende records.
  • Koppel deze tabellen via een referentiesleutel.
Records mogen alleen afhankelijk zijn van de primaire sleutel van een tabel (zo nodig een samengestelde sleutel). Laten we als voorbeeld het adres van een klant in een boekhoudsysteem nemen. Het adres moet toegankelijk zijn vanuit de tabel Klanten, maar ook vanuit de tabellen Orders, Verzending, Facturen, Debiteuren en Inningen. In plaats van het adres van de klant afzonderlijk op te slaan in al deze tabellen, is het handiger het adres op één plaats op te slaan, bijvoorbeeld in de tabel Klanten of in een afzonderlijke tabel Adressen. Deze tabel kunt u dan koppelen aan de tabellen waarin het adres moet kunnen worden opgevraagd.

Derde normaalvorm

  • Elimineer velden die niet afhankelijk zijn van de sleutel.
Waarden in een record die geen deel uitmaken van de sleutel van die record horen niet in de tabel thuis. Als de inhoud van een groep velden van toepassing kan zijn op meer dan één record in de tabel, is het meestal beter die velden op te nemen in een afzonderlijke tabel.

Stel dat de tabel Potentiële werknemers ruimte biedt aan de naam en het adres van de universiteit waaraan een potentiële werknemer studeert. U hebt echter een lijst nodig van alle universiteiten om een mailing de deur uit te kunnen doen. Als de NAW-gegevens van alle universiteiten zijn opgeslagen in de tabel Kandidaten, is het onmogelijk alleen de universiteiten op te vragen waarvan momenteel geen kandidaten beschikbaar zijn. Maak in dat geval een afzonderlijke tabel Universiteiten en koppel deze via een universiteitscode aan de tabel Kandidaten.

UITZONDERING: Hoewel het theoretisch gewenst is de derde normaalvorm te volgen, is dit niet altijd praktisch. Als u een tabel Klanten hebt en alle mogelijke afhankelijkheden tussen velden wilt elimineren, moet u afzonderlijke tabellen maken voor plaats, postcode, verkopers, klantsegmenten en alle andere factoren die mogelijk dubbel worden opgeslagen in verschillende records. In theorie is het zinvol normalisatie na te streven. Een groot aantal kleine tabellen kan echter gevolgen hebben voor de prestaties of kan betekenen dat de limiet voor het aantal geopende bestanden of de geheugenlimiet wordt overschreden.

Het kan beter zijn de derde normaalvorm alleen toe te passen op gegevens die regelmatig veranderen. Als er dan nog enkele afhankelijke velden overblijven, moet de toepassing zo worden geschreven dat de gebruiker alle verwante velden moet controleren wanneer de inhoud van een van de velden wordt gewijzigd.

Overige normaalvormen

Er bestaat ook een vierde normaalvorm, ook wel Boyce Codd Normal Form (BCNF) genoemd, en zelfs een vijfde normaalvorm. Deze vormen worden echter zelden toegepast in praktijksituaties. Het negeren van de vierde en vijfde normaalvorm kan betekenen dat het databaseontwerp niet helemaal perfect is, maar voor de functionaliteit zal het weinig gevolgen hebben.

Normaliseren van een voorbeeldtabel

Deze stappen laten zien hoe u een voorbeeldtabel met gegevens van studenten normaliseert.
  1. Niet-genormaliseerde tabel:

    Deze tabel samenvouwenDeze tabel uitklappen
    Studentnr.MentorMentorruimteVak1Vak2Vak3
    1022Jansen412101-07143-01159-02
    4123Smit216201-01211-02214-01
  2. Eerste normaalvorm: geen herhalende groepen

    Tabellen mogen slechts twee dimensies hebben. Aangezien een student verschillende vakken heeft, moeten deze vakken worden ondergebracht in een afzonderlijke tabel. Een ontwerp met de velden Vak1, Vak2 en Vak3 in de bovenstaande records kan problemen opleveren.

    In spreadsheets wordt vaak een derde dimensie gebruikt, maar dit wordt afgeraden voor tabellen. Een andere manier om dit probleem te benaderen, is vanuit het oogpunt van een een-op-veel-relatie. De vuistregel is daar dat de 'een'-zijde en de 'veel'-zijde niet in dezelfde tabel moeten zijn ondergebracht. Het is dan ook beter een andere tabel in de eerste normaalvorm te maken door de herhalende groep (Vak) te elimineren, zoals hieronder is gebeurd:

    Deze tabel samenvouwenDeze tabel uitklappen
    Studentnr.MentorMentorruimteVaknr.
    1022Jansen412101-07
    1022Jansen412143-01
    1022Jansen412159-02
    4123Smit216201-01
    4123Smit216211-02
    4123Smit216214-01
  3. Tweede normaalvorm: elimineer redundante gegevens

    In de bovenstaande tabel is elk studentnummer gekoppeld aan verschillende vaknummers. Het veld Vaknr. is niet functioneel afhankelijk van Studentnr. (primaire sleutel), wat betekent dat deze relatie niet in de tweede normaalvorm is.

    De volgende twee tabellen demonstreren de tweede normaalvorm:

    Studenten:

    Deze tabel samenvouwenDeze tabel uitklappen
    Studentnr.MentorMentorruimte
    1022Jansen412
    4123Smit216


    Registratie:

    Deze tabel samenvouwenDeze tabel uitklappen
    Studentnr.Vaknr.
    1022101-07
    1022143-01
    1022159-02
    4123201-01
    4123211-02
    4123214-01
  4. Derde normaalvorm: elimineer gegevens die niet afhankelijk zijn van sleutel

    In het laatste voorbeeld is het veld Mentorruimte (het nummer van het kantoor van de mentor) functioneel afhankelijk van het kenmerk Mentor. De oplossing bestaat eruit dat kenmerk te verplaatsen van de tabel Studenten naar de tabel Faculteit, zoals hieronder:

    Studenten:

    Deze tabel samenvouwenDeze tabel uitklappen
    Studentnr.Mentor
    1022Jansen
    4123Smit


    Faculteit:

    Deze tabel samenvouwenDeze tabel uitklappen
    NaamKamerAfdeling
    Jansen41242
    Smit21642

Eigenschappen

Artikel ID: 283878 - Laatste beoordeling: dinsdag 16 juli 2013 - Wijziging: 6.4
De informatie in dit artikel is van toepassing op:
  • Microsoft Office Access 2007
  • Microsoft Office Access 2003
  • Microsoft Access 2002 Standard Edition
Trefwoorden: 
kbinfo kbdesign kbdatabase kbhowto KB283878

Geef ons feedback

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com