© marivlada/Shutterstock.com, © S&S Media
Teil 1: Anwendungsentwicklung auf Basis von Neo4j im Spring-Ökosystem

Farin, Rod und die Rainbirds …


Dieser Text ist der erste Teil einer Reihe von Tutorien, die sich mit Graphdatenbanken im Allgemeinen und Neo4j im Speziellen beschäftigen. In den fast zwanzig Jahren meines professionellen Berufslebens habe ich in der Regel mit relationalen Datenbanken gearbeitet. Seit letztem Jahr bin ich als Engineer für Neo4j im Spring-Data-Team tätig. Spring-Wissen hatte ich nach der Veröffentlichung des Spring-Boot-Buchs [1], was jedoch die Datenbank angeht, war ein Umdenken notwendig. Dieses Tutorial beschreibt meinen Weg durch die Welt der Graphen.

Graphen- und relationale Datenbanken haben eines gemeinsam: Sie existieren nicht im luftleeren Raum. In der Regel gibt es Anwendungen oder ganze Anwendungssysteme, heutzutage oftmals Microservices, die mit ihnen sprechen wollen. In vielen dieser Anwendungen werden Mappingsysteme eingesetzt, beispielsweise Neo4j-OGM (unser Graph-zu-Objekt-Mapper) oder JPA (ein objektrelationaler Mapper). Diese Abstraktionen machen es sehr leicht, Datenbankstrukturen in die Anwendung abzubilden. Leider wird oftmals das Anwendungsmodell eins zu eins in die Datenbank oder das Datenmodell eins zu eins in die Anwendung abgebildet. Ich halte es für falsch, dass das Schema einer Datenbank primär aus einer Anwendung oder, konkreter gesagt, aus einem Anwendungsfall getrieben entwickelt wird. Das gilt für Graphdatenbanken genauso wie für relationale Datenbanken. Im dritten Teil dieser Serie werde ich hinsichtlich des Anwendungsdesigns genauer darauf eingehen.

Relationale Datenbanken oder Datenbanken mit Beziehungen?

In den siebziger Jahren des vergangenen Jahrhunderts erfand Edgar F. Codd das relationale Modell beziehungsweise die relationale Algebra. Eine Relation ist nicht das, was die Allgemeinheit unter einer Beziehung versteht. Eine Relation im Sinne von Codds Algebra besteht aus Attributen und Tupeln, den Werten der Attribute. Damit ist eine Tabelle an sich eine Relation: Die Spaltenköpfe entsprechen den Attributen, die Werte in den einzelnen Zeilen den Attributwerten. Einer Ergebnismenge, die mit SQL abgefragt wird, entspricht somit wieder eine Relation. Durch Fremdschlüssel zusammengeführte (gejointe) Tabellen sind wieder neue Relationen. Fremdschlüssel selbst sind hingegen keine Relationen. Echte Beziehungen entstehen in relationalen Datenbanken also immer erst zur Laufzeit.

Das Schema einer Datenbank wird oftmals als logisches Beziehungsmodell von Entitäten (Entity Relationship Model) entworfen. Diese Darstellung ist sehr hilfreich, um ein Schema sinnvoll mit dem Fachbereich zu besprechen. Leider geht diese Klarheit bei der Modellierung eines physikalischen Datenbankschemas oftmals notgedrungen im Zuge der Normalisierung verloren.

Graphen und Graphdatenbanken

Der Ursprung der Graphentheorie geht auf Leonhard Euler zurück. Euler versuchte das Königsberger Brückenproblem zu lösen. Im frühen 18. Jahrhundert ging es in dieser Fragestellung darum, ob es einen Rundweg über alle sieben Brücken über den Pregels in Königsberg geben kann, der jede Brücke genau einmal überquert. Euler näherte sich dem Problem nicht geometrisch, sondern mit Methoden, die heutzutage der Graphentheorie zugeordnet werden. Die Ufer entsprechen den Knoten, die Brücken den Verbindungen zwischen den Knoten.

Es lohnt sich fraglos, sich intensiver mit den mathematischen Grundlagen zu beschäftigen. Für dieses Tutorial genügt indes die Kenntnis des Begriffs Property-Graph (Abb. 1).

simons_neo4j_1.tif_fmt1.jpgAbb. 1: Was ist ein Property-Graph?

Ich werde im Folgenden die Begriffe Nodes (Knoten), Relationships (Beziehungen) und Properties (Eigenschaften) benutzen. Nodes entsprechen Entitäten oder Dingen und werden daher üblicherweise mit Substantiven bezeichnet. Diese Substantive nennen wir Label. Sie nehmen Werte wie Künstler, Band, Solokünstler an. Ein Node kann mehr als ein Label haben. Beziehungen stellen typisierte und gerichtete Verbindungen zwischen Knoten dar. Sie werden in der Regel mit Verben in Kapitälchen bezeichnet. Sowohl Knoten als auch Beziehungen können beliebig viele Properties (Eigenschaften) aufweisen. Im Folgenden werde ich die deutschen Übersetzungen benutzen.

Mit diesem einfachen Modell können auch komplexe Beziehungsnetzwerke aus allen möglichen Anwendungsbereichen leicht modelliert werden. Im einfachsten Fall erfolgt das als Graphdiagramm auf einem Whiteboard oder Papier. Bei der Modellierung fällt schnell auf, dass es keinen Bruch zwischen logischem (Whiteboard) und physikalischem Modell gibt. Das erste Grundmodell unseres neuen Graphen sollte in der Lage sein, relevante Anwendungsfälle abzudecken und relevante Fragen zu beantworten.

Benötigte Software

Am Ende des Tutorials soll eine kleine Java-Anwendung auf Basis von Spring Boot entstanden sein, die sowoh...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang