Entity-Relationship-Diagramme

EmployeeSupervisionmanagesworks forDepartmentNameLocationsIDcontrolsProjectworks onHoursIDLocationNameNumber ofemployeesStartdateSsnBirth dateNameFirst nameLast nameSexSalaryAddressMiddle nameN1N1111NMN
Beispiel: Einfaches Datenmodell mit Mitarbeitern, Abteilungen und Projekten

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.

Inhaltsverzeichnis

  1. Begriffsbestimmung
  2. Basiselemente
    1. Entitätstypen
    2. Relationship-Typen
    3. Attribute
  3. Kardinalität
  4. Totale Teilnahme
  5. Schwache Entitäten und identifizierende Relationships
  6. Erweitertes Entity-Relationship-Modell
    1. Einfache Vererbung
    2. Disjunkte Unterklassen
    3. Überlappende Unterklassen
    4. Kategorien
  7. Literatur

Begriffsbestimmung

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:

Basiselemente

Entitätstypen

Entitätstyp
Ein Entitätstyp ist eine Typisierung gleichartiger Entitäten, z.B. Angestellte, Projekte, Abteilungen. Entitätstypen werden in starke Entitätstypen (dargestellt wie obenlinks) und schwache Entitätstypen (siehe unten) unterschieden — abhängig davon, ob es ein oder mehrere Schlüsselattribute des gleichen Entitätstyps gibt (stark) bzw. verbundene Entitäten zur Identifizierung nötig sind (schwach).
Schwacher Entitätstyp
Für die Identifizierung von schwachen Entitäten ist ein Attributwert einer anderen mit dieser Entität in Beziehung stehenden starken Entität nötig, z.B. könnten Raumnummern erst mit dem in Beziehung stehenden Gebäude identifizierbar werden. Schwache Entitäten und identifizierende Relationships werden in einem eigenen Abschnitt erläutert.

Relationship-Typen

Relation- ship
Relationship-Typen sind eine Typisierung gleichartiger Beziehungen / Verknüpfungen, z.B. Mitarbeiter leitet Projekt, Mitarbeiter ist Mitarbeiter von Abteilung. Relationship-Typen sind binär oder n-är, wobei der gleiche Entitätstyp in einer oder mehreren Rollen auftreten kann. Rollen in Entitäten werden mit einer durchgezogenen Linie zwischen Entitätstyp und Relationship-Typ dargestellt.
Ident. Relation- ship
Identifizierende Relationship-Typen erlauben, der Benennung entsprechend, die Identifizierung von schwachen Entitäten. Zum Beispiel kann der schwache Entitätstyp Räume mit dem starken Entitätstyp Gebäude über den identifizierenden Relationship-Typen in verbunden sein — und die Identifizierung einer einzelnen Entität erfolgt über den partiellen Schlüssel Raumnummer sowie über den Fremdschlüssel Gebäudenummer. Schwache Entitäten und identifizierende Relationships werden genauer in einem eigenen Abschnitt erläutert.

Attribute

Attribut
Attribute sind Typisierungen von Merkmalen von Objekten eines Entitätstyps — und repräsentieren z.B. Vornamen, Nachnamen, Geburtsdaten. Es gibt verschiedene Arten von Attributen, die mit unterschiedlichen Rahmen (mehrwertig, abgeleitet) bzw. unterstrichen (Schlüsselattribute, partielle Schlüssel) dargestellt werden.
Schlüssel- attribut
Schlüsselattribute sind Attribute oder Attributkombinationen, die eine Entität eindeutig identifizieren. Handelt es sich bei einem Schlüsselattribut um eine Attributkombination, so wird dieses als zusammengesetztes Attribut modelliert, wobei der Wurzelknoten dabei ein Schlüsselattribut ist. Somit können mehrere unterschiedliche Attributkombinationen oder einzelne identifizierende Attribute klar voneinander abgegrenzt als Schlüsselattribute dargestellt werden.
Mehrwertiges Attribut
Attribute können aus mehreren Werten bestehen, z.B. für mehrere Adressen für eine Person oder mehrere Stichwörter für ein Dokument. Solche mehrwertigen Attribute werden mit einer Ellipse mit doppelter Linie dargestellt.
Abgeleitetes Attribut
Manche Informationen zu einer Entität sind bereits anhand anderer Attribute oder Beziehungen bekannt, z.B. das Alter anhand des aktuellen Datums und Geburtstages einer Person oder die Anzahl an Bestellungen durch die Menge an gespeicherten Beziehungen zwischen Person und Bestellungen. Abgeleitete Attribute stellen dar, dass solche Informationen zu Entitäten bekannt sind, aber nicht (erneut) gespeichert werden müssen.
Partieller Schlüssel
Für die Identifizierung von schwachen Entitäten werden in der Regel sowohl partielle Schlüsselattribute als auch identifizierende Relationships benötigt. Attribute einer schwachen Entität, die partiell diese Entität identifizieren können, werden gestrichelt unterstrichen dargestellt.
Zusammen-gesetztes AttributBAC

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.

Kardinalität

1:1

PersonFührer-scheinhat11
Beispiel: 1:1-Beziehung

1:1

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.

1:n

MitarbeiterAbteilungarbeitetinN1
Beispiel: 1:n-Beziehung

1:n

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.

n:m

KundeProduktkauftNM
Beispiel: n:m-Beziehung

n:m

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 in n-ären Beziehungen

Kardinalitäten mit mehreren beteiligten Entitätstypen werden in einschlägigen Vorlesungen und in Fachbüchern behandelt.

Totale Teilnahme

PersonFührer-scheinhat11
Beispiel: Totale Teilnahme - kein Führerschein ohne Inhaber

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.

Schwache Entitäten und identifizierende Relationships

RaumGebäudegehörtzuRaum-Nr.Gebäude-Nr.StockwerkAdresseN1
Beispiel: Räume von Gebäuden als schwache Entitätstypen

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.

Erweitertes Entity-Relationship-Modell

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.

Einfache Vererbung

FahrzeugAuto

Einfache Vererbung

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.

Disjunkte Unterklassen

FahrzeugdAutoLKWFracht-raumMax. PersonenFahrzeug-IDKennzeichen
Beispiel: Disjunkte Unterklassen

Disjunkte Unterklassen

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

oAlumnusStudentMitarbeiterPersonNameHauptfachGehaltAkad. GradeSSN
Beispiel: Überlappende Unterklassen

Überlappende Unterklassen

Ü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

UnternehmenBankPersonuBesitzer
Beispiel: Kategorie

Kategorien

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.

Literatur

Elmasri, R., & Navathe, S. B. (2017). Fundamentals of Database Systems 7th Edition.

Dr. Johannes Tenschert

CEO, Process Science

+49 89 21540190
johannes.tenschert@pertuniti.de

Wir nutzen Cookies und Google Analytics um diese Webseite für Sie zu optimieren. Sind Sie damit einverstanden? (Opt-In)

(Sie können diese Entscheidung jederzeit widerrufen - mehr Informationen)