Wat is de derde normale vorm? (Databases)

De Derde normale vorm (databases) Het is een relationele databaseontwerptechniek, waarbij de verschillende tabellen die het vormen niet alleen aan de tweede normale vorm voldoen, maar al hun attributen of velden direct afhankelijk zijn van de belangrijkste sleutel.

Wanneer een database is ontworpen, is het hoofddoel het creëren van een nauwkeurige weergave van de gegevens, van de relaties tussen hen en de beperkingen op de relevante gegevens.

Bron: Pixabay.com

Om dit doel te bereiken, kunnen sommige databaseontwerptechnieken worden gebruikt, waaronder de standaardisatie.

Dit is een proces van het organiseren van gegevens in een database om redundanties en mogelijke anomalieën in de invoeging, bij te werken of te verwijten van de gegevens, waardoor een eenvoudig en stabiel ontwerp van het conceptuele model wordt gegenereerd,.

Begint met het onderzoeken van de functionele relatie of afhankelijkheid tussen attributen. Deze beschrijven sommige eigenschappen van de gegevens of de relatie daartussen.

[TOC]

Normale vormen

Standaardisatie maakt gebruik van een reeks tests, normale vormen genoemd, om de optimale groepering van deze attributen te identificeren en uiteindelijk de reeks adequate relaties tot stand te brengen die de gegevensvereisten van een bedrijf ondersteunen

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

Eerste normale vorm (1fn)

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

Per definitie zal een relationele database altijd worden genormaliseerd naar de eerste normale vorm, omdat attributenwaarden altijd atomair zijn. Alle relaties in een database zijn in 1fn.

Kan u van dienst zijn: constant (programmeren): concept, typen, voorbeelden

Het verlaten van de database stimuleert echter eenvoudig een reeks problemen, zoals redundantie en mogelijke update -afwijkingen. De hoogste normale vormen werden ontwikkeld om deze problemen te verhelpen.

Tweede normale vorm (2fn)

Het gaat over het elimineren van de cirkelvormige eenheden uit een tafel. Er wordt gezegd dat een verhouding in 2fn staat als deze zich in 1FN bevindt en ook elk veld of kenmerk niet volledig afhankelijk is van de primaire sleutel, of meer specifiek, wordt ervoor gezorgd dat de tabel een enkel doel heeft.

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

Derde normale vorm (3fn)

Het gaat over het elimineren van transitieve afhankelijkheden uit een tabel. Dat wil zeggen, elimineren niet -key attributen die niet afhankelijk zijn van de primaire sleutel, maar van een ander kenmerk.

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

Herhaalde waarden moeten worden gezocht in de niet -key -attributen om ervoor te zorgen dat deze attributen die geen sleutel zijn, niet alleen afhankelijk zijn van de primaire sleutel.

Er wordt gezegd dat attributen onderling onafhankelijk zijn als geen van hen functioneel afhankelijk is van een combinatie van anderen. Deze wederzijdse onafhankelijkheid garandeert dat attributen individueel kunnen worden bijgewerkt, zonder het gevaar te beïnvloeden een ander kenmerk.

Daarom moet deze, om een ​​databaseverhouding in de derde normale vorm te bevinden, te voldoen aan:

- Alle 2FN -vereisten.

Kan u van dienst zijn: ICT in het huis

- Als er attributen zijn die niet gerelateerd zijn aan de primaire sleutel, moeten deze worden geëlimineerd en in een afzonderlijke tabel worden geplaatst, waarbij beide tabellen via een externe sleutel worden gerelateerd. Dat wil zeggen, er zou geen transitieve afhankelijkheid moeten zijn.

Voorbeelden van de derde normale vorm

voorbeeld 1

Wees de studententabel, wiens primaire sleutel de identificatie van de student (ID_ESTUDIANT) is en bestaat uit de volgende attributen: Student Naam, Street, City en_postal Code, die voldoet aan de voorwaarden om 2fn te zijn 2fn.

In dit geval hebben Street en City geen directe relatie met de primaire identiteitssleutel, omdat ze niet direct gerelateerd zijn aan de student, maar ze zijn volledig afhankelijk van de postcode.

Aangezien de student zich op de site bevindt die wordt bepaald door Code_Postal, zijn straat en stad gerelateerd aan dit kenmerk. Vanwege deze tweede graad van afhankelijkheid is het niet nodig om deze attributen in de studententabel op te slaan.

Maak een nieuwe tabel

Stel dat er meerdere studenten zijn in dezelfde postcode, waarbij de studenttabel een enorme hoeveelheid records heeft, en het is noodzakelijk om de naam van de straat of de stad te wijzigen, dan moet deze straat of stad worden doorzocht en bijgewerkt tafelstudent.

Als het bijvoorbeeld nodig is om de "El Limón" -straat te wijzigen voor "El Limón II", zal het moeten zoeken naar "El Limón" in de studententafel en het vervolgens bijwerken naar "El Limón II".

Zoek in een enorme tabel en update De unieke of meerdere records vereisen veel tijd en hebben daarom invloed op de databaseprestaties.

In plaats daarvan kunnen deze details worden verkregen in een afzonderlijke (ansichtkaart) tabel die gerelateerd is aan de studententabel met behulp van het kenmerk Code_Postal.

De posttabel heeft een relatief kleinere hoeveelheid records en hoeft alleen te updaten zodra deze posttabel. Dit wordt automatisch weerspiegeld in de studententabel, waardoor de databases en het overleg worden vereenvoudigd. De tabellen zullen dus in 3fn zijn:

Het kan u van dienst zijn: metabusters: kenmerken, typen en voorbeelden

Voorbeeld 2

Wees de volgende tabel met het veld Num_project als de belangrijkste sleutel en met herhaalde waarden in attributen die niet sleutel zijn.

De telefoonwaarde wordt herhaald telkens wanneer de naam van een manager wordt herhaald. Dit komt omdat het telefoonnummer slechts een tweede -gradenafhankelijkheid heeft met het projectnummer. Het hangt echt af van de manager, en dit hangt op zijn beurt af van het projectnummer, wat een transitieve afhankelijkheid maakt.

Het kenmerk Manager_project kan geen mogelijke sleutel zijn in de tabelprojecten omdat dezelfde manager meer dan één project afhandelt. De oplossing hiervoor is om het kenmerk te elimineren met herhaalde gegevens (telefoon), waardoor een afzonderlijke tabel wordt gecreëerd.

De bijbehorende attributen moeten worden gegroepeerd, waardoor een nieuwe tabel wordt gecreëerd om ze op te slaan. De gegevens worden ingevoerd en wordt geverifieerd dat de herhaalde waarden geen deel uitmaken van de primaire sleutel. De primaire sleutel voor elke tabel is vastgesteld en, indien nodig, worden externe toetsen toegevoegd.

Om aan de derde normale vorm te voldoen, wordt een nieuwe tabel (managers) gemaakt om het probleem op te lossen. Beide tabellen zijn gerelateerd via het veld Manager_project:

Referenties

1. Teradata (2019). Eerste, tweede en derde normale vormen. Genomen uit: documenten.Teradata.com.
2. Cup -zelfstudie (2019). Normale derde vorm (3NF). Genomen uit: tutorialcup.com.
3. Database Dev (2015). Normale derde vorm (3NF) - Normaliseren van uw database. Genomen uit: Databasedev.co.Uk.
4. Relationeel DB -ontwerp (2019). Inleiding tot derde normale vorm. Genomen uit: relationaldbdesign.com.
5. Dummies (2019). SQL Eerste, tweede en derde normale vormen. Genomen van: dummies.com.