Het Entiteit-relatie gegevensmodel , ook wel ER genoemd , is een van de verschillende gegevensmodellen die u kunt gebruiken om over uw gegevens te redeneren.
Het is vooral een conceptueel datamodel , omdat het niet is gekoppeld aan een bepaalde implementatie. Dat is een taak die wordt overgelaten aan het logische datamodel.
Het ER-gegevensmodel is zo algemeen, zo hoog niveau, dat het kan worden geïmplementeerd door een verscheidenheid aan totaal verschillende soorten databases.
Het is geweldig omdat u niet nadenkt over de implementatiedetails, maar in plaats daarvan alleen denkt aan uw gegevens en hoe deze zijn georganiseerd . En terwijl u dit doet, wordt u gedwongen het probleem te analyseren op manieren waar u eerder niet aan had gedacht.
Ik vind ER-diagrammen geweldig om u te helpen bij het analyseren van een scenario waar gegevens bij betrokken zijn.
Het ER-model geeft je de tools om, met behulp van een grafische notatie, alle gegevens weer te geven die je nodig hebt om te modelleren, de relaties tussen de verschillende soorten gegevens en de bijbehorende informatie.
Er zijn 2 items waaruit een ER-model bestaat:
- de entiteiten
- de relaties
Entiteiten zijn soorten gegevens, zoals items of personen, die gemeenschappelijke eigenschappen hebben.
Relaties zijn de relaties tussen entiteiten.
Laat me je een voorbeeld geven, laten we het hebben over boeken en hun auteurs. We hebben 2 entiteiten :
- boek
- auteur
Een bepaald boek is een instantie van de boekentiteit.
Aangezien we 2 entiteiten hebben, hebben we 2 relaties tussen hen. Een daarvan is de relatie tussen een enkel boek en de entiteit van de auteur. Een daarvan is de relatie tussen een enkele auteur en de entiteit boeken. Als we erover nadenken, hebben we:
- een boek heeft een auteur
- een auteur kan veel verschillende boeken schrijven
De visuele notatie voor entiteiten
Met dit eenvoudige voorbeeld kunnen we beginnen met het introduceren van de visuele notatie die ons zal helpen het ER-gegevensmodel van ons scenario te maken.
Opmerking:er zijn veel verschillende manieren om ER-diagrammen te tekenen. Ik zal degene gebruiken die, naar mijn mening , is visueler en logischer.
Entiteiten worden weergegeven als rechthoeken, met wat tekst erin om ze te identificeren:
De visuele notatie voor relaties
De relatie tussen entiteiten wordt weergegeven, in zijn meest elementaire vorm, met behulp van een lijn die twee relaties verbindt, en een ruit met wat tekst erin om het type relatie te identificeren:
Merk op dat ik geen 2 relaties "boek heeft auteur" en "auteur schreef boek" heb gemaakt. Ik heb een enkele relatie gemaakt tussen een boek en een auteur.
Kardinaliteiten
Als we eenmaal een relatie hebben, moeten we nu aangeven om welke getallen het gaat. Op dit moment hebben we veel vragen:
- Hoeveel auteurs kan een boek hebben?
- Kan een auteur meerdere boeken schrijven?
- Moet een auteur ten minste één boek schrijven om auteur te worden genoemd?
- Kan een boek door meerdere auteurs worden geschreven?
- Kan een boek bestaan zonder op zijn minst een auteur?
Dat zijn allemaal goede vragen om te stellen, en in dit geval denk ik dat de antwoorden vrij duidelijk zijn. En als het antwoord niet voor de hand ligt, kun je over het probleem nadenken en je eigen beperkingen toevoegen.
Er zijn verschillende manieren om kardinaliteiten visueel aan te geven in een diagram. Sommigen geven er de voorkeur aan de vorm van de lijn te veranderen wanneer deze naar een entiteit verwijst.
Ik geef de voorkeur aan cijfers, die dingen duidelijker maken:
Bovenstaande cijfers betekenen dit:een boek kan geschreven zijn door 1 of meerdere auteurs. n betekent een willekeurig aantal elementen.
En een auteur kan van 0 boeken hebben geschreven (misschien schrijft hij er nu een) tot een oneindig aantal boeken.
De eerste heet een nul-op-veel-relatie . De tweede is een een-op-veel-relatie .
We kunnen ook hebben:
- een-op-een relaties
- veel-op-veel relaties
- nul-op-een relaties
Kenmerken
Elke entiteit kan een of meer attributen hebben.
Laten we zeggen dat we de bovenstaande relatie in een boekwinkel zullen gebruiken. Elke auteur heeft een naam, een bio, een website-URL.
Elk boek heeft een titel, een uitgever, een jaar van uitgave, een ISBN. De uitgever kan ook een entiteit zijn, als we dat willen. Maar we kunnen het ook definiëren als een attribuut van een boek.
Dit is hoe we de bovenstaande informatie kunnen weergeven:
Identificatiekenmerken
Entiteiten moeten worden geïdentificeerd met een unieke sleutel. De boekentiteit kan op unieke wijze worden geïdentificeerd aan de hand van het ISBN-kenmerk. Elk boek heeft een enkel ISBN (aangezien we niet een enkel exemplaar van een boek vertegenwoordigen, maar een boek "titel").
We identificeren de primaire sleutelkenmerken door ze te onderbouwen:
Auteur daarentegen heeft op dit moment geen unieke identificatie. Twee auteurs kunnen dezelfde naam hebben.
We moeten daarom een uniek sleutelkenmerk toevoegen. Bijvoorbeeld een id kenmerk:
Identificatiekenmerken kunnen meerdere kenmerken omvatten.
Het paspoort-ID en het land van de auteur identificeren bijvoorbeeld de persoon op unieke wijze en kunnen de id . vervangen kenmerk dat we hebben toegevoegd:
Welke te kiezen? Het is een kwestie van wat logischer is in uw toepassing. Als we een boekwinkel modelleren, kunnen we niet verwachten dat we het land- en paspoort-ID van alle boekauteurs hebben. We gebruiken daarom een willekeurige id we kiezen en associëren met elke auteur.
Relatiekenmerken
Attributen zijn niet uniek voor entiteiten. Relaties kunnen ook attributen hebben.
Bedenk dat we een bibliotheek moeten modelleren. Naast de entiteiten voor boeken en auteurs introduceren we nu de lezersentiteit , een persoon die het boek leent om het te lezen. We nemen de naam en het ID-kaartnummer als ze het lenen:
Maar we missen nog steeds informatie. We moeten weten wanneer de persoon het boek heeft geleend en de datum waarop hij het heeft teruggebracht, zodat we de informatie over de hele geschiedenis van een bepaald boek in onze bibliotheek kunnen opslaan. Deze informatie behoort niet tot de entiteiten van het boek of de lezer; het hoort bij de relatie:
Zwakke entiteiten
We hebben hierboven gesproken over primaire sleutels en hoe de hulp een entiteit uniek identificeert.
Sommige entiteiten zijn voor hun bestaan afhankelijk van andere entiteiten en worden zwakke entiteiten . genoemd .
Stel dat we bestellingen voor een online winkel moeten modelleren.
Voor elke bestelling slaan we de bestel-ID op, die begint bij 1 en in de loop van de tijd toeneemt, de datum en tijd waarop deze is geplaatst en de informatie over de klant, zodat we weten wie we moeten factureren en waar we deze naartoe moeten sturen.
Dan moeten we ook weten wat ze besteld hebben. We creëren een zwakke entiteit "besteld artikel", die elk artikel in de winkelwagen vertegenwoordigt op het moment van afrekenen.
Deze entiteit slaat de artikelprijs op op het moment van afrekenen (dus wanneer we de prijs van de producten in de uitverkoop wijzigen, heeft dit geen invloed op de reeds geplaatste bestellingen), het aantal artikelen dat is besteld en de gekozen opties. Stel dat we t-shirts verkopen, daarom moeten we de kleur en maat van het bestelde t-shirt opslaan.
Het is een zwakke entiteit omdat een entiteit van een besteld item niet kan bestaan zonder een entiteit van een bestelling.
Recursieve relaties
Een entiteit kan een recursieve relatie met zichzelf hebben. Stel dat we een persoonsentiteit hebben. We kunnen de ouder-kindrelatie op deze manier modelleren:
Een persoon kan 0 tot n kinderen hebben, een kind heeft 2 ouders (in het eenvoudigste scenario).
ISA-relaties
ISA staat voor IS-A en is een manier om generalisaties in het ER-model te modelleren.
We gebruiken het om vergelijkbare entiteiten onder een gemeenschappelijke paraplu te groeperen. Een auteur en een lezer, in het geval van het voorbeeld van boeken en bibliotheek, kunnen bijvoorbeeld worden gegeneraliseerd met behulp van een persoonsentiteit.
Ze hebben allebei een naam, dus we extraheren de naam tot aan de persoonsentiteit, en beheren gewoon de eigenaardigheden van het zijn van een auteur of lezer in de overeenkomstige entiteit:
Niet-binaire relaties
Niet elke relatie is strikt binair. Laten we een lesscenario nemen.
Vandaag om 10.00 uur vindt er een les plaats in een lokaal van de school, met een leraar die met een klas praat over natuurkunde.
Een les wordt dus op een bepaald tijdstip van de dag gegeven, het gaat om een vak, een leraar, een klas en een kamer.
We kunnen het op deze manier modelleren:
