Wie viele Fahrzeuge nutzt der Vertrieb? Das ist die Sorte Frage, die man für erledigt hält, bevor man sie überhaupt gestellt hat. In der Tabelle steht schließlich, welche Person zu welchem Fahrzeug gehört — gepflegt, überall gefüllt, sieht gut aus. Sie sagt nur nicht, ob die Person den Wagen zugewiesen bekommen hat oder ob sie ihn gefahren ist — und davon hängt die Antwort ab.
Gestellt hat sie Yerodin, Controller bei FastChangeCo, der fiktiven Firma, an der ich reale Situationen aus Projekten und Coachings greifbar mache.
Im Hub-Artikel vergangene Woche habe ich die Landkarte zu dieser Serie skizziert: drei Ebenen, wobei die fachliche meist als Erstes wegfällt. In diesem Teil gehen wir einen einzigen Begriff durch alle drei Ebenen durch — von der ersten Definition bis zu der Spalte, in der er am Ende landet. An jedem Übergang kann man sehen, was dabei verloren geht.
Die Frage, die keiner beantworten kann
Die Frage aus dem Controlling trifft auf eine gepflegte Tabelle — und bleibt trotzdem offen.
Xuefang, Junior Data Modeler, sieht sich die Tabelle an und findet nichts Auffälliges. Eine Spalte person_id, ein Fremdschlüssel auf die Personentabelle, nirgends leer. Ihre Frage ist die, die mir an dieser Stelle in Coachings fast immer gestellt wird: Da steht doch die Person dran, was soll denn fehlen?
Diego formuliert die Frage um: Was hat die Beziehung zwischen Fahrzeug und Person bedeutet, bevor sie eine Kombination aus Spalten in einer Tabelle war? Wer hat eigentlich entschieden, dass die beiden auf genau eine Art zusammengehören?
Bei FastChangeCo gehören die Fahrzeuge der Firma. Amal hat einen Dienstwagen, der auf sie läuft. Die Poolwagen stehen im Hof und werden gebucht, mal von der einen, mal von der anderen. Das sind zwei verschiedene Verhältnisse zwischen einer Person und einem Fahrzeug, und beide hängen im Geschäft an Geld — nur an unterschiedlichem.
Drei Ebenen, ein Fahrzeug
Zwei Beziehungen zwischen denselben zwei Begriffen, jede mit ihrem eigenen Grund im Geschäft.
Konzeptionell heißt: welche Begriffe gibt es, wie hängen sie zusammen, was bedeuten sie. Für unseren Fall sind das zwei Begriffe, Person und Fahrzeug, und dazwischen nicht eine Beziehung, sondern zwei. Zugewiesen an ist die eine — der Dienstwagen, der auf Amal läuft, mit allem, was daran hängt: Kostenstelle, geldwerter Vorteil, Überlassungsvertrag. Gefahren von ist die andere — wer tatsächlich am Steuer saß, für Versicherung, Haftung und Kilometer. Auf dieser Ebene wird noch nichts gebaut — hier wird benannt und entschieden.
Logisch wird daraus Struktur, immer noch ohne Datenbank im Kopf. Person und Fahrzeug bleiben stehen, es sind ja weiterhin zwei Begriffe. Dazu kommen die beiden Beziehungen, jede mit eigenen Angaben: Die Zuweisung hat einen Beginn und ein Ende, die Fahrt einen Zeitpunkt und einen Kilometerstand. Und weil beide über die Zeit viele-zu-viele sind — eine Person fährt mehrere Fahrzeuge, ein Fahrzeug wird von mehreren gefahren —, bekommt jede von ihnen einen eigenen Eintrag. Solche Zwischeneinträge heißen assoziative Entitäten. Wer mag, kann hier über Kardinalitäten (wie viele auf wie viele) reden — die Arbeit bleibt trotzdem eine fachliche. Wenn du die drei Ebenen einmal von Grund auf nachlesen willst: das habe ich 2015 schon einmal aufgeschrieben.
Derselbe Sachverhalt auf drei Ebenen. Nach unten kommt person_id dazu, valid_from und Kilometerstand fallen weg.
Physisch wird daraus eine einzige Tabelle. Zuweisung und Fahrt werden ins Fahrzeug hineingezogen — denormalisiert, sagt man dazu —, und übrig bleibt eine Spalte person_id. Ein Fremdschlüssel, ein Wert pro Fahrzeug. Nicht als Entscheidung gegen die Fahrt — an der Stelle wusste schlicht niemand mehr, dass es zwei gab. Was auf der ersten Ebene nicht entschieden wurde, entscheidet auf der dritten die Person, die die Tabelle anlegt.
Unsichtbar bleibt das Ganze aus einem banalen Grund. Bei einem Dienstwagen sind die zugewiesene und die fahrende Person meistens dieselbe. In den allermeisten Zeilen macht die fehlende Unterscheidung also überhaupt keinen Unterschied. Deshalb fällt sie nicht auf, jahrelang nicht. Auseinander gehen die beiden erst bei den Poolwagen — und bei dem Dienstwagen, den mal jemand anderes gefahren hat.
Über diese Serie: Dies ist Teil 1 von 3 der Serie über die Grundlagen der Datenmodellierung. Die Übersicht steht im Hub-Artikel. Teil 2 fragt am 16. September, was bei FastChangeCo eigentlich ein Employee ist; Teil 3 kommt am 23. September zur Methodenfrage und zur Checkliste.
Zwei Beziehungen, eine Spalte — kommt dir bekannt vor?
Begriffe klären, Beziehungen benennen, Definitionen verhandeln, bevor die erste Tabelle steht: genau das ist der Kern der Data Modeling Master Class. Neue Termine sind in Vorbereitung.
Was das später kostet
Links der wahre Sachverhalt, rechts die physischen Daten. Den Zeilen sieht man die gemeinte Lesart nicht an.
Yerodin bekommt am Ende seine Zahl. Solche Fragen bleiben nicht unbeantwortet — irgendjemand sieht auf die Spalte, entscheidet sich für eine Lesart und rechnet damit. Die Person am Fahrzeug wird schon die sein, die es fährt. Ab da steht diese Annahme im Filter eines Reports und sonst nirgends. Im Modell steht sie nicht, weil es dafür keine Stelle gibt.
Ein paar Monate später kommt die Kostenverteilung dazu. Die Kostenstelle rechnet über die Zuweisung: wer hat einen Dienstwagen, was kostet er, auf welches Team läuft er. Flotte und Versicherung rechnen über die Nutzung: wer ist gefahren, wie viele Kilometer, wer hatte den Poolwagen an dem Tag. Beide nehmen dieselbe Spalte, weil es nur die eine gibt, und lesen sie unterschiedlich. Bei den Dienstwagen kommt dasselbe heraus, bei den Poolwagen nicht.
Wenn das auffällt, wird es als Datenqualitätsproblem gemeldet. Nur sind die Daten in Ordnung. In keinem der beiden Reports steckt ein Rechenfehler, es gibt also auch keinen Bug, den jemand finden könnte. Die Differenz kommt aus einer Entscheidung, die nie getroffen wurde.
Beim Aufräumen kommt dann die eigentliche Rechnung. Der Tabelle sieht man nicht an, welche Zeile einmal zugewiesen meinte und welche gefahren. Die Unterscheidung war nie drin, sie lässt sich also auch nicht so einfach aus den Daten zurückholen, falls sie jemals vorhanden war.
Was pro Begriff festgehalten gehört
Ein Begriff, aufgeschrieben: Definition, Verantwortlicher und beide Beziehungen mit ihrem Grund.
Im Hub-Artikel steht, wie man anfängt, wenn man bei null steht: nicht alles modellieren, sondern fünf bis zwanzig Begriffe nehmen, um die bei euch täglich gestritten wird. Pro Begriff drei Dinge — eine Definition, auf die ihr euch einigt, einen Verantwortlichen und die Beziehungen zu den anderen Begriffen. Dokumentiert an einem Ort, an dem ihr versionieren könnt.
An unserem Fahrzeug sieht man, warum der dritte Punkt der ist, an dem es hängt. Zu jeder Beziehung gehört ihr Grund: Warum gibt es sie im Geschäft? Zugewiesen an gibt es wegen Kostenstelle und geldwertem Vorteil. Gefahren von gibt es wegen Versicherung, Haftung und Kilometern. Zwei Gründe, also zwei Beziehungen — der Grund ist das, woran man merkt, dass es nicht eine ist. In der Master Class ist das eine eigene Übung: zu jeder Beziehung den Grund aufschreiben, bevor irgendetwas gebaut wird.
Und zwei Beziehungen im Informationsmodell heißen zwei Umsetzungen im physischen Modell. Nicht zwingend zwei Tabellen, das hängt von der Methode ab — aber eben auch nicht eine Spalte, die beides bedeuten soll.
Bei den Fahrzeugen war die Bedeutung ja da. Jemand wusste, dass Zuweisung und Fahrt zwei verschiedene Dinge sind. Es hat sie nur nie jemand aufgeschrieben, und deshalb ist sie auf dem Weg zur Tabelle verloren gegangen.
Es geht auch andersherum. Manchmal ist die Bedeutung nie entschieden worden, und dann kann man sie auch nicht verlieren. Nächste Woche geht es um so einen Fall: was bei FastChangeCo eigentlich ein Employee ist, und warum diese eine Zahl wochenlang nicht zu bekommen war.
So long,
Dirk