Evolution von XML-Schemata auf konzeptioneller Ebene Übersicht: Der CodeX-Ansatz zur Lösung des Gültigkeitsproblems Thomas Nösinger, Meike Klettke, Andreas Heuer Lehrstuhl Datenbank- und Informationssysteme Institut für Informatik Universität Rostock (tn, meike, ah)@informatik.uni-rostock.de ABSTRACT die Gültigkeit bereits vorhandener XML-Dokumente verlet- If new requirements arise models have to be adapted to zen und macht eine Adaption dieser notwendig (siehe Ab- them. Additionally, the instances based on these models ha- bildung 1). ve to be adapted as well otherwise they might not be valid anymore. The same applies to the XML schema as a model XML-Schema Änderungen XML-Schema‘ and widely accepted description for XML documents. One solution for solving the occurring validity problem is the Gültigkeit Bestimmung der Änderungen Gültigkeit here described XML schema evolution. On the basis of a conceptual model the user interaction is analyzed and trans- XML-Dokumente Adaption XML-Dokumente‘ lated into transformation steps for the adaption of XML in- stances. The user interaction contains the use of predefined change operations on the conceptual model, a representation of the corresponding XML schema Figure 1: Das Gültigkeitsproblem nach [14] Categories and Subject Descriptors Der Vorgang der XML-Schemaänderung und der darauf folgenden Anpassung der XML-Dokumente wird als XML- I.7.1 [Document and Text Editing]; H.3.2 [Information Schemaevolution bezeichnet. Es existieren unterschiedli- Storage]; H.3.3 [Information Search and Retrieval]; che Ansätze zur Durchführung der XML-Schemaevolution D.2.8 [Metrics] [13]: Keywords 1. Die Anwendung einer expliziten Evolutionssprache. XML-Schemaevolution, konzeptionelle Modellierung, Gültig- 2. Der Vergleich zweier Versionen eines Modells und die keitsproblem, Instanzanpassung Ableitung von Transformationsschritten. 1. EINLEITUNG 3. Die Beobachtung und Auswertung der Nutzerinterak- Die dynamische Anpassung von Modellen an aktuelle Ge- tion, aus der dann Transformationsschritte abgeleitet gebenheiten birgt die Notwendigkeit, vorhandene Instanzen werden. Dieser Ansatz wird hier thematisiert. und Anwendungen an die neuen, eventuell veränderten Um- stände anzupassen. Ändert sich somit die strukturelle Be- Der erste Ansatz ist die Anwendung einer Evolutions- schreibung einer Datenbasis, muss zwangsläufig auch die Da- sprache zur XML-Schemaevolution. Dies entspricht im Da- tenbasis angepasst werden, damit die Gültigkeit bezüglich tenbankbereich dem Alter-Befehl der Data Definition Lan- des neuen Modells gewährleistet wird. Diese Problematik ist guage SQL. Zur Zeit ist dieser Ansatz aufgrund der feh- Kernpunkt des Gültigkeitsproblems, d.h. sind Instanzen lenden, standardisierten Evolutionssprache für XML-Sche- eines Modells nach dessen Änderung noch gültig? mata nicht anwendbar. Des Weiteren wird vom Anwender Die Veränderung der Struktur eines XML-Schemas bspw. an dieser Stelle ein tiefes Verständnis bzw. Expertenwissen durch das Umsortieren von Inhaltsmodellen, das Erhöhen der möglichen Sprachkonstrukte und deren Anwendung ver- des minimalen Vorkommens eines Elementes, das Einfügen langt. oder auch Umbenennen nicht-optionaler Elemente etc. kann Der zweite Ansatz ist die Versionierung von Modellen. Sind verschiedene Modelle vorhanden, dann können Trans- formationsschritte aus dem Vergleich beider Modelle erzeugt werden. Es müssen an dieser Stelle allerdings unterschiedli- che, eventuell nicht vergleichbare Versionen vorgehalten wer- den. Des Weiteren wird normalerweise bei syntaktischen und /oder semantischen Konflikten eine automatische Lösung basierend auf Heuristiken vorgeschlagen oder aber der An- wender zur Lösung benötigt. Dieses Vorgehen erfordert wie- 24th GI-Workshop on Foundations of Databases (Grundlagen von Daten- banken), 29.05.2012 - 01.06.2012, Lübbenau, Germany. derum ein tieferes Verständnis bzw. Expertenwissen der be- Copyright is held by the author/owner(s). teiligten XML-Schemaversionen. Der dritte Ansatz nutzt die Interaktion eines Anwenders erleichtern soll. PRISM++ ermöglicht keine XML-Schema- aus, indem von diesem getätigte Änderungen an einer kon- evolution, thematisiert allerdings die Notwendigkeit, auch zeptionellen Repräsentation eines XML-Schemas analysiert Integritätsänderungen vollziehen zu können. werden. Die Nutzeränderungen sind dabei die Anwendung In [9] wird das GEA Framework (Generic Evolution Archi- vordefinierter Operationen auf einem konzeptionellen Mo- tecture) vorgestellt, in dem XML-Schemata als UML-Klas- dell. Das somit erlangte Wissen wird für eine automatische sendiagramme mit Stereotypen beschrieben werden. Unter Erzeugung von Transformationsschritten zur Anpassung der Verwendung von elementaren Transformationsregeln werden XML-Dokumente und Anwendungen verwendet. Es wird im Änderungen in UML auf XML propagiert. Vergleich zu den ersten beiden Ansätzen weder vom Nutzer XCase [15] ist eine Implementierung von XSEM (kon- Expertenwissen bezüglich einer Evolutionssprache benötigt, zeptionelles Modell: Xml SEmantics Modeling), welches un- noch müssen unterschiedliche Versionen eines XML-Schemas ter Verwendung einer MDA (Model-Driven Architecture) vorgehalten, ausgewählt und verwendet werden. die XML-Schemaevolution durchführt. Es existieren unter- schiedliche Abstraktionslevel (u.a. PIM als Platform-Inde- 2. STAND DER FORSCHUNG pendent Model und PSM als Platform-Specific Model) die Änderungen auf abstrakterem Niveau ermöglichen und diese Die XML-Schemaevolution wird sowohl von den großen dann zwischen den verschiedenen Ebenen propagieren (ein Datenbank- und Softwareherstellern (u.a. Microsoft [4], IBM XML-Schema ist ein PSM). Dieser Ansatz ist dem hier vor- [3], Oracle [5], Altova [2]) als auch in Forschungsprototypen gestellten am ähnlichsten, unterscheidet sich aber grundle- (u.a. XCase [15], PRISM++ [8], X-Evolution [11], EXup [7] gend in der Herangehensweise der Erfassung von Änderun- und GEA [9]) thematisch behandelt und auch teilweise um- gen, deren Auswertung, Kategorisierung und dem Umfang gesetzt. möglicher Änderungen bezüglich eines XML-Schemas. Microsoft unterstützt den XML-Datentyp, lässt den Nut- Eine automatische Erzeugung von Transformationsschrit- zer in Collections XML-Schemata sammeln und danach mit- ten und die damit verbundene Anpassung von XML-Doku- tels einer Typisierung die Spalten einer Relation einem Sche- menten sind in den hier vorgestellten Forschungsprototypen ma zuordnen. XML-Instanzen typisierter Spalten können nicht möglich bzw. die umsetzbaren Änderungen sind nicht bezüglich ihres XML-Schemas auf Gültigkeit geprüft wer- umfangreich genug. Des Weiteren wird bei keinem der Pro- den, ändert sich allerdings ein XML-Schema, muss dieses totypen der hier vorgestellte Ansatz der XML-Schemaevo- unter einer neuen Version erneut eingefügt werden. Micro- lution verfolgt, es besteht somit weiterhin Forschungsbedarf soft unterstützt die hier angestrebte XML-Schemaevolution in dieser Thematik. nicht, sondern nutzt die Versionierung von XML-Schemata. IBM DB2 ermöglicht die Registrierung von XML-Schemata in einem XML-Schema-Repository (XSR) und eine anschlie- 3. FORMALE GRUNDLAGEN ßende Erweiterung dieser unter Beachtung von zehn stren- Eine Grundlage der XML-Schemaevolution ist das an der gen Kompatibilitätsanforderungen. In Oracle können Sche- Universität Rostock entwickelte, konzeptionelle EMX Mo- mata ebenfalls registriert und anschließend mittels der Me- dell (Entity Model for XML-Schema), das zur grafischen thoden copyEvolve und inPlaceEvolve evolutioniert werden. Modellierung von XML-Schemata im Forschungsprototypen Sowohl bei IBM als auch Oracle sind restriktive Anforderun- CodeX (Conceptual Design and Evolution for XML-Sche- gen gestellt, die nur eine Generalisierung des alten Schemas ma [12]) implementiert wurde. Die folgende Formalisierung ermöglichen und somit nur teilweise die angestrebte XML- des konzeptionellen Modells ist notwendig, um die bereits Schemaevolution unterstützen. erwähnten Änderungsoperationen auf dem EMX Modell de- Altova bietet mit Diffdog eine Erweiterung ihres Editors finieren zu können. an, mit dem zwei Schemata miteinander verglichen werden können, um nachfolgend XSLT-Skripte zur Transformation 3.1 Konzeptionelles Modell der Instanzen zu erzeugen. Treten bei dem Vergleich Kon- Das konzeptionelle Modell (MM ) ist ein Tripel, das aus flikte auf, d.h. es kann keine eindeutige Zuordnung zwischen Knoten (NM ), gerichteten Kanten zwischen Knoten (EM ) den unterschiedlichen Strukturen der XML-Schemata herge- und zusätzlichen Eigenschaften (FM ) besteht. leitet werden, dann wird vom Anwender eine manuelle Zu- MM = (NM , EM , FM ) (1) ordnung verlangt. Eine Automatisierung ist nicht möglich, eine Nutzerinteraktion und somit Expertenwissen bezüglich Die Knoten sind Elemente (elementsM ), Attributgruppen der XML-Schemata ist erforderlich. (attributegroupsM ), Inhaltsmodelle (groupsM ), Typen (ein- Die Prototypen X-Evolution [11] und EXup [7] nutzen eine fache (simple-typesM ), komplexe (complex-typesM )), Module grafische Oberfläche zur Spezifikation, Ausführung und Ve- (modulesM , u.a. externe XML-Schemata), Integritätsbedin- rifikation von Schemaänderungen (beschrieben durch Primi- gungen (integrity-constraintsM ) oder Annotationen (anno- tive), wobei die Updatesprache XSchemaUpdate für die Be- tationsM ). Die Knotenarten werden näher charakterisiert schreibung der Änderungen und die Dokumentadaption ver- (z.B. elements M = {elementM }, elementM = (ID, name, na- wendet wird. Eine Grundlage dieser Systeme ist ein DBMS, mespace, geometry, minoccur, maxoccur)), was auf Grund welches XMLTYPE unterstützt. EXup und X-Evolution ver- von Platzbeschränkungen an dieser Stelle und bei den fol- wenden darüber hinaus XSUpdate als Evolutionssprache, genden Modellen nicht vertieft werden soll. Die gerichteten welches XSPath nutzt (eine Teilmenge von XPath). Kanten werden jeweils zwischen Knoten definiert, wobei die PRISM++ [8] bietet einen fein-granularen Evolutionsme- Richtung die Zugehörigkeit (Enthalten-sein Beziehung) um- chanismus zur Evolution von Datenbankschemata, welcher setzt und gemäß der Möglichkeiten von XML-Schema fest- Datenbankadministratoren unter Verwendung von SMO-IC- gelegt wurden. MO (Evolutionssprache: Schema Modification Operators - Die zusätzlich zu definierenden Eigenschaften ermöglichen Integrity Constraints Modification Operators) die Evolution die Nutzer-spezifische Anpassung eines konzeptionellen Mo- dells, insofern dies erwünscht ist. Dazu zählen u.a. CodeX- von anderen Operationen. Eine Operation wird auf den oben Standardwerte zur Konfiguration des Editors, Angaben zur definierten Modellen ausgeführt. Pragmatik, Kosten, Namen und zur Version eines EMX Mo- Operation dells. Die Pragmatik (Pragmatik ∈ {kapazitätserhaltend, ka- Mx −−−−−−−→ Mx0 , x ∈ {M, S, D} (4) pazitätserhöhend, kapazitätsreduzierend}) ist im Zusammen- Operationen sind zum Beispiel: changeElementType (Um- hang mit den Änderungsoperationen notwendig, um den In- sortieren vom Inhaltsmodell), changeElementMinOccur (Er- formationsverlust durch nicht beabsichtige Modellanpassun- höhen des minimalen Vorkommens eines Elementes), add- gen zu verhindern. Die Kosten sollen die Steuerung von Än- ElementToComplexElement (Einfügen nicht-optionaler Ele- derungsoperationen ermöglichen, damit zu komplexe und so- mente) oder renameElement (Umbenennen eines Elemen- mit eventuell zu teure Transformationen verhindert werden tes). können. Kosten werden verwendet, um den Aufwand der Eine Übersicht über die Zusammenhänge zwischen den Änderungen zu bestimmen und gegebenenfalls eine Versio- Modellen und den Operationen ist in Abbildung 2 darge- nierung vorzuschlagen. stellt. Die renameElement-Operation soll exemplarisch auf 3.2 XML-Schema und XML-Instanzen den oben definierten Modellen betrachtet werden. Dies ist eine einfache Operation, kompliziertere Evolutionsoperatio- XML-Schema (XSD) als strukturelle Beschreibung von nen werden analog ausgeführt. XML-Instanzen ist formal durch das W3C definiert [6]. Ein XML-Schema (MS ) ist in unserem Kontext ein Tupel aus Knoten (NS ) und zusätzlichen Eigenschaften (FS ). Bezie- hungen zwischen den Knoten (z.B. gerichtete Kanten) sind implizit in den Knoten enthalten, die zusätzlichen Eigen- schaften sind Informationen zum Namen und der Version. MS = (NS , FS ) (2) Knoten sind laut abstraktem Datenmodell Definitionen (type-definitionsS ), Deklarationen (declarationsS ), Modell- gruppen (model-group-componentsS ), Gruppendefinitionen (group-definitionsS ), Annotationen (annotationsS ) oder Be- dingungen (constraintsS ). Neben der abstrakten Definition von Knoten existiert die Element-Informationseinheit, die Figure 2: EMX, XML-Schema und XML-Instanzen für jeden Knoten die Realisierung innerhalb eines XML- Schemas definiert, d.h. welche Inhalte und Attribute kön- nen verwendet werden oder nicht. A: renameElementM (IDValue, oldValue, newValue) XML-Instanzen (MD ) sind analog zum XML-Schema Tu- pel aus Knoten (ND ) und zusätzlichen Eigenschaften (FD ), ∀ n ∈ NM ∧ n.ID = IDValue: wobei die Beziehungen zwischen den Knoten wieder implizit if n ∈ elementsM in diesen enthalten sind. then n.name := newValue MD = (ND , FD ) (3) Wenn ein Nutzer die grafische Repräsentation eines Ele- Die Knoten einer XML-Instanz sind Dokumente (docu- mentes selektiert und das Attribut Name ändert, dann wird mentsD ), Attribute (attributesD ), Prozessanweisungen (pro- dieses in CodeX erkannt und als renameElementM Opera- cessing-instructionsD ), Namensräume (namespacesD ), Tex- tion geloggt. Regeln garantieren dabei, dass nur sinnvolle te (textsD ) oder Kommentare (commentsD ) [1]. Operationen geloggt werden (z.B. Voraussetzung für rena- Zusätzlichen Eigenschaften sind der Name, die Version, meElement-Operation: oldValue 6= newValue). Die Identi- Änderungseigenschaften und Signifikanz eines Dokumentes. fikation des selektierten Elements wird im konzeptionellen Die Änderungseigenschaften (changeable ∈ {true, false}) sol- Modell durch eine eindeutige ID gewährleistet. Neben der len bei XML-Instanzen den ungewollten Informationsverlust ausgeführten Operation, den beteiligten Werten und der ID verhindern (z.B. Entfernen von Elementen). Die Signifikanz müssen Informationen zum Kontext gespeichert werden. Da- (significance) ist ein normierter Wert, um bei Auswertungen zu zählen u.a. Angaben zum Gültigkeitsbereich, zu vorhan- von Dokumentkollektionen zum Finden von Standardwerten denen Referenzen und zum direkten Knotenumfeld (Positi- Dokumente priorisieren bzw. gewichten zu können. on in einem Inhaltsmodell etc.). Diese Kontextinformationen 3.3 Operationen sollen bei den nachfolgenden Operationen (renameElementS und renameElementD ) die Identifizierung des betroffenen Auf dem konzeptionellen Modell (EMX) werden vordefi- Elementes ermöglichen und die Verarbeitung erleichtern. nierte Änderungsoperationen vom Nutzer durchgeführt. Die anwendbaren Operationen lassen sich gemäß der Kategori- C: renameElementS (oldValue, newValue, context) sierung von Änderungsoperationen herleiten und charakte- risieren (siehe [10]). Charakteristika sind u.a. die Kapazi- ∀ n, m, k ∈ NS ∧ n 6= m ∧ n 6= k ∧ m 6= k ∧ context(n): tätsänderung (kapazitätserhaltend, kapazitätserhöhend oder // Globales Element mit neuem Namen existiert? kapazitätsreduzierend), der XML-Instanzeinfluss (Instanz- anpassung bei EMX-Änderung notwendig, nicht notwendig if n, m ∈ elementsS ∧ n.scope.variety = 0 global 0 ∧ oder abhängig vom Parameter), die herleitbaren bzw. ab- m.scope.variety = 0 global 0 ∧ n.name = oldValue schätzbaren Kosten einer Operation und die Abhängigkeiten ∧ m.name = newValue then newValue := uniqueName(newValue) ∧ 3.4 Zusammenhänge n.name := newValue Die Beschreibung der Operationen macht deutlich, dass es if ∃ k ∈ elementsS ∧ k .scope.variety = 0 local 0 ∧ Abhängigkeiten sowohl zwischen den Modellen als auch zwi- k .ref = oldValue schen den Operationen gibt. Zum Beispiel sind die Kontext- then ∀ k: k .ref := newValue informationen des konzeptionellen Modells für die Identifika- // Lokales Element mit neuem Namen, aber anderem Typ existiert? tion von Knoten im XML-Schema und/oder XML-Instanzen notwendig, zeitgleich lässt die Element-Informationseinheit elseif n, m ∈ elementsS ∧ n.scope.variety = 0 local 0 ∧ des XML-Schemas u.a. Aussagen über notwendige oder nicht m.scope.variety = 0 local 0 ∧ n.name = oldValue ∧ notwendige Anpassungen von XML-Instanzen zu (minOc- m.name = newValue ∧ n.type 6= m.type ∧ curs, maxOccurs). Diese Zusammenhänge wurden in der Ab- n.parent.name = m.parent.name bildung 2 dargestellt und führen zu folgenden Theoremen: then newValue := uniqueName(newValue) ∧ n.name := newValue Theorem 1. Ein konzeptionelles Modell MM wird durch 0 // Lokales Element, kein Namen-Typ-Konflikt? die Operation A eines Nutzers verändert zu MM . Sei B eine Beschreibungsvorschrift zur Abbildung (Korrespondenz) des elseif n ∈ elementsS ∧ n.scope.variety = 0 local 0 ∧ konzeptionellen Modells MM auf ein XML-Schema MS . C n.name = oldValue sei die Änderungsoperation zur Überführung von MS zu MS0 . then n.name := newValue Dann gilt: // Globales Element, kein Namen-Konflikt? A + B⇒C elseif n ∈ elementsS ∧ n.scope.variety = 0 global 0 ∧ n.name = oldValue Das Theorem 1 besagt: Sind die Operation des Nutzers auf then n.name := newValue dem EMX Modell und die Korrespondenzen zwischen dem if ∃ k ∈ elementsS ∧ k .scope.variety = 0 local 0 ∧ konzeptionellen Modell und dem XML-Schema bekannt, so k .ref = oldValue kann die Operation zum Anpassen des XML-Schemas her- then ∀ k: k .ref := newValue geleitet werden. Nachdem der Nutzer das konzeptionelle Modell verändert Theorem 2. Ein konzeptionelles Modell MM wird durch 0 hat, muss das entsprechende XML-Schema ebenfalls ange- die Operation A eines Nutzers verändert zu MM . Sei B ei- passt werden. Dafür wird das Log von CodeX geladen und ne Korrespondenz zwischen dem konzeptionellen Modell MM analysiert. Durch dieses Vorgehen sind die auszuführende und einem XML-Schema MS und sei D eine Korrespondenz Operation, die veränderten Werte und der entsprechende zwischen dem XML-Schema MS und MD . E sei die Ände- Knoten bekannt (Kontextinformationen). Durch die darauf- rungsoperation zur Überführung von XML-Instanzen MD zu 0 folgende Umbenennung eines Elementes im XML-Schema, XML-Instanzen MD , die bezüglich MS0 gültig sind. Dann gilt: müssen je nach Gültigkeitsbereich, umgebenen Knotenum- A + B + D⇒E feld und vorhandenen Referenzen weitere Anpassungen am XML-Schema vorgenommen werden. Zum Beispiel muss ge- Das Theorem 2 besagt: Sind die Operation des Nutzers auf prüft werden, ob eventuell gleich benannte, globale Elemente dem EMX Modell und die Korrespondenzen zwischen dem schon vorhanden sind oder ob Referenzen angepasst werden konzeptionellen Modell, dem XML-Schema und den XML- müssen. Die im konzeptionellen Modell gesammelten und im Instanzen bekannt, so kann die Operation zum Anpassen der Log gespeicherten Kontextinformationen erleichtern dies. XML-Instanzen hergeleitet werden. E: renameElementD (oldValue, newValue, context) Es können somit aus der Auswertung der Nutzerinterak- tion mit dem konzeptionellen Modell automatisch entspre- ∀ n ∈ ND ∧ FD .changeable: chende Transformationsschritte hergeleitet werden. if n ∈ elementsD ∧ n.node-name = oldValue ∧ context(n) 4. BEISPIEL then n.node-name := newValue Die vorgestellte renameElement-Operation wird nachfol- gend an einem durchgängigen Beispiel auf den unterschied- Der letzte Schritt in der XML-Schemaevolution ist die lichen Modellen angewendet. automatische Erzeugung von Transformationsschritten aus Der Knoten mit dem Namen ’nummer’ wird vom Nutzer den Änderungen des Nutzers am konzeptionellen Modell. ausgewählt und im konzeptionellen Modell verändert (siehe Nachdem das XML-Schema angepasst wurde, sind vorhan- Abbildung 3). Es sind keine Einschränkungen bezüglich der dene XML-Instanzen eventuell nicht mehr gültig (Gültig- Modellpragmatik oder der nicht zu überschreitenden Kosten keitsproblem). Dies kann aus den Charakteristika der Ope- gemacht worden (siehe FM ). CodeX erkennt, dass der aus- rationen, den gespeicherten Informationen des Logs und den gewählte Knoten eine spezifische ID (hier z.B. ’1’) hat und Anpassungen des XML-Schemas hergeleitet werden. Sind entsprechend ein Element ist. Wird nun das Attribut Name Instanzen betroffen (der XML-Instanzeinfluss der Opera- verändert, d.h. dieses Attribut bekommt den neuen Wert tion) und XML-Instanzen sollen verändert werden können ’ID’ (’nummer’ 6= ’ID’), dann wird dies in das Log geschrie- (FD .changeable), dann muss ein entsprechendes Transfor- ben. Im Log steht, dass die Operation renameElement(’1’, mationsskript erzeugt werden, das die Instanzen anpasst. ’nummer’, ’ID’) ausgeführt wurde. Des Weiteren werden an- In CodeX wird aktuell ein XSLT Skript (XML Stylesheet hand der eindeutigen Knoten-ID Kontextinformationen ge- Language Transformation) erzeugt, welches auf XML-Do- speichert, zum Beispiel die Gültigkeit (’lokal’), eventuelle kumente angewendet werden kann. Referenzen (ist in dem Fall aufgrund der Gültigkeit nicht ma und XML-Instanz ein zwingendes Element in einer Se- quenz war (minOccurs = ’1’), falls das globale Vaterelement ’event’ als Dokumentenwurzel ausgewählt wurde. Das be- deutet, dass alle XML-Instanzen die gültig bezüglich des alten XML-Schemas waren und die verändert werden sol- len (FD .changeable), entsprechend an das neue XML-Sche- ma angepasst werden müssen. Durch die Anwendung einer Operation auf dem konzep- tionellen Modell und der bekannten Korrespondenzen zwi- schen EMX Modell, XML-Schema und XML-Instanz, kann die Operation zum Anpassen der XML-Instanzen hergeleitet werden (siehe Theorem 2). Diese Operation bzw. die notwendigen Transformations- Figure 3: Konzeptionelles EMX Modell schritte sind in einem XSLT-Skript realisiert, welches für das Beispiel in Abbildung 5 dargestellt ist. möglich) und das Knotenumfeld (Vaterknoten ist gemäß der Kanteninformationen EM ’event’, Inhaltsmodell ist eine Se- quenz, zweite Position in Sequenz). Figure 5: XSLT-Skript zur XML-Instanzanpassung Figure 4: XML-Schema zum EMX Modell 5. UMSETZUNG Abbildung 4 ist das zum obigen EMX Modell gehören- Der CodeX-Editor bietet unterschiedliche Funktionalitä- de XML-Schema. Die Korrespondenzen zwischen dem kon- ten zur Durchführung und Unterstützung der XML-Sche- zeptionellem Modell und dem XML-Schema sind definiert, maevolution (siehe Abbildung 6). Unter anderem kann das d.h. es ist aufgrund der Abbildungsvorschriften möglich, das eine Modell in das andere zu überführen. Durch das Log Ergebnis ist bekannt, dass die renameElement-Operation ausgeführt wurde, diese Operation muss demnach auch auf dem XML- GUI Schemaänderung Datenbereitstellung Schema nachvollzogen werden. Es gibt dem Log folgend ein Visualisierung Import Export lokales Element ohne Referenzen im XML-Schema, welches den Namen ’nummer’ hat, in einer Sequenz an zweiter Stelle Evolutionsengine XSD Config XSD XML XSLT XSD Config steht und den Vater ’event’ besitzt. Dieses Element soll um- benannt werden, das Attribut ’name’ soll den neuen Wert ’ID’ erhalten. In dem überschaubaren Beispiel ist dies nur Dokument ein Knoten, der den entsprechenden Kontext hat und mittels Modell Mapping Spezifikation Operationen Konfiguration Instanzen Updateskripte & der renameElement-Operation umbenannt wird. Modell Daten Evolutionsspezifische Daten Evolutionsergebnisse Aufgrund der Anwendung einer Operation auf dem kon- Transformation Wissensbasis Log zeptionellen Modell (Operation und Kontextinformationen CodeX werden geloggt) und der bekannten Korrespondenzen, kann demnach die Operation zum Anpassen des XML-Schemas hergeleitet werden (siehe Theorem 1). Figure 6: Komponentenmodell von CodeX Durch die Umbenennung eines Elementes kann die Gültig- keit von XML-Instanzen betroffen sein. Es wurde die rena- konzeptionelle Modell bzw. dessen grafische Repräsentation meElement-Operation ausgeführt, welche laut Operations- von einem Nutzer verändert werden, was entsprechend in ei- spezifikation eine kapazitätserhaltende Operation ist. Des nem Log gespeichert wird. Welche Änderungen bzw. vordefi- Weiteren kann die Operation je nach Parametern (d.h. die nierten Operationen anwendbar sind, wird durch Operations- Kontextinformationen) einen Einfluss auf die Gültigkeit von spezifikationen beschrieben (siehe Kategorisierung in [10]). XML-Instanzen haben. Es muss zunächst der entsprechen- Das konzeptionelle Modell wird aus einem gegebenen XML- de Elementknoten im XML-Schema durch die Kontextinfor- Schema unter Verwendung vom Modell-Mapping Informa- mationen ermittelt werden. Es ist bekannt, dass das Ele- tionen (Korrespondenzen) extrahiert oder neu angelegt. Das ment ’nummer’ laut Korrespondenz zwischen XML-Sche- Log kann nach einer entsprechenden Analyse zur Erzeugung von XSLT-Skripten verwendet werden, welche die aus den 8. REFERENCES Nutzeraktionen hergeleiteten Transformationsschritte um- [1] XQuery 1.0 and XPath 2.0 Data Model (XDM) setzen. Diese Transformation nutzt die evolutionsspezifischen (Second Edition). http://www.w3.org/TR/2010/ Daten, u.a. erneut die Operationsspezifikation, XML-Sche- REC-xpath-datamodel-20101214/, December 2010. mainformationen, gegebene Konfigurationen oder auch Do- Online; accessed 01-March-2012. kumentkollektionen. Konfigurationen sind die zusätzlichen [2] Altova Produkt diffdog: XML-Schemavergleich. Eigenschaften (FM ) des konzeptionellen Modells, während http://www.altova.com/de/diffdog/ die Dokumentinstanzen zur Kostenabschätzung und gege- xml-schema-diff-tool.html, 2011. Online; accessed benenfalls zur Wertfindung verwendet werden können. Die 15-December-2011. Datenbereitstellung und Extraktion von Ergebnissen wer- [3] IBM DB2 LUW V9R7 Online Documentation. den entsprechend durch Import und Export-Komponenten http://publib.boulder.ibm.com/infocenter/ realisiert. db2luw/v9r7/index.jsp, 2011. Online; accessed 15-December-2011. 6. ZUSAMMENFASSUNG [4] Microsoft technet: Verwenden von xml in sql server. Die XML-Schemaevolution behandelt das Gültigkeitspro- http://technet.microsoft.com/de-de/library/ blem. Wenn sich XML-Schemata ändern und somit an neue ms190936(SQL.90).aspx, 2011. Online; accessed Gegebenheiten bzw. Anforderungen angepasst werden, müs- 15-December-2011. sen deren Instanzen zur Wahrung der Gültigkeit ebenfalls [5] Oracle XML DB Developer’s Guide 11g Release 2 adaptiert werden. Dies sollte weitestgehend automatisch er- (11.2). http://docs.oracle.com/cd/E11882_01/ folgen. Im präsentierten Ansatz wird ein konzeptionelles Mo- appdev.112/e23094/xdb07evo.htm, 2011. Online; dell verwendet, welches eine vereinfachte, grafische Reprä- accessed 12-December-2011. sentation eines XML-Schemas ist. Wird das konzeptionelle [6] W3C XML Schema Definition Language (XSD) 1.1 Modell durch vordefinierte Operationen von einem Nutzer Part 1: Structures. http://www.w3.org/TR/2012/ verändert, dann wird das damit gewonnene Wissen entspre- PR-xmlschema11-1-20120119/, January 2012. Online; chend geloggt und danach für die Anpassung des XML-Sche- accessed 01-March-2012. mas und der XML-Instanzen angewendet. In diesem Zusam- [7] F. Cavalieri. EXup: an engine for the evolution of menhang sind Kontextinformationen und Korrespondenzen XML schemas and associated documents. In zwischen den Modellen entscheidend, denn nur durch diese Proceedings of the 2010 EDBT/ICDT Workshops, Informationen können automatisiert Transformationsschrit- EDBT ’10, pages 21:1–21:10, New York, NY, USA, te aus der Nutzerinteraktion hergeleitet werden. 2010. ACM. Die einzelnen Modelle wurden kurz vorgestellt, bevor die [8] C. Curino, H. J. Moon, A. Deutsch, and C. Zaniolo. renameElement-Operation formal beschrieben wurden. Die Update Rewriting and Integrity Constraint Zusammenhänge der einzelnen Modelle und die Anwendung Maintenance in a Schema Evolution Support System: der renameElement-Operation wurde ebenfalls thematisiert. PRISM++. PVLDB, 4(2):117–128, 2010. An einem durchgängigen Beispiel wurde darüber hinaus dar- [9] E. Domı́nguez, J. Lloret, B. Pérez, Á. Rodrı́guez, gestellt, wie diese Operation auf den einzelnen Modellen an- A. L. Rubio, and M. A. Zapata. Evolution of XML gewendet wird. Des Weiteren wurde CodeX als Forschungs- schemas and documents from stereotyped UML class prototyp präsentiert, der zur Realisierung und Durchfüh- models: A traceable approach. Information & Software rung der XML-Schemaevolution unerlässlich ist. Technology, 53(1):34–50, 2011. Ein hier nicht ausführlich, aber dennoch in CodeX bereits [10] H. Grunert. XML-Schema Evolution: Kategorisierung vorhandener Aspekt ist die Berücksichtigung von Kosten- und Bewertung. Bachelor Thesis, Universität funktionen bei der XML-Schemaevolution. Aktuell werden Rostock, 2011. die möglichen Kosten einer Evolution anhand der durchzu- führenden Änderungsoperation abgeschätzt und mit einem [11] G. Guerrini and M. Mesiti. X-Evolution: A Nutzer-spezifischen Grenzwert verglichen. CodeX kann so Comprehensive Approach for XML Schema Evolution. konfiguriert werden, dass bei Überschreitung dieses Wertes In DEXA Workshops, pages 251–255, 2008. Änderungsoperationen abgelehnt werden und stattdessen ei- [12] M. Klettke. Conceptual XML Schema Evolution - the ne Versionierung vorgeschlagen wird. CoDEX Approach for Design and Redesign. In BTW Workshops, pages 53–63, 2007. [13] M. Klettke. Modellierung, Bewertung und Evolution 7. AUSBLICK von XML-Dokumentkollektionen. Habilitation, CodeX bietet derzeit Basisfunktionalitäten zur Modellie- Fakultät für Informatik und Elektrotechnik, rung von XML-Schema und zur XML-Schemaevolution an. Universität Rostock, 2007. Momentan fehlen allerdings die Behandlung von Integritäts- [14] M. Klettke, H. Meyer, and B. Hänsel. Evolution — bedingungen, Namensräume, die Beachtung von Dokument- The Other Side of the XML Update Coin. In 2nd kollektionen und die Auswertung und Speicherung der Kon- International Workshop on XML Schema and Data textinformationen. In Zuge der Anpassung und Erweiterung Management (XSDM), Tokyo, April 2005. soll CodeX als Webapplikation freigeschaltet werden, damit [15] J. Klı́mek, L. Kopenec, P. Loupal, and J. Malý. XCase der Prototyp von anderen Anwendern zur XML-Schemaevo- - A Tool for Conceptual XML Data Modeling. In lution verwendet werden kann. ADBIS (Workshops), pages 96–103, 2009. Des Weiteren werden die bisher vorhandenen Beschrei- bungen der Änderungsoperationen gemäß der Kategorisie- rung von [10] erweitert, formal beschrieben und integriert.