WAT IS DE DERDE NORMAALVORM? (DATABASES) - TECHNOLOGIE - 2025

De derde normaalvorm (databases) is een relationele database-ontwerptechniek, waarbij de verschillende tabellen waaruit het bestaat niet alleen voldoen aan de tweede normaalvorm, maar al hun attributen of velden rechtstreeks afhankelijk zijn van de primaire sleutel.

Bij het ontwerpen van een database is het belangrijkste doel het creëren van een nauwkeurige weergave van de gegevens, de relaties daartussen en de beperkingen op de gegevens die relevant zijn.

Bron: pixabay.com

Om dit doel te bereiken, kunnen enkele database-ontwerptechnieken worden gebruikt, waaronder normalisatie.

Dit is een proces waarbij de gegevens in een database worden georganiseerd om overtolligheden en mogelijke anomalieën bij het invoegen, bijwerken of verwijderen van de gegevens te voorkomen, waardoor een eenvoudig en stabiel ontwerp van het conceptuele model wordt gegenereerd.

Het begint met het onderzoeken van de functionele relatie of afhankelijkheid tussen attributen. Deze beschrijven een eigenschap van de gegevens of de relatie daartussen.

Normale vormen

Normalisatie maakt gebruik van een reeks tests, de zogenaamde normale vormen, om de optimale groepering van deze kenmerken te helpen identificeren en uiteindelijk de juiste set relaties vast te stellen die de gegevensvereisten van een bedrijf ondersteunen.

Dat wil zeggen, de normalisatietechniek is opgebouwd rond het concept van de normale vorm, dat een systeem van beperkingen definieert. Als een relatie voldoet aan de beperkingen van een bepaalde normale vorm, wordt gezegd dat de relatie die normale vorm heeft.

Eerste normaalvorm (1FN)

Er wordt gezegd dat een tabel in 1FN staat als alle attributen of velden erin alleen unieke waarden bevatten. Dat wil zeggen, elke waarde voor elk kenmerk moet ondeelbaar zijn.

Een relationele database wordt per definitie altijd genormaliseerd naar de eerste normaalvorm, omdat attribuutwaarden altijd atomair zijn. Alle relaties in een database zijn in 1FN.

Het zo verlaten van de database veroorzaakt echter een aantal problemen, zoals redundantie en mogelijke mislukte upgrades. Om deze problemen te verhelpen, werden hogere normale vormen ontwikkeld.

Tweede normaalvorm (2FN)

Het behandelt het verwijderen van circulaire afhankelijkheden uit een tabel. Er wordt gezegd dat een relatie in 2FN is als deze zich in 1FN bevindt en bovendien hangt elk niet-sleutelveld of kenmerk volledig af van de primaire sleutel, of meer specifiek, het zorgt ervoor dat de tabel een enkel doel heeft.

Een niet-sleutelattribuut is elk attribuut dat geen deel uitmaakt van de primaire sleutel voor een relatie.

Derde normaalvorm (3FN)

Het behandelt het elimineren van transitieve afhankelijkheden uit een tabel. Dat wil zeggen, verwijder de niet-sleutelattributen die niet afhankelijk zijn van de primaire sleutel, maar van een ander attribuut.

Een transitieve afhankelijkheid is een type functionele afhankelijkheid waarbij de waarde van een niet-sleutelveld of -attribuut wordt bepaald door de waarde van een ander veld dat ook niet de sleutel is.

Zoek naar herhaalde waarden in niet-sleutelattributen om ervoor te zorgen dat deze niet-sleutelattributen niet afhankelijk zijn van iets anders dan de primaire sleutel.

Van attributen wordt gezegd dat ze onderling onafhankelijk zijn als geen van hen functioneel afhankelijk is van een combinatie van andere. Deze wederzijdse onafhankelijkheid zorgt ervoor dat attributen afzonderlijk kunnen worden bijgewerkt, zonder het gevaar een ander attribuut te beïnvloeden.

Om een ​​relatie in een database in de derde normale vorm te hebben, moet deze daarom voldoen aan:

- Alle vereisten van 2FN.

- Als er attributen zijn die niet gerelateerd zijn aan de primaire sleutel, moeten deze worden verwijderd en in een aparte tabel worden geplaatst, waarbij beide tabellen met elkaar in verband worden gebracht door middel van een externe sleutel. Dat wil zeggen, er mogen geen transitieve afhankelijkheden zijn.

Voorbeelden van derde normaalvorm

voorbeeld 1

Stel dat de tabel STUDENT is, waarvan de primaire sleutel de identificatie van de student is (STUDENT_ID) en is samengesteld uit de volgende attributen: STUDENT_NAME, STREET, CITY en POST_CODE, die voldoen aan de voorwaarden om 2FN te zijn.

In dit geval hebben STREET en CITY geen directe relatie met de primaire sleutel STUDENT_ID, aangezien ze niet direct gerelateerd zijn aan de student, maar volledig afhankelijk zijn van de postcode.

Omdat de student wordt gelokaliseerd door de site bepaald door CODE_POSTAL, zijn STREET en CITY gerelateerd aan dit attribuut. Vanwege deze tweede mate van afhankelijkheid is het niet nodig om deze attributen op te slaan in de STUDENT-tabel.

Maak een nieuwe tafel

Stel dat er meerdere studenten zijn die zich in dezelfde postcode bevinden, waarbij de STUDENT-tabel een enorm aantal records heeft en het vereist is om de naam van de straat of stad te wijzigen, dan moet deze straat of stad worden gevonden en bijgewerkt in de hele tabel LEERLING.

Als u bijvoorbeeld de straat "El Limón" moet wijzigen in "El Limón II", moet u in de hele STUDENT-tabel naar "El Limón" zoeken en deze vervolgens bijwerken naar "El Limón II".

Het zoeken in een enorme tabel en het bijwerken van de enkele of meerdere records kost veel tijd en heeft daarom invloed op de prestaties van de database.

In plaats daarvan kunnen deze details worden bewaard in een aparte tabel (POSTCARD) die is gerelateerd aan de STUDENT-tabel met behulp van het POST_CODE-attribuut.

De POST-tabel heeft relatief minder records en deze POST-tabel hoeft maar één keer te worden bijgewerkt. Dit wordt automatisch weergegeven in de STUDENT-tabel, waardoor de database en queries worden vereenvoudigd. Dus de tabellen staan ​​in 3FN:

Voorbeeld 2

Laat de volgende tabel worden gebruikt met het veld Project_Num als de primaire sleutel en met herhaalde waarden in attributen die geen sleutels zijn.

De Telefoonwaarde wordt telkens herhaald als de naam van een manager wordt herhaald. Dit komt doordat het telefoonnummer slechts een tweedegraads afhankelijkheid heeft van het projectnummer. Het hangt echt eerst van de manager af, en dit hangt weer af van het projectnummer, wat een transitieve afhankelijkheid maakt.

Het attribuut Project_Manager kan geen mogelijke sleutel zijn in de tabel Projecten, omdat dezelfde manager meer dan één project beheert. De oplossing hiervoor is om het attribuut met de herhaalde gegevens (Phone) te verwijderen en een aparte tabel te creëren.

De bijbehorende attributen moeten worden gegroepeerd, waardoor een nieuwe tabel wordt gemaakt om ze op te slaan. De gegevens worden ingevoerd en er wordt geverifieerd dat de herhaalde waarden geen deel uitmaken van de primaire sleutel. De primaire sleutel wordt voor elke tabel ingesteld en indien nodig worden externe sleutels toegevoegd.

Om te voldoen aan de derde normaalvorm, wordt een nieuwe tabel (Managers) gemaakt om het probleem op te lossen. Beide tabellen zijn gerelateerd via het veld Project_Manager:

Referenties

1. Teradata (2019). Eerste, tweede en derde normale vormen. Overgenomen van: docs.teradata.com.
2. Tutorial Cup (2019). Derde normale vorm (3NF). Genomen van: tutorialcup.com.
3. Database-ontwikkelaar (2015). Third Normal Form (3NF) - Uw database normaliseren. Overgenomen van: databasedev.co.uk.
4. Relationeel DB-ontwerp (2019). Inleiding tot de derde normale vorm. Genomen uit: relationaldbdesign.com.
5. Dummy's (2019). SQL eerste, tweede en derde normale formulieren. Genomen van: dummies.com.