ER-model

Een voorbeeld van een ER-diagram

In de informatica , in de context van databaseontwerp , is het entiteit-relatiemodel (of entiteit-associatiemodel ; meer algemeen ER-model ) een theoretisch model voor de conceptuele en grafische representatie van gegevens op een hoog abstractieniveau , geformaliseerd door Peter Chen in 1976 .

Het entiteit-relatiemodel wordt vaak gebruikt in de eerste fase van het ontwerp van een database, waarin het nodig is om de informatie die voortvloeit uit de analyse van een bepaald domein te vertalen naar een conceptueel schema, het zogenaamde entiteit-relatiediagram (of ER-diagram ).

Op het gebied van ontwerp van database-engineering zijn er drie onafhankelijke en opeenvolgende niveaus van ontwerp: conceptueel ontwerp, logisch ontwerp, fysiek ontwerp. Eigenlijk is het ER-model de belangrijkste techniek voor de conceptuele ontwerpfase, het relationele model voor de logische ontwerpfase. Pas in de laatste fase van het fysieke ontwerp wordt rekening gehouden met de software- en hardwaretoepassingen , al dan niet propriëtair, op de markt.

Algemene informatie

Het ER-model is gebaseerd op een reeks concepten die zeer dicht bij de realiteit van belang liggen : daarom gemakkelijk te begrijpen door ontwerpers (en over het algemeen als voldoende begrijpelijk en belangrijk beschouwd, zelfs voor niet-technici), maar niet uitvoerbaar op computers . Hoewel het model is gericht op het ontwerp van databases, is het in feite onafhankelijk van de specifieke criteria van fysieke organisatie van persistente gegevens in IT-systemen . Er zijn technieken voor het vertalen van concepten op hoog niveau (beter begrepen door mensen) naar concepten op lager niveau die typerend zijn voor de verschillende logische modellen (bijvoorbeeld het relationele model ) die in de verschillende bestaande DBMS'en zijn geïmplementeerd.

Het ER-model is lange tijd (en misschien nog steeds) een van de meest solide benaderingen geweest voor het modelleren van toepassingsdomeinen op IT-gebied; om deze reden is het ook vaak gebruikt buiten de context van databaseontwerp en is het gebruikt als referentiemodel voor tal van andere modelleringsnotaties. De OMT- notatie is onder meer geïnspireerd op het ER-model en later samengevoegd tot UML .

Door middel van een identificatie-supersleutel (velden: parent code_ID, child code_ID), vertegenwoordigt het Entity-Association-schema een boomgrafiek op een willekeurig aantal niveaus (in het bijzonder ook een BOM ), heel gebruikelijk in de computerwereld. De Sunburst-grafiek maakt een eenvoudige en wijdverbreide grafische weergave van hiërarchische gegevens mogelijk.

De belangrijkste constructies van het model

Analyse van de belangrijkste constructies van het ER-model: entiteiten, associaties en attributen.

Entiteit

Ze vertegenwoordigen klassen van objecten (feiten, dingen, mensen, ...) die gemeenschappelijke eigenschappen en een autonoom bestaan ​​hebben met het oog op het toepassen van rente. Een exemplaar van een entiteit is een object of instantie van de klasse die de entiteit vertegenwoordigt. We hebben het hier niet over de waarde die het object identificeert, maar over het object zelf. Een interessant gevolg van dit feit is dat een entiteitsgebeurtenis een bestaan ​​heeft dat onafhankelijk is van de eigenschappen die ermee verbonden zijn. Hierin vertoont het ER-model een duidelijk verschil met het relationele model waarin we een object niet kunnen representeren zonder enkele van zijn eigenschappen te kennen.

In een diagram heeft elke entiteit een naam die haar uniek identificeert en wordt grafisch weergegeven door middel van een rechthoek met de naam van de entiteit erin.

Vereniging

Associaties (ook wel relaties genoemd) vertegenwoordigen een link tussen twee of meer entiteiten. Het aantal verwante entiteiten wordt aangegeven door de mate van associatie: een goede SEH-regeling wordt gekenmerkt door een prevalentie van associaties met graad twee. Het is mogelijk om een ​​entiteit met zichzelf te binden (via een ringassociatie), evenals om dezelfde entiteiten te binden met meerdere associaties.

Het wordt meestal grafisch weergegeven door een diamant met de naam van de vereniging. Het zelfstandig naamwoord kan een werkwoord zijn om een ​​leesrichting te geven, of het kan een zelfstandig naamwoord zijn om geen leesrichting te geven. De meest recente academische en professionele oriëntatie heeft de neiging om het zelfstandig naamwoord juist te gebruiken om te voorkomen dat er een richting aan de vereniging wordt gegeven.

attributen

Entiteiten en associaties kunnen worden beschreven met behulp van een set attributen. Alle objecten van dezelfde entiteitsklasse (of associatie) hebben dezelfde attributen - dit is wat we bedoelen als we het hebben over vergelijkbare objecten. De keuze van attributen weerspiegelt het detailniveau waarmee we informatie over entiteiten en relaties willen weergeven. Voor elke entiteitsklasse of associatie wordt een sleutel gedefinieerd. De sleutel is een minimale set attributen die een instantie van entiteit of associatie op unieke wijze identificeert. Het attribuut wordt weergegeven met een ellips waarbinnen de naam van het attribuut wordt gespecificeerd of zelfs eenvoudig, in het geval van complexe diagrammen, waarbij alleen de naam wordt aangegeven, mogelijk in overeenstemming. In het geval van een primaire sleutel is de attribuutnaam onderstreept of omcirkeld.

Andere modelconstructies

Kardinaliteit van verenigingen

Ze worden gespecificeerd voor elke entiteit die deelneemt aan een associatie en geven aan hoe vaak, in een associatie tussen entiteiten, een voorval van een van deze entiteiten kan worden gekoppeld aan voorvallen van de andere entiteiten die bij de associatie betrokken zijn (geeft het minimum en maximum aan voorvallen ).

Attribuutkardinaliteit

Het is ook mogelijk om kardinaliteitsbeperkingen voor attributen te definiëren, met twee doelen:

• optioneel aangeven;
• duiden meerwaardige attributen aan.

Als de beperkingsspecificatie ontbreekt, zoals in de meeste gevallen het geval is, is de kardinaliteit van het attribuut (1,1). Laten we het volgende voorbeeld bekijken:

Aangezien de specificatie van de kardinaliteitsbeperking in de naam ontbreekt, betekent dit dat de kardinaliteit (1,1) is.

• (0,1) NumeroPatente, het betekent dat een werknemer wel een rijbewijs kan hebben maar ook niet, of liever gezegd een werknemer mag hooguit een rijbewijs hebben.
• (0, n) NumeroTelefono, betekent dat een medewerker veel telefoonnummers kan hebben, maar ook geen telefoonnummer.
• (1, n) TitleStudio, het betekent dat een werknemer veel kwalificaties kan hebben, maar er minstens één moet hebben.

Entiteits-ID's

Ze vormen een subset van de attributen van een entiteit die elk voorkomen van dezelfde entiteit op unieke wijze identificeren. Een voorbeeld kan worden gevormd door het CodiceFiscale-attribuut van de CittadinoItaliano-entiteit. Het is in feite bekend dat elk voorkomen van de CittadinoItaliano-entiteit, dat wil zeggen elke burger die op het grondgebied van de Italiaanse Republiek woont, ondubbelzinnig kan worden geïdentificeerd door zijn belastingwetboek. Dit betekent dat er geen twee Italiaanse burgers met dezelfde belastingcode kunnen zijn (tenzij er sprake is van homocody ).

Generalisaties

Ze vertegenwoordigen logische verbindingen tussen twee of meer entiteiten. Van de betrokken entiteiten vallen de volgende op:

• één en slechts één moedermaatschappij;
• een of meer onderliggende entiteiten.

Onderliggende entiteiten zijn "speciale gevallen" van de bovenliggende entiteit. Elk attribuut van de bovenliggende entiteit is ook een attribuut van onderliggende entiteiten, maar onderliggende entiteiten kunnen attributen hebben die hen onderscheiden van hun vader en broers en zussen. Het volgende voorbeeld laat zien dat:

• elke persoon wordt geïdentificeerd door een belastingcode en wordt gekenmerkt door een achternaam, een naam en een leeftijd;
• elke persoon onderscheidt zich in man of vrouw;
• militaire positie kan ook worden beoordeeld.

Generalisaties zijn onderverdeeld in "totaal" en "gedeeltelijk". Een generalisatie is totaal wanneer de vereniging van de deelverzamelingen van de kinderen het geheel van de vader vormt. De veralgemening van persoon naar man of vrouw is bijvoorbeeld totaal, aangezien alle mensen ofwel mannen of vrouwen zijn, daarom verkrijgen we door de subsets van mannen en vrouwen te combineren de set mensen. Een generalisatie is gedeeltelijk wanneer, aan de andere kant, de vereniging van de subsets van de kinderen niet globaal de set van de vader identificeert. Zo is een moederentiteit Middelen van voortbeweging met de onderliggende entiteiten Fiets en Auto een gedeeltelijke generalisatie, aangezien er naast fietsen en auto's andere middelen van voortbeweging zijn, zoals bromfietsen, treinen, schepen, enz. De vereniging van de fiets- en auto-subsets is daarom niet voldoende om de moederset van Locomotion te identificeren.

Een generalisatie kan ook "exclusief" of "overlappend" zijn. Een generalisatie is exclusief wanneer het snijpunt van de deelverzamelingen van de kinderen leeg is; het overlapt in plaats daarvan wanneer het snijpunt van de subsets van de kinderen niet leeg is. Een bovenliggende entiteit Werknemer met onderliggende entiteiten Werknemer en Student identificeert een overlappende generalisatie in die zin dat er medewerkers kunnen zijn die tegelijkertijd student zijn. Concluderend kan een generalisatie zijn:

• totaal exclusief (t, e);
• totaal gesuperponeerd (t, s);
• gedeeltelijk exclusief (p, e);
• gedeeltelijk gesuperponeerd (p, s).

Soms kunnen de afkortingen (t, e) en de laatste die zojuist zijn aangegeven in de BHV-schema's verschijnen om informatie toe te voegen over het type generalisatie; het gebruik ervan binnen het ER-grafisch schema is echter niet bindend.

Entiteit – attribuut – waarde (EAV) datamodel

Een Entiteit – attribuut – waarde (EAV) datamodel wordt met voordeel gebruikt in gevallen waarin de databases bestaan ​​uit:

• enkele attributen van het variabele type in de loop van de tijd;
• honderden tabellen of categorieën van variabele grootte in de loop van de tijd, maar die daarbinnen bestaan ​​uit enkele tientallen rijen of instanties; en een relatief klein aantal tabellen, maar elk met duizenden of miljoenen rijen of instanties.

Op het gebied van business intelligence zou een informatiestructuur van dit type een multidimensionale OLAP-kubus kunnen zijn , waaraan de gebruiker vaak een analysedimensie moet toevoegen, van een onvoorspelbaar aantal en variabele in de tijd: de EAV-tabellen geven een samenvattende weergave wanneer de te analyseren gegevens zijn zeer verspreid, bijvoorbeeld in een biomedische kennisbank. Hetzelfde EAV-model kan ook worden gebruikt om EAV-tabellen rechtstreeks in de OLAP-kubus te importeren .

Een ER-model zou de limiet hebben om alle tabellen op de gebruikelijke manier te beheren, zelfs vanuit een visueel oogpunt, ongeacht hun grootte en belang. Het Entiteit – attribuut – waardemodel is een datamodel dat deze limiet overschrijdt, en waarmee concepten op een IT- efficiënte manier kunnen worden weergegeven , in situaties waarin individuele entiteiten worden beschreven door een aantal attributen (eigenschappen of parameters) die relatief veel kleiner zijn dan die potentieel geschikt zijn voor een effectieve conceptuele en logische representatie .

ER Schematische Documentatie

Een ER-schema is om verschillende redenen op zichzelf bijna nooit voldoende om alle aspecten van een applicatie in detail te beschrijven. Allereerst verschijnen in een ER-schema alleen de namen van de verschillende concepten die erin aanwezig zijn, maar dit kan onvoldoende zijn om hun betekenis te begrijpen. Bij bijzonder complexe schema's kan het voorkomen dat u de verschillende begrippen niet begrijpelijk en uitputtend kunt weergeven.

Om deze reden is het essentieel om elk ER-schema te voorzien van ondersteunende documentatie die kan dienen om de interpretatie van het schema zelf te vergemakkelijken en om eigenschappen van de weergegeven gegevens te beschrijven die niet rechtstreeks door de modelconstructies kunnen worden uitgedrukt. Vandaar de noodzaak om instrumenten te hebben om het schema te voltooien.

Bedrijfsregels

Een van de tools die door informatiesysteemanalisten het meest worden gebruikt voor het beschrijven van eigenschappen van een applicatie die niet direct met conceptuele modellen kunnen worden weergegeven, is dat van bedrijfsregels . Deze betekenis vloeit voort uit het feit dat in de meeste gevallen wat we willen uitdrukken slechts een regel is van het specifieke toepassingsdomein dat we overwegen.

De term bedrijfsregel wordt door analisten met een bredere betekenis gebruikt om informatie aan te duiden die een bepaald aspect van een toepassing definieert of beperkt. Op basis van een nogal geconsolideerde classificatie kan een bedrijfsregel met name zijn:

• de beschrijving van een concept dat relevant is voor de toepassing of de precieze definitie van een entiteit, attribuut of associatie van het ER-model;
• een integriteitsbeperking op de toepassingsgegevens, of het nu gaat om de documentatie van een beperking die wordt uitgedrukt met een constructie van het ER-model (zoals de kardinaliteit van een associatie) of de beschrijving van een beperking die niet rechtstreeks kan worden uitgedrukt met de constructies van het model;
• een afleiding of een concept dat kan worden verkregen door een gevolgtrekking of een rekenkundige berekening uit andere concepten van het schema.

Voor de regels van het eerste type is het duidelijk onmogelijk om een ​​precieze syntaxis te definiëren en wordt over het algemeen gebruik gemaakt van zinnen in natuurlijke taal. Deze regels worden meestal weergegeven in de vorm van woordenlijsten, waarin de beschrijvingen op de juiste manier worden gegroepeerd.

De regels die integriteitsbeperkingen en afleidingen beschrijven, zijn daarentegen meer geschikt voor formele definities met min of meer complexe syntaxis. Aangezien er echter geen standaardisaties zijn en elk gekozen formalisme het risico loopt niet voldoende expressief te zijn, zullen we nog steeds een beroep doen op definities in natuurlijke taal en ervoor zorgen dat deze definities adequaat worden gestructureerd. Met name de regels die integriteitsbeperkingen beschrijven, kunnen worden uitgedrukt in de vorm van beweringen of verklaringen die altijd in onze database moeten worden geverifieerd. Omwille van de duidelijkheid en om de constructie ervan te vergemakkelijken, moeten deze uitspraken atomair zijn, dat wil zeggen dat ze niet kunnen worden ontleed in zinnen die nog steeds uitspraken vormen. Bovendien, aangezien ze worden gebruikt om een ​​ER-schema te documenteren, moeten de beweringen declaratief worden vermeld in een vorm die geen methode suggereert om eraan te voldoen. Dit is in feite een realisatieprobleem en daarom niet relevant voor conceptuele representatie. Daarom zijn notaties zoals als <voorwaarde> dan <actie> niet geschikt om bedrijfsregels uit te drukken wanneer ze een ER-schema documenteren. Een vooraf gedefinieerde structuur voor het verkondigen van bedrijfsregels in de vorm van beweringen zou de volgende kunnen zijn:

<concept> moet/kan <uitdrukkingen op concepten>

waarbij de aangehaalde concepten kunnen corresponderen met concepten die voorkomen in het BHV-schema waarnaar wordt verwezen of met concepten die door hen kunnen worden gedefinieerd.

Bedrijfsregels die afleidingen uitdrukken, kunnen worden uitgedrukt door (rekenkundige of andere) bewerkingen te specificeren die het mogelijk maken om het afgeleide concept te verkrijgen. Een mogelijke opbouw is dus:

<concept> resulteert in <operatie op concepten>

Documentatie technieken

De documentatie van de verschillende concepten weergegeven in een diagram of de beschrijvende bedrijfsregels kunnen worden geproduceerd met behulp van een datadictionary. Het bestaat uit twee tabellen: de eerste beschrijft de schema-entiteiten met de naam, een informele definitie in natuurlijke taal, de lijst met alle attributen (met eventuele bijbehorende beschrijvingen) en mogelijke identifiers. De andere tabel beschrijft de associaties met de naam, hun informele beschrijving, de lijst met attributen (met eventuele beschrijvingen) en de lijst van betrokken entiteiten samen met hun deelnamekardinaliteit.

Voor wat betreft andere regels kunt u nog steeds een tabel gebruiken waarin de verschillende regels zijn opgesomd, telkens met vermelding van hun type. Het is belangrijk om alle regels weer te geven die beperkingen beschrijven die niet door het schema worden uitgedrukt, maar het is soms nuttig om ook regels weer te geven die beperkingen documenteren die al in het schema zijn uitgedrukt.

ER Schema Vertaling

De vertaling van het ER-schema naar een equivalent logisch schema (gebaseerd op een logisch model, zoals het relationele model ) , d.w.z. in staat om dezelfde informatie weer te geven, is een fundamentele stap van het logisch ontwerp , dat normaal wordt voorafgegaan door de herstructureringsfase van schema ER . Het belangrijkste element van de vertaling van een ER-schema in een equivalent logisch schema is het feit dat er geen relaties bestaan ​​in het relationele model , daarom moeten zowel entiteiten als associaties worden vertaald in relaties , door middel van geschikte gecodeerde regels, op basis van de vastgestelde hoofdidentificaties in de herstructureringsfase van de BHV-regeling, de kardinaliteit van de verenigingen en de aanwezigheid van externe identifiers.

Hoewel de voorbereidende fase van de herstructurering van het ER-schema slechts gedeeltelijk geautomatiseerd kan worden, kunnen verschillende software op de markt uit het geherstructureerde ER-schema automatisch het overeenkomstige relationele schema, de eigenlijke database, afleiden. Een duidelijk gevolg van deze feiten, en uiteraard ook van de aard van de betrokken modellen, is dat de activiteit van het automatisch afleiden van een ER -schema uit het relationele schema dat is afgeleid op basis van de fysieke implementatie van de DB , een functie die door sommigen beschikbaar is gesteld. software, staat het over het algemeen niet toe om het originele ER-schema te verkrijgen .

De naam van elke entiteit komt overeen met de kop van een tabelmatrix, met net zoveel kolommen als er attributen van de entiteit zijn. Als het attribuut een primaire sleutel is of deel uitmaakt van een superkey die uit meerdere attributen bestaat, kan het niet de NULL-waarde aannemen (niet-optioneel, verplicht attribuut) en kan het niet twee keer dezelfde waarde aannemen (unieke, niet-herhaalde waarden).

Als de associatie tussen twee of meer entiteiten een of meer attributen heeft, zal de associatie normaal gesproken aanleiding geven tot een tabel met als identificatiesleutel de verzameling primaire sleutels van alle entiteiten die verbonden zijn door de relatie (met enige kardinaliteit) en als velden de attributen geplaatst op de relatie in het ER-schema. Deze passage, van logische aard, moet niet worden verward met de reïficatie van een associatie tot een entiteit, een passage met een conceptueel karakter die in het ER-schema kan worden uitgevoerd.

In een tweede stap kan het aantal tabellen aanzienlijk worden verminderd, rekening houdend met de maximale kardinaliteit (unitair, n-air) die twee tabellen verbindt.

Bibliografie

• EF Codd, A Relational Model of Data for Large Shared Data Banks , IBM Research Laboratory, San Jose, Californië, Communications of the ACM - Volume 13 / Number 6 / June 1970
• Atzeni, Ceri, Paraboschi, Torlone, databases (modellen en querytalen) , McGraw Hill, 2003
• Atzeni, Ceri, Fraternali, Paraboschi, Torlone, Databases (Architectures en Evolution Lines) , McGraw Hill, 2003
• Ramez Elmasri, Shamkant B. Navathe, Databasesystemen , grondbeginselen , Pearson - Addison Wesley, 2003

Andere projecten

Andere projecten

• Wikimedia Commons

• Wikimedia Commons bevat afbeeldingen of andere bestanden op het entiteit-associatiemodel