TDWI Europe 2010 Munich

Transkript

1 TDWI Europe 2010 Munich Architektur und Modellierung für das Enterprise Data Warehouse W2A Mittwoch, 16. Juni :00 bis 11:30 & 12:00 bis 13:15 Dr. Michael Hahne Dr. Michael Hahne 2010 W2A / 1

2 Agenda Motivation Konzeptionelle Modellierung des Reporting Layers Zeitabhängigkeit im Reporting Layer am Beispiel Star Schema Staging und Core Data Warehouse Modellierung Architektur für Enterprise Data Warehousing W2A / 2

3 Agenda Motivation Konzeptionelle Modellierung des Reporting Layers Zeitabhängigkeit im Reporting Layer am Beispiel Star Schema Staging und Core Data Warehouse Modellierung Architektur für Enterprise Data Warehousing W2A / 3

4 Typische Data Warehouse Probleme We Can t Meet our Batch Windows KPI und Berichtsbereitstellung Backup derdatenbank Neuaufbau im Data Warehouse Our Costs are Spiraling Storage / Hardware / Replikation Rechenzentrumsbetrieb (Raum / Energie / Klimatechnik) Datenadministration The Targets Keep Changing Neue Geschäftsanforderungen Spezifische Projektanforderungen Externe Anforderungen / Audit / Innenrevision W2A / 4

5 Information as Corporate Asset We Do not Know What we not Know... The Known Current BI implementations are set up to answer known requirements The Unknown Little or nothing is done to be prepared for unpredictable future information needs W2A / 5

6 Aktuelles DW-Architektur-Konzept Endbenutzer- werkzeuge Data Abfrage- und Mining Berichtssysteme Executive - OLAP- Information Systeme Frontend Data Warehouse Metadaten- banksystem Data Mart Data Mart OLAP Server Enterprise Data Zentrale Warehouse/ Operational Datenbasis Data Store ETL-System Archivierungs- system Externe Daten Operative Vorsysteme W2A / 6

7 Agenda Motivation Konzeptionelle Modellierung des Reporting Layers Zeitabhängigkeit im Reporting Layer am Beispiel Star Schema Staging und Core Data Warehouse Modellierung Architektur für Enterprise Data Warehousing W2A / 7

8 Semantische Data Mart Modellierung mit ADAPT Application Design for Analytical Processing Technologies W2A / 8

9 ADAPT Modelliermethode Entwickelt von Dan Bulos, Symmetry Corporation Unahängig von Technologie und Architektur auf semantischer Modellierebene zur Modellierung von OLAP Systemen Zielsetzung Kommunikation (mit Fachanwender) Konzeptionelles Framework Frühe Problemidentifikation Verbesserte Qualität Grundlage für Entwicklung Folgt dem OLAP Paradigma Einfach und leicht verständlich Kein Case Tool Umfasst Konstrukte zur Abbildung von Cubes, Dimensionen und Beziehungen W2A / 9

10 ADAPT: Grundobjekte W2A / 10

11 Objekte der Dimensionsmodellierung in ADAPT Dimension Model Hierarchy { } Member { } Level { } Scope Attribute W2A / 11

12 ADAPT: Dimensionsobjekte in der Übersicht W2A / 12

13 Einfache Dimensionselemente W2A / 13

14 Elementbestimmte Dimension Szenario { } Ist { } Plan { } Abweichung Ist - Plan W2A / 14

15 ADAPT: Erweiterte Dimensionsobjekte W2A / 15

16 Dimension Scope Definiert eine Menge von Dimensionselementen Ist eine Teilmenge der übergeordneten Menge von Elementen (z.b. Dimension oder ein anderer Scope) Sind hilfreich zur Modellierung von Ausnahmen W2A / 16

17 Beispiele für Attribute Attribute können an der Dimension, an einer Ebene oder an einem Scope hängen W2A / 17

18 Ebenenbestimmte Dimension Produkt Produkthierarchie { } Warenhauptgruppe { } Warengruppe { } Warenuntergruppe { } Hersteller { } Produkt Bezeichnung { } Eigene Produkte { } Fremdprodukte Verpackungsart Herstellerhierarchie Verpackungsgröße Gewicht Anzahl auf einer Palette W2A / 18

19 Beziehungstypen in ADAPT (Domain Relationships) Fully exclusive Fully overlapping Partially exclusive Partially overlapping W2A / 19

20 Weitere Einsatzmöglichkeiten von Beziehungen Ebene Region hat USA und Europe Alle States sind entweder Continental oder Other Continental States verdichten sich zu Area Other States verdichten sich zu Region USA W2A / 20

21 Mit und ohne Domain Relationships W2A / 21

22 Attribute auf unterschiedlichen Ebenen Eine Organisationsdimension mit einer Hierarchie mit drei Ebenen: Region (top level) National Sales Organization (middle) Sales office (bottom) Ebene Region hat drei Elemente: APAC Europe NA Alle Elemente aller Ebenen haben Einen Manager Eine Adresse Jede national Sales Org hat Eine Currency W2A / 22

23 Totale Verdichtung In diesem Beispiel gibt es keinen All Years Knoten Wird in ADAPT durch den Pfeil vom Hierarchiesymbol zu der obersten Ebene verdeutlicht W2A / 23

24 Implizite Totale Verdichtung In diesem Fall gibt es implizit definiertes Element All Families als totale Verdichtung Dies wird in ADAPT durch den Doppelpfeil von der obersten Ebene zum Hierarchiesymbol dargestellt W2A / 24

25 Explizite Totale Verdichtung All als Präfix für die Top-Ebene weist auf die totale Verdichtung hin Optional kann in ADAPT das Top-Element auch über eine Domain Relationship modelliert werden (exclusive full set) W2A / 25

26 Unbalancierte Hierarchien W2A / 26

27 Parallele Hierarchien mit gemeinsamer Ebene Gemeinsam genutzte Ebenen sind meistens die Top-Ebene Werden in verschiedenen Hierarchien der gleichen Dimension genutzt W2A / 27

28 Hierarchien mit Verzweigungen Ein Hierarchiezweig ist ein Teil der Hierarchie, der von einem Knoten bis zur granularen Ebene geht Hilfreich ist, das Element oder den Scope am Eingang in den Zweig explizit zu modellieren W2A / 28

29 Spezielle Form der Verzweigung Eine Unit berichtet entweder an eine Area oder an ein Department, aber nicht an beides Ausgedrückt durch die einzelne gemeinsame Linie von Unit zur nächst höheren Ebene W2A / 29

30 Cube Shape in ADAPT Ein Cube hat immer eine Kennzahlen-Dimension Die meisten haben auch eine Zeitdimension Cubes gruppieren Kennzahlen gleicher Dimensionierung und gleicher Granularität W2A / 30

31 Cube-Modellierung Kennzahl Zeit { } Kosten { } { } Jahr Quartal Controlling Zeit Kostenstelle Kostenart Szenario Kennzahl { } Kostenstelle Kostenstellen- Hierarchie Kostenstelle Kalenderhierarchie Kostenstellenverantwortlicher { } Monat Szenario Kostenart { } Ist { } Plan Kostenarten- Hierarchie { } Abweichung { } Kostenart Ist - Plan W2A / 31

32 Cube Modifiers Ein Cube nutzt nicht immer die vollständige conformed dimension Mit Modifiers kann die Granularität und Dimensionsteilmenge des Cubes festgelegt werden {M} filtert Member {L} filtert Level {H} filtert Hierarchy {S} filtert Scope -Bereich x inkl. der Parents und Childs ; mehrere Subsets Cube Modifiers: Erweiterung von ADAPT, die Nippur (NL) entwickelt hat W2A / 32

33 Beispiel für Cube Modifiers Alle Elemente der Organisationshierarchie deren Organisation in der Menge Factories ist Nur Elemente des Scope Factories W2A / 33

34 Beispiel für Plandaten W2A / 34

35 Weiteres Beispiel W2A / 35

36 Mehrere Cubes oder einen Cube? Trade-Off: Viele Cube-Übergreifende Operationen vs. sparse Cubes W2A / 36

37 ADAPT: Weitere Objekte der Modellierung W2A / 37

38 Agenda Motivation Konzeptionelle Modellierung des Reporting Layers Zeitabhängigkeit im Reporting Layer am Beispiel Star Schema Staging und Core Data Warehouse Modellierung Architektur für Enterprise Data Warehousing W2A / 38

39 Zeitabhängigkeit: Strukturelle Veränderungen in Dimensionen PG 1 PG 2 Strukturveränderungen PG 1 PG 2 P 1 P 2 P 3 P 4 P 5 P 4 gelöscht P 6 hinzugefügt P 3 verändert P 1 P 2 P 3 P 5 P 6 W2A / 39

40 Zeitabhängigkeit: Implizierte Schemaveränderung PG 2 PG 1 PG 2 Schemaveränderungen PUG 1 PUG 2 P 1 P 2 P 3 P 5 P 6 P 1 P 2 P 3 P 5 P 6 W2A / 40

41 Anforderungen des Berichtswesens Mögliche Anforderungen: Berichte nach aktueller Struktur Berichte nach definierter historischer Struktur (Zeitpunkt) Berichte gemäß historischer Wahrheit (Transaktionsorientierte Sicht der Bewegungsdaten) Bericht vergleichbarer Resultate (Zeitintervall) W2A / 41

42 Beispiel für Slowly Changing Dimensions Produktdimension in Produkt P A P B P C P D Produkt P A P B P C P D P E Produktgruppe PG X PG X PG Y PG Y Produktdimension in Produktgruppe PG X PG Y (geändert) PG Y PG Y PG Y (neu) Produkt P A P B P C P D P A P B P C P D P E Fakten-Tabelle Periode Umsatz W2A / 42

43 Berichtsanforderungen -Szenarien Berichtsszenario aktuelle Struktur Produktgruppe PG X PG Y Umsatz Umsatz Berichtsszenario alte Struktur Produktgruppe PG X PG Y Umsatz Umsatz Berichtsszenario historische Wahrheit Produktgruppe PG X PG Y Umsatz Umsatz Berichtsszenario vergleichbare Resultate Produktgruppe PG X PG Y Umsatz Umsatz W2A / 43

44 Szenario I : Bericht mit aktueller Struktur Produktdimension in Fakten-Tabelle Produkt Produktgruppe Produkt Periode Umsatz P A P B P C P D P E PG X PG Y (geändert) PG Y PG Y PG Y (neu) P A P B P C P D P A P B P C P D P E Produktgruppe PG X PG Y Umsatz Umsatz W2A / 44

45 Szenario II : Bericht mit alter Struktur Fakten-Tabelle Produktdimension in Produkt Periode Umsatz Produkt P A P B P C P D Produktgruppe PG X PG X PG Y PG Y P A P B P C P D P A P B P C P D P E Produktgruppe PG X PG Y Umsatz Umsatz W2A / 45

46 Szenario III : Bericht nach historischer Wahrheit Produktdimension in Produkt P A P B P C P D Produkt P A P B P C P D P E Produktgruppe PG X PG X PG Y PG Y Produktdimension in Produktgruppe PG X PG Y (geändert) PG Y PG Y PG Y (neu) Produkt P A P B P C P D P A P B P C P D P E Fakten-Tabelle Periode Umsatz Produktgruppe PG X PG Y Umsatz Umsatz W2A / 46

47 Szenario IV : Bericht mit vergleichbaren Resultaten Produktdimension in Produkt P A P B P C P D Produkt P A P B P C P D P E Produktgruppe PG X PG X PG Y PG Y Produktdimension in Produktgruppe PG X PG Y (geändert) PG Y PG Y PG Y (neu) Produkt P A P B P C P D P A P B P C P D P E Fakten-Tabelle Periode Umsatz Produktgruppe PG X PG Y Umsatz Umsatz W2A / 47

48 Lösungsalternativen bei Strukturbrüchen Anpassung des historischen Datenmaterials an neue Strukturen Vorteile: Keine Aufblähung des Datenbestandes; Datenstrukturen bleiben überschaubar Nachteile: Alte Strukturen sind verloren; Anwender wollen u. U. Berichte mit alten Strukturen Separate Speicherung des historischen Datenbestandes zusätzlich zum Komplettbestand mit neuen Strukturen Vorteile: Alte Auswertungen können abgerufen werden Nachteile: Datenvolumen; aufwendige Aktualisierung, wenn Anwender auch neue Zahlen in den alten Strukturen sehen wollen; verwirrend für Endbenutzer Aufbau paralleler Hierarchien mit alten/neuen Strukturen Vorteile: Alle Zahlen können mit Stammdaten basierten Strukturen angezeigt werden Nachteile: Dimensionsstruktur kaum überschaubar Temporale Datenbanken - Gültigkeitsstempel Vorteile: Alle Zahlen können mit beliebigen Strukturen angezeigt werden Nachteile: Performance-Impact W2A / 48

49 Varianten der Berücksichtigung von Strukturänderungen as is Szenario as of & as is Szenario as posted Szenario as posted & as is Szenario as posted & as of & as is Szenario W2A / 49

50 as is Szenario: Update-Verfahren Produkt_Id SKU Produkt Gruppe Einfach zu implementieren AB6 AX3 PA600 PAX300 High Fidelity High Fidelity Stellt keine Historie von Attributsausprägungen zur Verfügung 103 AX4 PAX450 Consumer Electronic Einfachster Fall Unterstützt nur as is Szenarien Produkt_Id SKU Produkt Gruppe Meistens ausreichend AB6 AX3 PA600 PAX300 High Fidelity High Fidelity Empfehlung für nur as is 102 AX3 PAX300 Consumer Electronic 103 AX4 PAX450 Consumer Electronic W2A / 50

51 as is & quasi as of : Mehrere Attributspalten Geringfügig größerer Speicherbedarf in Dimensionstabellen Stellt historische Version ohne Zeitzuordnung zur Verfügung Produkt_Id SKU AB6 AX3 AX4 Produkt PA600 PAX300 PAX450 Gruppe High Fidelity High Fidelity Consumer Electronic Alte Gruppe High Fidelity High Fidelity Consumer Electronic Unterstützt Auswertungen aktueller Daten mit historischer Gruppierung und umgekehrt Produkt_Id SKU Produkt Gruppe Alte Gruppe Entspricht paralleler Hierarchie 101 AB6 PA600 High Fidelity High Fidelity 102 AX3 PAX300 Consumer Electronic High Fidelity 103 AX4 PAX450 Consumer Electronic Consumer Electronic W2A / 51

52 as is & as of Szenario: Versionierung ohne Datum Produkt_Id Version SKU Produkt Gruppe Etwas größerer Speicherbedarf in Dimensionstabellen AB6 AX3 PA600 PAX300 High Fidelity High Fidelity Benötigt unbedingt künstliche Dimensionsschlüssel AX4 PAX450 Consumer Electronic Stellt historische Versionen ohne Zeitzuordnung zur Verfügung Produkt_Id Version SKU Produkt Gruppe Die neue Gruppierung führt zu einer neuen Ausprägung in der Dimensionstabelle Unterstützt keine Auswertungen aktueller Daten mit historischer Gruppierung und umgekehrt AB6 AX3 AX3 AX4 PA600 PAX300 PAX300 PAX450 High Fidelity High Fidelity Consumer Electronic Consumer Electronic W2A / 52

53 as is & as of Szenario: Gültigkeitsstempel Etwas größerer Speicherbedarf in Dimensionstabellen Benötigt zusätzlich künstlichen oder zusammen gesetzten Dimensionsschlüssel Die neue Gruppierung führt zu einer neuen Ausprägung in der Dimensionstabelle Produkt_Id Fakten Unterstützt Auswertungen aktueller Daten mit historischer Gruppierung u. umgekehrt 103 Empfehlung für as is mit as of Produkt_AId Produkt_Id GültigVon GültigBis SKU Produkt Gruppe AB6 PA600 High Fidelity AX3 PAX300 High Fidelity AX3 PAX300 Consumer Electronic AX4 PAX450 Consumer Electronic W2A / 53

54 Implementierung des as posted Szenarios Etwas größerer Speicherbedarf in Dimensionstabellen Benötigt unbedingt künstliche Dimensionsschlüssel Stellt historische Versionen zum Transaktionszeitpunkt zur Verfügung Die neue Gruppierung führt zu einer neuen Ausprägung in der Dimensionstabelle Produkt_AId Fakten Unterstützt keine Auswertungen aktueller Daten mit historischer Gruppierung oder umgekehrt Empfehlung für nur as posted Produkt_AId Produkt_Id Version SKU Produkt Gruppe AB6 PA600 High Fidelity AX3 PAX300 High Fidelity AX3 PAX300 Consumer Electronic AX4 PAX450 Consumer Electronic W2A / 54

55 as posted & as of & as is Szenario: Snapshot-Verfahren Faktentabelle Deutlich größerer Speicherbedarf in Faktentabelle und in Dimensionstabellen Jede Aktualisierung der Dimensionstabelle fügt sämtliche Datensätze an die Tabelle an Ermöglicht vollständige Historisierung: as is über join Produkt_Id und Filter Curr as of über join Produkt_Id und Filter Loaddate as posted über join Loaddate und Produkt_Id Produkt_Id Current-Flag in Dimensionstabelle definiert aktuelle Zuordnung Ladedatum bzw. Zeitstempel muss in Dimensions- und Faktentabelle in Schlüssel aufgenommen werden Schlechte Performance (join!) Bei kleinen Dimensionen und für as * empfehlenswert Dimensionstabelle Curr Produkt_Id SKU AB6 AX3 AX4 AB6 AX3 AX4 Produkt PA600 PAX300 PAX450 PA600 PAX300 PAX450 DimX xx xx xx xx Fact Gruppe High Fidelity High Fidelity Consumer Electronic High Fidelity Consumer Electronic Consumer Electronic Loaddate Loaddate W2A / 55

56 as posted & as of & as is Szenario: Snapshot-Variante Delta-Historisierung Faktentabelle Größerer Speicherbedarf in Dimensionstabellen Jede Aktualisierung der Dimensionstabelle fügt verwendete Datensätze an die Tabelle an Current-Flag in Dimensionstabelle definiert aktuelle Zuordnung Ladedatum bzw. Zeitstempel muss in Dimensionsund Faktentabelle in Schlüssel aufgenommen werden Schlechtere Performance (join!) Empfehlenswert für alle Szenarien, wenn as posted Attribute unbekannt Produkt_Id Curr SKU Produkt Gruppe Produkt_Id Loaddate DimX Fact Loaddate xx xx xx xx Dimensionstabelle GueltigVon GueltigBis AB6 PA600 High Fidelity AX3 PAX300 High Fidelity AX3 PAX300 Consumer Electronic AX4 PAX450 Consumer Electronic W2A / 56

57 as posted & as of & as is Szenario: Mehrere Fremdschlüssel und Gültigkeitsstempel Etwas größerer Speicherbedarf in Dimensionstabellen Benötigt zusätzlich künstliche Dimensionsschlüssel Stellt historische Versionen auch zum Transaktionszeitpunkt zur Verfügung Die neue Gruppierung führt zu einer neuen Ausprägung in der Dimensionstabelle Unterstützt Auswertungen aktueller Daten mit historischer Gruppierung u. umgekehrt Produkt_AId Produkt_Id Fakten Empfehlung für alle Szenarien, wenn as posted Attribute bekannt Produkt_AId Produkt_Id GültigVon GültigBis SKU Produkt Gruppe AB6 PA600 High Fidelity AX3 PAX300 High Fidelity AX3 PAX300 Consumer Electronic AX4 PAX450 Consumer Electronic W2A / 57

58 Agenda Motivation Konzeptionelle Modellierung des Reporting Layers Zeitabhängigkeit im Reporting Layer am Beispiel Star Schema Staging und Core Data Warehouse Modellierung Architektur für Enterprise Data Warehousing W2A / 58

59 Enterprise Data Warehousing: Aktuelles Architektur-Konzept Endbenutzer- werkzeuge Data Abfrage- und Mining Berichtssysteme Executive - OLAP- Information Systeme Frontend Data Warehouse Metadaten- banksystem Data Mart Data Mart OLAP Server Enterprise Data Zentrale Warehouse/ Operational Datenbasis Data Store ETL-System Archivierungs- system Externe Daten Operative Vorsysteme W2A / 59

60 Speichersegmente des Data Warehouse Data Warehouse Enterprise Data Warehouse Operational Data Store Zentrale Staging Datenbasis Area ETL-System v Externe Daten Operative Vorsysteme W2A / 60

61 Staging Area Temporäre Zwischenspeicherung extrahierter Rohdaten vor der Integration Dauerhafte Speicherung der Extraktionshistorie im Coporate Staging Memory Kein direkter Zugriff der Endbenutzer für Analysen Plattform für Datentransformationen zur Entlastung von Quelldatenbanken und Data Warehouse Staging Area W2A / 61

62 Datenfluss im Staging Prozess Stagingtabelle Stagingtabelle Stagingtabelle Staging Area (Acquisition Layer) Stagingtabelle Stagingtabelle Stagingtabelle Corporate Staging Memory Lieferung Lieferung Lieferung Datenquelle Datenquelle Datenquelle ETL Metadaten: Was, Wann, Von, Nach W2A / 62

63 Staging Area im relationalen DBMS Lieferung ID Feld 1 Feld n 1907 Stagingtabelle Lieferung ID Feld 1 Feld n Stagingtabelle Corporate Staging Memory Lieferung Lieferung ID Feld 1 Feld n ETL Metadaten: Was, Wann, Von, Nach Lieferung ID Was Wann Datenquelle Feld 1 Feld n Liefergruppe ID Lieferung ID Wann W2A / 63

64 Operational Data Store Integrierte Detaildaten ggf. bis auf Belegebene für operatives Reporting I. d. R. keine allzu lange Historie Operational Data Store Ggf. Datenquelle für das Enterprise Data Warehouse Klassische relationale Datenablage (3. Normalform) W2A / 64

65 Enterprise Data Warehouse Verdichtete Daten (z. B. Tagesbasis) Enterprise Data Warehouse Lange Historie (> 5 Jahre) Großes Datenvolumen (u. U. > TB) Unternehmens- bzw. konzernweit ausgerichtet Nicht unbedingt denormalisiert, oftmals rein relational (Normalform) SPOT: Single Point of thetruth Entspricht Core Data Warehouse W2A / 65

66 Transformation und Integration im EDW Stammdaten Bewegungsdaten Transformationsprozess Stammdaten Lieferung Bewegungsdaten Lieferung ETL Metadaten: Was, Wann, Wie, Wohin, Woher Stagingtabelle Stagingtabelle Stagingtabelle Staging Area (Acquisition Layer) W2A / 66

67 Historisierung und Deltahandling für das EDW EDW-Tabelle EDW-Tabelle EDW-Tabelle Enterprise Data Warehouse (Integration Layer) EDW-Tabelle EDW-Tabelle EDW-Tabelle Corporate Memory Historisierung von Stammdaten Deltahandling Bewegungsdaten Stammdaten Lieferung Stammdaten Lieferung Bewegungsdaten Lieferung ETL Metadaten: Was, Wann, Wie, Wohin, Woher W2A / 67

68 Stammdaten und Bewegungsdaten im Core Warehouse Stammdatentabelle im EDW (FG = Fachlich gültig; TG = Technisch gültig): Lief ID Dim ID Blatt ID FG Von FG Bis TG Von TG Bis SKU Produkt AB6 PA AX3 PAX AX3 PAX AX3 PAX AX4 PAX450 Bewegungsdatentabelle im EDW: Lief ID Feld Fakten Zum Beispiel: -Auftrag Kopfdaten -Auftrag Positionsdaten -Faktura Kopfdaten -Faktura Positionsdaten -Lieferung Kopfdaten -Lieferung Positionsdaten W2A / 68

69 Konzeptionelle Multi-Layer Architektur Reporting / Analysis Reporting layer Operational Data Store Integration layer Corporate Memory Acquisition layer Corporate Staging Memory Source systems W2A / 69

70 Nutzung des EDW: Data Marts on Demand Data Mart Data Mart Data Marts (Reporting Layer) Aggregation Aggregation EDW-Tabelle EDW-Tabelle EDW-Tabelle Enterprise Data Warehouse (Integration Layer) EDW-Tabelle EDW-Tabelle EDW-Tabelle Corporate Memory W2A / 70

71 Agenda Motivation Konzeptionelle Modellierung des Reporting Layers Zeitabhängigkeit im Reporting Layer am Beispiel Star Schema Staging und Core Data Warehouse Modellierung Architektur für Enterprise Data Warehousing W2A / 71

72 Datenwachstum W2A / 72

73 Herausforderungen IT W2A / 73

74 Typische Data Warehouse Probleme We Can t Meet our Batch Windows KPI und Berichtsbereitstellung Backup derdatenbank Neuaufbau im Data Warehouse Our Costs are Spiraling Storage / Hardware / Replikation Rechenzentrumsbetrieb (Raum / Energie / Klimatechnik) Datenadministration The Targets Keep Changing Neue Geschäftsanforderungen Spezifische Projektanforderungen Externe Anforderungen / Audit / Innenrevision W2A / 74

75 Ausgaben für Storage (Platten, Bandsysteme, Netzwerk, Administration) wachsen jährlich um 15% bis 20%, obwohl die Speicherkosten um 30% jährlich sinken Ref.: McKinsey W2A / 75

76 Speicherkosten W2A / 76

77 Herausforderung fürs Data Warehouse With projected compounded annual growth rates for databases exceeding 125%, organizations face two basic options: 1) Continue to grow the infrastructure (e.g., server size, storage capacity) OR 2) Develop processes [and architectures] to separate dormant [archive-ready] data from active data. Meta Group Report Databases on a Diet W2A / 77

78 Historie der BI-Systeme Unterstützungsgrad bei Managementaufgaben MIS EIS DSS MSS Data Warehouse Executive Information Systems EDW On-Line Analytical Processing Decision Support Systems Management Information Systems Zeit W2A / 78

79 Data Warehouse-Konzept Data Warehouse (DW) = A subject oriented, integrated, nonvolatile, time variant collection of data organized to support management needs W. H. Inmon, Building the Data Warehouse, New York u. a. 1993, S. 29. subject oriented Themenorientierung integrated Vereinheitlichung nonvolatile Dauerhaftigkeit, Stabilität time variant Zeitorientierung der Informationen management needs Analyse und Entscheidungsunterstützung W2A / 79

80 Data Warehouse MSS Data Warehouse Operative Unternehmensdaten Operative Informationssysteme umfasst die Serverkomponenten einer Systemlösung, die für die unternehmensweite Datenversorgung der Front-End-Systeme zur Informationsbereitstellung und Entscheidungsunterstützung betrieblicher Fach- und Führungskräfte zuständig sind, ist physikalisch von den operativen Vorsystemen getrennt und baut lediglich zum Zweck der periodischen Datenaktualisierung bzw. -ergänzung Verbindungen zu den operativen DV-Systemen auf. W2A / 80

81 Aktuelles DW-Architektur-Konzept Endbenutzer- werkzeuge Data Abfrage- und Mining Berichtssysteme Executive - OLAP- Information Systeme Frontend Data Warehouse Metadaten- banksystem Data Mart Data Mart OLAP Server Enterprise Data Zentrale Warehouse/ Operational Datenbasis Data Store ETL-System Archivierungs- system Externe Daten Operative Vorsysteme W2A / 81

82 Bill Inmon s Enterprise Data Warehousing Concept Departmental Data Marts Acctg Marketing Finance Sales DSS Applications ERP ERP ERP ETL CRM Changed Data Staging Area EDW ecomm. Bus. Int. ERP Corporate Applications local ODS Global ODS Oper. Mart Granularity Manager Exploration warehouse/ data mining Cross media Storage Management Session Analysis Near line Storage Internet Dialogue Manager Cookie Cognition Preformatted dialogues Web Logs Archives Source:Bill Inmon W2A / 82

83 Datenzugriff vs. Datenwachstum Typisches Datenwachstum Typischer Datenzugriff vs. Datenwachstum Mit zunehmendem Datenwachstum ändert sich die Zugriffswahrscheinlichkeit signifikant W2A / 83

84 Information Lifecycle Management mit Near-Line Storage Online Datenbank Near Line Speicherung Daten Archivierung Häufiger Datenzugriff Updates Wenig Datenzugriff Kaum Datenzugriff W2A / 84

85 Bill Inmon s Meinung zu Performance Problemen im Kontext Near-Line Storage Indeed, leaving infrequently accessed data on disk storage greatly HURTS performance [] because mixing infrequently used data with actively used data is like adding lots of cholesterol into the blood stream. Information Lifecycle Management for Data Warehousing: Matching Technology to Reality By W.H. Inmon (2005) W2A / 85

86 Information Lifecycle Management (ILM) W2A / 86

87 Motivation für ein EDW Konzept Anticipating the unknown Datenwachstum Zunehmende Anzahl an Applikationen Dies führt zu Steigenden administrativen Kosten Höheres Ausfallrisiko von Anwendungen Gefahr eines Totalausfalls Ohne EDW Konzept Administrative Kosten Mit EDW Konzept Anzahl Applikationen / Datenvolumen W2A / 87

88 Konzeptionelle Multi-Layer Architektur Reporting / Analysis Reporting layer Operational Data Store Aggregation Acquisition layer Integration layer Transformation Corporate Memory Corporate Staging Memory Nearline Storage Source systems W2A / 88

89 Weitere Informationen Die zweite Auflage erscheint in Kürze! Sowie unter: W2A / 89

90 Kontakt Hahne Consulting GmbH Dr. Michael Hahne Geschäftsführer / Managing Director fon: fax: michael@hahneconsulting.de W2A / 90