Semantisches Referenzmodell

...

Mit semantischen Graph-Datenbanken heterogene Datenquellen harmonisieren.

Nachdem im vorangegangenen Artikel die Herausforderungen im Umgang mit großen Datenmengen diskutiert und das semantische Mapping als eine Lösungsmöglichkeit präsentiert wurde [1], folgt nun ein Referenzmodell für eine Graph-Datenbank.

...

Soll zum Beispiel ein Produkt in einer Handelsplattform über seinen Namen gefunden werden, so können Annotations verwendet werden, um unterschiedliche Schreibweisen für das gleiche Produkt zu unterstützen, ohne Einfluss auf die Relationen oder die Semantik des eigentlichen Datensatzes zu nehmen. Erwähnenswert ist die Klassenäquivalenz in semantischen Graph-Datenbanken. Definieren Sie beispielsweise, dass die Klassen Error, Bug und Defect äquivalent sind, so wird eine Abfrage aller Instanzen der Klasse Error auch alle Instanzen der Klassen Bug und Defect zurückliefern – wohlgemerkt mithilfe einer einzelnen und zentralen Äquivalenzdeklaration und nicht pro individueller Query oder gar pro Instanz.

Mapping im Referenzmodell

Während ein Mapping von Quelldaten auf ein zentrales Schema in einem Data Warehouse in erster Linie per Programm oder deklarativ auf Ebene der Daten erfolgt, unterliegt es in einer semantischen Single Source of Truth (SSOT) semantischen Konventionen. Für eine einheitliche, harmonisierte Verarbeitung von Inhalten ist eine gemeinsame Terminologie erforderlich.

...

Sollen weitere Datenquellen in eine bestehende SSOT integriert werden, wird idealerweise zunächst das Referenzmodell semantisch sinnvoll erweitert und dann das Mapping darauf aufgesetzt. Müssen neue Klassen oder Properties angelegt und in die Struktur des Referenzmodells integriert werden, so sollten diese immer sofort klar definiert und dokumentiert und eine eventuelle Äquivalenz mit anderen Entitäten spezifiziert werden, um Mehrdeutigkeiten von Beginn an zu vermeiden. Je mehr Ambiguitäten in einem Referenzmodell auftreten, umso weniger effektiv ist dies in Bezug auf eine Harmonisierung.

...

Abgrenzung Datenbankarchitekturen

Bei der Zusammenführung von Daten kommen unweigerlich die Begriffe Data Warehouse und Data Lake ins Spiel. Beide Ansätze unterscheiden sich in verschiedenen Aspekten von einer Single Source of Truth (SSOT).

...

Lassen Sie uns also einen Blick auf die Architektur einer SSOT werfen (Bild 1).

Inbound-APIs

Der Weg der Daten in eine SSOT beginnt beim Transport von den Primärquellen in den Hub. Es wird hier bewusst nicht der Term „Import" verwendet, da dieser eine Persistenz assoziiert, die in einem Hub nicht unbedingt stattfindet, da dieser die Daten ja gegebenenfalls lediglich durchleitet.

...

Unterstützt der Hub auch eine Push-Zustellung, so können neben einem automatisierten termin- und intervallgesteuerten Abruf über klassische APIs wie zum Beispiel REST, JSONP oder SOAP auch leicht Systeme integriert werden, die ihre Daten per FTP, SFTP, Message-Queues oder per Filesharing bereitstellen, mit Event- oder File-Monitoring-Mechanismen, exakt zu dem Zeitpunkt, zu dem sie von der Primärquelle geliefert werden.

Import und Persistenz versus On-Demand-Queries

Der Hub-Charakter der SSOT überlässt – anders als bei einem Data Warehouse – dem Betreiber die Entscheidung, Daten zu importieren und zu persistieren, oder diese nur an die Konsumenten durchzuleiten. Beides hat Vor- und Nachteile.

...

Ein Vorteil der Persistenz von Informationen innerhalb der SSOT ist, dass alle Detailinformationen an zentraler Stelle vorliegen. Während aggregierte und gefilterte On-Demand-Daten externer Quellen nicht ohne zusätzliche Abfragen weiter aufgeschlüsselt werden können, sondern neu angefragt werden müssen, zum Beispiel für Drill-down-Reports, können alle in der Graph-Datenbank persistierten Informationen mit vergleichsweise einfachen SPARQL-Queries beliebig miteinander verlinkt und in Beziehung zueinander gesetzt werden – ein entscheidender Aspekt, gerade wenn die Integration verschiedener Datenquellen in Dashboards mit intensiven Benutzerinteraktionen einhergeht.

Referenzmodell versus Domänenmodelle

Sind die Rohdaten aus den Primärquellen an der SSOT angekommen, so können sie wahlweise direkt in das Referenzmodell oder zunächst in ein domänenspezifisches Modell innerhalb der Graph-Datenbank transformiert und dieses dann wiederum gegen das Referenzmodell gemappt werden.

...

Domänenmodelle stehen jedoch nicht im Wettbewerb zu einem Referenzmodell, sondern sie nutzen dieses. Die zuvor in diesem Artikel diskutierte Klasse Priorität ist sinnvollerweise Teil des Referenzmodells. Mit SPARQL wird dieses zum Beispiel als zentrale Definition für das Ausgabeformat genutzt und die Inhalte der betreffenden Domänenmodelle „on the fly" darauf gemappt.

Inbound-Transformation

Die eigentliche Transformation von Rohdaten eines bestimmten Formats in ein semantisches Modell ist eine eher technische als eine semantische Aufgabe. Die Herausforderung ist hier in erster Linie die Umsetzung einer Vielzahl verschiedener Datenformate, die in den Primärquellen vorkommen können.

...

Die Belieferung der SSOT mit Daten aus den Primärquellen kann auf unterschiedlichste Art und Weise erfolgen. Dies können Direktzugriffe auf SQL- oder NoSQL-Datenbanken sein, Schnittstellen zu Big-Data-Services wie SAP4 HANA, Hadoop oder Elasticsearch, Dateien wie Excel, im CSV-, TSV- oder JSON-Format oder auch REST- und SOAP-APIs, vielleicht Message-Queues oder Log-Files oder natürlich auch externe Wissensdatenbanken und Ontologien im Web (Bild 2).

Mapping-Adapter

Viele zu einer Transformation nötigen Operationen können bereits einfache Mapping-Tabellen und konfigurierbare Umwandlungsfunktionen übernehmen, zum Beispiel für Feldnamen, Datumsangaben, String- oder Zahlen-Konvertierungen. Dort aber, wo spezifische oder komplexere Transformationen durchgeführt werden müssen, helfen sogenannte Mapping-Adapter.

Diese empfangen die Rohdaten im Format der Primärquelle und wandeln diese in das intermediäre Format um, hier JSON. Hilfreich ist dies dort, wo Quelldaten aufbereitet oder Informationen schon auf Basis der Quelldaten zusammengeführt oder umgewandelt werden müssen, beispielsweise lokale Zeitzonen-Anpassungen in UTC/GMT-Formate, spezielle Encodings nach UTF8 oder spezielle Mappings mithilfe manueller Hilfs- oder Cross-Reference-Tabellen.

Inbound-Validierung

Die erste Stufe der Qualitätssicherung in einer Single Source of Truth findet bereits beim Import statt. Nachdem die Rohdaten in das Zwischenformat transformiert wurden, prüft eine nachgeschaltete Ebene im Software-Stack die Daten auf Vollständigkeit und Gültigkeit gemäß den domänenspezifischen Regeln – auf dieser Ebene also noch nicht gegen das Referenzmodell.

So kann es zum Beispiel vorkommen, dass Primärsysteme bei einem Download-Versuch nicht erreichbar sind oder Daten aufgrund von Fehlern unvollständig geladen wurden. Praktisch ist im Fehlerfalle auch, bereits beim Import eine Benachrichtigung an den Eigentümer der Daten abzusetzen, dass eine Korrektur erforderlich ist. Die Inbound-Validierung verhindert somit, dass invalide Daten überhaupt erst die SSOT erreichen, wodurch etwaige Folgefehler vermieden werden.

Offline-Cache

Eine besondere Herausforderung entsteht, wenn Primärsysteme nicht über historische Daten, auswertbare Log-Files oder Audit-Trails verfügen und nur Snapshots über ihren aktuellen Status bereitstellen. In diesem Fall sind Reports über Zeiträume oder Trendanalysen ohne weitere Hilfsmittel nicht möglich. Eines dieser Hilfsmittel ist ein Offline-Cache. Dieser sichert die Snapshots in regelmäßigen Intervallen und kann so eine Historie simulieren.

...

Auch aus Performancegründen ist ein Offline-Cache nütz- lich. Benötigen die Anfragen an ein Primärsystem beispiels- weise sehr lange oder belasten diese die Systeme derart, dass häufige Anfragen der SSOT zu Leistungseinbußen für deren Benutzer führen, so können die benötigten Daten komforta- bel und schnell aus dem Cache gezogen werden. Bei vielen Reports ist häufig gar keine Echtzeitaussage erforderlich, so- dass eine Aktualisierung des Offline-Caches zum Beispiel auf Tagesbasis das Gesamtsystem erheblich entlasten kann.

...

Zentrale Services

Ganz allgemein ist ein großer Vorteil der Zusammenführung von Daten an einer zentralen Stelle, dass viele Services nicht mehr mehrfach pro Datenquelle, sondern nur noch einmal, nämlich zentral in der SSOT, umgesetzt werden müssen.

...

Ein zentrales Zugriffskontrollsystem über Rechte und Rol- len oder Policies regelt dabei, wer wie auf welches Wissen in der SSOT zugreifen oder dieses verändern darf. Die SSOT wird so nicht nur zu einem wertvollen Wissens-Hub und Enterprise-Asset, sondern auch zu einem effektiven Kollabo- rationsinstrument.

Outbound-Transformation

Die Outbound-Transformation dient der Bereitstellung har- monisierter Daten an ihre Konsumenten. In einer semanti- schen Single Source of Truth liegen die Informationen als RDF-Tripel vor. Damit diese von den Zielsystemen wie zum Beispiel BI-Tools verarbeitet werden können, müssen sie wie- der in ein unterstütztes Datenformat transformiert werden. Ähnlich wie bei der Inbound-Transformation helfen hier auch wieder entsprechende Adapter.

...

TSV. Kundenspezifische Formate können leicht über eigene Adapter, meist als Plug-ins, umgesetzt werden.

Outbound-Validierung

Die letzte Stufe vor der Auslieferung von Ergebnismengen an die Konsumenten ist die ausgehende Validierung. Bei den umfangreichen Prüfungen und Maßnahmen zur Datenquali- tät in der SSOT stellt sich die Frage, wozu eine Outbound- Validierung?

...

Zum anderen ist sie eine wichtige zusätzliche Sicherheits- instanz. Unabhängig von allen vorgelagerten Software-Ebe- nen und etwaiger dortiger Fehler oder Manipulationen durch Angriffe können hier finale Prüfungen auf sensible Daten durchgeführt werden, die keinesfalls an Konsumenten aus- geliefert werden dürfen – kombiniert mit entsprechenden Benachrichtigungsmaßnahmen ein willkommener Schutz ge- gen Datenlecks.

Outbound-APIs

Nach Outbound-Transformation und -Validierung sind die Daten inhaltlich für die Auslieferung an den Konsumenten bereit. Für den Transport an die Zielsysteme stehen nun die Outbound-APIs zur Verfügung.

...

Stellen die Konsumenten Hooks, also ihrerseits Upload- APIs bereit, so kann die SSOT Ergebnisse auch aktiv pushen. Hierzu kann das Outbound-API mit einem Scheduler verse- hen werden, um Auslieferungsprozesse zu automatisieren. Geht es um größere Datenmengen, so können diese zunächst in SQL- oder NoSQL-Datenbanken als Vermittlungsinstan- zen gepusht werden – sinnvoll dort, wo in BI-, Charting- oder Reporting-Tools lediglich Standardkonfigurationen wie JDBC/ODBC unterstützt werden, oder dort, wo aus Sicher- heitsgründen ausschließlich zertifizierte Out-of-the-Box-Ad- apter und keine manuellen Implementationen eingesetzt werden dürfen.

Customized Post-Processing

Eine Motivation zur Einführung einer SSOT ist es, ein Tool- übergreifendes Reporting zu ermöglichen und mit abtei- lungsübergreifenden Key-Performance-Indikatoren (KPIs) zentrale Geschäftsentscheidungen zu unterstützen. Im Front- end kann dies auf unterschiedliche Art und Weise realisiert werden. Zum Beispiel könnten BI-Tools wie Tableau oder Power BI zum Einsatz kommen, alternativ eine eigene Web-App mit einer Chart-Engine. Beide Frontends haben unterschied- liche Anforderungen.

...

Je nach Notwendigkeit kann das Post-Processing daher in einem separaten Prozess innerhalb der SSOT-Plattform, auf einem separaten System oder sogar erst auf dem Zielsystem selber stattfinden. Wichtig ist, die Prozesse möglichst unab- hängig voneinander zu realisieren, wozu sich Cloud-basierte Micro-Service-Strukturen besonders eignen.

Sicherheit

Im Gegensatz zu traditionellen SQL- oder NoSQL-Datenban- ken liegen in einer Graph-Datenbank die Informationen nicht als Tabellen oder Kollektionen, Zeilen und Spalten oder Do- kumente vor, sondern als eine Vielzahl von untereinander re- ferenzierenden Tripeln, eben als „linked information“.

...

Ferner können die Parameter, die der Aufruf erfordert, an- gefragt werden. Somit kann die App auch bei sich ändernden Anforderungen oder Möglichkeiten dynamisch reagieren. Beispielsweise in einem Reporting-System automatisch alle Filter anbieten, die ein API-Request zur Auswahl anbietet.

Fazit

Die semantische Single Source of Truth kombiniert eine Viel- zahl positiver Eigenschaften bestehender Datenbanksysteme und -architekturen: Sie bereichert Daten mit Bedeutung und schafft die Basis für deren gemeinsames Verständnis, und da- mit nicht nur für eine bessere Kommunikation und effiziente- re Zusammenarbeit zwischen den Menschen, sondern eben- so für eine höhere Interoperabilität und einen leichteren Aus- tausch von Informationen zwischen den Systemen.

...