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- 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.
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) notwendig 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 beginnen 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.
Nachdem das Datenmodell dieses Beispiels aus nur 7 Tabellen besteht, ist die Graphik noch überschaubar, mag ihrem Leser also wirklich etwas sagen.
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 Durchschnitt 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, Dokumentation 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).
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).
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 Codegenerator 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.
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.
stw4776ERDND — ERD . Notation . Datenmodell — News?
Mehr + B G E + S H A + More