Das Intuitive Datenmodell III - Container als Dokumente

Im Intuitiven Datenmodell (IDM) sind alle Werte einzigartig. Es gibt nur einen Vornamen "Peter" und nur einen Preis 12,34, egal in wievielen Containern diese Daten vorkommen. Aber das gilt nicht nur für solche atomischen Daten, sondern auch für Zusammensetzungen!

Um das zu verdeutlichen, nehmen Sie eine relationale Datenbank mit einer Tabelle für Personen an:

Personen(Vorname, Nachname)

In der Tabelle stehen einige Datensätze:

Personen("Peter", "Mustermann")
Personen("Frank", "Müller")
Personen("Gabi", "Mustermann")
Personen("Gabi", "Müller")
Personen("Susanne", "Frank")

"Gabi" und "Frank" und "Mustermann" sind in der relationalen Datenbank selbstverständlich mehrfach enthalten, weil sie ja in mehreren Datensätzen vorkommen. Nicht so aber in einer intuitiven Datenbank (IDB)! Dort gibt es alle Zeichenketten nur einmal - unabhängig davon, wie sie in Containern gebraucht werden, d.h. ob sie einen Vornamen oder einen Nachnamen darstellen.

"Gabi" usw. sind im IDM atomische Werte (Atomic Value, AV). Für eine IDB sind sie quasi unteilbar, sozusagen kleine Blobs ohne weitere Struktur. Sie entsprechen den Spalten im Relationalen Datenmodell oder Feldern in Klassen des Objektorientierten Datenmodells.

Die Zusammensetzungen solcher AVs sind, wie könnte es anders sein, zusammengesetzte Werte (Composite Values, CV). Anders als im Relationalen Datenmodell sind CVs allerdings beliebig tief schachtelbar. Die Schachtelungstiefe in einer relationalen Datenbank ist flach: Tabelle/Satz/Spalte. Das war´s. Bei Klassen ist es etwas anders, da können Felder Strukturen (struct) enthalten, die wiederum Strukturen enthalten können usw. Objekte sind in anderen allerdings nicht physisch enthalten wie Datensätze in Tabellen. Wenn man davon spricht, dass ein Objekt ein anderes enthält, dann ist das nur eine logische Enthalten-Beziehung, die durch Referenzen hergestellt werden muss.

Das IDM steht mit seiner beliebig tiefen Schachtelung, die keiner Ebene irgendeinen Vorrang gibt, daher dem XML Datenmodell am nächsten. Deshalb möchte ich die "Dateneinheiten", die man einer IDB zur Speicherung übergibt oder aus ihr ausliest, auch Dokumente nennen. Damit soll natürlich keine Nähe zu Word- oder Excel-Dokumenten suggeriert werden. Dokumente sind einfach nur Zusammenfassungen von Werten in einer für einen bestimmten Zweck geeigneten Struktur. Ob diese Werte dann Kalkulationen oder eine Bibliographie oder Kontaktdaten darstellen, ist unerheblich. Alles kann zu einem Dokument zusammengefasst werden. Und alles kann auch in immer wieder neuen Dokumenten zu einander in Bezug gesetzt werden.

Die obigen Daten könnten einer IDB also z.B. in Form mehrerer Dokumente zur Speicherung übergeben werden. Das IDM basiert nicht auf XML, aber ich kann XML zur Beschreibung von IDB Dokumenten benutzen. Dann sähen die Dokumente für die obigen Daten z.B. so aus:

<Person>
<Vorname>Peter</Vorname>
<Nachname>Mustermann</Nachname>
</Person>

oder

<Person vorname="Peter" nachname="Mustermann"/>

Atomische Werte könnten als Subelemente oder als Attribute notiert werden.

Aber auch eine knappere Notation ist möglich, die eher der obigen für die Tabellen entspricht:

Person(Vorname("Peter"), Nachname("Mustermann"))

Sie steht XML ins nichts nach. Auch mit ihr kann ich Schachtelungen ausdrücken:

Personen(
Person(Vorname("Peter"), Nachname("Mustermann"))
Person(Vorname("Klaus"), Nachname("Müller"))
)

Welche Notation ich im Folgenden benutze, hängt wahrscheinlich von meiner Tagesform ab ;-) Beide sind einfach zu lesen, denke ich.

Eine Abbildung nach XML ist mir vor allem wichtig, um zu zeigen, dass das IDM nicht nur "outspacet" ist. Wer XML kann, der hat im Grunde von viel vom IDM verstanden.

Und eine Abbildung auf zwei Notationen ist mir wichtig, um klar zu machen, dass das IDM eben letztlich notationsunabhängig ist. Beim IDM geht es nicht wie bei XML ursprünglich nur um Text. Es geht um ein Werteuniversum - dessen Inhalt sich auch in eine textuelle Dokumentenwelt abbilden lässt. Denn wie die Dokumente bzw. Daten intern abgelegt sind, ist unerheblich für das Intuitive Datenmodell. Es muss nur verwirklicht sein. Insofern ist auch eine objektorientierte Schnittstelle denkbar, z.B.

IIntuitiveDatabase db;
...
ICompositeValue person = db.CreateCV("Person");
person.Subvalues.Add(db.CreateAV("Vorname", "Peter"));
person.Subvalues.Add(db.CreateAV("Nachname", "Mustermann"));
...
db.Store(person);

Aber das sind im Augenblick Details. Wichtig ist, dass IDBs Dokumente speichern und liefern. Allerdings werden diese Dokumente nicht 1:1 in einer IDB abgelegt. Eine IDB speichert ja keine Kopien von Daten. Vielmehr werden die Dokumente "geshreddert" und so mit den schon vorhandenen Dokumenten "verwoben", dass den Bedingungen des IDM Genüge getan ist. Statt speichern würde ich eher sagen, dass IDBs Dokumente assimilieren. Sie nehmen sie auf, machen sie sich zu eigen - aber die Dokumente selbst verschwinden in dem Vorgang. Sie sind in der IDB nicht mehr ohne Weiteres erkennbar. Selbstverständlich kann man sie aber dennoch wieder herausbekommen ;-) Das Speichern von Daten in einer IDB ist insofern verlustfrei.

Wenn ich sage, dass die Dokumente bei der Assimilierung verschwinden, dann möchte ich damit vor allem ausdrücken, dass eben keine einfachen Kopien von Daten in einer IDB abgelegt werden. Wenn ich Daten einer relationalen Datenbank hinzufüge (z.B. Personen mit jeweils mehreren Adressen), dann führt das quasi immer dazu, dass neue Datensätze erzeugt werden. Füge ich ein Dokument mit demselben Inhalt einer IDB hinzu, dann kann es aber sein, dass nichts passiert oder nur sehr wenig. Denn wenn ein neues Dokument Werte enthält, die schon assimiliert wurden, dann werden die eben nicht nochmals in der IDB angelegt.

Insofern würde ich auch nicht sagen, dass in einer IDB diese oder jene Dokumente stecken. Die Dokumente A, B und C mögen assimiliert worden sein. Sie sind also schon in der IDB irgendwie drin und können auch wieder herausgeholt werden. Viel wichtiger ist aber das große Ganze, das durch die Assimilation entstanden ist. Aus dem können nämlich nicht nur A, B und C wieder generiert werden, sondern auch noch viele andere, neue, unvorhergesehene Dokumente, die sich quasi "einfach so" ergeben, weil A, B und C Gemeinsamkeiten aufweisen.

Diese Gemeinsamkeiten müssen dabei nicht nur bei AVs liegen, sondern können auf jeder Ebene eines Dokuments, d.h. bei den CVs liegen. Das (!) ist der entscheidende Unterschied zu einer relationalen Datenbank oder einer XML-Datenbank.