Funktionellt beroende i DBMS: Typer med exempel

By: Redaktionellt team Redaktionellt team
Hours Uppdaterad

⚡ Smart sammanfattning

Funktionellt beroende är en begränsning som avgör hur ett attribut relaterar till ett annat i ett databashanteringssystem. Den ligger till grund för normalisering genom att identifiera determinanter och beroenden, och den klassificeras i flervärdiga, triviala, icke-triviala och transitiva beroenden.

  • ➡️ Kärnidé: I X → Y fixerar determinanten X värdet på det beroende Y, skrivet med en pil.
  • 🏷️ Nyckelbegrepp: Determinant, beroende, axiom, dekomposition och union beskriver hur beroenden namnges och manipuleras.
  • 📐 Armstrongs axiom: Reflexivitet, augmentation och transitivitet härleder varje beroende som en mängd logiskt innebär.
  • 🔀 Fyra typer: Flervärderade, triviala, icke-triviala och transitiva beroenden beskriver vart och ett ett distinkt attributförhållande.
  • 🧹 Normaliseringslänk: Beroenden driver normalisering, vilket tar bort redundans och uppdateringsavvikelser.
  • 🔑 Stängning: Attributstängningen avslöjar kandidatnycklar och om ett beroende gäller.
  • ✅ Dra nytta: Bra beroenden signalerar bra design och skiljer kvalitetsscheman från dåliga.
Läs mer

Funktionellt beroende i DBMS

Vad är funktionellt beroende?

Funktionellt beroende (FD) är en begränsning som bestämmer relationen mellan ett attribut och ett annat attribut i ett databashanteringssystem (DBMS). Funktionellt beroende hjälper till att upprätthålla datakvaliteten i databasen. Det spelar en viktig roll för att skilja mellan bra och dålig databasdesign.

Ett funktionellt beroende betecknas med en pil ”→”. Det funktionella beroendet av Y på X representeras av X → Y. Låt oss förstå funktionellt beroende med ett exempel.

Exempel:

Anställningsnummer Anställd Namn Lön Ort
1 Dana 50000 San Francisco
2 Francis 38000 london
3 Andrew 25000 Tokyo

I det här exemplet, om vi känner till värdet på anställningsnummer, kan vi få fram anställningsnamn, ort, lön och så vidare. Med detta kan vi säga att ort, anställningsnamn och lön är funktionellt beroende av anställningsnummer.

Nyckelbegrepp

Här är några nyckeltermer för funktionellt beroende i en databas:

Nyckelbegrepp BESKRIVNING
Axiom Axiom är en uppsättning inferensregler som används för att härleda alla funktionella beroenden i en relationsdatabas.
Sönderfall En regel som föreslår att om du har en tabell som verkar innehålla två entiteter som bestäms av samma primärnyckel, bör du överväga att dela upp den i två olika tabeller.
Beroende Den visas på höger sida av diagrammet över funktionella beroenden.
determinanten Den visas på vänster sida av diagrammet över funktionella beroenden.
Union Det föreslår att om två tabeller är separata och primärnyckeln är densamma, bör du överväga att sätta ihop dem.

Regler för funktionella beroenden (Armstrongs axiom)

Nedan följer de tre viktigaste reglerna för funktionellt beroende i en databas. De är kända som Armstrongs axiom, och alla andra inferensregler kan härledas från dem.

  • Reflexiv regel: Om X är en mängd attribut och Y är en delmängd av X, så gäller X → Y.
  • Augmenteringsregel: När X → Y gäller och C är en attributmängd, gäller även XC → YC. Att lägga till attribut ändrar inte det grundläggande beroendet.
  • Transitivitetsregel: Liknar den transitiva regeln i algebra: om X → Y gäller och Y → Z gäller, så gäller även X → Z.

Tre ytterligare regler härleds från dessa och används ständigt i praktiken:

  • Unionsregel: Om X → Y och X → Z, då är X → YZ.
  • Nedbrytningsregel: Om X → YZ, då är X → Y och X → Z.
  • Pseudotransitivitetsregel: Om X → Y och WY → Z, då är WX → Z.

Att tillämpa dessa regler upprepade gånger på en uppsättning beroenden producerar dess förslutning, den kompletta uppsättningen beroenden som logiskt följer. Slutet av en attributuppsättning är också hur kandidatnycklar hittas, vilket kopplar direkt till studiet av DBMS-nycklar.

Missa inte:

Typer av funktionella beroenden i DBMS

Det finns huvudsakligen fyra typer av funktionella beroenden i DBMS:

  • Flervärdigt beroende
  • Trivialt funktionellt beroende
  • Icke-trivialt funktionellt beroende
  • Transitivt beroende

Flervärdigt beroende i DBMS

Flervärdiga beroenden uppstår i en situation där det finns flera oberoende flervärdiga attribut i en enda tabell. Ett flervärdigt beroende är en fullständig begränsning mellan två uppsättningar attribut i en relation, vilket kräver att vissa tupler finns. Betrakta följande exempel.

Exempel:

Bilmodell Maf_år Färg
H001 2017 Metallisk
H001 2017 Grön
H005 2018 Metallisk
H005 2018 Blå
H010 2015 Metallisk
H033 2012 Grå

I det här exemplet är Maf_year och Color oberoende av varandra men beroende av Car_model. Dessa två kolumner sägs ha flervärdesberoende på Car_model. Detta representeras som:

bilmodell → maj_år

bilmodell → färg

Trivialt funktionellt beroende i DBMS

Ett trivialt beroende är en mängd attribut som kallas trivialt om mängden attribut ingår i det attributet. Så, X → Y är ett trivialt funktionellt beroende om Y är en delmängd av X. Betrakta exemplet nedan.

Emp_id Emp_name
AS555 Harry
AS811 George
AS999 Kevin

Betrakta den här tabellen med två kolumner, Emp_id och Emp_name. {Emp_id, Emp_name} → Emp_id är ett trivialt funktionellt beroende, eftersom Emp_id är en delmängd av {Emp_id, Emp_name}.

Icke-trivialt funktionellt beroende i DBMS

Ett icke-trivialt beroende uppstår när A → B gäller och B inte är en delmängd av A. Om attributet B inte är en delmängd av attributet A anses beroendet vara icke-trivialt.

Företag CEO Ålder
Microsoft Satya Nadella 51
Google Sundar Pichai 46
Apple Tim Cook 57

Exempel:

{Företag} → {VD} (om vi känner till företaget, vet vi även namnet på VD:n). Men VD är inte en delmängd av företaget, och därför är det ett icke-trivialt funktionellt beroende.

Transitivt beroende i DBMS

Ett transitivt beroende är en typ av funktionellt beroende som uppstår när ett attribut indirekt bestäms av två funktionella beroenden. Betrakta exemplet nedan.

Företag CEO Ålder
Microsoft Satya Nadella 51
Google Sundar Pichai 46
alibaba Jack Ma 54

{Företag} → {VD} (om vi känner företaget, vet vi dess VD:s namn).

{VD} → {Ålder} (om vi känner VD:n, vet vi åldern).

Därför, enligt regeln om transitivt beroende, bör {Företag} → {Ålder} gälla, vilket är logiskt eftersom om vi vet företagsnamnet kan vi hitta åldern.

Obs: transitivt beroende kan endast förekomma i en relation av tre eller fler attribut.

Vad är normalisering?

Normalisering är en metod för att organisera data i en databas som hjälper dig att undvika dataredundans och avvikelser vid infogning, uppdatering och borttagning. Det är en process för att analysera relationsscheman baserat på deras olika funktionella beroenden och primärnyckel.

Normalisering är en inneboende del av relationsdatabasteorin. Det kan ha effekten att dela upp data i ytterligare tabeller så att varje fakta lagras en gång. Hela processen beskrivs i guiden till databasnormalisering, vilket bygger direkt på beroendetyperna ovan.

Fördelar med funktionellt beroende

  • Funktionellt beroende undviker dataredundans, så att samma data inte upprepas på flera platser i databas.
  • Det hjälper dig att upprätthålla kvaliteten på data i databasen.
  • Det hjälper dig att definiera databasers betydelser och begränsningar.
  • Det hjälper dig att identifiera dåliga designer.
  • Det hjälper dig att hitta fakta om databasdesignen.

Vanliga frågor

Determinanten är attributet till vänster om pilen som fixerar värdet. Den beroende är attributet till höger vars värde bestäms. I X → Y bestämmer X Y.

Ett funktionellt beroende fixerar ett enda värde för det beroende. Ett flervärdigt beroende tillåter en uppsättning oberoende värden, vilket är anledningen till att det behöver ett eget attribut och leder till fjärde normalformen.

Beräkna slutningen av en attributmängd med hjälp av beroendena. Om slutningen inkluderar alla attribut i relationen är den mängden en supernyckel; den minimala mängden är en kandidatnyckel.

Ja. Beroendeidentifieringsalgoritmer, vissa med hjälp av AI, skannar en datauppsättning och föreslår potentiella beroenden. En designer måste bekräfta dem, eftersom ett mönster som är sant i exempeldata kanske inte gäller som regel.

Den lagrar ett faktum om ett icke-nyckelattribut, så att uppdatera det riskerar avvikelser. Att ta bort transitiva beroenden är precis vad den tredje normalformen kräver, vilket håller varje faktum på ett ställe.

Sammanfatta detta inlägg med: