Das Datenmodell der ExpoDB

Bei Datenbanken unterscheidet man klassisch zwischen drei Ebenen:

• Das logische Modell oder Schema. Diese beschreibt die Gegenstände oder sog. "Entitäten", die man mit der Datenbank verwalten möchte. Es grenzt die verschiedene Typen dieser Entitäten ab, beschreibt ihre interne Zusammensetzung und wie sie untereinander verbunden sind. In einer Sammlungsdatenbank möchten wir z.B. unter anderem die Objekte in unseren Sammlungen verwalten sowie die Personen, die diese Objekte geschaffen haben. Die Sammlungsobjekte haben Attribute wie z.B. Inventarnummer und Werktitel. Die Personen haben Attribute, wie z.B. Nachnamen oder Geschlecht. Zu einem Sammlungsobjekte können mehrere Personen als Urheber:innen gehören, wie eine Person auch mehrere Objekte in der Sammlung geschaffen haben kann (Man sagt Objekte und Personen stehen in einer n zu m Beziehung). Insgesamt ist das logische Modell natürlich viel komplexer.
• Über dem logischen Modell gibt es die Ebene der Formulare und Masken. Diese Nutzungs-Ebene orientiert sich an der Bedienbarkeit über den Bildschirm. Masken können Attribute unterschiedlicher Entitäten zusammenführen. Entitäten oder einzelne Attribute können auch parallel auf verschiedenen Masken zugänglich sein. Da der Fokus hier die Praktikabilität beim Arbeiten ist, und nicht die zugrundeliegende Konstruktion, ist diese Ebene nicht optimal, um über die Struktur der Datenbank nachzudenken.  
• Die im logischen Modell festgelegten Entitäten und Zusammenhänge müssen schließlich noch in einer physischen Datenstruktur "auf der Festplatte" realisiert werden. Hier stehen performante Routinen im Vordergrund, um die Daten abzurufen und nach vielfältigen Kriterien zu selektieren. Sowie um sichere Updates auf den Daten durchzuführen, die die sog. Konsistenzbedingungen des logischen Modells bewahren. Auch diese sehr technische Ebene eignet sich nicht für die Auseinandersetzung mit der Datenbank. Am besten man lässt das Datenbankmanagementsystem diese konkreten Datenstrukturen automatisiert aus dem logischen Modell generieren und optimiert diese "Physische Ebene" bestenfalls behutsam.

Man unterscheidet drei Ebenen der Datenmodellierung

Insofern sollte eine Diskussion von Datenbanken am besten auf der Ebene des logischen Modells geführt werden (Sicher sollte man dabei im Hinterkopf behalten, dass jedes logische Modell auch in Datenstrukturen "physisch" realisiert werden muss. Und es muss auch schließlich auch eine praktikable Benutzeroberfläche am Bildschirm entstehen.)

Eine landläufige Art über logische Modelle nachzudenken, sind die Tabellen von relationalen oder sog. SQL-Datenbanken. Jede Entität, die in der Datenbank verwaltet werden soll, wird durch eine Tabelle repräsentiert. Und die Attribute durch deren Spalten. Durch Schlüsselspalten werden Zusammenhänge zwischen verschiedenen Entitäten bzw. Tabellen beschrieben: Zwei Datensätze unterschiedlicher Entitäten gehören zusammen, sofern sie in der Schlüsselspalte gleiche Werte aufweisen. Wiederholbare, selbst komplex zusammengesetze Datenkomponenten werden durch Hilfstabellen realisiert. Dieses Konzept ist sehr einfach und sehr leistungsfähig und kann sehr viele Zusammenhänge sehr gut beschreiben. 

Imdas pro basiert auf einer relationalen Datenbank. Doch leider orientiert sich imdas pro nicht am oben skizzierten Konzept. Es gruppiert Attribute anders in Tabellen und mischt gelegentlich Aspekte der physischen Realisierung in das logische Schema. Z.B. enthält eine Tabelle "OBJECT" gleichzeitig Attribute zu Sammlungsobjekten und Personen. Viele Tabellen haben gar nichts mit den Sammlungsobjekten zu tun, die verwaltet werden sollen. Sondern z.B. mit dem Layout von Masken und Reports oder sie sind schlicht Altlasten. Insgesamt ist das Datenbankschema von imdas pro daher kein guter Anknüpfungspunkt zum Nachdenken über die Strukturierung der Sammlungsdokumentation. Das Datenbankschema steht bei imdas pro daher auch eher im Hintergrund..

Für die ExpoDB wird die Daten daher in ein logisches Modell transformiert, das ein Verständnis der Sammlungsdaten und ihrer Zusammenhänge möglichst erleichtern soll. Das Ziel ist, dass möglichst viele Beteiligte bei den Daten in der ExpoDB mitreden können. Beteiligt sind natürlich die, die Daten in imdas pro eingeben und die Bestände in imdas-pro pflegen. Beteiligt sind auch die Kommunikationsabteilungen der Museen, die mit diesen Daten z.B. Digitale Kataloge konzipieren wollen. Beteiligt sind die Webagenturen, die die Digitalen Kataloge programmieren. Beteiligt können evtl. auch Projektpartner der Museen sein, die die Daten weiter auswerten. Beteiligt sind nicht zuletzt die Mitarbeiter:innen von Musis, die u.a. die Daten in die ExpoDB aus imdas importieren. Alle diese Beteiligten sollen mit der ExpoDB eine gemeinsame Sprache ("Ubiquitous Language") finden, in der sie über die Daten diskutieren können. 

Die Basis einer gemeinsamen Sprache sind gemeinsame Begrifflichkeiten. Zum Beispiel verwendet imdas pro für das, was in diesen Text hier mit "Entität" bezeichnet wird, den Begriff "Objekttyp". Er unterscheidet in imdas pro Sammlungsobjekte von Personen, Medien, Konvoluten, Provenienzen... Verbindet man mit dem Begriff "Objekt" enger nur Sammlungsobjekte, würde man unter "Typ" eine Klassifizierung in Gemälde, Münzen, Druckgrafik etc. erwarten. Dies wird in imdas pro wiederum über die "Objektbezeichnung" geleistet. Die Frage ist nun, ob man sich mit der gemeinsamen Sprache auf die Terminologie von imdas pro stützen möchte. Weil diese bereits vielen vertraut ist, die mit imdas pro arbeiten. Oder ob dies nicht die Gefahr birgt, dann in jeder Hinsicht nur in den Möglichkeiten von imdas pro zu denken. Ich persönlich habe z.B. unter Objektbezeichnung lange Zeit so etwas wie ein weiterer Titel oder Namen vermutet, was zumindest nicht ganz richtig war...

Es gibt umgekehrt auch "Nicht-Beteiligte" an der gemeinsamen Sprache. Z.B. wurden Daten aus imdas pro im SAP-System des Landes verwendet. Es wäre offensichtlich sinnlos anzustreben, dass die Sammlungsdokumentation die Sprache der Finanzverwaltung spricht oder umgekehrt die Finanzverwaltung die Sprache der Sammlungsdokumentation. Oder z.B. hat die Deutsche Digitale Bibliothek für Datenlieferungen aus Museen LIDO festgelegt. LIDO ist ein Transferformat und eignet sich nicht direkt als Datenmodell in der Sammlungsdokumentation. Dies ist auch nicht seine Absicht. Auch die breite Öffentlichkeit (z.B. in Digitalen Katalogen) erfordert eine andere Sprache (oder parallel sogar mehrere verschiedene Sprachen pro Publikum), die nicht sinnvoll gleichzeitig die interne Sprache der ExpoDB oder der Sammlungsdokumentation sein kann. Es ist also auch wichtig, die Erstreckung der Sprachverwendung ("Bounded context") zu definieren. Wo dann explizit Schnittstellen und Übersetzungen in andere Sprachen nötig sind, sofern Nicht-Beteiligte mit den Daten etwas anfangen sollen. Es ist jedenfalls hilfreich, zu wissen, wie weit man mit den gleichen Begriffen dasselbe meint. Und wann evtl. unterschiedliches. 

Um gemeinsam zu Modellieren ist wichtig, wer eine gemeinsame Sprache finden muss, und wer extern über Schnittstellen zu bedienen ist.

Für die Datenmodellierung in der ExpoDB ist es vorteilhaft, dass sie sich JSON und XML bedient, um Daten auszudrücken (Dabei werden nur XML so eingesetzt, dass es sich direkt in JSON-Syntax übersetzen lässt und umgekehrt - ohne dass sich die Semantik der Daten verändert). JSON und XML haben hier verschiedene Vorteile: Sie sind gleichzeitig von Menschen als auch von Maschinen lesbar. Insofern nehmen JSON- sowie XML-Daten gleichzeitig die Rollen von logischem Schema, Nutzerschnittstelle und physischer Realisierung wahr: JSON- und XML-Files sind Textdateien, die einfach aufzubewahren und auszutauschen sind. Sie können in jedem Texteditor editiert werden und Internet-Browser formatieren die beide Formate ansprechend, sodass man auch ihre Struktur leicht erfassen kann (evtl. benötigt man ein Plugin).

JSON und XML sind "baumartig" strukturiert. Dies meint, sie strukturieren Daten nicht nur in Zeilen und Spalten wie Tabellen bei relationen Datenbanken, in Excel oder in einer CSV-Datei. JSON und XML können komplex aufgebaute Komponenten enthalten, welche wiederum komplex aufgebaute Komponenten enthalten können, usw.. Solche Konstruktionen sind hilfreich für Datenelemente, die eng zusammengehören, die aber nicht selbst wie eine Entität ein unabhängiges gedankliches Konzept darstellen. Z.B. gehört in einer Maßangabe die Dimension, der Betrag und die Einheit immer zusammen. Es macht jedoch keinen Sinn "die Länge 3 cm" für sich, losgelöst von seinem Objekt zu betrachten. Oft, auch bei Maßen, wiederholen sich solche Datenkomponenten. Auch dafür hält JSON und XML Syntax bereit. Andere Beispiele sind z.B. Aliasnamen zu Personen oder zusätzliche Nummern zu einem Sammlungsobjekt. Das relationale Konzept benötigt, wie erwähnt, für solche Situationen Hilfstabellen. Mit XML bzw. JSON lassen sich solche Daten direkt in die Entitäten einbetten, was die Struktur besser beschreibt. Lediglich zur Darstellung von Beziehungen zwischen Entitäten sind weiterhin Relationierungen via Schlüsselpaaren notwendig. 

Das Modell der ExpoDB kennt innerhalb der Entitäten wie Museumsobjekte und Personen, neben Feldern auch in sich komplexe, wiederholbare Komponenten.

In diesem ersten Teil wurde behandelt, welche Überlegungen und Konzepte hinter der Modellierung in der ExpoDB stehen. Im zweiten Teil wird es konkreter darum gehen, welche Entitäten konkret in der ExpoDB verwaltet werden. Wie sie sich aus Attributen und komplexeren Komponenten zusammensetzen. Und welche Zusammenhänge die unterschiedlichen Entitäten untereinander haben. 

Nächster Beitrag: Die Entitäten der ExpoDB