Document

Studienarbeit
Erstellen einer graphischen Benutzerschnittstelle
zur visuellen
XML-Schema Erzeugung
und XQuery Anfragenstellung.
von Martin Nawrat
Datum: 31.07.2003
Inhaltsverzeichnis
1.
Inhalt und Aufgabenstellung
4
2.
XML
5
2.1. Grundbausteine
5
2.2. XML- Schema
7
2.3. XQuery
8
3
2.3.1 Pfadausdrücke
8
2.3.2 FLWR-Ausdrücke
8
Java JAZZ
10
3.1 Einleitung
10
3.2 Jazz – Funktionalität
11
3.3 Jazz – Architektur und Primärkonzepte
12
3.3.1 Knoten und Sichtkomponente
13
3.3.2 Kamera
14
3.3.3 Fälle (Events)
14
3.3.4 Benutzerdefinierte Sichtkomponenten und Swing Visual
14
Components
15
3.4 Jazz – Zusammenfassung
3.5 Jazz
als
grundlegende
Plattform
für
Datenbankschema
Visualisierung
16
3.5.1 Plattform
16
3.5.2 Aufbau der Tabellendarstellung der Schemata
16
2
4
Applikation – GUI
18
4.1 Einlesen benutzerspezifischen Daten
18
4.2 XML-Schemadefinition
18
4.3 Datenbankviews
19
4.4 XQueries und XML-Data
20
4.5 Export XML-Data
20
5
Ausblick
21
6
Benutzerhandbuch
22
6.1 Anforderungen
22
6.2 Start des Programms
22
6.3 Ablauf
26
3
Kapitel 1
Inhalt und Aufgabenstellung
Diese Arbeit befasst sich mit der Visualisierung der Datenbankschemata von Oracle
Datenbanken, basierend auf einem vollintegrierten Programm zur vollautomatischen
Erstellung von XML-Sichten auf objektrationale Datenbanken. Außerdem soll es um
die Erzeugung von virtuellen XML-Dokumenten gehen, an die XQueries gestellt
werden können. Das dabei zugrundeliegende Programm ist im Rahmen einer
Diplomarbeit [1] am FG Datenbanksysteme entwickelt worden.
Kern dieser Arbeit ist der Entwurf eines einfachen und benutzerfreundlichen FrontEnds, mit dem das Definieren von XML-Schemata, Grundlage der zu erzeugenden
XML-Daten, möglichst übersichtlich ist. Dafür wurde eine spezielle Plattform
ausgewählt, die möglichst viele benutzerfreundliche Interaktionen unterstützt, wie
zum Beispiel Skalierung, Fokussierung und Drehung.
Des Weiteren soll die vollständige Funktionalität des zugrundeliegenden Programms
übernommen und integriert werden. Dabei handelt es sich um folgende
Funktionalitäten: Erzeugung des XML-Dokuments, Ausführung der Anfragen in
form einer XQuery und XML-Datenausgabe.
4
Kapitel 2
XML
XML (eXtensible Markup Language) ist ein ideales Format zum Datenaustausch
zwischen verschiedenen Programmen und verschiedenen Plattformen. XML ist ein
selbsterklärendes Dateiformat mit eigener Struktur.
2.1
Grundbausteine
Der Grundbaustein eines XML-Dokumenttyps ist ein Element:
<Name>
Inhalt
</Name>
Das Element besteht aus einem Start-Tag, dem Inhalt des Elements und einem EndTag. Auch dies ist ein Element:
<Name> Zweiter Inhalt
</Name>
Es handelt sich um zwei Elemente mit auffallenden Ähnlichkeiten. Die jeweiligen
Start-Tags und End-Tags sind gleich, weshalb man beide Elemente demselben
Elementtyp zuordnet.
Die Tags lassen sich verschachteln, so dass komplexere Strukturen entstehen:
5
<BUCH>
<TITEL> Die Blechtrommel </TITEL>
<AUTOR> Günter Grass </AUTOR>
</BUCH>
In jedem Element können Attribute definiert werden. Attribute werden stets in das
Start-Tag der Elementdefinition eingefügt. Sie können nicht doppelt in einem
Element auftreten.
<Buch Kap1 = ’KapName1’ .. KapN = ’KapNameN’ > …
Der Inhalt eines XML-Dokuments kann in Baumstruktur dargestellt werden. Jedem
einzelnen Element wird ein Elementknoten zugewiesen. Jedes Kind eines solchen
Knotens kann je nach Inhalt weitere Elementknoten, Textknoten oder Attributknoten
besitzen. Letztendlich enthalten die Blätter des Baumes Informationen, wie Werte
der Attribute oder den Textinhalt der Elemente.
XML-Beispieldokument:
<Buch ISBN=“051015“>
<Titel> Die Blechtrommel </Titel>
<Autor> Günter Grass </Autor>
<Verlag>
<Name> Springer Verlag </Name>
<Ort> Springe </Ort>
</Verlag>
</Buch>
Baumdarstellung zum obigen Beispieldokument:
6
Das obige Beispiel stellt einen Baum dar, dessen Knoten durch Kreise und dessen
Blätter durch Rechtecke dargestellt sind. Die Namen der Elemente ergeben sich aus
der Elementdefinition des XML-Dokuments. Das einzige Attribut erhielt den Namen
der sich aus dem Präfix @ und dem Attributnamen zusammensetzt. Jedes Element,
das keinen strukturierten Inhalt besitzt, wird als Elementknoten dargestellt und
dessen Inhalt als Blatt. Der Wurzelknoten, der als Element interpretiert werden kann,
repräsentiert die Dokumentwurzel, deren Inhalt das XML-Dokument ist.
Mit XML lässt sich eine breite Palette von Dokumenttypen modellieren. Das
wichtigste dabei ist, dass XML keine expliziten Schemata zur Beschreibung der
enthaltenen Daten benötigt, weil sie im Dokument enthalten sind. Dabei ist der
strukturelle Aufbau der XML-Dokumente dem Benutzer überlassen.
2.2
XML- Schema
XML-Schema ist eine Sprache zur Modellierung strukturierter Informationen. Das
XML-Schema ist selbst ein XML-Dokument. Die Sprache bietet viele verschiedene
Datentypen an. In der Sprache können auch Elementinhalte typisiert,
Wertebereichsbeschränkungen erstellt und Typen verschieden beschrieben werden.
Folgendes Beispiel eines XML-Schemas namens LVBS sei wie in der Grafik
definiert. Auf diesem Schema werden alle folgenden Beispiele aufbauen. Die
genauere Beschreibung des XML-Schemas und dessen Definition ist [1] zu
entnehmen.
7
2.3.
XQuery
In XQuery werden die Anfragen an XML- Schemata mit verschiedenen Arten von
Ausdrücken formuliert. Diese Ausdrücke können beliebig verschachtelt sein und zu
einem einzigen Anfrageausdruck kombiniert werden. Als Ergebnis liefert ein
Ausdruck immer eine Liste, die sowohl einzelne Werte als auch Knoten enthalten
kann. Da XQuery eine große Anzahl von verschiedenen Ausdrücken besitzt, werden
im Folgenden nur die wichtigsten beschrieben. Die gesamte Syntax ist im aktuellen
Working Draft des W3C beschrieben.
2.3.1 Pfadausdrücke
Pfadausdrücke werden zur Adressierung von Elementen in XML-Schemata benutzt.
Diese werden als Baum betrachtet. Mit einem Pfadausdruck kann man sich
ausgehend von der Wurzel, die durch den ersten Tag gebildet wird, an den Kanten
entlang zu jedem beliebigen Knoten im Baum bewegen. Jedes beliebige Element im
XML-Schema ist so erreichbar. Als Ergebnis des Pfadausdrucks wird das gesuchte
Element geliefert.
2.3.2 FLWR-Ausdrücke
Die wichtigsten Ausdrücke in XQuery sind die FLWR-Ausdrücke (“FlowerAusdrücke“). Sie setzten sich aus den Teilen ’FOR’ bzw. ’LET’, ’WHERE’ und
’RETURN’ zusammen.
’FOR’ – bzw. ’LET’- Klauseln deklarieren Variablen und binden diese an einen oder
mehrere Werte, die z.B. durch Pfadausdrücke erhalten wurden.
Die ’FOR’- Klausel wird benutzt, wenn eine Iteration benötigt wird. Sie liefert dann
eine Folge von Tupeln, deren einzelne Werte jeweils an die entsprechenden
Variablen gebunden sind. Bei Verwendung der ’LET’- Klausel werden zwar auch
eine oder mehrere Variablen gebunden, im Unterschied zur ’FOR’- Klausel
allerdings jede Variable nur einmal. In einem ’FLWR’- Ausdruck können beliebig
viele ’FOR’- und ’LET’- Klauseln enthalten sein. Das Resultat dieser Klauseln ist
immer eine geordnete Folge von Tupeln gebundener Variablen. Mit Hilfe dieser
Variablen werden im nächsten Schritt, der ’WHERE’- Bedingung, die Aussagen, die
durch ’AND’ oder ’OR’ verknüpft werden können, ausgewertet. In einem ’FLWR’Ausdruck ist die ’WHERE’- Bedingung optional. Am Ende der ’FLWR’- Anweisung
steht die ’RETURN’- Klausel. Sie liefert das Ergebnis eines XQuery Ausdrucks und
wird für alle Daten ausgeführt, welche die Bedingungen der ’WHERE’- Klausel
erfüllen. Das Ergebnis kann ein Knoten oder eine Sequenz von Knoten sein.
8
An einem Beispiel soll der Umgang mit ’FLWR’- Ausdrücken verdeutlicht werden.
Die Anfrage bezieht sich auf das Schema „LVBS“:
for $i in /LVBS/Kataloge/ITEM/faecher/ITEM
for $j in /LVBS/lehrpersonen/ITEM
where $i/apartner = $j/OID
return
{
<Fach> {$i/name} </Fach>
<Verantwortlicher>
{$j/name }
</Verantwortlicher>
}
Im obigen Beispiel wird zu jedem Fach die verantwortliche Lehrperson bestimmt.
9
Kapitel 3
Java Jezz
In diesem Kapitel wird das verwendete Werkzeug zur Visualisierung von Datenbank
Schemata vorgestellt. Es wird auf die Funktionalität und die Architektur von Jazz
eingegangen. Anschließend wird die Implementierung der Aufgabe vorgestellt
3.1
Einleitung
Heutzutage enthalten graphische Benutzerschnittstellen (GUIs) eine große Anzahl
von eingebauten Objekten. Diese Fenster sind für den hierarchischen Entwurf von
Standardvorrichtungen wie Buttons, Scrollbars und Textbereiche ausgezeichnet.
Jedoch ist es für den Entwickler problematisch, wenn er versucht benutzerdefinierte
Fenster
zu
entwerfen.
Entwickler
definieren
gewöhnlich
diese
applikationsspezifischen Vorrichtungen, indem sie ein vorhandenes Fenster vererben
und dessen Methoden überschreiben, um neue Funktionalität zu definieren. Jedoch
sind GUIs sehr wichtig geworden und das Niveau der Funktionalität benötigt umso
mehr Aufwand. Ein neues GUI Fenster zu entwickeln und einzuführen ist eine
zeitaufwendige Aufgabe. Über das Schreiben des Codes hinaus, um das Fenster zu
zeichnen, muss der Entwickler den Quellcode zu allen benötigten Fällen, wie
Aktionen, Layout, Tastaturnavigation, empfindliche Hilfe des Kontextes, Popup
Menüs, Zugänglichkeit usw. auch selbst implementieren. Somit ist die Einführung
eines völlig neuen applikationsspezifischen funktionellen Fensters eine
erschreckende Aufgabe.
Ein bedeutendes Problem der benutzten Benutzerschnittstellen ist, dass sie
"monolithischen" Konstruktionsprinzipien folgen. Das heißt, sie verwenden eine
verhältnismäßig kleine Anzahl von Objektklassen, um eine große Menge
Funktionalität zur Verfügung zu stellen. Infolgedessen neigen Objektklassen
kompliziert zu sein und viele Methoden zu haben, und die Funktionalität, die durch
jede Klasse bereitgestellt wird, ist schwer, im neuen Fenster wiederzuverwenden.
10
3.2
Jazz – Funktionalität
Jazz ist ein neues Allzweckwerkzeug für die Entwicklung von ZUI-Anwendungen
zoomfähigen/verkleinerungs- und vergrößerungsfähigen objektorientierten 2D
Graphiken. Jazz ist vollständig in Java geschrieben und ist auf allen Plattformen, die
Java 2 unterstützen, lauffähig.
Jazz verwendet den Java2D Renderer und zielt auf effiziente Animation und
schnellen Bildschirmaufbau.
Viele der Strukturelemente von Jazz sind an gebräuchliche 3D Scene Graph
Systeme, wie Java 3D von Sun oder OpenInventor von SGI angelehnt. Durch die
Verwendung von einem einfachen hierarchischen Scene Graph Modell mit Kameras
ist die Nutzung einer Vielzahl gewöhnlicher als auch forward-looking
Schnittstellenmechanismen möglich. Dies beinhaltet auch hierarchische Gruppen
von Objekten mit affinen Transformationen (Translation, Skalierung, Rotation),
Ebenen, Zoom, internen Kameras (Portalen), Linsen, semantischen Zoom und
Mehrfachdarstellung.
Das Jazz-Design folgt dem Standard 3D Scene Graph Verfahren, Funktionalitäten in
separate nicht-visuell gruppierte Knoten zu trennen. Dieser Ansatz gewährleistet ein
modulares Scene Graph Design. Jazz hat einen Grundsatz der visuellen und
interaktiven Erweiterbarkeit. Es beinhaltet einen kleinen Satz von
Visualisierungsobjekten und eindeutig abgegrenzte Mechanismen für Anwendungen,
um eigene visuelle Objekte zu definieren. Dieses Konzept wird ähnlich auch bei
Interaktionsmechanismen wie Default Selection oder Navigation übernommen.
Diese Mechanismen können übernommen werden oder von Anwendungen
modifiziert werden.
11
3.3
Jazz – Architektur und Primärkonzepte
Jazz basiert auf drei primären Konzepten: Knoten, visuellen Komponenten und
Kameras. Die Objekthierarchie der öffentlichen Objekte die Anwendungen
verwenden können.
ZUIs stellen einzigartige Möglichkeiten zur Verfügung, weit über denen hinaus, die
durch die zwei dimensionalen GUIs unterstützt werden. Einige von denen sind:
1. Kundenspezifische Applikation von Graphiken, die nicht-rechteckig oder
transparent sein können, sowie traditionelle wechselwirkende Komponenten wie
Tasten u.ä..
2. Grosse Mengen von Objekten können gleichzeitig variiert, verschoben oder
gedreht werden, dank effektiver Unterstützung.
3. Hierarchische Gruppierung aller willkürlichen Objekte ist immer vorhanden.
4. Ansichtnavigation wird ununterbrochen aktualisiert.
5. Mehrfache Darstellungen der Objekte, damit sie in den unterschiedlichen
Kontexten an unterschiedlichen Skalen zugreifbar sind.
6. Mehrfache Ansichten auf die Oberfläche sind möglich, alle sind als
unterschiedliche Fenster innerhalb der "Portals" oder "Objektive" zu verwenden.
7. Objekte sind örtlich festgelegt, bei der Änderung der Ansicht (Vergrößerung oder
Verkleinerung).
8. Eigenschaften und Interaktionen der benutzerdefinierten Objektgruppen sind
jederzeit änderbar oder ausführbar.
Die Jazzplattform unterstützt alle diese Anforderungen.
12
Jazz basiert auf drei Primärkonzepten: Knoten, Sichtkomponente und Kameras.
3.3.1 Knoten und Sichtkomponente
Der Scene Graph von Jazz besteht aus einer Hierarchie von Knoten (nodes), welche
die Beziehung zwischen Objekten repräsentieren. Der Basisknotentyp ZNode ist ein
einfacher Knoten. Eine Knotenhierarchie kann verwendet werden um „Gruppen“ und
„Ebenen“, die in den meisten Graphik- und Zeichenprogrammen gefunden werden
können, zu implementieren und es zu ermöglichen, eine Gruppe solcher Objekte
gleichzeitig zu bewegen.
Knoten eines Scene Graph haben keine visuelle Gestalt auf dem Bildschirm.
Stattdessen gibt es spezielle Objekte (visueller Blattknoten und visueller
Gruppenknoten), visuelle Komponenten genannt, die bestimmten Knoten eines
Scene Graph angefügt sind, welche die Geometrie- und Farbattribute bestimmen.
Mit anderen Worten bestimmen Knoten, wo etwas in der Hierarchie eines Scence
Graphs gefunden werden kann und wie etwas aussieht. Alle Knoten haben einen
gemeinsamen Elternknoten und folgen einer strikten Baumhierarchie. Visuelle
Komponenten können wiederverwendet werden – dieselbe visuelle Komponente
kann an verschiedenen Stellen eines Scene Graph erscheinen und somit auch
mehrere Elternknoten haben.
Es gibt eine klare Trennung, was in einem Knoten implementiert ist und was von
einer visuellen Komponente gehandhabt wird. Knoten enthalten alle
Objektcharakteristiken die an einen Kindknoten vererbt werden. Zum Beispiel
werden Knoten verwendet um affine Transformationen (Translation, Skalierung,
Rotation) von Kindknoten, um Unterbäume entsprechend der Vergrößerung
auszuwählen und um die Transparenz für Gruppen von Objekten zu definieren.
Visuelle Komponenten haben keine hierarchische Struktur und spezifizieren noch
nicht einmal eine Transformation. Jede visuelle Komponente spezifiziert einfach,
wie diese darzustellen ist, was ihre Attribute sind und wie diese ausgewählt werden
kann.
Diese Aufteilung zwischen Knoten und visuellen Komponenten trennt der
Programmcode, der die Hierarchie des Graphen beinhaltet und Code der unabhängig
von dieser arbeitet. Dies ermöglicht eine hierarchische Strukturierung von Scene
Graph Knoten, aber zusätzlich auch die Wiederverwendbarkeit von visuellen
Komponenten. Es trennt also die Struktur vom Inhalt. Visuelle Komponenten sind
austauschbar, was es beispielhaft ermöglicht alle Kreise mit Rechtecken in einem
Segment eines Scene Graph ohne Auswirkung auf die Gruppierung oder die Position
eines Objektes zu ersetzten.
13
3.3.2 Kamera
Eine Kamera ist eine visuelle Komponente die eine Ansicht eines Scene Graph von
Jazz darstellt. Mit einer Kamera wird der Teil eines Scene Graph spezifiziert der
unter Verwendung einer affinen Transformation sichtbar ist. Mehrerer Kameras
können auf einen einzelnen Scene Graph gerichtet sein, wobei jeder eine eigene
Sicht auf den Scene Graph definiert.
3.3.3 Fälle (Events)
Jazz unterstützt Interaktion durch „Ereignishörer“ (event listener). Diese folgen dem
Standard-Java Ereignismodell und können auf jedem Knoten des Jazz Scene Graph
aufsetzen. Es gibt zwei Kategorien von Ereignissen: – Eingabeereignisse (input
events) und Objektereignisse (object events). Eingabeereignisse resultieren aus der
Anwenderinteraktion mit einem graphischen Objekt, wie einem Mausklick.
Objektereignisse werden durch eine Veränderung des Scene Graph ausgelöst, wie
beispielhaft einer Transformationsänderung oder der Einfügung eines Knoten. Alle
Ereignisse können durch das Hinzufügen eines Listeners an einen Scene Graph
Knoten verarbeitet werden. An einen Knoten können mehrer Listener angefügt
werden. Im Gegensatz zu den Eventlistener-Modellen von Swing oder AWT wird in
Jazz jedes Eingabeereignis an den in der Baumhierarchie des Graphen oberhalb
befindlichen Listeners-Knoten oder Elternknoten weitergegeben. Wird allerdings
von einem Listener das Ereignis erfasst, wird das Ereignis nicht mehr weitergegeben.
Mit diesem Mechanismus können für bestimmte Knoten maßgeschneiderte Listeners
programmiert werden, die mit einem graphischen Element korrespondieren. Es ist
allerdings auch möglich einen Listener in einer höheren Hierarchiestufe des Scene
Graph hinzuzufügen, der dann für das gesamte darrunterliegende Segment die
Interaktion unterstützt. Ereignishörer können in einer spezifischen oder generellen
Weise programmiert werden, abhängig von den jeweiligen Bedürfnissen
In Jazz sind bereits Ereignisbehandlungsroutinen für einige Basisfunktionen, wie
Navigation, Selektion und Hypertext-Links enthalten. Anwendung können auf diese
zurückgreifen oder eigene definieren
3.3.4 Benutzerdefinierte Sichtkomponenten
Visual Components
und
Swing
Jede Leichtgewichtskomponente von Java Swing kann in Jazz Szene Diagramme
eingefügt werden indem eine Jazz ZSwing visuelle Komponente eingefügt wird. Die
Swing Komponente kann dann wie andere Komponenten von Jazz, verkleinert oder
vergrößert werden. Als Beispiel kann eine Swing Schnittstelle mit Tabellen und
Knöpfen
in
eine
„Zoomoberfläche“
eingefügt
werden
und
mit
anwendungsspezifischer Visualisierung überlagert werden. Die Swing Komponenten
14
können auf die selbe Weise wie andere Jazz Komponenten manipuliert werden. Dies
beinhaltet die Rotation, Skalierung, Transparenz und Mehrfachsichten. Die
eingebettete Integration von Swing erfolgt transparent zu den graphischen
Interaktionsobjekten von Swing und zu anderen Knoten des Szenediagramms.
3.4
Jazz – Zusammenfassung
Diese Kapitel beschreibt die Architektur von Jazz, einem neuen Java Werkzeugsatz,
der die Entwicklung von erweiterbaren, objektorientierten 2D Graphiken mit
verkleinerungs- und vergrößerungsfähigen Darstellungen und Mehrfachdarstellung
unterstützt.
Während Jazz keine substantiell neuen Ideen einführt, besteht die Neuerung in der
Kombination von verschiedenen, bereits existierenden Techniken aus verschiedenen
Domänen. Jazz verwendet die von 3D Graphiken bekannten Szenediagramme,
Darstellung- und Interaktionstechniken von zweidimensionalen graphischen
Interaktionsobjekten,
Funktionalitäten
von
vergrößerungsund
verkleinerungsfähigen Anwenderschnittstellen und kombiniert diese mit einem
klaren entkoppelten objekt-orientierten Design. Der Einsatz von Jazz ermöglicht die
Programmierung von „zoomfähigen“ Anwendungen und fortgeschrittener
Visualisierung mit einer Klarheit und Effizienz.
Der größte Beitrag von Jazz ist die Schaffung eines graphischen Werkzeugkastens
der einem “minilithischen” Design folgt. Dies vereinfacht die Instandhaltung und
Erweiterung von Programmcode im Gegensatz zu monolithischen Ansätzen.
Der Nachteil des „minilithischen“ Ansatzes ist, dass Anwendungsentwickler eine
weitaus größere Anzahl an Objekten als unter Verwendung von traditionelleren
Design verwalten müssen. Zwar muss nur für die verwendeten Funktionen Energie
aufgewendet werden, allerdings wird für jede Funktion eine neue Knoteninstanz
benötigt.
Ein weiteres Problemfeld ist die Effizienz von Szenediagramm basierten Lösungen
im Vergleich mit rein kundenspezifischen. Die Alternative zu Jazz für bestimmte
Visualisierung wäre, eine eigene Datenstruktur, die das Modell repräsentiert, zu
erstellen und dann eine Darstellungsmethode zu erzeugen, die einfach durch das
Model läuft und die gesamte Szene darstellt. Dieser Ansatz ist einfach und sehr
effizient.
15
3.5
Jazz als grundlegende Plattform für Datenbankschema Visualisierung
Dieses Kapitel beschäftigt sich mit der eigentlichen Realisierung, Lösung des
gestellten Problems, und mit der Implementierung der Schnittstelle zur
Visualisierung der benutzerdefinierten XML-Schemata.
3.5.1 Plattform
Das Fenster zum Definieren eines XML-Schemas ist ein JFrame von Java Swing. In
dessen Struktur wurde Jazz ZCanavas, als ContentPane eingebettet. Dem Content
Pane wurden Auswahl-Händler und diverse Listeners hinzugefügt, damit das
darzustellende XML-Schema und alle seine Elemente verschoben, gelöscht oder
fokussiert werden kann.
3.5.2 Aufbau der Tabellendarstellung der Schemata
In dem Abschnitt wird nur eine beschränkte und nicht zu tiefgehende Sicht auf den
Aufbau der zu visualisierenden Objekte vorgestellt, weil man ansonsten auf zu viele
schon im Kapitel 3.2 besprochenen jazzspezifischen - Merkmale wiederholt
eingehen müsste.
Jede Einzelne Tabelle wird als ZGroup definiert und durch ZVisualGroup
Sichtkomponente abgebildet. Sie setzt sich zusammen aus dem Tabellentitel
(ZLabel), Closebutton (ZSwing), Spalten (ZSwing) und ein- oder ausgehenden
Referenzen (ZPolyline).
Der Titel wird als ZLabel Objekt definiert und als ZVisualLeaf in der
Gruppenkomponente platziert. Er beinhaltet den Tabellennamen der darstellenden
Tabelle.
Der Löschknopf und die Tabellenattribute sind ZSwing Objekte. Der Löschknopf ist
ein integrierter JButton, dessen Aufgabe ist die gesamte ZGroup, der er angehört, zu
entfernen. Das Löschen erfolgt auf eine sehr einfache Weise, weil der hierarchische
Aufbau von Jazz einen schnellen und direkten Durchgang zum Elternknoten, (hier
der ZGroup) ermöglicht.
Die Tabellenattribute werden wiederum durch eine in ZSwing Objekt integriertes
mehrfachauswählbares JList dargestellt. Die Auswahl der Tabellenattribute dient zur
Objekttyperstellung der Tabellen. Diese sind für das zugrundeliegende Programm
notwendig, um Anfragen an erstellte XML-Schemata ausführen zu können.
Genaueres über die Objekttypen ist dem Schreiben [1] zu entnehmen.
Die Referenzen sind durch ein ZPolyLine Objekt dargestellt, der als ZVisualLeaf
angezeigt wird. Diese Objekte werden nur dann erzeugt, wenn das benutzerdefinierte
16
XML-Schema mindestens zwei Tabellen enthält, deren Attribute aufeinander
zeigende Referenzen vorweisen. Die Referenzen werden direkt aus der Oracle
Datenbank gelesen. Ansonsten werden sie nicht angezeigt.
Der Titel, der Löschknopf, die Tabellenattributliste und die Referenzen werden alle
einer Gruppen-Sichtkomponente hinzugefügt und stellen eine Datenbanktabelle dar.
Durch die Jazz-Eigenschaften ist Skalierung und Fokussierung ohne Implementationsaufwand bereitgestellt.
17
Kapitel 4
Applikation GUI
Die Applikation stellt eine Schnittstelle zwischen dem Benutzer und der Datenbank
dar, die ihm leichten Zugriff auf die Daten ermöglicht. Außerdem soll der Benutzer
jeder Zeit neue XML-Schemata, Datenbankviews erzeugen und Anfragen in Form
einer XQuery stellen können. Des weiteren muss die Schemadefinition jeder Zeit
visuell dargestellt sein können.
Aufgrund der im Benutzerhandbuch beschriebenen Anforderungen beinhaltet dieser
Kapitel nur die Beschreibung der Implementationsmerkmale.
4.1
Einlesen benutzerspezifischen Daten
Direkt nach dem Start des Programms wird Verbindung zur Datenbank aufgebaut,
die stets erhalten bleibt. Als nächstes erfolgt das Einlesen den Benutzer zur
Verfügung stehenden Objekttabellen, deren Typen und deren Referenzen. Es wird
ein rein leserlicher Zugriff auf die Datenbank benötigt, daher muss die Applikation
keine wiederholt aktualisierbare Pufferung der Daten zur Verfügung stellen.
Neben der datenbankspezifischen Daten werden die vorhandenen Schemaspezifikationen eingelesen. Jede XML-Schemaspezifikation ist, als eine Datei vorhanden.
Diese Form der Speicherung von Schemaspezifikationen ist auf das Programm von
Christian Schlueter zurückzuführen [1].
Im Laufe des Programms bietet die Applikation das Einlesen und Speichern von
XQueries. Diese werden ähnlich wie Schemaspezifikationen, als eine Datei abgelegt.
4.2
XML-Schemadefinition
XML-Schema kann sehr unterschiedlich aufgebaut werden. Ausgehend von einem
einfachen Schema, das nur aus einer Objekttabelle besteht, bis zu einem Schema das
alle Objekttabellen beinhaltet, die dem Benutzer zur Verfügung stehen.
Selbstverständlich müssen die grundliegende Regel beibehalten werden, wie zum
Beispiel das zyklenfreie Definition von XML-Schema. Zyklenfrei heißt, das es keine
18
geschlossene Kreise von Referenzen geben kann. Dieses würde ein hierarchisches
Aufbau von XML-Schema verhindern. Jede einzelne Referenz kann jeweils entfernt
werden, wenn sie nicht benötigt wird.
Jedes XML-Schema wird durch folgende Parameter spezifiziert:
- Name
- Targetnamespace
- Tabellen
- Tabellentypen
- Modifiers
Der Schemaname kann beliebig vergeben werden, sollte aber keine Sonderzeichen
beinhalten. Der Targetnamespace ist in der Applikation standardmäßig gesetzt. Die
Tabellen repräsentieren Objekttabellennamen der Datenbank. Tabellentypen
repräsentieren die Typen der gewählten Objekttabellen. Im Gegenteil zu den
vorherigen müssen Modifiers nicht immer vorhanden sein. Diese repräsentieren die
umgedrehte Referenzen zweier Tabellen, charakterisiert durch den Namen des
Objektstyps und dem entsprechenden Referenzattribut.
Das Beispiel von LVBS-Schema ist darunter zu sehen:
4.3
Datenbankviews
Das XML-Schema ist ein XML-Dokument mit hierarchischer Struktur, auf dessen
Basis XQeries gestellt werden können. Jedoch enthält dieses Dokument keine Daten,
19
die man anfragen kann. Ein View ist eine Repräsentation von XML-Schema auf der
Datenbank. Dieses View wird anschließend durch in SQL übersetzte XQuery
angefragt. Die erstellten Datenbankviews sollten bei jeder Änderung von XML
Schema erneut überschrieben werden. Nachdem ein definiertes Schema gelöscht
worden ist, wird das entsprechende Datenbankview ebenso von der Datenbank
gelöscht.
4.4
XQueries und XML-Data
Die Anfragen sind in der Applikation selbst dem Benutzer überlassen. Es kann
jeweils nur eine Anfrage, an das XML-Schema gestellt werden. Bei einer
fehlerhaften Anfragestellung wird die Fehlermeldung des Parsers aufkommen. In den
XQueries können alle FLWR-Ausdrücke, die schon in Kapitel 2.3 beschrieben,
benutzt werden, so wie miteinander verkoppelt werden. Alle Eigenschaften und
Vorteile der XQueries können in der Applikation genutzt werden. Leider ist es nicht
gelungen eine Unterstützung zur Anfragestellung zu entwickeln.
4.5
Export XML-Daten
Die XML-Ausgabedaten können in eine Text- oder HTML-Datei ausgegeben werden
Dieses ermöglicht weitere Benutzung der Ausgabedaten.
20
Kapitel 5
Ausblick
Die Implementierung einer idealen graphischen Benutzerschnittstelle ist eine sehr
umfangreiche und damit auch fast unmögliche Aufgabe. Durch die nahezu
unbeschränkten Möglichkeiten lassen sich heutzutage fast alle Ideen und Wünsche
verwirklichen. Leider ist es aber nicht möglich, selbst aus Zeitgründen, alle diese
denkbaren Futures zu errichten.
Die entwickelte Benutzerschnittstelle umfasst alle wesentlichen Anforderungen des
zugrundeliegenden Programms [1]. XML-Schemata lassen sich sehr einfach
erstellen, und bieten eine klare Übersicht an. Die XQueries können geladen,
gespeichert und selbst entworfen werden. Es besteht auch die Möglichkeit die
Ausgabedaten zu exportieren.
Mit Hilfe dieser Applikation ist das Anfragen an objektrationale Datenbankschemata
sehr einfach. Den wesentlichen Überblick über das selbstdefinierte XML-Schema hat
der Benutzer jederzeit zur Hand. Die Anfragen können im Format einer XQuery
gestellt werden, was einen großen Vorteil darstellt. Im Vergleich zur SQL-Anfrage
ist eine äquivalente XQuery wesentlich einfacher aufgebaut und strukturiert.
Selbst bei den besten graphischen Benutzerschnittstellen führen fehlerhafte Handlungen zur unerwarteten (Fehl-) Aktionen. Auch in diesem Projekt kann zu solchen
Geschähen kommen, wenn man sich nicht an die Vorgehensweise hält, die im
Kapitel 6.3 beschrieben ist. Die meisten, in der Entwicklungsphase entdeckten
fehlerhaften Vorgehen, werden abgefangen. Es ist aber nicht auszuschließen dass,
noch weitere unvorgesehene Aktionen zur fehlerhaften Ablauf des Programms
führen könnten.
21
Kapitel 6
Benutzerhandbuch
In diesem Kapitel werden die Funktionalitäten des Programms erläutert und
außerdem die Anforderungen und Standardvorgänge erklärt.
6.1
Anforderungen
Zum Lauf des Programms ist eine Java 1.4 Umgebung erforderlich. Außerdem ist ein
Erweiterungspackage von Jazz als Classpath beim Aufruf des Programms
anzugeben. Alternative Lösung ist die Datei im Java Installationsverzeichnis
einzufügen,
.../jre/lib/ext/jazz.jar.
damit sie stets zur Verfügung steht. Ansonsten sind alle Anforderungen des
grundlegenden Programms von Christin Schlueter einzuhalten.
6.2
Start des Programms
Das Programm ist auf folgende Art und Weise aus dem DBVisualScheme
Verzeichnis aufzurufen.
!
java –classpath <vollständiger Pfad zur Datei jazz.jar>
de/unihannover/dbs/dbvs/gui/GUI
Oder man startet das Programm ohne –classpath und dem vollständigen Pfad der
jazz.jar Datei, wenn sie sich im Java Installationsverzeichnis befindet.
Gleich nach dem Start des Programms folgt die Anmeldung an die Oracle
Datenbank, um den ununterbrochenen Zugriff auf die benutzerspezifischen Daten zu
haben. Es handelt sich hier um Tabellen, Referenzen und Typen, die notwendig sind,
um die XML-Schemata anzulegen.
Es gibt drei Anmeldungsversuche. Nach dem dritten gescheiterten Versuch wird das
Programm beendet. Die Datenbankverbindung ist zum fehlerfreien Ablauf des
Programms stets erhalten.
22
Beim ordnungsgemäßen Ausschalten des Programms wird die bestehende
Datenbankverbindung geschlossen.
Nach der erfolgreichen Anmeldung wird ein Fenster angezeigt, in dem die
vorhandenen XML-Schemata in einem Auswahlfeld anzeigt werden. Der
nebenliegende Knopf visualisiert das gewählte Schema mit spezifischen
Schemaeigenschaften. Zusätzlich ist der Anfragebereich und der Ausgabebereich zu
sehen. In der Fußleiste ist der Alias? des an der Oracle Datenbank angemeldeten
Benutzers zu sehen.
XML-Schemata:
Alle auswählbaren XML-Schemata sind in Form einer Textdatei im Verzeichnis
../DBVisualScheme/de/unihannover/dbs/dbvs/gui/Schlueter/
abgelegt. Es wurde diese Form der Speicherung der Schemata ausgewählt aufgrund
der Anforderungen des Programms von Christian Schlueter [1]. Bei jedem Start des
Programms werden alle in oben genannten Ordner abgelegte Dateien deren Endung
„.spec“ sind, eingelesen. Jede solche Datei beinhaltet Namen der XML-Schema, die
verwendete Tabellennamen, deren ausgewählte Attribute und die Objekttypen der
Tabellen. Die Namen der XML-Schematabellen, deren Attribute und die
Objekttypen entsprechen namentlich den in der Oracle Datenbank angelegten
Tabellen, Attributen. und Objekttypen. Bei jeder neuen XML-Schemadefinition wird
eine neue Datei angelegt.
23
Anfragebereich:
Im Anfragebereich sind Anfragen im Format einer XQuery an das gewählte XMLSchema zu Stellen. Anfragen an ausgewählte XML-Schemata können geladen und
gespeichert werden. Diese werden in Form einer Textdatei im demselben Ordner wie
die XML-Schemadefinitionen abgespeichert und stehen dem Benutzer immer zur
Verfügung.
Ausgabebereich:
Im Ausgabebereich werden Ergebnisse einer Anfrage, die an das früher gewählte
XML-Schema gestellt worden ist, geliefert.
24
In dem Fenster können alle wesentlichen Aktionen des Programms ausgeführt
werden. Die Menüs enthalten alle relevanten Aufrufe von Funktionen des
Programms, wie Einloggen auf der Datenbank, XML-Schema erzeugen,
Datenbankview erzeugen, XML-Anfrage ausführen, sowie XML-Anfrage laden,
speichern und XML-Data exportieren.
Einloggen auf der Datenbank ist nach dem Start des Programms wiederholt möglich
indem man im Menü ’Database’ Log In wählt.
Erzeugung XML-Schema – Auswahl dieser Funktion führt zur Erstellung eines
XML-Schemas, dessen durch den Benutzer ausgewählte Name angezeigt wird mit
hierarchischen Struktur, so dass jedes Element zugreifbar ist.
Datenbankview erzeugen - Diese Funktion legt für das vorerst definierte und
erzeugte XML-Schema eine Sicht (View) auf der Oracle Datenbank an. An diese
Sicht wird im nachhinein die SQL-Anfrage gestellt, die die SQL-Repräsentation der
XML-Anfrage darstellt. Der Mechanismus zur Erzeugung solcher SQL-Anfragen ist
der Arbeit [1] zu entnehmen.
XML-Anfrage ausführen – Aufruf dieser Funktion ruft den eigentlichen und
wichtigsten Algorithmus des Programms auf. Die XML-Anfrage wird an das XMLSchema gestellt und ausgewertet. Die einzelnen Phasen und Abläufe sind im
Schreiben [1] genau beschrieben, daher wird darauf auf dieser Stelle nicht mehr
genauer eingegangen.
25
6.3
Ablauf
Nach dem erfolgreichem Start des Programms ist nun der korrekte Ablauf
beizubehalten.
1. Schritt. Neudefinition oder Änderung von XML-Schema
Durch Auswahl des Menus ‚Neues Schema’ wird ein neues Fenster geöffnet, in dem
die Definition des neuen XML-Schemas erfolgt. Zuvor wird der Benutzer nach dem
Namen von dem zu erstellenden XML-Schema durch ein Dialogfenster gefragt. In
der Anzeige wird vorerst nichts angezeigt. Im Menu ’Tabellen’ stehen alle
objektrationalen Tabellen der Datenbank, auf die der angemeldete Benutzer Zugriff
hat, zur Verfügung. Nach dem Auswahl einer der Tabellen aus dem Menu, wird sie
dem geöffneten Anzeigefenster hinzugefügt. Ein XML-Schema muss mindestens aus
einer Tabelle bestehen. Wenn es mindestens zwei oder mehrere Tabellen gibt, die
aufeinander referenzzierende Tabellenattribute besitzen, so werden diese Referenzen
in Form eines Pfeils angezeigt. Ab jetzt ist es dem Benutzer überlassen, welche
Tabellen das neue XML-Schema beinhalten soll, und welche Attribute ausgewählt
werden. Auswahl der Attribute erfolgt durch Markieren der Spalten entsprechender
Tabellen. Es können mehrere Tabellenattribute ausgewählt werden. Dies erreicht
man durch Anklicken mit gleichzeitig gedrückter Steuerungstaste der
Tabellenattribute. Diese Attribute werden in dem erstellten XML-Schema als
Elementknoten enthalten, so dass die Anfrage auf die Attribute erfolgen kann. Jede
Tabelle, die nicht dem XML-Schema angehören sollte, kann einfach entfernt werden.
Dazu dient der Löschknopf, der sich in der rechten oberen Ecke der
Tabellendarstellung befindet. Nach der XML-Schemaspezifizierung ist das
Speichern des neuen XML-Schemas erforderlich. Dies geschieht durch Betätigen des
Menu ’Speichern’.
Ein bestehendes XML-Schema kann auch geändert werden. Um Änderungen an
einem XML-Schema vorzunehmen wählt man das Schema aus und betätigt den
Knopf ’Visualisiere’ im Hauptfenster. Nun werden nur diejenigen Tabellen
angezeigt, die in der Schemadefinition vorkommen. Es können wieder einige
entfernt und es können neue Tabellen hinzugefügt werden. Das Speichern erfolgt wie
beim der Neudefinition. Das Fenster wird nach dem Speichern der XML-Schema
geöffnet bleiben, damit man die genaue Übersicht behält. Das Fenster kann aber
auch geschlossen werden. Der Name des aktuellen XML-Schemas wird immer im
Hauptfenster angezeigt.
2 Schritt: Erstellen oder Ändern einer Datenbanksicht
Um eine Datenbanksicht zu erstellen, muss man im Hauptfenster das Menü
’Datenbankview erzeugen’ auswählen. Die Erstellung der Datenbanksicht bezieht
sich immer auf das ausgewählte XML-Schema. Solange ein XML-Schema nicht
geändert wurde, ist die zugehörige Datenbanksicht für dieses Schema gültig. Nach
jeder Änderung von XML-Schema ist ein Überschreiben der Datenbanksicht
notwendig.
3 Schritt: Anfrageformulierung
Die Anfragen werden im Hauptfenster im gekennzeichnetem Textfeld gestellt. Jede
Anfrage an XML-Schema muss im XQuery Format gestellt werden. Die XQueries
26
können aus einer Datei geladen oder selbst geschrieben werden. Alle Anfragen sind
in Form einer Textdatei im Verzeichnis
../DBVisualScheme/de/unihannover/dbs/dbvs/gui/Schlueter/
zu finden. Selbstgeschriebene XQueries können auch abgespeichert werden. Dazu
benutzt man den Menüeintrag ’XQuery speichern’. Es zeigt sich dann der unten
angezeigte Dialog an.
Nach dem erfolgreichen Speichern befindet sich die Datei im oben genanten
Verzeichnis.
4. Schritt: Anfragestellung und Auswertung der Daten
Um die Anfrage zu starten, wählt man im Menü des Hauptfensters den Eintrag
’Anfrage ausführen’ aus. Diese Aktion stellt die XQuery Anfrage an das gewählte
XML-Schema. Anschließend gibt die Funktion die Ergebnisse der Anfrage zurück.
Diese werden im XML-Format in dem Ausgabebereich angezeigt.
Die Ausgabedaten können in eine HTML- oder Textdatei exportiert werden. Dafür
ist das Menü ’XML-Data speichern’ im Hauptfenster zuständig. Die Ausgabedatei
wird sich in dem Ordner
../DBVisualScheme/
befinden.
27
Literaturverzeichnis:
[1] Schlüter, Christian - XML - Sichten auf objekt-relationale Datenbanken.
Universität Hannover, November 2002, online verfügbar unter:
http://www.dbs.uni-hannover.de/ftp/theses/schlueter/Diplomarbeit.pdf. Letzter
Abruf am 12.07.2003.
[2] Chamberlin, Don; Robie, Jonathan; Florescu, Daniela: Quilt – An XML Query
Language for Heterogeneous Data Sources, 2000, online verfügbar unter:
http://www.almaden.ibm.com/cs/people/chamberlin/quilt_lncs.pdf.
Letzter
Abruf am 12.07.2003.
[3] The World Wide Web Consortium: XML Query (XQuery) Requirements, 2003,
online verfügbar unter: http://www.w3.org/TR/xquery-requirements/. Letzter
Abruf am 12.07.2003.
[4] Human-Computer Interaction Lab. Institute for Advanced Computer Studies,
Computer Science Department: Jazz: An Extensible Zoomable User Interface
Graphics Toolkit in Java, 2000 http://www.cs.umd.edu/hcil/jazz/
[5] Java [Web Page] (2003) : http://www.javasoft.com.
28