Das Entity-Relationship-Modell (ERM) wird insbesondere in der Modellierung von Datenbankstrukturen, z.B. zur Beschreibung der Informationen und Zusammenhänge von Informationssystemen, eingesetzt. Das Entity-Relationship-Modell ist die bekannteste Notation in der semantischen Datenmodellierung — und dient dazu, Dinge / Gegenstände / Objekte (Entities) und deren Beziehungen / Zusammenhänge (Relationships) zu beschreiben.
Das Erweiterte Entity-Relationship-Modell (EERM) beinhaltet alle Elemente von ER-Modellen und erweitert die Notation hinsichtlich Beziehungen von Entitätstypen: Vererbung, Spezialisierung / Generalisierung, Kategorien. Mit diesen neuen Beziehungen zwischen Entitätstypen können Zusammenhänge auf verschiedenen Granularitäten und gemeinsame Attribute komplexer Datenarchitekturen leichter dargestellt werden.
Pertuniti setzt die Chen-Notation für ER-Diagramme um. Kardinalitäten werden als Text gespeichert und dargestellt, womit auch eine Modellierung in (Min,Max)-Notation möglich ist. ER-Diagramme in Pertuniti werden in einem XML-Schema gespeichert, das die Semantik leicht maschinenlesbar darstellt und somit weitere Automation (z.B. die Generierung von Tabellen und Constraints) ermöglicht. Semantik und Darstellung sind in diesem Schema getrennt organisiert.
Da ER-Modelle Datenstrukturen abstrakt beschreiben, werden manche Begriffe häufig verwechselt oder vereinfacht dargestellt. Zum Beispiel meinen Modellierer mit dem Begriff “Entität” in der Regel den Entitätstyp. Die folgende Liste soll häufig verwendete Begriffe daher klarstellen:
Zusammengesetzte Attribute repräsentieren komplexere Strukturen, die sich auf einen Entitätstypen beziehen. Zusammengesetzte Attribute können mit den anderen Arten von Attributen kombiniert werden, z.B. als mehrwertiges Attribut für verschiedene Adressen jeweils mit Straße, Hausnummer, PLZ, Ort, Land.
In einer 1:1-Beziehung ist jede Entität einer oder keiner anderen Entität zugeordnet. Zum Beispiel kann eine Person einen Führerschein haben, muss jedoch nicht. Ein Führerschein kann auch nur einer Person zugeordnet werden.
1:1-Beziehungen in ER-Modellen sind selten und können ein Indikator dafür sein, dass Entitätstypen stattdessen als Klassenhierarchien abgebildet werden sollten, siehe Erweitertes Entity-Relationship-Modell.
In einer 1:n-Beziehung ist jede Entität eines Entitätstyps keiner, einer oder mehreren Entitäten eines anderen Entitätstyps zugeordnet. Zum Beispiel kann ein Mitarbeiter in einer Abteilung arbeiten (1 im Beispiel) und eine Abteilung kann mehrere Mitarbeiter haben (N im Beispiel).
1:n-Beziehungen werden in der Regel über einen Fremdschlüssel in der Datenbanktabelle, die auf eine (oder keine: NULL) andere Entität verweist, abgebildet.
In n:m-Beziehungen können Entitäten auf beiden Seiten jeweils beliebig häufig in Beziehung zueinander stehen, z.B. kann ein Kunde keines, eines oder mehrere Produkte kaufen und ein Produkt nicht, einmal oder häufiger gekauft werden.
Häufig könnten n:m-Beziehungen besser als eigener Entitätstyp modelliert werden. So macht das o.g. Beispiel zwar viel Sinn, wenn Kunden ähnliche Produkte auf Basis ihrer bisherigen Käufe vorgeschlagen werden sollen — und dafür die Beziehung analysiert wird. Allerdings handelt es sich bei der kauft-Beziehung nicht um Bestellungen: Der gleiche Kunde könnte das gleiche Produkt häufiger kaufen, die konkrete Beziehung zwischen diesem Kunden und Produkt gibt es jedoch nur einmal.
Zur Abbildung in Datenbankstrukturen werden n:m-Beziehungen in der Regel in zwei 1:n-Beziehungen aufgeteilt. Die entsprechend erzeugte zusätzliche Datenbanktabelle besteht aus Fremdschlüsseln der beteiligten Entitätstypen und Attributen des ursprünglichen Beziehungstyps.
Kardinalitäten mit mehreren beteiligten Entitätstypen werden in einschlägigen Vorlesungen und in Fachbüchern behandelt.
Jede Entität eines Entitätstyps, deren Rolle in einem Beziehungstyp mit doppelter Linie als totale Teilnahme an dem Beziehungstyp markiert ist, muss an mindestens einer konkreten Beziehung dieses Beziehungstyps teilnehmen.
Das Beispiel zur 1:1-Beziehung wird durch eine totale Teilnahme plausibler: Ein Führerschein wird immer genau einer Person zugeordnet. Nicht jede Person muss einen Führerschein haben. Totale Teilnahmen werden auch im erweiterten Entity-Relationship-Modell zur Konkretisierung von disjunkten und überlappenden Unterklassen sowie für Kategorien verwendet.
Anhand des oben eingeführten Beispiels mit Gebäuden und Räumen werden schwache Entitäten und identifizierende Relationships nun verdeutlicht.
Für einen Konzern werden Gebäude und Räume modelliert. Gebäude können sich auf einem größeren Campus eine Adresse teilen, d.h. pro Gebäude muss die komplette Adresse nicht eindeutig sein. Stattdessen erhält jedes Gebäude unternehmensweit eine eindeutige Gebäude-Nummer, die auf einem individuellen Campus ausgeschildert wird und das Gebäude in der Datenbank und für Mitarbeiter eindeutig identifiziert.
Ein Gebäude kann viele Räume beinhalten, ein Raum kann jedoch ausschließlich in genau einem Gebäude befinden. Jeder Raum erhält eine Raum-Nummer, die sowohl das Stockwerk als auch eine beliebige laufende Nummer enthält, die für das Gebäude und Stockwerk eindeutig ist, z.B. “3-12” (Stockwerk 3, Raum 12). Die gleiche Raum-Nummer kann für einige Gebäude neu vergeben werden, ist innerhalb von diesem Gebäude jedoch eindeutig. Das Stockwerk ist anhand der Raumnummer leicht abzulesen bzw. kann davon abgeleitet werden.
Die Raum-Nummer ist somit ein partielles Schlüsselattribut, das ausschließlich zusammen mit dem zugehörigen Gebäude eindeutig wird. Der Entitätstyp Raum ist ein schwacher Entitätstyp, da zur Identifizierung einer konkreten Entität das zum Entitätstyp Gebäude gehörende Schlüsselattribut Gebäude-Nummer nötig ist. Die Beziehung gehört zu macht dieser Umstand zu einem identifizierenden Beziehungstyp.
Häufig sind Typen von zu modellierenden Realweltobjekten sehr ähnlich, z.B. haben Mitarbeiter und Kunden als Kontakte beide einen Namen und eine Adresse. Es bietet sich daher an, z.B. “Klassenhierarchien” oder Bottom-Up-Kategorien zu bilden, mit denen man ähnliche Attribute und Beziehungstypen abstrahieren und übersichtlicher gestalten kann.
Eine Modellierung von Hierarchien von unterschiedlichen Entitätstypen liegt dabei nahe, um alle bekannten Elemente von ER-Diagrammen einsetzen zu können. Die Verbindung innerhalb von Hierarchien ist mit einem Relationship-Typen jedoch nicht möglich, da es sich bei den Entitäten der beteiligten Entitätstypen um das selbe Realweltobjekt handelt. In diesem Abschnitt werden exemplarisch einfache Vererbung, disjunkte und überlappende Unterklassen sowie Kategorien eingeführt. Alle Elemente des erweiterten Entity-Relationship-Modells können ebenfalls in Pertuniti modelliert werden.
Vererbung in erweiterten Entity-Relationship-Modellen wird in Pertuniti mit der Notation von Elmasri & Navathe (2017) umgesetzt — sowohl für einfache Vererbung wie hier im Beispiel, als auch für Unterklassen und Kategorien.
Bei der einfachen Vererbung handelt es sich um eine IST-EIN Beziehung, d.h. jede Entität aus der Unterklasse (hier Auto) ist immer auch Mitglied der Oberklasse (hier Fahrzeug). Totale Teilnahmen müssen bei dieser Darstellung nicht annotiert werden, da die Unterklasse immer total teilnimmt — und wenn dies auch für die Oberklasse gilt, kann man auf die Aufteilung in zwei Klassen verzichten.
Bei der Vererbung werden alle Attribute und Beziehungen der Oberklasse an die Unterklasse “vererbt”, d.h. die Vererbung kann zur Generalisierung und Spezialisierung von Entitäten verwendet werden.
Eine Klassenhierarchie mit disjunkten Unterklassen wird über einen Kreis mit einem “d” (disjoint) angezeigt. Die Oberklasse wird mit einer durchgezogenen Linie — oder einer doppelten Linie für totale Teilnahme der Oberklasse — repräsentiert. Die Verbindungen der Unterklassen werden mit einem “U” auf der Linie markiert. Unterklassen nehmen immer total an der Beziehung teil, weshalb auch hier keine totale Teilnahme mit doppelter Linie dargestellt wird.
Für disjunkte Unterklassen im Beispiel gilt, dass jede Fahrzeug-Entität (totale Teilnahme an der Beziehung) entweder auch vom Entitätstyp Auto oder vom Entitätstyp LKW ist, zumindest in der modellierten Mini-Welt. Jedes Auto und jeder LKW haben dabei eine Fahrzeug-ID, ein Kennzeichen (beides jeweils als Schlüsselattribut nutzbar), aber nur Autos haben eine Angabe zur maximalen Personenzahl und nur LKWs genaue Angaben zum Frachtraum. Beziehungen zu Fahrzeugen, z.B. für Vermietungen, Lieferungen oder Verkäufe, gelten auch für Autos und LKW.
Überlappende Unterklassen werden abseits von einem “o” (overlapping) wie disjunkte Unterklassen notiert. Auch hier kann die Teilnahme der Oberklasse total sein.
Für überlappende Oberklassen im Beispiel gilt, dass jede Entität vom Typ Person (totale Teilnahme an der Beziehung) auch eine Entität von mindestens einer der Unterklassen Mitarbeiter, Alumnus oder Student ist, d.h. Stammdaten zu abstrakten Personen werden werden im Entitätstyp Person organsiert, während für die jeweilige Unterklasse spezifische Eigenschaften dort modelliert werden.
Überlappende Unterklassen bedeuten nicht, dass konkrete Instanzen auch immer überlappen müssen, sondern dass auch Instanzen, die Teil mehrerer Unterklassen sind, im Datenmodell möglich sind.
Kategorien sind Teilmengen der Vereinigungsmenge von mehreren Entitymengen. Am Beispiel ausgedrückt kann jede Person, jedes Unternehmen und jede Bank grundsätzlich vom Entitätstyp Besitzer sein, muss es aber nicht. Jeder Besitzer ist eine Person, ein Unternehmen oder eine Bank, d.h. wie eine Unterklasse nimmt die Kategorie “Besitzer” an dieser Beziehung zwischen Entitätstypen total teil.
Wird eine Kategorie mit einer doppelten Linie markiert, so nehmen alle Entitätstypen, die zur Kategorie vereinigt werden, total teil. Diese Situation kann auch mit disjunkten Unterklassen dargestellt werden.
Elmasri, R., & Navathe, S. B. (2017). Fundamentals of Database Systems 7th Edition.