Architektur von Data Warehouses und Business · PDF fileInformatik_Spektrum_23_Februar_2005 3 HAUPTBEITRAG / ARCHITEKTUR VON DATA WAREHOUSES} Dieser Artikel stellt DW-Konzepte und

Informatik_Spektrum_23_Februar_2005 3

HAUPTBEITRAG / ARCHITEKTUR VON DATA WAREHOUSES }

Dieser Artikel stelltDW-Konzepte und -Architekturen dar,welche die Erprobungin mehrjähriger Praxisbestanden haben undsomit als etabliert gel-ten. Er erläutert gängigeBegriffe und beantwor-tet konkrete Fragestel-lungen des Systement-wurfs. Der Bogen spanntsich von der Modellie-rung der fachlichen

Architektur über die technische Architektur undSystemarchitektur bis zu Produkten. Den Abschlussbilden aktuelle Markttrends.

HistorieEntscheidungsunterstützende (dispositive/analytische)Systeme haben eine lange Historie seit den 60er-Jahren und wurden im Verlauf der Jahrzehnte beirecht ähnlicher Funktionalität lediglich unterschied-lich betitelt: Management Information Systems(MIS), Decision Support Systems (DSS), ExecutiveInformation Systems (EIS), Data Warehouses (DW)und schließlich Business Intelligence (BI)-Lösungen.Abbildung 1 gibt eine Übersicht über jeweilige Kernideen beziehungsweise Schlagworte.

Im Laufe dieser Zeit wurden das Maß der Inte-gration von Daten und das Niveau der Entschei-dungsunterstützung permanent verbessert. Währenddie Ansätze aus den 60er-und 70er-Jahren nochweitgehend – gemessen an ihren Ansprüchen –scheiterten, bauten die Werkzeuge späterer Genera-

tionen jeweils auf ihren Vorgängern auf, lernten ausderen Fehlern und wurden zunehmend erfolgrei-cher.

Operative und dispositive Systeme:OLTP versus OLAP

Dienste, welche die Durchführung des operativenGeschäfts eines Unternehmens unterstützen, wer-den auch OLTP (Online Transactional Processing)genannt, dispositive Dienste auch OLAP (OnlineAnalytical Processing). OLAP und OLTP haben sehrunterschiedliche Charakteristiken, so dass sich eineTrennung in unterschiedliche Systeme anbietet.Tabelle 1 zeigt eine Gegenüberstellung.

Data WarehouseEin Data Warehouse ist ein dispositives System. Wirzitieren eine klassische Definition von Inmon [12]:Ein Data Warehouse ist eine themenorientierte,zeitorientierte, integrierte und unveränderliche Da-tensammlung, deren Daten sich für Managemen-tentscheidungen auswerten lassen.Insbesondere bedeuten:

· themenorientiert: alles über Kunden, Produkte etc.;· zeitorientiert: periodische Ergänzung um aktuelle Daten,

Verdichtung nach Zeitintervallen;· integriert: Konsolidierung von Daten verschiedener operati-

ver Systeme;· unveränderlich: einmal

gespeicherte Daten wer-den nicht mehr verän-dert.

Architektur von Data Warehouses und Business Intelligence Systemen

Bernhard Humm · Frank Wietek

DOI 10.1007/s00287-004-0450-5© Springer-Verlag 2005

Dr. B. Humm · Dr. F.Wieteksd&m Research,Carl-Wery-Straße 42, 81739 MünchenE-Mail: [email protected]: [email protected]

Business Intelligence(BI) ist der Prozess der

Umwandlung von Datenin Informationen undweiter in Wissen. Ent-scheidungen und Pro-

gnosen stützen sich aufdieses Wissen und schaf-

fen dadurch Mehrwertfür ein Unternehmen.

Ein Data Warehouse(DW) bildet in vielen Fäl-

len die technische Basiszur Implementierung

einer BI-Lösung.

ARCHITEKTUR VON DATA WAREHOUSES}

Informatik_Spektrum_23_Februar_20054

Aktuelle BI-Trends wie Real-Time Analytics, Plan-ning/Commenting und das Zurückspielen analyti-scher Daten in operative Systeme weichen das Kri-terium der Unveränderlichkeit auf. Vor diesem Hin-tergrund wird auch zunehmend von analytischenanstelle von dispositiven Systemen gesprochen.

Data Warehouses stellen typischerweise OLAP-Funktionalität zur Verfügung. Zur Beschreibungder interaktiven Analyse haben sich folgende Be-griffe für Operationen etabliert:

· Drill-Down und Roll-up: schrittweise Verfeinerung bzw.Ver-dichtung von Analyseergebnissen, zum Beispiel von Jahres-über Monats- zu Tagesauswertungen. Die Verdichtung vonAnalyseergebnissen nennt man auch Aggregation. Diesewird in SQL mittels Grouping Sets und dem Cube Operatorumgesetzt.

· Slice-and-Dice: Navigation in einem multidimensionalen Datenraum durch Fokussierung auf einzelne Aspekte, zumBeispiel Verteilung der Umsätze für ein bestimmtes Produktauf unterschiedliche Regionen und Zeiträume.

· Drill-Through: direkter Zugriff aus analytischen Systemen aufoperative Basisdaten, zum Beispiel auf einzelne Verträge.

Ein Bindeglied zwischen operativem Geschäft unddispositivem Einsatz bilden vordefinierte Standard-berichte, die in der Regel einen großen Teil derDW-Nutzung ausmachen.

Business IntelligenceBusiness Intelligence umfasst ein breites Spektruman Anwendungen und Technologien zur entschei-dungsorientierten Sammlung, Aufbereitung undDarstellung geschäftsrelevanter Informationen. Esbezeichnet den analytischen Prozess, der Unterneh-mens- und Wettbewerbsdaten in handlungsgerich-

tetes Wissen über die Fähigkeiten, Positionen, Hand-lungen und Ziele der betrachteten internen oderexternen Handlungsfelder (Akteure und Prozesse)transformiert [9]. BI ist der Oberbegriff für DW/OLAP, Data Mining und Analytical Applications.Data Mining umfasst – als Teilbereich des Know-ledge Discovery in Databases – (teil)automatisierteTechniken zum Auffinden von Strukturen in gro-ßen Datenmengen, zum Beispiel die Kundenseg-mentierung nach Nutzungsprofilen [8]. AnalyticalApplications umfassen Anwendungen zur Planung,Simulation und zur Berechnung komplexer Kenn-zahlsysteme.

Die folgenden Abschnitte beschreiben die Modellierung (fachliche Architektur) und das Design (technische Architektur und Systemarchi-tektur) von Data Warehouses.

Business IntelligenceEntscheidungsunterstützende Systeme habeneine Historie von über 40 Jahren. Sie werdenheute unter dem Schlagwort Business Intelli-gence (BI) zusammengefasst. Data Warehousing(DW) ist die wichtigste BI-Technologie, für die etablierte Modellierungstechniken, Archi-tekturen und reife Produkte existieren. DieserArtikel gibt eine einführende Übersicht in dieArchitektur von Data Warehouses und Busi-ness-Intelligence-Systemen auf der Basis um-fangreicher Projekterfahrungen.

Abb. 1 Historie vonentscheidungsunter-stützenden Systemen


Fachliche ArchitekturSprachen und Techniken zur Modellierung betrieb-licher Informationssysteme wie Entity/Relationship(E/R) Modellierung [5] oder Object Oriented Analy-sis ( OOA; [6]) sind nicht nur etabliert, sondernauch umfassend standardisiert, zum Beispiel fürdie OOA durch UML [23, 24]. Solche Standards fürdie fachliche Modellierung von Data Warehousesexistieren noch nicht – Ansätze gibt es in Form vonNotationen wie ADAPT [4] sowie Metadaten- undSchnittstellenstandards wie dem Common Ware-house Metamodel der OMG [22] oder XML forAnalysis (XML/A; [25] ). Wir geben daher zu dennachfolgenden Begriffsdefinitionen auch gängigeSynonyme an (vgl. auch z. B. [1, 13, 14, 15, 16, 17]).

Measures, Fakten,Dimensionen und fachliche Sterne

Die Measure (auch Maßzahl oder Kennzahl ge-nannt) ist die kleinste Informationseinheit des DWund bildet die Basis für alle Auswertungen. Measu-res sind stets numerisch und können in der Regelaggregiert werden (Summe, Mittelwert etc.). Kom-plexe Measures können aus anderen Measures oder(evtl. nicht aggregierbaren) Basisinformationen ab-geleitet sein. Wir unterscheiden Measures und Mea-sure-Ausprägungen.

Eine Dimension ist ein Filter- und Auswertungs-Kriterium für Measures. Anders ausgedrückt:Dimensionen spannen einen mehrdimensionalenFakten-Raum auf und bilden somit das Koordina-tensystem zur Navigation durch die Daten. Eine Dimension kann aus mehreren Dimensions-Ele-menten bestehen, die hierarchisch, das heißt in einem Baum oder allgemein in einem gerichtetenazyklischen Graphen, angeordnet sind. Diese Struk-tur ist die Hierarchie der Dimension. Wir unter-scheiden wieder zwischen Dimensions-Elementenund ihren Ausprägungen.

Oftmals ist die Dimensions-Hierarchie linear,das heißt die Dimensions-Elemente bilden eine Liste von feinster Einteilung (der Dimensions-Basismit Basiswerten als Ausprägungen) bis zu gröbsterEinteilung. Dimensions-Elemente können verschie-dene Beschreibungen/Dimensionsattribute haben,

BI technologySystems that support business decisions havebeen established within the last 40 years. To-day, they are subsumed under the heading busi-ness intelligence (BI). Data warehousing (DW)is the most important BI technology. Over theyears, architectures and methodologies forbuilding DW have been established and, today,mature products are available. This article pro-vides an introductory overview of the architec-ture of DW and BI systems based on extensiveproject experience.

Tabelle 1

Fakt-Beschreibungen dienen zur Anzeige von Zu-satzinformationen zu einzelnen Measures. Fakt-Beschreibungen werden nicht aggregiert und müs-sen daher nicht numerisch sein.

Ein Fakt fasst eine Gruppe zusammengehören-der Ausprägungen von Measures und Fakt-Be-schreibungen zusammen. Jeder Fakt ist eindeutigeiner Ausprägung jeder Dimensions-Basis (s. un-ten) zugeordnet. Häufig werden die Begriffe Faktund Measure synonym verwendet.



zum Beispiel Kurz- und Langtexte in verschiedenenSprachen.

Beispiel: In nahezu jedem DW gibt es mindes-tens eine Dimension Zeit, zum Beispiel mit Dimen-sions-Basis „Tag“ (Ausprägung 03.10.2004) undweiteren Dimensions-Elementen „Monat“ (Okto-ber), “Jahr“ (2004). Häufig existieren auch mehrereZeit-Dimensionen, zum Beispiel für das Auftrags-und das Lieferdatum.

Ein fachlicher Stern (fachlicher Würfel/Cube,multidimensionales Datenmodell bzw. -schema) istdie Definition von Measures, Fakt-Beschreibungenund zugehörigen Dimensionen. Hierbei könneneinzelne Dimensionen, Measures und Beschreibun-gen auch in verschiedenen Sternen wieder verwen-det werden.

Abbildung 2 zeigt den fachlichen Stern „Aufträ-ge“ für ein Auftrags-DW. Der Stern „Aufträge“ umfasst die Measures „Umsatz“ und „Anzahl Ver-käufe“, die Fakt-Beschreibung „AuftragsNr“ und dieDimensionen „Zeit“ und „Region“.

AuswertungenFachliche Sterne sind nur Mittel zum Zweck – fürden Anwender bringen die Auswertungen der Daten fachlichen Nutzen. Abbildung 3 zeigt, wieAuswertungen über Modelle spezifiziert werden,und komplettiert damit das Bild der fachlichen Architektur.

Eine Auswertung besteht aus Beschriftungen,Filtern, Gruppierungs-Ebenen und Kennzahlen:

· Beschriftungen können Zeilen, Spalten und die gesamte Auswertung erläutern, zum Beispiel der Titel „Verkäufe jeRegion und Monat“.

· Filter (d. h. Möglichkeiten zur Parametrisierung) schränkendie dargestellten Kennzahlen ein. Im Beispiel:„Jahr = 2004“.

· Gruppierungs-Ebenen strukturieren die Daten des Reports.Sie bilden die Zeilen und Spalten einer Auswertung. Im Bei-spiel:„Region“,„Monat“.

· Kennzahlen definieren die eigentlichen Daten des Reports –sie bilden dessen Zellen.

Abb. 2 Fachlicher Stern „Aufträge“

Abb. 3 Übersicht Modellierung


Eine Auswertung wird auf der Basis von einemoder mehreren fachlichen Sternen spezifiziert – imBeispiel auf dem fachlichen Stern „Aufträge“.

Die fachlichen Sterne selbst werden – ausge-hend von Informationsanforderungen der End-anwender – auf der Basis von Datenmodellen(zum Beispiel E/R- oder OOA-Modellen) der ope-rativen Systeme spezifiziert. Die Spezifikationkann beispielsweise in Pseudocode wie folgt aus-sehen:

· Dimensionsbasis:Tag = Auftrag.Datum

· Measure:AnzahlVerkäufe = sum(Auftrag.AuftragsPosition.Anzahl)

· Fakt-Beschreibung:AuftragsNr = Auftrag.Nummer

Mit dieser Spezifikation schließt sich der Kreis, unddie Auswertungen sind präzise auf der Basis der Se-mantik der operativen Systeme definiert.

Theorie und PraxisDas Verständnis der theoretischen Grundlagen zurModellierung der fachlichen DW-Architektur hilft inder Spezifikationsphase eines DW-Projekts. Dennochgeht es leider in der Projektpraxis selten so einfachund strukturiert vor. Nachfolgend einige Beispiele:

· Fehlende Datenmodelle: Häufig existieren keine Datenmo-delle operativer Systeme oder sie liegen in einer schlechtenQualität (unvollständig, fehlende Semantik, etc.) vor. In derProjektpraxis muss man sich häufig auf die Suche machennach den Basisdaten für Auswertungen. Manchmal ist es dabei sogar Ziel führend, auf schon existierende Report-Strukturen der operativen Systeme direkt aufzusetzen.

· Inkonsistente Datenmodelle: Datenmodelle operativer Systemesind häufig untereinander semantisch inkonsistent. Noch viel

gravierender ist, dass das Verständnis unterschiedlicher Fachbe-reiche von identischen Begriffen häufig weit auseinander gehtbzw. fachliches Verständnis und implementierte Datenmodellenicht zueinander passen. Hier helfen nur umfangreiche Abstim-mungen und gegebenenfalls der Entwurf unterschiedlicherSichten für unterschiedliche Nutzerkreise auf Basis eines inte-grierten Datenmodells und klarer Begriffsabgrenzungen.

· Measure vs. Dimension: Die Entscheidung, ob ein Datum alsMeasure oder als Dimension abgebildet wird, ist eine De-sign-Entscheidung, die viel Erfahrung erfordert.Beispiel: Plan- und Ist-Umsätze können mit zwei Measures„PlanUmsatz“ und „IstUmsatz“ modelliert werden. Alternativkönnen ein Measure „Umsatz“ und eine Dimension „Umsatz-typ“ mit den Ausprägungen „Plan“,„Ist“ – und evtl. weiterenAusprägungen – verwendet werden. Die erste Variante istnatürlicher und performanter zu implementieren, die zweiteVariante ist jedoch flexibler und einfacher um weitere Aus-prägungen zu erweitern.

· Fakten- vs. Dimensionsbeschreibungen: Gruppen von Fakten-beschreibungen können auch als Attribute einer eigenenDimension modelliert werden. Beispiel: Kommen in obigemBeispiel zur „AuftragsNr“ noch Beschreibungen wie „Auf-tragstitel“ und „Bearbeitungsinstruktionen“ hinzu, könnteman hieraus eine eigene Auftragsdimension erzeugen bzw.Aufträge als Dimensions-Basis einer bereits bestehendenKostenstellendimension einfügen.

· Parallelhierarchien: Parallelhierarchien treten auf, wenn Dimensions-Elemente Verzweigungen haben. Ein klassischesBeispiel findet sich im fachlichen Stern Aufträge: WährendMonate eindeutig einem Jahr zuzuordnen sind, können Wochen nicht ohne weiteres Jahren zugeordnet werden.Eine Möglichkeit ist es, Wochen als Kalenderwochen eindeu-tig Jahren zuzuweisen. Man erhält dann in der Modellierungvon Dimensionselementen einen gerichteten azyklischenGraphen. Dies führt zu einer komplexen Modellierung mitverschiedenen Jahresdefinitionen. Alternativ kann man aufdie Aggregation von Wochen zu Jahren verzichten. Häufigführt die Verwendung von Parallelhierarchien zu Problemen

Abb. 4 Beispiel für ein Stern-Schema



bei der technischen Umsetzung und der Nutzung.· Dimensionen variabler Tiefe: Diese sind notwendig, wenn die

Dimensionselemente nicht statisch festgelegt werden kön-nen.

· Beispiel: Im operativen System wird ein Klassifkationssche-ma für Aufträge in Form eines Baums gepflegt. Die Außen-dienstmitarbeiter klassifizieren jeden gewonnenen Auftragdurch Auswahl und Zuordnung eines Baumelements. Im DWsollen Aufträge nach deren Klassifikation gefiltert und gruppiert werden. Modellierungstechnisch ist dies einfachumzusetzen mit einem Dimensionselement „Kategorie“ undder Einführung einer Rekursionskante von „Kategorie“ zu„Kategorie“. Eine performante technische Umsetzung ist je-doch schwierig.

Technische Architektur

Star-Schema und Snowflake-SchemaWird ein relationales Datenbankmanagementsys-tem (DBMS) für die Datenhaltung des DW verwen-det, so werden Fakten und Dimensionen klassi-scherweise nach einem Star Schema gespeichert.Abbildung 4 zeigt dies am Beispiel.

Für jeden fachlichen Stern wird eine Faktenta-belle angelegt. Diese enthält als Attribute die Mea-sures, die Fakt-Beschreibungen und Fremdschlüsselauf Dimensionstabellen für jede Dimension. Dieseenthalten denormalisiert jeweils alle Dimensions-elemente sowie weitere Dimensionsbeschreibungenals Attribute.

In einem Snowflake-Schema werden die Di-mensionstabellen durch Aufgliederung nach Hier-archiestufen (Dimensionselementen) normalisiert.Die Normalisierung im Snowflake-Schema gehtstark auf Kosten des performanten Zugriffs undder einfachen Darstellbarkeit durch DW-Frontend-Werkzeuge. Trotzdem hat ein Snowflake-Schemamit beschränkter Hierarchietiefe und in geeigneterKapselung vor dem Endanwender in speziellen An-wendungsfällen, etwa im Rahmen der Versionie-rung, durchaus seine Berechtigung.

Relational (ROLAP) versus multidimensional (MOLAP)

Außer relationalen DBMS werden auch multidi-mensionale DBMS zur Datenhaltung von DW eingesetzt. Zur Unterscheidung werden die BegriffeMOLAP (Multidimensional OLAP), ROLAP (Rela-tional OLAP) und HOLAP (Hybrid OLAP) verwen-det.

· MOLAP -Lösungen implementieren die multidimensionaleSicht auf Analysedaten physisch, indem die Fakten inklusiveZwischensummen und abgeleiteten Kennzahlen sequentia-lisiert in multidimensionalen Datenbanken (MDDB) gespei-chert werden. Zusammengehörende Fakten werden auch alsDatenwürfel (Cubes) bezeichnet.

· ROLAP -Lösungen implementieren fachliche Sterne in rela-tionalen DBMS, üblicherweise nach dem Star-Schema, selte-ner nach dem Snowflake-Schema oder anderen Schemata.Der Zugriff auf die Daten erfolgt entweder direkt über dieAnfragesprache des DBMS oder über eine ROLAP-Engine,die die angefragten Ergebnisdaten multidimensional aufbe-reitet und bei Maßnahmen zum Performance-Tuning unter-stützt.

· HOLAP bezeichnet die für den Benutzer mehr oder wenigertransparente Kombinationen von ROLAP- und MOLAP-Tech-nologien.

MOLAP bietet ein breites Funktionsspektrum fürmultidimensionale Operationen mit intuitiven Ana-lysesprachen. Derzeit unterstützen Produkte jedochnur ein begrenztes Datenvolumen. MOLAP ist zuempfehlen, wenn spezielle Funktionalität und hohePerformanz komplexer analytischer Auswertungenauf nicht zu großen Datenbasen gefordert, aber derAufwand für das Würfel-Update, also den Aufbauder multidimensionalen Strukturen aus den Basis-daten, unkritisch ist.

ROLAP bietet hohe Performance, Stabilität undBetriebssicherheit auch für große Datenmengen.Nur für komplexe multidimensionale Anfragen istder Befehlsumfang teilweise noch eingeschränkt.Die möglichst transparente Bereitstellung und Nut-zung von Voraggregierungen zur Performancestei-gerung – bis vor einigen Jahren noch ein großerPluspunkt von MOLAP – wird inzwischen auch vonden meisten ROLAP-Systemen gut unterstützt. Ins-gesamt ist ROLAP in der Regel die einfachere, kom-paktere, preisgünstigere und flexiblere Lösung.

Die großen ROLAP-Anbieter sind mit der Inte-gration von MOLAP-Technologien zu HOLAP-Lö-sungen mehr oder weniger weit fortgeschritten undkönnen darüber einerseits die Nachteile heteroge-ner Produktlandschaften (zum Beispiel Zusatzkos-ten für Administration und SW-Lizenzen) überwin-den und andererseits die Stärken beider Weltenvereinen.


Systemarchitektur

Die BI-ReferenzarchitekturErfolgreich in die fachliche und technische Anwen-dungslandschaft eines Unternehmens integrierteBI-Lösungen zeichnen sich durch eine klare Struk-tur aus. Unabhängig von den verwendeten Produk-ten weisen BI-Architekturen Gemeinsamkeiten auf,die wir in einer BI-Referenzarchitektur (Abb. 5) destilliert haben (vgl. auch [1]).

Die Referenzarchitektur ist modular und ser-viceorientiert aufgebaut. Services können von un-terschiedlichen Produkten oder Individuallösungenabgedeckt werden. Nach der Referenzarchitekturunterteilen wir ein DW in die drei aufeinander auf-bauenden Bereiche Data Integration, Data Manage-ment und Information Delivery/Analytic Applicati-ons. Daneben stehen Querschnittsfunktionen zumWarehouse Management.

Bereich „Data Integration“Operative Systeme eines Unternehmens bilden dieDatenquellen (Data Sources) für das DW. Beispielesind:

· Enterprise Resource Planning Systeme (ERP), z. B. SAP R/3,· Custom Appliations, z. B. das System für den Zahlungsverkehr

eines Finanzdienstleisters,

· Customer Relationship Management Systeme (CRM), zum Beispiel von Siebel,

· Externe Systeme, zum Beispiel zur Bereitstellung von Wäh-rungskursen,

· Weitere Anwendungen, zum Beispiel Microsoft Excel.

Data Integration stellt die Schnittstelle zu denQuellsystemen dar. Die Daten werden aus denQuellsystemen extrahiert, transformiert, qualitäts-gesichert und der DW-Datenhaltung zur Speiche-rung übergeben. Den Prozess der Datenintegrationbezeichnet man auch als ETL (Extraction, Transfor-mation, and Loading).

Man spricht von einer Staging Area (einem Ar-beitsbereich) als dem temporären Bereich in einerDatenbank oder dem Filesystem, in dem die Vor-verarbeitung der zu ladenden Daten stattfindet, be-vor sie in das Ziel-DW geladen werden. Ein derarti-ges Staging wird vor allem aufgrund der Komplexi-tät von ETL-Prozessen erforderlich.

Mitunter fließen die Ergebnisse des Transfor-mationsprozesses nicht direkt in das DW, sondernzunächst in ein Operational Data Store (ODS; [11]).Diese Datenbank bietet eine integrierte, konsoli-dierte, datenzentrierte Sicht auf die Quelldaten,beschränkt sich jedoch auf den jeweils aktuellenStand und ist typischerweise sowohl fachlich wieauch technisch relational modelliert. Sowohl die

Abb. 5BI-Referenz-architektur



Historisierung als auch die Umstrukturierung der Daten in eine denormalisierte, multidimensio-nale Sicht erfolgen in der Regel erst beim Laden in das DW. Ein ODS wird meist häufiger aktuali-siert als das DW und kann daher zur Unterstüt-zung operativ taktischer Entscheidungen auf Basiseines integrierten Datenbestands verwendet wer-den.

ETL wird heute durch ausgereifte Werkzeugeunterstützt. Die Zwischenablage in einer StagingArea verliert aufgrund der damit verbundenen höheren Laufzeit des Prozesses immer mehr an Be-deutung.

Besondere Bedeutung kommt dem Quality Management zu. Daten aus operativen Systemen ha-ben in der Praxis immer unterschiedliche, häufig auchsehr schlechte Qualität. Meist ist mit der Einführungeines DW auch eine umfangreiche manuelle Daten-pflege durch Fachbereiche notwendig. Systemtech-nisch muss das DW mit ungültigen, inkonsistenten,unvollständigen oder fehlenden Daten adäquat um-gehen. Hierzu dienen Verfahren zu Data Profiling,Parsing, Standardisierung und Matching/Data Clean-sing sowie zur Verifizierung von Datensätzen [2].

Bereich „Data Management“Das Data Management bildet den Kern des DW. Inihm sind die Geschäftsdaten, also die Inhalte fach-licher Sterne, sowie Metadaten des DW gespeichert.Die Speicherung der Geschäftsdaten im DW-Kernerfolgt üblicherweise auf Basis eines fachlich multi-dimensionalen Modells.

Zusätzlich können optional Geschäftsdaten in(ebenfalls multidimensional modellierten) DataMarts gespeichert werden. Data Marts schneidenbestimmte fachliche Ausschnitte aus dem Gesamt-datenbestand heraus und stellen diese für effizienteAuswertungen bereit. Sie können als separate Da-tenbanken/Schemata oder aber auch als Views aufden DW-Kern implementiert werden. Häufiger als der DW-Kern werden Data Marts auch tech-nisch multidimensional abgelegt (beispielsweise alsMOLAP-Würfel, die den Endnutzern zur Verfügunggestellt werden). Gerade in großen DW-Projektenwird oft ein großer DW-Kern entwickelt, aus demin einzelnen Projektstufen fachlich abgegrenzteData Marts abgeleitet bzw. geladen werden (Hub-and-Spoke-Architektur).

Bereiche „Information Delivery“ und „Analytical Applications“

Die Information-Delivery-Services extrahieren In-formationen aus den Daten und stellen sie den An-wendern in vielfältiger Form zu Verfügung:

· Predefined Reporting: Ausführung vordefinierter, in der Regelparametrisierter Standardberichte entweder auf Anfrageoder regelmäßig im Batch;

· Online Analytical Processing (OLAP): Ad-hoc-Formulierungvon Anfragen, Navigation durch den multidimensionalenDatenbestand mittels Slice & Dice, Drill-down und Roll-up;

· Data Mining: ungerichtete, teilweise automatisierte Untersu-chung und Analyse großer Datenmengen, um wichtigeMuster, Trends, Beziehungen und Regeln zu entdecken;

· Collaboration/Commenting: Unterstützung der Kooperati-on/Kommunikation von Anwendern bei der Datenanalyse,unter Anderem durch Speicherung von Annotationen imDW und vereinfachten Austausch von Analyseergebnissen.

Auch Analytical Applications erweitern die Funk-tionalität klassischer DW. Sie stellen Informationenin anwendungsspezifischen Zusammenhängen dar:

· Business Performance Management: Leistungsmessung derinternen und externen Prozesse durch definierte Metriken(z. B. Balanced Scorecards) mit dem Ziel der Optimierung vonGeschäftsprozessen;

· Forecasting/Simulation: Fortschreibung aktueller Kennzahlenin die Zukunft auf Basis flexibler Vorhersagemodelle;

· Budgeting/Planning: interaktiver Vergleich und Bewertungvon Planzahlen, What-If- und Break-Even-Analysen.

In der Regel erfolgt der Datenfluss unidirektionalaus dem DW zu den analytischen Anwendungen.In Ausnahmefällen (Commenting, Planning) werden jedoch auch Daten in das DW zurück ge-schrieben.

Von zunehmender Bedeutung ist auch derRückfluss aus dem DW in die operativen Systemezur Unterstützung taktischer Entscheidungen imtäglichen Geschäft ( Data Targets), zum Beispiel derRückfluss von Analyseergebnissen zur Kundenseg-mentierung aus dem analytischen CRM in das ope-rative CRM zur Durchführung von Kampagnen.

Bereich „Warehouse Management“Unter Warehouse Management verstehen wir diefür den Aufbau, Pflege und den Betrieb eines DWnotwendigen Querschnittsfunktionen:


· Meta Data Management: Verwaltung aller Metadaten desDW, insbesondere Metadaten-Austausch zwischen den ver-schiedenen DW-Komponenten bzw. Bereitstellung einer ge-meinsam genutzten, homogenen Metadatenbasis;

· Security: Dienste zur Authentifizierung (Benutzerkennung),Autorisierung (Zugriffskontrolle auf möglichst feingranula-rer Ebene) und evtl.Verschlüsselung – hierbei möglichst Un-terstützung eines Single Sign-on;

· Scheduling: Steuerung von DW-Prozessen, insbesondere ETLoder die regelmäßige Generierung und Verteilung von Be-richten;

· Systems Management: Werkzeuge für den Betrieb des DW,zum Beispiel zum Performance- und Auslastungs-Monito-ring sowie zur Archivierung und Datensicherung.

Von den Anforderungen zur konkretenArchitektur: Kernfragen des DW-Design

Die BI-Referenzarchitektur stellt eine Leitlinie fürdie Entwicklung konkreter DW-Architekturen dar.Sie ermöglicht es, in einer frühen Projektphaseschnell und effizient die notwendigen Services zubestimmen, den Umfang des Projekts zu umreißenund die grundlegenden Fragestellungen zur Absi-cherung eines erfolgreichen Projekts zu klären. Bei-spiele sind:

· Welche Anwendergruppen sollen das System nutzen? FürAnalysten/Controller eignen sich OLAP und Analytic Appli-cations. Für Manager ist eher Predefined Reporting adäquat;

· Wie viele Anwender bedienen das System und wie sind diePerformance-Anforderungen? Bei hohen Lastanforderungenist derzeit ROLAP der MOLAP-Technologie vorzuziehen;

· Wo arbeiten die Anwender? Arbeiten die Anwender inner-halb eines Unternehmensnetzwerks, so können lokaleDesktop-Anwendungen installiert werden. Andernfalls undauch bei großen Nutzerzahlen ist ein Browser-basierter Zu-gang notwendig;

· Wie ist die Heterogenität und Qualität der Quelldaten? Wieheterogen sind die Anwendergruppen mit ihren bisherigenBegriffswelten und Kennzahlsystemen? In jedem Fall müs-sen Maßnahmen zur Konsolidierung und zum Quality Ma-nagement aufgesetzt werden, sowohl systemtechnisch, abervor allem auch organisatorisch.

· Auf welcher Architekturebene soll das zukünftige Berichts-wesen/die Datenanalyse fachlich bzw. technisch aufsetzen:verbessertes Production Reporting auf den Quellsystemen,konsolidierte Sicht auf ein ODS, multidimensionale Analyseauf dem gesamten DW-Bestand oder einzelnen Ausschnit-ten (Data Marts)? Entsprechend sind Verarbeitungsprozesseund Komponentenschnittstellen zu gestalten.

· Ist ein Rückspielen von Analyseergebnissen in operative Systeme (Data Targets) geplant? Dann ist eine saubere Tren-nung von operativen und dispositiven Daten besonderswichtig. Falls sich durch die Einbindung der DW-Analysen indas Tagesgeschäft eine erhöhte Kritikalität der DW-Imple-mentierung ergibt, sind entsprechende Maßnahmen zur Si-cherstellung von Verfügbarkeit, Datenaktualität und Ausfall-sicherheit vorzusehen.

· Welche Information Delivery Dienste und Analytic Applica-tions sind geplant oder für die Zukunft angedacht? Danachist die Produktauswahl weitsichtig auszurichten.

· Sind der Drill-Through auf operative Daten und Real-timeAnalytics geplant bzw. für die Zukunft anvisiert? Dann ist diegesamte Systemarchitektur der Data Integration frühzeitigdarauf auszurichten. Eine nachträgliche grundlegende Um-gestaltung ist schwierig und aufwändig.

Noch wichtiger als derartige fachlich-technischeAspekte sind oft organisatorische Fragen zum Pro-jektvorgehen und DW-Betrieb – von Umfang undstetiger Weiterentwicklung einer DW-Lösung(„think big – start small“) über Einbettung in dieIT-Gesamtstrategie, Sponsoring im Management,Klärung von Verantwortlichkeiten und Abstim-mung der Erwartungshaltungen bis zur Einbindungder Fachabteilungen in die Planung. Dies ist nichtGegenstand dieses Artikels – s. aber dazu z. B. [2]oder [10].

DW-ArchetypenAus der Summe betrachteter Einzelaspekte einerDW-Implementierung ergeben sich typische Szena-rien mit ähnlichen Charakteristika. Das Bewusstseinum die fachliche Einordnung eines DW-Projekts er-leichtert den Rückgriff auf bewährte Modellierungs-und Designansätze. In der Regel treten mehrere die-ser so genannten Archetypen in Kombination in ei-ner konkreten DW-Implementierung auf:

· Transaktionsorientiert: Der Klassiker unter den DW, der sicheng am theoretischen Modell mittels Star Schemas imple-mentieren lässt. Die aus Buchungs- oder ähnlichen Syste-men importierten Quelldaten umfassen vordefinierte Fak-ten wie Mengen oder Umsätze.Typische Dimensionen sindStammdaten zu Kostenstellen und -arten, Zeitperioden, Pro-dukten etc., über die die Fakten in der Regel mittels Additi-on aggregiert werden können.

· Workflow-orientiert: Die Quelldaten des DW stammen ausWorkflow-Engines oder ähnlichen prozessunterstützendenSystemen. Diese liefern Status-/ Ereignis-Records und deren



Zeitstempel, die sich auf bestimmte Vorgänge beziehen, z. B.die Abwicklung eines Auftrags. Aus den Statusübergängenwerden Measures abgeleitet, zum Beispiel die Anzahl offe-ner Aufträge.

· Stammdatenorientiert: DW-Lösungen können auch (fast)ganz ohne Measures auskommen. Sollen nur Stammdaten(Kunden, Verträge, Produkte etc.) verwaltet und für DW-Aus-wertungen bereitgestellt werden, ist es sinnvoll, die Datenvon der normalisierten Repräsentation im operativen Sys-tem zu einer denomalisierten Darstellung für das DW zutransformieren. Dabei definieren die Faktentabellen als sogenannte „ factless fact tables“ lediglich die Verknüpfungenzwischen den entsprechenden Dimensionen.

· Anwendungsspezifisch: Beispiele sind Systeme zur De-ckungsbeitragsrechnung und zur Bilanzierung. Diese Syste-me unterliegen der Anforderung, dass sie die gleichen Zah-len liefern müssen wie die entsprechenden Finanzmoduleim operativen System. Dort sind oft Spezialregeln für dieAggregation (wie z. B. die Soll-Haben-Steuerung) imple-mentiert, die im DW ebenfalls explizit zu implementierensind. Kennzahldimensionen bilden Beziehungen zwischendiesen Measures ab. Abgesehen von derartigen Anwen-dungsspezifika gibt es viele Parallelen zum klassischentransaktionsorientierten DW.

Produkte

Best-of-Breed versus Tool SuiteAm Markt existieren zahlreiche BI-Produkte, so-wohl branchenspezifisch als auch -übergreifend, diewesentliche Dienste der BI-Referenzarchitektur ab-decken. DW-Produkte sind seit über zehn Jahrenauf dem Markt und haben mittlerweile eine hoheReife. Von daher ist der Produkteinsatz im Normal-fall einer Individualentwicklung vorzuziehen. DieAuswahl der passenden Produkte anhand priori-sierter Auswahlkriterien (Performance, Skalierbar-

keit, Funktionalität, Benutzungsfreundlichkeit, Inte-grierbarkeit, Support, Marktposition des Herstellersetc.) ist für ein Unternehmen eine verantwortungs-volle Aufgabe, da sie eine große Auswirkung aufdie Entwicklung, den Betrieb und die Nutzung derLösung hat [2, 19, 20]. Man unterscheidet die fol-genden Ansätze zum Produkteinsatz:

· Best-of-Breed: Für jeden Dienst der Referenzarchitektur wirdjeweils das für die Anwendung am besten geeignete Werk-zeug ausgewählt, auch wenn diese von unterschiedlichenHerstellern angeboten werden.

- Tool Suite: Es wird ein Hersteller ausgewählt, der eine inte-grierte Plattform mit allen wesentlichen Diensten der Refe-renzarchitektur anbietet.

Beide Ansätze haben Vor- und Nachteile, und esmuss jeweils im konkreten Anwendungsfall ent-schieden werden. Für eine Best-of-Breed-Lösungspricht die bessere funktionale Abdeckung, beson-ders bei fachlichen Spezialanforderungen. Für eineTool Suite sprechen reduzierte Integrations- undManagementaufwände. Derzeit ist davon auszuge-hen, dass vor diesem Hintergrund die Marktkonso-lidierung voranschreiten wird. Nur eine Handvollgroßer Anbieter (Kandidaten sind etwa SAS, Oracle,Microstrategy, Business Objects, Hyperion, Cognos,SAP, Informatica, Microsoft) werden sich durchset-zen, lediglich einige Spezialisten mit Nischenange-boten bzw. auf bestimmte Branchen oder Analyse-methoden zugeschnittenen BI-Lösungen (als „Plug-Ins“ für BI-Plattformen) werden überleben [7, 18,21].

ProduktlandkarteDie Kategorisierung von Produkten nach der BI-Referenzarchitektur hilft, Produkte mit ähnlicher

Abb. 6 Exemplarische BI-Produktlandkarte


Funktionalität zu vergleichen und zu einer Produk-tauswahl, sowohl nach dem Best-of-Breed-Ansatzals auch nach dem Tool-Suite-Ansatz zu kommen.Abbildung 6 zeigt eine solche vereinfachte Produkt-landkarte, in der exemplarisch einige aktuell wich-tige Produkte in der BI-Referenzarchitektur deneinzelnen Bereichen zugeordnet sind.

Das Funktionsspektrum der jeweiligen Produk-te ergibt sich aus dem abgedeckten Bereich der BI-Referenzarchitektur – Grad und Qualität der Ab-deckung sind auf einem feineren Detaillevel zu be-werten. Die Grenzen sind hierbei sicher fließend,da die meisten Anbieter zunehmend umfangreicheSuiten auf den Markt bringen und auch kaum einProdukt gänzlich ohne Warehouse-Management-Funktionalität auskommt:

· Im Bereich Data Management sind (neben Anbietern klassi-scher relationaler DBMS) Produkte zur Implementierungmultidimensionaler Datenbanken (MOLAP) wie HyperionEssbase oder Cognos Powerplay zu nennen. SAS ist ein klas-sischer HOLAP-Vertreter.

· Produkte zur Datenintegration wie Informatica PowerCenteroder Ascential DataStage ermöglichen den Zugriff auf eineVielzahl verschiedenartiger Datenquellen sowie die Trans-formation und Zusammenführung der Daten vor dem Ladenins DW. Derartige ETL-Tools können entweder spezifischenCode zur kombinierten Extraktion und Transformation aufSeite der Datenquellen generieren, als separater ETL-Serverzwischen Quellen und Ziel-DW den gesamten ETL-Prozesskoordinieren oder Transformationen und Ladevorgänge un-ter Nutzung der Zieldatenbank als ETL-Engine implementie-ren. Letztere Variante ermöglicht attraktive Lizenzmodelle/-kosten für Tool-Suiten von RDBMS-Anbietern.

· Angebote zum Information Delivery/Analytic Applications(zum Beispiel von Cognos oder Business Objects) sind oft-mals ihrerseits mehr oder weniger umfangreiche Suiten vonKomponenten für die verschiedenen Einzeldienste und ver-schiedene Anwendergruppen. Es können Sichten auf dasKern-DW sowie Analysen definiert, die Auswertungendurchgeführt und die Ergebnisse verteilt werden.Weiterhinwerden in der Regel ein personalisierbarer Zugriff überWeb-Browser sowie Möglichkeiten zur Einbindung in Porta-le oder andere Applikationen geboten.

· Tool Suites bzw. Plattformen bieten schließlich aufeinanderabgestimmte Einzelkomponenten zur Abdeckung aller Be-reiche der BI-Referenzarchitektur (wie zum Beispiel SAP-BWoder Oracle 9i) und/oder implementieren eine Plattform mitSchwerpunkt auf dem Data- und Warehouse Management,auf die andere Produkte und Lösungen aufsetzen können

(wie z. B. IBM DB2). In unterschiedlichem Umfang werdenvordefinierte Standardmodelle und -prozesse angeboten,die dem Anwender einerseits einen Teil von Design und Im-plementierung der spezifischen Lösung abnehmen, ihn aberandererseits auch in ein mehr oder weniger starres Korsettzwängen.

AusblickAnalyse- und entscheidungsunterstützende Syste-me haben eine lange Historie von über 40 Jahren.Während die ersten Analysesysteme als Teil deroperativen Systeme fest in diese integriert waren,wurden mit der DW-Architektur operative und dispositive Systeme strikt getrennt. Die system-technische Trennung von Zuständigkeiten war architektonisch ein entscheidender Fortschritt und bildete die Grundlage für umfangreiche Analysefunktionalität, z. B. Slice & Dice aufunterschiedlichsten Kennzahlen und enormen Datenmengen ohne Beeinflussung der Online Performance operativer Systeme.

Auf der anderen Seite reduziert die systemtech-nische Trennung der dispositiven Daten von denoperativen auch deren Aktualität. ETL-Prozesse wer-den häufig als nächtliche Batch-Läufe organisiertund erlauben daher nur die Tagesaktualität der dis-positiven Daten. Das ist für viele Anwendungsberei-che vollkommen ausreichend, z. B. für Analysen zurUnterstützung strategischer Entscheidungen. Darü-ber hinaus suchen aber immer mehr Unternehmenauch nach Analysemöglichkeiten zur Unterstützungtaktischer Entscheidungen des täglichen Geschäfts inEchtzeit. Dieser aktuelle Trend wird als Real-Time-Analytics (RTA) oder auch Active Data Warehousingbezeichnet. Einsatzfelder für RTA sind Geschäftspro-zesse mit hohem Anteil an Interaktion mit Kundenund Geschäftspartnern, z. B. Internet, mobile Diensteund elektronischer Wertpapierhandel.

Damit die Implementierung von RTA aber ar-chitektonisch in dem Sinn kein Rückschritt wird,dass operative und dispositive Systeme wieder eineuntrennbare Einheit bilden, ist eine Weiterentwick-lung der Datenintegrationstechniken und -werk-zeuge erforderlich. Neue Generationen von Produk-ten werden ihre Wurzeln sowohl in klassischemETL als auch in Techniken der Enterprise Applicati-on Integration (EAI) haben [3]. Dabei bleibt die BI-Referenzarchitektur unverändert, die Aktualisie-rung der dispositiven Daten erfolgt jedoch bedarfs-weise near-time oder real-time.



Die richtigen Entscheidungen zu treffen, so-wohl strategisch als auch taktisch, ist für jedes Un-ternehmen essentiell. Viele Unternehmen mit star-ken Bestrebungen zur Verbesserung ihrer Wettbe-werbsfähigkeit setzen heute erfolgreich und vielfäl-tig Business Intelligence ein und haben BI eng mitdem Geschäft des Unternehmens integriert. Dassentscheidungsunterstützenden Systemen nach ihrerlangen Historie auch noch eine lange Zukunft be-schert sein wird, ist keine gewagte Prognose.

Literatur1. Bauer, A.; Günzel H. (Hrsg.):„Data Warehouse Systeme – Architektur, Entwicklung,

Anwendung“, 2. Auflage. Heidelberg: dpunkt.verlag 2004.2. Bange, C.; Narr, J.; Keller, P.; Dahnken, O.:„BARC Studie Data Warehousing und Datenin-

tegration. 15 Software-Lösungen im Vergleich“. München: Oxygon Verlag 2003.3. Brobst, S.A.:„Enterprise Application Integration and Active Data Warehousing“, Pro-

ceedings of Data Warehousing 2002: From Data Warehousing to the Corporate Know-ledge Center. November 12–13. Heidelberg: Physica-Verlag 2002, S 15–23

4. Bulos, D.:„A new dimension“, Database Programming & Design, 6/1996, S. 33–375. Chen, P.P.:„The entity relationship model – towards a unified view of data“. ACM Tran-

sactions on Database Systems 1(1): 9–36 (1976)6. Coad, P.; Yourdon, E.:„Object-Oriented Analysis“.Yourdon, 1991.7. Dresner, H.; Hostman, B.; Tiedrich, A.; Buytendijk, F.:„Magic Quadrants for Business In-

telligence, 1H04“, Gartner Research, April 2004.8. Ester, M.; Sander, J.:„Knowledge Discovery in Databases.Techniken und Anwendun-

gen“. Heidelberg: Springer 2000.9. Grothe, M.; Gentsch, P.:„Business Intelligence – aus Informationen Wettbewerbsvor-

teile gewinnen“. Addison-Wesley 2000.10. Humm, B.; Zech, B.:„Architekturzentriertes Vorgehen für Integrationsprojekte“,

Lecture Notes in Informatics, Tagungsband GI-Jahrestagung 2004.11. Inmon, W.H.:„Building the Operational Data Store“. New York: John Wiley & Sons

1999.12. Inmon, W.H.:„Building the Data Warehouse“ 2nd edn. New York: John Wiley & Sons

2002.13. Imhoff, C.:„Mastering Data Warehouse Design“. New York: John Wiley & Sons 2003.14. Jarke, M.; Lenzerini, M.; Vassiliou, Y.:„Fundamentals of Data Warehouses“. Berlin

Heidelberg New York Tokio: Springer, Juli 2001.15. Kimball, R.:„The Data Warehouse Toolkit: The complete guide to dimensional model-

ling“, 2nd edn. New York: John Wiley & Sons 2002.16. Lehner, W.:„Datenbanktechnologie für Data-Warehouse-Systeme“. Heidelberg:

dpunkt.verlag 2002.17. Mucksch, H.; Behme, W.:„Das Data Warehouse-Konzept“.Wiesbaden: Gabler 2000.18. MetaGroup Deutschland GmbH:„Business Intelligence –Marktanalysie und Markt-

trends – Deutschland 2004“, 2004.19. „OVUM evaluates OLAP“, OVUM, 2003.20. Pendse, N.:„The OLAP Survey 3“. München: Oxygon 2003.21. Root, N.L.:„BI Platform Shootout“, IT View and Business View Brief, TechRanking, For-

rester Research, May 2003.22. http://www.omg.org/cwm23. http://www.rational.com/uml24. http://www.uml.org25. http://www.xmla.org

Documents

Architektur von Data Warehouses und Business · PDF fileInformatik_Spektrum_23_Februar_2005 3 HAUPTBEITRAG / ARCHITEKTUR VON DATA WAREHOUSES} Dieser Artikel stellt DW-Konzepte und