Business & Competitive Intelligence Systems - Data Warehousing

Data Warehousing & OLAP

Einführung

Business Intelligence
’Business Intelligence is the use of information that enables organisations to best decide, measure, manage and optimize performance to achieve efficiency and financial benefit.’
Business Intelligence (BI) bezieht sich auf Anwendungen und Technologien, die eingesetzt werden, um Daten und Informationen innerhalb eines Unternehmens zu sammeln, zugänglich zu machen und zu analysieren. BI-Systeme können Unternehmen helfen, umfassenderes Wissen über die Faktoren zu gewinnen, die ihr Geschäft beeinflussen, z.B. Kennzahlen über Vertrieb, Produktion und interne Abläufe. Sie können helfen, bessere Entscheidungen zu treffen.
Während sich operative Informationssysteme mit der Unterstützung operativer Geschäftsprozesse (Auftragsabwicklung, Materialwirtschaft, …) beschäftigen, unterstützen BI-Systeme (auch Analytische Informationssysteme) Managementaufgaben und Wissensprozesse. Ziel ist die Nutzbarmachung der Datenbanken (und anderen Datenspeichern) verborgenen Informationen. Business Intelligence im weiteren Sinne beschäftigt sich sowohl mit strukturierten (in Datenbanken gespeicherte) Daten als auch mit unstrukturierten (z.B. textuellen) Dokumenten. Diese Vorlesung konzentriert sich auf Business Intelligence im engeren Sinne, sprich die Speicherung und Analyse von strukturierten Daten.

Data Warehouse
’Ein Data Warehouse ist eine physische Datenbank mit integrierter Sicht auf beliebige Daten zu Analysezwecken.’

Als integrierte Datenbank für Business Intelligence dient ein Data Warehouse. Der Begriff Data Warehouse ist jedoch in der Literatur teils unterschiedlich definiert (z.B. reine Datenbank vs. komplette Systemarchitektur, Verwendung des multidimensionalen Modells).

Vereinfachte Architektur

Daten werden von unterschiedlichen Datenquellen (IMS = hierarchisches Datenbanksystem aus der IBM Mainframe-Welt, RDBMS = relationales Datenbanksystem) über eine Integrationsschicht (ETL – Extract, Transform, Load) in das Data Warehouse kopiert.
Analysewerkzeuge greifen auf die Daten im Data Warehouse zu.

Charakteristika eines Data Warehouse:

• Trennung von operationaler (transaktionsorientierter) und analytischer Datenverwaltung und -speicherung
• Wenige Benutzer*innen (im Vergleich zu operativen Systemen) mit langen leseintensiven Transaktionen
• Periodische (meist additive) Aktualisierungen (Ladevorgänge)
• Sehr große Datenmengen (Gigabytes bis Terabytes); Einbindung von Daten aus unterschiedlichsten Quellen (ggf. auch Berücksichtigung externer Daten)
• Extrahieren der relevanten Informationen aus den operationalen Rohdaten, normalerweise aggregiert; einfaches, verständliches Datenmodell

Zum letzten Punkt ist jedoch anzumerken, dass ein echtes Enterprise Data Warehouse gegen Veränderungen in der Analyseanforderung resistent sein sollte. Daher stellt sich die Frage, welche Informationen durch Aggregation verloren gehen. Oft hält man im Data Warehouse Detaildaten und verwendet für aggregierte Daten mit vereinfachtem Datenmodell einen abgeleiteten Data Mart.

Die klassische Definition für ein Data Warehouse stammt von William Harvey (ganannt Bill) Inmon:
’A Data Warehouse is a subject-oriented, integrated, non-volatile, time-variant collection of data organized to support management needs.’  

Sie lässt sich wie folgt in ihre Bestandteile zerlegen:

• Subject-oriented (themenorientiert): Das Datenmodell sollte sich an Analysethemen (Kundin, Produkt, etc.) orientieren und nicht an operativen Anwendungen
• Integrated: Daten aus heterogenen Systemen sind in einer einzelnen integrierten Datenbank gespeichert, Inkonsistenzen sind entfernt
• Non-volatile/time-variant (historisch/nicht flüchtig): Der Begriff “time-variant” ist missverständlich und wurde zu „..., where each unit of data is relevant to some moment in time“ umformuliert. Ein Data Warehouse speichert historische Daten (die üblicherweise 5-10 Jahre aufbewart bleiben) um Trendanalysen zu ermöglichen. Es wird grundsätzlich nichts, was einmal in das Data Warehouse aufgenommen worden ist, überschrieben, um Reproduzierbarkeit und Nachvollziehbarkeit der gemachten Auswertungen zu gewährleisten.

Grundlagen und Historie
Die Entwicklung von analytischen Systemen zur Management- und Entscheidungsunterstützung geht auf die 60er und 70er Jahre zurück. Ziel war und ist die Integration heterogener Datenbanken zur Entscheidungsunterstützung, einige Lösungen sind schon lange als verteilte und föderierte Datenbanken vorhanden.
Zunächst existierten analytische Informationssysteme mit Direktzugriff auf Operativdaten. Begriffe wie MIS (Management Information System), DSS (Decision Support System), EIS (Executive Information System) kamen in den 70er Jahren auf.

Entscheidungsunterstützung im Zeitverlauf

In den 60er Jahren dominierten Berichte im Batch-Betrieb. Sie waren jedoch schwer zu verstehen und zu analysieren, unflexibel und teuer. Jede Abfrage/jeder Bericht musste neu programmiert werden.
Die 70er Jahre brachten terminalbasierte DSS/EIS. Sie waren jedoch immer noch unflexibel und individuell programmiert.
In den 80er Jahren dominierten dann Desktop-Datenzugriff und –Analyseprogramme. Anfragetools und Spreadsheets brachten eine leichtere Bedienung, aber noch immer keine a priori Integration (Direktzugriff auf operative Datenbanken).
Data Warehousing mit ETL- und OLAP-Werkzeugen entwickelte sich Mitte der 90er Jahre. Die Daten werden a priori integriert und zur Analyse im Data Warehouse gespeichert. DSS/EIS können nun auf Data Warehouses mit Hilfe von Standard-OLAP-Werkzeugen zugreifen. Aber es gehört mehr zur Entscheidungsunterstützung als nur OLAP, z.B. in die Zukunft gerichtete Analysen (Prognosesysteme, Data Mining) und Dokumente/unstrukturierte Daten.
In den letzten Jahren hat der Begriff ’Business Intelligence’ den Ausdruck OLAP weitestgehend abgelöst, er ist jedoch üblicherweise weiter gefasst (inkludiert Data Mining, fachliche Anwendungen, teils unstrukturierte Daten, Portale, …).
Die folgende Tabelle fasst die Abgrenzung zwischen operativen Systemen (OLTP – Online Transaction Processing) und Data Warehousing/OLAP (Online Analytical Processing) zusammen.

OLTP vs. DWH/OLAP

Charakteristik	OLTP	DWH/OLAP
Benutzertyp	Sachbearbeiter*in, operativ	Management, Planung
Benutzerzahl	Tausende	Tendenziell weniger
Antwortzeit	Sekunden	Sekunden bis Minuten, sogar Stunden bei komplexen Anfragen
Anwendung	Verwaltung, operatives Geschäft	Analyse, Entscheidungsunterstützung
Anfragetyp	Record/Tupelorientiert, vordefiniert	Multidimensional, aggregiert, ad-hoc
Transaktionstyp	Kurse Lese-/Schreiboperationen	Lange Leseoperationen
Datenverwaltungsziel	Transaktionskonsistenz (ACID)	Historisierung
Datenbankgröße	Megabytes bis Gigabytes	Gigabytes bis Terabytes
Optimierungsanforderung	Indexzugriff über Primärschlüssel	Full-table scans

OLTP vs. DWH/OLAP

Gründe für die Trennung von OLTP- und DWH/OLAP-Systemen:

• OLTP optimiert für kurze Transaktionen und bekannte Lastprofile
• Komplexe OLAP-Anfragen degradieren die Performance von Transaktionen des operationalen Betriebs
• Spezieller physischer und logischer Datenbankentwurf für multidimensionale Anfragen notwendig
• Transaktionseigenschaften (ACID) im DWH unwichtig, da nur Lesezugriff
• Es werden historische Daten benötigt, die in OLTP-Systemen typischerweise nicht vorliegen
• Konsolidierung (Integration, Bereinigung und Aggregation) von Daten aus verschiedenen heterogenen Datenquellen
• Datenredundanz (Speicherung vorberechneter Aggregate auf verschiedenen Ebenen) kann aus Performance-Gründen notwendig sein; ist im DWH kontrollierbar
• Sicherheit (z.B. Anonymisierung der Daten im DWH)

Online Analytical Processing (OLAP)
OLAP ist eine ’Anwendungsarchitektur’, die ein Data Warehouse als Datenquelle verwendet. Hauptcharakteristikum ist die Multidimensionalität als intuitiver Analyseansatz.
Typische Anfragen:

• Wie haben sich die Verkaufszahlen in Bezug auf Verkaufskanäle und Produktgruppen dieses Jahr entwickelt (im Vergleich zum letzten Jahr)?
• Welche Geschäfte machen 80 Prozent des Umsatzes einer bestimmten Marke?

Erweiterte Architektur

Das multidimensionale Modell von OLAP-Systemen basiert auf dem Hypercube-Paradigma. Analytische Kennzahlen/Fakten (quantifizierende Informationen, innerhalb des Würfels) orientieren sich an Dimensionen (qualifizierende Informationen, außerhalb des Würfels). Dimensionen sind meist hierarchisch strukturiert.

Hypercube-Paradigma

Typische OLAP-Operationen zur explorativen Navigation sind Slicing und Dicing zur Auswahl eines Teilwürfels (z.B. Beschränkung auf Objekt „Hluboka“).

Slice and Dice

Weitere Operationen sind Drill-down und Roll-up zur Auswahl des Detaillevels/Aggregierungsgrades. Split und Merge erhöht bzw. verringert die Dimensionalität des Ergebniswürfels, z.B. je Objekt -> je Objekt und Jahr. Drill-Across: weist betrachtete Kennzahlen in anderen Dimensionen aus. Drill-Through betrifft die Architektur des DWH, z.B. Wechsel der Datenquelle.

Illustration der OLAP-Operationen

Illustration der OLAP-Operationen

Edgar Frank Codd hat 12 Regeln aufgestellt, die ein OLAP-System zu erfüllen hat  :

1. Mehrdimensionale Sicht
2. Transparenz für den Anwender*innen (Einbindung in Spreadsheets, etc.)
3. Flexible Zugriffsmöglichkeiten (Möglichkeit, auf unterschiedlichste Quellen zuzugreifen)
4. Konsistente Geschwindigkeit
5. Client-Server-Architektur
6. Gleichrangigkeit der Dimensionen
7. Dynamische Verwaltung dünn besetzter Matrizen (Sparse Data)
8. Mehrbenutzer*innenbetrieb
9. Unbeschränkte, dimensionsübergreifende Funktionen
10. Intuitive Datenmanipulation (Drill-down, Roll-up, etc.)
11. Flexibles Reporting
12. Unbegrenzte Dimensionen/Aggregationsebenen

Einen ähnlichen Kriterienkatalog hat Nigel Pendse mit dem FASMI-Test (Fast Analysis of Shared Multidimensional Information) im Rahmen der OLAP Report Marktstudie aufgestellt:

• Fast: Hochgradig effiziente Analyse mit garantierter Antwortzeit von 5-20 Sek. unabhängig vom zugrundenliegenden Datenvolumen und der Komplexität der Abfrage
• Analysis: Einfaches Benutzer*inneninterface, das dem „techn. Sachverstand der Zielgruppe“ gerecht wird, sinnvolle (inkl. graphische) Datenpräsentation
• Shared: Mehrbenutzer*innenbetrieb
• Multidimensional: Multidimensionale Sicht, hierarchisch strukturierte Dimensionen
• Information: Für aussagekräftige Informationen muss das Produkt auf Daten verschiedenster Quellen zugreifen können

Architekturen

Die vorgestellte vereinfachte Architektur lässt sich um Metadaten und Data Marts ergänzen.

Erweiterte Architektur

Man unterscheidet abhängige und unabhängige Data Marts:

• Abhängige Data Marts: Extraktion eines Teils des Data Warehouse zur Nutzung in einer Abteilung oder für eine bestimmte Benutzer*innengruppe/Anwendung. Zur Erinnerung: Das multidimensionale Datenmodell ergibt sich aus den Analyseanforderungen der Anwender*innen, ein Enterprise Data Warehouse sollte für verschiedene Anwendungen und Data Mining geeignet sein. (Virtuelle oder materialisierte) Data Marts können zur Erzeugung einer multidimensionalen Sicht auf das Enterprise-Datenmodell verwendet werden; vorberechnete Aggregate oder MDDB-Technologie sind nur in OLAP Data Marts nötig.
• Unabhängige Data Marts: Unter unabhängigen Data Marts versteht man den Versuch der Verwendung eines Abteilungs-Data-Mart als Proof-of-Concept bzw. Prototyp für ein Data-Warehouse-Projekt. Problem: Der Aufwand für den Ladevorgang (Data Cleaning, Datenextraktion), die Hauptproblematik in einem DWH-Projekt, reduziert sich nicht. Unabhängige Data Marts bringen weitere Probleme mit sich, wenn sie später zusammengeführt werden sollen.

Referenzarchitekturen
Die folgende Abbildung zeigt die Business-Intelligence-Referenzarchitektur des TDWI (The Data Warehouse Institute ).

Referenzarchitektur des TDWI

Aufbauend auf dem Data-Warehouse-Konzept hat Bill Inmon eine Referenzarchitektur für eine Corporate Information Factory (CIF) definiert.

BI-Architektur basierend Bill Inmons Corporate Information Factory (CIF)

Datenmodellierung

Betrachtet man die dargestellte Architektur, lässt sich feststellen, dass für das Data Warehouse und OLAP Data Marts unterschiedliche Datenmodelle zum Einsatz kommen können. Da (Enterprise) Data Warehouses unabhängig von einer konkreten Analyseanwendung sein sollten, kommen hier ’normale’ ER-Modelle zur Modellierung zum Einsatz. Das daraus resultierende logische Datenmodell ergibt eine normalisierte (3. Normalform) relationale Datenbank.
OLAP-Anwendungen (i.e. Data Marts) hingegen basieren auf dem multidimensionalen Modell. Datenmodelle unterliegen daher gewissen Restriktionen um den intuitiven Zugriff auf die Daten durch OLAP-Analysewerkzeuge zu ermöglichen.

Diese Unterscheidung, inkl. Gliederung in die üblichen Abstraktionsebenen der Datenmodellierung (konzeptuelles, logisches und physisches Modell) ist in der folgenden Abbildung dargestellt.

Data-Warehouse- und OLAP-Datenmodelle

Ein Subject Area Modell dient der groben Strukturierung des Data Warehouse in Themengebiete. Die folgende Abbildung zeigt das Subject Area Model eines Referenzdatenmodells für den Finanzdienstleistungssektor.

Subject Area Model für den Finanzdienstleistungssektor

Im physischen Datenmodell werden Generalisierungshierarchien oft aufgelöst, um die Handhabbarkeit der entstehenden Tabellenstrukturen zu verbessern. Die folgende Abbildung zeigt einen Ausschnitt aus einem logischen DWH-Datenmodell und die zugehörige physische Umsetzung.

Auszug aus dem logischen Datenmodell und physische Umsetzung

Das multidimensionale Model
Es existiert keine einheitliche mutidimensionale Algebra wie in der relationalen Welt. Multidimensionale Modelle entwickelten sich aus den Implementierungen in kommerziellen OLAP- (oft ehem. EIS-) Produkten, sie unterscheiden sich in ihrer Unterstützung komplexer Dimensionenshierarchien, abgeleiteten Kennzahlen, etc.
Wissenschaftliche Arbeiten versuchten nachträglich eine Formalisierung und saubere Definition dieser bereits existierenden Implementierungen (anstatt umgekehrt). Inzwischen hat sich OLE DB for OLAP und MDX-Anfragesprache als De-Facto-Standard zum Zugriff auf multidimensionale Datenstrukturen etabliert.
Das MD-Modell von Cabibbo und Torlone bietet ein wissenschaftliches Standardmodell (aber nur eines von vielen). Formalismus  :

• Dimension ist ein Tripel (L, ${\textstyle a\leq \ }$b, R-UP) bestehend aus einer Menge von Levels L mit Halbordnung ${\textstyle a\leq \ }$b und einer Menge von Roll-Up-Funktionen R-UP
• Datenwürfel: n-dimensionale f-Tables f[A1:l1, …, An:ln]:l0 mit Namen von Attributen Ai und Levels li
• Multidimensionales Schema (D, F) mit Menge von Dimensionen D und Menge von f-Tables F

Das Modell hat einige Einschränkungen. Es gibt keine Dimensionsattribute. Mehrere Kennzahlen müssen über mehrere f-Tables oder Kennzahlendimension abgebildet werden.

Beispielhalbordnung der Dimensionen im MD-Modell

Beispiel

• D = {time, location, product}
• L${\textstyle _{time}}$, L${\textstyle _{location}}$, L${\textstyle _{product}}$
• R-UP${\textstyle _{time}}$ = {R${\textstyle _{day->month}}$, R${\textstyle _{month->quarter}}$, R${\textstyle _{quarter->year}}$, R${\textstyle _{day->week}}$, R${\textstyle _{week->year}}$}, z.B. R${\textstyle _{day->month}}$(’27.06.2000’) = ’Juni 2000’
• R-UP${\textstyle _{location}}$ = {R${\textstyle _{store->city}}$, R${\textstyle _{city->area}}$}
• R-UP${\textstyle _{product}}$ = {R${\textstyle _{item->category}}$, R${\textstyle _{item->brand}}$}, z.B. R${\textstyle _{item->category}}$(’Lego’)=’Toys’

Multidimensionale Modellierung
Das multidimensionale Modell ist eine intuitive Repräsentation der Realwelt. Das ist wichtig, da Endbenutzer*innen durch das Datenmodell navigieren (dieses also verstehen) müssen.
Bei der multidimensionalen Modellierung stellt sich die Frage nach der Notation: Ist die ER-Notation für multidimensionalen Entwurf geeignet? Problem: keine Unterscheidung zwischen qualifizierenden Entities (Dimensionen) und quantifizierenden Entities (Fakten). Es gibt viele Vorschläge für multidimensionale Notationen, es ist aber kein Standard in Sicht.

Multidimensional ER (ME/R) wurde am FORWISS, Technische Universität München entwickelt . Es erweitert die ER-Notation um die drei Elemente Fact Relation, Dimension Level und Roll-up Relation.

Beispielhalbordnung der Dimensionen im MD-Modell

Graph-Grammatik von ME/R

Beispielmodell in ME/R

Application Design for Analytical Processing Technologies (ADAPT) ist ein proprietärer Ansatz (basiert nicht auf anderen Notationen) aus der Consulting-Praxis, entwickelt von Dan Bulos, Symmetry Corporation . Er wird oft in Verbindung mit Oracle Express verwendet (erwähnt auf diversen Konferenzen der Oracle User Group). Erstmalig publiziert in der Zeitschrift Database Programming & Design, inzwischen auch diverse Reaktionen in wissenschaftlichen Veröffentlichungen.
Kritik: Fehlende formale Beschreibung, Semantik nur anhand von Beispielen; große Symbolvielfalt, hohe Komplexität.

Modellierungselemente in ADAPT

Beispielmodell in ADAPT

Speicherung multidimensionaler Daten
Multidimensionales Modell ist konzeptuell/logisch, nicht zwangsläufig physisch. Die multidimensionale Realisierung erfolgt mittels proprietärer MDBMS (MOLAP) oder relational mit herkömmlichen relationalen DBMS (ROLAP):

• Multidimensionales OLAP (MOLAP): OLAP-Daten werden in speziellen Speicherstrukturen (d.h. multidimensionalen Arrays) gespeichert. Speichersystem und OLAP Engine sind stark miteinander verwoben, der Datenzugriff ist daher proprietär, aber schnell aufgrund optimierter Datenhaltung. Varianten von MOLAP sind Client OLAP oder Desktop OLAP (DOLAP). Der Trend geht in Richtung Hybrid OLAP (HOLAP) mit relationaler Speicherung der Detaildaten und multidimensionale Speicherung der Aggregate (eine Art Cache).
• Relationales OLAP (ROLAP): ROLAP verwendet ein relationales logisches/physisches Datenmodell, ergänzt durch multidimensionale Metadaten. Eine multidimensionale Engine setzt OLAP-Operationen in SQL-Anfragen um.
  

MOLAP-Speicherung ist mit einigen Problemen verbunden. Oft müssen alle Aggregate vorberechnet werden, um die optimierte Speicherung nutzen zu können. Inkrementelle Datenbank-Aktualisierungen sind nicht möglich, da das multidimensionale Array jedes Mal komplett neu generiert werden muss, wenn sich die Struktur ändert. Ein weiteres Problem ist die Dünnbesetztheit (Sparsity): in typischen Datenwürfeln sind weniger als 5% der Zellen besetzt, leere Zellen benötigen jedoch ebenfalls Speicherplatz. Als Lösungsansatz dienen Kompressionsverfahren.

Mangelnde Skalierbarkeit: Multidimensionale Arrays werden durch die vorberechneten Aggregate und die Dünnbesetztheit sehr groß, die Technologie ist für hunderte Gigabytes dadurch ungeeignet. Aus diesen Gründen wird MOLAP üblicherweise nur für ’small-scale’ Anwendungen oder Data Marts verwendet, nicht zur Speicherung eines (Enterprise) Data Warehouse.
Bei ROLAP-Speicherung kommen als Datenmodell sog. Star- oder Snowflake-Schemata mit einer zentralen Fakttabelle und Dimensionstabellen zum Einsatz.

Ein Star-Schema besteht aus einer zentralen Fakttabelle zur Speicherung der quantifizierenden Daten (Kennzahlen) mit einem zusammengesetzten Primärschlüssel aus den Dimensionen. Die Fakttabelle hat wenige Spalten und (sehr) viele Tupel. Dimensionstabellen in Star-Schemata sind denormalisiert, sie haben relativ wenige Tupel und werden für Selektion und Aggregation (GROUP BY) verwendet.

Star-Schema

Bei Star-Schemata wird Redundanz in den Dimensionstabellen bewusst in Kauf genommen. Die Datenbank ist also nicht in 3. Normalform (3NF). Denormalisierung spart aufwendige Joins bei den Anfragen und erhöht die ’Browsing Performance’.

Beispieldimensionstabelle im Star-Schema

Im Gegensatz zum Star-Schema sind die Dimensionstabellen im Snowflake-Schema normalisiert (d.h. die Datenbank ist in 3NF). Das führt zu einer leichteren Aktualisierungsmöglichkeit, jedoch auch zu schlechterer Performance (mehr Joins). Die Speicherplatzeinsparung spielt keine Rolle (Dimensionstabellen sind im Vergleich Fakttabelle eher klein).

Snowflake-Schema

Ein Problem im multidimensionalen Modell sind die sog. Slow Changing Dimensions. Dimensionen (qualifizierende Daten) ändern sich mit der Zeit, z.B. Kund*innen ändern ihren Namen oder ziehen um, Produkte fallen weg, Produktgruppen, Organisationseinheiten werden umstrukturiert. Dies ist problematisch, da historische Daten im DWH existieren. Verglichen mit den quantifizierenden Kennzahlen sind die Dimensionen jedoch meist relativ statisch, daher spricht man von ’slow changing’. Designalternativen:

• Überschreiben der Dimensionstabellen (UPDATE), Problem: alte Anfragen/Berichte sind nicht mehr nachvollziehbar
• Versionierung/Historisierung der Dimensionstabellen, ggf. Abbildung der Versionierung als eigene Dimension

Datenbewirtschaftung

Die folgende Abbildung zeigt schematisch den Vorgang der Datenbewirtschaftung, sprich der Beladung des Data Warehouse (ETL – Extract ,Transform, Load).

Ladevorgang (ETL)

Daten werden temporär in der Staging Area gehalten, bevor sie in das DWH geladen werden. Alle Transformationen werden in der Staging Area durchgeführt. Das Preprocessing beeinflusst nicht die Datenquellen oder das DWH. Die Staging Area ist der zentrale Speicher für die ETL-Prozesse. Das Datenmodell der Staging Area entspricht dabei üblicherweise dem der Quellsysteme, von dort werden die Daten in das Zielmodell (Data-Warehouse-Datenmodell) transformiert.

ETL – Extract, Transform, Load
Es gibt unterschiedliche Verfahren zur Extraktion der Daten aus den Quellsystemen über Replika, Snapshots, Logfiles, Exports/Dumps, Datenbank APIs (ODBC), etc. Zu bedenken sind hierbei die begrenzten Zeitfenster, d.h. es werden meist nur relevante Daten (solche Tabellen/Felder, die ins DWH übernommen werden sollen) extrahiert. Die Verfügbarkeit und Performance des Quellsystems sollte nicht beeinträchtigt werden.

Extraktionsarten:

• Periodisch
• Manuelles Anstoßen
• Ereignis-gesteuert
• Sofort nach Veränderungen in den Quelldaten

Problem: OLTP-Systeme sind oft alt, schlecht dokumentiert und schwer zugänglich.

Die Transformation der Daten in eine integrierte Form (Data-Warehouse-Datenmodell) erfolgt im nächsten Schritt. Es muss sowohl die Struktur als auch die Inhalte transformiert werden.

Typische Transformationsformen:

• Normalisierung, De-Normalisierung
• Datentypumwandlung
• Berechnungen, Aggregierung
• Standardisierung
• Umwandlung von Maßeinheiten
• Data Cleansing
• Anonymisierung
• Historisierung

Beim Load werden die Daten aus der Staging Area in das DWH (und ggf. in Data Marts) transferiert. Daten im DWH werden selten ersetzt, stattdessen wird die Historie von Werten und Änderungen abgespeichert. Daten müssen an bereits existierende Tabellen hinzugefügt werden. Meistens geschieht das basierend auf Massenlade-Mechanismen des DBMS, um große Datenmengen zu bewegen.
Problem: Zugriff auf große Datenmengen in einem u.U. kurzen Zeitfenster; operative Systeme und DWH sollten während des Ladevorgangs aus Konsistenz- und Performance-Gründen möglichst offline sein, konkret die operativen Systeme während der jeweiligen Extraktion, das DWH während des Load.

Extract, Load, Transform (ELT)
Moderne relationale DBMS bieten mächtige Sprachen an (z.B. PL/SQL). Daher hat sich der ELT-Ansatz als Variante zum ETL entwickelt. Die Transformation findet dabei erst im DWH statt. Der Vorteil ist eine potentiell höhere Performance und die Tatsache, dass keine leistungsstarken und teuren ETL-Server benötigt werden (die Leistung der DWH-Datenbank wird auch zur Transformation verwendet).
Bei händischer Entwicklung ergibt sich jedoch das Problem, dass wichtige Funktionen zur Pflege und Verwaltung der Transformationsregeln (Metadaten) und Statistiken zur Bewertung der Datenqualität fehlen. Als Lösungsansatz dient hier die Generierung des SQL-Code durch ELT-Werkzeuge.

Historisierung
Daten werden in den operativen Datenbanken z.T. statisch (als Snapshot) gespeichert und müssen historisiert (versioniert) werden, um zeitliche Veränderungen analysieren zu können. Beim Update ist dafür zu sorgen, dass die Versionsführung ’sauber’ ist:

• Keine Überschreibung von Werten
• Keine Lücken
• Keine Überschneidungen von Versionen einer Entität

Die Versionsführung von Entitäten wird von den Datenbanksystemen jedoch nicht direkt unterstützt. Der SQL-Befehl UPDATE überschreibt, der SQL-Befehl DELETE löscht. Beziehungen werden üblicherweise über Primärschlüssel hergestellt, referentielle Integrität wird über Constraints hergestellt, die auf Snapshots wirken. Das Problem ist daher auf Applikationsebene zu lösen, wird aber meist unterschätzt.

Häufigste Fehler:

• Daten werden (absichtlich oder versehentlich) überschrieben
• Es gibt Lücken oder Überschneidungen in den Versionen zu Objekten
• Zeitlich nicht zusammenpassende Daten werden gemeinsam verwendet (’gejoint’)

Weitere Fehlerquellen in der Versionsführung liegen darin, dass Daten verspätet eintreffen, Eintritts- oder Wirksamkeitszeitpunkte von Zustandsänderungen sich nachträglich ändern oder Merkmale (Attribute) später anders beschrieben werden als ursprünglich konzipiert (Semantikänderungen).

In der temporalen Datenbanktheorie unterscheidet man drei Dimensionen der Zeit:

• Gültigkeitszeit (Valid/Data Time): Zeitpunkt der Gültigkeit eines Objekts oder eines Ereignisses im betrachteten Realitätsausschnitt
• Transaktionszeit (Transaction/Registration Time): Zeitpunkt, zu dem ein Ereignis oder Sachverhalt in die Datenbank aufgenommen wird
• Benutzerdefinierte Zeit (User-defined Time): Zeit-Attribut, dessen Bedeutung von der Anwendung festgelegt wird (ist für das DBMS ein Attribut ohne besondere Bedeutung)
  

Eine temporale Erweiterung von SQL wurde als TSQL2 vorgeschlagen. TSQL2 basierte auf einem bitemporalen Datenmodell (Gültigkeits- und Transaktionszeit) und einer Versionierung auf Tupelebene. z.B. Eingrenzung der Gültigkeitszeit im Rahmen der WHERE-Klausel:

Leider wurde die TSQL2 (auch SQL/Temporal) nicht weiterverfolgt und nie in den SQL-Standard aufgenommen.
’It was with some regret that the ANSI and ISO SQL groups withdrew the SQL/Temporal project from further development in late 2001, but some of us hope that […] standardization might continue in the future.’

Eine Methodik zur temporalen Datenhaltung in Data Warehouses ist das Continuous History Management. Der konzeptuelle Rahmen sieht drei Arten von Entitätstypen vor: persistente Objekte, Ereignisse und Aufzählungstypen (diskrete, hierarchisch geordnete Wertevorräte). Es basiert auf einem bitemporalen Modell der Objektevolution mit zwei Zeitachsen (Zustand der Realität, Zustand der Datenbank). Dazu kommen Schemaevolutionsregeln zur Sicherstellung der Aufwärtskompatibilität des Datenmodells und Regeln zur Evolution von Aufzählungstypen.
Kund*innen, Produkte und alle Arten von Bestandsdaten sind persistente Objekte. Data Warehouses bestimmter Branchen (z.B. Versicherungen, Behörden) befassen sich überwiegend mit persistenten Objekten. Persistente Objekte sind in der Regel zeitlich veränderlich. Im Data Warehousing steht die Evolution der persistenten Objekte im Zentrum des Interesses (Beispiele: Bestandsoptimierung, Kostenmanagement, Yield Management).

Ein Datenmodell ist aufwärtskompatibel zu einem anderen Datenmodell, wenn alle Datenstrukturen und alle zulässigen Query-Ausdrücke des letzteren Modells in ersterem Modell enthalten sind.

’Damit ein Datenmodell aufwärtskompatibel mit einem anderen, vorher existierenden Datenmodell ist, müssen alle Queries, die im vorher existierenden Modell formulierbar sind, in beiden Modellen die gleichen Ergebnisse liefern.’

Neben der Nichtvolatilität nach Inmon wird die Aufwärtskompatibilität des Datenmodells und die Korrekturfähigkeit der Daten gefordert. Es ist kaum erreichbar, dass ein Data Warehouse, und sei es auch nur zu bestimmten Zeitpunkten und mit einem gewissen Zeitverzug, ein hundertprozentig vollständiges und korrektes Abbild der Realität darstellt. Nichtvolatilität und Korrekturfähigkeit sind jedoch auf den ersten Blick unvereinbare Forderungen, können jedoch durch geeignete Konventionen miteinander verträglich gemacht werden.

Die Lösung liegt im bitemporalen Modell:

• Unterscheidung zwischen Wirksamkeitszeitpunkten und Aufnahmezeitpunkten (Transaktionszeitpunkten) von Ereignissen/Zustandsübergängen
• Zwei Zeitachsen: Zustandsachse der realen Welt und Wissensachse (’bitemporales Modell’, Zeitebene)

Beispiel 1: Korrektur im Status einer Person

Das Beispiel stammt aus der Bundesagentur für Arbeit. Eine Person ist ’einsetzbar’, wenn sie arbeitslos ist. Bei einem bitemporalen Datenmodell gäbe es zwei Dimensionen (mit jeweils Von/Bis-Zeitstempeln), Zustand (z.B. ZUST_VON, ZUST_BIS) und Kenntnisstand (z.B. KENNT_VON und KENNT_BIS).

Am 1.3. sieht die entsprechende Datentabelle folgendermaßen aus (Annahme, Datensatz angelegt am 1.1.):

Beispiel 2: Korrektur eines Wirksamkeitszeitpunkts

Beispiel 3: Nachträgliches Einfügen eines Wohnorts

Vorberechnung von Aggregaten
Zur Optimierung der Abfrageperformance werden häufig verwendete Aggregate (z.B. Summierung der Verkäufe auf Monatsebene) oft vorberechnet und persistent gespeichert. Der Grundgedanke ist die Vorberechnung eines Join- oder Aggregationsergebnisses. Die höhere Geschwindigkeit der Anfrageverarbeitung gilt es dabei gegenüber den höheren Kosten zum Vorhalten und Aktualisieren der sog. materialisierten Sichten abzuwägen.

Man unterscheidet dabei eine explizite und implizite Speicherung:

• Explizit: Die Speicherung erfolgt als zusätzliche (aggregierte Fakten-) Tabellen ohne direkte Verbindung zu den Detaildaten. Das Update erfolgt im ETL-Prozess, die Verwendung durch Abfragen auf Aggregate und Detaildaten getrennt.
• Implizit: Aggregate sind als materialisierte Sichten direkt mit den Detaildaten verbunden. Das Update erfolgt durch das DBMS beim Verändern der Detaildaten, die Verwendung durch Abfrage auf die Detaildaten, das DBMS schreibt die Anfrage automatisch um (Query Rewriting).

Die Forschung beschäftigt sich bereits seit einigen Jahren mit der Fragestellung, welche materialisierten Sichten gespeichert werden sollen (Auswahlproblem). Die Anzahl möglicher Sichten ist dabei 2n bei n funktional unabhängigen Attributen (kombinatorische Explosion).

Mögliche materialisierte Sichten

Datenanalyse

Eines der Hauptanwendungsgebiete für Business Intelligence ist das Corporate Performance Management (CPM). Es unterstützt Unternehmen bei einer effizienten und kostensparenden Unternehmenssteuerung.
CPM steht für Prozesse, Methoden und analytische Anwendungen zur Unternehmenssteuerung.
CPM schafft die Verbindung zwischen Zielen, Metriken (KPIs) und Personen, um Verwaltung, Analysen und Maßnahmen im gesamten Unternehmen voranzubringen.
CPM hilft Transparenz zu schaffen, kritische Bereiche aufzuzeigen sowie Ergebnis, Planung und Forecasts zu optimieren. Daraus resultiert eine höhere Zuverlässigkeit der Prognosen und Forecasts. Durch intelligente Verknüpfung von Geschäftsanwendungen wird Zugang zu Informationen ermöglicht, um Antworten auf strategische und operative Fragen zu geben. Aus den gesammelten Daten wird über integrierte Planungs-und Konsolidierungs-Anwendungen ein Mehrwert geschaffen und Nutzen generiert. Ziel ist ein ’Single Point of Truth’ für sämtliche Kennzahlen und Reports sowie Zeit-und Kosteneinsparung.
Da auch der Mittelstand in einem globalisierten Marktumfeld wettbewerbsfähig sein muss, ist CPM ein immer wichtigerer Baustein. Die Kostenhürde wird durch konsequente Integration gesenkt. Weniger Anpassungsbedarf beschleunigt die Implementierung und senkt die Betriebskosten.

Die folgende Abbildung zeigt eine mögliche Kategorisierung der Funktionalität von BI-Werkzeugen.

Mögliche Kategorisierung der Funktionalität von BI Tools

Eine andere (ähnliche) Kategorisierung findet sich bei SAP/Business Objects zur Einordnung des Produktportfolios.

Reportingpyramide

Die Reportingpyramide unterscheidet drei Typen von Analysewerkzeugen und Nutzer*innengruppen:

• Interaktive Dashboards/Entscheider: Hier kommen interaktive Analysen mit Auswahlboxen, Reglern, Drill, ’was-wäre-wenn’-Analysen zum Einsatz. Das Layout ist grafikorientiert, Output-Formate wie PowerPoint, Outlook, PDF und Web werden verwendet.
  
• Ad-Hoc-Reporting/Analysten: Hier wird ein leistungsfähiges, webbasiertes Reporting mit intuitiver Drag&Drop-Funktionalität gefordert. Das Interface basiert auf semantischen Layers (multidimensionales Modell). Interaktive Analysen mit Drillen, Filtern, Sortieren, Gruppieren, Sektionen, Berechnungen und Formatieren sind möglich.
  
• Reporting/Konsument*innen: Die dritte Kategorie bilden hochformatierte, interaktive Informationen für alle Anwender*innen mit listenorientierter Darstellung (GuV, Bilanzen, etc.). Informationen werden dargestellt, wann und so wie Anwender sie benötigen.
  

SQL für OLAP – Star Queries
Bei der Analyse in ROLAP-Anwendungen führt die Verwendung von Star- und Snowflake-Schemata zu Star Queries. Die Dimensionstabellen werden über Joins mit der Faktentabelle verbunden. Der Verdichtungsgrad und die Bildung von Aggregaten wird durch die GROUP-BY-Klausel gesteuert.

SQL SELECT Syntax

Beispiel – Wieviele Handies von welchem Hersteller haben junge Kund*innen in den bayrischen Filialen an Weihnachten 2001 gekauft:

Der frühe Sprachumfang von SQL weist dabei Defizite hinsichtlich Aggregations- und Gruppierungsmöglichkeiten auf. Ursprünglich werden nur die Standard-Aggregationsfunktionen SUM(), AVG(), COUNT(), MIN() und MAX() unterstützt. Herstellerabhängige Erweiterungen, z.B. STDDEV(), VARIANCE(), COVARIANCE() oder Funktionen zur linearen Regressionsanalyse kamen hinzu.
Seit SQL:99 gibt es für OLAP einige zusätzliche Konstrukte, wie ROLLUP, CUBE, GROUPING SETS, PERCENTILE, RANK, ...

Man unterscheidet folgende Funktionstypen in SQL:

• Skalarfunktionen: Verknüpfung einzelner Attribute durch Operatoren zur Werteberechnung, Transformation einzelner Attribute, z.B. Nettopreis*Steuersatz, MONTH(Datum)
• Aggregationsfunktionen: Werteverdichtung einer gebildeteten Gruppe, z.B. SUM(), MAX(), MIN(), COUNT(), …
• OLAP-Funktionen: Erweiterung der Aggregationsfunktionen, OVER()-Klausel hinter einer Aggregationsoperation, z.B. Tagesstückzahlen und der Anteil an den Gesamtstückzahlen:

Beispieldatensatz

Die ROLLUP-Klausel errechnet n+1 (Unter-) Aggregate ausgehend von einer Liste mit n Spaltennamen, vom detailliertesten Level zur Gesamtsumme.

Ergebnis:

Beispielergebnis der ROLLUP-Klausel

Die CUBE-Klausel verallgemeinert ROLLUP und liefert die Aggregate aller 2n möglichen Gruppierungskombinationen.

Ergebnis:

Beispielergebnis der CUBE-Klausel

Die GROUPING-SETS-Klausel erlaubt eine Gruppierung nach mehreren Kriterien innerhalb einer Anfrage.

Ergebnis:

Beispielergebnis der GROUPING-SETS-Klausel

Die OVER()-Klausel erlaubt die Berechnung von Aggregaten auf unterschiedlicher Aggregationsebene in einer Abfrage.
Beispiel: von Tagesstückzahlen und der Anteil an den Gesamtstückzahlen. Ohne OVER()-Klausel muss mit einer verschachtelten Anfrage gearbeitet werden:

Mit OVER()-Klausel ist die gleiche Anfrage deutlich leichter formulierbar:

Die OVER()-Klausel erlaubt auch eine attributlokale Partitionierung pro Attribut der Ergebnisrelation, d.h. pro angewandter Aggregrationsoperation. Das ermöglicht eine individuelle Nachgruppierung der Ergebnisrelation.
Beispiel – Stückzahl und Anteil der Tagesproduktion an der Monats- und Jahresproduktion:

Weiters ist die Berechnung von kumulierten Werten möglich.
Beispiel – Berechnung kumulierter Lieferzahlen über Gesamtzeitraum, Lieferart und Liefermonat mit attributlokaler Ordnung durch ORDER-BY-Subklauseln:

Schließlich existieren RANK-Operatoren zu Berechnung des Rangs eines Ergebnistupels innerhalb der Partitionsmenge.
Ohne RANK-Operator kann dies durch die COUNT-Klausel erfolgen:

Durch die Einführung von RANK- und DENSERANK-Operatoren ist die Semantik jedoch klarer definiert.
Beispiel für den RANK-Operator:

Tupel-Duplikate erhalten dabei den gleichen Rang mit Lückenbildung bei der Rangfolge zum Nachfolgetupel. DENSERANK arbeitet wie RANK, nur ohne Lückenbildung. ROWNUMBER liefert eine eindeutige Nummerierung der Tupel.
Beispiel für RANK, DENSERANK und ROWNUMBER

Beispiel für attributlokales Ranking:

Weiters ist die Bildung dynamischer Fenster möglich. Das Ziel ist dabei die Glättung ’verrauschter’ Datensätze.

Die Fenstergrößen kann einerseits über die Klauseln ROWS (Anzahl der Tupel) und RANGE (Anzahl der wertemäßig verschiedenen Tupel) explizit angegeben werden.
Für eine dynamische Festlegung der Fenstergröße gibt es zwei Möglichkeiten:

• Ausgehend von definierten Startpunkt bis zum aktuellen Tupel über UNBOUNDED PRECEDING (erstes Tupel der jeweiligen Partition), n PRECEDING (n-ter Vorgänger relativ zur aktuellen Position), CURRENT ROW (aktuelles Tupel – nur mit RANGE und Duplikaten sinnvoll)
• Angabe der unteren und oberen Schranken über BETWEEN untere Grenze AND obere Grenze, durch Spezifikation der Grenzen über UNBOUNDED PRECEDING, UNBOUNDED FOLLOWING, n PRECEDING, n FOLLOWING, CURRENT ROW (obere Grenze muss dabei eine höhere Position als untere Grenze spezifizieren)

Beispiel – gleitende Durchschnitte der Lieferzahlen (zentriertes 3-Tagesfenster, zwei asymmetrische Wochenfenster, retrospektives 30-Tagefenster):