Seminarausarbeitung Data Warehousing

Größe: px
Ab Seite anzeigen:

Download "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].

OLAP und Data Warehouses

OLAP und Data Warehouses OLP und Data Warehouses Überblick Monitoring & dministration Externe Quellen Operative Datenbanken Extraktion Transformation Laden Metadaten- Repository Data Warehouse OLP-Server nalyse Query/Reporting

Mehr

Einführungsveranstaltung: Data Warehouse

Einführungsveranstaltung: Data Warehouse Einführungsveranstaltung: 1 Anwendungsbeispiele Berichtswesen Analyse Planung Forecasting/Prognose Darstellung/Analyse von Zeitreihen Performancevergleiche (z.b. zwischen Organisationseinheiten) Monitoring

Mehr

Data Warehousing. Kapitel 1: Data-Warehousing-Architektur. Folien teilweise übernommen von Matthias Gimbel

Data Warehousing. Kapitel 1: Data-Warehousing-Architektur. Folien teilweise übernommen von Matthias Gimbel Data Warehousing Kapitel 1: Data-Warehousing-Architektur Folien teilweise übernommen von Matthias Gimbel 2 Analyse von Geschäftsprozessen Mögliche Fragestellungen Wie entwickelt sich unser Umsatz im Vergleich

Mehr

Data-Warehouse-Architektur

Data-Warehouse-Architektur Data-Warehouse-Architektur Anforderungen Referenzarchitektur Phasen des Data Warehousing Komponenten VL Data Warehouses, WS 2000/2001 2-1 Anforderungen des Data Warehousing Unabhängigkeit zwischen Datenquellen

Mehr

Anforderungen des Data Warehousing. 2. Data-Warehouse-Architektur. Anforderungen des Data Warehousing. Referenzarchitektur. Data-Warehouse-Manager

Anforderungen des Data Warehousing. 2. Data-Warehouse-Architektur. Anforderungen des Data Warehousing. Referenzarchitektur. Data-Warehouse-Manager 2. Data-Warehouse-Architektur Anforderungen Referenzarchitektur Phasen des Data Warehousing Komponenten Anforderungen des Data Warehousing Unabhängigkeit zwischen Datenquellen und Analysesystemen (bzgl.

Mehr

Data-Warehouse-Architektur

Data-Warehouse-Architektur Data-Warehouse-Architektur ƒ Anforderungen ƒ Referenzarchitektur ƒ Phasen des Data Warehousing ƒ Komponenten Vorlesung Data-Warehouse-Technologien 2-1 Anforderungen des Data Warehousing ƒ Unabhängigkeit

Mehr

Data Warehouse Grundlagen

Data Warehouse Grundlagen Seminarunterlage Version: 2.10 Version 2.10 vom 24. Juli 2015 Dieses Dokument wird durch die veröffentlicht.. Alle Rechte vorbehalten. Alle Produkt- und Dienstleistungs-Bezeichnungen sind Warenzeichen

Mehr

1 Einleitung. Betriebswirtschaftlich administrative Systeme

1 Einleitung. Betriebswirtschaftlich administrative Systeme 1 1 Einleitung Data Warehousing hat sich in den letzten Jahren zu einem der zentralen Themen der Informationstechnologie entwickelt. Es wird als strategisches Werkzeug zur Bereitstellung von Informationen

Mehr

Kapitel 2 Terminologie und Definition

Kapitel 2 Terminologie und Definition Kapitel 2 Terminologie und Definition In zahlreichen Publikationen und Fachzeitschriften tauchen die Begriffe Data Warehouse, Data Warehousing, Data-Warehouse-System, Metadaten, Dimension, multidimensionale

Mehr

Einführung in OLAP und Business Analysis. Gunther Popp dc soft GmbH

Einführung in OLAP und Business Analysis. Gunther Popp dc soft GmbH Einführung in OLAP und Business Analysis Gunther Popp dc soft GmbH Überblick Wozu Business Analysis mit OLAP? OLAP Grundlagen Endlich... Technischer Background Microsoft SQL 7 & OLAP Services Folie 2 -

Mehr

MIS by Franziska Täschler, Winformation GmbH ftaeschler@winformation-gmbh.ch Ausgabe 01/2001

MIS by Franziska Täschler, Winformation GmbH ftaeschler@winformation-gmbh.ch Ausgabe 01/2001 MIS Glossar by Franziska Täschler, Winformation GmbH ftaeschler@winformation-gmbh.ch Ausgabe 01/2001 Aggregat Data Cube Data Marts Data Mining Data Warehouse (DWH) Daten Decision Support Systeme (DSS)

Mehr

Kapitel II. Datenbereitstellung 2004 AIFB / FZI 1. Vorlesung Knowledge Discovery

Kapitel II. Datenbereitstellung 2004 AIFB / FZI 1. Vorlesung Knowledge Discovery Kapitel II Datenbereitstellung 2004 AIFB / FZI 1 II. Datenbereitstellung 2004 AIFB / FZI 2 II. Datenbereitstellung Collect Initial Data identify relevant attributes identify inconsistencies between sources

Mehr

Kapitel 6 Einführung in Data Warehouses

Kapitel 6 Einführung in Data Warehouses Kapitel 6 Einführung in Data Warehouses Skript zur Vorlesung: Datenbanksysteme II Sommersemester 2008, LMU München 2008 Dr. Peer Kröger Dieses Skript basiert zu einem Teil auf dem Skript zur Vorlesung

Mehr

Multidimensionales Datenmodell, Cognos

Multidimensionales Datenmodell, Cognos Data Warehousing (II): Multidimensionales Datenmodell, Cognos Praktikum: Data Warehousing und Mining Praktikum Data Warehousing und Mining, Sommersemester 2010 Vereinfachte Sicht auf die Referenzarchitektur

Mehr

Datenbanktechnologie für Data-Warehouse-Systeme

Datenbanktechnologie für Data-Warehouse-Systeme Wolfgang Lehner Datenbanktechnologie für Data-Warehouse-Systeme Konzepte und Methoden dpunkt.verlag 1 1.1 1.2 1.3 1.4 1. 5 2 2.1 2.2 2.3 Einleitung 1 Betriebswirtschaftlicher Ursprung des Data Warehousing...

Mehr

Logische Modellierung von Data Warehouses

Logische Modellierung von Data Warehouses Logische Modellierung von Data Warehouses Vertiefungsarbeit von Karin Schäuble Gliederung. Einführung. Abgrenzung und Grundlagen. Anforderungen. Logische Modellierung. Methoden.. Star Schema.. Galaxy-Schema..

Mehr

Business Intelligence. Data Warehouse / Analyse Sven Elvers 2005-07-06

Business Intelligence. Data Warehouse / Analyse Sven Elvers 2005-07-06 Business Intelligence Data Warehouse / Analyse Sven Elvers 2005-07-06 Einleitung Dieses Dokument beschreibt einen für das Verständnis relevanten Teil der Präsentation. Business Intelligence Motivation

Mehr

Kapitel II. Datenbereitstellung. II. Datenbereitstellung. II.1 Grundlagen. II. Datenbereitstellung. Collect Initial Data. II.

Kapitel II. Datenbereitstellung. II. Datenbereitstellung. II.1 Grundlagen. II. Datenbereitstellung. Collect Initial Data. II. II. bereitstellung Kapitel II bereitstellung 1 2 II. bereitstellung II.1 Grundlagen Collect Initial Data identify relevant attributes identify inconsistencies between sources Describe Data characterize

Mehr

Data Warehouse Technologien

Data Warehouse Technologien mitp Professional Data Warehouse Technologien von Veit Köppen, Gunter Saake, Kai-Uwe Sattler 2. Auflage 2014 Data Warehouse Technologien Köppen / Saake / Sattler schnell und portofrei erhältlich bei beck-shop.de

Mehr

Data-Warehouse-Systeme

Data-Warehouse-Systeme Vorlesung im Wintersemester 2008/09 Data-Warehouse-Systeme Dr. Stefanie Rinderle-Ma Institut für Datenbanken und Informationssysteme Universität Ulm stefanie.rinderle@uni-ulm.de Übersicht 1) Einführung

Mehr

Datawarehouse Architekturen. Einheitliche Unternehmenssicht

Datawarehouse Architekturen. Einheitliche Unternehmenssicht Datawarehouse Architekturen Einheitliche Unternehmenssicht Was ist Datawarehousing? Welches sind die Key Words? Was bedeuten sie? DATA PROFILING STAGING AREA OWB ETL OMB*PLUS SAS DI DATA WAREHOUSE DATA

Mehr

Komponenten und Architekturen von Analytischen Informationssystemen (AIS)

Komponenten und Architekturen von Analytischen Informationssystemen (AIS) Komponenten und Architekturen von Analytischen Informationssystemen (AIS) Melanie Pfoh Konsultation 27. Juni 2013 Hinweis Diese Folien ersetzen keinesfalls den Übungsstoff des zugehörigen e-learning-kurses.

Mehr

Data Warehouse Definition (1) http://de.wikipedia.org/wiki/data-warehouse

Data Warehouse Definition (1) http://de.wikipedia.org/wiki/data-warehouse Data Warehouse Definition (1) http://de.wikipedia.org/wiki/data-warehouse Ein Data-Warehouse bzw. Datenlager ist eine zentrale Datensammlung (meist eine Datenbank), deren Inhalt sich aus Daten unterschiedlicher

Mehr

Themenblock: Erstellung eines Cube

Themenblock: Erstellung eines Cube Themenblock: Erstellung eines Cube Praktikum: Data Warehousing und Data Mining Einführung relationale Datenbanken Problem Verwaltung großer Mengen von Daten Idee Speicherung der Daten in Form von Tabellen

Mehr

Data Warehouse. für den Microsoft SQL SERVER 2000/2005

Data Warehouse. für den Microsoft SQL SERVER 2000/2005 Warehouse für den Microsoft SQL SERVER 2000/2005 Begriffe 1 DWH ( Warehouse) ist eine fachübergreifende Zusammenfassung von Datentabellen. Mart ist die Gesamtheit aller Datentabellen für einen fachlich

Mehr

Data-Warehouse-Systeme

Data-Warehouse-Systeme Data-Warehouse-Systeme Architektur, Entwicklung, Anwendung von Andreas Bauer, Holger Günzel 3., überarb. u. aktualis. Aufl. Data-Warehouse-Systeme Bauer / Günzel schnell und portofrei erhältlich bei beck-shop.de

Mehr

BI Konsolidierung: Anspruch & Wirklichkeit. Jacqueline Bloemen. in Kooperation mit

BI Konsolidierung: Anspruch & Wirklichkeit. Jacqueline Bloemen. in Kooperation mit BI Konsolidierung: Anspruch & Wirklichkeit Jacqueline Bloemen in Kooperation mit Agenda: Anspruch BI Konsolidierung Treiber Was sind die aktuellen Treiber für ein Konsolidierungsvorhaben? Kimball vs. Inmon

Mehr

Business Intelligence Data Warehouse. Jan Weinschenker

Business Intelligence Data Warehouse. Jan Weinschenker Business Intelligence Data Warehouse Jan Weinschenker 28.06.2005 Inhaltsverzeichnis Einleitung eines Data Warehouse Data Warehouse im Zusammenfassung Fragen 3 Einleitung Definition: Data Warehouse A data

Mehr

Data Warehouses. Alexander Fehr. 23. Dezember 2002

Data Warehouses. Alexander Fehr. 23. Dezember 2002 Data Warehouses Alexander Fehr 23. Dezember 2002 Inhaltsverzeichnis 1 Einführung 1 1.1 Motivation.............................. 1 1.2 Definitionen.............................. 1 1.3 Abgrenzung von operativen

Mehr

Agenda. Themenblock: Data Warehousing (I) Referenzarchitektur. Eigenschaften eines Data Warehouse. Einführung Data Warehouse Data Access mit SQL

Agenda. Themenblock: Data Warehousing (I) Referenzarchitektur. Eigenschaften eines Data Warehouse. Einführung Data Warehouse Data Access mit SQL Themenblock: Data Warehousing (I) Praktikum: Data Warehousing und Data Mining 2 Eigenschaften eines Data Warehouse Referenzarchitektur Integrierte Sicht auf beliebige Daten aus verschieden Datenbanken

Mehr

ENTERBRAIN Reporting & Business Intelligence

ENTERBRAIN Reporting & Business Intelligence Überblick Vorhandene Listen/Analysen in ENTERBRAIN Die Daten in ENTERBRAIN Das Fundament des BI - Hauses Details zur ENTERBRAIN Staging Area Reports und Cubes auf Basis der Staging Area Data Mining mit

Mehr

Kapitel 4: Data Warehouse Architektur

Kapitel 4: Data Warehouse Architektur Data Warehousing, Motivation Zugriff auf und Kombination von Daten aus mehreren unterschiedlichen Quellen, Kapitel 4: Data Warehousing und Mining 1 komplexe Datenanalyse über mehrere Quellen, multidimensionale

Mehr

Nach Data Warehousing kommt Business Intelligence

Nach Data Warehousing kommt Business Intelligence Nach Data Warehousing kommt Business Intelligence Andrea Kennel Trivadis AG Glattbrugg, Schweiz Schlüsselworte: Business Intelligence, Data Warehouse Zusammenfassung Data Warehouse bedeutet, dass operative

Mehr

Umsetzung der Anforderungen - analytisch

Umsetzung der Anforderungen - analytisch Umsetzung der Anforderungen - analytisch Titel des Lernmoduls: Umsetzung der Anforderungen - analytisch Themengebiet: New Economy Gliederungspunkt im Curriculum: 4.2.5.5 Zum Inhalt: In diesem Modul wird

Mehr

Data Warehouses. Data Warehouse Architektur ... Sommersemester 2011. Melanie Herschel melanie.herschel@uni-tuebingen.de

Data Warehouses. Data Warehouse Architektur ... Sommersemester 2011. Melanie Herschel melanie.herschel@uni-tuebingen.de Data Warehouses Sommersemester 2011 Melanie Herschel melanie.herschel@uni-tuebingen.de Lehrstuhl für Datenbanksysteme, Universität Tübingen Data Warehouse Architektur Data-Warehouse-System Teilsichten

Mehr

Informationssysteme. Prof. Dr. Hans Czap. Lehrstuhl für Wirtschaftsinformatik I. Lehrstuhl für Wirtschaftsinformatik I - II - 1 -

Informationssysteme. Prof. Dr. Hans Czap. Lehrstuhl für Wirtschaftsinformatik I. Lehrstuhl für Wirtschaftsinformatik I - II - 1 - Vorlesung Grundlagen betrieblicher Informationssysteme Prof. Dr. Hans Czap Email: Hans.Czap@uni-trier.de - II - 1 - Inhalt Kap. 1 Ziele der Datenbanktheorie Kap. 2 Datenmodellierung und Datenbankentwurf

Mehr

Intelligente Kanzlei

Intelligente Kanzlei Seite 1 von 5 Intelligente Kanzlei Datawarehouse und OLAP in der Steuerkanzlei Notwendigkeit eines Kanzleiinformationssystems Seit einigen Jahren sind enorme Veränderungen am Beratungsmarkt durch einen

Mehr

Star-Schema-Modellierung mit ERwin - eine kritische Reflexion der Leistungspotentiale und Anwendungsmöglichkeiten

Star-Schema-Modellierung mit ERwin - eine kritische Reflexion der Leistungspotentiale und Anwendungsmöglichkeiten Star-Schema-Modellierung mit ERwin - eine kritische Reflexion der Leistungspotentiale und Anwendungsmöglichkeiten Michael Hahne T&I GmbH Workshop MSS-2000 Bochum, 24. März 2000 Folie 1 Worum es geht...

Mehr

Steuerungsverfahren und ihre Datenstrukturen 02 - Datenmanagement

Steuerungsverfahren und ihre Datenstrukturen 02 - Datenmanagement Steuerungsverfahren und ihre Datenstrukturen 02 - Datenmanagement 1 Übersicht - Datenmanagement 1 Übersicht - Datenmanagement...1 2 Übersicht: Datenbanken - Datawarehouse...2 3 Übersicht: Data Mining...11

Mehr

Solution for Business Intelligence. MID Insight 2013

Solution for Business Intelligence. MID Insight 2013 Solution for Business Intelligence MID Insight 2013 A G E N D A 1. Solution für Business Intelligence (BI) 2. Die Gründe und Hintergründe 3. Die Methode 4. Vorteile MID GmbH 2013 2 Solution für Business

Mehr

Data Warehousing: Anwendungsbeispiel

Data Warehousing: Anwendungsbeispiel Frühjahrsemester 2012 cs242 Data Warehousing / cs243 Datenbanken Kapitel 1: Einführung H. Schuldt Data Warehousing: Anwendungsbeispiel Tresgros Tresgros Tresgros Filiale Muttenz Filiale Allschwil Filiale

Mehr

Multidimensionales Datenmodell

Multidimensionales Datenmodell Multidimensionales Datenmodell Grundbegriffe fi Fakten, Dimensionen, Würfel Analyseoperationen fi Drill-Down, Roll-Up, Slice und Dice Notationen zur konzeptuellen Modellierung fi ME/R, ADAPT Relationale

Mehr

fi Data Warehouse: Sammlung von Technologien zur Unterstützung von Entscheidungsprozessen fi Herausforderung an Datenbanktechnologien

fi Data Warehouse: Sammlung von Technologien zur Unterstützung von Entscheidungsprozessen fi Herausforderung an Datenbanktechnologien Einführung Gegenstand der Vorlesung fi Data Warehouse: Sammlung von Technologien zur Unterstützung von Entscheidungsprozessen fi Herausforderung an Datenbanktechnologien Datenvolumen (effiziente Speicherung

Mehr

Vergleich von Open-Source und kommerziellen Programmen zur Durchführung eines ETL-Prozesses

Vergleich von Open-Source und kommerziellen Programmen zur Durchführung eines ETL-Prozesses Vergleich von Open-Source und kommerziellen Programmen zur Durchführung eines ETL-Prozesses Exposé zur Diplomarbeit Humboldt-Universität zu Berlin Mathematisch-Naturwissenschaftliche Fakultät II Institut

Mehr

Realisierung von OLAP Operatoren in einem visuellen Analysetool. Vortrag von Alexander Spachmann und Thomas Lindemeier

Realisierung von OLAP Operatoren in einem visuellen Analysetool. Vortrag von Alexander Spachmann und Thomas Lindemeier Realisierung von OLAP Operatoren in einem visuellen Analysetool Vortrag von Alexander Spachmann und Thomas Lindemeier Gliederung Ausgangssituation/Motivation Was ist OLAP? Anwendungen Was sind Operatoren?

Mehr

WAHLPFLICHTBEREICH WIRTSCHAFTSINFORMATIK 'DATA WAREHOUSE'

WAHLPFLICHTBEREICH WIRTSCHAFTSINFORMATIK 'DATA WAREHOUSE' Take control of your decision support WAHLPFLICHTBEREICH WIRTSCHAFTSINFORMATIK 'DATA WAREHOUSE' Sommersemester 2008 Gliederung Business Intelligence und Data Warehousing On-Line Analytical Processing Ziel

Mehr

Agile Analytics Neue Anforderungen an die Systemarchitektur

Agile Analytics Neue Anforderungen an die Systemarchitektur www.immobilienscout24.de Agile Analytics Neue Anforderungen an die Systemarchitektur Kassel 20.03.2013 Thorsten Becker & Bianca Stolz ImmobilienScout24 Teil einer starken Gruppe Scout24 ist der führende

Mehr

Eignung unterschiedlicher Faktenmodellierungen in Data Warehouse-Systemen

Eignung unterschiedlicher Faktenmodellierungen in Data Warehouse-Systemen Christoph Arnold (B. Sc.) Prof. Dr. Harald Ritz Eignung unterschiedlicher Faktenmodellierungen in Data Warehouse-Systemen AKWI-Tagung, 17.09.2012, Hochschule Pforzheim Christoph Arnold, Prof. Dr. Harald

Mehr

1Ralph Schock RM NEO REPORTING

1Ralph Schock RM NEO REPORTING 1Ralph Schock RM NEO REPORTING Bereit für den Erfolg Business Intelligence Lösungen Bessere Entscheidungen Wir wollen alle Mitarbeiter in die Lage versetzen, bessere Entscheidungen schneller zu treffen

Mehr

Mit Transbase Hypercube Data Warehouse Anwendungen effizient betreiben. Die Hypercube-Technologie

Mit Transbase Hypercube Data Warehouse Anwendungen effizient betreiben. Die Hypercube-Technologie Mit Transbase Hypercube Data Warehouse Anwendungen effizient betreiben Transbase Hypercube ist eine Transbase -Option, die die innovative Hypercube-Technologie für komplexe analytische Anwendungen (OLAP)

Mehr

Business Intelligence

Business Intelligence Business Intelligence Anwendungssysteme (BIAS) Lösung Aufgabe 1 Übung WS 2012/13 Business Intelligence Erläutern Sie den Begriff Business Intelligence. Gehen Sie bei der Definition von Business Intelligence

Mehr

Vertrautmachen mit Daten

Vertrautmachen mit Daten Kapitel III Vertrautmachen mit Daten 2004 AIFB / FZI 1 III Vertrautmachen mit Daten (see also Data Preparation ) 2004 AIFB / FZI 2 III Vertrautmachen mit Daten III.1 OLAP III.1.1 Einführung in OLAP Wie

Mehr

Asklepius-DA Die intelligente Technologie für die umfassende Analyse medizinischer Daten Leistungsbeschreibung

Asklepius-DA Die intelligente Technologie für die umfassende Analyse medizinischer Daten Leistungsbeschreibung Asklepius-DA Die intelligente Technologie für die umfassende Analyse medizinischer Daten Leistungsbeschreibung Datei: Asklepius DA Flyer_Leistung_2 Seite: 1 von:5 1 Umfassende Datenanalyse Mit Asklepius-DA

Mehr

Komponenten und Architekturen von Analytischen Informationssystemen (AIS)

Komponenten und Architekturen von Analytischen Informationssystemen (AIS) Komponenten und Architekturen von Analytischen Informationssystemen (AIS) Melanie Pfoh Konsultation Zusammenfassung OPAL 6. Übung Juni 2015 Agenda Hinweise zur Klausur Zusammenfassung OPAL Übungen / Kontrollfragen

Mehr

Business Intelligence und Geovisualisierung in der Gesundheitswirtschaft

Business Intelligence und Geovisualisierung in der Gesundheitswirtschaft Business Intelligence und Geovisualisierung in der Gesundheitswirtschaft Prof. Dr. Anett Mehler-Bicher Fachhochschule Mainz, Fachbereich Wirtschaft Prof. Dr. Klaus Böhm health&media GmbH 2011 health&media

Mehr

Data Warehouse. Kapitel 17. Abbildung 17.1: Zusammenspiel zwischen OLTP und OLAP. Man unterscheidet zwei Arten von Datenbankanwendungen:

Data Warehouse. Kapitel 17. Abbildung 17.1: Zusammenspiel zwischen OLTP und OLAP. Man unterscheidet zwei Arten von Datenbankanwendungen: Kapitel 17 Data Warehouse OLTP Online Transaction Processing OLAP Online Analytical Processing Decision Support-Anfragen Data Mining opera- tionale DB opera- tionale DB opera- tionale DB Data Warehouse

Mehr

Marketing Intelligence Übersicht über Business Intelligence. Josef Kolbitsch Manuela Reinisch

Marketing Intelligence Übersicht über Business Intelligence. Josef Kolbitsch Manuela Reinisch Marketing Intelligence Übersicht über Business Intelligence Josef Kolbitsch Manuela Reinisch Übersicht Beispiel: Pantara Holding Der Begriff Business Intelligence Übersicht über ein klassisches BI-System

Mehr

The integration of business intelligence and knowledge management

The integration of business intelligence and knowledge management The integration of business intelligence and knowledge management Seminar: Business Intelligence Ketevan Karbelashvili Master IE, 3. Semester Universität Konstanz Inhalt Knowledge Management Business intelligence

Mehr

Seminar. Data Warehousing im Verkehrsbereich. Grundlagen und Architektur

Seminar. Data Warehousing im Verkehrsbereich. Grundlagen und Architektur Stärkung der SelbstOrganisationsfähigkeit im Verkehr durch I+K-gestützte Dienste Seminar Data Warehousing im Verkehrsbereich Sommersemester 2003 Grundlagen und Architektur Bearbeiter: Ting Zheng Betreuer:

Mehr

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221 Oracle 10g und SQL Server 2005 ein Vergleich Thomas Wächtler 39221 Inhalt 1. Einführung 2. Architektur SQL Server 2005 1. SQLOS 2. Relational Engine 3. Protocol Layer 3. Services 1. Replication 2. Reporting

Mehr

Performanceoptimierung mit Exadata Verarbeitung extremer Datenmengen mit PL/SQL basierter Datenbewirtschaftung (Erfahrungsbericht)

Performanceoptimierung mit Exadata Verarbeitung extremer Datenmengen mit PL/SQL basierter Datenbewirtschaftung (Erfahrungsbericht) Performanceoptimierung mit Exadata Verarbeitung extremer Datenmengen mit PL/SQL basierter Datenbewirtschaftung (Erfahrungsbericht) Christian Haag, DATA MART Consulting Consulting Manager Oracle DWH Team

Mehr

Data Warehouses und Moderne Betriebliche Anwendungen von Datenbanksystemen

Data Warehouses und Moderne Betriebliche Anwendungen von Datenbanksystemen Data Warehouses und Moderne Betriebliche Anwendungen von Datenbanksystemen (Folien von A. Kemper zum Buch 'Datenbanksysteme') Online Transaction Processing Betriebswirtschaftliche Standard- Software (SAP

Mehr

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Andreas Ditze MID GmbH Kressengartenstraße 10 90402 Nürnberg a.ditze@mid.de Abstract: Data Lineage

Mehr

Business Intelligence im Krankenhaus

Business Intelligence im Krankenhaus Business Intelligence im Krankenhaus Dr. Thomas Lux Holger Raphael IT-Trends in der Medizin 03.September 2008 Essen Gliederung Herausforderungen für das Management im Krankenhaus Business Intelligence

Mehr

Adlerblick So gewinnen Sie einen Überblick über ein DWH Dr. Andrea Kennel InfoPunkt Kennel GmbH CH-8600 Dübendorf Schlüsselworte Einleitung

Adlerblick So gewinnen Sie einen Überblick über ein DWH Dr. Andrea Kennel InfoPunkt Kennel GmbH CH-8600 Dübendorf Schlüsselworte Einleitung Adlerblick So gewinnen Sie einen Überblick über ein DWH Dr. Andrea Kennel InfoPunkt Kennel GmbH CH-8600 Dübendorf Schlüsselworte DWH Projekt, Methodik, Stärken und Schwächen, Übersicht, Weg der Daten,

Mehr

6 InfoCubes erstellen und konfigurieren

6 InfoCubes erstellen und konfigurieren InfoCubes bilden die Reportingschicht in der LSA; sie sind für die Performance des Reportings entscheidend. In diesem Kapitel stellen wir Ihnen vor, welche InfoCubes es gibt und wie Sie damit arbeiten.

Mehr

OLAP mit dem SQL-Server

OLAP mit dem SQL-Server Hartmut Messerschmidt Kai Schweinsberg OLAP mit dem SQL-Server Eine Einführung in Theorie und Praxis IIIBibliothek V dpunkt.verlag Teil OLAP undder Microsoft SQL-Server 1 1 Theoretische Grundlagen 3 1.1

Mehr

Relationale Datenbanken Datenbankgrundlagen

Relationale Datenbanken Datenbankgrundlagen Datenbanksystem Ein Datenbanksystem (DBS) 1 ist ein System zur elektronischen Datenverwaltung. Die wesentliche Aufgabe eines DBS ist es, große Datenmengen effizient, widerspruchsfrei und dauerhaft zu speichern

Mehr

Business Intelligence

Business Intelligence Business Intelligence Anwendung 1 MInf1 HAW Hamburg Betreuender Professor: Prof. Dr. Zukunft by Jason Hung Vuong [12] Gliederung 1. Hamburg Energie Kooperation 2. Motivation 3. Business Intelligence 4.

Mehr

Hinweise zur Klausur Zusammenfassung OPAL-Übungen / Kontrollfragen Fragen Vertiefung Modellierung

Hinweise zur Klausur Zusammenfassung OPAL-Übungen / Kontrollfragen Fragen Vertiefung Modellierung Komponenten und Architekturen von Analytischen Informationssystemen (AIS) Melanie Pfoh Konsultation Zusammenfassung OPAL 24. Juni 2014 Agenda Hinweise zur Klausur Zusammenfassung OPAL-Übungen / Kontrollfragen

Mehr

Friedrich-Schiller-Universität Jena

Friedrich-Schiller-Universität Jena Friedrich-Schiller-Universität Jena Seminar WS2011 Data Warehouse Systeme Präsentationsthema Metadaten Präsentiert von: Julian Zausch, 96382 Inhaltsverzeichnis EINLEITUNG... - 3 - WELCHE ROLLE SPIELEN

Mehr

Data Mining-Projekte

Data Mining-Projekte Data Mining-Projekte Data Mining-Projekte Data Mining stellt normalerweise kein ei nmaliges Projekt dar, welches Erkenntnisse liefert, die dann nur einmal verwendet werden, sondern es soll gewöhnlich ein

Mehr

Eine Einführung in OLAP

Eine Einführung in OLAP Eine Einführung in OLAP Einleitung... 1 Wofür wird OLAP benötigt?... 1 Was ist OLAP?... 3 OLAP Charakteristika... 3 Dimensionen... 3 Hierarchien... 3 Flexible Präsentation... 4 OLAP und Data Warehousing...

Mehr

Innovatives Reporting mit PM10: Analysen und Berichte mit Single Point of Truth 11.00 11.45 Uhr

Innovatives Reporting mit PM10: Analysen und Berichte mit Single Point of Truth 11.00 11.45 Uhr Copyright 2007 Infor. Alle Rechte vorbehalten. Innovatives Reporting mit PM10: Analysen und Berichte mit Single Point of Truth 11.00 11.45 Uhr Hubertus Thoma Presales Consultant PM Schalten Sie bitte während

Mehr

Data Warehouse Version: June 26, 2007. Andreas Geyer-Schulz und Anke Thede

Data Warehouse Version: June 26, 2007. Andreas Geyer-Schulz und Anke Thede Data Warehouse Version: June 26, 2007 Andreas Geyer-Schulz und Anke Thede Schroff-Stiftungslehrstuhl Informationsdienste und Elektronische Märkte Fakultät für Wirtschaftswissenschaften Gebäude 20.20 Rechenzentrum,

Mehr

Marketing Intelligence Architektur und Konzepte. Josef Kolbitsch Manuela Reinisch

Marketing Intelligence Architektur und Konzepte. Josef Kolbitsch Manuela Reinisch Marketing Intelligence Architektur und Konzepte Josef Kolbitsch Manuela Reinisch Übersicht Mehrstufiges BI-System Architektur eines Data Warehouses Architektur eines Reporting-Systems Benutzerrollen in

Mehr

Einsatz von Anwendungssystemen

Einsatz von Anwendungssystemen Einsatz von Anwendungssystemen WS 2013/14 7 Führungssysteme 7.1 Data Warehouse 7.2 Planungssysteme 7.3 Balanced Scorecard (BSC) 7.4 Business Intelligence 7 Führungssysteme 7.1 Data Warehouse Ein Data Warehouse

Mehr

Hetero-Homogene Data Warehouses

Hetero-Homogene Data Warehouses Hetero-Homogene Data Warehouses TDWI München 2011 Christoph Schütz http://hh-dw.dke.uni-linz.ac.at/ Institut für Wirtschaftsinformatik Data & Knowledge Engineering Juni 2011 1 Data-Warehouse-Modellierung

Mehr

Business Intelligence Aufgabenstellung

Business Intelligence Aufgabenstellung Hochschule Darmstadt Business Intelligence (BI) Fachbereich Informatik Praktikum 2 Prof. Dr. C. Wentzel Dipl. Inf. Dipl. Math. Y. Orkunoglu Sebastian Gobst Änderung: 15.06.2012 Datum: 30.05.2012 1. Einführung

Mehr

Leseprobe. Claus Jordan, Dani Schnider, Joachim Wehner, Peter Welker. Data Warehousing mit Oracle. Business Intelligence in der Praxis

Leseprobe. Claus Jordan, Dani Schnider, Joachim Wehner, Peter Welker. Data Warehousing mit Oracle. Business Intelligence in der Praxis Leseprobe Claus Jordan, Dani Schnider, Joachim Wehner, Peter Welker Data Warehousing mit Oracle Business Intelligence in der Praxis ISBN: 978-3-446-42562-0 Weitere Informationen oder Bestellungen unter

Mehr

Data Warehouse und Data Mining

Data Warehouse und Data Mining Data Warehouse und Data Mining Seminararbeit von Christian Hägele im Februar 2004 Betreuer: Dr. M. Grabert Inhaltsverzeichnis 1 Einführung 1 2 Data Warehouse 3 2.1 Warum Data Warehouse?........................

Mehr

Data Warehousing. Fragen des Marketingleiters. Beispiel: : Amazon. Technisch... Amazon weltweit... Datenbank. Aufbau eines DWH OLAP <-> OLTP Datacube

Data Warehousing. Fragen des Marketingleiters. Beispiel: : Amazon. Technisch... Amazon weltweit... Datenbank. Aufbau eines DWH OLAP <-> OLTP Datacube Fragen des Marketingleiters Data Warehousing Wie viele Bestellungen haben wir jeweils im Monat vor Weihnachten, aufgeschlüsselt nach? Aufbau eines DWH OLAP OLTP Datacube Beispiel: : Amazon Technisch

Mehr

1 Einführung. Unbekannte Begriffe: Business Intelligence, Knowledge Management, Unternehmensportale, Information Warehouse.

1 Einführung. Unbekannte Begriffe: Business Intelligence, Knowledge Management, Unternehmensportale, Information Warehouse. 1 Einführung mysap Business Intelligence stellt mit Hilfe von Knowledge Management die Verbindung zwischen denen, die etwas wissen und denen, die etwas wissen müssen her. mysap Business Intelligence integriert

Mehr

Friedrich-Schiller-Universität Jena Fakultät für Mathematik Informatik Lehrstuhl für Datenbanken und Informationssysteme Betreut von: David Wiese

Friedrich-Schiller-Universität Jena Fakultät für Mathematik Informatik Lehrstuhl für Datenbanken und Informationssysteme Betreut von: David Wiese Friedrich-Schiller-Universität Jena Fakultät für Mathematik Informatik Lehrstuhl für Datenbanken und Informationssysteme Betreut von: David Wiese Seminar Data Warehousing Sommersemester 2005 vorgelegt

Mehr

Einführung in Data Warehouses

Einführung in Data Warehouses Kapitel l6 Einführung in Data Warehouses Vorlesung: Dr. Matthias Schubert Skript 2009 Matthias Schubert Dieses Skript basiert auf dem Skript zur Vorlesung Datenbanksysteme II von Prof. Dr. Christian Böhm

Mehr

Vorwort zur zweiten Auflage...V. Vorwort zur ersten Auflage... VIII

Vorwort zur zweiten Auflage...V. Vorwort zur ersten Auflage... VIII Vorwort zur zweiten Auflage...V Vorwort zur ersten Auflage... VIII 1 Management Support Systeme und Business Intelligence Anwendungssysteme zur Unterstützung von Managementaufgaben...1 1.1 Computergestützte

Mehr

1 Einführung 1 1.1 SAP Business Information Warehouse... 3. 1.1.1 BW Version 3.0...5. Architekturplanung... 9

1 Einführung 1 1.1 SAP Business Information Warehouse... 3. 1.1.1 BW Version 3.0...5. Architekturplanung... 9 vii 1 Einführung 1 1.1 SAP Business Information Warehouse... 3 1.1.1 BW Version 3.0...5 Architekturplanung.................................... 9 2 BW-Basissystem 11 2.1 Client/Server-Architektur... 12

Mehr

Integration Services Übersicht

Integration Services Übersicht Integration Services Übersicht Integration Services Übersicht Integration Services stellt umfangreiche integrierte Tasks, Container, Transformationen und Datenadapter für die En t- wicklung von Geschäftsanwendungen

Mehr

Software-Engineering und Datenbanken

Software-Engineering und Datenbanken Software-Engineering und Datenbanken Prof. Dr. Bernhard Schiefer bernhard.schiefer@fh-kl.de http://www.fh-kl.de/~schiefer Prof. Dr. Bernhard Schiefer 1-1 Wesentliche Inhalte Begriff DBS Datenbankmodelle

Mehr

Ausarbeitung Projekt. Sven Elvers. Business Intelligence: Analyse. Betreuender Prüfer: Prof. Dr. Olaf Zukunft

Ausarbeitung Projekt. Sven Elvers. Business Intelligence: Analyse. Betreuender Prüfer: Prof. Dr. Olaf Zukunft Hochschule für Angewandte Wissenschaften Hamburg Hamburg University of Applied Sciences Ausarbeitung Projekt Sven Elvers Business Intelligence: Analyse Betreuender Prüfer: Prof. Dr. Olaf Zukunft Fakultät

Mehr

Christian Kurze BI-Praktikum IBM WS 2008/09

Christian Kurze BI-Praktikum IBM WS 2008/09 Einführung in die multidimensionale Datenmodellierung e mit ADAPT BI-Praktikum IBM WS 2008/09 1 Gliederung Einführung multidimensionale Datenmodellierung 1. Multidimensionales Modell BI-Praktikum IBM WS

Mehr

Data Warehousing Grundbegriffe und Problemstellung

Data Warehousing Grundbegriffe und Problemstellung Data Warehousing Grundbegriffe und Problemstellung Dr. Andrea Kennel, Trivadis AG, Glattbrugg, Schweiz Andrea.Kennel@trivadis.com Schlüsselworte Data Warehouse, Cube, Data Mart, Bitmap Index, Star Queries,

Mehr

BARC-Studie Data Warehousing und Datenintegration

BARC-Studie Data Warehousing und Datenintegration Ergebnisse der BARC-Studie Data Warehouse Plattformen Dr. Carsten Bange BARC-Studie Data Warehousing und Datenintegration Data-Warehouse -Plattformen und Datenintegrationswerkzeuge im direkten Vergleich

Mehr

Data Warehouse. Kapitel 16. Abbildung 16.1: Zusammenspiel zwischen OLTP und OLAP. Man unterscheidet zwei Arten von Datenbankanwendungen:

Data Warehouse. Kapitel 16. Abbildung 16.1: Zusammenspiel zwischen OLTP und OLAP. Man unterscheidet zwei Arten von Datenbankanwendungen: Kapitel 16 Data Warehouse OLTP Online Transaction Processing OLAP Online Analytical Processing Decision Support-Anfragen Data Mining operationale DB operationale DB operationale DB Data Warehouse operationale

Mehr

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching 1.1 Caching von Webanwendungen In den vergangenen Jahren hat sich das Webumfeld sehr verändert. Nicht nur eine zunehmend größere Zahl an Benutzern sondern auch die Anforderungen in Bezug auf dynamischere

Mehr

Agenda. Hype oder Mehrwert. Herausforderungen. Methoden Werkzeuge. Kosten Nutzen. Definition Ziele

Agenda. Hype oder Mehrwert. Herausforderungen. Methoden Werkzeuge. Kosten Nutzen. Definition Ziele Agenda Definition Ziele Methoden Werkzeuge Herausforderungen Kosten Nutzen Hype oder Mehrwert Definition / Ziele Google Suche: define:business Intelligence Mit Business Intelligence können alle informationstechnischen

Mehr

Zusammenspiel von Business Intelligence mit betrieblicher Anwendungssoftware Falk Neubert, Universität Osnabrück

Zusammenspiel von Business Intelligence mit betrieblicher Anwendungssoftware Falk Neubert, Universität Osnabrück Zusammenspiel von Business Intelligence mit betrieblicher Anwendungssoftware 14. März 2013, IHK Osnabrück-Emsland-Grafschaft Bentheim Geschichte Kassenbuch des Liederkranz, 1886 Hutmachergesangvereins

Mehr

Aufbau eines Data Warehouse für den Lebensmitteleinzelhandel

Aufbau eines Data Warehouse für den Lebensmitteleinzelhandel Die Fallstudie aus der Wirtschaftsinformatik: Aufbau eines Data Warehouse für den Lebensmitteleinzelhandel Dipl.-Kfm. Carsten Bange, Dr. Heiko Schinzer, Würzburg 1. Ausgangssituation Der hohe Wettbewerbsdruck

Mehr

DW Data Warehousing Funktionsweise, Einsatz- und Problemfelder

DW Data Warehousing Funktionsweise, Einsatz- und Problemfelder DW Data Warehousing Funktionsweise, Einsatz- und Problemfelder Andreas Meier, Universität Fribourg Folie 1 DW Cartoon Quelle: Knoll M., Meier A. (Hrsg): Web & Data Mining. Praxis der Wirtschaftsinformatik,

Mehr