Maak kennis met het ER-diagram (Entity Relationship), de onderdelen ervan en wat er vaak misgaat bij het maken ervan.
Heeft u ooit een relationeel databasemodel gemaakt? Of misschien probeer je je eerste te maken? U weet (of u zult er snel achter komen) dat het vertalen van echte problemen naar databaselogica soms behoorlijk moeilijk kan zijn.
Een van de hulpmiddelen die u kunnen helpen, is het ER-diagram. De algemene wijsheid bij het ontwerpen van databases is dat hoe beter uw ER-diagram is, hoe gemakkelijker het zal zijn om het databasemodel te bouwen. Dit belangrijke item zet de toon voor alle toekomstige frustraties of successen. Met een goed ER-diagram is het maken van een relationeel databasemodel vrij eenvoudig. Natuurlijk kunnen er in elke fase van databasemodellering fouten worden gemaakt. Als u echter een goed ER-diagram heeft, kunt u sommige van die fouten voorkomen.
Laten we dus eens kijken wat het ER-diagram is en hoe we de veelvoorkomende fouten kunnen vermijden.
Wat is een ER-diagram?
"ER-diagram", of ERD, is een afkorting voor Entity Relationship Diagram. Het brengt het te modelleren probleem in kaart, maar op een gestructureerde manier die de relaties tussen entiteiten laat zien.
De bouwstenen van een ER-diagram
ER-diagrammen bestaan uit de volgende elementen:
- Entiteit
- Relaties
- Entiteits- of relatiekenmerken
Het eerste element van het ER-diagram is de entiteit . De entiteit is een object of gebeurtenis waarover we informatie willen opslaan. Kortom, het is alles waarover we gegevens kunnen verzamelen. We kunnen bijvoorbeeld gegevens opslaan over werknemers, studenten, docenten, kopers, producten, afdelingen, betalingen, locaties, enz.
Zodra we entiteiten hebben, is het noodzakelijk om relaties te creëren . Een relatie laat zien hoe een entiteit is verbonden met en is gekoppeld aan een of meer andere entiteiten.
Het laatste element van het ER-diagram is een entiteit of relatie attribuut . Een attribuut is een beschrijving van een eigenschap die tot een entiteit of relatie behoort. Attributen hebben waarden. Sommige attributen voor de hierboven genoemde entiteiten kunnen zijn:
- Medewerker, student, docent, koper – ID, naam, achternaam, geboortedatum, adres, etc.
- Product – ID, categorie, beschrijving, kleur, serienummer, enz.
- Afdeling – ID, afdelingsnaam, afdelingshoofd, aantal medewerkers, etc.
- Betalingen – ID, datum en tijd, bedrag.
- Locatie – Stad, postcode, regio, land, continent.
Soorten relaties
Voordat we ingaan op de gebruikelijke fouten in ER-diagrammen, is het belangrijk om de mogelijke relatietypen te begrijpen. De meeste ERD-fouten zijn in wezen foutief gedefinieerde relaties tussen entiteiten.
Er zijn drie soorten relaties tussen entiteiten:
- Een-op-een (1:1)
- Een-op-veel (1:N)
- Veel-op-veel (M:N)
Een-op-een (1:1) relaties
Het eerste relatietype is een-op-een , of 1:1 . In deze relatie kan een enkele instantie van een entiteit alleen worden verbonden met een enkele instantie van een andere entiteit (en vice versa natuurlijk).
Laten we zeggen dat we de entiteit student . hebben met de attributen naam en achternaam . We hebben ook de entiteit id met het enige kenmerk id . De 1:1-relatie zou betekenen dat één student slechts één ID-nummer kan hebben. Het betekent ook dat één ID-nummer slechts aan één student kan toebehoren.
Deze relatie wordt zeer zelden gezien in databases. Als slechts één ID aan slechts één student kan worden gekoppeld, is het niet nodig om ze in twee verschillende entiteiten te scheiden.
Hier is een voorbeeld van deze relatie:
Een-op-veel (1:N) relaties
Het meest voorkomende type databaserelatie is een-op-veel of 1:N . Een een-op-veel-relatie betekent dat elke afzonderlijke instantie van een entiteit kan worden verbonden met meerdere instanties van een andere entiteit. Het betekent ook dat elke instantie van de tweede entiteit aan slechts één instantie van de eerste entiteit kan worden gekoppeld.
Er is bijvoorbeeld een entiteit koper met de attributen id , naam , en achternaam . We willen een relatie aangaan met de entiteit betaling die de attributen id . heeft , datum , en waarde . Dit is een 1:N-relatie omdat één koper één of meerdere betalingen kan doen. Een betaling kan echter niet door meerdere kopers worden gedaan; het kan slechts door één koper worden gemaakt.
Hier is het voorbeeld:
Deze relatie is ook andersom te zien. In deze situatie wordt het veel-op-een . genoemd of N:1 . Dit is natuurlijk geen nieuw type relatie. Het is hetzelfde als 1:N, maar het wordt vanuit de tegenovergestelde richting bekeken.
Stel dat we als voorbeeld de entiteit werknemer . hebben met de attributen id , naam , en achternaam . We willen werknemer ’s relatie met de entiteit afdeling die de attributen id . heeft en naam . De relatie tussen deze twee entiteiten is N:1. Dit betekent dat elke medewerker maar op één afdeling kan werken, maar meerdere medewerkers op dezelfde afdeling.
Veel-op-veel (M:N) relaties
Een Veel-op-veel of M:N relatie betekent dat elke instantie van de eerste entiteit kan worden geassocieerd met meer dan één instantie van de tweede entiteit. Het betekent ook dat elke instantie van de tweede entiteit kan worden gekoppeld aan meerdere instanties van de eerste entiteit.
Laten we eens kijken hoe dit werkt tussen de entiteiten student en lezing . Laten we zeggen dat student heeft de attributen id , naam , en achternaam . De entiteit lezing heeft de attributen id en naam . Een veel-op-veel relatie kan als volgt worden geïnterpreteerd:één student kan één of meer colleges bijwonen, terwijl één college kan worden bijgewoond door één of meer studenten.
Hier is het diagram voor dit voorbeeld:
Bij databasemodellering worden dergelijke relaties meestal opgesplitst in twee of meer 1:N- of N:1-relaties door nieuwe entiteiten te introduceren.
Typische fouten gemaakt bij het maken van een ER-diagram
Veel fouten in het ER-diagram passen in een van deze vier categorieën:
- Onjuiste relaties tussen entiteiten
- Een entiteitsinstantie gebruiken in plaats van een entiteit
- Een kenmerk verwarren met een entiteit
- Complexe kenmerken
Laten we ze allemaal afzonderlijk bekijken.
Onjuiste relaties tussen entiteiten
De meest voorkomende fouten doen zich voor bij het definiëren van de relatie tussen entiteiten . Er zijn meestal geen fouten in een 1:1-relatie. Het is echter heel gemakkelijk om een 1:N-relatie te verwarren met een M:N-relatie. Dit komt meestal voort uit het niet begrijpen van de eisen van de eindgebruiker. Het is essentieel om zeer duidelijk gedefinieerde vereisten te hebben en een diep begrip van waarom de database nodig is en hoe deze zal worden gebruikt. Als we een ER-diagram maken met onvoldoende gegevens en onvolledig begrip, zal dit er hoogstwaarschijnlijk toe leiden dat relaties tussen entiteiten verkeerd worden gedefinieerd.
Laten we een voorbeeld bekijken. Als u een database voor een bank maakt, maakt u hoogstwaarschijnlijk een ER-diagram met de entiteit client met de attributen id , naam , en achternaam . Je hebt ook een entiteit genaamd account met de attributen id en typ . Als u geen ervaring heeft in de banksector, denkt u waarschijnlijk dat er altijd een 1:N-relatie is tussen de klant en account entiteiten, zoals hieronder weergegeven.
Eén klant kan meerdere rekeningen bij één bank hebben. Een account kan echter eigendom zijn van slechts één klant. Is dit echt waar? Misschien is het dat wel, misschien niet. Heel wat banken bieden gezamenlijke rekeningen aan die door meerdere klanten kunnen worden gebruikt. Maakt u een ER-diagram voor een bank die een dergelijke dienst aanbiedt? Als de bank geen gezamenlijke rekeningen aanbiedt, dan heb je gelijk:de relatie tussen klant en account is 1:N. Als de bank echter wel gezamenlijke rekeningen aanbiedt, dan is de relatie M:N.
Een entiteitsinstantie gebruiken in plaats van een entiteit
Een andere veelgemaakte fout is het gebruik van een entiteitsinstantie in plaats van een entiteit. Een entiteitsinstantie is een enkele instantie van een bepaalde entiteit, d.w.z. een entiteit die in feite een attribuut van een grotere categorie zou kunnen zijn.
Laten we zeggen dat we in een bedrijf werken dat mobiele telefoons en laptops toewijst aan bepaalde werknemers. Dus in onze database zouden we een entiteit hebben met de naam laptop met de attributen id en model en een entiteit genaamd werknemer met de attributen id , naam , en achternaam , Rechtsaf?
Er is hier een probleem:een laptop is eigenlijk geen entiteit - er zijn ook mobiele telefoons om rekening mee te houden. De oplossing is om de entiteit laptop te vervangen met een meer algemene entiteit, zoals apparatuur . Deze entiteit kan de attributen ID . hebben , type , en model , zoals hieronder weergegeven. Het type kan bestaan uit waarden zoals telefoon , PC , tablet , en laptop . Op deze manier is het niet nodig om voor elk type apparatuur een aparte entiteit aan te maken.
Je kunt het voorbeeld hier vinden:
Een kenmerk verwarren met een entiteit
De volgende veelgemaakte fout is het verwarren van een attribuut met een entiteit. Laten we zeggen dat we hebben besloten om een entiteit te creëren met de naam employee die zal bestaan uit de attributen id , naam , achternaam , geboortedatum , id_department , name_afdeling , en head_department . Deze entiteit brengt ons in de problemen wanneer we een databasemodel maken, omdat het bestaat uit te veel attributen die deze specifieke entiteit niet uniek definiëren .
Onthoud dat we entiteiten hebben gedefinieerd als alles waarover we gegevens kunnen verzamelen. Met dat in gedachten kunnen we zien dat de huidige werknemer entiteit kan worden opgesplitst in twee entiteiten:werknemer en afdeling , zoals hieronder weergegeven.
Complexe kenmerken
De laatste veelgemaakte fout waar we het over zullen hebben, is het opnemen van een complex attribuut in een entiteit. Met andere woorden, we hebben een attribuut dat eigenlijk zijn eigen entiteit zou moeten zijn .
Laten we zeggen dat we een entiteit hebben genaamd studenten dat wordt gedefinieerd door de volgende attributen:id , naam , achternaam , geboortedatum , adres , en exam_geslaagd . Hier, exam_geslaagd is een complex attribuut dat uit meer dan één stuk informatie bestaat, d.w.z. de examen-ID en -datum en de score van de student. Het zo laten zou een vergissing zijn. In plaats daarvan moeten we een nieuwe entiteit maken uit dit complexe kenmerk . De nieuwe entiteit zou examens kunnen heten en bestaan uit de volgende attributen:id , datum , students_id , en score .
Je kunt het voorbeeld hier vinden:
Heb je nuttige tips voor ER-diagrammen gekregen?
Deze vier soorten fouten zijn de meest voorkomende fouten bij het maken van ER-diagrammen. Natuurlijk is er geen volledige lijst met typische fouten of soorten fouten. In het echte leven zullen er waarschijnlijk veel soorten fouten gebeuren. Een gebrek aan planning, onvoldoende technische ondersteuning en een gehaast databaseontwerpproces dragen allemaal hun eigen problemen bij. Als je ooit databases hebt gemaakt of er vanuit de zakelijke kant aan hebt deelgenomen, heb je er waarschijnlijk een aantal meegemaakt! Al die omstandigheden leiden tot verschillende fouten, waarvan sommige vrij uniek zijn.
Heb je zelf een voorbeeld van een niet zo goed ER-diagram? Of zijn er misschien nog andere fouten die je vaak tegenkomt? Laat het me weten in het opmerkingengedeelte.