Datenwörterbuch

Ziel

Das Datenwörterbuch legt für jedes Datenelement einen kanonischen Namen fest, die Werte, die es annehmen darf, das Format und die Länge, die sie beschränken, und die Bedeutung, die die Organisation ihm gibt. Es geht ein Problem an: Ein Datenelement trägt selten von einem System zum nächsten dieselbe Bedeutung. Das Feld Kunde im CRM meint den Haushalt, jenes in der Fakturierung meint den Zahler, jenes im Portal meint die angemeldete Benutzerin und alle drei heissen gleich. Diese Unschärfe hat einen Preis: Eine Schnittstelle, die zwei dieser Systeme zusammenführt, ist auf Feldebene falsch und sieht dabei korrekt aus, ein konsolidierter Bericht addiert Grössen, die nicht dasselbe messen, und eine Migration transportiert Werte, deren Bedeutung niemand mehr kennt.

Die Technik stützt jede Entscheidung, die voraussetzt zu wissen, was ein Feld enthält: eine Schnittstelle zwischen zwei Anwendungen spezifizieren, eine Anforderung schreiben, die ein Attribut erwähnt, eine Eingabe validieren, eine Datenübernahme abstecken, eine Kennzahl aus mehreren Quellen konsolidieren, vor einer Revisionsstelle die Definition einer regulierten Grösse verteidigen. Ohne Wörterbuch erhält die Frage «was ist dieses Feld genau» eine Antwort aus dem Stegreif, je nach Team und Tag eine andere. Die Technik dient den Aufgaben der Anforderungsanalyse und der Design-Definition, wo sie Struktur und Inhalt der Daten einer Lösung spezifiziert.

Das Ergebnis ist das Wörterbuch selbst: ein Eintrag je Datenelement, primitiv oder zusammengesetzt, jeder mit seinem Namen, seinen Aliasnamen, seinen Werten und Bedeutungen und seiner Definition, bei zusammengesetzten Elementen zusätzlich mit ihrer Kompositionsregel. Es hat die Form einer Tabelle oder eines Satzes verknüpfter Tabellen, geführt in einer Tabellenkalkulation, einem Wiki oder einem spezialisierten Werkzeug, und es steht häufig neben einem Datenmodell. Der BABOK bezeichnet es auch als Metadaten-Verzeichnis: Sein Inhalt ist die unter Governance geführte Beschreibung der Daten der Organisation, ihr Name, ihr Format, ihre zulässigen Werte und ihre Bedeutung. Sein Nutzen misst sich an einem Test: Eine Entwicklerin, eine Analystin oder eine Revisorin, die auf ein unbekanntes Feld stösst, findet in einer Minute dessen Bedeutung, dessen zulässige Werte und dessen Eigentümer, ohne die Person zu befragen, die das System vor zwölf Jahren geschrieben hat.

Einsatz

Wann einsetzen

• Integration mehrerer Systeme: Dasselbe Feld muss auf beiden Seiten der Schnittstelle dasselbe bedeuten.
• Datenübernahme oder Migration: festhalten, was jedes Quellfeld enthält, bevor es transportiert wird.
• Aus mehreren Quellen konsolidierte Kennzahl: die eine Definition der Grösse festlegen, bevor Zahlen addiert werden.
• Datenmodell im Aufbau: den Attributen der Entität ihr Format, ihre Länge und ihre zulässigen Werte geben.
• Regulierter oder revidierter Bereich: Die Definition eines Feldes muss vor einer Kontrollinstanz belegbar und nachvollziehbar sein.
• Altsystem ohne Dokumentation: die Bedeutung der Spalten rekonstruieren, bevor etwas geändert oder abgelöst wird.
• Mehrere Aliasnamen für dasselbe Feld: Mehrere Fachbereiche benennen dieselben Daten verschieden, ein kanonischer Name ist nötig.
• Analytische Arbeit auf Quelldaten: Die Auswertung hängt davon ab, was jedes Feld genau enthält.

Wann nicht einsetzen

• Mehrdeutigkeit liegt beim Fachbegriff: Das ist Sache des Glossars, das Feldformat entscheidet hier nichts.
• Isolierte Wegwerf-Anwendung eines einzigen Teams: das Schema direkt lesen, das Wörterbuch kostet mehr, als es einbringt.

Beschreibung

Der Eintrag im Wörterbuch: vier Felder

Der BABOK hält vier Angaben je Datenelement fest (§10.12.3.2) und bezeichnet alle vier als obligatorisch. Ein Eintrag, dem eines dieser Felder fehlt, leistet nicht mehr das, wofür es das Wörterbuch gibt.

• Name: der eindeutige Name des Elements, jener, auf den sich zusammengesetzte Elemente beziehen. Er ist der Schlüssel des Wörterbuchs: Zwei verschiedene Elemente dürfen nicht denselben Namen tragen, sonst wird jede Komposition mehrdeutig.
• Aliasnamen: die alternativen Bezeichnungen, die Anspruchsgruppen für dasselbe Element verwenden. Das Feld existiert, weil die Organisation ihre Gewohnheiten nicht aufgibt: Der Kundendienst sagt «Versichertennummer», die Buchhaltung sagt «NAVS13», das Deutschschweizer System zeigt «AHV-Nummer» an. Alle drei als Aliasnamen eines einzigen kanonischen Namens zu erfassen, bringt die stille Duplizierung ans Licht, solange sie noch sichtbar ist.
• Werte und Bedeutungen: die Liste der zulässigen Werte, als Aufzählung oder als Beschreibung des erlaubten Formats, Länge und Zeichenzahl inbegriffen. Sind die Werte abgekürzt oder codiert, wird ihre Bedeutung ausgeschrieben: Ein Element, dessen zulässige Werte 1, 2 und 3 lauten, ist unbrauchbar, solange das Wörterbuch nicht sagt, dass 1 «Interessent», 2 «aktive Kundin» und 3 «gekündigte Kundin» bedeutet. Dieses Feld trägt die meiste Arbeit und den meisten Wert.
• Beschreibung: die Definition des Elements im Kontext der Lösung. Sie sagt, was das Element in diesem System, für diese Organisation misst, bezeichnet oder identifiziert. Die Norm ISO/IEC 11179-4 legt die Regeln für das Schreiben dieser Definition fest. Eine Definition eines Datenelements sagt, was der Begriff ist. Eine Formulierung, die beim Verneinen stehen bleibt, definiert nichts: «dieses Feld ist nicht das Kündigungsdatum» lässt alles offen, was das Feld enthält. Sie steht in der Einzahl. Sie ist ein beschreibender Satz oder eine beschreibende Wortgruppe. Sie steht für sich, das heisst, sie ist verständlich, ohne dass ein anderer Eintrag geöffnet werden muss. Sie ist frei von Zirkelschluss: Der definierte Begriff taucht in seiner eigenen Definition nicht wieder auf. Sie enthält weder die Begründung noch das Erfassungsverfahren noch die funktionale Verwendung des Feldes, die alle anderswo hingehören. Gegen die erste dieser Regeln wird am häufigsten verstossen.

Ein reales Wörterbuch ergänzt fast immer zwei Spalten, die der BABOK nicht nennt und die die Praxis verlangt: den Eigentümer und die Validierungsregeln, die für den Wert gelten, sofern sie über das Format hinausgehen (eine Prüfziffer, ein Wertebereich, eine Abhängigkeit von einem anderen Element). Beide dienen der Pflege, und die Pflege ist die strukturelle Schwachstelle der Technik.

Der Eigentümer entscheidet drei Fragen, die niemand allein aus dem Schema beantworten kann: welche Werte zulässig sind, was das Element bedeutet, wenn zwei Systeme es unterschiedlich lesen, und ob eine Formatänderung in die Umsetzung geht. Seine Autorität beruht auf seiner Stellung in der Organisation: Der Fachbereich, der für den Prozess einsteht, in dem die Daten entstehen, ist der einzige, der das Unternehmen auf die Definition dieser Daten verpflichten kann. Das Wörterbuch hält diese Verantwortung fest und macht sie einsehbar.

Primitive Elemente, zusammengesetzte Elemente und die Kompositionsnotation

Ein primitives Element ist atomar: Es trägt einen einzigen Wert, beschränkt durch Format und Länge, und es lässt sich für die Organisation nicht mehr sinnvoll zerlegen. Ein zusammengesetztes Element wird aus anderen Elementen gebildet, primitiven oder selbst zusammengesetzten, verbunden nach einer Kompositionsregel. Die Regel wird in einer kompakten Notation geschrieben. Diese Notation macht aus dem Wörterbuch eine Struktur.

Der BABOK nennt drei Kompositionsmechanismen und gibt nur für die Sequenz ein Symbol an: die Sequenz (die vorgegebene Reihenfolge der primitiven Elemente, die in der zusammengesetzten Struktur aneinandergereiht werden, markiert durch ein Pluszeichen, wie in Customer Name = First Name + Middle Name + Family Name), die Wiederholung (ein oder mehrere Elemente können mehrfach auftreten) und das optionale Element (es kann in einer gegebenen Instanz des zusammengesetzten Elements auftreten oder fehlen). Die klassische Notation der strukturierten Analyse, aus der die Technik stammt und die Tom DeMarco 1978 festgelegt hat, ergänzt einen vierten Operator, die Auswahl, und gibt jedem der vier ein Symbol. Die meisten realen Wörterbücher verwenden diese Notation mit vier Operatoren.

Die Disziplin, die der Notation ihren Wert gibt, lässt sich in eine Regel fassen: Ein zusammengesetztes Element referenziert bereits inventarisierte Elemente über ihren Namen, und es definiert sie niemals inline neu. Kundenadresse = Strasse + Hausnummer + (Adresszusatz) + PLZ + Ort + Kanton zu schreiben, setzt voraus, dass alle sechs Elemente je als Eintrag im Wörterbuch bestehen, mit ihrem Format und ihren Werten. «vier Ziffern, Bereich 1000 bis 9999» in die Definition der Adresse zu kopieren, statt PLZ zu benennen, führt jene Duplizierung wieder ein, die die Technik beseitigen soll, und garantiert, dass die beiden Kopien auseinanderlaufen.

Verhältnis zu benachbarten Techniken

Diese Techniken bearbeiten denselben Stoff und werden leicht verwechselt.

Das Glossar definiert die Fachbegriffe, für Menschen, in Prosa: Es sagt, was eine Kundin ist, was eine Police ist, was ein Schadenfall ist. Es ist der Einstieg in ein gemeinsames Vokabular. Das Datenwörterbuch definiert die Datenelemente und ihre Struktur: das Format, die Länge, die zulässigen Werte, die Komposition. Beide treffen sich oft beim selben Wort: Das Glossar sagt, was eine Kundin für das Unternehmen ist, das Wörterbuch sagt, welche Felder sie beschreiben und welche Werte in jedem davon zulässig sind.

Die Begriffsmodellierung erfasst Vokabular und Bedeutung: Nominalbegriffe, Verbalbegriffe, die sie zu Fakten verbinden, unabhängig von jeder technischen Darstellung und lesbar für Fachleute, die ein Klassendiagramm beiseiteschieben würden. Das Begriffsmodell beantwortet «wovon sprechen wir und was behaupten wir darüber». Das Datenwörterbuch beantwortet «welche Felder tragen das, in welchem Format, mit welchen Werten». Das zweite lässt sich besser aufbauen, wenn das erste besteht. Die Geschäftsregeln werden im Vokabular des ersten geschrieben und gegen die zulässigen Werte des zweiten geprüft.

Die Datenmodellierung liefert Struktur und Beziehungen: die Entitäten, ihre Attribute, die Kardinalitäten, die Schlüssel. Das Wörterbuch definiert die Elemente, aus denen diese Attribute bestehen. Der BABOK hält fest, dass das Wörterbuch oft gemeinsam mit einem Entity-Relationship-Diagramm verwendet wird und daraus abgeleitet werden kann. In der Praxis ist die Aufteilung klar: Die Kardinalität zwischen Kunde und Police hat in einem Wörterbuch nichts verloren, und das genaue Format der AHV-Nummer hat in einem Entity-Relationship-Diagramm nichts verloren. Der Quervergleich prüft, ob sich jedes Attribut des Modells zu einem Eintrag des Wörterbuchs auflösen lässt.

Das Wörterbuch aufbauen und pflegen

1. Die Menge der Elemente abgrenzen
   Eine Lösung, eine Domäne oder das ganze Unternehmen: Der Entscheid bestimmt alles Weitere, und ein unternehmensweiter Anspruch ohne unternehmensweite Governance erzeugt ein totes Dokument. Der BABOK zählt diese Reichweite zu den Grenzen der Technik: Wer die Metadaten übergeht, welche die übrigen Nutzungsszenarien verlangen, erhält ein Wörterbuch, das auf Unternehmensebene wenig Wert behält. Von den Artefakten ausgehen, die bereits Elemente referenzieren (Datenmodelle, Schnittstellenspezifikationen, Formulare, Berichte, Datenbankschemata).
2. Zuerst die primitiven Elemente inventarisieren
   Für jedes angetroffene Feld den Namen, die gebräuchlichen Aliasnamen, die Werte und Bedeutungen (Aufzählung oder Format mit Länge und Bereich) und die Beschreibung im Kontext der Lösung erfassen.
3. Synonyme und Homonyme auflösen, bevor die Namen feststehen
   Zwei Teams benennen dasselbe Element verschieden: einen kanonischen Namen wählen, die übrigen in die Aliasnamen überführen. Zwei Teams verwenden denselben Namen für zwei verschiedene Dinge: in zwei Elemente mit eindeutig unterschiedenen Namen aufspalten. Das ist der Schritt mit dem höchsten Wert und jener, der am häufigsten übersprungen wird.
4. Die zusammengesetzten Elemente bilden
   Aus den aufgelösten primitiven Elementen, mit der Kompositionsnotation und unter Referenzierung jedes Bestandteils über seinen Namen. Die Auswahl auf der richtigen Ebene ansetzen: Wenn zwei Fälle unterschiedliche Bestandteile verlangen, umfasst die Alternative ganze Gruppen.
5. Mit dem Datenmodell abgleichen
   Sofern es besteht oder parallel entsteht: Jedes Attribut des Modells muss sich zu einem Eintrag auflösen lassen, und das Wörterbuch darf kein Element führen, das kein Modell und keine Schnittstelle verwendet. Tote Einträge verderben am schnellsten, weil niemand bemerkt, dass sie falsch sind.
6. Je Element oder je Domäne eine Person benennen
   Der BABOK weist auf den Pflegeaufwand als Grenze der Technik hin: Die Pflegedisziplin setzt eine Person voraus, die für Richtigkeit und Vollständigkeit jedes Eintrags einsteht. Ein Team steht für nichts ein.
7. Das Wörterbuch veröffentlichen und an die Artefakte anbinden, die es nutzen
   Ein Wörterbuch, das konsultiert wird, ist ein Wörterbuch, das von dort aus erreichbar ist, wo die Frage entsteht: von der Anforderung, der Schnittstellenspezifikation, dem Bericht, dem Schema. Isoliert im eigenen Dokument wird es nur von der Person geöffnet, die es geschrieben hat.
8. Ereignisgesteuert pflegen
   Die Änderung, die das Schema anpasst, ist die Änderung, die den Eintrag nachführt, im selben Merge Request oder im selben Ticket. Ein separates Traktandum «Wörterbuch überprüfen» ist ein Traktandum, das verschoben wird.
9. Das Wörterbuch periodisch gegen das reale Schema prüfen
   Ein automatisierter Vergleich zwischen dem Dokumentierten und dem, was die Datenbank enthält (Typen, Längen, Einschränkungen, beobachtete Werte), fängt die Abweichung ab, bevor eine Anspruchsgruppe einer falschen Definition vertraut.

Wenn das System sein Wörterbuch bereits mitbringt

Manche Systeme deklarieren die Struktur ihrer Daten selbst, in maschinenlesbarer Form und konstruktionsbedingt richtig. Das Wörterbuch wird dort ausgelesen statt geschrieben, und die Arbeit verlagert sich auf die Hälfte, die die Maschine nicht trägt: den kanonischen Namen, die Aliasnamen, die Bedeutung der Werte und den Eigentümer.

Der Katalog einer relationalen Datenbank

Jedes relationale Datenbankmanagementsystem beschreibt sein eigenes Schema in Systemtabellen, die sich mit SQL abfragen lassen. Die Norm ISO/IEC 9075-11 normiert diesen Zugriff unter dem Namen INFORMATION_SCHEMA, und jede Engine ergänzt ihn um eigene Sichten, die Oracle sein Data Dictionary nennt. Eine Abfrage auf diese Sichten liefert für jede Spalte jeder Tabelle den Typ, die Länge, die Genauigkeit, die Pflicht oder Optionalität, die Schlüssel und die Einschränkungen. Diese Hälfte des Eintrags ist in dem Moment richtig, in dem sie gelesen wird: Das dokumentierte und das effektive Format sind dasselbe Objekt.

Die zulässigen Werte ergeben sich teilweise daraus. Eine CHECK-Einschränkung zählt die zulässigen Werte einer codierten Spalte auf, und ein Fremdschlüssel auf eine Referenztabelle liefert noch mehr, weil diese Tabelle den Code und seine Bezeichnung nebeneinander führt. Die Bedeutung steht dort, wo jemand sie hingeschrieben hat. Der Spaltenname legt sie nahe, ohne sie je zu garantieren: dat_resil lässt sich erraten, liest sich auf drei Arten und ist für keine massgebend. Schemakommentare (COMMENT ON TABLE und COMMENT ON COLUMN bei Oracle, PostgreSQL und Db2, erweiterte Eigenschaften bei SQL Server) sind die einzige Stelle, an der eine Definition im selben Skript steht wie die Struktur, die sie beschreibt, also die einzige Stelle, an der beide nicht auseinanderlaufen können. Wo ein Team diese Disziplin einhält, kommt ein Teil des Feldes Beschreibung mit dem Schema mit.

Dieser Fall verschiebt den Aufwand der Technik, ohne ihn aufzuheben. Schritt 2 wird zu einer Extraktion von wenigen Minuten, Schritt 9 wird fortlaufend und kostenlos, der Hauptteil des Aufwands verlagert sich auf die Schritte 3 und 6, nämlich die Synonyme, die Homonyme und die Verantwortung für die Richtigkeit. Ein ausgelesener Eintrag ist beim Format richtig und beim Sinn stumm. Wer einen Spaltennamen für eine Definition nimmt, erzeugt ein Wörterbuch, dessen Zeilen alle dokumentiert aussehen.

Das aktive Wörterbuch einer Standardsoftware

Ein Wörterbuch ist aktiv, wenn das System daraus erzeugt wird und nicht bloss darauf verweist. Manche ERP-Systeme führen das Wörterbuch auf diese Weise. Das ABAP Dictionary von SAP ist der Referenzfall.

Die Folge kehrt jene des von Hand geführten Wörterbuchs um. Die Dokumentation von SAP nennt die erste Wirkung: Wird eine bestehende Domäne geändert, sind alle ihre Verwender betroffen, und die Fremdschlüssel, die auf den betroffenen Feldern beruhen, können inkonsistent werden. Eine Änderung von Länge oder Typ geht weiter und erzwingt die Konvertierung der betroffenen Tabellen. Die Domäne einer Lieferantennummer zu verbreitern, berührt jede Tabelle mit einem daraus abgeleiteten Feld, dazu die Bildschirmmasken und die Schnittstellen, die deren Bezeichner anzeigen. Die Plattform garantiert hier die Eigenschaft, die ein manuelles Wörterbuch über Disziplin anstrebt: eine einmal und nur einmal geschriebene Definition. Der Preis ist die Reichweite: Eine Formatänderung ist konstruktionsbedingt global, sie lässt sich also nicht modulweise steuern.

Zwei Präzisierungen lohnen sich, weil ihre Verwechslung teuer ist. Erstens wird ein Objekt des Wörterbuchs über die Entwicklung geändert und wie Code transportiert; bei einer vom Hersteller ausgelieferten Domäne ist der Eingriff eine Modifikation des Standards. Wer für die Verlängerung eines Feldes ein «einfaches Customizing» verspricht, verspricht eine Tabellenkonvertierung. Zweitens wird die vom Fachbereich genutzte Länge fast nie im Wörterbuch eingestellt. Die Kundennummer beruht auf einer Domäne mit zehn Zeichen, die unverändert bleibt; über die Kontengruppe, den Nummernkreis und die Wahl zwischen interner und externer Nummernvergabe legt das Customizing die Anzahl der innerhalb dieses Formats effektiv genutzten Zeichen fest. Ein externer Nummernkreis mit sechs Stellen erzeugt eine Nummer, die der Anwender als 123456 liest und die Datenbank als 0000123456 speichert, wobei die an der Domäne hängende Konvertierungsroutine die führenden Nullen ergänzt.

Ein Eintrag, der CHAR(10) aus dem Wörterbuch abschreibt, ist richtig und irreführend: Er gibt das Format des Datenfelds und schweigt zur Regel, die die Werte bestimmt und im Customizing steckt. Er schweigt ebenso dazu, dass das Element zwei Formen hat, eine interne und eine externe, wobei die zweite jene ist, die der Fachbereich benennt und jede Austauschdatei transportiert. Das Feld Werte und Bedeutungen wird deshalb aus dem Customizing gefüllt, und das Feld Aliasnamen hält beide Formen fest. Dieselbe Differenz kehrt auf Ebene des Objekts wieder: Seit der Geschäftspartner das führende Objekt ist, sind ein Kunde und ein Lieferant zwei Rollen derselben Partei, die neben der Kundennummer und der Lieferantennummer eine eigene Nummer trägt. Drei Identifikatoren bezeichnen dann dieselbe Partei, und das Wörterbuch sagt nicht, welchen davon der Fachbereich «die Nummer» nennt.

Was das aktive Wörterbuch liefert, liefern wenige Quellen: bereits übersetzte Bezeichner, eine Dokumentation je Element und eine Garantie technischer Richtigkeit. Was es auslässt, bleibt vollständig offen: der Name, den der Fachbereich verwendet, der Eigentümer der Definition und die reale Verwendung des Feldes. Ein Standardfeld, das das Unternehmen für einen anderen Zweck umgewidmet hat, liest sich im Wörterbuch richtig und in den Daten falsch.

Das Wörterbuch in einer Analytics-Initiative

Die Spalte der Validierungsregeln, die die Praxis den vier Feldern des BABOK hinzufügt, ist verankert: Der Guide to Business Data Analytics der IIBA (§3.4) erweitert den Eintrag um Geschäftsregeln und Validierungsregeln, auch für abgeleitete und transformierte Elemente. Die Spalte des Eigentümers beruht allein auf der Praxis.

Der Leitfaden nennt die Geschäftsregel neben der Validierungsregel, und das Modell mit sechs Spalten gibt ihr keine Spalte. Die Frage stellt sich beim ersten abgeleiteten Eintrag. Die Regel, die ein abgeleitetes Element berechnet, gehört in Werte und Bedeutungen, neben das Format und die Liste der zulässigen Werte, denn sie sagt, was das Element wert ist. Die Validierungsregeln halten fest, was einen Wertkandidaten zurückweist: eine Prüfziffer, einen Wertebereich, eine Abhängigkeit von einem anderen Element. Die Geschäftsregel, die das Element bestimmt, ohne es zu berechnen oder zu beschränken, gehört ins Verzeichnis der Geschäftsregeln. Das Wörterbuch nennt sie über den Namen der Regel, statt sie abzuschreiben.

Der Leitfaden fügt eine Frage hinzu, die ein Wörterbuch für eine einzelne Lösung nie stellen muss: wo das Element liegt. In einer Analytics-Initiative verortet das Wörterbuch jedes Element über die Systeme der Organisation hinweg und wird damit zum Inventar dessen, was tatsächlich existiert, bevor die Forschungsfrage formuliert wird. Zusammen mit einem Entity-Relationship-Modell sagt es, wie Daten aus mehreren Quellen verbunden werden: Typ, Format und Länge entscheiden, ob die Verbindung möglich ist.

Was die Übung scheitern lässt

Das stille Auseinanderlaufen mit dem realen Schema

Das ist die zentrale Falle, tödlich, weil sie unsichtbar ist. Das Wörterbuch wird einmal geschrieben, beim Projektabschluss, dann entwickelt sich das Schema weiter: Eine Spalte wird verbreitert, eine Aufzählung erhält einen Wert, ein Feld wird zweckentfremdet und niemand rührt den zugehörigen Eintrag an. Das veraltete Wörterbuch kostet dann mehr als gar keines, weil es weiterhin konsultiert und geglaubt wird: Eine Entwicklerin liest das dokumentierte Format, baut darauf eine Validierung und irrt auf eine Art, die gedeckt aussieht. Ohne Wörterbuch hätte dieselbe Person im System nachgesehen. Die Schritte 8 und 9 gibt es einzig aus diesem Grund.

Das Glossar duplizieren

In die Beschreibung zu schreiben, was «Kunde» für das Unternehmen bedeutet, erzeugt zwei Dokumente, die sich widersprechen werden, sobald das eine nachgeführt wird und das andere nicht. Die Beschreibung bleibt auf das Element im Kontext der Daten der Lösung beschränkt, und die Debatte über den Fachbegriff geht zurück ans Glossar.

Blindheit gegenüber Homonymen

Den Kunden des CRM und den Kunden der Fakturierung als ein Element zu behandeln, weil sie denselben Namen tragen, erzeugt eine auf Feldebene falsche Integration, während das Wörterbuch vollkommene Konsistenz meldet. Schritt 3 ist die einzige Abwehr.

Das zusammengesetzte Element, das seine Bestandteile abschreibt

Die Bestandteile im Klartext in die Definition eines zusammengesetzten Elements zu kopieren, zerstört die Einzigkeit der Quelle und stellt die Duplizierung wieder her, die die Technik beseitigt.

Die zu tief angesetzte Auswahl

Die Alternative zwischen zwei Identifikatoren zu schreiben und dann von allen Fällen die Attribute nur eines der beiden zu verlangen, erzeugt eine Kompositionsregel, die einen Fall zulässt und ihn sogleich ungültig macht. Die Alternative umfasst die ganze Gruppe der Bestandteile, die vom gewählten Fall abhängen.

Das Abgleiten in den Unternehmenskatalog ohne die entsprechende Governance

Zusätzlich zu den vier Feldern von Hand Data Lineage, Qualitätskennzahlen und Zugriffsrechte führen zu wollen, erzeugt ein Dokument, das zu schwer ist, um gepflegt zu werden. Diese Dimensionen gehören auf eine Katalogplattform und in deren Verantwortungsmodell.

Der codierte Wert, dessen Bedeutung nie geschrieben wird

Eine Aufzählung 1, 2, 3 ohne ihre Legende macht aus dem Wörterbuch ein leeres Register. Der BABOK sagt es ausdrücklich: Ein abgekürzter Wert trägt die Erklärung seiner Bedeutung.

KI-Überlegungen

Das Reverse Engineering ist der klarste Einsatz. Ein Sprachmodell liest ein Datenbankschema (Spaltennamen, Typen, Einschränkungen, Indizes), liest den Code, der es schreibt und es liest, betrachtet eine Stichprobe von Werten und erzeugt einen ersten Entwurf von Einträgen: einen vorgeschlagenen kanonischen Namen, in den verschiedenen Systemen aufgespürte Aliasnamen, ein aus dem Typ abgeleitetes Format samt Länge, eine aus den angetroffenen unterschiedlichen Werten rekonstruierte Aufzählung. Bei einem Altschema mit mehreren hundert undokumentierten Spalten verwandelt dieser erste Entwurf eine Arbeit von mehreren Wochen in eine Durchsicht von wenigen Tagen.

Die Abweichungserkennung ist der Einsatz mit dem höchsten Wert, weil er die zentrale Falle der Technik angeht. Laufend zu vergleichen, was das Wörterbuch erklärt (Format, Länge, zulässige Werte) und was das lebende Schema tatsächlich enthält (effektiver Typ, effektive Einschränkung, Verteilung der beobachteten Werte), ist mechanische, sich wiederholende und undankbare Arbeit, genau jene Art von Wachsamkeit, die menschliche Aufmerksamkeit auf Dauer nicht durchhält und die eine Werkzeugkette mühelos durchhält. Ein unbekannter Wert, der in einer aufgezählten Spalte auftaucht, eine überschrittene Länge, eine verschwundene Spalte: Jede dieser Abweichungen geht als Meldung an den Eigentümer des Elements.

Der dritte Einsatz betrifft Synonyme und Homonyme zwischen Systemen. Angesichts zweier Schemata oder zweier bestehender Wörterbücher meldet ein Modell die Paare «diese beiden Felder beschreiben wahrscheinlich dasselbe unter zwei Namen» und die Fälle «dieser Name bezeichnet in diesen beiden Datenbanken zwei verschiedene Dinge», gestützt auf Namen, Typen, Werteverteilungen und Kontext. Es beschleunigt Schritt 3, indem es die Kandidaten liefert; der Entscheid bleibt menschlich.

Die Grenze ist scharf und betrifft die Bedeutung. Die massgebende Bedeutung eines Datenelements ist eine Tatsache des Unternehmens. Ein Modell, das eine Spalte kundenstatus mit den Werten 1, 2 und 3 betrachtet, feststellt, dass Zeilen mit 3 keine jüngere Aktivität mehr aufweisen, und daraus schliesst, «3 bedeutet wahrscheinlich gekündigt», hat eine als Definition dargebotene Vermutung erzeugt, im Wörterbuch nicht unterscheidbar von einem Wert, den der Fachbereich bestätigt hat. Die Spalte kann ebenso gut eine administrative Sperre codieren, geerbt aus einem 2014 abgelösten System. Kein Modell kann das entscheiden, denn die Antwort ist ein Entscheid, den die Organisation getroffen hat oder treffen muss. Jeder von einer Maschine verfasste Eintrag ist ein Vorschlag an den Eigentümer des Elements, der ihn bestätigt, bevor er als Tatsache ins Wörterbuch eingeht. Dasselbe Prinzip gilt für die Sensibilität der Daten: Ein Produktionsschema, seine Stichproben und seine Verteilungen einem externen Dienst offenzulegen, ist ein Entscheid des Datenschutzes, getroffen vor der Nutzung.

Beispiele

Das Beispiel ist das Wörterbuch eines Krankenversicherers der Westschweiz, beschränkt auf die Elemente, die eine versicherte Person und ihre Kontaktdaten beschreiben. Jeder Eintrag trägt die vier Felder des BABOK (Name, Aliasnamen, Werte und Bedeutungen, Beschreibung) und die zwei, die die Praxis ergänzt (Eigentümer, Validierungsregeln). Format und Länge stehen in «Werte und Bedeutungen»: Der BABOK ordnet die Beschreibung der erlaubten Formate dort ein, Zeichenzahl inbegriffen. Die Schweizer Identifikatoren prüfen diese Spalte Feld für Feld, weil ihr Format beschränkt und die Beschränkung prüfbar ist.

Eine unbeabsichtigte Lesart ergibt sich aus der Tabelle. «Numéro de police» ist in der Westschweiz die katasterrechtliche Bezeichnung der Hausnummer, und «police» heisst auf Französisch zugleich Versicherungspolice. Im Wörterbuch eines Versicherers bezeichnet ein einziges französisches Wort diese beiden Dinge ohne Zusammenhang, und eines davon taucht auch in der Kardinalität zwischen Kunde und Police auf. Das ist ein Homonym des Französischen, und die Abwehr ist jene aus Schritt 3: den Alias fallen lassen oder ihn eindeutig unterschieden führen, «Numéro de police du bâtiment». Die Tabelle wählt den zweiten Weg. Allein das Feld Aliasnamen hat den Konflikt zutage gefördert.

Die zusammengesetzten Elemente werden anschliessend aus diesen primitiven Elementen gebildet, ohne je eines davon neu zu definieren. Zusammen verwenden diese Regeln die vier Operatoren der Notation.

Eine Validierungslücke ergibt sich aus der Komposition. Die Tabelle der primitiven Elemente verlangt die Bestätigung der E-Mail-Adresse bereits, bevor diese als Kanal dient. Die Abhängigkeit vom Vorhandensein zeigt sich dagegen erst in der Komposition: Die Kundenkontaktdaten machen die E-Mail fakultativ, während der Bevorzugte Kanal erlaubt, sie zu wählen. Der bevorzugte Kanal darf deshalb nur dann «E-Mail» lauten, wenn die Adresse erfasst ist.

Visualisierungen

Der Kompositionsbaum zeigt auf einen Blick, was die Notation in einer Zeile sagt, und er macht sichtbar, was die Zeile verbirgt: die Tiefe. Versicherte Person referenziert Kundenadresse und Kundenkontaktdaten, die ihrerseits primitive Elemente referenzieren, und diese Verschachtelung unterscheidet ein Wörterbuch von einer blossen Liste von Feldern. Die Art der Verbindung wird am Konnektor abgelesen: Adresszusatz ist in dieser Komposition fakultativ, und dasselbe primitive Element wäre in einer anderen obligatorisch. Die Auswahl verlangt den Baum noch deutlicher. Sie beschränkt eine Gruppe von Zweigen, von denen genau einer gewählt wird, und keine Markierung an einem einzelnen Element kann diese Bedingung aussagen.

Der Baum ist zugleich das Kontrollinstrument des Wörterbuchs, und er deckt Mängel auf, die eine Zeile für Zeile gelesene Regeltabelle durchgehen lässt. Ein verwaistes Blatt, ein Bestandteil, der nirgends als Eintrag des Wörterbuchs erscheint, ist eine Inline-Neudefinition: Das zusammengesetzte Element hat seinen Bestandteil im Klartext abgeschrieben. Ein primitives Element, das von keinem zusammengesetzten Element referenziert wird, ist entweder ein toter Eintrag, ein Element, das kein Modell und keine Schnittstelle verwendet und das Schritt 5 auszusondern verlangt, oder das Zeichen, dass ein zusammengesetztes Element vergessen wurde. Ein Zyklus, ein zusammengesetztes Element, das sich über eine Kette von Referenzen am Ende selbst referenziert, ist eine zirkuläre Komposition, in einem einzeln gelesenen Regelsatz nicht erkennbar und auf dem Baum sofort sichtbar. Diese drei Kontrollen fangen ab, was Schritt 9 erst später abfinge, gegen das reale Schema und teurer.

Aufwand

Werkzeuge

Eine geteilte Tabellenkalkulation oder eine Wiki-Seite genügen, solange der Bereich begrenzt, nur ein Team beteiligt und das Schema stabil ist. Die Lizenzkosten sind null, die Struktur des Wörterbuchs fügt sich in Spalten und das Sortieren nach Name oder Alias bringt die Doubletten nach oben. Die Grenze ist im Voraus bekannt: Die Pflege ist manuell, sie beruht also auf Disziplin und sie gibt beim ersten Release unter Zeitdruck nach. Dieser Entscheid lässt sich vertreten, wenn die Volatilität des Schemas gering ist, und er wird teuer, wenn sie es nicht ist.

Die nächste Schicht lebt im Code. dbt docs und die entsprechenden Werkzeuge der Transformationsschicht erzeugen die Dokumentation der Elemente aus dem modellierten Schema, bei jedem Build: Die Beschreibung wird im selben Repository geschrieben wie die Transformation, sie wird im selben Merge Request geprüft und sie kann nicht vom Schema abweichen, da sie daraus gewonnen wird. Das ist die strukturelle Antwort auf die zentrale Falle, und sie passt, sobald die Daten ohnehin in einer Transformationskette leben. Schema-Registries (für Ereignis- und Streaming-Daten) gehen auf einem engeren Bereich weiter: Sie versionieren die strukturelle Definition und weisen eine nicht konforme Nachricht in der Produktion zurück, was auf diesem einen Datensegment einen starken Schutz gegen die Abweichung bietet, ohne jedoch die Aliasnamen oder die fachliche Beschreibung zu tragen.

Datenkataloge rechtfertigen sich, wenn der Bereich das Unternehmen ist, mehrere Systeme abgeglichen werden müssen und die Organisation in ein Verantwortungsmodell investieren kann. Collibra und Alation sind die etablierten kommerziellen Plattformen: Sie lesen die technischen Metadaten der lebenden Schemata automatisch aus und gehen damit die Abweichung an, und sie legen Governance-Abläufe darüber (Eigentümer, Freigabe, Lebenszyklus der Definition). DataHub und OpenMetadata bieten dieselbe Funktionsfamilie als Open Source und sind die Option, wenn der Lizenzpreis der blockierende Punkt ist, um den Preis des Plattformbetriebs.

Der Bezugsrahmen dieses ganzen Werkzeugkastens ist die Norm ISO/IEC 11179, die die Metadaten-Verzeichnisse definiert: Teil 1 legt den allgemeinen Rahmen fest, und Teil 4 legt die Regeln für das Schreiben einer Definition eines Datenelements fest. Der DAMA-DMBOK, das Referenzwerk des Datenmanagements, ordnet das Wörterbuch dem Kapitel des Metadatenmanagements zu und liefert dessen Verantwortungsmodell. Beide lohnen die Lektüre, bevor eine Plattform gewählt wird, denn sie beschreiben, was die Plattform tragen soll.

Quellen

• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.12 Data Dictionary.
• ISO/IEC 11179-1, Information technology - Metadata registries (MDR) - Part 1: Framework: der normative Rahmen der Metadaten-Verzeichnisse, deren häufigste Form das Datenwörterbuch ist.
• ISO/IEC 11179-4, Information technology - Metadata registries (MDR) - Part 4: Formulation of data definitions: die Regeln für das Schreiben einer Definition eines Datenelements, die direkte Referenz des Feldes Beschreibung.
• ISO/IEC 9075-11, Information technology - Database languages SQL - Part 11: Information and definition schemas (SQL/Schemata): die Norm, die das INFORMATION_SCHEMA definiert, den normierten Zugriff auf den Katalog einer relationalen Datenbank.
• DAMA International, DAMA-DMBOK: Data Management Body of Knowledge, Kapitel Metadatenmanagement: das Verantwortungs- und Governance-Modell der Metadaten-Verzeichnisse.
• SAP, ABAP Keyword Documentation, ABAP Dictionary: Technical Attributes of Domains: die technischen Attribute einer Domäne und die Reichweite einer Änderung über alle daraus abgeleiteten Felder.
• Tom DeMarco, Structured Analysis and System Specification, Yourdon Press, 1978: die Quelle der klassischen Kompositionsnotation mit vier Operatoren (Sequenz, Wiederholung, Optionalität, Auswahl).
• IIBA, Guide to Business Data Analytics, §3.4 Data Dictionary: der um Geschäfts- und Validierungsregeln erweiterte Eintrag (abgeleitete Elemente eingeschlossen) und die Verortung eines Elements über mehrere Systeme.