Dynamisches Daten Modell

Komplexe, beziehungslastige Datenstrukturen beschreiben

Datenmodell Typen

Grob gerechnet, lassen sich zwei Typen von Datenmodellen unterscheiden. Zum einen das heute am meisten verwendete tabellenartige Modell (Entity-Relationship), das mittels der Anfragesprache SQL angesteuert wird. Datenstrukturen werden in Tabellen mit Spalten atomarer Werte »flachgeklopft«. Beziehungen werden über Schlüssel- und Fremdschlüssel relational abgebildet. Hierarchische Beziehungen sind nur unnatürlich abzubilden.

Das zweite, weit verbreitete Datenmodell, das weniger zum Speichern der Daten Verwendung findet, sich vielmehr als Abbildung der Daten im Hauptspeicher eignet, ist das Objektorientierte Datenmodell, überlicherweise als UML-Klassen-Diagramm dargestellt.

Das OO-Modell ist ausdrucksstärker, Beziehungen jeder Art, auch hierarchische, können natürlich abgebildet werden. Gleichzeitig sind schnelle Zugriffspfade wie Indizes explizit auszuformulieren und nicht nahtlos in das Modell integriert, weiterhin sind Relationen, Schlüssel- und Fremdschlüsselbeziehungen leider auch nicht natürlicher Bestandteil. Die Verallgemeinerung verliert sich in detaillierter Komplexität. OO-Programmiersprachen bieten nur wenig bis gar keine – von LINQ einmal abgesehen – Unterstützung von komplexen Datenmodellen.

Der Weg zur Lösung

An dieser Stelle kann ich kein neues, allgemeingültiges Datenmodell entwerfen, jedoch mit einer Idee den ersten Schritt eines Weges gehen, dessen langfristiges Ziel die Vereinheitlichung der Datenmodelle ist, mittelfristig die Erstellung komplexer OO-Modelle erleichtert.

Natürlich ist die Idee umfangreicher, als hier dargestellt. Dinge wie automatische Speicherverwaltung (Garbage-Collection), Verteilung der Daten über mehrere Netzwerkknoten, Clustering der Daten, Implementierung einer virtuellen Maschine und Definition eines Bytecodes zur dynamischen Erweiterung des Modells in OS- und hardwareunabhängiger Weise gehören dazu. Sie sind ohne unterstützende Entwicklungswerkzeuge – die für sich genommen eigenständige Projekte sind – jedoch nicht vernünftig umzusetzen.

Einschränkungen

Der erste Schritt auf dem Weg besteht nun darin, Dinge auszuschließen, um sich nicht in der Detailliertheit des Gesamten zu verlieren. Alles das, was sich nicht aus der natürlichen Weiterentwicklung des schon Vorhandenen ergibt, wird also verworfen.

Zunächst widmen wir uns dem ersten Einsatzgebiet des Datenmodells. Es soll uns erlauben, bestehende C-Datenstrukturen (struct type_t) mit Werten und Zeigern sowie Listen, (Suffix-)Bäume, Tries zu einem Ganzen zu verbinden. Die Dynamik des Modells besteht darin, daß es per C-API bzw. textueller Beschreibung um neue Datentypen (Objekte, Indizes und Beziehungen) erweitert werden kann.

Das Datenmodell soll uns also erlauben, bestehende C Datenstrukturen einfacher miteinander zu kombinieren und automatisch die Einhaltung von Beziehungen, Invarianten usw. zwischen den einzelnen Teilen sicherzustellen, um den C Programmierer so von der manuellen und fehleranfälligen Aufgabe der Einhaltung der Konsistenzbe­din­gungen zu befreien.

Konzept

Das vorläufige Konzept liest sich einfach. Eine textuelle Beschreibung des Datenmodells wird einem DDM-Übersetzer gelesen und eine interne Repräsentation verwandelt. Daraus resultiert eine Instanz eines DDM-Typ-Kataloges.

                       (liest)
------------------------    ╭────────────────────╮
  DataModel Definition  --> │  DDM-Übersetzer    │
     (Text Datei)           │  (DDM-Parser)      │
------------------------    ╰────────────────────╯
                            ↓ (erzeugt)
   ╭────────────────────╮
   │  DDM Typ Katalog   ├───◯  Catalog-Interface
   │  (Type Catalog)    │
   ╰──────────────▴─────╯
                  │1
   ╭──────────────┴──────╮   ╭────────────────────────╮
   │  Datenbank Instanz  ├──▸│  DB Datensatz Speicher │
   │  (DB Instance)      │  1│  (DB InMemory Store)   │
   ╰─┬────────┬───────┬──╯   ╰────────────────────────╯
     ◯        ◯       ◯
    Catalog-  Query-  Update- Interface

Um eine Datenbank mit dynamischem Datenmodell anzulegen, muss eine Datenbankinstanz, parametriert mit dem entsprechenden DDM-Typ-Katalog, erzeugt werden. Die Datenbankinstanz verwaltet zusätzlich den die Datensätze enthaltenden Speicher. Die Struktur der Datensätze ist gemäß den Typen aus dem DDModell definiert.

Einer Datenbankinstanz kann mittels Kataloginterface die Beschreibung der Datentypen entlockt werden. Mittels Query- und Updateinterface können Datensätze gelesen, angelegt und geändert werden.

typedef char[2] LANG;

struct textdef_t {
   LANG       language;
   u16        len;
   char[len]  text;
}

struct textres_t {
   textdef_t[textdef_t.language] translations;
}

struct resource_file_t {
   u16             len;
   char[len]       filename;
   set(LANG)       lang;
   list(rextres_t) textresources;

   invariant
      textresources.translations.language in lang
      ;
}