Objekttypen

Objekttyp

Regeln für die Namen von Objekttypen

Um interne Konflikte mit den Namen von Objekttypen zu vermeiden, gelten für alle Objekttypnamen die folgenden Regeln:

• Kein Objekttyp darf mit dem Präfix ez_ beginnen (Groß- und Kleinschreibung wird nicht beachtet)

• Ein Objekttyp muss den folgenden regulären Ausdruck erfüllen: ^[a-z][a-z0-9_]{0,61}[a-z0-9]$

  • Nur kleine Buchstaben des englischen Alphabets (a - z), Zahlen oder Unterstriche _ sind erlaubt
  • Mindestlänge 2 Zeichen, Höchstlänge 63 Zeichen
  • Muss mit einem Buchstaben beginnen

• Als Name für einen Objekttypen ist keine der folgenden geschützten Systemtabellen erlaubt:

  • pool
  • collection
  • user
  • group
  • message

Felder

Keine leeren Einträge (NOT NULL Constraint)

Ein NOT NULL Constraint kann für einfachen Feldern (auf Top Level Ebene und in Mehrfachfeldern), und ebenso auf Mehrfachfelder selbst gesetzt werden. Dabei wird NOT NULL unterschiedlich umgesetzt.

Für einfache Felder wird direkt in der Datenbank ein NOT NULL Constraint gesetzt. Das bedeutet, dass dieses Feld generell nicht leer sein kann. Dies sorgt u.a. auch dafür, dass ein Datenmodell nicht eingespielt werden kann, wenn ein NOT NULL Constraint neu gesetzt wird, und vom betroffenen Objekttyp bereits Objekte existieren, die dieses Constraint verletzen würden.

Im Gegensatz dazu wird das NOT NULL Constraint für Mehrfachfelder anders interpretiert: Es muss mindestens einen Eintrag in dieser Tabelle für jedes Objekt geben. Dies wird nur über die Import-API geprüft, also beim Speichern von Objekten. Dies gilt für den Editor, den Gruppeneditor und den JSON Importer.

Das Constraint wird in den folgenden Fällen nicht geprüft, so dass hier leere Mehrfachfelder möglich sind:

• Datenmodellaktualisierungen
• Löschen von verlinkten Objekten, die dann ein leeres Mehrfachfeld zurücklassen können

Editierbar in Verlinkung

Im Gegensatz zum vorwärts Verlinken, wobei eine easydb-ID des verlinkten Datensatzes am Hauptdatensatz gespeichert wird (als Verweis auf diesen Datensatz), wird beim Editieren in der Verlinkung, also beim rückwärts Verlinken, ein Datensatz als Teil eines anderen Datensatzes gespeichert.

Objecttype: Subject
Subject-ID    134
Title         Viele Bäume

  ^ Objekttyp: Term
  ^ Term-ID             89
  ^ Term-Subject-ID     134
  ^ Term-Title:         Wald

  ^ Objekttyp: Term
  ^ Term-ID             90
  ^ Term-Subject-ID     134
  ^ Term-Title:         Forest

In diesem einfachen Beispiel haben wir zwei Objekttypen angelegt: Subject und Term. Ein Benutzer kann im Subject-Editor an einem Subject mehrere Terms abspeichern. Im Term-Editor kann der vorwärts Link zum Subject genutzt werden, um genau ein Subject zu verlinken. Beim rückwärts Verlinken gehören die verlinkten Datensätze (2 Terms) fest zum Hauptdatensatz (Subject), d.h. wenn das Subject mit nur einem Term neu gespeichert wird, wird der nicht mehr verlinkte Term gelöscht. Beim vorwärts Verlinken würde nur die Verlinkung gelöst, nicht aber der Datensatz selbst. Rückwärts verlinkte Objekte verhalten sich wie Mehrfachfelder, die fest zum Datensatz gehören, können dabei aber auch separat bearbeitet und gesucht werden.

Bidirektional

Beim Speichern von Verlinkungen zwischen zwei Datensätzen entsteht eine Richtung der Verlinkung (vorwärts oder rückwärts). Die Richtung ist entscheidend für die Sichtbarkeit der Datensätze, je nachdem von welcher Seite der Datensatz betrachtet wird. Um es an einem Beispiel zu verdeutlichen, soll Bild 198 mit Bild 166 und Bild 168 verlinkt werden. Beispiel 1: die Verlinkung wird über ein Mehrfachfeld Andere Bilder realisiert. Beispiel 2: die Verlinkung wird mit einem separaten Objekttyp Bild-An-Bild realisiert.

In beiden Fällen soll nun die Verlinkung von Bild 166 bzw. 168 zum Bild 198 sichtbar sein.

Bsp. 1: In einem Mehrfachfeld

Dafür wird im ersten Beispiel das Feld Andere-Bild-ID als Bidirektional markiert. Damit weiß easydb, dass eine Verlinkung in beide Richtungen funktionieren soll. In der Datenbank werden Einträge für jede Richtung erzeugt, d. h. beim Speichern von Bild 198 werden an den Bildern 166 und 168 jeweils die Mehrfachfeld-Einträge automatisch abgespeichert.

Objekttyp: Bild

Daten:

Bsp. 2: In einem separaten Objekttyp

Im zweiten Beispiel werden im separaten Objekttyp Datensätze, die den Link in die andere Richtung aufbauen, automatisch erzeugt. Durch die Einstellung Editierbar in Verlinkung werden die Bild-An-Bild Einträge des verlinken Bildes im Editor des Hauptdatensatzes editiert. Fügt man dort nun zwei Verlinkungen zum Bild 168 und 166 ein, werden automatisch zwei Datensätze für den Link in die andere Richtung geschrieben. Ruft man nun den Editor für Bild 166 bzw 168 auf, erscheint dort als Bild-An-Bild Eintrag die Verlinkung zum Bild 198.

Objekttyp: Bild

Objekttyp: Bild-An-Bild

Daten:

Objekttyp: Bild

Objekttyp: Bild-An-Bild

Bidirektional Reverse

Die Markierung eines Feldes als Bidirectional Reverse sorgt dafür, dass in einem bidirektionalen Kontext vorwärts Verlinkungen mit unterschiedlichen Attributen versehen werden und hierdurch typisierte bidirektionale Links entstehen. Im Falle bidirectional wird somit der Link 1 zu 1 kopiert und im Fall bidirectional reverse erhält der Link unterschiedende Attribut.

Die Einrichtung im Datenmodell ist für Bidirektional und Bidirektional Reverse gleich. In beiden Fällen wird bei der Verlinkung vorwärts auf die gleich Tabelle verwiesen.

HINWEIS: Bei Einfachfeldern (Top-Level) müssen es zwei vorwärts Links sein, bei Mehrfachfeldern (Nested) reicht ein Link auf den Top-Level Objekttyp.

Beim Einfügen von tt1 wird tt2 automatisch erzeugt. tt1 enthält als Linktyp l1, easydb schreib den Rücklink als l2 in tt2.