Een volledig functionele afhankelijkheid is een toestand van databasormormalisatie die gelijk is aan de normalisatienorm van Second Normal Form (2NF). In het kort betekent dit dat het voldoet aan de vereisten van First Normal Form (1NF) en dat alle niet-key-attributen volledig functioneel afhankelijk zijn van de primaire sleutel.
Dit is niet zo ingewikkeld als het misschien klinkt. Laten we dit in meer detail bekijken.
Samenvatting van First Normal Form
Voordat een database volledig functioneel afhankelijk kan zijn, moet deze eerst voldoen aan First Normal Form.
Dit alles betekent dat elk attribuut een enkele atomaire waarde moet hebben.
De volgende tabel doet dat bijvoorbeeld niet voldoen aan 1NF, omdat de medewerker Tina is gekoppeld aan twee locaties, beide in één cel:
| werknemer | Plaats |
|---|---|
| John | Los Angeles |
| Tina | Los Angeles, Chicago |
Als u dit ontwerp toestaat, kan dit een negatieve invloed hebben op gegevensupdates of -invoeren. Om de conformiteit van 1NF te garanderen, herschikt u de tabel zodat alle kenmerken (of kolomcellen) één waarde bevatten:
Eerste Normale Formulier Compliantie
Maar 1NF is nog steeds niet genoeg om problemen met de gegevens te voorkomen.
Hoe 2NF werkt om volledige afhankelijkheid te garanderen
Om volledig afhankelijk te zijn, moeten alle niet-kandidaat-sleutelattributen afhankelijk zijn van de primaire sleutel. (Denk eraan, een kandidaatsleutelattribuut is elke sleutel (bijvoorbeeld een primaire of externe sleutel) die wordt gebruikt om een databaserecord uniek te identificeren.
Databaseontwerpers gebruiken een notatie om de afhankelijke relaties tussen kenmerken te beschrijven:
Als attribuut A de waarde van B bepaalt, schrijven we ditA -> B- wat betekent dat B functioneel afhankelijk is van A. In deze relatie bepaalt A de waarde van B, terwijl B afhangt van A.
Bijvoorbeeld in het volgende Werknemersafdelingen tabel, EmployeeID en DeptID zijn beide kandidaat-sleutels: EmployeeID is de primaire sleutel van de tabel, terwijl DeptID een externe sleutel is.
Elk ander kenmerk - in dit geval EmployeeName en DeptName - moet afhankelijk zijn van de primaire sleutel om de waarde ervan te verkrijgen.
| EmployeeID | Naam werknemer | DeptID | DeptName |
|---|---|---|---|
| EMP1 | John | Dept001 | Financiën |
| EMP2 | Tina | Dept003 | verkoop |
| eMP3 | Carlos | Dept001 | Financiën |
In dit geval is de tabel niet volledig afhankelijk omdat, terwijl de EmployeeName afhankelijk is van de primaire sleutel EmployeeID, de DeptName in plaats daarvan afhangt van de DeptID. Dit heet gedeeltelijke afhankelijkheid .
Om deze tabel te laten voldoen aan 2NF, moeten we de gegevens in twee tabellen scheiden:
| EmployeeID | Naam werknemer | DeptID |
|---|---|---|
| EMP1 | John | Dept001 |
| EMP2 | Tina | Dept003 |
| eMP3 | Carlos | Dept001 |
We verwijderen het DeptName-attribuut van de werknemers tabel en maak een nieuwe tabel afdelingen :
| DeptID | DeptName |
|---|---|
| Dept001 | Financiën |
| Dept002 | Personeelszaken |
| Dept003 | verkoop |
Nu zijn de relaties tussen de tabellen volledig afhankelijk, of in 2NF.
Waarom volledige afhankelijkheid belangrijk is
Volledige afhankelijkheid van databasekenmerken helpt de gegevensintegriteit te waarborgen en gegevensanomalieën te voorkomen.
Bekijk bijvoorbeeld de tabel in het bovenstaande gedeelte die alleen aan 1NF voldoet. Hier is het weer:
| werknemer | Plaats |
|---|---|
| John | Los Angeles |
| Tina | Los Angeles |
| Tina | Chicago |
Tina heeft twee records. Als we een update uitvoeren zonder te beseffen dat er twee zijn, zou dit resulteren in inconsistente gegevens.
Of, wat als we een medewerker aan deze tabel willen toevoegen, maar we weten de locatie nog niet? We zijn misschien niet toegestaan om een nieuwe werknemer toe te voegen als het locatiekenmerk NULL-waarden niet toestaat.
Volledige afhankelijkheid is echter niet het hele plaatje als het gaat om normalisatie. U moet ervoor zorgen dat uw database zich in Third Normal Form (3NF) bevindt.
