Oracle Data Warehouse. Konzepte und Methoden

Transkript

1 Oracle Data Warehuse Knzepte und Methden 1

2 Viele Wege führen nach Rm... 5 Die Bedeutung des Data Warehuse in heutigen Unternehmen 6 Vier wichtige Aspekte machen das Data Warehuse s erflgreich 6 Der Aspekt des Unternehmensweiten 7 Rlle und Eigenschaften haben sich permanten verändert 7 Operatinalsierung des Data Warehuse 8 Aktuelle Herausfrderungen vn Data Warehuse Architekturen 9 1. Flexibilität bei der Infrmatinsauswahl für die Endbenutzer 9 2. Bereitstellung Ressurcen, Kapazität und Perfrmance für Endbenutzer 9 3. Agilität bei der Bereitstellung vn neuen Infrmatinen für die Endbenutzer 9 4. Ksten und Effizienz bei Aufbau und Betrieb der Systeme 9 Das Schichtenmdell Schichten- Mdellierung im Data Warehuse: Effizienz durch Strukturierung vn Infrmatinen 3- Schichten- Mdell histrisch Die Mehrwert- Leistungen des Data Warehuse Trtz datenmdellierung bleibt die Gefahr vn Infrmatinschas Ziel die Erwartungen der Endbenutzer treffen Die Schichten im Detail Die Data Mart Schicht (User View Layer) Data Marts sind redundant und flüchtig Herleiten der multidimensinalen Mdelle eines Data Marts Schritt 1 (Fachanwenderfragen und Analysemdell) Schritt 2 (Geschäftsbjekt- Mdell) Schritt 3 (Multidimensinale Struktur, Fakten und Dimensinen) Schritt 4 Hinzufügen vn interessanten Referenzdaten (ptinal) Die Umsetzung des multidimensinalen Mdells in eine physische Speicherung Das Star- Schema Varianten des Star Schemas Degenerated Dimensin Factless Fact Table Empfehlungen für den Aufbau vn Faktentabellen Die Wahl der Granularität einer Fakten- Tabellen beieinflusst die Flexibilität der Abfrage Auslagern vn weniger häufig genutzt Attributen Umgang mit grßen Faktentabellen Histrisierung Schlüssel in Dimensinen Wahl der Schlüsselfelder Umschlüsselung Business Key Quellsysteme Umgang mit dem Aspekt des Operativen der Vrsysteme Umgang mit Datenqualitätsprblemen in den Vrsystemen Stage Schicht (Data Integratin Layer) Archivierung gelesener Sätze Generische Stage- Strukturen Operatinal Data Stre (ODS) Die (Kern- ) Data Warehuse Schicht (Enterprise Infrmatin Layer) Anwender erwünscht! Keine Angst vr Security und schlechter Abfrage- Perfrmance Security- Aspekte in der Data Warehuse Schicht (Enterprise Infrmatin Layer) Verhindern vn Datenchas: Management vn Infrmatinen in der Data Warehuse Schicht Klassifizierung vn Infrmatinen Hilfsmittel: Dkumenatin der Infrmatinen Organisatin der Daten in Tabellen und Partitinen

3 Partitining- Struktur und Varianten Range Partitining List Partitining Hash Partitining Sub- Partitining Partitin Wise Jin Reference - Partitining Interval Partitining Verwaltung vn Partitinen Indizierung im Data Warehuse In welchen Situatinen nutzt man im Data Warehuse Indexe bzw. Schlüssel? Index- Varianten Btree- Indexe Bitmap- Indexe Platzbedarf Star- Transfrmatin Glbale und lkale Indexe (Partitinieren vn Indexen) Prüfen, b ein Index benötigt wird der nicht W wird wie indiziert (Gesamtsicht) Data Marts Data Warehuse- Schicht (Enterprise Infrmatin Layer) Stage bzw. Integratins- Schicht Typischer Umgang mit Indexen im DWH aus der Sicht der ETL- Aufgabenstellung Benutzer- Sichten und Kennzahlensystemen (MViews) Einsatz vn Materialized Views anstelle vn Summentabellen Vrteile vn Materialized Views im Data Warehuse Kntext Bedienen unterschiedlicher Zielgruppe und Aufbau vn Kennzahlensysteme Erstellungs- und Aktualisierungsknzepte Benutzerabfragen autmatisch umlenken Query Rewrite Hierarchische Struktur einer Dimensin für das Rewrite nutzen Hilfsmittel um Materialized Views zu verstehen ETL Extraktin, Transfrmatin, Lad Datennahe Transfrmatinen für Daten- rientiertes Data Warehuse Daten der Przesse? Technische Mittel in der Datenbank Generieren statt Prgrammieren Die ETL- Aktivitäten und das Schichten- Mdell Phase 1 Kpieren Phase 2 Integrieren Phase 3 Infrmatins- Mehrwerte schaffen Phase 4 Sammeln Phase 5 Endbenutzersichten aufbauen Die Verteilung vn Ladeaktivitäten im Schichten- Mdell Stichwrt 1 zu 1 Kpien Wiederhlbarkeit des Ladelaufs Deltadatenerkennung Altbacken, aber immer nch die Masse aller Input- Daten für das Data Warehuse (External Tables) Schnelles Prüfen und Laden mit SQL- Mitteln Nutzen des Mengen Paradigmas Mengen- basiertes ETL Laden mit aktiven Cnstraints DML Errr Lgging Eindeutigkeit prüfen Typ- Frmat, Null- und Werte- Prüfungen Umschlüsselung vn Stamm- und Bewegungsdaten Einfache aber schnelle mengenbasierte SQL- Hilfsmittel (Multiple Insert und Merge) Prgrammiertes Parallelisieren (Pipe- Verfahren mit Table Functins) Schnelles Bewegen vn grßen Datenmengen innerhalb der Datenbank (PEL) Generieren statt Prgrammieren: Mit Graphik mdellieren

4 Umgang mit Hardware- Ressurcen im Data Warehuse Hardware wichtiger Bestandteil im Data Warehuse Private Hardware: ungeschriebene Regel Die Hardware- Knfiguratin Speicherhierarchien Infrmatin Life Cycle Management (ILM) Plattenplatz für Tabellen ptimieren und PCT_FREE Leseleistung messen Calibrate_IO Orin (Oracle IO Numbers) ASM (Autmatic Strage Management) RAC (Real Applicatins Clusters) Kstengünstige Ausfallsicherheit Warehuse- Przesse gezielt zuteilen Das System überwachen Autmatisiertes Schwellwert- Mnitring AWR Reprt ADDM Autmatic Database Diagnstic Mnitr Sessin- Infrmatinen abfragen Mnitring des Platzverbrauchs Dkumentatin Metadaten Repsitry zur Dkumentatin der Inhalte und Zusammenhänge Verwaltung vn Data Warehuse- Systemen Backup im Data Warehuse Stage / Integratin Layer Data Mart Data Warehuse Schicht und alle langlebigen Daten RMAN

5 Viele Wege führen nach Rm......aber es gibt längere und kürzere Wege Data Warehuse Systeme gehören heute mit zu den wichtigsten IT- Systemen eines Unternehmens. Sie haben sich etabliert und müssen ihren Nutzen nicht mehr unter Beweis stellen. Allerdings sind auch heute, nach fast 20 Jahren Data Warehuse- Erfahrung, die meisten Systeme Firmen- individuell knzipiert und erstellt, denn die Systeme gibt es auch heute nch nicht vn der Stange als Fertig- Sftware. Auf der anderen Seite gibt es kaum ein System, dessen Architektur s einfach zu standardisieren ist, wie die des Data Warehuse. Die vrliegende Darstellung zu dem Oracle basierten Data Warehuse stellt die Methden und Verfahren in den Vrdergrund, mit denen man Data Warehuse Systeme auf der Basis einer Oracle Datenbank entwerfen und aufbauen kann. Es sind nicht die technischen Features der Datenbank, die erklärt werden sllen, sndern die Möglichkeiten und Einsatzknzepte die zur Lösung der Aufgabenstellung Data Warehuse führen. Ein Data Warehuse ist ein System zur Beschaffung, Aufbereitung und Bereitstellung vn unternehmensweit anfallenden Infrmatinen. Dieser Text rientiert sich an diesem Infrmatinsbeschaffungsweg. Die ersten Kapitel legen ausführlich die Einteilung eines Data Warehuse Systems in mdellierte Schichten dar. Das erleichtert die Psitinierung der Datenbank- Technlgie in den flgenden Kapiteln, die s ihren Platz in der Schichtenarchtektur findet. Der Text richtet sich an Architekten und Planer vn Data Warehuse Systemen. Er ist swhl geeignet um Data Warehuse Systeme vn Grund auf neu zu mdellieren der auch um bestehende Systeme zu überprüfen. Es sind viele Punkte beschrieben, die dem Data Warehuse- Praktiker bekannt vrkmmen. In vielen Seminaren und Präsentatinen haben hier näher beschriebene einzelne Aussagen allerdings für umfangreiche Diskussin geführt. Denn der Text stellt an mehreren Stellen gewhnte Verfahren in Frage. Mit Recht: Data Warehuse- Systeme muss man heute mit anderen Rahmenparametern betrachten, als dies nch in den 1990er Jahren der Fall war. Die Oracle Datenbank ist sicher die am häufigsten verwendete Datenbank für Data Warehuse Systeme. Das liegt auch daran, dass sie sich swhl für OLTP als auch für Data Warehuse Systeme sehr gut eignet und man diese Datenbank hne Technikbruch als ein (!) zusammenhängendes Medium für beide Anfrderungen nutzen kann. Leider führt das ft zu einem pauschalen Datenbank- Einsatz hne die spezifischen Anfrderungen der Data Warehuse- Przesse zu berücksichtigen. Data Warehuse- Anfrderungen sind andere als OLTP- Anfrderungen. Nicht jedes Feature der Oracle- Datenbank macht auch in dem Data Warehuse Sinn und umgekehrt gibt es Funktinen, die besnders in Data Warehuse- Systemen Nutzen liefern. Ziel dieses Textes ist es deshalb auch, eine Data Warehuse spezifische Sicht zu vermitteln, damit die Oracle Datenbank s ptimal wie möglich die Anfrderungen in einem Data Warehuse unterstützen kann. Um den Umfang zu beschränken, ist auf die breite Darstellung vn Skripten der umfangreicher Kmmand- Syntax verzichtet wrden. Hierzu sllte man die Oracle Dkumentatin nutzen. Eine Sammlung mit den wichtigsten Hilfen (auch für Einsteiger) und lauffähigen Beispielen zu den hier besprchenen Themen kann zusätzlich vn dem Autr bezgen werden. Diese Skript- Sammlung ist eine Kurzreferenz, um immer wiederkehrende Kmmands hne langwierige Suche in der Dkumentatin der Internet an einer Stelle kmpakt zur Hand zu haben 1. 1 Diese Kurzreferenz sllte man während des Lesens zur Hand haben. 5

6 Die Bedeutung des Data Warehuse in heutigen Unternehmen Vier wichtige Aspekte machen das Data Warehuse s erflgreich Data Warehuse Systeme gehören heute zu den erflgreichsten Anwendungen in mdernen Unternehmen. Die Sinnhaftigkeit muss nicht mehr argumentiert werden. Während Business Intelligence Anwendungen ft nur für einzelne Fragestellungen stehen, hat das Data Warehuse System schn fast die Rlle eines zentralen Infrmatin- Pls übernmmen, in dem man alles ablegt, was abseits der knkreten perativen Przesse, abteilungsübergreifend relevant sein kann. Der Erflg der Systeme ist auch durch Mund- zu- Mund- Prpaganda entstanden: Es gibt da was an zentraler Stelle, da findest Du alles was Du brauchst. Da sind Daten in leicht zugänglicher Frm, die findest Du s nicht in Deinem Online- System. Und dann immer wieder: Liebes DWH- Team, könnt Ihr nicht auch nch Daten der Systeme X, Y, Z mit in das Warehuse aufnehmen?. Dann ist wieder passiert, was s typisch für gut funktinierende Data Warehuse Systeme ist: Ein Verfahren nach dem andern, wird an das Data Warehuse System angeschlssen. Und je mehr Systeme angeschlssen sind, ums mehr vermehren sich die Nutzen- Effekte des zentralen Data Warehuse. Um die histrisch gewachsenen Einflusssphären eines Data Warehuse- Systems festzustellen, müsste man es einfach mal abschalten. Wie lange wird es dauern, bis die ersten Beschwerden kmmen? Wer beschwert sich? Wie viel Druck entsteht, bis das System wieder läuft? 2 Für diese Erflgsgeschichte sind 4 Gründe anzuführen, die sich seit Bestehen der Data Warehuse- Idee in den 1990er Jahren nicht verändert haben: 1. Der erste ist der zentrale Charakter. Ein Data Warehuse ist meist das einzige System, in dem man unternehmensweit an einer einzigen Stelle eine umfassende und zusammenhängende Infrmatin erhält. Viele OLTP- Systeme beschäftigen sich dagegen nur mit einzelnen Sachgebieten und Fragenstellungen. Das Data Warehuse stellt jedch übergreifende Querverbindungen zwischen den Systemen dar. 2. Der zweite wichtige Vrzug des Data Warehuse Systems ist die verständliche Darstellung vn Infrmatinen. Während sachbezgene Anwendungen ihre Infrmatinen nur in ihrem speziellen Kntext verwalten, überführt ein Data Warehuse die spezifische Terminlgie der Fachanwendung in eine allgemein verständliche Frm und Sprache und macht sie s auch für Sachgebietsfremde Mitarbeiter, z. B. aus anderen Abteilungen, verstehbar. Darüber hinaus harmnisiert ein Data Warehuse Begriffe, Frmate, Betrachtungsebenen und Definitinen. Infrmatinen aus unterschiedlichen Sachgebieten können smit zusammenhängend benutzt werden, ein einheitliches unternehmensweites Gesamtbild entsteht. Die vier Hauptziele des Data Warehuse 3. Der dritte wichtige Aspekt vn Data Warehuse Systemen ist das Vrhalten vn histrischen Daten. Operative Anwendungen verändern ihre Daten permanent. Die Planung und weitere Ausrichtung der Aktivitäten eines Unternehmens erfrdern jedch eine vergleichende Betrachtung aktueller und histrischer Daten. Ein Data Warehuse wirft nichts weg. Man sieht, wie die wirtschaftliche Situatin ein Jahr zuvr war und kann sie mit der jetzigen vergleichen. Nur wer die Vergangenheit kennt, kann die Gegenwart bewerten und Entscheidungen für die Zukunft treffen. 4. Das vierte wichtige Merkmal vn Data Warehuse Systemen ist die Separierung vn Daten vn ihrem perativen Kntext. Durch dieses Weg- Kpieren kann man Daten unabhängig vn den perativen Anwendungen beliebig verändern und sie einer weiteren Verwendung zuführen. Operative Systeme bleiben dadurch unberührt. Für die Betrachtung und die Analyse der Daten wird bewusst ein zeitlicher Fixpunkt gesetzt. Man definiert damit einen zeitlichen Bezugspunkt zu dem man eine Aussage frmuliert und den man in Relatin zu anderen Bezugspunkten bringen kann. 2 Eine interessante Erfahrung wird es sein, wenn sich plötzlich Persnenkreise melden, mit denen man nicht gerechnet hat, denn ft werden die Daten aus Data Warehuse- Systemen an Stellen weiterverwendet, an denen man sie nicht vermutet hätte. Oft wird sgar das Tp Management dabei sein. Denn auch drt arbeitet man mit Daten aus dem Data Warehuse, hne dass man es weiss. 6

7 Viele aktuelle Diskussinen müssen sich an diesen vier Punkten rientierten. Ein Reprting, das direkt auf den perativen Systemen aufsetzt, ist kein Data Warehuse, weil keiner der vier Punkte berücksichtigt wurde. Die Diskussin um Real time- Reprting macht vergessen, dass Mehrwerte ft nur durch einen harmnisierenden, anreichernden und Qualitäts- sichernden ETL- Przess entstehen und das ist ft in Real time nicht zu machen. Es nützt dabei auch nichts, wenn alle Daten in den Hauptspeicher geladen werden. Der Aspekt des Unternehmensweiten Business Intelligence Lösungen werden meist mit Blick auf einzelne Sachgebiete der Abteilungen betrachtet. Data Warehuse Systeme begründen sich dagegen über einen unternehmensweiten Wirkungsbereich. Hier liegen die wesentliche Aufgaben und Mehrwerte. Es macht diese Systeme zu einem idealen Mnitring- Instrument für abteilungsübergreifende aber auch Zeiten- übergreifende Vergleiche. Unternehmen müssen heute in immer kürzerer Zeit geänderte der kmplett neue Geschäftspraktiken anwenden, um erflgreich zu sein. Diese permanenten Änderungen erfrdern ein stabilisierendes Kntrllinstrument, um Fragen zu beantwrten wie: Welche Bereiche/Prduktlinien sind über lange Zeiträume prfitabel? Haben sich neue Prduktinsverfahren gegenüber früheren bewährt? Gibt es territriale Veränderungen bei der Geschäftsentwicklung? Direkt betrffenen Fachmitarbeiter können ft nur schwer aus ihrem unmittelbaren Aktinsfeld heraus abstrahieren und räumlich der zeitlich entfernte Sichten einnehmen. Hier bietet das Data Warehuse eine unternehmensweite, sachgebietsübergreifende und auch histrische Datensammlung an, um die nötige Abstraktin vn der direkten Jetzt- und Hier- Erfahrung zu ermöglichen. Ein Data Warehuse wirkt als Schnittstelle zwischen vielen Unternehmensprzessen S lassen sich schneller Fehlentwicklungen erkennen. Ein frühzeitiges Gegensteuern ist möglich. Dies verdeutlicht, wie wichtig es ist, möglichst alle Geschäfts- (Erflgs- ) relevanten Przesse an ein Data Warehuse anzuschließen, d. h. Daten aus diesen Przessen in das zentrale System zu überführen. Ums besser kann das System seine übergreifende Mnitring- Funktin erfüllen. Ein zentrales, unternehmensweites Data Warehuse kann flgende zusätzliche Funktinen bzw. psitive Effekte liefern: Unternehmensweit gemeinsame, standardisierte Infrmatinen Glssare / Definitinen als Nachschlagewerk Standardisierte Begriffe und Hintergründe zu Kennzahlen Gleiches Verständnis über den Inhalt vn Kennzahlen und Sachverhalten Gemeinsam genutzte Berichte Gleicher aktueller Kenntnisstand Beschleunigte und zeitgleiche Infrmatinsweitergabe Minimierter Kmmunikatinsaufwand Verhindern vn Infrmatin Hiding bestimmter Stellen, weil Infrmatinen durch die Zentralität allen zur Verfügung stehen (Demkratisierung durch gleiche Infrmatinen) Reduzierung des Aufwands für die Infrmatinsbeschaffung Wiederverwendung vn bereits an anderer Stelle erstellten Infrmatinen Weniger Reibungsverluste bei abteilungsübergreifenden Przessen Rlle und Eigenschaften haben sich permanten verändert Man spricht seit Anfang der 90er Jahre vn Data Warehuse Systemen. Aufgrund der vrgenannten psitven Eigenschaften finden die Systeme eine immer weit reichendere Verwendung. Dienten sie ursprünglich nur dem Reprting auf einer strategischen Ebene und füllten Mnats- /Quartalsberichte, s sind Warehuse - Systeme heute ft zusätzlich direkt mit perativen Anwendungen verzahnt. Viele Fachmitarbeiter, ausserhalb vn Cntrlling der Planungsstäben haben das verlckende Infrmatinsangebt des Data Warehuse erkannt und wllen mit ihren Geschäftsprzessen angedckt werden. Das führte zu neuen Datenbereichen und auch zu einer feineren Granularität der Daten, denn auf der perativen Ebene stehen meist knkrete Transaktinen bzw. Geschäftsvrfälle im Vrdergrund, die auch in dem Data Warehuse auffindbar sein sllen. 7

8 Die Rlle des Data Warehuse ist heute umfassender gewrden Die Flgen sind kürzere Betrachtungszeiträume (der Zeitpunkt des Geschäftsvrfalls wird wichtig) und zwangsläufig ein massives Anwachsen der Datenmengen. Data Warehuse- Systeme sind heute die am schnellsten wachsenden Anwendungen mit deutlich sichtbaren finanziellen Flgen in den IT- Budges. Dies erklärt die z. T. angestrengte Suche vn IT- Verantwrtlichen nach Alternativen für hchvlumigen Speicher und ressurcen- effizienten Lösungen. Neben der Betrachtung vn fachlichen Aspekten bei der Gestaltung und Mdellierung vn Warehuse- Systemen spielt heute daher auch die Betrachtung vn Hardware- und Ksten- Aspekten eine bedeutende Rlle. Operatinalsierung des Data Warehuse Diese geänderte Verwendung kann man auch als Operatinalisierung des Data Warehuse bezeichnen, in Ergänzung zu der ausschließlich dispsitiven Aufgabenstellung in den Anfangsjahren. Als die Nutzung des ursprünglich für dispsitive Zwecke entwrfenen Systems für perative Aufgaben. Beispiele für perative Verwendung vn Data Warehuse- Systemen Das Hervrheben dieses Aspekts zielt vrallem auf die in einem Data Warehuse verwendetet Datenhaltungsplattfrm. In der Vergangenheit belieferten die Systeme wenige Persnen mit aggregierten Infrmatinen über größere Zeitabstände hinweg. Heute bewegt sich das Data Warehuse schn nahe an den Anfrderungen an perative Systeme mit vielen Benutzern, sehr grßen Datenmengen und permanenten Änderungsvrgängen. War es früher gebten eine separate für aggregierte Auswertungszwecke passende Datenhaltung zu wählen, ist es heute wichtig nicht mehr zwischen einer Datenhaltung für perative und dispsitive Zwecke zu unterscheiden. Heute ist es wichtig eine für OLTP und Data Warehuse- Zwecke durchgängig einheitlich nutzbare Datenhaltungs- Kmpnente einzusetzen, weil beide Anfrderungen durchmischt, eng verzahnt und kaum nch trennbar sind. Hinzu kmmt die immer geringere Zeit, die bleibt, um Daten aus einem perativen Verwendungkntext in einen dispsitiven zu überführen. Die Oracle Datenbank erfüllt genau diese Anfrderung. Ursprünglich für perative Zwecke entwickelt, hat sie sich seit dem Release 7 (1994) kntinuierlich auch als ideale Data Warehuse- Plattfrm etabliert und ist heute die am meisten verwendete Datenhaltung für ein Data Warehuse. 8

9 An DWH - Systeme werden im Zuge der Operatinalisierung des DWHs heute auch OLTP- artige Anfrderungen gestellt Aktuelle Herausfrderungen vn Data Warehuse Architekturen Vr der Darstellung der Mdellierung und Architektur, sllten aktuelle Prblemstellungen skizziert werden, denn darauf müssen die Mdellierung und eine Architektur reagieren. 1. Flexibilität bei der Infrmatinsauswahl für die Endbenutzer Data Warehuse Systeme präsentieren sich gegenüber Endanwendern meist über eine Reihe vn technischen Datenbanktabellen, die im besten Fall durch ein Business Intelligence Tl vr dem Zugriff und den Blicken der Endanwender abgeschttet sind. Diese Tabellen stellen die maximal verfügbare Infrmatin für Abfragen dar. Ist eine Infrmatin nicht da, dann kann sie auch nicht abgefragt werden. Ziel eines guten Data Warehuse Designs ist es, das Infrmatinsangebt des Data Warehuse s breit zu spannen, dass Endbenutzer möglichst alles, was sie interessiert auch in den Daten finden. Gerade in grßen Unternehmen kann das schwer sein, weil die Mdellierer der Infrmatinsstruktur in dem Data Warehuse nicht mit allen Endanwendern in Kntakt treten können. Ums wichtiger ist es, Datenmdelle zu entwerfen, die eine möglichst hhe Menge an unterschiedlichen Abfragen ermöglichen. Gleichzeitig dürfen die Mdelle nicht zu kmplex sein, weil man die Endanwender wegen der Kmplexität und Unhandlichkeit überfrdern und verlieren kann. Multidimensinale Mdelle (z. B. Star Schema) erfüllen diesen Zweck. Sie vereinen Einfachheit (Orientierung an Geschäftsbjekten) und eine hhe Menge an ptentiellen Abfragen. 2. Bereitstellung Ressurcen, Kapazität und Perfrmance für Endbenutzer Schwache Hardware Ressurcen führen zu schlechter Abfrageperfrmance, der auch zur Einschränkung der Online- Verfügbarkeit des Data Warehuse- Systems, weil die Zeit, in der das System aktualisiert der auch gesichert wird, zu lange dauert. Gemeint ist auch, dass nicht genügend Abfragen parallel gestellt werden können um Zeit zu sparen. Die Arbeitszeit des Anwenders sllte ptimal genutzt werden. Hier helfen extrem leistungsfähige Systeme, die dem Anwender die Abfrage- Ressurce dann zur Verfügung stellen, wenn er sie benötigt. Das kann bedeuten, dass Online- Abfragen in der Zeit beantwrtet werden müssen, die der Anwender braucht, um eine neue Anfrage zu frmulieren, als echtes interaktives und Adhc- Auswerten der Daten. 3. Agilität bei der Bereitstellung vn neuen Infrmatinen für die Endbenutzer Vn Endanwendern wird Kreativität gefrdert, neue Ideen sllen zusätzliche Marktchance eröffnen der Przesse verbessern. Deswegen wllen sie immer neue Infrmatinen aus dem Data Warehuse geliefert bekmmen und frmulieren Anfragen für neue Tabellen, Spalten und Kennzahlen der dem Anschließen neuer Datenquellen. Weil zentrale IT- Abteilungen mit der Erfüllung dieser Wünsche nicht Schritt halten können, helfen sich Fachanwender dann selbst, indem sie sich eigene Datenbestände anlegen. Dieses Phänmen ist bei fast allen Warehuse- Umgebungen mehr der weniger zu erkennen. IT- Abteilungen reagieren ft hilfls mit kurzfristigen Lösungen, in dem sie neben dem knslidierten Data Warehuse zusätzliche separate Datenbanken bereitstellen, in denen sie den Anwendern freie Hand lassen. Anwender mutieren zu Prgrammierern ihrer eigenen Auswertesysteme. Das Ergebnis sind zusätzliche Ksten für Hardware, zusätzliche Datenkpier- Läufe (1:1- Kpien) und nicht abgestimmte Kennzahlen, weil jeder nach eigenen Vrstellungen Zahlenwerke aufbereitet. Eine slche Vrgehenswese höhlt Sinn und Zweck des zentralen Data Warehuse aus. Den Druck, der zu slchen Situatinen führt, wird man nicht ganz abstellen können. Man kann ihn aber durch ein gewisses Infrmatinsmanagement mildern: Ein erstes Mittel hierzu ist die Dkumentatin aller Infrmatinen, die in dem Data Warehuse vrhanden sind. Das sind Listen aller Kennzahlen, aller Referenzdaten, aller Stammdaten mit ihren Ausprägungen, die in dem Data Warehuse vrhanden sind. Wenn man eine bereits bestehende Infrmatin über eine gute Dkumentatin wiederfindet, braucht man sie nicht mehr neu zu beschaffen. Ein weiteres Mittel ist die Aufteilung des Data Warehuse in eine zentrale, granular gehaltene Warehuse- Schicht und eine Endbenutzersicht. Die Warehuse- Schicht stellt die Obermenge aller Infrmatinen in dem Data Warehuse dar. Es muss leicht und einfach sein, aus diesem Pl an Daten, die passenden Infrmatinen für eine neue Anfrage zu liefern hne gleich in die Vrsysteme greifen zu müssen. 4. Ksten und Effizienz bei Aufbau und Betrieb der Systeme Die finanziellen Belastungen vn Data Warehuse Systemen sind in den letzten Jahren besnders unter die Lupe genmmen wrden. Die Ksten sind in dem Data Warehuse aufgrund der hhen Datenmengen sehr hch. Um nch perfrmant arbeiten zu können,schafft man 9

10 größere Maschinen an und die Ksten steigen erneut. Viele Hersteller vn DWH- Kmpnenten finden ffene Ohren, wenn sie Wege und Mittel aufzeigen, um Ksten zu sparen. Und: Data Warehuse- Systeme gehören whl zu den Systemen, die am ineffizientesten mit Ressurcen umgehen. Dafür kann man fast in jeder Umgebung eine Reihe vn Beispielen liefern. Das können sein: ein ungeschickter, unüberlegter Tl- Einsatz nicht genutzte Features der Mittel in der Datenbank die Anwendung falscher Verfahren z. B. beim Backup Mehrfachaufwand durch mangelnde Dkumentatin usw. Hier helfen meist einfache Maßnahmen, geschultes Persnal, pragmatisches Vrgehen. Wer weiß z. B. genau welche Daten in dem Data Warehuse wirklich genutzt werden? Wenn man das weiss, kann man Plattenplatz, ETL- Läufe und Verwaltungsaufwand sparen. Das bedeutet: Verbesserungsptentiale sind genügend da. 10

11 Das Schichtenmdell Data Warehuse Systeme sind nicht einfach nur eine Ansammlung vn Daten der ein Haufen vn nach Bedarf zusammenkpierten Tabellen. Das Data Warehuse repräsentiert eine Art Infrmatinsbeschaffungsweg und ist eher als Przess zu verstehen. Der Przess ist nicht zufällig, sndern flgt immer wieder gleichen Regeln und Methden. Schichten- Mdellierung im Data Warehuse: Effizienz durch Strukturierung vn Infrmatinen Das Hauptziel vn allem Tun im Data Warehuse, ist es den Endbenutzer mit Infrmatinen zu versrgen. Es muss klar sein welchem Benutzer welche Infrmatin wann und für welche Aufgabenstellung geliefert werden. Zu diesem Ziel kann man mehr der weniger effizient gelangen. Effizienz wird durch Synergien erreicht und Synergien entstehen durch möglichst frühzeitiges Erkennen gleicher Schritte, damit sie nur einmal zu bewältigen sind. Ein Hilfsmittel dazu ist das Schichtenmdell. Das Schichtenmdell teilt das Data Warehuse methdisch begründet in mehrere Schichten, in denen die enthaltenen Daten durch entsprechende Bearbeitungsschritte aus ihrer ursprünglichen Frm in den perativen Systemen in eine benutzergerechtere Frm für die Endbenutzer überführt werden. Vr allem in unternehmensweit aufgestellten Data Warehuse Systemen hat sich die Aufbereitung der Daten in drei Schritten bewährt: 1) Man sammelt, integriert und prüft auszuwertende Daten der perativen Vrsysteme. (Stage der Data Integratin Layer genannt). 2) Man granularisiert diese Daten in einem alle Sachgebiete umfassenden (in Richtung 3 NF tendierenden) - Schema. (DWH- Schicht der Enterprise Infrmatin Layer genannt). 3) Je nach Zielgruppe und Sachgebiet fügt man im letzten Schritt die granularen Infrmatinsbausteine meist zu multidimensinalen Endbenutzer- Mdellen (meist Star Schemen) zusammen. (Data Marts der User View Layer genannt). Diese Ressurcen- schnende Vrgehensweise zielt auf die Wiederverwendung vn Daten und Entwicklungsarbeiten in einer zentralen Schicht, bei gleichzeitiger Flexibilität durch beliebige Auswerte- Szenarien in der Data Mart- Schicht. 3 Schichten- Mdell Das Ziel der 3- Schichten- Architektur ist der Entwurf einer möglichst umfassenden, mehrere Unternehmens- und Themenbereiche abdeckenden stabilen Infrmatinsablage, die in kurzer Zeit knslidierte Berichte und Analysen für alle (!) Zielgruppen des Unternehmens bereitstellt. Das 3- Schichten- Mdell gibt dem Data Warehuse die Möglichkeit, Infrmatinen zunächst zu harmnisieren und zu vereinheitlichen, bevr sie in Business Intelligence Systemen ausgewertet werden, srgt für eine zeit- und Phasen- überdauernde Knstante, während sich Geschäftsprzesse wesentlich häufiger verändern, kann durch das Ausnutzen vn Synergien Aufwand und Zeit sparen. Allerdings wächst heute auch Kritik an diesem Mdell: Zu viele redundante Daten (Daten werden zwar in unterschiedlicher Frm, aber dch vn ihrem Inhalt her redundant in den unterschiedlichen Schichten vrgehalten) Gefahr für höherer Latenzzeiten (durch den vermehrten Aufwand für datentransfrmatinen und Kpien) Hher Entwicklungsaufwand (für mehr Transfrmatinen und mehr Tabellen) Diese Punkte sllten ernst genmmen werden, da sie in manchen Diskussinen die unbestreitbaren Vrteile des 3- Schichten- Mdells überlagern können. Im Ergebnis können dann heutige Lösungen wie Lösungen aus den 1980ern aussehen, bei denen Daten direkt aus den perativen Systemen in die prprietäre Speicherung bestimmter BI- Tls gelangen. Die Intentin dieser kritik ist berechtigt: Sie will Daten schneller und mit weniger Aufwand zu dem Enbenutzer bringen und ihn damit besser unterstützen. Dieses Ziel sllte jedch nicht erreicht werden, indem man gleich die Ziele des Data Warehuse (stimmige, knslidierte, leicht verständliche Daten) abschafft, sndern, indem man das Data Warehuse effizienter macht. Um Synergie- Effekte möglichst kmplett zu nutzen empfiehlt Oracle alle 3 Verarbeitungsschritte bzw. Schichten in einer einzigen Datenbank- Instanz und damit auch Hardware- Umgebung anzusiedeln. 3- Schichten- Mdell histrisch Dieses 3- Schichten- Mdell hat sich aufgrund der Erfahrungen, seit den 1980er Jahren entwickeln. Hatte man ursprünglich direkt auf den perativen Systemen ausgewertet, stellte man fest, dass es günstiger war, Auswertungen auf Kpien der perativen Daten durchzuführen. Dann passten die separat erstellten Auswerteergebisse auf separaten Datenkpien der unterschiedlichen Sachgebiete nicht zusammen und es fehlten einheitliche sachgebietsübergreifende Auswertungen. Letztlich führte man eine einheitliche, zentrale und sachgebietsübergreifende Warehuse- Schicht ein, um Infrmatinen zunächst zu sammeln und zu knslidieren, bevr man dann wieder 11

12 in die sachgebietsgebzgene Auswertung ging. Dieses Prinzip hat sich bei den meisten unternehmensweit aufgestellten Data Warehuse- Systemen seit Ende der 1990er Jahre etabliert und ist heute ein nicht mehr in Frage gestellter Standard. Die Mehrwert- Leistungen des Data Warehuse Auf dem Weg zu den Benutzern durchlaufen perative Daten mehrere Wandlungsschritte in den einzelnen Warehuse- Schichten. Operative Systeme nutzen Daten für ihre Zwecke ideal zusammengesetzt und auch nur diejenigen Daten, die sie wirklich benötigen. Für Analysten der Mitarbeiter, die eine unternehmensweite, przessübergreifende Aufgabe verflgen, reicht das nicht aus, bzw. die Daten sind ft wenig verständlich. Das Data Warehuse löst diesen Knflikt. Der Wandlungsprzess im Data Warehuse löst die Datenstrukturen der perativen Systeme auf und überführt die Kerninfrmatin in eine Frm, die leicht und flexible für unterschiedliche Zielgruppen und deren Bedürfnisse neu kmbiniert werden kann. Man bedient sich der Hilfsmittel aus der Datenmdellierung, mit denen man perative Daten in einem ersten Schritte in die kleinsten möglichen Infrmatinsbausteine zerlegt (Nrmalisierung in Richtung 3 NF) und dann je nach Endbenutzeranfrderung wieder neu kmbiniert. Die Vrgänge finden bei dem Übergang vn Stage zur DWH- Schicht (Nrmalisierung) und vn der DWH- Schicht in die Data Mart- Schicht (Denrmalisierung) statt. Die Daten in der zentralen Data Warehuse- Schicht sind anwendungs- und Endbenutzer- neutral. Gleichzeitig reduziert das Data Warehuse die Menge der zur Verfügung stehenden perativen Daten, da nicht alle auswerte- relevant sind. Dieses Verständlich- machen vn perativen Daten ist eine wichtige Mehrwertleistung des Data Warehuse. Trtz datenmdellierung bleibt die Gefahr vn Infrmatinschas Nrmalisierungs- / Denrmalisierungsprinzip im Data Warehuse Das Nrmalisierungs- /Denrmalisierungsverfahren verhindert nch nicht ein ptentielles Infrmatinschas im Data Warehuse. Denn aufgrund der sg. Hmnymen- /Synnymen- Prblematik können bei einem unklaren Begriffsverständnis unerkannt Infrmatinen mehrfach in einem Data Warehuse abgelegt sein. Diese Gefahr ist ums größer, je mehr Przesse und Abteilungen an dem DWH- System angeschlssen sind. Hier helfen: Glssars mit abgestimmten Begriffsdefinitinen Deskriptren- Verfahren zur Standardisierung und für das Wiederauffinden vn Begriffen Metadatenmanagement Datenqualitätsstandards Ziel die Erwartungen der Endbenutzer treffen Die Erwartungen der Endbenutzer an die Infrmatinen des Data Warehuse gehören zu den Schlüsselaufgaben. Diese Erwartungen richtig zu treffen ist ein sich wiederhltender Entwicklungsschritt. Die erwarteten Infrmatinen muss man aus den Fragestellungen und Przessbeschreibungen der Fachanwender herleiten. Ein Data Warehuse ist jedch nach den Knstruktinsprinzipien vn Datenstrukturen knzipiert und bildet die Infrmatinen zu den Objekten der Geschäftsprzesse ab, nicht aber die Geschäftsprzesse selbst. Ein wichtiger Mdellierungsschritt ist daher das Identifizieren der richtigen Geschäftsbjekte und die IT- technische Beschreibung der Geschäftsbjekte und das Darstellen mittels leicht verstehbaren und leicht auswertbaren Datenmdellen bzw. Tabellenstrukturen. Der Data Warehuse- Mdelliere entwirft daher zunächst meist multidimensinale Mdelle für die Data Mart Schicht (User View Layer). Damit ist der Infrmatinsbedarf der Fachanwender beschrieben und eingegrenzt. Diese Endanwender - Mdelle bilden dann die Grundlage für die zentrale Data Warehuse Schicht, die eine Obermenge aller Infrmatinen vn allen Data Marts darstellt. 12

13 13

14 Die Schichten im Detail Die Data Mart Schicht (User View Layer) Der Hauptzweck der Data Mart- Schicht (User View Layer) ist die Endbenutzer- gerechte Aufbereitung der Warehuse- Daten. Gegenüber der Data Warehuse- Schicht (Enterprise Infrmatin Layer) entstehen keine zusätzlichen Infrmatinen. Aber die Datenmdellart und die Granularität der Daten kann sich ändern. Als Datenmdellart bevrzugt man multidimensinale Mdelle (Star- Schema, Snwflake), weil diese für Endbenutzer intuitiver sind. Ziel der Mdellierung eines Data Mart ist es, s viele Abfrage- Ergebnisse wie möglich präpariert zu haben bevr der Anwender seine Abfragen frmuliert. Deswegen ergänzt man multidimensinale Abfragemdelle auch durch vrbereitete Kennzahlen- Tabellen, die man in dem Oracle Data Warehuse meist als Materialized Views erstellt. Kennzahlenbäume sind aufeinander aufbauende Materialized Views. Die Eigenschaften der Data Mart- Daten und Mdelle sind: Mdell- Varianten im User View Layer Alle Datenmdell- Varianten können vrkmmen, meist multidimensinal (Star) Star, Snwflake, Ansammlung einzelner Tabellen, Cubes Außer 3 NF- Mdelle Abfrage- /End User- rientierte Namen und denrmalisierte Daten. Sie rientieren sich an den dem Endbenutzer bekannten Geschäftsbjekten. Teils temprär. Data Marts werden eventuell nur bei Bedarf neu aufgebaut. Data Marts können histrisiert sein (wenn nicht in der Warehuse- Schicht bereits histrisiert wurde). Die Daten sind redundant zur DWH- Schicht. Data Marts sind redundant und flüchtig Aufgrund des 3- Schichten- Knzeptes sind Data Marts prinzipiell redundant. Daher ist die Frage berechtigt, b zu jedem Zeitpunkt alle Data Marts auch physisch vrhanden sein müssen, der nur dann, wenn Endbenutzer die Marts benötigen. Um Ksten zu senken, können Data Marts auch auf Anfrderung erzeugt werden (Dynamische Data Marts). Die Data Marts kmplett neu aufzubauen erleichtert die Verwaltung und das Laden eines Data Marts. Denn: Es sind keine Updates, sndern nur Inserts (schnelles Insert Append 3 ) in der Datenbank nötig. Das schnelle Neuaufbauen erflgt als sgenannter Massenladevrgang und ermöglicht das leichte Kmprimieren der Daten (Standard- Cmpressin Funktin der Oracle Datenbank). Durch regelmäßiges Neuaufbauen wird das Ansammeln vn alternden Daten verhindert. Es befinden sich nur wirklich benötigte Daten in dem Data Mart und teurer Plattenplatz wird gespart. Herleiten der multidimensinalen Mdelle eines Data Marts Data Marts stellen verständlichen Daten für Endbenutzer bereit. Das bedeutet, dass die Infrmatinen in der Sprache der Anwender und als Kmbinatin vn Geschäftsbjekten und den Aktinen rund um die Geschäftsbjekte präsentiert werden. Gleichzeit müssen diese Infrmatinen s flexibel angebten werden, s dass alle Infrmatinsbedürfnisse des Benutzers abgedeckt sind. Eine Umsatzangabe sll z. B. nicht nur bezgen auf ein Stück vrhanden sein, sndern auch in einer gewissen Verpackungsmenge, Gebindemenge, Liefereinheit, bezgen auf Lagerfläche, bezgen auf Verkaufseinheiten usw. Aber auch bezgen auf Tage, Mnate und Jahre und bezgen auf Filialen, Orte, Reginen, Länder usw. Je breiter slche Auswahlmöglichkeiten gespannt sind, ums flexibler ist die Nutzung der Daten durch die Endbenutzer. Eine der wichtigsten Aufgaben bei dem Design vn Data Warehuse Systemen ist daher das Erfrschen der Erwartungshaltung und Bedürfnisse der Endanwender. Ziel ist nicht möglichst viele Daten des Unternehmens im Data Warehuse zu speichern, sndern diejenigen Daten, die die Endbenutzer jetzt und wahrscheinlich auch in der Zukunft abfragen wllen. Diese Aufgabe löst man durch das Entwickeln vn multidimensinalen Mdellen gemeinsam mit den Fachanwendern. Die Aufgabe gliedert sich in 4 Schritten: 3 Ein Insert mit dem Hint APPEND ist ein schneller, sg. mengenbasierter Vrgang in der Oracle- Datenbank. 14

15 1. Analyse Fachanwenderfragen (mit Analysemdell bzw. Przessmdell) 2. Herleiten (Geschäfts- )Objektmdell zur Darstellung der Zusammenhänge der Daten und Bilden vn Datenstrukturen 3. Bilden einer Multidimensinale Struktur 4. Hinzufügen vn allgemein interessierende Ergänzungen Der Schritt 1 erflgt gemeinsam mit den Fachanwendern. Schritte 2 und 3 erledigt der Mdellierer allein an seinem Schreibtisch auf einem Blatt Papier der mit einem Datenmdellierungstl, das lgische Datenmdelle darstellen kann. Die Abflge 1-3 ist iterativ zu verstehen. Schritt 1 (Fachanwenderfragen und Analysemdell) Ausgangspunkt für die Analyse und Herleitung vn Infrmatinsanfrderungen sind Fragen, die gemeinsam mit Fachwendern entwickelt und beantwrtet werden: Beispiele: Die Infrmatinen in diesen Fragen lassen sich klassifizieren in: Bewegungsdaten Stamm- Objekte Eigenschaften der Stamm- Objekte Die Schwierigkeit besteht darin, ein Geschäftsbjekt genau abgrenzen zu können. D. h. zu erkennen, wann ein Begriff ein Bezeichner eines Geschäftsbjektes ist und wann ein Begriff nur eine Eigenschaft eines Objektes beschreibt. Oder wann beschreibt ein Begriff ein Geschäftsbjekt und wann beschreibt der Begriff eine Aktin rund um das Objekt, als die Unterscheidung zwischen Stamm- und Bewegungsdaten. Wie schwierig das sein kann zeigt der Begriff Bankknt. Auf den ersten Blick beschreibt der Begriff ein Geschäftsbjekt als etwas Statisches, etwas was man beschreiben kann, und etwas was Eigenschaften besitzen kann. Bei genauerer Betrachtung kann es aber auch eine Bewegungsinfrmatin sein, denn es interessiert eigentlich nur der Betrag, der auf dem Knt verbucht ist. Der ist aber zeitabhängig und verändert sich. D. h. die Bewegungsdaten sind hier die Sätze mit Zuwächsen und Abgängen. Diese Fragen bearbeitet man gemeinsam mit den Fachanwendern in entsprechenden Wrkshps, meist an einer Wandtafel. Das genannte Knt- Beispiel suggeriert, dass der Mdellierer, der den Wrkshp leitet, ein Kenner vn Bankgeschäftsprzesse sein muss. Das ist nicht der Fall. Sicherlich hilft ein gewisses Verständnis für Bankprzesse und Begrifflichkeiten. Er braucht aber auch eine gewisse Neutralität, die es ihm ermöglicht, abseits der Bankenfachlichkeit und Bankensprache auf einer sprachlichen Ebene Sachzusammenhänge neutral zu frmulieren und neu zu srtieren. Er muss Fragen frmulieren, die dazu führen die Fachlichkeit darzustellen und zu klären. Eine gewisse Fachfremdheit des Mdellierers führt zu unknventinellen Fragen und frdert die Fachmitarbeiter auf, ihre Sachzusammenhänge mit einfachen Mitteln zu erklären. Der Mdellierer muss den Sachzusammenhang durch die Erklärungen des Fachmitarbeiters verstehen können und dann kann er die Einteilung nach Bewegungs- Daten, Stammdaten und Eigenschaften der Stammdaten vrnehmen. Die Ergebnisse lassen sich in einem Analysemdell (Przess- Sicht) darstellen. Das Analysemdell ist eine extrem vereinfachte Darstellung der Geschäftsprzesse mit dem Ziel, die Geschäftsbjekte als slche vn den Geschäftsprzessen isliert darzustellen und zwischen Geschäftsbjekten und deren Attributen zu unterscheiden. Geschäftsbjekte sind als Kreise mit Namen dargestellt. Bewegungsdaten sind gerichtete Pfeile zwischen den Geschäftsbjekten. Diese Vrarbeit führt später zur Unterscheidung vn Fakten- und Dimensinsdaten. Attribute lassen sich graphisch an den Kreisen platzieren. 15

16 Schritt 2 (Geschäftsbjekt- Mdell) Analyse - bzw. Przessmdell Durch eine Umgruppierung bzw. Zusammenfassung der auch Aufspaltung vn Geschäftsbjekten des Analysemdels (Spezialisierungs- und Generalisierungsverfahren aus der Datenmdellierung) leitet man das Objektmdellleiten. Das ist dann bereits ein Vrläufer für die Dimensinen des dimensinalen Mdells, weil schn Hierarchien und Attribute der Dimensinen erkennbar sind. Das Zusammenfassen vn generalisierbaren Objekten (Ort - > Regin, Artikel - > Artikelgruppe, Kunde - > Bewhner einer Regin, Tag - > Mnat usw.) führt zu den späteren Drillpfaden, die man Anwendern für ihre interaktiven Analysen anbietet (Aggregatlevel). Schritt 3 (Multidimensinale Struktur, Fakten und Dimensinen) Objektmdell In dem Objektmdell hatte man nur die Kreise (Geschäftsbjekte) des Analysemdells weiterverarbeitet. Die Pfeillinien des Analysemdells fasst man zu Bewegungsdatentabellen zusammen. Das dkumentiert, was mit den Geschäftsbjekten geschieht. Dieses Geschehen ist zählbar, messbar. Damit haben wir die Kennzahlentabellen, der aus dimensinaler Sicht gesprchen, die Fakten- Tabellen. Ein neues sg. multidimensinales Mdell wird jetzt erstellt: Jedes Geschäftsbjekt ergibt eine Dimensin. Die in dem Objektmdell gefundenen Aggregatinen und Spezialisierungen bilden die Hierarchie- Stufen der neu geschaffenen Dimensinstabellen. Alle (!) Eigenschaften eines Geschäftsbjektes sind als Spalten in den Dimensinstabellen zu beschreiben. Dimensinsbjekte sind eindeutig. Ein eindeutiger Identifier zählt sie durch. Daraus entsteht später der Primary Key der Dimensinstabellen. Bewegungsdaten werden zu Fakten- Tabellen- Feldern, die eine gewisse Größe ausdrücken (Kennzahlen). Die Beziehung zwischen den Geschäftsbjekte und dem was passiert (Bewegungsdaten) stellt man durch Schlüssel dar, wbei die Dimensinstabelle das Master- Objekt ist und seinen Primary - Key an die Detail- Tabelle (Fakten) vererbt. Die Schlüsselbildung erflgt vn den Geschäftsbjektetabellen (Dimensinen) in Richtung der Bewegungsdatentabellen (Fakten) als 1:n Zurdnung. Für jedes an den zu analysierenden Geschäftsprzessen beteiligten Geschäftsbjekten wird eine Dimensin erzeugt und die Verbindung zu den relevanten Bewegungsdaten erzeugt man durch eine Schlüsselbildung. Das beschreibt den Przess vllständig, s dass zu erwarten ist, dass möglichst viele Endanwenderfragestellungen bedienbar sind 4. Aufbauschema einer Dimensin 4 Können Geschäftsbjekte nicht mit Bewegungsdaten in Verbindung gebracht werden, dann hat man entweder beim Mdellieren etwas falsch gemacht der man hat eine Schwachstelle in dem Geschäfstprzess aufgedeckt. 16

17 Schritt 4 Hinzufügen vn interessanten Referenzdaten (ptinal) Viele interessante Bezüge zu anderen Fakten der Gegebenheiten, sind jetzt nch nicht in dem Mdell enthalten, weil sie in den Anwenderfragen zunächst keine Rlle spielten. Aus Analysegesichtspunkten kann man slche Infrmatinen hinzufügen. Z. B. die Darstellung der Zeit in Frm einer Zeit- Dimensin bestehend aus Tag, Mnat, Quartal, Jahr usw. Oder die Darstellung vn räumlichen Bezügen, man erweitert den Hriznt vn der Filiale auf gröber gefasste räumliche Einheiten. Z. B. wird die Zurdnung vn Filialen zu Landkreisen in den perativen Daten nicht vrkmmen, sie kann aber vn einem Analysestandpunkt aus interessant sein. Die Infrmatin zu den Landkreisen wird dann in eine Reginen- Dimensin mit aufgenmmen. Die Umsetzung des multidimensinalen Mdells in eine physische Speicherung Diese multidimensinale Mdellfrm besagt nch nichts über die ptentielle Speicherung vn Analysedaten in eine Datenbank. Es ist ein lgisches Mdell. Das Mdell unterscheidet sich vn dem 3. Nrmalfrm- Mdell der Warehuse- Schicht grundlegend durch eine Umgruppierung der Daten. Man kann es in mehreren Arten in der Oracle Datenbanken speichern. Star Schema: Die Daten werden in einer relatinalen Datenbank, wie Oracle, in Tabellen abgelegt. Eine Dimensin wird durch genau eine Tabelle abgebildet, die durch eine Primary Key / Freign Key Beziehung mit einer der mehreren Faktentabellen verbunden ist. Snwflake Schema: Die Daten liegen in einer relatinalen Datenbank. Die Dimensinsdaten sind aber nrmalisiert auf einzelne Tabellen verteilt. (Hier fehlt der Generalisierungs- und Spezialisierungsschritt in dem ben genannten Objektmdell). Vrberechneter Würfel: Um eine Benutzeranfrage zu bedienen erfrdern die vrgenannten Star- und Snwflake- Frmen in relatinalen Datenbanken eine Jin- Abfrage auf Dimensins- und Faktentabellen. Dabei muss das Datenbanksystem grße Teile zuerst lesen, bevr ein Ergebnis feststeht. Um diesen Aufwand zu minimieren, baut das Würfelverfahren schn zum zu dem Zeitpunkt der Würfeldefinitin alle möglichen Jin- Varianten einmal auf und speichert die gefundenen Werte. Es gibt letztlich nur nch vrkmbinierte und vrberechnete Ergebniswerte in sg. Zellen. Die Kmbinatinsvarianten aus denen heraus die Werte gebildet wurden entsprechen den Dimensinstabellen des Starschemas, sie sind aber physisch nur nch als Metadaten vrhanden, über die man auf die vrberechneten Werte zugreift. Um diese Unterschiede auch sprachlich auszudrücken spricht man bei den ersten beiden Varianten vn ROLAP (relatinal abgebildetes OLAP) und bei der Würfelvariante vn MOLAP (multidimensinales OLAP) 5. Es sind aber alle drei Varianten Frmen vn multidimensinalen Mdellen. Diese Feststellung ist wichtig, weil die Eigenschaft Multidimensinalität in vielen Diskussinen irreführend nur der Würfelvariante zugeschrieben wird. Wenn Multidimensinalität eine wichtige Grundlage für flexible Auswertungen ist, dann wären eben nur Würfel flexibel abfragbar. Dabei sind Star Schemen genau s flexibel abfragbar. Das Star- Schema Will man die ROLAP- Variante einsetzen, als will man die multidimensinalen Mdelle mit relatinalen Tabellen abbilden, dann empfiehlt Oracle das Star Schema und nicht das Snw Flake Schema. Die Gründe sind: Bei Abfragen sind weniger Jins aufzulösen. Star Schema Snwflake Das Oracle Data Warehuse bevrzugt das StarSchema Die Datenbank kennt spezielle Perfrmance- Optimierungen für das Stan Schema (Star Transfrmatin 6 ). Der ETL- Aufwand ist geringer, da nicht alle nrmalisierten Tabellen zu aktualisieren sind. Auch wenn das Star Schema tchnisch als relatinale Tabellen realisiert ist, ist es z. B. in einer graphisch präsentierten Frm auch für Fachanwender intuitiv und leicht verstehbar. Es ist als Vermittler zwischen IT und Fachanwender nutzbar. Es ist flexibler, wenn Änderungen anstehen. Bei Faktentabellen fügt man einfach nur Spalten an, wenn neue Dimensinen hinzumdelliert werden, und auch die Dimensinen lassen sich einfach um weitere Felder erweitern. 5 Während in der Oracle Datenbank das Star Schema mit einfachen Tabellen und einer speziellen Star Schema- Optimierung umgesetzt wird, bietet Oracle für den MOLAP- Bereich die Oracle OLAP Optin (Lösung innerhalb der Oracle- Datenbank) und Hyperin Essbase (Lösung außerhalb der Oracle Datenbank) an. 6 Die Star Transfrmatin wird weiter in einem späteren Kapitel besprchen. 17

18 Multidimensinale Struktur (lgisch und physisch) Diese Mdell- Frm stellt eine ideale Brücke zwischen Fachanwender- Fragen (Infrmatinsbedürfnis der Anwender) und den technischen Möglichkeiten der Oracle- Datenbank dar. Star Schema- Mdelle können direkt vn Fachanwendern verstanden werden, da die Dimensinen den Infrmatinsgehalt der Geschäftsbjekte wiedergeben. Schn durch die graphische Anrdnung vn Dimensins- und Faktentabellen lassen sich Benutzerabfragen erahnen. In dem dargestellten Beispiel ist das: Welche Artikel werden vn welchen Kunden in welcher Zeit in welcher Reginen gekauft? Varianten des Star Schemas Star Schemen kmmen in der Praxis in vielen Spielarten vr. Man kann nahezu alle Infrmatinsanfrderungen durch diese Mdellfrm abbilden. Dimensinen können und sllten mehrere Fakten- Tabellen referenzieren. Zwischen mehreren Fakt- Tabellen können selbst PK/FK- Beziehungen bestehen. Zwischen Fakten- Tabellen und Dimensinen können N : N - Beziehungen bestehen, die man mit entsprechenden Mitteln auflöst. Star Schemen können auch kmplexer aufgebaut sein Die in der Graphik dargestellten Faktentabellen sind alle über die Prdukte- und Zeit- Dimensin miteinander verbunden 7. Damit können alle Daten in diesen Faktentabellen (alle Kennzahlen) mit zusammenhängenden SQL- Abfragen ausgewertet werden. User View Layer (Data Mart Schichten) sllten s aufgebaut sein, dass möglichst viele Faktentabellen über das Grs der Dimensinen zugreifbar ist. Das in der Graphik dargestellte Beispielmdell erlaubt es z. B. in einer einzigen SQL- Abfrage Verkauf und Einkauf vn Prdukten, die Aufteilung auf Anteilsmengen der Teile der Prdukte und Verkaufsanteile vn Verkäufern an den Prdukten zu messen. Und das auch nch bezgen auf Zeit und Ort. Auch wenn manche Abfragemöglichkeiten augenfällig keinen Sinn ergeben, s garantiert das Mdell die Stimmigkeit der Fakten untereinander (Stimmigkeit der Kennzahlen) und ist die Grundlage für eine Flexibilität, die man den Benutzern über Business Intelligence- Tls anbieten kann. Fehlende Flexibilität auf der Endanwenderseite entsteht ft dadurch, dass Kennzahlen nicht miteinander in Verbindung gesetzt werden können bzw. nicht zusammen in einem Reprt erscheinen können. Ursache ist fehlende Vraussicht bei der Mdellierung der Data Marts (User View Layer), weil diese Tabellen nur als einzelne islierte Tabellen dargestellt sind. Wenn Data Marts sgar in unterschiedliche Datenbank- Schemen abgelegt der sgar mit unterschiedlicher Technlgie realisiert sind, dann können Zusammenhänge auf der Endanwenderseite nicht mehr gebildet werden. 7 Dimensinen, mit den man auf mehrere Fakten- Tabellen zugreifen kann nennt man auch Cnfrmed Dimensins. 18

19 Im UserView Layer sllten allen Fakten nach Möglichkeit über gemeinsam genutzte Dimensinen zusammenhängend zugreifbar sein. Die Data Mart- Schicht (User View Layer) sllte durchgängig- abfragbar aufgebaut sei. Star Schemen sllten über gemeinsgenutzte Dimensinen verbunden sein Degenerated Dimensin Dimensinen können auch völlig in eine Fakten- Tabelle übernmmen werden. Das wird dann gemacht, wenn die Dimensinen- Tabelle nur wenige Spalten umfasst und man damit für die spätere Abfrage einen Jin sparen kann. Degenerated Dimensin: Eine Kunden- Dimensin wurde in der Faktentabellen aufgelöst Typische Beispiele sind Dimensinen wie Geschlecht mit den Werten [Maennlich / weiblich / XX]. Anstelle des Schlüssels kann man hier den Wert direkt in die Fakten- Tabelle aufnehmen. Dimensinstabellen mit nur einem Feld sind daher unüblich 8. Factless Fact Table Factless Fact Table: Zähl- Faktentabelle Wenn eine Fakten- Tabelle nur die Freign Key Schlüsselwerte der Dimensinstabellen und keine zusätzlichen Wertfelder (Kennzahlenfelder) enthält, dann wird sie nur zum Zählen der jeweiligen Dimensinen- Verknüpfungen genutzt. Empfehlungen für den Aufbau vn Faktentabellen Effizient aufgebaute Fakten- Tabellen sind nach flgende Regeln mdelliert: Eine Faktentabelle sllte s granular wie möglich aufgebaut sein. Je granularer sie definiert ist, um s mehr Aggregate lassen sich zu einem späteren Zeitpunkt daraus bilden. Das kann bei einem Lebensmittelhändler die Milchpackung sein, die über das Band an der Kasse läuft der bei einer Telefngesellschaft das einzelne Telefngespräch. Das hat Auswirkungen auf die Dimensinen (eine Zeit- Dimensin muss z. B. ein Level Minuten der Sekunden haben) und auf die Datenmengen. Die aufgrund der feineren 8 Das mag weit hergehlt sein, aber es gibt Beispiele, bei denen slche Eigenschaften wirklich als Dimensin mdelliert wurden. Bei dieser Vrgehensweise kmmen schnell 100 und mehr Dimensinen zustande. 19

20 Granularität entstehenden Datenmengen können mit heutigen Datenbanktechniken beherrscht werden. Perfrmance sllte kein Argument für eine höhere Granularität sein. Nach Möglichkeit sllten keine separaten Faktentabelle erstellt werden, nur um eine höhere Aggregatins- Ebene zu erhalten. Diese Aggregatins- Ebenen können zum Abfragezeitpunkt aus einer Faktentabelle mit granularen Daten errechnet werden. Wenn die Perfrmance hier nicht reicht, kann eine Materialized View 9 helfen Durch gemeinsam genutzte Dimensinen erstellt man verwandte Faktentabellen, damit Abfragen mit möglichst vielen Infrmatinen zusammenhängend flexibel gestaltet werden können. Die Faktentabelle besitzt keinen eigenen PK Der Zugriff erflgt nur über die Freign Key- Felder Sätze müssen nicht eindeutig sein, d. h. die Fakten- Tabelle enthält keinen Primary Key (Ausnahme: Eine Fakten- Tabelle ist Master in einer Master/Detail- Beziehung zwischen Fakten- Tabellen) Fakten- Tabellen sind meistens Partitining- Kandidaten 10. Die Wahl der Granularität einer Fakten- Tabellen beieinflusst die Flexibilität der Abfrage Endbenutzer wünschen meist ein Höchstmaß an Abfragemöglichkeiten und Flexibilität. Wählt man die Granularität der Faktentabelle kleiner, s steigt damit autmatisch die Menge der Abfrageptinen. Es steigt aber auch die Menge der Sätze in der Fakten- Tabelle. Mehr Aggregat- Level in den Dimensinen führen zu einer Verfielfachung vn Abfrageptinen Die Datenbank- Technlgie und die Hardware- Mittel sind in den letzten Jahren sehr stark verbessert wrden. Daher kann man heute die Granularität der Fakten- Tabellenwerte s klein wie möglich wählen. Ideal ist die Granularität die gleiche, wie die der perativen Quelldaten. Man kann bis auf die Detail- Ebene drillen hne auf die perativen Daten wechseln zu müssen. Die Granularität der Faktentabelle erhöt die Menge der Abfrageptinen für die Endbenutzer Auslagern vn weniger häufig genutzt Attributen Werden Spalten vn Dimensins- Tabellen weniger häufig genutzt, s kann man diese in eine separate Dimensin auslagern. An der Faktentabelle ändert sich dadurch nichts, denn es wird derselbe FK- Schlüssel vn allen Dimensinen genutzt. Ein analges Verfahren erhält man, wenn man zwischen zwei Dimensinen eine 1:1 Beziehung erstellt. 9 Materialized Views werden weiter unten besprchen. 10 Partitining wird in einem separaten Abschnitt besprchen 20