In de context van relationele databases is Third Normal Form (3NF) een cruciaal ontwerpprincipe en datamodelleringsstandaard die de efficiënte organisatie en normalisatie van gegevens in een database garandeert. Normalisatie is het proces waarbij een database wordt gestructureerd door gegevensredundantie te elimineren en de gegevensintegriteit te verbeteren. Er zijn verschillende normale vormen (NF's) die verschillende niveaus van normalisatie definiëren, waarbij 3NF een van de meest gebruikte en essentiële vormen is, die een goed evenwicht biedt tussen het minimaliseren van redundantie en het behouden van gebruiksgemak voor relationele databases.
De Derde Normaalvorm, of 3NF, werd voor het eerst geïntroduceerd door Edgar F. Codd, de pionier van het relationele model, in 1971. Deze normaalvorm is gebaseerd op twee fundamentele principes: het elimineren van transitieve afhankelijkheden en ervoor zorgen dat elk niet-primair sleutelkenmerk volledig wordt gebruikt. functioneel afhankelijk van de primaire sleutel voor elke relatie. Er wordt gezegd dat een databasetabel zich in 3NF bevindt als deze aan de volgende drie criteria voldoet:
- De tabel volgt de Eerste Normaalvorm (1NF).
- De tabel volgt de Tweede Normaalvorm (2NF).
- Er zijn geen transitieve afhankelijkheden tussen niet-sleutelattributen.
Om dit verder uit te werken, schrijft First Normal Form (1NF) voor dat een tabel atomaire waarden moet bevatten, waarbij elk attribuut een enkele waarde bevat in plaats van een set of lijst, waardoor attributen met meerdere waarden worden verboden. Het vereist ook dat elke attribuutwaarde uniek moet zijn binnen een enkele rij met gegevens. Dit zorgt voor gegevensconsistentie en vereenvoudigt het uitvoeren van query's, waardoor de complexiteit van het werken met gegevens over meerdere rijen wordt verminderd.
Second Normal Form (2NF) bouwt voort op 1NF door de beperking toe te voegen dat elk niet-sleutelattribuut volledig afhankelijk moet zijn van de gehele primaire sleutel in een tabel. Hiermee worden de problemen van redundantie en gedeeltelijke afhankelijkheden direct aangepakt, waardoor het risico op afwijkingen in de database wordt geminimaliseerd. Om een tabel in 2NF te kunnen plaatsen, moet deze aan twee vereisten voldoen: de tabel bevindt zich al in 1NF en er bestaan geen gedeeltelijke afhankelijkheden tussen de attributen.
Ten slotte gaat de Third Normal Form (3NF) het normalisatieproces nog een stap verder door transitieve afhankelijkheden tussen niet-sleutelattributen te elimineren. Dit betekent dat er in een tabel die voldoet aan 3NF geen enkel niet-sleutelattribuut mag voorkomen dat afhankelijk is van een ander niet-sleutelattribuut, dat op zijn beurt weer afhankelijk is van de primaire sleutel. Simpel gezegd: alle niet-primaire sleutelkenmerken zouden direct afhankelijk moeten zijn van de primaire sleutel, in plaats van indirect via andere niet-primaire sleutelkenmerken. 3NF zorgt er dus voor dat redundantie wordt geminimaliseerd, terwijl het gemak van het opvragen behouden blijft en efficiënt databasebeheer mogelijk wordt gemaakt.
AppMaster, een no-code platform voor het bouwen van backend-, web- en mobiele applicaties, is voor zijn gegevensopslag en -beheer sterk afhankelijk van relationele databases. Het naleven van 3NF bij het datamodelleringsproces is uiterst belangrijk voor het garanderen van de efficiëntie, integriteit en schaalbaarheid van de applicaties die via AppMaster zijn ontwikkeld. Door de 3NF-principes te volgen, kan AppMaster een krachtig en betrouwbaar platform bieden waarmee gebruikers hun applicaties kunnen ontwikkelen op basis van hun specifieke behoeften.
Voorbeeld:
Beschouw een databasetabel met informatie over werknemers, hun afdelingen en afdelingslocaties:
| WerknemerID | Werknemernaam | AfdelingID | Afdelingsnaam | AfdelingLocatie |
In deze tabel bestaat de primaire sleutel uit de kenmerken EmployeeID en DepartmentID. De tabel heeft verschillende afhankelijkheden, waaronder een gedeeltelijke afhankelijkheid (EmployeeName is afhankelijk van EmployeeID) en transitieve afhankelijkheden (DepartmentName en DepartmentLocation zijn afhankelijk van DepartmentID, die deel uitmaakt van de primaire sleutel). Deze tabel staat niet in 3NF.
Om deze tabel naar 3NF te converteren, moeten we zowel de gedeeltelijke als de transitieve afhankelijkheden elimineren. Dit kan worden bereikt door de gegevens in afzonderlijke tabellen op te splitsen:
| WerknemerID | Werknemernaam | AfdelingID |
En
| AfdelingID | Afdelingsnaam | AfdelingLocatie |
Door vast te houden aan 3NF bevatten de nieuwe tabellen geen redundante gegevens en minimaliseren ze het risico op afwijkingen, waardoor de algehele gegevensintegriteit en efficiëntie van de relationele database worden verbeterd.
Concluderend is Third Normal Form (3NF) een essentieel ontwerpprincipe en datamodelleringsstandaard voor relationele databases, die een efficiënte dataorganisatie, minimale redundantie en verbeterde data-integriteit garanderen. Door zich te houden aan 3NF bij het ontwerpen van databasetabellen kunnen platforms zoals AppMaster een robuuste en efficiënte basis bieden voor de ontwikkeling en implementatie van verschillende web-, mobiele en backend-applicaties, wat resulteert in een hogere productiviteit en lagere kosten voor klanten van elke omvang in diverse industrieën.
