Datenmodellierung

Zusammenfassung
Was ist Datenmodellierung?
Denkweise Fachanwender gegenüber IT-Spezialist
Entstehung eines Datenmodells an einem Beispiel
Exkurs: Kleine Katastrophen bei der Datenmodellierung

vgl. hierzu Darstellungsformen für Daten, Bildschirmformualare und Prozesse
vgl. auch Benutzerkontakt (dort vor allem das Interview)

Zusammenfassung

Erklärt werden die Grundlagen der Datenmodellierung inkl. der wichtigsten Terminologie, wobei auf die unterschiedliche Sichtweise von Fachanwendern und IT-Spezialisten eingegangen wird. Zur Veranschaulichung wird ein einfaches Beispiel einer privaten Ausleihe von Büchern verwendet und in Form eines Dialoges zwischen zwei Personen dargestellt. Das Beispiel wird konsequent verfolgt, sodass es auch im Rahmen eines echten Anforderungsdokuments nutzbar wäre. Im Beispiel werden typische Kommunikationsformen, Gedankengänge, Fragetechniken, Problemstellungen und Lösungswege beschrieben, wie sie sich auch im echten Leben darstellen.

Was ist Datenmodellierung?

Datenmodellierung, insbesondere die physikalische Modellierung und Optimierung für eine relationale Datenbank, ist eine Wissenschaft für sich. Auf diesen Seiten wird nur eine relativ pragmatische Sicht der logischen Datenmodellierung vorgestellt, wie sie für eine Anforderungsanalyse notwendig ist und auch von einem Fachanwender bzw. Nicht-IT-Spezialisten verstanden werden kann. Auf hierarchische Datenbanksysteme wird nicht eingegangen. Routinierte Datenmodellierer und DB-Administratoren mögen mir die teilweise oberflächliche Betrachtungsweise und den freizügigen Gebrauch der Fachterminologie sowie die Abweichungen von der üblichen Symbolik vergeben, es gibt hierzu bereits genügend Material im Web und in der Fachliteratur.

Wenn man ein IT-System oder einen Geschäftsvorfall betrachtet, so lassen sich verschiedene Sichtweisen unterscheiden. Eine davon ist die Datensicht. Daten werden eingegeben, verarbeitet, ausgegeben. In irgendeiner Weise werden die Daten auch abgespeichert und können danach gesucht werden. Diese Speicherung, d.h. die physikalische Repräsentation der Daten, unterliegt meist einer wohldefinierten Struktur, die vor Beginn der Entwicklung eines Systems fixiert sein muss, damit eine Suche auch ohne weiteres möglich ist. Meist deshalb, da bei mangelhaften Zeitvorgaben, gewachsenen Systemen oder Datenmodellierung durch Nicht-Experten eher von einer Ansammlung von Tabellen gesprochen werden muss, nicht von einem Datenmodell. Auf dieser Struktur setzen Geschäftsprozesse oder Verarbeitungsprozeduren auf.

Unter Daten versteht man einzelne Attribute wie den Namen eines Kunden, seine Telefonnummer oder ähnlich einfache Dinge. Unter einem Datenobjekt versteht man die Zusammenfassung mehrerer solcher Attribute. Ein Kunde, bestehend aus Name und Kontaktinformation, kann solch ein Objekt sein; oder eine Bestellung bestehend aus Artikelnamen, Artikelnummern, Stückzahl, Preis, Bestelldatum und Bestellnummer mit einer Kundenzuordnung kann ein anderes Datenobjekt sein. Die Bestellung hat eine Zuordnung zu einem Kunden, oder anders formuliert hat sie eine Beziehung bzw. Relation zum Kunden.

Ein Datenmodell besteht aus Datenobjekten und Relationen zwischen den Datenobjekten. Innerhalb des Modells werden die Datenobjekte bis auf einfache Attribute herunter gebrochen. Für diese Attribute können bestimmte Randbedingungen definiert werden, z.B. dass sie unique (eindeutig) sein müssen (eine Kundennummer wird niemals für zwei verschiedene Kunden vergeben werden, sondern immer nur einmalig existieren) oder dass das Attribut befüllt sein muss (z.B. wird man immer einen Kundennamen verlangen und es ist auch zu erwarten, dass jeder Kunde einen Namen hat, aber eine Telefonnummer muss er nicht unbedingt haben oder angeben). Die Relationen zwischen den Objekten werden quantifiziert. Z.B. kann ein Kunde mehrere Bestellungen gleichzeitig aufgeben, jede Bestellung wird sich aber genau einem Kunden zuordnen lassen. - Innerhalb der IT spricht man von einem Entity Relationship Model, kurz ERM oder ER-Model.

Das physikalische Ergebnis eines solchen ERM spiegelt sich in einer relationalen Datenbank wider. Eine relationale Datenbank soll zumindest dem theoretischen Ansatz nach ohne Redundanzen sein, d.h. jede Information wird nur ein einziges Mal in der Datenbank vorhanden sein. Um dies zu erreichen, gibt es eine formalisierte Technik, mit der ein Datenmodell normalisiert wird, wie man im IT-Jargon sagt. Es gibt verschiedene Normalformen, die alle Aussagen über Redundanzen enthalten. Die 3. Normalform (kurz 3nf) ist hier das passende Schlagwort, und hier endet die Welt für den normalen Business Analysten und für Fachanwender; höhere Normalformen sind nur von wissenschaftlicher Bedeutung. Der nächste Schritt ist dann die Denormalisierung, um das Datenmodell pragmatisch zu vereinfachen. Redundanzen werden u.U. eingeführt, um Performance-Schwierigkeiten zu begegnen: damit hat allerdings weder der Fachanwender, noch der Business Analyst zu tun, das macht der Datenbankentwickler.

Als Fachanwender müssen Sie zwar kein Datenmodell selbst bauen können, Sie sollten aber sehr wohl ein ERM lesen können, um sich kompetent an der Spezifikation eines IT-Systems zu beteiligen. Die Datensicht auf das von Ihnen gewünschte System müssen Sie natürlich verstehen, wie sonst wollen Sie verifizieren, dass die dokumentierten und in einem Datenmodell dargestellten Anforderungen auch das wiedergeben, was Sie sich vorstellen?

Ein Business Analyst baut entweder ein logisches Datenmodell mit einem geeigneten Werkzeug selbst, das dann vom Datenbankspezialisten als Vorlage für ein physikalisches Datenbankmodell genutzt wird. Oder er beschreibt das Modell lediglich und modelliert das physikalische Modell gemeinsam mit dem Datenbankspezialisten. Ich bevorzuge und empfehle prinzipiell die zweite Variante, einerseits geht das schneller und billiger, andererseits gibt es keine Verständnis- und Verständigungsprobleme. Zudem können kritische Stellen im Modell, die zu Performance-Problemen führen können, vom Datenbankspezialisten erkannt und an den Business Analysten sofort kommuniziert werden, der dann evtl. sofort seine Prozesse dahingehend überprüft und ggf. auch modifiziert.

google zu Datenmodell oder Datenmodellierung,
google zu Entity Relationship Model
google zur 3. Normalform oder 3nf

Denkweise Fachanwender gegenüber IT-Spezialist

Fachanwender denken am ehesten in Datenobjekten. Sie sprechen vom Kunden, vom Auftrag, von einem Provisionsmodell, von einer Aktie, einem Wertpapierdepot etc. Was sich hinter dem Objekt im Detail verbirgt, ist dem Fachanwender klar, auch wenn er dies nicht bis aufs letzte Attribut ausführt. Eine Denkweise in Relationen besteht nur vage, eher wird in Vorgängen gedacht. Ein Kunde erteilt einen Auftrag, er erhält eine Provision, ein Anleger ordert eine Aktie.

Diese Denkweise ist für ein IT-System ungenügend. Ein IT-Spezialist denkt eher in Tabellen, die über konkrete Attribute zu anderen Tabellen in Beziehung stehen. Kunden werden in einer Kundentabelle abgebildet, ein (für den Fachanwender nicht sichtbares) Attribut ist ein interner Primärschlüssel, den man sich im weiteren Sinne wie eine eindeutige und für alle Zeiten gleiche Kundennummer vorstellen kann. Ein Auftrag wird über diesen Kundenprimärschlüssel der Kundentabelle zugeordnet und hat seinerseits einen Auftragsprimärschlüssel. In einer dritten Tabelle werden Artikel aufgelistet, über eine vierte werden Artikel mit Aufträgen verbunden. Ein IT-Spezialist betrachtet Zusammenfassungen verschiedener Tabellen als Datenobjekt.

Spricht ein Fachanwender von einem Auftrag, so stellt er sich darunter ein Blatt Papier vor, auf dem die Anschrift des Kunden, seine Kundennummer, die bestellten Artikel mit Artikelname, Bestellnummer und Preis sowie das Datum der Bestellung steht. Im Datenmodell steht aber beim Auftrag kein Kundenname sondern nur ein Verweis auf die Kundentabelle, aus der der Name bei Bedarf gelesen wird. Das Datenobjekt ist nur eine Sicht über mehrere Tabellen.

Entstehung eines Datenmodells an einem Beispiel

Schritt 1: Was erzählt der Auftraggeber freiwillig?

Im ersten Schritt verlässt sich der Analytiker auf die Aussagen seines Kunden. Der Kunde kommuniziert dabei im Sinne der IT fast immer zwei Informationen:

eine unvollständige, meist auch falsche hohe Sicht der Datenobjekte.
eine Reihe von Details zu den Datenobjekten. Die Details geben im Normalfall das Datenobjekt nicht vollständig wieder, d.h., dass Attribute fehlen. Häufig sind diese Details oder Attribute falschen Datenobjekten zugeordnet, fast immer sind Informationen redundant, und manchmal ist die Sichtweise auch einfach nur inkorrekt.

Stellen wir uns jemanden vor, sagen wir Lothar der Leser, der eine kleine Bibliothek hat und seine Bücher an Bekannte und Bekannte von Bekannten verleiht. Leider verliert er gelegentlich den Überblick und die Bücher verschwinden auf nimmer wiedersehen. Lothar will ein kleines Programm, das ihm die Verwaltung übernimmt. Unvorsichtigerweise sagt sein Freund Paul der Programmierer zu, ihm dabei zu helfen.

Bislang organisiert er seine Ausleihe dadurch, dass er sich Karteikarten anlegt, die folgende Informationen enthalten: Buchtitel und Name des Entleihers. Alles andere hat Lothar im Kopf, die Kontaktinformationen seiner Bekannten im Notizbuch. Bei Bekannten von Bekannten notiert er noch eine Telefonnummer. Gelegentlich schaut er die Kartei durch und ruft seine Bekannten an, sofern er noch ihre Telefonnummer lesen kann, wenn er seine Bücher wieder haben will. Vielleicht schickt Lothar auch eine EMail, wenn er eine Adresse hat, so klar ist das aber nicht. Bekommt er ein Buch zurück, so wird die Karteikarte weggeworfen. Während eines ersten Gesprächs zwischen Paul und Lothar zeigt sich, dass Lothar einige tausend Bücher hat, die er am liebsten noch nach Schlagworten katalogisieren will. Seinen näheren und ferneren Bekanntenkreis will er ebenfalls gleich in das neue System einbauen, also eine kleine Adressverwaltung zusätzlich.

In erster Näherung lassen sich zwei Datenobjekte identifizieren: Bekannte und Bücher. Der einzige sichtbare Zusammenhang zwischen beiden ist, dass eine Entleihung stattfindet. Ohne sich um irgendwelche Standard-Darstellungsformen zu kümmern, lässt sich folgendes Bild zeichnen:

Es ist ungefähr das, was Lothar erzählt hat. Die Schlagworte sind Paul verdächtig, ebenso die Bekannten der Bekannten. Aber bislang hat Paul noch keinen Grund, sich darüber den Kopf zu zerbrechen. Die Schlagworte können ganz einfach in einem String aufgelistet werden, der ein Attribut der Bücher ist; dass jemand ein Bekannter eines Bekannten ist, kann in einem Bemerkungsfeld oder vielleicht in Klammern hinter den Vornamen geschrieben werden.

Schritt 2: Was muss erfragt werden? Wie erarbeiten wir eine hohe Sicht auf die Datenobjekte?

Die zu stellende Frage schlechthin ist, nach welchen Kriterien die gespeicherten Daten gesucht werden sollen. Im weiteren Sinne ist die Suche auch eine Form der Filterung oder Sortierung.

Die Schlagworte und die Bekannten der Bekannten sind, wie gesagt, verdächtig, es lohnt sich also nachzufragen. Wozu, so fragt Paul Lothar, will er die Schlagworte überhaupt benutzen? Die vage Antwort lautet dahingehen, dass er die Bücher katalogisieren will. Er benutzt hier offenbar einen Begriff, der für ihn eine sehr klare Bedeutung hat, die aber dem Informatiker verschlossen bleiben kann. "Willst Du die Bücher also nach Schlagworten suchen? Oder sollen sie nur angezeigt werden?" fragt Paul nach. Die Frage ist nicht zu unterschätzen, denn wenn etwas nicht gesucht werden soll, ist die Abspeicherungsform ziemlich egal. Die Arbeit für Paul wird um so leichter, je weniger Suchkriterien gegeben sind.

"Natürlich will ich danach suchen!" Jetzt wird die Angelegenheit klarer. Natürlich will er danach suchen. Für ihn, für Lothar den Bücherwurm-Fachanwender, ist dies die natürlichste Angelegenheit der Welt, so natürlich, dass er gar nicht daran denkt, dass jemand anders nicht auf dieselbe Idee kommen könnte. Nun: Paul arbeitet gerade an einem Datenmodell, deshalb macht er sich eine Notiz Anwendungsfall suchen von Büchern nach Schlagworten nicht vergessen. Er will natürlich suchen. "Wonach willst Du noch suchen?" ist eine konsequente Folgefrage. "Autor und Titel reichen mir."

Der gesunde Menschenverstand und ein Blick auf ein paar Buchrücken belehrt uns darüber, dass es Bücher mit mehr als nur einem Autor gibt. "Jedes Buch hat einen Autor?" fragt Paul nach. Die Frage ist boshaft in ihrer Formulierung, genau so, dass eine falsche bzw. unvollständige Antwort suggeriert wird. "Ja." lautet die Antwort. - "Ausnahmslos und immer? Wenn wir jetzt im Mittelalter wären und ich Dir sage, dass Du mit Deinem Kopf dafür haftest, dass jedes Buch nur einen Autor hat, und dass Dein Kopf mit dem Schwert abgeschlagen wird, wenn ich auch nur ein Buch ohne Autor oder mit mehr als einem Autor finde...?" Das wirkt. Lothar grübelt nach. "Ja, immer, es gibt nur ein paar Ausnahmen." - "Also nicht immer?" - "Doch, immer, es gibt nur ein paar Ausnahmen." Die Diskussion muss nicht vertieft werden. Eine einzige Ausnahme bedeutet, dass es nicht immer nur ein Autor ist, oder anders herum gesehen, dass jedes Buch mehrere Autoren haben kann. - Für Fachanwender ist es wichtig, dass dies verstanden wird. In der Datenmodellierung gibt es keine Ausnahmen. Sofern Sie einen Satz sagen, der das Wort Ausnahme enthält, ist er im Sinne eines Datenmodells unbrauchbar. Für Informatiker ist es nicht nur wichtig, sondern von entscheidender Bedeutung, dass stets daran gedacht wird, dass Fachanwender nur wenige Gedanken aus Ausnahmen verschwenden.

Weiteres Nachfragen ergibt, dass es zwar wünschenswert wäre, nach einzelnen Titelstichworten zu suchen, dass Lothar aber für seinen Fall nur den Titelanfang braucht. Es mag zwar mal vorkommen, dass ein Buch keinen Autor hat, aber dann schreibt Lothar einfach kein Autor als Autor. Da es sich um eine Ausleihe handelt, wäre auch interessant zu sehen, wer alles Bücher ausgeliehen hat, oder welche Bücher jemand hat. Welche Bücher jemand hat, nicht welches Buch er hat; ein Bekannter kann also offenbar mehr als ein Buch ausleihen. - Bei solchen Spitzfindigkeiten lohnt es sich stets, genau hinzuhören.

Wir fassen also zusammen: Bücher sollen gesucht werden nach

Autor, wovon es einen oder mehrere gibt
Titel, wovon es einen gibt
Schlagworten, wovon es normalerweise mehrere gibt
Ausleiher, wobei jedes Buch nur von einer Person gleichzeitig ausgeliehen werden kann, aber jede Person mehrere Bücher ausleihen kann

und

alle gerade ausgeliehenen Bücher sollen ebenfalls gesucht werden können.

Paul grübelt kurz. "Und die Bekannten? Wie werden die gesucht?" - "Gar nicht, die kenne ich." Paul denkt nun Dinge, die... Lassen wir das. Paul fragt nur: "Du suchst sie nicht. Dann werden sie auch nicht angezeigt, außer zusammen mit dem Buch. Beim Ändern blätterst Du alle durch, oder? Und..." Lothar hat es kapiert. "Gesucht wird nur nach dem Namen." Paul vergewissert sich. "Name? Welcher Name?" - "Na, der Familienname natürlich." Natürlich. - "Kein Vorname, kein Spitzname?" - "Nein, ich habe ja nur ein paar Dutzend Bekannte." Lügner, denkt Paul sich, und denkt an seine im Laufe der Jahre gesammelten einige hundert Kontakte. Aber Paul wird für seine Hilfe nicht bezahlt und will die Angelegenheit nicht weiter verkomplizieren; er glaubt Lothar einfach, war er sagt.

"Was ist mit dem Bekannten eines Bekannten?" Lothar grübelt nach. "Ach, das ist nicht interessant. Aber wenn ich es mir so recht überlege, dann will ich meine Bekannten ebenfalls verschlagworten, irgendwie sowas in der Richtung Geschäftskontakt, Freund, Bekannter eines Bekannte etc." Eine Beispielsammlung ist stets verdächtig, und wenn sie auf etc. endet, gleich noch mehr. Paul fragt nach: "Dieses Schlagwort, hmmmm, nennen wir es mal Bekanntheitsgrad, hmmm, reicht da eines? Oder kann jemand ein Freund und ein Geschäftskontakt gleichzeitig sein?" - "Eines reicht." erklärt Lothar entschieden. "Ich hafte mit meinem Kopf. Ich will aber eine Liste angezeigt bekommen können, als z.B. alle Geschäftskontakte."

Wir fassen also zusammen: Bekannte sollen gesucht werden nach

Namen, von denen jeder Bekannter genau einen hat

und

eine Liste für alle Bekannten eines bestimmten Bekanntheitsgrades muss erzeugt werden können.

Die Zeichnung könnte dann so aussehen:

Paul macht einen Rundgang in der Hausbibliothek. "Wie findest Du hier überhaupt ein Buch?" will er wissen. Lothar zuckt die Schultern. "Ich weiß, wo es steht." Dies soll also nicht Pauls Sorge sein. Von der Hochschulbibliothek oder Stadtbücherein wissen wir, dass jedes Buch einen Aufkleber mit einer Signatur hat und dass es irgendeine Sortierung im Regal gibt, sei es nach Signatur, nach Sachgebiet und dort nach Titel oder Autor. Sachgebiet? Wir fragen nochmals nach. Nein, Sachgebiet interessiert Lothar nicht, das deckt er noch mit dem Schlagwort ab.

Das Bild oben zeigt nun die Datenobjekte, die wir brauchen, um Lothars Daten so zu speichern, dass wir auch alle seine Suchanfragen beantworten können. Verbal sehen wir bereits einige Quantifizierungen der Beziehungen zwischen den Objekten, für die es in IT-Modellen sowohl numerische (0:n, 1:n, 0:1, 0:n, evtl. auch m:n) als auch symbolische Darstellungsweisen gibt, mit denen ich Sie nicht weiter quälen will. Verbal dargestellt bedeutet dieses Bild und alle Informationen, die wir erfragt haben sowie alle Annahmen, die wir unterstellen, folgendes:

Jeder Bekannte hat genau 1 Bekanntheitsgrad.
Jedes Buch hat hat 1 oder n Autoren.
Jedes Buch hat 1 oder n Schlagworte.
Jedes Buch kann von 0 oder 1 Bekannten ausgeliehen werden. - Nicht etwa 1:1, sonst müssten immer alle Bücher verliehen sein!

Wir haben nun eine hohe Sicht auf die zu verarbeitenden Datenobjekte erarbeitet.

Im Sinne der IT fehlt hier aber noch etwas wichtiges:

Ein Bekanntheitsgrad kann 0 oder n Bekannten zugeordnet werden. - Das ist insofern wichtig, als bei der Datenpflege Abhängigkeiten in der Datenbank existieren. Wird gefordert, dass jeder Bekanntheitsgrad mindestens einem Bekannten zugeordnet wird, aber auch, dass jeder Bekannte einen Bekanntheitsgrad hat, so hat man ein Henne-Ei-Problem: Wenn noch kein Bekanntheitsgrad in der Datenbank ist, wie kann dann ein vollständiger Datensatz für einen Bekannten angelegt werden? Und umgekehrt?
Jedes Buch kann einen oder mehrere Autoren haben, aber jeder Autor kann auch mehrere Bücher geschrieben haben. Das Henne-Ei-Problem des Bekanntheitsgrades gilt auch hier.
Dasselbe gilt für die Schlagworte: Jedes Buch kann eines oder mehrere Schlagworte besitzen, aber jedes Schlagwort kann von einem oder mehreren Büchern verwendet werden.

In einer Datenbank werden für die Zuordnung von Autoren und Schlagworten zu Büchern Verknüpfungstabellen eingeführt, für eine (wenig formale) Darstellung reicht es, wenn dieses Faktum irgendwie dargestellt wird.

Exkurs: Abermals die unterschiedliche Denkweise zwischen Fachanwender und IT-Spezialist

Wir bewegen uns noch immer auf einer rein fachlichen Ebene. Ein Informatiker hat kein Interesse daran, was hinter den Daten steckt. Ihn interessiert nicht, dass Autoren Bücher schreiben, oder Leute Bücher entleihen. Es ist ihm ganz egal, was die Leute oder Dinge im echten Leben tun, die er in seiner Datenbank abbildet. Er will nur eines wissen: Wie viele? Keiner, einer oder mehrere? Nur die Beziehungen und ihre Quantifizierungen interessieren ihn.

Die Entwicklung der Bilder zeigt aber recht gut, dass die Sichtweise des IT-Spezialisten bereits auf hohem Niveau deutlich differenzierter ist, als die des Fachanwenders. Ein Bekannter, also eine natürliche Person, stellt wie auch ein Buch ein Ding dar, das man in der Fachanwenderwelt vordergründig nicht weiter zerlegen muss. Für ein IT-System würde dies aber vor allem bedeuten, dass Informationen nur gespeichert, nicht aber gesucht werden können.

Die Konsequenz: Stellen Sie sich zwei Stapel Karteikarten vor: Einer enthält nur Karteikarten mit Daten über ihre Bekannten, der andere besteht nur aus Büchern. Alle Schlagworte und Autoren stehen irgendwo auf den Bücherkarten, mal oben, mal in der Mitte (rechts), mal auf der Rückseite unten links. Wenn ein Bekannter ein Buch ausleiht notieren sie seinen Namen auf der Bücherkarte, irgendwo, wo noch etwas freier Platz ist, und stecken sie zurück in den Stapel. Nun mischen Sie jeden Stapel kräftig durch. Jetzt versuchen Sie alle Karteikarten über die Bücher von Hesse, H. zu finden. Oder alle, die Martina ausgeliehen hat. Viel Spaß beim Suchen!

Dieses Beispiel verdeutlicht recht gut die Kommunikationsprobleme zwischen nicht IT-versierten Fachanwendern und IT-Spezialisten. Aus der Struktur erfordernden Sicht eines Programmierers bzw. eines Business Analysten ist fast jede Information, die ihm genannt wird, etwa so sinnlos, wie der Versuch, eine Bücherkartei samt Ausleihe auf die beschriebene Weise zu organisieren. Ein technischer Mitarbeiter weigert sich normalerweise schlichtweg, auf solch einem Niveau eine Diskussion zu führen, deshalb schickt er einen Analytiker vor.

Als Fachanwender können Sie Ihrem Analytiker sehr helfen, wenn Sie sich stets folgende Fragen stellen:

Was will ich nur speichern und anzeigen, nicht aber suchen?
Was will ich suchen?
Welche Auflistungen von Informationen will ich haben?
Wie stehen meine Datenobjekte miteinander in Beziehung? Wie sind diese Beziehungen zu quantifizieren?
Wie viele "Teile" (Ausprägungen in der IT-Terminologie) einer Eigenschaft gibt es? 0, 1 oder mehrere?

Schritt 3: Die Attribute der Datenobjekte aus Sicht des Fachanwenders

Programmierer Paul fragt nun bei Lothar nach, welche Attribute die Datenobjekte haben sollen. Einige davon kennen wir bereits. Paul geht mit Lothar jedes Datenobjekt durch:

Bekanntheitsgrad:

Kurzer beschreibender Text

Bekannter:

Familienname
Vorname
Anschrift (nicht weiter differenziert, ein Feld für einen kurzen Text genügt)
Geburtsdatum (Lothar ist noch eingefallen, dass er sich jeden Monat eine Liste aller Geburtstagskinder erstellen lassen will)
Telefonnummer
Handynummer
EMail-Adresse geschäftlich
EMail-Adresse privat
beliebige Notizen
den Bekanntheitsgrad

Schlagwort:

Kurzer beschreibender Text

Autor:

Familienname
Vorname

Buch

die Autoren
die Schlagworte
Titel
Jahr der Auflage
beliebige Notizen (hier will Lothar z.B. Verlag, Auflage und Sprache hinein schreiben, aber er will bestimmt nicht danach suchen)
der Bekannte, der das Buch ausgeliehen hat
das Datum, an dem er es ausgeliehen hat
das Datum, für das die Rückgabe vereinbart wurde

Neben diesen reinen Auflistungen erfragt Paul nun auch die Datenformate. Wie viele Zeichen kann ein Familienname lang sein? Ist die Jahreszahl der Auflage vierstellig?

Schritt 4: Übersetzung der fachlichen Sicht in ein IT-taugliches Datenmodell

Paul geht nun nach Hause und macht alleine weiter. Im Geschäftsleben wird nun ein technisch versierter Business Analyst mit einem geeigneten Werkzeug ein logisches Modell bauen, oder aber er wird sich mit dem Datenbanker zusammentun, um ein physikalisches Datenmodell zu entwerfen. Aus dem recht allgemeinen Datenobjekt und den noch vage formulierten Beziehungen werden nun konkrete Tabellen. Ein erster Entwurf könnte etwa wie im Bild aussehen, wobei hier nur die Schlüssel der Tabellen dargestellt werden, über die die einzelnen Tabellen miteinander verknüpft werden. Die grünen Tabellen dienen nur der Verknüpfung von Autoren bzw. Schlagworten mit Büchern. In ihnen findet sich jeweils ein eindeutiges Wertepaar (Tupel), das genau ein bestimmtes Buch mit genau einem bestimmte Autor bzw. einem bestimmten Schlagwort verbindet. Soll ein Buch mit mehreren Autoren oder Schlagworten verbunden werden, so werden die entsprechenden Tupel hinzu gefügt.

Mit ## markierte Attribute sind die Primärschlüssel der jeweiligen Tabelle, mit # markierte Attribute sind Schlüssel, mit denen auf einen Eintrag in einer anderen Tabelle verwiesen wird.

Eine erste Dokumentation für die einzelnen Tabellen, die schon ein gutes Stück Richtung Technik geht, könnte so aussehen:

Bekanntheitsgrad

Name	Format	Erklärung
##Bekanntheitsgrad	--	Primärschlüssel
Bekanntheitsgrad	string, 30 Zeichen	Ein kurzer Text, der den Bekanntheitsgrad erklärt. Beispiele: Freund, Geschäftskontakt, privat, Familie, Bekannter eines Bekannten, Internetbekanntschaft

Bekannter

Name	Format	Erklärung
##Bekannter	--	Primärschlüssel
#Bekanntheitsgrad	--	Enthält hier den Primärschlüsssel des ausgewählten Bekanntheitsgrades.
Familienname	string, 30 Zeichen	z.B. Scharbert
Vornamen	string, 30 Zeichen	z.B. Karl
Anschrift	string, 100 Zeichen	z.B. "Connollystr. 8, 80809 München, Deutschland"
Telefonnummer	string, 20 Zeichen	z.B. 089 / 1234567
Handynummer	string, 20 Zeichen	z.B. 0171 / 1234567
Geburtsdatum	date	z.B. 28.03.1964
email geschäftlich	string, 30 Zeichen	z.B. (hier schreibe ich nichts, damit keine Bots Adressen sammeln können)
email privat	string, 30 Zeichen	dito
Bemerkungen	string, 250 Zeichen	irgendwelche Notizen zur Person

Schlagwort

Name	Format	Erklärung
##Schlagwort	--	Primärschlüssel
Schlagwort	string, 30 Zeichen	Ein kurzer Text. Beispiele: Datenbanken, Programmiersprachen, Analysemethodik, Botanik (allg.), Unterhaltungsliteratur

Autor

Name	Format	Erklärung
##Autor	--	Primärschlüssel
Familienname	string, 30 Zeichen
Vorname	string, 30 Zeichen	z.B. A.

Buch

Name	Format	Erklärung
##Buch	--	Primärschlüssel
Titel	string, 100 Zeichen
Auflagejahr	numerisch ganzzahlig, 4 Stellen
Bemerkungen	string, 250 Zeichen	für beliebige Notizen
#Ausleiher	--	hier wird der Primärschlüssel des Bekannten eingetragen, der das Buch ausgeliehen hat. Ist das Buch gerade nicht ausgeliehen, so steht hier null drin.
Ausleihdatum	date	Datum, an dem das Buch ausgeliehen wurde.
Rückgabedatum	date	Datum, für das die Rückgabe vereinbart wurde.

Verknüpfungstabelle Buch-Autor

Name	Format	Erklärung
#Buch	--	hier wird der Primärschlüssel des Buches eingetragen, zu dem der Autor gehört, der ebenfalls über den Primärschlüsssel in der Tabelle Autor identifiziert wird.
#Autor	--	hier wird der Primärschlüssel des Autors bzw. einer der Autoren des Buches eingetragen, das durch #Buch referenziert wird.

Verknüpfungstabelle Schlagwort-Autor

Name	Format	Erklärung
#Buch	--	hier wird der Primärschlüssel des Buches eingetragen, dem ein Schlagwort zugeordnet wird, das seinerseits über den Primärschlüssel in der Tabelle Schlagwort identifiziert wird.
#Schlagwort	--	hier wird der Primärschlüssels des Schlagworts bzw. eines der Schlagworte für das Buch eingetragen, das durch #Buch referenziert wird.

Der Fachanwender kann solch eine Liste ohne weiteres Attribut für Attribut durchsehen und aushaken. Aber es obliegt ihm und der geschickten Fragetechnik des Analytikers, die Vollständigkeit der Auflistungen zu gewährleisten. Als Faustregel für Kosten nach Fertigstellung eines kompletten IT-Systems kann man sagen:

Wird ein einzelnen Attribut hinzu gefügt, das nur gespeichert und angezeigt werden soll, dann ist die Änderung noch bezahlbar. Beispiel: Bei den persönlichen Daten soll noch eine weitere Telefonnummer hinzu gefügt werden.
Soll nach diesem Attribut auch noch gesucht werden, wird es etwas teurer.
Wird eine neue Beziehung zwischen Datenobjekten eingeführt, so bedeutet dies normalerweise, dass eine Reihe neuer Suchfunktionen zu implementieren sind. Es wird etwas teurer, aber ist noch bezahlbar.
Stellt sich heraus, dass die Quantität einer Beziehung falsch war, dann wird die Änderung wirklich teuer, und zwar so teuer, dass im Zweifelsfall Ihr Budget nicht ausreicht. Beispiel: Wir hätten Lothar geglaubt und wären nur von einem Autor ausgegangen. Nicht nur, dass die vorhandene Datenstruktur falsch ist und angepasst werden muss, jede andere Funktion vom Abspeichern, Ändern und Löschen eines Buch-Datensatzes bis zur Suchfunktion für den Autor und die Anzeige der Autoren auf jeder betroffenen Bildschirmseite und jedem Ausdruck muss überarbeitet werden.

Schritt 5: Weitergehende Überlegungen zum Datenmodell

Bekannte, gleich welcher Art, und Autoren sind beides natürliche Personen. In einem großen Datenmodell wird es sehr viele verschiedene natürliche Personen geben, z.B. interne Mitarbeiter, Außendienstmitarbeiter, Kunden, Ansprechpartner bei Zulieferern etc. Eine naheliegende Modifizierung des Datenmodells wäre es, Bekannte und Autoren in einer Tabelle zusammenzufassen.

In großen Datenmodellen gibt es sehr viele Tabellen, die mit den Tabellen Schlagwort und Bekanntheitsgrad zu vergleichen sind. Sie enthalten neben ihrem Primärschlüssel und irgendwelchen Systeminformationen nur einen Text, und dieser Text wird nur dazu benutzt, um ein kontrolliertes Vokabular bzw. eine definierte Wertemenge festzulegen, die i.d.R. in Comboboxen auftauchen. Im Rahmen einer Denormalisierung werden diese vielen Tabellen in einer einzigen zusammengefasst, wobei zur Unterscheidung, um was es sich gerade handelt (Bekanntheitsgrad, Schlagwort oder sonst etwas) noch ein weiteres Attribut eingeführt wird.

Von all diesen Entscheidungen bekommt der Fachanwender nichts mit.

Exkurs: Kleine Katastrophen bei der Datenmodellierung

Ein gutes Datenmodell ist die Grundlage für ein vernünftiges System inkl. dessen Weiterentwicklung. Typische Katastrophen basieren meist auf dem Unverständnis der für relationale Datenbanken spezifischen mengenorientierten Operationen. Einmischungen der Fachabteilung oder anderer Leute, die keine Ahnung von Datenbanken haben und dennoch Modellierungs-Entscheidungen erzwingen, die nichts mehr mit einem sauberen Datenmodell zu tun haben, rächen sich früher oder später. Den Witz bzw. die Bitternis hinter den Beispielen verstehen Sie nur, wenn Sie die Prinzipien der Datenmodellierung kennen.

Beispiele aus der Praxis

Ein unüberschaubares Datenmodell mit ca. 250 Tabellen wurde einmal hinterfragt. Das Modell entsprach vollkommen der 3nf, eine Denormalisierung aller Tabellen wie Schlagwort oder Bekanntheitsgrad im Beispiel oben, war nicht durchgeführt worden. Diese Tabellen machten etwa zwei Drittel des Modells aus und enthielten oft nur ein halbes Dutzend Werte.

Bestimmte Produkte, die in einer relationalen Datenbank hinterlegt waren, waren extrem unterschiedlich. Sie wurden in eine einzige Tabelle gepresst, wobei für jede Eigenschaft jedes Produkts eine eigene Spalte vorgesehen war. Mit jedem neuen Produkt wurden neue Spalten hinzu gefügt. Die Tabelle war lediglich eine sehr dünn besetzte Matrix, manche der Spalten wurden nur von einem einzigen Produkt benötigt.

Für eine Anwendung wurden zweisprachige Texte verlangt (deutsch und englisch). Man führte in den entsprechenden Tabellen zwei Attribute ein, die jeweils den deutschen und englischen Text enthielten. Gleichzeitig wurde darüber diskutiert, dass das Datenmodell internationalisiert werden sollte.

In einem System, das Händlerhierarchien abbilden sollte, wurden vom Kunden drei Hierarchiestufen verlangt. Da keine Anforderung existierte, dass evtl. einmal eine vierte Stufe eingeführt werden sollte, wurden die drei Stufen als drei Attribute in einer Tabelle definiert. Die auswertende businsss logic wurde hart codiert.

Anstatt die Vergabe von Primärschlüsseln den Automatismen des Datenbanksystems zu überlassen, wurden die Schlüssel manuell erzeugt und eingegeben.

Produkte wurden Produktgruppen zugeordnet. Anstatt, dass diese Produktgruppen (analog zu den Bekanntheitsgraden im Beispiel oben) innerhalb der Datenbank verwaltet und nur über einen Schlüssel automatisch mit dem Produkt verknüpft wurden, wurden Abkürzungen in Form von zwei oder drei Buchstaben langen Codes manuell erfasst. Es gab keine Syntaxprüfung der Codes. Als die Daten in ein anderes System migriert werden mussten, waren insgesamt zwei Wochen manueller Auswertungen und Bereinigungen notwendig, um diese und vergleichbare Fehler an anderer Stelle zu eliminieren. Alle diese Fehler waren über Jahre hinweg ein dauerhaftes Produktions-Ärgernis gewesen, das nur durch sehr viel Aufwand bei manuellen Kontrollen in den Griff zu bekommen war.