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

• die an Hochschulen und Fachhochschulen als Standard gelehrt werden,
• obgleich sie nur in sehr kleinen Projekten wirklich praktikabel sind: nur in Spielprojekten eben, wie man sie während des Studiums betrachtet.
  
  

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:

• Die Ausdrucksfähigkeit von Graphik ist äußerst begrenzt (Graphik kann nur plakative Aussagen machen).
• Komplexe Diagramme zu pflegen ist weit aufwendiger als die Pflege von Spezifikationen in Form gut strukturierter Texte.
• Zudem sind allzu komplexe, allzu umfangreiche Bilder nicht mehr wirklich überblickbar: Sie be­ginnen schwer erfassbar zu werden, wo man versucht mehr als etwa 7 Objekte in ihrer Beziehung zueinander abzubilden.
• Kurz: Bilder helfen nur, wenn sie nicht zu viele Details enthalten und klein genug sind, auf einer Seite DIN A4 ausdruckbar zu sein. Genau dann aber werden sie auch nicht allzu viel aussagen.
  
  

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):





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:

• Das Modell spezifiziert in ERD Notation (nur über dieses File wird das Datenmodell gepflegt).
• Das Modell in konzeptueller, am besten verstehbarer Form (dieses HTML File ersetzt die Graphik und zeigt insbesondere für jede Entität auch all ihre Bezüge hin zu anderen Entitäten: generalisierende Entitäten, per Fremdschlüssel referenzierte, und auch alle sie referenzierenden Fremdschlüssel anderer Entitäten.
• Das Modell implementiert in SQL (seine physische, relationale Form).
  
  

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

• ein SQL Script zur automatischen Implementierung entsprechender Tabellen in einem relationalen DBMS (z.B. Oracle, MySQL, etc.)
• ein HTML File, welches diese Implementierung im Browser einzusehen gestattet und
• ein HTML File, welches das Datenmodell als ein in Textform gegebenes Entity-Relationship-Diagramm präsentiert (es enthält alle Information, die eine durch DB Designer erzeugte Graphik enthalten würde).
  
  

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:

• Man kann damit ganze Hierarchien voneinander erbender Entitätstypen definieren. Im Beispiel hier ist das die Folge der zunehmend spezieller werdenden Entitätstypen
  
  Person   >   Student   >   Studentenheim_Bewohner.
  Mein Generator etwa (ds.exe) implementiert jede solche Hierachie von Typen über eine einzige relationale Tabelle (deren Name dann Union_NNN ist, wo NNN den Namen des an der Spitze der Vererbungshierarchie stehenden Typs bezeichnet: im Beispiel Union_Person).
• Man kann Mengen von Attributen, die einheitlich definiert in mehr als nur einer Tabelle aufzutreten haben, einen eigenen Namen geben, so dass es nicht notwendig ist, all diese Attribute N mal zu definieren, wenn sie in N Tabellen auftreten sollen: ERD Notation erlaubt, jede solche Menge von Attributen zu behandeln wie eine eigene Entität (natürlich nur im logischen DB Design – nicht auch in der physischen Datenbank). In meinem Beispiel ist das der Typ Adresse.
• Das ERD Notation interpretierende Werkzeug (in meinem Fall ds.exe) kann zu einem Code­generator erweitert werden, mit dessen Hilfe sich die gesamte Datenschicht einer Applikation automatisch implementieren lässt. Insbesondere kann Code generiert werden, häufig auftretende Queries in je einer eigenen Methode dieser Schicht zu kapseln. Wie sich ERD Notation erweitern lässt, solchem Zweck mit zu dienen, ist auf Seite 3 der Reference Card for ERD Notation beschrieben.
  
  

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

• Online Hilfe zu DB Designer einerseits und
• Reference Card for ERD Notation (and ds.exe with usage) andererseits.
  
  

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.




stw4776ERDND — ERD . Notation . Datenmodell — News?

Plus + B G E + More
 

07.05.2022
© 2022 Impressum, top