Seminarausarbeitung Data Warehousing

Transkript

1 Seminarausarbeitung Data Warehousing vorgelegt von Insa Stührenberg Carl von Ossietzky Universität Oldenburg 7. März 2003

2 Zusammenfassung Die Datenmengen in den Betrieben wachsen stetig. Neben den operativen Datenbanksystemen, die dem operativen Tagesgeschäft dienen, haben sich Data Warehouses als Speicherkomponente etabliert. Ein Data Warehouse stellt eine integrierte und bereinigte Datenbank dar, die eine zeitliche Sicht auf die Daten ermöglicht. Um eine Datenhistorisierung zu gewährleisten, dürfen veränderte Datensätze nicht einfach überschrieben werden. Ein Data Warehouse stellt nur einen Bestandteil eines Data Warehouse Systems dar. Als Data Warehousing wird der gesamte Prozess der Datenbeschaffung, Integration und Analyse bezeichnet. Die wichtigsten Anwendungen sind die interaktive Datenanalyse OLAP sowie Data Mining. Konzeptionell liegt einem Data Warehouse das multidimensionale Datenmodell zugrunde. Dieses Modell verwendet die Datenunterteilung in Fakten und Dimensionen, die in ihrer Kombination einen Würfel bilden. Dimensionshierarchien schaffen einen Verdichtungsgrad, der für die Analyse angemessen ist. Für die Berücksichtigung temporaler Gesichtpunkte werden in einem Data Warehouse Zeitstempel verwendet. Diese können entweder auf Attribut- oder Tupelebene eingeführt werden. Für die Umsetzung des multidimensionalen Datenmodells existieren mehrere Möglichkeiten. Neben der direkten multidimensionalen Abbildung (MOLAP), ist auch eine relationale Umsetzung (ROLAP) der multidimensionalen Konstrukte realisierbar. Wenn Detaildaten in Relationen gespeichert werden und gewisse Verdichtungen multidimensional gehalten werden, wird das hybride OLAP (HOLAP) verwendet.

3 Inhaltsverzeichnis 1 Einführung Vorgehensweise Data Warehouse Definition Stärken und Schwächen eines Data Warehouse Abgrenzung zu OLTP Einsatzgebiete Referenzarchitektur Anforderungen an ein Data Warehousing Die Komponenten eines Data Warehouse Systems Beschreibung einer Referenzarchitektur und Phasen eines Data Warehousing Das multidimensionale Datenmodell Das multidimensionale Datenmodell Vorstellung verschiedener Designnotationen ME/R-Modell Multidimensional Unified Modeling Language (muml) Struktur des multidimensionalen Datenmodells Operatoren des multidimensionalen Modells Versionierung von Dimensionstabellen Umsetzung des multidimensionalen Datenmodells Umsetzungsmöglichkeiten Relationale Speicherung Snowflake-Schema Star-Schema Weitere Schemaformen Temporale Erweiterung des relationalen Datenmodells Fazit Beurteilung und Ausblick

4 Kapitel 1 Einführung Data Warehouses haben aufgrund des enormen Anstiegs des Datenvolumens in den Betrieben an Bedeutung gewonnen. Die Daten stammen aus Quellen vom Point-of-sale bis zum Back-Office-System, aber auch verstärkt aus E-Business-Anwendungen. Der Wunsch wächst, in grossen Datenbeständen die Übersicht zu behalten. Ferner sollen mit möglichst geringem Aufwand interessante Zusammenhänge erkennbar werden. Mit steigendem Interesse wird die Möglichkeit der Analyse und Auswertung von akkumulierten Daten genutzt, um die strategische Unternehmensplanung zu optimieren. Da der Datenbestand oft in unterschiedlichen Formaten und verteilt vorliegt, erweist sich ein zentraler Datenzugang als weniger geeignet. Theoretisch ist es realisierbar, die internen Daten je nach Bedarf unmittelbar aus den Dateien oder Datenbanken zu holen. Die hohe Zugriffszeit und die enorme Aufbereitungszeit der Daten lassen diese Methode allerdings fraglich erscheinen. Effektiver ist es, die gefragten Daten aus den Datenbanken der operativen Anwendungssysteme zu selektieren und zu aggregieren, um sie dann in einer eigenen Datenbank (einem Data Warehouse) zu verwalten und durch OLAP ( On Line Analytical Processing)-Techniken auszuwerten. Die Aufgabenstellung dieser Arbeit lässt sich demnach an zwei Kernfragen verdeutlichen: 1. Wie werden einfliessende Daten verschiedener heterogener Quellen integriert? 2. Welches Datenmodell liegt einem Data Warehouse konzeptionell zu Grunde und wie erfolgt dessen Umsetzung? Daraus ergibt sich als Zielsetzung dieser Arbeit, die Möglichkeiten eines Data Warehousing herauszustellen. 1.1 Vorgehensweise Im 2. Kapitel erfolgt eine allgemeine Erläuterung eines Data Warehousing, wodurch ein erster Überblick über dieses Konzept gegeben wird. Es wird deutlich, dass Unternehmen durch den Einsatz eines Data Warehouse grosse Produktivitätsverbesserungen und Wettbewerbsvorteile gegenüber Konkurrenten erzielen können. Das nächste Kapitel stellt die Anforderungen und Phasen eines Data Warehousing vor. Zusätzlich wird die Referenzarchitektur eines Data Warehouse Systems mit den einzelnen Komponenten erläutert. Ferner wird herausgestellt, dass ein Data Warehouse nicht zwingend zentral vorliegen muss. Inhalt des 4. Kapitels ist die Vorstellung des multidimensionalen Datenmodells. Dieses eignet sich auf konzeptioneller Ebene am besten für die Modellierung eines Data Warehouse. Es bietet dem Anwender eine Denkweise in Dimensionen und Fakten(vgl. Abschnitt 4.3). Im 5. Kapitel werden Realisierungskonzepte für die Umsetzung des multidimensionalen Datenmodells vorgestellt. Eine Möglichkeit ist die direkte multidimensionale Datenspeicherung multidimensionaler Konstrukte. Die Abbildung des Datenmodells auf das relationale Datenbanksystem stellt eine Alternative hierzu da. Im letzten Kapitel werden die erarbeiteten Erkenntnisse dieser Arbeit zusammengefasst und beurteilt. Zusätzlich wird der Bezug zu unserer Projektgruppe Personalisierung internetbasierter Handelsszenarien hergestellt.

5 Kapitel 2 Data Warehouse In diesem Kapitel wird das Konzept eines Data Warehousing vorgestellt. Nach einer umfassenden Erläuterung des Begriffes Data Warehouse erfolgt eine Gegenüberstellung der Vor- und Nachteile eines Data Warehouse. Im Anschluss werden die OLAP-Anwendungen von den OLTP (On Line Transactional Processing)-Anwendungen abgegrenzt und die Einsatzgebiete eines Data Warehouse benannt. 2.1 Definition In der Literatur gibt es zahlreiche Definitionen für den Begriff Data Warehouse, wodurch die Schwierigkeit einer allgemein zutreffenden Erklärung verdeutlicht wird. A datawarehouse is a copy of transaction data specifically structures for querying and reporting [KRR+98]. Diese Definition von Kimball betrachtet lediglich die verschiedenen Aufgaben eines Data Warehouse. Es vernachlässigt somit die existenz gespeicherter Daten im Data Warehouse, die nicht für die Abfrage o.ä. gedacht sind. Die etablierteste Definition ist die von Inmon: A Data Warehouse is a subject-oriented, integrated, time-variant and nonvolatile collection of data in support of managements decision and making process (vgl.[m00]). ˆ Fachorientierung (subject- oriented): Ein Data Warehouse ist fach- bzw. subjektorientiert, indem es verschiedene Sachverhalte eines Unternehmens ( subjects wie Kunde, Verkäufe) betrachtet. Der Auswertungsaspekt steht beim Data Warehouse deutlich im Mittelpunkt. Innerbetriebliche Abläufe und Funktionen sind hingegen von untergeordnetem Interesse. Das Schema ist also analyseorientiert. ˆ Integration (integrated): Im Vergleich zu operativen Systemen werden in einem Data Warehouse Daten aus verschiedenen Quellen verarbeitet. Sie werden in einer einzigen, allgemeingültigen Form gespeichert. ˆ Nicht- flüchtige Daten (non- volatile): Auf den Datenbestand eines Data Warehouse sind keine Änderungen erlaubt, sondern nur lesende Zugriffe. Daten werden in periodischen Abständen hinzugeladen, aber nicht modifiziert. Sie werden also nach einmaliger Eingabe nicht mehr geändert. Daher besitzt ein Data Warehouse eine persistente und stabile Datenbasis [M00]. ˆ Historisierte Daten (time-variant): Ein Data Warehouse speichert im Vergleich zu den operativen Systemen auch historisierte Daten. Es bietet durch diese Historisierung der Daten einen Vergleich der Daten und Analysen über einen längeren Zeitraum. Der allgemeine Zeithorizont eines Data Warehouse beträgt etwa 5-10 Jahre (der der operativen Systeme hingegen nur Tage). Ein Data Warehouse stellt somit eine physische Datenbank dar, die eine zeitabhängige Sicht auf beliebige integrierte und bereinigte Daten ermöglicht.

6 Es stellt aber nur ein Bestandteil eines Data Warehouse Systems dar (vgl. Abschnitt 3.3). Die einzelnen Komponenten dieses Systems dienen hierbei sowohl der Integration (Bsp. Datenbeschaffung) als auch der Analyse der Daten. Data Warehousing umschreibt den gesamten dynamischen Prozess. Es umfasst alle Schritte der Datenbeschaffung, der Speicherung und der Analyse. Somit beinhaltet es die Integration, Transformation, Konsolidierung, Bereinigung und Speicherung der Daten sowie die Datenbereiststellung für analytische Zwecke und Interpretationen [SAP02]. Ein Data-Warehouse-System ist also mehr als die Summe seiner Komponenten [BG01]. Erst der Prozess an sich erreicht die Ziele des Systems. Um die Potentiale eines Data Warehouse auszuschöpfen, wird ein Modellierungsansatz für die Analyse benötigt. Oft wird das multidimensionale Datenmodell verwendet. Dieses stellt Strukturen und Auswertungskomponenten bereit, die bereits bei der Modellierung eine Analyse ermöglichen (vgl. Kapitel 4). Als wichtigste Anwendungen gelten die interaktive Datenanalyse OLAP sowie das Data Mining, die Suche nach unbekannten Mustern oder Beziehungen in Daten für die Erlangung neuer Informationen. 2.2 Stärken und Schwächen eines Data Warehouse Ein Vorteil eines Data Warehouse ist die verbesserte Datenqualität. Die Daten sind genauer und liegen durch einfache Transformation und Bereinigung in einem konsistenten Zustand vor. Ein Data Warehouse kann die Abfrageperformance beschleunigen, wodurch eine schnellere Informationsbeschaffung ermöglicht wird. Die Historisierung der Daten lässt ferner historische Trends erkennen. Die Leistung, die die Verarbeitung operativer Daten ermöglicht, wird durch den Einsatz eines Data Warehouse zusätzlich besser nutzbar. Nicht zuletzt unterstützt ein Data Warehouse Restrukturierungsmassnahmen und erhöht wegen der geringen Komplexität der Systemarchitektur die Flexibilität. Aus allgemeiner Unternehmenssicht ermöglicht der Einsatz eines Data Warehouse dem Unternehmen eine Verbesserung der Kundenbeziehungen. Durch die Erstellung von Kauf- und Kundenprofilen kann der Anbieter individuell auf die Kundenpräferenzen eingehen (z.b. mit Sonderangeboten). Ein Data Warehouse steigert ferner die Effizienz eines Unternehmens und hilft, Implementierungs- und Wartungskosten eines Data Warehouse zu kontrollieren. Die Potentiale sind allerdings nur erreichbar, wenn ein Data Warehouse professionell eingesetzt wird. Die Verständigung zwischen Anwender,IT-Abteilung sowie Projektmanagement muss dafür vorbildlich und ausgereift sein (vgl. [I99]). Ferner können Probleme beim Datenmanagement auftreten. Eine effiziente und wartbare Aktualisierung eines Data Warehouse mit neuen Daten ist nicht immer einfach. Da die Datenbeschaffung auf einzelne Komponenten verteilt ist, müssen bei einer Änderung dieses Prozesses alle betroffenen Elemente angepasst sowie ihre technische Zusammenarbeit neu getestet werden. Der Einsatz von Extraktions-Transformation-Lade-Werkzeugen hat dieses Problem gemindert (vgl. [HA02]). Eine weitere Schwäche eines Data Warehouse sind die enormen Kosten hinsichtlich Hard-, Software und Personal vor allem in der Anfangsphase eines Data Warehouse. Ebenso muss das Management von dem Einsatz eines Data Warehouse überzeugt werden. Nicht zuletzt ist bei dem Einsatz eines Data Warehouse zu beachten, dass ein Trainingsbedarf für den Endbenutzer hinsichtlich des Datenzugriffes entsteht. 2.3 Abgrenzung zu OLTP Um die Möglichkeiten eines Data Warehouse zu verstehen, ist es zunächst nötig, OLTP-Anwendungen von OLAP-Anwendungen abzugrenzen. OLTP-Anwendungen haben für eine auszuführende Transaktion nur begrenzte Datenmengen zu verarbeiten. Sie operieren immer auf dem aktuellsten Datenbestand. Dadurch eignen sie sich für das operative Tagesgeschäft (Bsp. Flugreservierungssystem). Dabei können die Daten nicht nur gelesen, sondern auch modifiziert werden. Das Schema ist eindeutig anwendungsorientiert. Der Fokus liegt bei diesen Anwendungen auf der Dateneingabe. Die ausschliesslich lesenden OLAP-Anwendungen verarbeiten hingegen grosse Datenmengen und arbeiten vor allem mit historisierten Daten. Daher dienen diese der strategischen Unternehmensplanung

7 Merkmal OLTP OLAP Orientierung Transaktion Analyse Nutzer Angestellter, DBA etc. Manager, Analysten etc. Datenbankdesign ER basiert Star/Snowflake Fokus Dateneingabe Informationsausgabe Operationen Index/hash auf Primärschlüsssel Scan Priorität Performance, Verfügbarkeit Flexibilität Summierbarkeit hoch detailliert summiert, konsolidiert Zugang schreibend/lesend lesend Arbeitseinheit kurze, einfache Transaktion komplexe Anfragen Tabelle 2.1: OLTP versus OLAP (Bsp. zur Beantwortung der Fragestellung: Wie hat sich die Auslastung der Transatlantikflüge über die letzten zwei Jahre entwickelt?). Der Schwerpunkt liegt hier auf der Informationslieferung. Da OLAP- Anfragen komplex sind, beeinträchtigen sie bei paralleler Auswertung mit den einfachen, transaktionalen Anwendungen letztere in ihrer Leistung. Diese Unvereinbarkeit hat zur Entwicklung von Data Warehouse-Systemen geführt [KE97]. Die wichtigsten Unterschiede sind zusammengefasst in Abbildung 2.1 (vgl.[acp+99]) dargestellt. Deutlich wird, dass die Unterschiede zwischen OLAP und OLTP zu einem anderen Benutzerkreis und unterschiedlichen Prioritäten führen. Kimball betont als wichtigsten Unterschied, dass ein Data Warehouse im Gegensatz zu den operativen Systemen die Vergangenheit beschreiben kann [K96]. 2.4 Einsatzgebiete Der Grundgedanke eines Data Warehouse ist die Datenanalyse. Sobald Daten gespeichert werden, entsteht meistens ebenso das Interesse, diese auch auszuwerten zu können. Daher sind die Anwendungsgebiete eines Data Warehouse breit gefächert. Sie reichen von der Betriebswirtschaftslehre über technische Anwendungen bis hin zu den Wissenschaften. Am häufigsten werden Data Warehouse-Systeme jedoch in der Betriebswirtschaft (v.a. Marketing, Controlling) eingesetzt. Bei informationsorientierten Anwendungen fördern sie insbesondere im Berichtswesen die Kennzahlenerstellung. Ein wichtiges Einsatzgebiet liegt im E-Commerce. Ein Data Warehouse sammelt und archiviert hierbei die Daten über das Kundenverhalten im Internet. Es unterstützt durch die dynamische analytische Informationsauswertung die E-Commerce-Lösungen der einzelnen Abteilungen. Dadurch ermöglicht es die Personalisierung dieser Anwendungen. Da das Beschaffungsverhalten analysierbar wird, werden diese Systeme auch bei der Onlinebeschaffung über Marktplätze oder E-Procurement-Lösungen genutzt. Ebenso ermöglichen sie einen Austausch unterschiedlicher Planungsinformationen, wodurch sie auch bei der Erstellung von Supply-Chains eingesetzt werden. In analyseorientierten Anwendungen werden Data Warehouses vor allem in der Kosten- und Leistungsrechnung eingesetzt. Für die Planungsunterstützung eines Unternehmens müssen Data Warehouses neben Ist- auch Plandaten speichern. Dadurch wird ein Plan/Ist-Vergleich möglich, um die Wirtschaftlichkeit eines Unternehmens beurteilen zu können. In kampagnenorientierten Anwendungen liefern Data Warehouses die Daten, um eine Kampagne zu starten. Am Ende dieser ermöglichen sie es zusätzlich, dessen Erfolg zu beurteilen (Bsp. Customer-relationsship-Management-System zur Betrachtung der Kundenbeziehungen auf unterschiedlichen Ebenen) [BG01, TH01].

8 Kapitel 3 Referenzarchitektur Dieses Kapitel stellt eine Referenzarchitektur eines Data Warehouse Systems vor. Diese besteht aus verschiedenen Komponenten. Ein Data Warehouse stellt somit nur ein Bestandteil des Systems dar. Der Datenbestand eines Data Warehouse kann dabei auch verteilt vorliegen. Nachdem zuerst auf die Anforderungen an ein Data Warehousing eingegangen wird, werden anschliessend die einzelnen Systemkomponenten erläutert. Hierbei werden die jeweiligen Aufgaben, die Funktionsweise sowie der Zusammenhang dieser Komponente im System beschrieben. Abschliessend erfolgt eine allgemeine Beschreibung einer Referenzarchitektur sowie der Phasen eines Data Warehousing. 3.1 Anforderungen an ein Data Warehousing In diesem Abschnitt werden die Anforderungen an ein Data Warehousing vorgestellt. Wichtig ist eine Unabhängigkeit zwischen Datenquellen und Analysesysteme hinsichtlich Verfügbarkeit (d.h. bei Systemausfällen), Belastung sowie Änderungen in den Quellsystemen. Ferner soll es integrierte und abgeleitete Daten dauerhaft bereitstellen. Diese Daten müssen persistent gespeichert und mehrfach verwendbar sein. Es muss flexibel mit ihnen gearbeitet werden können. Ausserdem fordern Data Warehouses Skalierbarkeit. Erweiterungen sollen möglich sein, die bereits existierende Strukturen nicht verändern und neue Quellen integrieren. Die Prozesse (vgl.abschnitt 3.3) müssen möglichst automatisch ablaufen. Ferner muss Eindeutigkeit hinsichtlich Datenstrukturen, Zugriffsrechten und Prozessen herrschen. Nicht zuletzt ist eine Anforderung an ein Data Warehousing die Möglichkeit individueller Nutzersichten (also anwenderspezifische Datenbestände). Die Architektur sollte sich am Ziel dieser ausrichten, d.h. also an der Datenanalyse. Damit die enthaltenen Daten entscheidungsrelevant sind, müssen diese bei der Übernahme aggregiert und verdichtet werden. So interessiert sich ein Manager nicht für die einzelnen Bestellpositionen, sondern eher für die Quartals- und Jahressummen. 3.2 Die Komponenten eines Data Warehouse Systems Die einzelnen Bestandteile eines Data Warehouse Systems werden im folgenden vorgestellt und in Abbildung 3.3 in ihrer Gesamtheit grafisch dargestellt [BG01]. Der Data-Warehouse-Manager initiiert, lenkt und überwacht die einzelnen Prozesse in allen Phasen. Er muss die Prozesse automatisch ablaufen lassen, indem er die Vorgänge durch Kontrollflüsse steuert. Der Datenbeschaffungsprozess kann dabei regelmässig erfolgen, abhängig von Datenänderungen oder aufgrund ausdrücklichen Verlangens [BG01]. Die Datenquelle (Bsp. interne oder externe Datenbank, flat files, www-seiten) beeinflusst durch die Art der Datenspeicherung die Analysefähigkeit eines Data Warehouse-Systems. Sie stellt einen Bestand von Daten mit Inhalten für die Datenanalyse dar. Hinsichtlich Struktur, Inhalt und Schnittstellen ist sie von heterogener Art. Als Quelldaten werden dabei die Daten in Verbindung mit deren

9 Beschreibungen bezeichnet. Diese können nach verschiedenen Merkmalen klassifiziert werden (Bsp. Herkunft: intern und extern, Zeit: aktuell und historisch). Diese Einteilung ermöglicht eine Strukturierung und verbesserte Übersichtlichkeit der Datenquellen. Bei der Betrachtung der Quelle und deren Auswahl muss sowohl der Verwendungszweck eines Data Warehouse und die Quelldatenqualität (Bsp. Konsistenz, Korrektheit) als auch die Verfügbarkeit (organisatorisch und technisch) und der Preis für den Datenerwerb beachtet werden [BG01]. Monitore sollen Datenmanipulationen in den Quellsystemen aufdecken. Allgemein ist Monitoring die Voraussetzung für die Anpassung eines Data Warehouse an die aktuelle Nutzung. Es gibt meist einen Monitor pro Datenquelle, da seine Funktionsweise von den dessen Merkmalen und den Anforderungen der Analysekomponenten abhängt. Es gibt verschiedene Monitoring-Strategien. Eine Variante aktiviert bei Änderungen einen Trigger, der die Änderungen beispielsweise in eine Datei schreibt. Die Methode der Replikation schreibt einen geänderten Datensatz in eine spezielle Tabelle. Eine weitere Strategie arbeitet mit Zeitstempeln. So wird jedem Datensatz ein Zeitstempel zugewiesen, der den Zeitpunkt der Änderung enthält. Bei der Log-basierten Methode werden Änderungen in eine Log-Datei geschrieben. Eine weitere Alternative basiert auf Snapshot- Dateien. Hierbei wird in regelmässigen Abständen der Datenbestand in eine Schnappschussdatei geschrieben. Für die Entdeckung von Änderungen wird dann der aktuelle Datenbestand mit einem Schnappschuss der alten Daten verglichen. Der Arbeitsbereich enthält die Daten des Datenbeschaffungsbereichs (engl. staging area). Der Datenbeschaffungsbereich wiederum enthält alle Komponenten, die funktional zwischen den Datenquellen und der Basisdatenbank liegen. Damit integriert er heterogene Daten. Im Arbeitsbereich werden die Daten temporär zwischengespeichert sowie bereinigt und integriert. Dadurch behindern die Datentransformationen die anderen Komponenten des Systems nicht. Ferner werden die transformierten Daten erst nach erfolgreichem Abschluss der Transformation in ein Data Warehouse geladen. Die Extraktionskomponente dient der Datenübertragung aus einer Datenquelle in den Arbeitsbereich. Sie stellt daher die Verbindung zu den operativen/externen Datenquellen dar. Ferner unterstützt sie die Auswahl der Quellen, die importiert werden sollen (unabhängig von ihrer Speicherform). Daten werden entweder periodisch, auf Anfrage, aufgrund von Ereignissen oder sofort nach Änderungen extrahiert. Die Extraktion wird normalerweise durch Schnittstellen zwischen Netzwerken und Standarddatenbankschnittstellen (Bsp. ODBC) technisch umgesetzt. Das Ermitteln von Datenänderungen erfolgt in Abhängigkeit der gewählten Monitoring- Strategie [M00]. Die Transformationskomponente: Die relevanten operativen Daten des Arbeitsbereiches unterscheiden sich strukturell (Bsp. Schemaintegration) und inhaltlich (Bsp. Datenbereinigung). Daher ist es notwendig, sie in einen geeigneten Zustand zu bringen. Heterogene Daten brauchen zunächst ein einheitliches Format für ihre Vergleichbarkeit (durch z.b. Teilung/ Kombination von Attributen, Vereinheitlichung von Datumsangaben). Data Migration bezeichnet hierbei die Standardisierungstransformationen, die eine Integration heterogener Daten bewirkt. Data Scrubbing stellt den Prozess der Verbesserung der Datenqualität mit Hilfe von Software-tools dar. Die Datensemantik wird hierbei mit Hilfe von domänenspezifischen Wissen kontrolliert (Bsp. Postleitzahlenverzeichnisse). Data Auditing hat die Entdeckung von Beziehungen und Regelmässigkeiten in den Daten zur Aufgabe [M00]. Ziel ist es also, die verschiedenen Schemata der einzelnen Datenquellen in das Schema zu transformieren, das dem allgemeinen Datenmodell folgt [B01]. Die Ladekomponente: Die transformierten Daten des Arbeitsbereiches sind speicherungs- und auswertfähig. Für die Weiterleitung ist eine Komponente notwendig, um die analyseunabhängigen Detaildaten in die Basisdatenbank zu übertragen. Eine andere muss die analysespezifischen Daten aus der Basisdatenbank in ein Data Warehouse transferieren. Wenn ein gespeicherter Datensatz geändert werden muss, darf dieser aufgrund der Forderung nach Datenhistorisierung nicht überschrieben werden. Der geänderte Datensatz muss stattdessen gespeichert werden. Zu unterscheiden sind Onlineund Offline-Ladevorgänge. Während beim ersteren auch während des Ladens ein Data Warehouse verfügbar ist, ist dies beim letzteren nicht der Fall. Beim Offline-Ladevorgang sind somit während

10 des Ladens Anfragen an ein Data Warehouse nicht erlaubt. Ein Ladevorgang sollte ferner in einem günstigen Zeitraum stattfinden (Bsp. nachts, Wochenende). Eine grosse Datenmenge zwingt hierbei zu effizienteren Manahmen (Bsp. durch Parallelisierung). Die anwendunsgneutrale Basisdatenbank stellt eine integrierte Datenbasis dar. Ihre Aufgabe ist die Sammlung, Integration und Verteilung der Daten. Dies ermöglicht eine Mehrfachverwendung und flexible Datenverwendung. Sie enthält aktuelle sowie historisierte Daten, die bereits bereinigt sind. Ausserdem stellt die Basisdatenbank die Analysebasis dar. Sie hat also ebenso eine Auswertungsfunktion. Die Basisdatenbank wird entweder in Echtzeit aktualisiert, in periodischen Abständen oder in Abhängigkeit einer Änderungsquantität (d.h., wenn eine bestimmte Änderungszahl erreicht wird). Es muss erkennbar sein, um welche Daten es sich handelt und v.a. wie sie im Laufe ihres Weges transformiert worden sind. Zusätzlich muss ein Datenzugriff technisch möglich sein. Es werden also verfügbare und nachvollziehbare Daten gefordert. Da der Einsatz einer Basisdatenbank sowohl mit hohem Aufwand als auch enormen Kosten verbunden ist, wird in der Praxis oft auf diese Komponente verzichtet. Grafisch wird die Anordnung der Basisdatenbank als Nabel-Speiche-Architektur dargestellt. Dabei sind die Datenquellen und das Data Warehouse die Speichen und die Basisdatenbank die Nabe. Dies bewirkt eine Reduktion der Schnittstellen, da der Transport der Daten nur indirekt erfolgt [BG01]. Data Warehouse: Indem ein Data Warehouse mit dem Repositorium und der Basisdatenbank verbunden ist, enthält es alle analyserelevanten Daten. Es muss die vom Anwender benutzten und geforderten Daten dauerhaft verwalten und bei Analysen bereitstellen. Somit passt sich die Strukturierung an den Analysebedarf an. Da die Struktur eines Data Warehouse die Struktur des OLAP-Speichers beeinflusst, nimmt sie auch Einfluss auf die Anfrageperformance. Dem Analyseprogramm werden die relevanten Daten bei Bedarf gegeben. Ein Data Warehouse bietet neben diesen Zugriffsfunktionen auch Funktionen der Verarbeitung. Durch diese Schnittstelle kann eine Anwendung formulieren, was gebraucht wird. Tuningparameter und Mechanismen bieten eine effiziente Anfrageverarbeitung (Bsp. Zugriffsstrukturen). Indem die Daten aus der Basisdatenbank geladen werden, werden sie aktualisiert. Da viele Datensätze pro Zeiteinheit in ein Data Warehouse gelangen, besitzen viele Datenbanksysteme zudem einen Massenlader (engl.bulk loader). Indem einige Funktionen für die Ladezeit abgeschaltet sind (Bsp. Mehrbenutzerkoordination), kann die Ladeperformance erhöht werden. Verteilung eines Data Warehouse/Data Marts: Ein Data Warehouse, das hauptsächlich detaillierte Firmendaten enthält, muss nicht zwingend zentral vorliegen. In der Praxis wird eine Verteilung der Verarbeitungs- und Administrationslast bevorzugt. Dadurch wird ein zentrales Data Warehouse ausgeschlossen. Dieses bietet zwar einerseits Datenintegrität und einen single point of truth, aber andererseits bedeutet es aber auch eine starke Netzwerkbelastung und mangelnde Flexibilität hinsichtlich Skalierbarkeit. Das sogenannte Data Mart-Konzept liefert stattdessen eine inhaltlich beschränkte Sicht auf ein Data Warehouse. Es bildet Extrakte der Data Warehouse-Daten, die für bestimmte Benutzer mit einem homogenen Informationsbedürfnis ausgerichtet sind. Aus Datenbanksicht entspricht es der Verteilung eines Data-Warehouse-Datenbestandes. Vorteilhaft ist hierbei, dass meist aggregierte und nicht mehr so stark normierte Daten vorliegen. Dadurch ist die Performance der Abfragen höher als bei einem Data Warehouse selbst. Oft wird dieses Konzept auch wegen der Benötigung von Zugriffrechten für den Nutzer eingesetzt. Es ermöglicht ferner die Abbildung der Unternehmensstruktur mit den Verantwortlichkeiten, indem z.b. jede Abteilung ein Data Mart bekommt. Dadurch ist eine Unabhängigkeit der Abteilungen erreichbar. Data Marts können auch den Beginn eines zentralen Data-Warehouse-Entwurfs darstellen. So errichtet jede Abteilung ihr eigenes Data Mart. Diese werden dann unternehmensweit zusammengefügt, wodurch sie dann ein zentrales Data Warehouse bilden. Dieses Verfahren ist zeitsparender und kostengünstiger. Data Marts sind hier als eine Art Prototyp einzusetzen, die die Kontrolle der Anforderungen ermöglichen [B01]. Think big, start small : Dieses Vorgehen führt also nur zum Erfolg, wenn bereits zu Beginn des Entwurfs die spätere Zusammenführung der einzelnen Marts mit eingeplant wird. Sonst besteht die Gefahr von Insellösungen. Das Data Mart-Konzept ist ferner sinnvoll, wenn Spezialdaten vorliegen, die nur von bestimmten Benutzergruppen benötigt werden. Eine Speicherung dieser Daten in einem

11 zentralen Data Warehouse wäre hier nicht angebracht. Das übergeordnete Ziel dieses Konzeptes ist demnach die Komplexitätsreduktion sowie die Verringerung des Datenvolumens. Konkret gibt es zwei Ausprägungen: Abhängige Data Marts (vgl. Abbildung 3.2 [BG01]) sind Extrakte aus dem integrierten Datenbestand der Basisdatenbank. Ihnen liegt eine integrierte Datenbasis zugrunde. Dadurch sind Analysenergebnisse auf dessen Datenbestand aufgrund der fehlenden Normierung die gleichen wie die auf ein Data Warehouse. Die Extrakte können strukturell gebildet werden (Beschränkung auf Schemateile Bsp. bestimmte Dimension), inhaltlich (Bsp. letzte Jahresergebnis) oder aggregiert. Bei letzterem wird die Granularität verringert (Bsp. Beschränkung auf Monatsergebnisse. Neben dem geringerem Datenvolumen ermöglichen abhängige Data Marts schnellere Antwortzeiten und eine Zugriffslokalität der Daten. Abhängige Data Marts Analyse A Laden Data Warehouse Analyse B Analyse C Abbildung 3.1: Abhängige Data Marts Unabhängige Data Marts (vgl. Abbildung 3.3 [BG01]) sind isolierte Sichten auf die Quellsysteme. Sie stellen kleine Data Warehouses dar, die keine integrierte Datengrundlage besitzen. Daher können sie nur entstehen, wenn keine Basisdatenbank existiert. Eine nachträgliche Transformation und Integration in einen übergeordneten Analysekontext ist daher zwingend. Dadurch wird das Integrationsund Transformationsproblem nicht gelöst, sondern nur auf einen späteren Zeitpunkt verschoben. Verschiedene Analysesichten sowie die Konsistenz der Analysen werden aufgrund der zusätzlichen Transformation hierbei zum Problem. Data-Mart-übergreifende Analysen sind nicht realisierbar (Bsp. abteilungsübergreifend). Unabhängige Data Marts bieten zwar ein schnelles Vorgehen, eine Ausfallsicherheit und schnelle Ergebnisse, jedoch sind sie schwer änderbar und unflexibel. Datenintegrität und single point of truth sind hier nicht gegeben. Analyse A Analyse C Analyse D Analyse B Data Warehouse Data Marts Laden Transformation Laden Laden Laden Abbildung 3.2: Unabhängige Data Marts Es gibt auch Architekturen ohne Data Warehouse.Hier liegen stattdessen nur Data Marts vor, die

12 virtuell ein Data Warehouse bilden (vgl.[bg01]). Analyse bezeichnet alle Operationen, die mit den Daten eines Data Warehouse durchgeführt werden, um neue Informationen zu generieren (Bsp. Anfrage von Analysefunktionen auf ausgewählte Daten). Durch Analysewerkzeuge können die Anwender die gesammelten Daten mit interaktiven Navigationsund Analysemöglichkeiten präsentieren. Zu den Darstellungselementen gehören neben Tabellen (v.a. Pivottabellen) und Grafiken auch Text sowie multimediale Elemente (Bsp. Videosequenz). Die Werkzeuge sind meist auf die Anwender und Einsatzgebiete zugeschnitten. Zur Realisierung gibt es Standard Reporting Werkzeuge für die Berichtserstellung und -Verteilung sowie Berichtshefte (engl. briefing books), welche als Entwicklungsumgebungen z.b. Tabellen darstellen können. Ausserdem gibt es ad-hoc-queries & Reporting, die Berichte grafisch erstellen und Informationen in Form von Kennzahlen und Dimensionen liefern. Eine eigene Oberfläche für die mehrdimensionalen Datenanalyse und -anfrage bieten Analyse- Clients. Ferner gibt es Spreadsheet Add-ins, die Tabellenkalkulationen um Datenanbindung und Navigation erweitern. Für die Realisierung gibt es ebenso Entwicklungsumgebungen, die die Entwicklung eigener Analyseanwendungen fördern und Operationen auf multidimensionalen Daten liefern. Als eine mögliche Plattform gibt es Fat Clients mit eigenen Speicher- und Verarbeitungsmöglichkeiten. Diese Clients führen nahezu die gesamte Verarbeitung ohne Server aus. Eine andere Möglichkeit stellen Thin Clients dar, bei denen fast die gesamte Datenverarbeitung auf dem jeweiligen Server stattfindet. Sie dienen nur der Informationendarstellung. Ferner gibt es noch die aktive Verteilung über Offline- Medien. Hier wird lediglich bei Bedarf eine Verbindung zu einem Data Warehouse hergestellt. Das Repositorium (engl.repository) speichert die Metadaten eines Data Warehouse Systems. Metadaten sind Daten über den Daten. Diese dokumentierenden Daten werden nach ihrem fachlichem Nutzen (für den Endanwender) und den technischen Daten wie z.b. Indizes eingeteilt. Sie liefern z.b. physische Speicherinformationen sowie Informationen über Data-Warehouse-Prozesse, Zugriffsrechte und Schemata. Neben dieser Aufgabe der Informationslieferung dienen sie auch zur Steuerung des Data Warehouse Managers für die verschiedenen Prozesse. Der Metadatenmanager steuert die Metadatenverwaltung. Er stellt eine Datenbankanwendung dar, der das Versions- und Konfigurationsmanagement, das Integrations-, die Zugriffs-, die Anfrageund Navigationsmöglichkeiten der Metadaten anbietet. Ferner liefert er die Schnittstelle für Lese- und Schreibzugriffe auf das Repositorium. Dadurch können Metadaten zwischen den verschiedenen Komponenten erreicht und ausgetauscht werden (Bsp. API). Damit Werkzeuge integriert werden können und das Repositorium steuerbar wird, werden die Metadaten vereinheitlicht. Passende Werkzeuge sind dabei allgemein einsetzbare Metadatenverwaltungssysteme (mit einem einfach zu änderndem Kernschema) und werkzeugspezifischen Metadatenverwaltungskomponenten. Die Praxis zeigt, dass oft ein Austausch zwischen dezentralen Metadaten- Managementsystemen notwendig ist [BG01]. 3.3 Beschreibung einer Referenzarchitektur und Phasen eines Data Warehousing Um die relevanten Daten aus den operativen Systemen in einem Data Warehouse zu integrieren, muss dieses verschiedene Schritte durchlaufen (vgl. Abbildung 3.1 [BG01]). Zunächst werden die Änderungen in den Quellen durch Monitore kontrolliert. Mittels Extraktion werden dann die relevanten Daten aus den operativen Systemen in einen temporären Arbeitsbereich kopiert. Dort finden Datentransformationen (d.h. Integration und Bereinigung) statt. Anschliessend werden die Daten in eine Basisdatenbank kopiert, von wo aus sie dann in ein Data Warehouse geladen werden. Diese stellt die Schnittstelle zum Anwender dar und bildet sich durch den jeweiligen Analysezweck. Das Repositorium ist nur mit dem Metadatenmanager verbunden, welcher alle anfallenden Metadaten verwaltet und die restlichen Komponenten mit Metadaten versorgt. Da Unabhängigkeit und zeitliche Stabilität gefragt sind, wird somit auf einen Direktzugriff auf die

13 Extraktion Laden Laden Analyse Datenquellen Arbeitsbereich Basisdatenbank Data Warehouse Kontrollfluss Transformation Monitor Data Warehouse Manager Datenfluss Data Warehouse System Metadaten -Manager Repository Abbildung 3.3: Referenzarchitektur eines Data Warehouse Systems operativen Daten verzichtet. Stattdessen wird eine separate physische Ablage geschaffen. Die Analyse steht also der Integrationsanforderung gegenüber und lässt mehrere Datenbanken in einer Architektur zu. Die wichtigste Aufgabe eines Data Warehouse ist die laufende Aktualisierung der Daten. Hierbei gibt es zwei Strategien. Beim vollständigen Laden werden Teile der Daten im Data Warehouse gelöscht und neu geladen. Aus Performancegründen ist jedoch die inkrementelle Aktualisierung (engl. inkremental maintenance) effektiver. Hier werden lediglich die Änderungen der operativen Daten in das Data Warehouse eingebracht. Data Warehouses sind meist als Dreischichtenarchitektur realisiert. Auf unterster Ebene befindet sich ein Data Warehouse, das in Verbindung mit dem Repositorium die heterogenen Daten verschiedener Quellen integriert. Es stellt somit die Datenhaltungskomponente dar. Meist liegt ihm ein relationales Datenbanksystem zugrunde. Auf mittlere Ebene befindet sich für die Verarbeitung der OLAP-Server, der für die Analyse multidimensionaler Daten konzipiert worden ist. Er ist meistens als relationales oder multidimensionales OLAP implementiert (vgl. Abschnitt 5.2). Die oberste Schicht stellen Front- End Tools dar (Bsp. Analyse-, Anfrage- oder auch Berichtstools). Diese Tools stellen Benutzeranwendungen dar, die insbesondere die Anfragen an den OLAP-Server definieren und Analyseergebnisse angemessen präsentieren sollen (vgl. [HK01]).

14 Kapitel 4 Das multidimensionale Datenmodell Wie im traditionellen Datenbankentwurf werden bei der Erstellung eines Data Warehouses die Phasen der konzeptionellen, logischen und physischen Modellierung unterschieden. Dabei wird zuerst ein konzeptionelles Datenmodell erstellt, um Zusammenhänge ohne Beachtung von Implementierungsdetails zu modellieren. Dieses Kapitel stellt das multidimensionale Datenmodell vor. Nachdem zuerst zwei Designnotationen erläutert werden, erfolgt eine Beschreibung der Struktur des multdimensionalen Datenmodells. Anschliessend werden dynamische Operatoren vorgestellt, die auf diese Strukturen duchführbar sind. Im letzten Abschnitt dieses Kapitels wird im Rahmen der Versionierung von Dimensionstabellen das Konzept der slowly chanigng dimensions eingeführt. 4.1 Das multidimensionale Datenmodell Einem Data Warehouse liegt ein multidimensionales Datenmodell zugrunde. Für dessen Abbildung wird also eine konzeptionelle Modellierungstechnik benötigt, die die speziellen semantischen Konstrukte dieses Datenmodells berücksichtigt. Damit ist die Idee des multidimensionalen Modell gemeint, unabhängige Attribute (Dimensionen) logisch von den abhängigen Attributen (Fakten) zu trennen. Konventionelle Entwurfstechniken wie das ER-Modell (entity-relationsship-modell) oder die UML (unified modelling language) bieten aufgrund der wenigen verwendeten Konstrukte eine gewisse einfache Anwendbarkeit. Da sie aber keine Unterscheidung in Klassifikationsstufen, beschreibenden Attributen und Fakten bieten, eignen sie sich nicht. Sie werden der Semantik multidimensionaler Datenmodelle nicht gerecht. So wird aus dem ER-Modell nicht unbedingt ersichtlich, welche der Beziehungen Klassifikationsbeziehungen sind. Schliesslich muss nicht jede 1:n-Beziehung eine Klassifikation darstellen. Klassifikationsbeziehungen können auch als Attribute modelliert sein [BG01]. 4.2 Vorstellung verschiedener Designnotationen Im diesem Abschnitt werden verschiedene Designnotationen vorgestellt. Zunächst wird das multidimensional entity/relationsship-modell (ME/R-Modell) erläutert und anhand eines grafischen Beispiels verdeutlicht (Abbildung 4.1). Als weitere Designnotation wird in Abschnitt die multidimensional unified modelling language (muml) präsentiert und ebenso in einer Grafik veranschaulicht (Abbildung 4.2) ME/R-Modell Das ME/R-Modell ist von der Universität Erlangen für die Einführung der multidimensionalen Semantik entwickelt worden. Es ergänzt und spezialisiert das ER-Modell um drei Elemente (vgl. Beispiel Abbildung 4.1 [H01]). Da das klasssiche ER-Schemata genutzt werden kann, bietet es eine einfache Erweiterung bestehender Konzepte (vgl. [H01]).

15 ˆ Die Klassifikationsstufe ist eine besondere Ausprägung von Entities. Diejenige Stufe, die mit der Faktbeziehung verbunden ist, wird als Basisklassifikationsstufe oder Dimension bezeichnet. Sie wird grafisch in Form eines Rechteckes dargestellt ˆ Die Faktbeziehung dient der Aufnahme mehrerer Faktattribute und enthält somit die eigentlichen Analysedaten. Grafisch wird sie als Würfel repräsentiert ˆ Die Klassifikations-Beziehungsmenge verbindet (als Pfeil) Klassifikationsstufen verschiedener Abstraktionsebenen untereinander und mit der Faktbeziehung Produktfamilie Produktgruppe Artikel Bezirk Stadt Filiale Verkauf Quartal Monat Tag Verkäufe Umsatz Abbildung 4.1: ME/R Multidimensional Unified Modeling Language (muml) Die muml ist im Rahmen einer Diplomarbeit von der Universität Oldenburg entwickelt worden. Als erstes wurde sie in einem OFFIS- Projekt (OFFIS Tools for Data Warehousing) angewendet. Die muml ermöglicht als UML-Erweiterung die Erstellung eines konzeptionellen, multidimensionalen Schemas [H01]. Zu unterscheiden sind hier die eigentliche Sprache und die grafischen Konstrukte. Die multidimensionalen Sprachelemente und deren Semantik hat die muml von der Multidimensional Modeling Language (MML) erhalten, die ebenfalls im Rahmen der o.g. Diplomarbeit entwickelt worden ist (vgl. [AI01]). Diese objektorientierte Sprache liefert Konstrukte für abstrakte Klassen, Vererbung und Komposition. Damit ermöglicht sie eine flexible Implementierung, die technische Details nicht beachtet. Sie unterstützt die Anforderungen konzeptioneller, multidimensionaler Modelle (Bsp. Mehrfachhierarchien,Verdichtungspfade) und unterstützt die Schemaevolution. Die MML bietet ferner die konventionelle Unterscheidung zwischen Metamodell, Schema und Ausprägung. Ein Metamodell entspricht einem Modell eines Modells. Es stellt die Konstruktmenge bereit, die zur Modelldarstellung benutzt werden darf und somit den Metadaten zur Verfügung steht. Sie bildet daher das konzeptionelle Schema des Repositoriums. Das Schema wird durch diese Mittel des Metamodells gebildet und bezeichnet die physische Speicherform einer Datenbank. Die Ausprägungen sind die bestimmten Werte, die Instanzen, eines Modells. Während das Metamodell somit die Beschreibungsmittel liefert, stellt das Schema die Muster zur Verfügung. Grundlage für die muml sind die UML-eigenen Erweiterungsmöglichkeiten, die eine Anpassung ohne Veränderung des UML-Metamodells ermöglichen. Die muml verwendet für die Bereitstellung der multidimensionalen Elemente v.a. die Eigenschaftswerte (engl. tagged values) und die Stereotypen. Eigenschaftswerte umfassen ein Schlüsselwort (tag), das das Merkmal beschreibt, und einen dazugehörigen Datenwert. Sie sind benutzerdefinierte, sprach- und werkzeugspezifische Paare, die die Semantik einzelner Modellelemente um spezielle Eigenschaften erweitern. Stereotypen sind projekt-, unternehmens- oder methodenspezifische Erweiterungen vorhandener Modellelemente, die als neues Konstrukt Untermetaklassen einfügen. Grafisch dargestellt werden muml-diagramme durch das Klassendiagramm der UML. Es umfasst die statischen Merkmale von Klassen und Objekten (Bsp. Attributangaben, Beziehungen) sowie die genannten objektorientierten Konstrukte. Abbildung 4.2 (vgl. [AI01]) zeigt die Faktentabelle Verkauf sowie die Zeit- und Geographiedimension mit ihren Hierarchien. Die Faktentabelle enthält drei Fakten (Anzahl, Einzelverkaufspreis und Umsatz), wobei der letzte abgeleitet ist. Jede Klassifikationsstufe wird hier durch eine Klasse des Typs dimensional-class modelliert.

16 <<Fact- Class>> Verkauf Anzahl: Verkäufe EinzelVK: Preis /Umsatz : Preis {formula= Anzahl*EinzelVK, parameter= Anzahl, EinzelVK } Dimension Geographie <<Dimensional- Class>> Stadt <<Dimensional- Class>> Region <<Dimensional- Class>> Land Dimension Zeit <<Dimensional- Class>> Tag <<Dimensional- Class>> Monat Abbildung 4.2: muml 4.3 Struktur des multidimensionalen Datenmodells Beim multidimensionalen Datenmodell erfolgt eine Unterscheidung in qualifizierende und quantifizierende Daten. Letztere sind die eigentlichen zu analysierenden Daten, wohingegen die qualifizierenden diese näher beschreiben. ˆ Fakten: Fakten (Bsp. Verkaufszahl) sind Datenobjekte, die neben quantifizierbaren auch qualifizierbare Daten umfassen. Sie enthalten ein oder mehrere Faktattribute, die in der Betriebswirtschaft als Kennzahlen bezeichnet werden. Faktattribute sind meist numerische Daten (Bsp. konkreter Umsatz, Verkäufe). Wenn sich alle Fakten in einem Würfel befinden, wird von einem Single-Cube gesprochen. Andernfalls liegt ein Multi-Cube, welcher dem Galaxy-Schema entspricht (siehe Abschnitt 5.2.3). ˆ Dimensionen: Eine Dimension ist eine ausgewählte Entität (Bsp. Produkt), die für die eindeutige Strukturierung des Datenraums unerlässlich ist. Die Dimensionen stellen die beschreibenden Daten dar. Sie enthalten Attribute, die den Charakter der Dimension möglichst genau beschreiben (Bsp. Dimension Zeit: Jahr, Periode, Monat, Woche, Tag). Eine Dimension verdeutlicht damit einen Aspekt der Auswertungskontextes. Eine typische Anzahl von Dimensionen liegt im Versicherungsbereich bei 10-15, in der Industrie bei 8, im Controlling bei und beim Marketing bei 5-7 Dimensionen. ˆ Klassifikationsschema, Pfad: Das Klassifikationsschema einer Dimension ist eine halbgeordnete Menge von Klassifikationsstufen mit einem kleinsten Element. Es ist also das Schema zur Abstraktion von einer oder mehreren Klassifikationshierarchien, die einer Dimension zugeordnet wird. Eine vollgeordnete Teilmenge von Klassifikationsstufen eines Klassifikationsschemas wird als Pfad bezeichnet [BG01]. ˆ Klassifikationshierarchie: Damit Daten für die Analyse einem angemessenen Verdichtungsgrad entsprechen, werden Dimensionen hierarchisch organisiert. Eine Hierarchie ist ein analyseabhängiger Datenzusammenschluss. Eine Klassifikationshierarchie ist die vollständige Zerlegung einer nichtleeren Menge in disjunkte Teilmengen nach Auswertungssichten. Sie bildet mittels einer Baumstruktur eine Abstraktionshierarchie über die Dimensionselemente. Eine Klassifikationshierarchie bezüglich eines Pfades ist also ein balancierter Baum. Sie enthält als höchste Hierarchiestufe immer die Ebene ALL. Die Daten der niedrigsten Stufe (die Detaildaten) bestimmen die Datengranularität (Verdichtungsgrad) und daher die im Würfel zu speichernde

17 Datenmenge. Daten gleicher Granularität stellen ein Dimensionslevel dar. Dabei wird eine Unabhängigkeit der Klassifikationsstufen vorausgesetzt. Die Baumkanten genügen den funktionalen Abhängigkeiten: Attribut B ist dabei funktional abhängig von einem Attribut A(A B) wenn jedem Wert a dom(a) genau ein Wert b dom(b) zugeordnet ist. Ein Klassifikationsknoten ist die Verdichtungsstufe innerhalb einer Klassifikationshierarchie. Die Dimensioninstanz ist die Menge aller Klassifikationshierarchien auf Pfaden im Klassifikationsschema [BG01]. Bei entarteten Hierarchien (unbalancierte Baumstruktur) sind die Aggregationen unvollständig. Multiple Hierarchien stellen mehrere Hierarchien auf einer einzigen Dimension dar. Verzweigende Pfade innerhalb einer Hierarchie, die wieder zusammengeführt werden, werden als alternative Verdichtungspfade bezeichnet (vgl. [H01]). ˆ Würfel: Ein Würfel (data cube) besteht aus mehreren Datenzellen, welche eine oder mehrere Fakten auf Detailebene beinhalten. Eine Zelle ist daher Schnittpunkt der Dimensionen, die den Würfel aufspannen (Würfelachsen). Ein Würfel ist eine Ausprägung eines Würfelschemas. Dieses Schema besteht aus der Granularität und Faktmenge. Die Würfelinstanz ist eine Menge von Würfelzellen. Ein Würfel entsteht dann durch Instanziierungen eines multidimensionalen Schemas. Oft sind nicht alle Zellen eines Würfels besetzt. Hier gilt die traditionelle Unterscheidung zwischen nicht möglichen (logische Dünnbesetztheit), nicht bekannten und nicht eingetretenen Ereignissen (natürliche Dünnbesetztheit). Für die Speicherung nicht existenter Werte können meist die Werte NULL 1 oder N/A 2 verwendet werden. Abbildung 4.3 ([AI01]) zeigt die graphische Präsentation der erläuterten Struktur. Die um den Fakt (hier: Umsatz) angeordneten Dimensionen spannen einen Raum auf, der als Datenwürfel bezeichnet wird. Die Kanten/Achsen der Würfel stellen die Dimensionen (hier: Ort, Produkt, Zeit) dar. Die Datenzellen entsprechen den Fakten (hier: Verkaufszahlen). Die Ortdimension ist in diesem Beispiel hierarchisch organisiert. 4.4 Operatoren des multidimensionalen Modells Auf die statischen Strukturen des Datenwürfels sind dynamische Operationen ausführbar, die im folgendem erläutert werden. Das multidimensionale Modell bietet als eine Operation die Restriktion eines Würfels, welche einen Teilwürfel selektiert. Spezialfälle der Selektion sind das slice und dice, die beide eine Betrachtung der Daten aus verschiedenen Perspektiven ermöglichen. Während das Slicing einem Schnitt durch den Datenwürfel entspricht, ist Dicing eine Würfelrotation. Wenn die Würfel das gleiche Schema besitzen, sind Operationen wie Vereinigung, Durchschnitt und Differenz zweier Würfel definierbar. Verbundoperationen auf Würfel ermöglichen es, einen neuen Fakt darzustellen oder zu berechnen [BG01]. Eine Aggregation ist eine Würfelverdichtung von einer feineren zu einer höheren Granularität mittels Aggregationsfunktion. Diese Berechnungsfunktion bildet eine Wertemenge auf einen einzelnen Wert ab. Das Ergebnis einer Aggregationsfunktion lässt sich formal durch die funktionalen Abhängigkeiten auf den Klassifikationsstufen ausdrücken. So gibt es das drill-down,das eine Verfeinerung der Hierarchieebenen bis hin zu den atomaren Werten bewirkt (Bsp. Betrachtung der Verkaufszahlen auf Regionalebene anstatt auf Landesebene). Das roll-up stellt das Gegenstück hierzu dar, also eine Vergröberung der Hierarchie. Das drill-through bietet die Möglichkeit, auch auf Daten zu reporten, die nicht im Data Warehouse selbst, sondern nur in den OLTP- Systemen gespeichert sind (Bsp. Buchungsbelege) [HK01]. Summierbarkeit bezeichnet in diesem Zusammenhang die inhaltliche Korrektheit der Anwendung einer Aggregationsfunktion auf einen Würfel. So ist es zwingend, dass Ergebnisse vergleichbar sind. Die Gruppierungsmengen müssen dafür vollständig und disjunkt sein, um Mehrfachzählungen 1 not applicable 2 not available

18 Fakt (Daten-)Würfel Ort Dimensionen Bremen HB Nord HB Süd Nordwest OL Nord Oldenburg OL West OL Ost Hierarchie A B C D E Zeit Produkt Abbildung 4.3: Multidimensionaler Datenwürfel bei der Aggregation zu vermeiden (Bsp. ein Produkt darf nicht in zwei Produktgruppen vorkommen). Ebenso müssen sich die Operatoren der Aggregationen und die Fakten vom Typ her vertragen. Fakten, die Ereignisse wie Verkäufe beschreiben, können problemlos aggregiert werden. Fakten, die einen Zustand zeigen, dürfen nicht hinsichtlich der Zeitdimension summiert werden (Bsp. Lagerbestand am Jahresende ist nicht die Summe der Lagerbestände der vergangenen Monate, sondern der vom letzten Monat). Andere Fakten, die eher Berechnungsfaktoren sind (Bsp. Preise, Steuersätze) machen eine Summierung unsinnig, da die Preissumme über alle Produkte für sich allein keine vernünftige Aussage bietet. 4.5 Versionierung von Dimensionstabellen Da die Daten eines Data Warehouses für Analysezwecke gedacht sind, ist der Zeitbezug enorm wichtig. Während Fakten durch die Zeit-Dimension implizit eine Gültigkeit aufweisen, werden Veränderungen in den Dimensioneninhalten nicht historisiert. Bisher wurden die Werte der Dimensionstabellen als statisch angesehen. So sind in konventionellen Ansätzen die Dimensionselemente als Schnappschuss- Datenbank charakterisiert, in denen nur Informationen über gegenwärtige Zustände gespeichert sind. Da aber z.b. Mitarbeiter wechseln oder Filialen geschlossen/geöffnet werden können, ist diese Annahme nur für wenige Dimensionstypen richtig. Somit müssen auch diese Änderungen berücksichtigt werden. Indem auch alte und neue Dimensionsdaten für Analysen bereitstehen, sind zeitlich nicht zusammengehörige Fakten und Dimensionsdaten kombinierbar (vgl. [H99]). Der Schemaevolutionsprozess startet, sobald die geänderten Anforderungen in das konzeptionelle Modell integriert werden sollen. Der Designer arbeitet z.b. mit einem Schema in einem Design-tool, das auf einer grafischen Präsentation beruht (Bsp. ME/R-Modell). Das tool ermöglicht es dem Designer, gewünschte Operationen dem Schema hinzuzufügen. Wenn dieser seine Arbeit erfolgreich beendet hat, übergibt er seine Änderungen. Das System kontrolliert dann die Integrität des resultierenden Systems und verbreitet die Änderungen des Schemas und der Instanzen zum Implementierungslevel (Bsp. durch Transformation der Evolutionsoperationen in eine SQL-Sequenz). Somit braucht der Designer keine Implementierungskenntnisse besitzen, da er nur auf konzeptioneller Ebene tätig wird.

19 Kimball führt in diesem Zusammenhang das Konzept der slowly changing dimensions ein (vgl.[k96]). Dieses beschäftigt sich mit den Werteänderungen der Dimensionsattribute. Kimball geht hierbei davon aus, dass sich Dimensionswerte nur sehr langsam ändern (Bsp. Produktbeschreibung). Da Daten von OLAP-Systemen immer zeitbezogen sind, muss die Entwicklung der Änderungen analysiert werden. Er unterscheidet drei Möglichkeiten, zeitlich verändernde Dimensionen zu behandeln: 1. So können Änderungen der Klassifikationshierarchie durch Überschreiben realisiert werden. Diese einfache und schnelle Anpassung der Struktur bewirkt den Verlust der ursprünglichen Klassifikationsstruktur. Damit können keine Auswertungen mit alten Hierarchien durchgeführt werden. Bei operativen Systemen ist diese Methode unproblematisch, da hier nur aktuelle Werte von Interesse sind. Für die Anwendung auf Data-Warehouse-Daten ist diese jedoch nur empfehlenswert, wenn der alte Wert nicht mehr bedeutend ist (Bsp. bei fehlerhaften Werten). 2. Eine andere Möglichkeit ist ein Ansatz mit Versionsnummern. Hierdurch wird die Historisierung und eine saubere Modellierung gewährleistet. Bei einer Werteänderung wird das entsprechende Tupel mit einer neuen Versionsnummer angelegt. Das alte Tupel zeigt somit die Vergangenheit bis zum Zeitpunkt der Änderung, während das neue die vergangenen Werte nach der Änderung beschreibt. Ein Zeitstempel ist bei diesem Ansatz nicht notwendig. Vorteilhaft ist ebenso, dass so viele Änderungen wie gewünscht vermerkt werden können, da für jede Änderung ein neues Tupel angelegt wird. Die Generalisierungsanforderungen und die Tabellengrösse an sich schwächen allerdings die Vorzüge dieser Methode ab. Sobald sich ein Wert des Tupels ändert, wird dieses dupliziert, wodurch enormer Speicherplatzbedarf entsteht. 3. Eine dritte Möglichkeit ist das Anlegen eines Zustandsattributes. Hier werden für die zu historisierenden Dimensionsattribute zusätzliche Felder für den aktuell gültigen und den ursprünglichen Wert mit einbezogen. Bei einer Änderung wird der aktuell gültige Wert überschrieben, der ursprüngliche erhalten. Es gehen somit nur die Änderungen verloren, die zwischen der ersten Eingabe und der Eingabe des aktuell gültigen Wertes durchgeführt werden. Operatoren auf Schemaebene können Schemaänderungen auf der konzeptionellen multidimensionalen Ebene beschreiben. Diese lassen sich hinsichtlich Operatoren des Klassifikationsschemas und des Würfelschemas wie folgt unterscheiden: ˆ insert classification level: diese Operation erweitert das Modell um ein neues Dimensionslevel. Es erweitert die Levelmenge ohne die Klassifikationsbeziehungen zu ändern und hat keine Auswirkungen auf die Instanzen ˆ delete classification level: diese Operation löscht ein Dimensionslevel und automatisch auch die Instanzen des Modells ˆ insert measure: hier wird ein neuer Fakt eingefügt, welche den spezifischen Dimensionen zugeordnet wird. Es werden zusätzliche Informationen für frühere Werte oder ein ausgezeichnetes Zeichen für einen neuen Fakt benötigt ˆ delete measure: diese Operation löscht ein Fakt. Dies hat keinen Einfluss auf die anderen Fakten (es sei denn, sie wurde aus dieser berechnet) und Dimensionen ˆ modify granularity: hier wird die Granularität der Dimension geändert. Die Datenanpassung muss explizit geschehen, d.h. eine Vergröberung der Daten bewirkt eine Aggregation (umgekehrt bei einer Verfeinerung) Änderungen der abzubildenden Welt werden also durch Veränderungen von Klassifikationshierarchien dargestellt. Änderungen der Hierarchie können das Ändern, das Hinzufügen oder das Löschen eines Klassifikationsknotens sein. Ein Knoten wird jedoch nur dann gelöscht, wenn dieser in allen betroffenen Datenräumen ungültig ist. Sobald sich jedoch die Klassifikationshierarchie oder das Datenschema ändert, gehen die ursprünglichen Daten verloren. Änderungen bergen also die Gefahr von Datenverlusten und Inkonsistenzen. Dies führt zu Strukturbrüchen, sodass zeitunterschiedliche Analysen

20 nicht mehr vergleichbar sind. Bei diesen dynamischen Klassifikationshierarchien muss also eine vergangenheitsbezogene Auswertung gewährleistet werden. Das Nachvollziehbarkeitsprinzip erzwingt die Reproduzierbarkeit älterer Analysen. Für die Darstellung eines Zeitbezuges in den Dimensionstabellen sind Erweiterungen der OLAP- Architektur notwendig. So müssen im Repositorium Gültigkeiten abgelegt werden. Der OLAP-Server muss ausserdem zeitbezogene Anfragen verstehen können.nicht zuletzt muss er bei den Informationen der Metadaten Versionsinformationen mitführen können. Unter diesen Voraussetzungen erhält ein OLAP-Server eine zeitbehaftete Anfrage und kann diese interpretieren. Ferner überprüft er, wann welche Dimensionen zu verwenden sind. Das Repositorium wird dann gefragt, welche Instanzen zu diesem Zeitpunkt gültig waren, wodurch die Anfrage an ein Data Warehouse gestellt werden kann [H99].