Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
In dit artikel wordt de terminologie voor databasenormalisatie voor beginners uitgelegd. Een basiskennis van deze terminologie is handig 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 de database flexibeler te maken door redundantie en inconsistente afhankelijkheid te elimineren.
Redundante gegevens verspillen schijfruimte en veroorzaken onderhoudsproblemen. Als gegevens op meer dan één plaats moeten worden gewijzigd, moeten de gegevens op exact dezelfde manier op alle locaties 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 naar het adres van een bepaalde klant te zoeken, is het misschien niet logisch om daar te zoeken naar het salaris van de werknemer die die klant aanroept. Het salaris van de werknemer is gerelateerd aan of afhankelijk van de werknemer en moet dus worden verplaatst naar de tabel Werknemers. Inconsistente afhankelijkheden kunnen gegevens moeilijk toegankelijk maken omdat het pad om de gegevens te vinden mogelijk ontbreekt of beschadigd is.
Er zijn enkele regels voor databasenormalisatie. Elke regel wordt een 'normale vorm' genoemd. Als de eerste regel wordt waargenomen, wordt gezegd dat de database zich in 'eerste normale vorm' bevindt. Als de eerste drie regels worden waargenomen, wordt de database beschouwd als 'derde normale vorm'. Hoewel andere normalisatieniveaus mogelijk zijn, wordt de derde normale vorm beschouwd als het hoogste niveau dat nodig is voor de meeste toepassingen.
Net als bij veel formele regels en specificaties bieden echte scenario's niet altijd een perfecte naleving. Over het algemeen vereist normalisatie aanvullende tabellen en sommige klanten vinden dit lastig. Als u besluit een van de eerste drie normalisatieregels te schenden, moet u ervoor zorgen dat uw toepassing eventuele problemen verwacht, zoals redundante gegevens en inconsistente afhankelijkheden.
De volgende beschrijvingen bevatten voorbeelden.
Eerste normale vorm
- Verwijder 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. Als u bijvoorbeeld een voorraaditem wilt bijhouden dat afkomstig kan zijn van twee mogelijke bronnen, kan een inventarisrecord velden bevatten voor Leverancierscode 1 en Leveranciercode 2.
Wat gebeurt er wanneer u een derde leverancier toevoegt? Het toevoegen van een veld is niet het antwoord; het vereist wijzigingen in programma's en tabellen en biedt geen ondersteuning voor een dynamisch aantal leveranciers. In plaats daarvan, plaats alle leveranciersinformatie in een aparte tabel genaamd Leveranciers en koppel de voorraad aan leveranciers met een itemnummersleutel, of koppel de leveranciers aan de voorraad met een leverancierscodesleutel.
Tweede normale vorm
- Maak afzonderlijke tabellen voor sets waarden die van toepassing zijn op meerdere records.
- Koppel deze tabellen met een vreemde sleutel.
Records mogen niet afhankelijk zijn van iets anders dan de primaire sleutel van een tabel (indien nodig een samengestelde sleutel). Denk bijvoorbeeld aan het adres van een klant in een boekhoudsysteem. Het adres is nodig voor de tabel Klanten, maar ook door de tabellen Orders, Verzending, Facturen, Debiteuren en Verzamelingen. In plaats van het adres van de klant op te slaan als een afzonderlijke vermelding in elk van deze tabellen, slaat u het op één plaats op, in de tabel Klanten of in een afzonderlijke tabel Adressen.
Derde normale vorm
- 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. Over het algemeen geldt dat wanneer de inhoud van een groep velden van toepassing is op meer dan één record in de tabel, kunt u overwegen deze velden in een afzonderlijke tabel te plaatsen.
In een tabel voor werknemerswerving kunnen bijvoorbeeld de naam en het adres van een kandidaat worden opgenomen. Maar u hebt een volledige lijst met universiteiten nodig voor groepsmailings. Als informatie van de universiteit wordt opgeslagen in de tabel Kandidaten, is er geen manier om universiteiten zonder huidige kandidaten weer te geven. Maak een afzonderlijke tabel Universiteiten en koppel deze aan de tabel Kandidaten met een codesleutel voor de universiteit.
UITZONDERING: het is niet altijd praktisch om de derde normale vorm te hanteren, maar theoretisch wenselijk. Als u een tabel Klanten hebt en u alle mogelijke afhankelijkheden tussen velden wilt elimineren, moet u afzonderlijke tabellen maken voor steden, postcodes, verkoopmedewerkers, klantklassen en andere factoren die in meerdere records kunnen worden gedupliceerd. In theorie is normalisatie de moeite waard om te streven. Veel kleine tabellen kunnen echter de prestaties verminderen of de open bestands- en geheugencapaciteit overschrijden.
Het kan beter zijn om de derde normale vorm alleen toe te passen op gegevens die regelmatig worden gewijzigd. Als sommige afhankelijke velden behouden blijven, ontwerpt u uw toepassing zodat de gebruiker alle gerelateerde velden moet verifiëren wanneer een veld wordt gewijzigd.
Andere normalisatievormen
Vierde normale vorm, ook wel de Boyce-Codd normale vorm (BCNF) genoemd, en vijfde normale vorm bestaan, maar worden zelden beschouwd in praktische ontwerpen. Het negeren van deze regels kan resulteren in minder dan perfect databaseontwerp, maar mag geen invloed hebben op de functionaliteit.
Een voorbeeldtabel normaliseren
In deze stappen wordt het proces voor het normaliseren van een fictieve studententabel gedemonstreerd.
Niet-genormaliseerde tabel:
Student# Adviseur Adv-Room Klasse1 Klasse2 Klasse3 1022 Jones 412 101-07 143-01 159-02 4123 Smit 216 101-07 143-01 179-04 Eerste normale vorm: Geen herhalende groepen
Tabellen mogen slechts twee dimensies hebben. Aangezien één leerling/student meerdere klassen heeft, moeten deze klassen worden vermeld in een afzonderlijke tabel. Velden Class1, Class2 en Class3 in de bovenstaande records zijn indicaties van ontwerpproblemen.
Spreadsheets maken vaak gebruik van de derde dimensie, maar tabellen mogen dat niet. Een andere manier om dit probleem te bekijken, is met een een-op-veel-relatie: plaats niet de ene kant en de vele kanten in dezelfde tabel. Maak in plaats daarvan een andere tabel in de eerste normale vorm door de herhalende groep (Class#) te elimineren, zoals wordt weergegeven in het volgende voorbeeld:
Student# Adviseur Adv-Room Klas# 1022 Jones 412 101-07 1022 Jones 412 143-01 1022 Jones 412 159-02 4123 Smit 216 101-07 4123 Smit 216 143-01 4123 Smit 216 179-04 Tweede normale vorm: Overbodige gegevens elimineren
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 heeft geen tweede normale vorm.
In de volgende tabellen ziet u de tweede normale vorm:
Studenten:
Student# Adviseur Adv-Room 1022 Jones 412 4123 Smit 216 Registratie:
Student# Klas# 1022 101-07 1022 143-01 1022 159-02 4123 101-07 4123 143-01 4123 179-04 Derde normale vorm: Gegevens elimineren die niet afhankelijk zijn van de sleutel
In het laatste voorbeeld is Adv-Room (het kantoornummer van de adviseur) functioneel afhankelijk van het kenmerk Advisor. De oplossing is om dat kenmerk van de tabel Studenten naar de tabel Faculteit te verplaatsen, zoals hieronder wordt weergegeven:
Studenten:
Student# Adviseur 1022 Jones 4123 Smit Faculteit:
Naam Kamer Afdeling Jones 412 42 Smit 216 42