Successfully reported this slideshow.
<ul><li>Arno Tigges, Seniorberater </li></ul><ul><li>OPITZ CONSULTING München GmbH </li></ul>Durchgängige Business Intelli...
Agenda <ul><li>Hintergrund Was sind die aktuellen Anforderungen an DWH/BI? </li></ul><ul><li>Praktikable DWH Referenzarchi...
<ul><li>1 </li></ul>Hintergrund
Aktuelle Anforderungen an Business Intelligence <ul><li>Aktuelle Geschäftsprozesse haben die Erwartungen an Business Intel...
„ Die Zwei“ Modellierungsansätze <ul><li>Ralph Kimbal </li></ul><ul><ul><li>Dimensionales Modell mit Stars und Snowflakes ...
Typische Probleme und Lösungsansätze <ul><li>Probleme: </li></ul><ul><li>Ein DWH ist kompliziert und nur langwierig einzuf...
<ul><li>2 </li></ul>Praktikable DWH-Referenzarchitektur
Referenzarchitektur <ul><li>Die Referenzarchitektur … </li></ul><ul><ul><li>…  ist nichts „Neues“. </li></ul></ul><ul><ul>...
Hauptkomponenten der Architektur Security Informations-Quellen Quellen Informations-Management Data Warehouse BI- / EPM-To...
Details der Architektur Security Quellen Staging Layer Foundation Layer Access + Perfor-mance Layer unstrukturierte Daten ...
Datenbewirtschaftung Security Quellen Staging Layer Foundation Layer Access + Perfor-mance Layer unstrukturierte Daten Per...
<ul><li>3 </li></ul>Einbindung in die Gesamtarchitektur
Informationsbereitstellung <ul><li>Jede BI-Anwendung kann auf alle Daten jedes Layers zugreifen. </li></ul><ul><li>1. Wahl...
Informationsbereitstellung Security Quellen Staging Layer Foundation Layer Access + Perfor-mance Layer unstrukturierte Dat...
Bidirektionale Integration <ul><li>Gewonnene Informationen fließen direkt zurück </li></ul><ul><ul><li>BI-Tools erzeugen n...
Entwicklung und Einführung neuer Reportinganforderungen <ul><li>Iterativ-inkrementelles Vorgehen </li></ul><ul><ul><li>Um ...
Entwicklung und Einführung neuer Reportinganforderungen <ul><li>Iterativ-inkrementelles Vorgehen mit der Referenzarchitekt...
<ul><li>4 </li></ul>Fazit
Fazit Anforderung Vereinfachung durch Referenzarchitektur (Near-)Real-Time DataWarehouse  durch die prinzipielle Architekt...
Fragen und Antworten
Kontakt <ul><li>OPITZ CONSULTING München GmbH Weltenburger Straße 4  81677 München Tel. +49 89 680098-1467 [email_address]...
Nächste SlideShare
Wird geladen in …5
×

Das modulare DWH-Modell - DOAG SIG BI/DWH 2010 - OPITZ CONSULTING - ArnoTigges

3.388 Aufrufe

Veröffentlicht am

Der Vortrag beschreibt die Architektur eines serviceorientierten, modular erweiterbaren DWH-Modells und dem dazu gehörigen Berichtswesens. Er soll außerdem zeigen, wie ein solches Modell in ein bereits existierendes, stark heterogenes Umfeld eingebunden werden kann.
Die verschiedenen Schichten des DWH-Modells sowie die Einbindung in das Umfeld werden dabei detailliert beschrieben. Auf die Vor- und Nachteile der verschiedenen Modellierungsmöglichkeiten (3NF, Stern, Cube), sowie Aspekte der zukünftigen Erweiterung und Veränderung wird ebenfalls eingegangen. Eine kurze Übersicht über Tuning und Sicherheitsaspekte beendet den ersten Teil.
Der zweite Teil besteht aus einer Übersicht über die Einbindung des Berichtswesens in die Gesamtarchitektur. Verschiedene Ansatzmöglichkeiten für die Bedienung der Anforderungen verschiedener Nutzergruppen werden erarbeitet. Zuletzt werden Ideen zur Konsolidierung und Ablösung eines stark zerklüfteten, sich widersprechenden Berichtswesens gegeben.
Der Vortrag soll damit DWH-Architekten Möglichkeiten aufzeigen, wie man ein DWH zukunftssicher und flexibel modellieren und in ein heterogenes Umfeld einbetten kann. OPITZ CONSULTING Berater Arno Tigges hielt diesen Vortrag am 29.06.2010 bei der DOAG SIG BI/DWH in Köln.

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Das modulare DWH-Modell - DOAG SIG BI/DWH 2010 - OPITZ CONSULTING - ArnoTigges

  1. 1. <ul><li>Arno Tigges, Seniorberater </li></ul><ul><li>OPITZ CONSULTING München GmbH </li></ul>Durchgängige Business Intelligence durch eine praktikable DWH-Referenzarchitektur <ul><li>DOAG SIG DWH/BI, Köln, 29. Juni 2010 </li></ul>Das modulare DWH Modell
  2. 2. Agenda <ul><li>Hintergrund Was sind die aktuellen Anforderungen an DWH/BI? </li></ul><ul><li>Praktikable DWH Referenzarchitektur Wie wird man den aktuellen Anforderungen gerecht? </li></ul><ul><li>Einbindung in die Gesamtarchitektur Wie führe ich eine DWH/BI-Lösung durchgängig ein? </li></ul><ul><li>Fazit </li></ul>
  3. 3. <ul><li>1 </li></ul>Hintergrund
  4. 4. Aktuelle Anforderungen an Business Intelligence <ul><li>Aktuelle Geschäftsprozesse haben die Erwartungen an Business Intelligence deutlich gesteigert </li></ul><ul><ul><li>(Near-)Real-Time Data Warehouse </li></ul></ul><ul><ul><li>durchgängige, also unternehmensweite Business Intelligence </li></ul></ul><ul><ul><li>sowohl tiefere als auch breitere Analysemöglichkeiten </li></ul></ul><ul><ul><li>Verarbeitung von immer größeren Datenmengen </li></ul></ul><ul><ul><li>perfekte Datenqualität und ein echter „Single Point of Truth“ </li></ul></ul><ul><ul><li>unstrukturierte Datenquellen </li></ul></ul><ul><ul><li>Compliance and Corporate Governance </li></ul></ul><ul><ul><li>stets flexible Anpassungsmöglichkeiten und Zukunftssicherheit </li></ul></ul>
  5. 5. „ Die Zwei“ Modellierungsansätze <ul><li>Ralph Kimbal </li></ul><ul><ul><li>Dimensionales Modell mit Stars und Snowflakes </li></ul></ul><ul><ul><li>vereinfachtes „denormalisiertes“ Datenmodell </li></ul></ul><ul><ul><li>auf das Abfragen von Daten ausgerichtet </li></ul></ul><ul><li>Barry Devlin / Bill Inmon </li></ul><ul><ul><li>„ der Teufel liegt im Detail“, also stets größtmögliche Detailtiefe </li></ul></ul><ul><ul><li>normalisiertes 3NF-Datenmodell </li></ul></ul><ul><ul><li>auf das Datenmanagement ausgerichtet </li></ul></ul>Vorteil Nachteil Kimbal <ul><li>einfache Navigation (Drills) </li></ul><ul><li>schnelle Datenzugriffe </li></ul><ul><li>eingeschränkte Analysemöglichkeiten </li></ul><ul><li>nötige Anpassungen u. U. sehr komplex </li></ul>Devlin Inmon <ul><li>effektives Datenmanagement </li></ul><ul><li>kein Verlust von Detailtiefe oder Historisierung </li></ul><ul><li>Performance oft problematisch </li></ul><ul><li>komplexe 3NF-Strukturen für Anwender </li></ul>
  6. 6. Typische Probleme und Lösungsansätze <ul><li>Probleme: </li></ul><ul><li>Ein DWH ist kompliziert und nur langwierig einzuführen … (… und nutzt am Ende ja sowieso nur einigen wenigen.) </li></ul><ul><li>Selbst kleinere Änderungen im DWH sind sehr kompliziert … (… bei größeren Änderungen fängt man besser gleich von vorne an.) </li></ul><ul><li>Es entstehen mehrere kleinere Insel-Lösungen ... (… die untereinander nicht einmal abgleichbar sind: Multiple Points of Non-Truth) </li></ul><ul><li>Lösungen: </li></ul><ul><li>„ Think Big – Start Small“ Iterativ-inkrementelles VGM </li></ul><ul><li>Durchgängiges Metadatenmanagement und geeignete Tools </li></ul><ul><li>Enterprise DWH-Projekte für durchgängiges BI </li></ul>
  7. 7. <ul><li>2 </li></ul>Praktikable DWH-Referenzarchitektur
  8. 8. Referenzarchitektur <ul><li>Die Referenzarchitektur … </li></ul><ul><ul><li>… ist nichts „Neues“. </li></ul></ul><ul><ul><li>… ist aber mit aktuellen technologischen Möglichkeiten besser umsetzbar. </li></ul></ul><ul><ul><li>… ist keine konkrete Anleitung. </li></ul></ul><ul><ul><li>… ist geeignet als Leitfaden für eine neu zu implementierende Architektur. </li></ul></ul><ul><ul><li>… kann auch als Roadmap für Änderungen vorhandener Architekturen dienen. </li></ul></ul><ul><ul><li>… kann vollständig oder nur in Teilen umgesetzt werden. </li></ul></ul>
  9. 9. Hauptkomponenten der Architektur Security Informations-Quellen Quellen Informations-Management Data Warehouse BI- / EPM-Tools Informations-Zugriff ETL, Messaging und Metadaten <ul><li>Design: </li></ul><ul><li>Das Farbschema ist im Design als „OC 2009“ hinterlegt. </li></ul><ul><li>Ebenso sind die Schriftarten als „OC 2009“ hinterlegt. </li></ul><ul><li>Die Standardfarben sind: </li></ul>
  10. 10. Details der Architektur Security Quellen Staging Layer Foundation Layer Access + Perfor-mance Layer unstrukturierte Daten Performance Management Apps Master-Daten Standard BI-Applikationen temporäre Daten zurück-gewiesene Daten prozess-neutrales Daten-model in 3NF eingebettete Data Marts MVs, AWs, CTAS Analyse Sandkasten BI-App-Daten ETL, Messaging und Metadaten BI Abstraction and Query Generation operative Daten Advanced Analysis Tools Alerts, Dashboards, Reports, Queries Web Services
  11. 11. Datenbewirtschaftung Security Quellen Staging Layer Foundation Layer Access + Perfor-mance Layer unstrukturierte Daten Performance Management Apps Master-Daten Standard BI-Applikationen temporäre Daten zurück-gewiesene Daten prozess-neutrales Daten-model in 3NF eingebettete Data Marts MVs, AWs, CTAS Analyse Sandkasten BI-App-Daten ETL, Messaging und Metadaten BI Abstraction and Query Generation operative Daten Advanced Analysis Tools Alerts, Dashboards, Reports, Queries Web Services
  12. 12. <ul><li>3 </li></ul>Einbindung in die Gesamtarchitektur
  13. 13. Informationsbereitstellung <ul><li>Jede BI-Anwendung kann auf alle Daten jedes Layers zugreifen. </li></ul><ul><li>1. Wahl: Daten über den „BI Abstraction“-Provider beziehen. (Also z. B. aus dem Oracle BI Server) </li></ul><ul><li>2. Wahl: BI-Tools dürfen direkt auf Foundation, Stage oder Quelle zugreifen. </li></ul><ul><li>Ergebnis: </li></ul><ul><li>Es können alle Report- und Analyse-Anforderungen flexibel und schnell mit dem DWH-Modell zur Verfügung gestellt werden. </li></ul><ul><li>Alles was an Informationen im DWH vorhanden ist, wird auch genutzt. </li></ul><ul><li>Es werden keine „Insellösungen“ provoziert. </li></ul>
  14. 14. Informationsbereitstellung Security Quellen Staging Layer Foundation Layer Access + Perfor-mance Layer unstrukturierte Daten Performance Management Apps Master Daten Standard BI-Applikationen temporäre Daten zurück-gewiesene Daten Prozess-neutrales Daten-model in 3NF eingebettete Data Marts MVs, AWs, CTAS Analyse Sandkasten BI-App-Daten ETL, Messaging und Metadaten BI Abstraction and Query Generation operative Daten Advanced Analysis Tools Alerts, Dashboards, Reports, Queries Web Services
  15. 15. Bidirektionale Integration <ul><li>Gewonnene Informationen fließen direkt zurück </li></ul><ul><ul><li>BI-Tools erzeugen neue Daten. </li></ul></ul><ul><ul><li>Auch der „Analyse-Sandkasten“ dient experimentellem Data Mining und erzeugt Daten. </li></ul></ul><ul><ul><li>Gewonnene Daten müssen bewahrt werden, um den Mehrwert zu sichern. </li></ul></ul><ul><ul><li>Diese fließen entweder direkt in das Staging Layer … </li></ul></ul><ul><ul><li>… oder zunächst in die Quelle und dann über die ETL Strecke zurück ins Data Warehouse. </li></ul></ul><ul><li>Datenqualität verbessern </li></ul><ul><ul><li>Ergebnisse von Auswertungen können auch zur Verbesserung der Datenqualität genutzt werden. </li></ul></ul><ul><ul><li>Die Web-Service-Schnittstelle kann z. B. von MDM-Lösungen genutzt werden. </li></ul></ul>
  16. 16. Entwicklung und Einführung neuer Reportinganforderungen <ul><li>Iterativ-inkrementelles Vorgehen </li></ul><ul><ul><li>Um eine neue Anforderung zu realisieren, fehlen meistens die nötigen Daten im Warehouse. </li></ul></ul><ul><ul><li>Oft müssen diese zunächst integriert werden, </li></ul></ul><ul><ul><li>erst dann können konkrete Anforderungen definiert werden. </li></ul></ul><ul><ul><li>Mit iterativ-inkrementellem Vorgehen nähert man sich schrittweise dem Ziel. </li></ul></ul>PM, tCM, RM Ergebnis der Iteration 1. Analyse 2. Design 3. Qualitätsdefinition 4. Lösungs- Implemen- tierung 5. Qualitätsmessung, Lieferung
  17. 17. Entwicklung und Einführung neuer Reportinganforderungen <ul><li>Iterativ-inkrementelles Vorgehen mit der Referenzarchitektur </li></ul><ul><ul><li>Während des Designs greift der Report über den BI Abstraction Provider (evtl. sogar ausschließlich) auf die Quellsysteme durch </li></ul></ul><ul><ul><li>Sobald die Anforderungen verstanden sind, werden die Daten sukzessive in die DWH Layer integriert </li></ul></ul><ul><ul><li>Der Report selber muss nicht adaptiert werden, sondern nur die Metadaten müssen angepasst werden </li></ul></ul><ul><li>Ergebnis: schnellere Lieferung der Ergebnisse </li></ul>
  18. 18. <ul><li>4 </li></ul>Fazit
  19. 19. Fazit Anforderung Vereinfachung durch Referenzarchitektur (Near-)Real-Time DataWarehouse durch die prinzipielle Architektur u. neue Technologien durchgängiges, also unternehmensweites BI durch schnelle Umsetzung von Anforderungen und Vermeidung von Insellösungen sowohl tiefere als auch breitere Analysemöglichkeiten durch Balance zwischen „Kimball“ und „Devlin/Inmon“-Ansätzen Verarbeitung von immer größeren Datenmengen durch Lifecycle Management und Redundanzfreiheit im 3NF Foundation Layer perfekte Datenqualität und ein echten „Single Point of Truth“ durch Integration aller Data-Marts unstrukturierte Datenquellen durch die prinzipielle Architektur u. neue Technologien Compliance and Corporate Governance durch das übergreifende Security-Konzept und die Historisierungsmöglichkeiten im 3NF Stets flexible Anpassungs-möglichkeiten und Zukunfts-sicherheit durch einfache Integration, Datenzugriff auf alle Layer und Anpassungsfähigkeit bzgl. Nutzung verschiedener Tools
  20. 20. Fragen und Antworten
  21. 21. Kontakt <ul><li>OPITZ CONSULTING München GmbH Weltenburger Straße 4 81677 München Tel. +49 89 680098-1467 [email_address] </li></ul><ul><li>Besuchen Sie uns im Internet: www.opitz-consulting.com </li></ul>Quellen: „ Enabling Pervasive BI through a Practical Data Warehouse Reference Architecture“ An Oracle Whitepaper, February 2010 http://www.oracle.com/us/solutions/datawarehousing/058925.pdf <ul><li>Arno Tigges </li></ul><ul><ul><li>Project Manager </li></ul></ul>

×