Aufgabenstellung mit Lösung

Transkript

1 Hochschule Darmstadt Data Warehouse SS2009 Fachbereich Informatik Praktikumsversuch 5 Prof. Dr. S. Karczewski Dipl. Inf. Dipl. Math. Y. Orkunoglu Thorsten Peter Datum: Aufgabenstellung mit Lösung 1. Aufgabenbeschreibung In diesem Praktikum sollen die Studierenden mit dem ETL-Tool Data Manager (DecisionStream) umgehen. Dabei werden Daten aus verschiedenen operativen Datenquellen ( OLTP ) geladen und ein für die Analyse ( OLAP ) passendes Transformationsmodell ( Star-Schema-Transformation ) erstellt. Schließlich werden, auf Basis dieses Transformationsmodells, die Data Marts erzeugt und in eine Zieldatenbank ( Data Warehouse ) geladen. Das Praktikum besteht aus 3 Teilen: I. Erstellung eines einzigen Data Marts, bei dem sowohl die Erzeugung der Faktentabelle als auch die Erzeugung der Dimensionstabellen mithilfe eines einzigen sogenannten Fact Builds erfolgt. Um dies zu realisieren, werden Sie folgende Schritte wählen: 1. Katalog erstellen. Der Katalog ist das zentrale Repository für die Data- Manager-Metadaten. 2. Verbindungen zu den operativen Datenquellen definieren. 3. Analyse der Quelldaten. Auf Basis der Quelldaten erstellen Sie das konzeptionelle Star-Schema für die Analyse. Dieses Star-Schema bildet die Grundlage für die nun folgende Realisierung im Data Manager. 4. Dimensionen modellieren. Mithilfe des Hierarchy Wizards und dem von Ihnen erstellten Star-Schema sollen Sie die Dimensionen im Data Manager anlegen. 5. Star Schema Fact Build anlegen und ausführen. Sie werden mit dem Fact Build Wizard einen Star Schema Fact Build erzeugen, der sowohl die Erzeugung der Faktentabelle als auch die Erzeugung der Dimensionstabellen beinhaltet und die transformierten Daten in die Zieldatenbank schreibt. II. Erstellung zweier Conformed Data Marts, bei denen die Erzeugung der konformen Dimensionstabellen mithilfe sogenannter Dimension Builds erfolgt. Die Erzeugung der beiden Faktentabellen eine Faktentabelle pro Data Mart erfolgt mithilfe von zwei Fact Builds, wobei jeweils die bereits erzeugten konformen Dimensionstabellen verwendet und nicht erneut erstellt werden. Sie modellieren also im Sinne der Data-Warehouse-Theorie eine Galaxie. In Teil I werden die Faktentabelle und die drei Dimensionstabellen des Data Marts im Rahmen eines einzigen Fact Builds in die Zieldatenbank geschrieben. In diesem Teil soll ein weiterer Data Mart (eine weitere Faktentabelle) hinzukommen, der optimalerweise die selben Dimensionstabellen ( Conformed Dimensions / Seite 1 von 16

2 Data Marts) wie der erste Data Mart verwendet. Um dies zu realisieren, werden Sie in diesem Teil des Praktikums folgende Schritte wählen: 1. Ergänzen des konzeptionellen Star-Schemas aus Teil I um den zweiten Data Mart ( Galaxie) 2. Erzeugen der konformen Dimensionstabellen mit Dimension Builds 3. Erstellen von Data Integrity Lookups 4. Erzeugen der Faktentabellen mit Fact Builds. Die in Schritt 2. erstellten Data Integrity Lookups werden dabei verwendet, um sicherzustellen, dass nur solche Datensätze in die Faktentabelle aufgenommen werden, die gültige Datensätze in den Dimensionstabellen referenzieren. So soll z.b. der Lagerbestand eines Produkts nur dann in die Stock-Faktentabelle aufgenommen werden, wenn das Produkt auch in der Product-Dimensionstabelle existiert ( Integrität). die Verbindung zwischen Fakten- und Dimensionstabellen über die im vorherigen Schritt 1. angelegten künstlichen Schlüssel herzustellen. Das Lookup bildet hierbei die in den Quelldaten eingesetzten operativen Schlüssel auf die im Data Warehouse eingesetzten künstlichen Schlüssel ab. III. Beantwortung von Fragen 2. Lernziele ETL-Prozess kennen lernen Aufbau eines integrierten Data Warehouse bestehend aus mehreren unabhängigen Data Marts mit konformen Dimensionen Vor- und Nachteile des Aufbaus eines Data Warehouse auf Basis von unabhängigen Data Marts mit konformen Dimensionen kennen 3. Voraussetzungen Folgende Kenntnisse sollten Sie mitbringen, um diese Praktikumsaufgabe bearbeiten zu können: Verständnis über die Zusammenhänge zwischen Data Warehouse, Data Mart und Conformed Dimension Star-Schema Snowflake-Schema 4. Abnahme Die Abnahme findet am Ende der Praktikumssitzung statt. Seite 2 von 16

3 Software starten Anleitung Rechner starten DATENBANKEN auswählen Data Manager starten (auf dem Desktop Data Manager klicken) Teil I In diesem Teil des Praktikums werden Sie einen Data Mart erstellen, bei dem sowohl die Erzeugung der Faktentabelle als auch die Erzeugung der Dimensionstabellen mithilfe eines einzigen sogenannten Fact Builds erfolgt. Hier ein kurzer Überblick über das, was Sie im Folgenden tun werden (hier noch nichts tun, detaillierte Anweisungen folgen): 1. Katalog erstellen. Der Katalog ist das zentrale Repository für die Data- Manager-Metadaten. 2. Verbindungen zu den operativen Datenquellen definieren. 3. Analyse der Quelldaten. Auf Basis der Quelldaten erstellen Sie das konzeptionelle Star-Schema für die Analyse. Dieses Star-Schema bildet die Grundlage für die nun folgende Realisierung im Data Manager. 4. Dimensionen modellieren. Mithilfe des Hierarchy Wizards und dem von Ihnen erstellten Star-Schema sollen Sie die Dimensionen im Data Manager anlegen. 5. Star Schema Fact Build anlegen und ausführen. Sie werden mit dem Fact Build Wizard einen Star Schema Fact Build erzeugen, der sowohl die Erzeugung der Faktentabelle als auch die Erzeugung der Dimensionstabellen beinhaltet und die transformierten Daten in die Zieldatenbank schreibt. 1. Katalog erstellen 1.1 Eine leere Datenquelle einrichten, die den Katalog aufnimmt Menüpunkt Tools ODBC Administrator... Tab System-DSN Hinzufügen Microsoft Access Driver (*.mdb, *.accdb) auswählen Als Datenquellenname MyCatalog angeben Datenbank Erstellen auswählen. Als Name MyCatalogDatabase.mdb angeben. Die Katalog-Datenbank soll auf dem Laufwerk D: abgespeichert werden (das logische Laufwerk C ist geschützt. d.h. wenn der Rechner neu gestartet werden muss/wird, werden alle angelegten Dateien auf der C- Partition gelöscht). 1.2 Mit der MyCatalog Datenquelle verbinden und den Katalog erzeugen Menüpunkt File New Catalog... Als Name MyCatalog angeben Next ODBC auswählen und MyCatalog als Datenquelle angeben. Test Connection klicken Finish Es steht jetzt ein leerer Katalog zur Verfügung, der sämtliche im Folgenden anfallenden (Meta-) Daten aufnimmt. Seite 3 von 16

4 2. Verbindungen zu den operativen Datenquellen definieren Nun können die Verbindungen zu den Datenquellen definiert werden. Diese werden in dem neu angelegten Katalog gespeichert. 2.1 Verbindung mit der Stock Datenquelle herstellen Rechtsklick auf Connections im linken TreeView Insert Connection Als Alias Stock angeben Tab Connection Details ODBC DS Stock als Datenquellenname angeben Test Connection klicken OK 2.2 Stellen Sie analog zum vorherigen Schritt auch eine Verbindung zu der Datenquelle DS Reference her. Als Connection-Alias wählen Sie diesmal Reference. 2.3 Nachdem nun die Verbindungen zu den operativen Quelldatenbanken hergestellt sind, wird noch eine Verbindung zu der Zieldatenbank ( Data Warehouse ) benötigt. Hierfür richten Sie analog Schritt 1.1 eine leere Datenquelle ein, die die Zieldatenbank aufnimmt: Menüpunkt Tools ODBC Administrator... Tab System-DSN Hinzufügen Microsoft Access Driver auswählen Als Datenquellenname DS Output angeben Datenbank Erstellen auswählen. Als Name dsout angeben. Die Zieldatenbank soll ebenfalls auf dem Laufwerk D: abgespeichert werden. Danach stellen Sie, analog Schritt 2.1, eine Verbindung zu der soeben erzeugten Datenquelle her. Als Connection-Alias wählen Sie Output. Die Verbindungen zu den operativen Quelldatenbanken sowie zur noch leeren Zieldatenbank sind nun eingerichtet. 3. Analyse der Quelldaten Um das multidimensionale Datenmodell erstellen zu können, müssen Sie sich zunächst damit vertraut machen, welche Daten in den operativen Quelldatenbanken gespeichert sind. Nutzen Sie SQLTerm, um die Quelldatenbanken (Stock, Reference) zu analysieren: Menüpunkt Tools SQLTerm Wählen Sie die zu betrachtende Datenbank aus und lassen Sie sich im linken TreeView die verfügbaren Tabellen in dieser Datenbank durch einen Klick auf das (+)-Symbol vor der Datenbank anzeigen. Nach einem Rechtsklick auf die gewünschte Tabelle können Sie sich mittels Select rows eine Query über alle Spalten der Tabelle generieren lassen. Selbstverständlich können Sie diese Query auch manuell erstellen/nachbearbeiten. Ein Klick auf die Play-Taste innerhalb des Test-Feldes führt die Query auf der Datenbank aus und zeigt das Ergebnis an. Seite 4 von 16

5 Überlegen Sie sich, wie Sie die operativen Quelldaten in einem Star-Schema für die Analyse abbilden können. Beantworten Sie hierfür kurz die unten stehenden Fragen und zeichnen Sie anschließend das Star-Schema (ohne die Attribute im Einzelnen aufzuführen) und ein Klassifikationsschema für jede Dimension. Alternativ können Sie auch das Multidimensionale E/R Modell zeichnen. Was kann mithilfe der vorhandenen Daten analysiert werden? - Lagerbestandsanalyse nach Produkt (Product), Ort (Location) und Zeit (Fiscal) Name der Faktentabelle? - Stock Name der Dimensionen? - Product, Location, Fiscal Aus welcher Quelldatenbanktabelle gewinnt die Faktentabelle ihre Daten? - siehe Modell (unten) Aus welcher/welchen Quelldatenbanktabelle/ Quelldatenbanktabellen gewinnt welche Dimension ihre Daten? - siehe Modell (unten) Welche Hierarchieebenen enthält welche Dimension ( Klassifikationsschema)? - siehe Modell (unten) BREAKPOINT Seite 5 von 16

6 Gewinnt Daten aus Tabelle(n): - ds_location in Datenquelle DS Reference - ds_timezone in Datenquelle DS Reference Product (D3) Stock Gewinnt Daten aus Tabelle(n): - ds_product in Datenquelle DS Reference Location (D1) Gewinnt Daten aus Tabelle(n): - ds_stock in Datenquelle DS Stock Fiscal (D2) Gewinnt Daten aus Tabelle(n): - ds_fiscal in Datenquelle DS Reference Dimension: Location (D1) Dimension: Fiscal (D2) Dimension: Product (D3) Top Top Top Timezone (D1-E1) Year (D2-E1) Product Type (D3-E1) State (D1-E2) Quarter (D2-E2) Product (D3-E2) Month (D2-E3) Seite 6 von 16

7 4. Dimensionen modellieren Nachdem Sie sich über die Struktur der Quelldaten im Klaren sind, sollen Sie die Dimensionen im Data Manager mithilfe des Hierarchy Wizards modellieren. 4.1 Modellierung der Location Dimension Menüpunkt Tools Hierarchy Wizard Wählen Sie Create the hierarchy from multiple tables (Snowflake Schema) Als Name der Hierarchie wählen Sie Location Klicken Sie auf Add, um eine neue Reference Dimension hinzuzufügen, die die Location-Hierarchie enthält Als Name der Reference Dimension wählen Sie Location OK Next Next Fügen Sie die Timezone-Ebene unterhalb der ALLLocation-Ebene ein Klicken Sie auf ALLLocation und wählen Sie Add Als Name Timezone eingeben Als Source Database Reference wählen Klicken Sie auf den Browse for table button neben Source Table und wählen Sie ds_timezone Fügen Sie timezone_cd und timezone_name aus der Available attributes Liste zur Chosen attributes Liste hinzu Klicken Sie in der Chosen attributes Liste auf die Id Box für timezone_cd und auf die Caption Box für timezone_name Klicken Sie auf OK, um die Ebene zu erzeugen Fügen Sie die State-Ebene unterhalb der Timezone-Ebene ein Klicken Sie auf Timezone und wählen Sie Add Als Name State eingeben Als Source Database Reference wählen Klicken Sie auf den Browse for table button neben Source Table und wählen Sie ds_location Fügen Sie state_cd, state_name und timezone_cd aus der Available attributes Liste zur Chosen attributes Liste hinzu Klicken Sie in der Chosen attributes Liste auf die Id Box für state_cd, auf die Caption Box für state_name und auf die Parent Box für timezone_cd Klicken Sie auf OK, um die Ebene zu erzeugen Next Finish Im linken TreeView des Hauptfensters sehen Sie nun unter Library Dimensions die Location-Dimension. 4.2 Modellierung der Fiscal Dimension Menüpunkt Tools Hierarchy Wizard Wählen Sie Create the hierarchy from the columns of one table (Star Schema) Als Name der Hierarchie wählen Sie Fiscal Klicken Sie auf Add, um eine neue Reference Dimension hinzuzufügen, die die Fiscal-Hierarchie enthält Seite 7 von 16

8 Als Name der Reference Dimension wählen Sie Fiscal OK Next Als Source Table für die Hierarchie wählen Sie die ds_fiscal Tabelle in der Reference Datenbank Next Deselektieren Sie Include a top level with an All member Next Erzeugen Sie die Year-Ebene für die Hierarchie Klicken Sie auf Fiscal und wählen Sie Add Als Name Year eingeben Als Source column for Id fiscal_yr wählen Als Source column for caption fiscal_yr_desc wählen Klicken Sie auf OK, um die Ebene zu erzeugen Fügen Sie die Quarter-Ebene unterhalb der Year-Ebene ein Klicken Sie auf Year und wählen Sie Add Als Name Quarter eingeben Als Source column for Id fiscal_qtr wählen Als Source column for caption fiscal_qtr _desc wählen Klicken Sie auf OK, um die Ebene zu erzeugen Fügen Sie die Month-Ebene unterhalb der Quarter-Ebene ein Klicken Sie auf Quarter und wählen Sie Add Als Name Month eingeben Als Source column for Id period_no wählen Als Source column for caption period_no _desc wählen Klicken Sie auf OK, um die Ebene zu erzeugen Next Next Finish Im linken TreeView des Hauptfensters sehen Sie nun unter Library Dimensions die Fiscal-Dimension. 4.3 Modellierung der Product Dimension Menüpunkt Tools Hierarchy Wizard WICHTIG: Wählen Sie Create the hierarchy from the rows of one table Als Name der Hierarchie wählen Sie Product Klicken Sie auf Add, um eine neue Reference Dimension hinzuzufügen, die die Product-Hierarchie enthält Als Name der Reference Dimension wählen Sie Product OK Next Als Source Table für die Hierarchie wählen Sie die ds_product Tabelle in der Reference Datenbank Next Unter Select the column for the Id product_cd wählen Unter Select the column for the Caption product_name wählen Unter Select the column for the Parent parent_product_cd wählen Unter Select the column for the level name product_type wählen Next Next Next Next Finish Im linken TreeView des Hauptfensters sehen Sie nun unter Library Dimensions die Product-Dimension. Seite 8 von 16

9 4.4 Analysieren der modellierten Hierarchien im Reference Explorer Klicken Sie unter Library Dimensions auf das (+)-Symbol neben der gewünschten Dimension Rechtsklicken Sie auf die jeweilige Hierarchie und wählen Sie Explore OK Untersuchen Sie die Attribute der Hierarchie indem Sie verschiedene Ebenen expandieren 5. Star Schema Fact Build anlegen und ausführen Bis hierhin haben Sie, auf Basis der operativen Quelldaten, die Dimensionen modelliert. Im letzten Arbeitsschritt des ersten Praktikumsteils sollen Sie, auf Basis der modellierten Dimensionen einen Star Schema Data Mart erzeugen, welcher seine Daten aus den operativen Quelldaten gewinnt. Das Ergebnis wird eine Faktentabelle und drei Dimensionstabellen sein. 5.1 Aufrufen des Fact Build Wizards Menüpunkt Tools Fact Build Wizard Unter Enter the name of the build Stock1 eingeben Unter Select the connection into which the build is to deliver data Output auswählen Aktivieren Sie die Perform a full Refresh on the Target Data Checkbox Next 5.2 Einrichten der Datenquelle von der die Fakt-Daten gelesen werden sollen Klicken Sie auf den Data Source Button Add Als data source name Stock angeben Unter Select the connection from which the data source is to read Stock auswählen Next Setzen Sie im linken Teilfenster einen Haken vor ds_stock. Im rechten Teilfenster erscheint ein SELECT-Statement, das die Spalten anzeigt, die in den Fact Build einbezogen werden. Klicken Sie auf Finish Next Next 5.3 Beziehungen herstellen zwischen den Attributen der Faktentabelle und den unter 4. modellierten Dimensionshierarchien Neben period_nr die Fiscal-Hierarchie auswählen (Doppelklick auf die Fiscal- Dimension, dann Klick auf die Fiscal-Hierarchie) Neben state_cd die Location-Hierarchie auswählen Neben product_cd die Product-Hierarchie auswählen Akzeptieren Sie von hier an alle Default-Einstellungen mit Next und klicken Sie am Ende auf Finish Im linken TreeView des Hauptfensters sehen Sie nun unter Builds and JobStreams den Stock1 Fact Build. Ein Klick auf Stock1 zeigt das zugehörige grafisch aufbereitete Modell. 5.4 Fact Build ausführen Klicken Sie im linken TreeView des Hauptfensters unter Builds and JobStreams auf den Stock1 Fact Build Führen Sie den Fact Build aus: Menüpunkt Actions Execute OK Seite 9 von 16

10 Schließen Sie das DOS-Fenster durch drücken der Enter-Taste Schauen Sie sich das Log File für diesen Build an: Menüpunkt Tools Browse Log Files Öffnen Sie die Datei Build_Stock1_0001.log Das Log File zeigt, dass sowohl die F_Stock1 Faktentabelle als auch die drei Dimensionstabellen mit Daten gefüllt worden sind. Verifizieren Sie dies, indem Sie die Access-Zieldatenbank dsout.mdb auf Laufwerk D öffnen und analysieren. Schließen Sie diese danach wieder! BREAKPOINT Teil II In Teil I haben Sie einen Star Schema Data Mart zur Analyse des Lagerbestandes erzeugt. Hierbei wurden die Faktentabelle und die drei Dimensionstabellen des Data Marts im Rahmen eines einzigen Fact Builds in die Zieldatenbank geschrieben. Soll nun neben der Lagerbestandsanalyse auch noch eine Verkaufsanalyse (Verkaufszahlen, Umsätze etc.) möglich werden (die Auswertedimensionen sollen die gleichen sein), so wird ein zweiter Data Mart benötigt, dessen Faktentabelle die Verkaufsdaten beinhaltet. Optimalerweise werden dabei die selben Dimensionstabellen verwendet ( Conformed Dimensions). Um dies zu realisieren werden Sie in diesem Teil des Praktikums folgende Schritte wählen (hier noch nichts tun, detaillierte Anweisungen folgen): 1. Ergänzen des konzeptionellen Star-Schemas aus Teil I um den zweiten Data Mart ( Galaxie) 2. Erzeugen der konformen Dimensionstabellen mit Dimension Builds 3. Erstellen von Data Integrity Lookups 4. Erzeugen der Faktentabellen mit Fact Builds. Die in Schritt 2. erstellten Data Integrity Lookups werden dabei verwendet, um sicherzustellen, dass nur solche Datensätze in die Faktentabelle aufgenommen werden, die gültige Datensätze in den Dimensionstabellen referenzieren. So soll z.b. der Lagerbestand eines Produkts nur dann in die Stock-Faktentabelle aufgenommen werden, wenn das Produkt auch in der Product-Dimensionstabelle existiert ( Integrität). die Verbindung zwischen Fakten- und Dimensionstabellen über die im vorherigen Schritt 1. angelegten künstlichen Schlüssel herzustellen. Das Lookup bildet hierbei die in den Quelldaten eingesetzten operativen Schlüssel auf die im Data Warehouse eingesetzten künstlichen Schlüssel ab. Frage: Wieso kann der in Teil I angelegte Fact Build hier nicht wieder verwendet werden? - Der in Teil I angelegte Fact Build kann hier nicht eingesetzt werden, da das Erzeugen der Dimensionstabellen untrennbar mit der Erzeugung der Stock1- Faktentabelle verbunden ist. Jedes Ausführen des Fact Builds würde die Dimensionsdaten überschreiben und somit das Entwickeln konformer Dimensionen verhindern. Seite 10 von 16

11 1. Ergänzen des konzeptionellen Star-Schemas aus Teil I um den zweiten Data Mart Um neben der Lagerbestandsanalyse noch eine Verkaufsanalyse möglich zu machen, wird eine weitere Datenquelle benötigt, die die Verkaufsdaten beinhaltet. 1.1 Verbindung mit der Sales Datenquelle herstellen Stellen Sie eine Verbindung zu der Datenquelle DS Sales her. Als Connection- Alias wählen Sie Sales. 1.2 Ergänzen des Star-Schemas um dem zweiten Data Mart Nutzen Sie SQLTerm, um sich mit dem Inhalt der Sales-Quelldatenbank vertraut zu machen. Zeichnen Sie in das von Ihnen in Teil I erstellte Star Schema den zweiten Data Mart ein (auch hier ohne die Attribute im Einzelnen aufzuführen). Die Faktentabelle nennen Sie Sales. Achten Sie auf die Beziehungen zwischen Fakten und Dimensionen! Fiscal Stock Product Sales Location 2. Erzeugen der konformen Dimensionstabellen mit Dimension Builds Auf Basis der in Schritt 2 modellierten Galaxie, sollen Sie im Folgenden Dimension Builds anlegen, die zur Erstellung der konformen Dimensionstabellen verwendet werden. Seite 11 von 16

12 2.1 Erzeugen der Conformed Dimension Builds Menüpunkt Tools Dimension Build Wizard Als Name D_ProductH eingeben Next Unter Dimension to be delivered wählen Sie Product. Da die Product- Hierarchie die einzige Hierarchie in dieser Dimension ist, wird sie automatisch in der Reference item to be delivered Box ausgewählt. Unter Deliver into Connection wählen Sie Output Next Next Next Next Aktivieren Sie die Add Surrogate Keys to the Dimension Tables Checkbox Next Finish Im linken TreeView des Hauptfensters sehen Sie nun unter Builds and JobStreams den D_ProductH Dimension Build. Wiederholen Sie diese Schritte, um zwei weitere Dimension Builds mit den Namen D_FiscalH und D_LocationH zu erzeugen. Dabei basiert der D_FiscalH Build auf der Fiscal-Dimension und der D_LocationH Build auf der Location-Dimension. 2.2 Ausführen der Conformed Dimension Builds Führen Sie die D_ProductH, D_FiscalH und D_LocationH Dimension Builds aus, indem Sie diese im linken TreeView des Hauptfensters auswählen und über Menüpunkt Actions Execute OK ausführen. Schließen Sie die jeweiligen DOS-Fenster durch drücken der Enter-Taste Schauen Sie sich die Log Files für diese Builds an: Menüpunkt Tools Browse Log Files Öffnen Sie das entsprechende Log File 2.3 Verifizieren des Ergebnisses in Access Öffnen Sie die Access-Zieldatenbank dsout.mdb auf Laufwerk D und untersuchen Sie den Inhalt der neu angelegten Dimensionstabellen. In Access: Menüpunkt Datenbanktools Beziehungen Markieren Sie die Tabellen D_Product, D_Fiscal und D_Location und ziehen Sie diese auf das Beziehungen-Fenster Frage: Welches Attribut enthält jede der Tabellen? Woher kommt es und wozu wird es verwendet werden? - Jede der Tabellen enthält ein Attribut namens skey ( surrogate key ). Dieser künstliche Primärschlüssel wird später dazu verwendet werden, um die Faktentabelle mit den Dimensionstabellen zu verknüpfen. Angelegt wurde diese Spalte aufgrund der aktivierten Add Surrogate Keys to the Dimension Tables Checkbox im Dimension Build Wizard (siehe Schritt 1.1). 3. Erstellen von Data Integrity Lookups In Schritt 5. werden Sie Lookups einsetzen, um sicherzustellen, dass nur solche Datensätze in die Faktentabelle aufgenommen werden, die gültige Datensätze in den Dimensionstabellen referenzieren. So soll z.b. der Lagerbestand eines Produkts nur dann in die Stock-Faktentabelle Seite 12 von 16

13 aufgenommen werden, wenn das Produkt auch in der Product-Dimensionstabelle existiert ( Integrität). die Verbindung zwischen Fakten- und Dimensionstabellen über die im vorherigen Schritt 2. angelegten künstlichen Schlüssel herzustellen. Das Lookup bildet hierbei die in den Quelldaten eingesetzten operativen Schlüssel auf die im Data Warehouse eingesetzten künstlichen Schlüssel ab. Im Folgenden werden Sie die hierfür nötigen Lookups definieren: 3.1 Erstellen des FiscalL Lookups Klicken Sie im linken TreeView des Hauptfensters auf das (+)-Symbol vor Library Dimensions Rechtsklicken Sie auf Fiscal und wählen Sie Insert Lookup Als Name wählen Sie FiscalL und klicken Sie auf das Attributes Tab Wählen Sie D_Fiscal als Template. Aus den verfügbaren Attributen werden nur diejenigen benötigt, die für den Integritätstest der Faktdaten und die Abbildung der operativen auf die künstlichen Schlüssel (siehe oben) nötig sind. Fügen Sie deshalb den künstlichen Schlüssel skey und den operativen Schlüssel period_no zur Chosen attributes Liste hinzu. Klicken Sie in der Chosen attributes Liste auf die Id Box für period_no Wählen Sie im Data Access Tab Use Template for data access und selektieren Sie Output in der Connection Box Klicken Sie auf den Browse Button neben dem Table name Feld und selektieren Sie D_Fiscal OK 3.2 Erstellen des LocationL Lookups Klicken Sie im linken TreeView des Hauptfensters auf das (+)-Symbol vor Library Dimensions Rechtsklicken Sie auf Location und wählen Sie Insert Lookup Als Name wählen Sie LocationL und klicken Sie auf das Attributes Tab Wählen Sie D_Location als Template. Aus den verfügbaren Attributen werden nur diejenigen benötigt, die für den Integritätstest der Faktdaten und die Abbildung der operativen auf die künstlichen Schlüssel (siehe oben) nötig sind. Fügen Sie deshalb den künstlichen Schlüssel skey und den operativen Schlüssel state_cd zur Chosen attributes Liste hinzu. Klicken Sie in der Chosen attributes Liste auf die Id Box für state_cd Wählen Sie im Data Access Tab Use Template for data access und selektieren Sie Output in der Connection Box Klicken Sie auf den Browse Button neben dem Table name Feld und selektieren Sie D_Location OK OK 3.3 Erstellen des ProductL Lookups Klicken Sie im linken TreeView des Hauptfensters auf das (+)-Symbol vor Library Dimensions Rechtsklicken Sie auf Product und wählen Sie Insert Lookup Als Name wählen Sie ProductL und klicken Sie auf das Attributes Tab Wählen Sie D_Product als Template. Aus den verfügbaren Attributen werden nur diejenigen benötigt, die für den Integritätstest der Faktdaten und die Abbildung der operativen auf die künstlichen Schlüssel (siehe oben) nötig sind. Fügen Sie deshalb den künstlichen Schlüssel skey und den operativen Schlüssel product_cd zur Chosen attributes Liste hinzu. Seite 13 von 16

14 Klicken Sie in der Chosen attributes Liste auf die Id Box für product_cd Wählen Sie im Data Access Tab Use Template for data access und selektieren Sie Output in der Connection Box Klicken Sie auf den Browse Button neben dem Table name Feld und selektieren Sie D_Product OK OK 4. Erzeugen der Faktentabellen mit Fact Builds Nachdem Sie sowohl die konformen Dimensionstabellen erzeugt, als auch die Lookups angelegt haben, können die Fact Builds zur Erstellung der Faktentabellen angelegt werden. 4.1 Erstellen des Sales Fact Builds Menüpunkt Tools Fact Build Wizard Unter Enter the name of the build Sales eingeben Unter Select the connection into which the build is to deliver data Output auswählen Next Wählen Sie Data Source Add Unter Select the connection from which the data source is to read Sales auswählen Next Haken vor ds_sales setzen, um diese Tabelle auszuwählen Finish Ein Default Transformation Model wird vorgeschlagen. Weiter mit Next Next In der Use Reference Spalte der period_no Dimension wählen Sie das FiscalL Lookup In der Use Reference Spalte der state_cd Dimension wählen Sie das LocationL Lookup In der Use Reference Spalte der product_cd Dimension wählen Sie das ProductL Lookup Next Next Next Next Entfernen sie den Haken vor Deliver dimensions, weil Sie für die Dimensionen ja bereits separate Dimension Builds erzeugt und ausgeführt haben Next Finish 4.2 Erstellen des Stock Fact Builds Menüpunkt Tools Fact Build Wizard Unter Enter the name of the build Stock eingeben Unter Select the connection into which the build is to deliver data Output auswählen Next Wählen Sie Data Source Add Unter Select the connection from which the data source is to read Stock auswählen Haken vor ds_stock setzen, um diese Tabelle auszuwählen Finish Ein Default Transformation Model wird vorgeschlagen. Weiter mit Next Next In der Use Reference Spalte der period_no Dimension wählen Sie das FiscalL Lookup In der Use Reference Spalte der state_cd Dimension wählen Sie das LocationL Lookup In der Use Reference Spalte der product_cd Dimension wählen Sie das ProductL Lookup Seite 14 von 16

15 Next Next Next Next Entfernen sie den Haken vor Deliver dimensions, weil Sie für die Dimensionen ja bereits separate Dimension Builds erzeugt und ausgeführt haben Next Finish 4.3 Ausführen der Fact Builds Um den Verlauf der Fact Builds besser nachvollziehen zu können, passen Sie das Logging an bevor sie die im vorigen Schritt angelegten Fact Builds ausführen: Rechtsklicken Sie im linken TreeView des Hauptfensters unter Builds and JobStreams auf den Fact Build (Sales / Stock) und wählen Sie Properties. Klicken Sie auf das Logging Tab und setzen sie einen Haken vor Detail im Trace Fenster Nachdem Sie das Logging angepasst haben, führen Sie die Fact Builds aus: Klick auf den entsprechenden Fact Build (Sales / Stock) und starten über Menüpunkt Actions Execute OK. Die jeweiligen DOS-Fenster schließen Sie durch drücken der Enter-Taste. 4.4 Verifizieren des Ergebnisses in Access Öffnen Sie die Access-Zieldatenbank dsout.mdb auf Laufwerk D und untersuchen Sie den Inhalt der neu angelegten Faktentabellen Teil III Aufgaben: 1. Betrachten Sie das Log File der Fact Builds. Wieviele Datensätze wurden jeweils in die Zieldatenbank geladen? Wurden Datensätze nicht übertragen? Falls ja, warum? - Es wurden Datensätze nicht übertragen, da Datensätze in die Faktentabelle eingefügt werden sollten, die keine gültigen Datensätze in den Dimensionstabellen referenzieren. Beispiel: Es sollen Verkaufszahlen für ein Produkt eingefügt werden, das es gar nicht gibt. 2. Ein wesentlicher Unterschied zwischen Teil I und Teil II des Praktikums besteht in der Art und Weise wie die Faktentabelle(n) mit den Dimensionstabellen verknüpft sind. Wie ist die Faktentabelle F_Stock aus Teil II mit ihren Dimensionstabellen verbunden? Wie wurde dies in Teil I für die Faktentabelle F_Stock1 realisiert? Welche Vorteile hat die Vorgehensweise in Teil II? Bei der Beantwortung der dritten Frage betrachten Sie folgende Hinweise: a. Verschiedene operationale Datenquellen müssen oft in einem Data Mart bzw. Data Warehouse integriert werden. b. Die Faktentabelle eines Data Marts kann enorm groß werden. c. In einem OLTP-System muss lediglich der aktuelle Status der Entitäten gespeichert werden. So ist es nicht notwendig und vielleicht kontraproduktiv die Vergangenheit eines Mitarbeiters zu speichern; beispielsweise interessiert vielmehr die aktuelle Abteilung des Mitarbeiters als irgendeine alte. Ein Data Warehouse hingegen muss Daten für mehrere Jahre vorhalten und somit auch Änderungen verwalten können. Dies muss ermöglicht werden. - In Teil I wurden die in den operationalen Quelldatenbanktabellen vorhandenen Primärschlüssel dazu genutzt, um auch die (transformierten) Tabellen des Data Marts zu verbinden. In Teil II hingegen wurden zum Seite 15 von 16

16 Verknüpfen der (transformierten) Tabellen des Data Marts neue künstliche Primärschlüssel erzeugt, unabhängig von den bereits vorhandenen (künstlichen) Primärschlüssel in den operativen Quelldatenbanktabellen. Es gibt einige Gründe für die Verwendung eines dedizierten künstlichen Primärschlüssels innerhalb des Data Marts: a. Oftmals werden Entitäten aus verschiedenen operationalen Systemen in einem einzigen Data Mart integriert. Beispielsweise kann in einem Bankenkontext ein einziger Kunde als Girokonto-Kunde, Sparkonto-Kunde, Versicherungs-Kunde, u.s.w. existieren. Anstatt nun drei Kundennummern zu verwenden, um den Kunden zu identifizieren, wird ein künstlicher Primärschlüssel verwendet und die drei Kundennummern werden zu natürlichen Schlüsseln innerhalb des Data Marts. b. Betrachtet man die enorme Größe von Data Marts bzw. Data Warehouses, so kann die geringe Größe von künstlichen Schlüsseln viel Speicherplatz sparen (die Schlüssel müssen in den riesigen Faktentabellen abgelegt werden). c. Künstliche Primärschlüssel innerhalb der Dimensionstabellen ermöglichen das Verwalten von Änderungen über die Zeit. Beispiel: Ein Vertriebsbeauftragter hat eine einzigartige Mitarbeiternummer. Wechselt dieser Vertriebsbeauftragte nun die Abteilung, so bleibt seine Mitarbeiternummer gleich, nur die Abteilung ändert sich. Um nun unterscheiden zu können, welche Geschäfte dieser Vertriebsbeauftragte für seine alte bzw. neue Abteilung gemacht hat, muss in der entsprechenden Dimensionstabelle ein neuer Datensatz eingefügt werden. Die bis dato einzigartige Mitarbeiternummer ist damit jedoch nicht mehr eindeutig. Abhilfe schafft hier eine künstliche Primärschlüsselspalte, die, unabhängig von dem operationalen Schlüssel (Mitarbeiternummer), die Einzigartigkeit garantiert. Innerhalb der Faktentabelle wird diese künstliche Primärschlüsselspalte referenziert, so dass zwischen Mitarbeiter X in Abteilung Y und Mitarbeiter X in Abteilung Z unterschieden werden kann. 3. Der zweite wesentliche Unterschied zwischen Teil I und Teil II des Praktikums besteht in der Art und Weise wie das Data Warehouse aufgebaut wurde. Wie wurden die Fakten- und Dimensionstabellen in Teil I erzeugt und wie in Teil II? Worin sehen Sie die Vorteile des Aufbaus eines integrierten Data Warehouse mit Conformed Data Marts / Dimensions? - In Teil I wurden Fakten- und Dimensionstabellen im Rahmen eines einzigen Fact Builds erzeugt, was das Entwickeln konformer Dimensionstabellen verhindert, da ein weiterer solcher Fact Build die Dimensionstabellen des vorherigen Builds überschreiben würde. Teil II nutzt voneinander getrennte Fact und Dimension Builds und ermöglicht somit den Aufbau eines integrierten Data Warehouse mit konformen Dimensionen. - Im Gegensatz zu einem einzigen Data Warehouse kann ein aus mehreren Teilen zusammengesetztes, integriertes Data Warehouse in handhabbaren Einheiten entwickelt werden Devide and Conquer. - Sind die konformen Dimensionen identifiziert, können die Data Marts unabhängig voneinander, d.h. von verschiedenen Teams entwickelt werden. - (Teil-)Ergebnisse stehen relativ schnell zur Verfügung. - Wartbarkeit, Flexibilität ist erhöht. Seite 16 von 16