'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:
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:
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.
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:
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 :
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:
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.