De derde normaalvorm (databases) is een relationele database-ontwerptechniek, waarbij de verschillende tabellen waaruit het bestaat niet alleen voldoen aan de tweede normale vorm, maar al hun attributen of velden rechtstreeks afhankelijk zijn van de primaire sleutel.
Bij het ontwerpen van een database is het belangrijkste doel om een nauwkeurige weergave van de gegevens, de relaties daartussen en de relevante gegevensbeperkingen te creëren..
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.
Artikel index
Normalisatie maakt gebruik van een reeks tests, de zogenaamde normale vormen, om de optimale groepering van deze attributen 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 normaalvorm, wordt gezegd dat de relatie zich in die normale vorm bevindt.
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..
Het behandelt het elimineren van circulaire afhankelijkheden uit een tabel. Er wordt gezegd dat een relatie zich in 2FN bevindt als deze zich in 1FN bevindt en ook elk niet-sleutelveld of kenmerk hangt 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.
Het behandelt het verwijderen 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-sleutelattribuut of veld 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 individueel kunnen worden bijgewerkt, zonder het gevaar een ander attribuut te beïnvloeden..
Om een databaserelatie in de derde normale vorm te hebben, moet deze 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.
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.
Aangezien 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.
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 tafel STUDENT.
Als het bijvoorbeeld vereist is om de straat "El Limón" te veranderen in "El Limón II", moet u zoeken naar "El Limón" in de hele STUDENT-tabel 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 dus 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, wat de database en queries vereenvoudigt. Dus de tabellen staan in 3FN:
Laat de volgende tabel worden gebruikt met het veld Project_Num als primaire sleutel en met herhaalde waarden in attributen die geen sleutels zijn.
De telefoonwaarde wordt elke keer 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, waardoor een aparte tabel ontstaat.
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 aan de derde normaalvorm te voldoen, wordt een nieuwe tabel (Managers) aangemaakt om het probleem op te lossen. Beide tabellen zijn gerelateerd via het veld Project_Manager:
Niemand heeft nog op dit artikel gereageerd.