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.
Ein semantischer Graph ist ein Instrument, die reale Welt, ihre Entitäten und dere
n Beziehungen untereinander abzubilden. Auch wenn innerhalb einer Graph-Datenbank üblicherweise bestimmte Bezeichner als Identifikatoren verwendet werden, um diese für Entwickler wartungsfreundlich zu halten, so ist die Abbildung dennoch unabhängig von einer bestimmten Terminologie oder einer Sprache. Im Prinzip könnten Klassennamen auch eindeutige Identifikatoren, sogenannte UUIDs, sein. Ohne Zusatzinformation sind diese für einen Menschen in einem Modell aber schwerlich zu managen, daher können die eigentlichen Bezeichner um Anmerkungen (Annotations) bereichert werden.
Alle Entitäten, Klassen und Instanzen können eine Vielzahl davon referenzieren. Dass Annotations mit einer Länder- beziehungsweise Sprachkennzeichnung versehen werden können, lässt erahnen, wie leicht die Internationalisierung einer Graph-Datenbank ist. Alle Entitäten können mittels der Abfragesprache SPARQL auch über ihre Annotations gefunden werden.
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.
Dazu ein Beispiel: Ein Feld estimation könnte in der einen Umgebung den Aufwand in Stunden, in der anderen effort einen Aufwand in Euro bedeuten, ein Feld cost einen Betrag in Euro oder in Dollar, ein Feld time einen Zeitstempel relativ zu einem anderen oder eine Dauer, damit implizit vielleicht auch den Aufwand meinen. Bereits an diesen wenigen Termen mit ihrer Vielzahl von Mehrdeutigkeiten wird ersichtlich, wie wichtig ein Referenzmodell ist.
Derzeit stellen die meisten Datenquellen noch keine maschinenlesbaren Meta-Informationen bereit. Heterogene Daten können aber nur dann Tool-übergreifend maschinell verglichen, aggregiert oder analysiert werden, wenn ihre Bedeutung eindeutig definiert und harmonisiert ist. Beispielsweise können zwei Gewichtsangaben 0,1 und 300 aus verschiedenen Systemen nur dann sinnvoll und richtig summiert werden, wenn sowohl deren Einheiten (etwa kg und g) als auch die Umrechnungsfaktoren bekannt sind (1 kg = 1000 g) – der Unterschied im Ergebnis auf reiner Datenbasis: 300,1 oder semantisch korrekt: 400 g oder 0,4 kg.
Im Referenzmodell könnten beispielsweise die Data-Property time mit „Duration in seconds", cost mit „Amount of money to be paid" und estimate mit „Estimated duration in days" definiert sein. Dabei ist nicht entscheidend, wie die Terme in einer individuellen Domäne definiert sind, sondern dass sie definiert sind. Bei Bedarf können weitere Terme wie zum Beispiel timestamp mit „Point in time in GMT" oder timeInDays mit DurationInDays als Nachfahre vom time leicht ergänzt werden. Ein Referenzmodell lebt, sollte aber gut durchdacht und abgestimmt sein und möglichst aufwärtskompatibel bleiben.
Quelldaten stehen immer im Kontext ihrer jeweiligen Domänenmodelle und somit auch im Kontext ihrer domänenspezifischen Terminologie. Die Kunst beim Mapping der Primärdatenquellen auf ein Referenzmodell ist: einerseits Klassen, Instanzen und Properties der Domänenmodelle möglichst vollständig auf das Referenzmodell abzubilden – und zwar unter Berücksichtigung möglicher Beziehungen und ...
Abhängigkeiten untereinander – und andererseits die größtmögliche Wiederverwendung bereits im Referenzmodell bestehender Klassen und Properties. Letzteres kann bei umfangreichen Ontologien zu einer Herausforderung werden.
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).
Während ein Data Warehouse eher als ein zentrales Repository für strukturierte Daten für einen bestimmten Zweck genutzt wird, werden in einem Data Lake eher Rohdaten an einer zentralen Stelle zusammengeführt, deren Zweck und Nutzung noch nicht bestimmt ist. Bevor Daten in ein Warehouse eingestellt werden, werden diese aufbereitet und unterliegen bereits beim Schreiben einem Schema (Schema-on-Write). Was ihre Inhalte leicht verständlich macht, macht Änderungen eher aufwendig, da Konsumenten wie BI-Tools diese unmittelbar zum Beispiel für Dashboards nutzen. Zielgruppe sind daher eher Business Professionals, die mit schnellen Analyseergebnissen zur beschleunigten Entscheidungsfindung beitragen wollen.
Daten in einem Lake unterliegen keinem festen Schema, sie sind üblicherweise sehr dynamisch, ungefiltert, umfangreich und wenig organisiert. Ihre Inhalte sind leicht veränderbar, ideal für Machine Learning und für die Zielgruppe der Data Scientists, auf der anderen Seite jedoch schwerer zu verstehen. Auch Navigation, Datenqualität und Data Governance sind schwieriger. Ein Schema wird erst beim Lesen aus dem Lake angewendet (Schema-on-Read).
Der hier vorgestellte semantische SSOT-Ansatz unterscheidet sich in gleich mehreren Punkten von beiden Ansätzen. Zwar kann eine Taxonomie in Form einer reinen Klassenhierarchie und auch das Referenzmodell als eine Art Schema angesehen werden. Die Individuals – die Objekte oder Records in der Datenbankterminologie – müssen jedoch keinem bestimmten Schema folgen, weder schreibend noch lesend. Zwar kann eine Klassenzuordnung explizit für eine Instanz definiert werden, sie kann aber durch die Verwendung bestimmter Properties auch semantisch erschlossen werden, sich also implizit ergeben.
In einer SSOT werden die Properties üblicherweise mit semantischen Zusatzinformationen, den Metadaten, versehen, mithilfe von Annotations dokumentiert und von mehreren Individuals gemeinsam genutzt. So zum Beispiel die Property weight mit der zusätzlichen Angabe der Basiseinheit kg für alle materiellen Dinge als oberste Klasse. Dadurch ist das Wissen in einer SSOT sehr leicht verständlich, inhaltliche Änderungen und Erweiterungen sind einfach und Migrationen im Idealfall sogar automatisierbar.
Zudem können durch die Graph-Technologie alle Informationen miteinander verlinkt werden, was eine SSOT für Data-Analysten auf der Ebene der Abfragesprache SPARQL ebenso attraktiv macht wie für die Business Professionals auf der Ebene von High-Level-Knowledge-APIs mit entsprechenden Parametern und Sicherheitseinstellungen. Dann folgt die SSOT dem Data Hub Pattern. Das heißt, Informationen müssen nicht auf Festplatten persistiert werden, sondern können auch einfach durchgeleitet werden – ein essenzieller Aspekt, wenn es um Sicherheit und Datenschutz geht –, ohne auf die willkommenen Features der Transformationen und Validierung und damit auf ein zentrales Qualitätsmanagement verzichten zu müssen.
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.
Unabhängig von Art und Umfang der Daten sorgen Adapter zunächst für die physikalische Anbindung der Primärquellen. Dabei können die Adapter die Daten nicht nur pullen, das heißt per Programm aus vorhandenen APIs der Quelle auslesen, sondern über Hooks auch passiv auf deren Zustellung warten.
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.
Es erscheint klar, dass Informationen aus Big-Data-Quellen wie zum Beispiel Hadoop oder Elasticsearch nicht sinnvoll in einer SSOT als Schattensystem redundant vorgehalten werden. Hier unterstützt das semantische Modell in der SSOT, die richtigen On-Demand Queries an die angebundenen Systeme zu formulieren und die Daten dort aufzubereiten – diese also bei Bedarf dort zu filtern, zu aggregieren, zu gruppieren und zu sortieren und abschließend nur das gewünschte Datenextrakt in der SSOT zu verarbeiten. In den meisten Fällen werden die Big-Data-Engines die Extrakte ohnehin schneller generieren, als dies in einer SSOT möglich wäre, weil sie speziell hierfür optimiert wurden. Die Kunst besteht in der optimalen Kombination beider Technologien.
Zwar können durch On-Demand-Queries Latenzen und dadurch Performance-Nachteile auftreten. Ein intelligenter Offline-Cache zum Beispiel in MongoDB oder Redis kann diese aber wieder ausgleichen. Wer schon einmal Daten aus SAP in eine SSOT integriert hat, wird einen solchen Cache zu schätzen wissen.
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.
Während die direkte Transformation eher der Warehouse-Architektur mit einem zentralen Schema nahekommt, erinnert die Transformation über intermediäre Domänenmodelle eher an die Lake-Architektur mit voneinander unabhängigen Schemata in einer übergeordneten Datenbank.
In einer Graph-Datenbank können die Vorteile beider Ansätze aber sehr praktikabel miteinander kombiniert werden. In Bezug auf die Transformation von Rohdaten in ein semantisches Modell besteht grundsätzlich kein Unterschied, ganz gleich, ob diese zunächst in ein Domänenmodell oder direkt in das Referenzmodell übertragen werden, denn beides sind schließlich semantische Modelle, welche den gleichen Konventionen folgen.
Aus Gründen der einfacheren Wartbarkeit werden die Instanzen der verschiedenen Primärquellen häufig zunächst in separaten Graphen verwaltet. Dies ermöglicht es, die Inhalte bestimmter Quellen leicht en gros aus der Graph-Datenbank zu entfernen, sie neu zu importieren oder unabhängig von anderen zu verarbeiten. Seiteneffekte können so komfortabel vermieden werden.
SPARQL erlaubt Abfragen gegen mehrere Graphen innerhalb einer Query. Das macht es leicht, eine Ergebnismenge über mehrere Quellen in einem Result-Set zusammenzufassen. Da die Domänenmodelle ja auch bereits semantischen Definitionen unterliegen, ist die Integration von Informationen aus mehreren semantischen Domänenmodellen sehr einfach. Es gibt daher große Knowledge-Graphen, die über kein zentrales Referenzmodell verfügen, sondern die die Datenharmonisierungen ausschließlich über SPARQL-Queries abwickeln – eins der Paradigmen des Semantischen Webs.
Ein weiteres Argument für vorgeschaltete Domänenmodelle ist die einfachere Identifikation möglicher Inkonsistenzen zwischen ihnen. Finden sich im Domänenmodell ERP Kunden aus Aufträgen, die im Domänenmodell CRM nicht vorhanden ist, so kann dies mit SPARQL sehr leicht herausgefunden und ausgewiesen werden.
Nicht zuletzt sind unabhängige Domänenmodelle vorteilhaft, wenn Updates an den Primärquellen durchgeführt und Migrationen erforderlich werden. In diesen Fällen müssen nur die Domänenmodelle und die involvierten SPARQL-Queries angepasst werden. Die anderen Modelle und Instanzen bleiben davon unberührt – ein wichtiger Aspekt für die Verfügbarkeit einer SSOT im operativen Betrieb.
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.
Letztlich kommt es darauf an, eingehende Daten in Tripel zu zerlegen und diese mithilfe von SPARQLs INSERT-Kommandos in die Graph-Datenbank einzustellen, wahlweise in den Graphen eines Domänenmodells oder direkt in den des Referenzmodells.
Eine bewährte Praxis ist dabei, sich auf ein intermediäres Format zwischen dem Datenformat der Primärquelle und den Tripeln zu verständigen. Fast alle Programmiersprachen beherrschen JSON und XML für strukturierte beziehungsweise hierarchisch organisierte Daten. Wenn ausschließliche flache Strukturen vorkommen, kann CSV eine weitere Option sein. Sinn des Zwischenformates ist eine breite Unterstützung durch bestehende Tools und Libraries sowie die Möglichkeit, die Umwandlung in die RDF/OWL-Tripel nur einmalig zentral umsetzen zu müssen. JSON hat sich hier als ein einfaches, etabliertes und breit unterstütztes Format bewährt.
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 wenn in komplexen Umgebungen Primärsysteme einmal offline sind oder diese ohne Abstimmung mit anderen Parteien aktualisiert werden, kann mit einem Offline-Cache noch immer eine Zeit lang weitergearbeitet werden und die Verfügbarkeit der SSOT bleibt erhalten.
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.
Für gute Reports und Leistungskennzahlen werden gute Daten benötigt, was dem Datenqualitätsmanagement einen hohen Stellenwert gibt. Arbeiten viele Personen gleichzeitig an zentralen Daten, so können diese zentral synchronisiert und Kollegen mittels Subscriptions sofort über Änderungen informiert werden.
Werden Änderungen an Daten vorgenommen, kann eine Single Source of Truth nicht nur ein Versionskontrollsystem hierfür bereitstellen oder Abhängigkeiten verwalten, son- dern auch abteilungsübergreifende Abstimmungs- oder ap- plikationsübergreifende Approval-Prozesse anstoßen. Sie kann zentrale Audits unterstützen, Informationen können mit Labels zur Indizierung oder mit Attachments für Zusatz- und Detailinformationen versehen werden.
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.
Die Abfragesprache SPARQL liefert die Ergebnisse als ein- fach strukturierte Result-Sets im Spalten- und Zeilenformat zurück. Diese können in jedes erdenkliche Datenformat transformiert werden, beispielsweise JSON, XML, CSV oder
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 einen ist sie eine (optionale) zusätzliche Prüfebene, die sicherstellt, dass die Übergabe an das Zielsystem mög- lichst fehlerfrei erfolgt. Gerade in komplexen heterogenen Tool-Umgebungen arbeiten unterschiedliche Entwickler an den diversen SSOT-Services. Wird zum Beispiel nach einem Modell-Update eine der Transformationen angepasst, so kann die Outbound-Validierung einen Import im Fehlerfalle zurückweisen und so Folgefehler im Zielsystem vermeiden. Sie ist damit also eine Art finale Test- und Qualitätssiche- rungsinstanz.
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.
Für ein Pulling durch die Konsumenten können dies zum Beispiel REST- oder JSONP-APIs sein, ebenso gut aber auch Message-Queues oder Fileshares für CSV/TSV oder sogar Excel-Dateien.
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.
Während es für Tableau eher geeignet ist, umfangreiche Datenmengen bereitzustellen – gegebenenfalls sogar in SQL- oder NoSQL-Puffern –, die dann interaktiv in Dashboards im Tool selber gefiltert oder aggregiert werden, wird eine reine Chart-Engine meist nur mit genau den Daten beliefert, die für eine gerade gewünschte Visualisierung erforderlich sind. Denken Sie zum Beispiel an die Anpassung von Zeitstempeln in lesbare Datumsangaben oder an geglättete Durchschnitts- linien – Transformationen und Berechnungen, die praktika- blerweise nicht auf Datenbank-, sondern auf Anwendungs- ebene durchgeführt werden. Als praktisch erweist sich hier der Einsatz von serverseitigem JavaScript. Ein Post-Proces- sing-Skript kann einen JSON-Datensatz aus der SSOT sehr leicht vor der Auslieferung mit zusätzlichen Informationen bereichern oder spezielle Berechnungen durchführen. Zu- dem kann JavaScript einfach zur Laufzeit modifiziert werden, was nötige Anpassungen sogar mit unterbrechungsfreier Verfügbarkeit des Gesamtsystems ermöglicht.
In bestimmten Fällen kann es notwendig sein, erst in der Ergebnismenge für ein bestimmtes Ziel weitere Daten hinzu- zufügen, die nicht in der Single Source of Truth selber ver- waltet werden sollen – oder dürfen. Gründe hierfür können zum Beispiel Unternehmens- oder Security-Policies oder auch gesetzliche Restriktionen sein: aus Unternehmenssicht zum Beispiel der Schutz geistigen Eigentums, aus Kunden- sicht der Schutz von Zahlungsinformationen, oder aus Mitar- beiter- und juristischer Sicht das Arbeitnehmerrecht oder die Regelungen der DSGVO.
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“.
Eine entsprechende Herausforderung stellt ein Access- Control-System für einen Graphen dar, hauptsächlich deswe- gen, weil keine Schemata vorgeschrieben sind, wegen der Mehrfachvererbung, weil alles mit allem verlinkt sein kann und auch weil identische Properties zwischen einer Vielzahl unterschiedlicher Individuen geteilt werden können. Ge- wünschte und willkommene Features für den Smart-App-
Filter als Abfrageparameter und vor allem unterliegt sie kon- figurierbarer Zugriffskontrolle.
In einer Single Source of Truth können wir mithilfe einer sogenannten Facade ein vergleichbares Konzept nutzen, aber noch einen Schritt weiter gehen. Semantische Graph- Datenbanken heben sich insbesondere durch ihre Fähigkeit, Metadaten zu verarbeiten, von anderen Datenbanken ab, al- so durch die Fähigkeit, Informationen über die Daten selbst preiszugeben.
Der Zugriff auf die Knowledge Base erfolgt also üblicher- weise nicht direkt via SPARQL, sondern über die Facade. Die- se liest die im Graphen gespeicherte Liste von Views und de- ren Parameter und Zugriffsberechtigungen aus. Jede App kann so selbst feststellen, welche APIs ihr beziehungsweise dem Konsumenten bereitstehen.
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.
Wissen wird zentral verfügbar und wiederverwendbar, Redundanzen entfallen, Abhängigkeiten und Inkonsistenzen werden aufgedeckt, es entsteht Transparenz und bessere Planbarkeit. Die Datenqualität wird verbessert, Betriebs-, Wartungskosten und Infrastrukturkosten sinken.
Sicher müssen bestehende Datenbanksysteme nun nicht unmittelbar umgestellt werden, doch eine nähere Betrach- tung, wo eine semantische Single Source of Truth konkret un- terstützen kann, lohnt sich sicher. Wir werden Sie hier mit weiteren Einblicken in diese Technologien auf dem Laufenden halten. ■
Author: Alexander Schulze, published October 2019