Data Warehouse. Prof. Dr. W. Riggert

Transkript

1 Data Warehouse Prof. Dr. W. Riggert

2 Gliederung Ausgangssituation : Motiv und Hintergrund Definition und Architektur Operative Systeme vs Data Warehouse OLAP und Beispiel Data Mining 2

3 Motiv Marktentwicklungen und Wettbewerb zwingen zu - kürzeren Entscheidungsprozessen - besserer Entscheidungsunterstützung durch Information - flacheren Strukturen - Business Process Reengineering Data Warehouse Technische Entwicklungen ermöglichen bessere Lösungen - starke Endbenutzerwerkzeuge - Client-Server Technologie - preisgünstige Hard- und Software Quelle : Software AG 3

4 Motiv Könnten Sie mir schnell das wichtigste auf einer Seite zusammenfassen? 4

5 Ursache Flut nicht relevanter Informationen erschwert das Herausfiltern entscheidungsbedeutender Informationen: Im WWW findet keine Selektion statt -Verkehr steigt exponentiell Moderne Informations- und Kommunikationstechnologien sind Wegbereiter der Datenflut, da Speicherkapazität keine limitierende Ressource darstellt 5

6 Hintergrund Hinter den Daten transaktionsorientierter Anwendungen verbergen sich wichtige Informationen, z.b. Aussagen über : Kaufverhalten Kundenwünsche Markttrends Qualitätssituation Geschäftsperformance Wettbewerber 6

7 Ist-Situation Die Daten sind in zu vielen Datenbanken verstreut und nicht vergleichbar. (Datumsformate, Währungen, etc.) Es gibt keinen zentralen Ort zur Speicherung externer Zahlen (z.b. Marktforschungen oder Daten über Konkurrenten.) Auf die vorhandenen Datenbanken ist Zugriff nur bedingt möglich. Es fällt schwer, aus den vorhandenen Systemen geeignete Daten zu extrahieren. Extraktion liegt in der Hand der SQL-Kenner. 7

8 Gliederung Ausgangssituation : Motiv und Hintergrund Definition und Architektur Operative Systeme vs Data Warehouse OLAP und Beispiel Data Mining 8

9 Ziele Zusammenführung (Integration) und Verdichtung (Aggregation) von Daten aus mehreren heterogenen Quellen in einer zentralen Datenbank 9

10 Definition : Annäherung Nicht jede Datensammlung ist ein Data Warehouse! Ein Data Warehouse (DW) ist ein Datenlager, das nach einem bestimmten Konzept strukturiert ist, um flexible und schnelle Auswertungen zu ermöglichen 10

11 Definition - exakt 1 "Ein Data Warehouse ist eine Themenorientiert Die Daten werden nach dem betriebswirtschaftlichen Umfeld des Unternehmens organisiert. "Alles über Kunden, Produkte oder..." Zeitorientiert Daten eines Data Warehouses werden langfristig gespeichert. Jedes Data Warehouse beinhaltet auch die Dimension Zeit. Periodische Ergänzung um aktuelle Daten, u.u. Verdichtung älterer Informationen 11

12 Definition - exakt 2 integriert Das Data Warehouse wird aus einer Vielzahl interner wie externer Datenquellen bewirtschaftet. Dabei spielt die Datenqualität eine wesentliche Rolle. Zusammenführung und Konsolidierung verteilter Daten Unveränderlich Die Daten werden persistent gespeichert. Daten sind nur lesbar. Datensammlung für Managemententscheidungen." (W.H. Inmon, "Building the Data Warehouse") 12

13 Data Warehouse Merkmale Themenorientierung: Data Warehouses befriedigen den Informationsbedarf bezüglich Sachverhalten, die das Handeln des Unternehmens bestimmen Integration: Data Warehouses vereinheitlichen die Daten der Vorsysteme: Anpassung an Datenformate Vereinheitlichung von Datumsfeldern Umrechnung von Werteinheiten Währungsumrechnungen Beständigkeit: Die im Data Warehouse abgelegten Daten werden nicht mehr verändert nur Lese-Zugriff Zeitraumbezug: Data Warehouses beinhalten zeitraumbezogene, historisierte Daten 13

14 Merkmale Bestimmende Merkmale: Vereinheitlichung: aus aus verschiedenen Datenbeständen in in eine eine homogene Datenwelt zusammengeführt Themenausrichtung: auf auf die die Informationsbedürfnisse des des Anwenders ausgerichtet Zeitorientierung: Einbeziehung von von historischen Werten (aber (aber auch auch von von Planzahlen) Dauerhaftigkeit: jederzeitige Wiederholbarkeit einer einer Abfrage 14

15 Data Warehouse Einordnung 15

16 Data Warehouse Architektur Data Marts (DM) ASCII Endbenutzeranalysen Staging Area Core DWH Clients Host Relat. DB [ ] Extraktion Transformation Aggregation Metadaten-Management Analyse Quelle : Diplomarbeit Herrera 16

17 Data Warehouse Anforderungen 1 Das Data Warehouse bietet einen Zugang zu allen relevanten Daten des Unternehmens. Die Daten eines Data Warehouses sind konsistent, d.h. frei von logischen Widersprüchen Daten im Data Warehouse können nach jeder beliebigen und möglichen betrieblichen Kennzahl getrennt und kombiniert werden 17

18 Data Warehouse Anforderungen 2 Das Data Warehouse besteht nicht nur aus Daten. Zum Gesamtsystem gehören auch verschiedene Tools um die Daten abzufragen, analysieren und darzustellen Das Veröffentlichen der Daten ist die Kernaufgabe des Data Warehouses. Die Daten werden an einem zentralen Ort gesammelt, sorgfältig transformiert und qualitätsgesichert Das Data Warehouse kann keine mangelhafte Datenqualität beheben. 18

19 Data Warehouse Ziele Ein Data Warehouse führt Daten aus unterschiedlichen internen und externen Quellen zusammen, um mit Abfrage- und Analysewerkzeugen neue Informationen zu gewinnen besitzt eine eigenen physische Datenhaltung, um operative Anwendungen nicht zu beeinträchtigen nutzt sämtliche Datenformate: relationale Daten, unstrukturierten Text, Fotos, Videos beinhaltet aggregierte Daten über einen längeren Zeitraum 19

20 Data Mart Ein Data Mart ist eine logische und physikalische Teilmenge eines Data Warehouse mit subjekt- oder abteilungsspezifischem Charakter Dabei ist es nicht erforderlich, die Daten unmittelbar aus dem Data Warehouse zu laden, sondern eine Übernahme direkt aus den operativen Daten ist möglich. 20

21 Data Mart Eigenschaften Data Marts sind abteilungs- oder themenbezogene Datenbanken, die eine Untermenge der im zentralen Data Warehouse gespeicherten operativen Daten enthalten Data Marts werden eingeführt, um die Systemleistung bei Datenabfragen zu verbessern und die Abhängigkeit von unternehmensweiten Warehouse-Daten zu verringern. 21

22 Data-Mart Architektur Data Marts (DM) ASCII Endbenutzer- Analysen Staging Area Clients Host Relat.DB [ ] Extraktion Transformation Aggregation Metadaten-Management Analyse Quelle : Diplomarbeit Herrera 22

23 Datenübernahme: ETL-Prozess Die Datenübernahme ist ein dreistufiger Prozess: Extraktion: Selektion der Daten aus den Quellen und Ablage in einen Zwischenspeicher. Arten: Periodische Extraktion Extraktion auf Anfrage Ereignisgesteuerte Extraktion Transformation: Beseitigung von Qualitätsmängeln der Daten aufgrund Inkorrekter Daten Inkonsistenter Daten Unvollständiger Daten Doppelter Daten Veralteter Daten Irrelevanter Daten 23

24 Transformation Die Qualität wird durch mehrere Maßnahmen gesichert: Bereinigung durch Ausgleich syntaktischer und semantischer Mängel Harmonisierung durch die Vereinheitlichung unterschiedlicher Codierungen; z.b. m/w oder 0/1 und Blank für Unternehmen Verdichtung durch Aggregation auf verschiedenen Stufen Anreicherung durch weitere Kennzahlen 24

25 Transformation: Konflikte bei der Datenintegration Semantische Konflikte: In zwei Datenquellen wird das gleiche Objekt mit unterschiedlichen Attributen beschrieben Beschreibungskonflikte: für Attribute der selben Objekte werden synonyme Bezeichnungen, verschiedenen Datentypen, Wertebereiche oder unterschiedliche Maßeinheiten verwendet Falsche Daten: Eingabefehler oder veraltete Daten Unterschiedliche Repräsentation: gleicher semantischer Sachverhalt wird unterschiedlich abgebildet: Schulnote als 1 bis 6 oder als sehr gut bis unzureichend 25

26 Transformation: Konfliktbereinigung Konvertierungs- und Normalisierungsfunktionen: Zurückführung unterschiedlicher Einheiten auf einen festgelegten Standard Domänenspezifische Bereinigung: Korrektur der Daten durch Hintergrundwissen aus dem Fachgebiet, z.b. Adressdaten Domänenunabhängige Bereinigung: Zusammenführung unterschiedlicher Datenmodelle durch Prüfung von Ähnlichkeiten bezüglich der Objekte, z.b. entspricht die Bestellnummer in Schema 1 derjenigen in Schema 2 mit einer gewissen Wahrscheinlichkeit Regelbasierte Bereinigung: automatische, programmgestützte Anpassung von Objekten 26

27 Laden Die Übernahme der Daten unterscheidet zwei Ausprägungen: Initiales Füllen Zyklische Aktualisierung: Komplette Datenübernahme bei jedem Zyklus Übernahme jeweiliger Änderungen inkrementell Auswahl protokollierter Daten 27

28 Laden: Aktualisierung Vollständige Aktualisierung - Full Refresh. Der gesamte Datenbestand der operativen Quellen wird geladen Inkrementelle Aktualisierung - Incremental Refresh Nur die Änderungen der operativen Daten werden geladen. Dabei entstehen zwei Probleme : Erkennen und Identifizieren der Änderungen Einarbeitung der Änderungen in den Datenbestand unter Berücksichtigung historischer Bestände. 28

29 Laden: Aktualisierung 2 Wie aktuell müssen die bereitgestellten Daten sein? Daten des Vormonates, der vergangenen Woche oder von gestern? In welcher Aggregationsform sollen die Daten vorliegen? Von Interesse sind keine einzelnen Aktivitäten, sondern zusammengefasste Vorgänge. 29

30 Analysen, Trends Berichte ETL: Interne/Externe Datenquellen? Einkauf Lager/Bestände Personal Vertrieb Finanzen Interne Informationsressourcen Data Warehouse Externe Informationsressourcen Kunden Lieferanten Markt Wettbewerb 30

31 ETL: Datenquellen und -arten Online Daten- Banken / Internet Operative Verfahren sammeln, filtern, bewerten bereinigen, strukturieren, ergänzen Datenquelle intern extern Marktvolumen, Marktanteile, Verbrauchs- Kennzahlen,... Auftragseingang, Umsatz, Kosten Deckungsbeitrag, Produktivität,... Presse- Meldungen, Patente, Gutachten,... Kundenbesuchs- Berichte, Projektberichte,... quantitativ qualitativ Datenart Nach: Meier, M., Fülleborn, A., Integration, externer Führungsinformationen..., WI 41(1999)5, S 449 ff. 31

32 DW-Architektur im Überblick Δ LH DB TUI Δ MOLAP Δ Δ ROLAP Datenquellen Extraktion Transformation Warehouse-DB Analyse-Schicht Präsentation Metadaten Prozessmanagement Quelle : sd&m 32

33 Meta-Datenverwaltung Meta-Daten sind Daten über Daten Welche Daten liegen im Data Warehouse? In welcher Form existieren sie? Wer ist für die Pflege verantwortlich? Wann fand die letzte Aktualisierung statt? Welche Berichte sind vorgesehen? 33

34 Eigenschaften Subjekt-orientierter Aufbau : Unternehmensdaten nach dem Informationsbedarf des Managements Zeitvariante Daten : Datenprotokollierung über längere Zeiträume Nicht-flüchtige Sammlung von Daten : Aktualisierung der Datenbestände in festgelegten Zeitabständen Integrativer Inhalt : Verbindung entscheidungsrelevanter Daten aus unterschiedlichen operativen Anwendungen 34

35 Gliederung Ausgangssituation : Motiv und Hintergrund Definition und Architektur Operative Systeme vs Data Warehouse OLAP und Beispiel Data Mining 35

36 Vergleich : operativ vs. Data Warehouse 1 Operative Systeme Data Warehouse Die Struktur operativer Systeme ist an der Abwicklung von Geschäftsprozessen orientiert. Sie enthält keine Redundanzen Datenstruktur Detaillierungsgrad Ein Data Warehouse enthält managementrelevante Objekte als Dimension ohne in dritter Normalform vorzuliegen. Operative Systeme enthalten Data Warehouses enthalten detaillierte Daten verdichtete Daten Zeitraumbezug Operative Systeme enthalten aktuelle Daten Data Warehouses bestehen aus historischen, aktuellen und prognostizierten Daten 36

37 Vergleich : operativ vs. Data Warehouse 2 Operative Systeme Data Warehouse Aktualisierungszeitraum Die Daten in einer operativen Die Daten eines Data Warehouses Datenbank sind einer permanenten werden zu vordefinierten Änderung unterlegen Zeitpunkten durch die Extraktionsprogramme aktualisiert Systemlast Die Auslastung operativer Systeme Die Systemlast bei Data Warehouseist bekannt, insbesondere wann Nutzung schwankt stark. Allerdings Spitzenzeiten mit einer Vielzahl von werden nur wenig Transaktionen Transaktionen existieren durchgeführt. Verfügbarkeit Operative Systeme haben einen hohen Anspruch an die Verfügbarkeit Geringe Anforderungen an die Verfügbarkeit. 37

38 Vergleich : operativ vs. Data Warehouse 3 Einfügen Laden Operative Datenbank Data Warehouse Änderung Löschung Ersetzung Zugreifen Daten werden auf Record-Basis bearbeitet Daten werden ins Warehouse geladen und dort zugegriffen. Wenn ein Snapshot gemacht wird, verändern sich die Daten anschließend nicht mehr. 38

39 Vergleich : operative vs. Managementunterstützung Merkmal Datenstruktur Identifikationskriterium Operative DV-Systeme flache, nicht hierarchische Tabellen eindimensional Managementunterstützende Systeme multidimensionale Strukturen mehrdimensional Datenmanipulation zeilenbezogen sichtspezifisch Datenmenge/ Transaktion Betrachtungsebene klein detailliert umfangreich aggregiert Zeithorizont gegenwärtig historisch, gegenwärtig, zukünftig 39

40 Gliederung Ausgangssituation : Motiv und Hintergrund Definition und Architektur Operative Systeme vs Data Warehouse OLAP und Beispiel Data Mining 40

41 12 OLAP-Regeln (nach Codd) Basisregeln 1 Mehrdimensionale Perspektive Intuitive Datenmanipulation Zugriffsmöglichkeiten Datenintegration Ein Bericht sollte durch Slice und Dice per Mausklick veränderbar sein Einfache Navigation durch Drill-up, Drill-down oder Drillthrough Ein Benutzer soll nicht wissen müssen, wo die gerade verwendeten Daten herkommen Ein OLAP-System soll Daten in einem eigenständigen Prozess übernehmen und ein Drill-through gestatten Client/Server Architektur OLAP-Anwendungen werden über ein Netzwerk nach diesem Verteilungsprinzip betrieben, um ressourcenintensive Prozesse auf einem Server auszuführen 41

42 Basisregeln 2 Unterstützung verschiedener Analysemodelle Categorical = historische Daten, Exegetical = interaktive Analyse, Contemplativ = Wenn/dann -Anaylse Formulatic = formelbasierte Analyse Mehrbenutzerfähigkeit Transparenz Es ist ein gleichzeitiger Zugriff mehrerer Benutzer gestattet Daten stammen aus integriertem Datenbestand oder aus heterogenen externen Quellen 42

43 Spezielle Regeln Trennung denormalisierter Daten Trennung Uneingeschränkte Anzahl von Dimensionen Null- und Fehlwerte Daten in OLAP-Datenbanken werden denormalisiert gespeichert OLAP-Daten sind von Produktivdaten getrennt abzulegen OLAP-Datenbanken geben keine Einschränkung bezüglich der Dimension vor Da in einem Datenwürfel nicht jede Zelle gefüllt ist, müssen leere Zellen einen Fehlwert tragen, der nicht den Wert Null besitzt 43

44 Kritik Unscharfe Trennung zwischen fachlich-konzeptionellen Anforderungen und technischer Realisierung Keine Klarheit, ob mehrdimensionale Datensichten ein eigenes Datenmodell benötigen 44

45 Begriffe OLAP = Online Analytical Processing = Analyse und Auswertung von multidimensional aufbereiteten Daten, um Informationen für Unternehmensentscheidungen zu gewinnen OLTP = Online Transaction Processing Die operativen Geschäftsprozesse und IT- Systeme eines Unternehmens MOLAP = Multidimensional OLAP auf Basis einer proprietären, multidimensionalen Datenbank ROLAP = Relational OLAP auf Basis einer relationalen Datenbank Data Mart = spezielle Teildatenmenge eines DW, z.b. für eine bestimmte Abteilung des Unternehmens, ist aufgebaut wie das DW selbst und wird auch mit den gleichen Methoden und Tools ausgewertet. 45

46 OLAP-Werkzeuge Würfel (Cube) als Synonym für OLAP-Datenbanken - 3 Dimensionen (bei 4 oder mehr Dimensionen spricht man von sog. Hybercubes) Individuelle Sicht auf die Daten des Würfels durch Pivotisierung: Daten aus verschiedenen Perspektiven nach verschiedenen Kriterien analysieren Rotation: Vertauschen der Dimensionen Slice and Dice: herausschneiden einzelner Scheiben bzw. Betrachtung kleinerer Teilwürfel 46

47 OLAP-Grundfunktionen Slice (Schneiden): Einschränkung der Anzahl der Dimensionen eines Würfels Dice (Drehen): Vertauschen der Dimensionen eines Würfels und dadurch Drehung Drill-Down (Herunterbrechen): Verfeinerung der Dimesionen des Würfels Drill Through: Durchgriff auf die Daten des Ursprungssystems 47

48 Dimensionen und Fakten 1/3 Fakten entsprechen Kennzahlen, die für eine bestimmte Kombination von Dimensionswerten Gültigkeit haben. Beispiel: Erlös der Produktgruppe Kühlschränke im Monat Dezember 2000 in München Eine typische Abfrage auf einem Data Warehouse-Datenbestand besteht darin, eine oder mehrere Kennzahlen bezüglich einer bestimmten Dimensionskombination darzustellen, wobei bzgl. einiger Dimensionen eingeschränkt wird anderer Dimensionen aufgerissen wird (Zeilen oder Spalten) der restlichen Dimensionen aggregiert wird Quelle : sd&m 48

49 Dimensionen und Fakten 2/3 Dimensionen sind endliche Wertebereiche typische Dimensionen sind Zeit, einzelne Monate oder auch Kalendertage eines definierten Zeitraums Ort, z.b. eine Postadresse aber auch Kategorien, z.b. Produktgruppe: Kühlgeräte, Fernseher,... Werttyp: Plan, Ist, Soll Dimensionen sind häufig hierarchisch organisiert (Tag -> Monat -> Quartal -> Jahr) und können auch noch weitere Merkmale haben (Kalenderwoche, Wochentag, Feiertag) Quelle : sd&m 49

50 Dimensionen und Fakten 3/3 Eine Kennzahl ist aggregierbar bezüglich einer Dimension, wenn es eine fachlich sinnvolle (kommutative und assoziative) Aggregationsfunktion gibt (zumeist Summe, gelegentlich auch Mittelwertbildung). Beispiel: Der Umsatz einer Firma ist bezüglich der Dimensionen Zeit, Verkaufsorganisation und Verkaufsort sinnvoll aggregierbar durch Summenbildung. Der Kundenbestand ist durch Summierung zwar bezüglich der Verkaufsorganisation aggregierbar, nicht jedoch bezüglich der Zeitdimension; hier ist eine Mittelwertbildung sinnvoll Entsprechend verdichtete Ergebnisse heißen Aggregate. Die Abbildung der Aggregationsfunktionen werden bei einem relationalen Data Warehouse in SQL- Statements formuliert, die Berechnung leistet die Datenbank. Quelle : sd&m 50

51 Beispiel Produkt Region Branche Dimensions-Relation Produkt-Nr Filial-Nr Kunden-Nr Datum Anzahl Umsatz Ost West Nord Region PKW PC Kaffee Fahrzeuge Elektronik Lebensmittel Produktgruppe Branche Quelle für folgende Beispiele : Prof. E. Rahm 51

52 Mehrdimensionale Datensicht Hierarchische Dimensionierung PKW Region Zeit PC Jahr Kaffee Bundesland 1Q 2Q 3Q Fahrzeuge Elektronik Lebensmittel Branche Ort Quartal Monat Woche Zeit Tag 52

53 Multidimensionale Daten Fakt/Kennzahl (z.b. Absatz) Region Produkt Produkt Region Quartal Absatz Radio Hessen Quartal Radio Radio Hessen Hessen Radio Hessen Radio Bayern Dimensionen Radio Radio Bayern Bayern Radio Bayern

54 Relational vs. Multidimensional Bestellnr Region Branche Zeit Menge 1406 Ost Fahrzeug 2Q West Elektronik 1Q 58 PKW 7829 Nord Fahrzeug 2Q 30 PC 5327 Ost Lebensmittel 3Q 300 Kaffee Nord Ost Lebensmittel Elektronik 1Q 3Q Q 2Q 3Q Fahrzeuge Elektronik Lebensmittel Branche Zeit Relation : Untermenge des Kreuzproduktes aller Wertebereiche Multidimensional : Kreuzprodukte aller Wertebereiche mit aggregiertem Wert pro Kombination 54

55 Multidimensionale Strukturen Unterschiedliche Ebenen der Datendarstellung nach Informationsbedürfnis und organisatorischer Stellung Zeit Produkt Ort 55

56 OLAP am Beispiel: Navigation in einem 3D-Würfel Gebietsleiter: Alle Produkte und Monate für ein Gebiet Produktmanager: Alle Gebiete und Monate für ein Produkt Umsatz Umsatz Produkt Produkt Gebiet Gebiet Umsatz Finanzmanager: Alle Produkte und Gebiete für einen Monat Monat Geschäftsleitung: Alle Produkte und Gebiete für alle Monate Umsatz Umsatz 56

57 Navigation in multidimensionalen Daten 3 Kosten/Erlöse Erlös Fracht Einkaufspreis 2 Plan / Ist Plan Ist Gebiete Nord West Süd 46 Jan Feb Mar Slicing 5 Perioden Kühlgeräte Fernseher Videorecorder Drill Down, Roll up Kühlschrank Gefrierschr. Minibar Dicing 1 Produktgruppen 14 Produkte Quelle : sd&m 57

58 Multidimensionale OLAP (MOLAP) Speicherung in multidimensionaler Datenbank (genauer Aufbau ist Geheimnis des Herstellers) auf einem speziellen Server Alle möglichen Aggregate sind vorberechnet! Aufbau der multidimensionalen Datenbank (also Einladen der Grunddaten und Berechnung der Aggregate) kann mehrere Stunden in Anspruch nehmen insgesamt derzeit geringere Datenmengen speicherbar als beim ROLAP- Ansatz Zugriff auf den Würfel ist extrem schnell, da keine Berechnungen mehr nötig. Dafür muss der Würfel regelmäßig berechnet werden. Werkzeuge (Server): Oracle-Express-Server, Hyperion-Essbase, Cognos PowerPlay, u.a. Quelle : sd&m 58

59 Relationales OLAP (ROLAP) Speicherung in relationaler Datenbank (Stern- oder Snow-Flake Schema) Die Ergebnismenge wird in der Datenbank berechnet und zum Client bzw. Server übertragen. Größe ist beschränkt, Würfel aber schnell modifiziert und neu erstellt Anwender stellt die Abfragen mit grafischer Oberfläche zusammen, Tools generieren die SQL-Zugriffe auf die Datenbank Berechnung der Ergebnisse bei jedem Zugriff auf die Datenbank, kann je nach Datenmenge mehrere Minuten in Anspruch nehmen Werkzeuge (Clients): Business Objects, insight, Crystal Info u.a Quelle : sd&m 59

60 MOLAP oder ROLAP? MOLAP / Multidimensionale DB + Optimiert für den OLAP-Analyse (Zugriff auf Schichten im multidimensionalen Würfel.) + Sehr schnell und Benutzerfreundlich Keine standardisierten Zugriffsmethoden (proprietäre Datenhaltung) und Programmierschnittstellen i.a. komplexere Architektur als bei ROLAP Würfel müssen vorberechnet werden ROLAP / Relationale DB (Abbildung des mehrdimensionalen Würfels durch "Stern-Schema ) + Große Datenmengen möglich ( > 100 GB) + Gut für Standardreporting + offenes System langsam bei uneingeschränkten OLAP-Analysen Quelle : sd&m 60

61 Relationale Modellierung Die relationale Modellierung favorisiert zwei Vorschlaäge Star-Schema Snowflake-Schema Beide berücksichtigen Fakten und Dimensionen Star-Schema: für jede Dimension wird eine Tabelle eingerichtet. Diese Tabellen sind nicht miteinander verknüpft, sondern stehen nur mit der Faktentabelle über die Primärschlüssel in Beziehung. Snowflake-Schema: normalisiertes Star-Schema, um keine redundanten Einträge in den Dimensionstabellen zu haben; allerdings steigt die Anzahl der Tabellenverknüpfungen über Joins 61

62 Star-Schema - Aufbau Hauptkomponenten des Star-Schemas sind so genannten Fakttabellen und Dimensionstabellen, wobei die Dimensionstabellen sternförmig um die Fakttabellen mittels Primary-Key / Foreign-Key Beziehungen angeordnet sind 62

63 Star-Schema - Beispiel 1 Denormalisierte Dimensionstabellen Kunde Zeit Kunden-Nr Kundenname Beruf Alter Produkt Produkt-Nr Produktname Produktgruppe Branche Hersteller Farbe Preis Verkauf Kunden-Nr Produkt-Nr Datum Filiale Anzahl Umsatz Zentrale Tabelle und eine Tabelle pro Dimension Datum Tag Monat Quartal Jahr Filialen Filialname Ort Land Region 63

64 Star-Schema - Beispiel 2 Zeit Zeit-Nr. Quartal-Nr. Quartalsname Datum Monat-Nr. Monatsname Tag-Nr. Wochentag Saison Kunde Kunden-Nr. Key Account-Nr. Key Account-Name Kundenname Kundentyp Branche Verkauf Orts-ID Zeit-Nr. Kunden-Nr. Produkt-Nr. Umsatz Menge Sitz Orts-ID Region-Nr. Regionalleiter Länder-Nr. PLZ Ort Produkt Produkt-Nr. Produktname Spartename Spartenleiter Produktlinien-Nr. Produktlinie Produktlinienleiter Farbe Modell-Nr. 64

65 Snowflake-Schema Beispiel 1 PGruppe Kunde Kunden-Nr Kundenname Beruf Alter Produktgruppe Branche Produkt Produkt-Nr Produktname Produktgruppe Hersteller Farbe Preis Normalisierte Dimensionstabellen Verkauf Kunden-Nr Produkt-Nr Datum Filiale Anzahl Umsatz Zeit Datum Tag Monat Jahr Filialen Filialname Ort Explizite Darstellung der Dimensionshierarchie MonatQ Monat Quartal OrtL Ort Land LandR Land Region 65

66 Snowflake-Schema Beispiel 2 Region Region-Nr. Regionalleiter Land Länder-Nr. Länder-Name Lager PLZ Lagerort Lagerleiter Kundenattribute Kunden-Nr. Kundenname Kundentyp Branche Sitz Orts-ID Region-Nr. Länder-Nr. PLZ Produkt Produkt-Nr. Farbe Modell-Nr. Kunde Kunden-Nr. Key Account-Nr. Verkauf Orts-ID Zeit-Nr. Kunden-Nr. Produkt-Nr. Umsatz Menge Produkt Produkt-Nr. Produktlinien-Nr. Sparten-Nr. Key Account Key Account-Nr. Key Account-Name Zeit Zeit-Nr. Jahr-Nr. Quartal-Nr. M onat-nr. Tag-Nr. Produktlinie Sparte Produktlinien-N r. Sparten-Nr. Produktlinienleiter Spartename Spartenleiter Quartal Quartal-Nr. Quartalsname Monat Monat-Nr. Monatsname Tag Tag-Nr. Wochentag Saison 66

67 Snowflake-Schema - Aufbau Das Snowflake-Schema besteht ebenfalls aus den beiden Komponenten Faktentabelle und Dimensionstabelle. Die Dimensionstabellen werden jedoch im Gegensatz zum Star-Schema normalisiert. Durch die Normalisierung entstehen zusätzliche Tabellen. Vorteil dieses Schemas ist die Vermeidung der redundanten Datenhaltung und somit die Einsparung von Speicherplatz. Nachteil dagegen ist die komplexere Modellstruktur und zusätzlich notwendige Tabellen-Joins, die wiederum die Abfrage-Performance verschlechtern 67

68 Gliederung Ausgangssituation : Motiv und Hintergrund Definition und Architektur Operative Systeme vs Data Warehouse OLAP und Beispiel Data Mining 68

69 Data Mining: Motiv 69

70 Data Mining 1 Data Data Mining Miningversucht auf auf der der Basis Basis der der vorhandenen Daten Daten eine eine Mustererkennung, Segmentierung und und Faktorenanalyse, um um die die Faktoren zu zu identifizieren, die die signifikanten Einfluss auf auf die die Kenngrößen des des Unternehmens besitzen. Für Für Erfolgsindikatoren wie wie Rentabilität, Marktanteil oder oder Kundenbindung wird wird analysiert, welche welche Kräfte Kräfte diese diese beeinflussen, so so dass dass ein ein vollständiges Bild Bild der der Ursache-Wirkung-Beziehungen entsteht. 70

71 Data Mining 2 Data Data Mining Miningbezeichnet einen einen mehrstufigen Prozess, in in dem dem bisher bisher unbekannte aber aber wichtige Zusammenhänge, Muster Muster und und Trends Trends durch durch gezieltes Aufbereiten und und Auswerten großer großer Datenmengen entdeckt werden. 71

72 Data-Mining-Verfahren Musterkennung Clusteranalyse Segmentierung Musterbeschreibung Statistische Verfahren Assoziation - Warenkorbanalyse 72

73 Data Mining : Nutzung Hypothesen- Testing Wie läuft die Produktion Wie entwickelt sich meine Abteilung? Wo steht aktuell VB Maier? Entdecken Berichten, veröffentlichen verteilen & durchsehen Leistungsbemessung Ad-hoc- Anfragen Soll ich den Vertrieb unterstützen? Welche Abhängigkeiten zwischen Produkten gibt es? Analyse Verifizieren Erkennen von Zusammenhängen 73

74 Zusammenfassung Problem : Integration heterogener Datenbestände und Bereinigung der Primärdaten Anforderungen Große Datenvolumina Multidimensionale Auswertung Temporäre Anfragen Notwendigkeit neuer Aggregate Spezielle Indexstrukturen Parallele Anfrageverarbeitung

75 Web-Links Data Warehousing on the WWW Ralph Kimballs Homepage OLAP Council Die Informationweek besitzt einen sehr interessanten Data Warehousing-Bereich The Data Warehousing Information Center Data Warehouse Institute: Hier gibt es eine gute Sammlung von technischen Whitepapers von verschiedenen Tool- Anbieter Marktanalysen. The OLAP Report: Interessante und hilfreiche Echte Fundgrube für Whitepapers, Produktbesprechungen und Auflistung von Anbietern für Spezialthemen. Whitepapers und ausführliche Produktbeschreibung vieler OLAP-Werkzeuge. 75

76 76