Entity-Relationship-Modell
Das Entity-Relationship-Modell, kurz ER-Modell oder ERM, dient dazu, im Rahmen der Datenmodellierung einen Ausschnitt der realen Welt zu beschreiben. Das ER-Modell besteht meist aus einer Grafik und einer Beschreibung der darin verwendeten einzelnen Elemente (siehe nachfolgend unter Darstellungsformen). Es dient zum einen in der konzeptionellen Phase der Anwendungsentwicklung der Verständigung zwischen Anwendern und Entwicklern, wobei ausschließlich das Was, also die Sachlogik, und nicht das Wie, also die Technik, wesentlich ist. Zum anderen dient das ER-Modell in der Implementierungsphase als Grundlage für das Design der Datenbank.
Begriffe
Die beiden Begriffe Entity und Relationship können folgendermaßen charakterisiert werden:
- Gegenstand oder Entität (Entity)1): Repräsentant für die Dinge (Subjekte, Objekte) der Wirklichkeit (z. B. Angestellter, Projekt, Buch, Autor, Verlag).
- Beziehung (Relationship)2): semantischer Zusammenhang zwischen i. d. R. zwei Gegenständen z. B.
- „leitet“ als Beziehung zwischen Angestellter und Projekt
- „verfasst“ als Beziehung zwischen Autor und Buch
- „ist Herausgeber von“ als Beziehung zwischen Verlag und Buch
- „ist Vorgesetzter von“ als Beziehung zwischen Angestellter und Angestellter.
- Kardinalität: mögliche Anzahl der an einer Beziehung beteiligten Gegenstände; so kann ein Angestellter mehrere Projekte leiten, während ein Projekt von genau einem Angestellten geleitet wird.
1) Gegenstandstyp und Entitätsstyp (Entity type) wären hier die genauen Bezeichnungen; in der betrieblichen Praxis spricht man aber meist von Entität. Der Unterschied zwischen der Entität als Einzelobjekt (z. B. "Albert Schweitzer") und der Entität als Menge aller Objekte (z. B. "Arzt") ergibt sich i. d. R. aus dem Zusammenhang.
2) entsprechend wäre hier die genaue Bezeichnung Beziehungstyp (Relationship type).
Beziehungen mit spezieller Semantik
Die inhaltliche Bedeutung der Beziehung zwischen Entitäten kommt im ER-Diagramm lediglich durch einen kurzen Text in der Raute (meist ein Verb) bzw. als Beschriftung der Kante zum Ausdruck), wobei es dem Modellierer freigestellt ist, welche Bezeichnung er vergibt. Nun gibt es Relationships mit spezieller Semantik, die relativ häufig bei der Modellierung vorkommen. Daher hat man für diese Relationships spezielle Bezeichner und grafische Symbole definiert. Spezialisierung / Generalisierung und Zerlegung / Aggregation sind zwei ergänzende Beschreibungsmittel mit einer speziellen Semantik. Mit diesen beiden speziellen Relationships kann die Realwelt verfeinert / vergröbert modelliert werden. Mit fest definierten Namen und speziellen grafischen Symbolen wird gezeigt, dass es sich um semantisch vorbesetzte Relationships handelt.
Die Spezialisierung / Generalisierung mittels "is-a"-Relationship
Bei der Spezialisierung wird ein Entity1) als Teilmenge einer anderen Entity deklariert, wobei sich die Teilmenge (spezialisierte Menge) durch besondere Eigenschaften (spezielle Attribute und/oder Relationships) gegenüber der übergeordneten (generalisierten Menge) auszeichnet. Da es sich bei einem Einzelobjekt einer spezialisierten Menge um dasselbe Einzelobjekt der generalisierten Menge handelt, gelten alle Eigenschaften – insbesondere die Identifikation - und alle Beziehungen des generalisierten Einzelobjektes auch für das spezialisierte Einzelobjekt.
Das Relationship Spezialisierung/Generalisierung wird durch "is-a" / "can-be" beschrieben.
Für "is-a" wird gelegentlich auch "a-kind-of" benutzt. Es handelt sich hierbei um ein 1:c-Relationship.
Beispiel zur "is-a"-relationship: Dackel is-a Hund
und in anderer Leserichtung: Hund can-be Dackel
Die Spezialisierung erhält man durch Aufteilung, während die Generalisierung durch Zusammenführen von gleichen Einzelobjekten mit gemeinsamen Eigenschaften und Beziehungen, die in verschiedenen Entities vorkommen, in einem neuen Entity begründet ist. So können z.B. Kunden und Lieferanten zusätzlich zu Geschäftspartnern zusammengeführt werden, da Name, Anschrift, Bankverbindung etc. sowohl bei den Kunden als auch bei den Lieferanten vorkommen.
Die Aggregation / Zerlegung mittels „is-part-of“-Relationship
Werden mehrere Einzelobjekte (z.B. Person und Hotel) zu einem eigenständigen Einzelobjekt (z.B. Reservierung) zusammengefasst, dann spricht man von Aggregation.
Dabei wird das übergeordnet eigenständige Ganze Aggregat genannt;
die Teile, aus denen es sich zusammensetzt, heißen Komponenten.
Aggregat und Komponenten werden als Entities deklariert.
Bei Aggregation / Zerlegung wird zwischen Rollen- und Mengenaggregation unterschieden:
Eine Rollenaggregation liegt vor, wenn es mehrere rollenspezifische Komponenten gibt, diese zu einem Aggregat zusammengefasst werden und es sich um ein 1:c-Relationship handelt.
Beispiel zur "is-part-of"-relationship: Fußballmannschaft is-part-of Fußballspiel und Spielort is-part-of Fußballspiel
und in anderer Leserichtung: Fußballspiel besteht-aus Fußballmannschaft und Spielort.
Eine Mengenaggregation liegt vor, wenn das Aggregat durch Zusammenfassung von Einzelobjekten aus genau einer Komponente entsteht. Hier liegt ein 1:cN-Relationship vor.
Beispiel zur Mengenaggregation: Fußballspieler is-part-of Fußballmannschaft
und in anderer Leserichtung: Fußballmannschaft besteht aus (mehreren, N) Fußballspielern
Darstellungsformen
Die graphische Form des ER-Modells wird Entity-Relationship-Diagram (ERD) oder ER-Diagramm genannt.
Es sind mehrere Darstellungsformen für das ER-Modell in Gebrauch.
Für die Entität wird einheitlich das Rechteck verwendet.
Das Relationship wird gelegentlich als Raute mit Verbindungslinien zwischen den beteiligten Entitäten dargestellt. Meist wird aus Platzgründen auf die Raute verzichtet, was allerdings nur bei binären Relationships (Beziehung zwischen genau zwei beteiligten Gegenständen) möglich ist.
Für die Darstellung der Kardinalitäten haben sich die folgenden Notationen etabliert:
- Chen-Notation oder (1,n)-Notation (und davon abgeleitet die UML-Darstellung).
- Bachmann-Notation oder Martin-Notation oder „Krähenfuß-Notation“
- Numerische Notation oder (min,max)-Notation
- MC(Must,Can)-Notation oder (1,c,m)-Notation
- IDEF1X-Notation
Folgende Zusammenstellung versucht einen Überblick darüber zu geben, wie die Kardinalität von Beziehungen in verschiedenen Notationen ausgedrückt wird (Die Beispiele zu MC- und Bachmann-Notation sind mangels Referenzen noch als ungesichert zu betrachten)
____________ n 1 ____________ Chen: | Person |---------< geboren_in >---------| Geburtsort | ____________ 1 n ____________ Schlageter/Stucky: | Person |---------< geboren_in >---------| Geburtsort | ____________ [1,1] [0,*] ____________ ISO: | Person |---------< geboren_in >---------| Geburtsort | ____________ MC 1 ____________ Must-Can: | Person |---------< geboren_in >---------| Geburtsort | ____________ ____________ Bachmann: | Person |>O-------< geboren_in >-------|-| Geburtsort | ____________ ____________ Pfeil: | Person |<<----------------------------|>| Geburtsort | ____________ 1 ____________ IDEF1X: | Person |O-----------------------------<>| Geburtsort |
Das Resource Description Framework (RDF) beruht ebenfalls auf dem Konzept von Entity-Relationship-Modellen und bietet seinerseits verschiedene Notationen an. Zur konkreten Implementierung eines ER-Modells in einem relationalen Datenbanksystem wird meistens die Sprache SQL verwendet.
Einsatz in der Praxis
Das ER-Modell kann (und soll) bei der Erstellung von Datenbanken zunächst bei der Konzeption einer Datenbank, auf deren Grundlage dann die Implementierung der Datenbank erfolgt, genutzt werden. Die Umsetzung der in der Realwelt erkannten Objekte und Beziehungen in ein Datenbank-Schema erfolgt dabei in mehreren Schritten:
- Erkennen und Zusammenfassen von Objekten zu Entitäten1) durch Abstraktion von Einzelobjekten zu einer Entität (z.B. Die Kollegen Fritz Maier und Paul Lehmann und viele weitere zu der Entität "Angestellter").
- Erkennen und Zusammenfassen von Beziehungen zwischen je zwei Objekten zu einer Relationship (z.B. der Angestellte Paul Lehmann leitet das Projekt Verbesserung des Betriebsklimas und der Angestellte Fritz Maier leitet das Projekt Effizienzsteigerung in der Verwaltung). Dies führt zu der Relationship "Angestellter leitet Projekt".
- Bestimmung der Kardinalitäten, d.h. der Häufigkeit des Auftretens (z.B. wird ein Projekt immer von genau einem Angestellten geleitet und ein Angestellter darf höchsten drei Projekte leiten.)
All dies lässt sich in einem ER-Modell darstellen.
Weiter sind folgende Schritte notwendig, die meist jedoch nicht grafisch dargestellt werden (so z.B. in der obigen Grafik):
- Bestimmung der relevanten Attribute der einzelnen Entitäten.
- Markierung bestimmter Attribute einer Entität als identifizierende Attribute.
- Durchführung des Prozesses der Normalisierung, um die Redundanz innerhalb der zu erstellenden Datenbank zu verringern und um die Datenintegrität zu erhöhen. Da das Ergebnis der Normalisierung meist zu neuen Entitäten und geänderten Relationships führt, beginnt man in diesen Fällen wieder mit dem ersten Schritt.
- Generierung des Schemas einer relationalen Datenbank mit all seinen Tabellen- und zugehörigen Feld(definitionen) mit ihren jeweiligen Datentypen.
Geschichte
Das ER-Modell wurde 1976 von Peter Chen in seiner Veröffentlichung The Entity-Relationship Model vorgestellt. Die Beschreibungsmittel für Generalisierung und Aggregation wurden 1977 von Smith and Smith eingeführt. Danach gab es einige Weiterentwicklungen so z.B. Ende der 80er Jahre durch Wong und Katz.
Das ERM ist das erste Beschreibungsmittel zur Erstellung von konzeptionellen Schemata.
Erweiterungen
Eine Erweiterung des ERM stellt das Structured Entity Relationship Model (SERM) dar, mit dem Existenzabhängigkeiten visualisiert werden können.
Siehe auch
Literatur
- Peter Pin-Shan Chen: The Entity-Relationship Model--Toward a Unified View of Data. In: ACM Transactions on Database Systems 1/1/1976 ACM-Press ISBN 0362-5915, S. 9-36
- J.M. Smith, D.C.P. Smith: Database Abstractions: Aggregation and Generalization, ACM Transactions on Database Systems, Vol. 2, No. 2 (1977), S. 105-133)
- J. M. Smith and D. C. P. Smith: Database Abstraction: Aggregation, Communications of the ACM, Vol. 20, Nr. 6, pp. 405-413, June 1977
Werkzeuge
- DB Designer 4.0 (GPL)
- Innovator
- ADW
- case/4/0
- Dia_gtk
- ERwin
- Oracle Designer
- GNU Ferret
- Visio von Microsoft
- Rochade Metadaten-Repository
- ARIS von IDS Scheer