Page ThesisDB4ECGStatus

((short description what this page is about))

Bericht 1

Zunächt habe ich die Anforderungen der überarbeiteten und somit leicht modifizierten Augabenstellung entsprechend angepasst.

Dann habe ich mich über QPath bzw. XQuery informiert und die Abspeicherung der Stringrepräsentationen der MPE in einer XML Datenbank in Betracht gezogen. Dazu habe ich das durch die Stringrepräsentation eines MPE gegebene XML Dokument aufgrund der in verschiedenen Quellen angegebenen Kriterien als ein semistrukturiertes, dokumentenzentriertes XML-Dokument klassifiziert. Dem entsprechend habe ich Überlegungen bezüglich einer geeigneten Speicherung der XML-Dokumente und Architektur einer möglichen verwendeten (nativen) XML-Datenbank angestellt.(siehe Grafik "Speicherung und Architektur von XML Datenbanken").

gelesenes Material

• D. Draheim and L. Pekacki: Process-Centric Analytical Processing of Version Control Data, 2003 Intl. Workshop on Principles of Software Evolution (IWPSE-03), Helsinki, Finnland, Sep 2003
• Jan Baumann: XML & Datenbanken http://www.wwz.unibas.ch/wi/lehre/swi/arbeiten05/xmldb.pdf
• Tekla Kiss, Helge Richter und Alexander Grahl: Native XML Datenbanken http://www.ipsi.fraunhofer.de/~lehti/seminar2003/thema2.doc

zu betrachtende Problemstellungen

Sind in der String(XML)- Repräsentation des MPE wirklich alle relevanten Daten des Event-Package-Objekts enthalten, so dass man daraus wieder genau entsprechendes EventPackage-Objekt rekonstruieren kann?

Wie sieht es mit der Performance von nativen XML-Datenbanken aus?

Wie mächtig sind die XML-Anfragesprachen, was lässt sich damit realisieren?

Bericht 2

Weitere Vertiefung in das Gebiet der nativen XML Datenbanken, mit Fokus auf der nativen, modellbasierten XML Datenbank Apache Xindice.

Überlegungen zur Erzeugung eines XML Dokuments, in dem die komplette Information des EventPackage-Objekts mit seinen Attributen enthalten ist, um dieses XML Dokument dann in die Datenbank zu schreiben und daraus auch wieder das EventPackage - Objekt rekonstruieren zu können.

gelesenes Material

• Apache Xindice Administrator Guide: http://xml.apache.org/xindice/guide-administrator.html
• Apache Xindice User Guide: http://xml.apache.org/xindice/guide-user.html
• Apache Xindice Developer Guide: http://xml.apache.org/xindice/guide-developer.html
• Xindice 1.1 XPath Guide: http://xml.apache.org/xindice/guide-xpath.html

zu betrachtende Problemstellungen

• Zur Anfrage der Dokumente in Xindice wird XPath verwendet. Sind die geforderten Anfragen mit XPath realisierbar?

Bericht 3

Aufgrund nun eindeutig abgestimmter Anforderungen und sich daraus ergebenden Argumenten, welche in Richtung einer relationalen Abbildung weisen, verabschiede ich mich (zunächst) von der Idee die MPEs in einer nativen XML Datenbank zu speichern.

Alle Typen von MPEs haben eine feste gemeinsame Menge von Standardattributen, welche in einer Relation gespeichert werden sollen.

Diese Attribute werden voraussichtlich sein:

• Benutzer
• Typ
• Zeit (in ms)
• Datum
• Projekt

Die typspezifischen Attribute eines MPE werden dann entweder in einer weiteren Tabelle gespeichert und entsprechend mit dem Eintrag in der Tabelle der Standardattribute verknüpft. Eine andere Möglichkeit wäre, für jeden MPE Typ eine Tabelle anzulegen, in der sowohl die Standardattribute des MPE als auch die Detailattribute dieses MPE Typs gespeichert werden.

zu betrachtende Problemstellungen

Aufgrund der Art und Häufigkeit der entstehenden Anfragen muss entschieden werden, ob die Speicherung der MPEs in einer großen Standardattributtabelle mit verknüpfter Detailattributtabelle geeigneter ist, oder die Speicherung der Standard- und Detailattribute gemeinsam in MPE-Typ spezifischen Tabellen.

Weiterhin muss das DataBaseTargetModule die Standardattribute in geeigneter Form aus einem EventPacket (insbes. aus der ArgList) extrahieren können. Gleiches gilt für die Detailattribute.

Bericht 4

Die Standardattribute werden nicht durch den direkten Zugriff auf die ArgList in ValidEventPacket extrahiert, sondern durch dafür von ValidEventPacket bereitgestellte Methoden. Des weiteren wird zur Erzeugung des XML Dokuments aus dem String der ArgList der von ECG bereitgestellte XML Parser genutzt.

zu betrachtende Problemstellungen

Zur Speicherung der typspezifischen Attribute eines MPE ist eine Abbildung zwischen den Attributen und der dem XML-Schema entsprechenden Tabelle notwendig. Des weiteren muss erkannt werden, ob für einen gegebenen Ereignistyp bereits eine dem Schema entsprechende Tabelle existiert oder nicht. Ist keine entsprechende Tabelle vorhanden, so muss eine solche erzeugt werden.

Bericht 5

Ausführliche Evaluierung der Quelle http://www.rpbourret.com/xml/XMLAndDatabases.htm bezüglich der Abbildung der XML Dokumente in die relationale Datenbank.

IM ECGLab wird XML zum Datentransport verwendet, es handelt sich also um datenzentrierte Dokumente, mit ziemlich regelmäßiger Struktur und das Interesse liegt mehr oder weniger auf den im XML Dokument enthaltenen Daten und nicht auf dem gesamten XML Dokument.

Daten werden üblicherweise in relationalen Datenbanken gespeichert, weshalb ich mich für das DBMS MySQL entschieden habe. Läge mein Interesse auf der Speicherung von ganzen XML Dokumenten, so wäre eine nativen XML Datenbank vorzuziehen gewesen.

Um Daten zwischen XML Dokumenten und einer Datenbank transferieren zu können, muss das Schema des XML Dokuments auf das Datenbankschema abgebildet werden. Eine Software für den Datentransfer baut dann auf dieser Abbildung auf.

Generell gesehen gibt es zwei Möglichkeiten der Abbildung von XML Schemata in Datenbankschemata:

1. tabellenbasierte Abbildung
   • modelliert XML Dokumente als einzelne Tabelle oder als Menge von Tabellen
   • Konsequenz bei einem solchen "round-tripping" eines XML Dokuments (also dem Speichern der Daten aus dem Dokument in die Datenbank und dann rekonstruieren des Dokuments aus diesen Daten) ist oft, dass das rekonstruierte Dokument nicht genau dem ursprünglichen Dokument entspricht.
2. Objektrelationale Abbildung
   • die Daten in dem Dokument werden als Baum von Objekten modelliert, welche spezifisch zu den Daten im Dokument sind.
   • das Modell wird dann in die relationale Datenbank gemapped, indem Klassen in Tabellen und skalare Eigenschaften in Spalten abgebildet werden.
   • Damit werden die Daten zwischendem XML Dokument und den Objekten transferiert (XML data binding) und zwischen den Objekten und der Datenbank.

Ich werde voraussichtlich die objektrelationale Abbildung wählen und habe mich für das Mapping von XML --> JavaBean für das Tool JaxMe, einer OpenSource Implementierung von JAXB, entschieden. Zur weiteren Abbildung der JavaBean in die Datenbank soll Hibernate zum Einsatz kommen.

Bericht 6

Der Einsatz von JaxMe zum Mapping von XML → Java, dem sog. unmarshalling, ist aufgrund eines Bugs in JaxMe bzgl. des XML Namensraums von XML Dokumenten nicht möglich. der Bug hätte nur durch eine Modifikation der MSDT - XML Schemata umgangen werden können, wovon ich aber absehen wollte.

Daher habe ich andere Frameworks für das Mapping XML <-> Java <-> Datenbank in Betracht gezogen und mich in jedes soweit hineingearbeitet, dass ich mir einen Überblick über die jeweilige Arbeitsweise und die Vor- und Nachteile schaffen konnte. Näher betrachtet habe ich die Frameworks Hibernate und Castor auch im Vergleich zu JaxMe.

Das Framework Castor geht den Weg über die Generierung von Java aus XML und bildet diese Java Klassen dann mit Hilfe einer Mapping Datei in die Datenbank ab. Die Generierung von Java Klassen, falls das im ECG überhaupt wirklich in geeigneter Form möglich wäre, stellt ansonsten aber keinen Nutzen dar.

In einem Artikel über Hibernate 3 (http://www.devx.com/Java/Article/27896) las ich, dass Hibernate nun auch das direkte Abbilden von XML in eine Datenbank unterstützt, also ohne Generierung von Java, sondern lediglich mit Hilfe einer Mapping - Datei. Dabei gilt, dass Hibernate XML Dokumente sozusagen wie Java Objekte behandelt und die einzelnen Elemente aus dem XML Dokument mit der entsprechenden Mapping - Datei dann auf Tabellen und Spalten abbildet. Aber auch in der Hibernate Doku, welche zu Thema XML Mapping eher knapp gehalten ist steht, dass dieses noch ein experimetelles Feature "under extremely active development" ist. Doch da ich diesen Ansatz des direkten XML - Mappings in die Datenbank für die Zwecke des ECG Labs ziemlich optimal finde, habe ich mich in das Thema hereingearbeitet und die entsprechende Hibernate "Umgebung" mit Datenbank, Konfigurations- und Mapping - Datei aufgebaut. Doch leider ist es mir nicht gelungen, ein XML Dokument entsprechend einer Mapping - Datei einzulesen und zu verarbeiten. Und obwohl ein Framework an sich eine schöne Sache ist und zur Minimierung von Fehlern und Aufwand beiträgt, sah ich den Aufwand für ein "experimentelles" Feature, dessen Funktionalität nicht einmal wirklich sicher gestellt ist, irgendwann dann nicht mehr gerechtfertigt. Deswegen werde ich jetzt von der Verwendung eines Frameworks absehen und die Abbildung von Events komplett selbst implementieren, was ich dann auch entsprechend besser auf die Anwendung im ECG Lab anpassen kann.

Bericht 7

Das Extrahieren der Daten aus den XML Dokumenten und deren Abbildung in entsprechende Datenbanktabellen bringt mehrere separat zu betrachtete Problemstellungen mit sich:

• es reicht nicht, beim Einfügen von Daten in eine Tabelle zu überprüfen, ob die Tabelle bereits existiert und falls dies nicht der Fall ist, einfach eine neue Tabelle, mit den Elementnamen des XML - Dokuments entsprechenden Spalten zu generieren. Beim Auslesen der Elementnamen aus den XML-Dokumenten können zwar die Namen für die Spalten der zu generierenden Tabelle entnommen werden, jeoch ist keine Aussage bzgl. des Datentyps der Elemente, bzw. der Spalten möglich. Daher müssen die Informationen zur Erstellung neuer Tabellen aus den XML Schemata der MSDTs gezogen werden.

• Das bedeutet, dass ein Mechanismus gefunden werden muss, der bei Veränderung oder Hinzufügen eines Schemas eine dem Schema entsprechende Tabelle erstellt bzw. eine existierende Tabelle evtl. verändert. Es müssen also die existierenden Tabellen mit den existierenden MSDT Schemata abgeglichen werden.

• Dazu wiederum muss ein XML-Schema in geeigneter Form eingelesen und "ausgewertet" werden können und die entsprechende Information in ein "CREATE TABLE ..." umgesetzt werden.

• Ein weiteres Problem stellen optionale Elemente in den XML-Schemata dar, welche in dem neuen Release des ECG Lab bereits existieren.

Optionale Elements entsprechen einem möglichen NULL Wert in der Datenbank. Ein Problem stellt sich jedoch bei der dynamischen Generierung der Parameter für den "INSET INTO.." - String um die jeweilgen Daten aus einem XML-Dokument in die Datenbank einzufügen. Die Elemente in diesem String müssen der Reihenfolge der Tabellenspalten entsprechen. Doch extrahierte ich ganz schlicht nacheinander die Daten aus den XML Dokumenten, so erhalte ich keine Information aus den XML Dokumenten darüber, ob optionale Elemente in dem jeweiligen XML Dokument nun gerade vorhanden sind oder nicht. Ich kann mich also nicht mehr darauf verlassen, dass ich überhaupt für alle Spalten der Datenbanktabelle Daten aus dem XML-Dokument erhalte, denn NULL Werte stehen nicht im XML-Dokument. D.h. ich müsste explizit für jedes ELement im XML-Dokument den Namen und den Wert herausziehen und dass ganze dann mit den Informationen aus dem entsprechenden XML-Schema abgleichen, um so herauszufinden für welche evtl. nicht vorhandenen optionalen Elemente in diesem Dokument NULL Werte in der Datenbanktabelle eingefügt werden müssen.

gelesenes Material

Mapping W3C Schemas to Object Schemas to Relational Schemas: http://www.rpbourret.com/xml/SchemaMap.htm

Bericht 8

Um den im vorhergehenden Bericht betrachteten Problemstellungen bezüglich der Generierung und Veränderung von Datenbanktabellen gerecht zu werden ist es nötig die XML Schemata der verschiedenen Ereignistypen zu parsen, um somit Informationen über Elemente und deren Datentyp zu erhalten. Auch nach nach ausführlicher Suche konnte ich kein passendes Tool bzw.Framework ausfindig machen, welches eine API bereitstellt mit der es möglich wäre aus einem XML Schema entsprechende Informationen zu erhalten. Ich fand lediglich Frameworks, welche die Möglichkeit bieten aus den XML - Schemata Klassen zu generieren, um dann von diesen Klassen Objekte zu erstellen, welche schemakonforme XML Dokumente darstellen.

Diese Frameworks (z.B. Apache XMLBeans), welche XML-Schemata in 'Objektschemata' abbilden, sollen jedoch den Zugriff und das Modifizieren von Daten in (datenzentrierten) XML Dokumenten aus einer Anwendung heraus erleichtern.

Diese Abbildung von XML-Schemata auf Objektschemata finde ich für die betrachteten Zwecke im ECG-Lab nicht passend, denn zum einen geht es hierbei nicht um den Zugriff auf Daten in einem XML Dokument und zum anderen wäre es schlecht für die Dynamik bezüglich veränderter oder hinzukommender MSDT - Schemata, wenn aus diesen erst Klassen und *.jar Files generiert und dann entsprechend verwendet werden müssten.

Der zentrale Punkt ist das extrahieren von Informationen aus einem XML-Schema, wobei ich den Weg gewählt habe das jeweilige Schema mit dem Apache Xerces Parser zu parsen, um dann die entsprechende Information zu erhalten und in geeigneter Weise zu speichern.

Bisher habe ich eine Art 'Infrastruktur' von Klassen mit verschiedenen Verantwortlichkeiten aufgebaut:

• XML Schema parsen und informationen extrahieren
• Datentypen der Elemente aus dem XML - Schema in entsprechende SQL - Datentypen abbilden
• Informationen über Elements in geeigneter Weise speichern (eigener Datentyp entworfen)
• Informationen über SQL - Tabellen aus der Datenbank holen
• Informationen über die Tabellen in geeigneter Weise speichern, so dass ein Vergleich von XML - Schema und Tabellenschema möglich ist
• XML - Schema und Tabellenschema vergleichen und ggf. Tabelle verändern oder neu erzeugen
• aus den Informationen über ein XML - Schema entsprechende SQL Befehle generieren

Diese 'Infrastruktur' ist aber noch nicht komplett implementiert und auch nicht getestet und ich vermute, dass das extrahieren und speichern der richtigen von Informationen aus einem XML - Schema nicht so ganz so klappen wird wie ich es brauche und wie ich es mit dem Apache Xerces J2 und dessen Schema API zu implementieren versuche.

Bericht 9

Implementiert und getestet ist der Mechanismus, dass die Daten dem EventPacket und somit dem darin enthalteten XML Dokument entnommen und in der Datenbank eingefügt werden. Das ganze ist bisher so realisiert, dass das DatabaseTargetModule in seiner write() - Methode das EventPacket in "Empfang" nimmt und dieses weiter an die Methode controlEventToDB(ValidEventPacket eventPacket) gibt.

Diese widerum übergibt das EventPacket einer Instanz der Klasse CreateSql, welche mit Hilfe der Proxyklasse für das EventPacket (ValidEventPacketProxy) die Daten aus dem EventPacket extrahiert und die entsprechenden "INSERT INTO.." Strings für die Einfügeoperation der Datenbank generiert.

Dabei wird auch ein Datenbank Proxy (DatabaseProxy) verwendet, der vor der Generierung der SQL-Strings aus der Datenbank die Metainformationen der entsprechende Tabelle holt und diese (die Spaltennamen) in der selben Reihenfolge wie in der Tabelle vorkommend, in einen Vector schreibt. Für jedes Element des Vectors (also jede Spalte der Tabelle) wird dann bei der Generierung des SQL-Strings mit Hilfe der Klasse ValidEventPacketProxy geschaut, ob in dem XML Dokument auch ein Element mit dem entsprechenden Namen vorhanden ist. Falls ja, wird von der Methode ValidEventPAcketProxy.getElementValue(String elementName) der entsprechende Wert zurück geliefert und in den SQL-String eingetragen. Ist in dem XML Dokument kein entsprechendes Element vorhanden, weil es sich beispielsweise um ein optionales XML-Element handelt, so wird von der Methode ValidEventPAcketProxy.getElementValue(String elementName) NULL zurück geliefert und auch dieses in den SQL-String eingetragen. Somit richtet sich die Einfügeoperation nach den in der Tabelle vorhandenen Spalten, und für Spalten optionaler Elemente des XML-Dokuments wird ggf. ein null Wert in die Datenbank eingetragen.

Noch nicht realisiert ist die dynamische Anpassung und Generierung der Datenbanktabellen bei veränderten oder neu eingeführten MSDT XML-Schemata.

Bericht 10

Ich habe weiter an dem im vorigen Bericht erwähnten Mechanismus zur Speicherung von Events gearbeitet. Dabei habe ich Veränderungen, Verbesserungen und weitere Tests durchgeführt. Wird ein Event in die Datenbank eingefügt, so wird der Event über zwei Tabellen 'verteilt'. Zum einen kommen die Daten welche für alle Events gleich sind in eine Tabelle 'common' und die restlichen eventspezifischen Daten in eine dem Event entsprechende Tabelle. Dabei sind mehrere Dinge zu beachten:

1. die Daten des Events in den zwei Tabellen müssen verknüpft werden
2. es darf nicht vorkommen, dass ein Event nur teilweise in eine Tabelle eingefügt wird. Wenn beim Einfügen in die eine Tabelle ein Fehler auftritt, dürfen auch nicht die Teildaten des Events in die andere Tabelle eingefügt werden.
3. Wenn Eventdaten aus einer der beiden verknüpften Tabellen gelöscht werden müssen auch die entsprechenden Daten aus der anderen Tabelle gelöscht werden.

Diese Dinge sind nun implementiert und folgendermaßen gelöst:

1. Die Tabelle mit den 'common' Daten hat eine Spalte 'id' welche eindeutige Zahlen enthält. Beim Einfügen einer Reihe in die Tabelle wird für diese Spalte vom Datenbanksystem automatisch (incrementell)eine Zahl generiert. Diese generierte Zahl lasse ich mir nach der Einfügeoperation in die 'common' Tabelle von der Datenbank zurück geben und übergebe sie dann der Einfügeoperation für die eventspezifische Tabelle als Variable.
2. Damit ein Event nur in beide oder in keine der Tabellen eingefügt wird habe ich das Auto-Commit der Datenbankverbindung auf false gesetzt und lasse die Verbindung erst dann alle Daten festschreiben wenn alle unter 1 erwähnten Operationen erfolgreich durchgelaufen sind. Sollte es zwischendurch zu einer Exception kommen so wird ein rollback durchgeführt.
3. Damit nicht nur ein Teil eines Events aus einer der Verknüpften Tabellen gelöscht wird habe ich zwischen der 'id' Spalte der 'common' Tabelle und der 'id' Spalte der msdt-spezifischen Tabellen eine Fremdschlüssel Beziehung hergestellt.

Bericht 11

Um eine Art Proxy für die msdt Schemata zu entwerfen, über den man dann Informationen über das Schema selbst in geeigneter Form erhalten kann, habe ich mir das Apache Projekt XMLBeans genauer angesehen.

Zunächst einmal habe ich mir einen Überblick verschafft, wofür diese Technologie eingentlich entworfen wurde, was sie kann und welche Möglichkeiten sie einem bietet die gewünschten Ziele zu erreichen.

XMLBeans erleichtert den Zugriff auf XML, indem es das XML an Java Klassen bindet und dann über 'bean-like' setter- und getter- Methoden den Zugriff auf das XML ermöglicht.

Die XMLBeans API bietet jedoch auch ein XML Object Model, über welches man Informationen über ein XML Schema selbst erhalten kann. Und genau diesen Teil fand ich für die Idee eine 'Schema-Proxys' interessant und habe genauer untersucht inwieweit diese Möglichkeiten für den Gebrauch im ECG_Lab geeignet sind.

Man kann die XMLBeans API in drei Kategorien unterteilen:

• XmlObject API: Alle java Klassen die aus XML Schemata generiert wurden sind von XMLObject abgeleitet und bieten über getter- und setter- Methoden Zugriff auf die DAten der Instanzen (XML-Dokumente)

• XMLCursor API: mit einem XML Cursor ist es möglich Informationen aus dem XML Infoset eines XML Dokuments zu erhalten

• SchemaType API: bietet ein komplettes Objekt Modell eines XML Schemas, welches die 'Metainformationen' eines XML Schemas wiederspiegelt und auch entsprechende Methoden bietet um diese Informationen zu extrahieren.

Ich habe die SchemaType API für ein geeignetes Mittel empfunden um aus den msdt XML Schemata geeignete Informationen zu erhalten. Beispielsweise um Schema-Elemente und -Datentypen mit den Datenbanktabellen abzugleichen und so das dynamische Anpassen der Datenbanktabellen an modifizierte Schemata umzusetzen.

Nachdem ich mich eine Weile mit dem Komponenten- und Typsystem der XMLBeans API auseinandergesetzt habe, habe ich nun einen ersten Entwurf des SchemaProxys fertiggestellt und getestet, der ein beliebiges Schema einliest, es 'compiliert' (Datenmodell aufbaut) und rekursiv die Baumstruktur des XML Schemas durchläuft. Dabei wird jeder Knoten auf gewisse (alle möglichen) Eigenschaften überprüft und in Abhängigkeit davon wird der Algorithmus fortgesetzt.So lange bis alle einfachen Elemente (Blätter des XML Schema Baums) erreicht sind und mit den entsprechenden Namen und Datentypen ausgegeben werden.

Um dieses zu veranschaulichen habe ich eine Grafik erstellt, die diesen Algorithmus skizziert (XSDSchema.pdf im Anhang).

Ausstehende Problemstellungen:

• verfeinern des SchemaProxys, geeignete Ausgaben erzeugen
• Datenbanktabellen mit den Ausgaben des SchemaProxys abgleichen und Tabellen ggf. dynamisch anpassen

Bericht 12

Ich habe weiter an dem Schema Proxy gearbeitet und dieses dahin gehend weiter entwickelt, dass es nun möglich ist die Namen und 'Datentypen' der Elemente auszulesen, welche später die Spalten in den Datenbanktabellen darstellen sollen. Die Elemente werden in einem Vector von Elementen (selbst definierter Typ 'Element') zurück gegeben. Ein Object vom Typ Element besitzt drei Attribute :

• Name
• Sql Datentyp
• Xml Datentyp

Beim extrahieren eines Elements aus einem XML Schema wird zunächst nur der Name und der XmlDatentyp gesetzt. Dann wird dieses Element einer Methode übergeben, welches dem XML Datentyp des Elements den entsprechenden Sql Datentyp zuordnet und diesen in das Sql Datentyp Attribut des Elements schreibt.

Auf Grundlage solcher Elemente können dann XmlSchema und existierende Tabellen verglichen und Tabellen ggf. erstellt oder angepasst werden. Dazu liefert eine Klasse DBCommunicator durch entsprechende Informationen, welche sie ebenfalls durch Instanzen der Klasse Element zurück gibt.

Nun sind vorerst verschiedene Punkte zu klären,

• Inwieweit kann ein Schema modifiziert werden, dürfen beispielsweise Elemente umbenannt oder gelöscht werden, wie sollten diese Änderungen in mit der Datenbank kommuniziert werden
• wie soll der Ablauf der "Synchronisierung" von XML Schemata und Datenbanktabellen beim Sart des ECG_Labs sein
• die "Synchronisierung" darf nur in Richtung DB Tabellen gehen, es dürfen also nur Änderungen der Schemata in den Tabellen nachvollzogen werden

Bericht 13

Der XMLSchemaProxy ist nun insoweit implementiert, dass er in seiner getSchemaProperties() - Methode alle Element - Deklarationen in einem Schema auf sämliche relevanten Eigenschaften untersucht um dann das Schema auf entsprechende Tabellen in der Datenbank abzubilden. Dabei wird werden folgende Heuristiken verfolgt:

• jedes Element, welches ein 'complex Type' ist wird in eine eigene Tabelle in der Datenbank abgebildet.
• jedes Element welches ein 'simple Type' ist wird als Spalte in der Tabelle des übergeordneten 'complex type' Elements abgebildet
• kann ein 'simple Type' Element mehr als einmal in einer Dokumenteninstanz des XML Schemas vorkommen (maxOccurs>1), so wird für dieses Element ebenso eine eigene Tabelle in der Datenbank angelegt.
• 'complex Type' Elemente können Attribute haben, diese werden dann auch in einer eigenen Tabelle in der Datenbank abgelegt.

Die Methode getSchemaProperties liefert als Rückgabewert einen Vector, welcher für ein msdt Schema alle nötigen Tabellen mit ihren jeweiligen Spaltennamen und -typen enthält, um Instanzen (XML Dokumente) des Schemas in der Datenbank zu speichern. Gleichzeitig generiert die Methode die sog. TableInformation für jedes Schema. TableInformation ist eine mit dem Singleton-Pattern implementierte Klasse deren Instanz in einer HasMap zu jedem msdt-Typ die Namen der zu diesem msdt-Typ gehörigen Tabellen hält. damit ist festgehalten, welche Tabellen man bein Einfügen oder Extraherien eines msdt Typs in die bzw. aus der Datenbank betrachten muss.

Da neue Eventtypen mit entsprechenden Schemata hinzu kommen können oder existierende Eventtypen erweitert werden können, müssen beim Start oder nach dem Ändern bzw. Hinzufügen eines Eventtyps die Schemata mit den in der Datenbank existierenden Tabellen abgeglichen werden. D.h. es werden Änderungen in den Schemata in Richtung Datenbank nachvollzogen.

Das geschieht, in dem für jedes im msdt Ordner liegende Schema folgende Operationen vollzogen werden:

• zunächst wird für das Schema ein XMLSchemaProxy Objekt erzeugt, auf welchem dann die Methode getSchemaProperties() aufgerufen wird.
• diese Methode liefert wie oben bereits erläutert einen Vector aller für diesen Eventtyp nötigen Tabellen (Vector tablesToCreate)
• dieser Vector tablesToCreate wird dann der Methode sychronizeSchemaToDB(Vector tablesToCreate) übergeben.
• in dieser Methode wird für jede Tabelle des tablesToCreate Vektors überprüft, ob schon eine entsprechende Tabelle in der Datenbank existiert oder nicht.
  • existiert die Tabelle noch nicht, so wird sie erstellt
  • existiert die Tabelle bereits in der Datenbank, so wird die Tabelle mit der Datenbank abgeglichen.
    • enthält die aus der getSchemaProperties() erzeugte Tabelle eine Spalte welche in der entsprechenden Datenbanktabelle noch nicht vorhanden ist, so wird diese Spalte in der Datenbanktabelle hinzugefügt.

Eine Grafik welche die oben berschriebenen Vorgänge skizziert befindet sich im Anhang.

Die Verknüfpung aller zu einem Event gehörenden Tabellen geschieht über eine Spalte linkID. Diese linkID Spalte ist der Primärschlüssel der commondata Tabelle und ein Fremdschlüssel in allen anderen generierten Tabellen. Beim Einfügen in commondata wird dieser Primärschlüssel von der Datenbank generiert, als Variable zurückgegeben und wird dann bei den Einfügeoperationen in allen anderen zu diesem Event gehörenden Tabellen als Wert für die Fremdschlüsselspalte übergeben.

Ausstehende Problemstellungen:

• Benennung der Tabellen muss überlegt werden, das soetwas wie ein 'Namensraum' für die Tabellen eines Schemas existieren muss, da es sonst zu Problemen kommt wenn zwei Schema ein 'complex Type' Element mit identischen Namen enthalten
• Wie werden 'complex Type' Elemente behandelt, welche wiederum nur ein 'Complex Type' Element enthalten (siehe msdt.focustrackersystem.xsd)

Comments