OLAP und Aggregierung

Transkript

1 Stärkung der SelbstOrganisationsfähigkeit im Verkehr durch I+K-gestützte Dienste Seminar Data Warehousing im Verkehrsbereich Sommersemester 2003 OLAP und Aggregierung von Jan Sandberger Betreuer: Heiko Schepperle Datum: 9. Juli 2003

2 Inhaltsverzeichnis 1. OLAP Was ist das? OLAP Was ist das? Die Regeln von Codd Die FASMI-Kriterien Architekturvorschlag 7 2. OLAP Operationen Einführung eines Beispiels der RollUp-Operator der Drill-Down-Operator Der Pivot-Operator Der Slice-And-Dice-Operator SQL-Erweiterungen zur OLAP-Unterstützung erweiterte Aggregierungsfunktionen Unterstützung der Multidimensionalität der RollUp-Operator Der Cube-Operator Der GroupingSet-Operator ROLAP, MOLAP, HOLAP Bedeutung und Unterschiede ROLAP Relationale OLAP-Server MOLAP Multidimensionale OLAP-Server HOLAP hybride OLAP-Server 13

3 1. OLAP Was ist das? 1.1 OLAP Was ist das? OLAP steht für Online Analytical Processing, und damit für eine ganze Klasse von Analysewerkzeugen, mit der Daten in Data Warehouse Systemen analysiert werden können. Analysen betreiben bedeutet immer, etwas auszuwerten, um Zusammenhänge zu erkennen. Im speziellen Falle des Online Analytical Processing dient die Analyse dazu, aus einem großen unübersichtlichen Datenbestand in einem Data Warehouse Zusammenhänge zu erkennen und damit für den Menschen brauchbare Informationen aus den Daten zu gewinnen. Es geht also darum, Wissen aus den Daten zu extrahieren, das helfen kann, Entscheidungen zu treffen. OLAP Systeme gehören damit zu den entscheidungsunterstützenden Systemen. Da Data Warehouse Systeme oft in (Groß-)Unternehmen eingesetzt werden, handelt es sich bei den im Data Warehouse abgelegten Daten oft um Beschreibungen von Geschäftsprozessen und Unternehmensentwicklungen. Dementsprechend handelt es sich bei den Analyse Treibenden meist um Manager und Unternehmensanalysten, und damit oft um Laien auf dem Gebiet der Datenbanktechnologie. Aus diesem Grund sind OLAP Systeme so entwickelt worden, dass sie wenig Kenntnisse über Datenbanken voraussetzen, um diese analysieren zu können. 1.2 Die Regeln von Codd Der Begriff OLAP geht auf Edgar F. Codd zurück, der ihn anlässlich der Präsentation eines multidimensionalen Datenbanksystems prägte. Codd, der vorher schon eine Reihe von Kriterien für Online Transactional Processing (OLTP) Systeme eingeführt hatte, veröffentlichte Regeln/Kriterien für OLAP Systeme, anhand derer OLAP Systeme bewertet und entwickelt wurden (vgl. [Codd93]). 1. Multidimensionale, konzeptuelle Sichtweise Für die Analyse soll eine Sichtweise zur Verfügung gestellt werden, die sich an den Konzepten der gespeicherten Geschäftsprozesse orientiert und nicht an grundlegenden (z.b. relationalen) Datenbankkonzepten. Kenngrößen werden aus der Sicht von Dimensionen betrachtet, die eine intuitive Sicht auf die Daten ermöglichen und das Schemadesign erleichtern. 2. Transparenz OLAP-Systeme können auf mehrere Data Warehouse Systeme zugreifen. Für den Anwender muss dieser Zugriff transparent, also unbemerkt, entstehen. Unbemerkt heißt auch, dass durch die Benutzung mehrer Datenquellen keine negativen Auswirkungen auf Funktionalität, Bedienbarkeit oder Performanz ergeben. 3. Zugriffsmöglichkeiten Wie eben erwähnt soll der Zugriff auf mehrere Datenquelle möglich sein, sowohl innerbetriebliche als auch unternehmensexterne. Daher müssen die verschiedenen logischen Schemata der Data-Warehouse-Systeme auf ein umfassendes heterogenes OLAP-Schema abgebildet werden. 4. Gleichbleibende Antwortzeit Um eine effektive Analyse gewährleisten zu können, sollte die Antwortzeit auf eine OLAP-Anfrage nicht länger als 5 20 Sekunden betragen. Diese Antwortzeit sollte unabhängig von der Anzahl der Dimensionen, der Anzahl der Klassifikationsebenen und der Menge der im Data Warehouse abgelegten Daten sein.

4 5. Client/Server Architektur Alle bisher vorgestellten Referenzarchitekturen schlagen eine Trennung der Speicherung der Daten im Data Warehouse und der Verarbeitung bzw. Darstellung der Daten durch OLAP-Systeme vor. Der Vorteil dieser Variante ist die Möglichkeit, ressourcenintensive Berechnungen auf dem Server ausführen zu können und den Netzwerkverkehr so gering wie möglich halten zu können. Um so wichtiger ist es, dass OLAP-Server eine offene Schnittstelle für verschiedene Anwendungen zur Verfügung stellen. 6. Generische Dimensionalität Die Dimensionen sollten in ihrer Struktur und Funktionalität einheitlich sein. Dimensionen sollten nicht an bestimmte Voraussetzungen geknüpft sein. 7. Dynamische Behandlung dünn besetzter Matrizen OLAP Systeme verwenden ein Datenwürfelmodell, wobei die Kanten des Würfels den einzelnen Dimensionen entsprechen. Diese Würfel, die intern als Matrizen abgelegt werden, sind meist sehr dünn besetzt. Daher müssen OLAP-Systeme in der Lage sein, effizient mit dünn besetzten Matrizen umzugehen. Ein Ansatz ist, das physische Schema anzupassen, um einen höheren Füllgrad der Würfel zu erreichen. Diese Anforderung an OLAP Systeme wird mit steigender Dimensionalität des Modells wichtiger. 8. Mehrbenutzer-Unterstützung Wie für jedes Datenbanksystem ist auch eine zentrale Forderung an OLAP-Systeme, dass konkurrierende Zugriffe auf Daten möglich sein sollen. Auch Zugriffsrechte müssen sehr feingranular vergeben werden können. 9. Uneingeschränkte kreuzdimensionale Dimensionen Alle Berechnungen, die sich durch Navigieren durch die Aggregationsebenen bzw. Hierarchieebenen innerhalb einer oder mehrerer Dimensionen ergeben, soll das OLAP Werkzeug selbständig erkennen und ableiten. 10. Intuitive Datenbearbeitung Die Benutzeroberfläche soll so gestaltet sein, dass sie einfach und ergonomisch zu erlernen und zu benutzen ist. Insbesondere soll sich die Funktionalität der Oberfläche an der Sicht der Dimensionen orientieren und somit einfache Neuausrichtungen der Dimensionen und Aggregationsebenen zulassen. 11. Flexible Berichterstellung Von der Berichterstellung wird gefordert, dass sie Daten unabhängig von den Dimensionen anordnen und darstellen kann. 12. Unbegrenzte Anzahl von Dimensionen und Klassifikationsebenen Diese Forderung ist eher als idealistisch zu betrachten und ist in der Realität kaum umzusetzen. Meistens lassen sich fünf bis acht Dimensionen finden. Zwar findet sich oft die Forderung, dass 20 bis 30 Dimensionen unterstützt werden sollen, diese erfüllen dann jedoch oft nicht mehr die Orthogonalitätseigenschaft.

5 Zwei Jahre nach Veröffentlichung dieser zwölf Regeln erweiterte Codd 1995 diesen Regelsatz um weitere sechs Regeln (vgl. [OLAP03a]). Grund dafür waren gestiegene Anforderungen der multidimensionalen Datenanalyse gerecht zu werden. 1. Datenintegration Für den Anwender sollten nicht nur die eigenen multidimensionalen Daten verfügbar sein, sondern auch die darunter liegenden Daten (vgl. Vorschlag einer Referenzarchitektur, s.u.) 2. Unterstützung verschiedener Analysemodelle Das OLAP System sollte vier Analysemodelle unterstützen, die hier kurz dargestellt werden sollen: das kategorische Analysemodell entspricht dem einfachen Reporting. Es dient der Beschreibung des gegenwärtigen Zustands der Daten durch den Vergleich mit historischen Daten. das exegetische Analysemodell ist interaktiver angelegt als das kategorische Modell und ermöglicht es, die Schritte von den historischen Daten zu den aktuellen Daten nachzuverfolgen. das kontemplative Analysemodell führt Was wäre wenn Analysen durch. Dabei werden Ergebnisse von Berechnungen mit simulierten Daten errechnet. Es werden also simulierte Daten vorgegeben, um zu analysieren, wie sich die Ergebnisse verändern. das formelbasierte Analysemodell geht den gegenteiligen Weg. Hier werden Ergebnisse vorgegeben, und es wird versucht, zu analysieren, wie sich die Daten ändern müssen, um auf das gewünschte Ergebnis zu kommen. Dieses Analysemodell ist ein sehr komplexes und bisher nur sehr wenig in OLAP Produkten zu finden. 3. Trennung von analyseorientierten und operativen Daten Änderungen in der OLAP-Datenbank dürfen keine Änderungen in den zugrunde liegenden Detaildaten zur Folge haben, da sonst deren Integrität gefährdet ist. 4. Trennung der Speicherorte Da Schreiboperationen auf der OLAP-Datenbank möglich sein sollen, müssen die Speicherorte der analyseorientierten Daten der OLAP-Datenbank und den operativen Datenbank des Data Warehouse getrennt werden. Weitere Gründe für eine Trennung der Speicherorte sind Performanzprobleme und die einfachere Integration verschiedener Schemata aus heterogenen Quellsystemen. 5. Unterscheidung zwischen Null- und Fehlerwerten Das OLAP System muss in der Lage sein, zwischen leeren Feldern und dem numerischen Inhalt Null bzw. alphanumerischen Inhalt SPACE/LEERZEICHEN unterscheiden können. 6. Behandlung von fehlenden Werten Leere Zellen der OLAP Datenbank sollen effizient verwaltet und zur Speicherplatzoptimierung genutzt werden.

6 1.3 Die FASMI-Kriterien Die in Kapitel 1.2. genannten Kriterien haben sich in der Praxis für die Entwicklung und Bewertung von OLAP Werkzeugen als zu umfangreich und zu theoretisch erwiesen. Daher wurde im OLAP Report eine einfache, produktunabhängige Definition entwickelt, die FASMI- Definition (vgl. [OLAP03]). FASMI steht für Fast Analysis of Shared Multidimensional Information. Folgende Kriterien wurden darin festgelegt: 1. Geschwindigkeit Das OLAP-System sollte in der Lage sein, die meisten Anfragen innerhalb von fünf Sekunden zu beantworten, einige komplexe Anfragen in höchstens zwanzig Sekunden. Zeitkritisch sind nicht nur die Analysen und deren Präsentation, sondern auch hierarchische Konsolidierungen innerhalb der Dimensionen und Berechnungen wie sie beispielsweise bei der Erstellung materialisierter Sichten ausgeführt werden. 2. Analysemöglichkeit Das OLAP-System soll intuitiv bedienbar und anwenderfreundlich sein. Es soll möglich sein, beliebige Berechnungen durchzuführen und verschiedene Präsentationsformen zu nutzen. Es wird jedoch nicht verlangt, dass diese Funktionalität vom OLAP-System selbst angeboten wird, es genügt, wenn das System eine Schnittstelle z.b. für Excel o.ä. bereit stellt. 3. Sicherheit Es muss ein sicherer Mehrbenutzerbetrieb gewährleistet sein. Ähnlich wie bei OLTP- Systemen müssen Zugriffsrechte auf Zellebene vergeben werden können und Sperrverfahren konkurrierenden Zugriff auf Datenelemente regeln. 4. Multidimensionalität Die Multidimensionalität ist das Schlüsselkriterium von OLAP-Datenbanken. Daher soll dem Anwender eine multidimensionale, konzeptuelle Sichtweise auf die Daten zur Verfügung gestellt werden. Beliebige Dimensionen sollen in Anfragen kombiniert werden können. 5. Kapazität OLAP-Systeme sollen auch große Mengen von Daten verwalten können und gut skalieren, um auch bei steigender Datenmenge stabile Antwortzeiten gewährleisten zu können.

7 1.4 Architekturvorschlag (vgl. [Chaud]) Operative Datenbanken Data Warehouse OLAP Server Analyse E-T-L Serve Serve Report / Query Data Mining Data Marts

8 2. OLAP Operationen 2.1 Einführung eines Beispiels An dieser Stelle möchte ich ein Beispiel einführen, anhand dessen die verschiedenen OLAP- Operationen erklärt werden sollen. Es handelt sich um ein SnowFlake-Schema, bei dem der Übersichtlichkeit wegen die Faktentabelle weggelassen wurde. Dieses Schema modelliert eine fiktive Firma mit Filialen in den USA und Kanada, die Elektronikprodukte, Medikamente und Kleidung vertreibt (vgl. [Colo02]). Top Welt Jahr Kontinent Alle Produkte Halbjahr Staat Produktlinie Quartal Tertial Land PGruppe Monat Woche Stadt Produkt Tag Die OLAP-Anfrage wertet die Kennzahlen Summe und Anzahl nach den markierten Feldern aus, also nach Staaten, Produktlinien und Quartal. Unter Summe ist die Summe aller Umsätze zu verstehen, unter Anzahl die Summe der verkauften Produkte. Das Anfrageergebnis sieht dann wie folgt aus: Elektronik Medikamente Kleidung Summe Anzahl Summe Anzahl Summe Anzahl USA Canada USA Canada

9 2.2 der RollUp-Operator Der RollUp-Operator berechnet das Anfrageergebnis der Anfrage, die sich auf eine höhere Klassifikationsstufe in mindestens einer Dimension bezieht. In unserem Beispiel wollen wir ein Roll-Up in der Dimension Geografie betrachten, also über den ganzen Kontinent Nordamerika aggregieren. Elektronik Medikamente Kleidung Summe Anzahl Summe Anzahl Summe Anzahl Wie man sieht, nimmt die Genauigkeit der Anfrage ab, und die Zahl der angezeigten Daten nimmt ab. Die Dimension Geografie taucht hier nicht mehr auf, da wir bereits das Top Element der Dimension erreicht haben (unter der Annahme, dass nur Filialen in Nordamerika existieren). Weiter ist zu beachten, dass sich die betrachteten Kennzahlen einfach durch Summieren aggregieren lassen. Bei einer Kennzahl wie durchschnittlicher Umsatz pro Artikel würde das Summieren zu falschen Werten führen. 2.3 der Drill-Down-Operator Mit Hilfe des Drill-Down-Operators kann man innerhalb einer oder mehrer Dimensionen in der hierarchischen Struktur nach unten navigieren, also eine genauere Aufschlüsselung der Daten erreichen. In unserem Beispiel wird die Dimension Geografie genauer aufgeschlüsselt, es interessieren also nicht nur die Zahlen der Staaten, sondern auch die Zahlen der einzelnen Bundesländer. Entsprechend nimmt auch die Menge der angezeigten Daten zu. Dass im Beispiel die Menge der zusätzlich angezeigten Daten nur so wenig zunimmt, liegt daran, dass es nur in drei Ländern Filialen gibt. Elektronik Medikamente Kleidung Summe Anzahl Summe Anzahl Summe Anzahl USA Californien New York Canada Ontario USA Californien New York Canada Ontario

10 2.4 Der Pivot-Operator Der Pivot-Operator ändert an den numerischen Anzeigewerten nichts. Verändert wird nur die Sicht auf die Daten. Im Modell des Datenwürfels (vgl. [Nkou03]) bewirkt der Pivot-Operator eine Drehung des Datenwürfels an einer oder mehrerer Dimensionslinien. In der tabellarischen Ausgabe ergibt sich folgendes Bild Summe Anzahl Summe Anzahl Elektronik USA Canada Med USA Canada Kleidung USA Canada Der Slice-And-Dice-Operator Die bisher betrachteten Operatoren konnten auf den Datenbestand zugreifen und nach verschiedenen Hierarchieebenen auswerten. Allerdings greifen die bisher betrachteten Operatoren immer jeweils auf den gesamten Datenbestand zu. Der Slice-And-Dice-Operator lässt es zu, einzelne Ebenen oder Zellen auszuwerten. Slice-And-Dice greift also nicht auf den gesamten Datenbestand zu sondern nur auf die Daten in einem bestimmten Teilwürfel. In unserem Beispiel könnte die Ausgabe auf die USA beschränkt werden, wenn die Daten aus Kanada momentan nicht interessieren.

11 3. SQL-Erweiterungen zur OLAP-Unterstützung Da OLAP-Werkzeuge in den letzten Jahren immer größere Verbreitung gefunden haben und zu einem wichtigen Wirtschaftszweig geworden sind, versuchen die großen Hersteller von Datenbanken, OLAP-Anfragen serverseitig zu unterstützen. Die verbreitetsten Mechanismen sollen hier kurz dargestellt werden. 3.1 erweiterte Aggregierungsfunktionen Standardmäßig unterstützen die meisten Datenbanksysteme einfache Aggregierungsfunktionen wie Summen- oder Durchschnittsbildung. Bei der Analyse von Daten mittels OLAP-Werkzeugen werden jedoch häufig weitere Statistikfunktionen wie Quantile, Mediane oder Mittelwerte benutzt. Aus diesem Grund sind diese Funktionen in den neueren SQL Standards aufgenommen und in den meisten der großen Datenbankprogramme auch schon integriert worden. 3.2 Unterstützung der Multidimensionalität Es gibt Ansätze, das multidimensionale Datenmodell der OLAP-Datenbanken direkt zu unterstützen. Dafür wird der Group-By-Operator eines SQL-Ausdrucks um Funktionalität erweitert. Er erlaubt zum Einen die Gruppierung nach mehreren Attributen. Zum Anderen wird er in manchen DBMS um den RollUp- den Cube- und den GroupingSet-Operator erweitert. Eine genaue Beschreibung dieser Operatoren findet sich in [Colo02]. Auch diese Erweiterungen sind teilweise bereits im neuesten SQL Standard von 2003 aufgenommen worden der RollUp-Operator Der RollUp-Operator erzeugt automatisch eine Reihe von Group-By-Klauseln. Verallgemeinert werden aus RollUp(c1, c2, cn) die Klauseln (c1, c2,, cn), (c1, c2,..., cn-1),..., (c1, c2), (c1), () erzeugt. Beispielsweise werden aus RollUp(country, state) folgende Group-By-Klauseln generiert: (country, state), (country), ( ). Die Anfrage an das Data Warehouse in o.g. Beispiel SELECT staat, land, SUM(Summe) AS Summe FROM fact f, location l WHERE f.lid = l.lid GROUP BY ROLLUP (country, state) liefert folgendes Ergebnis. Staat Land Summe ,24 Canada ,64 Canada Ontario 35754,64 USA ,6 USA Californien ,41 USA New York 95664,19 Zu beachten ist, dass die Tabelle fact die Faktentabelle des Data-Warehouse-Systems ist, auf die im Beispiel der Einfachheit halber verzichtet wurde.

12 3.2.2 Der Cube-Operator Im Gegensatz zum RollUp-Operator erzeugt der Cube-Operator Group-By-Klauseln mit allen möglichen Teilmengen der Attribute, die dem Cube-Operator übergeben wurden. Werden dem Cube-Operator beispielsweise 3 Attribute übergeben, so erzeugt der Cube-Operator 2 3 = 8 Group- By-Klauseln Der GroupingSet-Operator Der GroupingSet-Operator erlaubt es, mehrere Group-By-Klauseln in einem Statement zu formulieren. Der GroupingSet Operator ist äquivalent zur Vereinigung von zwei oder mehr Select-Statements, wobei jeder Group-By-Operator in den einzelnen Select-Statements einem Set des Grouping-Set-Operators entspricht. Die Anfrage an das Data Warehouse in o.g. Beispiel SELECT staat, land, produktline, SUM(Summe) AS Summe FROM fact f, location l, product p WHERE f.lid = l.lid AND f.pid = p.pid GROUP BY GROUPING SETS ( (staat, land), (produktlinie) ) liefert das folgende Ergebnis: Staat Land Produktline Summe Canada Ontario ,64 USA Califorinien ,41 USA New York , Kleidung 53912, Elektronik 77944, Medikamente ,81

13 4. ROLAP, MOLAP, HOLAP Bedeutung und Unterschiede Wie in der Beispielarchitektur gesehen (vgl. 1.4) werden OLAP-Server als Zwischenstufe zwischen den OLAP-Tools und den Data-Warehouse-Servern eingesetzt. Die Bemühungen, OLAP-Server zu optimieren, zielen daher darauf ab, entweder den Zugriff der OLAP-Tools auf den OLAP-Server zu optimieren oder den Zugriff des OLAP-Servers auf den Data-Warehouse- Server zu optimieren. Anhand dieser Optimierungsbemühungen lassen sich OLAP-Server in drei Klassen aufteilen. 4.1 ROLAP Relationale OLAP-Server Relationale OLAP-Server optimieren die Anfragen an das Data-Warehouse-System. Sie empfangen die multidimensionalen Anfragen der OLAP-Clients und setzen diese um in relationale Anfragen. ROLAP-Server entscheiden auch, welche Sichten materialisiert werden (vgl. [Fries03]). Multidimensionale Anfragen an den ROLAP-Server werden umformuliert, um auch die materialisierten Sichten verwenden zu können. Ausserdem übernehmen ROLAP-Server Verwaltungsaufgaben, indem sie ein Scheduling von Anfragen an das Data-Warehouse durchführen und die Ressourcen, die für die Zugriffe benötigt werden, verwalten. 4.2 MOLAP Multidimensionale OLAP-Server MOLAP-Server unterstützen die multidimensionale Sicht der OLAP-Clients auf die Daten. MOLAP-Server können dadurch eine sehr effiziente Indizierung der Daten aufbauen, die einen schnellen Zugriff gewährleistet. Ihr Nachteil ist allerdings, sie aufgrund der Dünnbesetztheit der Daten im multidimensionalen Modell eine schlechte Speicherausnutzung haben. 4.3 HOLAP hybride OLAP-Server Hybride OLAP-Server kombinieren die Vorteile von ROLAP- und MOLAP-Servern, indem sie Detaildaten, die meist in großer Zahl vorliegen, in relationalen Datenbanken ablegen während aggregierte Daten z.b. aus materialisierten Sichten in multidimensionalen Datenbanksystemen abgelegt werden. Der Hauptnachteil der HOLAP-Server ist, dass sie sehr komplex sind und dadurch lange Implementierungszeiten und kosten verursachen.

14 Literatur [BaGü00] A.Bauer, H.Günzel: Data Warehouse Systeme, dpunkt-verlag 2000 [Chaud] Chaudhuri, Surajit: An Overview of Data Warehousing and OLAP Technology [Clau98] Clausen, Nils: OLAP Multidimensionale Datenbanken, Addison-Wesley, 1998 [Codd93] Codd, E: Beyond Decision Support. In: Computerworld 27, 1993, S [Colo02] [Fries03] [Nkou03] Colossi, Malloy, Reinwald: Relational extensions for OLAP, IBM Systems Journal Vol. 41, 2002, S. 714ff, Fries, J. C.: Sichtenmaterialisierung Anwendungen und Probleme. Seminar: Data Warehousing im Verkehrsbereich, Universität Karlsruhe, Juni DWVSS03_-_Sichtenmaterialisierung_-_Anwendungen_und_Probleme_- _Ausarbeitung.pdf Nkouatchet, H.: Physische Modellierung und Optimierung eines Data Warehouse. Seminar: Data Warehousing im Verkehrsbereich, Universität Karlsruhe, Juni DWVSS03_-_Physische_Modellierung_-_Ausarbeitung.pdf [OLAP03a] [OLAP03b]