Genug von Joins? Wie Graphdatenbanken Daten verknüpfen.

Wer in einem der zunehmend datenbasierten Arbeitsfelder als Ingenieurin, Entwicklerin, Data Analyst oder Data Scientist arbeitet, begegnet an vielen Stellen Datenbanken. Häufig werden Daten in klassischen relationalen Datenbanken gespeichert und mithilfe von Structured Query Language (SQL) Abfragen in täglichen Geschäftsprozessen genutzt. Dabei stößt man früher oder später auf die Notwendigkeit von Join-Operationen, um Daten die in unterschiedlichen Tabellen gespeichert sind, miteinander zu verknüpfen. Graphdatenbanken hingegen bieten die Möglichkeit Verknüpfungen Out-of-the-Box zu modellieren. 

Join-Operationen: Wie sich intelligent Daten aus unterschiedlichen Tabellen verknüpfen lassen

Nehmen wir an, wir wollen eine Datenbank für Filme anlegen und dort Informationen über Länge, Nutzerbewertungen, Genre und Erscheinungsdatum speichern. Dafür lässt sich leicht eine Tabelle „Movies“ mit den jeweiligen Spalten „Name“, „Length“, „ImdbRating“, „Genre“ und „ReleaseDate“ anlegen, in der ein Film pro Zeile gespeichert wird. Im nächsten Schritt interessiert uns pro Film, welche Schauspieler/Schauspielerinnen welche Figuren darstellen und ob es eine Hauptrolle ist. Hier tauchen verschiedene Probleme auf. Wie speichern wir Listen von Schauspielern/Schauspielerinnen, die alle von unterschiedlicher Länge sein können? Man benötigt also wieder eine neue Tabelle, wir nennen sie „MovieCharacters“, in welcher alle Rollen und der darstellende Schauspieler oder die darstellende Schauspielerin gespeichert werden können. dazu legen wir die Spalten „Character“, „Actor“ und „IsMainCharacter“ an. Allerdings benötigt man dann im nächsten Schritt auch eine Möglichkeit die beiden Tabellen verknüpfen zu können. Mithilfe einer Unique ID (UID) pro Film lässt sich die Herausforderung aber bewältigen. Diese UID, beispielsweise bestehend aus dem Namen und dem Erscheinungsdatum eines Filmes, wird sowohl in der Tabelle „Movies“ als auch der neuen Tabelle „MovieCharacters“ in der eigens dafür angelegten Spalte „MovieID“ hinterlegt. Mithilfe eines Joins können nun ohne viel Aufwand für die angelegten Filme alle Schauspieler/Schauspielerinnen  abgefragt werden. 

Gehen wir nun noch einen Schritt weiter und legen eine dritte Tabelle, „Actors“ genannt, mit Informationen, wie Geburtsdatum und Geschlecht des Schauspielers/der Schauspielerin, an. Um die erfassten Daten sinnvoll nutzen zu können, benötigen wir wieder eine UID pro Schauspieler/pro Schauspielerin. Damit besitzt unsere Tabelle die Spalten „DateOfBirth“, „Gender“ und „ActorID“. Wollen wir nun eine Fragen beantworten wie beispielsweise: „Wie viele weibliche Schauspielerinnen spielten seit 2000 in einem Film eine Hauptrolle?“, müssen wir alle drei Tabellen verknüpfen, da sich die Informationen zum Erscheinungsdatum, zu Geschlecht und zu Hauptrolle in den unterschiedlichen Tabellen befinden. Die dabei entstehenden SQL-Abfragen enthalten mehrere Join-Operationen und können vor allem bei einer wachsenden Anzahl von Tabellen schnell komplex und sehr rechenintensiv werden. Hier bieten Graphdatenbanken einen alternativen Ansatz. Graphdatenbanken bilden die Verknüpfungen von Film zu Rollen zu Schauspielern/Schauspielerinnen direkt ab. 

Das Geheimnis dahinter: Beziehungen statt Joins in Graphdatenbanken 

In Graphdatenbanken existieren zwei unterschiedliche Typen von Datenobjekten. Diese nennt man Knoten und Kanten. Knoten können einfach angelegt werden und ähneln als einzelner Eintrag einem flachen Json-Dokument. Dabei ist den Knoten ein Typ zugewiesen, in unserem Fall „Movie“, „MovieCharacter“ und „Actor“, und Felder wie „name“ und/oder „length“. In diesen werden dann die konkreten Werte gespeichert. Der Film „A Beautiful Mind“ sieht als Knoten vom Typ „Movie“ folgendermaßen aus: 

Movie {name: „A Beautiful Mind“; length: 135; imdb_rating: 8.2; genre: “drama”; release_date „2001-12-13”} 

Kanten hingegen können nur zwischen zwei Knoten initialisiert werden - mit anderen Worten: Sie beschreiben Beziehungen zwischen Knoten. Nehmen wir als Beispiel den Film „A Beautiful Mind“, den Charakter „John Nash“ und den Schauspieler „Russel Crowe“. Zwischen „A Beautiful Mind“ und „John Nash“ kann dann beispielsweise die Beziehung „hasCharacter“ und zwischen „John Nash“ und „Russel Crow“ die Beziehung „playedBy“ definiert werden. Diese stellen anlog zu den UIDs in relationalen Datenbanken eine Verknüpfung zwischen Daten her. Die Benennung der Kanten impliziert eine weitere Eigenschaft, nämlich die Richtung. Liest man die Knoten und die Beziehung in dieser Reihenfolge, ergibt sich eine intuitive Art die Daten nachzuvollziehen: „A Beautiful Mind“ – > „hasCharacter“  – > „John Nash“. Neben der soeben beschriebenen Richtung können Kanten, wie Knoten auch  Felder mit Werten besitzen. Diese Eigenschaft lässt sich geschickt nutzen, um unser Datenmodell noch aussagekräftiger und besser abfragbar zu gestalten. Hierzu erzeugen wir Kanten vom Typ „playedCharacterIn“ zwischen Schauspielern/Schauspielerinnen und Filmen und verzichten auf die Knoten vom Typ „MovieCharacter“. Diese Kanten versehen wir mit den Eigenschaften „character_name“ und „is_main_character“. Somit können wir die Beziehung zwischen Schauspielern/Schauspielerinnen und Filmen, oder anders gesagt, das "Schauspielern" exakt und intuitiv erfassen. Das Ergebnis liest sich dann so: 

Actor{name: „Russel Crowe“; … } “ – „playedCharacterIn“ {character_name: “John Nash”; is_main_character: True}  – > Movie {name: „A Beautiful Mind“ ; …} 

Eine Abfrage wie in diesem Beispiel lässt sich vollkommen ohne Join-Operationen durchführen und kann mit Übersichtlichkeit und verkürzten Abfragezeiten überzeugen. 

Welcher Ansatz und welche Datenbank geeignet sind lässt sich nicht generalisieren. Die Entscheidung hängt immer von der Struktur der Daten und den Fragen, die man mit ihrer Hilfe beantworten möchte, ab. Für stark verknüpfte Daten bietet es sich an, den alternativen Einsatz einer Graphdatenbank zu überdenken. Ein Indikator für den Grad an Verknüpfungen ist in jedem Fall die Anzahl an  Join-Operationen über mehrere Tabellen bei geeigneten Beispielabfragen für den entsprechenden Datensatz.  

Wenn du auch genug von Joins hast, probier doch mal eine Graphdatenbank aus. Und für alle, die noch mehr erfahren möchten, geht's hier zu weiterführenden Infos: Data Analytics.