Metadaten - Praktische Informatik
Werbung
Metadaten Udo Kelter 09.11.2008 Zusammenfassung dieses Lehrmoduls Metadaten sind Daten über (Nutz-) Daten. Metadaten treten in Datenbanken, in der Dokumentverwaltung, bei der Software-Modellierung und in vielen weiteren Kontexten auf. Entitätsbezogene Metadaten sind einzelnen Nutzdatengranulaten, typbezogene Metadaten hingegen dem Typ von Nutzdatengranulaten zugeordnet. Systeme, die Metadaten im gleichen Datenbankmodell wie die Nutzdaten repräsentieren, nennt man selbstreferentiell. Typbezogene Metadaten (Schemata) sind instantiierbar, wenn ein DVS verfügbar ist, das die Instantiierung durchführt. Die auftretenden Metadaten, deren selbstreferentielle Darstellung und die entstehende Metadaten-Hierarchie untersuchen wir für relationale Datenbanken und XML-Dateien. Vorausgesetzte Lehrmodule: obligatorisch: – Datenverwaltungssysteme – Architektur von DBMS – Einführung in SQL Stoffumfang in Vorlesungsdoppelstunden: 1 1.5 Metadaten 2 Inhaltsverzeichnis 1 Einordnung und Motivation 1.1 Metadaten in Datenbanken . . . . . . . 1.2 Metadaten in der Dokumentverwaltung 1.3 Metadaten vs. Nutzdaten . . . . . . . . 1.4 Selbstreferentialität . . . . . . . . . . . . 1.5 Sprachebenen in der Linguistik . . . . . . . . . . 3 4 5 6 7 8 2 Arten von Metadaten 2.1 Typbezogene vs. entitätsbezogene Metadaten . . . . . . . . . 2.2 Instantiierbare Metadaten . . . . . . . . . . . . . . . . . . . . 10 10 10 3 Selbstreferentialität in relationalen Datenbanken 3.1 Repräsentation relationaler Schemata durch Tabellen . . . . . 3.2 Zugriff auf selbstreferentiell repräsentierte Schemata . . . . . 3.3 Metatypen und Meta-Metadaten . . . . . . . . . . . . . . . . 3.4 Übersicht über die semantischen Ebenen . . . . . . . . . . . . 3.5 Meta-Ebenen vs. Implementierungsebenen von Datenbankobjekten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 13 15 16 19 4 Selbstreferentialität in XML 4.1 Aufbau von XML-Dateien . 4.2 Typ-Annotationen . . . . . 4.2.1 Typ-Annotationen in 4.2.2 Typ-Annotationen in . . . . 22 22 23 23 24 Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Glossar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 26 26 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . schwach strukturierten Daten . strikt typisierten Nutzdaten . 20 c 2008 Udo Kelter Stand: 09.11.2008 Dieser Text darf für nichtkommerzielle Nutzungen als Ganzes und unverändert in elektronischer oder gedruckter Form beliebig weitergegeben werden und in WWW-Seiten, CDs und Datenbanken aufgenommen werden. Jede andere Nutzung, insb. die Veränderung und Überführung in andere Formate, bedarf der expliziten Genehmigung. Die jeweils aktuellste Version ist über http://kltr.de erreichbar. Metadaten 1 3 Einordnung und Motivation Informell definiert man Metadaten als “Daten über Daten”, also Daten, die andere (Nutz-) Daten beschreiben oder einordnen, sie besser verständlich machen, ihre Struktur darstellen usw. Diese Definition unterstellt, daß es andere Daten gibt (oder gab oder geben wird, der Zeitpunkt ist unerheblich) und daß die Metadaten einen vorhandenen Informationsbedarf stillen. Der Begriff Metadaten ist alt, er wird immer wieder in neuen Kontexten und in neuen Variationen benutzt. Er ist ferner mit weiteren komplexen Begriffen wie Metaschema, Metamodell und Meta-CASE verbunden. Schließlich ist die Trennung zwischen Daten und Metadaten nicht immer eindeutig. Dies alles erklärt die regelmäßig auftretenden Konfusionen um diese Begriffe. Für Metadaten wichtige Kontexte waren und sind: – Dokumentverwaltung: Nutzdaten sind hier Bücher und andere elektronische Dokumente, Metadaten sind Angaben über Autor, Publikationsjahr, Verleger, ggf. persönliche Anmerkungen usw. Die wichtigste Dokumentsammlung ist inzwischen sicherlich das WWW; die Bezeichnung Metadaten wird seit einigen Jahren zunehmend mit diesem Kontext verbunden. – Datenbanken: hier treten neben den Nutzdaten diverse Arten von Metadaten auf, die wichtigsten sind die konzeptuellen Schemata. – Programmierung: in objektorientierten Sprachen ist das Prinzip der Reflexion (reflection) bzw. Introspektion verbreitet; bei Bedarf können hier Metadaten dynamisch erzeugt werden, die Informationen über die Typstruktur von Objekten darstellen. – System-Modellierung: man kann die Struktur von Modellen mittels Metamodellen spezifizieren; die UML benutzt diesen Ansatz durchgängig. In den folgenden Abschnitten analysieren wir die vorstehenden Fälle detaillierter, um Gemeinsamkeiten und Unterschiede herauszuarbeiten. c 2008 Udo Kelter Stand: 09.11.2008 Metadaten 1.1 4 Metadaten in Datenbanken Beim Stichwort Datenbankinhalt denkt man oft nur an die eigentlichen Nutzdaten, z.B. bei einer Adreßdatenbank an die Tupel, die jeweils eine Adresse darstellen. Auch wenn von Datenbankabfragen bzw. Datenmanipulationsoperationen die Rede ist, sind i.d.R. diese Nutzdaten gemeint. Neben den Nutzdaten gibt es aber noch weitere Daten, die ebenfalls mehr oder weniger notwendiger Inhalt einer Datenbank sind und die i.d.R. eigene Zugriffsschnittstellen haben: 1. die Datenbankschemata, also insb. die Definitionen der applikationsspezifischen Typen 2. Daten über die zugelassenen Benutzer und deren Rechte 3. Daten über die physische Organisation der Datenbank (z.B. Aufteilung auf Dateien oder logische Plattenlaufwerke, Datenträger, Archive u.ä.) und ggf. interne Schemata 4. ggf. Daten über integrierte Applikationen und speziell bei objektorientierten DBMS Daten über die Operationen einzelner Objekttypen 5. Angaben zur Herkunft der Daten: z.B. kann zu jedem Datum interessieren, wann und von welchem Benutzer es um letzten Mal geändert wurde An Rande erwähnenswert sind transiente Hilfsdaten. Beispiele hierfür sind die angemeldeten Anwendungsprozesse und die von ihnen gehaltenen Sperren. Bei manchen DBMS kann man diese Daten abfragen und so spezielle Informationsbedürfnisse befriedigen. Transiente Metadaten betrachten wir i.f. nicht weiter. Die im Kontext von DBMS auftretenden Arten von persistenten Metadaten können wir danach gruppieren, wer ggf. diese Daten lesen oder ändern möchte und welche Schnittstellen dafür benötigt werden: 1. Eine erste Gruppe persistenter Metadaten dient primär dazu, die logische Struktur der Daten zu beschreiben und das Verständnis von Sinn und Zweck der Daten zu unterstützen; man kann hier von semantischen Metadaten reden. Hierzu zählen die externen und c 2008 Udo Kelter Stand: 09.11.2008 Metadaten 5 konzeptuellen Schemata, Angaben zur Herkunft der Daten und Angaben zu den Applikationen, in denen die Daten verwendet werden. Es sind Schnittstellen erforderlich, durch die diese Metadaten von Applikationen abgefragt und ggf. auch geändert werden können. Ferner sind entsprechende Standard-Dienstprogramme wünschenswert; benutzt werden sie von Applikationsentwicklern beim Entwickeln und Testen der Applikationen und teilweise auch von Endnutzern. 2. Eine zweite Gruppe von persistenten Metadaten dient vor allem administrativen Zwecken. Hierzu zählen die internen Schemata, Zugriffsrechte, Verwaltung der Datenträger usw. Diese Metadaten spielen normalerweise (zum Glück) keine Rolle für die Applikationslogik oder den Endbenutzer, sie werden typischerweise nur vom Datenbank- bzw. Systemadministrator benutzt. Für die administrativen Metadaten muß es i.w. die gleichen Schnittstellen für Abfragen und Änderungen geben wie für die semantischen. Die Trennlinie zwischen semantischen und administrativen Metadaten ist nicht scharf, sie hängt von den individuellen Informationsbedürfnissen ab. Häufig besteht an den administrativen Metadaten kein Interesse, daher sie werden nicht als Metadaten wahrgenommen. 1.2 Metadaten in der Dokumentverwaltung Klassische Fälle von Dokumentsammlungen sind elektronische Bibliotheken und Büroinformationssysteme. Während diese Sammlungen noch halbwegs vorstrukturiert sind, ist das WWW als “Dokumentsammlung” extrem heterogen und unstrukturiert. Dementsprechend schwierig ist es, in solchen nicht oder nur schwach strukturierten Datenbeständen zu suchen und Metadaten zu systematisieren. Metadaten sind hier vor allem dazu gedacht, die Suche nach Dokumenten zu unterstützen. Der zentrale Dokumenttyp des WWW sind HTML-Seiten. HTMLDateien enthalten eine Mischung aus Nutzdaten, Metadaten und sehr c 2008 Udo Kelter Stand: 09.11.2008 Metadaten 6 viel Layout-Daten. Die Strukturen der Nutz- und Metadaten sind aus dieser Mischung kaum noch rekonstruierbar. Dementsprechend schwierig ist die Suche nach relevanten Daten. Eine wichtige Methode, diese Suche zu unterstützen, besteht darin, zu trennen zwischen 1. inhaltlich relevanten Daten, die in XML-Dateien gespeichert werden, und 2. Formatierungsangaben bzw. Layout-Daten, die z.B. in Style-Sheets verwaltet werden. Ein weiterer Vorteil dieser Trennung ist, daß Formatierungen abhängig von Benutzerpräferenzen oder Anzeigekontexten geändert werden können. Die Struktur von XML-Dateien kann durch Dokumenttypdefinitionen oder XML-Schemata beschrieben werden; diese spielen eine vergleichbare Rolle wie Datenbankschemata. 1.3 Metadaten vs. Nutzdaten Bei vielen Metadaten stellt sich die Frage, wieso man sie nicht als Nutzdaten ansieht, vor allem wenn auch der Endnutzer darauf zugreift, und ob hier nicht die konzeptionelle Trennung zwischen Nutzdaten und Metadaten zerstört wird. Die Antwort ist: 1. Daten sind dann Metadaten, wenn es einen Nutzdatenbestand gibt (oder gab oder geben wird), den die Metadaten beschreiben, und wenn die Metadaten zur Interpretation dieser Nutzdaten tatsächlich genutzt werden. Metadaten beziehen sich immer auf einen Nutzdatenbestand, ohne diesen sind sie keine Metadaten. Die tatsächliche Nutzung ist eine Frage des Standpunkts oder der Systemgrenzen, kann also subjektiv unterschiedlich beurteilt werden. Ein Beispiel sind Analyse-Datenmodelle (ER-Diagramme oder Analyse-Klassendiagramme): diese sind Metadaten für eine Person, die sie gebraucht, um entsprechende Nutzdaten zu verstehen oder zu dokumentieren, und nur Nutzdaten für einen ER- oder UML-Diagrammeditor. c 2008 Udo Kelter Stand: 09.11.2008 Metadaten 7 2. Die Speicherungs- bzw. Darstellungsform spielt keine Rolle dafür, ob Daten Metadaten sind oder nicht. Man kann z.B. die DBSchemata als Text repräsentieren oder durch Tabelleninhalte. Metadaten sind insofern normale Daten als man die Systeme, die Metadaten verwalten sollen, in den üblichen Phasen entwickeln muß: nach einer Anforderungsanalyse, welche Metadaten benötigt werden, kommt die übliche Entwurfs- bzw. Implementierungsphase. Es müssen persistente Darstellungen der Metadaten in Dateien oder Datenbanken festgelegt werden, transiente Darstellungen im Hauptspeicher und lesbare formatierte Darstellungen auf Ausgabemedien. Bei der Gestaltung dieser Darstellungen hat man viele Freiräume, dementsprechend vielfältig sind die Darstellungsformen von Metadaten. In vielen Systemen werden sowohl Nutzdaten wie Metadaten zusammen verarbeitet und z.B. gleichzeitig im Hauptspeicher gehalten. Die gemeinsame Verarbeitung mit Nutzdaten ist ebenfalls unerheblich dafür, ob Daten Metadaten sind. 3. Wer bzw. welches System die Metadaten ausnutzt, um die Nutzdaten zu interpretieren, ist ebenfalls unerheblich; entscheidend ist, daß die Metadaten überhaupt für diesen Zweck genutzt werden. In manchen Fällen werden Metadaten in der Bedienschnittstelle eines Informationssystems angezeigt, damit Anwender die Nutzdaten verstehen und einordnen können; ein Anwender nutzt die Metadaten mental aus, um die Nutzdaten richtig zu interpretieren. Metadaten werden oft auch ausgenutzt, um die Nutzdaten maschinell zu interpretieren oder zu verarbeiten. Hauptbeispiel sind die konzeptuellen Schemata; im DBMS-Kern werden sie dazu benutzt, um Schnittstellen zu den Nutzdaten zu realisieren, in Browsern oder ähnlichen Applikationen dazu, Standard-Darstellungen der Nutzdaten zu erzeugen. 1.4 Selbstreferentialität Eine ähnliche Frage wie die nach dem Unterschied zwischen Nutzdaten und Metadaten ist die Frage, ob man die Metadaten wie normale c 2008 Udo Kelter Stand: 09.11.2008 Metadaten 8 Nutzdaten, also im gleichen Datenbankmodell mittels eines passenden Schemas modellieren soll. Die Antwort ist: Für die Speicherungsform und technische Handhabung der Metadaten stehen im Prinzip alle Optionen offen, also auch die Modellierung im gleichen Datenbankmodell wie die Nutzdaten oder sogar die Speicherung in der gleichen Installation. Details hängen natürlich vom Datenbankmodell ab. Weiter unten werden wir am Beispiel von relationalen Datenbanken zeigen, wie man relationale Schemata durch Tabellen repräsentieren kann. Sofern Datenbankschemata oder vergleichbare Typdefinitionen eines Datenverwaltungssystem (DVS) als Nutzdaten repräsentiert werden, bezeichnet man dies auch als Selbstreferentialität1 . Die selbstreferentielle Verwaltung bzw. Repräsentation von Metadaten ändert natürlich nichts an dem inhaltlichen Charakter der Metadaten, Metadaten werden nicht zu Nutzdaten, nur weil sie technisch genauso wie die Nutzdaten verwaltet werden. Die Selbstreferentialität liegt insofern nahe, als die Datenbankschemata und andere DB-Metadaten sowieso innerhalb der Datenbank-Installation benötigt werden und irgendwie verwaltet werden müssen. Vorteilhaft ist ferner, daß man die Standardschnittstellen und Standardeditoren des Systems verwenden kann, um die Metadaten zumindest auszulesen. Veränderungen an den Metadaten dagegen verursachen erhebliche Probleme, die wir später diskutieren werden. 1.5 Sprachebenen in der Linguistik Metadaten weisen viele Parallelen zum Konzept der Metasprachen auf, das aus der Linguistik stammt. Eine zentrale Erkenntnis der Linguistik ist, daß sprachliche Aussagen auf verschiedenen semantischen Sprachebenen (anders gesagt Bedeutungsebenen) stehen können: 1 Der Begriff Selbstreferentialität ist nicht optimal, aber es gibt keinen völlig überzeugenden. Nicht gemeint ist hier Rekursion oder eine Referenz eines Objekts auf sich selbst. Selbstreferenzierung ist eigentlich ein linguistischer Begriff und bezeichnet das Phänomen, daß ein Text direkt oder indirekt Aussagen über sich selbst macht (“Jede Regel hat Ausnahmen.”). Es treten mehrere Sprachebenen auf, die Aussagen über den Text liegen auf einer Meta-Sprachebene. c 2008 Udo Kelter Stand: 09.11.2008 Metadaten 9 Die Basis bilden Aussagen in der sogenannten Objektsprache (“Hans Maier wohnt in Essen.”). Nicht mehr zur Objektsprache, sondern zur Metasprache erster Stufe gehören Aussagen über Aussagen der Objektsprache, z.B.: “Nachnamen fangen mit einem Großbuchstaben an.” “Eine Postleitzahl hat 5 Ziffern.” “Deutsche Sätze haben meist ein Subjekt und ein Prädikat.” Die vorstehenden Beispiele machen Aussagen zur Wortbildung und Syntax der Objektsprache. Darüber hinaus könnnen auch Aussagen zur Bedeutung und zum Wahrheitsgehalt von Aussagen gemacht werden: “Seine Behauptung ist eine Unverschämtheit.” “Dieses Buch enthält viele Fehler.” “Kinder und Betrunkene lügen nicht.” “Wenn A und B Aussagen sind, wenn eine Aussage der Form ‘aus A folgt B’ gilt und wenn A zutrifft, dann trifft auch B zu.” Das letzte Beispiel zeigt, daß die mathematische Aussagenlogik Aussagen in der Metasprache enthält. Die Metasprache zweiter Stufe enthält Aussagen über Aussagen der Metasprache erster Stufe. Der vorige Abschnitt enthält viele derartige Aussagen. Die Parallele zwischen Metadatenebenen und Sprachebenen ergibt sich daraus, daß Daten ebenfalls Aussagen sind, nur nicht in der Syntax einer Umgangssprache, sondern etwas kryptischer und platzsparender codiert. Nutzdaten entsprechen daher Aussagen in der Objektsprache, Metadaten Aussagen in der Metasprache. Wie wir später sehen werden, muß man analog zu Metasprachebenen auch Metadatenebenen unterscheiden. Ein großes Problem entsteht für die Linguistik dadurch, daß die Umgangssprache alle Sprachebenen zugleich beinhaltet und daß eine einzige Aussage Begriffe und Bedeutungen auf mehreren Ebenen haben kann (“Dieser Satz hat fünf Worte.”). Wenn eine Aussage auf der Metaebene auf sich selbst Bezug nimmt und dabei etwas über ihre eigene Wahrheit oder Falschheit aussagt, kann ein Paradoxon entstehen c 2008 Udo Kelter Stand: 09.11.2008 Metadaten 10 (“Dieser Satz ist falsch.” “Keine Regel ohne Ausnahme.”). Bei Daten und Metadaten existieren normalerweise keine analogen Probleme, weil diese durch den Anwendungskontext genau einer Bedeutungsebene zugeordnet sind. Von der Linguistik kann die Informatik lernen, daß man sich massive Probleme einhandelt, wenn man Bedeutungsebenen nicht strikt voneinander trennt. 2 2.1 Arten von Metadaten Typbezogene vs. entitätsbezogene Metadaten Sowohl bei Datenbanken wie auch in der Dokumentverwaltung kann man zwei Arten von Metadaten unterscheiden: – entitätsbezogene Metadaten: diese sind einzelnen Nutzdatengranulaten bzw. den dadurch dargestellten realen Entitäten zugeordnet. Beispiel: Publikationsdatum oder Seitenzahl eines Buchs. Entitätsbezogene Metadaten müssen für jedes Nutzdatengranulat individuell verwaltet und wie normale Attribute der Nutzdaten modelliert werden. Sie können integriert mit den Nutzdaten oder separat verwaltet werden. – typbezogene Metadaten: XML-Dokumenttypdefinitionen, Datenbankschemata, Data Dictionary-Einträge usw. sind Metadaten, die einheitlich für eine Sammlung von Dokumenten, Tupeln, Datensätzen usw. eines bestimmten Typs gelten. Jedes einzelne Nutzdatengranulat muß einen eindeutigen Typ haben, über den Typ werden ihm die typbezogenen Metadaten indirekt zugeordnet. Entitätsbezogene Metadaten werden in diesem Lehrmodul nicht weiter betrachtet. 2.2 Instantiierbare Metadaten Oben wurden Datenbankschemata als Beispiele von typbezogenen Metadaten genannt – daß ein Nutzer ein Datenbankschema zum Verständnis der Datenbank benutzt, mag durchaus vorkommen, viel häufiger werden Datenbankschemata aber benutzt, um die Datenbank zu c 2008 Udo Kelter Stand: 09.11.2008 Metadaten 11 “konfigurieren” und die Aufnahme von Nutzdaten überhaupt erst zu ermöglichen. Typbezogene Metadaten, zu denen ein Datenverwaltungssystem (DVS) Instanzen bilden und verwalten kann, bezeichnen wir als instantiierbare Metadaten oder Schemata für dieses DVS. Metadaten sind nicht von sich aus instantiierbar, sondern nur, wenn ein DVS vorhanden ist, das die Instantiierung im Detail bestimmt. Charakteristisch für den Umgang des DVS mit den instantiierbaren Metadaten ist: – Das DVS, genauer gesagt eine Installation des DVS auf einem bestimmten Rechner, wird durch Schemata konfiguriert. D.h. dieses DVS realisiert eine Funktion, mit der ein Schema in die Installation übernommen werden kann (Beispiel: CREATE TABLE ...); danach können Nutzdaten (“Instanzen”) gemäß diesem Schema erzeugt, geändert, gelöscht und durchsucht werden. In relationalen DBMS dienen hierzu die “Funktionen” INSERT, UPDATE, DELETE und SELECT. – Alle vorgenannten Funktionen sind insofern generisch, als sie mit beliebigen Basistypen, die in einem Schema definiert sind, arbeiten können, und wenigstens einen Typ-Parameter haben, in denen ein zu benutzender Basistyp explizit angeben wird (z.B. INSERT INTO relationR ..., SELECT attributeA FROM relationR ...). – Die Grundzüge der generischen Funktionen werden durch das zugrundeliegende Datenbankmodell definiert. Wie diese Funktionen im Detail arbeiten und ob es ggf. weitere ergänzende Funktionen gibt, wird erst durch das konkrete DVS bestimmt. Beispielsweise könnten verschiedene relationale DBMS mit signifikant verschiedenem Funktionsumfang durch die exakt gleichen Schemata konfigurierbar sein. Was es also konkret bedeutet, daß eine Instanz von instantiierbaren Metadaten gebildet wird und in welcher Form eine Instanz danach existiert, hängt in groben Zügen vom Datenbankmodell und im Detail von dem konkreten DVS ab, wird jedenfalls nicht allein durch die Schemata (egal in welcher Darstellung) spezifiziert. Für sich alleine c 2008 Udo Kelter Stand: 09.11.2008 Metadaten 12 genommen sagen die Schemata insb. nichts darüber aus, – welche enthaltenen Typen einzeln instantiierbar sind (i.d.R. sind z.B. Attribute nicht einzeln instantiierbar) und – welche generischen Funktionen vorhanden sind, welche Parameter sie haben, ob sie mit einzelnen Instanzen oder mit Mengen von Instanzen arbeiten und wie sie im Detail arbeiten. Typbezogene vs. instantiierbare Metadaten. Instantiierbare Metadaten sind definitionsgemäß typbezogenen, aber nicht alle typbezogenen Metadaten sind instantiierbar. Ein Beispiel für typbezogene, nicht instantiierbare Metadaten sind Angaben zu einem Datenfeld, warum und auf wessen Wunsch es eingeführt wurde und wie es pragmatisch zu benutzen ist. Typbezogene Metadaten sind nur dann instantiierbare Metadaten, wenn sie die generischen Funktionen des unterstellten DVS beeinflussen. Instantiierbare Metadaten haben einen wesentlich anderen Charakter als “normale” Metadaten: – Statt die Nutzdaten nur deskriptiv zu ergänzen oder unscharf zu beschreiben, sind instantiierbare Metadaten Vorschriften, wie die Nutzdaten strukturiert sein müssen. – Während normale Metadaten frei gestaltet werden können, müssen instantiierbare Metadaten völlig konsistent mit den Konzepten des unterstellten DVS und dessen Datenbankmodell sein. Wie instantiierbare Metadaten aussehen können, wird sehr genau durch das unterstellte DVS vorgegeben, der eventuelle Informationsbedarf von Nutzern spielt keine Rolle. Instantiierbare Metadaten sind daher letztlich als eine von mehreren denkbaren Repräsentationen der Schemata des unterstellten DVS anzusehen. – Die Schemata müssen auf jeden Fall innerhalb des Datenbankkerns verwaltet werden, während alle anderen Metadaten außerhalb des Datenbankkerns, also wie normale Nutzdaten verwaltet werden. c 2008 Udo Kelter Stand: 09.11.2008 Metadaten 13 Instanz-von-Beziehungen. Sofern das DVS die instantiierbaren Metadaten (und ggf. weitere typbezogene Metadaten) selbstreferentiell darstellt, liegt es nahe, die Nutzdaten mit ihren Typdefinitionen zu verbinden. Technisch kann dies auf unterschiedliche Weise geschehen, z.B. durch Instanz-von-Beziehungen von den Nutzdaten zu den selbstreferentiellen Schema-Darstellungen. Im Endeffekt können Applikationen, die mit den Nutzdaten arbeiten, die zugehörigen selbstreferentiell repräsentierten Metadaten lokalisieren, auslesen und bei der Verarbeitung der Nutzdaten ausnutzen. Oft werden in der Applikation selbst gemäß dem Analysemuster Exemplartyp (s. [AM]) Beschreibungen von Typen und deren Instanzen verwaltet und durch Instanz-von-Beziehungen verbunden. Wie die Instanzen erzeugt und verwaltet werden, kann bei der Gestaltung der Applikation völlig frei entschieden werden. Die durch die Applikation bzw. das DBMS realisierten Instanz-von-Beziehungen haben daher eine völlig andere Bedeutung und dürfen trotz ähnlich klingender Namen nicht gleichgesetzt werden. 3 3.1 Selbstreferentialität in relationalen Datenbanken Repräsentation relationaler Schemata durch Tabellen In relationalen Systemen werden Schemata üblicherweise selbstreferentiell repräsentiert. Der ANSI/ISO SQL-Standard von 2003 definiert eine Datenbank INFORMATION SCHEMA, die diverse Metadaten zu allen Relationen in allen Datenbanken einer Installation bereitstellt. Die Schemata werden durch rund 20 Tabellen repräsentiert, darunter die Tabellen SCHEMATA, TABLES, COLUMNS und TABLE CONSTRAINTS. Die Datenbank INFORMATION SCHEMA ist mit SELECT lesbar; verändert werden kann sie nur durch Kommandos wie CREATE TABLE, nicht hingegen durch die Elementaroperationen INSERT, DELETE und UPDATE. I.f. stellen wir eine stark vereinfachte Version der Inhalte dieser Datenbank vor. c 2008 Udo Kelter Stand: 09.11.2008 Metadaten 14 Angaben über die vorhandenen Tabellen und deren Attribute kann man selbstreferentiell bereitstellen mittels einer Tabelle tabellenattribute, die für jedes Attribut jeder Tabelle den Namen, Typ usw. angibt2 . Die benutzerdefinierte Relation kunden mit den Spalten Kundennummer, Kundenname, Wohnort und Kreditlimit würde innerhalb dieser Tabelle wie folgt repräsentiert: Tabelle: tabellenattribute Tabellenname Attributname ... ... kunden Kundennummer kunden Kundenname kunden Wohnort kunden Kreditlimit ... ... Attributtyp ... integer char(40) char(25) decimal(5,0) ... Vorgabewert ... – – – 0,0 ... Die vorhandenen Identifizierungsschlüssel könnte man durch die folgende Tabelle (idschluessel) darstellen. Eine Tabelle kann mehrere Identifizierungsschlüssel haben, diese werden durch das Attribut IdSchlNr durchnumeriert. Jeder einzelne Identifizierungsschlüssel besteht aus einer Menge von Attributen, pro Attribut wird ein Tupel in der Tabelle eingetragen. Tabelle: idschluessel Tabellenname IdSchlNr ... ... kunden 1 ... ... Attributname ... Kundennummer ... Letztlich kann man alle Angaben über Tabellen, Domänen, Sichten, Primärschlüssel, Fremdschlüssel usw., die in den SQL-Kommandos zur Schemaverwaltung ( CREATE TABLE usw.) textuell dargestellt werden, 2 Die hier definierte Tabellen tabellenattribute und idschluessel sind stark vereinfachte Versionen der Tabellen COLUMNS und TABLE CONSTRAINTS. Wir gehen hier vereinfachend davon aus, daß nur ein einziges Datenbankschema verwaltet werden muß und man sich implizit hierauf bezieht. c 2008 Udo Kelter Stand: 09.11.2008 Metadaten 15 auch in tabellarischer Form repräsentieren. Allerdings deutet bereits das vorstehende Beispiel darauf hin, daß die tabellarische Darstellung aller Details eines Schemas nicht besonders übersichtlich ist und die textuelle Darstellung deutlich lesbarer ist. Die Komplexität der Schemata kann reduziert werden, wenn man für Detailstrukturen eine textuelle Darstellung wählt. In unserem Beispiel haben wir dies für die Attributtypen so gemacht: Texte wie “decimal(5,0)” beinhalten mehrere Angaben, für die bei einer komplett relationalen Modellierung eigene Spalten vorhanden sein müßten. Das Prinzip der Selbstreferentialität ist nicht nur bei den Schemata, sondern bei allen Arten von Metadaten anwendbar, z.B. administrative Metadaten, insb. sofern der Bedarf besteht, diese Metadaten ohne zusätzliche Schnittstellen abfragen oder sogar verändern zu können. Das Prinzip der Selbstreferentialität ist im Prinzip bei allen Datenbankmodellen anwendbar, nicht nur beim relationalen. Schemata und die viele andere Arten von Metadaten haben indessen eine komplexe Struktur, die spannende Frage ist, ob es die Modellierungsfähigkeiten des Datenbankmodells erlauben, diese Strukturen bequem zu modellieren. Das obige Beispiel zeigte bereits, daß das relationale Modell nur bedingt geeignet ist, relationale Schemata zu modellieren. 3.2 Zugriff auf selbstreferentiell repräsentierte Schemata Der offensichtliche praktische Nutzen der Selbstreferentialität ist, daß man die Standardschnittstellen des Systems verwenden kann, um die Schemata auszulesen. Man braucht keine eigene Schnittstelle im DBMS-Kern zu realisieren; eine ggf. gewünschte andere Darstellung - z.B. textuell - kann durch eine Applikation außerhalb des Datenbankkerns realisiert werden. Ob man die Schemata auch nach der gleichen Methode verändern kann, ist hingegen fraglich: 1. Wenn wir wieder auf das Beispiel der Tabelle tabellenattribute zurückkommen, dann müßte das Löschen eines Tupels zur Folge haben, daß in der betroffenen Tabelle ein Attribut entfernt und ggf. c 2008 Udo Kelter Stand: 09.11.2008 Metadaten 16 Teile der Datenbank konvertiert werden. Dies ist aber u.U. überhaupt nicht möglich oder nicht im Normalbetrieb; der Versuch, das Tupel zu löschen, müßte dann mit einer speziellen Fehlermeldung abgelehnt werden. Dies bedeutet, daß sich die Semantik von Standardoperationen ändert, wenn man sie auf Metadaten anwendet, und zwar durch eine Vielzahl von Nebeneffekten und zusätzliche Fehlerfälle. Dies ist umständlicher und schlechter verstehbar als eigene Operationen. 2. Die Struktur der Metadaten ist oft relativ komplex und kann komplizierte Integritätsbedingungen aufweisen. Da das zugrundeliegende Datenbankmodell normalerweise recht elementare Operationen aufweist, braucht man mehrere elementare Operationen, um eine korrekte Typdefinition zu konstruieren oder abzuändern (z.B. bei einer Objekttypdefinition wird zuerst der Typ erzeugt und dann werden ‘Eltern’-Beziehungen zu den Supertypen erzeugt, dann die Attribute zugeordnet). Die einzelnen Änderungen dürfen zunächst keine Auswirkungen auf die Metadaten haben, erst wenn die gesamte Sequenz von Operationen ausgeführt ist, können die Metadaten tatsächlich geändert werden. Da das DBMS von sich aus den Abschluß der Änderung nicht erkennen kann, benötigt man zusätzlich eine Operation, die den Abschluß signalisiert; das DBMS muß dann herausfinden, welche Detailänderungen vorgenommen wurden, und prüfen, ob der neue Zustand korrekt ist. Die Vorstellung, daß durch normale Datenmanipulationsoperationen implizit auch die Metadaten verändert werden, kann hier praktisch nicht mehr aufrechterhalten werden. Aufgrund der vorstehenden Probleme eignet sich der selbstreferentielle Ansatz i.a. nur für das Auslesen, nicht aber für das Ändern von Metadaten. Daher werden im ANSI/ISO SQL-Standard alle Tabellen mit Metadaten als schreibgeschützt definiert. 3.3 Metatypen und Meta-Metadaten Die Metadaten haben natürlich auch Typen; diese Typen bezeichnet man als Metatypen, entsprechende Schemata als Metaschemata. c 2008 Udo Kelter Stand: 09.11.2008 Metadaten 17 Ein Beispiel für ein Metaschema ist das Schema unserer oben erwähnten Tabelle tabellenattribute. Die Metatypen kann man wiederum selbstreferentiell repräsentieren; diese Daten sind Daten über Metadaten, also Meta-Metadaten. Die folgende Tabelle zeigt dies für die Metatypen aus den Tabellen tabellenattribute und idschluessel. Man beachte, daß die Spaltenköpfe der beiden genannten Tabellen hier zu Datenwerten in der Spalte Attributname werden. Tabelle: datenbankmodellKonzepte Tabellenname Attributname Attributtyp tabellenattribute Tabellenname char(200) tabellenattribute Attributname char(200) tabellenattribute Attributtyp char(200) tabellenattribute Vorgabewert char(1000) idschluessel Tabellenname char(200) idschluessel IdSchlNr integer idschluessel Attributname char(200) Vorgabewert – – – – – – – Die Tabelle wurde datenbankmodellKonzepte genannt, weil die Metatypen den Konzepten aus dem Datenbankmodell entsprechen. Es war relativ leicht, die Tabelle datenbankmodellKonzepte hinzuschreiben und den Begriff Meta-Metadaten zu bilden. Bei genauem Hinsehen ist aber nicht klar, ob das überhaupt sinnvoll ist, was wir da gemacht haben: 1. Meta-Metadaten stillen eigentlich keinen Informationsbedarf, der bei der Interpretation oder Verarbeitung der Metadaten entstehen würde. Entwickler von Applikationen und Datenbank-Nutzer wissen sowieso, daß Attribute einen Namen, Typ und Vorgabewert haben, dahingehend besteht kein Informationsbedarf. Wenn diese Kenntnisse über das Datenmodell nicht vorhanden wären, könnte man außerdem die Meta-Metadaten, die ja als Nutzdaten repräsentiert werden, gar nicht abfragen, denn um die Abfrage formulieren zu können, muß man dieses Wissen schon haben. c 2008 Udo Kelter Stand: 09.11.2008 Metadaten 18 Allenfalls sind Abfragen sinnvoll, wie lang z.B. der Name einer Tabelle maximal sein darf; dies sind aber technische Details, die man eher als Konfigurationsparameter der generischen Funktionen des DBMS-Kerns auffassen wird. Der DBMS-Kern konsultiert auch nicht die Meta-Metadaten, bevor er auf die Metadaten zugreift, um herauszufinden, ob er diese Metadaten als Schemata von relationalen Tabellen oder als Dokumenttypdefinitionen von XML-Dateien oder Konfiguration einer Suchmaschine interpretieren soll – die generischen Funktionen, die der Laufzeitkern eines relationalen DBMS realisiert, können nur mit relationalen Tabellen arbeiten, mit sonst nichts. 2. Die Meta-Metadaten können nicht ohne weiteres (signifikant) geändert werden, ohne zugleich den DBMS-Kern umzuprogrammieren. Ändert man das Metaschema ab, so ist deswegen alleine überhaupt nicht klar, wie der DBMS-Kern mit diesen neuen Strukturen umgehen soll. Wir könnten z.B. in der Tabelle datenbankmodellKonzepte ein neues Tupel (’tabellenattribute’, ’Geheimhaltungsstufe’, ’char(200)’, ’’ ) eintragen. Was das bedeuten soll, ist völlig unklar. Man müßte zunächst klären, wie das Konzept einer Geheimhaltungsstufe zu verstehen ist, dazu passend müßte ggf. die Syntax des CREATE TABLE-Kommandos erweitert werden, und die Wirkung der generischen Funktionen müßte geeignet modifiziert werden. Außerdem müßte natürlich die Metadaten-Tabelle tabellenattribute eine weitere Spalte Geheimhaltungsstufe bekommen. Im Endeffekt müssen wesentliche Teile des DBMS-Kerns umgestaltet werden. Ferner müßten ggf. sogar alle Nutzdaten entsprechend angepaßt werden. Als Konsequenz aus den vorstehenden Überlegungen sind das Metaschemata eines DBMS und dessen selbstreferentielle Repräsentation durch Meta-Metadaten, also hier die Tabelle datenbankmodellKonzepte, immer komplett statisch. Selbstreferentiell repräsentierte Metaschemata sind daher (in üblichen DBMS) in der Praxis weitgehend sinnlos! Man kann diese Metadaten nicht ändern, und um diese c 2008 Udo Kelter Stand: 09.11.2008 Metadaten 19 Daten abzufragen, muß man viele Konzepte schon vorher kennen, weil sie in der Abfrage verwendet werden. 3.4 Übersicht über die semantischen Ebenen Man kann die auftretenden Daten bzw. selbstreferentiellen Schemarepräsentationen je nach ihrer Bedeutung in mehrere Ebenen einteilen, diese Ebenen sind in der Tabelle in Bild 1 zusammengefaßt. Nr. Bedeutungsebene (Daten repräsentieren...) 2 1 0 Meta-Metadaten: Repräsentationen von Metaschemata / Metatypen Metadaten: Repräsentationen von Schemata / Typen Nutzdaten: Repräsentationen von Realwelt-Entitäten Beispiel einer dargestellten Entität Begriff “Tabelle” Syntax und Semantik der Daten wird bestimmt durch ... veränderbar MetaMetaschema nein Tabellenschema “Adressen” eine Adresse Metaschema + Datenbankmodell + DBMS Schema + Dokumentation ja ja Abbildung 1: Hierarchie der Bedeutungsebenen von Daten in einer Datenbank Lesehinweise zu dieser Tabelle: Auf Ebene 0 werden Nutzdaten verwaltet. Die “syntaktische” Struktur der Nutzdaten wird durch ein Schema vorgegeben, das allerdings komplexere Konsistenzbedingungen i.d.R. nicht beinhaltet; letztere können z.B. in einem Data Dictionary verbal dokumentiert sein, insofern wird noch nicht einmal die syntaktische Struktur der Daten durch das Schema vollständig dargestellt. Überhaupt nicht dargestellt wird die Bedeutung der Daten. Schemata werden auf Ebene 0 nur genutzt, aber nicht in irgendeiner Form als Daten repräsentiert oder verwaltet. Auf Ebene 1 werden Repräsentationen von Schemata verwaltet. Daß dies in der syntaktischen Form von Tabellen geschieht, ist willkürc 2008 Udo Kelter Stand: 09.11.2008 Metadaten 20 lich, man könnte genausogut eine textuelle Darstellung verwenden3 . Entscheidend ist, daß Schemata dargestellt werden. Für das Metaschema gelten die gleichen prinzipiellen Bemerkungen wie für das Schema: es stellt nur die syntaktische Struktur der Schemata weitgehend dar, aber nicht vollständig, und die Bedeutung der Schemata überhaupt nicht. Die letzte Spalte gibt an, ob diese Daten innerhalb eines DBMS durch die Nutzer veränderbar sind. Man kann diese Daten- und Schemahierarchie beliebig nach oben fortsetzen, es bringt aber nichts ein. Schon auf Ebene Metadaten stößt das Prinzip der Selbstreferentialität an Grenzen, denn ändernde Standard-Operationen sind nicht mehr erlaubt4 . Die selbstreferentielle Repräsentation der Metatypen ist sinnlos, weil die Metatypen eines DBMS komplett statisch sind. 3.5 Meta-Ebenen vs. Implementierungsebenen von Datenbankobjekten Die semantischen Meta-Ebenen in Bild 1 werden leicht verwechselt mit den Ebenen der Abstraktionshierarchie für Datenbankobjekte, die in Abschnitt 4 in [DBSA] vorgestellt wird. Prinzipiell haben diese beiden Hierarchien nichts miteinander zu tun, sie sind völlig orthogonal zueinander. Nutzdaten, Metadaten und ggf. Meta-Metadaten existieren alle nebeneinander und gleichzeitig als persistente Daten, sie müssen in irgendeiner Form auf den persistenten Medien gespeichert und beim Lesen von dort in mehreren Schritten an die Schnittstellen gebracht werden. 3 Die textuelle Darstellung wäre durch eine Grammatik bzw. Sprachdefinition strukturiert! Man kann übrigens die Daten auf allen Ebenen textuell darstellen und erhält dann eine Hierarchie von Sprachebenen. In der Tabelle muß dazu überall “Schema” durch “Grammatik” ersetzt werden. 4 Zur Klarstellung sei daran erinnert: wir diskutieren hier nur instantiierbare Metadaten, also Repräsentationen von Schemata. Andere Metadaten können natürlich mit Standard-Operationen geändert werden, da sie keine operationale Bedeutung haben. Obwohl es sich semantisch um Metadaten handelt, können sie technisch wie Nutzdaten behandelt werden. c 2008 Udo Kelter Stand: 09.11.2008 Metadaten 21 Ein extern sichtbares Tupel, das z.B. eine Adresse darstellt, existiert intern in absteigender Reihenfolge der Ebenen als Pufferbereich, als Inhalt eines Speichersatzes, als Teil eines Blocks und letztlich als magnetische Struktur auf einer Platte – in allen Fällen sind dies semantisch gesehen die gleichen Nutzdaten, nur die Implementierungsebene unterscheidet sich. In der nachfolgenden Tabelle sind Nutzdaten in Spalte 2 skizziert und jeweils mit “Std.” für Standardverfahren markiert. Implementierungsebene n-Tupel-Ebene 1-Tupel-Ebene Speichersatzebene Nutzdaten Std. Std. Std. Metadaten (Schemata) nur lesen nur lesen Std. Segmentebene Std. Std. Metametadaten (Metaschemata) geeignet?? geeignet?? nur teilw. sinnv. nur teilw. sinnv. Analog wie Nutzdaten müssen auch die Metadaten über die komplette Implementierungshierarchie hinweg realisiert werden. Die Metadaten werden natürlich in eigenen Segmenten verwaltet, insofern liegen sie “neben” den Nutzdaten. In der vorstehenden Tabelle sind Metadaten in Spalte 3 skizziert, die parallelen Spalten für Nutzdaten und Metadaten sollen andeuten daß beide Arten von Daten gleichzeitig nebeneinander existieren. Auf den beiden unteren Ebenen kann man die Metadaten wie normale Daten verwalten, man kann aber ebensogut abweichende Implementierungen verwenden, weil auf Metadaten anders als auf Nutzdaten zugegriffen wird. Auf der 1-Tupel-Ebene kann man immerhin noch für lesende Zugriffe die Standardschnittstellen und Implementierungsverfahren anbieten, für schreibende Zugriffe sind andere Schnittstellen sinnvoller. Auch dann, wenn Standardverfahren zum Einsatz kommen, und unabhängig von der Implementierungsebene sind die Daten, die z.B. ein Schema darstellen, immer Metadaten. Metametadaten, also speziell das Metaschemata, kann man theorec 2008 Udo Kelter Stand: 09.11.2008 Metadaten 22 tisch ebenfalls selbstreferentiell repräsentieren; diese Daten existieren dann parallel zu den Nutzdaten und Metadaten ebenfalls über alle Implementierungsebenen. Wie aber schon früher diskutiert können aus diversen praktischen Gründen Metametadaten nur mit sehr starken Einschränkungen selbstreferentiell repräsentiert werden. Weil es auch wenig Vorteile einbringt, liegt es nahe, komplett darauf zu verzichten. 4 4.1 Selbstreferentialität in XML Aufbau von XML-Dateien XML-Dateien enthaltenen i.w. zwei Teile: – einen Nutzdatenbestand, dessen Struktur ein Baum ist. Der Baum wird textuell dargestellt. Ein Teilbaum, auch Element genannt, wird in einem Textabschnitt dargestellt, der mit einem öffnenden tag beginnt, z.B. <Adresse>, und einem schließenden tag endet, z.B. </Adresse>. Jeder Knoten des Baums hat einen Typ, der Name des Typs steht in beiden tags. Im öffnenden tag können ferner Attributwertzuweisungen stehen, z.B. <Adresse AdrID=’A112’>. Hier ein Beispiel eines Teils der Nutzdaten: <Adresse AdrID=’A112’ > <Name>Frank</Name> <Vorname>Ulrich</Vorname> <Straße>Hauptstr.</Straße> <Hausnummer>5</Hausnummer> <Ort PLZ=’57076’>Siegen</Ort> </Adresse> <Adresse> .... </Adresse> – einer optionalen Dokumenttypdefinition (DTD), in der die Schachtelungsstruktur der tags definiert wird. c 2008 Udo Kelter Stand: 09.11.2008 Metadaten 23 Bei der DTD handelt es sich im Prinzip um eine kontextfreie Grammatik, die die Syntax und die inhaltliche Struktur des Textes, der die Nutzdaten darstellt, definiert. Hier können wir folgenden sehr interessanten Sachverhalt feststellen: Die Bedeutungsebenen von Daten, Metadaten usw. in Datenbanken (s. Tabelle 3.4) gelten analog für Texte, Grammatiken, Meta-Grammatiken usw. Das Prinzip der Selbstreferentialität wird somit (mit hier nicht interessierenden Ausnahmen) auch in XML-Dateien in Form von DTDs oder XML-Schemata angewandt. Auf Details gehen spätere Lehrmodule über Transportdateien und die XML [TRD] ein. 4.2 Typ-Annotationen Eine spezielle, oft irreführende Form von Metadaten stellen die Typangaben in den Tags in XML-Dateien dar. Derartige Angaben zum Typ der Daten, die direkt in die Nutzdaten eingebettet sind, bezeichnen wir als Typ-Annotationen. Typ-Annotationen treten auch in Bibtex-Dateien und vielen anderen Transportdateiformaten auf. Als Beispiel betrachten wir wieder den obigen Ausschnitt aus einer XML-Datei, die in den Nutzdaten eine Adreßliste enthält. Die eigentlichen Adreßdaten sind offensichtlich Nutzdaten. Die Frage ist, ob die Namen der Elementtypen und Attribute Metadaten sind und welche Art von Metadaten hier vorliegt. Diese Namen kann man ohne weiteres gemäß der allgemeinen Definition, wonach Metadaten die Interpretation der Nutzdaten ermöglichen bzw. unterstützen, als entitätsbezogene Metadaten ansehen; dies ist abhängig von der subjektiven Verwendung dieser Daten. Unklar ist hingegen, ob diese Namen auch typbezogene Metadaten in dem Sinne sind, daß sie implizit ein Schema der Nutzdaten darstellen (ggf. redundant bei jeder Instanz). 4.2.1 Typ-Annotationen in schwach strukturierten Daten An dieser Stelle muß man sich bewußt machen, daß XML eigentlich für schwach strukturierte Daten gedacht ist, das sind Daten, deren Struktur extrem variantenreich ist und/oder sich ständig unvorhersehbar ändert. Das Fehlen von eindeutigen Typdefinitionen ist gerade das c 2008 Udo Kelter Stand: 09.11.2008 Metadaten 24 Wesensmerkmal schwach strukturierter Daten. In Datenbanken und in vielen Programmiersprachen haben Typen die zentrale Eigenschaft, für alle Instanzen des Typs eine einheitliche Struktur sicherzustellen; genau diese Eigenschaft ist unerwünscht bei schwach strukturierten Daten. Weil es für derartige Daten keine Schemata im Sinne von Datenbanken gibt, ist die Selbstreferentialität hier prinzipiell nicht sinnvoll. Wenn man, obwohl es kein Schema gibt, trotzdem etwas über die Struktur aller Instanzen eines Elementtyps wissen will, kann man bestenfalls die Kindelementtypen und Attribute, die bei den vorhandenen Instanzen dieses Elementtyps auftretenden, aufsammeln. Man findet aber mit dieser Methode viele Strukturmerkmale nicht sicher heraus: die zulässige Häufigkeit einzelner Kindelemente, Reihenfolgerestriktionen, bei Attributen wie z.B. AdrID die Art des Attributs5 . Ferner könnte die vollständige Typdefinition einer Adresse eine optionale Angabe der Anrede und des Landes beinhalten, die zufällig in den vorhandenen Nutzdaten nirgendwo auftritt. Die implizit durch die Typ-Annotationen gegebenen Typdefinitionen sind also i.a. vage und unvollständig. 4.2.2 Typ-Annotationen in strikt typisierten Nutzdaten Sofern die Daten strikt typisiert sind, also eine DTD (oder ein XMLSchema) vorhanden ist und nur gemäß der DTD gültige XML-Dateien betrachtet werden, interessiert die Frage nicht mehr, ob die tags implizit eine Typdefinition darstellen. Die Typnamen in den tags sind nunmehr als Referenzen auf die Typdefinitionen in der DTD zu verstehen, also als unidirektional implementierte “ist-Instanz-von”-Beziehungen6 . Wenn man Typ-Annotationen als Referenzen auf Typdefinitionen versteht, ist es wenig sinnvoll, sie als entitätsbezogene Metadaten an5 Möglich wäre ein ID-, IDREF-, IDREFS- oder CDATA-Attribut. Es kommt hier nicht darauf an, daß die Typdefinitionen tatsächlich technisch in einem XML-Format vorliegen, sondern daß sie im Anwendungskontext (z.B. innerhalb von Applikationen) als Referenzen auf Typdefinitionen interpretiert und benutzt werden. 6 c 2008 Udo Kelter Stand: 09.11.2008 Metadaten 25 zusehen, weil sie ja nur Referenzen auf etwas anderes sind und selbst nichts aussagen. Dies wird besonders offensichtlich, wenn die Typnamen keine intuitive Semantik vermitteln, sondern nur “sinnlose”, generierte Nummern sind: ..... <TypId117543>Frank</TypId117543> <TypId117544>Ulrich</TypId117544> ..... Der entscheidende Punkt ist hier, daß man (meist unbewußt) zu einem anderen Datenbankmodell übergegangen ist, nämlich zu einem Datenbankmodell mit streng typisierten Datengranulaten. In einem solchen Datenbankmodell hat jedes Datengranulat einen eindeutigen Typ, und für jeden Typ liegt eine vollständige Definition vor. Das relationale Datenbankmodell ist ein Beispiel hierfür. Bei einem streng typisierten Datenbankmodell müssen die internen Implementierungsstrukturen so gestaltet werden, daß zu jedem Datengranulat sein Typ festgestellt werden kann. Im relationalen Datenbankmodell wird dies i.d.R. dadurch realisiert, daß alle Tupel gleichen Typs in einem Container (einer Tabelle) verwaltet werden und die Typdefinition der Tabelle zugeordnet ist. Man kann aber auch die Datengranulate gemischt speichern, muß dann aber an jedem Datengranulat explizit eine Typangabe speichern. Ob man hierfür ausdrucksstarke Namen oder sinnlose Nummern verwendet, ist eine Implementierungsentscheidung. Konzeptuell wird in allen Fällen eine Referenz auf die volle Typdefinition realisiert. Eine XML-Datei entspricht bzgl. des Implementierungsniveaus einem B*-Baum in der Implementierungshierarchie für Datenbankobjekte7 . Die XML-Datei implementiert einen getypten Baum; man sieht 7 Man beachte die Analogie zwischen den Begriffen “physische Konsistenz” einer Datenbank und “Wohlgeformtheit / Validität” einer XML-Datei. Wenn eine Datenbank physisch inkonsistent ist, ist der intern sichtbare Inhalt nicht mehr korrekt gemäß den Schemata interpretierbar. Wenn eine XML-Datei infolge eines falsch geschriebenen Typnamens oder Fehlers in einem Tag nicht mehr valide bzgl. einer DTD bzw. wohlgeformt ist, wird ihr Inhalt nicht mehr von einem validierenden XML-Prozessor akzeptiert, sie kann nicht mehr verarbeitet werden. c 2008 Udo Kelter Stand: 09.11.2008 Metadaten 26 (leider) die Implementierungsdetails komplett. Unsere Ausgangsfrage, ob bei strikt typisierten Nutzdaten die Typ-Annotationen Metadaten sind, ist letztlich nur Folge eines falsch gewählten Betrachtungsstandpunkts: hier werden Meta-Ebenen und Implementierungsebenen verwechselt (vgl. Abschnitt 3.5). Die TypAnnotationen sind hier keine Metadaten, sondern in die Nutzdaten eingebettete Typangaben, die ggf. als Referenzen auf andernorts vorhandene Metadaten interpretiert werden können. Literatur [AM] Kelter, U.: Lehrmodul “Analysemuster (Stichworte)”; 2006 [DBSA] Kelter, U.: Lehrmodul “Architektur von DBMS”; 2005 [DVS] Kelter, U.: Lehrmodul “Datenverwaltungssysteme”; 2005 [TRD] Kelter, U.: Lehrmodul “Transportdateien und die SGML”; 2004 Glossar Metadaten (meta data): Daten über Daten; im Kontext von DBS vor allem Schemata bzw. Typdefinitionen Meta-Metadaten (meta meta data): Daten über Metadaten; insb. eine selbstreferentielle Repräsentation des Metaschemas Metaschema (meta schema): Schema, das zur Speicherung von Metadaten (insb. Schemata und Typdefinitionen) benutzt wird Nutzdaten: die in einem System verwalteten “primären” Daten (ohne die Metadaten) Selbstreferentialität: Ansatz, die Metadaten in einem DVS wie Nutzdaten darzustellen Typ-Annotationen: in die Nutzdaten eingebettete Angaben zum Typ der Daten, Beispiel: tags in XML c 2008 Udo Kelter Stand: 09.11.2008 Index DTD, 22 Objektsprache, 9 Formatierung, 5 Schema, 4, 11, 12 generische DVS-Funktionen, 11 Konfigurierung, 18 internes, 4 Selbstreferentialität, 7, 26 Änderung von Metadaten, 15, 16 bei administrativen Metadaten, 15 bei Metatypen, 20 bei schwach strukturierten Daten, 24 bei Sprachen, 23 in relationalen Datenbanken, 13 in XML, 22 Sprachebenen, 8 Grammatik, 23 Implementierungsebenen von Datenbankobjekten, 20, 25 Instanz-von-Beziehung, 12 Layout-Daten, 5 Meta-Metadaten, 17, 18, 26 Metadaten, 3, 4, 26 administrative, 5 entitätsbezogene, 10 Hierarchie, 17, 19 in Datenbanken, 3, 4 in der Dokumentverwaltung, 3, 5 in Programmen, 3 instantiierbare, 10, 12 Instanzbildung, 11 Nutzung, 7 persistente, 4 semantische, 4 Speicherung, 6, 8, 20 transiente, 4 Typ-Annotationen, 23 typbezogene, 10, 23 vs. Nutzdaten, 6, 8 Metaschema, 16, 26 Metasprache erster Stufe, 9 Metasprache zweiter Stufe, 9 Metatyp, 16 Typ-Annotationen, 23, 26 Nutzdaten, 3, 26 27
