Interaktive Diagramme mit Oracle XDK und SVG

Interaktive Diagramme mit Oracle XDK und SVG
Florian Werner
Universität Tübingen, Lehrstuhl Wirtschaftsinformatik
Abstract
According to the Information Visualization Reference Model [4] there are three separate steps
when generating a diagram: filtering, mapping and rendering. Each step has its own characteristics and demands. The paper shows how the Scalable Vector Graphics (SVG), a W3C standard for 2D-vector graphics, and the Oracle XML Developer’s Kit (XDK), a XML web development framework, can be used to meet the requirements of dynamic and interactive diagrams on the web. It discusses some principal design decisions like the architecture and the
employment of the mentioned technologies for the different steps of the visualization process.
Thereby it explains the potential of both technologies and gives a categorization of diagrams
and diagram elements which is crucial to the programmatic construction of a diagram. It promotes a modular approach to foster the flexibility of a visualization application. The evaluation by the implementation of two basically different prototypes gains useful insights for future improvements.
Keywords
Information Visualization, Business Intelligence (BI), Chart, Diagram, SVG, XML, XSLT,
XDK, XSQL, Servlet, Rich Internet Applications (RIA)
„Visualization can be seen as the intersection of user interface design, graphics, and databases“ (Tang/Stolte/Bosch 2003)
Einleitung
Ein wesentlicher Faktor für das erfolgreiche Agieren von Unternehmen am Markt ist die
zeitadäquate Versorgung der Führungskräfte mit Informationen. Entsprechend wird die Entscheidungsfindung im Unternehmen heutzutage durch umfangreiche Lösungen der Business
Intelligence (BI) unterstützt. Dabei werden die Informationen nicht nur rein numerisch in
Kreuztabellen dargestellt, sondern zur schnellen, intuitiven Erfassung von Datenmustern auch
visualisiert. In der Regel geschieht dies durch klassische Diagrammformen wie Säulen-, Linien- oder Tortendiagramme.
1
Neben generischen Anforderungen, z. B. der dynamischen Generierung der Diagramme
aus operativen Daten und der interaktiven Einflussnahme des Benutzers auf die Visualisierung während der Datenanalyse, ergibt sich oftmals der Bedarf an einer unternehmensspezifischen, flexiblen und einfach zu implementierenden BI-Lösung. Dies gilt insbesondere für
Kleine und Mittelständische Unternehmen (KMU), die eine Marktnische mit spezialisierten
Produkten ausfüllen. Es stellt sich die Frage nach einem für dieses Szenario geeigneten Ansatz.
Die Stärke umfassender BI-Produkte liegt in der Verarbeitung von heterogenen Massendaten und dem Angebot effizienter Datenintegrations- und Analyse-Werkzeuge. Sie bringen
erhebliche Implementierungskosten mit sich und sind in Grenzen flexibel. Für spezifische,
lokal begrenzte Informationsbedarfe sind derartige Applikationen daher nicht geeignet. Dies
gilt ebenso für „kleine“ BI-Produkte, sofern Diagrammdefinitionen einem Benutzerkreis zugänglich gemacht werden sollen, der über die einzelne Führungskraft hinaus geht. Hier mangelt es neben der Flexibilität an der Verteilbarkeit.
Oracle bietet mit dem XML Developer’s Kit (XDK) [1] eine einfache und flexible Lösung
an, welche in Verbindung mit dem Extensible Markup Language (XML)-basierten 2DVektorformat Scalable Vector Graphics (SVG) [2] die Anforderungen an individuelle Diagramme erfüllen kann. Beim XDK werden relational oder im XML-Format in der Datenbank
vorliegende Daten zunächst in externe XML-Dokumente überführt und dann dynamisch bis
zum Ausgabeformat weiterverarbeitet. Die Bereitstellung der Präsentationsdokumente im
Web erfolgt über eine Servlet Engine. Durch integrierte Programmierschnittstellen (API) sowie die Verwendung etablierter Standards lässt sich eine zunächst schlank gehaltene Variante
sukzessive erweitern und zunehmend an die Gegebenheiten des Unternehmens anpassen.
Aus der Wahl der XML-Technologie als Verarbeitungs-Plattform ergeben sich Vorteile,
die an das XML-Format gekoppelt sind. Wichtigstes Merkmal von XML ist die Trennung von
Inhalt, Struktur und Präsentation. Jeder Aspekt kann in der Verarbeitungskette von XMLDokumenten gezielt gesteuert werden. Die Möglichkeit der flexiblen Transformation lässt
sich für die Generierung von Diagrammen effektiv nutzen: Während Inhalts- und Strukturtransformation dazu dienen, Daten zu integrieren, übernimmt das Zielformat SVG die Rolle
der Präsentation bzw. der grafischen Benutzerschnittstelle. Prinzipiell wären auch andere
Ausgabeformate als SVG, z. B. die Hypertext Markup Language (HTML) denkbar. Es existieren aber gute Gründe für seinen Einsatz: SVG wurde gezielt für die Darstellung grafisch
ansprechender und benutzerfreundlicher Webapplikationen entwickelt. Daher bietet es neben
der reinen Erzeugung zweidimensionaler Vektorgrafik auch die Möglichkeit, einzelne Bestandteile der Grafik durch Interaktion oder Animation zu beeinflussen oder mit anderen medialen Inhalten zu kombinieren. Auf diese Weise können anspruchsvolle Web-Applikationen
(sog. Rich Internet Applications – RIA) im Browser geschaffen werden.
Die bei der XML-Technologie bestehende Trennung in Inhalt, Struktur und Präsentation
sowie die Verbindung einzelner XML-Dokumente durch Transformationen weist offensichtliche Parallelen zum allgemeinen Prozess der Informationsvisualisierung auf: Bei diesem werden zunächst Daten in eine gewünschte Struktur gebracht, dann auf grafische Objekte abgebildet und schließlich als Diagramm dargestellt. Auch aus diesem Blickwinkel bietet sich
demnach die Verwendung von XML an, insbesondere auch deshalb, da durch die Entkopplung der Aspekte Datenfilterung, grafisches Mapping und Präsentation Einfluss auf jeden
Transformationspunkt des Prozesses durch den Benutzer genommen werden kann. Dies geschieht über die genannte Interaktionsmöglichkeit von SVG.
2
Im Hinblick auf Diagramme lässt sich die Funktionalität des XDK sehr effektiv einsetzen, um eine flexible, modulare Visualisierungs-Architektur zu realisieren, die Funktionalität
von SVG, um Diagramme mit benutzerfreundlicher Interaktivität anzureichern. Auf diese
beiden Aspekte wird im Folgenden vorrangig eingegangen.
Informationsvisualisierung
Die Erkenntnisse der Wahrnehmungspsychologie zeigen, dass Menschen numerische Informationen wesentlich schneller verarbeiten können, wenn sie grafisch aufbereitet sind. Die
intuitivere Erfassung gegenüber der tabellarisch-numerischen Form lässt sich gut an einem
sog. Mosaikplot nachvollziehen, das die Verteilung der Passagiere auf der Titanic hinsichtlich
Klasse, Geschlecht und Überleben zeigt (Tab. und Abb. 1). Es lassen sich die Mengenverhältnisse durch die Flächen des Diagramms auf einen Blick erfassen, wohingegen die numerische
Darstellung intensiveres Studium erfordert.
Überlebt
Klasse
Geschlecht
Nein
Ja
1
Männlich
118
62
Weiblich
4
141
2
Männlich
154
25
Weiblich
13
93
Männlich
422
88
Weiblich
106
90
Männlich
670
192
Weiblich
3
20
3
Besatzung
Tab. 1 / Abb. 1: Passagiere der Titanic: Tabellarisch und als Mosaikplot
Wissenschaft und Wirtschaft besitzen große Datenaufkommen. Hier werden Diagramme
zur Visualisierung komplexer Informationszusammenhänge (auch als „Datenmuster“ bezeichnet) in unterschiedlichsten Zusammenhängen benötigt. Entsprechend hat sich die Informationsvisualisierung (Information Visualization) als ein eigenes, interdisziplinäres Forschungsgebiet etabliert, das die Erforschung der optimalen Form der grafischen Repräsentation von Massendaten sowie der benötigten Vorstufen zum Ziel hat. Es besitzt im Bereich der
Informatik starke Berührung zu den Gebieten Datenbanken und Human Computer Interaction
(HCI). Zum einen geht es hier um die effiziente Datenhaltung und -harmonisierung, zum anderen um die aufgaben- und benutzergerechte Gestaltung der Benutzerschnittstelle, die dem
Benutzer die Wahrnehmung und Analyse der Daten ermöglichen soll. Letztlich dienen alle
involvierten Forschungsdisziplinen – zu nennen wären ebenso die Statistik, die Kognitionswissenschaft, die Soziologie und das Grafikdesign [3] – dem Ziel, den Benutzer optimal bei
der Erfassung und Auswertung der Daten in seinem fachlichen Kontext zu unterstützen. Dies
ist stets in Erinnerung zu behalten, um eine Verselbstständigung einzelner Bereiche zu vermeiden, d. h. etwa das Analysewerkzeug mit technischer Funktionalität oder grafischen Effekten zu überfrachten, was der Gebrauchstauglichkeit (Usability) entgegenwirken könnte.
3
Der Prozess der Informationsvisualisierung
Der Prozess der Informationsvisualisierung, auch als Information Visualization Reference
Model [4] bekannt, beschreibt die elementaren Schritte, die bei jeder Visualisierung zu durchlaufen sind (Abb. 2).
Abb. 2: Prozess der Informationsvisualisierung
Der Prozess lässt sich grob in die Phasen Filtering, Mapping und Rendering unterteilen,
d. h. jene Transformationsschritte, welche die Quelldaten zunächst in die für die Analyse geeignete Struktur bringen, sie daraufhin in grafische Objekte überführen und schließlich dem
Benutzer in Form eines Diagramms zur Ansicht bringen. Im Bereich Datenbanken wird der
erste Teilprozess (Filtering) differenzierter beschrieben und ist dort als ExtractionTransformation-Loading (ETL)-Prozess bekannt.
Für die Umsetzung der einzelnen Transformationsschritte stellt sich die Frage, bei welchem Schritt welche Technologie zum Einsatz gelangen soll. Dabei sind sowohl technologische als auch architektonische Alternativen denkbar. So könnte das Filtering, also die Datentransformation sowohl in der Datenbank als auch außerhalb erfolgen. Das Gesamtsystem
könnte entsprechend der Transformationsschritte modularisiert werden, es könnten Mappingund Rendering-Schritt zusammengefasst werden oder jeder Teilschritt (insbesondere das Filtering) sogar in mehrere Module separiert werden. Aus technologischer Sicht wäre zu überlegen, welche Technologie neben der Datenbank effizient Aggregationen und Strukturtransformationen realisieren kann oder welche Rendering Engine in der Lage ist, eine Vielzahl an
grafischen Primitiven schnell darzustellen. Alle Entscheidungen hängen letztlich vom Anwendungsszenario der Nutzung ab, d. h. von Parametern wie dem Umfang der Daten, der Integrationsebene der Quellsysteme, der Komplexität statistischer Berechnungen, der gewünschten grafischen Repräsentation oder den Interaktionswünschen des Benutzers bei der
Analyse.
Ausgehend von dem zu Beginn beschriebenen Szenario und seinen Implikationen (KMU;
flexible, individuelle Diagramme; Applikation mittlerer Größe; mehrere Benutzer; keine
übermäßig komplexen Auswertungen; einfache Programmierung) bietet sich für die Basisarchitektur ein 3-Tier-Modell parallel zu den Transformationsschritten des Visualisierungsprozesses an. Dadurch wird eine prinzipielle Trennung zwischen Datenhaltung, logischer
Weiterverarbeitung inklusive Mapping sowie der Präsentationsebene erreicht, was der Applikation Flexibilität in wesentlichen Punkten verleiht. So könnten ggf. im Middletier weitere
XML-Datenquellen integriert oder die Ausgabe auf unterschiedliche Endgeräte erweitert werden.
Für eine Technologieentscheidung zugunsten von Datenbank, XML und SVG sprechen
Gründe, die sich an den Stärken der jeweiligen Technologie orientieren:
Die Datenbank-Technologie ist eine etablierte Technologie, mit der jahrzehntelange Erfahrungen existieren. Auch in einem kleinen Unternehmen bzw. Einsatzradius der Applikation liegt i. d. R. entsprechendes Know-how vor. In puncto Datenverarbeitung im Wortsinn
kann man von bewährter und zuverlässiger Funktionalität ausgehen. Für die Transformation
4
von Daten in andere Objekte, in diesem Fall in eine visuelle Abstraktion (Mapping), und das
Rendering ist eine Datenbank dagegen nicht ausgelegt. Idealerweise wird also das Filtering,
d. h. die Aufbereitung der Daten innerhalb der Datenbank durchgeführt, da hier komplexe
Datenmanipulationen und -aggregationen möglich sind. Da Diagramme oftmals einen Zeitbezug aufweisen, lassen sich z. B. komplexe Datumsfunktionen nutzen, die andernfalls aufwändig zu programmieren wären. Zudem bietet sich neben herkömmlichen SQL-Operationen
z. B. die Nutzung der im SQL 2003-Standard umgesetzten und von Oracle unterstützten BIFunktionen an.
Eine ideale Möglichkeit, einem breiteren Benutzerkreis Diagramme bereit zu stellen, sind
Web-Technologien. An Stelle der aufwändigen und fehlerbehafteten Verteilung von spezieller
Client-Software kann als Client ein Browser genutzt werden, der heutzutage auf nahezu jedem PC zur Verfügung steht. Neben diesem Vorteil erwirbt man weitere Benefits: Sofern die
Lösung über das firmeneigene Intranet hinaus geht, ist Ortsunabhängigkeit gegeben, zudem
sind Browser mittlerweile auf unterschiedlichsten Endgeräten implementiert. Noch unabhängig von SVG betrachtet, wird bei Wahl dieser Alternative der Browser für das Rendering
zuständig sein, ggf. durch Unterstützung von Plug-ins, die i. d. R. zur Verfügung stehen und
nicht selbst zu entwickeln sind.
Für das Mapping schließlich stellt sich die Frage, welche Technologie die Überführung
von Datenstrukturen in grafische Objekte umsetzen kann und welcher Art das Grafikformat
sein soll, das dem Browser zum Rendern übergeben wird. Die XML-Familie, d. h. die Standards, die aus der XML Activity des World Wide Web Consortium (W3C) hervorgegangen
sind, wurden mit dem Ziel geschaffen, eine einfache Möglichkeit für den Transport und die
Verarbeitung von Informationen im Internet zu realisieren. Zugleich sollte die Präsentationsbeschreibung (z. B. die Textfarbe und -größe) vom eigentlichen Informationsgehalt entkoppelt sein, um die Informationen neben dem Menschen (der im World Wide Web – WWW
schon immer als Empfänger galt) auch durch Maschinen verarbeitbar und semantisch interpretierbar zu machen.1 In puncto Know-how liegen mit XML ebenfalls zunehmend Erfahrungen in KMU vor, oftmals bedingt durch die Rolle als Zulieferer von Großunternehmen, welche XML als Format für den Informationsaustausch (Lagerbestand, Produktkatalog etc.) einfordern. Ein mögliches XML-Dokument ist in Codebsp. 1 abgebildet.
<?xml version = '1.0'?>
<Projektgruppe Bereich="Vertrieb">
<Projektleiter>Erich Weber</Projektleiter>
<Projektmitarbeiter> Markus Merz</Projektmitarbeiter>
<Projektmitarbeiter> Max Claasen</Projektmitarbeiter>
</Projektgruppe>
Codebsp. 1: XML-Dokument
Die Entkopplung von Daten und Präsentation verleiht XML große Flexibilität, da in
XML vorliegende Daten für unterschiedliche Ausgabeformate wiederverwendet werden kön1
Letzteres wurde durch die Anreicherung mit Datenauszeichnungen (den sog. Tags) erreicht. Auf diese Weise
liegt in einem XML-Dokument stets eine Beschreibung des Inhalts in Form von Metadaten vor. Ein Umstand der
sich bei der Diagrammgenerierung sehr positiv bemerkbar macht, wie noch zu sehen sein wird.
5
nen. Neben dem Transport und der Weiterverarbeitung ist bei XML grundsätzlich die Überführung in ein Präsentationsformat (analog zu HTML) vorgesehen. Da es sich bei Diagrammen in den meisten Fällen um zweidimensionale Grafik handelt, sollte hier ein Präsentationsformat verwendet werden, das 2D-Grafik darstellen kann und aus XML generierbar ist. Dieser
Forderung genügt das XML-Derivat SVG, das je nach Browser entweder nativ oder mit Hilfe
eines Plug-ins gerendert werden kann. Ein SVG-Dokument, das die Daten des XML-Beispiels
verwendet, ist in Codebsp. 2 dargestellt. Abb. 3 zeigt das gerenderte Resultat.
<?xml version = '1.0'?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20001102//EN"
"http://www.w3.org/TR/2000/CR-SVG-20001102/DTD/svg-20001102.dtd">
<svg xmlns="http://www.w3.org/2000/svg" width="500" height="500">
<circle cx="250" cy="250" r="200" fill="none" stroke="red"/>
<text x="50" y="75" font-size="50">Erich Weber</text>
<text x="200" y="150" font-size="70">Markus Merz</text>
<text x="200" y="350" font-size="70">Max Claasen</text>
</svg>
Codebsp. 2: SVG-Dokument
Abb. 3: Gerendertes SVG-Dokument
Für das Mapping der Daten auf die in SVG spezifizierten grafischen Elemente sind
schließlich die Extensible Stylesheet Language Transformations (XSLT) als Mitglied der
XML-Familie prädestiniert, da hierbei die aus XML-Knoten bestehenden Datensätze sequenziell geparst und durch grafische Elemente ersetzt bzw. damit kombiniert werden können. Die
Ausgabe einer XSLT ergibt stets ein XML-konformes Dokument, in unserem Fall ist dies
SVG. Das folgende Codebsp. 3 zeigt die Transformationsanweisungen, um das XMLAusgangsdokument (Codebps. 1) in das SVG-Dokument des obigen Beispiels (Codebsp. 2)
zu überführen:
6
<?xml version = '1.0'?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output
doctype-public="-//W3C//DTD SVG 20001102//EN"
doctype-system="http://www.w3.org/TR/2000/CR-SVG20001102/DTD/svg-20001102.dtd"
media-type="image/svg+xml"
method="xml" />
<xsl:template match="/">
<svg xmlns="http://www.w3.org/2000/svg" width="500" height="500">
<circle cx="250" cy="250" r="200" fill="none" stroke="red"/>
<text x="50" y="75" font-size="50">
<xsl:value-of select="Projektgruppe/Projektleiter"/>
</text>
<text x="200" y="150" font-size="70">
<xsl:value-of select="Projektgruppe/Projektmitarbeiter[1]"/>
</text>
<text x="200" y="350" font-size="70">
<xsl:value-of select="Projektgruppe/Projektmitarbeiter[2]"/>
</text>
</svg>
</xsl:template>
</xsl:stylesheet>
Codebsp. 3: XSLT-Dokument zurTransformation in SVG
Es bleibt zu klären, wie die Datenbereitstellung in XML-Form zu bewerkstelligen ist. Sofern eine Datenbank eingesetzt wird, die das XML-Format nativ unterstützt, werden XMLDokumente über unterschiedliche Schnittstellen direkt extern bereit gestellt. Andernfalls wäre
das XML-Format aus relationalen Strukturen zu erzeugen – in dieser Form werden die Daten
in kleineren Szenarien i. d. R. vorliegen. Gängige Datenbanken stellen dafür Adapter zur Verfügung. Die folgende Abbildung veranschaulicht Basisarchitektur und eingesetzte Technologien einschließlich der durch die Transformationen erzeugten Dokumente in Verbindung mit
dem Visualisierungsprozess (Abb. 4):
Abb.4: Visualisierungsprozess mit eingesetzten Technologien
Für das genannte Szenario sind im Rahmen der Architektur- und Technologieentscheidung freilich Alternativen denkbar: So ließe sich das Filtering prinzipiell auch im Middletier,
d. h. mit Hilfe von XSLT realisieren. Hierbei können neben der Strukturtransformation (der
Umordnung und inhaltlichen Manipulation der Knoten) Aggregat-Funktionen bei der Zu-
7
sammenführung genutzt werden. Diese stehen allerdings in XSLT 1.0/XPath 1.0 nur rudimentär zur Verfügung. XSLT 2.0/XPath 2.0 kennen dagegen mächtige Aggregat- und CastingFunktionen, jedoch wird hiermit die Performanz einer Datenbank nicht erreicht werden. Nur
in begründeten Fällen sollten also Daten erst auf der Ebene der externen XML-Dokumente
zusammengeführt werden, da die Verarbeitung derzeit nicht so komfortabel und effizient wie
in der Datenbank geschieht. Diese Variante wäre insbesondere dann vorstellbar, falls die
Daten aus unterschiedlichen Quellen stammen und keine Integration auf der Persistenzschicht
erfolgen kann. Sofern Datenquellen mit unterschiedlicher Transformationsfunktionalität eingebunden werden, kann eine Integration im Middletier indes denselben, wenn auch auf XSLT
reduzierten Umfang für alle Daten ermöglichen. [3]
Als Ort der Mapping-Transformation ließe sich alternativ der Browser wählen, sofern er
eine eigene XSLT Engine besitzt. Auf diese Weise könnte der Server entlastet werden, der die
XML-Dokumente ausliefert. Allerdings fallen die Ergebnisse der Transformation – trotz
Standardisierung – unterschiedlich aus, je nachdem in welchem Umfang und auf welche Weise die Implementierung der XSLT Engine erfolgt ist. Im Extremfall wird die Transformation
mit einem Fehler abgebrochen, sodass der Benutzer keine Visualisierung zu Gesicht bekommt. Der nicht kontrollierbaren Transformation im Browser ist daher bei der Generierung
von Diagrammen mit SVG, das gegenüber HTML ein vergleichsweise junges Format darstellt, eine Server-basierte Variante vorzuziehen.
Mittlerweile ist XML als Technologie-Bündel zu betrachten, da die Kernstandards um
eine Vielzahl weiterer XML-Spezifikationen und unterstützende Software ergänzt wurden. Es
liegt ein Portfolio an Komponenten vor, das den Entwicklungsaufwand für eine XMLApplikation erheblich reduziert und die Technologie auch für kleinere Projekte interessant
macht. Als Framework, das eine Basis für XML-Applikationen bietet, ist das XML Developer’s Kit (XDK) von Oracle zu verstehen. Es lässt sich für die vorgestellte Architektur ideal
einsetzen. Neben den üblichen Verarbeitungsmöglichkeiten von XML stellt es als ein proprietäres Spezifikum einen Adapter zur Verfügung, der aus relationalen Strukturen XMLDokumente erzeugt. Dies kann für jede Datenbank erfolgen, die über die Java Database Connectivity (JDBC) ansprechbar ist. Die SQL-Anweisungen zur Selektion und Manipulation von
Daten werden dabei XML-Standard-konform in XML-Dokumente integriert. Somit lässt sich
unter Einbeziehung von Datenbank und Browser mit dem Framework als Bindeglied der gesamte Visualisierungsprozess programmatisch unterstützen.
Bevor die Visualisierungs-Lösung näher erörtert wird, sollen die Merkmale und Potenziale der genannten Technologien – XML, SVG und XDK – kurz skizziert werden.
XML und SVG
Zur zeitlichen Einordnung der Standards der XML-Familie soll folgender Zeitstrahl
(Abb. 5) dienen; XML hat sich durch Anpassung der Funktionalität aus der Standard Generalized Markup Language (SGML) entwickelt, einer Metasprache zur Definition von Auszeichnungselementen für Textdokumente. Sie wurde als zu komplex und zugleich als zu beschränkt für viele Anwendungen im Web empfunden.
8
Abb.5: W3C-XML-Standards im Zeitverlauf
Das vom W3C ins Leben gerufene XML existiert mittlerweile seit 10 Jahren und hat sich
als Industriestandard, insbesondere für die Integration von Systemen und dem damit verbundenen Datenaustausch über das Web etabliert. Besonders die Trennung zwischen Inhalt,
Struktur und Präsentation verleiht XML große Flexibilität. Der raschen Verbreitung waren
außerdem folgende Eigenschaften zuträglich, die sich ebenso positiv für das XML-Derivat
SVG auswirken und neben dem bereits Genannten für den Einsatz beider Formate auch aus
ökonomischer Sicht sprechen:
•
•
•
•
•
nicht-proprietärer, offener Standard
keine Lizenzkosten
plattformunabhängig
selbstbeschreibend
einfache Struktur
•
•
•
•
•
verifizierbar (Syntax)
validierbar (Semantik)
kombinierbar (Namensräume)
erweiterbar
einfach programmatisch verarbeitbar
Gerade bei der Erzeugung von Diagrammen können diese Eigenschaften sehr gut ausgenutzt werden, da es sich um die schrittweise Überführung von Daten in numerische, textuelle
und grafische Elemente handelt. Zudem können durch die Modularisierung der Aspekte Inhalt, Struktur und Präsentation damit einhergehende fachliche Tätigkeiten, die unterschiedliche Anforderung an das Know-how des Entwicklers stellen, im Entwicklungsprozess effizient
verteilt werden.
Für SVG lassen sich weitere positive Eigenschaften anführen, die sich für die Gestaltung
von Diagrammen anbieten:
•
•
•
•
•
Hohe Abbildungsqualität (Vektorformat)
Entkoppelung des Erscheinungsbilds vom Layout (Cascading Style Sheets – CSS)
Textelemente extrahierbar, d. h. auch durchsuchbar
Animation (Synchronized Multimedia Integration Language – SMIL)
Interaktion (ECMAScript bzw. JavaScript)2
In Verbindung mit weiteren Dokumentenformaten der sog. XML-Familie ist – wie schon
ausgeführt – eine Verarbeitung von Daten, die in XML-Dokumenten enthalten sind, und deren Transformation in unterschiedliche Strukturen und Zielformate möglich. Eine wichtige
Funktion nimmt dabei die Extensible Stylesheet Language (XSL) ein, welche dazu dient, ein
in der XML-Syntax vorliegendes Ausgangsdokument in ein Zieldokument zu transformieren.
Genaugenommen besteht XSL aus zwei Spezifikationen: XSLT und XSL Formatting Objects
(XSL-FO). Letztere widmet sich der Druckausgabe von XML-Dokumenten. Als Ergebnis
können so aus einer XSL-Transformation HTML- oder WML-Dokumente entstehen, über
2
Bei ECMA-Script handelt es sich um den Sprachkern von JavaScript, der durch die European Computer Manufacturers Association (ECMA) 1998 als Standard definiert wurde. Der konkrete JavaScript-Umfang unterscheidet sich gegenüber ECMAScript je nach verwendetem Browser.
9
XML-FO als Zwischenschritt PDF-Dateien erzeugt werden oder es kann eine Umwandlung in
ein Grafikformat wie SVG erfolgen.
Schließlich ist eine dritte Dokumentenart der XML-Familie im Transformationsprozess
von Belang: Damit festgelegt werden kann, welche konkreten Objekte (also Elemente und
Attribute) in einem Dokument vorkommen dürfen, existiert XML Schema. Durch ein XML
Schema-Dokument lässt sich über die Existenz von Elementen und Attributen zudem ihre
Strukturierung, d. h. die Reihenfolge oder ihr Wertebereich erzwingen. Neben der syntaktischen Korrektheit lässt sich also auch in Grenzen eine semantische Überprüfung durchführen.
Dies trägt stark zur Einschränkung von Fehlern in längeren Transformationsketten bei, da sich
auch Zwischenergebnisse validieren lassen.
SVG kennt abgesehen von üblichen geometrischen Primitiven (Rechteck, Kreis, Linie)
und einfacher Farbgebung (Linienfarbe, homogene Füllung) auch komplexe Elemente wie
Freihand-Zeichnungen, Farbverläufe und Filtereffekte, mit denen grafisch anspruchsvolle
Visualisierungen möglich sind. Neben den Diagrammtypen, die sich in Standardsoftware für
Informationsvisualisierung finden, können mit diesen Gestaltungsmitteln auch sehr individuelle Diagramme geschaffen werden, z. B. die Kombination aus CAD-Zeichnung und visualisierten Kennzahlen zur Überwachung des CAD-Objekts. Dabei ist die Einbindung des CADObjekts sowohl nativ in SVG oder als Rastergrafik (z. B. JPEG3 oder Portable Network Graphics – PNG) möglich. Neben der Referenz auf externe Ressourcen ist auch deren Einbettung
über das für XML-Dokumente übliche Base64-Encoding möglich.
Da SVG neben seinen grafischen Eigenschaften auch Interaktivität bietet, lässt es sich
über die Funktion als reines 2D-Format hinaus, d. h. der Zeichenfunktion, auch als Dialogebene der Benutzerschnittstelle verwenden. Dadurch ist mit SVG ein Graphical User Interface
(GUI) realisierbar. [5] Durch die Übernahme von Elementen aus dem Modul „Animation“
(2001) der Synchronized Multimedia Integration Language (SMIL) können zudem einfache
Animationen umgesetzt werden, die eine benutzerfreundliche Gestaltung ermöglichen.
Die Leistungsfähigkeit von SVG hängt wesentlich von der SVG-Version und -Variante
ab, die zum Einsatz gelangen soll. Unterschieden werden können derzeit die Versionen SVG
1.0 (als W3C-Recommendation im Jahr 2000 verabschiedet) und SVG 1.1 (2003). Version
1.2 durchlief seit 2002 mehrere Draft-Stadien (letzter Draft von 2005) und soll offiziell Anfang 2009 (reduzierte Variante) bzw. 2010 (voller Umfang) verabschiedet werden. Version
1.1 stellt eine Modularisierung von SVG 1.0 sowie eine Korrektur von Fehlern dar, definiert
aber keine wesentlich erweiterte Funktionalität. Für Version 1.1 (der volle Umfang wird als
SVG Full bezeichnet) existieren Untermengen der Spezifikation, die sich speziell an Mobilen
Endgeräten ausrichten (sie werden zusammen als SVG Mobile bezeichnet): Das Profil SVG
Basic (SVGB) ist für den Personal Digital Assistant (PDA) ausgelegt, wohingegen SVG Tiny
(SVGT) auf Elemente verzichtet, welche grafisch aufwändig realisiert werden, und auf Mobiltelefone abzielt.
Für interaktive Diagramme ist der Gestaltungsumfang der vollen Spezifikation elementar,
da sowohl anspruchsvolle grafische Objekte als auch eine benutzerfreundliche Interaktion
realisiert werden. Auch Animationen können – sofern sie sich in Grenzen halten – dazu beitragen, die Lesbarkeit eines Diagramms zu erhöhen. Um die Möglichkeiten der Spezifikation
ausschöpfen zu können, ist deren Unterstützung im Browser wichtig. Hier bietet der Adobe
3
JPEG steht für Joint Photographic Experts Group und ist ein Grafikformat, das aus den Aktivitäten dieses Gremiums hervorging. Es umfasst mehrere Standards.
10
SVG Viewer (ASV) in der Version 3.03 den größten Umfang. Er ist auf den Internet Explorer
ausgerichtet. Die Browser Firefox und Opera unterstützen SVG dagegen nativ und nähern
sich diesem Level der Unterstützung zunehmend an. Jedoch ist die Interaktivität und Animation in diesen Browsern derzeit noch stark eingeschränkt. Deshalb soll im Folgenden der ASV
als Rendering Plug-in vorausgesetzt werden. Sofern der Einsatz einfach gehaltener Diagramme vorgesehen ist, lässt sich der Kreis der unterstützenden Browser für eine Applikation entsprechend erweitern. [6]4
Auch zur Verwendung von SVG existieren Alternativen. Als prominentestes Beispiel lassen sich die proprietären, wenngleich im Web weit verbreiteten Formate Adobe Flash bzw.
der Nachfolger Flex nennen. Aus dem Hause Microsoft stammt als Pendant dazu seit jüngerer
Zeit das Produkt Silverlight. Insbesondere mit Flash liegen langjährige Erfahrungen vor und
es hat sich im Web breit etabliert. Mit der Funktionalität von Flash kann SVG nicht gleichziehen. So bleibt SVG hinter Flash in puncto Animationen und zeitlicher Synchronisation zurück, was sich allerdings mit der Version 1.2 ändern wird. Da Animation bei Diagrammen
eine untergeordnete Rolle spielt, fällt dieser Punkt nicht ins Gewicht. Die Unterstützung durch
eine Entwicklungsumgebung ist ein wesentlicherer Aspekt, bei dem Flash einen höheren Grad
aufweist. Da SVG in erster Linie ein Grafikformat ist, unterstützen immerhin gängige Zeichenprogramme wie Adobe Illustrator, Corel Draw oder das Open Source-Programm Inkscape die WYSIWYG-Erstellung. Dagegen sind der Zugriff auf die Browserumgebung bzw. den
DOM-Baum oder die deklarative Erstellung von Interaktion und Animation nicht gegeben.
Allerdings sprechen neben den oben erwähnten Punkten auch Gründe für den Einsatz von
SVG: Vor allem die mit XML realisierte Trennung von Inhalt, Struktur und Präsentation ermöglicht eine immense Flexibilität der Anwendungsarchitektur. Eine Erweiterbarkeit hin zu
mehrschichtigen Architekturen mit mehreren Transformationsschritten ist gegeben. Zudem
trägt die automatische Generierbarkeit von SVG zur Flexibilisierung bei; Vergleichbares ist
mit Flash nur sehr bedingt umsetzbar. Sollte die Plattform geändert werden, ist bei SVG davon auszugehen, dass weiterhin Parser existieren, die bereits formulierte XML- und XSLTDokumente verarbeiten können. Ebenso ermöglicht die XML-Konformität die Nutzung einer
Vielfalt an gängigen Web-Techniken, z. Β. Asynchronous JavaScript and XML (AJAX). Das
Scripting betreffend ist Flash dagegen an das proprietäre ActionScript gebunden. Auch die im
Web wichtige Linking-Funktionalität ist bei SVG weitaus mächtiger. Eine ähnliche Gegenüberstellung ergibt sich bei Silverlight, das mit Flex nahezu gleichziehen kann [7]. Zusammenfassend kann gesagt werden, dass SVG für das hier verfolgte Anwendungsszenario ideal
geeignet und momentan anderen Grafik- und Interaktionsformaten vorzuziehen ist, die zudem
für derartige, grafikintensive Applikationen ursprünglich nicht konzipiert wurden. Nur im
Falle von hochfunktionalen Web-Applikationen, d. h. einer „Fat RIA“ [8] wäre der Einsatz
von Flex oder Silverlight zu bedenken.
4
Ein großes Manko besteht darin, dass der ASV momentan nicht weiterentwickelt wird, was in der Übernahme
der Firma Macromedia durch Adobe und der Wahl von Flash/Flex als strategischer Web-Plattform begründet ist.
Die Preview der Version 6 ist die letzte veröffentlichte und inzwischen nicht mehr offiziell beziehbare Version.
Teilweise können hier JavaScript-Bibliotheken Abhilfe schaffen, die SVG über nativ im Browser implementierte
Formate – für den Internet Explorer wäre dies die von Microsoft propagierte Vector Markup Language (VML) –
emulieren (z. B. Dojo).
11
Oracle XDK und XSQL Publishing Framework
Neben der XML-Funktionalität innerhalb der Datenbank, unter dem Schlagwort XML
Database (XDB) eingeführt, bietet Oracle mit dem XDK auch eine umfangreiche Unterstützung der XML-Verarbeitung im Middletier an. Auf einfache Weise lassen sich damit relational in der Datenbank vorliegende Daten in externe XML-Dokumente überführen und flexibel
weiterverarbeiten. Das Extended Structured Query Language (XSQL) Publishing Framework
ist Teil des XDK und kombiniert getrennt nutzbare Bestandteile des XDK (XML Parser, XSL
Transformation Processor, XML SQL Utility …) zu einer Servlet-basierten XMLEntwicklungsplattform (Abb. 6). Oracle-spezifisch ist dabei das XML-Derivat XSQL, welches das Absetzen von SQL-Statements gegen die Datenbank ermöglicht und einem eigenen
XML-Namensraum angehört. Den Kern des Framework bildet der XSQL Page Processor, der
die Transformationsschritte steuert.
Durch die Unterteilung in XSQL und XSLT ist eine klare Trennung zwischen Datenabfrage und Transformation ins Zielformat gegeben, wie es der beschriebenen Basisarchitektur
entspricht. Mit geringem Entwicklungsaufwand lassen sich somit schnell Daten im Web publizieren, z. B. in Form von SVG-Diagrammen.
Abb. 6: Oracle XSQL Publishing Framework
Der Ablauf bei der Verarbeitung der XML-Dokumente sieht folgende Reihenfolge vor [9,
10, 11]:
n Der Browser sendet einen Request mit dem Unified Ressource Locator (URL), z. B.
http://www.myserver.de/myXSQLPage.xsql
des
angeforderten
XSQLDokuments an den Server, auf dem das XSQL Servlet ausgeführt wird. Der XSQL Page
Processor verarbeitet die XSQL-Seite, indem er sie parst und zentrale Elemente separat
behandelt: Er extrahiert das vom Element <xsql:query> umschlossene SQL-Statement
12
und übergibt es an die XML SQL Utility. Die Referenz auf das Stylesheet, mit dem die
von der Datenbank angeforderten Daten weiterverarbeitet werden sollen, wird ebenfalls
extrahiert und zwischengespeichert. Eine XSQL-Seite ist wie folgt strukturiert (Codebsp. 4):
<?xml version = '1.0'?>
<?xml-stylesheet type="text/xsl" href="myStylesheet.xsl" ?>
<page xmlns:xsql="urn:oracle-xsql" connection="myConn">
<xsql:query>
SELECT * FROM dept WHERE dname = 'ACCOUNTING'
</xsql:query>
</page>
Codebsp. 4: XML-Seite im Oracle-spezifischen XSQL-Format
o Im zweiten Schritt lädt die XML SQL Utility die selektierten Daten aus der Datenbank
und bringt sie in eine XML-konforme Struktur. Das Ergebnisdokument wird an den
XSQL Page Processor zurück geliefert. Die Ausgabe des XML-Dokuments sieht für obiges Beispiel per Default wie folgt aus (Codebsp. 5):
<?xml version = '1.0'?>
<?xml-stylesheet type="text/xsl" href="myStylesheet.xsl" ?>
<page xmlns:xsql="urn:oracle-xsql" connection="myConn">
<rowset>
<row num="1">
<deptno>10</deptno>
<dname>ACCOUNTING<dname>
<loc>NEW YORK<loc>
</row>
<rowset>
</page>
Codebsp. 5: XML-Seite der XML SQL Utility
In der Ausgabe ist im Beispiel die Referenz auf das Stylesheet notiert worden. Tatsächlich würde die XML-Seite mit den Daten nur dann im Browser zur Ansicht kommen, sofern die zweite Zeile mit <!-- foo --> auskommentiert würde. Die Möglichkeit, zunächst nur die reinen Daten in XML-Form im Browser zu betrachten, unterstützt den effizienten Test einzelner Entwicklungsschritte.
p Das XML-Dokument wird vom XSQL Page Processor gemeinsam mit dem zwischengespeicherten Verweis auf das XML Stylesheet an den XSLT Processor übergeben.
q Der XSLT Processor wandelt unter Verwendung der Transformationsanweisungen im
XSTL-Dokument (.xsl) das XML-Dokument in ein Zielformat um; in unserem Fall ist
dies SVG und liefert es an den XSQL Page Processor zurück. Dieser beantwortet den Re-
13
quest des Client, indem er das erzeugte SVG-Dokument über das XSQL Servlet an ihn
ausliefert.
Neben der gerade beschriebenen Standard-Funktionalität verfügt das XSQL Publishing
Framework über weitreichende Möglichkeiten der Konfiguration und Erweiterung. So ist
nicht nur die Selektion von Daten sondern prinzipiell jegliche Data Manipulation Language
(DML)-Operation möglich. Unter Verzicht auf die Mappingfunktion von relationalen Daten
auf die XML-Struktur kann die Verarbeitung auch unmittelbar auf XML-Ebene erfolgen.
D. h., es lassen sich bereits in der Datenbank in XML-Form (entweder nativ über den Datentyp XMLType oder eine CLOB-Spalte) vorliegende Daten direkt als XML-Dokument beziehen.
Ebenso kann der umgekehrte Weg gewählt werden, d. h. ein XML-Dokument in die Datenbank zurückgespeichert werden. Zudem lassen sich für die Ablaufumgebung in der Konfigurationsdatei XSQLConfig.xml differenzierte Caching- und Fetching-Parameter zur Optimierung der Performance einstellen. Der Connection Pool ist ebenfalls zu konfigurieren und die
Verbindungen zu unterschiedlichen Datenbanken können über Aliasnamen abstrahiert werden. Für spezielle Funktionalität erlaubt das Framework sowohl die Erweiterung auf Datenebene (XSQL) als auch auf Transformationsebene (XSLT). So ist es möglich für die XSQLDatei eigene Action Handler via <xsql:action handler="myActionHandler"> zu
implementieren, deren Verweis auf die jeweilige Java-Klasse ebenfalls in der XSQLConfig.xml notiert wird. Für XSLT können neben den bereits integrierten Serializern eigene
Serializer über die Anweisung <?xml-stylesheet serializer="mySerializer"?>
referenziert werden, die sowohl unter Verzicht auf ein Stylesheet als auch nach der Transformation zum Einsatz kommen können. Die über 500 Seiten umfassende Dokumentation des
XDK beschreibt detailliert weitere Möglichkeiten, wie das Framework bestimmten Anforderungen gerecht werden kann, z. B. den Aufruf aus Java Server Pages (JSP), von der Kommandozeile oder über ein Java-Advanced Programming Interface (API) [9].
Ein großer Vorteil bei der Entwicklung mit dem XSQL Publishing Framework ist die
Unterstützung des XDK durch das von Oracle stammende, frei verfügbare Integrated Development Environment (IDE) JDeveloper. Über dieses Entwicklungswerkzeug lässt sich der
komplette Transformationsprozess (d. h. von der Datenextraktion bis zur Visualisierung im
Browser) abbilden und über die integrierte Servlet Engine sofort testen. Da eine Neukompilation der XML-Dateien nicht erforderlich ist, sind Veränderungen am XML-Quellcode ohne
Neustart des Servlets sofort sichtbar, was den Entwicklungsprozess deutlich beschleunigt. Als
Production Release ist momentan die Version 10.1.3.4 des JDeveloper verfügbar, die das
XDK 10.1.3.3 enthält.5 XSLT/XPath werden vom XKD durch die Java-Bibliotheken im
Archiv xmlparserv2.jar in den Versionen 1.0 sowie mit wenigen Ausnahmen 2.0 vollständig unterstützt.
5
Die aktuelle Versionsnummer des XDK ist nicht einfach zu ermitteln und scheint je nach Produkt, in welches
das XDK integriert ist, zu differieren: Als Standalone-Variante wird das XDK unter der Versionsnummer
10.1.0.2 (bzw. 10.1.0.3 für Unix-Systeme) bereit gestellt, als Teil der Datenbank 11g trägt es die Versionsnummer 11.1.0.7. Offensichtliche Unterschiede, auch in der Dokumentation konnten allerdings nicht ausgemacht
werden.
14
Visualisierungs-Architektur
Die Visualisierungs-Architektur hält den Prozess der Diagramm-Generierung und die im
jeweiligen Schritt eingesetzten XML-Dokumente fest (Abb. 7).
Abb. 7: Visualisierungs-Architektur
Der Entscheidungsträger und Betrachter der Diagramme besitzt einen Informationsbedarf, der sich nicht an der technischen Implementierung orientiert. Entsprechend empfiehlt es
sich ein eigenes XML-Format zu definieren, welches lediglich das Ziel des Prozesses, d. h.
den Bedarf an Informationen sowie die gewünschten Diagrammtypen beschreibt und gemeinsam mit dem späteren Nutzer der Applikation erarbeitet wird. [3] Auf diese Weise lässt sich
die Diagramm- und Datenbeschreibung von der Datenaufbereitung entkoppeln. Aufgrund der
eingeschränkten programmatischen Möglichkeiten des XSQL Publishing Framework empfiehlt es sich allerdings, die Beschreibung des Datenimports aus dem separaten XMLKonfigurationsdokument heraus zu lösen und im XSQL-Dokument zu platzieren. Die Diagrammbeschreibung verbleibt dagegen in einem eigenen XML-Dokument und wird durch den
Action Handler <xsql:include-xml href="myXML.xml"> in das XSQL-Dokument importiert. Da der XSQL Page Processor die sequenzielle Verarbeitung mehrerer Transformationen durch den Action Handler <xsql:include-xsql href="myXSQL.xsql"> bietet,
kann in einem ersten Schritt die Transformation in eine für Diagramme optimierte Basisstruktur erfolgen, die als Grundlage für die Generierung jeglicher Diagramme dient. Sie kann wie
auch die reine Diagramm- oder Datenbeschreibung durch ein XML-Schema (.xsd) beschrieben und validiert werden. Erst in einer zweiten Transformation erfolgt die Umwandlung in
SVG.
Durch die Fixierung einer Basisstruktur können die XSLT-Dateien zur Generierung des
Mappings als SVG Diagram Templates wiederverwendet werden. Die Transformationslogik
wird also nicht für jedes zu erzeugende Diagramm neu erdacht, sondern lediglich für jeden
Diagrammtyp. Durch einen derartigen modularen Aufbau ist im Hinblick auf die Kombination verschiedener Diagrammtypen in einer einzigen Grafik hohe Flexibilität gegeben. Ebenso
können dieselben Datenbeschreibungen mit unterschiedlichen Diagrammtypen kombiniert
werden, sofern sie dieselbe Datenstruktur besitzen (z. B. zweidimensionale Daten in einem
kartesischen Koordinatensystem). Das XML-Schema, das die Datenstruktur mitbeschreibt,
wäre entsprechend allgemeingültig zu halten. Ferner eröffnet XSQL die Möglichkeit mehrere
Datenquellen (auch statische XML-Dokumente) parallel einzubinden. Auf diese Weise kön-
15
nen z. B. fehlende Datensätze ergänzt und damit die Datenqualität verbessert werden. Für den
Entwicklungsprozess der XML-Dokumente besteht der Vorteil, dass diese von unterschiedlichen Personen erstellt werden können, die sich auf die jeweiligen Aspekte konzentrieren
(z. B. Datenselektion, Filtering, Mapping, Rendering, Design und Browserintegration).
Die modulare Architektur birgt aber auch Nachteile: Der zweistufige Prozess führt zu
mehr Komplexität und damit Fehleranfälligkeit. So müssen z. B. Parameter über beide Stufen
hinweg übergeben werden, wenn ein Dimensionswechsel oder ein Drill-down (d. h. die Auswahl einer Ebene mit feinerer Granularität der Daten) erfolgen soll. Prinzipiell wäre auch eine
einstufige Transformation denkbar, sofern Diagramm- und Datenbeschreibung in einem einzigen Dokument abgelegt werden können, und keine weiteren Filtering-Transformationen im
Middletier nötig sind.
Diagramme und Diagrammelemente
Der Begriff „Diagramm“ verweist auf eine enorme Bandbreite unterschiedlichster Formen aus unterschiedlichsten Kontexten. Neben gängigen Formen wie Säulendiagramm, Tortendiagramm oder Liniendiagramm lassen sich auch Ablaufzeichnungen oder individuelle
figürliche Darstellungen unter diesen Begriff fassen. Gemeinsam ist allen Diagrammen, dass
sie eine Reduktion der realen Komplexität vor dem Hintergrund einer Zielsetzung vornehmen.
Die Informationen über die von der Realität abstrahierten Entitäten (z. B. den Verkaufsumsatz) werden dabei mit grafisch-symbolischen Mitteln repräsentiert. Als Qualitätskriterien für
Diagramme können Merkmale wie Klarheit, Einfachheit, gute Musterwiedergabe Validität,
Fokussierung und Standardisierung genannt werden. [12] Diesen Kriterien sollte eine Visualisierung verpflichtet sein.
Abstrahiert man von gängigen Diagrammtypen, die in der Wirtschaft Anwendung finden,
so lassen sich mehrere Grundtypen isolieren. Eine Kategorisierung könnte (unter Orientierung
an SHNEIDERMAN [13]) wie folgt aussehen:
• eindimensional – X-Achse mit Skala – Bsp.: Thermometer
• zweidimensional – logisches kartesisches Koordinatensystem – Bsp.: Liniendiagramm, Tortendiagramm
• dreidimensional – logisches kartesisches Koordinatensystem mit zusätzlichem
Merkmal – Bsp.: Blasendiagramm
• mehrdimensional – Kombinationen möglicher Skalen – Bsp.: Netzdiagramm,
• Zustände – binäre oder ternäre Skala6 – Bsp.: Schalter
• Graphen – implizierte zeitliche, funktionale oder hierarchische Abhängigkeit – Bsp.:
Prozessdiagramm
Analog zu den vorgestellten Diagrammtypen werden konkrete Diagramme aus einer Reihe möglicher Diagrammelemente konstruiert. Als Diagrammelemente, die aus Daten beim
Mapping in Zeichenobjekte erzeugt werden, lassen sich unterscheiden [12]:
•
•
•
•
6
Canvas = gesamte Zeichenfläche
Diagram Area = eigentliche Diagrammzeichenfläche
Data Object = Datenobjekte, z. B. Datenpunkt, Linie, Säule, Kreisausschnitt...
Axis = Achse
Genau genommen handelt es sich hierbei um den eindimensionalen Typ mit eingeschränktem Wertebereich.
16
•
•
•
•
•
•
•
•
•
•
•
Scale = Skala
Ticks = Skalenstriche
Legend = Legende
Title = Titel
Container = grafisches Element zur Einbettung anderer grafischer Elemente, z. B.
Trichter, Meter, Röhre …
Marker = Markierung eines Wertebereichs, z. B. Schwellwert, Default-Wert
Label = Beschriftung, sowohl für Achsen, Skala und Datenobjekte
Annotation = textuelle Zusatzangaben
Interactivity = Interaktivität
Animation = Animation
Visuals = visuelle Effekte, Design
Hält man sich das konkrete Rendering eines der genannten Elemente im Kontext mehrerer Diagrammtypen vor Augen, wird deutlich, dass prinzipiell jedes der genannten Elemente
in jeglichem Diagramm vorkommen kann. Das abstrakte visuelle Objekt könnte also logisch
betrachtet prinzipiell immer gegeben sein, nur die grafische Realisierung differiert von Diagrammtyp zu Diagrammtyp. So verfügt selbst ein eindimensionales Schalterdiagramm mit nur
zwei Werten, nämlich „an“ oder „aus“, genau genommen über eine Y-Achse mit exakt zwei
Skalenstrichen, d. h. eine nominale Skalierung. Bei einem ebenfalls eindimensionalen Thermometer mit einem stetigen und theoretisch nur durch den absoluten Nullpunkt nach unten
begrenzten Wertebereich käme dagegen eine kardinale Einteilung der Skala zum Zuge.
Wesentlich für die grafische Visualisierung ist letztlich, ob das logische grafische Objekt
tatsächlich gezeichnet wird oder nur als mathematisches Konstrukt zur Repräsentation eines
Koordinatensystems in der Vorstellung dient. Entsprechend wird beim Schalter keine Achse
gezeichnet, sondern ein Container-Element, das zwei funktional abhängige Boxen mit boolescher Ausprägung enthält. Beim Thermometer wird dagegen eine fortlaufende, kardinale Skala eingesetzt (i. d. R. intervallisch beschränkt, je nach Anwendungsfall z. B. für die Wetterbeschreibung zwischen -100 °C und +100 °C). Ergänzend könnten beim Thermometer noch
zwei sich entsprechende Skalen z. B. Celsius und Fahrenheit gezeichnet werden. Auch ein
Container-Element wird wie beim Schalter in Anlehnung an die physische Ausprägung abgebildet, in diesem Fall ein Quecksilberthermometer.7 Abb. 8 zeigt die Gegenüberstellung der
Diagrammtypen und der logisch vorhandenen mathematischen bzw. grafischen Elemente.
7
Die Wahl von grafischen Objekten aus dem Erfahrungsbereich des Benutzers unterstützt die intuitive Erfassung
und Interpretation eines Diagramms (vgl. typische Symbole der grafischen Benutzerschnittstelle wie den Mülleimer für Löschoperationen von Dokumenten o. ä.).
17
°C
°F
100
212
50
122
0
32
-50
-58
-100
-148
100
212
50
122
0
-50
-100
1
0
0
1
-58
-148
Abb. 8: Logisch-mathematische und visuelle Repräsentation von Diagrammen
Diagramminteraktionen
Eine spezielle Kategorie von Diagrammelementen sind Elemente zur Repräsentation von
Interaktivität. Sie können auf unterschiedliche Weise mit Funktionalität hinterlegt werden.
Aus dem Bereich der BI und speziell aus dem Online Analytical Processing (OLAP) sind
Interaktionen bekannt, die dem Benutzer ausgehend von einer Überblicksdarstellung erlauben, die aktuelle Ansicht seiner Datenmenge, des sog. „Data Cube“ zu modifizieren. Dabei
lassen sich Interaktionen unterscheiden, die sich auf verschiedene Schritte des Visualisierungsprozesses beziehen (Abb. 9):
Abb. 9: Interaktiver Einfluss auf den Visualisierungsprozess
Analog zu dieser Unterteilung können folgende Interaktionen bzw. Operationen genannt
werden (in Anlehnung an [3, 13, 14, 15, 16]):
Interaktionen der Präsentations-Ebene
• Overview = Übersicht über Datenmenge erlangen
• Pan = Ansicht verschieben
• Zoom = Ansicht vergrößern
• History = zu einer bereits erzeugten Ansicht wechseln
• Design Change = Wechsel der grafischen Details, z. B. Farbschema, visuelle Effekte
(Schatten, Opazität …)
• Relate = Anzeige oder Navigation zu Kontextinformationen, auch qualitativen Daten
• Merge = Zusammenführung mehrerer Diagramme in einem einzigen
• Extract = Export der angezeigten Datenobjekte in anderer Form zur Weiterverarbeitung
Interaktionen der Mapping-Ebene:
• Type Change = Wechsel des Diagrammtyps
18
Interaktionen der Filtering-Ebene:
• Drill-up/down = Auswahl einer feineren Granularitätsstufe eines Datenausschnitts,
z. B. Region Deutschland statt Region Europa
• Drill-aside = Auswahl eines anderen Datenbereichs auf derselben Granularitätsstufe
einer Dimension, z. B. Jahr 2001 statt Jahr 2002
• Slice & Dice = Auswahl anderer Dimensionen bzw. einer anderen Anordnung von
Dimensionen8
• Sort = Datensätze nach einem Kriterium sortieren (alphabetisch, numerisch …)
• Filter = Datensätze nach einem Filterkriterium einschränken
• Group = Datensätze gruppieren
• Aggregate = Berechnung statistischer Standardwerte
• Relate = Datensätze vergleichen
• Level of Detail (LOD)9 = Nachladen von Datenobjekten im Anschluss an eine
Zoom-Operation
Festzuhalten bleibt, dass die Zuordnung der Interaktion zur jeweiligen architektonischen
Transformationsebene nicht trennscharf ist. Bei der Unterscheidung handelt es sich in erster
Linie um eine Festlegung, in welchem Schritt des Visualisierungsprozesses (Filtering, Mapping, Rendering) die Operation zu verankern ist. Architektonisch kann die Operation aber
auch in einer anderen Ebene erfolgen. D. h., das Filtern von Daten betrifft den Prozessschritt
Filtering, kann aber programmatisch entweder durch eine Datenbank-Abfrage oder das reine
Ausblenden von Elementen auf der Präsentationsebene umgesetzt werden.
Diagrammkonstruktion
Die Konstruktion eines Diagramms basiert auf den soeben beschriebenen, potenziell
möglichen Diagrammelementen. Dabei wird es nötig sein, zunächst festzulegen, in welchem
Kontext und für welche Erkenntnisziele das Diagramm eingesetzt werden soll. Nur für das
Anwendungsszenario relevante Elemente wären bei der Konstruktion zu berücksichtigen.
Prinzipiell sind zwei elementare Komponenten eines Diagramms zu verbinden: Zum
einen ist eine Datenbeschreibung zu erstellen, d. h. eine Definition der Datenmenge, die in
einem Diagramm visualisiert werden soll. Dies ist im verfolgten Szenario über die deklarative
Sprache SQL, die in eine XSQL-Datei eingebettet wird, und – falls nötig – anschließenden
Datentransformations-Operationen in XSLT möglich (in der Visualisierungs-Architektur als
„Datenbeschreibung“ und Transformation des Filtering existent).
Zum anderen handelt es sich um die Diagrammbeschreibung, d. h. eine Festlegung, welchen Typs das Diagramm sein soll und welche der genannten Interaktionsmechanismen es
enthalten soll. Dies geschieht mit Hilfe des in der Visualisierungs-Architektur charakterisierten, separaten XML-Dokuments, das als „Diagrammbeschreibung“ bezeichnet ist. Beide
Komponenten einer Diagrammkonstruktion sollen kurz beschrieben werden:
8
9
Dies kann ebenso über Drill-up/down als auch Drill-aside auf den Einstiegsebenen erfolgen.
Auch als „Details-on-demand“ bezeichnet [Shneiderman].
19
Datenbeschreibung
Alle Diagrammelemente bis auf die Datenobjekte selbst geben den Kontext vor, in dem
die Daten zu interpretieren sind, und scheinen auf den ersten Blick unabhängig von den Daten
zu sein. Tatsächlich hängen allerdings auch die Diagrammzeichenfläche, Achsen, Skalen inkl.
Skalenstrichen, Achsen- und Skalenbeschriftungen sowie Beschriftungen der Datenobjekte,
Legende und Marker unmittelbar von den Quelldaten ab. So bestimmt bspw. die Datentopologie, welcher Art die verwendeten Skalen sind. Handelt es sich z. B. um unabhängige Datensätze (Einwohnerzahlen der Länder Europas, Umsätze pro Produktgruppe etc.), würde eine
nominale Skala gewählt. Bei abhängigen Daten wäre dagegen eine ordinale oder kardinale
Skalierung zu verwenden. [3, 17] Weiterhin bestimmt z. B. der maximale Y-Wert, wie groß
die Diagrammzeichenfläche sein muss. Die enge Abhängigkeit zwischen allen Diagrammelementen ist nicht verwunderlich, da ja schließlich die Daten visualisiert werden sollen und
alle Elemente diesem Zweck unterstellt sind. Indirekt sind demnach auch alle scheinbar frei
bestimmbaren Elemente, z. B. das Farbschema (s. u.) davon abhängig und sollten sich an diesem Zweck ausrichten.
Damit eine zweidimensionale Grafik entstehen kann, ist stets eine Transformation in
einen zweidimensionalen Vektorraum nötig. Daher sind alle Daten zumindest in das Format
eines kartesischen Koordinatensystems zu bringen. Sofern mehr als zweidimensionale Datenbestände in einem einzigen Diagramm abgebildet werden sollen, müssen die durch X-YKoordinaten definierten Datenpunkte um weitere grafische Elemente ergänzt werden. Im Blasendiagramm wird die Z-Dimension z. B. durch den Kreisradius repräsentiert. Prinzipiell wäre eine weitere Dimension aber ebenso gut durch Farbwerte oder andere visuelle Gestaltungsmittel darstellbar, z. B. die Simulation des dreidimensionalen Raums.
Das Datenmodell, das aus dem Filtering-Schritt hervorgeht und als Grundlage für das
Mapping von grafischen Objekten dient, muss die gewünschten Dimensionen berücksichtigen. Auf seiner Basis werden die grafischen Objekte durch den zweiten Transformationsschritt, d. h. im gewählten Szenario durch ein XSLT-Stylesheet (dem SVG Template) in Verbindung mit der Diagrammbeschreibung erzeugt.
Diagrammbeschreibung
Auch die Diagrammbeschreibung basiert auf den zu visualisierenden Daten, da sich nicht
jeder Diagrammtyp wie schon angedeutet für jegliche Daten eignet. So impliziert ein Liniendiagramm einen zeitlichen Verlauf; es würde bei nominal vorliegenden Daten keinen Sinn
ergeben. Zudem ist der semantische Kontext bzw. das Anwendungsszenario der Daten für die
Wahl der Visualisierung wichtig. Da eine direkte Ableitung aus den Daten nicht oder zumindest nicht mit vertretbarem Aufwand möglich ist, erfolgt die Erstellung der Diagrammbeschreibung deklarativ durch den Menschen. Seinem qualitativen Einschätzungsvermögen
wird die Maschine i. d. R. unterlegen sein.
20
XML-Diagramm-Basisstruktur
Als Ergebnis der ersten Transformationsstufe, d. h. der Verbindung von Daten- und Diagrammbeschreibung sowie nötigen Strukturtransformationen ergibt sich analog zur oben konzipierten Visualisierungs-Architektur (Abb. 7) die Diagramm-Basisstruktur als XMLDokument. Sie bildet die Vorstufe der dynamischen Diagrammgenerierung. Die Modellierung
eines XML-Schemas, das diese Basisstruktur fixiert, müsste demnach die XML-Elemente
beider Komponenten, Daten- und Diagrammbeschreibung, definieren.
XML-Schema für Diagramme
Als Ausgangspunkt für eine Anpassung an das fachliche Anwendungsszenario und die
eingesetzten Diagrammtypen könnte basierend auf den Ausführungen zur DiagrammKonstruktion eine hierarchische Struktur wie in Abb. 10 dienen.10 Die Nutzung dieser relativ
generischen Grundstruktur ließe spätere Erweiterungen zu, ohne dass das Schema und damit
die darauf basierenden Applikationsmodule modifiziert werden müssten. Ein völlig allgemeingültiges Schema ist aufgrund der Breite möglicher Diagrammtypen nicht realisierbar und
ebenso wenig sinnvoll. Für ein spezielles Anwendungsszenario wird man darum bemüht sein,
eine Balance zwischen generischer und fachspezifischer Gestaltung zu erreichen. Dadurch
sind sowohl Lesbarkeit als auch Nachhaltigkeit gegeben.
Abb. 10: XML-Schema für Diagramme
Als Container-Element für alle folgenden XML-Elemente dient <diagramset>. Da es
im Rahmen des grafischen Layouts einer Applikation zur Informationsanalyse nötig sein kann
mehrere Diagramme parallel zu betrachten und flexibel zwischen Gruppen von Diagrammen
hin- und herwechseln zu können, ist das Element <diagramgroup> als weiteres ContainerElement eine Hierarchiestufe darunter eingefügt. Die Existenz mehrerer Diagramme ergibt
sich aus dem Vorkommen mehrerer Knoten des Elements <diagram> innerhalb dieses Containers. Schließlich ist mit den Elementen <config> und <dataset> eine grundsätzliche
Unterteilung zwischen den deklarativ konfigurierbaren Objekten eines Diagramms und den
sich unmittelbar aus den Daten ergebenden Objekten vorgenommen. Eine exakte Zuordnung
der Elemente ist aufgrund der Interdependenz von Daten und Diagrammtyp ebenso wie für
die Unterscheidung in generische und spezifische Konfigurationsparameter nicht zwingend
10
Sie entspricht dem, was Tang/Stolte/Bosch als „Specification“ bezeichnen: Einem „middle ground“, der die
einfache Definition des vom Benutzer gewünschten Diagramms zulässt. [3] Diese XML-Datei bzw. die separaten Teile Daten- und Diagrammbeschreibung könnten benutzerfreundlich durch die Auswahl von Optionen in
einem Web-Formular erzeugt werden.
21
vorzunehmen und kann je nach Szenario sicherlich modifiziert werden. Dennoch existieren
im Rahmen des Gestaltungsprozesses diese grundlegenden Unterscheidungen. Im Bsp.
(Abb. 11b) sind unter <specific> mögliche Ausprägungen für die Diagrammtypen Säulenund Liniendiagramm exemplarisch aufgeführt. Auch die Konfiguration der Skalen ist im Bsp.
unter diesem Teilbaum realisiert.
Abb. 11a: Teilbaum der generischen Diagrammbeschreibung
Ein wichtiger eigener Bereich besteht im Knotenset <interaction>, das sowohl im
Teilbaum der generischen als auch spezifischen Konfiguration existiert (Abb. 11a und 11b).
Hier können klassische Interaktionsmechanismen von OLAP aktiviert werden, z. B. Drilldown oder Drill-aside. Die Existenz eines entsprechenden Elements zieht ggf. weitere Unterelemente nach sich, welche die Interaktion näher beschreiben. Leider lassen sich in einem
XML-Schema Abhängigkeiten zwischen Elementen über die hierarchische Existenz, Reihenfolge und Anzahl hinaus nicht erzwingen. So können trotz der inhaltlich gegebenen Interdependenz z. B. keine logischen Abhängigkeiten zwischen Elementen des Teilbaums <dataset> und <config> definiert werden.
Im Teilbaum <config> können neben interaktiv erreichbaren Informationen innerhalb
des Elements <aggregation> statistische Standardberechnungen aktiviert werden, z. B. die
Summe, der Mittelwert oder die Standardabweichung der angezeigten Datenpunkte. Das Element <colorscheme> schließlich legt die Art des Farbschemas, z. B. klassisch, modern oder
Graustufen fest.
22
Abb. 11b: Teilbaum der spezifischen Diagrammbeschreibung
Abb. 12: Teilbäume der Datenbeschreibung
Das <dataset> gliedert sich in zwei Teilbäume, die zum einen datenspezifische Definitionen zulassen, zum anderen die generierten Daten unter der entsprechenden Rubrik (eindi-
23
mensional, zweidimensional, dreidimensional und multidimensional) sammeln (Abb. 12).
Dabei ist sowohl eine Ableitung der Definitionen (<defs>) aus den Quelldaten als auch eine
manuelle Festlegung denkbar, die direkt in der XML-Datenbeschreibung erfolgt.
Eine mögliche Instanz eines Dokuments dieser Struktur ist in Codesbsp. 6 zu sehen. Es
setzt sich wie oben geschildert aus der Diagramm- und Datenbeschreibung zusammen, die
durch eine erste Transformation in die abgebildete Struktur überführt werden.
<?xml version = '1.0'?>
<diagramgroup>
<diagram type="line">
<config>
<generic>
<colorscheme>classic</colorscheme>
<interaction>
<switch_colorstyle>false</switch_colorstyle>
</interaction>
</generic>
<specific>
<line_weight>3</line_weight>
<dots_weight>5</dots_weight>
<y_axis_ticks>adjusted</y_axis_ticks>
<x_axis_scale>temporal</x_axis_scale>
</specific>
</config>
<dataset>
<defs>
<title>Umsätze Business Unit “Music”</title>
<x_axis>
<unit>Jahre</unit>
<label>Zeit</label>
</x_axis>
<y_axis>
<unit>Anzahl in Mio.</unit>
<label>Zugriffe</label>
</y_axis>
</defs>
<data>
<two_dim_item>
<x_value>2001</x_value>
<y_value>95</y_value>
</two_dim_item>
<two_dim_item>
<x_value>2002</x_value>
<y_value>110</y_value>
</two_dim_item>
...
</data>
</dataset>
</diagram>
</diagramgroup>
Codebsp. 6: XML-Instanz der Diagramm-Basisstruktur
24
Programmatische Erzeugung des XML-Schemas
Analog zur Visualisierungs-Architektur ist die vorgestellte Basisstruktur als Ergebnis der
ersten Transformation mit XSLT zur generieren. Dies geschieht einerseits in der XSQL-Datei
der ersten Transformationsstufe (Codebsp. 7) durch das Zusammenführen von Diagrammund Datenbeschreibung mittels <xsql:include-xml>, andererseits durch die anschließende
Strukturtransformation durch das Stylesheet. Im letztgenannten Schritt könnten zudem neben
den bereits durch die Datenbank realisierten weitere Filtering-Operationen durchgeführt werden. Damit die korrekten XML-Elemente im resultierenden XML-Baum erzeugt werden, ist
das Standardmapping (s. o.: rowset/row) von relationaler auf die XML-Struktur über die
Attribute rowset-element und row-element zu modifizieren. Dadurch dass für die Xund Y-Werte des Koordinatensystems immer dieselben Aliasbezeichner verwendet werden
(x_value bzw. y_value), kann das Stylesheet wiederverwendet werden. Prinzipiell wäre
auch die Umbenennung der Knoten durch die erste Transformation möglich. An diesem konkreten Beispiel wird deutlich, dass aufgrund der hohen Flexibilität der Architektur bzw. der
verwendeten Technologien meist mehrere Möglichkeiten der Realisation gegeben sind. Es ist
anhand des Anwendungsszenarios zu entscheiden, welche Variante gewählt wird. Diese ist
über alle Diagramme möglichst konsistent beizubehalten, um die Wartbarkeit des erzeugten
Codes zu gewährleisten.
<?xml version = '1.0'?>
<?xml-stylesheet type="text/xsl" href="trans1.xsl" ?>
<diagram> xmlns:xsql="urn:oracle-xsql" connection="myConn">
<xsql:include-xml href="dgr_config.xml"/>
<dataset>
<defs>
<title>Umsätze Business Unit "Music"</title>
<x_axis>
<unit>Jahre</unit>
<label>Zeit</label>
</x_axis>
<y_axis>
<unit>Mio. EUR</unit>
<label>Umsatz</label>
</y_axis>
</defs>
<xsql:query rowset-element="data" row-element="two_dim_item">
SELECT year as x_value, sales as y_value
FROM year_sales WHERE bu = 'MUSIC'
</xsql:query>
</dataset>
</diagram>
Codebsp. 7: XSQL-Seite der ersten Transformationsstufe
Die inkludierte XML-Datei dgr_config.xml entspräche exakt dem Ausschnitt des
Schemas für die Basisstruktur unterhalb des Teilbaums <config>. Sollen mehrere Diagrammbeschreibungen in einer einzelnen XML-Datei enthalten sein, müsste die Zusammen-
25
gehörigkeit der jeweiligen Diagramm- und Datenbeschreibung durch die konsistente Reihenfolge in XML- bzw. XSQL-Datei implizit festgelegt werden. Das umschließende Element
<diagram> wäre dann durch <diagramset> zu ersetzen und die Stylesheet-Transformation
entsprechend anzupassen. In der XML-Datei bildete <diagramgroup> das Wurzelelement.
Auch in diesem Fall besteht eine Alternative: An Stelle der Strukturtransformation und
Zuordnung von Diagramm- und Datenbeschreibung durch das Stylesheet kann auch die
XSQL-Datei mehrere <xsql:query>- und <xsql:include-xml>-Elemente aufnehmen
und so eine explizite Zuordnung vornehmen.
Auf die Wiedergabe der XSLT-Datei, welche die Transformation in die DiagrammBasisstruktur vornimmt, wird hier verzichtet, da es sich um eine einfache Strukturtransformation handelt.
Diagramme und SVG
Im Rahmen der zweiten Transformationsstufe stellt sich die Frage, welche konkreten
SVG-Elemente auf die Daten gemappt werden sollen. Da sich mit SVG Linien, Rechtecke
und Kreise neben normalem Text darstellen lassen, können die entsprechenden klassischen
Diagrammformen (Linien-, Säulen- und Tortendiagramm) leicht erzeugt werden.11 Allerdings
existiert für derartige Diagramme eine Vielzahl an Standardsoftware, die eine Eigenentwicklung nur schwer rechtfertigen dürfte. Jedoch geht der Sprachumfang von SVG deutlich über
diese einfachen grafischen Elemente hinaus und beinhaltet grafische Primitive wie Ellipsen,
Polygone und Pfade, mit denen sich z. B. Béziers-Kurven erzeugen lassen. Auch Attribute
wie Füllung, Strichbreite und Farbe lassen sich beeinflussen. Dabei sind nicht nur eine einfache Farbgebung sondern auch Farbverläufe und Muster sowie Filtereffekte anwendbar. Zudem können Transformationen des zweidimensionalen Vektorraums inkl. einfacher Matrixtransformationen durchgeführt werden. Durch dieses Potenzial lassen sich insbesondere sehr
individuelle Diagramme effizient programmieren und durch die Kombination mit grafischen
Objekten, die aus Zeichenprogrammen exportiert und in SVG eingebettet werden (z. B. aus
CAD-Programmen), fachspezifisch gestalten. Einen entsprechenden Gestaltungsumfang kann
Standardsoftware nicht bieten.
Da SVG die Kombination und das flexible Layout unterschiedlicher eigenständiger SVGDateien zulässt, ist ein modularer Aufbau von komplexen Diagrammen möglich. Zudem kann
SVG als Objekt in HTML eingebettet werden, sodass durch die Vermittlung von JavaScript,
dem der komplette DOM-Baum zugänglich ist, übergreifende Interaktionen möglich werden.
Exemplarisch zeigt folgender Ausschnitt aus einem XSLT-Dokument das Mapping von
Daten auf grafische Objekte (Codebsp. 8):
11
Diese Aussage soll nicht darüber hinwegtäuschen, dass teilweise aufwändige mathematische Berechnungen
für die Beeinflussung nötig sind. Bspw. können Kreisausschnitte nur durch den Einsatz trigonometrischer Formeln zufriedenstellend berechnet werden. [5, 18, 19, 20]
26
<?xml version = '1.0'?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output
doctype-public="-//W3C//DTD SVG 20001102//EN"
doctype-system="http://www.w3.org/TR/2000/CR-SVG20001102/DTD/svg-20001102.dtd"
media-type="image/svg+xml"
method="xml" />
<xsl:template match="/">
<svg xmlns="http://www.w3.org/2000/svg" width="500" height="500">
<g id="datapoints">
<xsl:for-each select="diagramset/diagramgroup/diagram/dataset/
data/two_dim_item">
<xsl:call-template name="datapoints">
<xsl:with-param name="rowIdx" select="position()"/>
<xsl:with-param name="y_value" select="y_value"/>
</xsl:call-template>
</xsl:for-each>
</g>
</svg>
</xsl:template>
<xsl:template name="datapoints">
<xsl:param name="rowIdx"/>
<xsl:param name="y_value"/>
<circle id="dp_{$rowIdx}" cx="{$xoffset + $rowIdx * 20}"
cy="{$yoffset + $y_value}" r="{$dp_weight}" class="dgrDatapoint"/>
</xsl:template>
Codebsp. 8: Mapping von Daten auf SVG-Elemente
Für jeden Datensatz (two_dim_item) wird das Template mit dem Namen datapoints aufgerufen und ein Kreis mit dem Radius dp_weight erzeugt. Die Y-Position ergibt sich direkt
aus dem Wert des Knotens y_value zuzüglich eines Offsets. Die X-Position ist dagegen abhängig von der relativen Position des Datensatzes im XML-Baum (rowIdx), dem Standardversatz 20 und ebenfalls einem Offset.
Neben den Template-Anweisungen für die Erzeugung der SVG-Elemente wird in dem
Stylesheet auch ein größerer Abschnitt der Berechnung wichtiger Diagrammeigenschaften
gewidmet sein, die in Variablen mit der Anweisung <xsl:variable> abgelegt werden. Dies
sind z. B. die Größe der Diagrammzeichenfläche, die Anzahl der Datensätze, das Skalierungsmaß für eine X- bzw. Y-Einheit oder der maximale X- und Y-Wert. Beim Aufruf eines
Templates, das ein bestimmtes Diagrammelement zeichnet, werden dann diejenigen Variablen
als Parameter übergeben, die für die Bestimmung der Eigenschaften des Elements (Position,
Größe etc.) benötigt werden.
27
Diagramminteraktionen mit SVG und XSQL
SVG und Interaktivität
Neben dem Mapping auf SVG-Elemente, welche die Daten und ihren Kontext visualisieren, müssen zudem Elemente erzeugt werden, welche die gewünschten Diagramminteraktionen umsetzen. SVG bietet drei Möglichkeiten, um grafische Elemente bzw. Text mit Interaktivität auszustatten:
Das simpelste, wenngleich effektiv einsetzbare Element ist der aus HTML bekannte <a>Tag. Analog zu HTML lassen sich hierüber Hyperlinks zu weiteren Diagrammen erzeugen
(bzw. XSQL-Seiten, welche diese Diagramme generieren), wodurch z. B. ein Drill-down/-up
oder -aside realisierbar ist.
Animationen werden durch die in SVG integrierte SMIL ermöglicht. Auslöser für Animationen können neben der rein zeitlichen Steuerung Maus- oder Tastatur-Ereignisse sein.
Auf diese Weise lässt sich die Aufmerksamkeit des Betrachters auf einzelne Elemente lenken
(z. B. bei einem Marker) oder die Möglichkeit der Interaktivität bei mouseover signalisieren.
Auch dynamische Grafiken sind denkbar, z. B. die Veränderung von Ländergrenzen im Geschichtsverlauf.
Die weitaus mächtigste und komplexeste Funktionalität bietet ECMAScript, das i. d. R.
als JavaScript implementiert ist, und mit dem sich das Document Object Model (DOM), d. h.
der komplette SVG-Elementbaum manipulieren lässt. In Verbindung mit der verfügbaren,
umfangreichen Ereignisbehandlung kann damit die direkte Manipulation von Steuerelementen
der Benutzerschnittstelle (z. B. Schieberegler) oder Diagrammelementen selbst erfolgen. Im
ersten Fall könnten Zoom und Pan realisiert werden, in letzterem ließen sich damit weitere
typische OLAP-Diagramminteraktionen wie Drill-aside, Slice oder Dice unterstützen. Auch
What-if-Szenarien sind denkbar.
Konzeptionell ist die für einzelne Diagrammtypen grundlegende Interaktivität – wie gezeigt – separat in der oben angeführten Basisstruktur zu beschreiben. Individuelle, komplexe
Interaktionen müssten dagegen im SVG Template des jeweiligen Diagrammtyps situativ ergänzt werden.
Interaktive Operationen mit XSQL
Die vorgestellte Visualisierungs-Architektur sieht eine Aufspaltung in mehrere Ebenen
bzw. Module vor, um Flexibilität der Applikation zu erzielen. Dies bringt neben der separation of concerns aber auch Komplexität mit sich, da Diagramme – wie oben ausgeführt – nur
im Kontext adäquat zu erfassen sind, und dieser Kontext prinzipiell auf jeder Transformationsstufe vorliegen muss. [3] Speziell im Hinblick auf interaktive Diagrammoperationen ist
dies zu betonen. So muss für das auf einen Drill-down folgende Diagramm feststehen, welcher Datenausschnitt gewählt werden soll. Umgekehrt muss bei einem Drill-up bekannt sein,
aus welchem Datenausschnitt der Drill-down erfolgte, d. h. wohin zurück zu kehren ist. Auch
ein Drill-aside sollte nur dann erfolgen können, sofern für das anschließende „Slice“ auch
Daten vorhanden sind. Diese einfachen Beispiele zeigen bereits die große Bedeutung des
Diagrammkontexts für die Navigation im Datenraum. Insbesondere sofern eine Interaktion
erfolgt, die sich der Transformation Filtering zuordnen lässt, sind komplexe Kontextoperationen nötig.
28
Das XSQL Publishing Framework bringt durch seinen allgemeingültigen Ansatz die Einschränkungen mit sich, dass die volle programmatische Umgebung nicht „out-of-the-box“ zur
Verfügung steht. In erster Linie sind bereitgestellte Action Handler zu nutzen; nur für sehr
spezielle Anwendungen wird man den Weg des Customizing gehen wollen und auf die angebotenen APIs zurückgreifen. Wird eine Seiten-basierte Navigation der Applikation gewählt,
sind zwischen den SVG-Seiten daher Parameter zu übergeben, die den Diagrammkontext repräsentieren. Dies ist bei einer mehrstufigen Architektur und Seiten-basierter Navigation nicht
trivial, lässt sich aber durch verfügbare Action Handler realisieren:
• Die Referenz {@param} auf einen mit der URL übergebenen Parameter kann in
einer XSQL-Seite zur dynamischen Anpassung von Attributen oder Elementinhalten
dienen.
• <xsql:include-request-params> integriert sämtliche mit der URL übergebenen Parameter in die vom XSQL Page Processor erzeugte XML-Datei der Daten, sodass diese im anschließenden Stylesheet als XML-Elemente zur Verfügung stehen.
• <xsql:set-stylesheet-params> erlaubt das Setzen eines im anschließenden
Stylesheet verfügbaren Parameters, der dort über <xsl:param/> deklariert ist.
• <xsql:set-session-param> erlaubt das Setzen eines Parameters, der für die
Dauer der HTTP-Sitzung zur Verfügung steht.
• <xsql:if-param> erlaubt die Kontrollflusssteuerung basierend auf der Existenz
oder dem Wert eines Parameters.
Durch die Übergabe von Parametern mit der URL und deren flexible Weiterverwendung
kann eine Verkettung von XML-Seiten sowohl über die Transformationsstufen hinweg als
auch entlang der Navigation durch den Datenraum erfolgen. So könnte die URL
http://www.myserver.de/olap/diagram1.xsql?dimx=time&dimy=sales&dim0=
2001&dim1=Jan semantisch bedeuten, dass es sich um eine zweidimensionale Ansicht der
Dimensionen Umsatz und Zeit handelt, die Quellgranularität im Jahr 2001 und die Zielgranularität im Monat Januar besteht. Damit wäre durch den Navigationspfad der elementare Kontext für das Zieldiagramm gegeben.
Evaluation
Prototyp
Zur Evaluation des Konzepts wurden zwei Diagramme mit unterschiedlichen Eigenschaften als Prototypen umgesetzt. Zunächst wurde ein Liniendiagramm als klassisches und leicht
nachvollziehbares Diagramm realisiert. Über Hyperlinks und unter Verwendung desselben
SVG Template ist hier der Drill-down zu detaillierteren Dimensionsgraden möglich. ECMAScript-Ereignisse liefern im Diagramm kontextsensitive Zusatzinformationen (Abb. 13).
29
Abb. 13: Screenshot des Prototyps „Liniendiagramm“
Zudem wurde ein individualisiertes Diagramm umgesetzt, welches die Spezifika von
SVG stärker als klassische Diagrammtypen ausschöpft (Abb. 14). Dazu wurde ein Bild im
PNG-Format eingebunden, das die Szenerie eines Wintersportgebiets zeigt. Auf diesen visuellen Kontext werden weitere, steuerbare SVG-Elemente gezeichnet. Neben einer Überblicksansicht ist die Möglichkeit einer Level of Detail-Interaktion gegeben. So lassen sich wichtige
Informationen für das Gesamtsystem (z. B. Zustand der Lifte, Verteilung der Skifahrer) in der
Überblicksansicht erfassen und bei einem Indiz für eine vom Soll-Zustand abweichende Information auf der Makroebene ein Zoom in die Mikroebene vornehmen. Hier werden zusätzliche grafische Elemente nachgeladen bzw. sofern im DOM-Baum bereits vorhanden über die
Änderung des Style-Attributs visibility zur Ansicht gebracht.12
12
Exemplarisch wurde dabei die Integration von bereits existierenden ECMAScript-Bibliotheken zur Verarbeitung von SVG erprobt. Der Prototyp wurde unter Verwendung der ursprünglich für Karten entwickelten Bibliotheken von carto.net [26] umgesetzt. Die Module des Open Source-Frameworks bieten eine gute Basis für komplexe Interaktivität, die durch ECMAScript realisiert wird.
30
Abb. 14: Screenshot des Prototyps „Individuelles Diagramm“
Lessons Learned
Einige wichtige Erkenntnisse lassen sich in Verbindung mit der Evaluation festhalten:
Zum einen soll nochmals betont werden, wie wichtig der Diagrammkontext für eine adäquate
Visualisierung einschließlich der komfortablen Navigation im Datenraum ist (vgl. auch [21]).
Erst wenn dieser Kontext vorliegt, lässt sich das Potenzial von SVG, nämlich die differenzierte grafische Gestaltung bei der Repräsentation von Informationen und die weitreichende
Interaktivität ausschöpfen. Hier sind der Kreativität gerade im Hinblick auf eine benutzerfreundliche Gestaltung kaum Grenzen gesetzt. Möchte man z. B. bereits auf einer höheren
Ebene der Datengranularität Hinweise auf darunter liegende Anomalien (eingeschränkt verfügbare Daten, Abweichungen vom Soll-Wert etc.) wiedergeben, muss zugleich der Kontext
der darunter liegenden Ebenen vorhanden sein. Diesen herzustellen ist nicht einfach.
Der enge Zusammenhang aller Diagrammelemente wurde schon erwähnt. Insbesondere
die Wahl der richtigen Skalierung – neben nominal, ordinal, kardinal müssen temporale Skalen als eigene Kategorie betrachtet werden, da sie eine eigene Qualität besitzen [13] – scheint
eine gute Basis für alle übrigen grafischen Berechnungen zu sein. Überhaupt können selbst
für visuell einfach gehaltene Diagramme umfangreiche mathematische Operationen durchzuführen sein.
Was die Modellierung eines XML-Schemas der Diagramm-Basisstruktur angeht, ist die
Auffassung über eine Balance zwischen Allgemeingültigkeit und Ausrichtung auf spezielle
Diagrammtypen diskussionsbedürftig. Besonders wichtig ist daher eine umfassende Analyse
31
des Anwendungsszenarios der Diagramme und der zukünftigen Entwicklung einer Applikation.
Das sog. Painter Model von SVG, d. h. die Überdeckung von Elementen bei nachfolgender Zeichnung an derselben Stelle, muss – so einfach es ist – stets berücksichtigt werde. Dies
verbietet die Abarbeitung von Mapping-Transformationen in einem Schritt, obwohl sie der
gleichen Logik unterworfen sind. Hier hilft nur die Auslagerung der Berechnung in ein eigenes Template, um Redundanzen im Code zu vermeiden.
Neben der Auslagerung von Berechnungen empfiehlt sich unbedingt die Kapselung der
Funktionalität zur Generierung der oben unterschiedenen Diagrammelemente in eigenen
Templates. Dadurch können diese wie Funktionen mit Parametern aufgerufen werden. Das
Ergebnis ist ein flexibler Baukasten für die Generierung verschiedener Diagrammelemente.
Da XSLT-Dateien in andere eingebunden werden können, lassen sich die SVG Templates zur
Generierung spezieller Diagramme aus bereits vorhandenen Stylesheets modular konstruieren, indem nur die dafür benötigten Templates integriert werden. Die Modularisierung sollte
sich zudem auch auf gesamte Diagramme beziehen, damit Ansichten mit mehreren unterschiedlichen Diagrammtypen zusammengestellt werden können (Dashboards, Diagramm im
Diagramm etc.).
Hinsichtlich der Werkzeug-Unterstützung der Entwicklung besteht noch Bedarf. So existiert im JDeveloper über die Prüfung der XML-Konformität hinaus momentan keine Unterstützung der Syntax von SVG. Entsprechend lassen sich komfortable Unterstützungsfunktionen wie z. B. Code Complete nicht nutzen. Zudem ist das Debuggen von gemischtem Code,
d. h. SVG innerhalb XSLT, schwierig. Hier ist man auf die Unterstützung des Debuggers im
SVG-Viewer angewiesen, der Hinweise auf syntaktische oder semantische Fehler gibt.
Ausblick
Das XSQL Publishing Framework verfügt über eine Reihe von Action Handlern und
Konfigurationsparametern, die hier nicht vorgestellt wurden. Sie lassen sich ebenso wie die
Möglichkeit der Erweiterung des Framework um benutzerdefinierte Java-Funktionen und
fortgeschrittene XML-Techniken [22] zur Verbesserung einer Applikation einsetzen. Allerdings ist angesichts der Komplexität der Parameterübergabe über mehrere Stufen einer Architektur hinweg auch über die Seiten-basierte Navigation und den dabei schwer herzustellenden
Diagrammkontext nachzudenken. Bei funktional mächtigeren Applikationen ließen sich weitere Web-Technologien einbinden, die jeweils ihre Stärken einbringen könnten. Neben der
Einbettung von SVG in HTML zur Nutzung von Formularen oder weiteren medialen Objekten [23] ist die Verwendung von AJAX aufgrund der Wahl von XML als Kerntechnologie des
XSQL Publishing Frameworks naheliegend [24]. Auf diese Weise könnten wichtige Kontextvariablen in JavaScript repräsentiert sein, die Navigation durch Modifikation eines womöglich über mehrere Ebenen der Datengranularität aufgebauten XML-Baums erfolgen und nur
im Falle eines Dimensionswechsels oder Unterschreiten einer Detailstufe das Nachladen von
Daten über einen XSQL-Aufruf erfolgen. Frameworks, die auf eine komfortable interaktive
Benutzerschnittstelle im Web abzielen (z. B. Oracle ADF oder das Google Web Toolkit –
GWT ) könnten ergänzend für eine benutzerfreundliche Gestaltung eingesetzt werden.
Das Filtering ließe sich ggf. verstärkt im Middletier, d. h. durch XSLT vornehmen. Dies
hätte Vorteile für die Integration von Datenquellen, die nur XML als Format liefern können
und keine mächtigen Datentransformationen anbieten. Durch die Weiterentwicklung der
32
XML-Technologie werden die Performance-Nachteile zunehmend eine untergeordnete Rolle
spielen. So hat Oracle mit der neuen Java-Umgebung in der Datenbank-Version 11 einen sog.
„Scalable DOM“ eingeführt, der die Performance von Parsing-Operationen deutlich steigert.
Hinsichtlich der Reaktionszeit einer Applikation kann SVG bei großen Datenmengen, die
in einem Diagramm analysiert werden sollen, an seine Grenzen stoßen. In diesem Fall wird zu
anderen Technologien, z. B. Applets mit Java 2D-Komponenten gegriffen. Entsprechend sind
die Hersteller der SVG-Viewer gefragt, auch ein schnelles Rendering für SVG anzubieten.
Einen großen Vorteil besitzt SVG gegenüber Web-Technologien wie Flex und Silverlight: Es bleibt durch seine Repräsentation als XML-Dokument flexibel weiterverarbeitbar.
Das genannte XSQL Publishing Framework von Oracle ist nur eine Möglichkeit dieses
Potenzial auszuschöpfen. Darüber hinaus existieren (z. B. im Umfeld des Apache Project)
mannigfaltige Möglichkeiten, die vorgestellte Architektur zu erweitern und um Funktionalität
zu ergänzen und damit für spezielle Anwendungsszenarien attraktiv zu machen. Auf der Präsentationsebene könnten parallel Formate wie PDF oder RSS für unterschiedliche Information
Consumer erzeugt werden und im Middletier könnte die Integration von anderen XMLDerivaten wie die Extensible Business Reporting Language (XBRL) [25] erfolgen.
Literatur
[1] http://www.oracle.com/technology/tech/xml/xdkhome.html
[2] http://www.w3.org/Graphics/SVG
[3] Tang, Diane; Stolte, Chris; Bosch, Robert: Design Choices when Architecting Visualizations. In: Proceedings of the IEEE Symposium on Information Visualization 2003 (INFOVIS 2003).
[4] Card, Stuart K.; Mackinlay, Jock D.; Shneiderman, Ben: Readings in Information Visualization: Using
Vision to Think. San Francisco: Morgan Kaufmann 1999.
[5] Rathert, Nikolas A.: Knowledge Visualization Using Dynamic SVG Charts. In: Geroimenko, Vladimir;
Chen, Chaomei (Hrsg.): Visualizing Information Using SVG and X3D. XML-based Technologies for the
XML-based Web. London: Springer 2005, S. 245-255.
[6] http://wiki.svg.org/Viewer_Matrix
[7] König, Kai; Trask, John-Daniel: Im Wettstreit. Flex vs. Silverlight: Unterschiede und Gemeinsamkeiten.
In: iX 2008, Hft. 8, S. 42-46.
[8] Walter, H.-D.: „Rich Internet Applications“ – Eine perfekte Kombination benutzerfreundlicher Schnittstellen mit Webtechnologie. In: Informatik Spektrum 31 (2008), S. 333-343.
[9] Oracle XML Developer's Kit – Programmer’s Guide. 10g Rel. 2 (B14252-01).
[10] Thomas, Michael D.: Oracle XSQL. Combining SQL, Oracle Text, XSLT, and Java to Publish Dynamic
Web Content. Indianapolis (IA): Wiley 2003.
[11] Muench, Steve: Building Oracle XML Applications. Sebastopol (CA): O’Reilly 2000.
[12] White, Jan V.: Using charts and graphs: 1000 ideas for visual persuasion. New Providence (NJ): Bowker
1984.
[13] Shneiderman, Ben: A Task by Data Type Taxonomy for Information Visualization. In: Proceedings of the
IEEE Symposium on Visual Languages 1996 (VL 96).
[14] Kemper, Hans-Georg; Mehanna, Walid; Unger, Carsten: Business Intelligence. Grundlagen und praktische
Anwendungen. 2. Aufl. Wiesbaden: Vieweg 2006.
[15] Ueberschär, Nicole; Winter, André M.: Visualisieren von Geodaten mit SVG im Internet. Band1: Scalable
Vector Graphics – Einführung, clientseitige Interaktionen und Dynamik. Heidelberg: Wichmann 2006.
33
[16] Rodrigues Jr., Jos´e F.; Traina, Agma J. M.; de Oliveira, Maria Cristina F.; Traina Jr., Caetano: Reviewing
Data Visualization: an Analytical Taxonomical Study. In: Proceedings of the IEEE Conference on Information Visualization 2006 (INFOVIS 2006).
[17] Tory, Melanie; Möller, Torsten: Rethinking Visualization: A High-Level Taxonomy. In: Proceedings of the
IEEE Conference on Information Visualization 2004 (INFOVIS 2004).
[18] Bader, Herbert: SVG Reporting. Vektorgrafiken im Web einsetzen. Frankfurt: Software & Support 2004.
[19] Tidwell, Doug: XSLT. 2. Aufl. Sebastopol (CA): O’Reilly 2008.
[20] Mangano, Sal: XSLT Cookbook. 2. Aufl. Sebastopol (CA): O’Reilly 2006.
[21] Chen, Chaomei: Information Visualization. Beyond the Horizon. 2. Aufl. London: Springer 2004.
[22] Scardina, Marc; Chang, Ben; Wang, Jinyu: Oracle Database 10g XML & SQL: Design, Build, & Manage
XML Applications in Java, C, C++, & PL/SQL. New York: McGraw-Hill 2004.
[23] Eisenberg, J. David: SVG Essentials. Sebastopol (CA): O’Reilly 2002.
[24] Powers, Shelley: Adding Ajax. Sebastopol (CA): O’Reilly 2007.
[25] http://www.xbrl.org
[26] http://www.carto.net
Kontaktadresse:
Florian Werner
Universität Tübingen – Lehrstuhl Wirtschaftsinformatik
Melanchthonstr. 30
72074 Tübingen
E-Mail: [email protected]
Telefon: +49(0)7071-2975421
34