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 character-istics and demands. The paper shows how the Scalable Vector Graphics (SVG), a W3C stan-dard for 2D-vector graphics, and the Oracle XML Developer’s Kit (XDK), a XML web devel-opment framework, can be used to meet the requirements of dynamic and interactive dia-grams 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 pro-motes a modular approach to foster the flexibility of a visualization application. The evalua-tion by the implementation of two basically different prototypes gains useful insights for fu-ture 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 data-bases“ (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 Ent-scheidungsfindung 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-, Lini-en- oder Tortendiagramme.

1

Neben generischen Anforderungen, z. B. der dynamischen Generierung der Diagramme aus operativen Daten und der interaktiven Einflussnahme des Benutzers auf die Visualisie-rung während der Datenanalyse, ergibt sich oftmals der Bedarf an einer unternehmensspezifi-schen, 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 An-satz.

Die Stärke umfassender BI-Produkte liegt in der Verarbeitung von heterogenen Massen-daten 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 zu-gänglich gemacht werden sollen, der über die einzelne Führungskraft hinaus geht. Hier man-gelt 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 2D-Vektorformat Scalable Vector Graphics (SVG) [2] die Anforderungen an individuelle Dia-gramme 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) so-wie 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 XML-Dokumenten gezielt gesteuert werden. Die Möglichkeit der flexiblen Transformation lässt sich für die Generierung von Diagrammen effektiv nutzen: Während Inhalts- und Struktur-transformation 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 exis-tieren 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 Be-standteile der Grafik durch Interaktion oder Animation zu beeinflussen oder mit anderen me-dialen 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 offensichtli-che Parallelen zum allgemeinen Prozess der Informationsvisualisierung auf: Bei diesem wer-den zunächst Daten in eine gewünschte Struktur gebracht, dann auf grafische Objekte abge-bildet und schließlich als Diagramm dargestellt. Auch aus diesem Blickwinkel bietet sich demnach die Verwendung von XML an, insbesondere auch deshalb, da durch die Entkopp-lung der Aspekte Datenfilterung, grafisches Mapping und Präsentation Einfluss auf jeden Transformationspunkt des Prozesses durch den Benutzer genommen werden kann. Dies ge-schieht über die genannte Interaktionsmöglichkeit von SVG.

2

Im Hinblick auf Diagramme lässt sich die Funktionalität des XDK sehr effektiv einset-zen, 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 In-

formationen 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ält-nisse 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 3 Männlich 422 88 Weiblich 106 90

Besatzung Männlich 670 192 Weiblich 3 20

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“ be-zeichnet) in unterschiedlichsten Zusammenhängen benötigt. Entsprechend hat sich die Infor-mationsvisualisierung (Information Visualization) als ein eigenes, interdisziplinäres For-schungsgebiet etabliert, das die Erforschung der optimalen Form der grafischen Repräsenta-tion 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 an-deren 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 Kognitions-wissenschaft, 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 ver-meiden, d. h. etwa das Analysewerkzeug mit technischer Funktionalität oder grafischen Ef-fekten 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 durch-laufen 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 ge-eignete 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 Extraction-Transformation-Loading (ETL)-Prozess bekannt.

Für die Umsetzung der einzelnen Transformationsschritte stellt sich die Frage, bei wel-chem Schritt welche Technologie zum Einsatz gelangen soll. Dabei sind sowohl technologi-sche als auch architektonische Alternativen denkbar. So könnte das Filtering, also die Daten-transformation sowohl in der Datenbank als auch außerhalb erfolgen. Das Gesamtsystem könnte entsprechend der Transformationsschritte modularisiert werden, es könnten Mapping- und Rendering-Schritt zusammengefasst werden oder jeder Teilschritt (insbesondere das Fil-tering) sogar in mehrere Module separiert werden. Aus technologischer Sicht wäre zu überle-gen, welche Technologie neben der Datenbank effizient Aggregationen und Strukturtransfor-mationen realisieren kann oder welche Rendering Engine in der Lage ist, eine Vielzahl an grafischen Primitiven schnell darzustellen. Alle Entscheidungen hängen letztlich vom An-wendungsszenario der Nutzung ab, d. h. von Parametern wie dem Umfang der Daten, der In-tegrationsebene der Quellsysteme, der Komplexität statistischer Berechnungen, der ge-wü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 Basis-architektur ein 3-Tier-Modell parallel zu den Transformationsschritten des Visualisierungs-prozesses an. Dadurch wird eine prinzipielle Trennung zwischen Datenhaltung, logischer Weiterverarbeitung inklusive Mapping sowie der Präsentationsebene erreicht, was der Appli-kation Flexibilität in wesentlichen Punkten verleiht. So könnten ggf. im Middletier weitere XML-Datenquellen integriert oder die Ausgabe auf unterschiedliche Endgeräte erweitert wer-den.

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 Er-fahrungen existieren. Auch in einem kleinen Unternehmen bzw. Einsatzradius der Applika-tion 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 Zeitbe-zug aufweisen, lassen sich z. B. komplexe Datumsfunktionen nutzen, die andernfalls aufwän-dig 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 BI-Funktionen 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 je-dem 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än-gig 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 Stan-dards, 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äsentations-beschreibung (z. B. die Textfarbe und -größe) vom eigentlichen Informationsgehalt entkop-pelt 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 inter-pretierbar zu machen.1 In puncto Know-how liegen mit XML ebenfalls zunehmend Erfahrun-gen in KMU vor, oftmals bedingt durch die Rolle als Zulieferer von Großunternehmen, wel-che XML als Format für den Informationsaustausch (Lagerbestand, Produktkatalog etc.) ein-fordern. 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ön- 1 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 Über-führung in ein Präsentationsformat (analog zu HTML) vorgesehen. Da es sich bei Diagram-men in den meisten Fällen um zweidimensionale Grafik handelt, sollte hier ein Präsentations-format 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 sequen-ziell 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 XML-Ausgangsdokument (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-SVG- 20001102/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 75" font-size="50"> x="50" y=" <xsl:value-of select="Projektgruppe/Projektleiter"/> </text> <text "150" font-size="70"> x="200" y= <xsl:value-of select="Projektgruppe/Projektmitarbeiter[1]"/> </text> <text "350" font-size="70"> x="200" y= <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. So-fern eine Datenbank eingesetzt wird, die das XML-Format nativ unterstützt, werden XML-Dokumente ü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 Ver-fügung. Die folgende Abbildung veranschaulicht Basisarchitektur und eingesetzte Technolo-gien 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 Technologieentschei-dung 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 rudimen-tär zur Verfügung. XSLT 2.0/XPath 2.0 kennen dagegen mächtige Aggregat- und Casting-Funktionen, 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 ein-gebunden 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 Wei-se die Implementierung der XSLT Engine erfolgt ist. Im Extremfall wird die Transformation mit einem Fehler abgebrochen, sodass der Benutzer keine Visualisierung zu Gesicht be-kommt. Der nicht kontrollierbaren Transformation im Browser ist daher bei der Generierung von Diagrammen mit SVG, das gegenüber HTML ein vergleichsweise junges Format dar-stellt, 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 XML-Applikation 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 Develo-per’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 proprie-täres Spezifikum einen Adapter zur Verfügung, der aus relationalen Strukturen XML-Dokumente erzeugt. Dies kann für jede Datenbank erfolgen, die über die Java Database Con-nectivity (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 ge-samte Visualisierungsprozess programmatisch unterstützen.

Bevor die Visualisierungs-Lösung näher erörtert wird, sollen die Merkmale und Potenzia-le 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 General-ized Markup Language (SGML) entwickelt, einer Metasprache zur Definition von Auszeich-nungselementen für Textdokumente. Sie wurde als zu komplex und zugleich als zu be-schrä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 verbun-denen 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 ausge-nutzt 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 In-halt, Struktur und Präsentation damit einhergehende fachliche Tätigkeiten, die unterschiedli-che 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 de-ren 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 Ma-nufacturers Association (ECMA) 1998 als Standard definiert wurde. Der konkrete JavaScript-Umfang unter-scheidet 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 syntakti-schen 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 individu-elle Diagramme geschaffen werden, z. B. die Kombination aus CAD-Zeichnung und visuali-sierten Kennzahlen zur Überwachung des CAD-Objekts. Dabei ist die Einbindung des CAD-Objekts sowohl nativ in SVG oder als Rastergrafik (z. B. JPEG3 oder Portable Network Gra-phics – 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 Dialog-ebene 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 An-fang 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 Mobil-telefone 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 bei-tragen, 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 Gre-miums 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 Anima-tion 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 Diagram-me vorgesehen ist, lässt sich der Kreis der unterstützenden Browser für eine Applikation ent-sprechend erweitern. [6]4

Auch zur Verwendung von SVG existieren Alternativen. Als prominentestes Beispiel las-sen 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 gleichzie-hen. So bleibt SVG hinter Flash in puncto Animationen und zeitlicher Synchronisation zu-rü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 Zei-chenprogramme wie Adobe Illustrator, Corel Draw oder das Open Source-Programm Inksca-pe 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 er-mö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 da-von auszugehen, dass weiterhin Parser existieren, die bereits formulierte XML- und XSLT-Dokumente 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]. Zusam-menfassend 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üt-zung der XML-Verarbeitung im Middletier an. Auf einfache Weise lassen sich damit relatio-nal 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 XML-Entwicklungsplattform (Abb. 6). Oracle-spezifisch ist dabei das XML-Derivat XSQL, wel-ches 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 Datenab-frage und Transformation ins Zielformat gegeben, wie es der beschriebenen Basisarchitektur entspricht. Mit geringem Entwicklungsaufwand lassen sich somit schnell Daten im Web pu-blizieren, 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]:

Der Browser sendet einen Request mit dem Unified Ressource Locator (URL), z. B. http://www.myserver.de/myXSQLPage.xsql des angeforderten XSQL-Dokuments 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 (Co-debsp. 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

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 obi-ges Beispiel per Default wie folgt aus (Codebsp. 5):

Ilfnf

Ds

DXd

<?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

n der Ausgabe ist im Beispiel die Referenz auf das Stylesheet notiert worden. Tatsäch-ich würde die XML-Seite mit den Daten nur dann im Browser zur Ansicht kommen, so-ern die zweite Zeile mit <!-- foo --> auskommentiert würde. Die Möglichkeit, zu-ächst nur die reinen Daten in XML-Form im Browser zu betrachten, unterstützt den ef-izienten Test einzelner Entwicklungsschritte.

as XML-Dokument wird vom XSQL Page Processor gemeinsam mit dem zwischenge-peicherten Verweis auf das XML Stylesheet an den XSLT Processor übergeben.

er XSLT Processor wandelt unter Verwendung der Transformationsanweisungen im STL-Dokument (.xsl) das XML-Dokument in ein Zielformat um; in unserem Fall ist ies 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 Daten-typ 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 Daten-bank zurückgespeichert werden. Zudem lassen sich für die Ablaufumgebung in der Konfigu-rationsdatei XSQLConfig.xml differenzierte Caching- und Fetching-Parameter zur Optimie-rung der Performance einstellen. Der Connection Pool ist ebenfalls zu konfigurieren und die Verbindungen zu unterschiedlichen Datenbanken können über Aliasnamen abstrahiert wer-den. Für spezielle Funktionalität erlaubt das Framework sowohl die Erweiterung auf Daten-ebene (XSQL) als auch auf Transformationsebene (XSLT). So ist es möglich für die XSQL-Datei eigene Action Handler via <xsql:action handler="myActionHandler"> zu implementieren, deren Verweis auf die jeweilige Java-Klasse ebenfalls in der XSQLCon-fig.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 Transfor-mation zum Einsatz kommen können. Die über 500 Seiten umfassende Dokumentation des XDK beschreibt detailliert weitere Möglichkeiten, wie das Framework bestimmten Anforde-rungen gerecht werden kann, z. B. den Aufruf aus Java Server Pages (JSP), von der Kom-mandozeile 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 De-velopment 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 Neukompila-tion 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 voll-stä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 Versionsnum-mer 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 Informationsbe-darf, 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 gemein-sam 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 emp-fiehlt es sich allerdings, die Beschreibung des Datenimports aus dem separaten XML-Konfigurationsdokument heraus zu lösen und im XSQL-Dokument zu platzieren. Die Dia-grammbeschreibung verbleibt dagegen in einem eigenen XML-Dokument und wird durch den Action Handler <xsql:include-xml href="myXML.xml"> in das XSQL-Dokument im-portiert. Da der XSQL Page Processor die sequenzielle Verarbeitung mehrerer Transforma-tionen durch den Action Handler <xsql:include-xsql href="myXSQL.xsql"> bietet, kann in einem ersten Schritt die Transformation in eine für Diagramme optimierte Basisstruk-tur 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) beschrie-ben 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 Kombina-tion 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 unterschiedli-chen 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 Aus-wahl einer Ebene mit feinerer Granularität der Daten) erfolgen soll. Prinzipiell wäre auch eine einstufige Transformation denkbar, sofern Diagramm- und Datenbeschreibung in einem ein-zigen 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 For-

men aus unterschiedlichsten Kontexten. Neben gängigen Formen wie Säulendiagramm, Tor-tendiagramm 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 Verkaufsum-satz) 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 Visuali-sierung 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.: Liniendia-

gramm, 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 Rei-he möglicher Diagrammelemente konstruiert. Als Diagrammelemente, die aus Daten beim Mapping in Zeichenobjekte erzeugt werden, lassen sich unterscheiden [12]:

• Canvas = gesamte Zeichenfläche • Diagram Area = eigentliche Diagrammzeichenfläche • Data Object = Datenobjekte, z. B. Datenpunkt, Linie, Säule, Kreisausschnitt... • Axis = Achse

6 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 mehre-rer 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 Dia-grammtyp 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 Ther-mometer 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 boole-scher Ausprägung enthält. Beim Thermometer wird dagegen eine fortlaufende, kardinale Ska-la eingesetzt (i. d. R. intervallisch beschränkt, je nach Anwendungsfall z. B. für die Wetterbe-schreibung 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 abge-bildet, 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üll-eimer für Löschoperationen von Dokumenten o. ä.).

17

0 10

1320

50

-50

100 212

122

-100 -148

-58

°C °F

0

50

-50

100 212

122

-100 -148

-58

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 erlau-ben, die aktuelle Ansicht seiner Datenmenge, des sog. „Data Cube“ zu modifizieren. Dabei lassen sich Interaktionen unterscheiden, die sich auf verschiedene Schritte des Visualisie-rungsprozesses 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 Weiterverarbei-

tung

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, Map-ping, 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, wel-chen Typs das Diagramm sein soll und welche der genannten Interaktionsmechanismen es enthalten soll. Dies geschieht mit Hilfe des in der Visualisierungs-Architektur charakterisier-ten, separaten XML-Dokuments, das als „Diagrammbeschreibung“ bezeichnet ist. Beide Komponenten einer Diagrammkonstruktion sollen kurz beschrieben werden:

8 Dies kann ebenso über Drill-up/down als auch Drill-aside auf den Einstiegsebenen erfolgen. 9 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 Datentopo-logie, welcher Art die verwendeten Skalen sind. Handelt es sich z. B. um unabhängige Daten-sä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 Diagramm-elementen 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 die-sem 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 Daten-bestände in einem einzigen Diagramm abgebildet werden sollen, müssen die durch X-Y-Koordinaten definierten Datenpunkte um weitere grafische Elemente ergänzt werden. Im Bla-sendiagramm 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 Gestal-tungsmittel 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ücksichti-gen. Auf seiner Basis werden die grafischen Objekte durch den zweiten Transformations-schritt, d. h. im gewählten Szenario durch ein XSLT-Stylesheet (dem SVG Template) in Ver-bindung 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 Linien-diagramm 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 zumin-dest nicht mit vertretbarem Aufwand möglich ist, erfolgt die Erstellung der Diagrammbe-schreibung 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 Dia-

grammbeschreibung sowie nötigen Strukturtransformationen ergibt sich analog zur oben kon-zipierten Visualisierungs-Architektur (Abb. 7) die Diagramm-Basisstruktur als XML-Dokument. 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 Diagramm-Konstruktion 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 allge-meingü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 Container-Element eine Hierarchiestufe darunter eingefügt. Die Existenz mehrerer Diagramme ergibt sich aus dem Vorkommen mehrerer Knoten des Elements <diagram> innerhalb dieses Con-tainers. 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 separa-ten 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äulen- und 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. Drill-down oder Drill-aside. Die Existenz eines entsprechenden Elements zieht ggf. weitere Unter-elemente nach sich, welche die Interaktion näher beschreiben. Leider lassen sich in einem XML-Schema Abhängigkeiten zwischen Elementen über die hierarchische Existenz, Reihen-folge und Anzahl hinaus nicht erzwingen. So können trotz der inhaltlich gegebenen Interde-pendenz z. B. keine logischen Abhängigkeiten zwischen Elementen des Teilbaums <data-set> 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 Ele-ment <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 Defini-tionen 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 Diagramm- und 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 wer-den. 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 X- und 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 kon-kreten 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"> <dataset> <xsql:include-xml href="dgr_config.xml"/>

<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 Dia-grammbeschreibungen in einer einzelnen XML-Datei enthalten sein, müsste die Zusammen-

25

gehörigkeit der jeweiligen Diagramm- und Datenbeschreibung durch die konsistente Reihen-folge 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 Diagramm-Basisstruktur vornimmt, wird hier verzichtet, da es sich um eine einfache Strukturtransforma-tion 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 Eigenentwick-lung 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 einfa-che Farbgebung sondern auch Farbverläufe und Muster sowie Filtereffekte anwendbar. Zu-dem können Transformationen des zweidimensionalen Vektorraums inkl. einfacher Matrix-transformationen 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 SVG-Dateien 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 For-meln zufriedenstellend berechnet werden. [5, 18, 19, 20]

26

Fgahv

SgsrTaG

<?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-SVG- 20001102/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}" t + $y_value}" r="{$dp_weight}" class="dgrDatapoint"/> cy="{$yoffse </xsl:template>

Codebsp. 8: Mapping von Daten auf SVG-Elemente

ür jeden Datensatz (two_dim_item) wird das Template mit dem Namen datapoints auf-erufen und ein Kreis mit dem Radius dp_weight erzeugt. Die Y-Position ergibt sich direkt us dem Wert des Knotens y_value zuzüglich eines Offsets. Die X-Position ist dagegen ab-ängig von der relativen Position des Datensatzes im XML-Baum (rowIdx), dem Standard-ersatz 20 und ebenfalls einem Offset.

Neben den Template-Anweisungen für die Erzeugung der SVG-Elemente wird in dem tylesheet auch ein größerer Abschnitt der Berechnung wichtiger Diagrammeigenschaften ewidmet sein, die in Variablen mit der Anweisung <xsl:variable> abgelegt werden. Dies ind z. B. die Größe der Diagrammzeichenfläche, die Anzahl der Datensätze, das Skalie-ungsmaß für eine X- bzw. Y-Einheit oder der maximale X- und Y-Wert. Beim Aufruf eines emplates, das ein bestimmtes Diagrammelement zeichnet, werden dann diejenigen Variablen ls Parameter übergeben, die für die Bestimmung der Eigenschaften des Elements (Position, röß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 visualisie-ren, müssen zudem Elemente erzeugt werden, welche die gewünschten Diagramminteraktio-nen umsetzen. SVG bietet drei Möglichkeiten, um grafische Elemente bzw. Text mit Interak-tivitä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 Ani-mationen 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 Ge-schichtsverlauf.

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 ge-zeigt – separat in der oben angeführten Basisstruktur zu beschreiben. Individuelle, komplexe Interaktionen müssten dagegen im SVG Template des jeweiligen Diagrammtyps situativ er-gä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 separa-tion 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 Transforma-tionsstufe 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, wel-cher 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 Kontextoperatio-nen nötig.

28

Das XSQL Publishing Framework bringt durch seinen allgemeingültigen Ansatz die Ein-schrä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 ange-botenen APIs zurückgreifen. Wird eine Seiten-basierte Navigation der Applikation gewählt, sind zwischen den SVG-Seiten daher Parameter zu übergeben, die den Diagrammkontext re-prä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 übergebe-nen Parameter in die vom XSQL Page Processor erzeugte XML-Datei der Daten, so-dass 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 Zielgranu-larität im Monat Januar besteht. Damit wäre durch den Navigationspfad der elementare Kon-text für das Zieldiagramm gegeben.

Evaluation

Prototyp

Zur Evaluation des Konzepts wurden zwei Diagramme mit unterschiedlichen Eigenschaf-ten 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. ECMA-Script-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 visuel-len Kontext werden weitere, steuerbare SVG-Elemente gezeichnet. Neben einer Überblicks-ansicht 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 In-formation auf der Makroebene ein Zoom in die Mikroebene vornehmen. Hier werden zusätz-liche 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 Verarbei-tung von SVG erprobt. Der Prototyp wurde unter Verwendung der ursprünglich für Karten entwickelten Biblio-theken von carto.net [26] umgesetzt. Die Module des Open Source-Frameworks bieten eine gute Basis für kom-plexe 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 differenzier-te 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 benutzer-freundliche 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 ver-fü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 Ska-len 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 durchzu-fü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 Applika-tion.

Das sog. Painter Model von SVG, d. h. die Überdeckung von Elementen bei nachfolgen-der 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 eige-nes 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 konstruie-ren, indem nur die dafür benötigten Templates integriert werden. Die Modularisierung sollte sich zudem auch auf gesamte Diagramme beziehen, damit Ansichten mit mehreren unter-schiedlichen Diagrammtypen zusammengestellt werden können (Dashboards, Diagramm im Diagramm etc.).

Hinsichtlich der Werkzeug-Unterstützung der Entwicklung besteht noch Bedarf. So exis-tiert im JDeveloper über die Prüfung der XML-Konformität hinaus momentan keine Unter-stützung der Syntax von SVG. Entsprechend lassen sich komfortable Unterstützungsfunktio-nen 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. Aller-dings ist angesichts der Komplexität der Parameterübergabe über mehrere Stufen einer Archi-tektur hinweg auch über die Seiten-basierte Navigation und den dabei schwer herzustellenden Diagrammkontext nachzudenken. Bei funktional mächtigeren Applikationen ließen sich wei-tere 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 Objek-ten [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 Kontext-variablen in JavaScript repräsentiert sein, die Navigation durch Modifikation eines womög-lich ü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 Silver-light: 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 XML-Derivaten 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: Proceed-ings 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 Schnittstel-len 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 Informa-tion 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: florian.werner@uni-tuebingen.de Telefon: +49(0)7071-2975421

34