Leseproben
Michael Simons Neo4j

Der einfachste Weg zum Start ist sicherlich die Desktopdistribution. Sie bringt – passend für das Betriebssystem – ein JDK und eine Desktopoberfläche mit. Da im Kern aber die kommerzielle Enterprise Edition der Datenbank genutzt wird, muss ein kleines Formular ausgefüllt werden. Die Nutzung der Enterprise Edition der Datenbank ist in Form der Desktopdistribution kostenlos möglich. Je nach Betriebssystem wird die Installation mit Hilfe eines Installers durchgeführt oder (unter macOS) durch Drag and Drop in den Ordner Programme.

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, 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.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Java Magazin 7.19 - "Lucene, Solr, Elasticsearch"

Alle Infos zum Heft
579894250Anwendungsentwicklung mit Neo4j im Spring-Ökosystem
X
- Gib Deinen Standort ein -
- or -