Volledige funksionele afhanklikheid in databasis normalisering

'N Volledige funksionele afhanklikheid is 'n toestand van databasis normalisering wat gelykstaande is aan die normalisasie standaard van die tweede normale vorm (2NF) . Kortliks beteken dit dat dit aan die vereistes van Eerste Normale Vorm (1NF) voldoen, en alle nie-sleutelkenmerke is ten volle funksioneel afhanklik van die primêre sleutel.

Dit is nie so ingewikkeld soos dit mag klink nie. Kom ons kyk meer hieroor.

Opsomming van Eerste Normale Vorm

Voordat 'n databasis ten volle funksioneel afhanklik is, moet dit eers voldoen aan Eerste Normale Vorm .

Dit beteken dat elke kenmerk 'n enkele atoomwaarde moet bevat.

Byvoorbeeld, die volgende tabel voldoen nie aan 1NF nie, omdat die werknemer Tina aan twee liggings gekoppel is, beide in 'n enkele sel:

Eerste Normale Vorm Nie-Voldoening
werknemer plek
John Los Angeles
Tina Los Angeles, Chicago

Om hierdie ontwerp toe te laat, kan die data-opdaterings of inskrywings negatief beïnvloed. Om 1NF-nakoming te verseker, herrangskik die tabel sodat alle eienskappe (of kolomme selle) 'n enkele waarde hou:

Eerste Normale Vorm Nakoming
werknemer plek
John Los Angeles
Tina Los Angeles
Tina Chicago

Maar 1NF is steeds nie genoeg om probleme met die data te vermy nie.

Hoe 2NF werk om volle afhanklikheid te verseker

Om ten volle afhanklik te wees, moet alle nie-kandidaat-sleutelkenmerke afhang van die primêre sleutel. (Onthou, 'n kandidaat sleutel kenmerk is enige sleutel (byvoorbeeld 'n primêre of vreemde sleutel) wat gebruik word om 'n databasis rekord uniek te identifiseer.

Databasisontwerpers gebruik 'n notasie om die afhanklike verhoudings tussen eienskappe te beskryf:

As attribuut A die waarde van B bepaal, skryf ons hierdie A -> B - wat beteken dat B funksioneel van A afhanklik is. In hierdie verhouding bepaal A die waarde van B, terwyl B afhanklik is van A.

Byvoorbeeld, in die volgende Werknemersdepartement- tabel is WerknemerID en DeptID beide kandidaat sleutels: WerknemerID is die primêre sleutel van die tabel terwyl DeptID 'n vreemde sleutel is.

Enige ander kenmerk - in hierdie geval, EmployeeName en DeptName - moet afhang van die primêre sleutel om die waarde daarvan te verkry.

Werknemersdepartemente
Werknemer ID EmployeeName DeptID DeptName
Emp1 John Dept001 Finansies
Emp2 Tina Dept003 verkope
Emp3 Carlos Dept001 Finansies

In hierdie geval is die tabel nie heeltemal afhanklik nie, aangesien die Werknemersnaam afhanklik is van die primêre sleutel EmployeeID, hang die DeptName in plaas van die DeptID. Dit word gedeeltelike afhanklikheid genoem .

Om hierdie tafel te maak voldoen aan 2NF, moet ons die data in twee tabelle skei:

Werknemers
Werknemer ID EmployeeName DeptID
Emp1 John Dept001
Emp2 Tina Dept003
Emp3 Carlos Dept001

Ons verwyder die DeptName-kenmerk uit die tabel Werknemers en skep 'n nuwe tabel Departemente :

departemente
DeptID DeptName
Dept001 Finansies
Dept002 Menslike hulpbronne
Dept003 verkope

Nou is die verhoudings tussen die tafels volledig afhanklik, of in 2NF.

Hoekom Volle Afhanklikheid Is Belangrik

Volledige afhanklikheid tussen databasis eienskappe help om data integriteit te verseker en data-afwykings te vermy.

Kyk byvoorbeeld na die tabel in die afdeling hierbo wat slegs by 1NF pas. Hier is dit weer:

Eerste Normale Vorm Nakoming
werknemer plek
John Los Angeles
Tina Los Angeles
Tina Chicago

Tina het twee rekords. As ons een werk sonder om te besef dat daar twee is, sal die resultaat onbestaanbare data wees.

Of, wat as ons 'n werknemer by hierdie tabel wil byvoeg, maar ons ken die ligging nog nie? Ons kan dalk nie toegelaat word om 'n nuwe werknemer toe te voeg nie, as die ligging-attribuut nie NULL-waardes toelaat nie.

Volle afhanklikheid is egter nie die hele prentjie nie, wanneer dit by normalisering kom. U moet seker maak dat u databasis in Derde Normale Vorm (3NF) is.