Auszeichnungssprachen

Die Struktur muß alle möglichen Analysemethoden effizient unterstützen

Die Daten müssen einen Zeitraumbezug aufweisen, da sie für effiziente Analysen bis zu zehn Jahre gespeichert werden müssen.

Struktur- und Formatvereinheitlichung um Konsistenz über langen Zeitraum zu sichern

Nicht-Voltialität, also nicht-Flüchtigkeit, der Daten um korrekte Analysen sicherzustellen. Eine Veränderung der Daten nach einer Übernahme sollte also unterbunden sein, ausser eventuellen Korrekturen bei der Übernahme.

Die Transformation zum Komponentenschema beseitigt die Heterogenität, indem die lokalen Schemata in ein vorher festgelegtes globales Datenmodell transformiert werden.

Das Exportschema filtert diejenigen Daten heraus, die der globalen Anwendung nicht zur Verfügung gestellt werden sollen.

Für das föderierte Schema wird das vorher durch Schemaintegration gewonnene globale Datenmodell genutzt. Hier werden alle Exportschemata vereinigt, was zu Konflikten führen kann.

Das externe Schema versorgt Anwendungen mit einer speziell angepaßt Datenstruktur, die vom föderierten Schema abgeleitet wird. So können Daten anders strukturiert oder auch schlicht weggelassen werden, falls sie bei einer Anwendung unwichtig sind.

Extensionale Konflikte. Zu Extensionalen Konflikten kann es kommen, wenn zwei äquivalente Klassen von unterschiedlichen Datenbanken verschiedene Ausschnitte der Realität beschreiben. So kann es zum Beispiel vorkommen, daß sich alle Angaben auf dieselben Objekte beziehen, aber auch, daß sich die Menge der Objekte nur überlappt, die eine Datenbank nur eine Untermenge der Objekte der anderen Datenbank beschreibt, oder daß die Mengen der Objekte vollständig disjunkt sind.

Heterogenitätskonflikte. Die verschiedenen Datenbanken können mit unterschiedlichem Datenmodell arbeiten, zum Beispiel einem relationalen oder objektorientierten. Bei der Umwandlung dieser Modelle in das einheitliche föderierte Schema müssen semantische Verluste vermieden werden, eventuell muß auch eine semantische Anreicherung realisiert werden.

Beschreibungskonflikte. Wenn wir zwei äquivalente Objektklassen gefunden haben, können sie unterschiedlich beschrieben werden:

1.1.2.a

Strukturelle Konflikte. Innerhalb von Datenmodellen gibt es oft die Möglichkeit Sachverhalte verschieden zu Modellieren, die sich aber trotzdem semantisch äquivalent sind.

Datenkonflikte. Durch unterschiedliche Konventionen bei der Angabe von Daten, können sich semantisch äquivalente Ausdrücke unterscheiden. Darunter fallen zum Beispiel Namensangaben ("Michael Müller" <> "Müller, Michael"), aber auch einfache Tippfehler.

Einfache Skallierbarkeit und Erweiterbarkeit. Das hinzufügen von weiteren Quellen und die Veränderung des globalen Schemas sollte keine Probleme bereiten.

Vollständigkeit. In einem globalen Schema sollten alle Daten aus den einzelnen Quellen vorhanden sein.

Minimalität. In einem globalen Schema sollte für alle zueinander äquivalenten Element nur ein Element definiert sein.

Verständlichkeit. XML typisch ist hier die Anforderung, daß das entstehende globale Scheme für Menschen gut lesbar ist. Daraus folgt, daß die Definition des globalen Schemas in einer referenzierten Datei erfolgen sollte und nicht über inline Definitionen.

Ordent man diese Funktionalität in die oben beschriebene 5-Ebene-Architektur ein, so stellt man fest, daß sich der schwierige Schritt vom lokalen Schema zum Komponentenschema damit bewerkstelligen läßt, da sowohl das nötige globale Schema generiert wird, als auch die Daten dorthinein überführt werden. Es erscheint hierbei sinnvoll, die Reihenfolge der einzelnen Schritte umzusortieren und so das Exportschema vor dem Komponentenschema zu bilden. Wir haben also eine konkrete Implementierung für unser allgemeines Modell gefunden.

Um die späteren Operationen auf der Datenstruktur zu ermöglichen, verwandeln wir die flachen XML Schemata in ein objektorientiertes Model, das sich später wieder in eine XML Schema Datei zurücktransformieren läßt[4]. Dazu dienen uns fünf verschiedene Klassen von Objekten: Node, Child, Datatype und Attribute Objekte. Alle diese Klassen haben Unterstrukturen, die die Objekte weiter beschreiben. So besitzt zum Beispiel das Node Objekt eine Liste über alle Child Objekte. Generell werden so alle möglichen Eingenschaften aus dem Schema in diese Objektstruktur gebracht. Diese Objektstruktur läßt sich als gerichteter Graph darstellen. Dafür wird in [4] folgende Notation vorgeschlagen:

Jedes Objekt wird mit einem Rechteck dargestellt, in dem zwei Linien oben und unten zwei kleinere Rechtecke abtrennen. Der Name eines Node bzw. Child Objektes, entsprechen den Elementnamen im XML Schema, wird in dem obersten Rechteck eingeschlossen. Drumherum angeordnet, in den Ecken des Rechtecks, werden links oben beginnend, im Uhrzeigersinn vorangehend folgende Angaben notiert: Der Namespace des Elementes, die maximale Kardinalität, die minimale Kardinalität und eine eindeutige Nummer. Kardinalitäten sind dabei natürlich nur bei Child Objekten möglich, eine unbegrenzte Häufigkeit wird durch das Unendlichkeitssymbol dargestellt.

Im mittleren Viereck werden die Attribute des Elements mit ihren Datentypen notiert.

Im unteren Viereck wird die Struktur angegeben:

Dabei werden den Datentypen entsprechend die eindeutigen Nummern der assoziierten Objekte in Klammern hinter dem Datentyp notiert. So stellt sich ein Element vom XML Datentyp Choice zum Beispiel so dar: C { 3, 7} mit 3 und 7 als IDs der referenzierten Elemente. In der graphischen Darstellung werden Kindobjekte mit Linien an ihre Eltern gebunden. Hierzu ein Beispiel aus [4]:

Abbildung 1.2

Nachdem im Präintegrationsschritt das XSDM gebildet wurde, werden im zweiten Schritt die Elemente auf Übereinstimmungen und Konflikte untersucht. Dabei können sechs Typen von semantischen Verhältnissen gefunden werden:

Aus dieser Klassifikation der Elemente kann nun auf paarweise Konflikte geschlossen werden. Diese können je nach Typ des Elements und je nach semantischem Verhältnis unterteilt werden:

Nun beginnt der Integrationsschritt, in dem die beiden in XSDM Notation als Bäume dargestellten Schemata vereinigt werden. Werden Elemente zu einem verschmolzen, werden alle Attribute aller dieser Elemente übernommen, als Datentyp wird das niedrigste gemeinsame Niveau gewählt. Hierbei kann es zu Datenkonflikten, vor allem Skalenkonflikten führen, die manuell gelöst werden müssen. Im einfachsten Fall der Intergration von nur zwei Terminalen Elementen müssen neben der Integration der Attribute noch folgenden Regeln beachtet werden:

1.2.4.a

Bei der Vereinigung von zwei nichtterminalen Objekten A und B müssen wir die Datentypen korrekt kombinieren, damit das entstehende globale Schema für die lokalen Schemata valide bleibt.

Um diese Integration zu verdeutlichen, werden wir sie an einer kleinen Datenstruktur durchführen. Seien A und B zwei Elternelemente, die zueinander in der incompatible Beziehung stehen. A und B sollen gemäß der incompatible Beziehung miteinander zu C verschmolzen werden. Zu beachten sind dabei die Datentypen der Elternelemente, da aus ihnen der Datentyp von C bestimmt wird. Seien hier A und B vom Typ Sequence, dann wird C vom Typ Choice über die Sequences von A und B. Element A habe nun n Kinder, Element B m. Davon sind jeweils einige unique, weshalb sie im integrierten Schema als Kinder auftauchen müssen. Sie bleiben also in den Sequences erhalten. Finden sich jedoch Elemente, die miteinander verschmolzen werden können, wird in beiden Sequencen auf das verschmolzene Element verwiesen. Diese Prozedur wird über die Kinder weitergeführt, bis ein minimales globales Schema berechnet wurde.

Wir haben gesehen, daß die XML Schema Integration ein wirkungsvolles Werkzeug ist, um bekannte Schemata effizient zu verschmelzen. Probleme kann es noch immer geben, wenn die Semantik der einzelnen Elemente unklar ist, dann ist menschliches Eingreifen unumgänglich. Kommen aber die Daten wie in unserem anfangs angeführten Beispiel aus einem bestimmten, relativ engen Bereich, so sind semantische Überschneidungen zumindest unwahrscheinlich, so daß diese Methode ihr Ziel erfüllt.