Business Intelligence

1. Multi- dimensionale Analyse

2. Konsistenz der Datenlogistik

Data Warehousing ist kein Produkt, sondern der Prozess der Zusammen-führung und des Managements von Daten aus verschiedenen Quellen mit dem Zweck, eine einheitliche, detaillierte Sicht auf einen einzelnen Geschäftsbereich oder das gesamte Unternehmen zu erhalten. [Gartner]

Logische Beschreibung der im Data Dictionary des Data Warehouse zusammengefassten Daten (Kern des Data Warehouse).

Zumindest drei Arten von Metadaten (Daten von Daten):

Daten für Generierung (Build Process): Datenquelle, Verantwortlicher...

Kontrolldaten (Build-/Runtime Process): letzter Aktualisierungszeitpunkt, Zugriffsrechte ... 

Anwenderinformationen für die Nutzung (Runtime Process): Daten-struktur im Data Warehouse, Semantik und Integrität der Daten, Berech-nungsregeln ...

• Enterprise Data Warehouse (EDW) Dutzende von operati-ven Systemen mit großem Datenvolumen integriert werden müssen, ist es sowohl aus Machbarkeits- als auch aus Performancegründen zweck-mäßig, das Data Warehouse in kleinere Einheiten, Data Marts, zu zerlegen.

• Data Marts sind auf einzelne Unternehmensbereiche speziali-sierte kleine Data Warehouses. Sie können einen redundanten Daten-ausschnitt des EDW beinhalten und müssen in bezug auf Gesamtkonzept und Metadaten dem EDW entsprechen, weil sonst dessen Eigenschaft, „single point of truth“ zu sein, aufgegeben wird.

• verbreitete Praxis, EDW-Projekte mit ausgewählten Data Marts zu beginnen. Später gehen sie im EDW auf oder werden diesem nachgeordnet, wenn sie ihren abgehobenen Status beibehalten.

Extraktion, Transformation und Laden der Daten für das DWH

Die Outputschnittstelle muss vor allem den Auswertungsbedürfnissen der Endnutzer Rechnung tragen, die von Standardberichten bis hin zu ursa-chenforschenden Ad-hoc-Anfragen eine große Bandbreite haben. In die-sem Zusammenhang gewinnt OLAP (Online Analytical Processing), eine Softwarelösung für die multidimensionale Analyse, eine Schlüsselfunk-tion. OLAP wurde von E. F. CODD, dem Begründer der Relationentheo-rie, ausgearbeitet.

Unter Metadaten ("Daten über Daten") versteht man strukturierte Daten, mit deren Hilfe eine Informationsressource beschrieben und dadurch besser auffindbar gemacht wird.

Metadaten liefern Grundinformationen über ein Dokument, wie z.B. Angaben über Autor, Titel oder Zeitpunkt der Veröffentlichung, und reproduzieren damit im Prinzip genau das, was an Erschließungsarbeit in den Bibliotheken seit jeher geleistet wurde. Vgl.: Metatags, XML, Resource Description Framework (RDF) Semantic Web

ist die Grundlage für die Einrichtung einer unternehmensweiten Datenarchitektur, die Governance und Compliance berücksichtigt.

ist ein von der Object Management Group (OMG) entwickelter Standard für Beschreibung, Zugriff und Austausch von im Data-Warehouse-Prozess anfallenden Metadaten.

Er soll Interoperabilität zwischen verschiedenen Data-Warehouse-Systemen und -Werk-zeugen ermöglichen.

Mithilfe des CWM lassen sich beispielsweise die im ETL-Prozess verwendeten Datenschemata von Quell- und Zieldatenbanken und die zwischen diesen stattfindenden Transformationen beschreiben.

Es erlaubt zudem die Definition von Abbildungsvorschriften zwischen dem physischen Modell eines Data Warehouse und den darauf aufsetzenden logischen Modellen wie etwa dem eines OLAP-Werkzeuges.

Das Common Warehouse Metamodel nutzt die Unified Modeling Language (UML) als Notationssprache und Kern des eigenen Metamodells.

Erstellte Metadaten-Beschreibungen lassen sich mit der XML-Sprache XML Metadata Interchange (XMI) austauschen oder können über den Zwischenschritt einer Interface Definition Language (IDL) verschiedenen Programmiersprachen zugänglich gemacht werden.

"Metadata is the data warehouse's Gordian knot, and Alexander and his sword are nowhere in sight." Kimball et al., 1998

• Prüfung der Datenqualität (durch ETL bereinigt)
• Datenintegration
• fachliche Harmonisierung (subjekt orientiert)
• Datenbereinigung (ETL Prozess)
• Historisierung und Archivierung von Dateb
• Zugriffsschutz Berechtigungen
• Nachvollziehbarkeit Dokumentation
• Reproduzierbare Berichte
• Kapselung (Konsistenz, Wiederverwendung)
• Qualitätssicherung für fachliche Logik
• Datenschutz (Anonymisierung, Pseudonymisierung)
• Einheitliche Kennzahlen

• Im ETL-Prozess werden die Daten aus den heterogenen Datenquellen integriert, aufbereitet und im DWH für Auswertungen zur Verfügung gestellt.

• Dem eigentlichen ETL-Prozess geht häufig ein Data Profiling voraus, das der Datenbereinigung zur Sicherung einer hohen Datenqualität dient (z.B. EVOKE)

• ETL (in Verbindung mit Data Profiling) sichert hohe Datenqualität TDQM Exkurs "Datenqualität". 50 % der DWH-Projekte scheitern vor allem wegen mangelnder Datenqualität: garbage in garbage out.

•ETL kann 50 bis 80 % der Aufwendungen eines DWH-Projekts beanspruchen.

•ETL ist eine datenorientierte Middleware Exkurs "Middleware"

intermediärer Pufferspeicher

mit besonderer Bedeutung für den ODS (Operational Data Store)

Definitionsphase

• Analyse und Dokumentation der Quellsysteme Datenkatalog

•Bestimmung der operativen Daten für die Extraktion

•Aufstellung der Transformationsregeln

•Definition der Laderoutinen

•Dokumentation im Metadaten-Repository

Ausführungsphase

Staging Area: Arbeitsbereich, Zwischenspeicher für einzelne ETL-Schritte

Monitoring

ETL-Komponente zur Beobachtung der operativen Quellen im Hinblick auf die Aktualisierung des DWH (neue Zeitscheibe!)

Es gibt einen Monitor für jede Datenquelle und jeweils verschiedene Verfahren: Schnappschuss-Vergleich, Trigger-, Replikations- und zeitstempel-basierte Verfahren sowie Log- oder Protokolldateianalyse

Extraction

Dieser Teilprozess integriert die heterogenen operativen Quelldatenbestände, d.h. es werden nach Vorschrift der Metadaten einzelne Datenbereiche aus verschiedenen Quellsystemen extrahiert und auf der Staging Area abgelegt.

Transformation

Im Bereich der Staging Area finden die Transformationen und Anpassungen der extrahierten Daten unter Maßgabe der Anforderungen des DWH, d.h. der in den Metadaten festgelegten Regeln statt:

Datenmigration: einheitliches Datenformat der extrahierten Daten nach den Festlegungen der Metadaten

Datenbereinigung: Reinigung der Rohdaten von fehlerhaften, nicht relevanten, unbekannten, redundanten, veralteten oder fehlenden Werten. (Data Cleansing)

Anpassungen Anpassung der Quelldaten an das DWH-Modell (Schemaintegration)

Loading

Übernahme der Daten aus der Staging Area in das DWH, zumeist über Bulk-Loader:

- Komplett-Loading (Erstbefüllung) - inkrementelles Loading gemäß Historienkonzept des DWH

siehe Grafik

Die Analyse- und Auswertungstools greifen direkt auf das integrierte Data Ware-house zu. Dazu muss es folgenden spezifischen Anforderungen gerecht werden:

• Integration aller funktionell notwendigen Daten und Datenstrukturen in das unternehmensweite EDW,

• Berücksichtigung von Restriktionen der eingesetzten Softwaretools zur Ana-lyse und Auswertung im Hinblick auf den zu integrierenden Teil des Daten-modells,

• Bereitstellung eines Höchstmaßes an Abfrageperformance (incl. Tuning durch zusätzliche Indizierungs- bzw. Partitionierungsstrategien).

Das EDW gilt als theoretische Idealvariante, die aus Zeit- und Kostengründen in der Regel erst nach einer Reihe von funktionell ausgerichteten Projektphasen verwirklicht wird, in denen Data Marts eine besondere Bedeutung erlangen.

Die Integration einer Vielzahl von heterogenen Basisdaten der vorhandenen Quellsysteme unter der gleichzeitigen Beachtung einer hohen Abfrageperform-ance gehört zu den Hauptschwierigkeiten bei der Bewältigung von Data Ware-house-Projekten.

Hilfreich ist hierbei eine Grobstrukturierung der Anwendungs-systeme und deren Basisdaten.

Im Ergebnis dieser Strukturierung werden nur die Anwendungssysteme dem Data Warehouse zugeordnet, deren inhaltli-che/funktionelle Relevanz nachgewiesen wurde.

Andere Anwendungssystem-klassen können über weniger aufwendige Integratoren zusammengefasst und im Falle begründeter Auswertungserfordernisse über geeignete Schnittstellen dem DWH verfügbar gemacht werden.

Die Hub & Spoke-Architektur schließt die Verwendung von Data Marts aus-drücklich ein. Werden diese Data Marts jedoch ohne Rückgriff auf ein Gesamt-konzept für das später herauszubildende EDW als Insellösungen nebeneinander implementiert, wird das Desaster der "Verhüttelung" der Daten" (ZEMANEK) auf eine höhere Ebene verlagert.

siehe Grafik

Die auf einer übergreifenden Data Warehouse-Plattform beruhende Koexistenz-architektur von Data Mart(s) und DWH wird in der aktuellen Data Warehouse-Praxis trotz eintretender Redundanz- und Aufwandserhöhungen für Datenlade-vorgänge favorisiert, weil

• aus dem Data Warehouse herausgelöste funktionelle Bereiche durch Da-tenaufbereitungen z. B. im Sinne von Aggregationen im Interesse der zu er-wartenden Auswertungen einen Performance-Gewinn bewirken,

• die Koexistenzarchitektur einen idealen Mix zwischen Bottom-Up- und Top-Down-Ansatz vermittelt, der es auf der Grundlage eines Data Warehouse-Konzepts gestattet, die Implementierung mit praktikablen Data Marts zu be-ginnen, die später im Data Warehouse aufgehen oder mit ihm gekoppelt werden,

• Logik und Stringenz des Data Warehouse-Modells nicht der temporären Unfähigkeit von Softwaretools, die das bestehende Modell nicht realisieren können, zum Opfer fallen dürfen. Diese häufig nur temporären Kollisionen werden dadurch behoben, dass die kollidierenden Modellausschnitte via Data Mart(s) angepasst werden.

INMON schlägt für das Data Warehouse eine erweiterte Ebenenarchitektur vor. Danach ist das Enterprise (Atomic) Data Warehouse Grundlage für ein Depart-ment Data Warehouse und das wiederum für ein Individual Data Warehouse.

Während das Enterprise Data Warehouse alle Daten mit geringster Granularität spei-chert, orientiert sich das Department Data Warehouse an benutzergruppenspezifischen Fragestellungen. Ferner können die Daten bereits in einem verdichteten Zustand gehal-ten werden. Schließlich stellen die Individual Data Warehouses die benutzerspezifi-schen Auswertungsbereiche dar. Die beiden letztgenannten Data Warehouse-Ebenen sind auf Grund ihrer Spezifika auch als Data Marts zu verstehen.

hybride, noch transaktionsorientierte System-struktur zwischen operativen Applikationen und dem eigentlichen Data Warehouse (DWH), um Realtime-Zugriff auf integrierte Daten der Ba-sissysteme zu ermöglichen

ausgelagertes DWH für die performante statisti-sche und heuristische Analyse

kostenoptimierte Archivsysteme (≠ on-line!), um Pbyte-Volumina (z.B. Boeing, AT&T) zu realisieren

Dabei unterscheidet Inmon beim Alternative Storage zwischen :

• Secondary Storage: langsamerer, weniger teurer Disk based Speicher

• Near-line Storage: "storage where data is stored on tape based silos or optical devices"

• Operational Data Store ermöglicht eal-Time-Zugriff auf die operativen Quellsysteme
• Architekturkomponente, welches zwischen den operativen Quellsystemen und dem eigentlichen Data Warehouse liegt.
• Daten aus den Quellsystemen werden zeitnah im ODS zusammengeführt sind veränderbar (volatil) ( im Gegensatz Data Warehouse, das jeweils Momentaufnahmen (Snapshots) der Unternehmenssituation speiche

häufig diskutierte Frage: Oob der ODS Bestandteil der operativen Quellsysteme oder des Data Warehouse ist, wird in der Version 2.0B des SAP BW (Business Information Warehouse) im Anwendungsinteresse nach beiden Richtungen hin gelöst

• im ETL-Prozess extrahierten Daten der Quellsysteme ohne Integrationsmaßnahmen zwischengespeichert
• stehen aber im Bedarfsfalle den Auswertungssystemen zur Verfügung
• beim Übergang von der PSA in den ODS werden Maßnahmen des Data Cleansing und integrative Transformationen durchgeführt.
• ODS-Daten sind atomar und zeitnah

Die Aufnahme des ODS in die Data Warehouse-Architektur bedeutet eine qualitative Erweiterung im Anwenderinteresse. Vor allem dem Reporting werden durch die Einbeziehung atomarer Daten neue Dimensionen erschlossen.

• 85 % aller Daten in produktiven Datenbanken sind inaktiv. [Forrester Research]

• Analyse von DataVard 2013: Daten in InfoCubes nur 7 … 11 % der Systemgröße als Gegenargument zu in-Memory-Computing

• Meinung Oracle: Da nur 5 bis 20 Prozent aller Daten wirklich heiß sind, ist eine mehrschichtige Speicherhierarchie sinnvoll. [isreport 10/2013; 5/2014]

Herausragende Merkmale:

• Data-Warehouse-Strukturierung entsprechend dem Lebenszyklus der Daten

• Enterprise Metadaten Repository (EMR)

• Data Warehouse für strukturierte und unstrukturierte (80% !) Daten

• Data Warehouse als Bestandteil einer übergeordneten SOA-Architektur

Ein logisch zusammengehöriger Datenbestand, der einem einheitlichen konzeptuellen Schema genügt, ist physisch auf mehrere Rechner verteilt.

homogene Datenbanken

Eine föderierte Datenbank (federated data base system) setzt sich aus mehreren unabhängig entworfenen, autonomen Datenbanken zusammen.

heterogene Datenbanken

• Das Idealziel Bill Inmons, heterogene Datenquellen eines Unternehmens im Data Warehouse (DWH) so zu integrieren, dass es zum "single point of truth" der Datenwelt wird, ist durch die Unternehmenspraxis längst unterlaufen worden. Es ist keine Seltenheit, dass sich in größeren Unternehmen 20 und mehr DWHs im parallelen Einsatz befinden.
• Der Federated Data Warehouse (FDWH) Approach unterstützt die iterative Entwicklung eines DWH-Systems unter Einbeziehung mehrerer unabhängiger DWHs, Data Marts und Operational Data Stores vor allem durch eine Shared Information Staging Area.

zukunftstaugliche Datenarchitektur auf zwei Säulen.

• Integrated Data Warehouse

• Discovery Platform

UDA wird das klassische Data Warehouse um eine „Discovery Platform" ergänzt

Nutzer ermöglicht, neues Wissen aus Big Data zu generieren, um dadurch signifikante Innovations- und Wettbewerbsvorteile zu erzielen.

Einsatz von Spitzentechnologien im Umfeld von Hadoop und In-Memory-Computing

• Kennziffern werden als Fakten, Beschreibungen der Fakten als Dimensionen modelliert und implementiert.

• Datenmodellierung der Cubes als Star- und Snowflake-Schemata

Beispiel für eine dreidimensionale Hierarchie in der Produktion

• Produktionsjahr-Produktionsquartal-Produktionswoche

• Regionen-Großhändler-Einzelhändler

• Systeme-Baugruppen-Einzelteile

Beispiel für eine zehndimensionale Hierarchie im Einzelhandel

• Geschäftsbereich-Abteilung-Klasse-Produkt

• Region-Gebiet-Bezirk-Filiale

• Jahr-Quartal-Monat-Datum

• Bundesland-Ort-PLZ

Beispiel für eine dreißigdimensionale Hierarchie im Versicherungswesen

• Kunde-Police

• Firma-Police

• Deckungssumme-Deckung-Deckungsmultiplikator-Vertragsdetail

• Risikotyp-Police

• Zahlungsweise-Police

• Deckungsstatus-Police

• Finanzzuständigkeit-Police

• Vertragstyp-Police

• Vertragslaufzeit-Police

• Rate-Police

Ein System für die Produktion oder den Einzelhandel kann leicht 20 oder dreißig Dimensionen haben, und ebenso kann ein einfaches System für das Versicherungswesen nur einige wenige Dimensionen besitzen.