Data Warehouse Technik im Fokus - Teil 1 - Architektur und Konzepte Oracle Data Warehouse - Data Warehouse Technik im Fokus Teil 1: Architektur und Konzepte Die Themen Aufgaben und Entwicklung des Data Warehouse Das Schichten-Modell: Information-Factory Die Data Mart Schicht Quellsysteme Die Stage Schicht Die Kern-Data Warehouse Schicht ETL Check-Liste zur Planung Hardware Anforderungen Vorschau Datenbankmittel 1 Data Warehouse Technik im Fokus - Teil 1 - Architektur und Konzepte 2 Vier wichtige Aspekte machen das Data Warehouse so erfolgreich Data Warehouse Systeme gehören heute zu den erfolgreichsten Anwendungen in modernen Unternehmen. Grund dafür ist zum einen der zentrale Charakter. Ein Data Warehouse ist meist das einzige System, in dem man unternehmensweit an einer einzigen Stelle eine umfassende zusammenhängende Information erhält. Viele OLTP-Systeme beschäftigen sich dagegen nur mit einzelnen Sachgebieten und Fragenstellungen. Der zweite wichtige Vorzug des Data Warehouse Systems ist die verständliche Darstellung von Informationen. Während sachbezogene Anwendungen ihre Informationen nur in ihrem speziellen Kontext verwalten, überführt ein Data Warehouse diese spezifische Terminologie in eine allgemein verständliche Form und Sprache und macht sie so auch für sachgebietsfremde Mitarbeiter (z. B. aus anderen Abteilungen) verstehbar. Darüber hinaus harmonisiert ein Data Warehouse Begriffe, Formate, Betrachtungsebenen und Definitionen. Informationen aus unterschiedlichen Sachgebieten können somit zusammenhängend benutzt werden, ein einheitliches unternehmensweites Bild entsteht. Der dritte wichtige Aspekt von Data Warehouse Systemen ist das Vorhalten von historischen Daten. Operative Anwendungen verändern ihre Daten permanent. Die Planung und weitere Ausrichtung der Aktivitäten eines Unternehmens erfordern jedoch eine vergleichende Betrachtung aktueller und historischer Daten. Das vierte wichtige Merkmal von Data Warehouse Systemen ist die Separierung von Daten aus ihrem operativen Kontext heraus. Durch das „Weg-Kopieren“ kann man diese Daten unabhängig von den operativen Anwendungen beliebig verändern. um sie einer weiteren Verwendung zuzuführen. Operative Systeme bleiben dadurch unberührt. Der Aspekt des „Unternehmensweiten“ Business Intelligence Lösungen werden meist mit Blick auf einzelne Sachgebiete oder Abteilungen betrachtet. Data Warehouse Systeme verfügen dagegen über einen unternehmensweiten Wirkungsbereich. Wie zuvor bereits ausgeführt, liegen hier wesentliche Aufgaben. Diese unternehmensweite Ausrichtung macht Data Warehouse Systeme zu einem idealen MonitoringInstrument für abteilungsübergreifende aber auch Zeitenübergreifende Vergleiche. Unternehmen müssen heute in immer kürzerer Zeit geänderte oder komplett neue Geschäftspraktiken anwenden, um erfolgreich zu sein. Diese permanenten Änderungen erfordern ein stabilisierendes Kontrollinstrument, um Fragen zu beantworten wie: Welche Bereiche/Produktlinien sind die profitabelsten? Haben sich neue Produktionsverfahren gegenüber früheren bewährt? Gibt es territoriale Veränderungen bei der Geschäftsentwicklung? Solche Fragen können begrenzt auch direkt betroffenen Fachmitarbeiter beantworten. Das Abstrahieren aus dem unmittelbaren Aktionsumfeld heraus, sowohl räumlich als auch zeitlich, ist jedoch meist nur schwer machbar. Hier bietet das Data Warehouse eine unternehmensweite, sachgebietsübergreifende und auch historische Datensammlung an, um diese nötige Abstraktion von der direkten „Jetzt- und HierErfahrung“ zu ermöglichen So lassen sich schneller Fehlentwicklungen erkennen. Ein frühzeitiges Gegensteuern ist möglich. Dies verdeutlicht, wie wichtig es ist, möglichst alle Geschäfts(erfolgs-) relevanten Prozesse an ein Data Warehouse anzuschließen, d. h. Daten aus diesen Prozessen in das zentrale System zu überführen. Um so besser kann das Systeme seine übergreifende Monitoring-Funktion erfüllen. Weitere positive Aspekte können dem unternehmensweiten Charakter des Data Warehouse abgewonnen werden: Unternehmensweit Informationen o o o o gemeinsame, standardisierte Glossare / Definitionen als Nachschlagewerk Standardisierte Begriffe Gleiches Verständnis über den Inhalt Kennzahlen und Sachverhalten Gemeinsam genutzte Berichte von Gleicher aktueller Kenntnisstand o Verhindern von “Information Hiding” o Demokratisierung durch gleiche Informationen o Beschleunigte Informationsweitergabe Reduzierung des Aufwands für die Informationsbeschaffung o Wiederverwendung von bereits an anderer Stelle erstellten Informationen Data Warehouse Technik im Fokus - Teil 1 - Architektur und Konzepte Rolle und Eigenschaften haben sich permanten verändert Man spricht seit Anfang der 90er Jahre von Data Warehouse Systemen. Aufgrund der vorgenannten positven Eigenschaften finden die Systeme eine immer weitreichendere Verwendung. Dienten sie ursprünglich nur dem Reporting auf einer strategischen Ebene und füllten Monats-/Quartalsberichte so sind Warehouse Systeme heute oft direkt mit operativen Anwendungen verzahnt. Viele Fachmitarbeiter auch ausserhalb der Controlling-Abteilung oder Planungsstäbe haben das verlockende Informationsangebot des Data Warehouse erkannt und wollen mit ihren Geschäftsprozessen „angedockt“ werden. Das führte zu neuen Datenbereichen und auch oft zu einer feineren Granularität der Daten, denn auf der operativen Ebene stehen meist konkrete Transaktionen bzw. Geschäftsvorfälle im Vordergrund. Die Folgen sind kürzere Betrachtungszeiträume (der Zeitpunkt des Geschäftsvorfalls wird wichtig) und ein massives Anwachsen der Datenmengen. Data Warehouse-Systeme sind heute die am schnellsten wachsenden Anwendungen mit sichtbaren finanziellen Folgen in den IT-Budges. Dies erklärt die z. T. angestrengte Suche von IT-Verantwortlichen nach Alternativen für hochvolumigen Speicher. Neben der Betrachtung von fachlichen Aspekten bei der Gestaltung und Modellierung von Warehouse-Systemen spielt heute daher auch die Betrachtung von Hardware-Aspekten eine bedeutende Rolle. Operationalsierung der Data Warehouse-Rolle Diese geänderte Verwendung kann man auch als Operationalisierung bezeichnen. Also die Nutzung des ursprünglich für dispositive Zwecke entworfenen Systems für operative Aufgaben. 3 aggregierten Informationen über görßere Zeitabstände hinweg. Heute bewegt sich das Data Warehouse schon nahe an den Anforderungen an operative Systeme mit vielen Benutzern, sehr großen Datenmengen und permanenten Änderungsvorgängen. War es früher geboten eine separate, für aggregierte Auswertungszwecke passende Datenhaltung zu wählen, ist es heute wichtig nicht mehr zwischen einer Datenhaltung für operative und dispositive Zwecke zu unterscheiden. Heute ist es wichtig für OLTP und Data Warehouse-Zweck durchgängig einheitliche Datenhaltungs-Komponenten nutzen zu können, weil beide Anforderungen durchmischt, eng verzahnt und kaum noch trennbar sind. Hinzu kommt die immer geringere Zeit, die bleibt, um Daten aus einem operativen Verwendungkontext in einen dispositiven zu überführen (ETL). Die Oracle Datenbank erfüllt genau diese Anforderung. Ursprünglich für operative Zwecke entwickelt, hat sie sich seit dem Release 7 (1995) kontinuierlich auch als ideale Data Warehouse etabliert und ist heute die am meisten verwendete Datenhaltung für ein Data Warehouse. Angleichung der Anfordergungen an OLTP und DWH - Systeme im Zuge der Operationalisierung des DWHs Warehouse-Organisation in drei Daten-Schichten Das Data Warehouse erreicht die vorgenannten Ziele durch eine methodisch begründete Einteilung in mehrere Schichten, in denen die enthaltenen Daten durch entsprechende Bearbeitungsschritte aus ihrer ursprünglichen Form in den operativen Systemen in eine benutzergerechtere Form für die Endbenutzer überführt werden. Vor allem in unternehmensweit aufgestellten Data Warehouse Systemen hat sich die Aufbereitung der Daten in drei Schritten bewährt: 1) 2) 3) Man sammelt, integriert und prüft auszuwertende Daten der operativen Vorsysteme. (Stage) Man granularisiert diese Daten in einem alle Sachgebiete umfassenden (meist 3 NF) - Schema. (DWH-Schicht) Je nach Zielgruppe und Sachgebiet fügt man im letzten Schritt die granularen Informationsbausteine meist zu multidimensionalen Endbenutzer-Modellen (meist Star Schemen) zusammen. (Data Marts) Dieses ist eine Ressourcen-schonende Vorgehensweise mit der Betonung auf Wiederverwendung von Daten und Entwicklungsarbeiten bei gleichzeitiger Flexibilität durch beliebige Auswerte-Szenarien. Beispiele für operative Verwendung von Data Warehouse-Systemen Das Hervorheben dieses Aspekts zielt vorallem auf die in einem Data Warehouse verwendetet Datenhaltungsplattform. In der Vergangenheit belieferten die Systeme wenige Personen mit Data Warehouse Technik im Fokus - Teil 1 - Architektur und Konzepte 4 kann durch das Ausnutzen von Synergien Aufwand und Zeit sparen. Um Synergie-Effekte möglichst komplett zu nutzen, empfiehlt Oracle alle 3 Verarbeitungsschritte bzw. Schichten in einer einzigen Datenbank-Instanz und damit auch Hardware-Umgebung anzusiedeln. 3-Schichten-Modell historisch Seit den 1980er Jahren hatte man unterschiedliche Varianten der Organisation der Daten für dispositive Zwecke erprobt. Die aktuelle Organisation in 3 Schichten hat sich seit Mitte der 1990er bewährt. Die Mehrwert-Leistungen des Data Warehouse Auf dem Weg zu den Benutzern durchlaufen operative Daten mehrere Wandlungsschritte in den einzelnen Warehouse-Schichten. 1. Operative Systeme nutzen Daten für ihre Zwecke ideal zusammengesetzt und auch nur diejenigen Informationen, die sie wirklich benötigen. Für Analysten oder Mitarbeiter, die eine unternehmensweite prozessübergreifende Aufgabe verfolgen, reicht dies nicht aus, bzw. die Daten sind wenig verständlich. Der Wandlungsprozess im Data Warehouse löst die Datenstrukturen der operativen Systeme auf und überführt die Kerninformation in eine Form, die leicht und flexible für unterschiedliche Zielgruppen und deren Bedürfnisse neu kombiniert werden kann. Man bedient sich der Hilfsmittel aus der Datenmodellierung, mit denen man die operativen Informationen in einem ersten Schritte in die kleinst möglichen Informationsbausteine zerlegt (Normalisierung in Richtung 3. NF) und sie dann je nach Endbenutzeranforderung wieder neu kombiniert. Die Vorgänge finden bei dem Übergang von Stage zur DWH-Schicht (Normalisierung) und von der DWHSchicht in die Data Mart-Schicht (Denormalisierung) statt. Heute ist die Verwendung dieser Organisation nicht unumstritten. Die Kritik an diesem Modell lautet: Zu viele redundante Daten Gefahr für höherer Latenzzeiten Hoher Entwicklungsaufwand Diese Punkte sollten ernst genommen werden, da sie in manchen Diskussionen die unbestreitbaren Vorteile des 3-Schichten-Modells überlagern können. Im Ergebnis können dann heutige Lösungen wie Lösungen aus den 1980ern aussehen, bei denen Daten direkt aus den operativen Systemen in die proprietäre Speicherung bestimmter BI-Tools gelangen. Das Ziel der 3-Schichten-Architektur ist der Entwurf einer möglichst umfassenden, mehrere Unternehmensund Themenbereiche abdeckenden stabilen Informationsablage, die in kurzer Zeit konsolidierte Berichte und Analysen für alle (!) Zielgruppen des Unternehmens bereitstellt. Das 3-Schichten-Modell gibt dem Data Warehouse die Möglichkeit, Informationen zunächst zu harmonisieren und zu vereinheitlichen, bevor sie in Business Intelligence Systemen ausgewertet werden, sorgt für eine „zeit-und Phasen-überdauernde“ Konstante, während sich Geschäftsprozesse wesentlich häufiger verändern, 2. Das Normalisierungs-/Denormalisierungsverfahren verhindert noch nicht ein potentielles Informationschaos im Data Warehouse. Denn aufgrund der sog. Homonymen-/Synonymen-Problematik können bei einem unklaren Begriffsverständnis unerkannt Informationen mehrfach in einem Data Warehouse abgelegt sein. Diese Gefahr ist umso größer, je mehr Prozesse und Abteilungen an dem DWH-System angeschlossen sind. Hier helfen: Glossars mit abgestimmten Begriffsdefinitionen Deskriptoren-Verfahren zur Standardisierung und für das Wiederauffinden von Begriffen Metadaten-Management Datenqualitätsstandards Dies wird in der aktuellen Data Warehouse Diskussion unter dem Begriff Data Governance zusammengefasst. Data Warehouse Technik im Fokus - Teil 1 - Architektur und Konzepte 3. Die Erwartungen der Endbenutzer an die Informationen des Data Warehouse gehören zu den Schlüsselaufgaben. Diese Erwartungen richtig zu treffen ist ein immer wiederkehrender Entwicklungsschritt. Die erwarteten Informationen muss man aus den Fragestellungen der Fachanwender herleiten. Diese sind i. d. Regel an den Geschäftsprozessen orientiert, die bis zu einer gewissen Tiefe verstanden werden müssen. Ein Data Warehouse ist jedoch nach den Konstruktionsprinzipien von Datenstrukturen konzipiert und bildet die Informationen zu den Objekten der Geschäftsprozesse ab. Ein wichtiger Modellierungsschritt ist daher das Identifizieren der richtigen Geschäftsobjekte und die IT-technische Beschreibung der Geschäftsobjekte mittels leicht verstehbaren und leicht auswertbaren Datenmodellen bzw. Tabellenstrukturen. Das Ergebnis sind meist multidimensionale Modelle. 5 Data Marts sind redundant und „flüchtig“ Die Data Mart Schicht Der Hauptzweck der Data Mart-Schicht ist die Endbenutzergerechte Aufbereitung der Warehouse-Daten. Gegenüber der Data Warehouse-Schicht entstehen keine zusätzlichen Informationen. Aber die Datenmodellart und die Granularität der Daten kann sich ändern. Aufgrund des 3-Schichten-Konzeptes sind Data Marts prinzipiell redundant zur Data Warehouse-Schicht. Daher ist die Frage berechtigt, ob zu jedem Zeitpunkt alle Data Marts auch physisch vorhanden sein müssen, oder nur dann, wenn Endbenutzer die Marts benötigen. Um Kosten zu senken, können Data Marts auch nach Anforderung erzeugt werden. Das erleichtern auf der anderen Seite die Verwaltung und das Laden eines Data Marts: Als Datenmodellform werden multidimensionale Modelle (StarSchema, Snowflake) bevorzugt, weil diese für Endbenutzer intuitiver sind. Ziel ist es so viele Abfrage-Ergebnisse wie möglich präpariert zu haben. Deswegen ergänzt durch vorbereitete Data Warehouse Kennzahlenbäume Views. man multidimensionale Abfragemodelle auch Kennzahlen-Tabellen, die man in dem Oracle meist als Materialized Views erstellt. sind aufeinander aufbauende Materialized Zusammenfassend: Alle Varianten, meist multidimensional (Star) o Star, Snowflake, Ansammlung einzelner Tabellen, Cubes o Außer 3 NF-Modelle Abfrage-/End User-orientiert Teils temporär, warden eventuell nur bei bedarf aufgebaut Kann historisiert sein Daten redundant zur DWH-Schicht Je nach Anforderung regelmäßiger Neuaufbau Keine Updates sondern nur Inserts (Append) in der Datenbank. Das sind schnelle Vorgänge in einer OracleDatenbank. Das schnelle Neuaufbauen erfolgt als sogenannter Massenladevorgang. Damit ist das Komprimieren der Daten durch die Datenbank leichter möglich. Durch regelmäßiges Neuaufbauen wird das Ansammeln von alternden Daten verhindert und es befinden sich nur wirklich benötigten Daten in dem Data Mart. Teurer Plattenplatz wird gespart. Historisierung Historisierung findet auf zwei unterschiedliche Weisen statt. Zum einen beziehen sich die auszuwertenden Daten auf einen historischen Zeitraum (i. d. R. vom „Jetzt“ bis zu einem Zeitpunkt in der Vergangenheit). Zum anderen können sich die Rahmenbedingungen unter denen Daten entstehen verändert haben. In diesem Fall redet man von Slowly Changing Dimensions. Haben sich z. B. die Verkaufsgebiete verändert, so hat dies auch Auswirkungen auf Verkaufszahlen. Zur Darstellung der veränderten Rahmenbedingungen wird man bei den beschreibenden Informationen (Dimensionen) Versionen einführen. Zur Darstellung der unterschiedlichen Zeiten in denen Daten anfallen nutzt man Zeitattribute in den Datentabellen. Solche Zeitattribute sind eine gute Voraussetzung für das physische Partitionieren großer Tabellen (Oracle Partitions), was dann wieder Abfragen beschleunigen kann. Slowly Changing Dimensions können aufwendig sein. Sie erschweren das Abfragen. Deshalb sollte man diese nur einsetzten, wenn es nötig ist. Data Warehouse Technik im Fokus - Teil 1 - Architektur und Konzepte Weil Data Marts flüchtig sein können, sollte die Historisierung bereits in der Kern-DWH-Schicht angelegt sein. Bei dynamisch aufgebauten Data Marts hat man dann die Möglichkeit, nur einen Teil der Historisierung in den Data Marts zu realisieren. 6 Stamm-Objekte Eigenschaften der Stamm-Objekte Die Ergebnisse lassen sich in einem Analysemodell (Prozess-Sicht) darstellen. Empfehlung Star Schema verwenden Oracle empfielt die Verwendung des Star Schema-Modells. Anstelle von Snowflake oder 3 NF Intuitives Modell Auch für Fachanwender verständlich Performance-Optimierungen durch Datenbank möglich Flexibler, da Änderungen leichter umsetzbar ETL-Aufwand ist geringer, da weniger Tabellen Analyse - bzw. Proze ssmodell Umgang mit großen Faktentabellen Große Fakten - Tabellen stellen aufgrund des enormen Platzbedarfes und der doppelten Ladenaktivität eine besondere Herausforderung dar. Es ist daher sinnvoll, solche großen Objekte nur einmal in dem gesamten Data Warehouse aktiv zu halten. Diese Objekte kann man in der Data Warehouse-Schicht einmalig persistent vorhalten und aus den Data Marts darauf verweisen. Zum Schritt 2 (Geschäftsobjekt-Modell) Durch eine Umgruppierung bzw. Zusammenfassung und Anwendung von Datenmodellierungsmethoden (Spezialisierung und Generalisierung) kann man das Objektmodell herleiten. Das ist dann schon ein direkter Vorläufer des dimensionalen Modells, weil bereits Hierarchien, Dimensionen und Fakten erkennbar sind. Das ist ein weiterer Grund, weshalb Data Marts und Kern-Data Warehouse gemeinsam in einer Umgebung anzusiedeln sind. Strukturierung und Beziehungen der Objekte Herleitung der multidimensionalen Modell eines Data Marts Die Entwicklung multidimensionaler Modelle gliedert sich in 3 Schritten: 1. 2. 3. Analyse der Fachanwenderfragen (mit Analysemodell bzw. Prozessmodell Herleitung (Geschäfts-)Objektmodell Herleitung multidimensionale Struktur Objektmodell Zur Schritt 3 (Multidimensionale Struktur) Durch eine Schlüsselbildung zwischen den Bewegungsdatentabellen und den Geschäftsobjekte-Tabellen entsteht die multidimensionale Sicht. Zum Schritt 1 (Fachanwenderfragen) Ausgangspunkt für die Herleitung sind Fragen, die gemeinsam mit Fachwendern entwickelt werden: Z B: Die Informationen in diesen Fragen lassen sich klassifizieren in: Bewegungsdaten Alle Eigenschaften eines Geschäftsobjektes werden zu Spalten in den Dimensionstabellen. In diesen Dimensionstabellen werden alle (!) Eigenschaften aufgenommen. Dimensions-Objekte sind eindeutig, sie werden „durchgezählt“. Aggregationen und Spezialisierungen werden zu HierarchieStufen. Bewegungsdaten werden zu Faktentabellen-Feldern, die eine gewisse Größe ausdrücken (Kennzahlen) Die Beziehung zwischen den Geschäftsobjekten und dem was passiert (Bewegungsdaten) werden durch Schlüssel dargestellt, wobei die Dimensionstabelle das Master-Objekt darstellt und seinen Primary - Key an die Detail-Tabelle vererbt. Data Warehouse Technik im Fokus - Teil 1 - Architektur und Konzepte Das Star-Schema 7 Welche Verkäufer verkauften welche Produkte an welchen Tagen in welcher Stadt wie oft Soll bei einem Star Schema noch eine zusätzliche Sicht hinzugenommen werden, so wird lediglich eine Dimension mit einem zusätzlichen Schlüssel in der Fakten-Tabelle hinzugefügt. Varianten des Star Schemas Multidimens ionale Str uktur Die vorherrschende Modellform in der Data Mart-Schicht ist das Star Schema . Es ist einerseits ein multidimensionales Modell, auf der anderen Seite ist es mit Mitteln einer relationalen Datenbank wie Oracle physisch realisierbar. Diese Modell-Form stellt eine ideale Brücke zwischen Fachanwender-Fragen (Informationsbedürfnis der Anwender) und den technischen Möglichkeiten einer Datenbank dar. Star Schema-Modelle können direkt von Fachanwendern verstanden werden, da die Dimensionen den Informationsgehalt der Geschäftsobjekte wiedergeben. Wie flexibel das Star Schema mit komplexen Informationen umgehen kann, zeigt folgendes Beispiel Abbildungsversuch mit klassischen Spreadsheets Komplexität der Abfrage Dimensionen können mehrere Fakten-Tabellen referenzieren. Zwischen Fakt-Tabellen können selbst PK/FK-Beziehungen bestehen. Zwischen Fakten-Tabellen und Dimensionen können N zu N - Beziehungen bestehen. Degenerated Dimension Dimensionen können auch völlig in eine Fakten-Tabelle übernommen werden. Das wird immer dann gemacht, wenn die Dimensions-Tabelle nur wenige Spalten umfasst und man damit für die spätere Abfrage einen Join sparen kann. Welche Produkte werden an welchen Tagen wie oft verkauft? Welche Produkte werden an welchen Tagen in welcher Stadt wie oft verkauft? Typische Beispiele sind Dimensionen wie Geschlecht mit den Werten [Männlich / weiblich / XX]. Anstelle des Schlüssels kann man hier den Wert direkt in die Fakten-Tabelle aufnehmen. Data Warehouse Technik im Fokus - Teil 1 - Architektur und Konzepte Factless Fact Table 8 Höhere Granularität bei Fakten-Tabellen wählen Die Datenbank-Technologie und die Hardware-Mittel sind in den letzten Jahren sehr stark verbessert worden. Daher kann man heute die Granularität der Fakten-Tabellenwerte so klein wie möglich wählen. Früher Heute Wenn eine Fakten-Tabelle nur Schlüsselwerte und keine zusätzlichen Wertfelder enthält, dann wird sie nur zum Zählen der jeweiligen Dimensionen-Verknüpfungen genutzt. Empfehlungen für den Aufbau von Faktentabellen So granular wie möglich aufbauen o Performance-Thematik separat lösen o Keine eigene Faktentabelle bilden, nur um eine höhere Aggregations-Ebene zu erhalten o Keine separate Faktentabelle aus PerformanceGründen “Verwandte” Faktentabellen schaffen o Über gemeinsam genutzte Dimensionen Die Faktentabelle besitzt keinen eigenen PK o Zugriff nur über die Foreign Key-Felder o 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) Partitioning-Kandidat Star vs. Snowflake Schema In einem sog. Snowflake Schema sind die Aggregationsstufen einer Dimensionstabelle als separate Tabellen modelliert. Eine Dimension entspricht damit eher dem Modell der 3. Normalform. Informationsmenge und Abfrageoptionen Endbenutzer wünschen meist ein Höchstmaß an Abfragemöglichkeiten und Flexibilität. Wählt man die Granularität der einzelnen Dimensionen kleiner, so steigt damit automatisch die Menge der Abfrageoptionen. Es steigt aber auch die Menge der Sätze in der Fakten-Tabelle. Abfragen auf ein Snowflake-Modell erfordern komplexere Join-Formulierungen. Ein Snowflake-Modell ist schwerer lesbar In der Vergangenheit konnten einige Business Intelligence - Tools besser mit Snowflake umgehen, da dimensionale Beschreibungswerte in normalisierten Tabellen leichter abgegriffen werden konnten. Die Werkzeuge konnten damit leichter LookupTabellen bilden. Heute gibt es in diesem Bereich keinen Grund mehr ein Snowflake-Modell aufzubauen. Die Oracle Datenbank arbeitet effizienter mit einem Star Schema. Auslagern von weniger häufig genutzt Attributen Werden Spalten von Dimensions-Tabellen weniger häufig genutzt, so kann man diese in eine separate Dimension auslagern. An der Data Warehouse Technik im Fokus - Teil 1 - Architektur und Konzepte Faktentabelle ändert sich dadurch nichts, denn es wird derselbe FKSchlüssel von allen Dimensionen genutzt. 9 Die Schlüssel / Indizierung im Star Schema Schlüssel in Dimensionen Dimensionen sind als eindeutige Tabellen aufzubauen. Sie besitzen also einen Primary Key, der so auch in der Datenbank angelegt ist. Dieses Schlüsselfeld ist i. d. R. sehr einfach gehalten und wird im Verlauf des ETL-Prozesses gebildet. Weitere eindeutige Schlüssel (Alternate Key, Unique Key) können enthalten sein, sie spielen aber für die Konstruktion des Star Schemas keine Rolle. Durch den Denormalisierungs-Schritt gibt es im Gegensatz zu dem 3NF-Modell der Kern-Data Warehouse - Schicht auf den höheren Aggregat-Stufen keine eindeutigen Schlüssel mehr, auch wenn die Namensgebung dieses suggeriert. Wahl der Schlüsselfelder Wenn kein künstliches Zählfeld als Primary Key gewählt wird, sondern echte Felder, dann sollten folgende Regeln angewendet werden: Ein analoges Verfahren erhält man, wenn man zwischen zwei Dimensionen eine 1:1 Beziehung erstellt. Einfach benutzbare und kurze Felder o Speicherplatz sparen o Fehler vermeiden Nach Möglichkeit nicht zusammengesetzt o Erfordert beim Zugriff unnötig viel Vorwissen zu den einzelnen Schlüsselbestandteilen o Schlüsselbestandteile können leicht NULL-Wert annehmen, Eindeutigkeit ist gefährdet Keine Felder wählen, die NULL werden können Spaltenwerte sollten stabil sein und sich nicht mehr ändern Generell sollte man solche Lösungen gut überdenken, denn sind machen das gesamte Datenmodell komplex. Datenbanken sind heute wesentliche performanter als früher. Daher sind solche Lösungen aus Performancegründen heute kaum noch nötig. Manchen Systeme werden jedoch heute auch operativ genutzt. Durch dieses Verfahren, kann man operativ genutzte Spalten von den übrigen trennen. Allgemeine Regeln für das Star Schema Star Schema einfach halten o Für Endbenutzer überschaubarer o Nicht mit zu vielen Dimensions-Attributen überfrachten Code-Attribute vermeiden o Attribute mit beschreibenden Inhalten verwenden o Sprechende Column-Namen verwenden o Level-bezogene Präfixe verwenden Operativ genutzte Daten in separate Tabellen auslagern o 1:1-Beziehung zu Dimensionen Überfrachtete Dimensionen aufspalten o Bei zu vielen Attributen o Bei sehr oft genutzten Selektionskriterien Dimensionen mit nur einem Attribut in die Faktentabelle verlagern Umschlüsselung Das Umschlüsseln erfolgt zwar bereits in der Stage-Schicht. Es hat aber Auswirkungen auch auf die Data Mart - Schicht. Denn Geschäftsobjekte erscheinen hier entgegen der Situation in den operativen Systemen mit neuen künstlichen Schlüsseln, die auch bei Abfragen genutzt werden müssen. Eine Umschlüsselung auf künstliche Schlüssel ist aus mehreren Gründen notwendig: Integration o In mehreren Vorsystemen kann es unterschiedliche Schlüssel geben. Um nicht ein System zu bevorzugen, wählt man einen neuen. Stabilität o Natürliche Schlüssel können sich leichter ändern. o Geschäftsbereiche können sich ändern. o Ein DWH ist meist langlebiger als operative Anwendungen. Künstliche Schlüssel bedeuten Performance für das Star Schema, da die Datenbank mit solchen Schlüsseln besser umgehen kann. Data Warehouse Technik im Fokus - Teil 1 - Architektur und Konzepte Business Key Die Originalschlüssel aus den Vorsystemen übernimmt man zur Orientierung der Endbenutzer als sogenannte Business Keys bis in die Dimensionen hinein. Dort findet man sie auf der gleichen Stufe wie die neuen künstlichen Schlüssel. Es kann vorkommen, dass in einer Dimension gleich mehrere Originalschlüssel enthalten sind, weil die Geschäftsobjekte in mehreren Vorsystemen unterschiedlich verwendet wurden. In diesem Be is pie l finde t m an die be ide n „ Business Key “ „Kunden_NR“ und „Par tne rnummer“ ne ben dem küns tlic hen Schlüsse l „Dim _Kd_NR“ Zus ammenfassende Dar ste llung. Der Untesc hie d zwisc he n Btree und Bitm ap - Indexe n wird s päter v orge ste llt. 10 Data Warehouse Technik im Fokus - Teil 1 - Architektur und Konzepte Quellsysteme 11 In Data Warehouse Systemen treffen diese Daten jedoch auf Daten anderer Vorsysteme oder sie werden anders verwendet. Aus der übergreifenden Sicht des Data Warehouses sind die Quelldaten dann fehlerhaft. Zur Lösung gibt es folgende Verfahren: Quellsysteme können sehr herausfordernd sein. Z. B. Verschiedene OLTP-Systeme wie CRM und ERP Legacy Systeme Externe Daten von Partnern Unterschiedliche Zugriffsmethoden o Middleware Sources -> Message - basiert o Push / Pull - Anforderungen o Standard - Driver wie ODBC, JDBC o Text-basiert: CSV, fixed length, Copy books, EBCDIC, ASCII o Call-Schnittstellen o Satzarten-strukturiert Problemfall: oft fehlende beschreibende Informationen o Zugriff auf Dictionary-Systeme o Dokumentation o Müssen hergeleitet oder generiert werden Ausnahmefälle manchmal nicht dokumentiert Zeitliche Verfügbarkeit Unsaubere oder komplexe Schlüssel Andere Hardware / Betriebssystem-Plattformen Schwer nachvollziehbare Ablagelogik o „Wenn in Feld A der Wert XYZ dann in Feld B ein gütiger Wert“ Datenqualitätshürden Umgang mit dem Aspekt des Operativen der Vorsysteme Operative Vorsysteme sind eingebunden in z. T. erfolgskritische Unternehmensprozesse. Daher unterliegt der Umgang mit ihnen aus Sicht des Data Warehouse besonderen Regeln: Sie dürfen durch das Abziehen der Daten nicht behindert werden o Kein Einfluss auf die Performance o Kein Anhalten, um Daten herauszulesen Sie sollten nicht modifiziert werden o Keine zusätzlichen Tabellen einfügen o Keine Trigger einfügen Es sollten keine Daten-manipulierenden Aktivitäten erfolgen (Inserts, Updates), also auch keine “Marken”, die bereits gelesene Informationen kennzeichnen. Auf den Maschinen des Quellsystems sollten nach Möglichkeit keine zusätzlichen Programme installiert werden, die sich negativ auf das Performanceverhalten auswirken. Umgang mit Datenqualitätsproblemen Operative Vorsysteme gehen in einer besonderen Art und Weise mit Datenqualitätsproblemen um. Meist benutzen die Systeme die Daten aufgrund ihrer eigenen Verwendungsansprüche und die Daten sind aus dieser Sicht sauber. Festlegen von Qualitätsstandards gemeinsam mit den Vorsystem-Verantwortlichen (z. B. Fachanwendern). Prüfung der Einhaltung dieser Standards in der Stage-Schicht des Data Warehouses. Nach Möglichkeit fehlerhafte Informationen zurückweisen, bzw. aussondern und sie den Vorsystemverantwortlichen zur Korrektur anbieten. Fehlerhafte Sätze sollten nicht „auf eigene Faust“ korrigiert werden. Stage - Schicht Die Stage - Schicht oder „Integration Layer“ ist eine eher technisch ausgerichtete Arbeitsebene. Hier findet statt: Überprüfung von o Syntaktischer Korrektheit (Typ, Länge, NULL) o Vollständigkeit der Daten und Mengenverhältnisse o Gültigen Wertebereichen o Vorhandensein von Referenzdaten o Eindeutigkeit (optional) o Eliminierung von NULL-Werten Zusammenführung operativ getrennter Daten Bilden neuer Informationsobjekte mit dem Ziel der einfacheren Weiterverarbeitung (optional) Waisen-Management (optional) Bildung von Daten-Deltas (optional) Folgende Empfehlungen gelten für den Umgang mit der Stage Schicht: Keine 1:1-Kopien Keine besonderen Datenmodell-Strukturen Wenn möglich, bereits beim Extrahieren Prüfungen und Wandlungen von Daten vornehmen Keine Indizes verwenden Stage ist leer, wenn nicht geladen wird Archivierung gelesener Sätze Eine sehr praktische Funktion kann es sein, die geladenen Informationen nach der Bearbeitung zu archivieren. Diese Daten können bis zum Abschluss einer folgenden Ladephase aufbewahrt werden, um z. B. Delta-Abgleiche vorzunehmen. Generische Stage-Strukturen Eine der häufigsten neu wiederkehrenden Anforderungen an Data Warehouse-Systeme ist das Einbinden von neuen Eingangsdatenströmen. Um nicht permanent neue Entwicklungsarbeiten an dem System vornehmen zu müssen, kann es sinnvoll sein, für einfach strukturierte neue Quellen (z. B. TextDateien), generische Eingangsschnittstellen zu entwerfen. Hierbei wird über eine einfache Metadaten-Information (z. B. Feldliste) ein Generator gesteuert, der dann ein neues Einlese-Programm erzeugt. Data Warehouse Technik im Fokus - Teil 1 - Architektur und Konzepte Operational Data Store (ODS) Operational Data Store Strukturen dienen: dem schnellen Bereitstellen aktueller Informationen der Unterstützung von Real-Time-Fähigkeit der Unterstützung von operativem Reporting Die Schicht ist eine Hilfsschicht, um temporär die relativ aufwendigen Prüf- und Integrationsvorgänge in der Stage - Schicht zu umgehen. Operational Data Store - Informationen gelangen erst zu einem späteren Zeitpunkt oder sogar gar nicht in die Data Warehouse - Schicht. Diese Informationen sind nur für ausgesuchte Zwecke bestimmt und erheben nicht den Qualitätsanspruch der übrigen Data Warehouse - Daten. Folgende Eigenschaften gelten: Es findet eine auf Subjekte / Objekte bezogene Integration statt o Wie z.B. Kunde, Bestellung Die Gültigkeit ist auf die aktuelle Ladeperiode beschränkt. Es sind daher flüchtige Daten Die Daten befinden sich auf Transaktionslevel Direkter Zugriff durch Benutzer ist möglich Daten befinden sich in einem syntaktisch und semantisch geprüften Zustand (wenn möglich) Letztlich analog zur DWH-Schicht, nur ohne Historisierung Die (Kern-) Data Warehouse Schicht 12 allgemeine Sammlungen wie Feiertage, Steuertabellen, Geographiedaten, Währungskurse Bewegungsdaten o Angesammelte Daten aus allen Berichtsperioden o Zumindest die letzten Ladeperioden in sehr granularer Form, danach eventuell aggregiert oder mit Referenzen auf Archivierungen o Management von Daten und Informationen in der Data Warehouse Schicht - gegen Datenchaos An die Data Warehouse-Schicht werden ganz besondere Ansprüche gestellt. Die in ihr gesammelten Daten sind nicht nur von einer besonderen Datenqualität geprägt, ihre Ablage erfolgt auch in einer besonders systematisierten Art und Weise. Diese Systematik ist unbedingt notwendig, um den Wert und die volle Funktionsfähigkeit des Systems zu erhalten. In heutigen Data Warehouse Systemen tritt eine Herausforderung besonders zu Tage, die auch nicht durch die Mittel der Datenmodellierung zu erfüllen ist. Es ist die Verwaltung von Dateninhalten nach semantischen Gesichtspunkten. Die Datenmodellierung löst die Datenobjekte nur nach ihrer Struktur auf. Sie hat aber keinen Einfluss auf die Inhalten der Daten. Verhindert wird nicht, dass eine bestimmte Information mehrfach unter geänderten Namen vorkommen kann. Man spricht von Homonymen und Synonymen. Diese Problematik kann den Nutzen eines Data Warehouse Systems erheblich schmälern. In einigen Fällen sind durch diese unkoordinierte Verwendung von Inhalten mehrjährige Investitionen im Millionen-Umfang gefährdet. Die Kern Data Warehouse - Schicht ist die eigentliche, „wichtige“ Daten-Instanz des gesamten Data Warehouse - Systems. Hier befinden sich die Warehouse-Informationen, nachdem sie in der Stage Schicht geprüft und integriert wurden und bevor sie wieder in der Data Mart-Schicht für die Verteilung aufbereitet werden. Folgende Anforderungen gelten für die Data Warehouse - Schicht: Eindeutigkeit aller Objekte und Namen Redundanzfreiheit aller Informationen Bereichs- und Themen-übergreifend Anwendungs- und Geschäftsprozess-neutral o Objekte werden in mehreren Geschäftsprozesse benötigt o Daten müssen tauglich genug sein, um sie in allen Anwendungen zu verwenden Langlebigkeit der Daten (Historisierung) o Historisierung wird hier angelegt. In der Data Mart - Schicht kann es seine alternative oder ergänzende Historisierung geben Die Informationen liegen auf einem sehr granularen Level vor, damit die Daten leicht in neue Informationszusammenhänge überführt werden können. o 3 NF Modellform Folgende Informationsarten sind hier zu finden: Stammdaten o Historisiert (Slowly Changing Informationen) o Synchronisiert mit MDM-System Referenzdaten o externe (Partnerinformationen, Partnerproduktkataloge, Kontaktdaten etc. o interne (Mitarbeiter-, Abteilungsverzeichnisse, Abkürzungen, Regeln etc. Homonyme n / Sy nonymen - Problematik als Hauptur sac he für „Datenc haos“ Gelöst wird die Problematik durch eine Reihe von zusätzlichen Maßnahmen in der Data Warehouse - Schicht bzw. bei dem Übergang von der Stage - in die Kern-Warehouse-Schicht. Diese Maßnahmen können im weitesten Sinn auch als Data Governance-Maßnahmen bezeichnet werden. Die Aufgabenstellung und die damit verbundenen Lösungen sind alt, der Begriff Data Governance wird heute aber breit diskutiert. Hilfsmittel sind: Repository-System Informationskatalog oder Inventar o Metadaten-gestütztes Verzeichnis aller Datenobjekte in einem Data Warehouse o Mehrere Zugriffs- / Suchstrategien auf bestehende Objekte o Deskriptoren-Verfahren zum Qualifizieren von Objektnamen und Erleichtern der Suchstrategien Beschreibungen über den Zustand, Alter und Zuständigkeiten zu den Informationen Datenqualitätsstandards und Prüfregeln Namenskonventionen Data Warehouse Technik im Fokus - Teil 1 - Architektur und Konzepte Metadaten Repository zur Dokumentation der Inhalte und Zusammenhänge Eines der wichtigsten Hilfsmittel für die zu lösende Dokumentationsaufgabe ist ein Metadaten Repository. Ein solches Hilfsmittel ist bei den heute genutzten Data Warehouse Systemen wichtiger denn je, auch wenn es in der Praxis bislang kaum in der gewünschten Art eingesetzt wird. Hier ist kein Tool-bezogenes Repository gemeint, also ein Repository, das ein ETL-, Daten- oder Prozessmodellierungstool mitbringt. Es ist ein Werkzeug gemeint, das übergreifend Strukturen und inhaltliche Zusammenhänge in dem gesamten Data Warehouse beschreibt. Ein solches Werkzeug verhindert die mehrfache Modellierung von gleichen ETL-Strecken, Tabellen- und View- Definitionen, sowie redundante Dimensionen und Kennzahlen. 13 Suche über o Scope, Typen und beliebige Attribute Strukturauflösung in beliebiger Tiefe Automatischer Metadaten-Import Externe Referenzen Beliebig erweiterbar Frei programmierbar Data Warehouse Information Model In einem solchen Repository System wird ein Data Warehouse Informations-Modell implementiert. Das ist die Summe aller Metadaten-Typen, deren beschreibende Attribute-Typen und die Beziehungen zwischen den Metadaten-Typen. Ein solches MetadatenInformationsmodell ist von Data Warehouse zu Data Warehouse unterschiedlich, weil jedes Data Warehouse andere Inhalte aus dem jeweiligen Unternehmen widerspiegelt. Hierzu benötigt man ein generisches Repository, in dem die Definitionshilfsmittel in Form von Metadaten-Typen, MetadatenAttributen und Metadaten-Beziehungen selbst individuell definiert werden können. Beis piel für e in Metadaten -Informations-Mode ll Prinzip de s gener isc hen 4 -Schichte n-Repos itorie s Ein Beispiel für ein solches Repository ist der folgende Oracle-APEXbasierte Prototyp. Mit diesem Repository ist die Grundlage für alle anderen Data Governance-Maßnahmen gelegt. Begriffsdefinitionen und Glossars Die unternehmensweite Standardisierung von Begriffen und Bezeichnern ist eine wichtige Voraussetzung für ein gemeinsames Verständnis der Informationen in einem Data Warehouse. Über die Attributierung in dem Repository wird zu jedem Begriff eine Definition, der Verwendungszweck und die Herkunft beschrieben. Über Beziehungen lässt sich eine synonymes oder auch homonymes Verhältnis zu anderen Begriffen dokumentieren. Bei solchen Begriffsdefinitionen ist regelmäßige Pflege wichtig. Daher wird auch die für die Pflege verantwortliche Stelle dokumentiert. Dieser Prototyp verfügt über: Frei definierbare Meta-Typen o Objekte, Attribute, Beziehungen Die Begriffe präsentiert man über eine Web-Oberfläche, so dass alle Mitarbeiter die Definitionen einsehen können. Sollen neue Begriffe erfasst werden, sucht man zunächst mit den Hilfsmitteln des Repositories ob entsprechende Begriffe bereits vorhanden sind. Data Warehouse Technik im Fokus - Teil 1 - Architektur und Konzepte Deskriptoren-Verfahren Die zuvor dargestellten Begriffslisten bzw. Glossare eignen sich gut als Anwendungsfall für das Deskriptoren-Verfahren. Die Definition der Begriffe alleine ist es noch nicht ausreichend. Bei mehreren Tausend Definitionen wird die Menge den Erfolg zunichte machen und es schleichen sich doch wieder Synonyme bzw. Homonyme ein. Das Deskriptoren-Verfahren beschreibt die einzelnen Begriffe zusätzlich über feststehende Schlagwörter die in unterschiedlichen Kategorien, oder auch Klassen genannt, definiert wurden. Die Klassen entsprechen den Blickwinkeln aus denen heraus man den Begriff beschreiben will. Beis piel für die K lassifizierung eines Be gr iffs Beis piel für De skr iptore n -Klass en: Sammlunge n von festste hende n Beschre ibungsw erten Das Deskriptoren-Verfahren kann man auf alle relevanten Metadaten-Typen anwenden, z. B. auf Kennzahlenbeschreibungen, Berichte aber auch auf mehr technisch ausgerichtete MetadatenTypen wie Tabellen oder Materialized Views. Alte Daten - neue Daten Eine weitere Herausforderung kann es sein, das Data Warehouse von obsoleten Daten zu entrümpeln. Hierzu müssen alte und nicht mehr genutzte Daten identifiziert werden können. Hilfsmittel sind: Markieren aller Sätze beim Laden mit o Load-Datum o Letztes Änderungsdatum o Status-Feld für Aktuell Für Jahresvergleiche relevant Obsolet o Geladen aus Verfahren X,Y,Z o Geladen für Abt. A, B, C Herausfiltern der aktuellen Sätze über Beziehungsabfragen mit Zeiteinschränkung Einsatz von Partitioning o Erlaubt das Arbeiten nur auf den aktuellen Daten 14 Tabellen, i . d. R. aus dem Bereich der Bewegungsdaten im Data Warehouse können mit zusätzlichen Spalten versehen werden wie etwa: Owner Org_Unit Benutzer Angelegt _am Zuletzt_geändert_am Geschäftsprozess Status Data Warehouse Technik im Fokus - Teil 1 - Architektur und Konzepte ETL - Extraktion, Transformation, Load Data Warehouse Systeme erhalten in definierten Zeitabständen neue Daten aus den operativen Vorsystemen. Waren früher die Zeitabstände eher länger (Wochen, Monat, Quartal), so ist heute das tägliche Laden der Standard-Fall, oft findet man bereits untertägiges, stündliches Laden oder sogar das permanente Laden. Entscheidend bleibt der Punkt: Folgende Aktivitäten finden während des ETL-Prozesses statt: Erfüllt das Data Warehouse noch seine originären Funktionen des Integrierens, des semantischen Abgleichs und der Umwandlung im Sinne von Normalisieren und Denormalisieren. In manchen Diskussion wird der Realtime-Aspekt als Merkmal des Modernen dargestellt. In solchen Diskussionen sollte man immer den Zweck des Systems mit bewerten bevor die reine Technologie zum Selbstzweck wird. ETL vs. ELT In jüngster Zeit ist in Diskussionen der Begriff ETL durch den Begriff ELT ersetzt worden. Auch solche Begrifflichkeiten sollten auf ihren Zweck hin hinterfragt werden. Mit dem Begriff ELT (Extract Load Transform) wollen Tool-Hersteller zum Ausdruck bringen, dass Daten aus den Vorsystemen zunächst in das Zielmedium (Datenbank) geladen werden, um sie dort zu transformieren. Die Datenbank ist die eigentliche Transformations-Engine. Die Argumentation kommt ehemals von der Firma Sunopsis, die damit das Native-Generieren von SQL-Kommandos unterstreichen wollte. Dies ist eine Abgrenzung gegenüber Engine-basierten Werkzeugen wie Informatica, Data Stage oder Ab Initio, bei denen Daten in einem separaten Programm (Engine) transformiert werden und das Ergebnis dann in die Zieldatenbank gelangt. Sunopsis wurde von Oracle gekauft und das Produkt in ODI umgetauft. Oracle verfügte jedoch bereits über ein Native-SQLgenerierendes Werkzeug (Oracle Warehouse Builder). Die Argumentation ELT vs ETL wurde beibehalten. Sie trifft aber auch für Warehouse Builder zu. Hier werden beide Begriffe synonym genutzt, da es hier primär nicht um Marketingaussagen geht. Die Aufgabenstellung des ETL Folgende Anforderungen sind an den ETL-Prozess zu stellen: Backbone des DWH Transfer-Medium über alle Schichten hinweg o Vermittlungsfunktion o Übernimmt oft Dokumentationsaufgabe Bewegen großer Datenvolumina bei gleichzeitiger komplexer Transformation Standard-Lösung wird benötigt o Nicht zu komplex (Entwickler-Spielzeug) o Verständlich auch für Business User o Leichte Erklärbarkeit für Dritte Bereitstellen von Daten in adäquater Weise o Zeitlich passend o Richtige Form o Passende Inhalte Daten so ablegen, dass man sie wiederfindet o Dokumentation Daten Ressourcen-ökonomisch speichern o Berücksichtigung von Plattenplatz Es sollte nur das geladen werden, was wirklich gebraucht wird 15 Gibt es einen Auftrag für das Laden bestimmter Daten? o Wer braucht die Daten? o Welche Daten werden gebraucht? Sind die zu ladenden Daten in einem brauchbaren Zustand? o Welche Anforderungen sind an Quelldaten zu stellen? o Wer definiert die Anforderungen? Standardfunktionen Insert, Update, Delete, Merge (Insert / Update) 1:1-Transformationen (reines Kopieren, auch mit minimalen Änderungen) Selektionen (z.B. Where-Klauseln, Bedingungen) Gruppierende Transformationen (Aggregationen, Sortieren, Segmentieren) Pivotierende Transformationen (Verändern der Kardinalität von Zeilen und Spalten) Berechnungen (einfache oder komplexe, Funktionen oder Programme) Formatieren von Daten Zusammenführende und spaltende Transformationen (Join / Split) Anreichernde Transformationen (Referenzen auslesen, Lookups, Konstanten, Fallunterscheidungen) Aussortieren / Trennen von Datenbereichen Prüflogik (logisch / fachliche und physisch / technische) Protokollierende Maßnahmen (Log Files, Statistiken) Steuerungen (Rules-Systeme) Kommunizieren mit anderen Systemen (Messages senden / empfangen / quittieren) Die ETL-Aktivitäten lassen sich in 4 Bereiche gliedern: 1. Integrieren: Identifizieren von identischen oder zusammenhängenden Informationen o Synonymen-/Homonymen-Thematik Aggregationslevel angleichen o Identifizieren und Angleichen Formate, Zustände, Sichtweisen etc.... 2. Informations-Mehrwerte Qualitativ gute Informationen schaffen o Datenqualitäts-Checks Vollständigkeit Datentypen Referentielle Integrität Eindeutigkeit Korrekte Werte o Fachliche Regeln überprüfen Berechnungen / Aggregationen / Zusammenfassungen Anreichern und Vermengen mit Referenzdaten o Lookups o Marktdaten o Vergleichszahlen 3. Kopieren 1:1-Datenbewegung o Einfachste Aufgabe Mengen-Operationen o Ohne zusätzliche Logik Überwindung von Systemgrenzen Data Warehouse Technik im Fokus - Teil 1 - Architektur und Konzepte o Vorschriften zum Mapping o Schnittstellen-Konventionen Aspekt der Performance 4. Sammeln Einlagern von Daten o Zeitliche Rahmenvorgaben o Historisierung Versionieren von Daten Kategorisieren / Inventarisieren von Daten o Dokumentieren der eingelagerten Informationen Referenzen aufbauen Alterungs-Eigenschaften berücksichtigen Dokumentieren Mehr als nur eine Momentaufnahme 16 Zus ammenzie he n von Tr ans for mationen in den Bere ich der Stage Schic ht Zusammenfassen kann der ETL-Prozess wie folgt auf das SchichtenModell übertragen werden: Datennahe Transformationen für Daten-orientiertes Data Warehouse Im Gegensatz zu OLTP- oder SOA-basierten Systemen sind Data Warehouse - Systeme Daten-orientiert. Die Datenablage an sich stellt den eigentlichen Wert dar. Ein Datenbank-System wie Oracle stellt damit die ideale Plattform für ein Data Warehouse dar. Daher ist es nur folgerichtig, wenn auch das Laden und Transformieren der Informationen möglichst nahe an den Daten stattfindet. Auch wenn moderne Anwendungen heute über eine Middleware Komponente verfügen ist das Laden und Transformieren über die Datenhaltungs-Instanz am sinnvollsten, da hier die größten Synergie-Effekte erzielt werden können. Verteilung der ETL -Aktiv itäte n auf die 3 Sc hic hte n des Data Warehouse Sys tems Generieren statt modellieren Programmieren- Mit Graphik Auch wenn mit Bordmitteln der Datenbank (SQL, PL/SQL) gearbeitet wird, sollten die nötigen Datenbank-Objekte nicht manuell programmiert werden. Hierzu stehen heute graphische Editoren, wie z. B. durch Oracle Warehouse Builder (In Database ETL) zur Verfügung. ETL-Operationen im Data Ware house s ollten Daten - zentr iert in der Datenbank s tattfinden Das bedeutet, auch wenn operative Systeme z. B. über eine Service-orientierte Kommunikationsstruktur verfügen und darüber Daten auch in ein Data Warehouse gelangen können, so sollten das Gros der Transformationsroutinen und Logik Daten-nah, also mit den Bordmitteln der Datenbank stattfinden. Das 3-Schichten-Modell und der ETL-Prozess Die oben vorgestellte Schichten-Architektur kann und sollte auch zur besseren Organisation des ETL-Prozesses beitragen. Ein gut organisierter ETL-Prozess versucht so viele Transformationen so früh wie möglich durchzuführen, damit diese nur ein einziges Mal zu erledigen sind. Übertragen auf das Schichten-Modell bedeutet dies, dass die meisten Transformationen innerhalb der Stage-Schicht stattfinden sollten. Auf dem Weg der Daten in Data Mart-Schicht sollten dagegen nur einfache, aggregierende Join-Operationen erfolgen. Diese Vorgehensweise hat folgende Vorteile: Vermindern von Fehlern durch Handprogrammierung Tabellen- und Spaltennamen müssen nicht mehr mühsam geschrieben werden Steuerung vieler Entwicklungsschritte durch Wizards Automatische Steuerung von Ziel- und Quellschemata Automatische Validierung (z.B. Typverträglichkeiten) Debugging der Laderoutinen Laufzeitumgebung steht bereit Dokumentation Data Warehouse Technik im Fokus - Teil 1 - Architektur und Konzepte 17 Wiederholbarkeit des Ladelaufs Ladeläufe sollten generell so gestaltet sein, dass sie jederzeit mit der gleichen Quelldatenmenge wiederholt werden können. Hilfsmittel hierfür sind: Flashback (Oracle Datenbank - Flashback, damit wird ein Zustand vor der Ladeaktivität wieder eingestellt) Steuerung über eindeutige Schlüssel. Hierbei merkt man sich die durch die letzte Ladeaktivität neu entstandenen Schlüssel. Mengen-basiertes oder Einzel-Delete löscht die fehlerhaften Sätze. Separates Datenschema und späteres Überführen in Zielschema bzw. Laden in getrennten Partitionen. Steuerung über Inkrement-Load-Nummer oder Tagesdatum. Mengen-basiertes oder Einzel-Delete löscht die fehlerhaften Sätze. Load-Inkremente als Strukturierungshilfe für den Ladeprozess Die Einteilung in sogenannte Load-Inkremente hilft beim Steuern des Lade-Vorgangs. Portionierung von Ladestrecken-Etappen Einteilung nach o Schichten o Quellsystemen o Zielsystemen o Datum / Zeit o Versionen o Häufigkeitsnummern (Load-Inkrement) Die Verteilung von Load-Inkrementen auf die Schichten des Data Warehouses erfolgt nach folgendem Schema: Tabelle n des L oad-Managers Deltadatenerkennung Das Erkennen von geänderten Daten der operativen Vorsysteme stellt eine besondere Herausforderung da. Es gibt folgende technische Möglichkeiten zur Steuerung: Das Vorsystem liefert nur die geänderten Daten. Dies stellt die einfachste Lösung dar, sie ist jedoch selten, da dies zusätzlichen Aufwand für die Vorsysteme bedeutet. Allerdings kommt dies im Umfeld von SAP R/3 relativ häufig vor, weil R/3 sehr stark gekapselt ist. Abgreifen über Zeitstempel in den Quell-Tabellen. Dies ist eine einfache Methode. Sie funktioniert jedoch nur, wenn es solche Zeitstempel gibt. Erstellen von Triggern und temporären Tabellen im Quellsystem. Diese Variante ist nicht zu empfehlen, da sie das Quellsystem beeinflusst. Auslesen der Log-Dateien. Diese im Prinzip sehr gute Variante funktioniert jedoch nur bei Datenbanken mit LogDateien. Oracle Golden Gate nutzt diese Variante. Komplett-Kopie und SQL-Minus-Operation. Diese auf den ersten Blick sehr aufwendige Operation funktioniert in der Praxis trotz der großen Datenmenge, die bewegt werden muss, erstaunlich gut. Verteilung von Load-Inkreme nten auf die W arehous e Schic hten Die einzelnen Load-Inkremente können Namenskonventionen zusätzlich verwaltet werden: auch über Delta-Date n-Erkennung mit SQL -Minus-Oper ation Datenbank-interne Lade-Läufe schnell machen Beis piel für die Be nennung von Load -Inkreme nte n Load Inkremente können schließlich mit einem Load-Manager verwaltet werden. Der Load Manager stellt nur ein einfaches Tabellenwerk dar, in dem alle Load Inkremente erfasst sind. Über eine zentrale Load-Nummer (RUN_NUMBER) werden alle Inkremente eines zusammenhängenden Ladelaufs identifiziert. Das Laden von Daten mit SQL - Mitteln innerhalb der Datenbank erfordert einige Grundprinzipien in dem Umgang mit Constraints und Indexen. Ein typicher Ablauf sieht wie folgt aus: Constraints abschalten Indizes löschen Laden über “Direct Path” o Constraint-Prüfung mit SQL-Mitteln Eventuell Löschen alter Daten o Oder Archivieren Data Warehouse Technik im Fokus - Teil 1 - Architektur und Konzepte Aktivieren der Constraints o (Sofern überhaupt gebraucht) Neu-Aufbau von Indizes Statistiken aktualisieren o DBMS_STAT Der Umgang m it Tabellen im V erlauf de s L ade ns in der Date nbank Die Vorteile des SQL der Datenbank bei den Ladeaktivitäten SQL kann in dem gesamten Data Warehouse als Haupt-Lade- und Transformationssprache eingesetzt werden. Hierdurch vereinfacht sich der Umgang mit der eingesetzten Technologie erheblich, da nur eine Sprache beherrscht werden muss: SQL als Transformations-Sprache hat folgende Vorteile: SQL basiert, d.h. die Oracle Datenbank wird ausgenutzt o Möglichkeit primär mengenbasierte Operationen durchzuführen o Wesentlich höhere Performance o Automatisiertes Datenbankgeregelte Parallelisieren o Datenbankgestütztes Ressourcen Management Unterstützung aller aktuellen Datenbank-ETL-Funktionen wie o Multiple Inserts o Merge (Insert/Update) o Direct Path Load o Table Functions o Partition Exchange and Load Vollständige Hints-Bibliothek Verwendung aller Datenbank-Funktionen, z.B. auch analytische Funktionen o Im Gegensatz zu den von Drittherstellern nachgebildeten z.T. unvollständigen Funktionen (Beispiel SQL CASE, Decode) Datennahes Entwickeln 18 Leichtes, performantes und mengenbasiertes Update von Sätzen o Ausnutzen temporärere Strukturen Temp-Tables Cache-Tables o Ausnutzen besonders schneller Tabellen-Objekte Index-Based Tables o Direkter Zugriff auf Tabelleninhalte Nähe zu Katalogstrukturen o Alle Informationen stehen sofort zur Verfügung Komplett-Definition aller physikalischen Objekte im Data Warehouse o (Tables, Index, Materialized Views, Partitioning ...) o Data Warehouse Technik im Fokus - Teil 1 - Architektur und Konzepte Checkliste zur Planung und dem Neuaufbau von Data WarehouseSystemen Anforderungsdefinition zu dem System Ziel des Systems abstimmen Nutzergruppen und Nutzererwartung feststellen / Nutzen Lifecycle der Warehouse-Daten Aktualität der Daten festlegen Delivery Management Wiederholbarkeit von Ladeläufen prüfen Update-Plan (Update / Read-Only) Beschaffungs-/aufbereitungslatenz prüfen / definieren Architektur So kompakt wie möglich wählen - minimieren auf ein System Schichten-Schnitte nach fachlogischen Gesichtspunkten wählen (3-Schichten-Modell) Organisatorische Einbindung Mitarbeit Endbenutzer Managementsponsor Security Zugriffsplan für Kennzahlen festlegen Zugriff auf alle Schichten durch Endbenutzer Mandantenfähigkeit Logische Modellierungung Homonymen / Synonymen - Check Einführen von DWH-spezifischen Schlüsseln für KernStammobjekte Logische Datenmodellstrukturen in den Schichten Physikalisches Design Tabellenplan / Tablespaces Indexstruktur (Einsatz von Varianten) Sizing-Plan Datenmengen kontrollieren (Nutzerdaten) Wachstumserwartung feststellen Hardware „Private“ Hardware für das DWH o Storage nur für DWH o Netzwerk zwischen Storage und DWH Server nur für DWH o Konzentration aller Schichten auf einer zusammenhängenden Hardware o Ausbaufähigkeit für Wachstumserwartung berücksichtigen DWH-System verändern ihre Größe schneller als OLTP Skalierung über Hardware-Cluster prüfen 19 Effizienz im DWH Reduzieren von Datenmengen o Nur genutzte Daten speichern (Usage: Records und Columns) Reduzieren von Ladeläufen o Keine unnötigen Kopien o Kompakte Ladeläufe o Keine 1:1 Bewegungen Synergien schaffen o So früh wie möglich transformieren Keine Maintenance-Aktivitäten während ETL o Aktualisierungsplan von Indexen Kontinuierliche Verbrauchsdaten sammeln o Belegter Plattenplatz o Laufzeiten o Antwortzeiten Übersicht im DWH Ownerschaften feststellen Inventar/Metadaten-System implementieren Glossar zur Begriffsstandardisierung einführen Datenmodelle visualisieren Lineage/Impact visualisieren Quell- / Zielsysteme bekannt? Struktur Zugriffsmethode Verfügbarkeit Grad der Verfügbarkeit festlegen Gesamtsystem Teilsysteme Backup- / Recovery für das DWH Incremental Diversifizierung der Datenbestände Read-Only Aus Fremdbeständen wieder herstellbare Daten Backup reduzieren auf geänderte Daten Data Warehouse Technik im Fokus - Teil 1 - Architektur und Konzepte Hardware wichtiger Bestandteil im Data Warehouse Für die Konzeption von Data Warehouse-Systemen ist in den letzten Jahren die Hardware noch stärker in den Fokus gerückt. Gründe sind die enormen Leistungsanforderungen eines DWHSystems gegenüber den meisten OLTP-Anwendungen wobei z. T. sehr große Datenmengen in angemessener Zeit zu bearbeiten sind. Bei der Lösung dieser Herausforderung helfen gleich mehrere Technologien. Die Hardware stellt eine wichtige Voraussetzung dar. Hardwar e-Kompone nte n in einem Data Warehouse als Einheit betr achte n „Private“ Hardware ungeschriebene Regel DWH Systeme nutzen Speicherplatten und Netzwerk in einer anderen Weise als OLTP-Anwendungen. Daten werden in größeren Mengen und eher in zusammenhängenden Einheiten verarbeitet. Wichtig ist die Datenmenge pro Sekunde, die ein System bereitstellen kann (MB/sec). OLTP-Systeme lesen und schreiben dagegen mit höherer Frequenz kleinere Datenmengen. Die Anzahl der IO-Operationen pro Sekunde ist die Kenngröße (IOPS). Die Hardware kann nicht für beide gegenläufige Anforderungen gleichzeitig konfiguriert werden. Eine einfache Lösung ist das Trennen der Hardware für DWH und OLTPSysteme. DWH-Systeme sollten über eigene Rechner, eigenen Speicher und ein separates Netzwerk verfügen, über das auf die Speicherplatten zugegriffen werden kann. 20 Oracle’s Database Machine verfolgt diesen Ansatz konsequent, indem sie Speicher, das extrem schnelle Infiniband-Netzwerk und die Server-Maschinen in einer Einheit zusammenfasst und ein Data Warehouse als Datenbank-Anwendung bedient. Speicherhierarchien Anwender nutzen die Daten in einem Data Warehouse meist unterschiedlich häufig. Die wenigsten Daten nutzen sie regelmäßig und die Nutzungshäufigkeit nimmt mit zunehmendem Alter der Daten ab. Heute stehen unterschiedlich performante Speichermedien bereit, wobei eine höhere Zugriffsgeschwindigkeit auch höhere Kosten mit sich bringen. Die Oracle Datenbank erlaubt es mit ihren technischen Möglichkeiten unterschiedliche Speichervarianten auszunutzen. Häufig genutzte Daten können permanent im Hauptspeicher (RAM) vorgehalten werden. Damit sind komplette Data Mart extrem performant InMemory abfragbar, auch wenn sie mehrere Terabytes umfassen. Die nächste etwas kostengünstigere Technologie, Flash Speicher, kann man als 2nd Level Cache konfigurieren, der Daten persistent vorhalten kann und immer noch bis zu 200 mal kürzere Antwortzeiten liefert als Festplatten. SAS und SATA Platten unterscheiden sich durch ihr Speichervolumen und durch Performancewerte. Die schnelleren aber kleineren SAS-Platten eignen sich als klassische Speicherablage im Data Warehouse, während SATA-Platten durch ihr höheres Speichervolumen für seltener genutzte Daten sinnvoll sind. Das kommt der typischen Data Situation in Warehouse-Systemen entgegen, bei der meist ein überproportional großer Anteil der Daten sehr selten gelesen wird. Zur Entlastung des DWH-Systems ist es sinnvoll, kaum genutzte Daten zu archivieren. Sollen dieses Daten dennoch im Zugriff sein, sollten sich diese „prinzipiell“ archivierten Daten dennoch im Online Zugriff befinden. Das Oracle Datenbank-System kann solche Daten auf kostengünstigem Massenspeicher vorhalten und sie Benutzern ständig online verfügbar anbieten. Über die DWH Logistic Utilities stehen Funktionen für ein intelligentes Verschieben alternder oder weniger häufig genutzter Daten bereit. Spe icher-Hier arc hie für unters chie dliche Nutzungs ar ten In Memory Parallel Execution Die Oracle Datenbank kann über die Real Application Clusters (RAC) - Technologie mehrere Rechner als Cluster zusammenschalten. Das garantiert zum einen eine sehr hohe Ausfallsicherheit, zum anderen können Rechnerknoten dediziert einzelnen Aufgabenstellungen (ETL-Load-Jobs, Reporting-Jobs, Online-Betrieb usw. ) effizient zugeordnet werden. Damit können unterschiedliche Nutzungsprofile die gleiche Hardware ausnutzen. Das neue Verfahren des InMemory Parallel Execution kann die Hauptspeicher (RAM) aller RAC-Knoten-Rechner so nutzen, als wenn es sich um einen durchgängigen Speicher handeln würde. So kann das System auch große Datenmengen (ganze Data Marts) permanent im Hauptspeicher des GesamtClusters für Abfragen anbieten. Data Warehouse Technik im Fokus - Teil 1 - Architektur und Konzepte 21 Architektonische Vorteile RAC und ETL Alle E bene ne n eines Sys tems als Cluster aufge baut Hardware-Aspekte Storage und Plattensysteme Data Warehouse Technik im Fokus - Teil 1 - Architektur und Konzepte Allgemeine Aus ETL-Sicht Aufbauempfehlungen RAC Kompression: Verwaltung und Kosten reduzieren Wieviele Platten-Controller? Database Machine (Exadata) Alle vorgenannten Hardware-Aspekte lassen sich mit konventioneller Hardware-Technik von den meisten HardwareAnbietern umsetzen. Den geringsten Aufwand und die größten Nutzen-Effekte erzielt man jedoch mit dem Einsatz von Oracle’s Database Machine (DBM) und der dort implementierten ExadataStorage-Software. Als fertig vorkonfiguriertes System senkt die DBM Einführungsaufwand und Verwaltungskosten. Sie liefert 8 RAC-Knoten-Rechner mit 96 CPU Cores und 14 Storage-Server mit weiteren 112 CPU-Cores und 30 TB (100 TB Kapazität) SAS Storage bzw. 98 TB (300 TB Kapazität) SATA Storage. Verbunden sind beide Rechnergruppe mit einem eigenen 40 Gb InfinibandNetzwerk. 22 Die Exadata-Storage Software beschleunigt das System über sog. Smart-Scan-Verfahren, einem neu entwickelten Zero-CopyDatenprotokoll und einer speziellen Storage-Index-Technik auf bis zu 25 GB/Sec Datendurchsatz, die Abfragen in der Datenbank zur Verfügung stehen. Aufsc hnitt e ine r Database Mac hine Data Warehouse Technik im Fokus - Teil 1 - Architektur und Konzepte Kleine Vorschau auf einzelne Oracle Datenbank-Technologien Immer die passende Datenmodell-Form Grundsätzlich gibt es keine Einschränkung bei der Wahl einer passenden Daten- und Schichten-Architektur. Die Oracle Datenbank ist für die unterschiedlichsten Verwendungen, ob OLTP oder Data Warehouse, ob klassisches DWH, Realtime- oder Active-DWH einsetzbar. Sie unterstützt alle Datenmodell-Varianten wie 3NF, Star- und Snowflake-Schema. Sie bietet mit der OLAP-Option auch eine multidimensionale Speichervariante mit vorberechneten Kennzahlen an. 23 Mit Partitioning große verwalten Datenmengen leicht Das Partitionieren großer Tabellen gehört mit zu den wichtigsten Hilfsmitteln des Oracle Data Warehouse. Partitioning teilt die Daten großer Tabelle in physikalisch separierte Mengen und spricht diese Teilmengen separat an. Dadurch müssen bei entsprechenden Abfragen nur die Partitionionsdaten aber nicht die gesamte Tabelle gelesen werden, so dass eine gute Abfrageperformance entsteht. Zum anderen schafft es durch die kleineren Datenpakete Verarbeitungseinheiten für die Verwaltung. Das hilft in dem ETLProzess, bei der Indizierung, bei der Komprimierung oder dem Sichern der Daten. Würfel, Star-Sc hema und 3NF Mode lle in e iner D ate nbank In dem jüngsten Release kommt auch eine spalten-orientierte Speicherung zum Zuge, die für das Lesen von lediglich wenigen Spalten in einer Tabellen Vorteile zeigt. Entscheidend ist die Wahlfreiheit bei der Verwendung dieser Modelle. Für das Anbieten Geschäftsobjekt-naher Daten bei EndbenutzerAbfragen eignen sich Starschema-Modelle. Zum Vorhalten unternehmensweit-geltender einmaliger Informationen in zentralen Warehouse-Schichten eignen sich 3NF-Datenmodelle mit sehr granularen Informationseinheiten, weil aus diesen Daten meist andere Daten abgeleitet oder neu kombiniert werden. Empfohlene Architekturen in unternehmensweiten Systemen Partitionen habe n v iele Funktione n Die am häufigsten genutzte Variante ist das Rang-Partitioning bei dem die Einteilung der Partitionen entlang definierter Wertebereiche erfolgt. Das im DWH am häufigsten genutzte Kriterium ist die Zeit (z. B. Tage, Monate). Auch zusammengesetzte Felder oder über Funktionen ermittelte Werte können ein Partitionierungskriterium sein. Die Variante List-Partitionierung ordnet Daten aufgrund der Zugehörigkeit zu definierten Werten oder Begriffen. Die Einteilung nach Verkaufsgebieten „Nord“, „Sued“, „West“, „Ost“, „Mitte“ ist ein Beispiel. Klass isc hes 3 -Sc hic hten-Sc hem a In unternehmensweit aufgestellten Data Warehouse Systemen hat sich Aufbereitung der Daten in drei Schritten bewährt: 4) 5) 6) Man sammelt, integriert und prüft auszuwertende Daten der operativen Vorsysteme. (Stage) Man granularisiert diese Daten in einem alle Sachgebiete umfassenden (meist 3 NF) - Schema. (DWH-Schicht) Je nach Zielgruppe und Sachgebiet fügt man im letzten Schritt die granularen Informationsbausteine meist zu zu multidimensionalen Endbenutzer-Modellen (meist Starschemen) zusammen. (Data Marts) Nicht immer liegen Partitionierungskriterien vor. Die HashPartitionierung überlässt das Partitionieren der Daten der Datenbank. Dies ist dann hilfreich, wenn einerseits Datengruppen gebildet werden sollen und andererseits Daten gleichmäßig über die Datengruppen hinweg zu verteilen sind. Die Varianten lassen sich über Sub-Partitioning mischen, um das Partitionieren noch flexibler zu gestalten. Das grundlegende Partitionierungskriterium kann z. B. eine Monatseinteilung sein (Range) und die Monatspartitionen können noch weiter nach Verkaufsgebieten unterteilt sein. Dieses ist eine Ressourcen-schonende Vorgehensweise mit der Betonung auf Wiederverwendung von Daten und Entwicklungsarbeiten bei gleichzeitiger Flexibilität durch beliebige Auswerte-Szenarien. Um Synergie-Effekte möglichst komplett zu nutzen empfiehlt Oracle alle 3 Verarbeitungsschritte bzw. Schichten in einer einzigen Datenbank-Instanz und damit auch HardwareUmgebung anzusiedeln. Partitioning mit Subpartitioning Data Warehouse Technik im Fokus - Teil 1 - Architektur und Konzepte Aufbau eines Daten Life Cycle Mangements Man kann das Partitioning-Instrument nutzen, um alternde Daten innerhalb der Speichermedienhierarchie auf weniger performante aber dafür kostengünstigeren Speicher zu kopieren. Diese Kopierprozesse sind über die Warehouse-ManagementFunktionen automatisierbar. 24 ersten Schritt eine Reihe von Materialized Views, die nur allgemein einschränkende Bedingungen haben und noch viel Raum für weitere Spezialisierungen lassen. Hier würden etwa aufwendige Join-Operationen Platz finden. Eine Reihe weiterer Materialized Views basiert auf den Ergebnissen der vorgenannten Views, und sie nutzen die bereits erstellten Leseergebnisse. Mandantenfähigkeit Das Partitioning kann auch Grundlage für ein MandantenVerfahren sein, bei dem Tabellen nur einmal zu pflegen sind, einzelne Partitionen aber nur für die dafür autorisierten Personengruppen offen stehen. Über Label-Security ist ein Zeilen-orientiertes (bzw. Partition-bezogenes) Schützen von Tabellendaten möglich. Optimierte Starschema-Zugriffe Star-Schemen stellen typische Auswerte-Datenmodelle in Warehouse-Systemen dar. Um Abfragen auf ein Star-Schema noch schneller durchzuführen, kann man die Option der StarTransformation nutzen. Hier spaltet der Datenbank-Optimizer eine Abfrage optimal in Teilabfragen auf, die das System unter Verwendung von Bitmap-Indizes separat abarbeitet. Das Verfahren arbeitet eng mit der Bitmap-Indizierung zusammen. Bitmaps besonders Strukturen gut für denormalisierte Bei sehr stark denomalisierten Daten, wie diese das Data Warehouse z. B. in Star-Schemen nutzt, Ausschnitt aus einem Starsche ma mit I ndizier ung werden in bestimmten Tabellenspalten Informationen häufig redundant abgelegt. Um hierauf schnelle Zugriffe bei großen Datenmengen zu gewährleisten, hat Oracle eine spezielle Indizierungsart den Bitmap-Index entwickelt. Eine Bit-Codierung dokumentiert das Vorkommen bestimmter Werte in den Spalten. Die Bitmap-Indizierung gehört zu den effizientesten Verfahren bei der Zugriffsbeschleunigung im Starschema Sich selbst aktualisierende Kennzahlensysteme Ein sehr hoher Anteil von Benutzerabfragen in einem Data Warehouse ist vorhersehbar. Die Oracle Datenbank kann immer wiederkehrende Abfragen feststellen und sie für den Administrator dokumentieren. Dieser kann solche Abfragen über sog. Materialized Views vorbereiten und Abfrageergebnisse speichern. Wenn Benutzer zum wiederholten Mal solche Abfragen starten, bedient sich das System der gespeicherten Ergebnisse, ohne dass der Benutzer hierfür an seiner Abfrage etwas verändern muss. Die Benutzer erhalten Ergebnisse in einer wesentlich kürzeren Zeit. Über dieses Datenbank-Feature lassen sich intelligent strukturierte Kennzahlensysteme aufbauen. Man erstellt in einem Aufe inander aufbauende Mate rialized Views Materialized Views aktualisieren sich selbst ohne dass administrativ eingegriffen werden muss. Das Aktualisieren erfolgt auch (wenn sinnvoll) über das gezielte Nachladen von Änderungen in den zugrundeliegenden Basistabellen. Das beschleunigt die Verarbeitung. Materialized Views sparen ETL-Aufwand Mit dem Einsatz von Materialized Views spart man ETL-Aufwand. Die Aggregations-/Leseleistung müsste alternativ über ein ETLTool bzw. mit Programmiermitteln erbracht werden. Definiert man Materialized Views in Oracle Warehouse Builder, so erhält man auch eine graphische Dokumentation, z. B. welche Basistabellen werden von einer Materialized View gelesen. Data Warehouse Technik im Fokus - Teil 1 - Architektur und Konzepte Modell-basiertes ETL Eine der größten Herausforderungen bei dem Aufbau von Data Warehouse Systemen ist die Wahrung der Übersicht über die Menge der Objekte und verworrenen Datenflüsse. Dem begegnet das graphisch gestützte Modellieren der Datenstrukturen und der Datentransformationen. Die Oracle Datenbank verfügt mit Oracle Warehouse Builder (OWB- InDatabase-ETL) über ein graphisch arbeitendes ETL-Tool (Extraktion, Transition and Load) in dem alle Data Warehouse-Strukturen beschrieben sind. Die Datenflüsse von Quell- zu Ziel-Objekten sind dokumentiert und graphisch visualisiert. Über Metadaten-Auswertungen lassen sich auch extrem komplexe Datenflüsse bis auf die Feldebene aufzeigen. 25 Die Daten müssen, um transformiert zu werden, nicht die Datenbank verlassen. Die Ladelogik wird über mengenbasiertes SQL abgebildet. OWB-Transformationen bzw. - ETL stellen die schnellste Art dar, mit der ein Data Warehouse gefüllt und aktualisiert werden kann. Neutrales und Management übergreifendes Metadaten- Oracle Warehouse Builder deckt neben der ETL-Funktionalität auch die Rolle des Metadaten-Managements ab. Mit dem frei konfigurierbaren Repository lassen sich auch fachliche Metadaten beschreiben. Alle Metadaten liegen in offen zugänglichen Datenbank-Tabellen, so dass sie beliebig für andere Tools zur Verfügung stehen. Über eine Webanwendung kann man das Repository auswerten. Die entscheidenden AuswerteInformationen sind dabei die Beziehungen zwischen den Objekten. Diese können entweder als eingerückte Listen oder als graphische Flussdiagramme angezeigt werden. Graphische s Mapping zur Tr ansform ation v on Date n (ETL ) Extrem hohe Performance mit InDatabase ETL Einer der großen Vorteile von Oracle Warehouse Builder (InDatabase ETL) ist das Erzeugen von 100% Oracle-Datenbank Code (SQL bzw. PL/SQL). Oracle 10, 11.1, 11.2 und künftig auch 12 Datenbank-Syntax wird ohne manuelles Zutun direkt in die Datenbank gestellt. Metadate n-Auflistung v on O bj ekte n Wichtige Auswertungen auf der Metadaten sind Herkunfts- und Auswirkungs-Analyse (Lineage und Impact). Diese Analysen sind interaktiv und graphisch machbar. Graphische und int er aktive Auswirkungs- und Her kunfts analy se über Metadate n in einem Data Ware house -Sys tem Data Warehouse Technik im Fokus - Teil 1 - Architektur und Konzepte Würfel oder Star Flexibel formulierte Adhoc-Abfragen bieten einen hohen Komfort für Benutzer gerade dann, wenn es noch keine genaue Formulierung für eine Abfrage gibt. Die Oracle OLAP-Option berechnet Daten für alle potentiellen Abfrageergebnisse eines dimensionalen Datenraums vor. Diese vorberechneten Ergebnisse kann der Benutzer ohne Zeitverzug „abholen“. Es ermöglicht das leichte Navigieren auch in großen Datenmengen mit ständig wechselnden Abfragen. Die Abfragesprache bleibt SQL und die Wahl zwischen Abfragen auf klassische relationale Tabellen (wie in einem Starschema) oder auf einen OLAP-Würfel ist automatisiert und transparent. Bei zeitbezogenen Abfragen, Periodenvergleichen, „Year-toDate“-Abfragen usw. zeigen OLAP-Würfel Vorteile, da sie die typische Struktur eines Kalenders mit z. B. einer wechselnden Anzahl von Tagen pro Zeiteinheit, gesondert vermerkt haben. Relationales und m ultidimens ionales OLAP in e iner Date nbank Schlanke Architekturen mit OLAP-Würfeln 26 sich mit einfachen Mitteln passgenaue Testdaten bereitstellen. Z. B. kann man verschiedene Wertebereiche innerhalb einer Tabellenspalte gewichten, man kann Teildatensegmente aus operativen Tabellen extrahieren und sie als Grundbestand für Testdaten verwenden. Bereichsübergreifendes Metadaten Management Das Oracle Information Catalogue Framework ist ein erweiterbares Metadaten-Repository mit einer Web-basierten Oberfläche. Dokumentiert werden können alle relevanten Fragestellungen, die auch Fachanwender interessieren. Mit vorbereiten Strukturen des Oracle Data Warehouse -FrameWorks schnell implementiert Die besten Data Warehouse Systeme sind nach wie vor Eigenentwicklungen, weil nur spezifische Anpassungen die individuellen Anforderungen im Unternehmen berücksichtigen. Das bedeutet jedoch nicht, dass jedes technische Verfahren neu zu entwickeln ist. Die Data Warehouse Logistic Utilities sind ein Framework, in dem die wichtigsten technischen Verfahren und Konzepte eines modernen Data Warehouse Systems bereits vorgedacht und vorimplementiert sind. Die Utilities bestehen aus: Einer sehr einfachen aber flexiblen MetadatenVerwaltung für beliebige Datenund Informationsobjekte. Ein bereits in dem Repository implementiertes Data Warehouse Information Model Einer ETL-Tool-unabhängigen Laufzeitumgebung zur automatischen Dokumentation von Ladeläufen. Einer Job-Managementumgebung zum Verwalten von eingehenden Datenbeständen und Ladejobs. Einer Data Quality-Prüfumgebung zum regelgestützten Monitoring von Datenqualitätsanforderungen. Ausführliche Dokumentation zur Anwendung der Utilities OLAP-Würfel flexibilisieren die Data Mart Schicht einer unternehmensweiten Data Warehouse Architektur. Mit der OLAP Option ersetzt man eine separate, losgelöste OLAP-Infrastruktur in Fachabteilungen und verhindert unkontrollierten Wildwuchs. Permanentes Kopieren zwischen redundanten SatellitenDatenbeständen entfällt, die Gesamtarchitektur wird schlanker. Praxistaugliche Testdaten Die Neu- oder auch Weiterentwicklung von Warehouse-Systemen erfolgt meist unter Laborbedingungen. Das bedeutet, dass Routinen für Transformationen und Datenprüfungen ohne das Vorhandensein von Echtdaten entwickelt werden müssen. Reichen zunächst wenige manuell erstelle Testsätze um eine Grundfunktionalität zu entwickeln, muss man in einem anspruchsvolleren Testszenario Grenzsituationen und Ausnahmekonstellationen mit einem hohen Datenvolumen ermitteln. Über ein Oracle Data Warehouse Framework lassen Data War ehouse Me tam ode l Data Warehouse Technik im Fokus - Teil 1 - Architektur und Konzepte Inhalt Die Themen ............................................................................................................................................................................................... 1 Vier wichtige Aspekte machen das Data Warehouse so erfolgreich ......................................................................................................... 2 Der Aspekt des „Unternehmensweiten“ ................................................................................................................................................... 2 Rolle und Eigenschaften haben sich permanten verändert ....................................................................................................................... 3 Operationalsierung der Data Warehouse-Rolle......................................................................................................................................... 3 Warehouse-Organisation in drei Daten-Schichten .................................................................................................................................... 3 3-Schichten-Modell historisch ................................................................................................................................................................... 4 Die Mehrwert-Leistungen des Data Warehouse ........................................................................................................................................ 4 Die Data Mart Schicht ................................................................................................................................................................................ 5 Data Marts sind redundant und „flüchtig“ ............................................................................................................................................ 5 Historisierung ........................................................................................................................................................................................ 5 Empfehlung Star Schema verwenden .................................................................................................................................................... 6 Umgang mit großen Faktentabellen ...................................................................................................................................................... 6 Herleitung der multidimensionalen Modell eines Data Marts .............................................................................................................. 6 Strukturierung und Beziehungen der Objekte ....................................................................................................................................... 6 Das Star-Schema .................................................................................................................................................................................... 7 Varianten des Star Schemas .................................................................................................................................................................. 7 Empfehlungen für den Aufbau von Faktentabellen ............................................................................................................................... 8 Star vs. Snowflake Schema .................................................................................................................................................................... 8 Höhere Granularität bei Fakten-Tabellen wählen ................................................................................................................................. 8 Informationsmenge und Abfrageoptionen ............................................................................................................................................ 8 Auslagern von weniger häufig genutzt Attributen ................................................................................................................................. 8 Allgemeine Regeln für das Star Schema ................................................................................................................................................ 9 Die Schlüssel / Indizierung im Star Schema ........................................................................................................................................... 9 Quellsysteme ........................................................................................................................................................................................... 11 Umgang mit dem Aspekt des Operativen der Vorsysteme .................................................................................................................. 11 Umgang mit Datenqualitätsproblemen ............................................................................................................................................... 11 Stage - Schicht ......................................................................................................................................................................................... 11 Archivierung gelesener Sätze .............................................................................................................................................................. 11 Generische Stage-Strukturen ............................................................................................................................................................... 11 Operational Data Store (ODS) .................................................................................................................................................................. 12 Die (Kern-) Data Warehouse - Schicht ..................................................................................................................................................... 12 Management von Daten und Informationen in der Data Warehouse Schicht - gegen Datenchaos .................................................... 12 Metadaten Repository zur Dokumentation der Inhalte und Zusammenhänge ................................................................................... 13 Data Warehouse Information Model................................................................................................................................................... 13 Begriffsdefinitionen und Glossars ........................................................................................................................................................ 13 Deskriptoren-Verfahren....................................................................................................................................................................... 14 Alte Daten neue Daten ........................................................................................................................................................................ 14 ETL - Extraktion, Transformation, Load ................................................................................................................................................... 15 ETL vs. ELT ........................................................................................................................................................................................... 15 Die Aufgabenstellung des ETL .............................................................................................................................................................. 15 Datennahe Transformationen für Daten-orientiertes Data Warehouse ............................................................................................. 16 Das 3-Schichten-Modell und der ETL-Prozess...................................................................................................................................... 16 Generieren statt Programmieren- Mit Graphik modellieren ............................................................................................................... 16 27 Data Warehouse Technik im Fokus - Teil 1 - Architektur und Konzepte Wiederholbarkeit des Ladelaufs .......................................................................................................................................................... 17 Deltadatenerkennung .......................................................................................................................................................................... 17 Datenbank-interne Lade-Läufe schnell machen .................................................................................................................................. 17 Die Vorteile des SQL der Datenbank bei den Ladeaktivitäten ............................................................................................................. 18 Checkliste zur Planung und dem Neuaufbau von Data Warehouse-Systemen ....................................................................................... 19 Hardware wichtiger Bestandteil im Data Warehouse ............................................................................................................................. 20 „Private“ Hardware - ungeschriebene Regel ........................................................................................................................................... 20 Speicherhierarchien ................................................................................................................................................................................. 20 In Memory Parallel Execution .................................................................................................................................................................. 20 Hardware-Aspekte ................................................................................................................................................................................... 21 Storage und Plattensysteme ................................................................................................................................................................ 21 Architektonische Vorteile RAC und ETL ............................................................................................................................................... 21 Allgemeine Aufbauempfehlungen RAC Aus ETL-Sicht ......................................................................................................................... 22 Kompression: Verwaltung und Kosten reduzieren .............................................................................................................................. 22 Wieviele Platten-Controller? ............................................................................................................................................................... 22 Database Machine (Exadata) ................................................................................................................................................................... 22 Kleine Vorschau auf einzelne Oracle Datenbank-Technologien .............................................................................................................. 23 Immer die passende Datenmodell-Form ............................................................................................................................................. 23 Mit Partitioning große Datenmengen leicht verwalten ...................................................................................................................... 23 Aufbau eines Daten Life Cycle Mangements ....................................................................................................................................... 24 Mandantenfähigkeit ............................................................................................................................................................................ 24 Optimierte Starschema-Zugriffe .......................................................................................................................................................... 24 Bitmaps besonders gut für denormalisierte Strukturen ...................................................................................................................... 24 Sich selbst aktualisierende Kennzahlensysteme .................................................................................................................................. 24 Materialized Views sparen ETL-Aufwand ............................................................................................................................................ 24 Modell-basiertes ETL ........................................................................................................................................................................... 25 Extrem hohe Performance mit InDatabase ETL ................................................................................................................................... 25 Neutrales und übergreifendes Metadaten-Management ................................................................................................................... 25 Würfel oder Star .................................................................................................................................................................................. 26 Schlanke Architekturen mit OLAP-Würfeln ......................................................................................................................................... 26 Praxistaugliche Testdaten .................................................................................................................................................................... 26 Bereichsübergreifendes Metadaten Management.............................................................................................................................. 26 Mit vorbereiten Strukturen des Oracle Data Warehouse -FrameWorks schnell implementiert ......................................................... 26 28