Derde normale vorm (3NF) is een databaseprincipe dat de integriteit van gegevens ondersteunt door voort te bouwen op de database-normalisatieprincipes die worden geboden door First Normal Form (1NF) en Second Normal Form (2NF).
Derde normale formuliervereisten
Er zijn twee basisvereisten voor een database om in de derde normale vorm te zijn:
- De database moet al voldoen aan de vereisten van zowel 1NF als 2NF.
- Alle databasekolommen moeten afhankelijk zijn van de primaire sleutel, wat betekent dat de waarde van elke kolom alleen kan worden afgeleid van de primaire sleutel.
Over de primaire sleutelafhankelijkheid
Laten we verder gaan met wat we bedoelen met het feit dat alle kolommen afhankelijk moeten zijn van de primaire sleutel.
Als de waarde van een kolom kan worden afgeleid van zowel de primaire sleutel als een andere kolom in de tabel, is deze in strijd met 3NF. Overweeg een tabel Werknemers met deze kolommen:
- EmployeeID
- Voornaam
- Achternaam
Hebben zowel LastName als FirstName alleen betrekking op de waarde van EmployeeID? Welnu, kan LastName afhankelijk zijn van FirstName? Nee, omdat niets inherends in LastName de waarde van FirstName suggereert. Kan FirstName afhankelijk zijn van LastName? Nee, want hetzelfde geldt: wat een LastName ook is, het kan geen hint geven over de waarde van FirstName. Daarom is deze tabel compatibel met 3NF.
Maar overweeg deze Voertuigentabel:
- vehicleid
- Fabrikant
- Model
De fabrikant en het model zouden kunnen worden afgeleid van de VehicleID - maar het model zou ook van de fabrikant kunnen komen omdat een voertuigmodel alleen door een bepaalde fabrikant wordt gemaakt. Dit tabelontwerp voldoet niet aan 3NF en kan daarom leiden tot gegevensanomalieën. U kunt de fabrikant bijvoorbeeld bijwerken zonder het model bij te werken en onnauwkeurigheden te introduceren.
Om het compliant te maken, moeten we de aanvullende afhankelijke kolom naar een andere tabel verplaatsen en ernaar verwijzen met behulp van een externe sleutel. Dit zou resulteren in twee tabellen:
Voertuintabel
In de onderstaande tabel is de ModelID een externe sleutel voor de modellen tafel:
- vehicleid
- Fabrikant
- ModelID
Modeltabel
Deze nieuwe tabel brengt modellen in kaart voor fabrikanten. Als u voertuiginformatie specifiek voor een model wilt bijwerken, doet u het in deze tabel in plaats van in de tabel Voertuigen.
- ModelID
- Fabrikant
- Model
Afgeleide velden in het 3NF-model
Een tabel kan een afgeleide veld bevatten - een veld dat is berekend op basis van andere kolommen in de tabel. Bekijk bijvoorbeeld deze tabel met widgetorders:
- Bestellingsnummer
- Klantnummer
- Eenheid prijs
- Aantal stuks
- Totaal
Het totaal verbreekt de conformiteit van 3NF omdat het kan worden afgeleid door de eenheidsprijs te vermenigvuldigen met de hoeveelheid, in plaats van volledig afhankelijk te zijn van de primaire sleutel. We moeten het van de tafel verwijderen om te voldoen aan het derde normale formulier.
Omdat het is afgeleid, is het beter om het helemaal niet in de database op te slaan.
We kunnen het eenvoudig "on the fly" berekenen bij het uitvoeren van databasequery's. We hebben deze vraag bijvoorbeeld eerder gebruikt om bestelnummers en totalen op te halen:
SELECT Bestelnummer, Totaal FROM WidgetOrders
We kunnen nu de volgende query gebruiken:
SELECT Bestelnummer, Eenheidsprijs * Aantal AS TOTAAL VAN WidgetOrders
om dezelfde resultaten te bereiken zonder de normalisatieregels te overtreden.
