Seitenhistorie

...

• 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 Gegenstände Entitäten ab, beschreibt ihre interne Zusammensetzung und wie sie untereinander zusammenhängen. 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 intern 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:in gehören, wie eine Person auch mehrere Objekte in der Sammlung geschaffen haben. Das logische Modell ist natürlich insgesamt 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 Gegenstände Entitäten zusammenführen. Gegenstände Entitäten oder deren Attribute können auch parallel auf verschiedenen Masken zugänglich sein. Das der Fokus hier die Ergonomie ist, ist diese Ebene nicht optimal, um über die Struktur der Datenbank nachzudenken.  
• Die im logischen Modell festgelegten Gegenstände 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 Festlegungen des logischen Modells, die sog. Konsistenz, 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.

...

Eine landläufige Art über logische Modelle nachzudenken, sind die Tabellen von relationalen oder sog. SQL-Datenbanken. Jeder GegenstandJede Entität, der 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 Gegenständen Entitäten bzw. Tabellen beschrieben: Zwei Datensätze gehören zusammen, sofern sie in der Schlüsselspalte gleiche Werte aufweisen. Ergänzt um ein paar Hilfstabellen ist dieses Konzept sehr einfach und sehr leistungsfähig und kann sehr viele Zusammenhänge sehr gut beschreiben. 

...

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. Beteiligt sind auch die in den Kommunikationsabteilungen der Museen, die mit diesen Daten z.B. verständliche 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 finden, in der sie über die Daten diskutieren können. 

Es gibt umgekehrt auch nicht Beteiligte. 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 beabsichtigt nicht, sich direkt als Datenmodell in der Sammlungsdokumentation zu dieneneignen. Schließlich benötigt auch die breite Öffentlichkeit eine z.B. "Einfache Sprache" in Digitalen Katalogen (oder parallel sogar mehrere verschiedene Sprachen pro Publikum), die nicht sinnvoll die interne Sprache der ExpoDB sein kann. Es ist also auch wichtig die Grenze der Sprachverwendung zu definieren. Wo dann explizit Schnittstellen und Übersetzungen in andere Sprachen nötig sind. Jedenfalls es ist aber hilfreich, zu wissen, wie weit man mit den gleichen Begriffen dasselbe meint. Und wann evtl. unterschiedliches. 

...

Über die oben skizzierten Tabellen und ihre Relationen via Schlüsselbeziehungen hinaus kennt die ExpoDB noch ein weiteres Konstrukt: Es gibt Datenelemente, die eng zusammengehören, die aber nicht ein gedankliches Konzept darstellen, das für sich separat verwaltet werden sollte. Z.B. gehört in einer Maßangabe die Dimension, der Betrag und die Einheit immer zusammen. Es macht jedoch keinen Sinn "Länge 3 cm" für sich, losgelöst von seinem Objekt zu betrachten. Oft, auch bei Maßen, wiederholen sich solche Datenkomponenten. Neben den "atomaren" Attribute kennt die Modellierung der ExpoDB daher auch solche intern komplex zusammengesetzten "Komponenten", die sich wiederholen können. Andere Beispiele sind z.B. Aliasnamen zu Personen oder zusätzliche Nummerrn zu einem Sammlungsobjekt. Das relationale Konzept bildet solche Situationen in Tabellen ab. Da die ExpoDB mit XML bzw. JSON arbeitearbeitet, lassen sich Komponenten direkt darstellen.

...

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 Gegenständen Entitäten konkret in der ExpoDB verwaltet werden. Wie sie sich aus Attributen und komplexeren Komponenten zusammensetzen. Und welche Zusammenhänge die unterschiedlichen Gegenstände Entitäten untereinander haben.