Von Göttern und Graphen

Die Grundlagen – Chaos formt sich

Dieses Tutorial zeigt, wie mit eXtended Objects (XO) Daten in der Graphdatenbank Neo4j ablegt werden können.

XO, Java und Neo4j – Gottheiten, die sich verstehen

Neo4j ist eine Graphdatenbank. Anders als bei relationalen Datenbanken werden hier die Daten als Knoten und Kanten abgelegt. Knoten besitzen Labels, weiterhin haben sie Eigenschaften als Name-Wert-Paar und stehen mit anderen Knoten über Kanten in Beziehung. Labels markieren und kategorisieren einen Knoten. Beziehungen zwischen Knoten besitzen eine Richtung. Beziehungen können ebenfalls Eigenschaften besitzen.

Grafik_TutorialXO_Neo4jSymbole
Abbildung 1 Bezeichnung Neo4j Bestandteile

eXtended Objects (XO) ist ein Framework, um Daten von Java in Neo4j zu speichern. XO bietet ein Mapping zwischen Konzepten der Programmiersprache Java und Konzepten der Graphdatenbank. Knoten in der Datenbank werden auf XO-Entitäten abgebildet. Eine solche Entität ist kein Java-Bean im herkömmlichen Sinn, sondern eine von eXtendend Objects verwaltete Instanz eines Datentyps. Die Datentypen werden als Interfaces modelliert und tragen XO-spezifische Annotationen. Kanten werden auf ein- oder mehrwertige Properties abgebildet. Eigenschaften von Knoten werden auch als Properties abgebildet, allerdings haben diese einen primitiven Datentyp oder Sting als Typ. Properties werden durch Getter und Setter definiert.

Grafik_TutorialXO_Mapping
Abbildung 2 Mapping Java – XO – Neo4j

weiterlesen

Wenn der Wunsch Vater der Dokumentation ist

Der Beitrag könnte Spuren von Emotionen beinhalten. Gerne wird Open-Source-Software mangelnde Dokumentation nachgesagt. Diese Kritik mag manchmal gerechtfertigt sein, auf lange Sicht sind schlecht dokumentierte Frameworks aber einer gewissen negativen Selektion unterworfen – um es vornehm auszudrücken.

Hibernate – das Mapping-Framework von JBoss/Red Hat – besitzt traditionell eine sehr umfangreiche Dokumentation. Diese ist sicherlich ein wesentlicher Grund für die Beliebtheit des Frameworks. Ein Reibungspunkt kann trotzdem entstehen, wenn die Dokumentation Features andeudet, die nicht vorhanden oder fehlerhaft implementiert sind (z.B. HHH-5732). Was mich in den Wahnsinn treibt, ist @NaturalId.
weiterlesen

Alternative Schlüssel in JPA

Sobald man sein Java-Objektmodell auf eine relationale Datenbank abbildet, stellt sich die folgende Frage: Wie soll der Primärschlüssel gebildet werden?

Alle JPA-konformen O/R-Mapper unterstützen sowohl künstliche als auch natürliche Primärschlüssel: Künstliche Primärschlüssel werden vom O/R-Mapper beim Persistieren neuer Entität automatisch generiert. Ein künstlicher Primärschlüssel macht lediglich den Datensatz eindeutig und besitzt darüber hinausgehend keine weitere Bedeutung. Ein natürlicher Primärschlüssel ist Bestandteil der Daten. Er hat einen fachlichen Ursprung und muss durch den Fach-Anwender vergeben werden.

Bei der Erstellung des Objektmodell ist für jede Entität die Frage zu beantworten, ob sie einen künstlichen oder einen natürlichen Primärschlüssel erhalten soll. Die Erfahrung lehrt, dass ein künstlicher Schlüssel prinzipiell die bessere Wahl ist. Die Gründe hierfür sind vielfältig:

weiterlesen

Case-Study: ThyssenKrupp Steel Europe AG

EclipseLink LogoWir unterstützten die ThyssenKrupp Steel Europe AG bei der Erstellung eines neuen, einheitlichen Fertigungsleitsystems auf der Basis von Java-EE-5. Unsere Rolle war es, dem Inhouse-Team zum Thema Persistenz/JPA beratend zur Seite zu stehen. Wir unterstützen bei der Technologieauswahl, migrierten die bestehende Persistenztechnologie nach EclipseLink und schufen darauf aufbauend eine tragfähige Persistenzstrategie mit den Schwerpunkten Abfragsprache, Graph-Historisierung, Modell- und Metamodell-Generierung.

Auf der Basis moderner Enterprise-Java-Technologien ist es uns gelungen, ein performantes, hochverfügbares und flexibles Fertigungsleitsystem zu erstellen, welches den heutigen und zukünftigen Ansprüchen für die Auftrags- und Materialversorgung der verschiedenen Aggregate an den Standorten gewachsen ist.

Joachim Kaminski, Projektleiter,
ThyssenKrupp Steel Europe, Duisburg

Das neue Fertigungsleitsystem ging nach zweijähriger Entwicklungszeit bereits am ersten Standort in die Produktion. Ein weiterer Standort ist zwischenzeitlich gefolgt.

Lesen Sie mehr dazu in der gemeinsamen Case-Study: Kosteneinsparung dank einheitlichem Fertigungsleitsystem bei ThyssenKrupp Steel Europe.

Wir möchten hiermit noch einmal allen herzlich danken, die sich an der Erstellung der Case-Study beteiligt haben. Dank gilt auch dem EclipseLink/TopLink-Team in Kanada und dem Oracle TopLink-Support für ihre Unterstützung im Projekt.

Hibernate im Projekteinsatz

Ein neues Projekt beginnt und ich kann endlich einmal etwas auf der grünen Wiese anfangen. Aus dem Java-Universum suche ich mir die aktuellen Versionen meiner Lieblingsframeworks zusammen. Dabei stellt sich mir ein entscheidendes Problem: Ich habe eine relationale Datenbank und reines JDBC ist sicherlich nicht mehr „up to date“. Wenn in anderen Java-Projekten die Themen Persistenz und relationale Datenbank auf den Tisch kommen, dann fallen immer wieder die Begriffe Java Persistence API (JPA) und Hibernate. Die Gründe liegen auf der Hand:

weiterlesen

 1 2 3 Vor