Business News 3-2017 | 5

Predic t ive Analyt ics

Verborgenes sichtbar machen: Visuelle Analyse komplexer Daten am Beispiel der Panama PapersDr. Thorsten Liebig, derivo GmbH, und Karin Patenge, ORACLE Deutschland B.V. & Co. KG

Komplex vernetzte Datenbestände sind schwer zu durchschauen, tauchen aber an geschäftskritischen Stellen überall auf. Der Artikel zeigt die Herausforderungen dieser Aufgabe und bietet einen Lösungsweg, um semantische Methoden mit einer innovativen Visualisierung zu verzahnen.

chen Fragen aufgrund fehlender Übersicht nicht auf der Hand liegen? Wie lassen sich beispielsweise in den Panama Papers die Be-günstigten einer Offshore-Unternehmung leicht finden, wenn deren Beteiligung be-wusst über Strohmänner und indirekte Be-teiligungen verschleiert ist?

Derartige Zusammenhänge in kompli-zierten, womöglich verteilten Datenbe-ständen aufzudecken, stellt eine Herausfor-

derung dar. Dabei soll nicht der Eindruck entstehen, dass eine passende SQL-Abfrage oder das richtige BI-Dashboard keine wert-volle Informationen liefern können. Der kritische Punkt besteht oftmals darin, die richtigen Ideen für die aufschlussreichen Fragestellungen zu bekommen – insbeson-dere dann, wenn die zugrunde liegenden Daten oder das Datenschema nicht in allen Facetten bekannt sind.

Data Analytics im Unternehmen hat das Ziel, geschäftsrelevante Informationen auf-zuspüren, um begründete Schlüsse für un-ternehmerische Entscheidungen zu liefern. Klassische BI-Werkzeuge sind in diesem Zusammenhang dann hilfreich, wenn man die Struktur der Daten und seine Fragestel-lungen ausreichend kennt. Wie aber geht man vor, wenn der Datenbestand groß und komplex vernetzt ist und die aufschlussrei-

Predic t ive Analyt ics

6 | http://bs.doag.org

Diese Situation ist immer wieder gegeben, da die Datenverwalter zumeist nicht die Aus-werter der Daten sind. Häufig will man ja ge-rade eine Gruppe von Fachleuten, die keine Datenbank-Experten sind, dazu befähigen, eine Recherche zu betreiben, beispielswei-se Steuerfahnder, die in den Panama Papers nach verschleiertem Besitz suchen. Ein an-derer Anwendungsfall betrifft die Zusam-menführung technischer Produktdaten mit Vertriebsdaten eines Automatisierungsher-stellers, damit Produktmanager etwa die möglichen Risiken beim Auslauf, Austausch oder Lieferengpass von Produktteilen unter-suchen können.

Diese beiden und weitere Anwendungs-fälle lassen sich erfolgreich auf Basis se-mantischer Technologien und des darauf aufbauenden, interaktiven Visualisierungs- und Recherche-Werkzeugs SemSpect lö-sen. Der Artikel stellt diesen Lösungsansatz von der Aufbereitung und Anreicherung der Daten bis hin zur Analyse und Visualisie-rung der Daten am Beispiel der Panama Pa-pers vor. Dabei wird auch erläutert, welche Rolle hierbei Ontologiesprachen wie OWL und RDFS spielen, wie sich Linked Open Data integrieren lässt und welche Oracle-Komponenten für die technische Umset-zung möglich sind.

11,5 Millionen verschiedenartige Dokumente

Anfang 2015 hat die Süddeutsche Zei-tung 2,6 Terabyte an Daten in Form von 11,5 Millionen Dokumenten von einer anonymen Quelle erhalten. Diese werden inzwischen vom internationalen Konsortium investiga-tiver Journalisten (ICIJ) verwaltet und mit Redaktionen unter anderem aus den USA, Frankreich und Spanien ausgetauscht. Ein sehr naheliegender Verdacht war, dass die-se Daten Belege für die systematische Ver-schleierung von Besitzverhältnissen von Personen über Briefkastenfirmen mit Schein-direktoren enthalten.

Allerdings sind diese Belege verborgen in einer Vielzahl unterschiedlicher, größ-tenteils unstrukturierter Dokumente wie PDFs oder eingescannten Verträgen. Aus diesem Grund hat man Letztere mithilfe ei-ner Texterkennung gemeinsam mit E-Mails, Textdokumenten etc. in die Suchplattform Apache Solr geladen. Nicht unähnlich zur alltäglichen Suche im Web mit Google wur-den dort in einer Volltextsuche Informatio-nen über Personen und deren Zusammen-hänge parallel in den Redaktionen von Le

Monde, Guardian, Süddeutsche Zeitung etc. Stück für Stück identifiziert. Die Infor-mationen über Personen und Firmen sowie eine textuelle Beschreibung ihrer Bezie-hungen sind in Tabellen und einer Graph-Datenbank gespeichert.

Abbildung 1 zeigt diesen Arbeitsablauf schematisch. Auf diese Weise sind knapp eine Millionen Datenobjekte (Adressen, Fir-men, Personen) und etwa 4,5 Millionen Be-ziehungen zwischen diesen entstanden, die inzwischen der Öffentlichkeit als CSV-Datei-en sowie als Dump einer Graph-Datenbank (Neo4j) zugänglich sind.

Für journalistische Zwecke war es aus-reichend, nach bestimmten Namen und deren direkten Verbindungen zu suchen. Wie aber findet man in den verfügbar ge-machten Daten die Personen von Firmen mit Bezügen nach Deutschland? Welche anderen Firmen haben indirekte Beteili-gungen zu solchen Firmen? Welche Muster sind hier erkennbar?

Man könnte meinen, dass diese Recher-che direkt in der Graph-Datenbank möglich sein müsste. Leider sind die Daten jedoch sehr uneinheitlich erfasst, also mit und ohne Wortpräfixe. Zudem kommen ver-schiedene Abkürzungen sowie Synonyme vor. Auch unterschiedliche Schreibweisen und nicht zuletzt viele Schreibfehler er-schweren die Analyse.

Datenkonsolidierung und Datenschema ergeben einen WertSelbst Daten nur einer Anwendung sind häufig aufgrund mehrerer Erfasser und un-terschiedlicher Eingabemethodik nicht ein-heitlich und daher schwer auszuwerten. Die verfügbar gemachten Daten zu den Panama Papers sind ein Paradebeispiel hierfür. Was lässt sich tun? In diesem Fall kamen Werk-zeuge zur Datenkonsolidierung und Anrei-cherung zum Einsatz und es wurde ein se-mantisches Datenmodell entwickelt. Dieses Vorgehen unterscheidet sich dabei nicht von anderen Anwendungsfällen aus Industrie oder Behörden.

Primäres Ziel ist es, ein quellübergreifen-des, fachlich stimmiges Datenmodell zu er-stellen und die Daten anhand dieses Modells zu konsolidieren. Man setzt hier konsequent auf ontologiebasierte Modelle mit formaler Semantik und wissenschaftlich bewiesenen Eigenschaften zu Komplexität und Bere-chenbarkeit. Die Web Ontology Language (OWL) oder das Resource Description Format (RDF), beides offizielle Standards des W3C, sind hier die Sprachen der Wahl.

Für die Panama Papers wurde auf OWL gesetzt. Für die Erstellung von Datenmodel-len in OWL, die aus Klassen, Beziehungen und Datenwerten („class“, „object property“ und „data property“) bestehen, wurde der Ontologie-Editor Protégé eingesetzt. Im Fall

Abbildung 1: Ex trahieren von Datenobjekten und deren Beziehungen am Beispiel der Panama Papers

Import + Texterkennung

textuelle Suchmaschine

En#ty& Adresse& Land& Gründung&

Blue%Sky%Vision%Ltd.% c/o%Mossfon% Panama% 11:Nov:2014%

Flower%of%Sky%Corp.% c/o%Bank%of%Samoa,%Ms.%Berg% Samoa% 11:Oct:2005%

Joyful%Sky%Int.%Ltd.% c/o%Mossfon% Panama% 06:Nov:2013%

Officer& Beziehung& En#ty&

Peter%N.% execuNve%of% Flower%of%Sky%Corp.%

...% nominee%shareholder%of% ...%

...% ...% ...%

%%%%%151%Tsd.%Ad

ressen%

%%%495%Tsd.%EnN

Nes%

%%%370%Tsd.%Offi

cer%

E:Mails%Datenbanken%

PDFs%

Bilder%

Textdokumente%

4,5%Mio.%Beziehunge

n%

Business News 3-2017 | 7

Predic t ive Analyt ics

Abbildung 2: Klassen und Beziehungs-Hierarchie im Ontologie-Editor Protégé

der Panama Papers waren die zentralen Klas-sen schnell gefunden. Der Datenbestand be-handelt „Firmen“ (entities), „Mittelsmänner“ (intermediaries), „Angestellte“ (officer) sowie „Länder“ und „Adressen“.

Das Beziehungsmodell, das diese Klassen in Relation setzt, erfordert etwas Überblick über die eingetragenen Verknüpfungstex-te. Aus den knapp dreihundert verschiede-nen Verknüpfungen sind für das Ontologie-modell dreizehn inhaltlich unterschiedliche Beziehungen identifiziert und definiert wor-den. Abbildung 2 zeigt die Klassen und Be-ziehungen zu den Panama Papers, so wie sie in Protégé dargestellt sind. Für Steu-erfachleute ist dieses Modell eventuell zu grob oder auch fachlich schief. Hier liegt die Stärke des semantischen Ansatzes. Die Ontologie ist sehr flexibel, weil sie von der technischen Datenhaltung nicht so abhän-gig ist wie etwa das relationale Modell. Auch zur Laufzeit ist es möglich, Klassen zu verfei-nern oder neu einzuführen.

Das Besondere an einem ontologischen Modell ist zudem, dass Wissen über die Da-ten im Schema verankert werden kann. Es steht zur Zeit des Datenzugriffs automatisch zur Verfügung. Neben einer Hierarchie von Klassen und Beziehungen lassen sich wei-tere implizite Datenabhängigkeiten mithilfe sogenannter „Axiome“ definieren. So lässt sich beispielsweise sehr leicht und nachvoll-ziehbar ausdrücken, dass Firmen in Deutsch-land jene sind, deren Gerichtsbarkeit in Deutschland liegt.

Aus Spalten wird eine BedeutungFür die Abbildung der 4,5 Millionen einlie-genden Verknüpfungsaussagen auf die drei-zehn Beziehungen des Ontologie-Modells kam ein interaktives Datenkonsolidierungs-werkzeug zum Einsatz. Dabei werden inhalt-lich gleiche Verknüpfungsaussagen zusam-mengefasst und vom Benutzer über einfach zu definierende Muster in eine Beziehung des semantischen Datenmodells überführt.

Die 4,5 Millionen Verknüpfungen aus dem Panama Papers konnten beispielsweise mit diesem Werkzeug mit weniger als vierzig Regeln auf die dreizehn Beziehungen des Modells in etwa einer Stunde vereinheit-licht werden. Abbildung 3 zeigt die Benutzer-schnittstelle dieses Werkzeugs.

Dabei ist es gleichzeitig möglich, die Da-ten mit zusätzlichen Informationen aus ei-genen oder offenen Quellen anzureichern. Hier ist es von Vorteil, dass OWL – die Web Ontology Language – kompatibel zu den

Abbildung 3: Regelbasiertes Konsolidierungswerkzeug mit Panama-Paper-Daten

Formaten und Standards von Linked Open Data (LOD) ist. Auf diese Weise kann man Daten aus Wikidata, GeoNames etc. einfach und schnell für den eigenen Datenbestand nutzen.

Graph oder Ontologie?Was unterscheidet Graphen und Ontolo-gien? Das in Graph-Datenbanken vorherr-schende Datenmodell ist der sogenannte „Property Graph“. Er besteht aus Knoten und Kanten, die jeweils individuelle Eigen-schaften (Typ, Name etc.) – ihre sogenannte „Properties“ – besitzen können. Daten auf

Grundlage einer Ontologie haben ebenfalls eine Graph-Struktur aus Objekten und Be-ziehungen, die auch Eigenschaften erhal-ten können.

Abgesehen von syntaktischen Feinhei-ten besteht hier große Übereinstimmung. Die Unterschiede und die Wahl des Modells bestehen daher eher in den Zielen der Aus-wertung. Graph-Datenbanken sind dafür gemacht, Topologiefragen wie Erreichbar-keit, Zentralität oder Influenz effizient zu beantworten, wohingegen bei Ontologien das Ableiten von impliziten Fakten im Vor-dergrund steht.

8 | http://bs.doag.org

Überblick zuerst – Details nach BedarfWie lässt sich nun ein Graph (Netzwerk) aus Millionen von Objekten (Knoten) und Bezie-hungen (Kanten) verstehen und erforschen? Nach den Erfahrungen der Autoren liegt der Schlüssel in der datengetriebenen Explora-tion und kontextsensitiven Visualisierung. SemSpect ist ein Werkzeug, das diese Stra-tegie konsequent umsetzt und auch Nutzer ohne Erfahrung in Abfragesprachen anhand der visuellen Darstellung der Daten befä-higt, anspruchsvolle Recherche-Aufgaben in komplexen Datenbeständen zu bewältigen.

Ein Beispiel sind die „Angestellten“ (of-ficer) aus den Panama-Paper-Daten. Wie sind diese mit Datenobjekten aus den anderen Klassen verbunden? In SemSpect werden die mehr als 370.000 Angestellten zusam-mengefasst und als Gruppe (grafisch als Kreis) dargestellt. Für diese Gruppe lassen sich direkt aus einem Kontextmenü heraus die erreichbaren Klassen und Beziehungen anzeigen (siehe Abbildung 4).

Durch Auswahl einer Beziehung zeigt die Gruppe ihre verbundenen Datenobjek-te, ebenfalls in einer Gruppe zusammenge-fasst (siehe Abbildung 5). Auf diese Art und Weise kann eine Exploration der Daten vor-genommen werden, die sich visuell wie ein (umgestürzter) Baum von links nach rechts aufspannt. Im Unterschied zu gewöhnlichen Graph-Visualisierungen sind in SemSpect Datenobjekte und einzelne Beziehungen ag-gregiert dargestellt, um auch bei großen Da-tenmengen die Übersicht zu bewahren.

Datenobjekte wie die Länder der Ange-stellten sind als einzelne Punkte innerhalb ei-ner Gruppe dargestellt, solange ihre Anzahl unterhalb eines einstellbaren Schwellwerts liegt. Die Zahl in einem Datenobjekt gibt die Anzahl der verknüpften Objekte in der Vorgängergruppe an. Wird ein Datenobjekt selektiert, sind dessen Detail-Informationen sowie die direkt und indirekt verknüpften Objekte (sofern dargestellt) hervorgehoben.

Wenn man eine Gruppe selektiert, wer-den die Untergruppen sowie konfigurierbare Eigenschaften der Gruppe – die sogenann-ten „Facetten“ – angezeigt. Damit lassen sich die Gruppen einer Exploration selektiv filtern. Für jede Gruppe und jede Gruppen-verknüpfung ist auch eine Tabellenansicht verfügbar. In dieser lässt sich die Exploration ebenfalls etwa über Suchbegriffe filtern. Auf diese Weise können Schritt für Schritt durch Expansion des Expansionsgraphen und in-teraktive Filterung sehr komplexe Anfragen formuliert und deren Ergebnisse sofort gra-fisch dargestellt werden. Abbildung 6 zeigt links die Gesamtoberfläche von SemSpect mit dem Klassenbaum und gespeicherten Explorationen, in der Mitte die aktuelle Ex-

ploration und Tabellenansicht sowie rechts die Facetten einer Gruppe.

Es gibt weitere Funktionen in SemSpect, die die Recherche unterstützen (Markie-rungen, Speicherung von Zwischenergeb-nissen etc.). Für das Reporting lassen sich Gruppen und ganze Explorationen struktu-riert exportieren beziehungsweise als Bil-der abspeichern.

Die Technik dahinterSemSpect ist eine Client-Server-Anwendung mit einer HTML5/JavaScript-Web-UI, opti-miert für die Desktop-Benutzung (IE11 oder aktueller Chrome- beziehungsweise Firefox-Browser), sowie einem REST-Backend in Java 1.8. Die Schlussfolgerungs- und Anfrage-

Abbildung 4: Die „Officer“ in den Panama Papers und deren verknüpfte Klassen mit Beziehungen

Abbildung 5: Exploration der „Angestellten“ (officer) auf ihre Länder

Abbildung 6: Beispiel-Exploration in der Darstellung in SemSpect

Business News 3-2017 | 9

Predic t ive Analyt ics

Bearbeitung im Backend übernimmt Graph-Scale, eine patentierte RDFS/OWL-Techno-logie für Datenbanken. Prinzipiell arbeitet GraphScale mit relationalen und NoSQL-Datenbanken. Generell gilt, dass sich Graph-Datenbanken schon aufgrund der in diesem Artikel erwähnten Verwandtschaft von On-tologien und Graphen am besten eignen.

Es existieren aktuell Anbindungen an Oracle-Datenbank 12c Spatial and Graph, an Oracle Big Data Spatial and Graph mit der Oracle-NoSQL-Datenbank für die Da-tenhaltung sowie an Neo4j. Auch wenn GraphScale keine native Unterstützung von OWL oder RDFS voraussetzt, bleibt zu be-merken, dass Oracle-Datenbank 12c Spatial and Graph als einziges Backend diese Stan-dards und auch die Abfragesprache SPARQL nativ beherrscht.

Das vorgestellte Datenkonsolidierungs-werkzeug ist ebenfalls eine Web-Anwen-dung und kann mit unterschiedlichen Datenquellen betrieben werden. Im vorlie-genden Fall der Panama Papers lief das Sys-tem auf einem Oracle WebLogic Server.

FazitViele Daten haben inhärent eine Graph-Struktur; die Panama Papers sind ein gutes Beispiel dafür. Nutzt man diese Tatsache und setzt auf semantische Methoden und dar-auf abgestimmte Visualisierungs- und Ab-fragesysteme, lässt sich Verborgenes in Da-ten sichtbar machen. Sozialwissenschaftler aus Frankreich haben mit SemSpect in den Panama Papers auf Anhieb Hypothesen zu Netzwerken von vermögenden und einfluss-reichen Personen validieren können. Offen ist zum jetzigen Zeitpunkt, welche Verarbei-tungsmethoden und Auswertungsverfah-ren das BKA und die Steuerbehörden für die kürzlich angekauften Rohdaten der Panama Papers einsetzen.

Aber auch im Maschinenbau, in der Phar-maforschung, in sozialen Medien etc. tau-chen Datenbestände als Graphen auf. Das bedeutet im Umkehrschluss nicht, dass rela-tionale Datenbanken obsolet sind, sondern es deutet darauf hin, dass für das tiefe Ver-ständnis komplexer Daten und die Nutzung des darin verborgenen Wissens ergänzende Ansätze benötigt werden, die für Graphen optimiert sind.

Der in diesem Artikel exemplarisch an-hand der Panama Papers beschriebene An-satz semantischer Methoden mit einer für Graphen optimierten Benutzerschnittstelle ist nach Erfahrung der Autoren auf andere

Anwendungsbereiche direkt übertragbar. Die bereits nach diesem Muster produktiv gesetzten Lösungen stiften Nutzen in In-dustrie und Behörden durch eine höhere Ef-fektivität und Erkenntnisgewinn bei der Re-cherche sowie einen größeren Benutzerkreis durch die intuitive Benutzerschnittstelle.

Die IT-Landschaft muss dabei nicht völ-lig ausgetauscht werden. Der vorgestellte Lösungsansatz arbeitet, wie im vorherigen Paragraph beschrieben, sehr gut mit be-währten System-Komponenten wie der Oracle-Datenbank mit ihrer Erweiterung für Graphenmodelle zusammen. Die Erweite-rung des Oracle-Portfolios in Bezug auf Da-tenmanagement-Plattformen mit Oracle Big Data sowie dem Aufsatz Big Data Spatial and Graph ermöglicht auch die Speicherung und Auswertung von Graphen auf einer NoSQL-Datenbank beziehungsweise Apache-Ha-doop/HBase. Dies ist ein wichtiger Schritt zur Vereinigung etablierter und innovativer Technologien.

Weiterführendes Material• Ontologien – eine Definition: https://

de.wikipedia.org/wiki/Ontologie_(Informatik) • Panama Papers mit SemSpect:

http://panama.semspect.de• Weitere SemSpect-Demos: - SpringerNature SciGraph: http://scigraph.semspect.de - US Legislative von GovTrack.us:

http://govtrack.semspect.de• GraphScale Schlussfolgerungstechnologie: http://derivo.de/products/graphscale• Die Oracle-Datenbank jenseits von Entity-Rela-

tionship-Modellierung – vorhandenes Wissen repräsentieren und neues mit RDF Graph gen-erieren, DOAG News, Ausgabe 06/2015: https://www.doag.org/formes/pubfiles/7603500/docs/Publikationen/DOAGNews/2015/06-2015/06-2015-DOAG_SOUG_News_Karin_Patenge-

Die_Oracle-Datenbank_jenseits_von_Entity- Relationship-Modellierung_vorhandenes_ Wissen_repr%C3%A4sentieren_und_neues_mit_

RDF_Graph_generieren.pdf• Spatial and Graph Analytics with Oracle Da-

tabase 12c Release 2: http://www.oracle.com/technetwork/database-options/spatialandgraph/spatial-and-graph-wp-12c-1896143.pdf

• Protégé: http://protege.stanford.edu

PROMATIS GruppeTel. +49 7243 2179-0www.promatis.deEttlingen/Baden Hamburg Berlin Wien (A) Zürich (CH) Denver (USA)

Dafür steht PROMATIS als Geschä�sprozess-Spezialist mit mehr als 20 Jahren Erfahrungim Markt. Gepaart mit profundem OracleKnow-how scha�en wir für unsere Kundendie Digitale Transformation:

Oracle SaaS für ERP, SCM, EPM, CX, HCMOracle E-Business Suite und HyperionOracle Fusion Middleware (PaaS)Internet of Things und Industrie 4.0

Vertrauen Sie unserer Expertise als einer der erfahrensten Oracle Platinum Partner – ausgezeichnet mit dem EMEA OracleExcellence Award 2016.

ExzellenteBaupläne für die Digitale Ökonomie!

Image-Anzeige, 03/20164C, 73 x 297 mm, 3mm Beschnitt

...

.

Dr. Thorsten Liebigliebig@derivo.de

Karin Patengekarin.patenge@oracle.com