Data Mapping

Ziel

Das Data Mapping stellt Attribut für Attribut die Entsprechung zwischen einem Quelldatenbestand und einem Zielbestand her. Ein Altsystem speichert einen Betrag als Ganzzahl in Rappen, während die ablösende Plattform Franken als Dezimalzahl erwartet; es codiert das Fehlen eines Datums durch ein unmögliches Datum, wohingegen das Ziel den Nullwert zulässt. Jede dieser Abweichungen verlangt einen Entscheid.

Für jedes Zielattribut hält die Data-Mapping-Spezifikation zwei Dinge fest: ob der Wert unverändert ankommt und, wenn nicht, welche Regel ihn umformt. Sie allein trägt diese Angaben, denn das Ladeprogramm wendet die Regel an, ohne sie zu benennen. Die Spezifikation ist der Vertrag zwischen der Analyse und dem Team, das den Ladelauf schreiben wird. Später wird sie zum Nachweis für alle, die erklären müssen, woher ein Wert stammt.

Das Data Mapping leistet einen zweiten Dienst, den der IIBA-Leitfaden benennt: Es legt die Qualitätsmängel der Quelle und des Ziels offen. Wer die Regel für ein Attribut schreibt, muss nachsehen, was im Feld steht. Dabei zeigen sich das nie geprüfte Feld, die aufgegebene Codierung, von der noch drei Werte übrig sind, die Spalte, die von der Hälfte der Nutzenden ausgefüllt wird. Die Entdeckung kostet wenig, solange sie dem ersten Ladelauf vorausgeht.

Einsatz

Wann einsetzen

• Datenübernahme in ein neues System: Kein Ladelauf startet, bevor die Zuordnung geschrieben und abgenommen ist.
• Integration in einen bestehenden Bestand: Zusammenlegung von Portefeuilles, Konsolidierung nach einer Übernahme, Speisung eines gemeinsamen Data Warehouse.
• Uneinheitliche Formate auf beiden Seiten: Typen, Längen und Codierungen weichen voneinander ab.
• Zielattribut ohne direkte Entsprechung: Eine Berechnung oder eine Verkettung ist zu definieren.
• Geforderte Nachvollziehbarkeit: Eine Aufsichtsbehörde oder die Revisionsstelle fragt, woher jeder Wert im Zielsystem stammt.
• Zweifelhafte Qualität der Quelle: Das Data Mapping misst sie Feld für Feld, bevor die Mängel in die Produktion gelangen.
• Ladelauf durch ein anderes Team oder durch einen Dienstleister: Die Spezifikation ist die einzige Form, in der die Erwartung des Fachbereichs bei der Person ankommt, die den Ladelauf schreibt.

Wann nicht einsetzen

• Identisches Schema auf beiden Seiten: Beim Klonen einer Umgebung oder beim Wiederherstellen genügt ein Schemavergleich.
• Unvereinbare Datenmodelle: Das Zielmodell sieht keinen Platz für das vor, was die Quelle trägt; in diesem Fall führt der Weg zurück zur Datenmodellierung.

Beschreibung

Was die Technik hervorbringt

Das Ergebnis ist ein Register, meist in einer Tabellenkalkulation geführt, mit einer Zeile je Zielattribut. Der IIBA-Leitfaden legt die Spalten fest: Zielentität, Zielattribut, Zieldatentyp, Quellattribut oder -attribute, direkte Zuordnung, Transformationsregel.

Die Spalte der direkten Zuordnung wird im Register am schlechtesten behandelt. Sie steht nur dann auf ja, wenn der Wert unverändert ankommt, Format und Einheit eingeschlossen. Ein Betrag, der die Einheit wechselt, ein Datum, das das Format wechselt, ein Identifikator, der Trennzeichen erhält, sind indirekte Zuordnungen, so offensichtlich die Umformung auch sein mag. Ein aus Bequemlichkeit gesetztes Ja lässt die Regel nirgends stehen: weder in der Spezifikation noch im Kopf der Person, die den Ladelauf schreibt.

Quelle und Ziel

Auf der Quellseite betrifft die Analyse drei Punkte: das Format des Bestands (Datei mit Trennzeichen, Tabellenkalkulation, Datenbankentität, Dienst), die heute oder künftig interessierenden Attribute, dann Typ und Grösse jedes einzelnen. Der dritte Punkt verlangt, über die Deklaration des Schemas hinauszugehen: Eine als varchar(50) deklarierte Spalte, deren längster Wert 18 Zeichen misst, und eine gleich deklarierte Spalte, die bis zum Rand gefüllt ist, werfen verschiedene Probleme auf.

Auf der Zielseite betrifft die Analyse die Attribute, die für die Aufnahme der Quelle anzulegen sind, Typ und Grösse, die ihnen zu geben sind, die umzuformenden Quellattribute samt ihrer Regel und die Felder, die durch Berechnung, Verkettung oder Formatierung aufzubauen sind. Die Regel zur Dimensionierung steht ausdrücklich im Leitfaden: Die Grösse des Zielattributs ist nie kleiner als die der Quelle. Gleichheit ist der Normalfall; eine grössere Zielgrösse ist eine bewusst eingeräumte Reserve für Wachstum. Eine kleinere führt zu Datenverlust: Die meisten Ladewerkzeuge kürzen den Wert ohne Warnung. Diese Regel gilt für ein Attribut, das aus einem einzigen Quellattribut gespeist wird. Ein durch Verkettung oder Berechnung aufgebautes Attribut wird auf den ungünstigsten Fall seiner Eingaben dimensioniert, gemessen an den realen Daten.

Migration oder Integration

Der Leitfaden unterscheidet zwei Anwendungen, die nicht dieselbe Arbeit verlangen. Die Migration bringt die Quelldaten in einen neuen Bestand: Das Ziel wird zum Teil für ihre Aufnahme entworfen, und die Konflikte beschränken sich auf die Formate. Die Integration führt die Quelldaten in einen bereits gefüllten Bestand ein.

Sie setzt zunächst voraus, dass die Datenmodelle beider Seiten übereinstimmen, auch wenn die Schemata voneinander abweichen. Zwei verschiedene Schemata beschreiben dieselbe Wirklichkeit auf zwei Arten, und eine Zuordnung bringt sie zusammen. Zwei verschiedene Modelle beschreiben zwei Wirklichkeiten: Führt die Quelle einen Vertrag je Person und das Ziel einen Vertrag je Haushalt, schliesst keine Transformationsregel die Lücke, und die Frage geht zurück an die Modellierung.

Sie verlangt sodann eine Analyse der gemeinsamen Attribute beider Bestände und der Kardinalität ihrer Beziehung, eins zu eins oder null zu mehreren nach den Beispielen des Leitfadens. Entsprechen mehrere Quelldatensätze einem einzigen Zieldatensatz, ist Attribut für Attribut zu bestimmen, welcher den Vorrang hat, über das Schicksal der verknüpften Datensätze zu entscheiden und die Tabelle vorzusehen, die den alten Schlüssel festhält. Keiner dieser drei Entscheide folgt aus den Daten: Sie werden mit dem Fachbereich getroffen, in der Spezifikation.

Die Durchführung

1. Beide Bestände aufnehmen. Format, Volumen, Schema, Eigentümer. Das Datenwörterbuch beider Seiten beschaffen oder es für die betroffenen Attribute erstellen.
2. Die zu speisenden Zielattribute auflisten, einschliesslich derjenigen, die erst anzulegen sind. Diese Liste steht fest, bevor jemand die Quellen sucht.
3. Jedes Zielattribut seiner Quelle zuordnen. Ein Attribut, mehrere Attribute oder keines. Der Fall "keines" ist zulässig und ist aufzuschreiben: konstanter Wert, berechneter Wert, bei der Übernahme leer gelassenes Feld, das der Fachbereich später füllt.
4. Typ, Grösse und Wertebereich vergleichen. Jede Verkleinerung, jeden Unterschied in der Codierung, jede abweichende Einheit festhalten. Dieser Durchgang bringt die meisten nicht direkten Zeilen hervor.
5. Die Transformationsregel schreiben. Sie muss genau genug sein, um ohne Rückfrage ausgeführt zu werden, und lesbar genug, um vom fachlichen Eigentümer der Daten abgenommen zu werden. Beide Anforderungen sind zugleich erfüllt, wenn die Regel konkrete Werte nennt statt einer Absicht.
6. Die Regeln vom Fachbereich abnehmen lassen. Alte Codes, Sentinel-Werte, Kategorien wie "Diverses" und historische Ausnahmen kennen nur wenige Personen; dokumentiert sind sie selten und aus dem Schema nie ableitbar.
7. Die Quelle gegen die geschriebene Regel profilieren. Vor dem ersten Ladeversuch die Werte zählen, die ihr nicht entsprechen. Eine Regel, die 99,4% der Datensätze abdeckt, lässt einen Rest, dessen Behandlung jetzt zu entscheiden ist.
8. Eine Version einfrieren und sie halten. Der Leitfaden nennt die Grenze: Die Spezifikation ist nachzuführen, sobald sich auf der einen oder der anderen Seite etwas ändert.

Die Abgrenzung zu ETL, Wörterbuch und Datenflussdiagramm

Das Data Mapping deklariert, ETL führt aus. Die Spezifikation nennt die Zuordnung und die Regel; der Prozess wendet sie auf die Datensätze an, mit seiner Planung, seinem Wiederanlauf nach Fehlern und seinen Protokollen. Die Abgrenzung zeigt sich am Ergebnis: auf der einen Seite ein Dokument, das der Fachbereich liest und abnimmt, auf der anderen ein Prozess, der läuft. Der Leitfaden ordnet die Erzeugung der Audit-Trails der geänderten oder ersetzten Daten dem Ladeschritt des ETL zu, womit die nach dem Laden geführten Kontrollen auf die Seite des Prozesses fallen.

Das Datenwörterbuch kommt davor. Es legt Namen, Aliasnamen, Bedeutung, Format und zulässige Werte jedes Elements fest, und der Leitfaden bezeichnet es als Hilfe bei der Durchführung eines Data Mappings. Das Wörterbuch sagt, was das Feld ist; die Spezifikation sagt, was aus ihm wird. Ohne das Wörterbuch wird die Zuordnung auf Spaltennamen geschrieben.

Das Datenflussdiagramm beantwortet eine andere Frage: welcher Prozess welche Daten zwischen welchen Datenspeichern bewegt, auf welcher Zerlegungsebene. Es zeigt, dass die Daten der versicherten Person vom Altsystem zur Zielplattform gehen. Die Data-Mapping-Spezifikation sagt, was unterwegs mit dem Austrittsdatum geschieht.

Woran das Data Mapping scheitert

Der unverändert übernommene Sentinel-Wert. Ein Altsystem, das keinen Nullwert zulässt, codiert das Fehlen mit einem unmöglichen Wert: ein Datum wie 31.12.2099, ein Betrag von 0, ein Code 999. Ohne Regel übernommen, wird der Sentinel zu einer plausiblen Angabe. Ein Arbeitsvertrag endet in den Auswertungen im Jahr 2099, ein Lohn von null geht in eine Beitragsberechnung ein. Erkannt wird er beim Profiling, beim Blick auf die häufigsten Werte jedes Felds.

Die auf den Spaltennamen gestützte Zuordnung. Zwei Felder namens kunde bezeichnen im einen System den Haushalt, im anderen den Zahler; zwei Felder beginn_datum bezeichnen im einen die Unterzeichnung, im anderen das Inkrafttreten. Die Ähnlichkeit der Namen ist eine Annahme, die bei denen zu prüfen ist, die das Feld ausfüllen.

Die Regel, die im Code des Ladelaufs lebt. Eine in einer Sitzung beschlossene und im Prozess umgesetzte Umformung, die nicht ins Register zurückfliesst, ist an dem Tag nicht mehr prüfbar, an dem ihr Urheber das Mandat wechselt. Nachvollziehbarkeit Feld für Feld setzt voraus, dass die Deklaration ausserhalb des Codes besteht, der sie anwendet.

Die erst beim Laden entdeckte Kardinalität. Eine Zurückweisung wegen Verletzung der Eindeutigkeitsbedingung, am Tag vor der Umstellung, zeigt eine nicht durchgeführte Integrationsanalyse an. Zu bestimmen, welcher Datensatz den Vorrang hat, ist ein Führungsentscheid; ihn unter Druck in einer Migrationsnacht zu fällen, heisst, ihn der Person im Pikettdienst zu überlassen.

Die überholte Spezifikation. Eine Übernahme dauert Monate, in denen sich beide Systeme weiterentwickeln. Ohne Kontrollpunkt bei jeder Schemaänderung beschreibt das Register einen vergangenen Zustand, und der Ladelauf scheitert an Spalten, die sich verschoben haben. Die Spezifikation an die Änderungssteuerung beider Systeme zu binden, kostet wenig und gehört an den Anfang.

KI-Überlegungen

Integrationswerkzeuge schlagen Zuordnungskandidaten anhand der Ähnlichkeit von Name, Typ und stichprobenweise gelesenem Inhalt vor; ein Sprachmodell tut dasselbe mit zwei Spaltenlisten und erkennt dabei Abkürzungen und uneinheitliche Namenskonventionen. Bei einem Schema mit vierhundert Spalten nimmt dieser automatische Abgleich dem Analysten den mechanischen Teil der Arbeit ab und überlässt ihm die Zeilen, die einen Entscheid verlangen.

Die Übersetzung von "Datum im Format tt.mm.jjjj nach ISO, Wert 31.12.2099 nach null" in einen SQL-Ausdruck oder in eine Transformation des Werkzeugs ist wiederkehrende Codearbeit, von ihrer Spezifikation lückenlos beschrieben, deren erster Entwurf sich rasch gegenlesen lässt. Testdaten, die die Grenzfälle der Regel abdecken, entstehen auf demselben Weg. Das Profiling gehört zur selben Verwendung: Ein unbekanntes Feld über seine verschiedenen Werte, seine Längen, seinen Anteil an Nullwerten und seine Werte ausserhalb des Wertebereichs zu beschreiben, lässt sich in Alltagssprache verlangen, und das Ergebnis dient dazu, die geschriebene Regel am tatsächlichen Inhalt zu messen.

Der Abgleich stützt sich auf Namen und Typen, und das Werkzeug liefert seine Vorschläge mit derselben Bestimmtheit, ob sie nun richtig oder falsch sind. Was ein Feld in der Organisation bedeutet, ab wann es gefüllt wurde, welche Codierung es zuvor trug, steht nicht im Schema. Eine ohne fachliche Gegenlesung übernommene Zuordnung erzeugt einen Fehler je Datensatz. Auch die Entscheide zur Zusammenführung entziehen sich dem Werkzeug: Welche Zweigniederlassung eines fusionierten Arbeitgebers zum Referenzdatensatz wird, ist ein Führungsentscheid.

Bleiben die Daten selbst. Ein Produktionsauszug, der einem externen Dienstleister "zum besseren Verständnis des Felds" übergeben wird, enthält AHV-Nummern, Löhne und Geburtsdaten, also Personendaten im Sinne des Bundesgesetzes über den Datenschutz (DSG). Die Bekanntgabe an Dritte ist eine Bearbeitung: Sie verlangt einen Rechtfertigungsgrund, die Information der betroffenen Personen und, wenn der Dritte für die Kasse tätig wird, einen Vertrag zur Auftragsbearbeitung. Das Schema allein oder ein maskierter Auszug beantwortet dieselbe Frage.

Beispiele

Eine Pensionskasse migriert ihre Versichertendatensätze von einem alten Verwaltungssystem auf eine neue Plattform.

Eine von sechs Zeilen ist direkt. Die anderen fünf tragen je eine andere Art von Regel: Formatierung, Verkettung, Wechsel der Einheit, Sentinel-Wert, Zusammenführung. Die dritte zeigt die Grenze der Dimensionierungsregel: Zwei Quellen zu 40 Zeichen und ein Leerzeichen ergeben 81 Zeichen für ein Ziel von 80, also eine bewusst beschlossene und protokollierte Kürzung. Die letzte folgt aus keiner Angabe des Altsystems: Sie beruht auf einer Zuordnungstabelle, die der Fachbereich aus der Geschichte der Arbeitgeberfusionen aufbaut. Diese Tabelle ist ebenso ein Ergebnis des Data Mappings wie das Register selbst.

Visualisierungen

Die Spezifikation gehört in eine Tabelle: Als Bild verlöre sie die Auswahl, die Sortierung und den Vergleich von Version zu Version. Zeichnen lässt sich der Platz der Technik unter ihren Nachbarn: wer definiert, wer deklariert, wer ausführt.

Ein ausgefülltes Register geht man über die Spalte der direkten Zuordnung durch. Zuerst nimmt man sich die Zeilen mit "nein" vor, und bei jeder prüft man zwei Punkte: dass die Regel konkrete Werte statt einer Absicht nennt und dass die Zielgrösse die Quellgrösse abdeckt. Es bleiben die Zeilen ohne Quellattribut, von denen jede einen schriftlichen Entscheid tragen muss, konstanter Wert, berechneter Wert oder bei der Übernahme leer gelassenes Feld. Der Weg von einem Zielattribut zu seiner Registerzeile besteht aus drei Fragen, die der Reihe nach gestellt werden.

Aufwand

Werkzeuge

Die Tabellenkalkulation ist das ursprüngliche Format der Technik und genügt für die meisten Übernahmen: ein Blatt je Zielentität, eine Zeile je Attribut, die sechs Spalten des Registers. Ihre Schwächen treten mit wachsendem Umfang zutage, wenn mehrere hundert Zeilen parallel geändert werden, ohne Konsistenzprüfung und ohne lesbare Versionsgeschichte. Sie in einem Textformat im Repository des Projekts zu versionieren, behebt die zweite Schwäche mit wenig Aufwand.

Integrations- und ETL-Werkzeuge (Talend, Azure Data Factory, SQL Server Integration Services, Informatica, dbt) halten die Zuordnung in demselben Objekt, das sie ausführt, was den Abstand zwischen der deklarierten und der angewendeten Regel aufhebt. Der Preis ist die Lesbarkeit: Eine im Werkzeug ausgedrückte Umformung lässt sich vom fachlichen Eigentümer schlecht abnehmen, dessen Einverständnis die Regel gleichwohl voraussetzt. Was sich bewährt, ist ein lesbarer Export des Mappings aus dem Werkzeug statt eines zweiten, von Hand geführten Dokuments.

Datenkataloge und Werkzeuge für Data Lineage halten die Zuordnung als wiederverwendbare Metadaten, mit der Spur, die jedes Feld zwischen den Systemen hinterlässt. Das DMBOK behandelt diese Nachvollziehbarkeit unter dem Metadatenmanagement. Diese Möglichkeit lohnt sich, wenn mehrere aufeinanderfolgende Projekte dieselben Systeme mappen.

Werkzeuge für Data Profiling machen in wenigen Minuten die Sentinel-Werte und die aufgegebenen Codierungen sichtbar, die keine Lektüre des Schemas zeigt.

Quellen

• IIBA, Guide to Business Data Analytics, §3.6 Data Mapping: Quelle für die beiden Anwendungen Migration und Integration, für die Arbeit auf Attributebene, für die Dimensionierungsregel des Zielattributs, für die Spalten der Spezifikation sowie für Stärken und Grenzen der Technik.
• IIBA, Guide to Business Data Analytics, §3.10 Extract, Transform, and Load (ETL): die Schritte Extrahieren, Transformieren und Laden sowie die Erzeugung der Audit-Trails der geänderten oder ersetzten Daten beim Laden.
• IIBA, Guide to Business Data Analytics, §3.4 Data Dictionary: das Datenwörterbuch als Hilfe bei der Durchführung eines Data Mappings.
• DAMA International, DAMA-DMBOK: Data Management Body of Knowledge, 2. Auflage, Kapitel 12 Metadata Management: die Datenherkunft, Ursprung eines Elements und die daran vorgenommenen Umformungen, als Gegenstand des Metadatenmanagements.
• Bundesgesetz über den Datenschutz (DSG), SR 235.1: Art. 9 zur Auftragsbearbeitung, Art. 19 zur Informationspflicht und Art. 31 zu den Rechtfertigungsgründen, zitiert für die Bekanntgabe von Produktionsauszügen mit Personendaten.