Aufbau von Structr - Structr: Quelloffenes Daten-CMS auf Neo4j-Basis - page 8

Abbildung 1.3: Schemaeditor
Structr macht sich hier einen weiteren Vorteil der Graphdatenbank Neo4j zunutze: die Fle-
xibilität des Schemas. Bis Version 1.9 war Neo4j vollständig schemalos, d. h. besaß keiner-
lei Elemente, die eigens zur Typunterscheidung vorgesehen waren. Die Anwender mussten
ihre eigene, oft sehr individuelle Wahl treffen, z. B. die Markierung durch ein Typattri-
but oder Verknüpfung mit einem Typknoten. Die Verwaltung der Typinformation musste
vollständig auf Anwendungsebene erfolgen. Dem häufig geäußerten Wunsch nach Unter-
stützung bei der Einhaltung von Schemaregeln kamen die Neo4j-Entwickler mit Version 2
durch die Einführung der so genannten Labels nach. Die Freiheit bei der Typkodierung be-
steht nach wie vor, zusätzlich ist mit Labels aber erstmals ein eigenes Element verfügbar,
das zur Gruppierung von Knoten gleicher Eigenschaften verwendet werden kann und sich
damit auch zur Unterscheidung von Typen verwenden lässt. Man kann Knoten ein oder
mehrere Labels zuweisen, die von Neo4j, also in der Datenbank selbst, verwaltet werden.
An Labels können auch bestimmte Einschränkungen (Constraints) gebunden werden, die
die Einhaltung von Schemaregeln vereinfachen.
Die Schemalosigkeit bzw. Schemaflexibilität auf Datenbankebene macht es erst möglich,
das Datenmodell an einer einzigen, zentralen Stelle innerhalb der Gesamtarchitektur zu de-
finieren. Genau dieses Grundprinzip steckt hinter dem dynamischen Schema in Structr, das
wiederum als Graphstruktur in Neo4j persistiert wird, die mit dem Schemaeditor bearbeitet
werden kann.
Jeder Datentyp ist in Structr ganz klassisch intern als Java-Klasse definiert. Neben den ein-
gebauten Klassen, die für die Basisfunktionalität von Structr selbst notwendig sind, können
weitere projektspezifische Klassen geschrieben und in JAR-Dateien eingebunden werden.
Um den Einstieg zu erleichtern, stehen Maven-Archetype-Projekte zur Verfügung, die im
GitHub Repository von Structr zu finden sind [3].
Über den Schemaeditor können weitere, instanzspezifische Klassen definiert werden, deren
Quellcode dynamisch aus den Attributen eines entsprechenden Typknotens im Schema-
graph generiert und zur Laufzeit kompiliert, und deren Bytecode in den Class Loader der
JVM injiziert wird. Die möglichen Beziehungen zwischen den Klassen werden durch Rela-
tionenkanten im Schemagraph dargestellt, in denen nicht nur die Attributnamen von Quell-
und Zielknoten, sondern auch die Kardinalität und die Attribute der Kanteninstanzen defi-
niert werden.