Teil II
Nachdem die wesentlichen Unterschiede zwischen den klassischen RDBMS und den Graph-Datenmodellen in dem vorherigen Blog beleuchtet wurden, stellt sich die Frage nach dem Business Case-Nutzen.
Wie kann Graph- Technologie in die bestehende Software- und Datenarchitektur eingefügt werden? Denkt man an Graphdatenbanken und insbesondere an Neo4J als einen seiner prominentesten Vertreter, so werden einem evtl. die durch das breite mediale Echo prominent gewordenen Enthüllungen der sogenannten „Panama Papers“ mit breiten internationalen Vernetzungen präsent.
Der „alltägliche“ Betrug findet in der Regel in viel kleinerem unscheinbaren Rahmen statt. In Summe gesehen fügt dieser den betroffenen Unternehmen allerdings einen enormen wirtschaftlichen Schaden zu. Neben den Bank- und Geldinstituten sind es insbesondere Versicherungsunternehmen, die für Betrüger besonders attraktiv zu sein scheinen.
Wie erkennen Versicherungsunternehmen entsprechende Betrugsversuche, wie können Indizien für einen Versicherungsmissbrauch gesammelt werden?
In der Versicherungsbranche gibt es bereits heute ausgeklügelte Mechanismen, die auf Basis von vordefinierten Standardregeln die Schadenfälle in folgende Kategorien einteilen:
- Fraud
- Not Fraud
- Unsure.
Die „Unsure“-Verdachtskategoriefälle sind für die weiteren Untersuchungen von besonderem Interesse. Dabei sollen vor allem die Beziehungen zwischen Geschädigten, Schadensverursacher, Schadenfall und allen weiteren Akteuren wie Zeugen, Leistungserbringern (Ärzte, Krankenhäuser, Anwälte) etc. beleuchtet werden, um einen möglichen Versicherungsmissbrauchsverdacht auszuräumen oder zu bestätigen. Eine Graphdatenbank setzt auf die Untersuchung von Beziehungen innerhalb eines Netzwerkes und genau diese stehen bei der Analyse des Verdachts im Mittelpunkt. Im Folgenden werden auf Basis eines Business Case aus der Haftpflichtversicherungssparte „Verdacht auf doppelte Schadensmeldung“ die Kernaspekte der Neo4j-Abfragesprache „Cypher“ vorgestellt.
Business Case: „Verdacht auf doppelte Schadensmeldung“
Der betrachtete Sachverhalt setzt sich wie folgt zusammen: „ Am 01.01.2018 wurde von Herrn Klaus Mustermann, wohnhaft in Zürich Seefeld 1, ein Schadensfall angemeldet. Als geschädigter Gegenstand wurde ein Fernseher, Modell „FDS2010“, angegeben. Der Schadensfall ereignete sich in Zürich, Baselstraße 10.“
Bei der Untersuchung von Betrugsverdachtsfällen sind die Sachverständigen an einer möglichst großen Anzahl von Verbindungen bzw. einer Vielfältigkeit der Vernetzung zwischen den einzelnen Datenpunkten interessiert. Das Graph-Datenmodell ist daher in der Regel an die spezifische Fragestellung, das Untersuchungsverfahren, den Business Prozess oder das Modell angelehnt. Unterschiedliche Herangehensweisen bei der Untersuchung resultieren somit in unterschiedlichen Datenmodellen. Aus Gründen der Nachvollziehbarkeit enthält ein stark vereinfachtes Modell zur Visualisierung des obigen Sachverhaltes folgende Elemente:
- Gemeldeter Schadensfall, der untersucht wird (Claim)
- Geschädigter und versicherter Gegenstand (Subject-matter insured)
- Versicherungsnehmer und Schadensverursacher (Insurant)
- Adresse (Address)
Die anschließenden Bearbeitungsschritte einer Untersuchung laufen in den meisten Fällen nach folgendem Muster ab:
1. Laden der Daten
Im ersten Schritt werden die Schadensdaten in die Neo4j-Datenbank geladen. Dabei wird das Graph-Modell Pattern auf die Daten angewandt und die Daten als Knoten und die zugehörigen Beziehungen in der Neo4J-Datenbank erstellt. Betrachtet man das obige Graph-Modell Pattern unter der Cypher–Brille, so sind folgende Strukturen von Interesse:
Knoten (Node)
Die einfachste Deklaration eines Knotens ist () und repräsentiert einen anonymen Knoten ohne irgendwelche Eigenschaften. Ein Knoten – Label definiert den Knotentyp. Das Label bestimmt die Grenzen eines Beziehungskonstrukts, das untersucht wird. Auch die Nodes-Indizes in Neo4J nutzen die Labels:
Jeder Index ist eindeutig pro Label und Property-Kombination. Die Eigenschaften (Properties) eines Knotens bestehen aus key/value-Paaren und können analog zu den Knoten–Labels zum Einschränken des Graph-Patterns oder zur Speicherung der Zusatzinformationen genutzt werden.
Die Syntax zum Kreieren eines Insurant Knotens mit Label und Properties:
Properties: ( :Insurant {id: 100, name: "Klaus Mustermann", gender: „male“})Beziehung (Relationship)
Eine Beziehung hat immer einen Start- und einen Endknoten. Es gibt keine bidirektionalen Beziehungen, die Beziehungsrichtung ist immer durch einen Pfeil vorgegeben. Ein Beziehungstyp entspricht dem Label-Property-Konstrukt (die Beziehungseigenschaften entsprechen den Knoten).
Die Syntax zum Kreieren einer Beziehung: -[:LIVES_AT]->
Graph-Muster (Pattern)
Durch die Kombination von Knoten und Beziehungen entstehen Muster (Pattern)
Die Syntax:
(:Insurant {id: 100, name: "Klaus Mustermann", gender: "male"}) -[:LIVES_AT]-> (: Address {address_line_1:"Seestrasse 1", city:"Zuerich", zip:"8000", country:"CH"})Der springende Punkt bei der Patterndefinition ist das Verständnis davon, dass ein Knoten im Pattern einen 0 – N Datenbankknoten beschreibt und umgekehrt ein Pattern 0 – N Knoten und Beziehungen zwischen den Knoten beschreibt.
Variablen
Die Möglichkeit der Zuweisung von Variablen an Knoten, Beziehungen oder Patterns innerhalb eines Statements erhöht die Wiederverwendbarkeit der Abfragen in Cypher:
Die Syntax:
lives_at = (:Insurant)-[:LIVES_AT]->(:Address)Für den Datenimport bietet Neo4j unterschiedliche Schnittstellen an. Die einfachste Methode ist Cypher’s Befehl “LOAD CSV” oder „LOAD JSON“. Dabei werden die Daten von der Quelle (z.B. aus Oracle, MySQL, PostgreSQL-Tabellen) in eine CSV-Datei exportiert und anschließend importiert. Eine insurant.csv Datei zur Erstellung der Insurant–Knoten bedient sich folgender Syntax:
// Create Insurant
USING PERIODIC COMMIT
LOAD CSV WITH HEADERS FROM "file:insurant.csv" AS row
CREATE (:Insurant {id: row.PersonID, name: row.PersonName, gender: PersonGender});Sehr große Datenmengen müssen bei diesem Verfahren in mehrere Dateien gesplittet und dann beim Import via merge – Befehl wiederzusammengefügt werden.
Einen direkten Weg ohne Fileexport und Splitting bietet die Datenintegration via Talend Open Studio for Big Data an. Dieses stellt einen Connector für dieNeo4j-Datenbank bereit, welcher durch eine einfache Konfiguration direkt genutzt werden kann. Der Nachteil ist, dass diese Methode die Neo4J-Rest API nutzt und daher langsamer ist als die Methoden, die einen nativen Java Driver einsetzen.
Neo4J 3.0 bietet mit neo4j-import ein Tool für ein effektives bulk load von sehr großen Datenmengen und eine initiale Erstellung einer Datenbank.
2. Auffinden von Matches/Auffälligkeiten
Nachdem die Daten geladen wurden können unterschiedliche Beziehungen zwischen den einzelnen Schadensfällen, Geschädigten und weiteren Akteuren untersucht werden. Cypher ist eine deklarative Sprache und wurde bei ihrer Entwicklung stark durch die modernen Sprachen wie Python oder SPARQL beeinflusst. Als Ergebnis stehen einem Analysten neben SQL – ähnlichen Keywords wie WHERE, ORDER BY zusätzliche mächtige Konstrukte wie pattern-matching oder list-semantic zur Verfügung.
Der Cypher-Befehl MATCH in Kombination mit RETURN bringt die gesuchten Datenpunkte zurück. Mit der WHERE-Klausel können die Suchergebnisse eingeschränkt werden:
MATCH (insurant:Insurant)-[:LIVES_AT]->(adr:Address)
WHERE adr.country = 'CH'
RETURN insurant.name, adr.city, adr.address_line_1
Mit dem Befehl SET können Labels und Properties überschrieben oder ergänzt werden.
MATCH (insurant:Insurant)
WHERE insurant.name='Klaus Mustermann'
SET insurant.civil_status="single"
SET insurant :Insurant:Claimant
SET insurant.gender=NULL
RETURN insurant;Als Ergebnis wurde dem Knoten (:Insurant) ein weiteres Label (:Claimant) hinzugefügt, eine neue Property ‚civil_status‘ erstellt und die Property ‚gender‘ von (:Insurant) gelöscht.
Mit DELETE können die Knoten permanent aus der Graphdatenbank gelöscht werden. Sind die Knoten über Beziehungen verknüpft, können sie so lange nicht gelöscht werden, bis die Beziehungen gelöst sind. Dies erfolgt mittels des Keywords DETACH. Die gelösten Beziehungen werden automatisch mitgelöscht.
MATCH (claimint:Claimant)
WHERE claimant.name='Klaus Mustermann'
DETACH DELETE claimant;
In unserem Beispiel fokussieren wir uns zuerst auf die Adressen der Schadensfälle und der Versicherungsnehmer.
Dass zwei Versicherungsnehmer mit unterschiedlichen Familiennamen an der gleichen Adresse registriert sind, ist nicht außergewöhnlich. Schließlich kann es sich bspw. um eine Wohngemeinschaft handeln. Interessanter wird es, wenn man deren angemeldete Schadensfälle genauer analysiert. Als Eingangstor zum Traversieren wird nun die Schadensadresse eingegeben.
MATCH (a:Address{address_line_1:"Baselstrasse 10", city:"Zuerich"})<-[:PLACED_AT]-(m:Subject_matter_insured)-[:INVOLVED_IN]->(c:Claim <-[:ADVISED]-(i:Insurant) return a, m, c, iDiese Abfrage bringt neben dem Schadensdossier „Claim 2018“ von Herr Mustermann die weiteren von der Baselstraße 10 in Zürich gemeldeten Schadensfälle – inkl. der Knoten des geschädigten Gegenstands, des Versicherungsnehmers und das Schadensdossier „Claim 2017“.
3. Kombinieren der Matches
Im dritten Schritt werden die vorherigen Ergebnisse genauer untersucht. Der Vorteil von Neo4J ist dabei, dass alle in dem betroffenen Zusammenhang interessierenden Informationen extrem einfach und schnell bereitgestellt werden. So können die erfassten Informationen zu dem geschädigten Gegenstand gemeldeter Fälle abgeglichen werden. In unserem Beispiel liegt höchstwahrscheinlich eine Doppeltschadensmeldung vor, scheinbar wurde der gleiche Gegenstand an derselben Adresse beschädigt.
Architektonische Möglichkeiten
Der beschriebene Business Case zeigt auf, dass Neo4J in erster Linie das explorative Vorgehen bei den Datenanalysen unterstützt. Die nachfolgende Grafik stellt einen möglichen Einsatz von Neo4J in der Software-Architektur eines Unternehmens dar.
Die Daten für Neo4J können dabei aus bereits etablierten DBMS wie z.B. MySQL, Oracle, PostgreSQL und Hadoop je nach Fragestellung in ein jeweiliges Graphmodell überführt werden oder die Knoten und Beziehungen über einen Webcrawler (z.B. JAVA JSoup oder Python) direkt in Neo4J erstellt werden. Die Datenverarbeitung kann dabei sowohl in Echtzeit als auch im Batch-Modus erfolgen.
Die Koexistenzfähigkeit der relationalen DBMS und einer Graphdatenbank bringt Vorteile, die folgende Einsatzszenarien ermöglichen:
1. Datenexport aus relationalen DBMS oder NoSQL-Load ins Neo4J, Ad-hoc-Analysen mit „Wegwerfmodellen“
2. Dort, wo die relationalen DBMS aufgrund der Datenmenge, Performance, Datenvernetzungsdichte an ihre Grenzen stoßen, kann Neo4J ein Modell für die Unternehmensapplikationen bereitstellen
3. Die in der Graphdatenbank ermittelten Erkenntnisse können wieder für weitere BI-Zwecke in die relationale DBMS, Hadoop etc. zurückfließen.
Durch die Neo4J-Integration in die Software-Architektur wird das architektonische Gesamtwerk eines Unternehmens ein Stück flexibler und für bestehende und zukünftige Anforderungen leistungsfähiger.
