Entity-Relationship-Diagramm
Das Entity-Relationship-Diagramm (ERD, auch Entitäten-Beziehungs-Modell genannt) ist die grafische Form eines Datenmodells. Es zeigt die Entitäten, über die eine Organisation Informationen führt, die Attribute, die sie beschreiben, den Identifikator, der jede Ausprägung unterscheidet, und die Beziehungen, die sie verbinden, samt der minimalen und maximalen Zahl zulässiger Ausprägungen an jedem Ende einer Beziehung, was man Kardinalität nennt. Es ist eine der beiden Notationen, die die Datenmodellierung verwendet, neben dem UML-Klassendiagramm, und diejenige, zu der man greift, um das Schema einer relationalen Datenbank zu entwerfen. Auf der konzeptionellen Ebene bleibt das ERD im Vokabular des Geschäfts und ist ein gemeinsames Bild zwischen den Fachexperten und denen, die implementieren; auf der logischen und der physischen Ebene wird es zum Bauplan der Datenbank. Seine Kardinalität wird meist in Krähenfussnotation (crow's foot) gezeichnet.
Zweck
Das Entity-Relationship-Diagramm gibt ein neutrales, technologieunabhängiges Bild der Informationen, die eine Organisation braucht, und davon, wie diese zusammenhängen: die Dinge, über die das Geschäft Buch führt (die Entitäten), was über jedes festgehalten wird (die Attribute) und die Regeln, die sie verbinden (die Beziehungen und ihre Kardinalitäten). Es beantwortet eine Frage, die der Fliesstext eines Anforderungsdokuments offen lässt: von welchen Entitäten ist die Rede, welche hängt von welcher ab, und wie viele Ausprägungen der einen knüpfen an eine einzelne Ausprägung der anderen an.
Sein Wert zeigt sich an zwei Punkten. Auf der konzeptionellen Ebene ist es ein Artefakt der Elizitation und der Kommunikation: ein gemeinsames Vokabular zwischen den Fachexperten, die die Entitäten und Beziehungen bestätigen oder verwerfen, und denen, die die Lösung bauen werden. Auf der logischen und der physischen Ebene wird dasselbe Modell zum Ausgangspunkt eines relationalen Schemas, der Struktur der persistenten Daten, die die Datenbank umsetzt. Das Ergebnis ist das Diagramm samt den Definitionen, die es dokumentieren, jenen der Entitäten und der Attribute, die meist in einem Datenwörterbuch geführt werden.
Einsatz
Wann einzusetzen
- Strukturierte, persistente Daten im Zentrum der Veränderung: Datensätze, Transaktionen oder Stammdaten, die es zu fassen gilt.
- Datenvokabular fehlt oder ist umstritten: die Entitäten und ihre Beziehungen festlegen, damit alle von denselben Dingen sprechen.
- Entwurf einer relationalen Datenbank: das persistente Schema vorab festlegen, das logische und physische ERD trägt es bis in die Datenbank.
- Datenmigration oder -integration: die reale Struktur eines bestehenden Systems rekonstruieren, bevor über eine Übernahme entschieden wird.
- Eine zählende Geschäftsregel: die Kardinalität macht das Wie-viele-X-pro-Y explizit und diskutierbar.
Wann nicht einzusetzen
- Das Thema ist ein Verhalten oder ein Ablauf, keine Daten: die Abfolge der Aktivitäten modellieren, zu einem Prozessmodell wie BPMN oder einem Anwendungsfall greifen.
- Das Objektmodell muss Operationen tragen (ein an die Daten gebundenes Verhalten): zum UML-Klassendiagramm greifen, das allein sie ausdrückt.
- Ein rein fachliches Publikum braucht Bedeutung, nicht Struktur: das Vokabular mit einem Begriffsmodell festlegen, das dieses Publikum liest, wo das ERD ihm eine IT-Struktur aufzwingt.
Beschreibung
Die Elemente der Zeichnung
Ein ERD liest sich aus einer kleinen Zahl von Formen, und ein Business Analyst begegnet mehr davon, als er baut. Es lesen zu können genügt, um ein Modell zu validieren, das ihm vorgelegt wird.
- Die Entität, ein Rechteck, benannt mit einem Substantiv im Singular aus dem Geschäft (Patient, Verordnung, Rechnung): etwas Physisches, Organisatorisches, Abstraktes oder ein Ereignis, worüber die Organisation Buch führt.
- Das Attribut, eine über die Entität festgehaltene Eigenschaft, unter ihrem Namen aufgeführt: der Name des Patienten, das Datum einer Sitzung, der Betrag einer Rechnung.
- Der eindeutige Identifikator, das Attribut oder die Attribute, die jede Ausprägung von den anderen unterscheiden. In den Begriffen des relationalen Modells ist es der Primärschlüssel; er steht an der Spitze der Attribute der Entität.
- Die Beziehung, eine benannte Linie zwischen zwei Entitäten, die sich als Verbalphrase in beide Richtungen liest: ein Patient erhält Sitzungen, eine Sitzung betrifft einen Patienten.
- Die Kardinalität, getragen vom Symbol an jedem Ende der Linie. Sie ist das Element, das die Bedeutung trägt, und jenes, das ein eiliger Leser zu Unrecht übergeht.
Die Kardinalität im Krähenfuss lesen
Die Krähenfussnotation kodiert die Kardinalität mit einem zweiteiligen Symbol an jedem Ende der Beziehung. Die Markierung, die die Entität berührt, gibt das Maximum an: ein Strich für eins, der Krähenfuss, jene dreizinkige Gabel, deren Spitzen sich gegen den Entitätskasten öffnen, für viele. Die weiter auf der Linie zurückgesetzte Markierung gibt das Minimum an: ein Kreis für null (eine optionale Beziehung), ein Strich für eins (eine obligatorische Beziehung). Liest man die Linie zur Entität hin, liest man also zuerst das Minimum und dann das Maximum, und die vier Kombinationen lauten: Kreis und Gabel für null-oder-viele, Strich und Gabel für eins-oder-viele, zwei Striche für genau-eins, Kreis und Strich für null-oder-eins.
Eine Beziehung liest sich in beide Richtungen, und jede Richtung liest sich am Symbol des gegenüberliegenden Endes. Um zu erfahren, wie viele Sitzungen an einen Patienten anknüpfen, liest man das Symbol auf der Sitzungsseite; um zu erfahren, wie viele Patienten an eine Sitzung anknüpfen, liest man das Symbol auf der Patientenseite. Die Zählregel auf jeder Seite ist eine Geschäftstatsache: zu sagen, dass eine Sitzung zu genau einer Verordnung gehört und dass eine Verordnung eine bis mehrere Sitzungen erlaubt, heisst zwei Regeln aufzustellen, die das Geschäft bestätigen muss, jede auf ihrer Seite.
Was die Zeichnung nicht zeigt
Die erste Falle liegt in der Kardinalität selbst. Eine Grenze zu setzen, ohne sie in beide Richtungen zu validieren, ergibt ein Modell, das vollständig aussieht und lügt: ein per Voreinstellung gesetztes Maximum « viele » dort, wo das Geschäft nur einen Fall zulässt, friert eine Regel ein, die niemand bestätigt hat. Die zweite ist das Vermischen der Ebenen: Fremdschlüssel, Spaltentypen oder Indizes in ein konzeptionelles Datenmodell zu lassen, macht es für das Geschäft unlesbar, genau die Grenze, die BABOK nennt, und friert einen physischen Entwurf viel zu früh ein. Die dritte ist das Attribut in der falschen Entität oder die Entität ohne eigenen Identifikator, woraus die klassischen Widersprüche eines Modells entstehen. Die vierte ist die Viele-zu-viele-Beziehung, die so stehen bleibt: sie verbirgt fast immer eine dazwischenliegende, sogenannte assoziative Entität, die eigene Attribute trägt und die niemand benannt hat. Die letzte ist die Benennungsdrift, Entitäten im Plural, Entitäten, die in Wahrheit Prozesse sind, unbenannte Beziehungen; die Namen eines ERD stammen aus dem Vokabular des Geschäfts.
Ein letzter Punkt betrifft das Lesevokabular mehr als die Konstruktion: man begegnet mitunter Subtyp- und Supertyp-Strukturen oder schwachen Entitäten. Ein Leser erkennt sie, ohne ihre Konstruktion beherrschen zu müssen, um ein Modell zu validieren.
Die Notation ist nicht universell
Dasselbe Modell wird in mehreren Notationen gezeichnet, und sie zu verwechseln ist eine Falle für sich. Chens Notation, die der grundlegenden Arbeit, zeichnet Beziehungen als Rauten. Die Krähenfussnotation, auf Everest zurückgehend und dann durch Barkers Methode und die Oracle-Workshops verbreitet, ist die, die BABOKs Abbildung verwendet, und die, die man tatsächlich am Whiteboard zeichnet. Das UML-Klassendiagramm schliesslich trägt dieselbe Information in einer dritten Form, und sein Vokabular ändert sich: wo das ERD von Beziehung und Kardinalität spricht, spricht die Klasse von Assoziation und Multiplizität, für dieselbe Idee einer minimalen und maximalen Grenze. Die praktische Regel passt in eine Zeile: die Legende lesen, nicht zwei Notationen auf einer Zeichnung mischen.
Diese letzte Verwechslung deckt eine tiefere, die von ERD und UML-Klassendiagramm. Das ERD modelliert Daten: Entitäten, ihre Attribute, ihre Beziehungen. Das Klassendiagramm fügt das Verhalten hinzu, die Operationen, die eine Klasse ausführt, das Ausstellen einer Rechnung, das Eröffnen eines Kontos. Eine Domäne, in der zählt, was man mit den Daten tut, ebenso sehr wie ihre Struktur, gehört zum Klassendiagramm; ein Datenbankschema gehört zum ERD. Der Business Analyst arbeitet meist auf der konzeptionellen Ebene, manchmal auf der logischen, und überlässt die physische Ebene dem Datenbankadministrator.
KI-Überlegungen
Ein Sprachmodell leistet mehrere konkrete Dienste bei dieser Technik. Es entwirft ein erstes ERD aus einem Datenwörterbuch oder einem Anforderungstext, schlägt fehlende Entitäten und Attribute vor, erzeugt die Datendefinitionssprache (DDL) eines konzeptionellen Datenmodells und rekonstruiert umgekehrt ein ERD aus dem Schema einer bestehenden Datenbank. Es übersetzt auch von einer Notation in eine andere, von Chen in den Krähenfuss oder nach UML. Bei einem Altsystem ohne Dokumentation ist der Zeitgewinn real, und der so gewonnene Entwurf lässt sich schneller korrigieren, als sich ein leeres Blatt füllt.
Die Grenze ist klar und sie ist geschäftlicher Natur: Kardinalitäten lassen sich nicht erraten. Eine Maschine, die ein Schema liest, leitet ab, was die Datenbank enthält, einschliesslich der Strukturfehler, die sie angesammelt hat, aber sie kann nicht bestätigen, dass eine Verordnung tatsächlich nur einen Patienten betrifft, weil die Antwort daran liegt, wie die Praxis arbeitet. Das Minimum und das Maximum auf jeder Seite einer Beziehung sind Tatsachen, die nur die Fachexperten validieren. Ebenfalls ausserhalb der Reichweite der Automatisierung liegen die Umfangsentscheidungen, was das Modell aufnimmt und was es weglässt, und die Einstufung der Datensensitivität: ein ERD einer Arztpraxis führt eine AHV-Nummer und Gesundheitsdaten, deren Umgang den Datenschutz weit über das hinaus berührt, was ein Modell allein beurteilen kann.
Beispiele
Ein Diagramm liest sich am besten an einem Fall. Der Begriff, den es sichtbar macht, ist das Lesen einer Beziehung in beide Richtungen: eine Linie trägt zwei Zählregeln, eine je Ende, und jede wird am Symbol des gegenüberliegenden Endes gelesen. Die gewählte Domäne ist eine Physiotherapiepraxis in der Westschweiz, mit vier Entitäten, dem Patienten, der Verordnung, der Sitzung und dem Physiotherapeuten.
Die Beziehung zwischen der Verordnung und der Sitzung trägt die beiden zu lesenden Regeln. Auf der Sitzungsseite ist das Symbol ein Krähenfuss mit vorangestelltem Strich: eine Verordnung erlaubt eine bis mehrere Sitzungen, nie null, was besagt, dass eine Verordnung ohne Sitzung keinen Grund hat, erfasst zu werden. Auf der Verordnungsseite ist das Symbol ein Doppelstrich: jede Sitzung gehört zu genau einer Verordnung, weder null noch zwei. Die beiden anderen Beziehungen lesen sich gleich. Ein Patient erhält null bis mehrere Sitzungen und jede Sitzung betrifft genau einen Patienten; ein Physiotherapeut führt null bis mehrere Sitzungen durch und jede Sitzung wird von genau einem Physiotherapeuten durchgeführt. Die Sitzung ist der Punkt, an dem drei Beziehungen zusammenlaufen, und jedes ihrer Genau-eins-Enden besagt, dass die Sitzung ohne ihren Patienten, ihre Verordnung und ihren Physiotherapeuten nicht existieren kann.
Visualisierungen
Die Form trägt die Bedeutung, was es erlaubt, ein Modell zu validieren, ohne es Zeile für Zeile zu lesen. Die Silhouette gibt den Typ, ein benanntes Rechteck für eine Entität, den Identifikator an der Spitze ihrer Attribute. Die benannte Linie gibt die Beziehung, und ihr Symbol mit zwei Markierungen gibt die Zählregel, das Maximum an der Entität, die Minimum-Markierung zurückgesetzt auf der Linie. Ein Prüfer, der den Krähenfuss kennt, überfliegt so ein ganzes Schema mit dem Auge und erkennt eine zweifelhafte Kardinalität, ohne eine einzige Definition zu öffnen, was die Notation zu einer gemeinsamen Sprache macht.
Aufwand
| Phase | Stufe | Begründung |
|---|---|---|
| Vorbereitung | Niedrig bis mittel | Das Geschäftsvokabular, ein Datenwörterbuch oder ein Begriffsmodell zusammentragen, sofern vorhanden, und feststellen, wer die Entitäten und Beziehungen jeder Domäne mit Autorität bestätigen kann. |
| Durchführung | Mittel | Das Zeichnen selbst geht schnell, sobald die Entitäten bekannt sind. Der Aufwand liegt in der Validierung der Kardinalitäten mit den Fachexperten, die iterativ erfolgt, eine Zählregel nach der anderen. |
| Dokumentation | Mittel bis hoch | Das Modell und die Definitionen seiner Entitäten und Attribute, die mit dem Datenwörterbuch gepflegt werden, müssen aktuell bleiben, während sich die Daten ändern, sonst werden sie zu einem Archivbild, das niemand mehr konsultiert. |
Werkzeuge
Ein Whiteboard oder ein Blatt Papier genügt für die erste konzeptionelle Skizze: einige Entitäten und ihre Beziehungen werden im Stehen gesetzt und korrigiert, mit dem Geschäft. Allgemeine Diagrammwerkzeuge, diagrams.net, Lucidchart oder Visio, tragen Entity-Relationship-Schablonen und geben eine saubere Zeichnung, aber sie hören bei der Zeichnung auf. Datenmodellierungs-Werkbänke und Werkzeuge des rechnergestützten Software-Engineering gehen weiter: Sparx Enterprise Architect, erwin Data Modeler, ER/Studio, MySQL Workbench, Oracle SQL Developer Data Modeler oder dbdiagram.io erzeugen das Datenbankschema aus dem Modell und rekonstruieren es aus einer bestehenden Datenbank. Die Rollenteilung ist einfach: das Diagrammwerkzeug genügt, solange das ERD auf der konzeptionellen Ebene eine Diskussionsgrundlage ist, die Modellierungs-Werkbank wird nötig, sobald das Modell mit einer realen Datenbank synchron bleiben muss.
Quellen
- IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.15 Data Modelling: das Entity-Relationship-Diagramm als eine der beiden Notationen eines Datenmodells, die Liste seiner Elemente, die Kardinalität und ihre Lesart in beide Richtungen sowie die genannten Stärken und Grenzen seines Einsatzes.
- Peter Chen, « The Entity-Relationship Model: Toward a Unified View of Data », ACM Transactions on Database Systems, Bd. 1, Nr. 1 (1976), S. 9-36: die grundlegende Arbeit zum Entity-Relationship-Modell und seinen Grundbegriffen.
- Gordon C. Everest, « Basic Data Structure Models Explained with a Common Example », Proc. Fifth Texas Conference on Computing Systems (1976): der Ursprung der Kardinalitätsnotation im Krähenfuss.
- Richard Barker, CASE*Method: Entity Relationship Modelling, Addison-Wesley (1990), ISBN 978-0201416961: die Referenz für die Barker/Oracle-Variante des Krähenfusses, der ein Business Analyst in Oracle- und CASE-Werkzeugketten begegnet.

