Universität Konstanz
FB Informatik und Informationswissenschaft Bachelor-Studiengang Information Engineering
Bachelorarbeit
BaseX Tree View.
Entwicklung einer datenbankgestützten Visualisierung von XML-Dokumenten.
zur Erlangung des akademischen Grades eines Bachelor of Science (B.Sc.)
Studienfach: Information Engineering Schwerpunkt: Informatik der Systeme Themengebiet: XML & Datenbanken
von
Wolfgang Miller
(01/612437)
Erstgutachter: Prof. Dr. Marc H. Scholl Zweitgutachter: Prof. Dr. Marcel Waldvogel Betreuer: Dr. Christian Grün
Einreichung: 05.07.2011
Inhaltsverzeichnis
1 Einleitung 3
2 BaseX 4
2.1 Speicherstruktur . . . 5
2.2 Die grafische Benutzeroberfläche (BaseX GUI) . . . 6
3 BaseX Tree View 10 3.1 Rekonstruktion der Baumstrukur . . . 12
3.1.1 size-Approximation . . . 13
3.1.2 pre/post-Ebene . . . 18
3.1.3 Rekonstruktion des Baumes mittels Level-Knotenmatrix . . . 22
3.2 Konzepte und Umsetzung . . . 27
3.2.1 Zeichnen von Nachfahrenverbindungen . . . 28
3.2.2 Einsatz von Farben/Knoten-Temperatur . . . 33
3.2.3 Interaktives Highlighting der Knotenbeziehungen . . . 35
3.2.4 Big Rectangles . . . 38
4 Performanz 43 4.1 Einlesen der Level-Knotenmatrix . . . 44
4.1.1 Ansatz 1 - Breite zuerst . . . 46
4.1.2 Ansatz 2 - Tiefe zuerst . . . 48
4.1.3 Performanzvergleich beider Ansätze . . . 50
4.2 Effiziente Berechnung von Teilbäumen/Caching . . . 52
5 Verwandte Arbeiten 56 5.1 Cone Tree . . . 56
5.2 Hyperbolic Tree . . . 57
5.3 Space Tree . . . 58
6 Fazit 60
1 Einleitung
XML hat sich seit der Einführung im Jahr 1998 zu einem festen Standard zum Austausch von Daten etabliert (vgl.[W3C08]). Vor allem im Bereich des World Wide Web erfreut sich XML großer Beliebtheit. Da dadurch immer größere Datenmengen in XML abgelegt werden, gibt es auch eine steigende Nachfrage diese Dokumente und die darin gespei- cherten Daten zu untersuchen.
Diese Arbeit dokumentiert die Entwicklung einer traditionellen Baumvisualisierung, wel- che als Projekt zur XML-Datenbank BaseX und deren graphischem Frontend, der BaseX GUI entstand. Zielsetzung dabei war es dem Anwender eine alternative Sicht zur Unter- suchung eingelesene XML-Dokumente zur Verfügung zu stellen.
In unserem Alltag sind wir den Umgang mit unterschiedlichen Hierarchien gewohnt, etwa bei militärischen Rängen, in der Arbeitswelt oder bei verwandtschaftlichen Bezie- hungen. Graphische Abbildungen dieser Beziehungen, wie beispielsweise Ahnentafeln, entsprechen dabei der klassischen Baumdarstellung. Dadurch haben diese Visualisierun- gen den Vorteil, dass sie für jedermann gut verständlich sind und bei Anwendern eine hohe Akzeptanz besitzen. Nachteil dieser Visualisierungsart ist wiederum der enorme Platzbedarf, der zur Abtragung solcher Bäume benötigt wird.
Im Folgenden soll die Entwicklung einer klassischen Baumvisualisierung beispielhaft an- hand der Entwicklung der BaseX Tree View besprochen werden.
2 BaseX
BaseX ist ein XML-Datenbanksystem, welches von der Arbeitsgruppe „Datenbanken &
Informationssysteme“ des Fachbereichs Informatik an der Universität Konstanz entwi- ckelt wird. Neben einem XPath/Query Prozessor verfügt BaseX zudem über eine grafi- sche Benutzeroberfläche, welche mit verschiedenen Visualisierungen, unter anderem der in dieser Arbeit besprochenen Tree View, das Bearbeiten und Untersuchen von XML Do- kumenten ermöglicht.
Abbildung 1:Grafische Benutzerberfläche von BaseX
Implementiert wird BaseX in der Programmiersprache Java, ist somit relativ plattformu- nabhängig und auf Java-fähigen Systemen einsetzbar.
2.1 Speicherstruktur
BaseX verwendet ein PRE/SIZE/DIST-Mapping als interne Datenstruktur, um damit ein- gelesene XML-Dokumente auf eine Tabelle abzubilden (vgl.[Grü10]).
DerPRE-Wert dient als eindeutiger Identifikator eines Knotens im Dokument. Dieser Wert ergibt sich implizit aus der Stelle des Knotens in der internen BaseX-Tabelle, nachdem ein XML-Dokument sequentiell eingelesen wurde.
DerDIST-Wert dient zur Berechnung desPAR-Werts eines Knotens. Dieser Wert ergibt sich aus der Differenz desPRE-Werts eines Knotens zu dessen Vaterknoten. Die Speicherung desDIST-Werts stellte sich als vorteilhafter für die Verarbeitung von Updates heraus, als denPAR-Wert eines Knotens direkt zu speichern.
DerSIZE-Wert eines Knotens ergibt sich aus der Anzahl dessen Nachfahren und dem Kno- ten selbst. Dieser Wert stellt somit die Größe des Teilbaums dar den ein Knoten aufspannt.
PRE DIS SIZ ATS NS KIND CONTENT ---
0 1 7 1 0 DOC abcdef.xml
1 1 6 1 0 ELEM A
2 1 3 1 0 ELEM B
3 1 1 1 0 ELEM C
4 2 1 1 0 ELEM D
5 4 2 1 0 ELEM E
6 1 1 1 0 ELEM F
Abbildung 2:BaseX Tabelle
Abbildung 30 zeigt am Beispiel des abcdef.xml-Dokuments (siehe Anhang), die interne Tabellenrepräsentation von in BaseX eingelesenen XML-Dokumenten.
2.2 Die grasche Benutzeroberäche (BaseX GUI)
BaseX besitzt neben der reinen Datenbankanwendung auf Konsolenebene auch eine gra- fische Benutzeroberfläche mit deren Hilfe sich XML-Dokumente bearbeiten und unter- suchen lassen. Zusätzlich zu einem Editor, der die Eingabe von XQuery/XPath-Anfragen unterstützt, stehen in der aktuellen Version 6.6.2 (vgl. [Bas11]) sieben unterschiedli- che Visualisierungen zur Verfügung. Die in dieser Arbeit besprochene Tree View ist eine Visualisierung dieses Portfolios. Auf Abbildung 1 werden alle in BaseX vorhanden Visua- lisierungen gemeinsam bei der Untersuchung eines Dokuments gezeigt. Von links oben nach rechts unten sind darauf die folgenden Visualisierungen zu sehen: Die Verzeich- nisansicht, die in dieser Arbeit vorgestellte Tree View, die Streudiagramm Visualisierung (Scatterplott), die Textausgabe mit der aktuellen Treffermenge, die Tree Map, die Tabel- lenansicht und die Browser-Ansicht. Das Besondere hierbei ist, dass alle in BaseX vorhan- denen Visualisierungen miteinander verknüpft und synchronisiert sind, das heißt, wird in einer Visualisierung etwa ein Knoten markiert oder ein neuer Kontext gewählt, so wird dieses Ereignis ebenso in allen anderen Visualisierungen dargestellt. Hierdurch lässt sich ein geöffnetes XML-Dokument in mehreren unterschiedlichen Darstellungen gleichzeitig untersuchen.
Abbildung 3:Benachrichtigungssystem Basex GUI
Dieses Benachrichtigungssystem funktioniert über ein Observer Pattern, wobei der View Notifier als Vermittler zwischen den Views agiert. Abbildung 3 zeigt die Übermittlung
der GUI- Ereignisse an die einzelnen Views. Der Ablauf kann dabei in drei Schritte ein- geteilt werden: Die Benutzerinteraktion innerhalb einer View, das Informieren des View Vermittlers (View Notifier), welcher die Ereignisse an die anderen Views weiterleitet und die anschließende Verarbeitung der übermittelten Informationen in den einzelnen Views.
Interagiert ein Nutzer mit der BaseX GUI und öffnet dabei beispielsweise ein XML-Dokument, oder markiert(in einer der geöffneten Views) einen Knoten, so muss dieses Ereignis an die anderen Views weitergeleitet werden, um alle Visualisierungen auf dem gleichen Stand zu halten. Hierzu benachrichtigt die entsprechende View, in der die Interaktion stattgefunden hat, den View Notifier. Dies geschieht über den Aufruf verschiedener Me- thoden des View Notifiers, welche der jeweiligen Benutzerinteraktion entsprechen. Der View Notifier leitet diese Informationen im Anschluss an die anderen Views weiter, damit diese auf das eingetretene Ereignis reagieren können. Die benachrichtigten Views pas- sen daraufhin ihre Darstellung an, so dass alle geöffneten Views auf dem gleichen Stand sind.
Durch dieses Prinzip lassen sich XML-Dokumente in der BaseX GUI parallel mit unter- schiedlichen Visualisierungen untersuchen, wodurch im Zusammenspiel noch detaillier- tere Erkenntnisse über deren Aufbau gewonnen werden kann. Für die Tree View hat sich die in BaseX vorhandene Tree Map Visualisierung als besonders gut ergänzend herausge- stellt. Die Tree Map nutzt den vorhandenen Platz auf dem Zeichenbereich sehr effizient, um die einzelnen Knoten des Baumes abzubilden. Hierdurch lassen sich selbst bei einer hohen Knotenanzahl einzelne Knoten ausmachen und fokussieren. Der Nachteil dabei ist, dass bei einer hohen Knotenanzahl und zusätzlich mehreren vorhandenen Levels, sich die tieferen Levels visuell nicht voneinander unterscheiden lassen und ineinander verschwimmen. Dadurch ist für fokussierte Knoten, die auf tieferen Ebenen des Baumes liegen, in der Tree Map nicht erkennbar, welchem Level diese angehören. Hier kann die Tree View weitere Auskunft geben. Diese hat den Vorteil, dass immer das komplette Do- kument mit allen Levels abgebildet wird. Dadurch lässt sich zu jeder Zeit feststellen, auf welchem Level sich ein gerade fokussierter Knoten befindet und durch das Echtzeithigh- lighting der Knotenbeziehungen1 lassen zudem Aussagen über dessen Verwandtschafts- verhältnisse treffen. Nachteil der Tree View wiederum ist, dass diese den Platz auf dem Zeichenbereich weit weniger effektiv nutzt und Levels mit einer großen Knotenanzahl in sogenannten Big Rectangels2 zusammengefasst werden, die nur ein grobes Bild der
1das Echtzeithighlighting der Knotenbeziehungen wird in Kapitel 3.2.3 genauer besprochen
2Big Rectangles werden in Kapitel 3.2.4 thematisiert
darunterliegenden Knoten liefern. Die Schwächen der beiden Visualisierungen können somit im Zusammenspiel aufgeweicht werden und bieten damit ein noch besseres Bild des dargestellten XML-Dokuments.
Abbildung 4:Zusammenspiel Tree View/Tree Map
Abbildung 4 zeigt ein Anwendungsbeispiel wie die Tree Map und die Tree View gemein- sam verwendet werden können. Das geöffnete 111MB.xml-Dokument enthält 14 Level, 3.221.926 Knoten und ist 111MB groß. Links ist die Tree Map Repräsentation der Daten zu sehen und rechts die der Tree View.
Zunächst wurde die XPath-Anfrage//namean die Datenbank gestellt. Die rote Markie- rung zeigt die Knoten, welche in der Treffermenge liegen. Die Tree Map bietet hier eine weitaus genauere Darstellung der einzelnen markierten Knoten. In der Tree View sind diese Knoten zu einem Big Rectangle zusammengefasst und lassen sich nicht einzeln fo- kussieren. Dafür ist jedoch der Bereich im Baum ersichtlich auf dem sich diese Knoten befinden. Es lässt sich leicht ablesen, dass sich die Knoten der Treffermenge ausschließ- lich auf Levels 5 und 6 befinden. Im nächsten Schritt wurde ein Knoten in der Tree Map
mit der Maus fokussiert. Der Level dieses Knotens ist dabei nicht erkennbar. Bei Betrach- tung der Tree Map zeigt sich, dass es sich bei diesem Knoten um ein Blatt handelt, da sich der Knoten auf dem 14. Level des Baumes, also der tiefsten Ebene befindet.
3 BaseX Tree View
Die Tree View wurde mit dem Ziel entwickelt XML-Dokumente in einer traditionellen Baumdarstellung, wie sie beispielsweise in [Shn91]beschrieben wird, abzubilden. Das heißt die Bäume werden als gewurzelte, gerichtete Graphen dargestellt. Die Wurzel steht oben und die Kindknoten sind unterhalb ihrer Elternknoten positioniert, wobei Linien diese Paare verbinden. Dieses Kapitel soll anhand der Tree View mögliche Wege und An- sätze aufgezeigen, wie sich XML-Dokumente als traditioneller Baum visualisieren lassen, wobei als Umgebung die XML-Datenbank BaseX dient.
Abbildung 5:Evolution der Tree View
Auf Abbildung 5 sind die einzelnen Entwicklungsschritte der Tree View zu sehen, wie sie auch in diesem Kapitel behandelt werden. Chronologisch von links oben nach rechts unten werden die einzelnen Entwicklungsetappen der Tree View am Beispiel der Darstel- lung des input.xml-Dokuments gezeigt.
Zu Beginn der Entwicklung musste ein Verfahren gefunden werden, um aus den in der Datenbank abgelegten Daten den Baum des betrachteten XML-Dokuments zu rekonstru- ieren. Drei unterschiedliche Verfahrensweisen wurden hierfür evaluiert und werden im folgenden Unterkapitel „Rekonstruktion der Baumstruktur“ besprochen. Die Bilder 1 - 3 zeigen Abbildungen der Bäume, die durch Verwendung der unterschiedlichen Rekon- struktionsverfahren entstehen. Auf Bild 1 ist der Baum des size-Approximationsverfahrens zu sehen. Bild 2 zeigt den Baum der pre/post-Ebene und Bild 3 die Rekonstruktion des Baumes mittels der Level-Knotenmatrix. Letzteres Verfahren wurde nach einer Evaluati- on der verschiedenen Ansätze als Basis für die Tree View gewählt. Bild 4 und 5 zeigen die weitere Entwicklung auf Grundlage dieses Verfahrens, die im Unterkapitel „Konzepte und Umsetzungen“ besprochen wird. Auf Bild 4 ist der Baum mit Nachfahrenverbindun- gen abgebildet. Bild 5 zeigt die Tree View, wie sie in der aktuellen Version von BaseX integriert ist. Beispielhaft für die vorhandenen Interaktionsmöglichkeiten wurde auf die- sem Screenshot ein Knoten mit der Maus fokussiert, während dazu die Vor- als auch die Nachfahren des Knotens hervorgehoben angezeigt werden.
3.1 Rekonstruktion der Baumstrukur
Eine grundlegende Fragestellung, die sich bei der Entwicklung einer Baumvisualisierung ergibt, ist die Wahl der Methode, mithilfe derer die Baumstruktur eingelesener Dokumen- te rekonstruiert werden kann. Dabei ist es wichtig, dass für jegliche Art der Baumentwick- lung eine erkennbare Struktur entsteht, die die Beziehungen der Knoten untereinander verdeutlicht und so den Baum erkennen lässt. Im Laufe der Entwicklung wurden unter- schiedliche Ansätze zur Lösung dieser Aufgabenstellung evaluiert. Eine besondere Her- ausforderung war es, eine Methode zu finden, mit der sich eine gute Platzverteilung für die Knoten auf dem Zeichenbereich ermitteln lässt, da sich aus den in der Datenbank ab- gelegten Daten nicht direkt Rückschlüsse auf die Ausbreitung des Baumes ziehen lassen.
Vor allem die Pixelbreite des Zeichenbereichs auf dem der Baum abgetragen werden soll ist dabei ein limitierender Faktor, da in den allermeisten XML-Dokumenten viele Knoten auf wenige Levels verteilt sind.
Drei unterschiedliche Ansätze wurden im Verlaufe der Entwicklung evaluiert und getes- tet. Im Folgenden werden diese unterschiedlichen Ansätze besprochen sowie deren Vor- und Nachteile aufgezeigt. Zunächst wird auf die Approximation mittelsSIZE-Werten ein- gegangen, danach auf die pre/post-Ebene und als Letztes auf die Rekonstruktion mittels Level-Knotenmatrix.
Bei dem Verfahren der size-Approximation, sowie dem pre/post-Ebene Ansatz, handelt es um frühe Prototypenversionen der Tree View. Dies sollte bei den Beispielabbildungen dieser Verfahren beachtet werden.
3.1.1 size-Approximation
Ein Ansatz, Rückschlüsse auf die Baumstruktur eines XML-Dokumentes zu ziehen, ist das Verwenden derSIZE-Werte als Approximation für den Platzbedarf der einzelnen Knoten.
DerSIZE-Wert eines Knotens enthält die Anzahl aller Knoten des Teilbaumes den der Kno- ten aufspannt, beziehungsweise die Anzahl aller Nachfahren des Knotens und sich selbst.
Die Überlegung, die hinter diesem Verfahren steht ist, dass ein Knoten der einen größe- ren Teilbaum aufspannt, beziehungsweise eine größere Anzahl an Nachfahren besitzt, auch mehr Platz für diesen Teilbaum auf der Zeichnungsfläche benötigt als ein Knoten mit entsprechend weniger großem Teilbaum.
Abbildung 6:Abbildung des input.xml Dokuments (links) und des xmark114kb.xml Do- kuments (rechts) mittels size-Approximation
Um den Baum mittels size-Approximation aus einem eingelesenen Dokument zu rekon- struieren, wird dieses Dokument von oben nach unten, das heißt von der Wurzel an bis zu den Blättern, rekursiv durchlaufen. Für jeden Knoten wird über den SIZE-Wert bestimmt welchen Platzbedarf dessen Subbaum benötigt und dementsprechend zuge- wiesen. Dieser Platz wird wiederum von den Kindknoten einen Level tiefer geerbt und unter diesen aufgeteilt. Das heißt, hat ein Kindknoten im Verhältnis zu anderen Kindkno- ten des gleichen Levels einen größeren Anteil an den Nachfahren seines Vaterknotens, so lässt sich abschätzen, dass die Nachfahren dieses Knotens mehr Platz benötigen als die eines Kindknotens mit einem kleineren Nachfahrenanteil. Passt diese Näherung gut auf das eingelesene Dokument, so ergibt sich eine Baumstruktur mit guter Knotenverteilung.
Algorithmus zur size-Approximation
Algorithm 1drawSizeTree(r oot: Integer) l vl:=0
l b:=0
ww:=getWindowWidth() drawNode(r oot,l vl,l b,ww) ifr oot.size()>1then
drawSizeTreeChildren(r oot,l vl,l b,ww) end if
Algorithm 2drawSizeTreeChrildren(par: Integer,l vl: Integer,pl b: Integer,pw: Integer)
1: nod es:=par.size()−1
2: l b:=pl b
3: for allpr echildren of pardo
4: size:=pr e.size()
5: r at io:=size/nod es
6: w:=pw∗r at io
7: drawNode(pr e,l vl+1,l b,w)
8: ifsize>1then
9: drawSizeTree(pr e,l vl+1,l b,w)
10: end if
11: l b:=l b+w
12: end for
Der Gesamtalgorithmus zur size-Approximation ist in zwei Algorithmen aufgeteilt. Der erste Algorithmus, d r awSizeT r ee genannt, trägt den ersten Level, das heißt den Wur- zelknoten, auf dem Zeichenbereich ab und prüft ob dieser Nachfahren besitzt. Ist dies der Fall, so wird der rekursive Algorithmusd r awSizeT r eeChil d r enaufgerufen, welcher alle weiteren Levels abläuft und die Nachfahrenknoten des Wurzelknotens entsprechend, nach den Regeln der size-Approximation, auf dem Zeichenbereich anordnet.
Zur Initialisierung des size-Approximationsalgorithmus wird der PRE-Wert des Wurzel- knotens (r oot) and r awSizeT r eeübergeben. Im ersten Schritt wird der Level (l vl) auf 0, was dem obersten Level innerhalb des Baumes entspricht, gesetzt. Danach wird der Variablel b, welche der linken Grenze auf der x-Achse entspricht, ebenfalls 0 zugewiesen.
Mittels Aufruf der Methode g etW ind owW id thwird als nächstes die Gesamtbreite des zur Verfügung stehenden Platzes bestimmt, innerhalb dessen der Baum gezeichnet wer- den soll. Dieser Wert wird in der Variablewwabgelegt. Im Anschluss wird die Methode d r awN od eaufgerufen. Diese Methode zeichnet Knoten an die vorgegebene Position und
benötigt dafür als Parameter denPRE-Wert des Knotens, dessen Level, die linke Grenze des dem Knoten eingeräumten Bereichs und die Pixelbreite dieses Bereichs. Da der Wur- zelknoten alleine steht, ist diese linke Grenze 0 und die Pixelbreite entspricht der des gesamten Zeichnungsbereichs. Nach dem Aufruf von d r awN od e ist der Wurzelknoten auf dem Zeichenbereich abgetragen. Nun wird getestet, ob der Wurzelknoten Nachfah- ren besitzt, das heißt ob derSIZE-Wert des Wurzelknotens (r oot.size()) größer als 1 ist.
Ist dies nicht der Fall endet der Algorithmus an dieser Stelle und der Baum besteht ledig- lich aus dem Wurzelknoten. Andernfalls werden mit dem Aufruf des rekursiven Algorith- musd r awSizeT r eeChil d r enalle nachfolgenden Level, beziehungsweise deren Knoten durchlaufen und gezeichnet. Als Übergabeparameter werden die gleichen Werte wie für died r awN od e-Methode benötigt und übergeben.
Im ersten Schritt nach dem Aufruf von d r awSizeT r eeChil d r en wird die Anzahl aller Nachfahren des aktuellen Vaterknotens (par) bestimmt. Dies entspricht demSIZE-Wert des Vaterknotens (par.size()) dekrementiert um 1, da der Vaterknoten selbst nicht zu den Nachfahren zählt. Dieser Wert wird der Variablenod eszugewiesen. Als nächstes wird die linke Grenze auf der x-Achse des dem Vaterknoten zugehörigen Anteils an der Gesamt- breite des Fensters (pl b) der Variablel bübergeben. Im Hauptschritt werden nun, mittels desPRE-Wertes des aktuellen Vaterknotens par, alle vorhandenen Kinder (pr e) in einer Schleife durchlaufen und einzeln betrachtet. Innerhalb dieser Schleife wird zunächst der derSIZE-Wert des Kindes (pr e.size()) der Variable size zugewiesen. Als nächstes wird mit- hilfe diesesSIZE-Wertes der prozentuale Anteil des aktuell betrachteten Kindknotens an den Nachfahren des Vaterknotens ermittelt. Hierfür wird derSIZE-Wert des Kindes (size) durch die Anzahl der Nachfahren des Vaterknotens (nod es) dividiert und der Variable r at iozugewiesen. Nun folgt die Approximation des dem Kindknoten an Pixelbreite zur Verfügung stehenden Platzes innerhalb des Bereichs des Vaterknotens. Diese Breite wird durch Multiplikation des prozentualen Anteils des Kindes an den Nachfahren des Vaters (r at io) mit der Pixelbreite des Vaterknotenbereichs (pw) bestimmt und der Variablew zugewiesen. Nun folgt die Zeichnung des entsprechenden Kindknotens durch Aufruf der Methoded r awN od e. Übergeben werden hierfür derPRE-Wert des Kindknotens, der Le- vel des Vaterknotens inkrementiert um 1, was dem Level des Kindknotens entspricht, die linke Grenze (l b) und die Pixelbreite (w), welche für das Kind bestimmt wurde.
Im Anschluss wird geprüft, ob der Kindknoten seinerseits Nachfahren beziehungswei- se Kinder besitzt, das heißt, ob dessen SIZE-Wert größer als 1 ist. Ist dies der Fall wird d r awSizeT r eeChil d r enerneut aufgerufen und ein neuer Rekursionsschritt mit dem ak- tuellen Kindknoten als neuem Vaterknoten, beginnt. Im letzten Schritt der Schleife wird
die linke Grenze (l b) um den Breitewert des Kinknotens (w) erhöht. Existieren weitere Kinder, so ist deren linke Grenze jeweils um die Grenzen der vorhergehenden Geschwis- ters (preceding-siblings) nach rechts verschoben. Der Algorithmus endet sobald alle Re- kursionsschritte abgearbeitet sind.
Beurteilung
Hauptvorteil der size-Approximation ist, dass sich direkt die SIZE-Werte der einzelnen Knoten verwenden lassen, um eine Struktur des Baumes zu ermitteln. Zudem liefert die size-Approximation gute Ergebnisse bei Dokumenten deren Bäume eine relative Gleich- verteilung von Knoten auf den einzelnen Ästen besitzen. Desto gleichmäßiger hier die Knoten verteilt sind, desto höher ist auch die Aussagekraft derSIZE-Werte. Dies bedeutet im Umkehrschluss jedoch, dass dieSIZE-Werte bei Bäumen mit unterschiedlicher Astent- wicklung, beziehungsweise bei deformierten Dokumenten, wenig bis gar keine Aussage- kraft besitzen. DerSIZE-Wert eines Knotens gibt zwar Aufschluss über die Anzahl dessen Nachfahren, jedoch nicht darüber wie diese über die einzelnen Levels verteilt sind.
Abbildung 7:Beispiel für ein Dokument mit schlechter Knotenverteilung bei Anwendung der size-Approximation
Abbildung 7 zeigt ein Beispieldokument bei dem die size-Approximation ein schlechtes Ergebnis liefert, da die Knoten ungleichmäßig auf den Levels verteilt sind. Links ist die Darstellung des Dokuments mittels size-Approximation zu sehen und rechts mittels Tree View, wobei die roten Zahlen den PRE-Wert und die grünen Zahlen den SIZE-Wert der einzelnen Knoten anzeigen. Betrachtet man Level 1 des Baumes, so lässt sich für die
Knoten B,C und D jeweils ein SIZE-Wert von 4 ausmachen. Nach den Regeln der size- Approximation wird den Nachfahren dieser drei Knoten damit jeweils der gleiche Platz zugewiesen. Schaut man sich die Nachfahrenknoten von KnotenBan, so zeigt sich, dass diese jeweils einzeln auf drei unterschiedliche Levels verteilt sind. Im Gegensatz dazu befinden sich alle drei Nachfahrenknoten des Knotens Dauf Level 2. Die Nachfahrenk- noten vonDbenötigen somit mehr Platz auf Level 2 als der einzelne Nachfahrenknoten vonBauf diesem Level. Die size-Approximation teilt hier jedoch beiden Nachfahren auf Level 2 den gleichen Platz zu. Hierdurch entsteht suboptimale Struktur, bei der der Platz auf dem Zeichnungsbereich nur unzureichend genutzt wird. In der Gesamtansicht liegt der Teilbaum vonBzu weit links, während die Knoten der Teilbäume vonC undDeher gestaucht wirken.
Dieses Beispiel zeigt das große Problem der size-Approximation, denn ob die Abbildung eines XML-Dokuments ein gutes Ergebnis liefert, ist abhängig vom eingelesenen Doku- ment. Dieser gravierende Nachteil müsste durch vorherige Inspektion der tieferen Levels und Korrektur der getroffenen Annahmen ausgeglichen werden. Für die Tree View wurde dieser Ansatz daher nicht weiter verfolgt.
3.1.2 pre/post-Ebene
Dieser Ansatz verwendet die PRE- und POST-Werte der Knoten eines gegebenen XML- Dokumentes um dessen Baum abzubilden. Als Grundlage dient ein kartesisches Koordi- natensystem inN0×N0, auf dessen Achsen die PRE- und POST-Werte der Knoten abge- tragen werden. Die sich aufspannende Ebene wird als pre/post-Ebene (pre/post plane vgl.[Gru02]) bezeichnet. Am Ende des Verfahrens liegt der abgebildete Baum innerhalb der pre/post-Ebene.
Abbildung 8:Abbildung des input.xml Dokuments (links) und des xmark114kb.xml Do- kuments(rechts) mittels pre/post-Ebene
Um den Baum eines XML-Dokumentes zu erhalten werden alle Knoten des Dokuments durchlaufen und jeder Knoten einzeln betrachtet. Für jeden aktuell fokussierten Knoten wird, zusätzlich zum gegebenen PRE-Wert, der POST-Wert bestimmt. Im Anschluss wer- den die Achsen der pre/post-Ebene entsprechend derPRE- undPOST-Werte abgeschritten und so der Punkt des Knotens innerhalb der pre/post-Ebene ermittelt3. Die entstehenden Punkte auf der Ebene werden, zur Visualisierung der Beziehungen der Knoten unterein- ander, mit Linien verbunden. Das heißt, besitzt ein Knoten einen Vater, was auf alle außer dem Wurzelknoten zutrifft, so wird eine Verbindung zwischen dem Knoten und seinem Vater gezeichnet. Innerhalb der pre/post-Ebene entsteht so eine Abbildung des Baumes des übergebenen XML-Dokuments.
3In diesem Beispiel werden diePRE-Werte auf die x-Achse und diePOST-Werte auf die die y-Achse abgetra- gen. Die Werte auf der x-Achse nehmen dabei von links nach rechts und die der y-Achse von oben nach unten zu.
Algorithmus pre/post-Ebene:
Algorithm 3drawNodesPrePostPlane(pr e: Integer,l vl: Integer) post:=calcPost(pr e,l vl)
x:=pr e y:=post
drawNode(pr e, x, y) par:=pr e.par() ifpar6=−1then
ppost :=calcPost(par,l vl−1) p x :=par
p y:=ppost
drawConnection(p x,p y, x, y) end if
for allc pr echildren ofpr edo drawPrePostPlane(c pr e,l vl+1) end for
Der Algorithmus zur Zeichnung des Baumes innerhalb der pre/post-Ebene ist rekursiv aufgebaut und benötigt als Übergabeparameter den aktuell betrachtetenPRE-Wert (pr e) und den Level (l vl) des zu diesem PRE-Wert gehörenden Knotens. Um den Baum eines gegeben Dokuments abzubilden, werden als Startparameter der PRE-Wert des Wurzel- knotens und 0 als Level (was dem obersten Level des Baumes entspricht) an den Algo- rithmus übergeben. Im ersten Schritt wird derPOST-Wert des Wurzelknotens bestimmt.
Dies geschieht über den Aufruf der Methodecal c Post. Es folgt eine Zuordnung derPRE- undPOST-Werte des Knotens zu denx- und y-Koordinaten der pre/post-Ebene. Mithilfe dieser Koordinaten wird die Methoded r awN od eaufgerufen, welche den übergebenen Knoten an den entsprechenden Punkt im Koordinatensystem zeichnet. Im Weiteren wird ermittelt ob ein Vaterknoten (par) existiert. Ist dies der Fall, wird eine Verbindung vom aktuell betrachteten Knoten zu dessen Vater gezeichnet. Dies geschieht durch Ermitt- lung der Koordinaten des Vaters. Zunächst wird mittels Aufruf dercal c Post-Methode der
POST-Wert des Vaters bestimmt. Übergeben werden hierfür derPAR-Wert des Knotens und dessen Level um 1 dekrementiert (was dem Level des Vaterknotens entspricht). Mithilfe desPOST-Wertes werden die x- und y-Koordinaten des Vaters (p x und p y) zugewiesen und im Weiteren an die Methoded r awC onnec t ionübermittelt. Diese Methode zeichnet eine Linienverbindung zwischen dem Koordinatenpunkt des Knotens selbst und dessen Vater. Im letzten Schritt werden alle Kinder des aktuellen Knoten durchlaufen. Jedes die- ser Kinder wird einzeln betrachtet und startet einen neuen Aufruf des Algorithmus. Bei
diesem Rekursionsschritt werden der PRE-Wert des Kindes und der Level des Knotens um 1 inkrementiert (was dem Level der Kinder entspricht) übergeben. Der Algorithmus endet sobald alle Blätter des Baumes erreicht wurden, das heißt alle Knoten die keine Kinder besitzen. Als Endresultat ergibt sich ein Baum der innerhalb der pre/post-Ebene liegt.
Beurteilung
Die Verwendung der pre/post-Ebene bringt den Vorteil, dass sich die hierarchischen Be- ziehungen der Knoten untereinander gut abbilden lassen. Jeder Knoten hat einen ein- deutig zugewiesenen Punkt auf der pre/post-Ebene, so dass es zu keinerlei Überschnei- dungen, wie etwa bei der Approximation über dieSIZE-Werte, kommen kann. Zusätzlich ergibt sich aus den einzelnen Knoten mit Linien verbunden eine schöne Struktur, die den Baum deutlich erkennbar macht.
Abbildung 9: Darstellung von scene.xml, pre/post-Ebene (links) und BaseX Tree View (rechts)
Hauptnachteil, der gegen die Verwendung des pre/post-Ebene-Ansatzes spricht, ist der enorme Platzbedarf der entstehenden Bäume. Funktioniert die Darstellung bei kleinen Dokumenten mit wenigen Knoten noch sehr gut, so wächst der Baum schon bei mit- telgroßen Dokumenten mit mehreren Dutzend Knoten und nur wenigen Levels extrem hoch, so dass er selbst auf einem Bildschirm mit hoher Auflösung nicht mehr komplett dargestellt werden kann. Ein Beispiel hierfür zeigt Abbildung 9. Auf beiden Bildern ist das
scene.xml Dokument dargestellt, links mittles pre/post-Ebene und zum Vergleich rechts in der fertigen Version der Tree View. Obwohl das Gesamtdoument nur 73 Knoten auf 6 Levels verteilt umfasst, lässt sich hier bei der Abbildung auf die pre/post-Ebene, trotz einer Auflösung von 1920×1200 Bildpunkten, nur ein Teilausschnitt des Baumes sehen, da dieser zu riesig für den Bildschirmausschnitt ist. Dagegen wird dieser in der Tree View bei einem deutlich kleineren Zeichnungsbereich mit hohem Detailgrad abgebildet.
Für die Zielvorgabe, eine Visualisierung zu entwickeln, welche Teil einer Datenbankan- wendung ist, mithilfe der auch große Dokumente untersucht werden, ist diese Limitie- rung des pre/post-Ebene-Ansatzes unzureichend. Um die pre/post-Ebene dennoch auch für größere Dokumente nutzbar zu machen, müsste mithilfe von Transformationen und Skalierung der eigentliche Baum an den Anzeigebereich angepasst werden. Dies wür- de aber den eigentlichen Vorteil der pre/post-Ebene, nämlich die garantierte Nichtüber- schneidung der Knoten des Baumes, zu weiten Teilen aufheben und es müssten entspre- chende Kontrollmechanismen entworfen werden. Für die Tree View wurde dieser Ansatz daher nicht weiterverfolgt.
3.1.3 Rekonstruktion des Baumes mittels Level-Knotenmatrix
In diesem Verfahren wird eine zweidimensionale Matrix zur Rekonstruktion des XML- Baumes verwendet. Diese Matrix, im Weiteren als Level-Knotenmatrix4 bezeichnet, be- steht aus den einzelnen Levels des Baumes und den jeweils zu diesen Levels gehörenden Knoten, beziehungsweise derenPRE-Werte.
Mithilfe der Level-Knotenmatrix lässt sich eine optimale Platzverteilung der Knoten im Baum bestimmen. Hierfür wird jeder der vorhandenen Levels für sich betrachtet und die Anzahl der darin enthaltenen Knoten, sowie die Pixelbreite des zur Verfügung stehenden Ausgabebereiches auf dem Bildschirm, einbezogen. Reicht die Pixelbreite zur Darstel- lung aller Knoten eines Levels aus, wird jeder Knoten einzeln in Form eines Rechtecks (Rectangle) auf dem Zeichenbereich abgebildet. Sollte der Platz nicht für alle Knoten ausreichen tritt ein Sonderfall ein und alle auf dem Level vorhandenen Knoten müs- sen so zusammengefasst oder umorganisiert werden, dass diese dennoch auf dem zur Verfügung stehenden Anzeigebereich abgetragen werden können. Für Tree View wurde hierfür eine Zusammenfassung der Knoten in speziellen Rechtecken, sogenannten Big Rectangles, gewählt. Eine ausführliche Erläuterung der Big Rectangles findet sich in Ka- pitel 3.2.4.
Abbildung 10: Abbildung des input.xml Dokuments (links) und des xmark114kb.xml Dokuments(rechts) mittels Level-KnotenmatrixVerfahren
Zur Abbildung des Baumes eines gegebenen XML-Dokuments mithilfe des Level-Knotenmatrix
4Eine detaillierte Erläuterung zur Level-Knotenmatrix und Algorithmen mit deren Hilfe sich eine Level- Knotenmatrix berechnen lässt, findet sich in Kapitel 4.1
Verfahrens, wird zunächst die Level-Knotenmatrix erstellt. Auf Basis dieser werden an- schließend alle Levels des Dokumentes von oben nach unten durchlaufen und betrachtet.
Für jeden Level lassen sich aus der Level-Knotenmatrix die zugehörigen Knoten, sowie deren Anzahl auslesen. Jedem Knoten eines Levels soll nun anteilsmäßig der gleiche Platz eingeräumt werden. Dieser Platz ergibt sich aus der Division von zur Verfügung stehender Pixelbreite des Zeichenbereichs durch die Anzahl der Knoten auf dem entsprechenden Level. Liegt der berechnete Wert über der Grenze von einem Pixel, so lassen sich alle Kno- ten dieses Levels zeichnen. Jeder Knoten erhält dann den gleichen Platz zugesprochen.
Das bedeutet, falls existent, besitzen sowohl die vorhergehenden (preceding siblings), als auch die nachfolgenden Geschwister (following siblings) die gleiche Breite wie der Knoten selbst. Die einzelnen Knoten werden im Anschluss jeweils nebeneinander im Ab- stand des errechneten Platzes gezeichnet. Für jeden Knoten an der Indexpositionnder Level-Knotenmatrix eines Levels gilt also, wenn Bdie Breite jedes einzelnen Knoten ist und LB die linke Grenze auf der x-Achse, ab der der Zeichenbereich eines Knotens be- ginnt: LBn= (n−1)∗B.
Reicht die Pixelbreite des Zeichenbereichs nicht aus, um die Knoten eines Levels zu zeich- nen, werden die Knoten eines solchen Levels in einem Big Rectangle zusammengefasst.
Das Verfahren endet sobald alle Levels durchlaufen sind.
Algorithmus zur Rekonstruktion mittels Level-Knotenmatrix
Der Algorithmus, um den Baum mittels Level-Knotenmatrix abzubilden, benötigt als Aus- gangsparameter den PRE-Wert des Wurzelknotens (r oot). Im ersten Schritt wird die Level-Knotenmatrix bestimmt und der Variable l nm zugewiesen. Nun wird der maxi- male Level des Baumes ermittelt. Dieser Level entspricht genau der Höhe der Level- Knotenmatrix minus 1 und wird in der Variableml vgespeichert. Als nächstes wird mit- tels des Aufrufs der Methodeg etW ind owW id thdie Breite des zur Verfügung stehenden Zeichenbereichs in die Variable wwabgelegt. Im nun folgenden Hauptschritt wird eine Schleife betreten, die jeden Level des Baumes durchläuft, das heißt von Level 0 bis zum maximalen Level (ml v). Der jeweils aktuelle Level wird in die Laufvariablel vzwischen- gespeichert. Innerhalb der Schleife wird nun die Anzahl der Knoten auf dem betrachteten Level ermittelt. Dieser Wert ergibt sich aus der Größe der Level-Knotenmatrix an der In- dexposition des Levels (l nm[l v].size()) und wird an die Variable nod es übergeben. Im Anschluss wird der Platz bestimmt, der den einzelnen Knoten des gerade betrachteten Levels zur Verfügung steht. Dieser Wert ergibt sich aus der Gesamtfensterbreite (ww)
Algorithm 4drawLvlNodeMatrixTree(r oot: Integer) l nm:=generateLevelNodeMatrix(r oot)
ml v:=l nm.height()−1 ww:=getWindowWidth() forl v:=0to ml vdo
nod es:=l nm[l v].size() w:=ww/nod es
x:=0
ifw<2then
drawBigRectangle(l v,x,ww) else
for allpr einl nm[l v]do drawRectangle(pr e,l v,x,w)
x:=x+w end for end if end for
dividiert durch die Anzahl der Knoten des Levels (nod es) und wird der Variablewzuge- wiesen. Als nächstes wird die Startposition auf des x-Achse (x) auf 0 gesetzt. Nun folgt eine Prüfung, ob alle Knoten des aktuell betrachteten Levels auf den Zeichenbereich ab- getragen werden können, das heißt, ob die jedem Knoten zur Verfügung stehende Breite wüber einem Pixel liegt. Ist dies nicht der Fall, so werden die Knoten dieses Levels mit- tels Aufruf der Methoded r awBi gRec t ang l ein einem Big Rectangle zusammengefasst.
Dieser Methode werden der aktuellen Level (l v), die linke Grenze (x) und die Gesamt- fensterbreite (ww) übergeben. Reicht der Platz zur Zeichnung der Knoten aus, folgt eine Schleife, die alle in der Level-Knotenmatrix abgelegtenPRE-Werte der Knoten eines Levels (l nm[l v]) durchläuft. Jeder aktuell betrachtetePRE-Wert wird in die Variablepr eabge- legt. Im ersten Schritt der Schleife wird der gerade betrachtete Knoten mittels Aufruf der Methoded r awRec t ang l egezeichnet. Hierfür werden derPRE-Wert des Knotens, dessen Level (l vl), sowie der Startpunkt (x) und die Breite (w) des dem Knoten zugordneten Platzes übergeben. Nachdem der Knoten gezeichnet ist, wird der bestehende Startwert des Knotenbereichs auf der x-Achse um die Breitew der einzelnen Knoten nach rechts verschoben. Die Schleife endet sobald alle Knoten des betrachteten Levels gezeichnet wurden.
Am Ende des Verfahrens ist der Baum auf dem Zeichenbereich abgetragen.
Beurteilung
Die Rekonstruktion des Baumes mittels Level-Knotenmatrix bringt den Vorteil, dass der Platz für die Knoten, dank der gewonnen Informationen aus der Level Knotenmatrix, optimal aufgeteilt werden kann. Es ensteht eine gute Struktur, die sich leicht, wie in Kaptitel 3.2.1, durch Nachfahrenverbindungen ergänzen lässt. Ein Nachteil dieses Ver- fahrens ist jedoch, dass somit eine Abhängigkeit von der Level-Knotenmatrix besteht. Das heißt, das XML-Dokument muss zunächst komplett durchlaufen werden, um die Level- Knotenmatrix zu erstellen und kann erst danach auf dem Zeichenbereich abgetragen werden. Um diesen Performanznachteil auszugleichen, wurden zwei Algorithmen zur möglichst effizienten Erstellung der Level-Knotenmatrix entwickelt und evaluiert. Zu- dem wurde ein Cachingverfahren eingeführt, wodurch nur ein einmaliges Erstellen der Level-Knotenmatrix nach dem öffnen eines Dokuments notwendig ist und diese danach zur Berechnung von Teilbäumen weiterverwendet werden kann. Diese Maßnahmen zur Verbesserung der Performanz werden im Kapitel „Performanz“ genauer besprochen.
Die Frage, was passiert wenn ein Pixelbereich nicht ausreicht um alle Knoten eines Levels abzutragen, wurde für die Tree View mit den sogenannten „Big Rectangles“ beantwor- tet. Diese Herangehensweise, um die Knoten eines Levels zusammen zu fassen, wird in Kapitel 3.2.4 genauer besprochen. Bei Dokumenten mit wenigen Levels und hoher Knotenanzahl kann es dabei dazu kommen, dass die Abbildung eines solchen Baumes eingeschränkte Aussagekraft bietet, da alle Levels außer dem Wurzelknoten aus Big Rec- tangles bestehen. Dennoch überwiegen die Vorteile der kompakten Darstellung.
Abbildung 11:Vergleich Rekonstruktionsverfahren
Abbildung 11 zeigt am Beispiel des pom.xml-Dokuments einen Vergleich der bisher be- sprochenen Rekonstruktionsverfahren. Das Dokument enthält 146 Knoten, 9 Levels und hat eine Größe von 4KB. Die Screenshots wurden dabei jeweils bei einer Fenstergröße
des Zeichenbereichs von 570×500 Bildpunkten aufgenommen.
Bild 1 zeigt die size-Approximation, welche für dieses Dokument eine suboptimale Ver- teilung ermittelt, zudem kommt es zu massiven Überschneidungen. Bild 2 zeigt die Ab- bildung des Dokuments auf der pre/post-Ebene, bei der zwar eine gute Baumstruktur entsteht, welche jedoch bei weitem zu groß ist um in diesen Bildschirmausschnitt zu pas- sen. Das letzte Bild zeigt den gleichen Baum dargestellt mittels des Level-Knotenmatrix Verfahrens. Hier wird der komplette Baum dargestellt ohne Überschneidungen und Platz- problemen. Insgesamt stellte sich dieses Verfahren als am besten geeignet für das Tree View Projekt heraus und wurde daher als Basis für die weitere Entwicklung verwendet.
3.2 Konzepte und Umsetzung
Im letzten Unterkapitel wurden unterschiedliche Methoden zur Rekonstruktion des Bau- mes eingelesener XML-Dokumente besprochen. Für die Umsetzung des Tree View Pro- jektes wurde das Verfahren mittels Level-Knotenmatrix gewählt. Auf Basis dieses Verfah- rens wurden in der weiteren Entwicklung der Tree View unterschiedliche Konzepte zur Erweiterung und Verbesserung dieses Ansatzes evaluiert. Ein Teil dieser Konzepte soll in diesem Unterkapitel vorgestellt und besprochen werden.
Zunächst wird das Zeichnen von Nachfahrenverbindungen des Baumes näher erläutert.
Danach folgt die Vorstellung einer Idee zum Einsatz von Farben als Metainformation über einzelne Knoten innerhalb des Baumes. Im Anschluss wird ein interaktives Highlighting von Knotenbeziehungen besprochen und zuletzt wird auf das Konzept der Big Rectangles eingegangen.
3.2.1 Zeichnen von Nachfahrenverbindungen
Wie in der Einleitung dieses Kapitels besprochen, sind die Knoten einer traditionellen Baumdarstellung untereinander mit Linien verknüpft, so dass die Beziehungen innerhalb des Baumes deutlich werden. Bisher wurde nur die reine Knotenabbildung der Rekon- struktion mittels Level-Knotenmatrix erläutert. Hier soll nun näher auf die Erstellung von Nachfahrenverbindungen zwischen den Knoten eingegangen werden, das heißt, auf Verbindungslinien, die jeweils zwischen dem Vaterknoten auf Level nund dessen Kind- knoten auf Leveln+1 gezeichnet werden. Alle Kindknoten weisen dabei auf die Position des Vaterknotens. Werden diese Linienverbindungen über alle Levels gezeichnet, so ent- stehen mehrere Pfade, die sich von der Wurzel bist zu den Blättern erstrecken und die darin enthaltenen Knoten kenntlich machen.
Abbildung 12: Abbildung des input.xml Dokuments ohne Nachfahrenverbindungen (links) und mit Nachfahrenverbindungen (rechts).
Abbildung 12 zeigt auf der linken Seite den Baum des input.xml-Dokuments ohne einge- zeichnete Nachfahrenverbindungen und auf der rechten Seite mit. Der Aufbau und die Beziehungen der Knoten untereinander lassen sich mit diesen Verbindungen deutlich erkennen und unterstützen somit den Benutzer bei der Analyse eines Dokuments.
Kurzbeschreibung des Verfahrens
Das Verfahren zur Einzeichnung der Nachfahrenverbindungen ist rekursiv. Ausgangs- punkt ist der Knoten dessen Nachfahren gezeichnet werden sollen. Zunächst wird ge- prüft ob Nachfahren existieren. Ist dies der Fall, so wird die Pixelposition bestimmt an der sich der betrachtete Knoten befindet. Im Anschluss wird derPRE-Wert dieses Knotens um 1 inkrementiert, um dessen erstes Kind zu bestimmen und der Knoten selbst wird zum ersten betrachteten Vaterknoten. Da allePRE-Werte nach Levels unterteilt und nach ihrem Vorkommen im Baum geordnet in der Level-Knotenmatrix vorhanden sind, kann die Indexpositionid x des ersten Kindknotens auf der Level-Knotenmatrix dazu dienen, die weiteren Kinder dieses Vaterknotens zu bestimmen. Alle weiteren Kindknoten, falls vorhanden, müssen also auf dem gleichen Level der Level-Knotenmatrix ab der Indexpo- sition idx+1 folgen. Zudem lässt sich mittels Addition desPRE-Werts des Vaterknotens mit dessenSIZE-Wert eine obere Grenze festlegen, die die gelesenen Knoten unterschreiten müssen damit sie Kinder des Vaterknotens sind. Dies gilt, da derPRE-Wert eines Knotens addiert mit dessenSIZE-Wert ein Zeiger auf den, falls existent, nächsten nachfolgenden Knoten (first following) ist. Der PRE-Wert eines nachfolgenden Knotens, muss per De- finition größer als der PRE-Wert aller Kinder eines vorhergehenden Knotens (preceding node) sein. Das heißt, solange es sich bei den gelesenen Knoten an den weiteren Index- positionen id x+1+2+. . .+num PRE-Werte handelt, die kleiner sind als der PRE-Wert des Vaterknotens addiert mit dessenSIZE-Wert, so sind die gelesenen Knoten Kinder des Vaterknotens. Auf diese Weise werden alle Kindknoten des aktuell betrachteten Vater- knotens abgerufen. Für jeden Kindknoten wird dessen Position auf der Zeichenebene bestimmt. Zwischen dieser Position und der des Vaters wird eine Verbindung gezeichnet.
Im Anschluss ruft jeder Kindknoten das Verfahren erneut auf.
Die Nachfahrenverbindungen sind abgebildet sobald für alle rekursiven Aufrufe die Ab- bruchbedingung eingetroffen ist, das heißt, sobald alle Blattknoten erreicht wurden.
Algorithmus Nachfahrenverbindungen
Algorithm 5drawDescendantsConnection(par: Integer, pl v: Integer) size:=par.size()
ifsize=1then return end if
p x:=getNodePosition(par,pl v) l vl:=pl v+1
pr e:=par+1
id x:=LEVELNODEMATRIX[l vl].getIndexOf(pr e) nc:=LEVELNODEMATRIX[l vl].count()
while pr e<par+sizedo x:=getNodePosition(pr e,l vl) drawLine(p x,pl vl,x,l vl)
drawDescendantsConnection(pr e,l vl) id x:=id x+1
ifid x=nc then return
end if
pr e:=LEVELNODEMATRIX[l vl].getIndexPosition(id x) end while
Der rekursive Algorithmus d r aw Descend antsC onnec t ionzur Zeichnung der Nachfah- renverbindungen benötigt als Ausgangsparameter denPRE-Wert des Knotens (par) von dem aus die Nachfahrenverbindungen gezeichnet werden sollen und dessen Level (pl v).
Im ersten Schritt der Rekursion dient der Ausgangsknoten als Vaterknoten, um eine di- rekte Verbindung zwischen diesem und dessen Kindknoten zu zeichnen.
Zunächst wird derSIZE-Wert des Vaterknotens der Variablesizezugeordnet. Im Anschluss wird mittels des SIZE-Wertes geprüft, ob der entsprechende Knoten Nachfahren besitzt.
Ist der SIZE-Wert gleich 1, so ist dies nicht der Fall und es folgt der Abbruch. Hat der betrachtete Knoten Nachfahren, so wird als nächstes dessen Position auf der Zeichene- bene mittels Aufruf der Methode g et N od ePosi t ion erfasst. Diese Methode ruft intern die Level-Knotenmatrix auf und errechnet anhand der Pixelbreite des Zeichenbereichs, der Indexposition des Knotens und der Knotenanzahl des betrachteten Levels, die Positi- on an der sich ein Knoten befindet. Hierfür werden der Level des Vaterknotens (pl v) und dessenPRE-Wert (par) an die Methode übergeben. Der errechnete Positionswert wird in die Variable p x abgelegt. Desweitern wird der Variable l vl der Level des Vaterknotens
(pl v) inkrementiert
um 1 zugewiesen, was dem Level dessen Kinder entspricht. Als nächstes wird das erste Kind des Vaterknotens bestimmt, indem dessenPRE-Wert (par) um 1 inkrementiert wird.
DerPRE-Wert des Kindes wird in die Variable pr eabgelegt. Nun wird die Indexposition des Knotens auf der Level-Knotenmatrix bestimmt. Dazu werden allePRE-Werte des Le- vels mittels Binärer Suche durchsucht (LEVELNODEMATRIX[l vl].getIndexOf(pr e)) und die entsprechende Indexposition des Kindknotens zurückgegeben. Dieser Wert wird in id x gespeichert. Als nächstes wird die Anzahl der Knoten auf diesem Level mittels der count-Methode der Level-Knotenmatrix bestimmt (LEVELNODEMATRIX[l vl].count()) und an die Variablencübergeben. Im jetzt folgenden Hauptschritt wird eine Schleife be- treten, die alle Kinder (pr e) des Vaterknotens (par) durchläuft. Dies geschieht über Abruf des Levels der Kinder aus der Level-Knotenmatrix. Als Abbruchbedingung für die Schleife dient derPRE-Wert des Vaterknotens (par) addiert mit dessenSIZE-Wert (size). Solange dieser Wert größer ist als der PRE-Wert des aktuell betrachteten Knotens handelt es um ein Kind des Vaterknotens, ansonsten folgt der Abbruch der Schleife. Im ersten Schritt innerhalb der Schleife wird die Position des Kindknotens auf dem Zeichenbereich mittels des Aufrufs der Methode g et N od ePosi t ionbestimmt. Dieser Wert wird in die Variable x abgelegt. Nun folgt die Zeichnung der Verbindung zwischen dem Vaterknoten (par) und dem gerade betrachteten Kindknoten (pr e) über die Methoded r aw Line. Durch die Übergabe des Positionswertes des Vaterknotens (p x) und dem des aktuell betrachteten Kindknotens (x), wird eine Verbindung zwischen diesen gezeichnet. Als nächstes wird d r aw Descend antsC onnec t ionmit dem aktuell betrachteten Kindknoten erneut aufge- rufen um mit diesem als potentiellen Vaterknoten, einen neuen Rekursionsschritt zu star- ten. Danach wird die Indexpositionid xdes betrachteten Levels der Level-Knotenmatrix um 1 inkrementiert. Zeigt die inkrementierte Indexposition auf eine Stelle, die die Größe des Levels übersteigt, das heißt, fallsncgleichid xist, folgt der Abbruch. Ansonsten wird derPRE-Wert an der neuen Indexposition der Level-Knotenmatrix abgerufen und in der Variable pr eabgelegt. Es folgt eine Wiederholung des Hauptschritts.
Der Algorithmus endet sobald in allen abgelaufenen Pfaden die Blätter erreicht wurden.
Ergebnis sind Strichverbindungen, die die Knotenbeziehungen innerhalb des Baumes vi- sualisieren.
Beurteilung
Die Verbindungslinien stellen eine deutliche Verbesserung der Baumabbildung dar. Durch die Darstellung der Beziehungen der Knoten untereinander erhält der Nutzer ein klareres Bild wie die Hierarchie des Baumes aufgebaut ist und kann somit das Dokument besser untersuchen. Aus diesem Grund werden die Nachfahrenverbindungen des Wurzelkno- tens in der Tree View, zusätzlich zu den eigentlichen Knoten, immer eingezeichnet.
3.2.2 Einsatz von Farben / Knoten-Temperatur
Farben können neben rein ästhetischer Darstellung dazu genutzt werden, um die Auf- merksamkeit auf einzelne Elemente innerhalb einer Visualisierung zu lenken (vgl.[LHB03]).
Mittels Farben lassen sich so zusätzliche Metainformationen übermitteln, etwa eine Grup- pierung oder Zuordnung dargestellter Einzeldaten. Hieraus entstand die Idee Farben zu nutzen, um zusätzliche Informationen über die Knoten in einem Baum zu vermitteln.
Für eine Vorabversion der Tree View diente die geläufige Darstellung von Temperatur als Vorbild, um den Einfluss einzelner Knoten auf das Dokument zu zeigen. Wärme wird zumeist leuchtend rot und Kälte dunkelblau dargestellt. Zwischen diesen Extremen gibt es Mischfarben, die eine mittlere Temperatur anzeigen. Der Einfluss von Knoten bezog sich hierbei auf die Anzahl an Nachfahren in Relation zu den anderen auf dem gleichen Level befindlichen Knoten. Analog zur Temperaturdarstellung bei der rote Farben eine hohe Temperatur anzeigen und blaue Farben eine niedrige, wurde hoher Einfluss mit roter Farbe unterlegt und geringer Einfluss mit blauer. Der Nutzer sollte so intuitiv er- kennen können welche Knoten innerhalb des Dokumentes für ihn besonders interessant sind, weil sie einen großen Teilbaum aufspannen.
Abbildung 13:Temperaturdarstellung einer frühen Tree View Version
Abbildung 13 zeigt die Temperaturdarstellung am Beispiel des xmarl111kb.xml-Dokuments.
Mithilfe dieser Ansicht lässt sich beispielsweise gut feststellen, dass die Knoten „cat- graph“ und „categories“ auf Level 3 des Baumes nur wenige Nachfahren besitzen und damit auch wenig, bis gar keinen Einfluss auf die nachfolgenden Levels haben. Aller- dings werden auch die Blattknoten auf dem untersten Level rot dargestellt, so dass die Knoten-Temperatur hier eher verwirrend wirkt.
Beurteilung
Die Darstellung der Knoten-Temperatur wurde für die Tree View nicht weiterverfolgt, da diese von Testnutzern als weit weniger intuitiv empfunden wurde als erwartet.
3.2.3 Interaktives Highlighting der Knotenbeziehungen
In den vorangegangen Unterkapiteln wurde bisher nur die rein statische Abbildung des Baumes auf der Zeichenebene behandelt. Um dem Nutzer zusätzliche Informationen bei der Untersuchung eines XML-Dokuments zugänglich zu machen, wurde zunächst mit Far- ben und der besprochenen Knotentemperaturdarstellung experimentiert. Da sich dieser Ansatz jedoch bei Anwendertests als wenig intuitiv herausstellte, wurde nach weiteren Methoden gesucht. Dabei entstand die Idee für die Tree View ein Echtzeithighlighting der Knotenbeziehungen zu entwickeln. Einzelne Knoten eines abgebildeten Baumes lassen sich dabei mit dem
Mauscursor fokussieren, wodurch die Beziehungen dieses Knotens eingeblendet werden.
Das heißt, sobald mit der Maus über einen Knoten im Baum gefahren wird, wird dieser Knoten speziell hervorgehoben und zusätzlich werden sowohl die Vorfahren- als auch die Nachfahrenknoten durch entsprechend dunklere Farben angezeigt.
Abbildung 14:Beispiel Echtzeithighlighting
Abbildung 14 zeigt am Baum des input.xml-Dokuments ein Beispiel für das Echtzeithigh- lighting der Knotenbeziehungen. Der Mauscursor ist über dem Knoten „div“ positioniert und fokussiert diesen damit. Durch das fokussieren des Knotens wird dieser entsprechend umrandet und die Vor- sowie die Nachfahrenknoten eingeblendet. Ebenfalls werden die
Pfade zwischen den Knoten hervorgehoben und über dem fokussierten Knoten wird ein kleines Label mit dem Textinhalt des Knotens angezeigt.
Kurzbeschreibung des Verfahrens
Um dieses interaktive Echtzeithighlighting der Knotenbeziehungen zu realisieren, muss zunächst derPRE-Wert und der Level des fokussierten Knotens ermittelt werden. Stehen diese Werte fest, kann der in Kapitel 3.2.1 beschriebene Algorithmus dazu verwendet werden, um die Nachfahrenbeziehungen des Knotens entsprechend hervorzuheben. Da zudem auch die Vorfahrenbeziehungen angezeigt werden sollen, das heißt, der Pfad vom fokussierten Knoten bis zu Wurzel, wird ein zusätzlicher Algorithmus für diese Aufgabe benötigt. Der im Nachfolgenden besprochene Algorithmus zur Zeichnung des Vorfahren- pfads kann hierfür verwendet werden. Dieser benötigt ebenfalls denPRE-Wert, sowie den Level des fokussierten Knotens als Übergabeparameter.
Sobald beide aufgerufenen Algorithmen ihren Baumdurchlauf beendet haben sind die Knotenbeziehungen des fokussierten Knotens auf dem Zeichenbereich abgetragen.
Algorithmus Vorfahrenpfad
Algorithm 6drawAncestorsConnection(pr e: Integer, l vl: Integer) par:=pr e.par()
ifpar=−1then return
end if
x:=getNodePosition(pr e,l vl) pl vl:=l vl−1
p x:=getNodePosition(par,pl vl) drawLine(p x,pl vl, x,l vl)
drawAncestorsConnection(par,pl vl)
Der rekursive Algorithmus d r awAncest orsC onnec t ion dient dazu den Vorfahrenpfad von einem betrachteten Knoten bis zur Wurzel zu zeichnen. Als Ausgangsparameter wer- den der PRE-Wert des Knotens (pr e) und dessen Level (l vl) benötigt. Zunächst wird derPRE-Wert des Vaterknotens abgerufen und par zugewiesen. Existiert kein Vaterkno- ten, beziehungsweise ist par gleich -1, so ist der betrachtete Knoten der Wurzelkno-
ten und es folgt der Abbruch. Ist dies nicht der Fall, wird mittels Aufruf der Methode g et N od ePosi t ionmit demPRE-Wert des Knotens und dessen Level, die Position des Kno- tens auf der Zeichenebene ermittelt und der Variable x zugewiesen. Im Anschluss wird in der Variablepl vl der Level des Vaterknotens abgelegt, welcher dem Level des Knotens dekrementiert um 1 entspricht. Als nächstes wird g et N od ePosi t ionmit dem PRE-Wert des Vaterknotens (par) und dessen Level (pl vl) aufgerufen und der erhaltene Wert in die Variablep x abgelegt. Nun wird eine Verbindung zwischen dem aktuell betrachteten Knoten und dessen Vater gezeichnet. Dies geschieht über die Methoded r aw Line. Dieser werden die Positionen der beiden Knoten (p x,x), sowie deren Levels (pl vl,l vl) über- geben. Der letzte Schritt ruft den Algorithmusd r awAncest orsC onnec t ionrekursiv mit demPRE-Wert des aktuellen Vaters und dessen Level erneut auf. Das Verfahren endet so- bald der aktuell betrachtete Knoten dem Wurzelknoten entspricht.
Ergebnis ist ein Pfad vom betrachteten Knoten zur Wurzel.
Beurteilung
Das Einblenden der Beziehungen fokussierter Knoten erlaubt dem Nutzer direkt einzelne Knoten zu untersuchen und dadurch genauere Informationen über deren Rolle im Baum zu erhalten. Auch im Zusammenspiel mit anderen Visualisierungen können dadurch bes- sere Erkenntnisse gewonnen werden, siehe Kapitel 2.2.
Das Highlighting der Nachfahrenbeziehungen ist daher ein wichtiges Element der Tree View.
3.2.4 Big Rectangles
Visualisierungen stoßen bei entsprechend großen Inputdatenmengen an eine Grenze, bei der die Anzahl der darzustellenden Elemente höher ist als der zur Verfügung stehende, limitierte Anzeigebereich auf dem Ausgabegerät. Tritt dieser Fall ein, müssen Lösungen gefunden werden, um dennoch eine Repräsentation der Daten zu ermöglichen. Im Fal- le einer traditionellen Baumvisualisierung im XML-Umfeld ist vor allem die Breite des Zeichenbereichs ein limitierender Faktor. Ein Großteil der XML-Dokumente umfasst nur wenige Levels auf die sich die darin abgelegten Daten verteilen. Bei entsprechend großen Dokumenten, mit tausenden von Knoten auf einem Level, ist es daher nicht möglich je- den Knoten abzubilden, da die Anzahl an Knoten die Pixelbreite des Zeichenbereichs übertrifft.
Abbildung 15:Übergang von normalen Knoten zu Big Rectangles
Abbildung 15 zeigt die Funktionsweise der Big Rectangles am Beispiel des food.xml Do- kuments. Auf dem Bild links ist ein Fenster zu sehen dessen Zeichenbereich groß genug ist um alle Knoten des Dokuments einzeln darzustellen. Wird nun beispielsweise wie hier im rechten Bild geschehen, der Fensterausschnitt für die Tree View entsprechend verkleinert, so dass die Knoten einiger Levels nicht mehr auf den Zeichenbereich passen, werden diese in Big Rectangles zusammengefasst. In diesem Beispiel trifft dies auf den
Level 4 und den Level 5 des Dokuments zu.
Eine Fragestellung, die sich durch den Einsatz von Big Rectangles ergibt, ist wie trotz der Knotenzusammenfassung möglichst viele Informationen über den Gesamtbaum, einzel- ne Levels und deren Knoten an den Nutzer vermittelt werden können. Hierzu werden wie beispielsweise auf dem rechten Bild in Abbildung 15 zu erkennen, die Nachfahrenver- bindungen ebenfalls für Levels, deren Knoten in einem Big Rectangle zusammengefasst sind, eingezeichnet. Die Zeichnung der Verbindungen findet dabei über eine Approxi- mation der Knoten des entsprechenden Big Rectangles statt, so dass damit auch über die zusammengefassten Levels hinweg eine ungefähre Visualisierung der Beziehungen des Gesamtbaumes möglich ist. Zudem gibt es für die Big Rectangles, ebenfalls wie für normale Knoten, ein interaktives Highlighting der Knotenbeziehungen. Befindet sich der Mauscursor über einem Big Rectangle, so wird dessen aktuelle Position auf diesem fo- kussiert. Unter dem zu betrachtenden Pixel liegen jedoch zumeist mehrere Knoten, so dass der Fokus selbst approximiert werden muss. Das heißt, wird eine Pixelstelle auf ei- nem Big Rectangle fokussiert muss zunächst errechnet werden, welche Knoten sich unge- fähr unter dieser Mausposition befinden. Aus dieser Knotenmenge wird im Anschluss ein Knoten ermittelt, dessen Teilbaum am tiefsten in den Baum ragt. Stellvertretend für die anderen an dieser Pixelposition befindlichen Knoten werden dessen Knotenbeziehungen eingeblendet, da dieser Knoten als potentiell interessantester Knoten in der fokussierten Knotenmenge ausgemacht wurde.
Abbildung 16:Kontextänderung Tree View
Abbildung 16 zeigt am Beispiel des 111MB.xml Dokuments, wie die sich eine Kontex- tänderung mittels einer fokussierte Knotenmenge eines Big Rectangles auswirkt. Dabei wird zudem ersichtlich, welche Knoten unterhalb der fokussierten Stelle zusammenge- fasst wurden.
Im linken Bild ist zu sehen wie mittels des Mauscursors eine Knotenmenge auf Level 4 des Baumes fokussiert wurde. Die Knotenbeziehungen dieser fokussierten Stelle sind ein- geblendet, beziehungsweise die Verbindungen des Stellvertreterknotens der fokussierten Treffermenge. Ein Einfachklick auf diese Stelle markiert diese und zeigt die Anzahl der getroffenen Knoten in der BaseX GUI an5. In diesem Fall wurde eine Treffermenge von 50 Knoten ausgemacht. Durch einen Doppelklick auf die fokussierte/markierte Stelle, wird ein neuer Kontext mit der entsprechenden Knotenmenge abgebildet. Dieser neue Kon- text ist auf dem rechten Bild zu sehen. Es werden die 50 Einzelbäume der Treffermenge nebeneinander gezeichnet und lassen sich weiter so inspizieren. In dieser Ansicht ließen sich im Weiteren die für den Nutzer interessanten Teilbäume filtern und entsprechend anzeigen.
5Aus Platzgründen nicht auf dem Bild zu sehen
Beurteilung
Für die Visualisierung eines Baumes bringen die Big Rectangles den großen Vorteil, dass der abgebildete Baum nie über den zur Verfügung stehenden Fensterbereich hinaus wächst.
Somit sind keine Scrollbars notwendig, um den Gesamtbaum im Überblick zu behalten und zu betrachten. Zudem lässt sich hierdurch eine stufenlose Skalierung des Baumes implementieren.
Abbildung 17:Beispiel Skalierbarkeit der Tree View
Abbildung 17 zeigt ein Beispiel für die Skalierung der Tree View bei Veränderung der Fenstergröße des Zeichenbereichs. In allen 4 Screenshots ist das 114kb.xml Dokument in verschiedenen Fenstergrößen dargestellt. Wie auf dieser Abbildung zu erkennen ist, passt sich der Baum je nach zur Verfügung stehendem Platz an den Zeichenbereich an.
Ist es möglich einzelne Knoten abzutragen, werden diese gezeichnet, ansonsten folgt die Zusammenfassung entsprechender Levels zu Big Rectangles.
Ein Nachteil, der sich durch die Zusammenfassung von Levels zu Big Rectangles ergibt, ist jedoch, dass für einige XML-Dokumente die ausschließlich aus Levels mit vielen Kno- ten bestehen nur eine sehr grobe Übersicht über den Gesamtbaum dargestellt wird. Zwar lassen sich mittels des Highlightings der Nachfahrenverbindungen oder der Wahl eines lokalen Kontextes dennoch Informationen zu einzelnen Stellen des Gesamtbaumes ge- winnen, aber in der Übersicht ist auf den ersten Blick fast nur die Anzahl der Levels zu
erkennen.
Abbildung 18:Beispiel grobe Baumdarstellung durch Big Rectangles
Ein Beispiel für einen Baum, der in der Gesamtübersicht nur grob darstellt wird, findet sich in Abbildung 18. Beide Screenshots zeigen den Baum des factbook.xml Dokuments.
Links zu sehen ist die Darstellung des Baumes ohne Interaktion. Über die Levels 3 bis 7 und die Knoten darin lässt sich aus dieser Ansicht nur wenig erkennen. Um dennoch einige Informationen zu den Knoten auf diesen Levels zu erhalten, kann das Highlighting der Nachfahrenbeziehungen verwendet werden. Dies ist auf dem rechten Bild zu sehen.
Durch das fokussieren einer Knotenmenge auf dem Big Rectangle des 3. Levels wurde der Teilbaum eines Stellvertreterknotens der Treffermenge eingeblendet.
Insgesamt gesehen überwiegen die Vorteile des Einsatzes von Big Rectangles, da so zu jeder Zeit eine angepasste Darstellung an die zur Verfügung stehende Fenstergröße mög- lich ist. Die Big Rectangles sind daher fester Bestandteil der Tree View. Der Nachteil der groben Darstellung einiger Bäume kann in der BaseX GUI durch die Verwendung weite- rer Visualisierungen, wie beispielsweise in Kapitel 2.2 bei der Verwendung von Tree Map und Tree View gezeigt, aufgeweicht werden.
4 Performanz
Interaktive Visualisierungen müssen in Echtzeit auf Eingaben reagieren damit sie benutz- bar sind und den Anwender nicht frustrieren. Aus diesem Grund ist es eine wichtige An- forderung, möglichst effizient mit den zu Verfügung stehenden Ressourcen umzugehen und Flaschenhälse zu vermeiden. Ein XML-Datenbanksystem wie BaseX stellt dabei be- sonders hohe Anforderungen an eine Visulisierung. Es sollten sowohl kleine Dokumente im Kilobyte-Bereich, als auch Dokumente die tausende von Knoten umfassen und dabei mehrere hundert Megabyte im Speicher einnehmen, darstellbar sein.
Im folgenden Kapitel werden Methoden vorgestellt, mit denen sich eine Performanzstei- gerung für die Tree View erzielen lies.
4.1 Einlesen der Level-Knotenmatrix
BaseX verwendet intern ein PRE/SIZE/DIST-Mapping zur Speicherung von eingelesenen XML-Dateien. Aus diesen Werten lässt sich jedoch nicht direkt die Zugehörigkeit eines Knotens zu einem bestimmten Level und die Positionen innerhalb dessen ermitteln. Für den in Kapitel 3.1.3 besprochenen Weg der Rekonstruktion des Baumes ist es jedoch erforderlich eine entsprechende Zuordnung vorzunehmen. Hierzu dient die sogenannte Level-Knotenmatrix. In dieser werden für jeden Level die darin vorkommenden Knoten abgelegt.
Abbildung 19:Zusammenhang zwischen Baum und Level-Knotenmatrix (PRE-Werte in rot)
Abbildung 19 zeigt die Veranschaulichung einer Level-Knotenmatrix, beziehungsweise deren Bezug zu einem gegebenen XML-Baum. Abgebildet ist auf der linken Seite der Baum des index.xml-Dokuments mit den PRE-Werten der einzelnen Knoten in rot und auf der rechten Seite die sich aus dem Dokument ergebende Level-Knotenmatrix.
Im Folgenden werden zwei unterschiedliche Herangehensweisen zur Erstellung einer Level-Knotenmatrix besprochen und danach gegeneinander abgewogen. Der erste Ansatz geht zunächst in die Breite des Baumes bevor tiefere Ebenen betrachtet werden, während das zweite Verfahren zuerst in die Tiefe geht und erst im Nachhinein die Breite erfasst.
Beide Ansätze speichern das Ergebnis der Berechnung in einer globalen Level-Knotenmatrix-
Liste. Diese globale Level-Knotenmatrix-Liste besteht aus zwei verschachtelten Listen.
Die erste Dimension ist eine Liste, welche die Anzahl der Levels repräsentiert. Auf jede in dieser Liste enthaltenen Indexposition folgt eine weitere Liste mit denPRE-Werten des entsprechenden Levels. Die Indexposition gibt implizit den Level der Knoten an, welche sich auf der angehängten Liste befinden. Die Knoten jedes Levels sind geordnet nach ih- rem Vorkommen im Baum, das heißt, falls sich mehr als ein Knoten auf demselben Level befinden muss gelten:PRE(Kn)<PRE(Kn+1).
4.1.1 Ansatz 1 - Breite zuerst
Dieser Ansatz verwendet die Vater-Kinder Beziehungen der einzelnen Knoten, um die Levelzugehörigkeit der im Dokument enthaltenen Knoten zu ermitteln. Es werden suk- zessive, vom Wurzelknoten an bis zur tiefsten Ebene, die Kinder der Knoten des jeweils fokussierten Levels ermittelt und dem nächsthöheren Level zugeordnet. Zu Beginn wird vom Wurzelknoten ausgegangen, dieser dient als erster Vater und wird dem ersten Level zugewiesen. Von diesem Vaterknoten ausgehend werden, sollten entsprechend Nachkom- men vorhanden sein, im nächsten Schritt alle Kindknoten erfasst und ein Level über dem Vaterknoten eingeordnet. Ist dieser Schritt abgeschlossen, wird der betrachtete Level um 1 inkrementiert und alle vorher als Kinder des Wurzelknotens diesem Level zugeordneten Knoten dienen nun als Väterknoten. Diese Väterknoten werden einzeln in ihrer Reihen- folge betrachtet und wie zuvor beim Wurzelknoten, jeweils deren Kinder ermittelt und in Relation zu ihren Vätern, eine Ebene höher zugeordnet. Diese Verfahrensweise wie- derholt sich bis zu einem Level auf dem keine Kinder mehr gefunden werden und somit die tiefste Stelle des Baumes erreicht wurde.
Algorithmus Ansatz 1
Algorithm 7generateLevelNodeMatrix1(r oot: Integer) l vl:=0
LIST[l vl].add(r oot) repeat
for all par elements ofLIST[l vl] do size:=par+par.size()
pr e:=par+1 while pr e<size do
LIST[l vl+1].add(pr e) pr e:=pr e+pr e.size() end while
end for l vl:=l vl+1
untilLIST[l vl].size()==0
Der Algorithmus zu Ansatz 1 benötigt zunächst denPRE-Wert des Wurzelknotens (r oot) als Ausgangsparameter. Im ersten Schritt wird der fokussierte Level (l vl) auf 0(den ers- ten Level) gesetzt und derPRE-Wert des Wurzelknotens in die Level-Knotenmatrix-Liste
