Datenmapping ohne Albtraum: Canonical Model & Transformation.
Datenmapping ohne Albtraum: Canonical Model und Transformation
Wenn zwei Systeme reden, sprechen sie meistens verschiedene Sprachen. Das Mapping ist der Übersetzer.
Das Problem
System A nennt es customerId. System B nennt es client_id. System A hat eine Adresse als flaches Objekt. System B hat sie als verschachteltes Objekt mit separaten Zeilen. System A kennt keine Mehrwährung. System B schon.
Das klingt einfach. Wird aber schnell komplex, wenn 5 Systeme beteiligt sind und jedes seine eigenen Datenstrukturen hat.
Canonical Data Model
Das Canonical Model ist ein zentrales, neutrales Datenmodell, auf das alle Systeme mappen. Statt n×m Mappings (jedes System mappt auf jedes andere) gibt es nur n Mappings (jedes System mappt auf den Canonical).
Das spart Komplexität – besonders wenn Systeme hinzukommen oder wegfallen.
Transformation: Wo die Logik hingehört
Nicht in den Empfänger und nicht in den Sender. In eine dedizierte Mapping/Transformation-Schicht. Das können Bibliotheken sein (AutoMapper, bespoke PHP-Mapper), oder ein Integration-Layer (Apache Camel, n8n, eigene Middleware).
Umgang mit fehlenden Werten
Was passiert, wenn das Quellsystem ein Feld nicht liefert, das das Zielsystem erwartet? Null? Default-Wert? Fehler? Das muss für jedes Mapping-Feld explizit definiert sein – nicht implizit angenommen.
Checkliste Datenmapping
Datenstrukturen beider Systeme vollständig dokumentiert
Canonical Model definiert (wenn > 2 Systeme beteiligt)
Mapping-Tabelle für alle Felder (inkl. Umgang mit fehlenden Werten)
Transformation-Tests mit echten Daten
Edge Cases dokumentiert (null, leer, unerwartete Werte)
Datenmapping-Konzept für eure Integration?
markom.digital konzipiert und implementiert Datenmappings – auch für komplexe Systemlandschaften.
