Praktisches & Grundsätzliches zur Informatik

Reference Card for ERD Notation, Datenmodellierung, Königsweg, Entwurf Datenmodell, Code Generatoren

ERD Notation — Königsweg zur Datenmodellierung

Die meisten Software Entwickler scheinen heute — wenigstens über die ersten Jahre ihres Berufslebens hinweg — allzu sehr geprägt durch blindes Vertrauen in Software-Modellierungs-Methoden

In die Kategorie solcher Methoden lassen sich im Prinzip alle einordnen, die graphische Entwurfsmethoden sind, solche also, in denen Daten-, Prozess- oder andere Modelle in graphischer Form beschrieben werden. UML ist der bekannteste, keineswegs aber der einzige Vertreter solcher im praktischen Leben nur ganz selten brauchbarer Denkwerkzeuge.

Produkthersteller oder Hochschullehrer, die graphische Spezifikationssprachen zum Standard erheben wollen, verkennen die Tatsache, dass Bilder sich zwar gut punktweise zur Illustration des einen oder anderen Zusammenhangs eignen, niemals aber flächenweit ausreichend genaue Beschreibung von Software sein können, zu deren Implementierung letztendlich viele Tausend Lines of Code (LOC) notwen­dig sein werden.

Der Grund dafür, dass graphische Methoden an die Grenze ihrer Leistungsfähigkeit gelangen, sobald es um Modelle geht, deren Implementierung mehr als nur etwa 1000 LOC umfassen wird, hat vor allem drei gute Gründe:

Betrachten wir ein Beispiel: Die sehr gute Freeware DB Designer gilt an Hochschulen als Standard­werkzeug zum Entwurf relationaler Datenmodelle. Wie sich der Produktbroschüre entnehmen lässt, ergibt sich als Ergebnis solchen Designs dann z.B. folgendendes Diagramm (es modelliert eine Datenbasis Online Store):


Datenmodellierung (graphisch ist unpraktisch)



Nachdem das Datenmodell dieses Beispiels aus nur 7 Tabellen besteht, ist die Graphik noch überschaubar, mag ihrem Leser also wirklich etwas sagen.

ABER: Die Mehrzahl aller im praktischen Leben der Software-Entwickler
wirklich auftretende Datenmodelle haben ganz anderen Umfang:


Das Siebel System etwa — ein Produkt zum Bau von Portalen für Customer Relationship Management — umfasst 2800 Tabellen mit im Durch­schnitt je etwa 100 Attributen. Solche Modelle über Diagramme zu verstehen dürfte absolut unmöglich sein.

Sie über DB Designer oder ähnliche Werkzeuge zu spezifizieren und zu dokumentieren wäre möglich, doch ist ihre Dokumentation dann fast wertlos: Sie ist dann nämlich viel zu schwer zugänglich und nicht wirklich verstehbar (da in tausende kleinster Teile zerlegt). Der Zwang übrigens, Doku­men­tation interaktiv über kleine Eingabefelder zu erstellen, führt erfahrungsgemäß dazu, dass sie viel zu knapp und allein schon deswegen wertlos ist (sog. Alibi Doku).

Selbst wenn man Datenmodellen mit weit über 1000 Tabellen nicht jeden Tag begegnet, sollte doch klar sein, dass eine das gesamte Modell darstellende Graphik selbst dann nicht wirklich hilfreich sein wird, wenn sie nur einige Dutzend Tabellen (sowie alle Bezüge zwischen ihnen) darzustellen hat. Datenmodelle solchen Umfangs aber sind für Enterprise Anwendungen, die nicht ganz trivial sind, nun wirklich die Regel (schon Mantis — ein simples Bug Tracking System — hat ein Datenmodell bestehend aus 214 Attributen verteilt auf 26 Tabellen, und Mantis_User_Table z.B. hat Bezüge hin zu 13 anderen Tabellen. Ähnlich einfache Datenmodelle sind für Anwendungen, die Daten verwalten, Stammdaten etwa, die absolute Ausnahme).

Damit also stellt sich wirklich die Frage, ob es denn keine Datenmodellierungsmethode gibt, die geeigneter ist als die graphische, jene also, die Werkzeuge wie DB Designer unterstützen.

Und in der Tat: Es gibt sie. Sie heißt ERD Notation und erlaubt Entity-Relationship-artige Datenmodelle beliebiger Komplxität absolut redundanzfrei so zu spezifizieren, dass die resultierende Spezifikation dann als ein TXT File vorliegt, welches zudem noch beliebig viel Kommentar enthalten kann. Hier ein erstes Beispiel:

Um zu beweisen, dass sich so auch die viel umfangreicheren Modelle aus dem praktischen Leben noch gut — und gut verständlich — darstellen lassen, hier das ebenso präsentierte Datenmodell des Open Source Bug Tracking Systems Mantis:

spezifiziert   —   konzeptuell   —   implementiert


Geeignetes Werkzeug — z.B. mein er2web — kann ERD Notation umsetzen in

Dieses Werkzeug ist auch in der Lage, einen Großteil des umgekehrten Weg zu gehen, d.h. die Struktur eines bereits in SQL implementierten Datenmodells zu erkennen und in ERD Notation darzustellen (damit wird Re-Engineering existierender, in SQL implementierter Datenmodelle möglich; das Datenmodell zu Mantis etwa konnte ich auf diese Weise sehr schnell verstehen — Dokumentation dazu schien 2009 nicht zu existieren).

ERD Notation hat noch weitere Vorteile:

In der Summe gilt: Alles, was sich mit Werkzeugen wie DB Designer erreichen lässt — und noch einiges mehr — lässt weit müheloser auch mit ERD Notation erreichen in Kombination mit der Command Line Utility ds.exe (oder einer dazu äquivalenten, die sich jeder geschickte Programmierer in 2-3 Wochen selbst schreiben kann als ein Werkzeug, welches ERD Notation versteht und nach ERD und SQL umzu­setzen in der Lage ist).

Um wie viel einfacher die Arbeit, eine Datenschicht zu entwerfen, zu dokumentieren und zudem noch zu implementieren so werden kann, suggeriert ein Vergleich des Umfangs der beiden Handbücher

Da ERD Notation — anders als SQL — absolut redundanzfreie Specs gestattet, verwundert es nicht, dass die Beschreibung eines Datenmodells in ERD Notation typischerweise um mindestens den Faktor 2 weniger Code erfordert als SQL.




stw4776ERDNDERD . Notation . DatenmodellNews?

Mehr + B G E + S H A + More