Data Sets und Export in Ataccama MDM
Ataccama bietet mehrere Möglichkeiten, Daten aus dem Master Data Management (MDM)-System für nachgelagerte Anwendungen, Analysen oder externe Systeme bereitzustellen. Zwei häufig verwendete Ansätze sind Data Sets und Export Operations.
Beide Funktionen verfolgen das Ziel, Daten aus dem MDM-Modell bereitzustellen und für externe Verbraucher zugänglich zu machen. Sie unterscheiden sich jedoch hinsichtlich Architektur, Flexibilität, Konfigurationsaufwand, Performance und Wartbarkeit.
Data Sets stellen eine standardisierte, direkt integrierte Möglichkeit dar, MDM-Daten bereitzustellen. Sie eignen sich insbesondere für Szenarien, in denen aktuelle Daten für Reporting, Analyse oder einfache Integrationen benötigt werden.
Export Operations hingegen bieten einen technisch flexibleren Ansatz zur Datenextraktion. Sie ermöglichen eine stärkere Kontrolle über Datenquellen, Exportformate und nachgelagerte Verarbeitungsschritte.
Im Folgenden werden beide Ansätze anhand relevanter Kriterien gegenübergestellt.
Technische Details zur Konfiguration und Nutzung von Data Sets und Export Operations sind in der offiziellen Ataccama-Dokumentation beschrieben:
- Data Sets: Configuring Data Sets :: ONE MDM
- Export Operations: Creating an Instance Layer Model :: ONE MDM
- Instance Layer Model: Creating an Instance Layer Model :: ONE MDM
- Connecting a system: Connecting a System :: ONE MDM
- MDM REST APIs: REST API :: ONE MDM
- Full Load Processing: Full Load Operation :: ONE MDM
- Configuring Permissions: Configuring Permissions :: ONE MDM
Vorteile von Export Operations
Flexibilität bei Datenquellen und Datenbereitstellung
Export Operations können verschiedene Datenquellen in einem einzigen Exportprozess kombinieren. Neben MDM-Daten lassen sich auch Flat Files, Referenzdaten (RDM) oder Ergebnisse von REST-API-Abfragen einbinden. Dadurch können Daten aus unterschiedlichen Quellen gezielt miteinander verknüpft werden.
Zusätzliche Quellen können beispielsweise genutzt werden, um MDM-Daten über Lookups anzureichern oder den Exportprozess anhand externer Werte zu steuern. Das Ergebnis kann anschliessend flexibel bereitgestellt werden, zum Beispiel als Flat File in unterschiedlichen Speicherorten oder direkt in einer Datenbanktabelle.

Flexible Strukturierung der Exportdaten
Ein weiterer Vorteil ist die flexible Gestaltung der Ausgabe. Attribute können gezielt umbenannt werden. Dadurch können sowohl technische Feldnamen als auch geschäftsorientierte Bezeichnungen verwendet werden. Dies erleichtert die Integration in externe Systeme mit spezifischen Namenskonventionen.
Hohe Performance bei Datenextraktion
Darüber hinaus bieten Export Operations eine hohe Performance bei der Datenextraktion. Sie greifen direkt auf die zugrunde liegenden Datenquellen zu und benötigen keine zusätzlichen Abstraktionsschichten. Dadurch sind sie in der Regel sehr performant.
Dies ist insbesondere bei grossen Datenmengen oder regelmässigen Exportläufen ein wichtiger Vorteil.
Wiederverwendbarkeit von Exportdaten und Bereitstellung über REST APIs
Ein weiterer wichtiger Vorteil ist die Möglichkeit, die Ergebnisse einer Export-Operation wieder in das MDM-System zurückzuführen. Hierzu wird eine neue Entität im Instance Layer erstellt, die den Export als Datenquelle nutzt.
Über einen Full-Load-Prozess wird die Exportdatei erneut in das MDM geladen. Dadurch können die aufbereiteten Daten wieder in das System geladen und für weitere Prozesse genutzt werden.
Darüber hinaus stehen die exportierten Daten als Instance-Entität im MDM über die standardisierten REST APIs der Plattform zur Verfügung. Dies bietet mehrere Vorteile:
- Nutzung der bestehenden Authentifizierungs- und Berechtigungskonzepte
- Direkter API-Zugriff ohne zusätzliche Schnittstellenentwicklung
- Einheitliche Datenbereitstellung für unterschiedliche Konsumenten und Anwendungen

Nachteile von Export Operations
Hoher Implementierungs- und Wartungsaufwand
Export Operations erfordern mehrere Komponenten, darunter Exportprozesse, Full-Load-Prozesse, Workflows und optional Scheduler. Dadurch entsteht im Vergleich zu Data Sets ein deutlich höherer Aufwand bei der Entwicklung.
Auch im Betrieb steigt die Komplexität, da mehrere voneinander abhängige Prozesse koordiniert und gewartet werden müssen.
Zusätzlich sind Export Operations eng an die Struktur der zugrunde liegenden Entitäten gekoppelt. Änderungen am Datenmodell können bestehende Mappings ungültig machen. In diesem Fall müssen die Exportprozesse angepasst werden.
Das kann insbesondere in kollaborativen Entwicklungsumgebungen zu Problemen führen. Erweitert beispielsweise ein Entwickler eine Entität, werden bestehende Export-Mappings nicht automatisch aktualisiert.
Dadurch können Felder fehlen oder Validierungsfehler auftreten. Im schlimmsten Fall funktionieren die Exportprozesse nicht mehr. Der Wartungsaufwand steigt dadurch zusätzlich.
Kein Wechsel des Export-Typs bei Erweiterung der MDM-Datenquellen
Bei Standard-Export-Operationen ist die Auswahl der Datenquellen auf den konfigurierten Entity-Typ ausgerichtet. Wird beispielsweise ein Export für Master-Entitäten erstellt, können weitere Master-Entitäten hinzugefügt werden. Instance-Entitäten lassen sich dagegen nicht nachträglich in denselben Export aufnehmen.
Wenn sowohl Master- als auch Instance-Entitäten benötigt werden, muss ein Complex Export verwendet werden. Dafür ist eine entsprechende Neukonfiguration erforderlich.
Keine automatische Datenaktualisierung
Export Operations aktualisieren die Daten nicht automatisch. Die Aktualität hängt daher von der Ausführung der Orchestrierung ab.
Wenn beispielsweise kein Scheduler vorhanden ist oder der Prozess fehlschlägt, bleiben die Daten auf dem Stand des letzten erfolgreichen Exports. Dadurch können veraltete Daten entstehen, ohne dass dies sofort sichtbar ist.
Vorteile von Data Sets
Geringer Implementierungsaufwand
Data Sets lassen sich schnell erstellen, da keine zusätzlichen Prozesse wie Export- oder Load-Jobs notwendig sind. Dadurch werden Entwicklungszeit und Komplexität deutlich reduziert.
Zudem werden die zugrunde liegenden SQL-Abfragen auf Basis des logischen Datenmodells automatisch generiert. Beziehungen zwischen Entitäten und erforderliche Join-Bedingungen müssen daher in vielen Fällen nicht manuell definiert werden.
Dadurch sinken sowohl der Entwicklungsaufwand als auch das Fehlerrisiko.

Bereitstellung von Live-Daten
Data Sets greifen direkt auf das MDM-Datenmodell zu und liefern dadurch stets aktuelle Daten. Es entsteht kein Zeitverzug durch Batch- oder Exportprozesse.
Einfache Architektur ohne zusätzliche Orchestrierung
Data Sets benötigen im Gegensatz zu Export Operations keine zusätzlichen Workflows oder Scheduler. Dadurch entfällt der Aufwand für die Prozesssteuerung und die regelmässige Aktualisierung.
Da insgesamt weniger Komponenten beteiligt sind, bleibt die Architektur übersichtlich. Änderungen können in der Regel direkt am Data Set vorgenommen werden.
Dadurch sinkt der Implementierungs- und Wartungsaufwand.
Integrierte Zugriffskontrolle bei Data Sets
Data Sets lassen sich direkt in das rollenbasierte Berechtigungskonzept des MDM-Systems integrieren. Der Zugriff auf die bereitgestellten Daten kann über die MDM-Schicht gesteuert werden. Dabei werden die bestehenden Authentifizierungs- und Berechtigungsmechanismen der Plattform verwendet.
Im Gegensatz dazu bieten die direkten Ergebnisse von Export Operations, beispielsweise CSV-Dateien, keine integrierte Zugriffskontrolle.
Der Zugriff muss daher in der Regel über externe Mechanismen wie Dateisystemberechtigungen oder zusätzliche Infrastrukturkomponenten abgesichert werden. Eine rollenbasierte Berechtigungssteuerung in Ataccama ist erst möglich, wenn die Exportdaten wieder als Instance-Entität in das MDM geladen werden.

Nachteile von Data Sets
Eingeschränkte Anpassung von Feldnamen
Data Sets übernehmen standardmässig die Struktur des Datenmodells. Eine gezielte Umbenennung von Feldern ist nur eingeschränkt möglich, wodurch es zu Abstimmungsaufwand mit Konsumenten kommen kann.
Keine Datenhistorie
Data Sets liefern immer den aktuellen Datenstand. Historisierung oder Snapshot-basierte Analysen sind nicht möglich.
Im Gegensatz dazu können Export Operations Datenstände speichern und als eigene Entitäten persistieren.
Performance-Probleme bei grossen Datenmengen
Bei komplexen Abfragen oder grossen Datenmengen kann es zu langen Ladezeiten kommen. Dies gilt insbesondere für die Benutzeroberfläche.
Keine standardisierte REST-API-Bereitstellung
Data Sets sind nicht automatisch über standardisierte REST APIs verfügbar. Daher können zusätzliche Implementierungen notwendig sein, wenn externe Systeme auf die Daten zugreifen sollen.
Probleme bei SQL Overrides und Modelländerungen
Ein kritischer Nachteil betrifft SQL Overrides. Nach Modelländerungen können diese inkonsistent werden. In bestimmten Fällen kann dies sogar den Start des MDM-Servers verhindern, da Data Sets beim Deployment validiert werden.
Begrenzte Eignung für komplexe Integrationen
Data Sets sind hauptsächlich für einfache Datenbereitstellung gedacht. Für komplexe Integrationen, Datenhistorisierung oder mehrstufige Prozesse sind sie nur eingeschränkt geeignet.
Schlussfolgerung
Data Sets und Export Operations verfolgen unterschiedliche Ansätze zur Datenbereitstellung im MDM-Kontext.
Data Sets eignen sich insbesondere für:
• schnelle Bereitstellung von Live-Daten
• geringe Implementierungs- und Betriebskomplexität
• einfache Reporting- und Analyseanforderungen
• explorative Datenanalyse und schnelles Prototyping
Export Operations eignen sich hingegen besonders für:
• komplexe Integrationsszenarien
• hohe Flexibilität bei Datenquellen und Formaten
• Datenhistorisierung und Wiederverwendung
• API-basierte Bereitstellung über modellierte Entitäten
• performante Verarbeitung grosser Datenmengen
Darüber hinaus können Data Sets in der Praxis als Vorstufe für die Entwicklung von Export Operations verwendet werden. Sie ermöglichen eine schnelle Prüfung von Datenstrukturen, verfügbaren Feldern und Datenmengen direkt im MDM-System.
Dadurch kann früh geprüft werden, ob die fachlichen Anforderungen korrekt abgebildet sind. Gleichzeitig lassen sich mögliche technische oder Performance-Probleme früh erkennen. Dies unterstützt eine präzisere Spezifikation und reduziert das Risiko von Anpassungen in späteren Entwicklungsphasen.
Zusammenfassend hängt die Entscheidung zwischen beiden Ansätzen stark davon ab, worauf der Fokus liegt: auf einer einfachen Datenbereitstellung mit Data Sets oder auf Kontrolle, Integration und Erweiterbarkeit mit Export Operations.
Architekturdiagram


