Exploration komplexer OLAP-Daten in einem Pivot-Tabellen-Interface

Transkript

1 Universität Konstanz, FB Informatik und Informationswissenschaft, Masterstudiengang Information Engineering Exploration komplexer OLAP-Daten in einem Pivot-Tabellen-Interface Masterarbeit zur Erlangung des akademischen Grades eines Master of Science (M.Sc.) von Marion Herb Matrikel-Nr.: 01/ Erstgutachter: Prof. Marc H. Scholl Zweitgutachter: Prof. Oliver Deussen Betreuerin: Svetlana Mansmann Einreichung: 22. Dezember 2006

2

3 Zusammenfassung Im Rahmen des Projektes UniVis Explorer wird ein visuelles Data Warehouse, basierend auf einer OLAP-Architektur und einem multidimensionalen Datenmodell, für deutsche Hochschulverwaltungen entwickelt und implementiert. Durch geeignete Visualisierungstechniken werden die Benutzer des Systems, die Mitarbeiter in Verwaltung und Lehre, bei der Exploration und Analyse der universitären Daten unterstützt. Um korrekte Analyse-Ergebnisse zu gewährleisten, müssen die verwendeten Daten OLAP-konform sein. Die Institutionen an einer Hochschule sind jedoch oftmals hierarchisch aufgebaut und besitzen strukturelle Abhängigkeiten. In dieser Arbeit werden die Unregelmässigkeiten in den Daten beschrieben, die der Implementation vorausgehend konzeptionell modelliert und in ein normalisiertes Schema transformiert werden mussten. Die Aufgabenstellung besteht in der Implementation einer Pivot-Tabellenbasierten Datenexploration und deren Integration in das Data Warehouse-Frontend UniVis Explorer. Die Umsetzung der Benutzerinteraktion in eine Datenbanksprache sowie die Aufbereitung der Datenbank-Ergebnisse in eine für eine Pivot-Tabellen-- Darstellung geeignete Form, waren weitere Herausforderungen. Organisatorisch verflochtene Daten müssen mit großer Sorgfalt modelliert werden. Durch adäquate Transformationen der unförmigen Basisdaten in ein regelmässiges, für OLAP-Anwendungen problemlos zu verarbeitendes, Schema und die Integration der Visualisierungstechnik Pivot-Tabelle, konnte eine für den Hochschul-Einsatz geeignete Anwendung implementiert werden. Abstract Within the scope of the UniVis Explorer project a visual data warehouse for academic management is designed and implemented. The system is built based on OLAP architecture and its underlying multidimensional data model. Both the administrative department of the university as well as lecturers are supported when visually exploring and analyzing the data with appropriate visualization techniques. Applied data needs to be OLAP-conform in order to assure correct analyses results. However, academic organizations are often based on hierarchies and hold structural dependencies. This study describes existing irregularities within the data which needs to be modelled conceptually and transformed into a normalized scheme before implementing the pivot table. The main scope of this thesis lies within the implementation of a pivot-table-based data exploration and its integration into the data warehouse front-end UniVis Explorer. Transforming user interactions into a database language and formatting the emerging database results into a format convenient for pivot table presentation are additional challenges dealt with in this study. Organizationally merged and structured data needs to be modelled carefully. With the help of adequate transformation techniques, the bulky micro data needs to be pushed into a regular scheme so that OLAP applications may smoothly handle the data. The visualization technique pivot table can then be integrated into the visual data warehouse. 3

4

5 Inhaltsverzeichnis Inhaltsverzeichnis 5 Abbildungsverzeichnis 8 Tabellenverzeichnis 10 Einleitung 13 1 Grundlagen und Fallstudie UniVis Explorer Data Warehouse und OLAP Kooperationspartner SuperX Aufbau von SuperX Testdaten Das multidimensionale Datenmodell Grundidee Fakten Kennzahl Dimensionen Würfel Operationen auf multidimensionalen Daten Projektionen im Würfel Funktionen des OLAP Modellieren der multidimensionalen Daten Das konzeptionelle Schema Schemaformen MOLAP und ROLAP Das relationale Schema Das erweiterte multidimensionale Datenmodell Dimensionshierarchien Klassifikation der Dimensionshierarchien Homogene vs. heterogene Dimensionen Modellierungsanforderungen

6 INHALTSVERZEICHNIS Modellierungsfallen Bedingungen für Summierbarkeit Typverträglichkeit von Fakt und Aggregationsfunktion SuperX-Schema- und Datentransformation Schritt: Vom Pseudo-Sternschema zum Schneeflockenschema Schritt: Trennen von Kennzahlen und Dimensionen Schritt: Transformation von Dimensionshierarchien Schritt: Datennormalisierung Hierarchische Visualisierung mit Pivot-Tabellen Front End-Werkzeuge für ein Data Warehouse Hierarchische Visualisierungstechniken Aufbau und Funktionsweise einer Pivot-Tabelle Tabelle vs. Kreuztabelle vs. Pivot-Tabelle Struktureller Aufbau Manipulation von Pivot-Tabellen Darstellung der Zwischenaggregate Marktübersicht der Pivot-Tabellen-Interfaces Joolap CEUS-HB Tableau Software Fazit Framework Multifunktionswerkzeug Schemabrowser Datenbrowser vs. Schemabrowser Schemabrowser UniVis Explorer Fazit Benutzeroberfläche UniVis Explorer Interaktion mit der Pivot-Tabelle Zuordnung der Dimensionen Navigation in hierarchischen Dimensionen Aggregieren entlang verschiedener Dimensionen Weitere Manipulationen Visualisierung verschiedener Hierarchien Im Schemabrowser In der Pivot-Tabelle Implementation SQL und OLAP

7 INHALTSVERZEICHNIS Technische Details der Implementation Übersetzung der Benutzeraktionen in SQL Ausblick Verhindern von Interpretationsfehlern Erweiterung der Funktionalität des Schemabrowsers Anzeige von Pivot-Tabelle und weiterer Visualisierung Anhang 82.1 Beispiel: SQL-Abfrage einer Pivot-Tabellen-Darstellung Literaturverzeichnis 85 7

8 Abbildungsverzeichnis I Aufbau SuperX und Integration UniVis Explorer II Datenwürfel mit Studierendenzahlen III Dimensionshierarchie und -knoten sowie Hierarchieebenen IV Klassifikationspfade V Projektionen im dreidimensionalen Datenwürfel VI Universitäts-Data Warehouse-Schema in ME/R-Notation VII SuperX-Würfel Studierendenstatistik in Pseudo-Sternschema VIII Würfel Studierendenstatistik als Schneeflockenschema IX Verschiedene (nicht) hierarchische Dimensionen X Verschiedene hierarchische Dimensionen XI Multiple Hierarchien in der Dimension Land XII Unregelm. Datenbaum der zentralwissenschaftlichen Einrichtung.. 45 XIII Schemastruktur der transformierten Institutionen-Hierarchie XIV Regelmässiger Datenbaum der zentralwissenschaftlichen Einrichtung 46 XV Unregelmässiger Datenbaum der organisatorischen Einheiten XVI Regelmässiger Datenbaum der organisatorischen Einheiten XVII Festplatten-Visualisierung über eine Treemap XVIII Cone Tree einer hierarchischen Organisation XIX Zeilen-, Spalten-, Seiten- und Datenfeld einer Pivot-Tabelle XX Studierendenzahlen abhängig von Zeilen- bzw. Spaltenvariable XXI Studierendenzahlen abhängig von Zeilen- und Spaltenvariable XXII Geschachtelte Pivot-Tabelle XXIII Pivot-Tabellen-Interface von Joolap XXIV Joolap-Operation Schachtelung XXV Pivot-Tabellen-Interface von CEUS-HB XXVI Pivot-Tabellen-Interface von Tableau Software XXVII Navigationsbrowser über Daten- und Schemastruktur XXVIII Schemabrowser UniVis Explorer

9 ABBILDUNGSVERZEICHNIS XXIX Schematische Aufteilung des UniVis Explorer XXX UniVis Explorer mit Pivot-Tabellen-Visualisierung XXXI Geschachtelte Pivot-Tabelle für das Zeilenfeld XXXII Visualisierung versch. Hierarchien im Schemabrowser XXXIII Visualisierung versch. Hierarchien in einer Pivot-Tabelle XXXIV Parallele Exploration in Decomposition Tree und Pivot-Tabelle

10 Tabellenverzeichnis I Ausschnitt der Tabelle mit Studierendenzahlen II Ausschnitt einer denormalisierten Dimensionstabelle Nationalität III IV V VI Summierte und durchschnittliche Haushaltskosten in Tausend-Euro für ein akademisches Jahr über mehrere Institute Studierendenzahlen pro Fakultät und akademischem Jahr (Studium mit Regelstudienzeit drei Jahre, Beginn 1999/2000) Studierendenzahlen pro Studienfach und Akademischem Jahr (Dreijähriges Studium, mehrfache Fachbelegung möglich) Haushaltskosten pro Institut und Lehreinheit in Tausend-Euro (für zwei akademische Jahre, Lehreinheiten sind Institute und Fächer) VII Summierbarkeit abhängig von Aggregationsfunktion und Faktentyp.. 42 VIII Ergebnistupel dreier Anfragen über die Zeitdimension IX X Ergebnistupel der Unteranfrage nach Länder, Abschluss und Allgemeiner Hochschulreife Ergebnistupel der Unteranfrage nach Länder, Abschlußtyp, Allgemeiner Hochschulreife und Fachhochschulreife

11

12

13 Einleitung Motivation und Zielsetzung Vor dem Hintergrund aktueller Diskussionen um Hochschulrankings und Elite-Universitäten sowie der leistungsorientierten Mittelverteilung, ist der Wunsch auch an Hochschulen eine visuelle Exploration und Analyse der universitären Daten zu betreiben, um konkurrenzfähig zu sein, nachvollziehbar. Immer häufiger werden also auch an Hochschulen für die Entscheidungsunterstüzung typischerweise Data Warehouse- Systeme und -Front-Ends eingesetzt. Dem schnellen Vorgehen bei der Einführung dieser Systeme steht die Komplexität der zu analysierenden Daten gegenüber. So sind Organisationsstrukturen einer Hochschule hierarchisch und besitzen kein regelmässiges Datenschema. Man denke beispielsweise an Institutionen wie Verwaltungseinheiten, Lehrstühle, Institute und Abteilungen, die organisatorisch miteinander verflochten sind. Ausserdem sind diese Strukturen ständiger Veränderung unterworfen, ausgelöst durch interne Reorganisationen und das dynamische Wachsen der Strukturen. Der schnelle, intuitive und flexible Zugriff auf Daten über Data Warehouse-Interfaces ist ein kritisches Element. Davon hängt der Nutzen, den die Organisation aus dem Einsatz eines solchen Systems zieht, ganz entscheidend ab. Damit die Benutzer effektiv auf die akademischen Daten im Universitäts-Data Warehouse zugreifen können, wird ihnen ein benutzerfreundliches Front-End bereitgestellt. Für Mitarbeiter in der Verwaltung sind Pivot-Tabelle ein bekanntes und intuitiv zu bedienendes Standardwerkzeug. Ausserdem ist die Visualisierungstechnik Pivot-Tabelle, aufgrund der typischen geschachtelten Darstellungsweise der Daten, besonders gut für die Exploration hierarchischer Daten geeignet. Sie erlaubt seinen Benutzern speziell auf hierarchische Strukturen ausgelegte Operationen auszuführen. Aufgrund dieser Vorzüge wurde sie als eine Visualisierungstechnik in die Anwendung integriert. Anhand eines universitären Fallbeispiels wird der Bogen gespannt von der Transformation des Schemas und der Daten in eine regelmässige Struktur, bis zur Implementation des Pivot-Tabellen-Interfaces. Die Umsetzung von Benutzerinteraktionen in eine Datenbanksprache, die die Ergebnisse in einer auf die Pivot-Tabelle angepassten Form zurückliefert, sind die Herausforderungen, die in dieser Arbeit beschrieben werden. 13

14 TABELLENVERZEICHNIS Projektgruppe UniVis Der UniVis Explorer 1 ist ein Projekt der Arbeitsgruppe Datenbanken und Informationssysteme 2 der Universität Konstanz und wird gefördert vom Graduiertenkolleg Explorative Analysis and Visualization of Large Information Spaces 3. In der Projektgruppe UniVis wird das visuelle Data Warehouse für deutsche Hochschulverwaltungen als Java-Applikation, bestehend aus mehreren Komponenten, entwickelt und implementiert. Über einen Schemabrowser kann der Benutzer die hierarchischen Datenstrukturen mithilfe einer Decomposition-Tree- und der Pivot-Tabellen- Darstellung analysieren. Weitere Teammitglieder im Projekt UniVis Explorer sind Svetlana Mansmann, Roman Raedle und Andreas Weiler. Svetlana Mansmann betreute meine Arbeit und stand jederzeit, auch am Wochenende, für meine Fragen zur Verfügung. Roman Raedle und Andreas Weiler implementierten im Rahmen ihres Projektpraktikums und ihrer Bachelorarbeit die Decomposition-Tree-Visualisierung. Von der von den beiden Studierenden aus dem Decomposition-Tree und der Pivot-Tabelle zusammengeführten Applikation stammen die Screenshots (siehe Kapitel 4 Framework). Gliederung der Arbeit Die Arbeit gliedert sich in folgende Teile: In Kapitel 1 werden grundlegende Begriffe aus dem Bereich Data Warehouse und Konzepte des multidimensionalen Datenmodells, anhand universitärer Testdaten des Projektes UniVis Explorers, vorgestellt. Darauf aufbauend wird in Kapitel 2 eine Erweiterung des multidimensionalen Datenmodells beschrieben. Diese Erweiterung soll den komplexen Strukturen, gegeben durch heterogene und gemischt-granulare Aggregationshierarchien gerecht werden. Bedingungen für korrekte Aggregation und daraus resultierende Modellierungsanforderungen des Datenschemas werden gezeigt. Kapitel 3 widmet sich dem Aufbau und den Manipulationsmöglichkeiten einer Pivot- Tabelle. Einige auf dem Markt vorhandene Visualisierungswerkzeuge mit Interfaces in Pivot-Tabellen-Manier werden getestet und die Evaluationsergebnisse skizziert. Im Framework-Kapitel 4 steht die Umsetzung des Pivot-Tabellen-Darstellung im Vordergrund. Benutzerinteraktionen werden in die Datenbanksprache SQL übersetzt und eine Visualisierung mit der Pivot-Tabelle erzeugt. Die Abbildung von heterogenen und multipel granularen Hierarchien im Schemabrowser und der Pivot-Tabelle wird dokumentiert und mit Screenshots versehen. 1 Projekt-Website: (Abgerufen ) 2 Database & Information Systems Group (Abgerufen ) 3 Graduiertenkolleg / PhD Graduate Program (Abgerufen ) 14

15

16

17 Kapitel 1 Grundlagen und Fallstudie UniVis Explorer Data Warehouse-Konzepte und -Anwendungen zur visuellen Exploration werden an einem Fallbeispiel mit Daten einer Hochschule vorgestellt. Die Vermittlung der Grundlagen erfolgt anhand der speziellen Strukturen der universitären Testdaten. Die Umsetzung in ein geeignetes konzeptuelles und relationales Datenmodell steht dabei im Vordergrund. 1.1 Data Warehouse und OLAP In einem Data Warehouse werden Daten für statistische Auswertungen und Analysen getrennt von den operational betrieblichen Anwendungsdaten gespeichert [35, S.671]. Daten aus unterschiedlichen Quellen werden zyklisch geladen und dienen als zentrale Datensammlung für anspruchsvolle Entscheidungsprozesse in Unternehmen. Ein Data Warehouse ist im Allgemeinen themenbezogen, integriert, zeitveränderlich und nicht-flüchtig [35, 671]. Anwendungen des OLAP (On-Line Analytical Processing) greifen auf die Daten in einem Data Warehouse zu. OLAP wird zur Informationsaufbereitung großer Mengen operativer und historischer Daten und als Analyse- und Planungswerkzeug in vielen Branchen wie dem Bankenwesen, dem Handel, der Industrie sowie im Dienstleistungssektor eingesetzt [4]. Es stellt eine Applikation einschließlich ihrer Front-End-Werkzeuge dar und ermöglicht den Benutzern die Daten interaktiv abzufragen, zu explorieren und zu analysieren. Die meisten OLAP-Systeme besitzen die folgenden Funktionen [19, S. 317]: Multidimensionale Repräsentation von Geschäftsdaten Verdichtung multidimensionaler Daten Navigation in Hierarchien zur Bildung von Detaildaten Unterstützung von Anfragen entlang der Zeitdimension Unterstützung der Generierung von Analysen- und Szenarien Konstante Antwortzeiten unabhängig der Anfragekomplexität 17

18 KAPITEL 1. GRUNDLAGEN UND FALLSTUDIE UNIVIS EXPLORER 1.2 Kooperationspartner SuperX SuperX ist ein Hauptvertreter für visuelle akademische Data Warehouses in Deutschland. Die baden-württembergische Landesregierung unterstützt die Einführung von SuperX an den Hochschulen. Das universelle Hochschulinformationssystem SuperX ist für eine Anwendergruppe aus Rektoratsmitarbeitern, Fakultätsdekanen, Professoren und Mitarbeitern der Universitätsverwaltung konzipiert und soll an deutschen Hochschulen zum Wissensmanagement, zum Controlling und zur Hochschulsteuerung eingesetzt werden. Verschiedene Benutzergruppen machen ein Berechtigungskonzept notwendig, um einzelnen Anwendern oder Anwendergruppen Zugriffsrechte auf bestimmte Sachbereiche zu geben. Entstanden ist SuperX aus einem Projekt der Universität Karlsruhe in den 90er Jahren als Berichtssystem für Hochschulen. Die Abkürzung SuperX ging ursprünglich auf System zur Unterstützung von Planung und Entscheidung des Rektorats durch Information, Controlling und Simulation zurück. Es wurde sukzessive zu einem Data Warehouse-System für Hochschulen weiterentwickelt, und Die Weiterentwicklung des Open Source Produkts sowie die Beratung der Hochschulen bei der Einführung und der Pflege des Systems übernimmt die Firma MemText Aufbau von SuperX SuperX besteht aus einem Datenbank-Server und mehreren Anwendungen. Abbildung I zeigt am Beispiel SuperX die typische Gliederung eines Data Warehouse Systems in Datenquellen, Data Warehouse und Front-Ends [17, S. 18ff]. Abbildung I: Aufbau SuperX und Integration UniVis Explorer Datenquellen Daten aus unterschiedlichen Quellen des Hochschulbereichs werden gebündelt wobei das Hochschul-Informations-System HIS 2 mit den Verwaltungssystemen SOS und COB als Datenquelle dient. Das Modul SOS ist für die Daten-Laderoutine aus dem operativen Informationssystem HISSOS zuständig und ermöglicht u.a. die zentrale Erfassung der Studierenden- und Absolventendaten, die von Stellen innerhalb und 1 Website: (Abgerufen ) 2 Website: (Abgerufen ) 18

19 Kooperationspartner SuperX 1.2 außerhalb der Hochschule benötigt werden. Des Weiteren können damit Vorgänge wie Einschreibung, Rückmeldung und Studienfachwechsel abgewickelt werden. Das Modul COB extrahiert Daten aus HISCOB und beinhaltet die Kosten- und Erlösanalyse für die Kostenstellen und -träger. Weiterhin bildet es die innerhochschulischen Leistungsverflechtungen ab. Auf Lehreinheiten- und Studiengangsebene kann die Hochschulplanung unterstützt werden, wenn z.b. eine Reorganisation geplant ist. Konkret können mit den Daten die Kosten einer Hochschule nach Personal- und Sachkosten, Miete und Abschreibung analysiert werden. Weitere Module für spätere Integration sind Statistiken zu Stellen und Personal (das Modul SVA verwaltet z.b. das wissenschaftliche Personal pro Fachbereich), zur Finanzund Sachmittelverwaltung (Modul FSV z.b. Drittmittelausgaben pro Institution), zu Gebäude- und Flächennutzung (Modul BAU z.b. Raumausstattung), zur Zulassungsverwaltung (Modul ZUL) oder Kombinationen von Modulen um übergreifende Aussagen zu treffen (z.b. Auswertungen Lehrbeauftragte pro Studierende). Ferner können Datenquellen integriert werden, die nicht von HIS stammen. Data Warehouse In einer Datenbank werden die zu analysierenden Daten und das Schema des multidimensionalen Datenmodells gespeichert. Im festgelegten Rhythmus, z.b. nach einem Hochschulsemester, werden die in der Regel historisierten Daten [10, S. 13] geladen. SuperX enthält eine relationale Datenbank, worauf das OLAP-Front-End Joolap (mehr in Abschnitt 3) basiert. Die Daten der Joolap-Datenbank, die SuperX zur Verfügung stellte, werden nach der Transformation als Basis für den UniVis Explorer verwendet. Dazu später mehr. Front-Ends Für die Analyse und Auswertung der Daten existieren verschiedene Benutzeroberflächen, die folgenden bietet SuperX an: vordefinierte Ergebnistabellen für das allgemeine Berichtswesen in einem Applet Aufbereitung komplexer Berichte aus mehreren Ergebnistabellen in einem XML- Front-End Joolap für multidimensionale OLAP-Analysen Im Wesentlichen sprach die Plattformunabhängigkeit für eine Kooperation mit SuperX. Existierende kommerzielle Lösungen im Business Intelligence Bereich von Branchenriesen wie Oracle 3 oder SAP 4 sind zudem für öffentliche Institutionen wie Universitäten nicht finanzierbar. 3 Oracle Corporation, Website: (Abgerufen ) 4 Anwendung Business Information Warehouse der SAP AG, Website (Abgerufen ) 19

20 KAPITEL 1. GRUNDLAGEN UND FALLSTUDIE UNIVIS EXPLORER Testdaten Die Installation von SuperX auf dem Projektserver umfasst das Data Warehouse System sowie das Datenbanksystem PostgreSQL 5. Die hier verwendeten Testdaten bilden die universitäre Struktur von Verwaltung und Lehre ab und enthalten Statistiken zu Studierendenzahlen und Haushaltskosten über ein akademisches Jahr der Gerhard-Mercator-Universität Duisburg. An anderen Hochschulen weicht daher die Struktur der Administration und der Lehreinheiten vom vorgestellten Schema ab. SuperX stellte Testdaten zur Verfügung, da es keine eigenen Zahlen der Universität Konstanz gibt bzw. diese nicht verfügbar gemacht werden konnten. Die Testdaten sind zum einen Studierendenzahlen aus dem Modul Studierenden-Statistik SOS und zum anderen fiktive Bestellungen der organisatorischen Einheit aus dem Modul Kostenund Leistungsrechnung COB. Dabei wurden die Studierendenzahlen nicht personengenau erfasst. Es existieren also nur verdichtete Studierendenzahlen für Gruppen, die dieselben Eigenschaften besitzen (Fachsemester, Nationalität etc.). Der Faktenwürfel Studierendenstatistik beinhaltet ca und der Faktenwürfel Haushaltskosten Transaktionen. Die Würfel sind jeweils 2,3 bzw. 1,7 Megabytes und das komplette Data Warehouse inklusive aller Dimensionstabellen 14,6 Megabytes groß. 1.3 Das multidimensionale Datenmodell Die Hochschule verwaltet also Studierendenstatistiken sowie ihre Haushaltskosten, um zum einen Einschreibungszahlen und zum anderen die Ausgaben z.b. je institutionelle Einheit oder pro Projekt zu analysieren. In diesem Kapitel werden am Fallbeispiel die Grundbegriffe von multidimensionalen Datenmodellen eingeführt Grundidee Das multidimensionale Datenmodell, das dem Data Warehouse zugrunde liegt, wird über Fakten, Kennzahlen, Dimensionen sowie einen Würfel als visuelle Metapher charakterisiert. Die Fakten sind die zu analysierenden Transaktionen und werden durch Dimensionen wie Zeit und Organisation beschrieben. Die Dimensionen besitzen eine Struktur, gebildet durch das Schema, und Instanzen. Das Schema ist ein zyklusfreier gerichteter Graph mit unterschiedlichen Granularitäten für jede Stufe. Eine Instanz besitzt für jede Stufe ein Set an Elementen, die Dimensionsknoten. Die Elemente einer Stufe können durch Roll-Up-Funktionen auf die nächsthöhere Dimensionsebene abgebildet werden [12, S. 1], wodurch sich verschiedene Kennzahlen für die Aggregationsstufen ergeben. Analysiert werden die Daten durch Operationen auf dem Würfel wie durch Verringern oder Erhöhen der Dimensionen oder durch Selektion von Teilen des Würfels. In Abbildung II wird ein Ausschnitt des Data Warehouse, beruhend auf den Daten aus Tabelle I, abgebildet. Dargestellt sind Studierendenzahlen mit den Eigenschaften 5 Objektrelationales Datenbankverwaltungssystem, Website: (Abgerufen ) 20

21 Das multidimensionale Datenmodell 1.3 Fachsemester Herkunftsland Abschlußart D FH I II Sek I Primarstufe AT FH Tabelle I: Ausschnitt der Tabelle mit Studierendenzahlen Abschlußart, Fachsemester und Herkunftsland. Die dunkel markierte Zelle stellt die Anzahl der Studierenden, hier beispielsweise fünf, die das Diplom II anstreben, aus Deutschland stammen und sich im 3. Fachsemester befinden dar. 6 Abbildung II: Datenwürfel mit Studierendenzahlen Fakten Im universitären Kontext können Fakten Prüfungen, Kursteilnahmen oder Bestellungen sein. Fakten sind die tiefste Informationsebene und werden durch eine Kombination von Dimensionen definiert. Dabei besitzen sie quantifizierende und qualifizierende Eigenschaften: der numerische Aspekt ist die Kennzahl 7 als Ergebnis einer Ag- 6 Der universitäre Abschluß Diplom wird in mehrere Unterklassen gegliedert, wobei FH für den Fachhochschulabschluss steht und sich der Diplom I- vom Diplom II-Studiengang durch seine Regelstudienzeit unterscheidet. Des Weiteren wird das Lehramt-Studium unterteilt in Studium des Lehramts an Schulen für die Sekundarstufe I, II bzw. Sekundarstufe I/II und Primarstufe. 7 auch Kenngröße, Maßzahl, Faktattribut, Measure 21

22 KAPITEL 1. GRUNDLAGEN UND FALLSTUDIE UNIVIS EXPLORER gregatfunktion 8. Die Zuordnung vielfältiger Dimensionen bildet den qualifizierenden Aspekt. Zurück zum Fallbeispiel: ein Studierender zeichnet sich aufgrund mehrerer Eigenschaften aus. Die Eigenschaften persönlicher Natur sind Herkunftsland und Geschlecht. Die studiumsbezogenen Daten sind das Fachsemester, der angestrebte Abschluss und die Lehreinheit, der er aufgrund seines Studienfaches zugeordnet ist. Die Lehreinheit ist einer Abteilung und die wiederum einer Fakultät zugeordnet. Die letzte Eigenschaft ist die Zeitangabe, wobei die feinste Auflösung das Semester darstellt. Für die drei Dimensionen der Abbildung II kann die dunkel markierte Zelle in Funktionsschreibweise ausgedrückt werden: Studierendenkopf statistik(d, II, 3) = 5. Da jede Dimension auf der tiefsten Granularitätsstufe jeweils fünf Instanzen enthält, ist die Anzahl der Fakten: = Kennzahl Eine Kennzahl ist der numerische Aspekt der zu analysierenden Fakten. Im Fallbeispiel der Universität werden Studierendenzahlen in Köpfen oder Fällen, Kosten für Personal in Beträgen, oder Prüfungsleistungen in Form von Noten oder Punkten. Eine Formel aggregiert mehrere Werte zu einer Kennzahl wobei verschiedene Aggregationsfunktionen wie Summenbildung, Durchschnitt, Minimum oder Maximum, etc. benutzt werden. Nicht jede Aggregationsfunktionen kann dabei auf alle Kennzahlen angewendet werden (mehr in Kapitel 2). Wird die Dimension oder Formel geändert, ändert sich auch die Kennzahl. Die speziellen Kennzahlen Köpfe und Fälle in Studierendenstatistiken ergeben sich aus zwei unterschiedlichen Zählweisen. Die Kopfstatistik zählt alle Studierenden genau einmal, d.h. die Summe aller Studierenden über ein Semester bildet die Gesamtzahl der Studierenden der Universität in diesem Semester. Fall-Zahlen sind Belegungsstatistiken, da sie jeden Studierenden abhängig vom Studienfach enthalten. So wird in der Fallstatistik ein Studierender, der zwei Fächer studiert, also z.b. im Haupt- und Nebenfach, doppelt gezählt Dimensionen Die Dimensionen stellen das besondere Konzept des multidimensionalen Datenmodells dar und sorgen für den Fakten-Kontext. Es gibt vielfältige Eigenschaften der Transaktion, im Fallbeispiel des Haushaltskostenwürfels Institutionen, Fachsemester im Studierendenwürfel bzw. akademische Zeitabschnitte und Projektgruppen. Sachlogische Merkmale werden in einer Dimension zusammengefasst (Land, Subkontinent und Kontinent gehören bspw. zu einer geografischen Dimension) und tragen so zur Strukturierung bei. Durch diese Designregel bleiben die Dimensionen unabhängig voneinander. Dabei entsteht eine Struktur durch: 8 Synonyme Bezeichnung der Begriffe: die Hierarchieebene wird auch Aggregations- oder Verdichtungsebene, die Dimensionshierarchie kurz Hierarchie oder Verdichtungspfad, die Verdichtung wird Gruppierung oder Aggregation und die Aggregationsfunktion auch Verdichtungs- oder Gruppierungsfunktion genannt. 22

23 Das multidimensionale Datenmodell 1.3 ein Schema und (Land, Region, Kontinent) bzw. (Tag, Monat, Semester, Akademisches Jahr) seine Werte (Afghanistan, Ägypten,..., Zypern) (Australien, Mittelamerika,..., Zentralasien) (Afrika, Amerika,..., Europa) bzw. (1, 2,..., 31) (1, 2,..., 52) (WS 2001/2002, SS 2002,..., SS 2004) (2001/2002, 2002/2003, 2003/2004) Im Schema- und Datenbaum (siehe Abbildung III) vereint der künstliche Knoten T alle Werte. Durch diesen übergeordneten Wurzelknoten und die verschiedenen Stufen entsteht eine Baumstruktur. In diesem Fall besteht die hierarchische Dimension aus vier Stufen: T, Kontinent, Region, Land. Die Elemente (oder Instanzen) einer Stufe sind die Knoten des Datenbaums. Sie können geordnet (Dimensionshierarchie Zeit) oder ungeordnet (Dimensionshierarchie Herkunftsland) sein. Jede Dimension besteht aus mehreren Hierarchieebenen, die jeweils eine eigene semantische Detailierungsstufe besitzen. Die Eltern-Kind-Beziehungen der vier Stufen sind die Basis für Aggregationen innerhalb der Dimension [28, S. 2]. Abbildung III: Dimensionshierarchie und -knoten sowie Hierarchieebenen Granularität Die Granularität ist der Verdichtungsgrad und beschreibt die Feinheit, in der die Fakten über die Kennzahlen beschrieben werden [10, S. 21]. Das Beispiel aus Abbildung II wird um die Dimension Zeit erweitert. Daraus entstehen mehrere Granularitäten, zwei davon sind im Folgenden aufgeführt. G 1 besitzt eine höhere Granularität. 23

24 KAPITEL 1. GRUNDLAGEN UND FALLSTUDIE UNIVIS EXPLORER G 1 : G 2 : (Zeit.Semester, Herkunftsland.Land, Abschlussart.Abschlusstyp, Studiengangsdauer.Fachsemester) (Zeit.Akademisches_Jahr, Herkunftsland.Kontinent, Abschlussart.T, Studiengangsdauer.Fachsemester) Klassifikationspfade Multiple Hierarchien erhöhen die Flexibilität der Analyse. Sie ermöglichen auf verschiedenen Pfaden durch eine Dimension zu navigieren, was einen Blick auf die Daten aus verschiedenen Aspekten erlaubt. Abbildung IV: Klassifikationspfade Ein Klassifikationspfad ist eine Menge von Klassifikationsstufen und enthält stets das größte Element T. Eine Verdichtung ist nur entlang dieses Klassifikationspfades sinnvoll. Der Level der Klassifikationstufe ist nur eindeutig an seinem Pfad. Das granularste Element besitzt Level 1 und das größte Element T folglich ein variables Level (siehe Abbildung IV). Ein typisches Beispiel ist die Zeitdimension mit den ungranularsten Elementen Kalenderjahr und akademisches Jahr 9. Das granularste Element der multiplen Hierarchie ist der Tag. Es entstehen drei Pfade P 1 bis P 3 mit den folgenden Stufen über die der Tag verdichtet wird (siehe Abbildung IV (b)): P 1 : T Kalenderjahr Woche Tag P 2 : T Akademisches Jahr Semester Monat Tag P 3 : T Kalenderjahr Halbjahr Quartal Monat Tag 9 Ein akademisches Jahr fasst jeweils zwei Hochschulsemester bestehend aus Wintersemester und Sommersemester zusammen. Es erstreckt sich statt von Januar bis Dezember von Oktober bis September des Folgejahres. 24

25 Operationen auf multidimensionalen Daten 1.4 Kanten Ein Klassifikationspfad in einer Hierarchie wird durch funktionale Abhängigkeiten bestimmt, aber legt nicht die Bedeutung der Kanten fest. Es können diverse Abhängigkeiten bestimmt werden wie Part-Of-Beziehung: bspw. gehört das Projekt zu einer Projektgruppe Topologische Beziehung: ein Land bspw. Frankreich wird aufgrund seiner geografischen Lage zum Subkontinent Westeuropa gerechnet Is-A-Beziehung: das Dezernat ist eine administrative Einheit Würfel Das Konzept des multidimensionalen Datenmodells wird typischerweise über einen Datenwürfel 10 visualisiert. Die Achsen des Koordinatensystems werden von den Dimensionen aufgespannt, die Fakten ab sind die Punkte bzw. Zellen im multidimensionalen Raum. Trotz der 3D-Metapher besitzt ein Datenmodell oftmals mehr als drei Dimensionen. Die Anzahl der Dimensionen im Würfel ist nach oben offen, laut Pedersen [21, S. 41] sind Würfel zwischen vier- und zwölf-dimensional. Eine größere Anzahl führt zu Problemen der Performanz. 1.4 Operationen auf multidimensionalen Daten Die Analyse der Daten erfolgt durch Operationen auf dem Würfel. Das multidimensionale Datenmodell eignet sich dabei gut für Erhöhen oder Verringern von Dimensionen oder Auswahl von Subwürfeln Projektionen im Würfel In einem Würfel sind Aggregationen Projektionen auf die Achsen. Eine Aggregation geht mit der Reduktion von Dimensionen einher, dadurch verringert sich die Dimensionalität, aber nicht die Granularität. In Abbildung V (die Achsen entsprechen der Zuordnung von Abbildung II mit nicht-hierarchischen Dimensionen) sind folgende Projektionen dargestellt 11 : 1. Projektion auf XZ-Ebene Studierendenzahl abhängig von Abschlussart und Herkunftsland über alle Fachsemester 2. Projektion auf YZ-Ebene Studierendenzahl abhängig von Abschlussart und Fachsemester über alle Länder 10 Synonym bezeichnet mit Würfel, Data Cube, Cube, bei Dimensionalität größer drei Hypercube. 11 Vergleich Data Cube and Sub-Space Aggregates von Gray [9] 25

26 KAPITEL 1. GRUNDLAGEN UND FALLSTUDIE UNIVIS EXPLORER Abbildung V: Projektionen im dreidimensionalen Datenwürfel 3. Projektion auf XY-Ebene Studierendenzahl abhängig von Fachsemester und Herkunftsland über alle Abschlußarten 4. Projektion auf X-Achse Studierendenzahl abhängig von Herkunftsland über alle Abschlußarten und Fachsemester 5. Projektion auf Y-Achse Studierendenzahl abhängig von Fachsemester über alle Herkunftsländer und Abschlußarten 6. Projektion auf Z-Achse Studierendenzahl abhängig von Abschlussart über alle Herkunftsländer und Fachsemester 7. Projektion auf alle Achsen Studierendenzahl ohne Einschränkung Im n-dimensionalen Würfel gibt es also 2 n Projektionen um Daten zu verdichten. Dazu gehören die sieben dargestellten Projektionen, siehe Abbildung V, sowie das Aggregat der einzelnen Zelle. So erhält man 2 3 = 8 Verdichtungen im dreidimensionalen Würfel [35, S. 684f] Funktionen des OLAP Im Folgenden werden einige konkrete OLAP-Operationen aufgeführt. Nach Horner [11, S. 83] sind typische OLAP-Funktionen Roll-up, Drill-down, Slice und Dice und Pivoting. In der Literatur finden sich noch weitere Operationen, nämlich Schachtelung, Ranking und Sorting, Multi-Cube-Join. Sie werden der Vervollständigkeit halber, und da sie in einer Pivot-Tabelle typische Visualisierungen darstellen, wie im Falle der Schachtelung, ebenfalls erläutert. Roll-Up Ein Roll-Up aggregiert detaillierte Daten zur Bildung von Summen entlang eines Klassifikationspfades, wodurch sich die Granularität verringert. Hochkrempeln (engl. 26

27 Operationen auf multidimensionalen Daten 1.4 to roll up) der Elemente einer Stufe zu den Elementen einer weiteren ist nur sinnvoll wenn dies entlang der Dimensionshierarchie geschieht. Ein Roll-Up benutzt die Struktur der Daten in Form von Dimensionshierarchien und der Kennzahl. Als Beispiel wird in Abbildung III ein Roll-Up von Land zu Subkontinent durchgeführt. Eine Analyseanfrage berechnet die Studierendenzahlen bspw. mit der Summenfunktion der Herkunftsländer Finnland, Schweden und Island und die Summe für Nordeuropa. Drill-Down Drill-Down steht für eine Verfeinerung der Daten und ist somit die inverse Operation zu Roll-Up. Ein Drill-Down macht den Zugriff auf die Basisdaten unumgänglich, da zu granulareren Elementen der Dimensionshierarchie navigiert wird. In SQL 12 bedeutet ein Drill-Down also das Hinzufügen eines oder mehrerer Attribute in die Group-by-Klausel. Slicing und Dicing Diese Operationen führen eine Selektion zur Bildung von horizontalen oder vertikalen Ebenen (Slice=Scheibe) und Subwürfeln bzw. einzelnen Zellen (Dice=Würfel) am Würfel durch. Die Operationen können mit Roll-Up und Drill-Down kombiniert werden. Durch Auswahl von Dimensionsattributen werden Zellen betrachtet, die speziellen Kriterien genügen. Z.B. eine Selektion auf Studierende aus Spanien lässt den Würfel zu einer Ebene schrumpfen. Die Auswahl kann durch ein weiteres Kriterium eingeschränkt werden. Es werden weiterhin nur Zellen betrachtet, bei denen sich die Studierenden im 3. Fachsemester befinden. Im dreidimensionalen Würfel wird nun eine einzelne Spalte selektiert. Mit Einschränkung auf eine Ausprägung der dritten Dimension, z.b. Abschlußtyp FH-Diplom ist eine einzelne Zelle selektiert. Es können mehrere Dimensionsknoten betrachtet werden, z.b. Studierende aus Spanien im 2. und 3. Fachsemester mit FH-Abschluß. Dies formt einen Subwürfel und verändert dabei die Dimensionalität des Würfels nicht. Die Selektion z.b. einer Scheibe führt hingegen zur Verringerung der Dimensionalität. Für Slice- und Dice-Operationen werden Attribute in die Where-Klausel(n) der SQL- Anfrage hinzugefügt. Pivoting (Drill-Across) Pivoting beschreibt das Ändern der Dimensionsauswahl eines Würfels. Dimensionen werden hinzufügt oder auf eine andere Achse verschoben. Visuell werden die Ebenen des Würfels, zur Bildung einer alternativen Sicht auf die Daten, gekippt. Eine Rotation des Würfels aus Abbildung II bildet statt der Studierendenzahlen nach Abschlussart und Herkunftsland die Studierendenzahlen nach Fachsemester und Abschlussart ab. 12 SQL als die Structured Query Language ist eine deklarative Datenbanksprache für relationale Datenbanken. 27

28 KAPITEL 1. GRUNDLAGEN UND FALLSTUDIE UNIVIS EXPLORER Nesting (Schachtelung) Diese Operation bildet einen mehrdimensionalen Würfel auf eine zweidimensionale Fläche ab, bspw. für eine Präsentation am Bildschirm. In Pivot-Tabellen-Interfaces werden Dimensionen auf den Achsen ineinander geschachtelt. Ranking und Sorting Nach Ausführung der Anfrage und Bildung einer Rangfolge werden die ersten bzw. letzten (Top bzw. Bottom n) Ergebnisse oder eine Prozentzahl daraus ermittelt. Z.B. können durch diese Anfragen die drei größten Institute, aufgrund der zugeordneten Studierenden, ermittelt werden. Multi-Cube-Join (Drill-Through) Zwei oder mehr Würfel, die mindestens eine gemeinsame Dimension haben, können parallel abgefragt werden. Diese Verlinkung der Würfel ist wünschenswert, da durch die parallele Exploration deutlich komplexere Analyseanfragen möglich werden. Bei dieser Art von Operation werden nicht die Achsen, sondern die Inhalte in den Zellen verändert. So können vergleichende Aussagen über Lehrpersonal gegenüber Studierendenzahlen gezogen werden. Die Verlinkung ermöglicht auch, die Definition neuer Kennzahlen um bspw. die Kosten pro Studierenden zu berechnen. 1.5 Modellieren der multidimensionalen Daten Die im letzten Abschnitt 1.4 beschriebenen Operationen auf OLAP-Daten können auf speziellen Datenbankschemen besonders effektiv ausgeführt werden. Auf relationaler Ebene werden die mehrdimensionalen Eigenschaften nachgebildet und besonders zwischen Fakt und Dimension unterschieden Das konzeptionelle Schema Durch das ME/R-Modell soll der konzeptionelle Entwurf der beiden Würfel gezeigt werden. Einige Zusammenhänge in den universitären Daten werden einleitend beschrieben. Strukturen und Besonderheiten der universitären Daten Eine administrative oder eine Lehr-und-Forschungs-Einheit agieren als Besteller, die im Haushalt der Universität Kosten verursachen. Eine administrative Einheit kann eine Kostenstelle, die Bibliothek oder auch ein Dezernat der Zentralverwaltung sein. Der zweite Typ, die Lehre-Einheiten, sind die Fakultäten, Abteilungen, Institute, Fächer und Lehreinheiten. Das granularste Element in der Datenhierarchie sind die Personen, die einen Lehrstuhl repräsentieren können. Alle diese organisatorischen Einheiten können die Rolle des Bestellers innehaben. Ein Studierender ist aufgrund seines Studienfaches einer Lehreinheit zugeteilt. Die Lehreinheit wird einer Abteilung und diese der entsprechenden Fakultät unterstellt. 28

29 Modellieren der multidimensionalen Daten 1.5 Die Besteller werden in zwei weitere Klassen, die Administration und Lehre Einheiten unterteilt. Einheiten beider Institutionen können also Bestellungen aufgeben. Aufgrund der Datenstruktur wird die Administration in zwei weitere Subbäume unterteilt, zum einen Einheiten der Verwaltung und zum anderen Sonstige. In beiden Verwaltungsdimensionen ergeben sich Hierarchien. Zu Umstrukturierungen innerhalb der Verwaltung und der Lehreinheiten einer Universität gehören das Auflösen von Instituten oder Hinzufügen einer weiteren Einheit wie Fächer. Dieser Tatsache muss im Würfel Rechnung getragen werden, denn hier sind Strukturen und Hierarchien so abgebildet, wie sie der Realität entsprechen. So ist in Abbildung VI das unregelmässige Datenschema etwa daran zu erkennen, dass es Institute auf unterschiedlichen Hierarchiestufen gibt. Gleichnamige Instanzen auf mehreren Ebenen sollten also entweder nicht gleich bezeichnet oder nur auf derselben Hierarchiestufe verwendet werden. ME/R-Modell Eine grafische Modellierung des multidimensionalen Datenkonzepts erfolgt z.b. mittels des ME/R (Multi Entity-Relationship)-Modells [24]. Das traditionelle E/R-Modell [3] wird erweitert [24, S. 6], da es für Modellierung komplexer Datenstrukturen nicht ausreichend ist. Spezielle Konzepte, wie die Klassifikationsstufe, die Halbordnung zwischen den Klassifikationsstufen (rolls-up-to Beziehung) und der Würfel werden nicht repräsentiert und wurden ergänzt. Der Studierendenwürfel referenziert per Faktbeziehung u.a. die Dimension Herkunftsland. In der Hierarchie existieren Roll-Up-Beziehungen von Land zu Subkontinent und zu Kontinent. Ausserdem teilen sich die Würfel mehrere Dimensionen wie Semester und Lehreinheit. Klassifikationsstufen und zugehörige Werte bspw. der Verwaltung sind die folgenden: Dienst (Telefonzentrale, Hausdienst, Prüfungssekretariat, Poststelle... ) Sachgruppe (Personalentwicklung/Fortbildung... ) Dezernat (alle Dezernate, Kanzler... ) Kostenstelle (Zentralverwaltung... ) Verwaltung Auch die Lehre Einheiten bilden eine Hierarchie: Person Fach/Institut (Angewandte Materialtechnik, Physik... ) Lehreinheit (Elektrotechnik, Maschinenbau... ) Abteilung/Institut (Abteilung für Maschinenbau, Institut für Kulturwissenschaften... ) 29

30 KAPITEL 1. GRUNDLAGEN UND FALLSTUDIE UNIVIS EXPLORER Abbildung VI: Universitäts-Data Warehouse-Schema in ME/R-Notation Fakultät (Geisteswissenschaften, Wirtschaftwissenschaft... ) Schemaformen MOLAP und ROLAP Für OLAP-Datenmodelle existieren unterschiedliche Ansätze zur Speicherung. Zu den wichtigen Modellierungsverfahren gehören MOLAP und ROLAP. MOLAP Multidimensionale OLAP- (kurz MOLAP) Systeme basieren logisch auf der Multiplikation aller zu betrachtenden Dimensionen und bieten direkten Zugriff auf die mehrdimensionalen Arraystrukturen [2]. Physisch sind alle Aggregationen in einem OLAP- 30

31 Modellieren der multidimensionalen Daten 1.5 Würfel abgebildet. Der Vorteil ist die Verfügbarkeit aller Dimensions-Kombinationen, was eine hohe Flexibilität bezüglich Operationen wie Drill-Down und Roll-Up mit sich bringt. Von Nachteil wirkt sich die begrenzte Speicherkapazität und somit die begrenzte Größe der Dimensionen aus [18, S.377 f]. ROLAP Das zweite Modellierungsverfahren ist das relationale OLAP (kurz ROLAP). Die zu analysierenden Daten werden in relationalen Datenbanken gespeichert. Eine Normalisierung der Daten führt zu nahezu unbegrenzter Speicherkapazität. Dies bedeutet andererseits einen Nachteil durch Einbußen bei der Performanz, da normalisierte Tabellen viele Joins zwischen Tabellen verlangen. Fazit Beide Lösungen bieten Vor- und Nachteile: MOLAP berechnet Aggregationen schneller, dafür skaliert ROLAP besser. Im Rahmen des Projektes wird ROLAP bevorzugt, da die Testdaten in relationaler Form vorliegen. Zudem ist das Know-How bezüglich relationaler Datenbanken vorhanden Das relationale Schema Um die Mehrdimensionalität in einem relationalen System nachzubilden werden spezielle Datenbankschemen eingesetzt. Fakten und Dimensionen werden dabei strikt unterschieden und entsprechend in Fakten- und Dimensionstabellen getrennt. Die Daten werden in Stern-, Schneeflocken- oder im Fact Constellation Schemen modelliert. Diese spezielle Techniken werden in den nächsten Abschnitten erläutert. Sternschema Das Sternschema (oder Starschema) unterscheidet zwischen zwei Arten von Tabellen [18, S. 160]. Im Mittelpunkt steht die Faktentabelle (enthält Bewegungsdaten) mit Spalten für jede Kennzahl sowie für die Fremdschlüssel zu jeder Dimension. Die Dimensionstabellen (mit Stammdaten) enthalten beschreibende Informationen zu den Fakten. Die Schlüssel der zur Faktentabelle beitragenden Dimensionenen sind die Verbindung zwischen Fakten- und Dimensionstabellen [35, S. 688]. Dabei sind die Dimensionstabellen zumeist denormalisiert, da das Sternschema keine Attributhierarchien unterstützt [35, S. 689]. Dies spiegelt sich im Falle von hierarchischen Dimensionen in redundanten Einträgen wider (siehe Tabelle II). LandID LandName SubkontinentName KontinentName 1 Schweden Nordeuropa Europa 2 Norwegen Nordeuropa Europa 3 Dänemark Nordeuropa Europa Tabelle II: Ausschnitt einer denormalisierten Dimensionstabelle Nationalität 31

32 KAPITEL 1. GRUNDLAGEN UND FALLSTUDIE UNIVIS EXPLORER Die Faktentabelle wird also von den Dimensionstabellen umringt und das sich ergebende sternförmige Gebilde gibt dem Schema seinen Namen. Quasi-Sternschema von SuperX Das Schema in dem SuperX die Daten modellierte ähnelt einem Sternschema, aber verfügt nicht über typische denormalisierte Dimensionstabellen. Es wird deshalb hier als Pseudo-Sternschema bezeichnet. Die Faktentabelle in Abbildung VII besitzt eine Kennzahl value die die Studierendenzahl darstellt. Die Attributhierarchien in den Dimensionstabellen werden als inhärente Fremdschlüsselbeziehung abgebildet. Die Hierarchie wird über den Primärschlüssel key gebildet, den das Attribut parent referenziert. Über die Tabelle bluep_koepfe_faelle wird die Zuordnung zu Köpfe oder Fälle definiert. Die Dimensionshierarchien sind implizit dargestellt und infolgedessen nur aus den Inhalten der Tabellen ersichtlich. Abbildung VII: SuperX-Würfel Studierendenstatistik in Pseudo-Sternschema Schneeflockenschema Die Normalisierung der Dimensionstabellen, bzw. im SuperX-Pseudo-Sternschema die Auflösung der inhärenten Hierarchien, stellt den Übergang zu einem Schneeflokkenschema (Snowflake-Schema) dar und macht die Bildung von Attributhierarchien möglich. Die Schneeflocken-Metapher entsteht durch die Faktentabelle in der Mitte, die von den referenzierten Dimensionstabellen umringt wird (siehe Abbildung VIII). Der Würfel des Fallbeispiels besitzt sieben Dimensionen. Ist eine Dimension hierarchisch, werden aus Performanzgründen prejointen Tabellen der Dimensionshierarchie vorgeschaltet. Sie nimmt alle Primärschlüssel der zur Hierarchie gehörenden Dimensionstabellen auf. Jeder Eintrag erhält einen eindeutigen Schlüssel, auf den aus der Faktentabelle verwiesen wird. Jetzt sind Hierarchien explizit zu erkennen, da sie hierarchisch in separate Tabellen ausgelagert wurden. 32

33 Modellieren der multidimensionalen Daten 1.5 Abbildung VIII: Würfel Studierendenstatistik als Schneeflockenschema Fact Constellation Schema Eine weitere Datenmodellierungstechnik ist das Fact Constellation Schema [35, S. 689]. Es entsteht wenn mehrere Faktentabellen vorhanden sind, die sich Dimensionstabellen teilen. Dadurch entsteht eine optische Überlagerung der Sterne bzw. Schneeflocken. Das Datenmodell der Fallstudie ist also am ehesten ein Fact Constellation Schema. 33

34 Kapitel 2 Das erweiterte multidimensionale Datenmodell Werden OLAP-Operationen auf einem multidimensionalen Datenmodell ausgeführt erwarten sie eine spezielle Modellstruktur. Sind diese Bedingungen nicht gegeben versorgen traditionelle Modelle die Applikationen nicht mit korrekten Daten. In diesem Kapitel werden verschiedene reguläre und irreguläre Dimensionshierarchien eingeführt, die zu Problemen bei der Aggregationsbildung führen. Die Anforderungen an das Datenmodell um Summierbarkeit zu gewährleisten werden beschrieben sowie an einem konkreten Beispiel Modellierungstechniken zur Überführung des Schemas und der Daten in eine regelmässige Hierarchie aufgezeigt. 2.1 Dimensionshierarchien Die Klassifikation der Hierarchien ist bezüglich der Summierbarkeit von besonderem Belang, da die Operationen Roll-Up und Drill-Down entlang dieser vordefinierten Hierarchien stattfinden. In Data Warehouses existieren aus Gründen der Performanz materialisierte Sichten (materialized views). Diese Sichten dienen der Vorberechnung und Speicherung aggregierter Daten und werden ebenfalls entlang dieser Hierarchien aufgebaut [11, S. 84]. Für die Klassifikation der Hierarchien wird zwischen Daten- und Schemahierarchie unterschieden [34, S. 4] [32]. Die Datenhierarchie stellt die Dimensionsknoten und die Schemahierarchie die Klassifikationsstufen dar Klassifikation der Dimensionshierarchien Nicht hierarchisch Besitzt eine Dimension lediglich eine Klassifikationsstufe ist sie einfach (simple). Sie ist nicht hierarchisch da es nur eine Granularität und folglich keine Roll-Up-Beziehung gibt. Beispiele sind die Dimensionen Hochschulzugangsberechtigung und Geschlecht (siehe Abbildung IX (a)). 34

35 Dimensionshierarchien 2.1 Abbildung IX: Nicht hierarchische (a), streng hierarchische (b) und nicht-streng hierarchische (c) Dimensionen in Schema- und Datenhierarchie Streng hierarchisch In einer streng hierarchischen Dimension gibt es in der Schemahierarchie je Hierarchieebene eine ausgehende Roll-Up-Beziehung, z.b. Fachsemester Fachsemestergruppe. Also bedeutet dies für die Dimensionsknoten dass sie über genau einen Vorfahr auf einer höheren Aggregationsebene verfügen. Die Instanzen einer streng-hierarchischen Dimension ergeben durch die n:1-beziehung einen ausgeglichenen Baum (siehe Abbildung IX (b)). Nicht-streng hierarchisch Die nicht-streng hierarchische Dimension erlaubt eine m:n-beziehung zwischen den Stufen in der Hierarchie. Aus nicht-strengen Hierarchien können sich multiple und alternative Hierarchiepfade ergeben. Folglich kann eine Instanz zu verschiedenen Instanzen der darüberliegenden Stufe aggregiert werden. Im Fallbeispiel kann ein Projekt an mehreren Projektgruppen beteiligt sein. In ME/R-Notation wird die many-to-many- als belongs-to-beziehung dargestellt. Abbildung IX (c) zeigt eine nicht-streng hierarchische Dimension. Abbildung X: Nicht-deckend (a), nicht-ausgeglichen (b), heterogen (c) und gemischtgranular hierarchische (d) Dimensionen in Schema- und Datenhierarchie 35

36 KAPITEL 2. DAS ERWEITERTE MULTIDIMENSIONALE DATENMODELL Nicht-deckend hierarchisch Ist eine Hierarchie streng hierarchisch und Instanzen im Datenbaum überspringen eine oder mehrere Aggregationsstufen dann ist die Hierarchie nicht-deckend hierarchisch (non-covering). Beispielsweise wird Kostenklasse zu einer bestimmten Kostengruppe oder direkt zu einer Kostenkategorie zugeordnet (siehe Abbildung X (a)). Nicht-ausgeglichen hierarchisch Ein Datenbaum ist nicht ausgeglichen (non-onto) wenn es innere Knoten gibt, die keine Nachfahren haben. Im Fallbeispiel können die Abteilung und die Fakultät als Besteller auftreten. Sie besitzen also keine Nachfolgerknoten und befinden sich nicht auf der untersten Hierarchiestufe sondern sind selbst Blattknoten (siehe Abbildung X (b)). Der Vorteil multipler Hierarchien ist das auf unterschiedlichen Pfaden durch die Daten navigiert werden kann. Analysen können durch multiple Hierarchien viel weiträumiger gestaltet werden. Multipel hierarchisch Eine Stufe kann Roll-Up-Beziehungen zu beliebig vielen Klassifikationsstufen besitzen. Die sich so aus einer einzelnen Dimension ergebende Hierarchie ist multipel. Die Zeitdimension ist ein gerne benutztes Beispiel für eine multiple Hierarchie da intuitiv mehrere Aggregationspfade (vgl. Abbildung IV) gefunden werden. Trennen sich zwei Pfade an einer Stufe und treffen an einer höheren Stufe wieder aufeinander sind sie alternativ. Heterogen hierarchisch Eine heterogene Hierarchie ist eine Komposition mehrerer Dimensionshierarchien mit eigenen Aggregationsstufen und Attributen. Eine Oberklasse besitzt mehrere Unterklassen, die wieder Oberklassen weiterer Dimensionshierarchien oder Unterklassen sein können. Jede Unterklasse bildet in der Datenhierarchie einen eigenen Teilbaum (siehe Abbildung IX (c)). Gemischt-granular hierarchisch Die gemischt-granularen Hierarchien (mixed granularity hierarchy) stellen einen Spezialfall der heterogenen Hierarchien dar. Die Subklasse einer abstrakten Oberklasse kann Endinstanz der Hierarchie sein oder eine eigene Aggregationsstufe bilden. Im Fallbeispiel: entweder tritt die Abteilung selbst als Besteller auf oder die Person als Besteller aggregiert u.a. über die Aggregationsstufe Abteilung. In Abbildung IX (d) ist einer von vielen Datenbäumen dargestellt Homogene vs. heterogene Dimensionen Werden für zwei Stufen s 1 und s 2, von s 1 zu s 2 existiert ein Roll-Up, alle im Schema vorhandenen Instanzen der Stufe s 1 auf eine Instanz der darüberliegenden Stufe s 2 36

37 Modellierungsanforderungen 2.2 zugeordnet, sind die beiden Hierarchiestufen homogen [12, S. 2]. Ist ein Dimensionsschema homogen und es existiert auf der untersten Stufe der Schemahierarchie nur ein Hierarchieelement ist es streng-homogen (siehe Abbildung IX (b)). Für alle anderen Fälle ist das Dimensionsschema, bzw. die Klassifikationsstufen für die die Beziehung zutrifft, heterogen (siehe bspw. Abbildung X (c)). Heterogene Hierarchiestrukturen besitzen partielle Roll-Up-Funktionen ohne einheitliche Aggregationsebenen in den Baumlevels [12, S. 2]. Ob ein Schema streng-homogen, homogen oder heterogen modelliert wird hängt von diversen Faktoren ab. Es stellt sich die Frage ob gemeinsame Attribute der Stufen benutzt und wie die Instanzen in Dimensionsstufen gruppiert werden sollen. Heterogene Hierarchien sind flexibler da Stufen zusammengefügt werden können, die dieselbe Granularität besitzen. Dies reduziert die Komplexität des Schemas und der Anfragegenerierung. Dieser Vorteil wirkt sich nicht nur auf der logischen sondern auch auf der Speicherebene aus. 2.2 Modellierungsanforderungen Die Verdichtung von Daten entlang des Klassifikationspfades ist das Ziel des multidimensionalen Datenmodells. Unter gewissen Bedingungen berechnen bestimmte Operationen falsche Ergebnisse, die zu fehlerhaften Analysen und daraus resultierend zu falschen Entscheidungen führen [15, S. 1]. Was eine Kennzahl um bezüglich eines Klassifikationspfades korrekte Aggregationen zu erzeugen, erfüllen muss, wird Summierbarkeit (Summarizability) oder allgemein Aggregierbarkeit [10, S. 22] genannt. Das Datenvolumen von Data Warehouses kann beträchtlich sein. So gibt Herden [10, S. 14] die Größe von operativen Datenbanken im Bereich von Megabytes zu Gigabytes gegenüber Gigabytes zu Terabytes bei Data Warehouses an. So werden Aggregate aus Performanzgründen aus nächstkleineren Aggregationsstufen und nicht aus den Basisdaten gebildet. Möchte man bspw. die Summe aller Studierender aus Nordamerika berechnen ist es sinnvoll, lediglich über die Studierenden aus Ländern die in Nordamerika liegen, zu summieren, anstatt über alle Studierenden Modellierungsfallen Anhand einiger Modellierungsfallen [15, S. 3ff] werden verschiedene Konstellationen an Kennzahlen und Fakten ersichtlich, die Summierbarkeit erlauben oder nicht. Beispiel: Art der Aggregationsfunktion... Die summierten und durchschnittlichen Haushaltskosten zweier Lehreinheiten und ihrer Institute werden im Zahlenbeispiel aus Tabelle III abgebildet. Die Summenbildung ist für die Zwischen- sowie Endergebnis-Zeile eindeutig. Allerdings ergeben sich verschiedene Ergebnisse für den Durchschnitt auf Stufe der Institute (( ) 5 = = 26) im Vergleich zum Durchschnitt auf Basis der Zwischenergebnisse der Lehreinheiten (( ) 2 = 50 2 = 25). Anhand dieses Beispieles wird deutlich, daß manche Aggregationsfunktionen hierarchisch benutzt werden können und andere hingegen nicht. 37

38 KAPITEL 2. DAS ERWEITERTE MULTIDIMENSIONALE DATENMODELL Akademisches Jahr Lehreinheit Institut 1999/2000 Sozialwissenschaften Politikwissenschaft 30 Soziologie 10 SUBTOTAL SUM=40 AVG=20 Informatik Informationstechnik 20 Interaktive Systeme 40 Medientechnik 30 SUBTOTAL SUM=90 AVG=30 TOTAL SUM=130 AVG= Tabelle III: Summierte und durchschnittliche Haushaltskosten in Tausend-Euro für ein akademisches Jahr über mehrere Institute Beispiel: Art der Kennzahl... Akademisches Jahr Fakultät 99/00 00/01 01/02 02/03 TOTAL Naturwissenschaften Geisteswissenschaften TOTAL Tabelle IV: Studierendenzahlen pro Fakultät und akademischem Jahr (Studium mit Regelstudienzeit drei Jahre, Beginn 1999/2000) Tabelle IV mit Studierendenzahlen einer Universität gruppiert nach Fakultät und Jahr (kleine Zahlen zur Vereinfachung), enthält die Summe der Studierenden je Fakultät über einen Vier-Jahres-Zeitraum (Wintersemester 1999 bis Sommersemester 2003). Addiert man die Studierendenzahlen pro Fakultät für alle Jahre ergibt sich ein falsches Ergebnis ( = 70) da jeder Studierende des dreijährigen Studiums mehr als ein Jahr an der Fakultät ist. Einige Studierende werden also mehrmals gezählt. Wenn sämtliche Studiengänge der Fakultäten Natur- und Geisteswissenschaften im Jahr 1999/2000 beginnen, kann die Summe über die Zeit mithilfe Mutmassungen gebildet werden: im Jahr 1999/2000 nahmen 14 Studierende ein Studium in den Naturwissenschaften auf. 15 Studierende wurden in 2000/2001 gezählt, davon lediglich ein neuer, da die restlichen 14 ja 1999/2000 begannen. 2001/2002 kommen fünf neue zu den bereits eingeschriebenen 15 Studierenden hinzu. Im Folgejahr endet für 14 Absolventen, die Anfänger von 1999/2000, das Studium. Übrig bleiben sechs Studierende zu denen 2002/ neue Erstsemestler stossen. Die korrekte Summe der Studierenden ist folglich = 35 und nicht 70 wie ursprünglich berechnet. Es können viele Situationen mit Ausnahmen auftreten: Studierende verlängern von drei auf vier Jahre oder scheiden vor den vollen drei Jahren aus etc. Setzt man voraus dass sich alle Studierende nur für ein Programm eingeschrieben haben, kann die Summe über die Dimension Fakultät (horizontale TOTAL-Zeile) korrekt gebildet werden. Die Kennzahl Kopf bzw. Fall ist nicht absolut nicht-summierbar sondern relativ zur Zeitdimension nicht-summierbar. Für die Summenbildung ist also semantisches Hintergrundwissen notwendig. Die Art der Kennzahl scheint verantwortlich zu sein ob entlang einer Dimension sum- 38

39 Modellierungsanforderungen 2.2 miert werden kann oder nicht. Beispiel: Disjunkte Faktenmengen... Das Zahlenbeispiel aus Tabelle IV wird erweitert: wie erwähnt ist die Summierung der Studierendenzahl relativ zur Fakultätsdimension nur korrekt, wenn die Studierenden lediglich ein Studienfach wählen. Bei Haupt- und Nebenfachstudiengängen ist diese Bedingung nicht erfüllt und Studierende werden doppelt gezählt. Akademisches Jahr Fakultät 99/00 00/01 01/02 02/03 TOTAL Naturwissenschaften Geisteswissenschaften TOTAL Tabelle V: Studierendenzahlen pro Studienfach und Akademischem Jahr (Dreijähriges Studium, mehrfache Fachbelegung möglich) Die Summen der horizontalen Aggregationszeile in Tabelle V für die ersten drei Jahre sind jeweils um vier geringer als in Tabelle IV. Hintergrund: vier Studierende wählen Informatik als Haupt- und Mathematik als Nebenfach, was beides zu den Naturwissenschaften gehört. Jetzt können die Summen nicht mehr relativ zum Studienfach gebildet werden, da die Studierenden keine disjunkte Menge relativ zu dieser Dimension bilden. Beispiel: Zuordnung Klassifikationsstufen... Akademisches Jahr Lehreinheit Institut 99/00 00/01 TOTAL Sozialwissenschaften Politikwissenschaft Soziologie SUBTOTAL Informatik Informationstechnik Interaktive Systeme Medientechnik SUBTOTAL TOTAL Tabelle VI: Haushaltskosten pro Institut und Lehreinheit in Tausend-Euro (für zwei akademische Jahre, Lehreinheiten sind Institute und Fächer) In Tabelle VI sind Haushaltskosten in Tausend-Euro für Institute zweier Lehreinheiten Sozialwissenschaften und Informatik abgebildet. Haushaltskosten sind über die Zeitdimension summierbar, allerdings nicht relativ zu den Lehreinheiten da die Haushaltskosten einer Lehreinheit von Fächern und nicht nur von Instituten verursacht werden. Die Instanzen der Lehreinheiten werden also nicht komplett auf die Institute abgebildet. Angenommen, nur in den Instituten können Kosten anfallen, nicht aber in den Fächern, dann kann für die Summe der Kosten der Lehreinheiten korrekt über Institute 39

40 KAPITEL 2. DAS ERWEITERTE MULTIDIMENSIONALE DATENMODELL summiert werden Bedingungen für Summierbarkeit Sind komplexe multidimensionale Daten nicht summierbar (summarizable) kann nicht von Aggregaten, basierend auf Aggregationsstufen mit geringerem Level, abgeleitet werden. Um die Daten ein regelmässiges Schema zu verpassen, was viele Datenmodelle verlangen, müssen folgende drei Bedingungen eingehalten werden [15]. Überlappungsfreiheit Eine Klassifikationshierarchie ist überlappungsfrei (strict) wenn jeder Klassifikationsknoten der Stufe s höchstens mit einem Klassifikationsknoten der Stufe s + 1 verbunden ist. Zusätzlich darf jeder Datenpunkt als direkten Vorfahr höchstens einen Klassifikationsknoten mit Stufe 0 besitzen. Überschneidungen in Teilbäumen können auftreten, wenn Studierende mehreren Studienfächern zugeordnet sind. Im anderen Fall bilden die Studienfächer disjunkte Submengen aus ihren Studierenden. Kein Dimensionsknoten hat mehr als einen direkten Vorfahr. Vollständigkeit Ist die Klassifikationshierarchie überlappungsfrei, dann wird als nächstes die Gruppierung der Elemente auf Vollständigkeit (covering) überprüft. Jeder Klassifikationsknoten der Stufe s muss mindestens mit einem Klassifikationsknoten der Stufe s + 1 verbunden sein. Bei der Modellierung ist also zu beachten, daß keine Löcher in den Klassifikationshierarchien entstehen. Das Beispiel der Zuordnung von Städten zu Distrikten bzw. Länder und anschliessend zu Staaten ist ein typisches Beispiel. Manche Städte sind eigenständig und sind nicht einem Land zugeordnet, wie beispielsweise Bremen. Im Datenschema ergibt sich nun ein Sprung von diesen länderlosen Städten zum jeweiligen Staat. Kein Pfad überspringt eine oder mehrere Stufen von einem Dimensionsknoten zum nächsthöheren. Ausgeglichene Baumstruktur Die meisten Datenmodelle verlangen, daß die Instanzen der Dimensionshierarchie einen ausgeglichenen Baum bilden. Dies bedeutet, daß der Pfad vom Wurzelknoten zu den Blättern stets gleich lang ist. In Abbildung X (b) ist der Baum nicht ausgeglichen da nicht alle Teilbäume dieselbe Tiefe besitzen. Beispielsweise würde die Aggregationsfunktion Summe angewandt auf die Lehreinheiten und abgeleitet von der Summe der Aggregate der Abteilungen ein falsches Ergebnis liefern, da manche Abteilungen keine Kinderknoten besitzen. Das Datenschema bildet eine ausgeglichene Baumstruktur. 40

41 Modellierungsanforderungen 2.2 Fazit Referenzieren alle Fakten Knoten der niedrigsten Stufe des Datenbaumes, und besitzen diese Referenz nur auf einen und nicht auf mehrere Knoten, und der Datenbaum ist balanciert [21, S. 44], dann sind alle Bedingungen für korrekte Summierbarkeit gegeben und keine Knoten werden zu viel oder zu wenig aggregiert Typverträglichkeit von Fakt und Aggregationsfunktion Es ergeben sich weitere Bedingungen für eine korrekte Aggregierung, definiert von Lenz [15] und illustriert durch die Beispiele Im Folgenden werden die verschiedenen Typen von Fakten erläutert und anschliessend begründet, welche Kombination an Fakten und Aggregationsfunktionen sinnvoll ist. Verschiedenartige Fakten... Im Data Warehouse gibt es in der Regel folgende numerische Faktentypen ([21, S. 42f], [15, S. 9]): Flow-Fakten stellen Ereignisse dar wie Umsätze, Verkäufe, Klicks auf eine Webseite, diplomierte Studierende oder monatliche Geburtenrate. Sie beziehen sich jeweils auf eine bestimmte Zeitperiode und werden am Ende dieser aufgenommen. Stock-Fakten sind sogenannte Snapshots des Zustands zu einem bestimmten Zeitpunkt wie der Lagerbestand, die Besucher einer Webseite oder Einwohnerzahlen einer Stadt o.ä. Value-per-Unit-Fakten beschreiben eine Eigenschaft zu einem bestimmten Zeitpunkt wie Stückpreise, Kosten der Herstellung pro Einheit oder Währungskurse. Die Einheiten werden z.b. in Euro pro Stück angegeben.... und unterschiedliche Kennzahlen Kennzahlen können sich bezüglich ihrer Summierbarkeit unterschiedlich verhalten und so können hier die folgenden Typen identifiziert werden ([21, S. 43], [11, S. 84]): Voll-additive Kennzahlen können entlang jeder Dimension sinnvoll aggregiert werden, da sich die Dimensionen in Realität nicht überschneiden. Dies tritt auf bei Snapshot-Daten die dasselbe Objekt zu verschiedenen Zeitpunkten abbilden. Semi-additive Kennzahlen können nicht entlang jeder Dimension summiert werden. Beispiel verdeutlicht die Unterschiede da die Studierendenzahlen entlang der Fakultäts- aber nicht der Zeit-Dimension summierbar sind. Nicht-additive Kennzahlen können entlang keiner Dimension aggregiert werden da dies z.b. durch die Aggregationsfunktion nicht erlaubt ist. 41

42 KAPITEL 2. DAS ERWEITERTE MULTIDIMENSIONALE DATENMODELL Weitere nicht-additive Fakten Nur über numerische Fakten kann aggreggiert werden. Werden den Fakten kategorische Kennzahlen zugeordnet ist eine Summierung natürlich nicht möglich, denn arithmetische Regeln werden verletzt. Fehler können leicht unterlaufen bei nicht-additiven Textfeldern, feststehende Nummern (Temperaturen, Postleitzahlen, ISBN-Nummern) oder auch Angaben der geografischen Lage ( 37 Grad nördliche Breite, 122 Grad westliche Länge ) [11, S. 86]. Kategorische Kennzahlen sollten stets als Dimensionen definiert werden. Fazit Flow-Daten können über eine Zeitachse summiert werden (z.b. Summe der jährlichen Haushaltskosten aus den monatlichen). Für die Entscheidung ob es sinnvoll ist Stockund Value-per-Unit-Fakten zeitlich zu aggregieren, muss die statistische Aggregationsfunktion betrachtet werden. Bei Warenbeständen eines Lagers oder Studierendenzahlen ist eine Aufsummierung über die Monate zu den Beständen bzw. Zahlen des Quartals nicht möglich. Für die definierten Faktentypen und häufige Aggregationsfunktionen sind in Tabelle VII die erlaubten ( ) sowie nicht erlaubten ( ) Kombinationen dargestellt. Flow Stock Valueper-unit MIN MAX SUM Zeit: AVG RANGE Tabelle VII: Summierbarkeit abhängig von Aggregationsfunktion und Faktentyp Sind komplexe Aggregationsfunktionen nicht summierbar, bspw. die Standardabweichung oder der Durchschnitt, können sie trotzdem summiert werden, wenn die Summierbarkeitsbedingung für die Teil-Aggregationen, aus denen die Funktion zusammengesetzt wird, zutrifft [15, S. 4]. Die Summe (SUM) und die Anzahl (COUNT) berechnen bspw. den Durchschnitt (AVG). Die Summenfunktion erfüllt laut Tabelle VII in Kombination mit Stock-Fakten die Summierbarkeitsbedingung nicht. Trotz dieser nicht-summierbaren Komponente ist die aus SUM und COUNT zusammengesetzte AVG-Funktion summierbar. Dies liegt an der Bedeutung der Durchschnittsfunktion. 2.3 SuperX-Schema- und Datentransformation Der folgende Abschnitt beschreibt die Überführung der von SuperX im Pseudo-Sternschema (siehe Abbildung VII) modellierten Würfel in das Schneeflockenschema (siehe Abbildung VIII). Des Weiteren wird eine Datentransformation der unregelmässigen Institute-Dimension durchgeführt. 42

43 SuperX-Schema- und Datentransformation Schritt: Vom Pseudo-Sternschema zum Schneeflockenschema In den flachen Dimensionstabellen des originalen SuperX-Würfels gibt es funktionale Abhängigkeiten wenn, wie im Fallbeispiel (Abbildung VII zeigt die Fakten- und Dimensionstabellen), das Land, der Subkontinent sowie der Kontinent in einer Tabelle gespeichert werden. Das parent-attribut referenziert als Fremdschlüssel das key- Attribut derselben Relation. Der erste Schritt ist also die Entfernung der hierarchischen Beziehungen innerhalb der Tabellen. Dadurch entstehen in den Dimensionstabellen multiple Granularitäten. Zuerst werden alle Einträge, die hierarchische Strukturen besitzen, entsprechend ihrer Granularität aufgeteilt. Die Elemente einer Granularitätsstufe werden jeweils in eine eigene Tabelle kopiert. Die Primärschlüssel der einzelnen Einträge in den Tabellen referenzieren nun jeweils den Schlüssel der nächsthöheren Aggregationsstufe (z.b. dim_land.parent dim_subkontinent.id). Das entsprechende Attribut der Studierenden-Faktentabelle sos_cube stellt die Verbindung zum granularsten Element der Hierarchie dar (sos_cube.land dim_land.id). Aus Performanzgründen wurde dann pro Dimensionshierarchie eine Tabelle, die einen Prejoin der Schlüsselattribute aller vorhandenen Dimensionen durchführt, angelegt. Für die Prejoin-Relation bluep_land ergeben sich folgende Attribute: bluep_land.id, dim_land.id, dim_subkontinent.id, dim_kontinent.id Nun wird die Verbindung zwischen den Attributen der Faktentabelle und der zugehörigen Dimension durch den Fremdschlüssel auf die Prejoin-Tabelle sos_cube.land bluep_land.id hergestellt. Statt einer Tabelle als Zwischenstufe ist ein View denkbar bzw. sogar sinnvoller, weil sonst nach einer Veränderung im Würfel (Fakten werden neu eingeführt, Dimensionen werden angepasst etc.), die Dimensionstabellen und auch die Prejoin-Tabellen überprüft werden müßen. Die Prejoin-Tabellen bedeuten performantere Anfragen, denn jede Tabelle der Dimensionshierarchie ist direkt über die Prejoin-Tabelle mit der Faktentabelle verbunden. Dies verhindert mehrfaches Joinen entlang des Hierarchiepfades Schritt: Trennen von Kennzahlen und Dimensionen In dem Studierendenwürfel gibt es, wie erwähnt, die Kennzahlen Köpfe und Fälle. SuperX unterscheidet in ihrem Modell zwischen den Kennzahlen mittels einer weiteren Dimension. Diese Dimension bluep_koepfe_faelle wird entfernt und die Zuordnung der Kennzahl als Kopf- oder Fallstatistik in die Faktentabelle integriert. Zur Unterscheidung der beiden Kennzahlen werden nun zwei Attribute koepfe bzw. faelle in der Faktentabelle benutzt. Dieser Schritt verringert die Anzahl der Tupel auf die Hälfte und schafft eine explizite Trennung zwischen Dimension und Kennzahl. Ein weiterer Designfehler von SuperX ist die Studierenden nicht einzeln zu identifizieren. Stattdessen sind alle Instanzen mit denselben Eigenschaften zusammengefasst. Durch diese Verdichtung gehen viele Analysemöglichkeiten verloren, denn aus den Daten ist die Bewegung des einzelnen Studierenden nicht nachzuvollziehen. Dies wäre bei Summenbildung über eine Zeitachse von Vorteil, da aus den Basisdaten ersichtlich wäre, welcher Studierende in welchem Semester eingeschrieben ist. Des Weiteren klärt dies auch die Fachbelegung. Der Datenschutz-Einwand wird entkräftet, wenn man einen künstlichen Schlüssel zur Identifizierung benutzt. 43

44 KAPITEL 2. DAS ERWEITERTE MULTIDIMENSIONALE DATENMODELL Schritt: Transformation von Dimensionshierarchien Hierarchische Dimension Land Insgesamt entsprach die Datenmodellierung von SuperX nicht den angestrebten Designkriterien. Vorhandene Hierarchien z.b. in der Herkunfts-Dimension wurden nicht auf adäquate Aggregationsstufen abgebildet. So sind in der geografischen Dimension unterschiedliche Granularitäten in einer Aggregationsstufe abgebildet. Die Dimension Nationalität besitzt nämlich auf einer Aggregationsstufe die Instanzen Deutschland, Ausland (vereint alle Länder exklusive Deutschland) und Sonstige (nicht-zuordenbare Studierende). Dies macht vergleichende Anfragen zwischen deutschen und ausländischen Studierenden möglich, aber erlauben keine der geografischen Dimension angepassten typischen hierarchischen Anfrage. Für unsere Anwendung wurden diese und andere Dimensionen in Hierarchien transformiert, die Länder jeweils ihrer Region und wiederum ihrem Kontinent zuordnen. Um weiterhin beide Aggregationspfade anzubieten wird die multiple hierarchische Dimension vorgeschlagen, siehe Abbildung XI. Der zusätzliche Knoten Deutschland vs. Nicht-Deutschland läßt nun auch vergleichende Anfragen zwischen ausländischen und deutschen Studierenden zu (wie bei SuperX intendiert). Abbildung XI: Multiple Hierarchien in der Dimension Land Heterogene Dimension Organisatorische Einheiten Aufgrund des Pseudo-Sternschemas von SuperX befinden sich alle organisatorische Einheiten in einer Dimensionstabelle. Gerade diese Dimension erfordert aufgrund seiner heterogenen und gemischt-granularen Hierarchien eine Modellierung aus der die Struktur ersichtlicher wird. Das Attribut lehre der ursprünglichen SuperX-Tabelle bluep_org_einheiten teilt den gesamten Datenbaum der organisatorischen Einheiten, ungefähr 460 Einträge, in zwei Unterklassen. Diese beiden Klassen, Einheiten der Lehre und Forschung und Einheiten der Administration, stellen komplett unterschiedliche Objekte dar. Sie sind organisatorische Einheiten aber besitzen unterschiedliche Attribute, was es nicht sinnvoll macht, sie in einer gemeinsamen Dimension abzubilden. Sowohl Einheiten der Lehre und Forschung als auch Einheiten der Administration bilden gemischt-granulare Hierarchien. Alle Instanzen der Aggregationsstufen Fakultät, 44

45 SuperX-Schema- und Datentransformation 2.3 Abteilung, Lehreinheit, Institut und Person sind Endinstanzen (also selbst Besteller) oder stellen Aggegationsstufen der Lehre-Einheiten-Dimension dar. Dasselbe gilt für die Einheiten der Administration. All diese eigenständigen Objekte, die Aggregationsstufen darstellen, werden gruppiert und in eigene Dimensionstabellen ausgelagert. Alle Dimensionen sind durch Prejoin-Tabellen mit der Faktentabelle verbunden, um so alle Einträge aus beiden Unterklassen zusammenzuführen Schritt: Datennormalisierung Der bisherige Schritt bildet die Daten der organisatorischen Einheiten noch nicht als ausgeglichenen Baum ab. Die Unregelmäßigkeit wird in Abbildung XII an einem Ausschnitt deutlich, die den Datenbaum der Zentralwissenschaftlichen Einrichtung (die zentralwissenschaftliche Einrichtung ist an dieser Universität den Einheiten der Administration zugeordnet) darstellt. Erkennbar sind Faktoren, die die Summierbarkeit verletzen. Dazu gehört beispielsweise dass Blattknoten innere Knoten darstellen. Das Ziel ist die Modellierung eines balancierten Baumes mit einer einheitlichen Aggregationsebene je Stufe. Abbildung XII: Unregelmässiger Datenbaum der Zentralwissenschaftlichen Einrichtung Eine vollständige Visualisierung der Daten der beiden Teilbäume, Einheiten der Lehre sowie Einheiten der Administration, offenbaren Muster und Zusammenhänge. Mithilfe des Graphen-Layout-Werkzeuges Yed werden alle Instanzen der Institutionen-Tabelle als Knoten visualisiert. Um die Hierarchie darzustellen, werden anschließend die Verbindungen zwischen den Knoten als Kanten eingetragen. Durch einheitliche Einfärbung der Knoten desselben Typs können Regelmäßigkeiten und Muster erkannt werden. Abbildung XV zeigt die Struktur der Verwaltung. Dieser Teilbaum läßt sich in mehrere Teilbäume splitten. Dies schafft einheitliche Aggregationsebenen auf diesen Ausschnitten, was aufgrund der verschiedenen Institutionen in einer Universität nicht global, also für den gesamten Baum, möglich ist. Die Teilbäume sind, wie bereits erwähnt, auf oberster Ebene die Einheiten der Lehre und die Einheiten der Administration. Diese können unterteilt werden in Verwaltung (siehe in Abbildung XV oberes Cluster) und Sonstige (das untere Cluster). Das Ziel ist die verlustfreie Umstrukturierung der Daten in ein regelmäßiges Modell. Pedersen beschreibt in [20, S. 668ff] eine Daten-Transformationstechnik um Summierbarkeit zu erreichen. Anhand dieser intuitiven Regeln wurden die Daten in ein regelmäßiges Schema überführt. Der dreistufige Prozeß umfasst die folgenden Schritte: 1. Einfügen von Dummy-Knoten um Sprünge in der Hierarchie zu entfernen Covering-Anforderung 2. Einfügen von Dummy-Knoten um innere Blattknoten zu entfernen Onto-Anforderung 45

46 KAPITEL 2. DAS ERWEITERTE MULTIDIMENSIONALE DATENMODELL 3. Auflösen von Knoten-Verbindungen zu mehreren Vorfahren Strict-Anforderung im Fallbeispiel werden zuerst für alle Teilbäume gemeinsame Aggregationsstufen geschaffen. Der daraus entstandene Schemabaum der organisatorischen Einheiten zeigt Abbildung XIII. Alle Knoten desselben Typs werden auf der gemeinsamen Stufe im Baum arrangiert. Enthalten die Verbindungen zu Vorgängerknoten nun Sprünge, werden diese Lücken mit Dummy-Knoten aufgefüllt. Diese erben den Schlüssel des darüberliegenden vorhandenen Knotens, um die korrekte Verknüpfung der beiden Instanzen zu gewährleisten. Dies ermöglicht ein vereinfachtes und automatisches Joinen der Knoten über verschiedene Aggregationsstufen. Die Bezeichnung des neuen Knotens wird ebenfalls von seinem Vorgängerknoten bestimmt. An diesen wird ein benutzerfreundlicher Vermerk (bspw. Sonstige, Alle ) angehängt. Nun ist die Anforderung des ersten Schritts erfüllt, da der Baum der covering-anforderung genügt. Abbildung XIII: Schemastruktur der transformierten Institutionen-Hierarchie Der nächste Schritt ist der onto-schritt: Knoten wie Institut für Verkehr und Logistik (siehe Abbildung XII) besitzen keine nachfolgenden Knoten auf der Blattebene. Um das zu ändern werden auch hier Platzhalter-Dummy-Knoten eingefügt. Sie erben wie jeweils im ersten Schritt den Schlüssel und die Bezeichnung ihres Vorgängerknotens. Die Instanzen Lehreinheit Ostasienwissenschaft und Institut für Ostasienwissenschaft aus Abbildung XII entsprechen nicht dem Muster, befinden sich also auf der falschen Ebene. Dieses Knotenpaar wird dann einfach bezüglich ihres Baumlevels getauscht. Dies darf nur unter einer Bedingung geschehen: der höherstufige Knoten darf nicht mehr als diesen einen Nachfolgerknoten, mit dem getauscht werden soll, besitzen. Das Tauschen bewirkt dass der nun niedrigstufigere Knoten mehrere Vorgänger besitzt. Dies widerspricht der dritten Forderung, den Baum strict zu halten. Das ein Knoten mehrere Vorgänger besitzt, tritt im Fallbeispiel nicht auf. Alle Institutionen sind genau einer anderen Institution zugeordnet. Abbildung XIV: Regelmässiger Datenbaum der zentralwissenschaftlichen Einrichtung Abbildung XII stellt den Zustand der Hierarchie der Zentralwissenschaftlichen Einrichtung vor der Transformation, Abbildung XIV den Zustand danach, dar. Abbildung XV und XVI zeigen einen größeren Ausschnitt des ganzen Baumes jeweils vor und nach der Transformation. Entstanden ist nun eine heterogene Hierarchiestruktur mit unterschiedlichen Granularitäten. Die Ausgeglichenheit und Regelmässigkeit der Struktur nach allen Transformationsschritten ist in Abbildung XVI deutlich zu erkennnen. 46

47 Abbildung XV: Ausschnitt aus unregelmässigem Datenbaum der organisatorischen Einheiten 47

48 Abbildung XVI: Ausschnitt aus regelmässigem Datenbaum der organisatorischen Einheiten 48

49 Kapitel 3 Hierarchische Visualisierung mit Pivot-Tabellen In diesem Kapitel wird der Aufbau, die typische Visualisierung und die Manipulationsmöglichkeiten des OLAP-Standard-Werkzeugs Pivot-Tabelle beschrieben. Drei Interfaces, teilweise für die Domäne der universitären Hochschulverwaltung, werden vorgestellt. Die kleine Übersicht dient zur Präsentation der Konkurrenz -Systeme auf dem Markt. Des Weiteren werden wichtige Funktionalitäten festgestellt, mit Schwerpunkt auf der Navigation in den hierarchischen Datenstrukturen. 3.1 Front End-Werkzeuge für ein Data Warehouse Kaum ein OLAP-Werkzeug verfügt heute nicht über ein Pivot-Tabellen-Interface [5, S. 608]. Oft wird darauf hingewiesen, dass das Handhaben und Verstehen von Pivot- Tabellen vergleichsweise schwer sei [5, S. 607]. Pivot-Tabellen sind limitiert, da sie zum einen zweidimensionale Tabellen sind und zum anderen oft logische und physikalische Aspekte mit denen der Präsentation vermischt werden [8, S. 348]. Trotzdem stellt die Pivot-Tabelle einen natürlichen Startpunkt einer Analyse dar [8, S. 348] und ist die Standard-Benutzerschnittstelle, um einen OLAP-Datenwürfel zu verstehen und zu manipulieren [6, S. 62]. Für den effizienten Zugriff auf ein Data Warehouse, ohne Benutzung einer Datenbanksprache, gibt es Front End-Werkzeuge. Diese Benutzerschnittstellen teilt Herden [10, S. 15] in drei Klassen: Berichts- und Abfragewerkzeuge liefern vordefinierte und parametrisierte Auswertungen in Form von Berichten oder Diagrammen Data Mining-Werkzeuge decken unbekannte Zusammenhänge und Trends in den Daten auf OLAP-Werkzeuge erlauben dem Benutzer interaktiv den Datenbestand zu analysieren. Sie sind in vielfältiger Form verfügbar: als Client auf dem Arbeitsplatzrechner als Erweiterung zur Tabellenanwendung (z.b. Pivot-Tabellen Add-In für Microsoft Excel, siehe Abbildung XIX) als Webbrowser-Client, basierend auf HTML 49

50 KAPITEL 3. HIERARCHISCHE VISUALISIERUNG MIT PIVOT-TABELLEN Hierarchische Visualisierungstechniken Weshalb kann eine Pivot-Tabelle als hierarchisches Visualisierungswerkzeug bezeichnet werden? Der Benutzer kann über Manipulationsmöglichkeiten, wie das Expandieren von Dimensionen, die hierarchische Struktur in den OLAP-Daten explorieren. Das Navigieren in den Hierarchien geschieht entweder direkt in der Pivot-Tabelle durch Auf- und Zuklappen (Expand und Collapse) der Zeilen und Spalten, oder in der Navigationsleiste durch Auf- und Zuklappen der Einträge, zumeist in Form von Ordnern, eines Schemabrowsers. Im ersten Fall wird die hierarchische Datenstruktur und im zweiten die hierarchische Schemastruktur exploriert (mehr zum Schemabrowser in Abschnitt 4.1). Um hierarchische Strukturen visuell zu explorieren gibt es einige innovative Entwicklungen. Zwei davon sind die Treemaps von Johnson/Shneiderman [14] und die Cone Trees von Robertson/Mackinlay/Card [23]. Die Intention ist jeweils große Datenmengen durch effiziente Raumnutzung navigierbar und darstellbar zu machen. Die Visualisierung sollte verständlich sein, so dass der Benutzer sie intuitiv verstehen und bedienen kann. Treemaps Die Baumstruktur vernachlässigend werden die Elemente einer Hierarchie auf eine flache Karte gezeichnet. Dem einzelnen Element des Baumes werden entsprechend seiner Eigenschaft Gewichte verliehen (z.b. Grösse einer Festplatte und der sich darauf befindlichen Dateien und Verzeichnisse) und so deren Fläche festgelegt. Der Platz, der jedem Element zur Verfügung steht, wird je nach Gewicht auf seine Kinder verteilt. Abbildung XVII: Festplatten-Visualisierung über eine Treemap Abbildung XVII zeigt einen Treemap der über die Fläche die Dateigröße und über die Farbe den Dateityp abbildet (Grafik aus [25]). 50

51 Aufbau und Funktionsweise einer Pivot-Tabelle 3.2 Cone Trees Cone Trees sind die dreidimensionale Erweiterung der bekannten Baumstrukturen, die Hierarchien in der Zweidimensionalität abbilden. Sie visualisieren einen Baum platzsparend, da Hierarchien durch die Kegelmetapher über drei Dimensionen verteilt werden. Der Kegel selbst ist transparent, um einen Blick auf alle Elemente gleichzeitig zu gewähren. Abbildung XVIII: Cone Tree mit Verkaufszahlen einer hierarchischen Organisation In der Abbildung XVIII werden Verkaufszahlen einer Organisation in einem Cone Tree abgebildet. Die Organisationshierarchie wird an den vier Stufen des kegelförmigen Baumes dargestellt. Das Wurzelelement ist rot dargestellt und repräsentiert die Verkaufszahlen des gesamten Unternehmens. Die gelbe Stufe zeigt Verkäufe auf regionaler Ebene u.s.w. Jede Stufe erhält eine andere Farbe und gibt über die Größe der Elemente Aufschluß über die Anzahl der Verkäufe. D.h. je grösser das Element, desto mehr Verkäufe verbucht die Abteilung, Filiale oder allgemein Instanz (Grafik aus [22, S. 14]). 3.2 Aufbau und Funktionsweise einer Pivot-Tabelle Eine Pivot-Tabelle stellt die Werteverteilung mehrerer Variablen kompakt in tabellarischer Form dar. Die Datenquellen für Pivot-Tabellen sind Listen, Tabellen aus Tabellenkalkulations-Programmen oder externe Datenbank-Anwendungen [1, S. 425]. Oftmals unterstützt in Office-Paketen ein Assistent beim Verbindungsaufbau zur Datenbank und bei der Erstellung der Pivot-Tabelle Tabelle vs. Kreuztabelle vs. Pivot-Tabelle Die Begriffe Tabelle (Spreadsheet), Kreuztabelle (Cross Tab) und Pivot-Tabelle lassen sich durch die Literatur nicht eindeutig abgrenzen. Teilweise werden Kreuz- und Pivot- Tabelle synonym benutzt [6, S. 62]. Hersteller von Pivot-Tabellen-Interfaces beziehen 51

52 KAPITEL 3. HIERARCHISCHE VISUALISIERUNG MIT PIVOT-TABELLEN sich bezüglich des Begriffes auf das Add-In von Microsoft, die ihre Pivot-Table zuerst in Microsoft Excel einführten. Mmittlerweile, genauer seit der Version Windows XP, nennt Microsoft dasselbe Produkt Pivot-Table-Bericht. In der Literatur finden sich weitere Synonyme, wie Matrixbericht [27, S. 39]. Andere Hersteller wie z.b. Tableau Software (siehe Abschnitt 3.3.3) nennen ihr Produkt, obgleich pivot-tabellen-ähnlich, explizit anders, hier Text Table. Verkäufer grenzen ihr Pivot-Tabellen-Produkt durch Aussagen wie being like a spreadsheet on steroids [5, S. 608] von einfachen Tabellen ab. Werden die Begriffe Kreuztabelle und Pivot-Tabelle nicht synonym benutzt, wird der Unterschied über die niedrigere Dimensionalität der Kreuz- gegenüber der Pivot- Tabelle erklärt. Die traditionelle Tabelle wird an manchen Stellen als die statische und die Pivot-Tabelle als die dynamische Tabelle bezeichnet. Wie auch immer, die Gemeinsamkeit ist zumindest ihre Grundstruktur, gegeben durch ein Gitter aus Zeilen und Spalten Struktureller Aufbau Die beispielhafte (Excel-) Pivot-Tabelle aus Abbildung XIX beruht auf einer Verkaufsstatistik mit mehrjährigen Umsatzzahlen. Ein international operierendes Unternehmen speichert zu jedem Verkauf seines Produktes das Absatzland, das Geschlecht des Käufers, das Verkaufsdatum und natürlich die Höhe des Einkaufs. Im Folgenden werden typische Elemente einer Pivot-Tabelle am Beispiel in Abbildung XIX erläutert [1, S. 427ff]. Abbildung XIX: Zeilen-, Spalten-, Seiten- und Datenfeld einer Microsoft Excel Pivot- Tabelle Im Kontext von Pivot- bzw. Kreuztabellen ist von Variablen und Variablenwerten anstatt, wie bisher im Kontext des multidimensionalen Datenmodells, von Aggregationsstufen und Instanzen der Aggregationsstufen die Rede. Zeilenfeld Das Zeilenfeld nimmt eine Variable auf deren Werte auf der Y-Achse abgetragen werden. Die Beschriftung über der ersten Spalte repräsentiert das Land, in dem der Umsatz erwirtschaftet wurde und überschreibt alle seine Ausprägungen (Argentinien,..., Venezuela). Die Anzahl der Zeilen einer Pivot-Tabelle entspricht also der Anzahl der disjunkten Einträge in der entsprechenden Tabelle des Zeilenfeldes. Gibt es für eine Zelle keinen zugehörigen Wert, beispielsweise in Mexiko kaufte keine männlichen Kunden das Produkt, bleibt die Zelle leer. 52

53 Aufbau und Funktionsweise einer Pivot-Tabelle 3.2 Spaltenfeld Das Spaltenfeld trägt die Beschriftung Geschlecht und listet in der Zeile darunter, jeweils einmal, sämtliche Ausprägungen der entsprechenden Tabelle aus der Datenquelle. Auch hier gilt, dass es so viele Spaltenüberschriften unter dem Spaltenfeld gibt, wie Einträge für das Spaltenfeld in der zugehörigen Tabelle existieren. Mindestens eine Dimension muss auf einer der beiden zur Verfügung stehenden Achsen, also über das Zeilen- oder Spaltenfeld, abgebildet werden, damit die Tabelle nicht leer ist. Jede Achse kann theoretisch zwischen 0 und n Variablen aufnehmen, die dann durch Schachtelung auf den Achsen abgebildet werden. Die Achsen stellen die Variablenwerte des Spaltenfeldes neben- und die des Zeilenfeldes übereinander als eine Art Überschrift dar. Seitenfeld Das Seitenfeld wirkt als Filter auf die Pivot-Tabelle. Über ein Auswahlfeld kann aus sämtlichen Ausprägungen des Seitenfeldes gewählt werden. Im Beispiel ist das Seitenfeld Zeit und der Variablenwert 2000 der im Datenbereich für die Anzeige einzig der Umsätze aus dem Jahr 2000 sorgt. Durch Blättern gelangt der Benutzer zu den gefilterten Seiten. Der oberste Eintrag im Auswahlfeld dieser auch als Paging bekannten Funktion ist das Aggregat aller Ausprägungen (oftmals Alle bezeichnet). Wird dieses Aggregat selektiert, findet keine Filterung über das Seitenfeld statt. Können mehrere Seitenfelder benutzt werden, so wird nach mehreren Variablen gefiltert, und die Filterung durch logisches und verbunden. Datenfeld Jede Pivot-Tabelle benötigt mindestens eine Kennzahl, die im Datenbereich angezeigt wird. Ausserdem muss die Art der Aggregation definiert sein. Im Beispiel trägt das Datenfeld die Beschriftung Summe - Umsatz, also findet eine Summierung des Umsatzes statt. Zusammenfassung Den multidimensionalen OLAP-Aspekt unterstützt die Pivot-Tabelle durch Visualisierung mehrerer Dimensionen über das Zeilen-, Spalten- oder Seitenfeld. Dabei kann eine Pivot-Tabelle mehr als ein Element in den verschiedenen Feldern aufnehmen. Dadurch ändert sich das Layout entsprechend: die Variablenwerte werden auf den Achsen geschachtelt, oder es findet eine Mehrfachfilterung statt, oder in den Zellen werden mehrere Aggregate angezeigt. Diese Kombination von Zeilen-, Spalten-, Seiten- und Datenfeldern kann beliebige Sichten auf die Daten erzeugen und bestimmt als mehrdimensionaler Filter die Werte in der Pivot-Tabelle. Im Datenbereich werden schliesslich die Schnittmengen der selektierten Elemente angezeigt. Verändert der Benutzer einen Faktor der Pivot-Tabelle, durch Definieren einer anderen Dimension im Zeilen-, Spalten- oder Seitenfeld, durch Entfernen einer Dimension oder durch Wählen eines Filters etc., wird der Datenwürfel bildlich gesprochen gedreht. Für jede Zelle ergeben sich neue Schnittmengen. Dieses Drehen gibt der 53

54 KAPITEL 3. HIERARCHISCHE VISUALISIERUNG MIT PIVOT-TABELLEN Pivot-Tabelle ihren Namen: pivoter ist französisch und bedeutet drehen. Die Interaktivität einer Pivot-Tabelle entsteht also durch Einfügen oder Entfernen von Dimensionen, denn dadurch kann der Einfluss durch die Veränderung auf die Daten beobachtet werden Manipulation von Pivot-Tabellen Zum Umfang einer Pivot-Tabelle gehört, oftmals ein interaktives, Interface mit Möglichkeiten zur Kontrolle der zu analysierenden Daten. Folgende Manipulationen ergeben sich für Standard-Pivot-Tabellen-Interfaces nach Eick [6, S. 62]: Zuordnung von Dimensionen zum Zeilen-, Spalten- und Seitenfeld z.b. durch Drag and Drop in entsprechenden Platzhalter Navigation in den hierarchischen Strukturen durch Auf- und Zuklappen der Hierarchien Verdichtung der Daten entlang den Dimensionen mit verschiedenen Aggregationsfunktionen Weitere Operationen, um die Daten der Pivot-Tabelle für die aktuelle Fragestellung zu optimieren, sind Filtern und Pivoting. Das bedeutet eine Änderung der Dimensionen, z.b. durch Tauschen der Spalten- und Zeilenfelder oder das Einbringen neuer Dimensionen. Jede Interaktion mit der Pivot-Tabelle bedeutet eine Auffrischung der Darstellung. Alle Manipulationen haben gemein, dass die darunter liegenden Daten nicht verändert werden. Die Eingriffe des Benutzers passen die dargestellten Daten an, schreiben aber keine Änderungen in die Basisdaten der Datenbank zurück Darstellung der Zwischenaggregate Weitere relevante Elemente einer Pivot-Tabelle sind die Zeilen und Spalten mit Zwischenaggregaten. Sie bilden eine oder mehrere Verdichtungsstufen ab und erlauben dem Benutzer so Aggregate mehrerer Aggregationsstufen gleichzeitig zu betrachten. Ausserdem ist das Einfügen von Zwischenaggregatszeilen und -spalten auch gestalterisch von Vorteil, da sie die einzelnen Gruppierungen optisch voneinander abtrennen. Die Begriffe (Zwischen-) Summe bzw. (Sub-) Total sind zwar umgangssprachlich gebräuchlich, aber irreführend, da die Summenbildung (mittels Sum) nicht die angewandte Aggregationsfunktion sein muss. Auch in der englischen Sprache scheint es diese missverständliche Interpretation zu geben, da Total ebenfalls Summe bedeutet. Korrekt ist die Beschriftung bei Verwendung anderer Aggregationsfunktionen entsprechend zu ändern, z.b. Alle für die Aggregationsfunktion Count. Eine Variable als Zeilen- oder Spaltenfeld Die zu analysierenden Kennzahlen sind in einem Gitter dargestellt. Eine vertikale und horizontale Achse mit Ursprung in der linken oberen Ecke der Tabelle beinhalten die Überschriften der Zeilen bzw. Spalten, also ihre Variablenwerte. Die symmetrischen 54

55 Aufbau und Funktionsweise einer Pivot-Tabelle 3.2 Tabellen (eine Tabelle geht aus der anderen durch Vertauschen der Achsen hervor) in Abbildung XX enthalten jeweils eine Variable im Zeilen- bzw. Spaltenfeld. Eine Spaltenvariable existiert für die Tabelle in Abbildung XX (a) nicht, also wird das Aggregat, hier die Summe, der Studierenden abhängig von Geschlecht und unabhängig von weiteren Dimensionen gebildet. Abbildung XX: Summierte Studierendenzahlen abhängig von Zeilen- bzw. Spaltenvariable Geschlecht Eine Variable als Zeilen- und Spaltenfeld Wird eine weitere Variable, z.b. Kontinent, dem vormals leeren Spaltenfeld aus Abbildung XX (a) zugeordnet, entsteht die Struktur des typischen Gitterkreuzes (siehe Abbildung XXI). Abbildung XXI: Studierendenzahlen abhängig von Spaltenvariable Kontinent und Zeilenvariable Geschlecht Eine Anzeige von Zwischenergebnissen für die Spalten und Zeilen des Endergebnisses ist aufgrund mehrerer Werte für das Spalten- und Zeilenfeld sinnvoll (über eine einwertige Variable wie in Abbildung XX braucht kein Zwischenaggregat gebildet zu werden). Diese Zwischenaggregate werden im Beispiel als Spalte am rechten und als Zeile am unteren Rand der Tabelle eingefügt. Die Position dieser Zwischenergebnisse variiert, kann sich auch am oberen oder linken Rand befinden. Das Endergebnis mit dem über die Zeilen bzw. Spalten kumulierten Aggregat ist in der rechten unteren Zelle platziert, und sollte in der Regel aus den vertikalen und horizontalen Zwischenaggregaten zugleich berechnet werden können. Die angewandte Aggregationsfunktion bestimmt auch den Wert in den Ergebniszellen. Wird etwa die Summe im Datenfeld gebildet, erhält man das Gesamtaggregat durch Aufsummierung der Einzelaggregate. Mehrere Variablen als Zeilen- und Spaltenfelder Die geschachtelte Tabelle aus Abbildung XXII visualisiert je Zelle zwei Kennzahlen, sowie drei Zeilen- und zwei Spaltenfelder. Die Reihenfolge der Schachtelung erfolgt sinnvollerweise entsprechend der Hierarchie in der Dimension, hier also nach Kontinent, Region und zuletzt Herkunftsland. Alle Instanzen der Variablen sind meist innerhalb der Gruppierung alphabetisch sortiert. 55

56 KAPITEL 3. HIERARCHISCHE VISUALISIERUNG MIT PIVOT-TABELLEN Abbildung XXII: Geschachtelte Tabelle mit Studierendenzahlen abhängig von Spaltenvariablen Fachsemestergruppe, Fachsemester und Zeilenvariablen Kontinent, Subkontinent, Land, aggregiert über Kennzahlen Kopf und Fall Jede Gruppierung, z.b. Herkunftsregion Nordeuropa für das 1. bis 4. Fachsemester, schließt mit einem Zwischenergebnis ab und wird als zusätzliche Spalte bzw. Zeile an die entsprechende Position, hinter bzw. unter den letzten Variablenwerten, eingefügt. Die Zellen mit den Zwischen- und Endaggregaten werden optisch, z.b. hier über eine andere Hintergrundfarbe, von Aggregaten anderer Granularität abgegrenzt. Die Zwischenaggregate werden auch zwischengeblendet, wenn die Gruppierung nur aus einer Instanz besteht (z.b. Neuseeland). Wird eine Variable für ein Seitenfeld definiert, beziehen sich alle Zwischenergebnisse nur auf den Filter. Denkbar ist eine zusätzliche Zeile bzw. Spalte einzublenden, die unabhängig vom Wert des Seitenfelds ein globales Gesamtaggregat bildet. 3.3 Marktübersicht der Pivot-Tabellen-Interfaces Es gibt einige Data Warehouse-Lösungen und OLAP-Front Ends im internationalen universitären Umfeld. Das sind neben den beiden deutschen Vertretern Joolap und 56

57 Marktübersicht der Pivot-Tabellen-Interfaces 3.3 CEUS-HB: HigherEd Analytics 1, ASU DW 2 und SKOPUS-University 3. Die Pivot-Tabellen-Interfaces von Joolap und CEUS-HB werden hier betrachtet, da es zwei der größten akademischen Data Warehouse-Initiativen in Deutschland sind. Ausserdem ist SuperX der Kooperationspartner des UniVis Explorer-Projektes und verwendet dieselben OLAP-Würfel. CEUS-HB, auch ein Projekt an einer deutschen Hochschule, ist ebenso für den Einsatz an deutschen Hochschulen konzipiert. Ausserdem ist der Zugriff auf eine Online-Demoversion möglich. Tableau Software fällt aus dem Rahmen, ist es doch keine Lösung für Hochschulen, dafür enthält das Pivot- Tabellen-Interface umfassende Möglichkeiten zur Manipulation. Die Beschreibung konzentriert sich auf die Visualisierung und Funktionalität der Pivot- Tabellen-Interfaces und orientiert sich dabei an den von Eick [6, S. 62] definierten Standard-Manipulationen (siehe Abschnitt 3.2.3) Joolap Joolap ist ein Pivot-Tabellen-Interface für Hochschulverwaltungen. Das Java-Applet wird als Client auf einem Arbeitsplatzrechner installiert. Eine Demoversion, die dieser Untersuchung zugrunde liegt, wird auf der Webseite von Memtext 4 angeboten. Abbildung XXIII: Pivot-Tabellen-Interface von Joolap 1 Data Warehouse für analytisches Reporting an amerikanischen Hochschulen, Website: (Abgerufen ) 2 Data Warehouse zur Entscheidungsunterstützung an der Arizona State University in den USA, Website: (Abgerufen ) 3 Data Warehouse mit Modulen für die Generierung vordefinierter Reports und Analysen an amerikanischen Hochschulen, Website: (Abgerufen ) 4 Download der Joolap-Demoversion unter superx/dist/joolapdemosetup.exe (Abgerufen ) 57

58 KAPITEL 3. HIERARCHISCHE VISUALISIERUNG MIT PIVOT-TABELLEN Visualisierung Die Demoversion enthält eine Daten-Visualisierung über ein Balkendiagramm sowie über eine Pivot-Tabelle. Zugrunde liegen zwei OLAP-Würfel, die Studierende- und Haushaltskosten-Daten beinhalten. Die zu analysierenden Daten sind in einem Visualisierungsbereich optisch abgetrennt (siehe Pivot-Tabelle mit dunklem Rahmen in Abbildung XXIII). An der unteren Leiste wird zu den Kennzahlen ein erläuternder Text ausgegeben, z.b. Haupthörer ohne Beurlaubte. Die Pivot-Tabelle wird in Explorer-Manier dargestellt: die Werte des Zeilenfeldes sind als Ordner visualisiert. Diese sind zu expandieren wenn sie weitere Ordner oder Blattknoten enthalten. Blattknoten besitzen jeweils eigene Symbole bzw. Icons. Enthält ein Ordner weitere Knoten wird dies mit +, dem Ordner-Symbol vorangestellt, gekennzeichnet. Für alle im Würfel vorhandenen Dimensionen kann ein Filter angelegt werden, sofern sie nicht als Zeilen- oder Spaltenfeld verwendet werden. Sie sind dann im Einschränkungsbereich (siehe Abbildung XXIII rechts neben dem Visualisierungsbereich) als Buttons hinterlegt. Nach einem Klick darauf stehen in einem Popup-Fenster die Variablenwerte aller Hierarchiestufen zur (Mehrfach-) Selektion bereit (siehe Popupfenster in Abbildung XXIII). Manipulation Zuordnung der Dimensionen Zur Selektion der Dimension dient das Pulldownfeld ausserhalb (für das Spaltenfeld) und das Pulldownfeld innerhalb der Visualisierung (für das Zeilenfeld). Nach der Auswahl passt sich die Visualisierung dynamisch an. In Abbildung XXIII handelt es sich bei den Spalten- bzw. Zeilenfeldern um die Mittelherkunft bzw. die Kostenart. Navigation in hierarchischen Dimensionen In den Werten des Zeilenfeldes kann hierarchisch navigiert werden, indem die Ordner expandiert werden. Dies entspricht einem Drill-Down und Roll-Up entlang des Klassifikationspfades der hierarchischen Dimension. Diese Möglichkeiten bieten sich auch für die Werte des Spaltenfeldes: das Kontextmenü, über die rechte Maustaste, auf der entsprechenden Spaltenüberschrift (siehe in Abbildung XXIII Alle ), zu erreichen, erlaubt hier die Navigation in der Hierarchie. Diese Operationen werden mit Drill-Down und Drill-Up bezeichnet. Die Werte werden nicht optisch geschachtelt, sondern auf derselben Ebene hinter die Spalte, auf der der Drill-Downs beruht, eingefügt. Ein Drill-Down z.b. auf Alle aus der Dimension Mittelherkunft fügt Titelgruppe 98, Titelgruppe 99 etc. als weitere Spalten hinzu. Aggregieren entlang verschiedener Dimensionen Über das Kontextmenü des Zeilenfeldes kann der Benutzer einen zu analysierenden Dimensionsknoten wählen und diesen nach weiteren Dimensionen trennen. Trennen nach entspricht der OLAP- Operation Schachtelung. Die Instanzen dieser weiteren Dimension werden als weitere Zeilen an die Elemente im aufgeklappten Baum angehängt und farblich markiert (in 58

59 Marktübersicht der Pivot-Tabellen-Interfaces 3.3 Abbildung XXIV: Joolap-Operation Schachtelung der Abschlüße innerhalb Fachsemester Abbildung XXIV wird Abschluß in FS geschachtelt). Mehrfache Schachtelung sowie Drill-Down in Spalten- und Zeilenfelder gleichzeitig ist möglich. Durch die Operation Trennen nach werden nicht nur die Instanzen der weiteren Dimension (Schachtelung) sondern zusätzlich die eigenen Dimensionsknoten (entspricht Drill-Down) sichtbar. Zusammenfassung Die Auswahl von Dimensionen und Würfel sind über die Anwendung verteilt, was zu einer gewissen Unübersichtlichkeit führt. Eine Dimension kann nur gefiltert werden, wenn sie nicht zur Anzeige auf einer der Achsen benutzt wird. Wie schon erwähnt werden die Kennzahlen als Dimensionen behandelt und sind konsequenterweise in der Einschränkungsauswahl wiederzufinden (siehe Abbildung XXIV). Es existieren ausser der Summenbildung keine weiteren Aggregationsfunktionen. Die Zwischenaggregate werden nicht optisch von den anderen Aggregaten in den Zellen abgehoben. Wie in Abbildung XXIII zu sehen werden die Zwischenaggregate des Zeilenfeldes gar nicht angezeigt. Da über die Datenhierarchie eingeschränkt wird, muss der Benutzer die Daten kennen, um zum gewünschten Eintrag zu gelangen CEUS-HB CEUS-HB ist ein computerbasiertes Entscheidungsunterstützungssystem für Hochschulen in Bayern. Es wird an der Universität Bamberg entwickelt. CEUS-HB wird über einen Webbrowser mit Dynamic HTML 5 angezeigt. Auf Fakultätsebene werden anonymisierte und konsolidierte Daten aus den Bereichen Studierende, Personalmanagement und Mittelbewirtschaftung zur Verfügung gestellt. Dabei können die Statistiken mehrerer Hochschulen verglichen werden. 5 Online-Demoversion: Login und Passwort ceus (Abgerufen ) 59

60 KAPITEL 3. HIERARCHISCHE VISUALISIERUNG MIT PIVOT-TABELLEN Der Benutzer kann selbst Berichte erstellen, wird durch einen Assistenten unterstützt, kann Berichte für andere Benutzer freigeben oder auf vordefinierte Reports und Diagramme zurückgreifen. Abbildung XXV: Pivot-Tabellen-Interface von CEUS-HB Visualisierung Die Auswahl der Kennzahlen und Dimensionen (hier Metriken und Attribute genannt) erfolgt über eine Navigationsleiste, die alle Objekte mit verschiedenen visuelle Metaphern enthält. Nach Ausführung des Berichts kann der Benutzer, über eine umfangreiche Palette an Layout-Möglichkeiten, das Aussehen der Pivot-Tabelle verändern. Manipulation Zuordnung der Dimensionen Die Dimensionen werden aus dem Navigationsbereich per Drag & Drop selektiert und in das Spalten-, Zeilen- und Seitenfeld (hier Page-by-Funktion) eingefügt. Einzelne Elemente des Schemabrowsers können nicht wirklich expandiert werden, da immer nur eine Ebene auf einmal angezeigt wird. Navigation in hierarchischen Dimensionen Die Navigationsfläche zur Auswahl der Dimensionen und Kennzahlen bietet zwar den Link zu Hierarchien an, doch angezeigt werden nur nicht-hierarchische Dimensionen. 60

61 Marktübersicht der Pivot-Tabellen-Interfaces 3.3 Drill-Down und Roll-Up in hierarchischen Dimensionen, die im Visualisierungsbereich über die Pivot-Tabelle angezeigt werden, ist möglich, sowohl für die Spalten- als auch die Zeilenfelder. Aggregieren entlang verschiedener Dimensionen Alle Dimensionen, die als Zeilen-, Spalten- oder Seitenfelder benutzt werden, können in der Visualisierungsebene an eine andere Stelle geschoben werden. So wird das Seitenfeld durch einen entsprechenden Mausklick zum Spalten- oder Zeilenfeld. Des Weiteren ist die Schachtelung aller auswählbarer Dimensionen für das Zeilenfeld möglich. Zusammenfassung Das Explorieren der Variablenwerte sowohl im Navigations- wie auch im Visualisierungsbereich ist unkomfortabel. Dies wird zusätzlich unterstützt durch die wohl installationsabhängigen langen Antwortzeiten. Dafür zeichnete sich CEUS-HB durch umfangreiche Manipulationsmöglichkeiten, die sich auf die Darstellung auswirken, aus. Des Weiteren können verschiedene Aggregationsfunktionen, wie Rang oder Prozent im Verhältnis zum Gesamtwert etc., gewählt werden Tableau Software Tableau Software ist ein visuelles Werkzeug für allgemeine Analysen also nicht für spezifische Anwendungsdomänen konzipiert. Es wird als Client auf einem Arbeitsplatzrechner installiert und greift auf gängige Datenbankensysteme 6 und Tabellenkalkulationen zu. Um die aktuelle Demoversion zu testen, muß eine Anfrage 7 an Tableau Software gestellt werden. Visualisierung Die Benutzeroberfläche ist in einen Auswahl- und Visualisierungsbereich gegliedert. Die Auswahlfläche (siehe linker Bereich in Abbildung XXVI) bildet alle Felder der zugrunde liegenden Tabellen ab und ist unter anderem unterteilt in Dimensionen und Kennzahlen. Im Visualisierungsbereich sind Platzhalter für die Zeilen-, Spalten-, Daten- und Seitenfelder vorhanden. Manipulation Zuordnung der Dimensionen Per Drag & Drop werden die Dimensionen und Kennzahlen in die Zeilen- und Spaltenfelder oder direkt in die entsprechenden Bereiche der Tabelle bewegt. Die Anzeige erfolgt dynamisch. In diesen Feldern stehen die Elemente z.b. zur Filterung oder Dimensionsänderung zur Verfügung. 6 Die OLAP-Daten des Projektes UniVis Explorer liegen in einem PostgreSQL-Datenbanksystem. Leider gehört PostgreSQL nicht zu den unterstützten Datenbankensysteme. So konnte Tableau Software nicht einfach mit den eigenen multidimensionalen Daten getestet werden. 7 Registration um die auf 14 Tage begrenzte Free Trial -Version zu erhalten unter tableausoftware.com/trial.htm (Abgerufen ) 61

62 KAPITEL 3. HIERARCHISCHE VISUALISIERUNG MIT PIVOT-TABELLEN Abbildung XXVI: Pivot-Tabellen-Interface von Tableau Software Navigation in hierarchischen Dimensionen Die Datenquelle der untersuchten Testversion ist eine Tabelle aus einer Tabellenkalkulation. Die Dimensionen sind nicht hierarchisch. Z.B. scheinen Product Category 1 und Product Category 2 Aggregationsstufen einer Dimensionshierarchie zu sein, können aber nicht als solche qualifiziert werden was Operationen wie Roll-Up bzw. Drill-Down folglich verhindert. Aggregieren entlang verschiedener Dimensionen Dimensionen können entlang der Achsen geschachtelt werden. Die Zwischenaggregate in den Zeilen und Spalten sind nach Veränderungen an der Pivot-Tabelle standardmässig nicht sichtbar, können aber manuell eingeblendet werden. Zusammenfassung Dem Benutzer bieten sich umfangreiche Interaktionsmöglichkeiten. Neben des Pivot- Tabellen-Interfaces existieren Visualisierungstechniken wie Heat Maps, Histogramme, Balkendiagramme, Scatterplots u.v.w. Tableau Software umfasst eine Historyfunktion um zwischen den Visualisierungen und Selektionsauswahlen hin und her zu blättern. Mit Copy & Paste können selektierte Datenzellen in Tabellenkalkulationen wie Microsoft Excel, bzw. Visualisierungen in Microsoft Powerpoint übernommen werden. Das Produkt besitzt umfangreiche Manipulationsoptionen. Dazu gehört, dass die Zeilen- und Spalten-Überschriften der Pivot-Tabelle fixiert werden, wenn der Benutzer scrollt und der Bildschirmbereich zu klein ist. Insgesamt ist das Interface optisch ansprechend umgesetzt. 62

63 Marktübersicht der Pivot-Tabellen-Interfaces Fazit Den untersuchten Pivot-Tabellen-Interfaces mangelt es teilweise an Übersichtlichkeit, Benutzerfreundlichkeit und der Auswahl von Manipulationsmöglichkeiten. Oftmals können hierarchische Strukturen in den Daten nicht korrekt oder überhaupt nicht abgebildet werden. 63

64 Kapitel 4 Framework Der Hauptaspekt des letzten Kapitels ist die Implementation des Visualisierungswerkzeuges Pivot-Tabelle. Neben der Generierung der Datenbankanfrage wird die Darstellung der heterogenen und gemischt-granularen Hierarchien im Navigationswerkzeug Schemabrowser und in der Pivot-Tabelle beschrieben. Abgeschlossen wird die Arbeit mit einem Ausblick über Weiterentwicklungen des UniVis Explorers. 4.1 Multifunktionswerkzeug Schemabrowser Datenbrowser vs. Schemabrowser Abbildung XXVII vergleicht einen Daten- (a) und Schemabrowser (b). Der Datenbrowser erlaubt die Navigation über die Datenstruktur, der Schemabrowser über die Schemahierarchie. Abbildung XXVII: Navigationsbrowser über die Daten- (a) und Schemastruktur (b) (Abbildung aus [32, S. 8]) So kann der Benutzer des Datenbrowsers direkt in den Dimensionswerten (beispielsweise America, North America, Mexico) navigieren, indem er die Instanzen der Hierarchiestufen, abgebildet über die Metapher Ordner, auf- oder zuklappt. Allerdings werden die Hierarchien nicht deutlich, da kein Hinweis bezüglich der Hierarchiestufe vorhanden ist. Es fehlen die Information, daß es sich bei der in Abbildung XXVII(a) abgebildeten Hierarchie um Kontinent, Region, Land handelt. 64

65 Multifunktionswerkzeug Schemabrowser 4.1 In erweiterten OLAP-Systemen wird Schema- mit Datennavigation kombiniert (siehe Abbildung XXVII (b)). Die kompaktere Darstellung visualisiert eindeutig die Hierarchiestufen. Die Instanzen jeder Aggregationsstufe können on-demand, das heisst auf explizite Benutzeranfrage, in einem Popup-Fenster zur Vorschau angezeigt werden. Die Trennung der Dimensionsstruktur und der Instanzen wird deutlich Schemabrowser UniVis Explorer Der im Projekt UniVis Explorer umgesetzte Schemabrowser (siehe Abbildung XXIX) ist wie folgt aufgebaut: die aus dem Data Warehouse an die Applikation eingebundenen Würfel sind die Ordner der obersten Stufe. Sie werden durch ein Würfelsymbol gekennzeichnet. Abbildung XXVIII: Schemabrowser UniVis Explorer Die Dimensionen werden entsprechend ihrer hierarchischen Strukturen abgebildet. Dies sorgt für die Verschachtelung. Der Startknoten einer Dimension trägt die Bezeichnung der Dimension, bspw. Nationalität oder Lehreinheit. Die granularsten Elemente der Dimensionshierachie sind die Blattknoten, die nicht weiter zu expandieren sind. Sie besitzen zur besseren optischen Unterscheidung ein unterschiedliches Symbol. Alle Ordner zwischen Startknoten und Blattknoten sind die Stufen der Aggregationshierarchie. Die Würfel sind jeweils farblich markiert, umgesetzt über einen der Dimensionsbeschriftung vorangestellten farbigen Quader. Die Würfel geben die Farbe an ihre zugehörigen Dimensionen weiter. Dimensionen mehrerer Würfel werden mit der farbigen Markierung dieser Würfel versehen (siehe in Abbildung XXVIII: die Lehreinheit besitzt eine rote und eine blaue Markierung). Im Schemabrowser des UniVis Explorers werden nicht nur Dimensionen, sondern auch die Kennzahlen und Aggregationsfunktionen angezeigt. Die Check-Boxen machen Mehrfach-Selektion möglich. Um die Navigation transparent zu halten werden vom Benutzer bereits als Dimen- 65

66 KAPITEL 4. FRAMEWORK sionen für die Visualisierung ausgewählte Knoten deaktiviert und ausgegraut dargestellt. Ebenfalls werden alle weniger granularen Hierarchiestufen von weiterer Selektion über Drag & Drops ausgeschlossen Fazit Ein Schemabrowser erreicht bessere Antwortzeiten aufgrund der geringeren Knotenmenge die abgebildet werden muß. Ein Performanzvorteil ist, daß die Instanzen nur angefragt werden, wenn explizit eine Vorschau durch den Benutzer gefordert wird. Eine zur Definition der Schemastruktur geeignete Metatabelle sieht für das Beispiel des Knotens Subkontinent wie folgt aus: Attribute sind der künstliche Startknoten (Nationality bzw. jeweils die ID), zur Einordnung in die Baumstruktur der direkte Vorfahr Kontinente sowie der Tabellenamen in der Datenbank (bspw. dim_kontinent) [32, S. 6]. Die Trennung zwischen Struktur einer Dimension und dem Inhalt bedeutet für den Benutzer, daß er sich nicht mehr in den Daten auskennen muß um effizient zu einem Eintrag zu gelangen. Sucht er etwa ein bestimmtes Land mithilfe eines Datenbrowsers, muss er wissen in welchem Ordner, das bedeutet in welchen Kontinent bzw. Subkontinent, sich der Eintrag befindet. Der wesentlich kompaktere Schemabrowser bietet als Navigations- und Filterwerkzeug erweiterte Manipulationsmöglichkeiten. 4.2 Benutzeroberfläche UniVis Explorer Abbildung XXIX: Schematische Aufteilung des UniVis Explorer mit Decomposition Tree-Visualisierung Entsprechend bewährter Richtlinien anderer OLAP-Werkzeuge besitzt der UniVis Explorer drei Hauptkomponenten auf der Benutzeroberfläche (siehe Abbildung XXIX): 66

67 Interaktion mit der Pivot-Tabelle 4.3 eine horizontale Menüleiste, einen Navigationsbereich (siehe Absatz 4.1.2) auf der linken und den Visualisierungsbereich auf der rechten Seite. Die Oberfläche enthält verschiedene Manipulationsmöglichkeiten, die dem Benutzer erlauben, Lösungen zu seiner Fragestellung zu finden. Die Anfragen erfolgen manipulativ, ein reiner Sprachmodus zur Exploration der Daten ist nicht vorgesehen. Der Benutzer benötigt keine Datenbanksprachkenntnisse. Die Buttons der Menüleiste dienen der allgemeinen Funktionsauswahl. Dazu gehört eine Historyfunktion, die das Blättern zwischen den einzelnen Darstellungsschritten ermöglicht. Über die Menüleiste erfolgt die Wahl der Visualisierungstechnik. Des Weiteren kann die Visualisierungsfläche gelöscht oder skaliert werden. Der UniVis Explorer besitzt momentan zwei Haupt-Visualisierungstechniken: der Decomposition Tree 1 (siehe Abbildung XXIX) spaltet die Daten entlang von Dimensionen. Die Dekomposition erfolgt mithilfe Standardvisualisierungen wie Balken- und Tortendiagrammen. Die zweite Art der Visualisierung ist die Pivot-Tabelle. Abbildung XXX: UniVis Explorer mit Pivot-Tabellen-Visualisierung In den Abbildungen XXIX und XXX werden dieselben Daten bzw. Dimensionen vergleichend als Decomposition Tree und als Pivot-Tabelle visualisiert. 4.3 Interaktion mit der Pivot-Tabelle Fast alle Interaktionsmöglichkeiten des UniVis Explorers befinden sich zentral an einer Stelle: dem Schemabrowser. Die Möglichkeiten zur Interaktion ergeben sich intuitiv durch: Drag & Drop (Auswahl der Dimensionen), ein Kontextmenü durch Klicken auf das entsprechende Symbol hinter dem Knoten (Filterung), 1 Für Details sei auf die Bachelorarbeiten von Roman Rädle und Andreas Weiler verwiesen. 67

68 KAPITEL 4. FRAMEWORK Markieren eines Eintrages (zur Auswahl der Kennzahl und Aggregationsfunktion) Tool-Tipps (spezifische Hinweise und Erläuterungen auf Spaltenüberschriften, sowie den Spalten- und Zeilenfeldern der Pivot-Tabelle) Zuordnung der Dimensionen Der Benutzer befördert per Drag & Drop einen Knoten aus dem Schemabrowser in das entsprechende Feld im Visualisierungsbereich der Pivot-Tabelle. Zwei Felder repräsentieren das Spalten- bzw. Zeilenfeld, siehe Abbildung XXX. Hat der Benutzer mindestens eine Kennzahl und eine Aggregationsfunktion gewählt, werden die Dimensionen entsprechend ihrer Zuordnung zum Spalten- bzw. Zeilenfeld dynamisch angezeigt. Werden weitere Dimensionen hinzugefügt, erfolgt eine automatische Aktualisierung der Pivot-Tabelle. Die Variablenwerte der Spalten- und Zeilenfelder werden an der enstprechenden Achse aufgetragen. Wird mehr als eine Dimension für ein Feld selektiert, entsteht die Pivot-Tabellen-typische Schachtelung. Rückgängig gemacht werden kann die Zuordnung schrittweise oder vollständig. Beide Aktionen erfolgen über Buttons in der Menüleiste Navigation in hierarchischen Dimensionen Neben der Navigation in den Hierarchien (Aufklappen der Ordner) und dem Explorieren der Instanzen (Vorschau-Fenster) über den Schemabrowser bietet natürlich die Pivot-Tabelle Navigationsmöglichkeiten in diesen Srukturen. Durch Hinzufügen einer granulareren Aggregationsstufe auf dieselbe Achse wird ein Drill-Down ausgeführt. Dies ist in der aktuellen Anwendung bisher nur für das Zeilenfeld realisiert, aber auch für das Spaltenfeld denkbar. Es stellt sich die Frage ob mehrfache Schachtelung auf beiden Achsen intuitiv verständlich ist. Roll-Up ist momentan nicht möglich. Um es umzusetzen wird diese Funktion in ein Kontextmenü auf die Spalten bzw. Zeilen der Pivot-Tabelle gelegt. Wählt der Benutzer diese Operation, werden die entsprechenden Instanzen der Hierarchiestufe aus der Verschachtelung entfernt. Parallel wird der Knoten im Schemabrowser wieder aktiviert Aggregieren entlang verschiedener Dimensionen Die Vorgehensweise bezüglich der Zuordnung der Dimensionen ist identisch der Zuordnung der Dimensionen in hierarchischen Dimensionen. Ein Beispiel zur Aggregation entlang verschiedener Dimensionen stellt Abbildung XXXI dar. Zeilenfelder sind Nationalität und Abschlußtyp, das Spaltenfeld ist die Hochschulzugangsberechtigung. Man erkennt das benutzerfreundliche und fehlerverhindernde Deaktivieren der bereits selektierten Hierarchiestufen. Fehlerverhindernd da die Schachtelung der Pivot- Tabelle reihenfolglich der Zuordnung der Dimensionen geschieht. Die Schachtelung entlang einer hierarchischen Dimension entspricht einem Drill-Down und ein Drill- Down in die falsche Richtung ergibt keinen Sinn. 68

69 Visualisierung verschiedener Hierarchien 4.4 Abbildung XXXI: Geschachtelte Pivot-Tabelle für das Zeilenfeld Weitere Manipulationen Ein Seitenfeld kann nicht explizit, doch in Form eines Filters benutzt werden. Über die Selektionsauswahl im Vorschau-Fenster des Schemabrowsers wird ein Filter gewählt, der auf die gesamte Darstellung wirkt. Des Weiteren kann der Benutzer Spalten verschieben um Daten besser vergleichen zu können. Das Verschieben der Spalten ändert nicht die Gruppierung und Schachtelung der Dimensionen. 4.4 Visualisierung verschiedener Hierarchien Im Folgenden wird die Darstellung von heterogenen und gemischt-granularen Hierarchien im Schemabrowser und in der Pivot-Tabelle beschrieben Im Schemabrowser In Abbildung XXXII ist ein Ausschnitt des Schemabrowsers des Haushaltskostenwürfels dargestellt. Die Knoten Administration vs. Lehre oder Verwaltung vs. Sonstige bilden die Ober- und Unterklassen-Beziehung zur abstrakten Klasse Institutionen ab. Sie besitzen, wie bereits erwähnt, eigene Subbäume aber keine gemeinsamen Aggregationsstufen auf den Baumstufen. Die beiden Unterklassen können auf der obersten Stufe gegenübergestellt und verglichen werden. Dieser Tatsache wird durch zusätzliche Knoten, benannt mit X vs. Y, gerecht [32, S. 4]. Die zweifache Rolle der Dimension der gemischt-granularen Hierarchie, als Blattkno- 69

70 KAPITEL 4. FRAMEWORK Abbildung XXXII: Visualisierung heterogener und gemischt-granularer Hierarchien im Schemabrowser ten und als Aggregationsstufe, wird am Schemabrowser offensichtlich. Eine gemischtgranulare Dimension besitzt einen zusätzlichen abstrakten Kindknoten [34, S. 11]. Dieser der gemischt-granularen Dimension gleichbenannte Knoten (bspw. Nur Fakultät) stellt als Blattknoten eine nicht-hierarchische Dimension dar [32, S. 4] In der Pivot-Tabelle Jetzt wird das eben im Kontext des Schemabrowsers eingeführte Beispiel anhand der Pivot-Tabellen-Visualisierung, siehe Abbildung XXXIII, weitergeführt. Die Nummern 1 bis 4 in beiden Abbildungen beziehen sich auf die nachfolgenden Fälle. Für alle Beispiele werden zur Vereinfachung keine Spaltenfelder und kleine, fiktive Zahlenwerte zur Vereinfachung benutzt. Fall 1 Als erstes Zeilenfeld der Pivot-Tabelle wird der Knoten Administration vs. Lehre gewählt. Alle Bestellungen der Administration werden allen Bestellungen der Lehre gegenübergestellt. In der Pivot-Tabelle, markiert mit 1, betragen alle Ausgaben der Administration, unabhängig von Projekten oder Kostenkategorien und über die gesamte Zeitperiode, Euro, bzw. der Lehre Euro. Fall 2 Die weitere Auswahl des Knotens nach Fakultät bewirkt ein Drill-Down entlang der Hierarchie Lehre Einheiten. Nun werden die Zwischenaggregate für alle Fakultäten inklusive ihrer zugeordneten Institutionen berechnet und eingefügt. Wie in Abbildung XXXIII (2) zu erkennen, betrifft die Operation Drill-Down nur die 70

71 Visualisierung verschiedener Hierarchien 4.4 Abbildung XXXIII: Visualisierung heterogener und gemischt-granularer Hierarchien in einer Pivot-Tabelle Lehre. Die Werte der Fakultäten werden also in die Lehre Einheiten-Tabelle geschachtelt und die Administrative Einheiten-Tabelle bleibt unverändert. Es ergeben sich nach diesem Schritt zwei unabhängige und optisch voneinander getrennte Tabellen. Fall 3 Wird statt nach Fakultät der Knoten Fakultät vs. Abteilung als Dimension in die Pivot- Tabelle gezogen, werden jeweils die Aggregate der beiden Subklassen Fakultät und Abteilung angezeigt. Fall 4 Wird der Blattknoten nur Fakultät als zu visualisierende Dimension ausgewählt, wird das Aggregat für die Fakultäten als Endinstanz berechnet. Visuell ergibt sich eine Tabelle wie in Fall 2 (mit anderen Zahlen). Man erkennt an den Beispielen 2, 3 und 4, daß ein Einfügen von Dimensionen zum Aufspalten der Pivot-Tabelle führt. Dies geschieht, wenn in einem Subbaum der heterogenen Hierarchie keine Veränderung durch weitere Dimensionen entsteht. Die Exploration geschieht im jeweils anderen Subbaum. 71

72 KAPITEL 4. FRAMEWORK 4.5 Implementation Einige Implementationsdetails der Java-Programmierung leiten über zu einem Schwerpunkt des Kapitels, der Generierung der Datenbankabfragen in SQL SQL und OLAP Um SQL-Anfragen zu stellen müssen die multidimensionalen Daten in relationaler Form vorliegen. Operationen wie Slicing und Dicing und Drill-Down, realisiert mit Joins und Group-by können dann ausgeführt werden. Schwieriger ist die Umsetzung von hierarchischen und multidimensionalen Aggregationen in SQL. Eine Anfrage aus dem SQL-Standard-Funktionsumfang, ohne OLAP-Erweiterungen, benötigt pro Klassifikationsstufe eine Subanfrage. Bei einer geschachtelten Pivot-Tabelle wird pro Zeilenfeld eine Subanfrage nötig. Sind beispielsweise die Haushaltskosten der Lehreinheit Geographie für alle Monate, Semester und akademische Jahre gesucht, sieht eine typische SQL-Anfrage, auch Select-Anweisung oder SFW-Block (für Select, From und Where) genannt, für die Monate wie folgt aus: 1 SELECT m.name, sum(c.betrag) 2 FROM COB_CUBE c, dim_lehreinheit l, dim_monat m 3 WHERE l.name = Geographie 4 AND l.id = c.lehre_id 5 AND m.id = c.monat_id 6 GROUP BY m.id; Die Anfrage wird für die drei Klassifikationsstufen der Zeitdimension ausgeführt. Die Tabelle dim_monat (Zeile 2) sowie die Joinbedingung (Zeile 5) werden jeweils angepasst. Monat Geographie Januar Euro Februar Euro März Euro Semester Geographie SS Euro WS Euro Akademisches Jahr Geographie 2001/ Euro 2002/ Euro Tabelle VIII: Ergebnistupel dreier Anfragen über die Zeitdimension Die Ergebnistupel der drei Anfragen sind durch die sukzessive Ausführung in einem eher unpraktischen Schema (siehe Tabelle VIII). Übersichtlicher ist eine Ergebnisformatierung wie in verschachtelten Pivot-Tabellen wo die Aggregate dann jeweils an der richtigen Stelle eingebunden sind. Beispielsweise schließt das Tupel (2001/2002, Euro) die beiden Einträge (SS 2001, Euro) und (WS 2002, Euro) als Zwischenaggregat ab. 72

73 Implementation 4.5 Bei k Stufen in der hierarchischen Dimension sind somit Unions von k Anfragen nötig. Weiterhin bedeutet dies k Durchgänge durch die Faktentabelle [16, S. 29]. Operationen Cube und Rollup OLAP-Funktionen wie Cube und Rollup unterstützen multidimensionale Anfragen und eignen sich nach Vossen [35, S. 687] besonders für das Rolap-Datenmodell. Cube bildet für sämtliche Kombinationen der Klassifikationsstufen Summen, allerdings werden Hierarchien nicht beachtet. Hingegen berechnet die Funktion Rollup hierarchische Aggregationen mit Zwischensummen. Durch diese Erweiterungen der SQL-Standardfunktionen und eine Kombination von Rollup und Cube werden die multidimensionalen Daten exakt auf das Layout der Pivot-Tabelle abgebildet [16, S. 32]. Das im Rahmen des Projektes UniVis Explorer zur Verfügung stehende Datenbanksystem PostgreSQL besitzt keine OLAP-Funktionalität. Deswegen wird auf traditionelle SQL-Operationen zurückgegriffen Technische Details der Implementation Die Programmiersprache für die Implementation der Pivot-Tabelle ist Java Version 1.5.0_07. Das Datenbankverwaltungssystem bzw. die Datenbanksprache PostgreSQL Version ist deklarativ, objektrelational und implementiert Teile des SQL-Sprachstandards. Für typische Pivot-Tabellen-Funktionalitäten wie die Berechnung der Zwischenaggregate, eine typabhängige Formatierung der Zellen sowie die optische Gruppierung der verdichteten Elemente wurde nach einer geeigneten Java-Bibliothek gesucht. Eine diese Aufgaben erfüllende Bibliothek wurde gefunden: der JTree, der java-intern die Pivot-Tabelle darstellt, benutzt die Funktionalität des EnvelopeTableModels Übersetzung der Benutzeraktionen in SQL Die folgenden Erläuterungen beruhen auf der Visualisierung der Pivot-Tabelle in Abbildung XXXI und der zugehörigen SQL-Anfrage, die sich vollständig in Anhang.1 der Arbeit befindet. Dabei sind die Dimensionen Herkunftsland und Abschlußtyp die Zeilenfelder und Hochschulzugangsberechtigung das Spaltenfeld. Hierarchische Aggregationsstufen als Zeilenfelder wirken sich auf die im Folgenden beschriebene Vorgehensweise der Datenbankanfrage nicht grundsätzlich unterschiedlich aus. Beruhend auf der Benutzerselektion von Spalten- und Zeilenfelder sowie etwaigen Filtern wird ein komplexes SQL generiert. Die Anfrage liefert die Ergebnisse in exakt der gewünschten Darstellung, sodaß die Java-Applikation keine weiteren Umsortierungen vornehmen braucht. Die Versorgung der Daten für die Pivot-Tabellen- Darstellung erfolgt also komplett auf Datenbankseite. Im Vergleich zur Lösung die das Umsortieren der Ergebnistupel auf Java-Seite beinhaltet, wird so zum einen die Netzbelastung verringert und zum anderen auch die Antwortzeit verbessert. Wählt der Benutzer Dimensionen, eine Aggregationsfunktion oder eine Kennzahl, werden diese Informationen in dynamischen Speicherstrukturen gehalten. Nach je- 2 Das EnvelopeTableModel ist erhältlich unter der BSD-Lizenz für Freie Software, Webseite mit Download (Abgerufen ). 73

74 KAPITEL 4. FRAMEWORK dem zulässigen Drag & Drop erfolgt eine Datenbankanfrage und ein erneuter Aufbau der Pivot-Tabelle. Überschriften der Pivot-Tabelle Java implementiert einen JTree, der zwei Eingabeparameter benötigt: eine eindimensionale Speicherstruktur für die horizontalen Überschriften und eine zweidimensionale Speicherstruktur für die Dateninhalte der Tabelle. Die Methode getpivottableheader() ermittelt die Überschriften der Pivot-Tabelle, nämlich nach Ländern, nach Abschlußtyp, Allgemeine Hochschulreife, Fachhochschulreife und Hochschulreife im Ausland (die letzten drei Zeichenfolgen sind die Variablen des Spaltenfeldes Hochschulzugangsberechtigung): 1 public Vector<String> getpivottableheader( 2 Vector<VDimension> xaxisdimensions, 3 Vector<VDimension> yaxisdimensions) { 4 5 int size = yaxisdimensions.size(); 6 if (xaxisdimensions.size() > 0) { 7 size += getamountoftablerows(xaxisdimensions.get(0)); 8 } 9 10 Vector<String> columnnames = new Vector<String>(); for (VDimension dimension : yaxisdimensions) { 13 columnnames.addelement(dimension.tostring()); 14 } mypsql.execute("select name from " 17 + (xaxisdimensions.get(0)).gettablename() + ";"); for (int i = yaxisdimensions.size(); i < size; i++) { 20 columnnames.addelement(mypsql.next()[0]); 21 } return columnnames; 24 } Der Funktion getpivottableheader() werden die Parameter xaxisdimensions sowie yaxisdimensions, in denen sich die vom Benutzer gewählten Knoten bzw. Dimensionen für die Zeilen- und Spaltenfelder befinden, übergeben (Zeile 1-3). Um die Anzahl der Schleifendurchgänge zu bestimmen, wird die Spaltenanzahl ermittelt. Diese setzt sich aus der Anzahl der in der Y-Achse befindlichen Felder (Zeile 5) und der Anzahl der Instanzen der Tabelle, die auf die X-Achse abgebildet (Zeile 6-8) wird, zusammen. In den eindimensionale Vektor columnnames (Zeile 10) werden die Bezeichnungen der Zeilenfelder (Zeile 12-14) direkt übernommen, hier also nach Ländern und nach Abschlußtyp. Anschließend wird eine PSQL-Anweisung ausgeführt, die aus der entsprechenden Tabelle, hier bluep_hzb, alle Ausprägungen der Hochschulzugangsberechtigung selektiert (Zeile 16-17). Dabei werden drei Tupel zurückgeliefert, Allgemeine Hochschulreife, Fachhochschulreife und Hochschulreife im Ausland, die in der For-Schleife (Zeile 19-21) an den Vektor angehängt werden. 74

75 Implementation 4.5 An die aufrufende Funktion wird im letzten Schritt (Zeile 23) der Vektor mit den Tabellenüberschriften zurückgegeben, die anschliessend die Inhalte der Pivot-Tabelle ermittelt. Datenbereich der Pivot-Tabelle Die Programmieraufwand in Java, um die Inhalte der Pivot-Tabelle zu erhalten, sind komplexer. Interessant ist hier letztendlich aber der Aufbau der Datenbankanfrage SQL, welche sich in mehrere Unteranfragen gliedert. Durch mehrere Joins werden die Daten, die als Übergabeparameter für die Pivot-Tabelle bzw. das EnvelopeTableModel dienen, zusammengesetzt. Die Gliederung der folgenden Abschnitte orientiert sich am SFW-Block, wobei die Where-Klausel in den jeweiligen Unterabfragen steckt. Die SQL-Anfrage enthält abschliessend eine Order-by-Klausel. Select-Klausel In der Auswahlliste der Select-Klausel, die bestimmt, welche Spalten der Quelle auszugeben sind, werden die benötigten nicht-leeren Variablenwerte des Zeilenfeldes (Zeile 2-11) sowie alle Aggregate aus dem Datenbereich (Zeile 12-17) selektiert. 1 SELECT 2 CASE 3 WHEN not subselect0.spalte0 isnull THEN subselect0.spalte0 4 WHEN not subselect1.spalte0 isnull THEN subselect1.spalte0 5 WHEN not subselect2.spalte0 isnull THEN subselect2.spalte0 6 END AS spalte0, 7 CASE 8 WHEN not subselect0.spalte1 isnull THEN subselect0.spalte1 9 WHEN not subselect1.spalte1 isnull THEN subselect1.spalte1 10 WHEN not subselect2.spalte1 isnull THEN subselect2.spalte1 11 END AS spalte1, 12 CASE 13 WHEN "aggr2" isnull THEN 0 ELSE "aggr2" END, 14 CASE 15 WHEN "aggr3" isnull THEN 0 ELSE "aggr3" END, 16 CASE 17 WHEN "aggr4" isnull THEN 0 ELSE "aggr4" END From-Klausel Für jede Ausprägung auf der X-Achse, also für jeden Variablenwert des Spaltenfeldes, wird eine Unteranfrage generiert. Diese Unteranfrage selektiert die Variablenwerte des Zeilenfeldes (sozusagen die Überschriften der Zeilen, also beispielsweise Japan, Zertifikat / Zusatzstudium) sowie das Aggregat des jeweiligen Spaltenfeldes. Diese eindeutige Kennzeichnung der Zeile durch seine Überschriften wird benötigt um anschließend die Unteranfragen sukzessive zusammenzuführen. Im Folgenden wird dies an zwei Unteranfragen, die die Spalten Allgemeine Hochschulreife bzw. Fachhochschulreife selektieren, demonstriert. Unteranfragen der From-Klausel Die dargestellte Unteranfrage liefert die Ergebnistupel aus der Tabelle IX. Ein Platzhalter, hier beispielsweise *NULL*, wird benutzt 75

76 KAPITEL 4. FRAMEWORK damit nicht zugeordnete Kennzahlen nicht verloren gehen, sondern für Benutzer zur weiteren Nachforschung verfügbar sind. 1 SELECT 2 CASE WHEN dim_land.name isnull THEN *NULL* 3 ELSE dim_land.name END AS spalte0, 4 CASE WHEN dim_abschlussarten.name isnull THEN *NULL* 5 ELSE dim_abschlussarten.name END AS spalte1, 6 SUM(sos_cube.koepfe) AS "aggr0" 7 8 FROM sos_cube 9 FULL JOIN bluep_hzb 10 ON ( bluep_hzb.id = sos_cube.hzb ) 11 FULL JOIN bluep_nation 12 ON ( bluep_nation.id = sos_cube.nation ) 13 FULL JOIN dim_land 14 ON ( dim_land.id = bluep_nation.land ) 15 FULL JOIN bluep_abschluss 16 ON ( bluep_abschluss.id = sos_cube.abschluss ) 17 FULL JOIN dim_abschlussarten 18 ON ( dim_abschlussarten.id = bluep_abschluss.abschlussart ) WHERE bluep_hzb.name = Allg. Hochschulreife 21 GROUP BY dim_land.name, dim_abschlussarten.name; spalte0 spalte1 aggr2 Deutschland Diplom Serbien u. Montenegro Diplom 51 Spanien Diplom 19 Japan Diplom 10 Turkmenien Diplom 3 Deutschland Bachelor Tabelle IX: Ergebnistupel der Unteranfrage nach Länder, Abschluss und Allgemeiner Hochschulreife Diverse Joins (Zeile 9-18) verbinden die Faktentabelle mit den Dimensionstabellen. Die Where-Klausel der Unteranfrage schränkt auf den Variablenwert ein, hier in Zeile 20 auf Allg. Hochschulreife. Durch die Group-by-Klausel (Zeile 21) werden die Ergebnistupel für die gewünschte Formatierung zusammengefaßt. Verbinden der Unteranfragen durch Joins Für alle weiteren Unteranfragen ist das Vorgehen entsprechend, die Ergebnistupel, also die Ausprägung des Spaltenfeldes, die Aggregate sowie die Anzahl der Ergebnistupel, variieren natürlich. Um sicherzustellen dass alle Tupel in das Gesamtergebnis eingeschlossen sind, erfolgt die Verbindung der Ergebnistupel der Unteranfragen über den Full Join. 1 SELECT * 2 3 FROM 4 76

77 Implementation ( SELECT 6 CASE WHEN dim_land.name isnull THEN *NULL* 7 ELSE dim_land.name END AS spalte0, 8 CASE WHEN dim_abschlussarten.name isnull THEN *NULL* 9 ELSE dim_abschlussarten.name END AS spalte1, 10 SUM(sos_cube.koepfe) AS "aggr0" FROM sos_cube 13 FULL JOIN bluep_hzb 14 ON ( bluep_hzb.id = sos_cube.hzb ) 15 FULL JOIN bluep_nation 16 ON ( bluep_nation.id = sos_cube.nation ) 17 FULL JOIN dim_land 18 ON ( dim_land.id = bluep_nation.land ) 19 FULL JOIN bluep_abschluss 20 ON ( bluep_abschluss.id = sos_cube.abschluss ) 21 FULL JOIN dim_abschlussarten 22 ON ( dim_abschlussarten.id = bluep_abschluss.abschlussart ) WHERE bluep_hzb.name = Allg. Hochschulreife 25 GROUP BY dim_land.name, dim_abschlussarten.name 26 ) AS subselect FULL JOIN ( SELECT 31 CASE WHEN dim_land.name isnull THEN *NULL* 32 ELSE dim_land.name END AS spalte0, 33 CASE WHEN dim_abschlussarten.name isnull THEN *NULL* 34 ELSE dim_abschlussarten.name END AS spalte1, 35 SUM(sos_cube.koepfe) AS "aggr1" FROM sos_cube 38 FULL JOIN bluep_hzb 39 ON ( bluep_hzb.id = sos_cube.hzb ) 40 FULL JOIN bluep_nation 41 ON ( bluep_nation.id = sos_cube.nation ) 42 FULL JOIN dim_land 43 ON ( dim_land.id = bluep_nation.land ) 44 FULL JOIN bluep_abschluss 45 ON ( bluep_abschluss.id = sos_cube.abschluss ) 46 FULL JOIN dim_abschlussarten 47 ON ( dim_abschlussarten.id = bluep_abschluss.abschlussart ) WHERE bluep_hzb.name = Fachhochschulreife 50 GROUP BY dim_land.name, dim_abschlussarten.name 51 ) AS subselect ON ( 54 CASE 55 WHEN not subselect0.spalte0 isnull THEN subselect0.spalte0 56 END = subselect1.spalte0 57 AND 58 CASE 59 WHEN not subselect0.spalte1 isnull THEN subselect0.spalte1 60 END = subselect1.spalte1 61 ); 77

78 KAPITEL 4. FRAMEWORK Die Join-Bedingung muß für alle Zeilenfelder erfüllt sein, deswegen erfolgt der Join über nach Länder und Abschlußtyp (Zeile 53-61). spalte0 spalte1 aggr0 spalte0 spalte1 aggr Dänemark Diplom 3 NULL NULL NULL Deutschland Diplom Deutschland Diplom 8677 NULL NULL NULL Frankreich Diplom 3 NULL NULL NULL Ghana Diplom Tabelle X: Ergebnistupel der Unteranfrage nach Länder, Abschlußtyp, Allgemeiner Hochschulreife (Spalte aggr0) und Fachhochschulreife (Spalte aggr1) Die Tabelle X stellt ausschnittsweise die Ergebnistupel der beiden Unteranfragen dar, bevor sie durch einen Full Join vereinigt werden. NULL-Zellen weisen darauf hin, daß keine Werte für die Selektionsbedingung gefunden wurden. Order-by-Klausel Sortierungsattribute werden in der Order-by-Klausel definiert. Standardmässig, ohne Angabe von ASC (ascending, dt. aufsteigend) bzw. DESC (descending, dt. absteigend), wird eine aufsteigende Sortierung durchgeführt. Zuerst erfolgt die Sortierung nach Ländern (spalte0) und dann nach Abschlußtyp (spalte1) ORDER BY spalte0, spalte1; Filterung Werden im Schemabrowser Werte selektiert auf die gefiltert werden soll, reagiert das SQL wie folgt. Filterung auf Spaltenvariable Werden wie im Fallbeispiel die Hochschulzugangsberechtigungen auf der Spaltenzeile angezeigt, und auf diesem Feld ein Filter definiert, werden lediglich die entsprechenden Unteranfragen ausgeführt. Beispielsweise entfällt die Unteranfrage für Allgemeine Hochschulreife wenn darauf ein ausschließender Filter gesetzt wurde. Die Unteranfragen ermitteln lediglich die Aggregate für die restlichen Spaltenfelder. Filterung auf Zeilenvariable Wirkt sich der Filter auf die Zeilenvariable aus, wird eine zusätzliche Where-Bedingung in jede Unteranfrage angefügt. Das folgende Codebeispiel demonstriert dies an einer Unteranfrage, wobei auf die Länder Dänemark und Frankreich (Zeile 21) gefiltert wird. 1 SELECT 2 CASE WHEN dim_land.name isnull THEN *NULL* 3 ELSE dim_land.name END AS spalte0, 4 CASE WHEN dim_abschlussarten.name isnull THEN *NULL* 5 ELSE dim_abschlussarten.name END AS spalte1, 6 SUM(sos_cube.koepfe) AS "aggr2" 7 8 FROM sos_cube 9 FULL JOIN bluep_hzb 10 ON ( bluep_hzb.id = sos_cube.hzb ) 78

79 Ausblick FULL JOIN bluep_nation 12 ON ( bluep_nation.id = sos_cube.nation ) 13 FULL JOIN dim_land 14 ON ( dim_land.id = bluep_nation.land ) 15 FULL JOIN bluep_abschluss 16 ON ( bluep_abschluss.id = sos_cube.abschluss ) 17 FULL JOIN dim_abschlussarten 18 ON ( dim_abschlussarten.id = bluep_abschluss.abschlussart ) WHERE bluep_hzb.name = Allg. Hochschulreife 21 AND dim_land.name IN ( Dänemark, Frankreich ) 22 GROUP BY dim_land.name, dim_abschlussarten.name; Dasselbe Vorgehen tritt ein für zu filternde Dimensionen, die sich nicht als Variable im Zeilen- oder Spaltenfeld befinden. Hier erfolgt zusätzlich ein Join auf die zu filternde Dimension. Fazit Optimierungspotential besteht an der Stelle an der der Stringvergleich stattfindet. Mit einem fortlaufenden Primärschlüssel in den Subdimensionstabellen kann statt des teuren Stringvergleichs ein schnellerer Vergleich über die ID-Spalte erfolgen. Die Where-Klausel des letzten Codebeispiel lautet dann beispielsweise: WHERE bluep_hzb.id = 1 anstatt WHERE bluep_hzb.name = Allg. Hochschulreife Dem höheren Aufwand auf Java-Seite um das SQL zu generieren, steht der Vorteil gegenüber, daß dieses Vorgehen exakt die Pivot-Tabellen-Formatierung schafft. Das EnvelopeTableModel, welches den JTRee übergeben bekommt, sorgt für die Bildung der Zwischenaggregat- und Aggregatzeilen bzw. -spalten. Fehlerhafte Aggregate aufgrund unzulässiger Faktentyp- und Kennzahlkombination werden nicht beachtet. Einige Lösungsvorschläge dazu finden sich im Anschluß. 4.6 Ausblick In diesem Abschnitt werden einige Ideen für Erweiterungen des Interfaces vorgeschlagen Verhindern von Interpretationsfehlern Wie bereits erwähnt sind manche Kombinationen von Kennzahlentypen und Aggregationsfunktionen für fehlerhafte Aggregate verantwortlich. Um diese Gefahrenquelle zu verhindern sind im UniVis Explorer folgende Lösungsstrategien denkbar. 79

80 KAPITEL 4. FRAMEWORK Möglichkeit 1 Um falsche Aggregate bezüglich der Zeitdimension zu vermeiden, kann die Auswahl eines Semesters im Falle des Studierendenwürfels obligatorisch gemacht werden. Diese Einschränkung auf die granularste Hierarchiestufe ermöglicht die fehlerfreie Analyse aller Kennzahlen, auch der Kopfstatistik. Möglichkeit 2 Durch dynamisches Anpassen der Auswahlmöglichkeit für Kennzahlen, Funktionen oder Dimensionen werden nur zulässige Kombinationen ermöglicht. In einer Metatabelle werden die erlaubten Kombinationen hinterlegt. Wählt der Benutzer beispielsweise eine Zeitdimension als Spalten- oder Zeilenfeld, werden alle unzulässigen Aggregationsfunktionen für die Selektion deaktiviert. Möglichkeit 3 Weniger restriktiv ist der folgende Vorschlag: durch visuelle Hervorhebung von Aggregaten, die auf kritischen Kennzahl-Fakten-Kombinationen beruhen, wird der Benutzer vor fehlerhaften Rückschlüssen gewarnt. Auch hier bildet eine Metatabelle die Basis Erweiterung der Funktionalität des Schemabrowsers Der abstrakte Startknoten jeder Dimensionshierarchie im Schemabrowser erhält eine weitere Funktion. In der aktuellen Implementation besitzt er nur abstrakte Bedeutung als Platzhalter und Beschriftung der darunterliegenden Dimension. Der Versuch den Startknoten per Drop & Drop in den Visualisierungsbereich zu bewegen bleibt bisher für den Benutzer erfolglos. Denkbar ist nun, daß die Benutzeraktion, die den Knoten in die Visualisierungsfläche bewegt, als Auswahl aller Aggregationsstufen der Dimension verstanden wird. Bewegt der Benutzer beispielsweise den abstrakten Startknoten Nationalität in ein Feld der Pivot-Tabelle, werden dessen Hierarchiestufen Kontinent, Region und Land angezeigt Anzeige von Pivot-Tabelle und weiterer Visualisierung Um die Vorteile verschiedener Visualisierungstechniken zu kombinieren, ist eine parallele Anzeige mehrerer Visualisierungen denkbar, siehe Abbildung XXXIV. Beispielsweise kann ein Decomposition Tree im selben Panel wie die Pivot-Tabelle dargestellt werden. Interaktionen des Benutzers wirken sich auf beide Darstellungen aus. Eine grafische Visualisierung wird kombiniert mit der Darstellung konkreter Daten. Dies ist sinnvoll da bei Visualisierungen wie den Decomposition Trees die Beschriftungen der einzelnen Elemente verschwinden können wenn zu viele Werte gleichzeitig angezeigt werden. Diese Information bekommt der Benutzer dann über die Pivot- Tabelle hinzu. 80

81 Abbildung XXXIV: Parallele Exploration in Decomposition Tree und Pivot-Tabelle 81