Cursus
In databases treedt een transitieve afhankelijkheid op wanneer één attribuut in een tabel afhankelijk is van een ander attribuut, dat op zijn beurt afhankelijk is van de primaire sleutel. Transitieve afhankelijkheid is een probleem bij database-normalisatie omdat het leidt tot dataproblemen, zoals update-, invoeg- en verwijderingsanomaliën, die we in dit artikel zullen verkennen.
Als je na dit artikel meer wilt leren, raad ik de cursus Database Design van DataCamp aan om vertrouwd te raken met relationele databases en het opslaan van data in een database. Bekijk ook onze tutorial Normalization in SQL om meer te leren over de normale vormen in SQL, de meest gebruikte taal voor het beheren van relationele databases in deze context.
Transitieve afhankelijkheid in databases begrijpen
In relationele databases treedt een transitieve afhankelijkheid op wanneer één attribuut indirect afhankelijk is van een ander via een tussenliggend attribuut. Dit probleem betekent dat de waarde van één kolom indirect kan worden afgeleid uit de waarden van twee andere kolommen. Kijk naar de volgende tabel, genaamd DataCamp_Programs:
| Course_or_Skill_Track | Instructor | Instructor_Title |
|---|---|---|
| Data Manipulation in SQL | Mona Khalil | Data Scientist |
| SQL Fundamentals | Mona Khalil | Data Scientist |
| Introduction to SQL | Izzy Weber | Data Coach |
Uit deze tabel blijkt:
-
Course_or_Skill_Track→Instructor: Als we de course of skill track kennen, kennen we de docent. -
Instructordoet niet →Course_or_Skill_Track: Soms geven docenten meer dan één cursus of track. -
Instructor→Instructor_Title: Elke docent heeft een titel.
Daarom is Course_or_Skill_Track → Instructor_Title een transitieve afhankelijkheid.
Waarom transitieve afhankelijkheden problemen veroorzaken
Transitieve afhankelijkheden kunnen databaseproblemen veroorzaken, vooral gerelateerd aan dataredundantie, anomalieën en inconsistentie.
Dataredundantie
Dataredundantie treedt op wanneer dezelfde data onnodig wordt herhaald in de database, wat tot inefficiënties leidt. In het voorbeeld van de tabel DataCamp_Programs wordt de titel van de docent meerdere keren opgeslagen voor elke cursus die hij of zij geeft. Deze herhaling verspilt opslagruimte en maakt de database lastiger te onderhouden.
Data-anomalieën
Laten we nu kijken naar update-, invoeg- en verwijderingsproblemen.
Update-anomalieën
Update-anomalieën treden op wanneer wijzigingen in data op meerdere plaatsen moeten worden doorgevoerd door redundantie. Dit leidt tot inconsistenties als sommige instanties worden bijgewerkt terwijl andere over het hoofd worden gezien. Stel bijvoorbeeld dat we een SQL-query gebruiken om de tabel DataCamp_Programs bij te werken omdat de titel van Mona Khalil is gewijzigd in Lead Data Scientist. Je zou dan elke rij waarin haar titel voorkomt handmatig moeten bijwerken. Als zelfs maar één instantie wordt gemist, bevat de database tegenstrijdige informatie over haar huidige titel.
| Course_or_Skill_Track | Instructor | Instructor_Title |
|---|---|---|
| Data Manipulation in SQL | Mona Khalil | Lead Data Scientist |
| SQL Fundamentals | Mona Khalil | Data Scientist |
| Introduction to SQL | Izzy Weber | Data Coach |
Invoeg-anomalieën
Invoeg-anomalieën treden op wanneer je geen data kunt invoegen in de database omdat andere vereiste data ontbreekt. In andere gevallen kun je wel data invoegen, maar dwingt de structuur van de tabel je om irrelevante, redundante of ontbrekende informatie op te nemen, zoals in het onderstaande voorbeeld:
| Course_or_Skill_Track | Instructor | Instructor_Title |
|---|---|---|
| Data Manipulation in SQL | Mona Khalil | Data Scientist |
| SQL Fundamentals | Mona Khalil | Data Scientist |
| Introduction to SQL | Izzy Weber | Data Coach |
| Nader te bepalen | Liam Cooper | Data Analyst |
Verwijderings-anomalieën
Verwijderings-anomalieën treden op wanneer het verwijderen van een record per ongeluk waardevolle informatie uit de database verwijdert. Het verwijderen van het record met Izzy Weber verwijdert bijvoorbeeld ook de docenentitel, wat kan leiden tot dataverlies, omdat je mogelijk niet langer het volledige spectrum aan titels in het systeem hebt. Hier hebben we mogelijk Data Coach geheel uit het systeem verwijderd zonder dat te bedoelen.
| Course_or_Skill_Track | Instructor | Instructor_Title |
|---|---|---|
| Data Manipulation in SQL | Mona Khalil | Data Scientist |
| SQL Fundamentals | Mona Khalil | Data Scientist |
Transitieve afhankelijkheden verwijderen met 3NF
In de context van databases organiseert normalisatie de data om redundantie te minimaliseren en de dataintegriteit te verbeteren. Daarom worden transitieve afhankelijkheden vaak besproken in de context van de derde normale vorm (3NF), een normalisatietechniek die afhankelijkheden elimineert om het probleem van transitieve afhankelijkheid aan te pakken.
De derde normale vorm is een niveau van database-normalisatie dat transitieve afhankelijkheden elimineert en ervoor zorgt dat elk niet-sleutelattribuut alleen afhankelijk is van de primaire sleutel. Dit helpt redundantie en de fouten door transitieve afhankelijkheden te voorkomen. Overweeg de volgende stappen bij het normaliseren van een databaseschema.
Transitieve afhankelijkheden identificeren
Om transitieve afhankelijkheden in je database op te sporen, kun je het proces opsplitsen:
- Controleer functionele afhankelijkheden van de primaire sleutel: Begin met het identificeren van alle functionele afhankelijkheden waarbij attributen direct op de primaire sleutel steunen. Deze stap helpt je te focussen op de hoofdrelaties in je tabel.
- Zoek naar indirecte afhankelijkheden: Controleer vervolgens of er niet-sleutelattributen (die geen deel uitmaken van de primaire sleutel) afhankelijk zijn van andere niet-sleutelattributen. Als je merkt dat het ene niet-sleutelattribuut afhankelijk is van het andere, dat op zijn beurt afhankelijk is van de primaire sleutel, heb je een transitieve afhankelijkheid gevonden.
- Test op redundantie of anomalieën: Denk ten slotte na of deze indirecte afhankelijkheid dataredundantie introduceert of updates ingewikkelder maakt.
Tabellen opsplitsen
Zodra je de transitieve afhankelijkheden hebt geïdentificeerd, moet je de tabellen opsplitsen om ze te elimineren. Je splitst de tabel op in kleinere tabellen waarin niet-sleutelattributen direct afhankelijk zijn van de primaire sleutel. Je behoudt ook de relatie tussen de tabellen door te koppelen via vreemde sleutels.
Zo kun je de tabel DataCamp_Programs in twee tabellen opsplitsen om deze te normaliseren en de transitieve afhankelijkheid te elimineren. Zoals je ziet, splitsen we de tabel in tweeën. instructor wordt de sleutel om de twee te koppelen.
Tabel 1: courses_table
| Course or Skill Track | Instructor |
|---|---|
| Data Manipulation in SQL | Mona Khalil |
| SQL Fundamentals | Mona Khalil |
| Introduction to SQL | Izzy Weber |
Tabel 1: instructors_table
| Instructor | Instructor_Title |
|---|---|
| Mona Khalil | Data Scientist |
| Izzy Weber | Data Coach |
Deze structuur elimineert de transitieve afhankelijkheid, waarbij Instructor_Title eerder afhankelijk was van Course_or_Skill_Track via Instructor. Nu is Instructor_Title alleen afhankelijk van Instructor.
Hoe je transitieve afhankelijkheden voorkomt
Bij het ontwerpen van je database is het belangrijk om transitieve afhankelijkheden te vermijden om efficiëntie, schaalbaarheid en integriteit van data te behouden. De volgende best practices minimaliseren het risico op redundantie, anomalieën en inconsistentie.
- Normalisatie tijdens schema-ontwerp: Als je je database vanuit het schema ontwerpt, is het belangrijk om in een vroeg stadium rekening te houden met de derde normale vorm (3NF). Deze aanpak helpt transitieve afhankelijkheid te verminderen door de normalisatietechniek toe te passen.
- Regelmatige schema-audits: Na het creëren van je database is het belangrijk om regelmatig audits uit te voeren om te waarborgen dat deze vrij blijft van transitieve afhankelijkheden.
- Vermijd relaties te simplistisch te modelleren: Breng altijd de relaties in kaart en scheid de entiteiten correct in verschillende tabellen om verschillende informatie op te slaan.
Conclusie
Transitieve afhankelijkheden in databases treden op wanneer een attribuut in een tabel afhankelijk is van een ander attribuut, dat afhankelijk is van de primaire sleutel. Transitieve afhankelijkheid beïnvloedt altijd de efficiëntie van de database door redundantie, inconsistenties en anomalieën te introduceren. Als developer is het belangrijk om transitieve afhankelijkheden te identificeren en te elimineren voor dataintegriteit. Je moet transitieve afhankelijkheden ook tijdens het database-ontwerp identificeren en wegnemen. Het bereiken van de derde normale vorm (3NF) helpt je databases te optimaliseren en de efficiëntie te verbeteren.
Als je je vaardigheden in database-ontwerp wilt verbeteren, raad ik de DataCamp-cursus Creating PostgreSQL Databases aan om meer te leren over schema-ontwerp en toegangsbeheer in databases. Als je je databasebeheer-skills voor big data wilt uitbreiden, raad ik tot slot onze cursus Introduction to Data Modeling in Snowflake aan om meer te leren over relaties, dimensioneel modelleren en data vaults voor het bouwen van efficiënte cloud datawarehouses.
Veelgestelde vragen over transitieve afhankelijkheid
Wat is het verschil tussen functionele en transitieve afhankelijkheden?
Een functionele afhankelijkheid treedt op wanneer één attribuut rechtstreeks afhankelijk is van de primaire sleutel. Een transitieve afhankelijkheid treedt op wanneer een niet-sleutelattribuut afhankelijk is van een ander niet-sleutelattribuut, dat op zijn beurt afhankelijk is van de primaire sleutel.
Waarom zijn transitieve afhankelijkheden problematisch?
Transitieve afhankelijkheden leiden tot dataredundantie en anomalieën, zoals update-, invoeg- en verwijderingsanomaliën.
Wat is datanormalisatie?
Datanormalisatie is het proces waarbij een database in tabellen en kolommen wordt georganiseerd om dataredundantie te verminderen en de dataintegriteit te verbeteren.
Wat is de derde normale vorm (3NF)?
De derde normale vorm (3NF) is een normalisatietechniek zonder transitieve afhankelijkheden. In 3NF moet elk niet-prime attribuut alleen afhankelijk zijn van de primaire sleutel, zodat er geen indirecte afhankelijkheden bestaan.

