Seitenhistorie

...

• Das logische Modell oder Schema. Diese beschreibt die Gegenstände, die man mit der Datenbank verwalten möchte. Es grenzt die verschiedene Typen dieser Gegenstände 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 zusammenführen. Gegenstände 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 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.

Image Added

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 Benutzeroberfläche am Bildschirm entstehen.)

...

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 direkt als Datenmodell in der Sammlungsdokumentation zu dienen. Schließlich benöigt auch die breite Öffentlichkeit eine eigene Ansprache z.B. in Digitalen Katalogen, oder parallel sogar mehrere, die nicht sinnvoll die interne 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. 

Image Added

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

Ü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 "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 arbeite, lassen sich Komponenten direkt darstellen.

Image Added

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