Twee verwante entiteiten

Een entiteit met een attribuut

Een relatie met een attribuut

Een entiteit kan worden gedefinieerd als een ding dat een onafhankelijk bestaan kan hebben en op unieke wijze kan worden geïdentificeerd. Een entiteit is een abstractie van de complexiteit van een domein. Wanneer we over een entiteit spreken, hebben we het gewoonlijk over een of ander aspect van de werkelijke wereld dat kan worden onderscheiden van andere aspecten van de werkelijke wereld.

Een entiteit is een ding dat bestaat, hetzij fysiek, hetzij logisch. Een entiteit kan een fysiek object zijn, zoals een huis of een auto (ze bestaan fysiek), een gebeurtenis, zoals een huisverkoop of een autoservice, of een concept, zoals een klantentransactie of een bestelling (ze bestaan logisch-als een concept). Hoewel de term entiteit het meest wordt gebruikt, moeten we volgens Chen echt onderscheid maken tussen een entiteit en een entiteittype. Een entiteittype is een categorie. Een entiteit is, strikt genomen, een instantie van een bepaald entiteittype. Er zijn gewoonlijk vele instanties van een entiteittype. Omdat de term entiteittype wat omslachtig is, gebruiken de meeste mensen de term entiteit als synoniem voor deze term

Entiteiten kunnen worden opgevat als zelfstandige naamwoorden. Voorbeelden: een computer, een werknemer, een liedje, een wiskundige stelling, etc.

Een relatie geeft aan hoe entiteiten aan elkaar gerelateerd zijn. Relaties kunnen worden opgevat als werkwoorden, die twee of meer zelfstandige naamwoorden met elkaar verbinden. Voorbeelden: een eigen-relatie tussen een bedrijf en een computer, een toezicht-relatie tussen een werknemer en een afdeling, een uitvoerende relatie tussen een artiest en een liedje, een bewijzende relatie tussen een wiskundige en een gissing, enz.

Het hierboven beschreven linguïstische aspect van het model wordt gebruikt in de declaratieve database query taal ERROL, die natuurlijke taal constructies nabootst. De semantiek en implementatie van ERROL zijn gebaseerd op reshaped relational algebra (RRA), een relationele algebra die is aangepast aan het entiteit-relatiemodel en het linguïstische aspect ervan weergeeft.

Entiteiten en relaties kunnen beide attributen hebben. Voorbeelden: een werknemer-entiteit kan een Social Security Number (SSN) attribuut hebben, terwijl een bewezen relatie een datum-attribuut kan hebben.

Alle entiteiten behalve zwakke entiteiten moeten een minimale set van uniek identificeerbare attributen hebben die kunnen worden gebruikt als een unieke/primaire sleutel.

Entity-relatie diagrammen tonen geen afzonderlijke entiteiten of afzonderlijke instanties van relaties. In plaats daarvan tonen ze entity sets (alle entiteiten van hetzelfde entiteittype) en relationship sets (alle relaties van hetzelfde relatietype). Voorbeelden: een bepaald liedje is een entiteit; de verzameling van alle liedjes in een database is een entiteitverzameling; de eetrelatie tussen een kind en zijn lunch is een enkele relatie; de verzameling van alle dergelijke kind-lunch relaties in een database is een relatieverzameling.Met andere woorden, een relatieset komt overeen met een relatie in de wiskunde, terwijl een relatie overeenkomt met een lid van de relatie.

Zekere cardinaliteitsbeperkingen op relatiesets kunnen ook worden aangegeven.

In kaart brengen van natuurlijke taalEdit

Chen stelde de volgende “vuistregels” voor voor het in kaart brengen van natuurlijke taalbeschrijvingen in ER-diagrammen: “Engels, Chinees en ER-diagrammen” door Peter Chen.

Physieke weergave laat zien hoe gegevens daadwerkelijk zijn opgeslagen.

Relaties, rollen en kardinaliteitenEdit

In Chen’s oorspronkelijke paper geeft hij een voorbeeld van een relatie en de rollen ervan. Hij beschrijft een relatie “huwelijk” en de twee rollen “echtgenoot” en “echtgenote”.

Een persoon speelt de rol van echtgenoot in een huwelijk (relatie) en een andere persoon speelt de rol van echtgenote in dat (zelfde) huwelijk. Deze woorden zijn zelfstandige naamwoorden. Dat is geen verrassing; dingen benoemen vereist een zelfstandig naamwoord.

Chen’s terminologie is ook toegepast op eerdere ideeën. De lijnen, pijlen en kraaienpoten van sommige diagrammen zijn meer te danken aan de vroegere Bachman diagrammen dan aan Chen’s relatiediagrammen.

Een andere veel voorkomende uitbreiding op Chen’s model is het “benoemen” van relaties en rollen als werkwoorden of zinsdelen.

RolbenamingEdit

Het is ook gebruikelijk geworden om rollen te benoemen met zinsdelen als is de eigenaar van en is eigendom van. Juiste zelfstandige naamwoorden in dit geval zijn eigenaar en bezit. Dus persoon speelt de rol van eigenaar en auto speelt de rol van bezit in plaats van persoon speelt de rol van, is de eigenaar van, etc.

Het gebruik van zelfstandige naamwoorden heeft direct voordeel bij het genereren van fysieke implementaties van semantische modellen. Wanneer een persoon twee relaties heeft met auto dan is het mogelijk om namen te genereren zoals owner_person en driver_person, die onmiddellijk betekenisvol zijn.

CardinalitiesEdit

Modificaties aan de oorspronkelijke specificatie kunnen voordelig zijn. Chen beschreef look-across cardinalities. Terzijde: de Barker-Ellis notatie, gebruikt in Oracle Designer, gebruikt same-side voor minimum cardinaliteit (analoog aan optionaliteit) en rol, maar look-across voor maximum cardinaliteit (de kraaienpoot).

In Merise, Elmasri & Navathe en anderen is er een voorkeur voor same-side voor rollen en zowel minimum als maximum cardinaliteiten. Recente onderzoekers (Feinerer, Dullea et al.) hebben aangetoond dat dit coherenter is wanneer het wordt toegepast op n-ary relaties van een orde groter dan 2.

In Dullea et al. leest men “Een ‘look across’ notatie zoals gebruikt in de UML geeft niet effectief de semantiek weer van participatiebeperkingen die worden opgelegd aan relaties waarbij de graad hoger is dan binair.”

In Feinerer staat “Problemen ontstaan als we werken volgens de look-across semantiek zoals gebruikt voor UML associaties. Hartmann onderzoekt deze situatie en laat zien hoe en waarom verschillende transformaties falen.” (Hoewel de genoemde “reductie” vals is omdat de twee diagrammen 3.4 en 3.5 in feite hetzelfde zijn) en ook “Zoals we op de volgende pagina’s zullen zien, introduceert de look-across interpretatie verschillende moeilijkheden die de uitbreiding van eenvoudige mechanismen van binaire naar n-ary associaties verhinderen.”

Verschillende methoden om dezelfde één-op-veel relatie weer te geven. In elk geval toont het diagram de relatie tussen een persoon en een geboorteplaats: elke persoon moet op één, en slechts één, plaats zijn geboren, maar op elke plaats kunnen nul of meer mensen zijn geboren.

Twee gerelateerde entiteiten weergegeven met behulp van Kraaienpoot-notatie. In dit voorbeeld wordt een optionele relatie getoond tussen Artiest en Lied; de symbolen die het dichtst bij de entiteit Lied staan staan voor “nul, één, of veel”, terwijl een lied “één en slechts één” Artiest heeft. Het eerste voorbeeld wordt daarom gelezen als: een artiest (kan) “nul, één, of veel” song(s) uitvoeren.

Chen’s notatie voor het modelleren van entiteiten-relaties gebruikt rechthoeken om entiteitenreeksen weer te geven, en ruiten om relaties weer te geven die passen bij eersteklas objecten: ze kunnen eigen attributen en relaties hebben.

Attributen worden getekend als ovalen en worden met een lijn verbonden met precies één entity of relationship set.

Cardinaliteitsbeperkingen worden als volgt uitgedrukt:

• een dubbele lijn geeft een deelnemingsbeperking aan, totaliteit of surjectiviteit: alle entiteiten in de entiteitenverzameling moeten aan ten minste één relatie in de relatieset deelnemen;
• een pijl van entiteitenverzameling naar relatieset geeft een sleutelbeperking aan, d. w. z. injectiviteit: elke entiteit van de entiteitenverzameling moet aan ten minste één relatie in de relatieset deelnemen;
• een pijl van entiteitenverzameling naar relatieset geeft een sleutelbeperking aan, d. w. z.d.w.z. injectiviteit: elke entiteit van de entiteitenverzameling kan aan ten hoogste één relatie in de relatieset deelnemen;
• een dikke lijn geeft beide aan, d.w.z. bijectiviteit: elke entiteit in de entiteitenverzameling is bij precies één relatie betrokken.
• een onderstreepte naam van een attribuut geeft aan dat het een sleutel is: twee verschillende entiteiten of relaties met dit attribuut hebben altijd verschillende waarden voor dit attribuut.

Attributen worden vaak weggelaten omdat ze een diagram onoverzichtelijk kunnen maken; andere diagramtechnieken vermelden de entiteitsattributen vaak binnen de rechthoeken die voor de entiteitensets zijn getekend.

Gerelateerde conventie-technieken voor diagrammen:

• Bachman-notatie
• Barker’s notatie
• EXPRESS
• IDEF1X
• Crow’s foot-notatie (ook Martin-notatie)
• (min, max)-notatie van Jean-Raymond Abrial uit 1974
• UML klassendiagrammen
• Merise
• Object-rol modellering

Crow’s foot notationEdit

Crow’s foot notation, waarvan het begin dateert uit een artikel van Gordon Everest (1976), wordt gebruikt in Barker’s notatie, Structured Systems Analysis and Design Method (SSADM) en informatietechnologie engineering. Kraaienpoot diagrammen stellen entiteiten voor als dozen, en relaties als lijnen tussen de dozen. Verschillende vormen aan de uiteinden van deze lijnen geven de relatieve kardinaliteit van de relatie weer.

Crow’s foot notatie werd gebruikt in de consultancy praktijk CACI. Veel van de consultants bij CACI (waaronder Richard Barker) verhuisden vervolgens naar Oracle UK, waar zij de vroege versies van Oracle’s CASE tools ontwikkelden en de notatie bij een breder publiek introduceerden.

Met deze notatie kunnen relaties geen attributen hebben. Waar nodig worden relaties gepromoveerd tot entiteiten op zichzelf: bijvoorbeeld, als het nodig is om vast te leggen waar en wanneer een artiest een liedje heeft uitgevoerd, wordt een nieuwe entiteit “performance” geïntroduceerd (met attributen die de tijd en plaats weergeven), en de relatie van een artiest tot een liedje wordt een indirecte relatie via de performance (artiest-performs-performance, performance-features-song).

Drie symbolen worden gebruikt om kardinaliteit weer te geven:

• de ring staat voor “nul”
• het streepje staat voor “één”
• het kraaienpootje staat voor “veel” of “oneindig”

Deze symbolen worden in paren gebruikt om de vier soorten kardinaliteit weer te geven die een entiteit in een relatie kan hebben. De binnenste component van de notatie vertegenwoordigt het minimum, en de buitenste component het maximum.

• ring en streepje → minimaal nul, maximaal één (optioneel)
• streepje en streepje → minimaal één, maximaal één (verplicht)
• ring en kraaienpoot → minimaal nul, maximaal veel (optioneel)
• streepje en kraaienpoot → minimaal één, maximaal veel (verplicht)

Model usability issuesEdit

Bij het gebruik van een gemodelleerde database kunnen gebruikers twee bekende problemen tegenkomen waarbij de geretourneerde resultaten iets anders betekenen dan de resultaten die door de query-auteur zijn verondersteld.

De eerste is de ‘fan trap’. Deze doet zich voor bij een (master)tabel die gekoppeld is aan meerdere tabellen in een one-to-many relatie. Het probleem dankt zijn naam aan de manier waarop het model eruit ziet wanneer het in een entiteit-relatiediagram wordt getekend: de gekoppelde tabellen “waaieren uit” van de hoofdtabel. Dit type model lijkt op een sterschema, een type model dat in data warehouses wordt gebruikt. Wanneer men sommen over aggregaten probeert te berekenen met standaard SQL over de hoofdtabel, kunnen onverwachte (en onjuiste) resultaten optreden. De oplossing bestaat erin ofwel het model ofwel de SQL aan te passen. Dit probleem doet zich vooral voor in databases voor beslissingsondersteunende systemen, en software die dergelijke systemen bevraagt bevat soms specifieke methoden om met dit probleem om te gaan.

Het tweede probleem is een ‘chasm trap’. Een “chasm trap” doet zich voor wanneer een model het bestaan van een relatie tussen entiteittypen suggereert, maar het pad niet bestaat tussen bepaalde entiteitsvoorkomens. Bijvoorbeeld, een gebouw heeft één of meer kamers, die nul of meer computers bevatten. Men zou verwachten dat men het model kan bevragen om alle computers in het gebouw te zien. Computers die momenteel niet aan een kamer zijn toegewezen (omdat ze in reparatie zijn of ergens anders) worden echter niet in de lijst getoond. Er is een andere relatie tussen Gebouw en Computers nodig om alle computers in het gebouw vast te leggen. Dit laatste modelleervraagstuk is het gevolg van het feit dat niet alle relaties die in de echte wereld bestaan, in het model zijn vastgelegd. Zie Entity-Relationship Modelling 2 voor details.