Een volledige functionele afhankelijkheid is een toestand van databasenormalisatie die overeenkomt met de normalisatiestandaard van Second Normal Form (2NF). Kort gezegd betekent dit dat het voldoet aan de vereisten van First Normal Form (1NF), en dat alle niet-sleutelattributen functioneel volledig afhankelijk zijn van de primaire sleutel. Dit is niet zo ingewikkeld als het klinkt. Laten we dit in meer detail bekijken.
Samenvatting van de eerste normaalvorm
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 bevatten. De volgende tabel voldoet bijvoorbeeld niet 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 negatief effect hebben op gegevensupdates of invoer. Om 1NF-conformiteit te garanderen, herschikt u de tabel zodat alle attributen (of kolomcellen) één enkele waarde bevatten:
| Werknemer | Plaats |
| John | Los Angeles |
| Tina | Los Angeles |
| Tina | Chicago |
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-kandidaatsleutelkenmerken afhankelijk zijn van de primaire sleutel. 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 attributen te beschrijven: Als attribuut A de waarde van B bepaalt, schrijven we dit A -> B, wat betekent dat B functioneel afhankelijk is van A. In deze relatie bepaalt A de waarde van B, terwijl B afhankelijk is van A. Bijvoorbeeld in de volgende Medewerkersafdelingen tafel, Werknemer-ID en Afd.ID zijn beide kandidaatsleutels: Werknemer-ID is de primaire sleutel van de tabel terwijl Afd.ID is een vreemde sleutel. Alle andere attributen, in dit geval Naam werknemer en Afd.Naam—moet afhankelijk zijn van de primaire sleutel om zijn waarde te verkrijgen.
| Werknemer-ID | Naam werknemer | Afd.ID | Afd.Naam |
| 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 Werknemer-ID, de Afd.Naam hangt in plaats daarvan af van de Afd.ID. Dit wordt gedeeltelijke afhankelijkheid genoemd. Om deze tabel aan 2NF te laten voldoen, moeten we de gegevens in twee tabellen scheiden: een tabel Medewerkers en een tabel Afdelingen. Dit is de tabel Medewerkers:
| Werknemer-ID | Naam werknemer | Afd.ID |
| Emp1 | John | Dept001 |
| Emp2 | Tina | Dept003 |
| Emp3 | Carlos | Dept001 |
Wij verwijderen de Afd.Naam attribuut uit de tabel Medewerkers en maak een nieuwe tabel Afdelingen:
| Afd.ID | Afd.Naam |
| 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 tussen databasekenmerken helpt de gegevensintegriteit te waarborgen en gegevensafwijkingen te voorkomen. Kijk bijvoorbeeld eens naar de tabel in het bovenstaande gedeelte die alleen geldt voor 1NF. Hier is het dan nog een keer:
| Werknemer | Plaats |
| John | Los Angeles |
| Tina | Los Angeles |
| Tina | Chicago |
Tina heeft twee records. Als we er een bijwerken zonder te beseffen dat het er twee zijn, zou het resultaat inconsistente gegevens zijn. Of, wat als we een medewerker aan deze tafel willen toevoegen, maar de locatie nog niet weten? Het kan zijn dat we zelfs geen nieuwe medewerker mogen toevoegen als de Plaats kenmerk staat geen NULL-waarden toe. Volledige afhankelijkheid is echter niet het hele plaatje als het gaat om normalisatie. U moet ervoor zorgen dat uw database de derde normale vorm (3NF) heeft. Meer van Lifewire
-
Een database in de derde normale vorm (3NF) plaatsen
-
Een database in de eerste normale vorm zetten
-
Een-op-veel-relaties in een database
-
Basisprincipes van databasenormalisatie
-
Wat is transitieve afhankelijkheid in een database?
-
Wat zijn database-afhankelijkheden?
-
Wat is een databaserelatie?
-
Woordenlijst van algemene databasetermen
-
Wat is de Boyce-Codd-normale vorm (BCNF)?
-
Functionele afhankelijkheid in een database
-
Een databasekenmerk definieert de eigenschappen van een tabel
-
Meerwaardige afhankelijkheid in databaseontwerp
-
Feiten versus Afmetingentabellen in een database
-
Hoe referentiële integriteit zorgt voor databaseconsistentie
-
Determinanten en hun rol in een database
-
Inleiding tot databaserelaties
Uw privacyrechten
Lifewire en onze externe partners gebruiken cookies en verwerken persoonlijke gegevens zoals unieke identificatiegegevens op basis van uw toestemming om informatie op een apparaat op te slaan en/of te openen, gepersonaliseerde advertenties weer te geven en voor inhoudsmeting, doelgroepinzicht en productontwikkeling. Klik hieronder om uw toestemmingskeuzes voor Lifewire.com te wijzigen of in te trekken, inclusief uw recht om bezwaar te maken wanneer een legitiem belang wordt gebruikt. U kunt uw instellingen op elk moment bijwerken via de link “EU-privacy” onderaan elke pagina. Deze keuzes worden wereldwijd aan onze partners gesignaleerd en hebben geen invloed op de browsegegevens. Lijst met partners (leveranciers)
Wij en onze partners verwerken gegevens om:
Scan actief apparaatkenmerken voor identificatie. Gebruik nauwkeurige geolocatiegegevens. Informatie op een apparaat opslaan en/of openen. Selecteer gepersonaliseerde inhoud. Maak een gepersonaliseerd inhoudsprofiel. Meet advertentieprestaties. Selecteer basisadvertenties. Maak een gepersonaliseerd advertentieprofiel. Selecteer gepersonaliseerde advertenties. Pas marktonderzoek toe om doelgroepinzichten te genereren. Inhoudsprestaties meten. Ontwikkelen en verbeteren van producten. Lijst met partners (leveranciers)