4.1 Inleiding
Door de databasetabellen om te zetten in gewone tabellen, kunt u nu de onderlinge relaties analyseren. Het aantal elementen dat interageert tussen twee gerelateerde tabellen wordt de kardinaliteit genoemd. Kardinaliteit helpt u te bepalen hoe efficiënt u uw gegevens in tabellen hebt gepartitioneerd.
Theoretisch kunnen alle entiteiten relaties met elkaar onderhouden, maar in de praktijk zijn er drie soorten relaties tussen entiteiten:
- Een op een
- Een te veel
- veel te veel
4.2 Een-op-een communicatie
Als er slechts één exemplaar van entiteit A is voor elk exemplaar van entiteit B, wordt er gezegd dat ze een één-op-één-relatie hebben (vaak aangeduid als "1:1"). Op ER-diagrammen wordt een dergelijke relatie aangegeven door een lijn met aan elk uiteinde een kleine balk:
Een 1:1-relatie geeft over het algemeen aan dat, tenzij u een goede reden hebt om ze gescheiden te houden, de gegevens van de twee tabellen het beste tot één kunnen worden gecombineerd.
In sommige omstandigheden is het echter redelijk om tabellen met 1:1-relaties te gebruiken. Als uw tabellen velden hebben met optionele gegevens, zoals beschrijvingen, en deze in veel gevallen leeg zijn, is het zinvol om alle beschrijvingen naar een aparte tabel te verplaatsen, waardoor u veelvoorkomende hiaten kunt wegwerken en de efficiëntie van uw database kunt vergroten .
Om de gegevens goed in kaart te brengen, moet u vervolgens ten minste één identieke kolom in elke tabel opnemen (hiervoor kunt u het beste een primaire sleutel kiezen).
4.3 Een-op-veel-relatie
Dit type relatie doet zich voor wanneer een record in de ene tabel is gekoppeld aan meerdere entiteiten in een andere. Eenzelfde klant kan bijvoorbeeld meerdere bestellingen plaatsen, of een bibliotheekbezoeker kan in één keer meerdere boeken lenen. Een-op-veel-relaties (of afgekort 1:M) worden uitgedrukt in een diagram met kraaienpootjesnotatie, zoals in het onderstaande voorbeeld:
Om een 1:M-relatie toe te passen bij het plannen van een database, voegt u eenvoudigweg de primaire sleutel uit de "één"-tabel toe als een attribuut aan de "veel"-tabel. Als de primaire sleutel zich in een andere tabel bevindt, wordt deze een "vreemde sleutel" genoemd. De tabel 'één' wordt beschouwd als de bovenliggende tabel, terwijl de tabel 'veel' wordt beschouwd als de onderliggende tabel.
4.4 Veel-op-veel-relatie
Wanneer meerdere entiteiten in één tabel kunnen worden verbonden met meerdere entiteiten in een andere, wordt ervan uitgegaan dat ze een veel-op-veel-relatie (of M:M-relatie) hebben. Zo'n relatie bestaat bijvoorbeeld tussen studenten en klassen, aangezien elke student verschillende lessen kan bijwonen, en dienovereenkomstig kunnen er veel studenten naar elke klas komen.
Op het ER-diagram wordt dit type relatie als volgt weergegeven:
Helaas is het niet mogelijk om zo'n relatie direct in de database te implementeren. Daarom moet het worden opgesplitst in twee een-op-veel-relaties.
Om dit te doen, moet u een nieuwe entiteit tussen de twee tabellen maken. Als er een M:M-relatie tot stand is gebracht tussen verkoop en producten, kan de nieuwe entiteit "verkochte producten" worden genoemd omdat deze de inhoud van elke verkoop weergeeft.
Met "verkochte goederen" en de tabel "verkoop" en de tabel "goederen" worden gekoppeld door type 1:M. In verschillende modellen worden dergelijke tussenliggende entiteiten anders genoemd: "verbindingstabellen", "associatieve entiteiten" of "knooppunttabellen".
Elk linktabelitem verbindt twee verschillende entiteiten van aangrenzende tabellen (en kan ook aanvullende informatie bevatten). Een koppelingstabel tussen leerlingen en klassen kan er bijvoorbeeld als volgt uitzien:
4.5 Verplicht of niet?
Een andere benadering van linkanalyse is om te bepalen welke van de verbonden entiteiten een vereiste is voor de aanwezigheid van een andere entiteit. De optionele schakelzijde is gemarkeerd met een cirkel op de kofferbak.
Wil een staat bijvoorbeeld zijn eigen vertegenwoordiger in de VN hebben, dan moet hij op de wereldkaart staan, maar de tegengestelde bewering zal onjuist zijn:
Twee entiteiten kunnen onderling afhankelijk zijn (dat wil zeggen, de een kan niet bestaan zonder de ander).
Recursieve koppelingen
Soms kan een tabel naar zichzelf verwijzen. Een werknemerstabel kan bijvoorbeeld een 'manager'-kenmerk hebben dat ons verwijst naar een andere werknemer in dezelfde tabel. Dit is de recursieve relatie.
Extra aansluitingen
Links worden als overbodig beschouwd als ze meer dan eens worden weergegeven. In de regel kan een ervan worden verwijderd zonder belangrijke informatie te verliezen. Als de entiteit "studenten" bijvoorbeeld niet alleen direct, maar ook indirect via "klassen" is verbonden met de entiteit "leraren", is het logisch om de relatie tussen de entiteiten "studenten" en "leraren" te verwijderen. Deze beslissing wordt gerechtvaardigd door het feit dat het mogelijk is om studenten alleen via klassen aan leraren toe te wijzen.
4.6 Referentiële integriteit van gegevens
Bij het wijzigen van primaire en externe sleutels moet men rekening houden met een aspect als referentiële integriteit van gegevens . Het belangrijkste idee is om twee tabellen in een database te houden die dezelfde gegevens consistent opslaan.
Gegevensintegriteit vertegenwoordigt correct opgebouwde relaties tussen tabellen met een correcte koppeling ertussen. In welke gevallen kan de gegevensintegriteit worden geschonden:
- Verwijdering anomalie . Treedt op wanneer een rij wordt verwijderd uit de hoofdtabel. In dit geval blijft de externe sleutel uit de afhankelijke tabel verwijzen naar de verwijderde rij uit de hoofdtabel.
- Anomalie van insertie . Treedt op wanneer een rij wordt ingevoegd in een afhankelijke tabel. In dit geval komt de externe sleutel van de afhankelijke tabel niet overeen met de primaire sleutel van een van de rijen van de hoofdtabel.
- Anomalie bijwerken . Bij een dergelijke anomalie kunnen meerdere rijen van één tabel gegevens bevatten die bij hetzelfde object horen. Als u de gegevens in de ene rij wijzigt, kunnen deze in conflict komen met de gegevens uit een andere rij.
Verwijdering anomalie
Om de verwijderingsafwijking op te lossen, moet de refererende sleutel worden ingesteld op een van de volgende twee beperkingen:
Als voor een rij uit een afhankelijke tabel noodzakelijkerwijs een rij uit de hoofdtabel nodig is, wordt de refererende sleutel ingesteld op trapsgewijze verwijdering. Dat wil zeggen, wanneer een rij wordt verwijderd uit de hoofdtabel, worden de bijbehorende rij(en) verwijderd uit de afhankelijke tabel.
Als een rij uit een afhankelijke tabel geen relatie toestaat met een rij uit de hoofdtabel (dat wil zeggen, een dergelijke relatie is optioneel), dan wordt de refererende sleutel ingesteld op NULL wanneer de gerelateerde rij wordt verwijderd uit de hoofdtabel. De kolom met externe sleutels moet een null-waarde hebben.
Invoeging anomalie
Om de invoegafwijking bij het toevoegen aan een tabel met afhankelijke gegevens op te lossen, moet de kolom die de externe sleutel vertegenwoordigt null-waarden hebben. En dus, als het object dat wordt toegevoegd geen verbinding heeft met de hoofdtabel, heeft de externe sleutelkolom een NULL-waarde.
Anomalieën bijwerken
Om het update-anomalieprobleem op te lossen, wordt normalisatie toegepast, wat eerder is besproken.
GO TO FULL VERSION