Beschrijving van de basisbeginselen van databasenormalisatie
In dit artikel wordt voor beginners de terminologie uitgelegd die wordt gebruikt bij het normaliseren van een database. Basiskennis van deze terminologie is zinvol bij het bespreken van het ontwerp van een relationele database.
Beschrijving van normalisatie
Normalisatie is het proces van het ordenen van gegevens in een database. Het omvat het maken van tabellen en het tot stand brengen van relaties tussen deze tabellen volgens regels die zijn ontworpen om de gegevens te beveiligen en om de database flexibeler te maken door redundantie en inconsistente afhankelijkheid te elimineren.
Redundante (dubbel opgeslagen) gegevens betekenen verspilling van schijfruimte en veroorzaken onderhoudsproblemen. Als gegevens moeten worden aangepast die op verschillende locaties zijn opgeslagen, moeten de gegevens op alle locaties op exact dezelfde manier worden gewijzigd. Een wijziging van het adres van de klant is eenvoudiger te implementeren als die gegevens alleen worden opgeslagen in de tabel Klanten en nergens anders in de database.
Wat is een 'inconsistente afhankelijkheid'? Hoewel het intuïtief is voor een gebruiker om in de tabel Klanten te zoeken naar het adres van een bepaalde klant, is het misschien niet logisch om daar te zoeken naar het salaris van de werknemer die een beroep doet op die klant. Het salaris van de werknemer is namelijk gerelateerd aan en 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 'normale vorm' genoemd. Als de eerste regel wordt nageleefd, wordt gezegd dat de database de eerste normale vorm heeft. Als de eerste drie regels worden nageleefd, wordt de database beschouwd als 'derde normaal'. Hoewel andere niveaus van normalisatie mogelijk zijn, wordt de derde normale vorm beschouwd als het hoogste niveau dat nodig is voor de meeste toepassingen.
Zoals bij veel formele regels en specificaties, bieden scenario's in de praktijk niet altijd een perfecte naleving. Over het algemeen zijn voor normalisatie extra tabellen nodig, iets wat niet iedere klant op prijs stelt. 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 niet meerdere velden in één tabel om vergelijkbare gegevens op te slaan. 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 niet het antwoord; het vereist programma- en tabelwijzigingen en biedt niet soepel plaats aan een dynamisch aantal leveranciers. Een betere oplossing is alle leveranciersgegevens op te slaan in een afzonderlijke Leveranciers-tabel en de voorraadtabel via een artikelnummer te koppelen aan deze tabel of de leveranciers via een leverancierscode aan artikelen te koppelen.
Tweede normaalvorm
- Maak afzonderlijke tabellen voor sets met waarden die op meerdere records van toepassing zijn.
- Koppel deze tabellen via een referentiesleutel.
Records mogen niet afhankelijk zijn van iets anders dan de primaire sleutel van een tabel (indien 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.
Derde normaalvorm
- Verwijder 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. Over het algemeen geldt dat wanneer de inhoud van een groep velden van toepassing kan zijn op meer dan één record in de tabel, u kunt overwegen om die velden in een aparte tabel te plaatsen.
Stel dat in de tabel Potentiële werknemers de naam en het adres van de universiteit waaraan een kandidaat studeert zijn opgenomen. 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: Het vasthouden aan de derde normale vorm, hoewel theoretisch wenselijk, is 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 normalisatie de moeite waard. 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
De vierde normale vorm, ook wel Boyce-Codd normale vorm (BCNF) genoemd, en de vijfde normale vorm bestaan wel, maar worden zelden in de praktijk beschouwd. Het negeren van deze regels kan leiden tot een minder dan perfect databaseontwerp, maar heeft geen invloed op de functionaliteit.
Normaliseren van een voorbeeldtabel
Deze stappen laten zien hoe u een voorbeeldtabel met gegevens van studenten normaliseert.
Niet-genormaliseerde tabel:
Studentnummer Mentor Mentorruimte Vak 1 Vak 2 Vak 3 1022 Jansen 412 101-07 143-01 159-02 4123 Smit 216 101-07 143-01 179-04 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.
Spreadsheets gebruiken vaak de derde dimensie, maar tabellen niet. Een andere manier om dit probleem te bekijken, is met een een-op-veel-relatie. Plaats de ene kant en de vele zijden niet in dezelfde tabel. Maak in plaats daarvan een andere tabel in de eerste normale vorm door de herhalende groep (Klasse#) te elimineren, zoals in het volgende voorbeeld wordt weergegeven:
Studentnummer Mentor Mentorruimte Vaknummer 1022 Jansen 412 101-07 1022 Jansen 412 143-01 1022 Jansen 412 159-02 4123 Smit 216 101-07 4123 Smit 216 143-01 4123 Smit 216 179-04 Tweede normaalvorm: overbodige gegevens verwijderen
Noteer de meerdere Class# -waarden voor elke Student# -waarde in de bovenstaande tabel. Class# is niet functioneel afhankelijk van Student# (primaire sleutel), dus deze relatie is niet in de tweede normale vorm.
De volgende tabellen geven de tweede normaalvorm weer:
Studenten:
Studentnummer Mentor Mentorruimte 1022 Jansen 412 4123 Smit 216 Registratie:
Studentnummer Vaknummer 1022 101-07 1022 143-01 1022 159-02 4123 101-07 4123 143-01 4123 179-04 Derde normaalvorm: gegevens verwijderen die niet afhankelijk zijn van de 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:
Studentnummer Mentor 1022 Jansen 4123 Smit Faculteit:
Naam Kamer Afdeling Jansen 412 42 Smit 216 42
Feedback
Binnenkort beschikbaar: In de loop van 2024 zullen we GitHub-problemen geleidelijk uitfaseren als het feedbackmechanisme voor inhoud en deze vervangen door een nieuw feedbacksysteem. Zie voor meer informatie: https://aka.ms/ContentUserFeedback.
Feedback verzenden en weergeven voor