SQL eerste, tweede en derde normale vormen - dummies

Er zijn drie bronnen van wijzigingsanomalieën in SQL Deze worden gedefinieerd als eerste, tweede en derde normale vormen (1NF, 2NF, 3NF). Deze normale vormen fungeren als remedies voor het wijzigen van anomalieën.

Eerste normaalformulier

Om in de eerste normaalvorm (1NF) te zijn, moet een tabel de volgende eigenschappen hebben:

• De tabel is tweedimensionaal met rijen en kolommen.

• Elke rij bevat gegevens die betrekking hebben op iets of een deel van een ding.

• Elke kolom bevat gegevens voor een enkel attribuut van het ding dat het beschrijft.

• Elke cel (kruising van een rij en een kolom) van de tabel mag slechts één waarde hebben.

• Inzendingen in elke kolom moeten allemaal van hetzelfde type zijn. Als de invoer in een rij van een kolom bijvoorbeeld een werknemersnaam bevat, moeten alle andere rijen ook werknemersnamen in die kolom bevatten.

• Elke kolom moet een unieke naam hebben.

• Geen twee rijen kunnen identiek zijn (dat wil zeggen, elke rij moet uniek zijn).

• De volgorde van de kolommen en de volgorde van de rijen zijn niet significant.

Een tabel (relatie) in de eerste normale vorm is immuun voor sommige soorten aanpassingsanomalieën, maar is nog steeds onderhevig aan andere. De SALES-tabel heeft de eerste normale vorm en de tabel is onderhevig aan schrapping en invoegafwijkingen. De eerste normale vorm kan in sommige toepassingen nuttig zijn, maar onbetrouwbaar in andere.

Tweede normale vorm

Om de tweede normale vorm te waarderen, moet u het idee van functionele afhankelijkheid begrijpen. Een functionele afhankelijkheid is een relatie tussen of tussen attributen. Eén attribuut is functioneel afhankelijk van een ander, als de waarde van het tweede attribuut de waarde van het eerste attribuut bepaalt. Als u de waarde van het tweede attribuut kent, kunt u de waarde van het eerste attribuut bepalen.

Stel dat een tabel attributen (kolommen) StandardCharge, NumberOfTests en TotalCharge heeft die betrekking hebben op de volgende vergelijking:

TotalCharge = StandardCharge * NumberOfTests

TotalCharge is functioneel afhankelijk van zowel StandardCharge als NumberOfTests. Als u de waarden van StandardCharge en NumberOfTests kent, kunt u de waarde van TotalCharge bepalen.

Elke tabel in de eerste normale vorm moet een unieke primaire sleutel hebben. Die sleutel kan uit een of meer kolommen bestaan. Een sleutel die uit meer dan één kolom bestaat, wordt een samengestelde sleutel genoemd. Om in de tweede normale vorm (2NF) te zijn, moeten alle niet-sleutelkenmerken afhankelijk zijn van de volledige sleutel. Dus elke relatie die zich in 1NF bevindt met een enkele attribuutsleutel bevindt zich automatisch in de tweede normale vorm.

Als een relatie een samengestelde sleutel heeft, moeten alle niet-sleutelkenmerken afhankelijk zijn van alle componenten van de sleutel. Als u een tabel hebt waarin sommige niet-sleutelkenmerken niet afhankelijk zijn van alle componenten van de sleutel, breek de tabel dan op in twee of meer tabellen zodat - in elk van de nieuwe tabellen - alle niet-sleutelkenmerken afhankelijk zijn van alle componenten van de primaire sleutel.

Geluid verwarrend? Bekijk een voorbeeld om zaken te verduidelijken. Bekijk de SALES-tabel. In plaats van slechts één aankoop voor elke klant op te nemen, voegt u een rij toe telkens wanneer een klant een artikel voor de eerste keer koopt. Een bijkomend verschil is dat charterklanten (die met Klant-ID-waarden van 1001 tot 1007) korting krijgen op de normale prijs.

Customer_ID identificeert niet eenduidig ​​een rij. In twee rijen is Customer_ID 1001. In twee andere rijen is Customer_ID 1010. De combinatie van de kolom Customer_ID en de kolom Product duiden op unieke wijze een rij aan. Deze twee kolommen samen zijn een samengestelde sleutel.

Als niet voor het feit dat sommige klanten in aanmerking komen voor een korting en andere niet, de tabel niet in een tweede normale vorm zou zijn, omdat Price (een niet-sleutelkenmerk) alleen afhankelijk zou zijn van een deel van de sleutel (Artikel). Omdat sommige klanten in aanmerking komen voor een korting, is de prijs afhankelijk van zowel het klantnummer als het product en staat de tabel in de tweede normale vorm.

Derde normale vorm

Tabellen in de tweede normale vorm zijn bijzonder kwetsbaar voor sommige typen van anomalieën van wijzigingen - in het bijzonder die afwijkingen die voortkomen uit transitieve afhankelijkheden.

A transitieve afhankelijkheid treedt op wanneer een attribuut afhankelijk is van een tweede attribuut, dat afhankelijk is van een derde attribuut. Verwijderingen in een tabel met een dergelijke afhankelijkheid kunnen ongewenst informatieverlies veroorzaken. Een relatie in de derde normale vorm is een relatie in de tweede normale vorm zonder transitieve afhankelijkheden.

Kijk nog eens naar de SALES-tabel, waarvan je weet dat deze in de eerste normale vorm is. Zolang u ingangen beperkt om slechts één rij toe te staan ​​voor elke Customer_ID, hebt u een primaire sleutel met één kenmerk en bevindt de tabel zich in de tweede normale vorm. De tabel is echter nog steeds onderhevig aan anomalieën. Wat als klant 1010 bijvoorbeeld niet tevreden is met chloorbleekmiddel en het item retourneert voor terugbetaling?

U wilt de derde rij uit de tabel verwijderen, waarin staat dat klant 1010 chloor bleekmiddel heeft gekocht. U hebt een probleem: als u die rij verwijdert, verliest u ook het feit dat chloor met chloor een prijs van $ 4 heeft. Deze situatie is een voorbeeld van een transitieve afhankelijkheid. Prijs is afhankelijk van het Product, dat op zijn beurt afhankelijk is van de primaire sleutel Customer_ID.

Het doorbreken van de SALES-tabel in twee tabellen lost het probleem van de transitieve afhankelijkheid op. De twee tabellen vormen een database die zich in de derde normale vorm bevindt.