OWB10gR2_Step_By_Step_V1
Werbung
Oracle Warehouse step-by-step 1/300 Oracle Data Warehouse step-by-step mit Oracle Warehouse Builder 10gR2/11gR1 Der Praxiseinstieg Unternehmensdaten integrieren Auswertebasis bereitstellen Informationsgewinnung dokumentieren Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 2/300 Version: OWB10gR2_Step_By_Step_V1.doc Stand: September 2006 Version: OWB10gR2_Step_By_Step_V1.doc Stand: Juni 2007 Version: OWB10gR2_Step_By_Step_V1.doc Stand: Feb 2008 (Löschen von Prozessen) Änderungsnummer 3 Autor: Alfred Schlaucher, Oracle Deutschland, ORACLE Deutschland GmbH Kuehnehoefe 5 22761 Hamburg Germany www.oracle.com/de Die zugehörige OWB-Version ist OWB10G Release 2 Die Software kann über die folgende Oracle-Webseite bezogen werden: http://www.oracle.com/technology/products/warehouse/index.html Die Beispieldaten befinden sich auf der CD, mit der dieses Dokument ausgeliefert wurde (Verzeicnis Demodaten). Dieses Dokument ist von einer älteren Version zu OWB 9.2 in eine neuere überarbeitet worden. Nicht alle Kapitel sind fertig geworden. Mit diesen Zeichen °°°° markierte Stellen sind noch nicht fertig. Vom Autor: Hier haben sich eine Menge von Fehlern eingeschlichen. Wen wundert es auch, wenn so ein Text ständig weitergeschrieben und aktualisiert wird. Wenn Sie Fehler finden, melden Sie diesen bitte an die folgende Mailadresse. [email protected] Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 3/300 1. step-by-step zum Data Warehouse .................................................... 9 Bloß nicht alles lesen .................................................................................................................... 9 Kleine Helfer am Rand................................................................................................................ 10 Zu dieser neuen Version des step-by-step ................................................................................. 10 Kapitelübersicht: Wo steht was .................................................................................................. 10 2. Das Data Warehouse ........................................................................ 12 Das Warehouse-Prinzip .............................................................................................................. 12 Das Data Warehouse-System – 3-Schichtenarchitektur ............................................................ 13 Daten für Auswertungen aufbereiten: Dimensionale Sichten ..................................................... 14 Typische Analyseschritte eines Warehouse-Benutzers ............................................................. 15 Umsetzung mit technischen Mitteln – relationale Speicherung multidimensionaler Sichten ..... 17 1. Variante Kalkulationstabelle ................................................................................................ 17 2. Variante Relationale Datenbank ......................................................................................... 18 Spielarten des Starschemas ....................................................................................................... 19 Hierarchien .............................................................................................................................. 19 Intersection-Dimension ........................................................................................................... 19 Heterogenious Faktentabelle .................................................................................................. 19 Parallel Faktentabelle.............................................................................................................. 20 Konstellation ............................................................................................................................ 20 Degenerate Facts .................................................................................................................... 20 Degenerate Dimension ........................................................................................................... 20 Das Warehouse ist ein dynamisches und flexibles System ....................................................... 20 3. Erstellung eines Data Marts – Ein Beispiel-Szenario ..................... 23 Ableitung eines Auswertemodells aus Quellstrukturen .............................................................. 23 Das Quelldatenmodell ................................................................................................................ 23 Das Analysemodell ..................................................................................................................... 24 Das Objektmodell ....................................................................................................................... 24 Mögliche Fragestellungen........................................................................................................... 25 Das Abfrageschema modellieren (Starschema) – Abfragemodell ............................................. 25 Denormalisieren (Star und nicht Snowflake)........................................................................... 25 Informationsanreicherung ....................................................................................................... 26 Granularität ............................................................................................................................. 27 Das Mappingmodell .................................................................................................................... 27 Workflow-Modell ......................................................................................................................... 29 4. Die Komponenten des Oracle Warehouse-Kurzübersicht ............. 30 5. Aufbau des Data Warehouse-Systems mit dem Oracle Warehouse Builder (OWB) .................................................................................. 31 Aus welchen Objekten besteht ein Oracle Warehouse .............................................................. 32 Vorgehensweise bei dem Aufbau eines Warehouse Systems mit dem Warehouse Builder ..... 32 Allgemeine Vorgehensweise im Verlauf eines Lade-Prozesses (ETL) ...................................... 32 Einrichten der OWB Entwicklungsumgebung ................................................ 34 Zusammenspiel mit anderen Komponenten ............................................................................... 34 Einige Warehouse Builder Komponenten (Übersicht) ................................................................ 35 Wo ist die Dokumentation zu OWB 10g zu finden? ................................................................... 36 Systemanforderungen ................................................................................................................ 36 Die Installationsschritte des Warehouse Builders in der Übersicht ............................................ 36 Übersicht zu den angelegten Benutzern .................................................................................... 37 Hilfsscripte zum Erstellen der Demo-User .............................................................................. 38 Einlesen der Demodaten für die step-by-step-Einführung (ausgelieferte Dump-Datei) ............. 38 Unterschiedliche Repository-Benutzer einrichten ................................................................... 40 Die Installationsschritte des OWB im Einzelnen ........................................................................ 40 Voraussetzungen zur Installation: ........................................................................................... 40 Umschalten der Sprache vor der Installation: ......................................................................... 40 Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 4/300 Die Datenbank für die Installation vorbereiten ........................................................................ 40 Schritt 1: Software installieren: ............................................................................................... 41 Schritt 2: Repository Assistant ............................................................................................... 42 Anmeldung .............................................................................................................................. 48 Workflow Installation ............................................................................................................... 49 Erste Schritte ..................................................................................................... 52 Die Ausgangsituation nach der Installation ................................................................................ 52 OWB starten ............................................................................................................................... 52 Englische Bedienerführung einschalten? ................................................................................... 54 Eine erste Übersicht ................................................................................................................... 55 Project-Explorer ...................................................................................................................... 55 Connection Explorer ................................................................................................................ 55 Global Explorer ....................................................................................................................... 55 OMB*Plus ................................................................................................................................ 55 Der Project Explorer ................................................................................................................... 56 Module ordnen das Projekt ......................................................................................................... 56 Quell- oder Zielmodul? ........................................................................................................... 58 Ohne Locations – läuft nichts ..................................................................................................... 58 Schemadaten, Hostname, Port, Service-Name ...................................................................... 59 Die Beschreibung des ersten Quellsystems ................................................... 60 Commit aller Änderungen ........................................................................................................... 61 Definieren eines Source-Moduls für eine Oracle-Datenbankquelle ........................................... 61 Auslesen von Tabellenbeschreibungen (Metadaten) aus einer Quelldatenbank ....................... 62 Ein zweites Modul für die Warehouse-Tabellen erstellen .......................................................... 64 Exkurs 1: Ein genauer Blick auf Module und Locations ............................................................. 64 Exkurs 2: Woher kommen oder wie entstehen die Warehouse Tabellen? ................................ 65 Ein erstes Mapping erstellen ............................................................................ 66 Eine „Rundtour“ durch den Mapping-Editor ................................................................................ 66 Der Explorer (1) ....................................................................................................................... 67 Mapping (5) ............................................................................................................................. 67 Birds Eye View (3) ................................................................................................................... 68 Data Viewer (6) ....................................................................................................................... 69 Properties Inspector (2)........................................................................................................... 69 Generation Results (7) ............................................................................................................ 69 Palette (4) ................................................................................................................................ 69 Das Mapping aufbauen............................................................................................................... 70 Wechselspiel logisch/physisch oder Mapping / Modul ............................................................... 72 Das erste Deployment – Das Control Center ............................................................................. 75 Locations registrieren .............................................................................................................. 76 Die Tabelle generieren ............................................................................................................ 76 Ein Mapping generieren .......................................................................................................... 76 Leserechte .............................................................................................................................. 77 Connectors und Database-Links ............................................................................................. 77 Intelligenter Generierungsmechanismus ................................................................................ 78 Smart-Code Generation .......................................................................................................... 79 Ein erster Blick in das Repository über HTML-Browser ................................ 80 Aufruf des Repository Browsers ............................................................................................. 80 Design-Repository Browser .................................................................................................... 83 Impact- / Lineage-Analyse direkt aus OWB heraus ................................................................ 84 Nützliche Hilfsmittel: ......................................................................................... 87 Validate: ...................................................................................................................................... 87 Ad Hoc-Generierungen im Mapping-Editor ................................................................................ 88 Kopieren von Metaobjekten ........................................................................................................ 89 Schnelles Generieren und Deployen auch ohne Control Center ............................................... 89 Die Operatoren – Teil 1...................................................................................... 90 Mehrere Tabellen über JOIN verbinden und einlesen – Join Operator ............................... 90 Display Set .............................................................................................................................. 90 In mehrere Zieltabellen schreiben - Splitter-Operator Stand/letzte Änderung 13.05.2016 (in Arbeit) .......................................................... 94 75875104 Oracle Warehouse step-by-step 5/300 Exkurs: Multiple-Inserts in einem Kommando ............................................................................ 95 Exkurs: Wie viele Tabellen passen in ein Mapping und wie werden sie kombiniert .................. 96 Filter und Bedingungen (Where Operator) ................................................................................. 98 Exkurs: Zieltabellen automatisch leeren - Truncate ................................................................. 100 Beliebige Ausdrücke in einem SQL-Kommando - Der Expression-Builder ...................... 101 CASE Strukturen im Expression Builder .................................................................................. 104 2. Beispiel .............................................................................................................................. 106 Deduplicator Operator (DISTINCT Option) Aggregieren von Daten (SUM, AVG) ....................................................................... 106 ................................................................................. 107 Lookup Tabellen lesen ...................................................................................................... 110 Eine nachträgliche Änderung in ein Mapping einbauen ....................................................... 110 NULL-Werte verhindern ........................................................................................................ 113 Set Operator (UNION, UNION ALL, MINUS, INTERSECT) .............................................. 114 Pivoting mit SQL Mitteln - Der Pivot-Operator ................................................................... 115 Unpivoting mit SQL Mitteln - Der Unpivot-Operator ......................................................... 119 Unternehmensdaten integrieren – Teil 1 (Textdateien) ................................ 120 Integrieren von Textdateien ...................................................................................................... 120 Wie werden EBCDIC-Dateien eingelesen? .......................................................................... 123 Wie werden Dateien z. B. auf Unix-Servern eingelesen? ..................................................... 123 Einlesen von Textdateien über External Tables ................................................................ 123 Erstellen einer External Table aus einer Textdatei-Definiton................................................ 124 Erzeugen einer Directory-Definition in der Datenbank ......................................................... 124 Generieren von Directory-Objekten für External Tables ....................................................... 125 Test der External Table Definition ......................................................................................... 126 External Tables in einem Mapping benutzen ................................................................. 127 Einlesen von Dateien mit dem SQL Loader ............................................................................. 127 Die Operatoren - Teil2: Generische und wiederverwendbare Komponenten und Text-Output ............................................................................................... 129 Verwenden von Funktionen und Prozeduren – Die erweiterbare Funktionsbibliothek ..... 129 Anlegen einer Funktion ......................................................................................................... 130 Syntax-Check und Code-Debugging .................................................................................... 132 Verwenden einer Funktion .................................................................................................... 133 Verwenden von Aufrufparametern .................................................................................... 134 Parametereingabe und Aufruf des Mappings ....................................................................... 134 Schreiben von Textdateien ....................................................................................................... 135 XML-Dateien erzeugen ......................................................................................................... 137 Selbsterstellte Schreibroutinen ............................................................................................. 138 Wiederverwendbare Mapping-Bausteine – Pluggable Mappings ..................................... 138 Anwendungsszenario „Generisches Protokoll“......................................................................... 140 Zu dem ersten Punkt – flexible Input-/Output-Schnittstelle................................................... 141 Zu dem zweiten Punkt – Erzeugen zusätzlicher Sätze (z. B. Kopfzeilen) ............................ 141 Zu dem dritten Punkt (Kommunikation mit dem aufrufenden Mapping) ............................... 143 Der Sort-Operator ..................................................................................................................... 144 Unternehmensdaten integrieren – Teil 2 ....................................................... 145 Einlesen von ODBC-Quellen .................................................................................................... 145 Verwenden von ODBC-Quellen über den Warehouse-Builder ............................................ 147 Einlesen von XML-Dateien ....................................................................................................... 147 Einlesen von SAP-R/3-Daten mit dem SAP-Integrator ............................................................ 147 Messagebasiertes Einlesen von Nachrichten über Advanced Queuing .................................. 148 Generierungsstrategien .................................................................................. 149 Set based versus Row based ................................................................................................... 149 Der Code für die Set based Variante: ................................................................................... 150 Der Code für die Row based Variante: ................................................................................. 150 Der Code für die Row based (Target only) Variante ............................................................. 152 Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 6/300 Der Code für die Set Based failover to Row based Variante ................................................ 152 Der Code für die Set Based failover to Row based (Target only) Variante .......................... 153 Steuerung der Generierungsvarianten.................................................................................. 153 Mit der Set-Based-Variante performante Mappings erzeugen ................................................. 153 2 Klassen von Mappings – Mappings organisieren .............................................................. 153 Geschickte SQL-Anwendung ................................................................................................ 153 Inhaltliche Prüfungen ............................................................................................................ 154 Null / NOT Null - Prüfung ...................................................................................................... 154 Prüfung Numerisch / nicht Numerisch .................................................................................. 155 Prüfung auf Ist-Datum / Ist Nicht Datum ............................................................................... 155 Summenabgleiche ................................................................................................................ 156 Komplexere Lösungen - Mit temporären Zwischentabellen arbeiten ................................... 156 Ausnahmen, die nur mit Row Based generierbar sind ......................................................... 158 Den Schreibmodus ändern - Insert – Update – Delete ............................................................ 158 Updates - Updates / Insert .................................................................................................... 158 None ...................................................................................................................................... 160 Truncate/Insert ...................................................................................................................... 160 Delete/Insert .......................................................................................................................... 160 Runtime Kontrolle ........................................................................................... 161 Laufzeitergebnisse betrachten Runtime Audit Browser ........................................................ 161 Laufzeitverhalten ändern – Mapping Configuration .................................................................. 161 Zugriff auf die Laufzeitdaten des Repositories ......................................................................... 163 Zusätzliches Fehlerlogging – Error Trigger .............................................................................. 165 Debugger verwenden ...................................................................................... 168 Erzeugen von Auswertemodellen in einem Data Mart (Star Schema, Snowflake, OLAP-Würfel) ............................................................................... 174 Moduleinteilung und zusammenhängende Informationen .................................................... 174 Wozu werden Dimensionen gebraucht ..................................................................................... 174 Aus welchen Teilen besteht eine Dimension ............................................................................ 174 Business Key - Surrogate Key ............................................................................................ 175 Der Primary Key der Dimensionen ........................................................................................... 175 Dimensionen über den Star Schema Wizard erstellen ............................................................ 176 Dimension Artikel .................................................................................................................. 176 Mapping zum Erstellen der Dimension ................................................................................. 180 Dimension Regionen ............................................................................................................. 182 Dimension Kunde .................................................................................................................. 183 Die Zeitdimension ................................................................................................................. 185 Die Faktentabelle .................................................................................................................. 190 Das Füllen der Faktentabelle ................................................................................................ 192 Vermeiden von Fehlern beim Schreiben der Faktentabelle.................................................. 198 6. Automatisieren der Ladeprozesse-Workflow und Scheduling .... 200 Ladeläufe müssen flexibel sein ................................................................................................ 200 Struktur des Ladeprozesses ................................................................................................. 200 Erstellen von Prozessen ........................................................................................................... 201 Das erste Beispiel – einfache Workflows .............................................................................. 203 AND und FORK ............................................................................................................ 204 Schleifen bilden ..................................................................................................................... 205 Wechselspiel von Variablen und Parameter ......................................................................... 208 Parameterübergabe von Mapping zu Mapping ..................................................................... 209 Umgang mit Dateien - File Exists Aktivität ........................................................................ 210 Umgang mit externen Aufrufen Dateien File Exists Aktivität ............................................. 212 Security von externen Aufrufen freischalten ......................................................................... 213 Aufrufen von SQL Plus aus einem Prozess .................................................................... 214 Parameterübergabe an SQL Plus ......................................................................................... 216 Aufrufen von Prozessen und Mappings – Scheduling .............................................................. 218 Scheduling mit OWB-fremden Schedulern ........................................................................... 218 Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 7/300 Scheduling mit OWB ............................................................................................................. 219 Stoppen von laufenden Workflow-Prozessen über SQL*Plus.................................................. 222 Herausfinden von laufenden Prozessen: .............................................................................. 222 Beenden der laufenden Prozesse: ........................................................................................ 222 Beenden der laufenden Prozesse: ........................................................................................ 222 7. Aufbauen von Skripten zum automatisierten Ändern der Modelle (OMB Plus – Scriptsprache) ........................................................... 223 8. Metadatenmanagement im Data Warehouse ................................ 230 Metadaten ................................................................................................................................. 230 Java API ................................................................................................................................ 231 Metadata Dependancy Managers ......................................................................................... 231 Diagramme ausdrucken ........................................................................................................ 234 Auswertungen mit Application Express ................................................................................. 235 Leichtes Austauschen von Metadaten zwischen verschiedenen Repositories (MDL-Files) .... 239 Versionierung von Modellen und Modellteilen .......................................................................... 242 Change Manager – Zurückholen einer alten Version ............................................................... 244 9. Die Verbesserung der Datenqualität.............................................. 245 10. Experts ......................................................................................... 246 11. Implementierung des Starschemas in der Datenbank Oracle 10g247 Summentabellen / Materialized Views ........................................................... 249 Voraussetzungen für Query Rewrite ........................................................................................ 252 Parallelverarbeitung ........................................................................................ 255 Partitionierung ................................................................................................. 256 Partition Pruning ....................................................................................................................... 257 Join über 350.000 Faktsätze ohne Partition ......................................................................... 258 Partition-wise Join ..................................................................................................................... 258 Parallelisierungsgrad und Anzahl Partitions ............................................................................. 259 Zusammenfassende Empfehlung zur Partitionierung .............................................................. 259 Schnelles Laden von Daten mit Transportable Tablespace ........................ 260 Bitmap-Indizierung .......................................................................................... 261 Bitmap-Join-Index ..................................................................................................................... 261 Empfehlungen zum Optimieren von Ladeläufen .......................................... 263 NOLOGGING ........................................................................................................................ 263 In Teilschritten arbeiten ......................................................................................................... 263 CTAS ..................................................................................................................................... 263 Ohne Constraints arbeiten (Aus/Einschalten) ....................................................................... 263 Analyze.................................................................................................................................. 264 Bitmap ................................................................................................................................... 264 Analytische Funktionen in der Datenbank .................................................... 265 Rank Top 10 ............................................................................................................................. 265 Ranking innerhalb von Gruppen ............................................................................................... 265 Top 3 Artikel pro Artikelgruppe ................................................................................................. 266 Anteile an einer Gruppe ............................................................................................................ 267 Kumulierte Anteile ..................................................................................................................... 268 Segmentieren von Gruppen (Kunden) ...................................................................................... 269 Moving Average ........................................................................................................................ 270 Mehrfachverarbeitung innerhalb eines Kommandos – Reporting Aggregate Functions .......... 271 Vorjahresvergleiche .................................................................................................................. 272 Rollup-Option ............................................................................................................................ 275 Cube-Option ............................................................................................................................. 276 Grouping Sets ........................................................................................................................... 276 Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 8/300 Komplexeres Beispiel ............................................................................................................... 277 12. Testdatengenerator ..................................................................... 279 Die Funktionen .......................................................................................................................... 279 Beschreibung ............................................................................................................................ 281 Die Flat Files und die dazu passenden EXTERNAL Table Definitionen .................................. 283 13. Anhang mit Sonderthemen ......................................................... 285 Aufruf eines Mapping im Batch zu Testzwecken ...................................................................... 285 Tabellen im Speicher vorhalten ................................................................................................ 285 Nützliche Zeitfunktionen zum Erstellen einer Zeitdimension .................................................... 285 Rumpffunktion zu schnellen Erstellen einer Funktion .............................................................. 286 Prüfen auf Vorhandensein von Referenzsätzen oder Stammdaten ......................................... 286 Beispiel: Zugriff auf das Runtime-System: ............................................................................... 287 Sinnvolle Namenskonventionen ............................................................................................... 288 Wie mach ich was: Tips und Tricks .......................................................................................... 289 Mengenberechnungstabelle ..................................................................................................... 290 Table Functions ........................................................................................................................ 290 Table Functions und Warehouse Builder .............................................................................. 293 Polling ....................................................................................................................................... 294 Neu-kompilieren von Sourcen in der Datenbank ...................................................................... 295 Testdaten (CSV-File) ................................................................................................................ 295 Literaturliste (kommentiert) ....................................................................................................... 296 Aufrufparameter für OWB-Client setzen: .................................................................................. 298 Testhilfen und hilfreiche Kommandos für SQL*Plus Tests ....................................................... 298 Formatierungen der Ausgaben in SQLPLUS: ....................................................................... 298 Schnelles Erstellen einer CSV-Datei .................................................................................... 298 Hintergrund - Erstellen einer Tabelle mit Parameteraufruf ................................................... 298 Hilfskommandos zum Unterdücken des Outputs im Betriebssystemfenster: ....................... 299 Beispiel-Init.Ora-Datei für eine Installation von OWB und Oracle-Datenbank auf einem(!) Rechner. ................................................................................................................................... 299 Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 9/300 1. step-by-step zum Data Warehouse Die besten Data Warehouse-Systeme kommen nicht von der Stange, also starten Sie ein Data Warehouse-Projekt mit dem Ziel ein neues Data Warehouse zu bauen. Es entsteht nach den ganz speziellen Vorstellungen der späteren Benutzer und der spezifischen Situation des Unternehmens. Jedes Unternehmen ist anders, hat andere Ziele, hat eine andere Geschichte, andere Mitarbeiter und andere Gewohnheiten. Es wäre fatal, wenn ausgerechnet das Werkzeug das die Strategie- und Zukunftsplanung unterstützen soll über eine „0815“-Standard-Analyseanwendung gemeistert wird. Doch schon entstehen Ängste: o „Wird das neue Warehouse-Projekt zu einem Erfolg?“ o „Wer liefert die nötige Erfahrung?“ Denn ein Warehouse wird in einem Unternehmen meist nur einmal erstellt, und dann sollte es da sein. Erfahrungen im eigenen Unternehmen sind Mangelware. Hinzu kommen spezielle Herausforderungen die meist nur in Warehouse-Systemen auftreten: es sind Faktoren und Techniken zu berücksichtigen, die bei operativen Systemen nicht bekannt sind: o Dimensionale Modellierung. o Wechselspiel von Normalisierung und Denormalisierung o Hohe Ressourcenanforderungen bzgl. Mengen und Performance. o Flexibilität von Informationsstrukturen. o Strukturieren und Beschaffen von Informationen von denen man noch nicht weiß, wer sie wie braucht. o Fehlende Spezifikationen usw. Warehouse-Projekte sind Integrationsprojekte, d. h. es treffen sehr unterschiedliche operative Systeme aufeinander. Die Daten daraus sind zu harmonisieren. Diese step-by-step-Unterlage soll Ihnen helfen Aufwand in einem Warehouse-Projekt zu minimieren. Sie ist eine Sammlung von vielen Details und Hilfestellungen, die Sie sonst mühsam zusammen sammeln müssten. Außerdem ist sie eine Anleitung, die wie ein roter Faden durch Techniken und Tools des Oracle-Warehouse führt. Es ist kein Lehrbuch „Wie erstelle ich ein Warehouse“ und auch kein Syntaxnachschlagewerk. Hierzu gibt es genügend Fachbücher und auch Software-Dokumentation. Besonders empfehlenswert ist der Oracle 10g Warehouse-Guide, entweder als PDF-File oder Buch. (Literaturlisten und Bezugsquellen über den Autor im Anhang.) Bei der Erstellung des Papiers war dennoch wichtig, alle Code-Beispiele auch vollständig abzudrucken. Es sind immer Beispiele, die schon mal an anderer Stelle erfolgreich liefen. Sie sind mit Cut/Paste in das Dokument kopiert worden. Dieses Dokument ist kein offizielles Dokument von Oracle, es kann auch fehlerhaft sein. Diese sind sicher in einer Folgeversion korrigiert. Die Produkte sind nicht vollständig beschrieben. Den vollen Umfang der genannten Funktionen und Werkzeuge sollten Sie immer in der jeweiligen Dokumentation bzw. Online Hilfe nachlesen. An manchen Stellen sind Platzhalter für künftige Erweiterungen angebracht. An dem Dokument wird immer noch ständig ergänzt. Korrekturen und Ergänzungen können Sie dem Autor gerne mitteilen. Es gibt nicht zu allen Aktivitäten Bilder und Screencopies. D. H. es macht Sinn das Dokument zu lesen während Sie die Beispiele mit den jeweiligen Werkzeugen durchspielen. Sie brauchen hierzu eine Oracle Datenbank (9.2 aufwärts) und Oracle Warehouse Builder. Passende Beispieldaten sollten zusammen mit diesem Dokument ausgeliefert worden sein. Dieses Dokument wird wohl immer eine Baustelle bleiben. Neue Funktionen, neue Releases und auch neue Erfahrungen mit Beispielen aus Projekten fließen ständig ein. Deshalb Nachsicht, wenn was nicht 100% ausformuliert und fertig ist. Bloß nicht alles lesen Springen Sie in dem Text. Lesen Sie das Inhaltsverzeichnis, und suchen Sie sich die Stellen heraus, die Sie brauchen. Es ist nicht nötig kontinuierlich Seite für Seite zu lesen. Dafür haben Sie sicher keine Zeit. Wenn Sie z. B. längst wissen, wie ein Warehouse im Prinzip funktioniert, dann überspringen Sie die ersten Kapitel. Wenn Sie nur wissen wollen, wie WAREHOUSE BUILDER bedienen, dann springen Sie direkt in diese Kapitel. Wenn Sie das alles schon kennen und nur den Testdatengenerator bedienen lernen wollen, dann springen Sie dorthin. Allerdings sind in die Beispiele in dem Kapitel 5 aufeinander aufbauend Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 10/300 Kleine Helfer am Rand An den verschiedenen Textstellen sind zur besseren Orientierung Hinweismarkierungen angebracht. Diese sind: Besondere Tips: Praktische Hinweise aufgrund schon mal irgendwann vorher gemachter Erfahrungen Vorsicht Falle: Hier gibt es besondere Tips oder hier laufen Sie leicht Gefahr einen Fehler zu machen. Demodaten: Hier brauchen Sie etwas von außen z. B. Beispieldaten, die man Ihnen überlassen hat. Aufgabenstellung: Eine zu lösende Aufgabenstellung wird formuliert. Fragen an den Experten: Bestimmte Fragestellungen treten immer wieder auf. Hier sind weitergehende Hinweise, besondere Lösungswege, typische Verfahren gekennzeichnet. Es sind meist Lösungswege aus der Praxis bzw. aus Warehouse-Projekten, die man übernehmen kann. Infos am Rand bzw. hinter den Kulissen Manches Hintergrundwissen kann helfen bestimmte Dinge zu verstehen. Zu dieser neuen Version des step-by-step Nachdem der Warehouse Builder 10gR2 sehr lange auf sich waren lies und dann das Ende der BetaPhase sehr überraschend kam, musste dieses step-by-step Dokument sehr schnell von der alten Version in diese neue überführt. Was ist neben der Anpassung auf das neue Release anders und neu: Die Beispiele in Kapitel 5 sind durchgängig aufeinander aufbauend. Damit entsteht am Ende von Kapitel 5 ein zusammenhängendes Übungsbeispiel, in dem fast alle wichtigen Operatoren eingesetzt werden. Weil der Funktionsumfang des Workflows gewachsen ist, wurde ihm mehr Platz eingeräumt. Die wichtigsten Techniken im Umgang mit dem Workflow sind erklärt. Was fehlt noch und kommt in der nächsten Fassung: Das Data Profiling-Thema ist nicht aufgenommen worden. Das Thema ist zu umfangreich. Um dem Thema gerecht zu werden, muss man es zusammen mit den anderen Datenqualitätstechniken darstellen also Match/Merge und Metadatendokumentation. Experts. Für dieses neue Thema gibt es noch zu wenig Erfahrungen. Außerdem gibt es Dinge die unbedingt noch ausgebaut, vertieft und systematischer dargestellt werden müssten: Konzepte und Anwendungsbeispiele rund um das Metadatenmanagement Ein Betriebskonzept, also der Einsatz von OWB in Entwicklung, Test und Produktion Zu all den fehlenden Themen gibt es beim Autor bereits Material. Also, wer hier Informationen benötigt, der kann sie dort bekommen. Kapitelübersicht: Wo steht was 1. step-by-step zum Data Warehouse Diese Einleitung. Hinweise zur Bearbeitung. 2. Das Data Warehouse Hier finden Sie allgemeine Hinweise zu dem Thema Data Warehouse. Was ist es, und wer braucht es. Viele kennen das Thema schon, wenn Sie dazu gehören, überspringen Sie das Kapitel. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 11/300 3. Erstellung eines Data Marts - Am Beispiel 4. Die Komponenten des Oracle Warehouse - Kurzübersicht 5. Aufbau des Data Warehouse-Systems mit dem Oracle Warehouse Builder (OWB10g) 6. Automatisieren der LadeprozesseWorkflow und Scheduling 7. Skriptsprache 8. Metadatenmanagement Warehouse 9. Dataquality Management 10. Experts (Templates) 11. Implementierung des Starschemas in der Datenbank Oracle 10g 12. Testdatengenerator Stand/letzte Änderung 13.05.2016 im Data Hier stehen Erklärungen zu dem Fallbeispiel dieser step-by-step Unterlage. Außerdem sind Modelle vorgestellt, wie sie in einem WarehouseProjekt zum Einsatz kommen. Dieses kurze Kapitel listet die Tool-Komponenten des Oracle Warehouses auf. In diesem Kapitel ist die Bedienung des Oracle Warehouse Builders sehr detailliert erklärt. Hierzu gehören die Installation, der Aufbau der Entwicklungsumgebung und das Durchspielen des Fallbeispiels. Für die Einarbeitung in OWB ist dieses Kapitel mit das wichtigste. Wer dieses Kapitel durchgearbeitet hat, sollte danach bereits gut mit OWB arbeiten können. Der Workflow ist in dem OWB10g Release umfangreicher geworden. Die Beschäftigung mit dem Workflow ist daher lohnender und zu empfehlen. Hier sind Beispiele für die Durchführung von Arbeiten mit Skripten. Dies ist ein weiterführendes Thema und vor allem für diejenigen interessant, die OWB nach einem Projektabschluss im Echtbetrieb einsetzen wollen. Hier sind praktische Tips im Umgang mit dem Metadaten-Browser und der MDL-Datei vorgestellt. (Dieses Kapitel fehlt hier noch, es wird nachgeliefert.) Enthalten sind Data Profiling, Match Merge, Data Quality Auditing. (Dieses Kapitel fehlt hier noch, es wird nachgeliefert.) Enthalten ist der Aufbau von Experts (Templates). Die Oracle 10g Datenbank unterstützt ganz besonders das Starschema. Partitioning, Materialized Views, Bitmap-Indizierung und andere Techniken kommen zum Einsatz. Der Testdatengenerator ist eine Warehouse Builder-Anwendung. Wenn Sie die Funktionen geladen haben, steht Ihnen ein sehr hilfreiches Zusatz-Utility zur Verfügung (in Arbeit) 75875104 Oracle Warehouse step-by-step 12/300 2. Das Data Warehouse Das Data Warehouse gehört mittlerweile in vielen Unternehmungen zu den Standardsystemen. Es unterstützt die Kontrolle, die Planung und die strategische Ausrichtung von Unternehmensaktivitäten, beginnend bei der operativen Ebene bis hin zur Chefetage. Das Warehouse-Prinzip In operativen Anwendungen der Unternehmen (Bestellwesen, Buchhaltung, CRM, Lieferanten...) sind Unternehmensdaten in der Regel nach den Online-Bedürfnissen des Tagesgeschäfts organisiert: Solche Daten, die DV-Anwendungen oft zusammenhängend bearbeiten, sind auch zusammenhängend und damit performant in der Datenbank gespeichert. Allerdings sind diese Daten für die Analysezwecke von Controllern, Strategen, Marketingplaner meist unbrauchbar. Ein Beispiel: Es ist 10 Uhr morgens, und Sie müssen jetzt eine Entscheidung treffen, die erheblichen Einfluss auf Ihre Produkt- und Verkaufsstrategie der nächsten Monate hat. Sie wissen, dass die benötigten Informationen irgendwo in den verschiedensten Systemen zu finden sind, auf die Sie mit Ihrem PC oder über das Netzwerk zugreifen können. Sie wissen aber auch, dass Sie keine Möglichkeit haben, diese Informationen in der verbleibenden Zeit zu sammeln und in einen Zusammenhang zu bringen. Sie kapitulieren vor der Flut der Daten, auf die Sie zwar physisch zugreifen können, aber aufgrund der riesigen Menge, der Zersplitterung und der Redundanzen der Daten oder der fehlenden Dokumentation resigniert aufgeben. Studien zufolge sammeln wir in den Jahren 2003 bis 2006 in unseren Systemen mehr Daten, als die Menschheit bis dahin in den letzten Jahrtausenden davor. Die Speicherindustrie unterstützt uns dabei mit immer billigeren Plattenstapeln und steigender Plattenkapazität. Das mühsame Durchsuchen von Bergen von Listen ist oft der letzte Ausweg; aber ist ein solches Vorgehen eine vernünftige Planungs- und Entscheidungsgrundlage? Trotz aller Investitionen in Hardware, Software, Netzwerke und Betriebssysteme werden nicht die Informationen geliefert, die wirklich zur Entscheidungsfindung erforderlich sind. Aber nicht nur die Menge und die Zersplitterung stellen uns vor Herausforderungen. Auch einige bestehende Berichtswesenvarianten erschweren uns das Auffinden von Informationen und sie produzieren zudem noch unnötig Kosten: Weitere Beispiele: Fall 1 Ein großes Speditionsunternehmen erzeugt monatlich fünf Berichtsmappen mit zusammen 700 Einzelberichten. Sieben Mitarbeitern aus mehreren Abteilungen erstellen diese Berichte zum Teil von Hand. Diese 700 festen Berichte sollte das Unternehmen auf weniger als 50 generische Berichte reduzieren und sie automatisch und zeitgesteuert herstellen lassen um die Handarbeit zu ersetzen. Fall2 Ein Automobilhersteller zählt 15000 Einzelberichte. Verständlich, denn es gibt viele Abteilungen, und jede Abteilung besteht auf ihren individuellen Berichten. Ein zentraler Informationspool könnte eine Menge redundanter Berichte beseitigen, auch wenn diese optisch oder strukturell sehr unterschiedlich aufgebaut sind. Fall 3 Ein Controller einer Sparkasse stöhnt, weil er 80% seiner Arbeitszeit, damit verbringt 30 Datenbestände (Dateien, Excel-Sheets usw.) zusammen zu tragen. Die verbleibenden 20 % benötigt er dann dafür, die fertigen Berichte per Email oder zu Fuß zu den Kollegen in den anderen Büros zu transportieren. Automatisiertes Konsolidieren der Daten (was meist möglich ist) würde für die eigentliche Arbeit des Controllers freie Zeit schaffen. Fall 4 Eine TV-Gesellschaft muss IT-Personal abstellen, um Fachanwendern zu helfen, die komplexen Datenmodell des bestehenden Auswertesystems zu verstehen. Ein einfaches intuitives Datenmodell, wie das weiter unten beschriebene Starschema-Modell, könnte auch hier helfen. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 13/300 Die meisten Datenbestände in einem Unternehmen sind darauf ausgerichtet sind, den Ansprüchen der operativen Systeme zu genügen. Ein reibungsloser Ablauf des Tagesgeschäfts ist zu gewährleisten. . Ihre Daten sind sehr detailliert und haben sehr oft keine Verbindung zueinander. Aber die Anforderungen an operative Systeme unterscheiden sich grundsätzlich von den Anforderungen eines Anwenders, der strategische Entscheidungen zu treffen hat. Hierfür. Ist es notwendig, die Daten der operativen Systeme in einen inhaltsbezogenen, nach Sachthemen sortierten, historisch zu betrachtetem Zusammenhang zu bringen, die der Sichtweise eines Entscheiders oder Analysten entspricht. Für diese Zwecke extrahiert man Daten aus den operativen Systemen und überführt sie in ein Data Warehouse (ETL-Prozess, Extraction-Transition-Load). In dem Warehouse liegen die Daten meist in einer feinen, granularen, einmaligen und konsistenten Form vor. Sie sind durch zusätzliche sog. Referenzdaten oder auch externe Daten angereichert. Ständiges Nachladen der operativen Daten führt zur Historisierung. So ist es möglich zeitabhängige Veränderungen festzustellen, Trends sind erkennbar. Die Folge ist eine neue Qualität von Entscheidungen für alle Unternehmensbereiche - der Grundstein für einen langfristigen Unternehmenserfolg. Das Warehouse bildet die Grundlage für Auswertungen durch Analysten, Controller oder andere Warehouse-Benutzer, entweder direkt oder über eine weitere Warehouse-Schicht den Data Marts (kleine auf Benutzerbedürfnisse hin ausgerichtete Auswertedatenhaltung). Das Warehouse ist ein zentraler Datenpool, in dem alle entscheidungsrelevanten Informationen des gesamten Unternehmens gespeichert und für jeden autorisierten Mitarbeiter an jedem Ort zur Verfügung stehen. Das Data Warehouse-Prinzip – aus Daten Informationen machen! Das Data Warehouse-System – 3-Schichtenarchitektur Anders als klassische Reportingsysteme, die oftmals „stand alone“ und isoliert in separaten Abteilungen eingesetzt waren, besteht ein Data Warehouse-System aus mehrere Ebenen (Schichten) in denen die Informationen des Produktionsbetriebes Stück für Stück zunächst konsolidiert und letztlich für Auswertungsbelange neu aufbereitet werden. Das Ziel ist eine möglichst umfassende, dabei mehrere Unternehmens- und Themenbereiche abdeckende Informationsablage zu erhalten, die in kurzer Zeit konsolidierte Berichte und Analysen für alle (!) Zielgruppen des Unternehmens bereitstellt. Um das zu erreichen, isoliert man die eigentlichen Warehouse-Daten von den operativen Daten der Quellsysteme, aber auch von den Auswertedaten der späteren Benutzer. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 14/300 Die wesentlich umfassendere Warehouse-Schicht ist sachthemenorientiert und integriert bereichsübergreifende Fragestellungen (in der Regel 3. Normalform). Sie ist besonders gut für Konsolidierungszwecke geeignet, da sich Daten in der 3 Normalform sehr leicht sortieren und vergleichen lassen. Die Data Marts dagegen sind auf die einzelnen Zielgruppen mit ihren speziellen Fragestellungen zugeschnitten. Sie sind meist denormalisiert als sog. Dimensionale Modelle oder Würfel (Cube) aufgebaut . Das gesamte System kann durch eine Staging Area von den Vorsystemen (OLTP-Systeme) getrennt sein (Pufferschicht), damit sich die beiden Bereiche z. B. durch Performanceverluste nicht gegenseitig behindern. Außerdem können die aus unterschiedlichen Vorsystemen stammenden Daten in der Staging Area validiert und zurecht geschnitten werden. Sie ist das Eintrittstor aller Daten in das Warehouse. Zum Versorgen der verschiedenen Ebenen des Data Warehouse müssen Daten fließen. Es beginnt bei der Extraktion aus den Quellsystemen, mit Flat Files, Mainframesysteme, ERP-Systeme oder Dateien aus der Officewelt. Prüfungen und Umwandlungen machen Informationen vergleich- und kombinierbar. Zusätzliche Schlüsselbeziehungen sind aufzubauen. In weiteren Ladeschritten gelangen die Daten in die Warehouse– und letztlich in die Data Mart-Schicht. Das 3-Schichtenmodell sorgt für Flexibilität im Warehouse: Reichen die Informationen im Data Mart (oftmals als Starschema realisiert) für den Benutzer nicht mehr aus, dann kann die umfassendere Warehouse-Schicht solche Informationen nachliefern. Sehr schnell lassen sich neue Strukturen in der Data Mart-Schicht aufbauen. Mehrschichtenmodell eines Warehouse – Flexibilität und Skalierung schaffen! Daten für Auswertungen aufbereiten: Dimensionale Sichten Data Warehouse-Systeme halten Daten in einer Form vor, die für Fachmitarbeiter leicht auswertbar und leicht verstehbar ist. Diese Form muss zwei Ansprüchen genügen: 1. Sie muss für die Benutzer (Business-User) verständlich und intuitiv sein. Der Benutzer soll „seine Daten wiederfinden“. 2. Die Warehouse-Daten müssen mit vertretbarem Aufwand technisch gut verwaltet werden können. Wir brauchen eine flexible Struktur, um schnell auf neue Informationsanforderungen reagieren zu können. Gerade in einem Data Warehouse-System ändern sich die Informationsanforderungen ständig und es kann nicht immer ein neues Entwicklungsprojekt gestartet werden, um neue Daten zu liefern. Um diese Anforderungen zu erfüllen, hat sich die Modellierungstechnik des Starschemas durchgesetzt. Die meisten Warehouse-Systeme nutzen in ihrem Kern heute eine Variante dieses bewährten Prinzips in der Data Mart-Schicht. Daher ist hier eine kurze Zusammenfassung und Herleitung der Prinzipien eines Starschemas dargestellt. In der folgenden Liste sind typische Analyse-Vorgehensweisen eines Benutzers aufgeführt. Danach folgt die technische Darstellung zunächst mit Hilfe einer Spreadsheet-Darstellung und schließlich mit einer relationalen Datenbank wie Oracle. Schnell erkennen Sie die Limitierung des SpreadsheetAnsatzes und die Vorteile der dimensionalen Modellierung eines Starschemas in einer relationalen Datenbank. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 15/300 Typische Analyseschritte eines Warehouse-Benutzers Bildhafte Darstellung Welche Information braucht der Benutzer Beschreibung Welcher Umsatz wird in welcher Zeit erreicht? Ein einfacher erster Schritt ist das Betrachten entlang von Achsen eines Koordinatensystems, bei dem die Achsen den korrespondierenden Messgrößen entsprechen, z. B. Zeit und Umsatz. Die Schnittpunkte der Achsen bilden einen Zahlenraum – die eigentlichen Analysewerte. Es können beliebig viele Messgrößen (Dimensionen) in die Betrachtung mit einbezogen werden – theoretisch unbegrenzt, praktisch kann auch der geübte Analyst kaum mehr als 5 – 6 Sichten sich bewusst machen. Dreidimensionale, visuelle Hilfsmittel sollen schließlich die Vorstellungskraft unterstützen. Die „vierte“ Sicht (Dimension) wird durch einen zusätzlichen Würfel vergegenständlicht. 3 Sichten Welchen Umsatz in welcher Zeit pro Produkt? 4 Sichten Welchen Umsatz in welcher Zeit pro Produkt und Region? Räumliche Sichten zur Verbesserung der Vorstellungskraft. Jeder Würfel entspricht einem „Business View“. Welchen Umsatz erzielten die einzelnen Produkte in den Regionen in welcher Zeit? Welchen Vertriebszyklus (Zeit) durchliefen welche Produkte bezogen auf die einzelnen Regionen? (Pivoting) Welchen Umsatz erzielten die Produktegruppe XYZ in den Regionen in welcher Zeit? Welchen Umsatz erzielten die Produkte in den Regionen im 3. Quartal? (Slice und Dice) Stand/letzte Änderung 13.05.2016 (in Arbeit) Durch Vertauschen der Sichten (Dimensionen) entstehen Abfragevarianten bei gleichem Zahlenraum. Obwohl es sich um die gleichen Daten handelt, entstehen neue Sinnzusammenhänge. Entlang der Achsen (Dimensionen) schränkt man die Betrachtung ein. Achsenelemente werden einzeln betrachtet oder in Gruppen segmentiert. In Gruppen zusammen gefasst, lassen sich vergleichbare Achsenelemente aggregieren (Produktgruppen, Verkaufsgebiete usw.) 75875104 Oracle Warehouse step-by-step 16/300 Welchen Umsatz erzielten die einzelnen Produkte aus der Produktgruppe XYZ in den Regionen in welcher Zeit? (Drill Down) Welche Produktgruppen waren in den Regionen in welcher Zeit am erfolgreichsten? (Roll Up) Aggregation entlang von Unternehmensleveln. Drill to Detail auf Einzelobjekte. An welchen Produkten wurde unter Berücksichtigung der Lieferantenpreise in welchen Regionen am meisten verdient? Welche Produkte verursachten in welchen Regionen in welchen Zeiten die höchsten Lagerkosten? (Drill across) Stand/letzte Änderung 13.05.2016 (in Arbeit) Die Daten können selbst bereits Verdichtungen - also Zusammenfassungen von feineren Daten - sein. Es bilden sich Hierarchien. Häufig vorkommende übliche Hierarchien sind: - Zeithierarchien (Monat / Quartal / Jahr) - Unternehmenshierarchien (Abt. / Sparte) Unternehmenshierarchien sind meist nach dem tatsächlichen Geschäftsbetrieb (Produkte, Regionen usw.) ausgerichtet. - Produktgruppen - Regionen Daten in den Würfeln können unterschiedlich sein, aber dennoch durch identische Sichten (Achsen) vergleichbar sein. In dem nebenstehenden Beispiel sind Verkaufsund Einkaufszahlen vergleichbar, weil sie sich auf die gleichen Produkte und Zeiteinheiten (Dimensionen) beziehen. 75875104 Oracle Warehouse step-by-step 17/300 Umsetzung mit technischen Mitteln – relationale Speicherung multidimensionaler Sichten 1. Variante Kalkulationstabelle Welche Produkte werden an welchen Tagen wie oft verkauft? Eine einfache Variante für eine zweidimensionale Sicht ist z. B. eine Exceltabelle. Welche Produkte werden an welchen Tagen in welcher Stadt wie oft verkauft? Bei drei Sichten müssen Sie bei dieser Lösung bereits mehrere Exceltabellen schachteln. Welche Verkäufer verkauften welche Produkte an welchen Tagen in welcher Stadt wie oft? Erreichen wir 4 Sichten, ist ein ganzer Block hinzuzufügen. Die Vorgehensweise ist zunehmend unbrauchbar. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 18/300 2. Variante Relationale Datenbank Die Darstellung Verkaufszahlen in einfachen Tabelle. geht hier nicht. Technisch gesehen: Die zentrale Tabelle nennt man Faktentabelle (Facts) die umliegenden Dimensionstabellen (Dimensions). Beide Tabellenarten sind über 1:nBeziehungen miteinander verbunden. Die Foreign Keys sammeln sich in der Faktentabelle. Die Faktentabelle ist lediglich durch diese Foreign Keys bestimmt. Sie hat keinen eigenen Primary Key. Es können also Sätze mehrfach vorkommen. Dimensionstabellen enthalten beschreibende Informationen zu den Geschäftsobjekten (Textfelder, einmalige Eigenschaften, Stammdateninformationen). von einer Mehr Trennen von reinen Produktbeschreibungsdate n (Dimension oder Sicht) und den Verkaufszahlen (Fakten) in zwei über eine 1:n Beziehung verbundeneTabellen. Mit dieser Technik lassen sich jetzt nach und nach mehrere Sichten um die Verkaufszahlen herum gruppieren. Wie in dem oben dargestellten Mehrachsendiagramm bestimmen jetzt die Schlüsselwerte in den 1:n Beziehungen den Zahlenraum in der Verkaufstabelle (Fakten). Beliebig viele Sichten (Dimensionen) lassen sich darstellen. Gleichzeitig entsteht eine graphische Darstellung, welche die Vorstellungskraft auch des Business-Users unterstützt. Die Sichten (Dimensionen) entsprechen den Geschäftsobjekten der realen Welt, in der es sich um Produkte, Regionen, Verkäufer und Zeiträume dreht. Gemessen wird der Erfolg bei dem Umgang mit diesen Geschäftsobjekten: Verkäufe oder Umsatz. Die Dimensionen stellen dabei Ausgangspunkte für Geschäftsabfragen dar. Aber gleichzeitig handelt es sich hierbei um ein Datenmodell das eine relationale Datenbankstruktur beschreibt. Das Modell ist in dieser Form z. B. in einer Oracle Datenbank umsetzbar. Es wird Starschema genannt. Faktentabellen beinhalten Felder, mit denen gerechnet werden kann. Alle mess-/berechenbare Fakten, die sich ereignen (Bewegungsdaten). Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 19/300 Spielarten des Starschemas Damit sind die Grundeigenschaften des Starschemas beschrieben. Die folgende Übersicht skizziert mögliche Varianten eines Starschemas. In der Mitte steht die zentrale Faktentabelle. Um sie gruppieren sie sich eine Zeit-, Produkte-, Orte-, Verkäuferdimension. Bis auf die Verkäuferdimension sind alle über eine 1:n Foreign Key-Beziehung an der Faktentabelle angeschlossen. Dimensionstabellen können hierarchisiert sein. Hierarchien Die Ortedimension besteht z. B. aus den Hierarchieebenen „Ort“, „Kreis“, „Land“. Diese Hierarchieebenen könnten selbst wieder in separaten Tabellen liegen, die untereinander auch wieder über Foreign Key-Beziehungen verbunden sind. Entstehen würde eine sogenannte SnowflakeDimension. Von dieser Konstruktion wird hier abgeraten, da bei späteren Abfragen in der Datenbank zusätzliche Join-Aufwände zu erwarten sind. Außerdem können dann Techniken der Staroptimierung, wie sie im Folgenden noch besprochen werden, nicht mehr effizient eingesetzt werden. Es sollten also alle Hierarchien innerhalb einer Tabelle abgebildet sein. Diese ist dann denormalisiert. Es gibt noch eine zweite Art der Hierarchisierung. Bei der Produktdimension ist eine typische Stücklistenstruktur dargestellt, d.h. innerhalb einer Tabelle finden sich sog. Parent- und Child-Sätze einer Hierarchie, die beliebig tief geschachtelt sein kann. Die Tabelle bildet eine Beziehung auf sich selbst (rekursiv). Diese Art der Speicherung mag praktisch sein, ist aber nicht praktikabel für spätere Auswertungen. Man stelle sich nur vor, man will die verschiedenen Hierarchieebenen in einem Bericht mit Gruppenwechseln darstellen, ohne allerdings zu wissen, wie viele Gruppenwechsel vorkommen. Das Layout des Berichtes ist nicht vorherbestimmbar, also auch nicht automatisierbar. Selbst wenn es SQL-Mittel gibt, mit denen diese Struktur aufgelöst werden kann (Connect By), sollte sie dennoch bereits während des Starschema-Designs aufgelöst werden. Man nimmt eine fixe Anzahl von Level als Platzhalter an, von der man glaubt, dass sie nicht erreicht wird (L1-L10). Intersection-Dimension Eine weitere Dimensionsvariante ist für „Verkäufer“ dargestellt. Arbeiten mehrere Verkäufer eines Unternehmens an einer Verkaufsaktivität, so können die einzelnen Verkäufer nicht direkt den entsprechenden Faktensätzen zugeordnet werden. Es besteht eine n:m Beziehung zwischen Verkäufern und Verkaufsaktionen. Hier nutzt man eine Intersection-Tabelle. Die n:m-Beziehung löst sich also in eine Zwischentabelle mit zwei 1:n-Beziehungen auf. Heterogenious Faktentabelle Eine weitere Variante, um das vorgenannte Problem zu lösen, ist das Erstellen einer separaten Faktentabelle, in der der verkäuferbezogene Umsatz abgelegt ist. Diese neue Faktentabelle unterscheidet sich von der zentralen Faktentabelle dadurch, dass sie jeweils immer nur einen Teil der produktbezogenen Umsätze auflistet. Die Art der Fakten ist also die gleiche ( es handelt sich um Verkaufsumsätze), allerdings sind sie anders berechnet worden. Starschemen können aus mehreren Faktentabellen bestehen, Dimensionstabellen werden wiederverwendet, Informationen synchronisiert! Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 20/300 Parallel Faktentabelle Ein Starschema kann durchaus mehrere Faktentabellen enthalten (auch wenn die Form des Sterns damit nicht mehr gegeben ist). Hier handelt es sich dann meist um Messwerte, die miteinander in Bezug gesetzt werden sollen (Drill-Across-Anforderung). In dem Beispiel ist eine separate Faktentabelle für die Bestellkosten (Lieferkosten, Bezug über Lieferanten) gebildet worden. Konstellation Das Entscheidende an dieser „Konstellation“ des Starschemas ist, dass alle drei Faktentabellen vergleichbare Ergebnisse liefern. Es werden sog. „Conforming Dimensions“ genutzt, in diesem Fall sind es „Produkte“ und „Zeit“, über die eine Synchronsierung der Faktentabelle garantiert wird. Es sind z. B. Abfragen möglich, in denen die Lieferkosten und die Verkaufserlöse pro Produkt gegenüber gestellt werden können, oder es kann die Liquidität bzw. Kostendeckung über einen gewissen Zeitraum hinweg kontrolliert werden „Wie ist der zeitliche Verlauf der Differenz von Einkaufsaufwendungen und Verkaufserlösen?“, „Besteht die Tendenz einer Fehldeckung?“. Den Gesamtverbund von Faktentabellen über Conforming Dimensions nennt man Konstellation (Constallation). Factless Facts Faktentabellen müssen nicht immer messbare Werte enthalten. Sie können auch lediglich aus den Foreign Keys der Dimensionen bestehen. Hier soll z. B. festgehalten werden, ob es überhaupt eine Verkaufsaktivität gegeben hat. Degenerate Facts Bei dieser Variante werden eigentlich zu messende Fakten-Informationen als Tabellenspalte in einer Dimension mit aufgenommen. Z. B. kann ein Artikelpreis eine Column in einer Produktedimension sein. Im Prinzip könnte dieser Wert auch direkt in einer Faktentabelle stehen, wenn bei verschiedenen Verkaufsaktionen etwa unterschiedliche Preise bzw. Rabatte genutzt werden. Ist er aber fix, so könnte er auch in einer Dimension für jedes Produkt einmal aufgelistet werden. Die Faktentabelle, die sehr groß werden kann, wird dadurch kompakter. Gesamtumsätze pro Verkauf können schließlich auch berechnet werden aus einer Mengenangabe in der Faktentabelle und dem Preis aus einer Dimensionstabelle. Degenerate Dimension Das Gegenstück sind die „Degenerate Dimensions“. Hier sind Felder, die eigentlich aufgrund ihres Charakters in einer Dimension gespeichert sein sollten Bestandteile der Faktentabelle geworden. Dies lohnt sich bei Einzelinformationen, um somit einen zusätzlichen Join zu einer Dimension bei späteren Abfragen zu sparen. Durch diese geschickte Art der Speicherung von Dimensionen und Fakten lassen sich Sichten des Analytikers in eine relationale Datenbank wie Oracle ablegen. Alle oben beschriebenen nötigen Vorgehensweisen bei der Analyse sind durchführbar: Drill up/Down über die Hierarchien der Dimensionen, Slice/Dice über Filter bei Abfragen, Pivoting über die Reihenfolge der Dimensionen in den Abfragen, Drill Across über das gleichzeitige Abfragen zweier Faktentabellen mit einer gemeinsam genutzten Dimension als Join-Kriterium. Das Warehouse ist ein dynamisches und flexibles System Das hier skizzierte Starschema ist ein „Repräsentationsdatenmodell“, weil es Anforderungen der Warehouse-Anwender realisiert. Es ist aber auch ein wichtiger Baustein in der Kette der Informationswandlung von den operativen Quellsystemen bis hin zu den Berichten der Endanwender. Das Data Warehouse ist ein System zur Informationsgewinnung. Das System ist als durchgängiger Prozess zu verstehen. Dieser Informationsgewinnungs-Prozess sollte möglichst wenig durch Barrieren gestört werden. D. h. es ist z. B. sehr wichtig rechtzeitig zu garantieren, dass geänderte Informationsanforderungen der Endbenutzer schnell genug befriedigt werden können. Meistens ist es Ihnen unmöglich, solch Änderungen vorherzusehen. Wissen Sie immer welcher Anwender in zwei Wochen oder zwei Monaten oder in einem halben Jahr welche neuen Informationen braucht? Bevor in den Frontend- Werkzeugen dafür aufwendige Programmier- und Analysearbeit geleistet wird, sollte es möglich sein, fehlende Informationen in den früheren Phasen des Informationsgewinnungsprozesses bereitzuhalten. Ein Mittel hierfür ist das Starschema. Versuchen n Sie einen kleinen Test und finden Sie in dem folgenden Starschema die Anzahl der Kombinationsmöglichkeiten aller Attribute heraus. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 21/300 Wie viele Abfrageoptionen bietet dieses kleine Starschema? Wahrscheinlich geben Sie auf oder zumindest versuchen Sie einen geschickten Rechenalgorithmus zu finden, um alle Kombinationsmöglichkeiten zu errechnen. Es sind weit über 100. Die Zahl vervielfacht sich wenn Sie noch mehr Attribute in die Dimensionen mit aufnehmen oder sogar noch ganze Dimensionen hinzufügen. Auch wenn manche Abfrage-Optionen unsinnig sind, ist erkennbar, wie viel Informationspotential in einer so einfachen Datenmodellstruktur enthalten ist. D. h. ob die Benutzer entsprechende Abfragen bereits parat haben oder nicht, bereits in der Anlage des Datenmodells liegen Informationen bereit, die potentiell jederzeit nutzbar sind, ohne zusätzlichen Datenbeschaffungsaufwand zu betreiben. Wenn dennoch nicht die richtigen Informationen im Starschema vorliegen, bleibt immer noch der Weg zurück in die granular gehaltene Warehouse-Schicht. Hier sollten Informationen wie in den Regalen eines Warehauses sortiert vorliegen. Mit wenig Aufwand ergänzen Sie daraus das Starschema mit den fehlenden Daten. Und wenn auch das nicht reicht, so sollte der Weg in die Quelldatenbestände vorgezeichnet sein. Das Starschema ist natürlich noch entsprechend performant in der Oracle-Datenbank zu implementieren. Die beiden Anforderungen des Benutzers performantes Antwortzeitverhalten und Flexibilität bei der Vielfältigkeit der möglichen Fragestellungen sind nur durch ein integriertes Zusammenspiel aller Komponenten des Warehouse-Systems zu erreichen. Sinkt die Performance bei Abfragen, können entsprechende Optionen in der Datenbankhelfen. (z. B. durch zusätzliche Materialized Views). Auch solche Optionen sind bei dem Warehouse-Design zu berücksichtigen. Staging- oder Hilfssummentabellen können bei einem effizienten Ladefluss stören. Das Datenbanksystem sollte eine große Zahl von ihnen überflüssig machen. Baupläne sollten den gesamten Informationsgewinnungsprozesse dokumentieren um schnell an den entscheidenden Stellen eingreifen zu können. In dem Warehouse-System nutzt man das WarehouseModell (Metadaten) um Änderungen vorzunehmen. Das Warehouse-Modell entsteht bei dem Oracle Warehouse durch den Oracle Warehouse Builder. Die Komponenten des Oracle Warehouse greifen ineinander und ergänzen sich gegenseitig. Wer das System künstlich trennt z. B. in ETLKomponente, Auswerte-Komponente und Datenbank, der läuft Gefahr, den Warehouse-Prozess nicht optimal und ohne Brüche zu verwalten. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 22/300 Das Warehouse ist kein starres System, sondern ein ständiger Prozess, der immer(!) passgenaue Information zu dem Fachanwender liefert! Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 23/300 3. Erstellung eines Data Marts – Ein BeispielSzenario Ableitung eines Auswertemodells aus Quellstrukturen Ein Warehouse-System entsteht nicht auf Zuruf, sondern mit Methoden. Sie arbeiten dabei mit Hilfe von Modellen, die Sie schrittweise nacheinander ableiten. Folgende Modelle spielen eine Rolle: Modell Zweck Quelldatenmodell Befragungsergebnisse Geschäftsprozessmodelle Analysemodell Stellen die Ausgangssituation dar. Sie sind Quellmaterialien und bestimmen die ersten Schritte. Objektmodell Auswerte- oder Abfragemodell (Starschema) Mappingmodell Workflow-Modell Beschreibt den Geschäftsprozess, den es durch Warehouse-Technik zu unterstützen gilt. Dokumentiert die Geschäftsobjekte des Geschäftsprozesses und legt Rahmenbedingungen und Eigenschaften der Geschäftsobjekte offen. Spiegelt die Abfragebedürfnisse wider und definiert die Struktur der Warehouse-Datenbank. Dokumentiert die Zuordnung von Quell- und Zielsystem. Herleitungen und Wandlungen. Hinweise auf Extraktionstechniken. Regelt die Ablauflogik der einzelnen Komponenten des Mapping-Modells. Globale Ablauflogik des Bewirtschaftungsprozesses des Warehouses. Hilfsmittel, Werkzeug OWB, + Papier (UML) Papier (UML) OWB OWB OWB Anhand eines praktisches Beispiels können Sie am leichtesten den Zweck und die Funktionsweise eines Systems erkennen. Die vorliegende step-by-step-Anleitung liefert Ihnen dieses Beispiel. Es ist überschaubar und klein gehalten. Es nutzt jedoch viele Anforderungen aus der Praxis und behandelt einen großen Teil der in der Datenmodellierung vorkommenden Entity Relationship-Konstruktionen, wie Parent/Child - und n:m - Beziehungen. Die Eingrenzung auf einen zusammenhängenden Geschäftsprozess entspricht einem Data Mart, also einem kleinen Warehouse-Ausschnitt. Beispieldaten sind Bestellungen, Artikel und Kunden, also Bewegungs- und Stammdaten. Diese sog. Quelltabellen stellen die Ausgangsdaten des Szenarios dar. Die step-by-step-Anleitung führt Sie durch das Laden dieser Quelldaten in das Data Warehouse, zeigt Ihnen, wie Sie die Quelldaten umwandeln und in ein Starschema importieren. Nebenbei erstellen Sie die Struktur des Warehouses, Zwischentabellen und definieren das Starschema. Das Ergebnis ist ein mit Daten gefülltes Starschema. Die Speicherung wird über mehrere Techniken in der Oracle9i Datenbank optimiert. Im letzten Schritt können Sie die neue Struktur mit dem Oracle Discoverer auswerten bzw. mit Oracle Reports Standard-Berichte erzeugen. Das Quelldatenmodell Ein Beispielunternehmen nutzt folgendes Datenmodell um die Bestellungen von Artikel durch Kunden zu dokumentieren. Eine Bestellung gliedert sich in sogenannte Kopfdaten (Tabelle Bestellung) und Positionsdaten (Best_Position). Neben einem Bestelldatum ist auch ein Lieferdatum pro Bestellung erfasst. Zu den Kunden gehören neben Privatkunden auch Firmenkunden. Diese Kundenart kann dem Feld Status entnommen werden. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 24/300 Das Datenmodell der Beispieldaten (Quellsystem) Das Analysemodell Der Geschäftsprozess, der hinter diesem Datenmodell steht, ist sehr einfach: Kunden kaufen Artikel und Artikel werden geliefert. Über eine Geschäftsprozessanalyse entsteht eine Liste von Geschäftsobjekten (in diesem Beispiel 2) die zueinander in eine Art „Interaktion“ treten. Das Analysemodell des analysierten Geschäftsprozesses zu dem Beispielszenario Das Objektmodell Dennoch birgt dieser einfache Geschäftsprozess viele Details, die über entsprechende Fragestellungen ermittelbar sind. Das Objektmodell hilft diese Fragen zu finden. Bei näherer Betrachtung des Geschäftsprozesses sieht das Objektmodell wie folgt aus: Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 25/300 Das Objektmodell des Beispielprozesses für das Szenarios Über dieses Objektmodell erkennen Sie Kontextinformationen zu den Geschäftsobjekten. Eine wichtige Information sind mögliche Hierarchisierungen: o Ein Kunde „spezialisiert“ sich in einen Firmenkunden und einen Privatkunden. o Artikel lassen sich in Gruppen und diese in Sparten zusammenfassen. o Zwischen Bestellungen und Artikel ist offensichtlich noch eine besondere Auflösung oder Detaillierung nötig (Intersection-Information bzw. eine Zwischentabelle, das sind die Bestellpositionen). o Es kann unterschieden werden zwischen Bewegungsdaten (Bestellung) und mehr festeren Daten (in diesem Fall die Stammdaten Artikel und Kunde). Die letzten beiden Punkte stellen Indizien für Faktentabelleninformationen dar, die ersten beiden sind sicher Kandidaten für Dimensionen. Mögliche Fragestellungen Aus dem Objektmodell heraus sind Fragen formulierbar. Diese Fragen können bzw. sollten sich sogar mit den tatsächlichen Informationsbedürfnissen der Fachabteilung decken aus deren Einsatzbereich der Geschäftsprozess entstammt. Natürlich ist diese Fachabteilung vor Projektbeginn genau zu befragen. Das oben dargestellte Datenmodell des operativen Systems und Befragungsergebnisse aus der Fachabteilung sowie weitere Techniken gehören zu den Mitteln, mit denen man das Analyse- und Objektmodell erstellt. Wie ist das Verhältnis von Privat- zu Firmenkunden? Entspricht dieses Mengen-Verhältnis dem Umsatzverhältnis? Spielen Kundeneigenschaften wie Berufsgruppe, Wohnsituation, Bildung usw. bei dem Umsatz eine Rolle? Was sind die Kunden mit den höchsten Umsätzen? Wie ist der zeitliche Verlauf der Umsatzentwicklung? Gibt es hierbei Verschiebungen bezogen auf die Kundeneigenschaften? Können zusätzliche Kundensegmente gebildet werden, wenn z. B. Kundeneigenschaften zusammengefasst werden? Gibt es regionale Schwerpunkte bezogen auf Kundenmerkmale? Gibt es regionale Schwerpunkte bezogen auf Artikel/Artikelgruppen? Gibt es Zusammenhänge zwischen Kundenmerkmalen und Artikel? Was sind die umsatzstärksten Artikel? Renner/Pennerlisten? Gibt es saisonale Einflüssen auf die Umsatzentwicklung in Abhängigkeit von Artikel oder Kundeneigenschaften? Das Abfrageschema modellieren (Starschema) – Abfragemodell Jetzt lässt sich nach dieser Vorarbeit ein Starschema entwerfen. Denormalisieren (Star und nicht Snowflake) Eine erste Empfehlung ist das Starschema möglichst eng zu halten, also alle Dimensionsdaten in eine Tabelle zusammenzufassen: zu denormalisieren. (Ein Starschema im Gegensatz zu einem normalisiert aufgebauten Snowflake-Schema). Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 26/300 Zwei Gründe sprechen dafür: 1. Übersichtlichkeit für die Endanwender 2. Viele performance-optimierende Techniken in der Oracle-Datenbank sind genau auf diese Modellform abgestimmt Das bedeutet, dass alle Spezialisierungen von Kunde (Privat und Firma) in einer Tabelle zusammengefasst sind. Auch Artikel, Artikelgruppe und Artikelsparte sind zusammenzufassen. Was in dem operativen Modell in drei Tabellen mit 1:n Beziehungen aufgegliedert war, ist in der neuen Artikeldimension in einer Tabelle zusammengefasst. Zu jedem Artikel sind die zugehörige Gruppe und die Sparte verzeichnet. Es entstehen Hierarchien innerhalb der Tabelle (Denormalisierung). Informationsanreicherung Abfragen nach dem zeitlichen Verlauf oder der Umsatzentwicklung bzw. saisonale Einflüsse fordern nach einer zusätzlichen „Zeitmeßlatte“, einer Zeitdimension. Die Zeitdimension in diesem Modell ist vollständig neu. In einem operativen System werden Sie eine solche Tabelle nicht finden. Lediglich Bestell- und Lieferdatum kommen aus den Bewegungsdaten - der Bestellungs-Tabelle. Die Zeitdimension ähnelt einem Kalender. Ein Kalender ist hierarchisch aufgebaut und kann zusätzliche Betrachtungsweisen haben: Tag > Monat > Quartal > Jahr Tag > Woche > Jahr Tag > Quartal > Geschäftsjahr Tag > Jahreshälfte > Jahr Auch dies sind denormalisiert in einer Tabelle abgelegte Hierarchien: Zu jedem Tag ist der passende Monat, das Quartal und das Jahr gespeichert. Die Zeitdimension ist ein gutes Beispiel für mögliche parallele Hierarchien. Die Reihenfolge Tag > Monat > Quartal > Jahr ist nicht symmetrisch mit der Reihenfolge Tag > Woche > Jahr, da nicht immer die gleiche Anzahl Wochen in einen Monat passt. Auch die Zuordnung Geschäftsjahr und Kalenderjahr ist nicht deckungsgleich: ein bestimmter Tag kann in das Kalenderjahr 2002 aber auch in das Geschäftsjahr 2003 fallen. In diesem Fall redet man von parallelen Hierarchien. Das Zielschema des Szenarios (Starschema) Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 27/300 Eine weitere Form der Informationsbereicherung stellen Beschreibungstexte dar z. B. die Beschreibungstexte in der Kundendimension. In operativen Systemen ist oft ein Codewert hinterlegt. Im Starschema ergänzt man solche Codewerte um sprechende Texte (Branche / Branche_Text). Auch die Regionen-Tabelle ist neu. Abfragen nach regionalen Schwerpunkten sind oft nur lösbar, indem man (ähnlich der Zeitdimension) eine Art Regionen-Landkarte im Starschema zusätzlich aufbaut. Die Tatsache dass ein Kunde in Buxtehude wohnt besagt noch nichts. Erst die Zuordnung zu einem Landkreis oder sogar Vertriebsgebiet lässt Rückschlüsse zu. Denn solchen globaleren Einheiten können Sie eindeutigere Eigenschaften zuordnen z. B. Herr Meier ist Vertriebsleiter in Vertriebsgebiet Region Nord und dort liegt Buxtehude. Einzelne Werte sind berechnet wie z. B. „Umsatz“. Dies ist nicht der Umsatz pro Bestellung, sonder der Umsatz pro Artikel pro Bestellposition. Granularität Die Granularität der Sätze in der Faktentabelle liegt auf dem Level der Bestellpositionen. Die Bestellungen selbst sind nicht mehr wieder zu finden. Deswegen muss auch das Feld Umsatz bezogen auf die Positionen neu berechnet werden. In der Faktentabelle werden meist nur zählbare Objekte dargestellt, wobei man Abstufungen vorfindet. In dem Beispiel ist der Einzelpreis anders zu behandeln als der Umsatz. Der Umsatz ist bereits das Ergebnis einer Berechnung aus Preis mal Menge. Die Summe aller Umsätze pro Artikel pro Tag ergibt folglich ein anderes Ergebnis als die Summe aller Einzelpreise pro Artikel pro Tag. Das Mappingmodell Nachdem das Starschema bzw. Auswertemodell bekannt ist, kann die Suche nach den Quellstrukturen beginnen. Mit dem Mappingmodell befinden Sie sich schon mitten in der Planung für den kommenden ETL-Prozess. Die folgende Tabelle stellt eine Art Arbeitsblatt dar. Zunächst listet man unter Zieltabelle / Objekt alle Zieltabellen auf, in unserem Beispielfall sind das die Tabellen des Starschemas. Dann sucht man sich die nötigen Quellstrukturen und findet damit auch schon die Art des technischen Zugriffs. Schließlich legt man die Wandlungsregeln fest. Wenn Sie schon auf der Suche nach Quelldaten sind, entdecken Sie meist auch Datenmengen und Lade-/Updatezyklen. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step Quellsystem Extraktionsart / 28/300 Objekt/ Tabelle/ Feld (Mussfelder) Kunde OrtNr KDNr Regel Jeweils nur Schlüsselfeld und Textfeld Lookup auf (siehe rechts) Nein, es werden die Codes aus den Textdateien übernommen Textfiles : Orte D:\Szenario\testdaten Bestelldatenbank Oracle Schema SRC; Dblink (Stammdaten) - Alle Felder 1:1 Nein Artikel Artikelgruppe Artikelsparte Join über alle Tabellen Nein, es werden die Stammdatennummern übernommen - Prozedur Create_T age Bestelldatenbank Oracle Schema SRC; Dblink (Stammdaten) Bestellung Best_Position Join Bestelldatenbank Oracle Schema SRC; Dblink (Stammdaten) Textfiles : Branche, Berufsgruppe Ausbildung, Gehaltsgruppe Wohnart D:\Szenario\testdaten Stand/letzte Änderung 13.05.2016 Umschlüsselung Zwischen schritt Historisierung Verfahren Zieltabelle Objekt 1:1 Nein - Späteres WarehouseInkrement Dimension Kunde Es wird kein weiterer Schlüssel gebraucht (in Arbeit) Tabellen: Branche Berufsgruppe Ausbildung Gehaltsgruppe Gehaltsgruppe Wohnart Als Referenztabelle in der Warehouse- Schicht - „ Nein / Menge / Anzahl Zeilen Ladezyklus und Aktion Ca 1500 Initial + Jeweils Nur 10 – 20 Sätze Täglich Insert/ Update Initial Dimension Region Dimension Artikel 16000 Initial 300 Initial - Späteres WarehouseInkrement Tabelle Tage als Kalenderreferenztabelle Im Warehouse Nein Dimension Zeit 4000 (10 Jahre) Initial WH_Transaktionen Nein Fakten Umsatz 25000 Initial/ Täglich Insert 75875104 Oracle Warehouse step-by-step 29/300 Workflow-Modell Das Workflow-Modell ist das letzte Modell. Hier befinden Sie sich schon fast im Betrieb des Systems. Wie in einem Projektplan tragen Sie die einzelnen Transformationsroutinen (Mappings) in eine zeitliche Kette. Alle Abhängigkeiten serialisieren Sie. Parallelläufigkeiten schreiben Sie unter einander. Checkpunkte und Prüfbedingungen legen den Prozessfortschritt fest. Solche Modelle lassen sich am grünen Tisch oft nicht bis in letzter Konsequenz erstellen. Sie sind jedoch ein guter Startpunkt. Der Warehouse Builder bietet für diese Modellart einen optisch ansprechenden Process-Editor. b Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 30/300 4. Die Komponenten des Oracle WarehouseKurzübersicht Die Oracle Datenbank 10g hat sich seit dem Release 7 zur idealen Warehouse-Plattform entwickelt. Begreifen wir das Warehouse als dynamisches System mit der Notwendigkeit zur Integration vieler Komponenten, dann unterstützt Oracle 9i mit den vielen integrierten Funktionen diese Anforderung: Die Datenbank besitzt eine eigene ETL-Infrastruktur, die das Laden und Bewegen der Daten innerhalb der Datenbank sehr komfortabel macht. Externe Ladeprogramme sind nicht nötig. Die Datenbank besitzt einen eigenen Workflow-Mechanismus um den Warehouse-Prozess zu automatisieren. Komplexe Auswertungen werden durch analytische und statistische Funktionen direkt in der Datenbank unterstützt. Mining ist bei 10g innerhalb der Datenbank möglich. Messaging ist integriert um operative Daten auch über Messagingverfahren ins Warehouse zu laden. Die OLAP-Option ermöglichen komplexe Analysen wie Forecasting, Budgetierungen. Warehouse Metadaten sind in die Datenbank als neutraler Baustein mit aufgenommen. Die Partitioning Option der Datenbank, Bitmap-Indizierung und Materialized Views unterstützen die Abfrageperformance. Mit dem Oracle Warehouse Builder (OWB) erstellen Sie ein vollständiges Warehouse–System und organisieren auch den Betrieb des Systems. Im einzelnen übernimmt OWB: 1. Aufbau des Tabellenwerkes des Warehouses (Create Table/Index/Dimension/Function/Packages usw.) 2. Bereitstellen der Transformationslogik und Routinen von den Quelldaten aus den operativen Systemen bis in das Ziel-Data Warehouse hinein (PL/SQL-Routinen). 3. Zugriffslogik auf Quellsysteme (Flat File, ODBC, Gateway). 4. Bereitstellen der Metadaten zur Dokumentation und Beschreibung des Warehouse Systems. Oracle hat die Abstimmung und Integration der Werkzeuge in den letzten Jahren zunehmend ausgebaut und verstärkt. Strategisch orientiert sich Oracle an dem CWM-Standard der OMG (Common Warehouse Metamodel). Durch das Modellieren des Systems mit dem Oracle Warehouse Builder entstehen Metadaten während Sie das System aufbauen automatisch. Graphisch sind die Metadaten über eine Weboberfläche allen Warehouse-Benutzern zugänglich. Oracle Workflow übernimmt die Steuerung der Lade- und Berichtsgenerierung. Der Enterprise Manager erlaubt Ressourcen Management des gesamten Warehouses. Auch das Kontrollieren des WarehouseBetriebs ist über das Web möglich. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 31/300 5. Aufbau des Data Warehouse-Systems mit dem Oracle Warehouse Builder (OWB) Data Warehouse Systeme werden im Regelfall auf der Basis von relationalen Datenbanken aufgebaut. Oracle ist dabei das meistgenutzte Datenbanksystem. Daher ist es nur begrüßenswert, dass mit dem Warehouse Builder ein Werkzeug vorliegt, das genau diese Rahmenbedingungen adressiert: Alle benötigten Komponenten arbeiten innerhalb der Datenbank. Es wird nur mit Datenbankmitteln gearbeitet (Tabellen, PL/SQL, Indexdefinitionen, Materialized Views usw.) Es sind also keine zusätzlichen Sprachmittel oder Programme außerhalb der Datenbank nötig. Mit dem Warehouse Builder werden neue Potentiale frei gegeben: Er erlaubt das Erstellen von PL/SQL-Programm-Code mit graphischen Mitteln und unter Verwendung graphisch angezeigter Metadaten. Diese Vorgehensweise schafft größere Produktivität bei den Projektmitarbeitern und führt schneller zu Ergebnissen. Die Übersichtlichkeit der Ergebnisse minimiert den Wartungsaufwand. Der Oracle Warehouse Builder ist auf allen Ebenen des Warehouse Systems einsetzbar, er kann aus Quellsystemen extrahieren, er kann Daten prüfen und validieren und sie in beliebigen WarehouseArchitekturen speichern. Warehouse Life Cycle Management mit WAREHOUSE BUILDER Warehouse Systeme erstellt man heute inkrementell. Die Projekte bearbeiten nacheinander Teilbereich für Teilbereich des Unternehmens. Für jedes Inkrement durchläuft ein Projekt dabei mehrere Phasen: Analyse des Informationsbedarfs Entwurf/Definition der Warehouse-Struktur (Datenmodelle und Tabellen) Erstellen der Ladeläufe zum Befüllen des Warehouses Dokumentation des Gesamtsystems (Metadatenkatalog) (Sehen sie hierzu auch die entsprechenden Vorgehensmodelle für die inkrementelle Warehouse Entwicklung). Danach startet der Echtbetrieb des Warehouse-Inkrements und der Wartungsfall beginnt, Änderungen stellen sich ein und führen zu neuen Versionen. Alle diese Aktivitäten unterstützen der Warehouse Builder. Warehouse Life Cycle Management Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 32/300 Aus welchen Objekten besteht ein Oracle Warehouse Ist das Data Warehouse erstellt so besteht es in der Regel aus folgenden physischen DatenbankObjekten: Tabellen, Indexdefinitionen sowie Zuordnung zu Tablespaces mit physischen Parametern Views und Materialized Views Dimensionstabellen Funktionen und Prozeduren (PL/SQL) DB-Links Sequences Loader-Scripte External Tables Queues TCL-Scripte für den Enterprise-Manager Oracle Workflow Steuerroutinen .... Vorgehensweise bei dem Aufbau eines Warehouse Systems mit dem Warehouse Builder An dieser Stelle schon mal voraus blickend eine Liste mit typische Entwicklungsschritten: (Schritte 1-3 ohne Warehouse Builder) 1. Analyse der Benutzeranforderungen (Welche Auswertungen benötigt der Fachanwender?) 2. Analyse der Quellsysteme (Wo sind die benötigten Daten?) Bereitstellen des Datenmodelle der Quellsysteme. 3. Architektur des Warehouses (Es gilt ein System aufzubauen, das einerseits flexible für immer wieder neue Anforderungen ist, skalierbar für Mengen ist aber auch berichtsübergreifende Stimmigkeit der Informationen garantiert - siehe die oben genannten Beispielarchitektur) 4. Abbilden der Wunscharchitektur innerhalb des OWB (Definieren der sog. Module, s. u.). 5. Nachdokumentation der Quelldatenstruktur (DB-Kataloge, Flat File Struktur) mit dem OWB (Import Metadaten). 6. Definition und Aufbau der Zielschemen für Stage/Warehouse (3NF-Modelle)/Data Mart(Star Schema) je nach Konzept. Die Modelle können natürlich auch alternativ mit Modellierungswerkzeugen entworfen werden. (Siehe hierzu weiter unten "Exkurs: Woher kommen oder wie entstehen die Warehouse-Tabellen"). 7. Generieren und Anwenden der DDL des Warehouses über den Deployment Manager. 8. Erstellen der sog. Transformationsmappings über die Mapping-Editoren. Bei dem Aufbau des gesamten Warehouses werden mehrere Mappings entstehen, weil man das Befüllen aller Tabellen des gesamten Warehouse Systems in mehrere Schritte untergliedert. 9. Generieren und Anwenden der Transformationsroutinen (PL/SQL) mit dem Deployment Manager. Bei diesem Schritte werden die einzelnen Mappings über Testdatenläufe getestet. 10. Zusammenfassen der einzelnen Mappings zu einem kompletten Ladeszenario. Hierzu erstellen Sie einen Workflow mit dem Process-Editor. 11. Festlegen des Scheduling. 12. Versorgen von entsprechenden Auswertewerkzeugen mit Metadaten. Allgemeine Vorgehensweise im Verlauf eines Lade-Prozesses (ETL) Im Verlauf eines Projektes sind bei der technischen Realisierung des Ladeprozesses immer wieder ähnliche Schrittfolgen durchzuführen. Diese sind hier zusammengefasst: 1. Entgegennehmen der Quelldaten: Der Extraktvorgang hinterlässt Quelldaten in dem Eingangsbereich des Data Warehouses (z. B. Stage). 2. Prüfungen auf Vollständigkeit und Richtigkeit der Quelldaten. a. Anzahl Sätze Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 3. 4. 5. 6. 7. 33/300 b. Gültige Wertebereiche c. Vorhandensein von Referenzdaten d. Eventuell Eindeutigkeit e. ... Import und Prüfen der Dimensionsdaten a. Update / Insert / Merge b. Eventuell Historisierung / Slowly Changing Dimensions Prüfung der Bewegungsdaten auf Stimmigkeit mit den Dimensionsdaten a. Anti–Join-Prüfung b. Event. Fehlertabelle erstellen (zur Nachbearbeitung) Aufheben der Constraints der Faktentabelle a. Eventuelles Löschen von Indexeinträgen b. Eventuelles Aufheben der Fast Refresh Fähigkeit der Materialized Views Überführung Bewegungsdaten in die Faktentabellen a. Join mit Dimensionen Nacharbeiten a. Aktivierung der Constraints b. Event. Aktualisierung der Indexe c. Event. Refresh Materialized Views d. In Stage-Tabellen diejenigen Sätze entfernen, die geladen wurden. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 34/300 Einrichten der OWB Entwicklungsumgebung Zusammenspiel mit anderen Komponenten Hier sind alle Komponenten aufgelistet, mit denen der Warehouse Builder zusammenarbeitet: Sie beginnen mit der Installation des Oracle Warehouse Builder 10g (Teil von Oracle 10g oder als separate Software, die Sie als Download von Oracle-OTN im Web erhalten www.oracle.com/otn). Dann können Sie bereits loslegen. Zum Workflow-gesteuerten Ablauf können Sie den Workflow-Server nachträglich installieren. Oracle Workflow ist eine OracleDatenbank-Komponente, die Sie mit der Datenbank erhalten. Achten Sie auf die Zertifizierungen, also welche Workflow-Version mit welcher Datenbank-Version zusammen arbeitet. Zusätzlich gibt es: SQL Loader (optional): Lädt Flat File direkt in die Datenbank (wird seit Oracle 9i durch "External Tables" ersetzt/ergänzt) Gateways (optional): Zu allen gängigen Datenbanken (DB2, SQL Server, Sybase, Informix...) gibt es sog. Gateways. Diese können über DB-Links mit den Datenbank-Routinen kommunizieren. Workflow: Regelt die logische Abfolge der durch den Warehouse Builder erzeugten Mappings. Innerhalb des WAREHOUSE BUILDER gibt es einen Process-Editor, mit dem Sie einen Workflow erstellen. Der Workflow läuft dann auf dem Workflow-Server, den Sie bereits mit der Oracle 9i /10g Datenbank installiert haben. Runtime Audit Browser: (Bestandteil des Repository-Browsers). Zur Kontrolle von stattgefundenen Ladeläufen. Das ist ein Teil des Warehouse Builders, den man über eine Web Browser aufrufen kann. Hierzu ist keine Installation notwendig. Der Aufruf erfolgt über das Startmenü des Clients nachdem der OWB Browser Listener zuvor gestartet wurde. Repository Browser: (Bestandteil des Repository-Browsers). Dient der Darstellung von Metadaten im Web. Auch das ist ein Teil des Warehouse Builders, den man über eine Web Browser aufrufen kann. Hierzu ist keine Installation notwendig. Der Aufruf erfolgt über das Startmenü des Clients nachdem der OWB Browser Listener zuvor gestartet wurde. External Table Technik: Technisches Verfahren in der Datenbank seit dem Release Oracle 9.2 Steams Verfahren: Message-basiertes Verfahren der Oracle Datenbank seit dem Release Oracle 9.2 CDC (Change Data Capture): Message-basiertes Verfahren der Oracle Datenbank zum Auslesen von Oracle-Log-Files seit dem Release Oracle 9.2. Besonders hilfreich bei der Deltadatenerkennung. DataPump: Schnelles Ladeverfahren mit Hilfe von Export/Import (ab Oracle 10g) SAP Integrator: Bestandteil des Oracle Warehouse Builder für den SAP R/3 Zugriff über das SAP R/3-Dictionary. Peoplesoft Connector: Bestandteil des Oracle Warehouse Builder für den Peoplesoft-Zugriff eBusiness-Suite Connector: Bestandteil des Oracle Warehouse Builder für den PeoplesoftZugriff ODBC: Zugriff auf relationale Quellen außerhalb der Oracle Datenbank über einen ODBC-Treiber XML-DB: Funktionalität der Oracle Datenbank seit dem Release Oracle 9.2 zum leichten Bearbeiten von XML-Daten. Wird aus dem Oracle Warehouse Builder heraus angesteuert. UTL_File: Technisches Verfahren in der Datenbank zu Beschreiben und Erstellen von Textfiles Adapter für Anwendungen wie Peoplesoft, SAP etc: Adapter zum transaktions-basierten Kommunizieren mit Anwendungen. Oracle Data Profiler: Software-gestütztes Analysieren von Datenfehlern (Bestandteil des Oracle Warehouse Builder) (und viele andere Komponenten, die hier nicht erwähnt werden können) Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 35/300 Einige Warehouse Builder Komponenten (Übersicht) Erstellen von Transformationsmappings Erkennen von Strukturabhängigkeiten mit Hilfe von Metadaten Anzeigen von Tabelleninhalten Aufbau von Datenflüssen Starten von Prozessen Automatisieren von ETL-Vorgängen Erkennen von Datenqualitätsproblemen Erstellen von Datenstrukturen Steuern von Definieren von Deployments von Metadaten-Browser Qualitätsregeln Objekten Einige Editoren des Warehouse Builder zur Durchführung verschiedener Aufgabenstellungen Versionieren Komponentenübersicht des Gesamtsystems inkl. Datenbank-Komponenten Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 36/300 Wo ist die Dokumentation zu OWB 10g zu finden? Auf der Installations-CD befindet sich das Unterverzeichnis PDFDOC. Dort sind die PDF-Dateien: OWB10gInstall.pdf OWB10gUserGuide.pdf OWB10gScriptingReference.pdf (Manual zur Scriptsprache) OWB10gTransformationGuide.pdf (Zusammenfassende Beschreibung aller Transformationen) OWB10gDocAddendum.pdf (Wenn die Dokumentation nicht auf der CD sein sollte, kann sie immer auch von Oracle Technet (OTN) geladen werden. Systemanforderungen (Genaue Angaben in der Installationsanweisung auf der Installations-CD.) Es wird ca. 700 MB Plattenplatz benötigt. Ideal ist ein Szenario, bei dem die benötigte Datenbank auf einem separaten Server liegt. Wenn das der Fall ist, reichen 512 MB bis 1024 MB Hauptspeicher aus (angenehmer sind 1024 MB). Man bedenke, dass der Warehouse Builder eine Java Entwickler-Oberfläche besitzt, die auch auf anderen Plattformen laufen kann z. B. Sun Solaris, Linux usw. . Ausreichende Performance in der Oberflächenbedienung ist bei einem ausreichenden Hauptspeicherausbau gegeben. Ist die Oberfläche dennoch zu träge, so liegt das in der Regel an zu geringen Speicher-Parameter der Datenbank. Diese sind zu klein gewählt was oft bei Testinstallationen (und damit gewählter Standardinstallation) der Fall ist. Die Client-Software wird auf einem Standard-Windows2000 oder XP-Rechner (Pentium 2 und aufwärts) (oder SUN-Solaris) installiert. Bzgl. der Datenbank, gibt es keine besonderen Anforderungen. Im Verlauf der Installation wird ein Tablespace mit ca. 200 MB Plattenplatz für das MetadatenRepository gebraucht. Es sollte ein hochauflösender Bildschirm sein, die Größe von 17 oder 19 Zoll ist ideal. Das macht sich vor allem bei dem Arbeiten in den graphischen Mappings positiv bemerkbar. Die Installationsschritte des Warehouse Builders in der Übersicht (Weiter unten gibt es eine detaillierte Installationsbeschreibung.) Wählen Sie für den Warehouse Builder ein separates Home-Verzeichnis. Andere Oracle-Werkzeuge sollten nicht gestartet sein, um Fehlermeldungen im Verlauf der Installation zu vermeiden. Die Installation (ca. 15 - 30 Min.) besteht aus 5 Schritten die unabhängig von einander durchführbar sind. Nicht alle Schritte müssen von Beginn an durchgeführt werden: 1. Installation der Software (Setup startet automatisch nach dem Einschieben der CD). 2. Das Design (Entwicklungs-)Repository. Das wird sinnvollerweise in ein eigenes Oracle-Schema (z. B. OWB10G) gelegt. Die Installation fragt nach, ob der Benutzer neu angelegt werden soll oder ein bestehender genutzt wird. In diesem Repository sind sowohl die Design– als auch die Runtime-Metadaten gespeichert. Tip: Während der Repository-Installation werden Datenbankeinstellungen (Init.ora bzw. pfile) geprüft und Empfehlungen gegeben diese zu korrigieren. Schreiben Sie sich diese Parameter auf und ändern Sie diese, nachdem Sie die Installation insgesamt beendet haben. Wollen Sie nur üben und erste Gehversuche mit dem OWB machen, so reichen die Default-Settings aus. 3. Das Target Schema (auch Repository-User genannt): Das ist das eigentliche WarehouseSchema. D. h. dort werden die Nutzdaten des Warehouses liegen. Den Name dieses Schemas muss dem Warehouse Builder mitteilen, damit dort z. B. Daten hineingeladen werden können. Gibt es dieses Schema zum Installationszeitpunkt noch nicht, dann können Sie das Schema durch die Installationsroutine auch anlegen lassen. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 4. 5. 37/300 Workflow Installation (siehe weiter unten). Optional: Portaleintragungen für die Metadatenauswertungen. Dies ist nur nötig, wenn Metadaten mittels Web ausgewertet werden sollen. Das kann man praktischerweise in einem späteren Schritt nach installieren. Die gleichen Informationen erhält man als Entwickler über den mitgelieferten J2EE-(Java)-Container, der über die Windows-Start-Leiste aufgerufen werden kann (OWB Browser Listener). Die Schritte 2-5 können Sie später separat über das Windows-Start-Menu nachfahren. Achtung: Im Verlauf der System-Installation sollte die Java-Pool-Size in der Init.ora gesetzt sein, sonst gibt es Fehler (siehe Beispiel init.Ora-Datei im Anhang). Achtung: Im Verlauf der Installation sollten Sie keine anderen Java-Programme neu aufrufen. Das kann zu Abbrüchen und Java-Fehlern führen. Tip: Legen Sie sich zunächst einen separaten Tablespace (ca. 200 MB) für das Warehouse Builder Repository an und starten Sie danach die Installation. Das ist praktisch, wenn die Daten später wieder leichter entfernt werden sollen. Alle weiteren Schritte sind Wizard-geführt. Übersicht zu den angelegten Benutzern Hier eine Übersicht aller Benutzer (Datenbankschemen), die exemplarisch zur Durchführung des Szenarios in dieser Unterlage verwendet werden. In vielen Hard Copies dieser step-by-stepUnterlage finden Sie diese Benutzerdaten. Als Orientierung können sie hilfreich sein. Die meisten Benutzer werden im Verlauf der Installation automatisch angelegt. Funktion des Users Repository-User Target-Schema (Warehouse) User OWB10G DWH Source (Quellsysteme) SRC Workflow-Schema OWF_MGR (Default Name) Wie und wann entsteht der User Repository-Assistant Wahlweise durch Repository -Assistent (oder manuell) Ist in der Regel schon da. (Anlegen manuell siehe unten) Wird durch den Workflow Configuration Assistent angelegt. (Zuvor muss der Workflow-Server (eine Datenbank-Option) installiert sein.) Alle Schemen nach Abschluss des Dem –Szenarios. (Das Bild dient nur der Orientierung. Bitte noch nicht alle Schemen anlegen.) Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 38/300 OWB10G Das ist das Metadaten-Repository des Warehouse-Builders. Es ist auch gleichzeitig das Schema, in dem alle späteren Laufzeitergebnisse dokumentiert sind. Dieses Schema brauchen Sie also immer: Zum Entwicklungszeitpunkt und wenn Sie später das mit OWB erstellte Warehouse-System betreiben. In umfangreicheren Umgebungen kann es durchaus sein, dass es dieses Schema mehrfach geben wird, z. B. eines für Entwicklungs- und eines für Testzwecke. In unserem einfachen Szenario beginnen wir erst einmal mit einem Schema OWF_MGR Das Workflow-Schema wird benötigt, um die Workflow oder Ladeprozess-Routinen aufzunehmen. Wenn Sie nur einzelne Mappings ohne Workflow verwenden möchten, brauchten Sie das nicht. DWH Dies ist das eigentliche Data Warehouse-Schema. D. h. dort werden alle Warehouse-Daten abgelegt sein. In dieses Schema generiert OWB auch alle Lade-Routinen. Aus der Sicht des OWB-DesignSchemas ist das DWH-Schema ein Repository-User. Dieser Begriff wird im Verlauf der Installation verwendet In umfangreichen DWH-Systemen kann es hiervon mehrere geben. SRC Dieses Schema ist stellvertretend für ein beliebiges Quellschema, aus dem in dem Szenario Daten gelesen werden. Dieses wird natürlich nicht durch die Installationsroutine des OWB angelegt. Das müssen Sie mit dem Script selbst tun. Hilfsscripte zum Erstellen der Demo-User -- SRC-User (enthaellt die Quelldaten fuer das Beispiel-Szenario) CREATE USER "SRC" PROFILE "DEFAULT" IDENTIFIED BY "SRC" DEFAULT TABLESPACE "DWH" ACCOUNT UNLOCK; GRANT "CONNECT" TO "SRC" WITH ADMIN OPTION; GRANT "DBA" TO "SRC" WITH ADMIN OPTION; --- DWH-User (das ist das eigentliche Warehouse-Schema) CREATE USER "DWH" PROFILE "DEFAULT" IDENTIFIED BY "DWH" DEFAULT TABLESPACE "DWH" ACCOUNT UNLOCK; GRANT "CONNECT" TO "DWH" WITH ADMIN OPTION; GRANT "DBA" TO "DWH" WITH ADMIN OPTION; -Achtung: wenn das folgende nicht beachtet wird, kann es später im Verlauf des Deployments der Laderoutinen zu Fehlern kommen. -- Wenn SRC das Quellschema ist, dann sollten andere User darauf -- zugreifen können Connect SRC/SRC@ora92; Grant select any table to public; Einlesen der Demodaten (ausgelieferte Dump-Datei) für die step-by-step-Einführung Die Beispieldaten für diese step-by-step-Einführung sollten in ein Datenbank-Schema mit dem Namen SRC (für Source) geladen werden. Diese Daten sind mit denen eines Quellsystems vergleichbar. Sie erstellen in dieser step-by-step-Einführung Laderoutinen und Transformationen zur Überführung der Daten des SRC-Schemas in ein Ziel-Datenbankschema, z. B. mit dem Namen DWH. Erstellen Sie z. B. mit dem Enterprise Manager einen Tablespace SRC (20 MB). Erstellen Sie einen Benutzer SRC mit DBA-Rechten. Importieren Sie dann, wie unten stehend, die Testdaten: Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 39/300 IMP (Kommando auf der DOS-Ebene) Benutzer : SRC/SRC / das ist Quellschema EXPDAT.DMP : SRC_DATEN (Bestätigen Sie jetzt alle vorgegebenen Defaults bis auf) Benutzer: SRC (Und dann wieder alle weiteren Eingaben bestätigen) Ihr neuer Benutzer für das Es müssten geladen werden: (src_daten.dmp: Schemaname SRC, DBA-Rechte) Bestellung (~5000) Best_Position (~20000) Artikel (~65) Artikelgruppe (5) Artikelsparte (3) Tage (4018) Kunde (~1950) Orte (12834) Kreise (646) (Die Ortetabelle wird zusätzlich als Textdatei geladen, hierfür sollte eine CSV-Datei bei den Beispieldaten vorhanden sein) Wiederholen Sie den Ladevorgang für das Schema DWH und dem Datenbestand DWH_Daten. Die Daten sind optional. Sie werden für die Übungen nicht benötigt. Damit laden Sie: (dwh_daten_nur_Referenztabellen.DMP) Bildung (10) Berufsgruppe (10) Branche (10) Einkommensgruppe (7) Kundenart (10) Wohnart (17) Es gibt weitere Hilfstabellen in Form eines Datenbank–Dumps: Regionen (12834) (Wird beim Aufbau des Starschemas gebraucht.) WH_TRANSAKTIONEN (46035) (Kann verwendet werden, wenn ein Zwischenstand nicht erstellt wurde, um eine Faktentabelle zu befüllen). Es steht auch das fertige Star-Schema-Ergebnis zur Verfügung (Star.DMP), wenn Sie das step-bystep-Szenario nicht selbst aufbauen und stattdessen direkt das Ergebnis laden wollen. Hier sind enthalten: (Star.DMP: Schemaname DWH, DBA-Rechte) DIM_ZEIT (5352) DIM_REGION (12834) DIM_KUNDE (1946) DIM_ARTIKEL (65) F_UMSATZ (16627) WH_TRANSAKTIONEN (46035) Bei der Installation der Datenbank Oracle 10g kann auch ein Beispiel-Starschema (Schemaname SH) mitinstalliert werden. Diese englisch-sprachigen Daten können Sie natürlich auch nutzen. Allerdings müssten Sie dann die Beispiele übertragen und Sie haben keine Quelldaten. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 40/300 Unterschiedliche Repository-Benutzer einrichten Mit dem Warehouse Builder können unterschiedliche Benutzer gleichzeitig arbeiten. Den einzelnen Benutzern sind unterschiedliche Rechte zuweisbar. Es kann dafür gesorgt werden, dass einzelne Benutzer z. B. nicht in die Datenbank generieren oder keine Delete–Operation durchführen dürfen. Für diese Aktivität gab es in früheren OWB-Release Skripte. Ab OWB 10GR2 wird es über die Oberfläche durchgeführt. Siehe User Guide. Wenn Sie sich nur einarbeiten wollen reicht der Benutzer, der durch die Installation entsteht. Die Installationsschritte des OWB im Einzelnen Diese kurze Installationsanleitung beschreibt das Verfahren auf einem Windows-Standalone-Rechner. Die Anleitung ersetzt nicht die offizielle Dokumentation. Sie soll helfen möglichst schnell eine OWBInstallation zu Testzwecken einzurichten. Eine ausführliche Installationsanweisung ist in der SoftwareDokumentation enthalten. Voraussetzungen zur Installation: Windows-Client (Windows 2000 oder XP), 1 GB Hauptspeicher (Es reichen sicherlich auch 512 MB, wenn die Datenbank nicht auf demselben Rechner installiert ist. Aber das wird in der Bedienung deutlich langsamer und kann unangenehme Wartezeiten verursachen), ca. 700 MB Plattenplatz für die Software, Zugang zu einer Oracle-Datenbank ab 9.2 und höher, also auch Oracle 10GR1 und R2. Schalten Sie vor der Installation die Sprache Ihres Rechners auf Englisch. Das ist lediglich eine Vorsichtsmaßnahme. Wenn Sie die Einstellungen auf Deutsch belassen und die Erstellung des Repositories später abbricht, dann kann hier die Ursache liegen. Danach können Sie den Rechner wieder auf Deutsch zurückschalten. Umschalten der Sprache vor der Installation: -> Startmenü -> Settings -> Control Panel – Regional Options Die Datenbank für die Installation vorbereiten Treten im Verlauf der Installation Warnfenster auf, die Sie auffordern Datenbankparameter zu ändern, ignorieren Sie diese. Für Testzwecke brauchen Sie keine Änderungen an der Datenbank vorzunehmen. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 41/300 Die Installation besteht aus 2 Schritten: - Software Installieren: Setup auf der CD aufrufen - Repository und Target-Schema einrichten: Mit dem Repository Assistenten Beide Schritte können getrennt voneinander durchgeführt werden. Ist Schritt 1 erfolgt, kann Schritt 2 beliebig oft wiederholt oder auch rückgängig gemacht werden. Installationsschritte (Übersicht) Schritt 1: Software installieren: Der Installer startet entweder über autorun von selbst, oder Sie rufen die SETUP.EXE–Routine direkt auf. Software-Verzeichnis Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 42/300 Schritt 2: Repository Assistant Nach der Softwareinstallation befinden sich unter dem Start-Menü des Windows-Rechners die OWBKomponenten Hier ist der Repository-Assistant zu starten. Next Wählen Sie hier Advanced Setup. Advanced“ hört sich zwar „kompliziert“ an, ist es aber nicht. Hier erhalten Sie die beste Übersicht darüber, was Sie konkret tun. Next Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 43/300 Zum Installieren brauchen Sie die Systemadministratorberechtigung (SYS) zu der Datenbank, in der Sie den OWB installieren wollen. NEXT Wählen Sie die Option „Manage a Warehouse Builder Repository Owner“. Repository Owner ist das Repository Datenbankschema selbst. Der Repository User (die zweite Option) wird später das Zielschema oder Data Warehouse-Schema werden, in das der Warehouse Builder hineinschreibt. Next Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 44/300 Lassen Sie die Installationsroutine das Schema anlegen, in dem das Repository installiert werden soll. Wählen Sie „Create a new Warehouse Builder Repository Owner“ Vergeben Sie den Schemanamen für das OWB-Repository. Das wird später das Schema sein, unter dem Sie sich mit dem Warehouse-Builder Login anmelden (sofern nicht mehrere Entwickler eingerichtet werden sollen). Next Bestätigen Sie das Passwort. OK Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 45/300 Wählen Sie die vorbereiteten Tablespaces für Repository und Index aus. Zu Testzwecken können Sie auch die Defaults (z. B. USERS) beibehalten. Next Als Base Language wählen Sie AMERICAN ENGLISH. Lassen Sie Display Languages leer, also unberührt. Next Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 46/300 Jetzt werden Sie nach dem Target User (Ziel-Schema), bzw. Warehouse Builder Repository User, gefragt. Dieser Begriff ist etwas verwirrend, meint aber den Namen des Target- oder WarehouseSchemas in das später Daten hineingeladen werden sollen. Haben Sie noch kein Ziel-Schema, so lassen Sie den Assistenten für Sie ein Schema anlegen, also Create New DB User. NEXT Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 47/300 (°°°°)Hier heißt das Zielschema DWH_NEU (das Szenario in dieser Unterlage verwendet DWH) Next Zur Kontrolle erhalten Sie alle Eintragungen noch einmal. Bei Finish wird das Repository angelegt. Es ist sinnvoll sich dieses Fenster zu kopieren und sicher zu verwahren. Bei den vielen Schemanamen kann man sich schon mal vertun. Die Installation dauert in der Regel 5 – 10 Minuten. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 48/300 Anmeldung Starten Sie den Warehouse Builder indem Sie das Design Center über das Start Menü aufrufen. Die Anmeldung erfolgt unter der Angabe des Repository-Schema-Namens und der JDBC– spezifischen Wahl des Datenbank–Servers. Wählen Sie unter Username den Namen des vorher eingerichteten Repository Owners: Es startet das Design Center des OWB: Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 49/300 Workflow Installation Wenn Sie Workflow zusätzlich testen wollen, so ist Workflow als Datenbank-Komponente zu installieren. Sie brauchen die Workflow-Server-Komponente. Ab der Datenbankversion 10 ist diese auf der Companion-Zusatz-CD der Datenbank zu finden. Folgende Versionen passen zusammen: Datenbank 9.2 -> Workflow 2.6.2 Datenbank 10.1 -> Workflow 2.6.3 Datenbank 10.2 -> Workflow 2.6.4 Rufen Sie den Installer für die Companion-CD auf und wählen Sie den Workflow-Server aus. Nachdem der Installationssachritt abgeschlossen ist, müssen Sie noch einmal den Workflow Configuration Assistenten aufrufen. In dem folgenden Dialog geben Sie die gewünschten Workflow-Schema-Informationen an. Wählen Sie den Namen OWF_MGR für das Schema (Default). Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 50/300 Bei diesem Vorgang wird lediglich das Schema OFW_MGR in der Datenbank angelegt und bereits Prozeduren und Tabellen in das neue Schema geladen. Bei Submit sollte sich ein Fenster mit Protokollmeldungen öffnen: Hier wartet man 5 –10 Minuten. Danach ist der Vorgang abgeschlossen. Hintergrund: Was geschieht mit einem Zielschema, das über den Repository Assistenten als Repository-User gekennzeichnet wird? Es wird genau 1 Tabelle mit 1 Spalten und 1 Zeile angelegt: An dieser Stelle steht die Versionsnummer des OWB-Repositories. Hiermit kann der DeploymentVorgang prüfen, ob es eine Konsistenz zwischen dem Zielschema und dem Repository gibt. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 51/300 Und es gibt ganz viele Synonyme: Über diese Synonyme erhalten die später in dem Zielschema befindlichen Prozeduren (Packages) den Zugriff auf die verwaltenden Runtime-Tabellen des Warehouse Builder Repositories. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 52/300 Erste Schritte Die Ausgangsituation nach der Installation Wenn Sie alle vorgenannten Installationsschritte und das Laden der Testdaten durchgeführt haben, müsste Ihre Umgebung jetzt so aussehen: Ausgangssituation nach der Installation: Das Warehouse Builder-Repository ist installiert (Schema im Beispiel: OWBR2) Es gibt ein erstes – noch leeres – Default-Projekt „My_Project“. Es gibt ein Quell-System vom Typ Oracle 10g (Schema im Beispiel: SRC) mit den Beispieltabellen (z. B. Bestellung, Best_Position usw.). Es gibt ein Ziel-System vom Typ Oracle 10g (Schema im Beispiel: DWH) in dem Sie eventuell auch schon den Testdatenbestand (Berufsgruppe usw.) geladen haben. OWB starten Aufruf des OWB Client über das Start-Menu (Siehe Bild). Starten Sie den Oracle Warehouse Builder über die Option Design Center in Windows. Es erscheint ein kurzer Dialog, über den Sie sich an dem im Verlauf der Installation erstellten Repository anmelden. Tragen Sie die Zugangsdaten ein. Über Show Details werden die Maschinendaten eingegeben. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 53/300 Tip: Legen Sie sich diesen Aufruf in einen separaten Arbeitsordner. Das Suchen der Aufrufoption über das Startmenü ist ansonsten immer sehr aufwendig. Achtung: Die Anmeldung erfolgt nicht an dem Datenbankschema, in dem das Warehouse eingerichtet wird. Es ist das Repository-Schema, in das der Warehouse Builder die WarehouseModelle (Metadaten) speichert. Die Bedienoberfläche des Warehouse Builders erscheint. Wie Sie sofort sehen, ist die komplette Menu-Oberfläche in deutscher Sprache formuliert. Entsteht jetzt das Bedürfnis, das Ganze in Englisch zu sehen, so sollte jetzt sofort eine andere Spracheinstellung gewählt werden. Das ist auch schon aufgrund der hier abgedruckten, englischsprachigen Hardcopies hilfreich. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 54/300 Der erste Bildschirm nach dem Aufruf Englische Bedienerführung einschalten? Sind die Menupunkte jetzt in deutscher Sprache, so ist es sinnvoll, die Oberfläche in die englische Sprache umzuschalten. Denn viele Hilfen und Hinweise auch in dieser Unterlage sind in englischer Sprache verfasst. Unter <Werkzeuge> den Punkt Voreinstellungen wählen: Unter Locale die Sprache English_United_States auswählen. Ein Fenster erscheint mit der Frage, ob Sie OWB neu starten wollen. Bestätigen Sie das mit JA und starten Sie WAREHOUSE BUILDER auch wirklich neu. Es findet kein automatischer Restart statt. Danach sollte alles auf Englisch sein. Wenn nicht, sollten Sie die Spracheinstellungen an Ihrem PC modifizieren. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 55/300 Eine erste Übersicht Hier eine Übersicht über den ersten Bildschirm. Aktivieren Sie hierzu das zusätzliche OMB*PlusFenster über den Menüpunkt Window. Jetzt sind 4 Fenster geöffnet, die Sie natürlich nicht immer alle gleichzeitig brauchen werden. Aber sie sollten einmal erklärt werden. Zunächst einmal ist die Anordnung der Fenster wahlfrei: Sie können sie über die Kopfleiste überall positionieren. Project-Explorer Das wichtigste Fenster ist der Project-Explorer. Wie es der Name bereits sagt, wird hier die Projektarbeit stattfinden. Die übrigen Fenster stellen Hilfsfunktionen dar. Connection Explorer Hier sind die sogenannten Locations zu finden. Über Locations legt man fest, auf welchen Rechnern welche Datenbanken und Datenbankschemen zu finden sind. Locations stellen die Verbindungen zwischen den Warehouse Builder-Modellen und der tatsächlichen Physik dar. Sie können später keinen Deploy-Vorgang in eine Datenbank durchführen, ohne zuvor eine Location für diese Datenbank sauber definiert zu haben. Global Explorer Hier sind allgemeingültige (projektübergreifende) Objektdefinitionen zusammengefasst. Hier werden z. B. Benutzer und Rollen definiert. Aber auch public Funktionen und Prozeduren sind hier zu finden. OMB*Plus Dieses Fenster stellt eine Kommandozeile bereit, um OWB im Kommandomodus zu bedienen. Alle graphischen Aktivitäten über die Oberfläche können auch über die sogenannte OMB-Skriptsprache durchgeführt werden. Damit werden viele Vorgänge automatisierbar. Diese Scriptsprache ist sehr praktisch. Aber auch etwas für „höhere Semester“. Bei den ersten Schritten brauchen wir sie noch nicht. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 56/300 Der Project Explorer Der Project Explorer listet die verschiedenen Projekte auf. Projekte sind völlig selbständige Einheiten (mit Ausnahme der Objekte, die unter dem Global Explorer zu finden sind). Hier eine kurze Darstellung der Unterpunkte in jedem Projekt. Definition von Quell- und Zielstrukturen, Die Komponenten werden Module genannt. Quellen können sein Oracle-Datenbanken oder Datenbanken von anderen Herstellern, sowie Flat Files. Datenbanken anderer Hersteller werden über Gateways angeschlossen. Alle Module können sowohl lesend als auch schreibend verwendet werden. Spezielle Transportmodule für schnelles Laden Schnittstellen zu ERP-Systemen Data Quality-Komponenten, Regelbausteine und Data Profiler Wiederverwendbare Mapping-Komponenten Workflow und Prozesssteuerung Scheduling / Kalender Schnittstellen zu Oracle BI ETL Makros Konfiguration von Komponenten Locations und anderen Module ordnen das Projekt Alle Aktivitäten innerhalb des Warehouse Builders spielen sich in dem Rahmen von Modulen ab. Die Module stellen eine Art Fenster dar, durch das man einen bestimmten Ausschnitt des Quell- und des Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 57/300 Warehouse Systems betrachten kann. Sie unterteilen das Gesamtsystem auf einer logischen Ebene nach Gesichtspunkten, wie sie der Data Warehouse-Architekt festlegt. Die Module sind Repository-gesteuert. Alle Änderungen, die Sie an Objekten innerhalb eines Moduls vornehmen, überträgt der Warehouse Builder automatisch auch die anderen Module, wenn dort dieselben Objekte vorkommen. Löschen Sie eine Column in einer Tabelle KUNDE in dem Modul A, so finden Sie die geänderte Tabelle KUNDE auch in einem Modul B wieder (Refresh Button drücken). Sinnvollerweise folgt die Moduleinteilung der Architektur des Warehouse Systems. Eine klassische Architektur für ein unternehmensweites Warehouse sieht also wie folgt aus: Es gibt ein oder mehrere Module für die Vorsysteme, eines für eine mögliche Staging Area, eines für das eigentliche Warehouse und eines oder mehrere für mögliche Data Marts. Es entsteht automatisch eine Sortierung und Übersicht über das Warehouse System. In dem Warehouse Builder-Gesamtmodell fügen sich die Module in eine Hierarchie von mehreren Objekten ein: Projekte, Module, Dimensionen usw. (siehe Bild). Die Collections durchbrechen diese Objekthierarchie. In Collections fassen Sie beliebige Objekte nach fachlichen Anforderungen zusammen. Beide Konzepte zusammengenommen ergänzen sich hervorragend. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 58/300 Quell- oder Zielmodul? Die Module unterscheiden nicht danach, ob sie als Quell- oder Zielmodul verwendet werden. Sie können immer beides sein. Es gibt allerdings Ausnahmen: Die ERP- Module können nur lesend verwendet werden. Ohne Locations – läuft nichts Bevor wir mit der eigentlichen Arbeit beginnen, müssen die Locations erklärt werden. Locations treten bei dem Warehouse Builder an nahezu allen Stellen auf. Das Konzept der Locations muss man einmal verstanden haben, wenn man erfolgreich mit dem OWB arbeitet will. Das heißt, dass die meisten Fehler, die man zu Beginn mit dem OWB machen kann, aus dem falschen Umgang mit den Locations herrühren. Locations stellen kurz gesagt die Verbindung der OWB-Modelle und OWB-Objekte mit der Außenwelt dar. Einige Beispiele: Soll eine Tabelle in eine Datenbank generiert werden, so muss man die konkrete Tabelle über eine Location bekannt machen. Soll ein Datenbankkatalog eines Quellsystems gelesen werden, so ist über eine Location das Quellsystem zu bezeichnen. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 59/300 Locationen sind Objekte innerhalb des Warehouse Builder-Metamodells und haben immer einen Namen. Alle Locations sind im Connection Explorer aufgelistet. Dort können sie auch editiert werden. Locations besitzen die physischen ConnectionInformationen zu den Quell- und Zielsystemen. Z. B. erfordert eine Datenbank-Connection die Informationen: Schemadaten, Hostname, Port, Service-Name Beispieleditor einer Location für ein Oracle Datenbankschema Aufgeklappter Baum des Connection Explorers Connections müssen den Objekten zugewiesen werden, die sie verwenden sollen. In der Regel wird man bereits beim Erfassen von diesen Objekten (z. B. Module) aufgefordert, eine passende Location anzugeben. Die Locations haben es in sich: Wenn gerade bei der Generierung unerwartete Fehler auftreten, hilft es oft, die entsprechende Location komplett zu löschen und neu anzulegen. Die Locations finden ihren Hauptanwendungsbereich in dem Generierungszwecke und zum Starten der Ladejobs verwendet wird. Stand/letzte Änderung 13.05.2016 (in Arbeit) Control Center, das für 75875104 Oracle Warehouse step-by-step 60/300 Die Beschreibung des ersten Quellsystems Der erste Schritt bei dem Aufbau eines Data Warehouse-Systems ist immer die Identifizierung der benötigten Quelldaten. Hierzu müssen Sie ein erstes Modul anlegen. Das oben beschriebene Quelldatenmodelle und das angestrebte Zielmodell in dem hier vorgestellten Szenario hat die Form: Quell- und Zielmodell des Szenarios Nach dem erfolgreichen Laden der Beispieldaten befindet sich das Quellmodell in dem OracleDatenbankschema SRC. Das Zielmodell soll in dem Schema DWH neu aufgebaut werden. Darüber hinaus entstehen noch weitere Tabellen als Zwischenstufen. Bei der Festlegung der Module haben wir zwei Alternativen: 1. Wir wählen nur ein einziges Modul für das Quell- Zielschema oder 2. wir wählen für jedes Schema ein separates Modul. Technisch wäre die Option 1 gut möglich. Aber praktisch wäre es nicht. Wir sollten das Warehouse Builder Modell von Beginn für ein mögliches Wachstum flexibel halten und für jedes Quellsystem ein eigenes Modul wählen. Und dann sollte es weitere Module geben, in denen aus den Quellmodulen gelesen wird. Das folgende Szenario ist sinnvoll: Es wird ein erstes Modul „Bestellsystem“ erzeugt. Dieses bezieht über die Location LC_SRC die Metadatenbeschreibungen (Tabellenbeschreibungen) des Quelldatenmodells aus dem Schema SRC. Mehr macht dieses Modul nicht. Es wird nur zur Dokumentation der Tabellen im Quellsystem verwendet. Das Module „Warehouse“ wird die eigentliche Transformationsarbeit übernehmen. Es verwendet die Tabellenbeschreibungen des Quellsystems wie sie über das Modul „Bestellsystem“ geliefert werden. Das Mapping (AB) legt eine Transformation fest. Das Modul Warehouse ist über die Location LC_DWH mit dem Zielschema DWH verbunden. Dort wird hineingeschrieben. Die Locations LC_SRC und LC_DWH übernehmen unterschiedliche Aufgaben. Doch hierzu später. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 61/300 Commit aller Änderungen Bevor Sie mit den ersten Schritten beginnen, bedenken Sie, dass alles, was Sie neu erstellen oder ändern, noch nicht gesichert in dem Repository in der Datenbank abgelegt ist. Das ist erst der Fall, wenn Sie den sog. Commit-Knopf zu drücken (befindet sich im Kopfbereich des Design Centers). Der Warehouse Builder arbeitet zwar sehr zuverlässig und stürzt so gut wie nie ab (kommt wirklich nicht vor, Java-Code!). Es könnte jedoch die Datenbankverbindung zu dem Repository wegfallen und damit wären alle nicht "Committeten" Änderungen verloren. Natürlich steht auch Rollback unter dem Menüpunkt Project zur Verfügung. Definieren eines Source-Moduls für eine Oracle-Datenbankquelle Beginnen Sie in dem Project Explorer. Aktivieren Sie das Projekt MY_PROJECT. Das ist das Default-Projekt. Wenn Sie sich fit genug fühlen, können Sie auch ein eigenes Projekt definieren. Zum Üben ist das aber nicht nötig. Klappen Sie Databases auf. Erzeugen Sie ein neues Modul: Rechte Maustaste auf Oracle und wählen Sie New. Ein Wizard führt Sie durch den Erstellungsvorgang. Vergeben Sie den Namen Bestellsystem. Ignorieren Sie die Option „Identify the module type“. Sie hat nur dokumentarischen Wert. Next. Jetzt werden Sie aufgefordert, die Connection Informationen zu dem Quellschema anzugeben. Sie brauchen also eine gültige Location. Drücken Sie auf Edit. Ändern Sie den vorgeschlagenen Namen der Location (BESTELLDATEN_LOCATION1) auf den kürzeren Namen LC_SRC. Dieser Name wird später Bestandteil von anderen Objektnamen werden, z. B. DB Link Namen. Wenn der Name jetzt schon so lang ist, kann es später zu Problemen führen. Füllen Sie die entsprechenden Felder aus. Für unser Beispiel reicht: User name /Password / Host / Port / Service Name. Wählen Sie auch die passende Datenbankversion des Quellsystems. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 62/300 Festlegen der Location-Informationen für das Modul SRC Testen Sie die Connection. Machen Sie es jetzt, denn es verhindert später Fehler. Finish Den Metadaten Import machen wir separat. Ergebnis: Sie sollten jetzt in dem Projekt Explorer unter dem Punkt Oracle das Modul SRC finden und in dem Connection Explorer unter Locations/Databases/Oracle die Location LC_SRC. Auslesen von Tabellenbeschreibungen (Metadaten) aus einer Quelldatenbank Das eben erstellte Modul ist noch "leer". Es stellt eine Art Container dar, der jetzt bereit ist die Tabellenbeschreibungen aufzunehmen. Diesen Schritt nennt man Import der Metadaten. Rechte Maustaste auf Objekt Bestellsystem. Option Import. Der Metadaten Import-Wizard erscheint. Es erscheinen Optionen mit Datenbank-Objekten. Lassen Sie die Häkchen im Default gesetzt und drücken Sie gleich auf Next. Wählen Sie die Option Table. Next. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 63/300 Importierbare Objekttypen Im unteren Bereich finden sie die Optionen: None: Keine referenzierten Tabellen One Level: Zusätzlich importiert OWB die Parent-Tabellen der von Beziehungen All Level: OWB wertet alle Beziehungen auch über mehrere Tabellen hinaus verzweigte Beziehungen aus. Selektieren einzelner Tabellen, von denen die Metadaten zu importieren sind Belassen Sie es bei One Level. Klappen Sie das +-Zeichen vor Tables auf und es sollten alle Tabellen aus dem Source-Schema SRC aufgelistet werden. Selektieren Sie die Tabellen BEST_POSITIONEN und BESTELLUNG und schieben Sie die Tabellen mit dem Pfeil-Symbol > in das rechte Feld Beenden Sie den Dialog mit Next, Finish und OK. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 64/300 Überprüfen Sie die Existenz der Tabellen in dem Modul BESTELLDATEN. Das Ergebnis sieht jetzt so aus: Aufgeklapptes Modul Das neu entstandene Modul besitzt die folgenden Objekttypen: Es besitzt zusätzliche Objekte wie: Table Dimensions Cubes (das sind Fakten-Tabellen) Views und Materialized Views External Tables (Advanced) Queues Mappings Transformations Sequences User Defined Types Data Auditors Ein zweites Modul für die Warehouse-Tabellen erstellen Wie oben bereits ausgeführt, sollen die eigentlichen Warehouse-Objekte in einem zweiten Modul definiert werden. In diesem zweiten Modul wird die eigentliche Arbeit stattfinden. Erzeugen Sie sich ein neues Modul mit dem Namen Warehouse. Definieren Sie aber jetzt eine Location LC_DWH, die auf das Schema DWH zeigt. Dieser Vorgang ist analog zu dem oben beschriebenen durch zuführen. Bestätigen Sie alle weiteren Voreinstellungen (OK, Finish usw.). Lassen Sie sich das neue Modul anzeigen (Doppelklick auf den Namen). Überprüfen Sie auch die Existenz der neuen Location LC_DWH im Connect Explorer. Exkurs 1: Ein genauer Blick auf Module und Locations Module können über zwei Locations verfügen. Öffnen sie hierfür den Modul-Editor Rechte Maustaste auf das Modul Warehouse. Open Editor. Sie sehen ein Fenster mit den 3 Reitern: - Name (ist selbstredend) - Metadata Location - Data Location Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 65/300 Die beiden Location-Reiter sollten Sie näher betrachten. Der Metadata Location-Reiter zeigt auf das Datenbank-Schema aus dem für dieses Modul z. B. Tabellenbeschreibungen gelesen werden können. Die List-Box zeigt auf LC_DWH. Sie könnten hier auch umschalten und das Schema SRC einstellen. Den praktischen Nutzen werden wir später erkennen. Der Data Location-Reiter zeigt auf das Schema in das später generiert werden kann. Hier steht die Location auch auf LC_DWH. Exkurs 2: Woher kommen oder wie entstehen die Warehouse Tabellen? Es gibt 4 Wege, um diese zu erstellen: 1. Es gibt bereits ein Warehouse mit einer bestehenden Tabellenstruktur -> dann sind die benötigten Tabellen über den Import-Mechanismus zu laden: Rechte Maustaste auf den Modulnamen -> Import über den entsprechenden Pull DownMenüpunkt Import. Alternativ wird an verschiedenen Stellen diese Import-Option angeboten. Meist immer dann, wenn man sie tatsächlich braucht. Das finden Sie selbst heraus. 2. Es gibt Datenmodelle in Datenmodellierungstools. Hier hilft man sich ebenfalls mit dem vorgenannten Importmechanismus. Für ERwin und Power Designer starten Sie allerdings eine "Bridge". Oracle Designer-Datenmodelle übernehmen Sie, indem Sie den Metadaten-Importpfad eines Moduls umstellen auf „Oracle Designer Repository“. Rechte Maustaste auf den Modulnamen -> Open Editor. -> Reiter Metadata Location -> Source Type 3. Neuerstellen per Hand. Hierzu nutzen Sie den Data Object Editor Rechte Maustaste auf Tables im Modulfenster. -> New. 4. Neuerstellen als Kopie aus einer bestehenden Tabelle. Rechte Maustaste auf eine Tabelle, die Ihnen als Vorlage dient. Option Copy und dann Paste. 5. Erstellen einer neuen Tabelle über den Mapping-Editor während man ein Mapping erstellt. 6. Die einfachste Variante ist das "On-the-Fly"-Erstellen im Verlauf des interativen Entwicklungsprozesses des Warehouses. Dies kommt der Praxis der Warehouse-Entwicklung auch am nächsten. Hierbei definieren Sie die Tabellen Zug um Zug und zwar dann, wenn Sie sie brauchen. Natürlich ist es sinnvoll im Vorfeld der Entwicklung durch eine Informationsbedarfsanalyse ein Datenmodell zu erstellen. In der Praxis wird man aber diese so erstellten Modelle immer wieder ändern, weil sich unvorhergesehene Umstände im Verlauf der Entwicklungsarbeit ergeben haben. Sicherlich wird es immer wieder zu einer Mischung aus den genannten Möglichkeiten kommen. Wichtig ist festzuhalten, dass jederzeit alle Wege offen stehen, und man keinen Einschränkungen unterliegt. Letztlich entscheidet die Vorgehensweise im Projekt. Die Erfahrung zeigt jedoch, dass in der Praxis immer mehr „hemdsärmelig“ entwickelt wird, weil oftmals die Zeit für aufwendiges Projektmanagement bzw. starr getrennte Projektphasen fehlt. Aus diesem Grund ist es gut ein Werkzeug zu haben, das einerseits genügend Freiräume für flexible Projektgestaltung lässt, andererseits den nötigen Rahmen liefert um die Ergebnisse zu dokumentieren. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 66/300 Ein erstes Mapping erstellen Mappings nutzen Sie, um Datenflüsse graphisch festzulegen. Mappings sind die Kernbausteine des Ladeprozesses. In den Mappings nutzen Sie Operatoren als graphische Komponenten. Mappings werden später zu Prozessflüssen (Workflow) zusammengefasst. Beispielanforderung: Fassen Sie alle Sätze aus den beiden Tabellen BESTELLUNG und BEST_POSITION zu einer einzigen neu zu erstellenden Tabelle WH_TRANSAKTIONEN zusammen. Berücksichtigen Sie hierbei die Parent/Child-Beziehung zwischen beiden Quelltabellen. Öffnen Sie das neu angelegte Modul „Warehouse“. Erzeugen Sie ein Mapping: Rechte Maustaste auf Mappings -> New Vergeben den Namen MP_Transaktionen und drücken Sie OK. Der Mapping-Editor für das neue Mapping startet. Eine „Rundtour“ durch den Mapping-Editor Der Mapping-Editor soll zunächst erklärt werden. Selektieren Sie hierzu unter dem Auswahlpunkt „Window“ alle Optionen, damit alle Teilfenster sichtbar sind. Das sind - Explorer - Palette - Property Inspector - Birds Eye View - Generation Results - Data Viewer. Danach sieht Ihr Bildschirm etwas überfüllt aus. Bedenken Sie jedoch, dass die meisten Fenster bei der normalen Arbeit geschlossen bleiben und nur fallweise geöffnet sind. Alle Fenster sind „dockable“. Sie können sie also an beliebigen Stellen positionieren und auch am Rand „festdocken“. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 67/300 Mapping Editor mit allen geöffneten Fenstern Die einzelnen Fenster sollen hier kurz vorgestellt werden, bevor wir sie später benutzen. Der Explorer (1) Der Explorer hat zwei Aufgaben: Zum einen listet er alle Objekte aus allen Modulen auf, die man mit „Drag and Drop“ in den MappingEditor ziehen kann (Fußreiter Available Objects). Zum anderen listet er alle bislang benutzten Objekte im Mappingeditor auf (Fussreiter Selected Objects). Ein kleines Beispiel: Klicken Sie auf Available Objects. Öffnen Sie in dem Baum den Punkt „Databases / Oracle / SRC / Tables“. Markieren Sie die Tabellen „Bestellung“ und „Best_Position“. Ziehen Sie diese Objekte mit der linken gedrückten Maus in das Mapping-Fenster. Warten Sie etwas. Nach einem Augenblick erscheint ein Tabellenobjekt in dem Fenster. Drücken Sie den Knopf „Auto Layout“ in der Menüleiste. Zwei Tabellen erscheinen senkrecht übereinander. Wenn Sie die Tabellen nicht richtig sehen, drücken Sie noch auf den Knopf „Fit in Window“. Über die + und – Tasten können Sie zusätzlich die Sicht verändern. Klicken Sie jetzt in dem Explorer-Fenster auf Selected Objects. Sie werden die Auflistung der beiden Tabellen sehen. Klicken Sie abwechselnd auf jeweils einen der beiden Tabellennamen und Sie werden sehen, wie sich die gewählte Tabelle im Mapping-Fenster in den Mittelpunkt schiebt. Bei zwei Tabellen ist das keine große Hilfe. Aber man kann sich vorstellen, dass diese Funktion in komplexen Mapping mit 100 und mehr Operatoren eine große Orientierungshilfe darstellt. Mapping (5) Dieses Fenster ist das eigentliche Arbeitsfenster. Dieses Fenster lässt sich auch nicht schließen oder wegklappen (macht auch keinen Sinn). Sie haben die beiden Tabellen in den Mapping-Bereich gezogen. Anhand dieser Tabellenobjekte lassen sich grundlegende Dinge bzgl. der Darstellung der Operatoren erklären. Die Operatoren können haben: - einen Kopfbereich mit dem Namen des Objektes, - einen Gruppenbereich (z. B. INGR1, INOUTGRP1, OUTGRP1 usw.) und - bei aufgeklappten Gruppen sind Felder sichtbar. Wenn Sie mit der Maus die jeweiligen Bereiche selektieren, werden Sie feststellen, dass sich die Inhalte des Properties-Fensters (2) ändern. Im Properties-Fenster bekommen Sie immer die Information zu den aktuell selektierten Objekten angezeigt. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 68/300 Informationen rund den Tabellenoperator Die Darstellung des Operators lässt sich ändern. Wählen Sie hierzu die View Option „Options“. Einstelloptionen zur Darstellung des Tabellenoperators Birds Eye View (3) Der Birds Eye View stellt eine weitere Orientierungshilfe da. Versuchen Sie mit der Maus den blauen Rahmen groß und klein zu ziehen. Verschieben Sie den blauen Rahmen. Versuchen Sie mit gedrückter linker Maustaste den Fokus zu vergrößern bzw. zu verkleinern. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 69/300 Data Viewer (6) Der Data Viewer erlaubt Ihnen einen Blick auf die Tabelleninhalte. Markieren sie hierzu eine Tabelle. Drücken Sie in dem Data Viewer auf „Execute Query“ Sie werden die ersten 100 Sätze der gewählten Tabelle sehen. Tip: Diese Funktion ist sehr praktisch, wenn man Formatwandlungen durchführen möchte und nicht genau über die Quellformate Bescheid weiß. Properties Inspector (2) Der Properties Inspector liefert Einstellmöglichkeiten und Eigenschaften zu den in dem MappingFenster selektierten Operatoren. Dieses Fenster ist kontextsensitiv und ändert sich immer dann, wenn Sie ein anderes Objekt selektieren. Der Properties Inspector ist wichtig, weil Sie hier oft notwendige Funktionen finden, z. B. die Reihenfolge der zu beschreibenden Zieltabellen. Generation Results (7) Dieses Fenster liefert ad hoc-generierten Code. Dieser Code ist eine wichtige Hilfestellung für den Entwickler, um eine gewisse „Vorahnung“ zu dem späteren tatsächlichen Code zu gewinnen. Diese Funktion wird später noch einmal genauer erklärt. Palette (4) Hier sind alle zur Verfügung stehenden Operatoren zusammengefasst. Zum Kennenlernen der Operatoren schließen Sie am besten alle anderen Fenster, denn die Liste ist sehr lang. Im Kopf der Palette ist eine kleine Selektionslistbox versteckt. Klicken Sie auf All, und Sie sehen eine Clusterung der Operatoren: Hier eine Liste der Operatoren mit einer kurzen Erklärung: Source- und Target-Operatoren Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 70/300 Datenfluss – oder Transformationsoperatoren Vor- und Nachverarbeitung Wiederverwendbare Mapping-Bausteine Das Mapping aufbauen Doch nun zu dem Mapping. In dem Mapping-Fenster sind bereits die beiden Tabellen BESTELLUNG und BEST_POSITION. Um das Mapping zu einem funktionsfähigen Mapping zu machen, müssen die beiden Tabellen „verjoint“ und das Ergebnis in eine Zieltabelle geladen werden. Die Zieltabelle ist noch nicht da. Öffnen Sie das Paletten-Unterfenster „Transformationen“ Selektieren Sie den Joiner-Operator und ziehen Sie ihn rechts neben die bereits bestehenden Tabellen in das Mapping-Fenster. Der Joiner-Operator hat 2 Eingabebereiche ( INGRP1 / 2) und einen Ausgabebereich (OUTGR1) Überführen Sie mit „Drag and Drop“ die INOUTGRP1-Bereiche aus den beiden Tabellenbereichen auf die INGRP-Bereiche des Joiner-Operators. Klappen Sie den Joiner vollständig auf (Pfeil im Kopfbereich). Sie sehen jetzt den OUTGRP1-Bereich des Joiners angefüllt mit den Spaltennamen aus den beiden Eingabebereichen. Bei doppelten Namen wird eine „1“ angehängt. Sie müssen jetzt noch die Join-Bedingung festgelegen: Markieren Sie den Kopfbereich des Joiners. Sie sehen in dem Joiner-Properties-Fenster ein leeres Feld „Join Condition“. Selektieren Sie mit der Maus in dieses leere Feld. Es erscheinen 3 Punkte im rechten Feldbereich. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 71/300 Selektieren Sie die 3 Punkte und der Expression Builder erscheint. Expression Builder Der Expression Builder erscheint an mehreren Stellen im Warehouse Builder. Er erscheint immer dann, wenn nähere Einstellungen in einem SQL-Befehl zu machen sind, also z. B. eine WHEREBedingung oder eine Expression. In der Regel hat man im linken Bereich zwei Reiter, einen für die Input-Felder und einen für die zur Verfügung stehenden Funktionen (Transformationen). Durch Doppelklick gelangen die passenden Feldnamen von der linken in die rechte Hälfte. Eine Validierung des Ausdrucks kann man auch vornehmen. Machen Sie nacheinander einen Doppelklick auf die Felder BESTELLNR. Verbinden Sie beide mit einem Gleichheitszeichen. OK. Tip: Die Namen INGRP1 und INGRP2 sind nicht sprechend, vor allem, wenn Sie im Expression-Editor bei aufwendigen Join-Bedingungen die passenden Felder suchen. Benennen Sie diese Namen einfach um: Rechte Maustaste auf den Kopf des Joiners „Open Details“ und unter Groups die Namen einfach überschreiben. Z. B. in „Best“ und „Pos“. Bedenken Sie, dass diese Namen auch später in den PL/SQL-Code mit hinein generiert werden. Mit solchen Namen wird der Code leserlicher. Das fertige Mapping sieht jetzt so aus: Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 72/300 Das erste Mapping Wechselspiel logisch/physisch oder Mapping / Modul In dem Mappingeditor ist jetzt eine neue Tabelle entstanden, die wir gerne in der Datenbank wiederfinden möchten. Aber: Schieben Sie zur Kontrolle das Mapping-Fenster zur Seite, und kontrollieren Sie das Fenster des Moduls Warehouse. Sie werden die neue Tabelle WH_TRANSAKTIONEN nicht finden. Dieses Verhalten zu verstehen, ist für den weiteren Verlauf sehr wichtig, denn es gehört zur grundlegenden Mechanik des Mapping-Editors: Der Warehouse Builder unterscheidet zwischen sog. physischen und logischen Objekt-(Tabellen-) strukturen. Unter dem Punkt Table im Modulfenster sind alle Tabellen in ihrer physischen Struktur aufgelistet. So wie sie dort aufgelistet sind, sind diese auch in dem OWB-Repository gespeichert und können von dort aus in das Warehouse Zielschema generiert werden. Die in dem Mapping-Editor angezeigten Tabellen sind lediglich logische Strukturen. Es sind sog. Operatoren, die als Platzhalter für Tabellen fungieren. Warum diese Trennung: Mit dieser Technik ist es möglich, Definitionen von Tabellen zunächst auf einem logischen (entwicklungsbezogenen oder planerischen ) Level zu belassen und die Definitionen zu einem späteren passenden Zeitpunkt in physische Beschreibungen von Tabellen umzuwandeln. Es ist auch möglich aus einer logischen Tabellendefinition mehrere physische Tabellen abzuleiten. Das ist praktisch um etwa eine Entwicklungsumgebung von einer Produktionsumgebung zu unterscheiden. Das Verfahren setzt die Existenz mehrerer Module voraus. In diesem Testszenario benötigen wir diese Technik nicht. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 73/300 Eine logische Tabelle „Kunde“ existiert in unterschiedlichen Ausprägungen in zwei Modulen WHS1 und WHS2 Was ist zu tun um die neue Tabellenbeschreibung „WH_TRANSAKTIONEN“ als physische Instanz in einem Modul wieder zu finden: Mit der rechten Maustaste auf die Tabelle WH_TRANSAKTIONEN im Editor. Die Create and Bind Option wählen. Und jetzt einfach OK drücken, weil das Zielmodul bereits vorselektiert ist. Wenn Sie jetzt das Warehouse-Modul betrachten, können Sie die neue Tabelle sehen. In diesem Zustand können Sie für die neue Tabelle auch alle physische Parameter vergeben, bevor Sie die Tabelle in ein Zielschema einer Datenbank kopieren. Mit der rechten Maustaste auf den Tabellennamen. Option Configure. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 74/300 Festlegen der Tabelleneigenschaften Auch die Struktur der Tabelle können Sie in dem Data Object Editor verändern: Mit der rechten Maustaste auf den Tabellennamen. Option Properties. Tabelleneditor Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 75/300 Das erste Deployment – Das Control Center In unserem Szenario sind jetzt zwei neue Objekte entstanden die Tabelle WH_TRANSAKTIONEN und das Mapping MP_Transaktionen. Beide Objekte müssen in die Datenbank „deployed“ (generiert) werden. Dazu starten Sie das Control Center. Tools -> Control Center Manager. Das Control Center sollte jetzt starten. Wenn das Control Center nicht startet, müssen Sie u. U. zunächst den Control Center Service starten. Das erfolgt in einer reinen Windows-Umgebung über das Start-Menü. Ist die Datenbank auf einem Unix-System installiert, so können Scripte verwendet werden, wie Sie sie in dem Verzeichnis OWBHOME\owb\rtp\sql finden. Der Control Center Service sollte aber in der Regel automatisch starten, wenn Rechner und die Datenbank hochfahren. Starten des Control Centers Control Center Das wichtigste Organisationskriterium im Control Center sind die Locations in dem linken Fenster. Den Locations sind alle Module zugeordnet, die die jeweilige Location verwenden. Das Modul WAREHOUSE ist also unter der Location LC-DWH zu finden. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 76/300 Im rechten Fenster sehen Sie die Object Details. Hier stellen Sie ein, was Sie tun wollen. Unter dem Reiter „History“ sehen Sie, was Sie bis dahin generiert haben. In dem unteren Fenster sind die Generierungs- und spätere Laufergebnisse zu finden. Das Control Center ist zwar ein Entwicklungswerkzeug, Sie können aber damit alle Aktivitäten rund um OWB-Prozeduren einsehen und steuern. Locations registrieren Zunächst sollten Sie überprüfen, in welche Richtung die Locations zeigen. Hierzu klicken Sie mit der rechten Maustaste auf den Namen der Location und drücken auf Register. Sie sollten in einem separaten Fenster die Möglichkeit bekommen, diese Location zu testen. Sind die Connection-Daten falsch, so ändern Sie diese über den Connection Explorer. Bedenken Sie, dass Sie Locations nicht ändern können, wenn sie einem Modul zugewiesen sind. Es kann also sein, dass Sie diese Zuweisung für einen Augenblick aufheben müssen: Im Project Explorer mit der rechten Maustaste auf den Modulnamen klicken und dann Open Editor. Die Tabelle generieren Markieren Sie die Tabelle WH_Transaktionen Öffnen Sie die Listbox in dem Bereich „Object Details“ unter „Deploy Action“ auf „Create“ Drücken Sie jetzt den Deploy-Knopf im Kopfbereich des Fensters. Jetzt sollten Sie einen Generierungsjob unter „Control Center Jobs“ sehen. Wenn dort hinter dem Jobnamen ein grünes Häkchen erschienen ist, können Sie diesen Job mit einem Doppelklick öffnen. In dem neu geöffneten „Job Details“ Fenster sehen Sie die entsprechende Erfolgsmeldung und können auch den DDL-Text für die neue Tabelle sehen. Ein Mapping generieren Analog gehen Sie bei dem Generieren des Mappings vor. Sie müssen hierzu das Mapping „MP_TRANSAKTIONEN“ markiert haben. Nachdem Sie erfolgreich generiert haben, müssen Sie es noch starten: Drücken Sie hierfür den Start-Knopf im Kopfbereich des Fensters. Ein Job startet wieder. Beim Start des Jobs springt der Fokus des Fensters auf „Execution“. Mit Doppelklick können Sie die Laufzeitergebnisse abfragen. Mögliche Fehler sind im unteren Bereich aufgelistet, zusammen mit dem Laufzeitprotokoll. Der Erfolg wird Ihnen mit Success angezeigt. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 77/300 Das Control Center ist nicht die einzige Stelle an der das Ergebnis der gelaufenen Jobs nachlesen können. An separater Stelle wird noch der Repository Browser vorgestellt, der ebenfalls diese Ergebnisse anzeigen kann. Leserechte Sind Fehler beim Generieren aufgetreten, kann das an fehlenden Leserechten liegen. Sie wollen aus einer Prozedur, die sich in dem Schema DWH befindet Tabellendaten lesen, die in dem Schema SRC liegen. Dazu brauchen Sie für das Schema SRC Leserechte. Gehen Sie in das Schema SRC und setzen Sie die folgenden GRANT-Befehle ab. z. B. -> GRANT SELECT ON BESTELLUNG TO DWH; oder GRANT SELECT ANY TABLE TO DWH Haben Sie nicht die nötigen Rechte, so muss dies ein DBA für Sie tun. Haben Sie die Datenbank auf Ihrem Rechner und können sich selbst Rechte vergeben, so loggen Sie sich als DBA ein und geben dem SRC-User zunächst DBA-Rechte: grant dba to src. Das erste Teilergebnis ist geschafft, die ersten Daten sind bewegt. Weiter unten werden mehr Details vorgestellt. Connectors und Database-Links Erhalten Sie beim Generieren von Mappings Fehlermeldungen über nicht bekannte Tabellen, dann kann ein fehlender DB-LINK die Ursache sein. Das ist dann der Fall, wenn Quell– und Zielschema unterschiedlichen Datenbankinstanzen angehören. Die in der Oracle-Datenbanktechnik bekannten DB-Links verbergen sich hinter dem Punkt Connectors in dem Location-Zweig des Deploy-Trees. Sie haben als Sie die Module „BESTELLUNGEN“ und „WAREHOUSE“ anlegten auch für jedes Modul eine Location definiert. Die Locations sind in dem Tree zu erkennen. Die Locations repräsentieren den DB-Link als physische Verbindung innerhalb der Datenbank und „zeigen“ ausgehend von dem Schema DWH in das Schema SRC hinein. Sie würde gebraucht, wenn SRC und DWH Schemen in unterschiedlichen Instanzen lägen. Arbeiten Sie mit unterschiedlichen Instanzen und fehlt Ihnen ein Connector, so erstellen Sie einen Connector explizit. Öffnen Sie in dem WAREHOUSE BUILDER-Hauptfenster unter Oracle den Punkt Locations. Gehen Sie auf LOC_DWH und drücken Sie über das Kontextmenü den Punkt Create Connector. Vergeben Sie einen Namen (z. B. CONN_SRC). Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 78/300 Wählen Sie in dem folgenden Fenster die Location in der Listbox aus, zu dem Sie einen DB_Link aufbauen wollen, bzw. aus der Sie lesen wollen. Finish Im Dployment-Manager erscheint jetzt der neuer Connector. Deployen Sie ihn in das Zielschema DWH in der Datenbank. Jetzt sollten Sie keine Zugriffsprobleme mehr haben. Intelligenter Generierungsmechanismus In dem jüngsten Warehouse-Builder-Release muss man sich nicht mehr um die Connectoren kümmern. Der Warehouse-Builder stellt im Verlauf der Generierung selbständig fest, ob ein DatabaseLink in Form eines Connectors nötig ist oder nicht. Ist er nötig, so wird er im Hintergrund automatisch generiert. Diesen Mechanismus kann man über die Konfigurations-Parameter eines Mappings umgehen (->rechte Maustaste auf den Mapping-Namen -> Configuration). Hier haben Sie die Möglichkeit einen Database-Link-Namen und einen Schema-Namen für jede Tabelle des Mappings anzugeben. Diese werden dann beim Generieren genommen. „Configuration Properties“ eines Mappings Von dieser Vorgehensweise ist jedoch abzuraten. Die Möglichkeit besteht nur noch aus Gründen der Abwärtskompatibilität zu älteren Releasen. Dort war dies nötig. Der „Intelligente Generierungsmechanismus“ nimmt dem Entwickler diese Arbeit ab. Außerdem verlieren Sie damit die Möglichkeit den Mapping-Code mit einer einzigen Schalterstellung flexibel in ein anderes System zu generieren. Um dies zu erreichen ändert man nur die Zuordnung einer Location. So lange Objekte noch nicht generiert sind, werden sie in der folgenden Form beschrieben: {location.<object_name>}. Im Verlauf der Generierung löst OWB den „location“-String auf und ersetzt ihn durch den passenden Database-Link-Namen. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 79/300 Mit dieser DB-Link-Mechanik kann die Programmstruktur immer die gleiche bleiben, auch wenn andere Quell- und Zieldatenbanken gewählt werden sollten. Sie stellt eine Verknüpfung zwischen der Logik im Mapping und den tatsächlichen physischen Datenbanken dar. Auch die meisten Gateways, z. B. nach DB2 oder SQL Server, funktionieren nach dieser Logik. So können sie auf entfernt liegende Tabellen – auch in nicht-Oracle-Datenbanken - so zugreifen, als würden dieses lokal liegen. Locations und Connectoren beschreiben die Beziehungen zwischen Modulen Smart-Code Generation Wenn Sie Gelegenheit haben, Daten aus einer anderen Datenbank-Instanz auf einem anderen Rechner zu lesen und dabei einen Database-Link verwenden, betrachten Sie sich doch mal den generierten PL/SQL-Code. Sie werden sehen, dass OWB für den Fall von Database-Links mit InlineViews arbeitet. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 80/300 Ein erster Blick in das Repository über HTMLBrowser An dieser Stelle soll schon mal ein erster Blick in das Repository des Warehouse Builders geworfen werden. In den folgenden Beispielen wird immer wieder auf Auswertungen des Repositories verwiesen. Das Repository ist von Beginn an mitinstalliert worden. Es beinhaltet zunächst alle Entwicklungsinformationen (Design-Daten). Mit dem Deployment und Test in dem Beispiel zuvor, bestehen jetzt auch Laufzeitinformationen. Sie können sich diese in einem HTML-Browser ansehen. Die generierten Mappings kommunizieren ihre Laufzeitdaten mit dem Runtime-System, das sich im Regelfall in dem Zielschema also dem eigentlichen Warehouse befindet. Hier sind statistische Informationen (gelesene, geschriebene, abgewiesene Sätze usw. ) ebenso gespeichert wie die fehlerhaften Sätze. Aufruf des Repository Browsers Um den Metadaten-Bowser zu nutzen, ist zunächst der OWB Browser Listener zu starten (JavaAnwendung). Diesen starten Sie separat wie folgt: Starten Sie zunächst den OWB Browser Listener über das Startmenü Danach startet ein Fenster mit diversen Meldungen. Sie sollten warten bis die letzte Meldung „.....initialized“ erscheint. Console für Listener mit Controllmeldungen Starten Sie jetzt über das Start Menü den Repository Browser (oder starten Sie sie den Repositorybrowser über das Tools-Menü im Design Center). Es erscheint die Anmeldemaske, in der Sie die Repository-Zugangsdaten eintragen können. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 81/300 Anmeldemaske Rpository Sie befinden sich in einem Auswahlmenü über das Sie in unterschiedliche Reports sowohl für die Design-Metadaten als auch für die Laufzeit-Informationen gelangen. Zugriff auf die Runtime-Informationen des Repositories Wählt man den Execution Schedule Report, so kann man über eine zusätzliche Selektion nach Execution Name Execution Status Start Date und End Date gezielt einzelne Jobs ansteuern. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 82/300 Einschränkung auf die Anzeige eines gestarteten Mappings Detailinformationen zu den gelaufenen Job findet man in der rechten Spalte der Jobzeile. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 83/300 Detailinformationen zu dem vorher selektierten Job Der Fortschritt des Ladelaufes kann durch wiederholtes Drücken des REFRESH-Knopfes kontrolliert werden. An dieser Stelle können Ladeläufe auch angehalten bzw. auch gestartet werden. Design-Repository Browser Über die Option Design Repository: Navigation des Hauptfensters gelangen Sie in den MetadatenBowser. Einstieg zum Design Repository Browser In diesem Design Repository Browser eröffnet sich Ihnen eine Baumdarstellung aller Objekte des Repository. Um die Übersicht zu erleichtern, kann man einen Fokus setzen, z. B. auf das Modul Warehouse. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 84/300 Metadatenobjekte des Moduls WAREHOUSE Oder auf ein Mapping innerhalb dieses Moduls: Metadatenobjekte des Mappings MP_TRASNAKTIONEN_4_WHERE Die Brillen-Symbole auf der rechten Seite ermöglichen einen Zugang zur Impact- und LineageAnalyse. Impact- / Lineage-Analyse direkt aus OWB heraus Um eine Impact- bzw. Lineage-Analyse direkt aus dem OWB heraus zu erhalten, genügt es im Design Center mit der rechten Maustaste auf ein Objekt zu drücken, und dann die Impact- oder LineageOption zu drücken. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 85/300 Impact- / Lineage-Option im Design Center Hier nur ein Ausschnitt aus einer Impact-Analyse. Die dicken Kästchen mit dem Plus-Symbol kann man durch einen Doppelklick aufklappen. Dahinter verbergen sich Mappings. Die Darstellung kann sehr komplex werden, wenn man die Suche von zentralen Tabellen aus startet, die in vielen Mappings verwendet werden. Graphisch dargestellte Impact-Analyse Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 86/300 Zur besseren Übersichtlichkeit sollte man sich bei komplexen Darstellungen, passende Teilausschnitte vergrößern, und diese dann drucken. Eventuell müssen die Teilausschnitte dann wieder zusammengeklebt werden. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 87/300 Nützliche Hilfsmittel: Validate: In dem Mapping-Editor kann vieles kombiniert werden, was später zur Laufzeit nicht laufen würde. Deswegen ist es sinnvoll ein Mapping zu validieren, auch wenn die Validierung optional ist. Führen Sie folgenden Versuch durch: Ändern Sie über das Properties-Fenster für die Tabelle WH_TRANSAKTIONEN das numerische Feld Kundencode auf den Datentyp varchar. Drücken Sie das Validate-Symbol in der Kopfleiste des Editors Sie bekommen jetzt in dem Generation Results-Fenster Warnmeldungen angezeigt. Die erste besagt, dass die Tabelle WH_TRANSAKTIONEN nicht mehr mit der in dem Repository gespeicherten Version übereinstimmt (hier müsste synchronisiert werden). Zum anderen zeigt eine Meldung an, dass der Typ des Felds KUNDENCODE im Ausgabebereich des Joiners nicht mit dem Zielfeld der Zieltabelle übereinstimmt. Durch einen Doppelklick in den Textbereich kann man die komplette Meldung anzeigen. Unter Validation Details stehen Hinweise, wie man die Situation beheben kann. In fast allen Fällen sind diese Empfehlungen sinnvoll. Wenn Warnungsmeldungen erscheinen, kann die spätere Generierung erfolgreich verlaufen es muss aber nicht so sein. Erscheinen echte Fehlermeldungen (rotes Symbol), ist eine Generierung unmöglich. Ergebnis-Meldungen des Validate-Aufrufes Der Validate-Mechanismus arbeitet sehr genau und stellt eine große Hilfe bei der Vermeidung von Fehlern dar. In der aktuellen Version wird der Validate-Prozeß bei Generierungen jeder Art automatisch immer gestartet. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 88/300 Tip: Tritt irgend eine ungewöhnliche Fehlersituation vor allem bei dem Deploy der Datenbankobjekte auf, so findet man durch den Validierungs-Prozess meist den passenden Hinweis. Ad Hoc-Generierungen im Mapping-Editor SQL-Erfahrene können sehr schnell einem Programmcode ansehen, ob er tauglich ist oder nicht. Daher bietet der Mapping-Editor auch die Möglichkeit der Zwischengenerierung direkt aus dem Editor heraus. Drücken Sie das Generate-Symbol in der Kopfleiste des Editors. In dem Generation Result Fenster wird Ihnen ein Package-Code-Extrakt gezeigt. Zur besseren Lesbarkeit sind die vielen Aufrufe für die Statistik und Fehlerbehandlung entfernt. Den Code können Sie herauskopieren und separat testen. Im Kopf des Generation Result Fensters finden Sie eine Listbox Generation Style mit den Optionen Full und Intermediate. Wählen Sie Intermediate. Markieren Sie in dem Mapping-Fenster INOUTGRP1 von WH_TRANSAKTIONEN. Das Insert .... Into .....Select from ....-Statement erscheint in dem Generation-Result-Fenster. Markieren Sie nach und nach auch andere Gruppenfelder in dem Mapping und Sie erkennen, wie sich der generierte Code ändert. In der Listbox Aspect können Sie für diese Tabelle auch unterschiedlich DML-Befehle anwählen. Die Optionen ändern sich in Abhängigkeit von der Situation, in der sich die Tabelle befindet. Generierung von Intermediate Result In diesem Mapping sind das sehr einfache Beispiele. Bei komplexeren Mappings ist diese Technik ein wichtiges und ständiges Hilfsmittel. Tip: Das Intermediate-Result-Ergebnis kann in vielen Fällen direkt in SQL*Plus überführt werden. Somit kann man sehr schnell das jeweilige Statement testen. Kopieren über „Edit“ „Select All“ oder CTRL-A -> CTRL-C -> CTRL-V. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 89/300 Kopieren von Metaobjekten Alle Objekte können mit Hilfe des Kontextmenüs (rechte Maustaste) kopiert werden, auch komplexe Mappings und über Modulgrenzen hinweg. Allerdings nur innerhalb eines Projektes. Das ist praktisch, wenn Sie ein Mapping zu Testzwecken umbauen wollen, aber eventuell auf die Ursprungsversion wieder zurückkehren müssen. Schnelles Generieren und Deployen auch ohne Control Center Fast alle Objekte können auch direkt aus dem Design Center heraus generiert werden. Testen Sie es mit Hilfe der Tabelle WH_TRANSAKTIONEN aus. Selektieren Sie mit der rechten Maustaste die Tabelle WH_TRANSAKTIONEN Wählen Sie zunächst in dem Kontextmenü den Punkt Generieren. Selektieren Sie den Reiter Script markieren Sie den Tabellennamen View Code Die Create Table-Definition wird erscheinen. Dieses Verfahren ist wesentlich schneller, als wenn Sie zunächst das Control Center starten und sich in den Location zurecht finden müssen. Bedenken Sie jedoch, dass diese Art der Generierung nicht alle Optionen des Control Centers beinhaltet, z. B. fehlt das DROP Table. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 90/300 Die Operatoren – Teil 1 Mehrere Tabellen über JOIN verbinden und einlesen – Join Operator Den Join-Operator haben wir oben bereits kennen gelernt. In dem nächsten Szenario-Schritt ergänzen wir das Mapping um mehrere Quelltabellen ARTIKEL und KUNDE. Erstellen Sie ein zweites Mapping MP_TRANSAKTIONEN_2_JOINER. Tip: Kopieren Sie hierfür das Mapping MP_TRANSAKTIONEN (rechte Maustaste COPY/PASTE) und RENAME auf das neu entstandene Objekt COPY_OF_MP_TRANSAKTIONEN mit der rechten Maustaste. Öffnen Sie das Mapping. Ziehen Sie über das Explorer-Fenster die beiden Tabellen ARTIKEL und KUNDE aus dem Modul SRC in den Editor, wie bereits bekannt. (Wenn die Tabellen nicht über das Modul SRC sichtbar sind, importieren Sie die Tabellen mit der IMPORT-Funktion des Kontextmenüs am Modulnamen.) Erweitern Sie den Joiner um zwei weitere INGRP-Bereiche und benennen Sie die Gruppen ARTIKEL und KUNDE. (Rechte Maustaste auf den Joiner-Kopf -> Open Details). Ziehen Sie die INOUTGR-Bereiche der neuen Tabellen in die jeweiligen Eingabegruppenbereiche des Joiners Display Set Da die Kundentabelle etwas mehr Columns besitzt, wird der Ausgabebereich des Joiners sehr lang und unübersichtlich. Um die Situation in den Griff zu bekommen, gibt es mehrere Hilfsmittel: Zum einen: Display Sets verwenden. Nicht alle Columns werden genutzt. Wir blenden nur diejenigen Columns ein, die auch wirklich gebraucht werden. Löschen Sie den Eingabegruppenbereich mit dem Namen „Kunde“ wieder aus dem Joiner (Open Details). Das ist der schnellste Weg, alle Linien weg zu bekommen, und legen Sie ihn wieder neu an. Öffnen Sie jetzt das Kontextmenü der Tabelle Kunde (rechte Maustaste auf den Kopf der Tabelle). Wählen Sie den Punkt Display Set. Erfassen Sie in der Liste unter Name den neuen Eintrag „Joiner“ und selektieren Sie in dem unteren Bereich die Felder KUNDENNR / GESCHLECHT / VORNAME / NACHNAME / TITEL / STATUS Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 91/300 Festlegen eines Display Sets OK. Wählen Sie jetzt in dem Kontextmenü der Tabelle „Kunde“ über den Punkt „Select Display Set“ die neu entstandene Option „Joiner“. Jetzt sollten nur noch die vorher gewählten Spalten zu sehen sein. Ziehen Sie jetzt den INOUTGR-Bereich der so verkürzten Kunden-Tabelle in den entsprechenden Eingangsbereich des Joiners. Ergänzen Sie jetzt die Join-Bedingung (Markieren des Kopfs des Joiners -> Properties Fenster -> Join Condition wie in dem Bild angezeigt). Die neue Join-Condition Erweitern Sie jetzt die Zieltabelle WH_Transaktionen um die zusätzlichen Felder, die Sie jetzt in dem OUTGR-Bereich des Joiners finden. Tip: Die Reihenfolge der Spalten in der OUTGRP1-Gruppe orientiert sich an der Reihenfolge der Eingabegruppen. Dies hilft bei der Orientierung vor allem dann, wenn gleichbenannte Attribute aus verschiedenen Eingabetabellen geliefert werden. Doppelte Spaltennamen unterscheidet OWB durch das Anhängen eines Zählstrings (z. B. BESTELLNR_1) Tip: Die Spalten in der OUTGRP1-Gruppe können auch mit Hilfe von Präfixen leicht unterschieden werden. Öffnen Sie hierzu den Joiner-Editor (rechte Maustaste auf den Kopf des Joiners -> Open Details) und fügen Sie vor allen Column-Namen des INGRP-Bereichs einen Präfix ein (z. B. K_). Die Präfixkennzeichnung wird in den Ausgabebereich übertragen. Eine weitere Hilfe hierzu sind die Display Sets (rechte Maustaste auf den Kopf des Joiners -> Use Display Set -> Selektieren der jeweiligen Option. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 92/300 Ziehen Sie die Felder Artikelname / Einzelpreis und Status in die Zieltabelle WH_Transaktionen. Es erscheint ein Zwischenfenster über das Sie festlegen können, in welcher Art und Weise die Spaltennamen in die Zieltabelle übernommen werden. Mit „Go“ übernehmen Sie alle. Sie können aber auch den Präfix „K_“ wieder ausblenden, indem Sie „Ignore Source Prefix“ wählen. Überprüfen Sie die Richtigkeit des Mappings mit „Validate“. Sie erhalten die Information, dass die Tabelle WH_TRANSAKTIONEN nicht mehr synchron mit dem Repository ist. Sie müssen die Tabelle synchronisieren (rechte Maustaste auf WH_Transaktionen -> Synchronize -> Voreinstellungen lassen -> OK). Generieren und Testen Sie das neue Mapping über das Control Center. Sie müssen dabei auch die Tabelle erneuern, d. h. Sie sollten die Option REPLACE für die Tabelle wählen. Diese wird zwei Scripte erzeugen: ein DROP TABLE und ein CREATE TABLE. Wechseln Sie in das Control Center. Sie stellen fest, dass sich der Zustand der Objekte geändert hat. WH_Transaktionen_2 steht auf NEW und das Mapping MP_TRANSAKTION_2 auf Not Deployed. Dieses sollten Sie ändern, indem Sie neu generieren. An diesem Beispiel können Sie eine wichtige Aufgabe des Control Centers erkennen: Es zeigt Ihnen auf, welche Objekte sich im Verlauf des Entwicklungsprozesses geändert haben. Sie erkennen, welche Generierungen Sie nachziehen müssen. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 93/300 Der neue Zwischenstand des Beispiel-Mappings (Demo MP_TRANSAKTIONEN_2_JOINER) Tip: Haben Sie mit der Größe der Tabellen und dem beschränkten Platzangebot im Editor „gekämpft“? Wenn ja, sollten sie die Anzahl der angezeigten Attribute auf die tatsächlich „gemappten“ Attribute beschränken. Rechte Maustaste auf die Attributgruppe der Tabelle, die Sie in der Anzeige verkleinern möchten. Option Use Display Set -> MAPPED. Diese Option Use Display Set ist zudem sehr praktisch, wenn Sie nur Spalten von einem Join-Zweig sehen wollen. Schalten Sie zu Testzwecken zwischen den Optionen hin und her, um den Effekt kennen zu lernen. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 94/300 Die verschiedenen Display-Sets In mehrere Zieltabellen schreiben - Splitter-Operator In einem Mapping können Sie sowohl aus mehreren Tabellen lesen und gleichzeitig in mehrere Zieltabellen schreiben. In mehrere Zieltabellen können Sie über den "Splitter" schreiben. Aufgabenstellung: In Abhängigkeit von dem Feld "Status" der Tabelle WH_TRANSAKTIONEN sollen in zwei zusätzlichen Zieltabellen die Felder Name, Kundencode und Bestellmenge geschrieben werden. In dem Status-Feld kann stehen P (wie Privatkunde) und F (wie Firmenkunde). Erstellen Sie wieder eine Kopie von MP_TRANAKTIONEN_2_JOINER nach MP_TRANSAKTIONEN_3_SPLITTER. Ziehen Sie den Splitter-Operator zusätzlich in den Editor und positionieren Sie ihn rechts neben die Tabelle WH_TRANSAKTIONEN. Ziehen Sie die Felder Kundencode, Bestellmenge, Bestell_Total sowie Status aus WH_TRANSAKTIONEN in den Eingabebereich des Splitters. Ändern Sie die Namen OUTGP1/2 in die sprechenden Namen Privatkunde und Firmenkunde. (-> rechte Maustaste auf den Splitterkopf und dann Open Details). Markieren Sie die Ausgabegruppe Privatkunde und gehen Sie über die Group Properties (-> Properties Inspector) in das Feld Split Conditions um in den Expression Builder zu gelangen. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 95/300 Erzeugen Sie hier die Bedingung: INGRP1.STATUS = 'P' Wiederholen Sie den Vorgang für die Ausgabegruppe Firmenkunde mit der Bedingung INGRP1.STATUS = 'F' Erzeugen Sie zwei neue Tabellen WH_TRANS_PRIVAT und WH_TRANS_FIRMA. Ziehen Sie jetzt die kompletten Ausgabegruppen des Splitters also Privatkunden und Firmenkunden in die jeweiligen Eingabegruppen der Zieltabellen. Alle Attribute müssten übernommen werden. Betrachten Sie zur Kontrolle das generierte Ergebnis über das Generate-Symbol im Fensterkopf. Erzeugen Sie jetzt die neuen Tabellen in dem Modul Warehouse (-> rechte Maustaste auf den Tabellenköpfen -> Create And Bind). Generieren Sie die beiden neuen Tabellen und das neue Mapping. Betrachen Sie sich die Ergebnisse der neuen Tabellen über den Relational Data Viewer: Exkurs: Multiple-Inserts in einem Kommando Betrachten Sie das Insert-Statement für die beiden neuen Zieltabellen in dem Generation Result Fenster genau (ab etwa Zeile 120). Sie werden feststellen, dass der Warehouse Builder ein sog. Multiple Insert Statement generiert hat (Funktionalität der Oracle Datenbank ab Version 9i). Dies ist ein bedingtes Schreiben in zwei Tabellen gleichzeitig, wobei die Eingabemenge aus einem einzigen Select entnommen wurde. Alles in allem handelt es um ein einziges SQLKommando das die Datenbank sehr performant und parallelisiert abarbeitet. Ausschnitt aus dem generierten Code: INSERT /*+ APPEND PARALLEL("WH_TRANS_PRIVAT") APPEND PARALLEL("WH_TRANS_FIRMA") */ ALL Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 96/300 WHEN "STATUS" = 'P'/* SPLITTER.PRIVATKUNDEN */ THEN INTO "WH_Trans_Privat" ("BESTELLMENGE", "KUNDENCODE", "BESTELL_TOTAL", "STATUS") VALUES ("BESTELLMENGE$1", "KUNDENCODE$1", "BESTELL_TOTAL$1", "STATUS") WHEN "STATUS" = 'F'/* SPLITTER.FIRMENKUNDEN */ THEN INTO "WH_TRANS_FIRMA" ("BESTELLMENGE", "KUNDENCODE", "BESTELL_TOTAL", "STATUS") VALUES ("BESTELLMENGE$1", "KUNDENCODE$1", "BESTELL_TOTAL$1", "STATUS") (SELECT "WH_TRANSAKTIONEN"."BESTELLMENGE" "BESTELLMENGE$1", "WH_TRANSAKTIONEN"."KUNDENCODE" "KUNDENCODE$1", "WH_TRANSAKTIONEN"."BESTELL_TOTAL" "BESTELL_TOTAL$1", "WH_TRANSAKTIONEN"."STATUS" "STATUS" FROM "WH_TRANSAKTIONEN" "WH_TRANSAKTIONEN" WHERE ("WH_TRANSAKTIONEN"."STATUS" = 'P'/* SPLITTER.PRIVATKUNDEN */) OR ("WH_TRANSAKTIONEN"."STATUS" = 'F'/* SPLITTER.FIRMENKUNDEN */) ); Das neue Mapping sollte jetzt wie folgt aussehen. Der neue Zwischenstand des Beispiel-Mappings (MP_TRANSAKTIONEN_3_SPLITTER) Exkurs: Wie viele Tabellen passen in ein Mapping und wie werden sie kombiniert Sie können beliebig viele Joiner und Splitter mit beliebig vielen beteiligten Tabellen in einem Mapping kombinieren. Die Zwischentabelle WH_TRANSAKTIONEN in dem gezeigten Beispiel ist nur Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 97/300 entstanden, weil es in dieses Demo-Szenario gut passte. Wir hätten auch Joiner und Splitter direkt mit einander vereinen können. Es können auch beliebig viele Ladeschritte nacheinander in einem Mapping folgen, wobei eine Zieltabelle eine Quelltabelle in einem Folgeschritt darstellt, usw. Abarbeitung mehrerer Ladevorgänge in einem Mapping Auch das parallele Abarbeiten von unabhängigen Tabellen ist möglich: T1 – T4 und X1 – X4 werden nacheinander geladen. Die Tabellen müssen nicht in demselben „Ladestrang“ liegen. Auch komplexe Strukturen sind erlaubt, wie das folgende Beispiel zeigt: T1 – T4 und X1 – X4 werden nacheinander geladen über einen Joiner auf TX1-2 vereinigt und über einen Splitter wieder in V1-2 und W1-2 gespalten. Es gibt nur die Einschränkung, dass Sie die Fülle der Inserts, die der Warehouse Builder generiert, nicht mehr überschauen können. Tip: Füllen Sie nur die Operatoren in den Mapping-Editor, die auch zur Abarbeitung einer zusammenhängenden Teilaufgabe notwendig sind. In der Regel ist das das Verändern einer Tabelle oder von logisch zusammenhängenden Tabellen. Man kann sich hier an Geschäftsprozessen orientieren. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 98/300 Filter und Bedingungen (Where Operator) Ein Filter schränkt die Verarbeitung von Sätzen aus den einzelnen Tabellen ein. Er wird in SQL mit Hilfe der WHERE-Bedingung des SELECTS realisiert. Bereits bei dem JOINER-Operator ist eine WHERE-Bedingung erzeugt worden. Wir hätten also bereits dort einen Filter definieren können, indem wir die Join-Bedingung modifiziert hätten. Das Ergebnis wäre das gleiche gewesen, aber unübersichtlicher. Man verwendet OWB u. a. aufgrund der Möglichkeit zur Dokumentation. Eine JoinOperation und eine Filter-Operation sind logisch zwei unterschiedliche Dinge, auch wenn sie mit denselben SQL-Schlüsselwörtern realisiert sind. Aufgabenstellung: Es sollen nur Kunden mit Kundenummer > 1000 geladen werden. Erstellen Sie in dem Modul WAREHOUSE durch Kopie aus MP_TRANSAKTIONEN_3_SPLITTER das neue Mapping MP_TRANSAKTIONEN_4_WHERE. Minimieren Sie zunächst alle Operatoren, damit Sie leichter eine Übersicht bekommen. Ziehen Sie das Filter-Symbol aus der Palette und der Untergruppe Transformationen in die Editorfläche. Am besten zwischen die Tabelle Kunde und den Joiner-Operator. Durch einen Doppelklick auf die Tabelle Kunde können sie das minimierte Symbol aufklappen, so dass Sie alle Spalten sehen. Machen Sie das gleiche mit dem Joiner-Operator. Hier allerdings entstehen zu viele Spalten. Schalten Sie am besten die Display Set-Option des Joiners für Kunden an. Markieren Sie die Linien zwischen KUNDE und dem Joiner, so dass sie sich blau färben und löschen Sie diese. Ziehen die ganze (!) Gruppe INOUTGRP1 von KUNDE auf die Gruppe INOUTGRP1 des Filters. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 99/300 Ziehen Sie diese INOUTGRP1-Gruppe auf den Kunden-Bereich des Joiners. Das Connect Operator Fenster erscheint. Wählen Sie hier die Option „Match by name of Source and target attributes“ und dann Ignore target prefix mit „K_“. (Wenn sie in den Tests vorher die Kundenspalten mit K_ gekennzeichnet haben). Der Auto Mapping-Wizard OK Stellen Sie jetzt die Filterbedingung über den Properties Inspector ein. Generieren Sie das neue Mapping und testen Sie es. Tip: Benennen Sie das neue Filterobjekt um z. B. Kunden_groesser_1000. Das macht das Mapping lesbarer. Wir haben den Filter zwischen die Quelltabellen und den Joiner gesetzt, alternativ hätten wir ihn auch nach dem Joiner setzen können. Der generierte Code wird allerdings gleich bleiben. Die Filterbedingung wird als Bestandteil in die WHERE-Klausel mit aufgenommen. Achtung: Wie in dem Beispiel gezeigt, ist es nötig alle Columns zunächst in den Filter und dann erst in den Joiner fließen zu lassen. Würde man dies nur mit der einen Column tun, die einzuschränken ist und die übrigen Columns direkt mit dem Joiner verbinden, dann hätte der Joiner zwei Operatoren als Quelloperator. Eine Fehlermeldung würde dies anzeigen. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 100/300 Betrachten Sie sich nach einer Generierung im Mapping-Editor den Code für die Filterbedingung. Die Warehouse Builder baut die über den Filter-Operator definierte Bedingung in die Where- Klausel, die bereits durch die Join-Bedingung entstanden war, ein. Das Generierungsergebnis sieht jetzt so aus (Ausschnitt): ... FROM "SRC"."BEST_POSITION" "BEST_POSITION", "SRC"."BESTELLUNG" "BESTELLUNG" WHERE ( "BEST_POSITION"."BESTELLNR" = "BESTELLUNG"."BESTELLNR" ) AND ( "BESTELLUNG"."KUNDENCODE" > 1000 ) ); Das neue Mapping hat jetzt folgendes Aussehen: Exkurs: Zieltabellen automatisch leeren - Truncate Unsere Zieltabellen WH_TRANS_PRIVAT und WH_TRANS_FIRMA und auch die Zwischentabelle WH_TRANSAKTIONEN füllen sich mit jedem Test, die wir durchführen um mehrere 1000 Sätze. Eigentlich müssten wir zwischen allen Tests manuell eine TRUNCATE-Anweisung direkt in der Datenbank absetzen. Hier ein kleiner Vorgriff auf die Update / Delete / Insert-Steuerung, die weiter unten noch erklärt wird: Wir können die Zieltabellen auch auf TRUNCATE / INSERT umstellen, so dass OWB zunächst einen TRUNCATE durchführt bevor mit INSERT in die Datenbank geschrieben wird. Ändern Sie über das Properties-Fenster den Loading Type für alle betroffenen Tabellen auf TRUNCATE / INSERT. Generieren Sie das Mapping neu und testen Sie es. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 101/300 Einstellen des Loading Type zum initialen TRUNCATE auf eine Ziel-Tabelle Beliebige Ausdrücke in einem SQL-Kommando - Der ExpressionBuilder Beliebige Ausdrücke, Berechnungen, Wandlungen, aber auch besondere Prüfungen integriert der Expression-Builder in den Datenfluss. Mit diesem Operator führen Sie Ausdrücke in den Select-Teil des SQL Kommandos über die normalen Column-Namen hinaus ein. Anforderung: Leiten Sie aus den Bestellungen und Bestellpositionen zusätzlichen Feldern für Berechnung Gesamtwert pro Position (Artikelpreis mal Menge) Rechnungsfälligkeitsdatum (Lieferdatum + 20), Berechnung Bruttogesamtwert ab. Die Inhalte der neuen Felder sind zu berechnen. eine Information mit Kopieren Sie das Mapping WH_TRANSAKTIONEN_4_WHERE und machen Sie daraus WH_TRANSAKTIONEN_5_EXPR. Fügen Sie aus der Palette den Expression-Operator in das Mapping zwischen den Joiner und die Tabelle WH_TRANSAKTIONEN. Ziehen Sie die 3 Felder BESTELLMENGE, BESTELLDATUM und EINZELPREIS aus dem Ausgangsbereich des Joiners in den INGR1-Bereich der Expression. Öffnen Sie das Expression-Editor-Fenster (-> rechte Maustaste auf den Kopf der Expression -> Option Open Details). Erfassen Sie unter dem Reiter Output Attributes die Felder: - BESTELL_TOTAL (NUMBER) - RECHNUNGSDATUM (DATE) - BRUTTOWERT (NUMBER) Benennen Sie den Namen des Operators um z. B. auf Berechnungen. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 102/300 OK Minimieren Sie jetzt alle anderen Operatoren außer dem neuen Expression-Operator, damit Sie Platz auf dem Bildschirm bekommen. Markieren Sie der Reihe nach jedes der neu entstandenen Felder in dem Outgrp-Bereich des Operators. Wählen Sie in dem Properties Inspektor (Attribut Properties) für diese Felder die Option Expression (Achtung die 3 Punkte erscheinen erst, wenn Sie in das Feld klicken). Aufruf des Expression-Editors zu den Ausgabefeldern der Expression Jetzt erscheint der Expression-Editor. Im linken Bereich sind alle Eingabefelder aufgelistet, die wir zuvor in den Eingabebereich des Operators überführt haben. Diese wandern mit einem Doppelklick in den rechten Bereich in dem wir die eigentliche Rechenvorschrift formulieren. Die erste Regel ist für BESTELL_TOTAL festzulegen: Doppelklick auf BESTELLMENGE Doppelklick auf das Malzeichen Doppelklick auf EINZELPREIS Es entsteht der folgende Ausdruck: Expression Bestell_Total Sie können natürlich auch direkt in das Editor-Feld schreiben. Das ist manchmal schneller als ein Doppelklick auf die entsprechenden Symbole. Aber so kann man sich nicht verschreiben. Der erste Ausdruck ist fertig. OK Formulieren Sie die zweite Regel in dem Sie auf Bestelldatum die Zahl 20 addieren. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 103/300 Expression Rechnungsdatum Und die dritte Berechnung für den Bruttowert ist etwas komplexer. Hier werden 16% des Gesamtwertes berechnet und zu dem Gesamtwert hinzu addiert. Expression Bruttowert Sie können für alle Berechnungen auch ein Validate durchführen, das erspart späteres Korrigieren. Überführen Sie jetzt die neuen Felder des Ausgangsbereichs der Expression in die Tabelle WH_TRANSAKTIONEN. Die Felder RECHNUNGSDATUM und BRUTTOWERT entstehen dort neu. Für das Feld BESTELL_TOTAL müssen Sie die bestehende Verbindung zu dem Joiner vorher löschen. Synchronisieren Sie die Tabelle WH_TRANSAKTIONEN mit dem Modul Warehouse (rechte Maustaste Synchronize). Achten Sie darauf dass Sie die Option Outbound wählen, damit Änderungen aus dem Mapping in die Tabellendefinition des Moduls übertragen werden und nicht umgekehrt. Generieren Sie die geänderte Definition der Tabelle WH_TRANSAKTIONEN mit dem Control Center (Achtung Option REPLACE). und erzeugen Sie das neue Mapping. Betrachten Sie sich die Tabelleninhalte über den Data Viewer Die neuen Tabelleninhalte von WH_TRANSAKTIONEN Tip: Wir haben in diesem Beispiel alle Rechenoperationen in eine Expression hineingehängt. Das war bewusst so gemacht. Wir hätten auch für jede Expression einen separaten Operator wählen können. Allerdings würde diese Vorgehensweise das Mapping mit unnötig vielen Operatoren auffüllen und es wäre unübersichtlich. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 104/300 Der neue Zwischenstand: Das Mapping MP_TRANSAKTIONEN_5_EXPR CASE Strukturen im Expression Builder Der CASE Ausdruck macht SELECT-Abfragen flexibler. Das CASE gehört mit zu den mächtigsten Sprachmitteln des heutigen SQL. Es ersetzt das schwerer verstehbare DECODE. Mit dieser Konstruktion können manche Prüfroutinen oder Lookups in andere Tabellen entfallen. Bedingte Verarbeitungen und Prüfungen sind leicht möglich. Es ist auch ein wichtiges Hilfsmittel bei der noch zu besprechenden Thematik „Mengenbasiertes oder Satzbasiertes Laden“. Die CASE-Klausel kann die folgende Form haben: SELECT CASE feldname (oder Ausdruck) WHEN ’Wert_X’ THEN ’Returnvalue_X’ WHEN ’Wert_Y’ THEN ’Returnvalue_Y’ ELSE ’Kein Wert’ END FROM Tabelle; Um sicher zu sein, ob eine besondere Variante möglich ist, kann man entsprechende Tests mit der DUAL-Tabelle durchführen. select case 1 when 1 then 'EINS' when 0 then 'NULL' else 'NICHTS' end from dual; Je nachdem, was Sie an Stelle der 1 einsetzen liefert der Gesamtausdruck entsprechende Werte zurück. Anforderung: In dem vorhergehenden Beispiel konnten wie im Data Viewer für das berechnete Feld BESTELL_TOTAL einen 0-Wert finden. Die Ursache liegt in dem Feld BESTELLMENGE das ebenfalls eine 0 beinhaltet. Offensichtlich gibt es Bestellungen, in denen nichts bestellt wurde. Diese Fehlbestellungen sollten markiert und später ausgesondert werden. Die Markierung soll in einem zusätzlichen Feld „FEHLMENGE“ aufgenommen werden. Wenn eine Fehlmenge auftritt, soll dort eine 1 eingetragen werden. Kopieren Sie das Mapping WH_TRANSAKTIONEN_5_ EXPR und machen Sie daraus WH_TRANSAKTIONEN_6_CASE. Ziehen Sie eine zusätzliche Expression in das Mapping-Feld zwischen den Joiner und die Tabelle WH_TRANSAKTIONEN und rechts unterhalb der bestehenden Expressionen BERECHNUNGEN. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 105/300 (Wir erzeugen einen zusätzlichen Operator, um die Thematik CASE hervorzuheben und um zu zeigen, wie Expressions kombiniert werden können.) Überführen Sie das Feld BESTELL_TOTAL aus dem Ausgabebereich der Expression BERECHNUNGEN in den Eingabebereich der neuen Expression. Editieren Sie die neuen Expression (-> rechte Maustaste -> Open Details) indem Sie das neue Feld FEHLMENGE (number) unter dem Reiter Output Attributes erfassen. Benennen Sie die Expression Fehlmenge. Öffnen Sie für das neue Feld Fehlemenge den Expression Editor über den Properties Inspektor. Fügen Sie die folgende CASE-Anweisung ein: Nachdem Sie den Editor geschlossen haben überführen Sie das Feld FEHLMENGE der neuen Expression in die Tabelle WH_TRANSAKTIONEN. Synchronisieren Sie die Tabelle WH_TRANSAKTIONEN wieder über die Synchronize-Option Outbound. Generieren Sie die Tabelle WH_TRANSAKTIONEN und das neue Mapping und testen Sie es. Jetzt müssten alle fehlerhaften Liefermengen mit 1 markiert sein. Markierung von fehlerhaften Bestellmengen mit 1 in dem Feld FEHLMENGE Der neue Zwischenstand: Das Mapping MP_TRANSAKTIONEN_6_CASE Das Mapping MP_TRANSAKTIONEN_6_CASE Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 106/300 2. Beispiel Zur besseren Übung hier noch ein zweites Beispiel: In der Kundentabelle ist ein Statusfeld enthalten um Kunden in Privat- oder Firmenkunden zu kategorisieren. In einem Auswertebericht soll jedoch nicht der Code „P“ bzw. „F“ abgebildet werden, sondern der sprechende Text „Privatkunde“, „Firmenkunde“ bzw. ein Fehlertext, wenn kein Wert vorhanden ist. Die SQL-Konstruktion lautet: Hierzu kann man eine weitere Expression zwischen den Joiner und der Tabelle WH_TRANSAKTIONEN setzen und in der Tabelle ein weiteres Feld STATUSBESCHREIBUNG aufnehmen. Diese CASE-Lösung im Expression Builder lautet: Verwendung von CASE im Expression Builder Alles andere erfolgt analog wie in dem vorherigen Beispiel. Die CASE-Anweisung wird sehr häufig verwendet. Diese Beispiele zeigen aber auch wie schnell man iterativ die Mappings erweitern kann und zugleich das nötige Maß an Übersichtlichkeit behält. Deduplicator Operator (DISTINCT Option) Zum Erstellen von Listen mit eindeutigen Einträgen wird in der SQL-Sprache die DISTINCT-Option verwendet Anforderung: Erstellen Sie eine Tabelle mit den Nummern aller verkauften Artikel pro Jahr. Hierzu wird aus der Toolbox der Deduplicator-Operator verwendet und Sie müssen über eine Expression die Jahreszahl aus dem Bestelldatum ableiten. Kopieren Sie das Mapping WH_TRANSAKTIONEN_6_CASE und machen Sie daraus WH_TRANSAKTIONEN_7_DISTINCT. Ziehen Sie den DEDUPLICATOR-Operator in das Mapping-Feld rechts neben die Tabelle WH_TRANSAKTIONEN. Ziehen Sie zusätzlich einen Expression-Operator in das Feld. Überführen Sie aus der Tabelle WH_TRANSAKTIONEN die Spalte Bestelldatum in den Expression-Operator und fügen Sie in diesem Operator das Output-Feld Jahr (varchar2(4)) ein. Benennen Sie den Operator JAHR. Leiten Sie in dem Expression-Operator die Jahreszahl nach der folgenden Funktion ab: to_char( INGRP1.BESTELLDATUM ,'YY'). Überführen Sie jetzt das Feld ARTIKELNR aus der Tabelle WH_TRANSAKTIONEN und das Ausgabefeld der Expressen JAHR in den INOUTGRP1-Bereich des Deduplicators. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 107/300 Erstellen Sie eine neues Tabellenobjekt BESTELLTE_ARTIKEL rechts neben dem Deduplicator. Führen Sie die beiden Felder des Deduplicators in die neue Tabelle. Synchronisieren Sie die neue Tabelle mit dem Modul WAREHOUSE (-> rechte Maustaste auf den Kopf der neuen Tabelle -> Option Create And Bind). Generieren Sie die neue Tabelle und das neue Mapping. Testen Sie es und betrachten Sie sich die neue Tabelle in dem Data Viewer. Der Zwischenstand des Mappings MP_TRANSAKTIONEN_7_DISTINCT Tip: Umgang mit dem Data Viewer Der Data Viewer wird die Sätze aus der neuen Tabelle so anzeigen, wie sie die Datenbank liefert, also unsortiert. Das ist gerade bei einer mit DISTINCT erzeugten Tabelle nicht sehr leserlich. Die SQLSchlüsselwörter ODER BY feldname können hier helfen. Unter der Option Where Clause im Data Viewer kann man diese Schlüsselwörter eintragen. Allerdings haben wir keine Where-Klausel und müssen diese simulieren: Testen Sie den Ausdruck: 1=1 order by Jahr,Artikelnr. Data Viewer mit „simulierter WHERE-Klausel“ Aggregieren von Daten (SUM, AVG) Für die Aggregation von Daten (SUM, AVG usw.) ist der Aggregator-Operator zuständig. Sie hängen ihn zwischen Quell- und Zieltabelle und dort nimmt er die aggregierten, sowie die Group-By-Felder auf. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 108/300 Die Handhabung des Operators weicht von den bisher beschriebenen etwas ab, denn für das zu generierende SQL sind zwei Komponente zu definieren: o Schlüsselwörter wie: SUM, AVG, COUNT, MAX, STDDEV, STDDEV_POP, STDDEV_SAMP, VARIANCE, VAR_POP, VAR_SAMP und o Die Group By Klausel Anforderung: Erstellen Sie eine Tabelle mit den aggregierten Umsätzen pro Kunde. Das zugehörige SQL zu dieser Anforderung lautet: SELECT SUM(Feld_X) FROM Tabelle_X GROUP_BY Feld_y Kopieren Sie das Mapping WH_TRANSAKTIONEN_7_DISTINCT in das neue Mapping WH_TRANSAKTIONEN_8_AGG. Erstellen Sie eine neue Tabelle mit dem Namen UMSATZ_PRO_KUNDE und platzieren Sie diese rechts neben die Tabelle WH_TRANSAKTIONEN. Ziehen Sie den Aggregator-Operator in den Editor zwischen die Tabelle WH_TRANSAKTIONEN und die neue Tabelle. Überführen Sie die Felder KUNDENCODE und BESTELL_TOTAL in den INGR1-Bereich des Aggregators. Definieren Sie jetzt den GROUP BY Ausdruck: Markieren Sie mit der Maus den Kopf des Aggregators. In dem Properties Inspektor erscheint jetzt ein Feld mit dem Namen Group By Clause. Über dieses Feld gelangen Sie in den Group By Claus Editor. Festlegen der GROUP BY Klausel Schieben Sie das Feld KUNDENCODE in die rechte Fläche OK. In der Mapping-Fläche sehen Sie jetzt, dass das Feld KUNDECODE in dem OUTGR1-Bereich des Aggregators erscheint. Erfassen Sie jetzt zusätzlich für den Ausgabebereich des Aggregators das Feld SUMME_PRO_KUNDE (Analog dem Expression-Editor) (-> Rechte Maustaste auf den Kopf des Aggregators -> Open Details). Benennen Sie den Aggregator SUMME_PRO_KUNDE. Markieren Sie das neue Feld SUMME_PRO_KUNDE und Sie sehen in dem Properties Inspektor Fenster ein Feld mit dem Namen EXPRESSION. Hierüber gelangen Sie in den Expression Editor. Wählen Sie unter: Function -> SUM ALL/DISTINCT -> ALL Attribute -> BESTELL_TOTAL Wählen Sie abschließend: Use Above Values. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 109/300 Festlegungen für die SUM-Anweisungen Tip: Sie können unter Expression auch manuell Einträge vornehmen. Z. B. sind alle analytischen Funktionen hier möglich. Erstellen Sie die neue Tabelle in dem Modul WARHOUSE (-> rechte Maus auf den Kopf der Tabelle -> Create And Bind). Generieren Sie die neue Tabelle und das Mapping über das Control Center und testen Sie das Mapping. Das Ergebnis im Data Viewer Das erweiterte Mapping sieht jetzt so aus: Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 110/300 Das Mapping MP_TRANSAKTIONEN_8_AGG Lookup Tabellen lesen Eine der häufigsten Transformationen bei dem Laden von Daten in das Warehouse, ist das Dekodieren von Schlüsselinformationen über Referenzwerte in einer anderen Tabelle. Hierzu nutzen Sie den Key-Lookup-Operator. Anforderung: Die in dem Vorbeispiel erstellte Tabelle Umsatz_Pro_Kunde soll um RegionenInformationen angereichert werden, d. h. pro Kunde sind Bundesland und die Wohnregion des Kunden hinzuzufügen. Als Referenztabelle dient die Tabelle ORTE aus dem SRC-Schema. Kopieren Sie das Mapping WH_TRANSAKTIONEN_8_AGG WH_TRANSAKTIONEN_9_LOOKUP. in das neue Mapping Eine nachträgliche Änderung in ein Mapping einbauen Um später einen Lookup auf die Orte-Tabelle durchführen zu können, ist ein Schlüssel nötig: der OrteSchlüssel. Dieser ist in der Tabelle UMSATZ_PRO_KUNDE nicht enthalten. Wir haben zwei Möglichkeiten zu dieser Nummer zu gelangen: Wir nehmen einen separaten Lookup auf die Kundentabelle vor, um die Ortenummer zu erhalten oder wir gehen zurück in den Joiner und ziehen aus der Quelltabelle das Feld ORTNR nach. Die zweite Variante ist sicher besser, denn die erste hätte eine zusätzliche Leseoperation auf die Kundentabelle zur Folge, wir würden in einem Mapping zwei mal auf die Kundentabelle zugreifen. Führen Sie das Feld ORTNR aus der Tabelle KUNDE in den entsprechenden Eingangsbereich des Joiners. Zur besseren Orientierung können Sie für den Joiner das Display Set für den Kunden selektieren. Beachten Sie, dass das Feld auch durch den Filter-Operator zu führen ist. Ziehen Sie das Feld weiter in die Tabelle WH_TRANSAKTIONEN. Aus WH_TRANSAKTIONEN muss es jetzt noch in den Aggregator SUMME_PRO_KUNDE gelangen. Nehmen Sie das neue Feld ORTENR über den Properties-Inspektor in die GROUP BY Klausel mit auf. ORTENR wird danach in dem Ausgangsbereich des Operators erscheinen. Das Ganze sieht etwas aufwändig aus, aber durch die graphische Unterstützung behält man den Überblick. Die Änderung ist dennoch schnell durchgeführt. Der Vorgang zeigt aber auch, dass komplexere Mappings nicht von Beginn an geplant werden können und Änderungen immer auf der Tagesordnung stehen. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 111/300 Ziehen Sie den Lookup-Operator aus der Palette zwischen den Aggregator SUMME_PRO_KUNDE und die Tabelle UMSATZ_PRO_KUNDE. Es erscheint der Lookup-Operator Wizard mit der ersten Aufforderungen den neuen Operator zu benennen. Geben Sie dem neuen Operator den Namen ANREICHERN_KUNDE. (Step 1/5) Next (Step 2/5) Next (Step 3/5) Jetzt sehen Sie eine Liste mit allen Operatoren des gesamten Mappings. Aus dieser Liste können Sie ein Feld auswählen, das als Eingabeschlüsselwert für den Lookup-Operator dient, also der Wert, der umzuschlüsseln ist. Das ist in unserem Fall das Feld ORTNR aus dem Operator SUMME_PRO_KUNDE (Aggregator). Next. (Step 4/5) Es erscheint der Schritt in dem Sie die Lookup-Tabelle auswählen. Wählen Sie im oberen Bereich die Tabelle ORTE aus dem Modul SRC. Im unteren Bereich selektieren Sie bei Lookup Key die Ort_NR (das ist das Schlüsselfeld der referenzierten Ortetabelle und rechts unter Input Attribut das Feld ORTNR (das ist das Input-Feld, das wir in dem vorherigen Schritt gewählt haben. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 112/300 Next (Step 5/5) Im letzten Schritt sind die Rückgabefelder des Lookup-Operators zu wählen. Hier könnten Sie auch noch zusätzliche Funktionen für jedes Feld in dem rechten Bereich (dort wo NULL steht) hinterlegen. Das ist in unserem Fall aber nicht nötig. Next und Finish Ziehen Sie jetzt die beiden Felder BUNDESLAND und REGION in die Tabelle UMSATZ_PRO_KUNDE. Synchronisieren Sie die Tabellen WH_TRANSAKTIONEN und UMSATZ_PRO_KUNDE mit dem Modul WAREHOUSE (-> rechte Maustaste auf den Kopf der jeweiligen Tabellen -> Synchronize > Option Outbound....) Sie müssen jetzt die geänderten Tabellen neu generieren: WH_TRANSAKTIONEN UMSATZ_PRO_KUNDE und natürlich das neue Mapping Testen Sie es und betrachten Sie sich die Tabelle UMSATZ_PRO_KUNDE im Data Viewer Tip: Denken Sie bei Ihren Tests daran, die Tabelle UMSATZ_PRO_KUNDE auf TRUNCATE/INSERT zu stellen, damit Sie nicht aus Versehen bei wiederholten Läufen mit alten Werten arbeiten. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 113/300 NULL-Werte verhindern Bei der Durchsicht der Ergebnisdaten in der Tabelle UMSATZ_PRO_KUNDE ist zu erkennen, dass in einigen Sätzen kein Wert für BUNDESLAND und REGION angezeigt wird. Das ist auch erklärbar, denn der Lookup-Operator wird im SQL-Code mit einem Outer-Join realisiert, der für den Fall, dass kein Wert in der Referenztabelle gefunden wird, ein NULL-Wert zurückliefert. Für diesen Fall ist es praktisch, diese Sätze mit einem String z. B. „Keine oder falsche Ortsangabe“ zu markieren. In einem nachgelagerten Schritt können Sie diese Sätze herausfiltern und korrigieren. Wir lösen die Aufgabe, indem wir in dem Lookup-Operator ANREICHERN_KUNDE für die Rückgabefelder BUNDESLAND und REGION eine Funktion z. B. NVL mitgeben. Öffnen Sie dazu den Lookup-Editor des Operators ANREICHERT_KUNDE (-> rechte Maustaste auf den Kopf des Operators -> Open Details). Gehen Sie auf No-match Rows. Tragen Sie unter Default Value den String ’Keine oder falsche Ortsangabe’ ein. Achten Sie darauf dass das Zielfelder in der Tabelle UMSATZ_PRO_KUNDE (BUNDESLAD und REGION die richtige Größe haben. Der String ist sehr lang. Sonst gibt es später beim Starten des Mappings Fehler. Das Festlegen Markierungstexten für den NULL-Fall Die Zieltabelle sieht jetzt so aus: Die Tabelle UMSATZ_PRO_KUNDE mit der Markierung „Keine oder falsche Ortsangabe“ im NULLFall Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 114/300 Das Mapping sieht jetzt so aus: Das Mapping MP_TRANSAKTIONEN_9_LOOKUP Tip: Das Schlüsselfeld aus der Lookup muss ein Primary Key oder zumindest ein Unique Key-Feld sein, d.h. eindeutige Werte enthalten. Ist dies nicht der Fall, wird der Validate dies als Problemfall melden. Es kann später zum Laufzeitpunkt zu Abbrüchen kommen. Set Operator (UNION, UNION ALL, MINUS, INTERSECT) Set ist ein Mengenoperator, mit dem die Ergebnismengen von 2 und mehr SELECT-Befehlen wie in der Mengenlehre weiterverarbeitet werden. Es gilt: UNION: Die Ergebnisse von 2 oder mehreren SELECTs werden zusammengefasst, doppelte Sätze eliminiert. UNION ALL: Wie vorher, jedoch bleiben doppelte Sätze erhalten MINUS: Die Ergebnismenge eines zweiten SELECTS wird von der Ergebnismenge des ersten SELECTS abgezogen. INTERSECT: Es werden nur diejenigen Sätze geliefert, die in beiden (oder mehr) SELECTErgebnismengen vorhanden sind. Beachten Sie bei dem Umgang mit dem SET-Operator, dass alle SELECTs die gleiche Feldstruktur haben. Die Zieltabelle kann davon abweichen aber nur, wenn es die implizite Typkonvertierung der Datenbank erlaubt. Wandlungen von NUMBER nach VARCHCHAR2() sind z. B. erlaubt umgekehrt führt es jedoch zu einem Fehler. Anforderung: Es sollen alle Kunden gefunden werden, die noch nicht bestellt haben. Vorgehensweise: 1. Zusammenfassen von allen Firmen- und Privatkunden (UNION) 2. Abziehen dieser gefundenen Kundenmenge von der Ursprungstabelle Kunde aus dem Schema SRC (MINUS). Erstellen Sie ein neues Mapping mit dem Namen MP_SET Ziehen Sie die Tabellen WH_TRANS_FIRMA und WH_TRANS_PRIVAT aus dem Modul WAREHOUSE und die Tabelle KUNDE aus dem Modul SRC in die Editorfläche. Ziehen Sie jetzt 2 Set-Operatoren in den Editor. Für den ersten Set-Operator versorgen Sie die INGRP-Bereiche durch die Tabellen WH_TRANS_FIRMA und WH_TRANS_PRIVAT. Setzen Sie seine Properties auf UNION (Properties Inspector) Den zweiten SET-Operator versorgen Sie bei INGRP1 mit der Tabelle KUNDE und den INGRP2Bereich durch den OUTGRP-Bereich des ersten Set-Operators. Nehmen Sie allerdings jeweils nur Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 115/300 das Kundennummern (Code)-Feld mit. Stellen Sie die Eigenschaften des zweiten Operators auf MINUS. Erzeugen Sie jetzt eine neue Tabelle KUNDE_OHNE_BESTELLUNG und überführen Sie das eine Ausgangsfeld des Operators in die neue Zieltabelle. Erzeugen Sie die neue Tabelle in dem Modul WAREHOUSE (-> rechte Maustaste auf den Kopf der Tabelle -> Create And Bind) und generieren Sie die neue Tabelle und das neue Mapping über das Control Center. Testen Sie das Mapping und betrachten Sie sich die Ergebnisse mit dem Data Viewer. Mapping MP_SET Pivoting mit SQL Mitteln - Der Pivot-Operator °°°°° Bezieht sich noch auf das ältere Release°°°°°° Gerade bei dem Verarbeiten von Textdateien kann es vorkommen, dass in den Columns eines Satzes Informationen enthalten sind, die auf mehrere Sätze verteilt leichter verarbeitet werden können. Beispiel: Eine Excel-Tabelle enthält eine Jahresübersicht mit Artikelumsätzen. Die Tabelle besteht aus Spalten mit Monatswerten. Während des Ladens der Excel-Tabelle in das Warehouse müssen aus einem Satz mit 12 Monatswerten 12 Sätzen mit jeweils einem Monatswert entstehen. Diese Aufgabenstellung lösen wir mit dem Pivot-Operator Die Beispieldatei: Artikel_Nr;Januar;Februar;Maerz;Mai;Juni;Juli;August;September;Oktober;November;Dezember 1;3467;652456;8945;7490;7465;84734;3448;64637;33445;9499;84658;747764 5;3467;654256;89234545;749440;744565;846774;7097788;8945337;334545;946799;878458;748764 55;3467;6354556;866775;748990;78905;834644;623478;66547;3367845;949909;8445658;74654764 36;3467;645456;89545;74590;7245;5674;89058;23437;33545;95499;84558;754764 32;3467;645456;86875;7490;74985;8474;6378;6637;3345;9499;8458;74764 23;3467;655456;89845;74690;74665;84674;63878;66837;38345;94899;8458;74764 59;3467;656456;894775;76490;748965;804774;6ß378;669837;388345;94899;847658;74764 2;3467;654656;86456;7690;7465;8474;6378;6637;3345;9499;8458;74764 4;3467;654656;89645;74690;7465;8474;6378;6637;3345;9499;8458;74764 39;3467;686;89890;7490;7465;8474;63078;666437;33345;94992;826458;748964 12;3467;65236;8545;74906;74675;84374;637458;66337;336745;94299;84658;746764 Importieren Sie die Beschreibungsdaten der Flat File Artikelumsatz.csv in das Textmodul Ihres Projektes. „Sampeln“ Sie die Datei. (Wenn die Datei nicht vorhanden ist, erzeugen Sie die Datei aus den vorstehenden Beispielsätzen). Machen Sie daraus eine External Table EX_Artikelumsatz in dem Modul Warehouse. „Deployen“ Sie die External Table und testen Sie den Zugriff über SQL*Plus. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 116/300 Erstellen Sie ein in dem Warehouse-Modul ein neues Mapping mit dem Namen MP_Pivot. Ziehen Sie die neu erstellte External Table EX_Artikelumsatz in den Editor. Erstelle Sie eine neue Tabelle Artikelumsatz und erfassen Sie die Attribute Artikel_nr,Umsatz und Monat wie folgt: Ziehen Sie jetzt den Pivot-Operator aus der Toolbox in die Editorfläche. Ein Wizard startet. Als erstes legen Sie den Namen fest. Nennen Sie ihn UMSATZ_PRO_MONAT. Den nächsten Schritt der Definition In-/Out-Groups überspringen Sie, weil das System bereits die Vorgaben mit INGRP1 und OUTGRP1 getätigt hat. (Sie könnten auch mehrere Eingabegruppe verwenden. Unser Beispiel enthält jedoch nur eines). Im folgenden Schritt übernehmen Sie die Eingabeattribute der Quelle und schieben diese in das rechte Fenster. In unserem Fall sind das alle Attribute der Quelltabelle. Jetzt können Sie die Attribut-Eigenschaften der Felder des Pivot-Operators festlegen, z. B. die Schlüsseleigenschaft eines Feldes. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 117/300 Jetzt müssen Sie die gewünschten Ausgabeattribute des Pivot-Operators festlegen. In unserem Beispiel kennt der Operator bis jetzt nur das Schlüsselfeld Artikel_NR. Erfassen Sie jetzt ein Feld Umsatz um die Umsatzwerte (numerisch) darzustellen und ein Feld Monat für die Monatsnamen. An dieser Stelle ist der Begriff Row Locator zu erklären. In der Quelltabelle sind die Monatswerte in einer Reihe mit zwölf Spalten abgelegt. Jedem Feld dieser Reihe kommt virtuell eine bestimmte Rolle zu, das erste Feld repräsentiert eine Januarsumme das 2. eine Februarsumme usw. In der Zieltabelle gibt es dieses eindeutige Rolle nicht mehr. Hier existiert keine Spaltenposition mehr, anhand der wir erkennen können, ob es sich um einen Januar- oder Februarwert handelt. Um dennoch eine Orientierung zu erhalten um welchen Monat es sich handelt, sollten Sie ein optionales Hilfsfeld für den Monatsnamen einführen. Dieses Feld ist optional aber sinnvoll. Dieses Attribut mit dem Monatsnamen heißt Row Locator. Markieren Sie jetzt das Feld Monat als Row Locator Feld. In dem letzten Schritt legen Sie das Schema der Satzfolgen fest. Das Prinzip des Pivoting besteht darin, für die Anzahl der Spalten einer Quelltabelle eine entsprechende Anzahl Zeilen in der Zieltabelle zu erstellen. Zwölf Spalten produzieren somit zwölf Zeilen und jede Zeile der Quelle Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 118/300 erzeugt eine Gruppe von zwölf Zeilen der Zieltabelle. Jetzt bestimmen Sie die Inhalte der Felder dieser zwölf Zeilen. Fügen Sie zunächst 12 Zeilen ein (Add) Row1 bis Row12. Das Schlüsselfeld Artikel_Nr kann nicht mehr verändert werden, weil es als Schlüsselfeld gebraucht wird. Alle anderen Felder sind mit Null vorbelegt. Legen Sie für das Umsatzfeld in der ersten Zeile das Quellfeld INGRP1.JANUAR fest. Für die zweite Zeile wählen Sie INGRP1.FEBRUAR usw. In der Monatsspalte definieren Sie dann die Monatsnamen für die jeweiligen Zeilen Und jetzt Finish Editor für den Pivoting-Operator Verbinden Sie die OUTGRP-Felder des Pivot-Operators mit der Zieltabelle Pivoting Mapping (Demo: MP_Pivot) Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 119/300 Alle Einstellungen können nachträglich über Edit (rechte Maustaste auf den Kopf des Pivot-Operators wieder geändert werden. Schieben Sie die neue Tabelle Artikelumsatz in das Warehouse-Modul. Generieren Sie die neue Zieltabelle und das neue Mapping und testen Sie es. Das Ergebnis: Inhalte der Ergebnisstabelle Artikelumsatz nach der Pivoting-Operation. Unpivoting mit SQL Mitteln - Der Unpivot-Operator [Der Unpivot-Operator ist analog zu dem Pivot-Operator zu bedienen.] Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 120/300 Unternehmensdaten integrieren – Teil 1 (Textdateien) Integrieren von Textdateien Bislang haben wir nur Tabellen aus einer Oracle Datenbank verarbeitet. Hier sollen weitere mögliche Quellen vorgestellt werden. Eine der wichtigsten Quellen sind Textdateien. Unter Textdateien verstehen wir ASCII (oder EBCEDIC)-Dateien, die auf der Betriebssystemebene vorliegen. In der Regel liegen sie in 2 Formaten vor: 1. Dateien bei denen ein Separator (z. B. ; ) die Felder der Sätze unterteilt (CSV- oder Comma Separated Values-Strukturen). 2. Dateien mit Felder fester Länge (Fixed Length) Zudem können Dateien mehrere Satzarten enthalten. Ein Satzkennzeichen identifiziert die einzelnen Satzarten. Seit dem Datenbank-Release Oracle 9i steht die Technik der External Tables zur Verfügung um Textdateien in die Warehouse-Datenbank einzulesen. Diese Technik ersetzt in den meisten Fällen die davor genutzte Technik des SQL-Loaders. In beiden Fällen ist zunächst die Struktur der Textdatei einzulesen – also der Metadaten – Import durchzuführen. Der WAREHOUSE BUILDER gruppiert die Textdateien in einem separaten Modul. Textdateien sind meist bestimmten Themenbereichen oder Abteilungen zugeordnet. Auch hier helfen die Module, um die unterschiedlichen Textobjekte nach fachlichen Kriterien zusammen zu fassen. Aufgabenstellung: Eine Liste mit Ortsnamen liegt als CSV-Datei vor. Lesen Sie diese ein. Sie bildet später die Grundlage für eine Orte-Dimension. Definieren Sie in dem Design Center unter dem Punkt Files ein neues Modul mit dem Namen FF_Orte Unter Ihrem Projektordner finden Sie den Punkt „Files“. Über die rechte Maustaste wählen Sie dann den Punkt „NEW“. Ein Wizard startet in dem Sie den Namen für das neue Modul anlegen können. Die Angabe über das Verzeichnis in dem die Datei liegt, verbirgt sich hinter einer Location. Sie müssen also jetzt eine Location definieren. Wählen Sie die Option Edit und Sie können genaue Angaben zur Location machen. Ändern Sie am besten auch den Namen der Location z. B. auf LC_FF_ORTE, weil der vorgeschlagene Name sehr lang und wenig sprechend ist. Wählen Sie das Verzeichnis, in dem sich die Beispieldatei Orte.CSV befindet. Wählen Sie über den Wizard das Verzeichnis aus, in dem die Datei zu finden ist. Die Dateien selbst werden nicht angezeigt. Die Dateinamen werden erst bei dem späteren Import-Vorgang festgelegt. (Bei UNIX-Systemen ist hier ein entsprechender UNIX-Pfad anzugeben. Er muss allerdings hierzu von der Windowsumgebung her sichtbar sein). Nachdem Sie Next und Finish gedrückt haben erscheint das neue Modul. Die neue Location (LC_FF_ORTE) finden Sie jetzt auch unter dem Connection Explorer wieder und zwar unter Locations / Files. Starten Sie jetzt den Import-Wizard (-> Rechte Maustaste auf den Namen des neuen Moduls -> Import.) Nachdem Sie die ersten beiden Masken mit Next übersprungen haben, erhalten Sie eine Liste von allen Dateien in dem Verzeichnis, das Sie bei der Definition der Location angegeben haben. Achtung Demodaten: Orte.csv Wählen Sie die Datei ORTE.CSV und schieben Sie diese in das rechte Fenster ( Das ist in unserem Beispiel eine einfache Datei, mit nur einer Satzart, bei der die einzelnen Spalten mit einem Komma getrennt sind. Eine erste Spalte enthält die Spaltenüberschriften). Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 121/300 Next. Jetzt erscheint vor dem Dateinamen ein roter Punkt. Das bedeutet dass die Metadaten für diese Textdatei noch nicht beschrieben sind. Wählen Sie in dem Folgedialog die Option SAMPLE. Im unteren Teil erkennen Sie die ersten Sätze der Datei und eine Zeile mit Spaltenüberschriften. Sie sehen, dass die Textfelder mit einem Hochkomma gekennzeichnet sind. Die Überschriftenzeile können Sie später als Column-Namen nutzen. Die Hochkomma sind noch zu entfernen. Die nächsten Bildschirme können Sie mit Next überspringen, bis Sie auf den Bildschirm zur Angabe der „Field delimiter“ kommen. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 122/300 Entfernen Sie die Hochkomma für die dargestellten Sätze (Enclosures Left / Right). Setzen Sie den Field Delimiter auf Komma. (Das Ergebnis müsste dann aussehen wie rechts dargestellt). In einem der folgenden Dialoge wählen Sie Use the first record as the field names, um die erste Zeile als Spaltenüberschriften zu nutzen. Beenden Sie den Dialog. Die Metadaten für die Ortedatei sind jetzt vorhanden. Über das Kontextmenü (rechte Maustaste auf den Dateinamen) können sie im Projekt-Explorer nachträglich Eintragungen vornehmen, jedoch nicht den Dateinamen bzw. Pfad. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 123/300 Anzeigen der Eigenschaften einer bereits eingelesenen Textdatei Fragen an den Experten: Wie werden EBCDIC-Dateien eingelesen? EBCDIC-Dateien werden genauso gelesen, wie ASCII-Dateien. Hier stellt man jedoch einen anderen Zeichensatz im Verlauf des Samplings ein. Die Tatsache, dass OWB die ersten 1000 Sätze zum Analysieren bereits anzeigt und bei EBCDIC auch gleich in ein ASCII-lesbares Format umwandelt, ist sehr hilfreich um z. B. eine unbekannt Satzlänge für Fixed-Format-Dateien herauszufinden. Werden manche Zeichen nicht richtig dargestellt, so hat man die falsche Satzart erwischt. Wie werden Dateien z. B. auf Unix-Servern eingelesen? Warehouse Builder kann im Verlauf des Samplens nur Dateien lesen, die in dem unmittelbaren Zugriff über das Dateiverzeichnis des Entwicklungsrechners liegen. Sind die einzulesenden Dateien auf einem anderen Rechner, so müssen die Verzeichnisse (Laufwerke) dieses anderen Rechners dem Entwicklungsrechner bekannt gemacht werden. Das gilt auch für UNIX Betriebssysteme. Ist dies nicht möglich, so muss für den Zeitraum der Entwicklung die Datei (eine Beispieldatei oder die ersten 100 Sätze der Datei) auf den Entwicklungsrechner kopiert werden. Tip: Wenn Sie Textdateien mit vielen Spalternüberschriften besitzen und diese nicht einzeln schreiben wollen, suchen Sie nach Tabellen mit analogen Spaltennamen. Erstellten Sie sich ein Mapping in dem Sie als Ziel eine neue Textdatei wählen. Indem Sie die ganze Gruppe aus der Tabelle in die Zieldatei ziehen, übernimmt diese die Spaltennamen. Erzeugen Sie die Datei in einem Textmodul neu und Sie haben dort die gewünschte Tabellenbescheschreibung. Einlesen von Textdateien über External Tables Textdateien lädt man seit dem Oracle 9i Datenbank-Release am einfachsten mit den sog. External Tables in die Datenbank. External Tables behandeln Sie wie normale Tabellen. In der Projektarbeit hat sich die Überlegenheit der External Tables gegenüber dem SQL*Loader deutlich gezeigt. Die Vorteile: 1. Staging -Tabellen entfallen. Der gesamte Ladevorgang gestaltet sich homogener und kompakter, weil kein separates Programm neben der Datenbank zusätzlich zu starten ist. 2. Es können Joins auch auf externe Tabellen gebildet werden. 3. Zum Filtern, Aggregieren und Wandeln können Sie SQL-Mittel und PL/SQL-Prozeduren nutzen. 4. Das Datenbanksystem regelt selbständig die Parallelisierung im Verlauf der Verarbeitung der Sätze, die aus der Textdatei gelesen werden. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 124/300 Erstellen einer External Table aus einer Textdatei-Definiton Definieren Sie unter dem Modul WAREHOUSE eine External Table mit dem Namen EX_ORTE (-> Rechte Maustaste und dann „New“) Im Verlauf des Wizard-Dialogs erscheint eine Liste aller Textdateien, die in dem Projekt definiert sind. Wählen Sie die Datei Orte_CSV Next Wählen Sie die Location an der sich die Textdatei befindet. Beenden Sie den Dialog mit Finish. Die Definition zur Textdatei OREe_CSV liefert also die Vorlage für die External Table-Definition EX_ORTE. Erzeugen einer Directory-Definition in der Datenbank Bevor Sie die External Table generieren und nutzen können, brauchen Sie eine DirectoryAnweisung. Die Fundstelle der Textdatei legt eine CREATE DIRECTORY Anweisung fest. Das macht die Pfadangabe unabhängig von der eigentlichen External Table-Definition. Sie ist variabel und jederzeit auch automatisiert änderbar. Bei einer Änderung des Pfades ist nur die CREATE DIRECTORYAnweisung zu erneuern. Die Definition der External Table jedoch bleibt stabil. Beispiel für eine Directory-Definition: CREATE DIRECTORY link-name AS ‘//dir/pfad-name’; Oder die in diesem Beispiel zu generierende Definition: CREATE DIRECTORY LC_FF_ORTE AS '’D:\szenario\testdaten'; Sie können alle bereits bestehenden Directory-Einträge in der Datenbank abfragen mit: select * from all_directories; Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 125/300 Festlegen von physischen Ablagen von Dateien mit Hilfe von sog. Directory-Objekten Generieren von Directory-Objekten für External Tables Der WAREHOUSE BUILDER realisiert die Directory-Festlegung über die Location, die dem Textmodul zugewiesen wurde. Diese Zuweisung haben Sie bei der Definition des Moduls vorgenommen. Rufen Sie das Control Center auf. Registrieren Sie die Location, die Sie zu dem Textmodul finden. Betrachten Sie die Location zu dem Modul Warehouse. Registrieren der Text Modul-Location Nach dieser Registrierung finden Sie unter der Location für das Modul in dem sich die External Table befindet einen von dem Warehouse Builder automatisch erzeugten Eintrag: Einen Connector. Der Name entspricht dem Namen der Location von dem Textmodul. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 126/300 Connection, die das System gebildet hat. Dies ist die Vorlage für die CREATE DIRECTORY-Definition Diese Connection ist als erstes zu generieren. Dies erzeugt die CREATE DIRECTORY-Definition. Achtung: Im Jüngsten OWB-Release 10G R2 wird die Directory-Definition automatisch zusammen mit der External Table-Definition erstellt, wenn sie noch nicht da ist. Generieren Sie jetzt die External Table. Tip: Der Deployment Manager kann schnell unübersichtlich wirken, wenn man ihn falsch nutzt. Wenden Sie doch folgenden Trick an: Markieren Sie in dem Deployment Manager das Projekt. Im rechten Fenster erscheinen jetzt alle Objekte des gesamten Projektes. Wenn Sie bislang alle Objekte generiert haben, so müssen nur die beiden noch nicht generierten Einträge für das Directory (Connection die External Table „deployen“. als noch nicht deployed ) und aufgelistet sein. Diese können Sie jetzt Test der External Table Definition Wie stellen Sie fest, ob die External auch wirklich funktioniert? Starten Sie SQL*Plus und gehen Sie in Ihr Zielschema, in das Sie die External Table generiert haben. Setzen Sie folgendes Kommando ab: Test der External Table-Definition mit SQL Plus Sie können aber auch den Data Viewer verwenden indem Sie mit der rechten Maustaste auf die External Table drücken und Data wählen. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 127/300 Die External Table wird verwendet wie eine Tabelle, also kann man auch den Data Viewer verwenden, obwohl die hier gezeigten Sätze nicht in der Datenbank stehen. External Tables in einem Mapping benutzen External Tables benutzen Sie in den Mappings wie normale Tabellen. Erzeugen Sie in dem Modul WAREHOUSE ein Mapping MP_EX_Orte Ziehen Sie aus der Palette das Symbol für die External Tables in die Editorfläche. Wählen Sie in dem erscheinenden Dialog die External Table EX_ORTE unter dem Modul WAREHOUSE aus. Erzeugen Sie eine neue Tabelle in dem Mapping-Editor, indem Sie das Tabellensymbole aus der Palette in die Editorfläche rechts neben die External Table ziehen und unter Create unbound operator with no attributes den Namen Orte_Tab anlegen. Ziehen Sie die Spalten der External Table in die neue Tabelle. Erzeugen Sie die neue Tabelle auch in dem Modul WAREHOUSE (-> rechte Maustaste auf den Kopf der neuen Tabelle -> Option Create and Bind). Drücken Sie OK und kopieren Sie alle Columns der External Table in die neue Zieltabelle. Verwenden einer External Table Generieren Sie die neue Tabelle ORTE_TAB und das Mapping und testen Sie das Mapping und die Ergebnisse in der Tabelle über den Data Viewer. Dies war ein sehr einfaches Mapping. Bedenken Sie, dass sie alle SQL-Lese-Operationen auf External Tables durchführen können, also auch Joiner, Splitter, Filter, Aggregationen, Pivot, Unpivot, Table Functions.... Weiter unten folgen hierzu weitere Techniken. Einlesen von Dateien mit dem SQL Loader (Dies ist eine alte Variante oder nur anzuwenden, wenn nur eine Oracle 8i-Datenbank vorhanden ist. Daher wird dieser Abschnitt sehr knapp gehalten und ist nur zur Vollständigkeit aufgenommen. Arbeiten Sie den Abschnitt nur dann durch, wenn für Sie das Erzeugen von Control Files für den Loader wichtig ist .) Dateien können in einem Oracle Warehouse auch über den klassischen SQL Loader angebunden werden. Dieses separate Programm ist außerhalb der Datenbank zu starten. Der Warehouse Builder Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 128/300 generiert den Steuer-Code (CTL-Dateien) für den SQL-Loader. Die Metadaten zu den Dateien sind innerhalb des OWB-Repositories vorgehalten. Dateien werden innerhalb der Mappings wie Tabellen behandelt. Dateien können die Strukturen CSV (Comma Seperated Value) oder Fixed Length (feste Spaltenlänge) und mehrere Satzarten haben. Erzeugen Sie in dem Modul WAREHOUSE ein Mapping MP_SQL_LOADER Ziehen Sie das Flat File-Symbol aus der Palette in den Editor. Wählen Sie die Flat File Orte_CSV und bestätigen Sie mit OK bzw. Finish. Ziehen Sie das TABLE-Symbol aus der Palette in den Editor und erstellen Sie eine neue Tabelle Orte_Neu.. Verbinden Sie jetzt die Flat File-Attribute von der Quelle in die Zieltabelle. Generieren Sie alle Objekte. Anstelle der Generierung in die Datenbank wird ein Control-File erzeugt. Der Speicherort für diese Control File ist unter Configuration des Mapping anzugeben. Das Ergebnis ist ein Control-File-Script für den SQL-Loader: Zum korrekten Lauf muss die Location des Moduls, aus dem die Textdatei stammt, registriert sein (rechte Maustaste auf den Location-Namen und dann Option Register). Sie können auch im Verlauf des Deploy-Prozesses das CTL-File über die Deploy To File Option in ein Zielverzeichnis Ihrer Wahl schreiben und unabhängig von dem Warehouse Builder mit eigenen Mitteln weiterarbeiten, z. B. mit einer Batch-Datei für den Loader-Aufruf: sqlldr userid=DW/DW,control=MP_ORTE.ctl,log=log.log Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 129/300 Die Operatoren - Teil2: Generische und wiederverwendbare Komponenten und Text-Output Verwenden von Funktionen und Prozeduren – Die erweiterbare Funktionsbibliothek Es gibt Anforderungen, die nicht mit einfachen SQL Befehlskomponenten zu lösen sind. Hier helfen zusätzliche PL/SQL- oder Java-Funktionen. Solche Funktionen sind in der Funktionsbibliothek zu finden. Sie können eigene Funktionen innerhalb Warehouse Builder programmieren oder bestehende aus einer Datenbank importieren oder mit anderen Werkzeugen die Funktionen erstellen und sie dann über die Datenbank importieren. Diese Funktionen/Prozeduren sind die Schnittstelle hin zur freien Programmierung. Beliebige Aktivitäten in der Datenbank sind möglich. Die erweiterbare Funktionsbibliothek des Warehouse Builder ist damit ein Sammelort für alle zum Aufbau des Warehouse nötigen Routinen. In Funktionen oder Prozeduren sind auch solche Rechen- und Transformationsoperationen zu konzentrieren, die man an anderen Stellen wieder verwenden will. Die Expressions, die wir bereits kennen gelernt haben, finden wir nur innerhalb eines Mappings fest hinterlegt. Man kann den Code allenfalls mit Cut/Paste in ein anderes Mapping kopieren, dann ist es aber nicht mehr derselbe Code und er kann getrennt und ohne Synchronisation geändert werden. Funktionen sind nur innerhalb der Funktionsbibliothek zu ändern. Nachdem sie in die Datenbank „deployed“ wurden, wirken sie in allen Mappings in denen sie verwendet wurden gleichermaßen. Sie können Funktionen und Prozeduren an zwei Stellen definieren: innerhalb der Module über den Global Explorer Definitionsorte von Funktionen und Prozeduren Die Möglichkeit Funktionen und Prozeduren in Modulen zu definieren ergibt nur einen dokumentarischen Sinn. Wenn die Objekte später die Datenbank generiert werden, sind sie auch allgemein zugänglich. Auch wenn Sie innerhalb eines Mappings ein Objekt heranziehen, haben Sie Zugriff auf alle Funktionen und Prozeduren in allen anderen Modulen. Tip: Bleibt die Frage, wo man die Objekte am sinnvollsten definiert. Hier gibt es nur die Regel: Beziehen sich Funktionen nur auf die Tabellen in dem jeweiligen Modul, dann sollte man sie dort Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 130/300 ablegen. Man kann somit Metadaten auf Modul-Ebene leicht mit anderen Projekten austauschen und hat alle Objekte zusammen. Sind es generelle Funktionen (z. B. Zeitumrechnungen, oder testdatengenerierende Funktionen), so sollte man sie in dem Global Explorer ablegen. Über die Copy-Funktion können Sie bestehende Routinen als Vorlage nutzen. Das erleichtert die Arbeit. Neue Funktionen/Prozeduren erstellt Sie über den Wizard der jeweils immer über die rechte Maustaste und dann über „New ...“ startet. Aus dem komfortablen Editor heraus kann die neu erstellt Routine direkt in die Datenbank gestellt und getestet werden. Tip: Das Zusammenfassen wichtiger und immer wieder zu benutzenden Funktionen/Prozeduren in einer Bibliothek ist hilfreich, um eine projektübergreifende Bibliothek über einen längeren Zeitraum wachsen zu lassen. Es entsteht eine sog. Ressourcen-Bibliothek, die über den Metadaten-Loader in eine beliebige OWB-Umgebung hineinkopiert bzw. wieder um neue Funktionen ergänzt und herausgeholt werden kann. Anforderung: Für die beiden Tabellen WH_TRANS_PRIVAT und WH_TRANS_FIRMA soll eine Bonusberechnung durchgeführt werden. Die Berechnung des Bonus unterliegt mehreren Regeln: Für Firmenkunden: - werden bis 50% des Umsatzes mit 2% belegt - weitere 20 % mit 4% Für Privatkunden: - werden die ersten 30% mit 1% des Umsatzes belegt - weitere 10% mit 2%. Es ist eine Funktion zu erstellen, die sowohl für Firmen- und Privatkunden einsetzbar ist. Die Funktion wird zwei Aufrufparameter haben: - Statusflag (F oder P) - BESTELL_TOTAL. Sie wird eine ermittelte Bonussumme zurückliefern. Wir entschließen uns eine Funktion innerhalb des Moduls WAREHOUSE zu definieren. Anlegen einer Funktion Erstellen Sie eine Funktion BONUS_Berechnung (-> rechte Maustaste auf Functions innerhalb des Transformations-Astes in dem Warehouse-Modul. (Step 1/3). Erfassen Sie zwei Aufrufparameter für die Funktion: KUNDENSTATUS (varchar2) und BESTELL_TOTAL (number). (Step 2/3). Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 131/300 Jetzt erhalten Sie unter Step 2/3 die Möglichkeit den Funktions-Code zu erfassen. Wählen Sie hierzu den Punkt Code-Editor. In dem Editor-Fenster ist bereits ein Code-Template vorbereitet. Dieses Template an sich ist schon ablauffähig, bewirkt durch die NULL-Schlüsselwörter jedoch nichts. An diesen Stellen müssen Änderungen vorgenommen werden. Erfassen Sie den Code wie folgt: Funktion Bonus_Berechnung Den Code zum Kopieren um das Schreiben zu sparen: if KUNDENSTATUS = 'F' Then -- Firmenkunde Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 132/300 return ((BESTELL_TOTAL* 0.5)*0.02) + ((BESTELL_TOTAL* 0.2)*0.04); end if; if KUNDENSTATUS = 'P' Then -- Privatkunde return ((BESTELL_TOTAL* 0.5)*0.02) + ((BESTELL_TOTAL* 0.2)*0.04); Else return 0; end if; Testen Sie den Code jetzt über den Menüpunkt TEST. Sie werden nach der Location gefragt die sie selektieren können (in unserem Fall ist das LC_DWH). nachdem Sie die Location quittiert haben erscheint im unteren Feld z. B. ‚Succussfully tested’. Wenn dies erscheint, können Sie in das Zielschema in der Datenbank (DWH) wechseln und z. B. folgenden Funktionstest machen: Speichern Sie den Code mit SAVE unter dem Menüpunkt Code ab. und beenden Sie den Wizard mit OK Syntax-Check und Code-Debugging Der Code-Editor macht zwar nur eine rudimentäre Syntax-Prüfung (Gelb-Markieren von Klammern und Fettmarkierung von Schlüsselwörtern). Aber durch die Testfunktion ist er sehr praktisch geworden. Wird ein Debugging gebraucht, so kann man z. B. den SQL Developer von Oracle nutzen, der kostenlos von den Oracle-Seiten heruntergeladen werden kann ( oder er ist bereits auf der CD, mit der diese Step_By_Step ausgeliefert wurde. Debuggen mit Oracle SQLDeveloper Wenn Sie diesen Debugger ausführen, denken Sie an die folgenden Rechte, die SYS as das Schema DWH übertragen muss. grant DEBUG CONNECT SESSION to DWH; grant DEBUG ANY PROCEDURE to dwh; Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 133/300 Verwenden einer Funktion Diese Funktion soll in das Beispiel integriert werden: Kopieren Sie das Mapping WH_TRANSAKTIONEN_9_LOOKUP in das neue Mapping WH_TRANSAKTIONEN_10_Function. Ziehen Sie aus der Palette einen Transformation Operator rechts neben den Splitter. Ein Fenster öffnet sich, über das Sie die Funktion BONUS_BERECHNUNG in dem Modul WAREHOUSE auswählen können. OK Verbinden Sie die Felder STATUS und BESTELL_TOTAL aus dem Splitterausgang für Privatkunden mit den jeweiligen Eingabefeldern der Funktion. Erzeugen Sie in der Zieltabelle WH_TRANS_PRIVAT ein neues Feld BONUS (number). Verbinden Sie das Feld VALUE der Funktion mit dem neuen Feld BONUS in der Zieltabelle Wiederholen Sie den Vorgang für die Tabelle WH_TRANS_FIRMA. Synchronisieren Sie die Tabellen WH_TRANS_PRIVAT und WH_TRANS_FIRMA (-> rechte Maustaste auf die Tabellenköpfe -> Synchronize -> Option Outbound) Generieren Sie die geänderten Tabellen (Replace Option wählen) und das Mapping. Die Funktion müssen Sie nicht mehr generieren, wenn Sie diese vorher bereits getestet haben. Testen Sie das neue Mapping und betrachten Sie sich die Tabellen im Data Viewer. Der aktuelle Stand des Szenarios sieht so aus: Das Mapping MP_TRANSAKTIONEN_10_FUNCTION Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 134/300 Verwenden von Aufrufparametern Mappings können variabel gehalten werden indem Aufrufparameter von außen auf Einstellungen innerhalb des Mappings einwirken. In unserem Beispiel haben wir einen Filter eingebaut (Kundennummer > 1000). Diese Einschränkung ist ein für alle Mal festgeschrieben. Mit einem Aufrufparameter können wir diese Filterbedingung variabel halten. Aufrufparameter können Sie wie ein Attribut einer Tabelle innerhalb des Mappings weiterverwenden. Innerhalb des später generierten Mappings, stellt der Parameter ein einfacher Aufrufwert dar, den Sie von der aufrufenden Instanz her bestimmen können. Hilfreich sind Vorbelegungen für das Attribut, falls mal vergessen wird, später einen Parameter mitzugeben. Anforderung: Definieren Sie einen Aufrufparameter um den Filter zur Kundenselektion variabel zu halten. Kopieren Sie das Mapping WH_TRANSAKTIONEN_10_FUNCTION in das neue Mapping MP_TRANSAKTIONEN_11_Para. Ziehen Sie aus dem Pre/Post Processing-Bereich der Palette den Mapping Input-Operator in den linken Bereich des Mappings Öffnen Sie den Detail-Editor für diesen neuen Operator (-> rechte Maustaste auf den Kopf des Operators -> Option Details). Erfassen Sie das Feld AB_KD_NUMMER unter dem Reiter OUTPUT ATTRIBUTES. Nennen Sie den Operator KD_NR_FILTER. Klappen Sie den Filter-Operator KUNDE_GROESSER_1000 auf, und führen Sie das neue Feld des Parameter-Operators zusätzlich in den Filter-Operator, so dass dort ein neues Feld erscheint. Gehen Sie über den Properties Inspector in die Filter Condition des Filters (-> den Kopf des Filter Operators selektieren). Löschen Sie in dem rechten Bereich den Wert 1000 und ersetzen Sie ihn durch den Feldnamen AB_KD_NUMMER aus der Liste die Sie links sehen. Benennen Sie den Filter-Operator noch um, z. B. auf FILTER_KUNDE, denn der alte Name passt jetzt nicht mehr. Generieren Sie das neue Mapping mit dem Control Center. Und testen Sie das Mapping Parametereingabe und Aufruf des Mappings Wenn Sie das Mapping über das Control Center starten, werden Sie feststellen müssen, dass Sie keinerlei Daten mehr in Ihren Tabellen haben. Das ist verständlich, denn Sie hatten noch keine Chance einen sinnvollen Parameter für die neue Filterbedingung anzugeben. Hierzu müssen Sie eine Voreinstellung des OWB verändern, damit OWB Ihnen das Fenster zur Parametereingabe einblendet. Öffnen Sie ihm Design Center die Preferences , die Sie unter dem Menüpunkt Tools finden. Setzen Sie ein Häkchen für Prompt for excecution parameters unter Deployment / Process Starten Sie das Mapping jetzt noch einmal und Sie bekommen ein Auswahlfenster mit allen Aufrufparametern angezeigt. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 135/300 Eingabemöglichkeit von Parameterwerten im Verlauf des Mapping-Aufrufs Nachdem Sie den Wert für den Parameter gesetzt haben, können Sie die weitere Verarbeitung über den grünen Pfeil links oben starten. Das neue Mapping sieht jetzt so aus: MP_TRANSAKTIONEN_11_PARA Schreiben von Textdateien Ebenso wie das Schreiben in eine Datenbank kann auch in eine Textdatei geschrieben werden. Dies ist oft notwendig, wenn Ergebnisse zu protokollieren sind oder Daten über einen Workflow verschickt werden müssen. Im Ergebnis sind die folgenden Formate direkt aus einem Mapping heraus möglich: Textfile im CSV-Format Textfiles im Fixed Length Format XML Dateien Erzeugen wir zunächst eine einfache CSV-Datei. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 136/300 Anforderung: Protokollieren Sie alle bestellten BESTELLTE_ARTIKEL in eine Textdatei schreiben Artikel, indem Sie die Tabelle Erstellen Sie deswegen ein neues Mapping mit dem Namen MP_PROTOKOLL_ARTIKEL Ziehen Sie die Tabelle BESTELLTE_ARTIKEL aus dem Modul WAREHOUSE in die MappingFläche. Ziehen Sie jetzt aus dem Bereich Source/Target der Palette den Flat File Operator in die Editorfläche rechts neben die Tabelle BESTELLTE_ARTIKEL Ein Auswahlfenster mit den in dem Projekt befindlichen Textdateien erscheint. Wählen Sie den Punkt Create unbound operator with no attributes und vergeben Sie einen Namen für die künftige Textdatei, z. B. Protokoll_Verkaufte_Artikel Klappen Sie die Tabelle BESTELLTE_ARTIKEL auf und überführen Sie alle Attribute der Tabelle in den Textdatei-Operator. Erzeugen Sie die Definition der Textdatei in dem Text-Modul FF_ORTE (das ist bereits angelegt worden, als wir Textdateien über eine External Table gelesen haben) (-> Rechte Maustaste auf den Kopf des Textdatei –Operators -> Create and Bind) Jetzt müssen Sie vor dem Generieren nur noch außerhalb des Mappings unter den ConfigurationEinstellungen des Mappings den tatsächlichen Namen der noch nicht existierenden Zieldatei angeben. Generieren Sie das neue Mapping. Testen Sie es und überprüfen Sie die Existenz der neuen Datei in dem Dateiverzeichnis, das unter der Location des File-Moduls angegeben ist. Bedenken Sie, dass wir die Location des Flat File Moduls bereits angelegt haben, als wir die External Table in dem vorherigen Kapitel erstellten. Wenn Sie dies noch nicht gemacht haben, müssen Sie zunächst ein File-Modul mit einer gültigen Text-Location anlegen. Dies ist unter dem entsprechenden Kapitel beschrieben. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 137/300 Tip: Das Verfahren eignet sich generell gut, um Textfiles aus Datenbanktabellen zu erzeugen. Oftmals sollen auch die Spaltenüberschriften als Kopfzeile in die Textdatei geschrieben werden. Hierzu muss man bei den Properties zur Textdatei in dem Mapping-Editor ein Häkchen für die Option „File contains a header row“ setzen. Properties der Textdatei Tip: Aus den so entstandenen Text-File-Definitionen lassen sehr leicht wieder External Tables erstellen um diese Textinformationen wieder in eine Oracle-Datenbank zu schreiben. Es müssen nicht mehr die Metadaten der Textdatei durch das Sampling erzeugt werden, weil sie durch das Create And Bind im Mapping bereits da ist. XML-Dateien erzeugen Mit einem einzigen Klick können Sie die eben erzeugte Datei auch als XML-Datei herstellen. Setzen Sie das Häkchen in dem Configuration Fenster unter Flat File Operators (-> Output as XML file). Testen Sie es aus Ausschnitt aus generierter XML-File Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 138/300 Selbsterstellte Schreibroutinen Grundsätzlich kann man sich auch eine Textschreibroutine von „Hand programmiert“ erstellen. Der Aufruf einer solchen Prozedur kann im Verlauf eines Mappings oder aus dem Workflow heraus erfolgen. Das hier abgedruckte Beispiel schreibt bei jedem Aufruf eine Zeile weg. D. h. die Zeile sollte bereits "montiert" sein bevor sie als p_line1 der Prozedur übergeben wird. Dies ist im Mapping zu regeln. Eine solche Routine ist als Protokolldatei-Routine nützlich. CREATE OR REPLACE PROCEDURE SL1 (p_Dir in Varchar2, p_file in varchar2, p_line1 in varchar2) AS v_FileHandle UTL_FILE.FILE_TYPE; BEGIN -- Open the output file in append mode. -- v_FileHandle := UTL_FILE.FOPEN(p_FileDir, p_FileName, 'a'); v_FileHandle := UTL_FILE.FOPEN(p_Dir ,p_file, 'w'); UTL_FILE.PUT_LINE(v_FileHandle, p_line1); -- Close the file. UTL_FILE.FCLOSE(v_FileHandle); EXCEPTION -- Handle the UTL_FILE exceptions meaningfully, and make sure -- that the file is properly closed. WHEN UTL_FILE.INVALID_OPERATION THEN UTL_FILE.FCLOSE(v_FileHandle); RAISE_APPLICATION_ERROR(-20061, 'SD: Invalid Operation'); WHEN UTL_FILE.INVALID_FILEHANDLE THEN UTL_FILE.FCLOSE(v_FileHandle); RAISE_APPLICATION_ERROR(-20062, 'SD: Invalid File Handle'); WHEN UTL_FILE.WRITE_ERROR THEN UTL_FILE.FCLOSE(v_FileHandle); RAISE_APPLICATION_ERROR(-20063, 'SD: Write Error'); WHEN UTL_FILE.INVALID_PATH THEN UTL_FILE.FCLOSE(v_FileHandle); RAISE_APPLICATION_ERROR(-20063, 'SD:Falscher Pfad'); WHEN OTHERS THEN UTL_FILE.FCLOSE(v_FileHandle); RAISE; END ; Wiederverwendbare Mapping-Bausteine – Pluggable Mappings Es gibt immer wieder Aufgabenstellungen, für die wir zwar mehrere, unterschiedlichen Mappings brauchen, um sie zu lösen, aber dennoch sind die Aufgabenstellungen ähnlich. Bevor wir mühsam ganze Mappings kopieren, um sie dann getrennt weiter zu pflegen, ist es einfacher, ein generisches Mapping zu erstellen und dieses dann in andere Mappings einzubetten. Diese Bausteine nennt man Pluggable Mappings. Bevor wir hierzu eine Aufgabenstellung bearbeiten, sollte die Arbeitsweise an einem sehr einfachen Beispiel erklärt werden: Lassen Sie uns hierfür eine Tabelle kopieren. Erzeugen Sie zunächst ein Pluggable Mapping mit dem Namen CT unter dem Punkt -> Pluggable Mappings und -> Standalone Der Wizard fragt nach der Input_Signatur. Legen Sie hier 4 Felder an (F1-F2) jeweils varchar2(30) Dann werden Sie nach der Ouptut-Signatur gefragt. Drücken Sie hier einfach auf NEXT ohne Felder anzulegen. Sie erhalten jetzt eine Editor-Fläche die dem Mapping-Editor gleicht. Die beiden Operatoren Input und Output sind sichtbar. Schieben Sie die INGR1-Gruppe der Input-Signatur in die OutputSignatur, so dass dort die Felder F1-F4 ebenfalls entstehen. Erstellen Sie jetzt ein neues Mapping MP_Pluggable. Ziehen Sie die Tabelle WH_Transaktionen in die Editor-Fläche und aus der Palette unter dem Punkt unter dem Punkt Pluggable Mapping den Operator Pluggable Mapping. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 139/300 Jetzt erhalten Sie eine Liste über die Sie die bestehenden Pluggable Mappings selektieren können. Wählen Sie das vorher erstellte CT. Verbinden Sie die ersten 4 Spalten von WH_Transaktionen mit dem INGRP1-Bereich des Pluggable Mappings. Für den Ausgabebereich erzeugen Sie eine neue Tabelle WH_OUT und schieben Sie den Pluggable Mappings-OUTGRP1-Bereich dorthin. Erzeugen Sie diese neue Tabelle in dem Modul WAREHOUSE (-> Create And Bind -> Create in...). Generieren Sie das neue Mapping und die neue Tabelle, und testen Sie es. Das Mapping zum Testen der Pluggable Mappings Sehr viel ist mit diesem Mapping noch nicht gewonnen. Sie können aber jetzt Zug um Zug in dem Pluggable Mapping Änderungen vornehmen, und diese austesten. Fügen Sie jetzt in dem Pluggable Mapping für das Feld F1 im Ausgabebereich eine Expression ein, in dem SYSDATE anstelle des Eingangswertes geladen wird (to_char(sysdate)). Wenn Sie das Mapping MP_PLUGGABLE jetzt neu generieren, werden Sie keinerlei Veränderung in den Daten feststellen. Sie müssen erst das Pluggable Mapping in dem Mapping mit der neuen Version synchronisieren (-> rechte Maustaste auf den Kopf des Operators -> Synchronize -> Inbound ... Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 140/300 Geänderte Pluggable Mappings müssen mit den Mappings, in denen sie verwenden synchronisiert werden. Änderungen, die Sie in dem Pluggable Mapping durchführen werden, implizit auch in dem Repository abgespeichert. Definieren Sie allerdings in dem Pluggable Mapping Objekte wie Tabellen oder Textfiles, so müssen Sie diese mit den Objekten in den Modulen synchronisieren (Outbound). Diese einfache Übung sollte Sie mit dem Umgang vertraut machen und besonders auf die Notwendigkeit der Synchronisation hinweisen. In einem Pluggable Mapping sind alle Operatoren möglich wie Sie sie auch in einem Mapping verwenden können. Die Unterschiede liegen lediglich in der Tatsache, dass Pluggable Mappings eine Aufrufparameter- und eine Rückgabeleiste haben. Pluggable Mappings müssen nicht mit einer Aufruf oder Rückgabe-Parameterleiste versehen werden, wie das Beispiel im folgenden Abschnitt zeigt. Dort besteht der Output des Pluggable Mappings in dem Beschreiben einer Textdatei. Anwendungsszenario „Generisches Protokoll“ Das folgende umfangreichere Beispiel zeigt Anwendungsmöglichkeiten und darüber hinaus spezielle Techniken, die auch in anderen Fällen einsetzbar sind. Anforderung: Es ist ein Mapping-Baustein zu erzeugen, der an beliebigen Stellen in anderen Mappings zum Schreiben von Protokolldateien verwendet werden kann. Das Protokoll soll beliebig viele Textspalten aufnehmen können und eine unterstrichene Kopfzeile mit Datum und Uhrzeit enthalten. Format der Protokolltabelle In dem Beispiel werden folgende Aspekte behandelt: Erzeugen von zusätzlichen Sätzen mit Hilfe von Konstanten und dem SET-Operator und DUAL Verwenden des Sorter-Operators Verwenden des Set-Operators (UNION) Implizite Typkonvertierung Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 141/300 Bei der Planung des Pluggable Mappings sind mehrere Aspekte zu realisieren: 1. Wie kann die Aufrufschnittstelle so generisch gehalten werden, dass das Mapping auch mit einer unterschiedlichen Anzahl Parameter und unterschiedlichen Feldtypen arbeitet? 2. Wie können zusätzliche Kommentare (z. B. beschreibende Kopfzeilen) in den Datenfluss so hinein generiert werden, dass sie immer an erster Stelle stehen. 3. Wie kann zwischen dem aufrufenden Mapping und dem Pluggable Mapping eine Kommunikation statt finden, so dass neben den eigentlichen Sätzen auch noch andere Verwaltungsinformationen übergeben werden (z. B. Mapping-Name etc.). Zu dem ersten Punkt – flexible Input-/Output-Schnittstelle Pluggable Mappings können in ihrer Aufruf- und Rückgabeschnittstelle Parameter besitzen, die von den aufrufenden Mappings nicht verwendet werden müssen. Man kann also eine Reihe von Parametern vorsehen, die nicht immer von jedem Mapping benutzt werden müssen. Das passt auf unsere Anforderung, denn wir erstellen eine generische Protokoll-Routine, über die Sätze mit einer unterschiedlichen Anzahl von Feldern zu schreiben sind. Bleibt das Typen-Problem. Hier können wir nicht immer wissen, welche Feldtypen die aufrufenden Mappings für ihre Parameter mitgeben. Hier hilft ein Trick. Dem späteren Text in der Textdatei, wird es gleichgültig sein, von welchem Typ die Strings sind. Ein Text kennt keine Feldtypen. Deswegen definieren wir die gesamte Aufrufleiste des Pluggable Mappings vom Typ varchar2. Bei dem Aufruf der Komponente in dem späteren Mapping wird Oracle eine implizite Typkonvertierung vornehmen. Zu dem zweiten Punkt – Erzeugen zusätzlicher Sätze (z. B. Kopfzeilen) Während die eigentlichen Sätze über die Input-Schnittstelle des Pluggable Mappings angeliefert werden, gibt es für zusätzliche Informationen wie Kopfzeilen zunächst keinen Input. Da die Mappings letztlich in SQL überführt werden und für jeden zu schreibenden Datensatz in einem Zielobjekt eine Quellinformationen existieren muss, müssen wir eine solche Quelle simulieren. Das scheint zunächst ein Problem bzw. ein Stolperstein in der mengenorientierten Verarbeitungslogik des SQL zu sein. Ist es aber nicht. Wir können mit der DUAL-Dummy-Tabelle Sätze simulieren, die in Wirklichkeit gar nicht da sind. Um das zu verstehen, sollte man sich einige Prinzipien von OWB vergegenwärtigen: Wenn irgendwo Sätze weitergereicht werden, kann man sowohl mit dem Operator CONSTANT als auch mit einer EXPRESSION beliebige zusätzliche Felder in einer Zielstruktur generieren. Diese zusätzlich generierten Felder müssen nichts mit einer Quelltabelle zu tun haben. Es ist möglich, dass das Zielobjekt nur die zusätzlich generierten Felder aufnimmt und keine einzige Information von dem eigentlichen Quellobjekt. Betrachten wir uns das folgende Test-Mapping: Es gibt eine Quelltabelle ZAHL mit nur einem Feld (NR) und eine Zieltabelle ZIEL_TABELLE mit drei Feldern. Die Verbindung läuft über einen Expression-Operator, der im Ausgabebereiche drei Felder besitzt. Die Information in allen drei Feldern entsteht in diesen Expression-Feldern entweder über eine Funktion (sysdate) oder konstante Werte. Das Feld NR im Eingabebereich der EXPRESSION läuft ins leere und wird durch die Ausdrücke des Ausgabebereichs nicht verwendet. Das einzige, was von der Quelltabelle verwendet wird, ist die Anzahl ihrer Sätze. Denn genau so oft werden die Expression-Ausdrücke ausgelesen und in die Zieltabelle geschrieben. Test-Mapping zum Simulieren von Werten Letztlich entsteht durch OWB folgendes SQL: Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 142/300 INSERT /*+ APPEND PARALLEL("ZIEL_TABELLE") */ INTO "ZIEL_TABELLE" ("TAGESDATUM", "FREIER_KOMMENTAR", "BELIEBIGE_ZAHL") (SELECT sysdate, 'Das ist ein Text', 123456 FROM "ZAHL" Bei dieser Konstruktion war zumindest noch eine Quelltabelle nötig, um einen „triggernden“ Input zu liefern. Geht das auch ohne eine Quelltabelle? Für die Kopfzeilen in der Ausgabeliste, wollen wir nicht die Tabelle Zahl verwenden, weil eine solche Tabelle in dem jeweiligen Zielschema vorhanden sein muss. Wenn wir diese Tabelle einfach weglassen gibt es einen OWB-Fehler, der besagt, dass der Expression-Operator nicht genügend Eingabeparameter besitzt. Eine Lösung, die immer funktioniert ist die Verwendung der Tabelle DUAL, die in jeder OracleDatenbank-Umgebung vorhanden ist. Sie hat genau eine Zeile und eine Spalte und erfüllt letztlich die Kriterien, die wir hier brauchen. Doch es gibt noch weitere Möglichkeiten. „Überlisten“ kann man OWB indem man eine Art Dummy-Input für den Operator benutzt: z. B. eine Konstante oder einen Aufrufparameter. Konstanten haben den Nachteil, dass sie in dem später generierten Code eine Deklaration nach sich ziehen. Entsprechend sieht auch das SQL aus. Zur Qualifizierung der Konstanten enthält das SQL immer auch den Package-Namen. Verwenden wird den Aufrufparameter, wie in dem folgenden Beispiel, und wir haben nur die Sorge, das der INPUT_PARAMETER-Operator suggeriert, es gäbe einen sinnvollen Wert, den es aber nicht gibt. Testmapping zum Simulieren von Werten Welchen SQL-Code generiert OWB jetzt aus dieser Konstruktion? INSERT INTO "WH_Testsatz" ("TAGESDATUM", "ZAHL", "TEXT") (SELECT sysdate,1,'A' FROM DUAL ); OWB erkennt das Fehlen von Eingabewerten und baut von sich aus die Dummy-Tabelle DUAL in den Code ein. In Ordnung. Dieses Verhalten können wir nutzen, um Kopfzeilen zu generieren. Weil wir Sätze generieren wollen, die anschließen mit echten Tabellensätzen zusammen weiterverarbeitet werden sollen, nutzten wir hierfür einen SET-Operator. Der SET-Operator hat 2 oder mehr INGRP-Bereiche. Einen werden wir nutzen, um die eigentlichen Datensätze, die es zu schreiben gilt, aufzunehmen. Weitere Eingabebereiche nutzen wir, um für die Kopfzeilen Sätze künstlich zu erzeugen. Wir brauchen zwei Bereiche, einen für eine Kopfzeile und eine für einen Unterstrich. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 143/300 Zu dem dritten Punkt (Kommunikation mit dem aufrufenden Mapping) Diese Anforderung ist einfach zu lösen. Wir legen einfach die letzten Parameter der Input-Schnittstelle als Kommunikationsfelder fest. Das was über diese beiden Felder dem Pluggable Mapping übergeben wird, kann man dort beliebig weiter verarbeiten. Entsprechend sieht das Pluggable Mapping wie folgt aus: Über eine Input-Schnittstelle (Felder F1-F5) werden Daten entgegengenommen. Die Feldnamen sind beliebig, deswegen F1, F2 usw. In dem dargestellten Beispiel beschränkt man sich auf 5 Felder. Das können natürlich beliebig mehr sein. Die beiden letzten Felder nehmen den Namen des aufrufenden Mappings und den Namen der Tabelle auf, für die eine Protokolldatei geschrieben werden soll. Alle Felder, werden über eine Expression (mit SUBSTR()) in ihrer Länge auf 30 Bytes begrenzt. In dieser Expressen findet auch eine implizite Typkonvertierung von möglichen number-Feldern auf varchar2Felder statt. Ein SET-Operator nimmt die Sätze aus dem EXPRESSION-Operator auf. In separaten Eingabebereichen nimmt er auch den Text für eine Kopfzeile und eine Strichlinie auf. Informationen wie MAPPING-NAME und TABELLEN_NAME aus dem aufrufenden Mapping finden ebenfalls in der Kopfzeile Platz. (Wie haben noch ein Sortierproblem. Das wird weiter unten gelöst). Pluggable Mapping zum Erzeugen einer Protokoll-Textdatei mit Kopfzeile Das aufrufende Mapping benutzt das Pluggable Mapping als wenn es eine Tabelle wäre. Das folgende Beispiel schreibt nur den Inhalt der Tabelle ARTIKEL in die Protokolldatei. Das reicht zur Demonstration. Mapping zum Testen der Reusable Mappings Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 144/300 Das Ergebnis ist diese Liste: Beispiel-Output Die Unterstriche zwischen den Ausgabefeldern, kann man über die Eigenschaften der Textdatei einstellen, das kann auch ein Semikolon sein. Der Sort-Operator Bei den ersten Tests in dem vorher behandelten Mapping wird man eine kleine Überraschung erleben. Kopfzeile und Strichzeile sind nicht an der Stelle in der Liste, an der man sie vermutet. Sondern Sie stehen irgendwo, meist am Ende. Bevor wir die Sätze der Textdatei übergeben, sollten wir sie sortieren. Hierzu ist ein Sortierkriterium notwendig, über das wir festlegen, welche Sätze, die der SETOperator des Beispiels liefert, zuerst geschrieben werden. Wir erweitern alle Eingabebereiche des Set-Operators um ein Feld SORTER und hängen den SORT-Operator an den Ausgang des SETOperators. Die zu sortierenden Werte legen wir als Konstante fest. In unserem Beispiel sind das einfach die Buchstaben A, B, C (SORTER1=A, SORTER2=B, SORTER3=B. Für jede Satzart steht ein Buchstabe. Über die Properties des SORT-Operators (->Properties Inspector) wird dann das SORTER-Feld als Sortierkriterium bestimmt. Dieses Feld wird selbst nicht mehr an die Textdatei weitergegeben. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 145/300 Unternehmensdaten integrieren – Teil 2 °°°°° Bezieht sich noch auf das ältere Release°°°°°° Einlesen von ODBC-Quellen ODBC hat sich als Standard-Datenaustausch-Verfahren etabliert. ODBC hilft meist dann, wenn es keinen direkten Zugriff zu einem System gibt. Gerade in Office-Umgebungen ist ODBC verbreitet. MS Access oder Excel können Sie sehr leicht mit Hilfe von ODBC an das Warehouse anschließen. Mit dem Warehouse Builder greifen Sie auf ODBC-Quellen ebenso selbstverständlich zu wie etwa auf Oracle-Tabellen. Hier nutzen Sie die Möglichkeit der Oracle-Datenbank auf eine externe ODBC-Quelle zugreifen zu können. Die Datenbank-Möglichkeit nennt man HSODBC oder Heterogenous Services. Funktionsweise und benötigte Komponenten des ODBC-Zugriffs Die Einrichtung auf einem ODBC-fähigen Windows-Rechner sieht wie folgt aus: 1. Es muss ein Oracle-Listener auf dem Rechner laufen, auf dem auch die ODBC-Quelle zur Verfügung steht. 2. Definieren einer ODBC-Quelle als System-DSN (Siehe hierzu die üblichen Verfahren unter Windows). Die ODBC-Quelle sollte zunächst getestet werden, um sicher zu gehen, dass diese auch funktioniert. Machbar ist dies z. B. mit dem Programm "C:\Program Files\Microsoft Office\Office\MSQRY32.EXE" In dem Beispiel in dieser Unterlage heißt die ODBC-Quelle --> Orte <-Es wurde eine Excel-Datei als ODBC-Objekt gewählt. (Jede andere ODBC-Quelle wäre natürlich auch möglich.) Jetzt müssen drei Dateien modifiziert werden: - %ORACLE_HOME%\network\admin\listener.ora - %ORACLE_HOME%\network\admin\tnsnames.ora ( Achtung jetzt kommt ein neues Verzeichnis:) - %ORACLE_HOME%\hs\admin\inithsodbc.ora 3. In der TNSNAMES ist ein neuer TNS-Eintrag vorzunehmen, z. B. ORA9.DE.ORACLE.COM = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = Aschlauc-de)(PORT = 1521)) Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 146/300 ) (CONNECT_DATA = (SERVICE_NAME = ORA9) ) ) Orte.DE.ORACLE.COM = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = Aschlauc-de)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = Orte) ) (HS=OK) ) 4. In der LISTENER-Datei ist ein neuer Aufruf einzutragen, z. B. SID_LIST_LISTENER = (SID_LIST = (SID_DESC = (SID_NAME = PLSExtProc) (ORACLE_HOME = D:\ora9) (PROGRAM = extproc) ) (SID_DESC = (GLOBAL_DBNAME = ORA9) (ORACLE_HOME = D:\ora9) (SID_NAME = ORA9) ) (SID_DESC = (SID_NAME = Orte) (ORACLE_HOME = D:\ora9) (PROGRAM = hsodbc) ) ) 5. In dem Oracle-Home-Verzeichnis gibt es ein Verzeichnis mit dem Namen HS mit der Datei %ORACLE_HOME%\hs\admin\inithsodbc.ora als Beispiel einer ODBC-Konfigurationsdatei. Kopieren Sie diese und benennen Sie die neue Datei nach dem Muster: initeigenerODBCName.ora also in diesem Beispiel initOrte.ora. Hier nehmen sie folgende Einträge vor. # # HS init parameters # HS_FDS_CONNECT_INFO = Orte HS_FDS_TRACE_LEVEL = off 6. Jetzt sollte in SQLPlus noch ein neuer DBLink zur ODBC-Quelle definiert werden, z. B. create database link DBL_Orte using 'Orte.de.oracle.com' Unter using ist der Name anzugeben, wie er auch in der TNSNAMES verwendet wurde. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 147/300 Testen des ODBC-Aufrufs: Hier ist der Name des Karteireiters innerhalb von EXCEL anzugeben. Jede Kartei stellt eine eigene Tabelle dar. Beachten Sie das $-Zeichen vor dem DB-Linknamen. SQL> select ORT_sicher_excel$@dbl_orte; OrteNr ---------1 2 3 4 5 6 7 8 9 10 11 * from Ort ----------------------------Berlin Braunschweig Bremen Dortmund Elmshorn Essen Hannover Kaiserslautern Karlsruhe Kiel Ludwigsburg Anzeigen aller möglichen Tabellen über die ODBC Quelle: select * from all_tables@dbl_orte Verwenden von ODBC-Quellen über den Warehouse-Builder Alle ODBC-Objekte können wie normale Tabellen in den Mapping-Editoren betrachtet werden. Definieren Sie ein separates Quellmodul für eine ODBC-Quelle. Bei der Definition des DB-Links könne Sie die Option Use for Hetergeneouse Services“ wählen. Ausnahme: Es wird Ihnen nicht gelingen für eine ExcelTabelle einen solchen DB-Link anzulegen, denn das System fragt Sie nach User Name und Password. Eine Excel-Tabelle hat so etwas nicht. Bei Access oder SQL Server oder DB2/UDB ist dies möglich. Erstellen Sie einen View für Excel-Tabellen. In der View-Definition nutzen Sie den oben definierten DB-Link. Einlesen von XML-Dateien (Ist in Vorbereitung – wenn jetzt bereits ein Beispiel gebraucht wird, bitte über den Autor anfordern) Einlesen von SAP-R/3-Daten mit dem SAP-Integrator (Ist in Vorbereitung – wenn jetzt bereits ein Beispiel gebraucht wird, bitte über den Autor anfordern) Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step Messagebasiertes Queuing Einlesen 148/300 von Nachrichten über Advanced (Ist in Vorbereitung – wenn jetzt bereits ein Beispiel gebraucht wird, bitte über den Autor anfordern) Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 149/300 Generierungsstrategien Set based versus Row based Die Datenbank als Ladeutility zu nutzen, ist eine gute Wahl, denn die primäre Aufgabe der Datenbank ist es, Daten in großen Mengen zu verwalten aber auch zu bewegen. Um optimale Ladeperformance zu erzielen, sollte dem Warehouse-Entwickler die Besonderheiten der Oracle-Datenbank bewusst sein. Die höchste Ladeperformance erreicht die Datenbank mit den nativen Mitteln des SQL. Die Datenbank arbeitet hier mengenbasiert, sie verarbeitet mehrere Sätze gleichzeitig (Set Based). Plattenlese- und Plattenschreibaktivitäten sind blockorientierte Operationen, und das System kann mit einem (zeitintensiven) physischen IO viele Sätze gleichzeitig lesen bzw. schreiben. Das Gegenstück ist die Einzelsatzverarbeitung (Row Based). Select-Kommandos auf einzelne Sätze wie sie in Handprogrammierten Routinen regelmäßig vorkommen, zwingen das System für jeden angeforderten Satz mindestens einen physischen Plattenlesezugriff durchzuführen. Zwar bietet PL/SQL die Möglichkeit der Cursor-Technik, die mit einem einzigen Select-Befehl die zu verarbeitenden Sätze bereits in den Hauptspeicher liest, doch erfolgt auch hier die nachfolgende Verarbeitung (z. B. Schreiben mittels Insert) satzweise, und das kostet Zeit. Die Set-Based-Verarbeitung ist schneller, als die Row-Based-Variante und daher vorzuziehen. Allerdings besteht nicht immer eine Wahlmöglichkeit. Der Update SQL-Befehl ist z. B. eher ein Kandidat für die langsamere Variante. Fehlersituationen lassen sich in der Row-Based-Variante leichter verwalten, weil hier die Fehlerursache direkt auf den fehlerhaften Satz zurückführbar ist. Der Warehouse Builder berücksichtigt diese Unterschiede, in dem er mehrere CodeGenerierungsvarianten anbietet. Ein Demonstrationsbeispiel: Betrachten Sie sich das Mapping MP_TRANSAKTIONEN_4_WHERE. Das haben wir angelegt um die Filter-Bedingung zu testen. Öffnen Sie den Editor für dieses Mapping. Führen Sie eine Generierung aus diesem Mapping heraus über die Menüoption Generate durch. Schalten Sie in dem Kopfbereich des Generation-Result-Fensters den Operating Mode SET_BASED ein. Optionen-Wahl für den Operating Mode In der Listbox Operating mode sehen Sie die 5 Generierungsvarianten des Warehouse Builders. Das Generation-Result-Fenster eignet sich sehr gut zur Betrachtung dieser Varianten, weil Sie hin- und herschalten können und sehr viel Verwaltungs-Code weggelassen worden ist. Die ersten drei Optionen entsprechen der Set based bzw. Row based Variante. Die letzen 2 stellen eine Mischung zwischen beiden dar, indem sie zuerst mit Set based beginnen und erst im Felhlerfall (Failover) auf Row based umspringen. Die letzten beide Varianten sind die aufwendigsten, denn im Extremfall werden Quellsätze zweimal gelesen. Aber wir haben die Chance, dass bei fehlerfreien Läufen die schnelle SET-based Variante zieht. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 150/300 Der Code für die Set based Variante: Ausschnitt Code-Generierung Set based Dies ist die einfachste und schnellste Ladevariante. Beachten Sie auch den Hint: /*+ APPEND PARALLEL(WH_TRANSAKTIONEN, DEFAULT, DEFAULT) */ der eingestreut ist. Commit-Steuerung: Das System setzt bei dieser Variante nicht bei jedem Insert ein Commit-Kommando ab sondern in Abhängigkeit von dem Default erst nach 1000 Inserts. Diese Zahl können Sie über Configuration Properties ändern (rechte Maustaste auf MP_Load_Strategie und dann Configure). Die Filterbedingung ist in der Where-Klausel zu finden. Der Code für die Row based Variante: Schalten Sie den Operating Mode um auf die Row Based Variante. Bei der Row based Variante generiert der Warehouse Builder zunächst einen Cursor in der die Quelldaten inklusive Filter und Join-Bedingung in den Speicher geladen werden. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 151/300 Cursor in der Row based Variante Und schließlich erfolgt die Abarbeitung des Cursors nach einem Fetch (nicht dargestellt) und der zeitraubenden Schleife (Loop): Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 152/300 Loop bei der Row based Variante Commit-Steuerung Das System setzt ein Commit nach Abschluss der Schleife ab. Es zieht damit wieder die Default Commit Frequency von 1000 (s. o.). Die Filterbedingung kann prozedural mit PL/SQL-Programmiermittel realisiert sein oder, wie in diesem Beispiel, bereits im Cursor-Aufbau erfolgen. Der Code für die Row based (Target only) Variante Die Row based Variante löst die Filterbedingung erst in der Schleife. Die Row based target only Variante zieht diese Prüfung in die Cursor-Aufbauphase hoch, lässt damit also gar nicht so viele Sätze in die Schleife hineinlaufen und ist damit u. U. schneller. Commit-Steuerung Das System setzt ein Commit nach Abschluss der Schleife ab. Es zieht die Default Commit Frequency von 1000 (s. o.). Der Code für die Set Based failover to Row based Variante Hier generiert OWB die Kombination aus beiden Varianten. Läuft die Set based Variante auf einen Fehler, rollt die gesamte bislang durchgeführte Verarbeitung zurück und beginnt von neuem mit der Row based Variante. Diese Variante kann in einzelnen Fällen länger dauern, als wenn gleich die Row Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 153/300 based Variante gewählt worden wäre. Hier sollten Sie eine Entscheidung in Abhängigkeit von der Datenqualität treffen. Der Code für die Set Based failover to Row based (Target only) Variante Diese Variante entspricht den vorhergehenden, allerdings ist jetzt die Filterbedingung wieder in den Cursor hochgezogen. Steuerung der Generierungsvarianten Im Default generiert der Warehouse Builder die Variante Set based fail over to row based. Sie verändern diese Einstellung über die Mapping Configuration Properies (rechte Maustaste auf MP_TRANSAKTIONEN_4_WHERE und dann Configure). Steuerung der Generierungsvarianten Mit der Set-Based-Variante performante Mappings erzeugen Da die Set based-Operation die schnellste Variante ist, kann es Situationen geben, in der ein geschicktes Kombinieren von mehreren Insert Append-Läufen schneller ist, als ein Row Based Lauf. 2 Klassen von Mappings – Mappings organisieren Eine erste Regel besagt, dass Datenflüssen mit einer sehr geringen Fehleranfälligkeit zusammenzufassen sind. Umgekehrt werden Datenflüssen, die sehr wahrscheinlich Fehler produzieren auch zusammengefasst und von Beginn an mit der Row-based-Variante gesteuert, so dass diese erst gar nicht die Set-based-Variante versuchen. Durch die Selektion in fehlerträchtige und weniger fehlerträchtige Ladeflüsse kann man die Anzahl langsamer Mappings bereits reduzieren. Dies erfordert vorausschauende Planung bei dem Aufbau der Mappings. Die Wahrscheinlichkeit von Fehlern muss im Vorfeld ermittelt werden. Hier hilft das Data Profiling. Mappings mit einer Set-based-Verarbeitung kann man schliesslich auch zusammenfassen. Wenn keine Fehler zu erwarten sind, macht man „Sammelmappings“, in denen mehrere Ladestränge, d. h. das Laden von mehreren Zieltabellen, in einem Mapping zusammengefasst ist. Geschickte SQL-Anwendung Durch die geschickte Anwendung von SQL können die meisten Anforderungen heute mit der Setbased-Variante verarbeitet werden. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 154/300 Ein erstes Beispiel: Es sind mehrere Millionen Sätze in eine bereits bestehende und gefüllt Zieltabelle zu überführen, wenige Sätze sind in der Zieltabelle enthalten. Es muss ein umfangreicher Update vermieden werden: 1. Lauf Insert Append in eine temporäre Tabelle A für alle Sätze, die noch nicht in der Zieltabelle enthalten sind. (Minus Operation). 2. Lauf Insert Append in eine temporäre Tabelle B für alle Sätze, die bereits in der Zieltabelle enthalten sind. (Union Operation). 3. Lauf Insert Append aller Sätze der temporäre Tabelle A in die Zieltabelle. 4. Lauf Update aller Sätze der temporäre Tabelle B in die Zieltabelle. Mit den Datenbankmitteln von Oracle 10g Release 2 kann die Problematik generell entschärft werden. Denn hier gibt es zum einen das MERGE-Kommando, das UPDATE und INSERT vereint. Oracle Warehouse Builder generiert diese MERGE-Statements. Zum anderen gibt es Error-Tabellen, in die Sätze geschrieben werden, die eine Constraint-Verletzung verursachen. Inhaltliche Prüfungen Das eben genannte Beispiel löst Fälle, in denen es sich lediglich um ein schnelles Updaten von Tabellen handelt. Besondere Herausforderungen treten jedoch dann auf, wenn Inhalte von Quellsätzen während des Ladens geprüft werden müssen. Das sind Prüfungen wie: NULL / NOT NULL Numerisch / alphanumerisch Gültiges Datumsfeld Datum in Von/Bis-Bereichen Summenabgleiche in unterschiedlichen Tabellen Beliebige ‚Regular Expressions’ (Spezielle Semantik) Teilstringprüfungen Wertgültigkeit in Abhängigkeit von Werten aus anderen Tabellen (Lookup) Alle diese Fälle können mengenbasiert (Set-based) gelöst werden, wie die folgenden Beispiele zeigen. Null / NOT Null - Prüfung Anforderung: Es sollen einzelne Felder (F2, F3) einer Quelltabelle S auf NULL / Not Null überprüft und fehlerhafte Sätze aussortiert werden. In der folgenden Lösung durchlaufen die Feldinhalte von F1 und F2 eine CASE-Anweisung in der im Fehlerfall ein Kontrollfeld ERR mit der Zahl 1 belegt wird. Dieses Kontrollfeld dient dem folgenden Splitter, um fehlerhafte Sätze in die Fehlertabelle T_ERR auszusteuert. Die korrekten Sätze stehen nach Abschluss in der Tabelle T. Beispiel-Mapping zum Aussteuern von NOT-NULL-Feldern Die CASE-Anweisung für das Feld ERR lautet: Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step case when INGRP1.F2 else 0 end is null or 155/300 INGRP1.F3 is null then 1 Prüfung Numerisch / nicht Numerisch Eine ähnliche Lösung ist möglich für die Prüfung Numerisch / nicht Numerisch. Hier kann man sich eine kleine Hilfsfunktion erstellen, die eine Wert auf numerisch oder nichtnumerisch prüft. Diese Funktion wird dann wie in dem Beispiel zuvor in eine CASE-Anweisung geschrieben. Die folgende Funktion liefert einen NULL-Wert zurück, wenn der übergebene alphanumerische Parameter nicht in einen numerischen überführt werden kann. CREATE OR REPLACE FUNCTION IST_NUMMER(F1 IN VARCHAR2) RETURN NUMBER IS --initialize variables here -- main body BEGIN return to_number(f1); EXCEPTION WHEN OTHERS THEN RETURN NULL; END; / Die Verwendung in einem CASE-Statement sieht wie folgt aus: select case when ist_nummer('666') IS NULL then 'Nicht numerisch' else 'Numerisch' end from Dual Das dazu passende Mapping hat die gleiche Form, wie das Beispiel zuvor und wird deswegen hier nicht ausgeführt. Prüfung auf Ist-Datum / Ist Nicht Datum Genau das gleiche Verfahren ist für eine Datums-Prüfung möglich. Man braucht hier eine andere Funktion. CREATE OR REPLACE FUNCTION IST_DATUM("F1" IN VARCHAR2) RETURN DATE IS --initialize variables here -- main body BEGIN return to_date(f1); EXCEPTION WHEN OTHERS THEN RETURN NULL; END; Die Verwendung in einem CASE-Statement sieht dann wieder so aus: select case when ist_datum('11-MAR-2006') IS NULL then 'Datumsformatfehler' else 'OK' end from Dual Oder eine noch einfachere Verwendung: select ist_datum('11-MAR-2006') from dual Auch hierzu kann man sich das dazu passende Mapping leicht aus dem obigen Beispiel ableiten. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 156/300 Summenabgleiche Anforderung: In zwei Tabellen sind Erträge mit unterschiedlicher Verdichtung abgelegt. In einer Bestell-Tabelle ist die Gesamtsumme einer Bestellung erfasst und in einer Bestell-Positionen-Tabelle sind die Einzelpositionen zu dieser Bestellung mit den Einzelbeträgen einer Position gesammelt. Die Summe aller Einzelbeträge zu einer Bestellung soll gleich der Gesamtsumme einer Bestellung in der Bestell-Tabelle sein. Es sollen alle diejenigen Bestellungen gefunden werden, die fehlerhaft sind. Lösung: Hinter dieser Anforderung steckt die Gruppenwechsel-Thematik, d. h. wir müssen für jede Bestellnummer zunächst die dazu passenden Positionen in der Bestell-Positionen-Tabelle suchen, deren Einzelerträge zusammen addieren und das Ergebnis mit dem Summenfeld der Bestell-Tabelle vergleichen. SQL ist für eine solche Lösung prädestiniert. In prozeduralen Programmiersprachen müsste man hierfür zwei Schleifen mit einer entsprechenden Kopfverarbeitung für die Bestellungen realisieren. Die Mapping-Lösung: Mapping zur Lösung des Summenvergleichs Beide Quelltabellen werden über einen Joiner und dem Join-Kriterium der Bestellnummer miteinander „verjoint“. Damit ist die Zugehörigkeit der Positionssätze aus der einen Tabelle mit den Bestellsummensätzen der anderen Tabelle gegeben. Die Bestell-Positions-Sätze werden jedoch vorher über die Bestellnummer durchen einen Aggregator gruppiert und die einzelnen Positionswerte pro Bestellnummer aufaddiert (aggregiert). Im Ergebnis entsteht pro Bestellnummer nur ein Satz, der an den Joiner weitergegeben wird. Da nur Sätze mit abweichenden Summenwerten in die Zieltabelle gelangen dürfen, ergänzt man die Join-Bedinung um einen entsprechenden Eintrag. Join-Bedingung Der Deduplicator in dem Mapping soll verhindern, dass doppelte Bestellsätze angeliefert werden. Es sollen einzelne Felder (F2, F3) einer Quelltabelle S auf NULL / Not Null Komplexere Lösungen - Mit temporären Zwischentabellen arbeiten Bei komplexeren Lösungen und bei mehreren gleichzeitigen Prüfungen bieten sich temporäre Zwischentabellen an. Das Beschreiben und Wiederlesen einer Zwischentabelle kann im Endeffekt performanter sein, als die satzweise Abarbeitung in einer Cursor-gesteuerten prozeduralen PL/SQLSchleife. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 157/300 Anforderung: In einer Tabellen sind Statusmeldungen zu einem bestimmten Vorgang abgelegt. Ein Vorgang durchläuft eine Reihe von definierten Zuständen. Das Erreichen des Zustands wird über einen dazu festgelegten Statuswert (A,B,C,D...) festgehalten. Die Abfolge der Zustände, also auch die Abfolge der Statusmeldungen muss chronologisch entsprechend einer Datumsangabe erfolgen. Es muss also der Status A zeitlich vor dem Erreichen des Status B erfolgen. Um das zu überprüfen, wird ein Datumsfeld mitgepflegt. Die Datumskennzeichnung der Zustände erfolgte manuell, kann also fehlerhaft sein. Ein Fehler liegt dann vor, wenn z. B. der Status C ein früheres Datum besitzt als Status B. Die Herausforderung in diesem Beispiel liegt in dem Umstand, dass die zu prüfenden Informationen in der gleichen Tabelle über verschiedene Sätze hinweg verteilt sind. Das Lösungs-Mapping: Mapping zum Herausfinden von nicht-chronologischen Statusmeldungen Zur Lösung wurden zwei temporäre Tabellen eingeführt. Die Ausgangstabelle „STATUSMELDUNG“ ist zweimal als Quelle in das Mapping eingeführt worden. Die Sätze dieser Tabelle werden einmal sortiert nach dem Kriterium STATUS+DATUM und dann noch einmal umgekehrt nach DATUM+STATUS. Damit die Sortierergebnisse später verglichen werden können, hat man eine laufende Nummer eingeführt, die man sich aus zwei Sequence-Objekten liefern lässt. Wenn man jetzt einen Join über diese laufende Nummer bildet, müssen die Ergebnissätze den gleichen Statuswert aufweisen, wenn die Sätze gültig sind. Wenn nicht, laufen Datum und Statusabfolge auseinander. Die Join-Bedingung (Anti-Join wegen des !=-Vergleichs): Join-Bedingung des Status-Abgleichs Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 158/300 In vielen Fällen kann man auf die temporären Tabellen verzichten. Auch in diesem Beispiel könnte man ohne die beiden temporären Tabellen auskommen. Aber sie machen das Verfahren übersichtlicher. Ausnahmen, die nur mit Row Based generierbar sind Bestimmte Transformationen sind nur im Row based Modus generierbar: - Flat File as target Operationen - Name&Adress-Cleansing - Regular-Expressions Den Schreibmodus ändern - Insert – Update – Delete Sollen Zieltabellen Updates erfahren, so generiert der Warehouse Builder den passenden UpdateCode für eine Update-Steuerung. Um dieses Verfahren einzuschalten, gehen Sie wie folgt vor: Kopieren Sie das Mapping MP_ARTIKEL und erstellen Sie daraus das neue Mapping MP_ARTIKEL_UPD Markieren Sie die Zieltabelle DIM_ARTIKEL und öffnen Sie das Properties-Fenster hierzu. Unter Looding Type können Sie jetzt mehrere Auswahlvarianten erkennen. Einschalten des Änderungsmodus für die Zieltabelle Die unterschiedlichen Varianten, in eine Zieltabelle zu schreiben, sind hier kurz dargestellt: Updates - Updates / Insert Mit Updates werden bestehend Zielsätze geändert. Im Fall eines nicht vorhandenen Zielsatzes führt das System einen Insert durch. Updates sind natürlich nur dann durchführbar, wenn die Zieltabelle auch über einen Primary Key (Matchkriterium) verfügt. Ist das Selektionskriterium für Zielsätze nicht der Primary Key, so kann man einen alternativen Schlüssel festlegen. Ist die Zieldatenbank Oracle 9.2 oder höher, so generiert OWB ein Merge-Statement. Wenn Sie den Test mit dem kopierten Mapping durchführen, kann das Sequence-Objekt stören. Wir haben in einem früheren Beispiel das Sequence-Objekt gebraucht, um einen neuen künstlichen Schlüssel aufzubauen. Hier spielt uns die Logik einen Streich: Einerseits wollen wir in der Zieltabelle einen neuen künstlichen Schlüssel (Dimension_Key), andererseits ist das sogenannte Matchkriterium der alte Originalschlüssel (Artikelnummer). Für diese spezielle Anforderung müssen wir eine spezielle Lösung finden. Zunächst legen wir fest, dass das Matchkriterium die Artikelnummer sein soll. Selektieren Sie den Kopf der Zieltabelle DIM_ARTIKEL Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 159/300 Schalten Sie in dem Properties-Fenster die Option Match by constraint auf NO_CONSTRAINTS. Diese Option versucht einen Update über den Primary Key zu lösen. Stattdessen wählen wir das Feld Artikel_ID. Das ist ursprüngliche Artikelnummer, die mit den Bewegungssätzen aus der Bestell_Position-Tabelle übereinstimmt. Wählen Sie für dieses Feld die Optionen Load Column whenUpdating Row: No Update: Operation: = Match column when Updating Row: Yes Load Column when Inserting Row: Yes Match Column when Deleting Row: Yes Generieren Sie den Code innerhalb des Mappings und betrachten Sie sich den Intermediate Result-Code für die Zieltabelle. MERGE /*+ APPEND PARALLEL("DIM_ARTIKEL") */ INTO "DIM_ARTIKEL" USING (SELECT "ARTIKEL"."ARTIKELNR" "ARTIKELNR", "ARTIKEL"."ARTIKELNAME" "ARTIKELNAME", "ARTIKEL"."ARTIKELNR" "ARTIKELNR$1", "ARTIKEL"."ARTIKELGRUPPENNR" "ARTIKELGRUPPENNR", "ARTIKELGRUPPE"."ARTIKELGRUPPENNAME" "ARTIKELGRUPPENNAME", "ARTIKELSPARTE"."ARTIKELSPARTENNAME" "ARTIKELSPARTENNAME", "ARTIKELGRUPPE"."ARTIKELSPARTENNR" "ARTIKELSPARTENNR" FROM "SRC"."ARTIKEL" "ARTIKEL", "SRC"."ARTIKELGRUPPE" "ARTIKELGRUPPE", "SRC"."ARTIKELSPARTE" "ARTIKELSPARTE" WHERE ( "ARTIKEL"."ARTIKELGRUPPENNR" = "ARTIKELGRUPPE"."ARTIKELGRUPPENNR" ) AND ( "ARTIKELGRUPPE"."ARTIKELSPARTENNR" = "ARTIKELSPARTE"."ARTIKELSPARTENNR" ) ) MERGE_SUBQUERY ON ( "DIM_ARTIKEL"."ARTIKEL_ID" = "MERGE_SUBQUERY"."ARTIKELNR$1" ) WHEN MATCHED THEN UPDATE SET "ORIGINAL_NUMMER" = "MERGE_SUBQUERY"."ARTIKELNR", "ARTIKEL_NAME" = "MERGE_SUBQUERY"."ARTIKELNAME", Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step "GRUPPE_ID" = "GRUPPE_NAME" "SPARTE_NAME" "SPARTE_ID" = 160/300 "MERGE_SUBQUERY"."ARTIKELGRUPPENNR", = "MERGE_SUBQUERY"."ARTIKELGRUPPENNAME", = "MERGE_SUBQUERY"."ARTIKELSPARTENNAME", "MERGE_SUBQUERY"."ARTIKELSPARTENNR" WHEN NOT MATCHED THEN INSERT ("DIM_ARTIKEL"."DIMENSION_KEY", "DIM_ARTIKEL"."ORIGINAL_NUMMER", "DIM_ARTIKEL"."ARTIKEL_NAME", "DIM_ARTIKEL"."ARTIKEL_ID", "DIM_ARTIKEL"."GRUPPE_ID", "DIM_ARTIKEL"."GRUPPE_NAME", "DIM_ARTIKEL"."SPARTE_NAME", "DIM_ARTIKEL"."SPARTE_ID") VALUES ("DIM_ARTIKEL_SEQ".NEXTVAL, "MERGE_SUBQUERY"."ARTIKELNR", "MERGE_SUBQUERY"."ARTIKELNAME", "MERGE_SUBQUERY"."ARTIKELNR$1", "MERGE_SUBQUERY"."ARTIKELGRUPPENNR", "MERGE_SUBQUERY"."ARTIKELGRUPPENNAME", "MERGE_SUBQUERY"."ARTIKELSPARTENNAME", "MERGE_SUBQUERY"."ARTIKELSPARTENNR") ; None Die Option None ist nützlich, wenn die Zieltabelle z. B. als Vergleichstabelle benötigt wird, sie aber selbst nicht verändert werden soll. Die Set based Variante ist möglich. Truncate/Insert Bei der Option Truncate/Insert löscht der generierte Code zunächst die Inhalte in der Zieltabelle. Das ist oft für Zwischentabellen sinnvoll. Die Set based Variante ist möglich. Delete/Insert Hier löscht der generierte Code eventuell bereits vorhandene Sätze bevor ein neuer Satz eingefügt wird. Das kann einfacher sein, als ein Update-Vorgang. Die Set based Variante ist möglich. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 161/300 Runtime Kontrolle Laufzeitergebnisse betrachten Runtime Audit Browser Die Laufzeitergebnisse können entweder in dem Control Center oder in dem Repository Browser nachgeschaut werden. Wie man das macht, ist dort bereits ausgeführt worden. Laufzeitverhalten ändern – Mapping Configuration Die generierten Mappings kommunizieren ihre Laufzeitdaten mit dem Runtime-System, das sich im Regelfall in dem Zielschema also dem eigentlichen Warehouse befindet. Hier sind statistische Informationen (gelesene, geschriebene, abgewiesene Sätze usw. ) ebenso gespeichert wie die fehlerhaften Sätze. Die Menge der gemerkten Meldungen kann enorm und damit performancekritisch sein. Deswegen ist es sinnvoll, das "Traceverhalten" einzustellen. Configuration bei dem jeweiligen Mapping Hier stell Sie den Runtime Parameter "Default audit level" ein auf die Optionen: None: Es findet keine Protokollierung statt. Statistics: Die die Anzahl gelesener, geschriebener, gelöschter Stätze usw. wird dokumententiert Error Details: Im Fehlerfall dokumentiert OWB alle Sätze, die zu einem Fehler geführt haben inklusive der Fehlermeldung. Complete: Alle Informationen und Sätze werden dokumentiert, auch diejenigen, die nicht zu einem Fehler führten. D°as macht natürlich kaum Sinn. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 162/300 Einstelloptionen zur Intensität des Auditings der Ladeläufe Den Erfolg der durchgelaufenen Mapping können Sie mit Hilfe des Repository Browsers in mit einem messen und einsehen. Das ist bereits weiter oben dargestellt worden. Die übrigen Parameter sollten kurz vorgestellt werden: Deployable: legt fest, ob das Mapping generiert werden kann oder nicht. Language: PL/SQL oder ABAP. Diese Einstellung macht nur Sinn im Zusammenhang mit der Genierung von Code zum SAP-Daten-Lesen. Hier kann neben der Generierung von SAP ABAP-Programmen auch PL/SQL erzeugt werden. Mit diesem PL/SQL-Code würde man dann (in Ausnahmefällen) direkt auf die SAP-Datenbank gehen. Referred Calendar: Zuweisung des Mappings zu einem definierten Scheduling-Kalender (siehe Workwlow und Prozesssteuerung). Bulk Size: Arbeitet nur in Verbindung mit dem Bulk Processing Parameter und im Rowbased Mode. Wenn Bulk Processing aktiviert ist, dann kann hier die Anzahl zusammenhängend geladener Sätze festgelegt werden. Diese Option zielt auf das Bulk-Bind-Feature von PL/SQL. Analyze Table sample percentage: Prozentanzahl der Sätze einer Tabelle, die beim Analyze verwendet werden sollen. Das ist ein historischer Parameter. Analyze sollte nicht mehr genutzt werden. Stattdessen DBMS_STAT benutzen. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 163/300 Commit Frequency: Wirkt nur im Row-based mode und wenn Bulk-Processing nicht aktiviert ist. Hier legt man fest, nach welcher Anzahl Sätze ein Commit abgesetzt werden soll. Maximum number of errors: Wirk nur im Row-based mode. Die Verarbneitung bricht ab, wenn die Anzahl an Fehlern erreicht ist, die hier gesetzt ist. Default Operating Mode: Steuerung Set Based / Row Based Default Audit Level: (siehe oben) Default Purge Group: Die Jobs erhalten Namen, mit diesem Präfix. Über die Setzung des Preäfix, kann man Löschgruppen festlegen. ANSI SQL: Wahl zwischen ANSI SQL und Oracle SQL-Syntax. Commit Control: Einstellung über den Einsatz von Commit. Mit der Einstellung Automatic Correlated ist es möglich ein Commit bis an das Ende der kompletten Verarbeitung zu verlagern. Manual verhindert ein Commit in einem Mapping. Automatic setzt ein Commit immer nach dem Abarbeiten einer Tabelle ab. Analyze Table Statements: Bei dieser Wahl generiert OWB ein Analyze Table Kommando. Das sollte jedoch unter Oracle 10g nicht mehr verwendet werden. Enable Parallel DML: Grundsätzliche Option um parallele DML zu ermöglichen. Abgesetzt wird dann: EXECUTE IMMEDIATE 'ALTER SESSION ENABLE PARALLEL DML'; Optimized Code: Wirkt nur auf den Splitter-Operator. Wenn dieser Paramter gesetzt ist, generiert OWB ein echtes Multiple Insert Statement ab der Datenbankversion 9. Authid: Legt fest, welcher Benutzer generieren darf. Use Target Load Order: Hierüber kann von ausserhalb des Mappings gesteuert werden, ob die explizit im Mapping festgelegte Schreibreihenfolge für die Zieltabellen genutzt wird oder nicht. Error Trigger: Angabe eines Error-Triggers, der im Fehlerfall aufgerufen wird. Bulk Processing Mode: (siehe oben). Generation Mode: Einschränkung auf einen bestimmten Modus. Zugriff auf die Laufzeitdaten des Repositories Um zusätzliche Verwaltungsarbeiten durchführen zu können, oder um ein spezielles Fehlerreporting aufzusetzen, kann es sinnvoll sein die Laufzeitdaten des Repositories im Hintergrund abzufragen. Hierfür stehen Public-Views in dem Repositoryschema zur Verfügung. Auf diese kann man auch aus dem Zielschema heraus zugreifen. Die wichtigsten Views sind ALL_RT_AUDIT_EXECUTIONS ALL_RT_AUDIT_MAP_RUNS In dem ersten View sind alle ausgeführten Objekte enthalten. Das können Mappings aber auch Prozesse der Workflowsteuerung sein. Der Schlüsselbegriff ist hier die Execution_Audit_ID. Da sich Prozesse und Mappings gegenseitig aufrufen können, ist eine rekursive Parent-/Child-Folge abfragbar. Hierzu dient die Parent_Execution_Audit_ID. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 164/300 View mit Laufzeitinformationen zu Prozessen Meist will man jedoch einfach nur wissen, ob ein Mapping efolgreich verlaufen ist oder ob eine entsprechende Anzahl von Sätzen verarbeitet wurde. Diese Information steht in dem View ALL_RT_AUDIT_MAP_RUNS. Dieser View enthält die Detaillaufzeitdaten zu den Mappings. Beide Views sind über die Execution_Audit_ID miteinander verbunden. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 165/300 View mit den Detail-Informationen zu den Mappings Anforderung: Es wird eine Funktion gebraucht, die für ein bestimmtes Mapping, prüft, ob die Anzahl der gelesenen Sätze mit der Anzahl der geschriebenen Sätze übereinstimmt. Die folgende Funktion zeigt eine mögliche Lösung: CREATE OR REPLACE FUNCTION "F_SEL_INS"("MAPPINGNAME" IN VARCHAR2) RETURN NUMBER IS act_RUN_ID number; diff number; BEGIN select max(map_run_id) into act_RUN_ID from all_rt_audit_map_runs where MAP_NAME = '"'||MAPPINGNAME||'"'; select number_records_selected - number_records_inserted into diff from all_rt_audit_map_runs where map_run_id = act_RUN_ID; return diff; EXCEPTION WHEN OTHERS THEN RETURN 0; END; / Beispielaufruf: select f_SEL_INS('MP_ARTIKEL') from dual; Zusätzliches Fehlerlogging – Error Trigger Analog dem Exception-Handling von PL/SQL-Prozeduren kann aus einem Mpping heraus im Fehlerfall auch eine Fehlerbehandlungsprozedur (Error Trigger) aufgerufen werden. Das ist eine einfache PL/SQL-Prozedur mit folgender Aufrufschnittellen-Spezifikation: PROCEDURE <ErrorTriggerName> (p_sqlcode Stand/letzte Änderung 13.05.2016 IN NUMBER, (in Arbeit) 75875104 Oracle Warehouse step-by-step 166/300 p_sqlerrm IN VARCHAR2, p_error_stmt IN VARCHAR2 DEFAULT NULL, p_error_column IN VARCHAR2 DEFAULT NULL, p_error_value IN VARCHAR2 DEFAULT NULL); Die Prozedur wird dem jeweiligen Mapping über die Configuration mitgeteilt. Rechte Maustaste auf den Mappingnamen Configuration Eintrag Error Trigger Die Prozedur muss esistieren bevor das Mapping generiert wird. Eine Beispielprozedur zum Dokumentieren von Fehlern in einer zusätzlichen Tabelle kann wie folgt aussehen: Create or replace PROCEDURE MP_COMMIT_ERROR (p_sqlcode IN NUMBER, p_sqlerrm IN VARCHAR2, p_error_stmt IN VARCHAR2 DEFAULT NULL, p_error_column IN VARCHAR2 DEFAULT NULL, p_error_value IN VARCHAR2 DEFAULT NULL) IS PRAGMA AUTONOMOUS_TRANSACTION; runtime_audit_id NUMBER := MP_COMMIT.get_runtime_audit_id; BEGIN INSERT INTO Fehler_Protokoll VALUES('MP_COMMIT', runtime_audit_id, p_sqlcode, p_sqlerrm, p_error_stmt, p_error_value); -- an autonomous transaction must be committed. COMMIT; END MP_COMMIT_ERROR; Die Tabelle zum Aufnehmen der Fehler: Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 167/300 create table Fehler_Protokoll (mapping_name varchar2(50), runtime_audit_id number, p_sqlcode varchar2(50), p_sqlerrm varchar2(50), p_error_stmt varchar2(255), p_error_value varchar2(50)); Die Informationen in der Fehlertabelle können dann so aussehen. Auszug aus der Fehlertabelle Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 168/300 Debugger verwenden Komplexere Mappings können mit einem Debugger analysiert werden. Im Rahmen des Debuggens „durchläuft“ man satzweise jeden einzelnen Operator, kann den Lauf anhalten und kann sich die Inhalte des aktuellen Satzes anschauen. Breakpoint halten an, Watchpoints lassen in die Satzinhalte schauen. Diese Punkte definieren Sie. Damit das gelingt, simuliert OWB eine DebuggingUmgebung im Hintergrund. Wenn Sie zum ersten Mal das Debugging durchführen, wird OWB diese Umgebung initialisieren. Dazu gehören auch Testdaten, die entweder aus den tatsächlichen Daten der betroffenen Tabellen gewonnen werden, oder Sie können selbst welche definieren. Testen Sie das Mapping MP_TRANSAKTIONEN_3_SPLITTER und öffnen Sie das Mapping Wenn Sie jetzt noch nicht die Menüleiste des Debuggers sehen, schalten Sie diese über den Menüpunkt Window ein. Hier zunächst eine kurze Erläuterung zur Menüleiste. Sie starten den Debugger über diese Leiste mit dem linken Knopf. Es ist der Knopf, der als einzigster farbig unterlegt ist. Alle anderen sind grau, wenn der Debugger nicht aktiv ist. Die Menüleiste des Debuggers Starten Sie den Debug-Vorgang. Ein Fenster erscheint, das Sie auf die Situation der Testdaten aufmerksam macht. OWB analysiert die Situation und stellt fest, dass als einzige Testdaten die Tabellen des Mappings selbst vorliegen. Er zählt die Anzahl Sätze in diesen Tabellen und warnt Sie, wenn zu viele Sätze vorhanden sind, wie in diesem Fall. Die Anzahl Sätze werden wir nachher reduzieren. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 169/300 Warnung bei zu vielen Testsätzen Klicken Sie auf Yes, um den Vorgang fortzuführen. Sie erhalten eine Darstellung mit zwei zusätzlichen Fenstern. Dem Debug Info und Debug Data Fenster. Wenn Sie gefragt werden, bei welcher Tabelle Sie mit dem Debuggen beginnen wollen, dann legen Sie die Tabelle Bestellung fest. In dem Debug Info-Fenster können Sie immer mitverfolgen, was der Debugger gerade macht. Bevor Sie weitermachen sollte dort die Meldung stehen: Successful debug initialization! Situation nach dem ersten Starten des Debuggers Bevor wir das Testen starten, sollten wir die Testdaten einschränken. Wählen Sie dazu in dem Debug Info-Fenster den Reiter Test Data. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 170/300 Festlegung der Testsätze Selektieren Sie in dem neuen Fenster die Tabelle BESTELLUNG und drücken Sie auf Edit. Aktivieren Sie in dem neuen Fenster die Checkbox Row Count. Damit schränken Sie die Anzahl der Bestellsätze auf 100 ein. Einschränkung der Bestellsätze auf 100 Drücken Sie auf OK und Sie erhalten die Information, dass sich die Testsätze geändert haben. Sie müssen reinitialisieren. Drücken Sie dazu den entsprechenden Knopf in der Kopfleiste. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 171/300 Sie können das Modifizieren der Testdaten beliebig oft wiederholen. Sie können auch neue Testsätze erstellen. Markieren Sie jetzt die Tabelle WH_TRANSAKTIONEN und drücken Sie danach den Button Set Breakpoint . Setzen Sie noch einen Breakpoint auf die Zieltabelle WH_TRANS_PRIVAT. Starten Sie jetzt das Debuggen mit Resume Der Debugger startet und wird an dem ersten Breakpoint anhalten. Jetzt haben Sie die Möglichkeit über den Button Watchpoint in die einzelnen Tabellen hineinzuschauen. Selektieren Sie dazu immer zunächst das Objekt und dann den Button Set Watch Point. In dem Fenster Debug Data sehen Sie das Ergebnis des Watchpoints. Watchoint-Ergebnis hier Artikel bei Breakpoint WH_TRANSAKTIONEN Drücken Sie jetzt auf die Option Next Step in der Debug-Menüleiste. Der Debug-Lauf fährt bis zum Splitter fort. Hier ist eine Entscheidung zu treffen. Wählen Sie den Splitterweg für Privatkunden. Dort haben Sie den nächsten Breakpoint gesetzt. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 172/300 Auswahl im Splitter Danach hält der Debugvorgang auf der Zieltabelle WH_TRANS_PRIVAT an und auch hier können Sie Watchpoints setzen. Der Vorgang ist danach abgeschlossen. Diese kleine Übung zeigt bereits, dass es wenig Sinn macht das Debuggen mit sehr vielen Sätzen durchzuführen. Es ist notwendig die Anzahl der Sätze einzuschränken und sogar zur Not eigene Testfälle zu erzeugen. Wiederholen Sie den Vorgang mit der Bestelltabelle in dem Sie über den Testdatendialog die Anzahl zunächst auf 5 begrenzen und dann über die Option Edit im oberen Bereich die Zeilen zum Editieren freischalten. Erstellen von Testsätzen Über die Optionen Clear All Row und Add Row können Sie auch vollständig neue Sätze schreiben. Achtung: Jenachdem welche Einstellung Sie wählen, versucht der Debugger Sätze wieder in die Originalquelltabellen zurückzuschreiben. Dabei könnten auch Daten verloren gehen. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 173/300 Erstellen von Testsätzen Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 174/300 Erzeugen von Auswertemodellen in einem Data Mart (Star Schema, Snowflake, OLAP-Würfel) Für Auswertezwecke haben sich in der Praxis mehrere Datenmodelle und Techniken etabliert, die je nach Anwendungsfall in Abhängigkeit von den Rahmenbedingungen ihre Stärken ausspielen können. Die klassischen Auswerte-Datenmodelle in der relationalen Datenbankwelt sind das Star-und das Snowflake-Schema. Oracle bieten zusätzlich die OLAP-Option als alternatives Speicherverfahren an. Bei diesem Verfahren sind Kennzahlen bereits vorberechnet. Warehouse Builder erlaubt die Definition und die Erstellung von allen 3 Varianten. Die Metadatendefinition erfolgt jedoch nur einmal. Zu dem Zeitpunkt der Generierung entscheidet man sich dann für die jeweilige physische Ausprägung. Moduleinteilung und zusammenhängende Informationen Für Data Marts kann man neben Stage und Warehouse aus dokumentarischen Gründen ein separates Modul benutzen. Hier können Dimensionen und Faktentabellen aus einem zusammenhängenden Themengebiet zusammengefaßt sein. Grundsätzlich können beliebig viele Dimensionen und Faktentabellen definiert werden. Über die Verwendung des Wizards zum Aufbau von Faktentabellen legt der Benutzer die Zusammengehörigkeit von Dimensionen und Fakten fest. Dimensionen können in mehreren Starschemen gleichzeitig genutzt werden. Damit ist es leichter, Abfrageinhalte über Data MartGrenzen und Faktentabellen hinweg synchron zu halten (Conforming Dimensions). Wozu werden Dimensionen gebraucht Zum einen sind Dimensionen fundamentaler Bestandteil eines Starschemas wie dies bereits in dem einleitenden Kapitel zu den Dimensionen und Sichten ausgeführt wurde. Logisch gesehen representieren sie die Geschäftsobjekte, über die der Warehouse-Benutzer Informationen abfragt. Aus Sicht der Datenbank liefern sie wertvolle Hinweise zur Optimierung von Benutzerabfragen. Das Datenbanksystem wird sich an den Hierarchie-Leveln der Dimension orientieren um Benutzerabfragen automatisch auf vordefinierte Summentabellen (Materialized Views) umzulenken. Dieses QueryRewrite-Verfahren wird unten näher erläutert. Technisch gesehen, entstehen in der Datenbank nach dem Generieren: - eine oder mehrere relationale Tabellen (je nach dem ob ein Star- oder Snowflake-Schema beim Generieren gewählt wurde) - ein Datenbankobjekt Dimensional Table. Dieses hat eine Hilfsfunktion für den Datenbank-Optimizer bei der Steuerung des Query Rewrite Verfahrens in der Datenbank. Verwendet man die Oracle OLAP Option in der Datenbank, so dient die Dimension-Beschreibung der Definition der OLAP-Würfel. Oracle Warehouse Builder wird aus diesen Definitionen einen OLAPWürfel herstellen. Aus welchen Teilen besteht eine Dimension Idealerweise beinhaltet eine Dimension die zu erwartende Drill-Down- bzw. Roll-Up-Struktur der Abfragen der Warehouse-Benutzer. Um Trends zu erkennen verdichtet man Detailinformationen über gleiche Eigenschaften auf einer Makroebene. Artikel fasst man so zu Artikelgruppen zusammen, Orte werden auf Kreis- oder Landesebene in der Summe betrachtet, Mitarbeiter über Abteilungen oder Sparten in ein globales Bild eingestuft. Über Trends auf der Makroebene lassen sich Rückschlüsse auf die Detailebene ziehen. Besonderheiten auf der Einzelelementebene werden deutlich, aber auch Ausreißer auf der Einzelebene werden nivelliert usw. Für ein Level einer Hierarchie wird üblicherweise ein identifizierendes Element festgelegt – ein Levelschlüssel – und weitere beschreibende Attribute. Auf der untersten Ebene liegt der Primary Key der Dimensionstabelle. Dieser Schlüssel wird bei dem relationalen Star Schema als Foreign Key in die Faktentabelle vererbt. Bei der Definition der Level ist darauf zu achten, dass „abfragefähige“ Columns gefunden werden. Über diese Columns fragt der Warehouse-Benutzer später ab und das Auswertewerkzeug zeigt sie Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 175/300 dem Benutzer zur Selektion an. Diese Columns können gleichzeitig die Abfrageschlüsselwörter für die Endbenutzer sein. Business Key - Surrogate Key Bei der Schlüsselvergabe gibt es noch ein besonderes Phänomen. Meist wird in Data Warehouse Systemen ein eigenständiger künstlicher Schlüssel erzeugt. Das ist notwendig, weil in einem Warehouse System Informationen aus mehreren operativen Systemen zusammengefasst sind. Dort sind die Informationen oftmals nach anderen Schlüsseln sortiert und abgelegt, so dass das Warehouse einen neuen System-übergreifenden Schlüssel braucht. Der Oracle Warehouse Builder trägt diesem Umstand Rechnung, in dem er in den Wizards zur Erstellung der Dimensionen die Schlüsselarten Business und Surrogate (Starschems) vorsieht. Beispiel Artikeldimension: Auf den Hierarchieleveln gibt es die Levelschlüssel und jeweils noch ein Levelattribut (Langtext). Auf dem untersten Level gibt es noch zusätzlich einen Artikelschluessel als Primary Key der Dimension. Er übernimmt die Fremschlüsselbeziehung zur Faktentabelle. Die Artikeldimension ist über eine Denormalisierung der 3 Stammdatentabellen Artikelgruppe und Artikelsparte zu einer einzigen Tabelle entstanden. Artikel, Zu jeder Dimensionstabelle definiert man ein passendes Mapping. Hier findet die Denormalisierung statt. Werden neue künstliche Schlüssel gebraucht, so kann dieser, in diesem Mapping über eine Sequenz erzeugt werden. In dem nebenstehenden Beispiel verzichtete man auf das Erstellen eines zusätzlichen Schlüssels für die Dimension Artikel, da die Artikelnummer bereits eine laufende Nummer ist. Der Primary Key der Dimensionen Nach welchen Regeln sollten die Primary-Keys der Dimensionen im Warehouse aufgebaut sein? Aus der klassischen Datenmodellierung gibt es folgende Regeln für Primary Keys (PKs): Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 176/300 PKs sollten über lange Zeiträume hinweg stabil bleiben. Artikelnummern, die sich öfter ändern, eignen sich z. B. nicht. Wie sollen im Warehouse über Jahre hinweg Trends gemessen werden, wenn sich die Schlüssel ändern? PKs sollten kompakt aufgebaut sein. Zusammengesetzte Schlüssel eignen sich nicht. Die kompakteste Form ist eine laufende Nummer. PKs sollten nicht noch zusätzlich in Bedeutungsbestandteile zerfallen. Z. B. gruppenbezogene Präfix- oder Suffixangaben, Masken. Zusammengefasst ist das Bilden einer laufenden Nummer in den meisten Fällen die ideale Vorgehensweise. Eine Aufgabenstellung bei dem Aufbau des Starschemas ist folglich das Neubilden der Primary Key. Innerhalb des Warehouse-Builders wird man hierzu eine Sequenz (Datenbankobjekt) nutzen, die bei jedem Zugriff einen neuen Schlüssel liefert. Der Originalschlüssel, z. B. die Artikelnummer aus den Stammdaten, sollte ebenfalls mit in die Dimension übernommen werden, denn nur über den Originalschlüssel können Rückverweise auf die operativen Quellen nachvollzogen werden. Es wird möglich sein, aus dem Warehouse heraus über diese Schlüssel auf die Originaldaten der operativen Vorsystemen zuzugreifen. Auch bei Updates helfen die Orginalschlüssel, denn nur hierüber sind zu ändernde Sätze identifizierbar. Empfehlungen für die Planung und den Aufbau von Dimensionen: Verwenden Sie denormalisierte Strukturen, die nach Möglichkeit in einer Tabelle vorhanden sind (nicht noch zusätzliche normalisierte Strukturen, etwa Snowflake) Die Beziehungen zwischen der Faktentabelle und der Dimension sollte „unique“ sein, d.h. eine echte n:1 Beziehung. Dies ist im Vorfeld durch den Aufbau der Dimension im ETLProzess zu prüfen. Auf Datenbank-Contraints zwischen Faktentabelle und Dimensionen sollte verzichtet werden. Sie bremsen die Ladeperformance aus. Die Dimension sollte in sich stimmig sein. D.h. der Schlüssel eines unteres Levels muss exakt auf einen Schlüssel des darüber liegenden Levels passen (N:1-Struktur). Prüfungen durch die Prozedur „validate_dimension“ im DBMS_SUMMARY-Package unter SYS können hier helfen. Fakten-Sätze sollten immer ein Pandant zu den jeweiligen Dimensionssätzen haben. Faktentabellen erhalten keinen explizit erstellten Primary Key. Der PK der Faktentabelle ergibt sich aus der Kombination aller Foreign Keys zu den Dimensionstabellen. Diese Schlüsselkombination muss nicht eindeutig sein. Dimensionen über den Star Schema Wizard erstellen Der Warehouse Builder hat einen speziellen Wizard um ein Starschema zu definieren. Man geht in zwei Schritten vor: 1. Erstellen aller relevanten Dimensionen. 2. Erstellen der Faktentabelle, wobei hier die Beziehungen zu möglichen Dimensionen in dem Modul automatisch erkannt wird. Bei der Definition von Dimensionsobjekten werden 4 Objekte entstehen: ■ Eine Tabelle, in der die Daten in der Datenbank abgespeichert sind ■ Eine Primary Key- Definition (Index) ■ Ein Dimensional Table-Objekt ■ Ein Sequence-Objekt zum Bilden des künstlichen Schlüssels. Dimension Artikel Aufgabenstellung: Erstellen einer Dimension mit Artikeln: - unterstes Level Artikel mit einer Artikel_ID - Level2 Artikelgruppendaten - Level3 Artikelspartendaten Zusätzlich zu dem Originalschlüssel soll ein künstlicher Schlüssel für die Dimension aufgebaut werden. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 177/300 Gehen Sie mit der rechten Maustaste in dem Modul Warehouse auf den Punkt DIMENSIONS und wählen Sie hier die Option New und Using Wizard. Der Dimension-Wizard startet. Vergeben Sie den Namen DIM_ARTIKEL. Next. Legen Sie den Storage type auf ROLAP fest (kann man später wieder ändern). Im nächsten Schritt legen Sie Attribute fest, die später den Leveln zugeordnet werden können. Wählen Sie hier die Attribute: - ID (Surrogate, number) - Originanl_Nummer (Business, number) - Name (varchar2(32)) - Beschreibung (varchar2(50)) Festlegung der Attribute, die später den einzelnen Leveln zugeordnet werden können Die folgende Maske fragt nach den Leveln. Es ist also für jedes Level ein Levelname zu vergeben. Next. Definition der Diemensions-Hierarchie-Level Jetzt sind die vorher festgelegten Attribute den Leveln zuzuordnen. Wählen Sie: Level Artikel: ID, Original_Nummer, Name, Beschreibung Level Gruppe: ID, Name Level Sparte: ID, Name Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 178/300 Zurodnung von Attributen zu Leveln. Hier am Beispiel von Level Artikel Danach wählen Sie die Slowly Changing Dimension Option. Nehmen Sie hier den einfachsten Fall Option 1. Next. Jetzt ist die erste Dimension angelegt und sie erscheint in dem Project Explorer des Design Centers. Dort können Sie alle Einstellungen auch wieder über den Object Editor ansehen und nachträglich modifizieren. Eine Änderung wollen wir zusätzlich noch anbringen: Für den Surrogate Key sollte automatisch ein Oracle Datenbank Sequence-Objekt entstehen. Rufen Sie hierfür den Object Editor für die neue Dimension auf. Data Object Explorer mit der neuen Dimension Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 179/300 Hier finden Sie bereits einen Eintrag mit dem Namen DIM_ARTIKEL_SEQ. Sie brauchen also nichts mehr zu tun. Bis jetzt haben wir lediglich die logische Definition einer Dimension angelegt. Es fehlt noch das Gegenstück in Form einer relationalen Tabelle. Hierzu ist ein Bind-Vorgang nötig. Drücken mit der rechte Maustaste auf den Kopf des Objektes und wählen Sie die Option Auto Bind. Bind: Ableiten einer relationalen Tabelle aus der Dimensionendefinition Es entsteht ein neuer Reiter (DIM_ARTIKEL), und das neue Tabellenobjekt wird dargestellt. Dimension und Tabelle Das Ergebnis ist jetzt eine zusätzliche Tabelle, die Sie auch in dem Design Center sehen können. Sie werden auch die Sequence finden, die zur Bildung des Künstlichen Schlüssels in einem später zu definierenden Mapping gebraucht wird. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 180/300 Generieren Sie jetzt alle Objekte, die neu entstanden sind mit dem Control Center. Zu Ihrer Orientierung sind hier die generierten Scripte dargestellt. CREATE TABLE "DIM_ARTIKEL" ( "DIMENSION_KEY" NUMBER NOT NULL, "BESCHREIBUNG" NVARCHAR2(50), "ORINIGAL_NUMMER" NUMBER(1), "ARTIKEL_NAME" VARCHAR2(32), "ARTIKEL_ID" NUMBER, "GRUPPE_ID" NUMBER, "GRUPPE_NAME" VARCHAR2(32), "SPARTE_NAME" VARCHAR2(32), "SPARTE_ID" NUMBER ) ; ALTER TABLE "DIM_ARTIKEL" ADD CONSTRAINT "DIM_ARTIK_DIMENSION_KEY_PK" PRIMARY KEY ("DIMENSION_KEY") ; CREATE DIMENSION DIM_ARTIKEL LEVEL "ARTIKEL" IS "DWH"."DIM_ARTIKEL"."ARTIKEL_ID" LEVEL "GRUPPE" IS "DWH"."DIM_ARTIKEL"."GRUPPE_ID" LEVEL "SPARTE" IS "DWH"."DIM_ARTIKEL"."SPARTE_ID" HIERARCHY "STANDARD" ( "SPARTE" CHILD OF "GRUPPE" CHILD OF "ARTIKEL" ) ATTRIBUTE "ARTIKEL" DETERMINES ( "DWH"."DIM_ARTIKEL"."BESCHREIBUNG", "DWH"."DIM_ARTIKEL"."ORINIGAL_NUMMER", "DWH"."DIM_ARTIKEL"."ARTIKEL_NAME" ) ATTRIBUTE "GRUPPE" DETERMINES ( "DWH"."DIM_ARTIKEL"."GRUPPE_NAME" ) ATTRIBUTE "SPARTE" DETERMINES ( "DWH"."DIM_ARTIKEL"."SPARTE_NAME" ) ; Create Sequence "DIM_ARTIKEL_SEQ" START WITH 1 INCREMENT BY 1 ; Mapping zum Erstellen der Dimension Aufgabenstellung: Gebraucht wird ein Mapping zum Befüllen der neuen Artikeldimension: Als Quellen dienen Artikel, Artikelgruppe, Artikelsparte aus dem SRC-Schema. Erstellen Sie ein neues Mapping mit dem Namen MP_ARTIKEL Ziehen Sie über den Explorer die drei Tabellen Artikel, Artikelgruppe und Artikelsparte aus dem Source-Modul in die Editorfläche. Ergänzen Sie das Mapping um die Zieltabelle DIM_ARTIKEL und die Sequence DIM_ARTIKEL_SEQ aus dem vorigen Abschnitt. (Achtung: benutzen Sie die Tabelle DIM_ARTIKEL, nicht das Dimensions-Objekt). Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 181/300 Ziehen Sie einen Joiner zwischen die Quell- und die Zieltabelle. Präparieren Sie den Joiner so, dass er drei Quelltabellen aufnehmen kann und benennen Sie die Eingabegruppen entsptechend der Eingabetabellen. Verbinden Sie jetzt die Quelltabellen mit dem Joiner. Übernehmen Sie einfach die kompletten Attributgruppen. Definieren Sie die Join-Bedingung wie unten im Bild dargestellt. Joinbedingung den Mappings zur Bildung der Artikeldimension Verbinden Sie jetzt nach folgender Vorschrift den Ausgang des Joiners mit der Zieltabelle: Quelle DIM_ARTIKEL_SEQ.NEXTVAL ARTIKEL.ARTIKELNR ARTIKEL.ARTIKELNAME ARTIKEL.ARTIKELNR ARTIKEL.ARTIKELGRUPPENNR ARTIKELGRUPPE.ARTIKELGRUPPENNAME ARTIKELSPARTE.ARTIKELSPARTENNAME ARTIKELGRUPPE.ARTIKELSPARTENNR Ziel DIMENSION_KEY ORINIGAL_NUMMER ARTIKEL_NAME ARTIKEL_ID GRUPPE_ID GRUPPE_NAME SPARTE_NAME SPARTE_ID Generieren Sie das Mapping und testen Sie es. Achtung: es kann nicht passenden Feldlengen kommen. Überprüfen Sie dieses vorher mit dem Validate in dem Mapping. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 182/300 Mapping MP_Artikel Das Ergebnis: Ausschnitt aus der Dimensionstabelle Um das Zielmodell zu vervollständigen, erstellen Sie in den nächsten Schritten in der gleichen Art die Dimensionstabellen DIM_REGION und DIM_KUNDE. Dimension Regionen Die Regionen-Dimension und die zugehörige Tabelle haben hat die folgenden Definitionen: Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 183/300 Dimension und zugehörige Tabelle DIM_REGION Um diese Dimension mit Daten zu füllen, laden sie aus den Beispieldaten die Tabelle REGIONEN. Das Mapping hierzu sieht sehr einfach aus: Mapping MP_Regionen Dimension Kunde Die Kunden-Dimension sollte ähnlich schnell und einfach erstellbar sein. Im Gegensatz zu den anderen Dimensionen besteht diese jedoch nur aus einem Level: der Kunde selbst. Erstellen Sie eine Dimension DIM_KUNDE und verwenden Sie als Muster hierfür und für die Inhalte die Tabelle KUNDE aus dem Schema SRC (Beispieldaten). Definieren Sie in dem Editor nur ein Level: KUNDE. Verwenden Sie keine Sequence. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 184/300 Die Tabellen- und Dimensionendefinition DIM_KUNDE Vorsicht Falle: Die Vorgabe besagte, dass nur ein Level in der Hierarchie erstellt werden soll. Oracle Warehouse Builder wird jedoch mindestens zwei Level von Ihnen fordern. Das merken Sie spätestens bei der Generierung. Dieses Verhalten ist eine Einstellung von OWB. Die multidimensionale Speicherkomponente der OLAP-Option erfordert dies. Fügen Sie deswegen in die Dimension noch ein Dummy-Level ein z. B. Name_Total. Erstellen Sie hierzu das passende Mapping MP_KUNDE und verwenden Sie die folgenden Herleitungen. Quelle ist die Tabelle KUNDE aus dem SRC-Schema und Ziel ist die neu erstellte Dimension. Quelle DIMENSION_KEY STATUS KUNDENNUMMER TELEFAX TITEL STRASSE KONTAKPERSON EINKOMMENSGRUPPE GESCHLECHT BRANCHE WOHNART FIRMENRABATT ANZ_KINDER VORNAME ORTNR GEBURTSDATUM BILDUNG TELEFON BERUFSGRUPPE KUNDENART Stand/letzte Änderung 13.05.2016 Ziel KUNDE.KUNDENNR KUNDE.STATUS KUNDE.KUNDENNR KUNDE.TELEFAX KUNDE.TITEL KUNDE.STRASSE KUNDE.KONTAKTPERSON KUNDE.EINKOMMENSGRUPPE KUNDE.GESCHLECHT KUNDE.BRANCHE KUNDE.WOHNART KUNDE.FIRMENRABATT KUNDE.ANZ_KINDER KUNDE.VORNAME KUNDE.ORTNR KUNDE.GEBDAT KUNDE.BILDUNG KUNDE.TELEFON KUNDE.BERUFSGRUPPE KUNDE.KUNDENART (in Arbeit) 75875104 Oracle Warehouse step-by-step NAME ANREDE 185/300 KUNDE.NACHNAME KUNDE.ANREDE Mapping MP_Kunde Generieren und testen Sie die neuen Objekte. Ergebnismenge DIM_KUNDE Die Zeitdimension Es fehlt noch die Zeitdimension. Hier gibt es bei Oracle Warehouse Builder ein Standardverfahren, das bis hin zur fertigen und mit Daten gefüllten Dimension führt. Starten Sie in dem Design Center mit der rechten Maustaste bei Dimensions den Wizard zur Erstellung einer Zeitdimension. Beachten Sie die Option Using Time Wizard. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 186/300 Erstellen einer Zeitdimension über separaten Wizard Vergeben Sie den Namen DIM_ZEIT. Next. Wählen Sie die Option ROLAP. Next. Jetzt werden Sie nach dem Zeitraum gefragt, für den Sie die Defnition haben wollen. Wählen Sie als Startjahr 1996 und für die Zeitdauer 14 Jahre (Die Beispieldaten haben diese breite Spanne, es sind sogar Daten aus dem Bereich jenseits der Gegenwart enthalten: ein Fall für das Data Profiling). Auswahl des Zeitfensters für die Zeitdimension Im nächsten Schritt wählen Sie die Hierarchiestufen für die Zeitdimension. Wählen Sie Jahr/Quartal/Monat/Tag. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 187/300 Festlegen der Hierarchiestufen der Zeitdimension Nachdem Sie jetzt Next gedrückt haben, wird OWB eine Reihe von Objekten anlegen. Das können Sie an dem Protokoll leicht erkennen. Es entsteht sogar ein Mapping. Generierungsprotokoll für alle Objekte rund um die Zeitdimension Öffnen Sie das das neu erstellte Mapping DIM_ZEIT_MAP. Wählen Sie die Option Autolayout. Sie können die einzelnen Objekte betrachten. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 188/300 Mapping zur Erstellung der Zeitdimension Generieren Sie die neuen Objekte. Beachten Sie alle Objekte, die automatisch erzeugt wurden. Das sind DIM_ZEIT DIM_ZEIT_SEQ DIM_ZEIT_MAP Starten Sie das Mapping und betrachten Sie sich das Ergebnis in dem Data Browser. Geladene Sätz des Mappings zur Erstellung der Zeitdimension Das Ergebnis Auszug mit Beispieldaten Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 189/300 Wenn Sie sich die Daten genau betrachten, werden Sie sehen, das die Zeitdimension Felder beinhaltet, an die sie zunächst vielleicht nicht gedacht haben. Das sind Felder für die Anzahl Tage einer Zeitperiode oder Start- und Endtag einer Periode. Diese Felder sind für die Würfel der Oracle OLAP-Option wichtig. Wenn Sie eine einfacher strukturierte Zeitdimension erstellen wollen, dann wählen Sie bei der Definition die Option für Standarddimensionen. Zum Füllen der so erstellen Zeitdimension können Sie die kleine Prozedur verwenden, die bei den Beispieldaten mitgeliefert wird: days_Tabelle_Create_und_Prozedur_und_Aufruf_Dt_Modell.sql In diesem Script ist zunächst die Definition einer Hilfstabelle TAGE angegeben. Und schließlich die Prozedur TIME_GEN. Beide Objekte kann man über SQL Plus anlegen. und die Prozedur dann über EXECUTE und den passenden Parametern aufrufen. ---- Die Tabelle Tage drop Table Tage; CREATE TABLE TAGE ( Datum_ID NUMBER(4) NOT NULL, Datum_Desc DATE NOT NULL, Tag_des_Monats NUMBER(2) NOT NULL, Tag_des_Jahres NUMBER(3) NOT NULL, Woche_des_Jahres NUMBER(2) NOT NULL, Monats_Nummer NUMBER(2) NOT NULL, Monat_Desc VARCHAR2(9) NOT NULL, Quartals_Nummer NUMBER(1) NOT NULL, Jahr_Nummer NUMBER(4) NOT NULL ); -------------------------------------------------------------------------- Die Prozedur Time_Gen create or replace procedure Time_Gen (startdate DATE, enddate DATE) AS incdate DATE; recno INTEGER; Begin incdate := startdate; recno := 1; while incdate <= enddate LOOP insert into Tage(Datum_ID , Datum_Desc, Tag_des_Monats, Tag_des_Jahres, Woche_des_Jahres, Monats_Nummer, Monat_Desc, Quartals_Nummer, Jahr_Nummer) Values (recno, incdate, TO_NUMBER(TO_CHAR(incdate, TO_NUMBER(TO_CHAR(incdate, TO_NUMBER(TO_CHAR(incdate, TO_NUMBER(TO_CHAR(incdate, TO_CHAR(incdate, 'Month'), TO_NUMBER(TO_CHAR(incdate, TO_NUMBER(TO_CHAR(incdate, 'DD')), 'DDD')), 'WW')), 'MM')), 'Q')), 'YYYY'))); recno := recno + 1; incdate := incdate + 1; END LOOP; END; Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 190/300 --Beispielaufruf der Prozedur z. B.: --exec time_gen('01011990','31121999'); -exec time_gen('01011990','31122005'); -exec time_gen(to_date('01011998','DDMMYYYY'),TO_DATE('31122004','DDMMYYYY')); -exec time_gen(to_date('01011996','DDMMYYYY'),TO_DATE('31122004','DDMMYYYY')); -- Hilfskommandos -- alter session set nls_date_format = 'DD-MON-YY'; Die Faktentabelle Es fehlt die Faktentabelle in der die Bewegungsdaten von Bestellung und Best_POS zusammenfliessen. Während die Erstellung der Faktentabelle selbst sehr schnell erledigt ist, wird das Mapping etwas aufwendiger werden, denn hier müssen eine Reihe von Umschlüsselungen vorgenommen werden. Wählen Sie zunächst den Wizard zur Erstellung der Faktentabelle an. Fakten heißen in OWB Cube. Also rechte Maustaste auf Cube und dann die Option New wählen. Erstellung einer Faktentabelle Vergeben Sie den Namen F_UMSATZ. Next. Wählen Sie die Option ROLAP. Next. Jetzt haben Sie die Möglichkeit die Dimensionen auszuwählen, die mit der neuen Faktentabelle verbunden werden sollen. Das bedeutet damit auch, dass Sie in die Faktentabelle die nötigen Fremdschlüssel generiert bekommen. Wählen Sie hier alle 4 Dimensionen, die Sie zuvor erstellt haben. Next. Auswahl der Dimensionen, die zur Faktentabelle gehören Jetzt können Sie die eigentlichen Faktenwerte festlegen. Wählen Sie die Werte, wie in dem folgenden Bild: Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 191/300 Festlegung der Measures oder Kennzahlen in der Faktentabelle Alle Eintragungen der neuen Faktentabelle kann man in dem Object Editor wieder verändern. Die reinen Definitionsarbeiten sind jetzt allerdings abgeschlossen. Das Befüllen der neuen Faktentabelle kann beginnen. Die neue Faktentabelle in der graphischen Darstellung des Data Object Editors Tip: In den folgenden Schritten wird die Faktentabelle mit Daten gefüllt. Es ist empfehlenswert, im Verlauf der Testphase die Defintion von Foreign-Keys und Indexobjekten zu unterlassen. Das bremst nur den Entwicklungsfortschritt, da zu Beginn der Entwicklung meist noch fehlerhafte Sätze angeliefert werden. Das Aktivieren von Fremdschlüsseln und Indexdefinitionen kann später nachgeholt werden. Sie schalten die Generierung unter Configuration bei der Tabelle F_UMSATZ aus. Entfernen des Häkchens bei Deployable. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 192/300 Konfiguration der Faktentabelle / Entfernen und Aktivieren der Generierung von Foreign Keys und Indexdefinitionen Das Füllen der Faktentabelle Als Quelle für das Füllen der Faktentabelle benutzen wir die Tabelle WH_TRANSAKTIONEN aus den vorhergehenden Schritten. Diese Tabelle ist auch den Beispieldaten beigefügt. Erstellen Sie ein neues Mapping mit dem Namen MP_F_UMSATZ. Ziehen Sie die Tabellen F_UMSATZ und WH_TRANSAKTIONEN in die Editorfläche Folgende Felder können Sie sofort miteinander verbinden: Quelle BESTELLEMENGE BRUTTOWERT KUNDENCODE Ziel MENGE UMSATZ DIM_KUNDE Für die Schlüsselfelder DIM_ARTIKEL und DIM_ZEIT müssen jetzt Lookup-Werte gefunden werden, denn den Dimensionstabellen haben andere Schlüssel. Bevor man diese Lookups in dem Mappingeditor entwirft, sollte man sich die Datenwerte der entsprechenden Tabellen vorher genau ansehen. Hier eignet sich der Data Viewer. Für die Artikelwerte muss man einen Lookup auf die Tabelle DIM_ARTIKEL durchführen und ARTIKELNR mit ORIGINAL_NUMMER vergleichen um aus der Tabelle DIM_ARTIKEL den Wert DIMENSION_KEY zu erhalten. Betrachtung über die Schlüsselwerte Ziehen Sie jetzt ein Lookup-Operator in die Editorfläche. Nennen Sie ihn ARTIKEL Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 193/300 Wählen Sie als INGRP-Felder WH_TRANSAKTIONEN. (Step 3) das Feld ARTIKELNR aus der Tabelle Ingroup-Feld ARTIKELNR für Lookup Wählen Sie als Lookup-Tabelle (Step 4) die Tabelle DIM_ARTIKEL (nicht das Dimensionsobjekt) Im unteren Bereich der Fläche können Sie jetzt die korrespondierenden Attribute wählen. Das sind ORIGINAL_NUMMER als Lookup Key und ARTIKELNR als Eingabefeld. Der letzte Schritt (Step 5) ist nur dokumentarisch. Sie können den Vorgang beenden und in dem Mappingeditor, der dann wieder freigegeben wird das Lookup-Ausgangsfeld DIMENSION_KEY mit dem Feld DIM_ARTIKEL der Zieltabelle verbinden. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 194/300 Rückgabefelder des Lookupvorgangs Tip: Um die Entwicklungsarbeit zu beschleunigen, kann man diese Lookup-Bedingung separat testen, auch wenn man die Zieltabelle noch nicht generiert hat: Man kopiert sich den Intermediate-Result-Code für die Zieltabelle in einen Texteditor und macht daraus ein Zähl-Statement. Intermediate Result für die Zieltabelle Modifikation zum Testen INSERT INTO "F_UMSATZ" ("UMSATZ", "MENGE", "DIM_ARTIKEL", "DIM_KUNDE") (SELECT "WH_TRANSAKTIONEN"."BRUTTOWERT" "BRUTTOWERT", "WH_TRANSAKTIONEN"."BESTELLMENGE" "BESTELLMENGE", NVL("ARTIKEL"."DIMENSION_KEY", NULL) "DIMENSION_KEY", "WH_TRANSAKTIONEN"."KUNDENCODE" "KUNDENCODE" FROM "WH_TRANSAKTIONEN" "WH_TRANSAKTIONEN" LEFT OUTER JOIN "DIM_ARTIKEL" "ARTIKEL" ON ( ( "ARTIKEL"."ORIGINAL_NUMMER" = "WH_TRANSAKTIONEN"."ARTIKELNR" ) ) ); (SELECT count(*) FROM "WH_TRANSAKTIONEN" "WH_TRANSAKTIONEN" LEFT OUTER JOIN "DIM_ARTIKEL" "ARTIKEL" ON ( ( "ARTIKEL"."ORIGINAL_NUMMER" = "WH_TRANSAKTIONEN"."ARTIKELNR" ) ) ); Idealerweise muss das Ergebnis die gleiche Anzahl Zeilen liefern, wie die Tabelle WH_TRANSAKTIONEN Sätze hat. Dieses schrittweise Testen ist hilfreich, weil später nur ein zuammenhängendes komplexeres Statement zur Verfügung steht. In manchen Szenarien kommt bei den ersten Tests kein einziger Satz in der Faktentabelle an. Dann kann die Suche nach der fehlerhaften Bedingung aufwendig sein. In einem alternativen Testkonzept können Sie die Zieltabelle auf TRUNCATE/INSERT stellen, das Mapping generieren und starten. Dann sehen Sie wie viele Sätz die Lookup-Bedingung erfolgreich bestanden haben. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 195/300 Das gleiche Verfahren ist mit der Zeitdimension durchzuführen. Ziehen Sie hierzu wieder einen Lookup-Operator in den Editor. Eingabefeld ist jetzt das Feld BESTELLDATUM der Tabelle WH_TRANSAKTIONEN. Wählen Sie als Vergleichsfeld DAY_NAME Vergleichsfelder für die Lookup-Bedingung ZEIT Verbinden Sie das Feld DIMENSION_KEY im Ausgang des Lookup-Operators mit dem Feld DIM_ZEIT in der Zieltabelle. Tip: Bei dem hier gewählten Verfahren wurde das Datum umgeschlüsselt. Sie werden in der Faktentabelle kein Datumsfeld mehr haben. Es kann praktisch sein, wenn man auf diese Umsschlüsselung verzichtet. Es ist durchaus üblich, Datumsfelder in die Faktentabelle mitaufzunehmen, vor allem dann, wenn über dieses Feld partitioniert werden soll. Bei dieser Vorgehensweise müssen Sie aber die Zeitdimension als eine normale Dimension anlegen, da das Standardverfahren immer von künstlichen Nummernschlüssel ausgeht. Jetzt wird die Regionen-Dimension angeschlossen. Hierfür benötigen Sie zwei Umschlüsselungen. In der Tabelle WH_TRANSAKTIONEN finden Sie nur die Kundennummer. Wo der Kunde jedoch wohnt, wissen Sie erst, wenn Sie in der Kundendimension nachgeschaut haben. Dort findet sich die Ortenummer. Mit dieser Ortenummer müssen wir dann wieder in der Regionendimension nachsehen, um den Dimensionsschlüssel abzugreifen. Ziehen Sie zwei Lookupoperatoren in die Editorfläche des Mappings. Nennen Sie den ersten KUNDE_ORT. INPUT für diesen ersten Lookup ist KUNDENCODE, die Lookutabelle ist DIM_KUNDE, Vergleichsfelder sind DIMENSION_KEY und KUNDENCODE Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 196/300 Vergleichsbedingungen für Kunden-Lookup Den zweiten Lookup-Operator nennen Sie ORT Als Input-Feld wählen Sie jetzt das Feld ORTNR des ersten Lookup-Operators KUNDE_ORT. Lookup-Eingabe-Feld ORTNR Als Lookup-Tabelle wählen Sie DIM_REGION und als Vergleichsfelder ORT_NUMMER und ORTNR. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 197/300 Vergleichsbedingungen des Lookup-Operators ORT Beenden Sie den Vorgang und verbinden Sie das Feld DIMENSION_KEY des Operators mit dem Feld DIM_REGION der Zieltabelle. Das fertige Mapping müsste jetzt wie unten dargestellt aussehen. Auf das Füllen der noch leeren Felder wird hier verzichtet. Hierfür kann man sich beliebige Expressions, also Berechnungen vorstellen. Mapping MP_F_UMSATZ Ein Ausschnitt aus der Tabelle F_UMSATZ : Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 198/300 Vermeiden von Fehlern beim Schreiben der Faktentabelle Wenn man sich die Faktentabelle genau betrachtet, findet man bei einigen Dimensionswerten (DIM_REGION und DIM_ZEIT) Lücken. Hier sind tatsächlich Fehler in der Ausgangsdatenmenge. Der Lookup-Vorgang in dem Mapping MP_F_UMSATZ lässt diese Lücken zu, wenn in der Lookup-Tabelle kein passender Wert für die Eingabesätze gefunden wird. Eine sinnvolle Vorgehensweise ist das nicht, denn die betroffenen Sätze sind nicht mehr abfragbar, Auswerteergebnisse werden verfälscht. In der Faktentabelle sollten keine Sätze vorhanden sein, die keinen Eintrag in den Fremd-Schlüsselattributen besitzen. Die beste Vorgehensweise zur Vermeidung solcher Effekte, ist das vorherige Prüfen bevor man in die Faktentabelle schreibt. Hierzu erstellt man sich eine temporäre Tabelle mit den über Lookups erzeugten Faktenwerten. In die eigentliche Faktentabelle werden schliesslich nur die Sätze mit vollständigen Schlüsseln übernommen. Alle anderen Sätze steuert man am besten zusammen mit den Orginalwerten in eine separate Protokolltabelle aus. Ein solches Mapping kann z. B. so aussehen: Mapping MP_F_UMSATZ_KORR zum Verhindern von fehlerhaften Foreign-Key-Werten in der Faktentabelle Korrigierte Faktentabelle Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 199/300 Ausgesonderte Faktensätze mit mindestens einem fehlenden Schlüssel in DIM_REGION oder DIM_ZEIT Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 200/300 6. Automatisieren der Ladeprozesse-Workflow und Scheduling Ladeläufe müssen flexibel sein Bislang haben wir einzelne Mappings erstellt, um die Aufgabenstellung dieses Szenarios zu lösen. Wir hätten alle Ladeschritte in einem einzigen Mapping unterbringen können. Allerdings ist diese Vorgehensweise nicht sinnvoll. Sie gleicht der „Spaghetti-Code-Programmierung“, bei der nur der Programmierer selbst noch durchblickt, und auch das nur noch wenige Tage nach Abschluss des Projektes. Außerdem fehlt uns dann die nötige Flexibilität, denn nicht immer müssen alle Mappings zusammenhängend zu einem bestimmten Zeitpunkt laufen. Struktur des Ladeprozesses Durch eine mindestens 4-stufige Gestaltungsmöglichkeit liefert der Ladeprozess die Flexibilität, um Ladeläufe je nach Anforderung in mehreren Varianten ablaufen zu lassen. Die vier Stufen sind: Transformationslevel: Wandeln und Laden auf Feldebene. Das sind Funktionen, wie sie z. B. als Datenbankfunktionen bekannt sind (substr,, Expression...). das entspricht den einzelenen Linien in einem OWB-Mapping. Mappinglevel: Wandeln und Laden auf der Ebene von einer oder mehreren Tabellen. Zusammengefasst werden logisch zusammen gehörende Tabellen (technisch-funktionale Zusammenhänge). Betrachtet werden z.B alle Quelltabellen, die zum Füllen von ein oder mehreren zusammenhängenden Tabellen ( z. B. Parent / Child-Konfigurationen) nötig sind. Die tabellenbezogene Verarbeitung wird komplett abgeschlossen, beinhaltet also Inserts/Update/DeleteVorgänge. Prozesslevel I: Mehrere Mappings sind zu Verarbeitungsfolgen zusammengeschlossen. Es entstehen zusätzliche, den Mappings übergeordnete Einheiten, die sich in ihrer inneren Struktur wenig verändern, also nicht mehr manuell angefasst werden müssen. Zusammen gehören z. B. das Füllen aller Dimensionen und Fakten eines Starschemas, das Aufbauen eines Data Marts usw. Prozesslevel II: Diese Stufe sorgt für die flexible Gestaltung des Gesamtprozesses. Die Verarbeitungsfolgen des Prozesslevel I können hier flexibel kombiniert werden. Auf dieser Ebene ist spontanes Umhängen einzelner Abfolgen mit graphischen Mitteln möglich. Auf diesem Level kann z. B. im Verlauf des Warehouse-Betriebs entschieden werden, ob ein Starschema in einer Ladeperiode gefüllt oder ausgespart wird. 4 Ebenen der Datenflusssteuerung im Data Warehouse Die Mappings sind in einem Workflow zusammenzufassen. Der Workflow wird über Modellierungseditoren graphisch dargestellt und technisch über eine PL/SQL-Prozedur in der Datenbank realisiert. Zur Lauffähigkeit ist die Installation des Workflow-Servers in der OracleStand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 201/300 Datenbank nötig (siehe hierzu die Hinweise zur Installation des Workflows). Der Workflow-Server wird im Default in dem Schema OFW_MGR installiert. Der WAREHOUSE BUILDER besitzt einen Prozess-Editor. Über diesen Editor erstellen Sie graphisch den Prozess, indem Sie die benötigten Mapping durch Linien miteinander verbinden. Aus diesem graphisch dargestellten Prozess erstellt der WAREHOUSE BUILDER durch den Generierungsprozess die Workflowprozedur, der Deploy-Vorgang überführt die Prozedur in das Datenbankschema des Workflow-Servers (OWF_MGR). Jetzt muss diese Prozedur nur noch ähnlich wie die Mappings gestartet werden. Erstellen von Prozessen Das Arbeiten mit dem Prozess-Editor ist eine eigenständige und von dem Erstellen der Mappings unabhängige Aufgabe. Der Prozess-Editor hat ebenfalls eine Reihe von Operatoren. Hier nennt man sie allerdings Aktivtäten oder Activities. Zu Beginn sollten grundsätzliche Dingen zur Erstellung von Prozessen erklärt werden. Wir nutzen hierzu sehr einfache rudimentäre Mappings. Da das Ergebnis einer Prozessmodellierung in Form einer PL/SQL-Prozedur in einem Datenbankschema landet, benötigen wir auch hier wieder ein Modul und zu diesem Modul, eine Location, die auf das Workflow-Schema zeigt (OWF_MGR). Definition von Prozessen Erstellen Sie ein Modul mit dem Namen SZENARIO (-> Rechte Maustaste auf Process Flow Modules -> New). Sie werden aufgefordert eine Location anzugeben (LC_OWF_MGR). Jetzt haben Sie die Möglichkeit Prozesspakete anzulegen. Alle Prozesse, die Sie später in einem Prozesspaket definieren, werden in dem generierten Konstrukt in einer PL/SQL-Package landen, sie können sich also gegenseitig sehen und aufrufen. In dem ersten Beispiel geht es nur um die grundsätzliche Arbeitsweise des Workflows, die zu vergebenden Namen sind also belanglos. Definieren Sie eine Gruppe mit dem Namen Prozesse (-> Rechte Maustaste auf SZENARIO -> New). Und schliesslich können Sie jetzt eine Prozess mit dem Namen P1 anlegen (-> Rechte Maustaste auf Prozesse -> New). Es erscheint der Prozess-Editor. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 202/300 Prozess-Editor nach dem ersten Aufruf Der Prozess-Editor ist zwar auf den ersten Blick ähnlich aufgebaut, wie der Mapping-Editor, hat jedoch an einige Stellen wichtige Unterscheidungsmerkmale. Im rechten Bereich gibt es wieder die Arbeitsfläche, in der alle Aktivitäten Platz finden. Auch er hat eine Palette mit den möglichen Aktivitäten. Diese ist unterschieden in Utility- / OWB specific- und Control-Activities. Es gibt auch ein Object Details-Fenster, das die Eigenschaften der in der Arbeitsfläche selektierten Aktivitäten anzeigt. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 203/300 Object Details- Fenster Eine besondere Rolle spielt der Explorer. Neben der Option „Available Objects“ gibt auch den Reiter „Selected Objects“. Unter dieser Auswahl finden Sie später alle Detailsichten und Eigenschaften der verwendeten Aktivitäten. Sie selektieren diese Eigenschaften und setzen über das Object DetailsFenster die gewünschten Werte. Diese Bedienungsart müssen wir später noch genauer kennenlernen. Explorer-Fenster mit der Option Selected Object Das erste Beispiel – einfache Workflows Zum Kennenlernen der Möglichkeiten erstellt man sich am besten sehr einfache Mappings, so dass man bei dem Experimetieren nicht noch Gefahr läuft, sich mit Fehlern in komplexen Mappings herumschlagen zu müssen. Zunächst helfen zwei einfache Mappings M1 und M2. Startmapping M1 Erstellen Sie diese Mappings entsprechend der Graphik. M1: Ziel ist eine Tabelle T1. Dort wird ein Aufrufparameter in F1 und eine Zeitangabe über eine Konstante (Wert: TO_CHAR(sysdate,'DD.MM.YYYY::HH24:MI:SS')) abgelegt. Pro Lauf entsteht nur ein Satz. Für spätere Tests ist ein Ausgabeparameter definiert. Belegen Sie den Aufruf-Parameter mit einem Default-Wert z. B. ’A’. Das erspart Ihnen unnötige Parameter-Eingaben. M2: Das Mapping M2 ist noch einfacher. Es übernimmt die Sätze von T1 und schreibt sie in die Tabelle T2. Mapping M2. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 204/300 Erstellen Sie den ersten Workflow, indem Sie in dem Explorer-Fenster unter Available Objects beide Mappings M1 und M2 selektieren und in die Process-Flow-Editor-Fläche mit drag And Drop verschieben. Wenn Sie die Maus über die Aktivitäten-Objekte führen, ändert sich die Mauszeigerform zur Pfleilform. Jetzt können Sie mit der gedrückten linken Maustaste Verbindungen ziehen von der Startaktivität bis zur Aktivität M2 und dort den Knopf wieder loslassen. Es sollte eine Verbindungslinie erscheinen. Man nennt diese Linien Transision. Ihr Prozess ist jetzt schon fertig. Er muss noch generiert und getestet werden. Das machen Sie in dem Control Center unter der Location, die Sie für das Workflow-Schema OWF_MGR definiert und Ihrem Prozessmodul zugewiesen haben. Im Ergebnis stellen Sie fest, dass beide Mappings nacheinander aufgerufen wurden. Der Execution Schedule- Report zeigt Ihnen: AND und FORK Dieses einfache Beispiel kann beliebig erweitert werden. Erstellen Sie das weitere Mapping M3, in dem die Sätze der Tabelle T1 in eine neue Tabelle T3 kopiert werden. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 205/300 Mapping MP3 Sie könnten dieses Mapping in den bestehenden Prozess hinter das Mapping M2 hängen. Wir bauen jedoch noch zusätzliche Steuerelemente ein und zwar das gezielte parallele Starten (FORK) und die AND-Aktivität. Erstellen Sie einen neuen Prozess P2. Ziehen Sie die 3 Mappings M1,M2 und M3 in die Editor-Fläche. Ordnen Sie M1 und M2 übereinander und M3 rechts daneben an. Ziehen Sie jetzt aus der Palette die Fork und die AND- Aktivität hinzu. Ordnen Sie alle Aktivitäten wie auf dem zugehörigen Bild an und verbinden Sie mit den nötigen Transition-Linien, wie in dem Bild gezeigt. Prozess P2 Generieren und Testen Sie den Prozess. (Beachten Sie, dass das Control Center jetzt beide Prozesse neu erzeugt. Alle Prozesse, die Sie unter dem Punkt PROZESSE abgelegt haben, werden schließlich in ein Package hinein generiert). Durch die Fork –Aktivität starten M1 und M2 parallel. Grundsätzlich arbeitet die Datenbank schon parallel. Man wird also durch diese Steuerung keinen Performancegewinn erzielen. Man hat jedoch die Möglichkeit für einen gemeinsamen, gesicherten Abschluss zu sorgen, denn durch die ANDAktivität wird garantiert, dass M3 erst startet, wenn M1 und M2 abgeschlossen sind. Schleifen bilden Für bestimmte Aktivitäten ist es sinnvoll, Aktivitäten mehrmals durchzuführen. Eine File ExistAktivitäten soll z. B. für unterschiedlichen Verzeichnisse mehrfach durchlaufen werden, bis eine passende Datei wirklich gefunden wurde. Zwei Arten von Schleifen stehen zur Verfügung: 1. WHILE-Schleife für Wiederholungen mit Boolschen Abbruch-Entscheidungen (TRUE/FALSE) 2. FOR-Schleife für zählbare Abbruch-Kriterien, bei denen eine über eine Variable definierte Anzahl Schleifendurchläufe absolviert wird. In dem folgenden Beispiel soll das Mapping M1 10 mal durchlaufen werden. Erstellen Sie einen neuen Prozess P3. Fügen Sie die Mappings M1 und M2 und eine FOR-Schleife ein. An der FOR-Schleife hängt bereits eine End-Loop-Aktivität . Verbinden Sie alle Aktivitäten entsprechend dem Bild (Bild zu dem fertigen Prozess P3). Zur Ablaufsteuerung benötigen wir eine Variable, in der wir die Anzahl der Läufe so oft hochzählen, bis wir das Abbruchkriterium erreichen. Eine Variable können wir nur über die Selected Objects-Auswahl des Explorers definieren. Selektieren Sie in dem Baum den ordner Variables. Drücken Sie jetzt auf das Plus-Zeichen im Kopfbereich des Explorers. Es entsteht ein neuer Eintrag mit dem Namen Variable. Selektieren Sie dieses Objekt und Sie können in dem Object Details-Fenster die Eigenschaften des Objektes verändern. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 206/300 Setzen Sie die Eigenschaften der Variablen auf Name: V_FOR_LOOP Data Type: INTEGER Literal: false Es wird eine Zählvariable deswegen integer. Literal weist den späteren Generierungsprozess an, den verwendeten Ausdruck entweder in Hochkommatas zusetzen oder den Ausdruck so zu belassen, wie er in das Feld geschrieben wurde. Für die korrekte Arbeitsweise des Prozesses ist die richtige Wahl des Literals wichtig. Feste Ausdrücke wie z. B. Zahlenwerte brauchten keine Hochkomma, also Literal -> false. Weiter unten kommen jedoch auch noch Ausdrücke wir Variable_Name + 1. Diese müssen in Hochkomma gesetzt werden, also Literal -> true. Jetzt müssen wir die Bedingung für die FOR-Schleife festlegen. Selektieren Sie mit der Maus die Aktivität FOR_LOOP. Setzen Sie für Optionen die folgenden Werte: CONDITION: Value: V_FOR_LOOP<10 Literal: false INITIAL_VALUE: Value: Literal: 1 true NEXT_VALUE: Value: Literal: V_FOR_LOOP+1 false VARIABLE: Binding: V_FOR_LOOP Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 207/300 Die Festlegung der Bedingungen für die FOR-Schleife Generieren und Testen Sie den Prozess. In der Tabelle T1 müssten jetzt 9 Zeilen entstehen. Prozess P3 Das Ergebnis in der Tabelle T1 Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 208/300 Wechselspiel von Variablen und Parameter Mit einer kleinen Änderung können wir ein mögliches Wechselspiel zwischen Variablen des Prozesses und Input-Parametern der Mappings testen. Das Mapping M1 verfügt über einen Eingabe-Parameter, den wir in dem Mapping bereits mit dem Zeichen ’A’ vorbelegt haben. Dieser Parameter soll jetzt durch den Wert der Schleifenzählervariable durch Parameterübergabe für jeden Schleifendurchlauf überschrieben werden. Die Kommunikation mit den Mappingparametern (ob Input- oder Output) erfolgt über das sogenannte Binding. Kopieren Sie den Pozess P3 und machen Sie daraus den Prozess P4. Markieren Sie in dem Prozess P4 das Mapping M1. Unter Selected Objects sehen Sie unter dem Mapping die möglichen Parameter, u. a. auch den Parameter EINGABE_M1 Selektieren Sie diesen und unter dem Fenster Object Details erscheinen die Eigenschaften des Parameters. Jetzt können Sie Binding in der Listbox die Variable V_FOR_LOOP wählen. Diese Variable wird pro Schleifenlauf hochgezählt. Generieren Sie den Prozess und Testen Sie ihn. In der Tabelle T1 sollten jetzt 9 Sätze erscheinen, in denen hochgezählte Werte vorkommen. Das Ergebnis in der Tabelle T1 Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 209/300 Parameterübergabe von Mapping zu Mapping In dem nächsten Beispiel soll ein Mapping Werte einem nachfolgenden Mapping übergeben. Dies gelingt ebenfalls über das Binding und mit Hilfe einer Variablen, die als „Mittler“ zwischen den Mappings fungiert. Definieren Sie hierfür zunächst ein Testmapping M4, entsprechend der folgenden Darstellung. Mapping M4 Generieren Sie die neue Tabelle T4 und das Mapping M4. Testen Sie das Mapping, bevor Sie den folgenden Prozess erstellen. Das Mapping verfügt über einen Eingabe-Parameter mit dem Namen M4_EINGABE. Die Konstante ZEIT dient nur als Kontrolleingabe damit erkannt werden kann, wann die Zeile geschrieben wurde. In dem neuen Prozess übernimmt eine Variable den Ausgabewert des ersten Mappings und übergibt den Wert an den Eingabeparameter des nachfolgenden Mappings. Schema der Parameterübergabe von Mapping zu Mapping in Prozessen Erstellen Sie sich einen neuen Prozess P5. Fügen Sie die beiden Mappings M1 und M4 dort ein. Positionieren Sie die beiden Mappings nebeneinander und verbinden Sie diese mit den TransitionLinien. Definieren Sie eine Variable mit dem Namen V_M1_M4 (über den Selected Objekts-Bereich mit dem +-Symbol). Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 210/300 Prozess P5 Unter Selected Objects in dem Explorer sind die beiden Mappings M1 und M4 aufgelistet. Unter M4 finden Sie auch den Parameter M4_EINGABE Selektieren Sie den Parameter. In dem Object Details-Fenster können Sie unter Binding die zuvor definierte Variable V_M1_M4 auswählen. Wiederholen Sie den Vorgang mit dem Parameter M4_Eingabe, indem Sie auch diesen mit der Variablen ’zusammenbinden’. Generieren Sie den Prozess und testen Sie ihn. In der Zieltabelle T4 erscheint ein Satz mit dem Wert, der als Default für den Ausgabe-Parameter des Mappings M1 festgelegt wurde. Umgang mit Dateien - File Exists Aktivität Eine der häufigsten Quellen In Warehouse-Systems sind immer noch Textdateien. Diese liegen irgendwo auf Servern oder werden mittels FTP angeliefert und letztlich zwischen Verzeichnissen hinung herkopiert. Das Nichtvorhandensein von Textdateien ist eine der häufigsten Ursachen für Ladeabbrüche im produktiven Betrieb des Data Warehouse. Hier hilft die File Exists Aktitivität. Kopieren Sie sich die Textdatei FF_BESTELLUNG aus den Beispieldaten in ein Verzeichnis aus dem Sie später auch mit External Tables lesen können (nicht Voraussetzung, es ist nur ein Vorgriff auf spätere Übungen). Erstellen Sie ein neues Prozess-Package BESTELLUNGEN. Erstellen Sie innerhalb dieses Packages einen neuen Prozess B1. Ziehen Sie die FILE_EXITS Aktivitität in die Editorfläche. Ziehen Sie zusätzlich noch eine END_ERROR Aktivität in die Editorfläche. Verbinden Sie alle Aktivitäten entsprechend dem Bild. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 211/300 Mapping B1 Selektieren Sie die FILE_EXITS Aktivitität. Sie finden jetzt in dem Explorer-Fenster unter Selected Objects das FILE_EXISTS Objekt und die Möglichkeit eine Pfadangabe vorzunehmen. Markieren Sie PATH und tragen Sie in dem Object Details Fenster unter Value die Ablagestelle Ihrer Datei ein. Optionen zum Ansteuern der Textdatei Ändern Sie jetzt die Zustände der Transitions zwischen der FILE_EXITS Aktivitität und den beiden Ausgängen des Prozesses. Bei der Wahl der Conditions stellen Sie fest, dass sich die Optionen geändert haben. Sie können zwischen - MISSING, - FILE_EXITS, - END_ERROR wählen. Daran erkennen Sie, dass die Bedingungen, für die Weiterverarbeitung nach Abschluss einer Aktivität auch unterschiedlich ausfallen können. Wählen Sie für den Fehlerausgang die Option „Missing“ und für den Success-Fall die Option FILE_EXISTS Generieren Sie den Prozesse, und testen Sie ihn, in dem Sie abwechselnd die Datei z. B. umbenennen. Standard-Conditions für Transitions, die aus der FILE EXITS Aktivität weggehen Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 212/300 Jenachdem, ob die Datei korrekt vorhanden ist oder nicht, wird der Prozess einen Fehler nach aussen melden oder nicht. Sie sehen das in dem Laufzeitprotokoll. Umgang mit externen Aufrufen Dateien File Exists Aktivität Das vorangegangene Beispiel lässt die Frage aufkommen, was zu tun ist, wenn die Datei nicht da ist. Dann könnte z. B. ein Kopiervorgang die Datei beschaffen. Dazu sind Kommandoaufrufe in das Betriebssystem durchzuführen. Die einfachste Variante hierfür ist das Aufrufen einer Kommando-Datei (Stapel-/Batchdatei). Wir können auch den Kommando Interpreter CMD (z. B. c:\windows\system32\cmd.exe) aufrufen und entsprechende Parameter anhängen. Das einfachste Verfahren ist allerdings eine Batch-Datei mit den Kommandos zu erstellen und diese einfach nur aufzurufen. Das hat den Vorteil, dass die auszuführenden Kommandos unabhängig von den einmal generierten Prozessen des Warehouse Builders verändert werden können. Anforderung: Eine Datei soll dann kopiert werden, wenn sie nicht in einem angegebenen Verzeichnis exisitiert. Kopieren Sie den Prozess B1 und erstellen Sie daraus den Prozess B2. Erstellen Sie sich neben dem Verzeichnis für Ihre Testdaten, das bereits exisitiert noch ein zweites Verzeichnis Testdaten2, aus dem heraus Sie die Datei kopieren können, wenn sie noch nicht exisitiert. Erstellen Sie sich eine Batch-Datei RUN.BAT zum Kopieren mit folgendem Inhalt: copy D:\Szenario\Testdaten2\*.* D:\Szenario\Testdaten Ergänzen Sie jetzt den Prozess um die Aktititäten: USER_DEFINED und eine zweite FILE_EXISTS Aktivität und ordnen Sie die Objekte wie in dem folgenden Bild: Prozess B2 Absetzen Betriebssystem-Kommandos und File_Exist Die Transitions in dem Bild sind durchnummeriert. Sie besitzen die folgenden Bedingungen: 0: leer 1: EXISTS 2: MISSING 3: leer 4: leer 5: MISSING 6: EXISTS 7: leer Die Aktivität USER_DEFINED besitzt unter COMMAND den Aufruf der Batch-Datei. Alle anderen Parameter sind leer. (-> Selected Objects). Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 213/300 Aufrufsteuerung der Batch-Datei In diesem Prozess ist eine Aktivität END_WARNING eingebaut, weil der Warehouse Builder nach den FILE_EXISTS Aktivitäten immer eine „unbedingte“ Transition erwartet. Dies ist eine Sicherheitsmassnahme dafür, dass ein Prozess auch immer zum Ende kommt. Generieren Sie den Prozess und testen sie ihn indem Sie die Textdatei aus dem einen Verzeichnis löschen und aus dem anderen Verzeichnis kopieren lassen. Ergebnis-Protokoll des Laufs Security von externen Aufrufen freischalten Achtung: Das Aufrufen von externen Prozessen und Programmen ist geschützt. Damit dieses funktioniert muss man in einer OWB-Properties-Datei einen Parameter freischalten: Das Verzeichnis . .owbhome..\owb\bin\admin und hier die Datei: Runtime.properties. Hier muss am Ende der Datei folgendes stehen: # # FTP, Shell amd SQLPlus operator are disabled by default # property.RuntimePlatform.0.NativeExecution.FTP.security_constraint = NATIVE_JAVA property.RuntimePlatform.0.NativeExecution.Shell.security_constraint = NATIVE_JAVA property.RuntimePlatform.0.NativeExecution.SQLPlus.security_constraint = NATIVE_JAVA Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 214/300 Aufrufen von SQL Plus aus einem Prozess SQL Plus-Aufrufe stellen die einfachste Variante dar, individuelle Aktivitäten in der Datenbank durchzuführen und dabei einen direkten Kontakt zu allen Datenbank-Objekten zu haben. Über die Aktivität SQLPLUS kann man eine SQL*Plus Session im Hintergrund starten und alle Datenbank-Kommandos absetzen, die über SQL*Plus möglich sind. In dem folgenden Test werden wir eine native INSERT-Anweisung durchführen und zusätzlich eine Prozedur aufrufen. Erstellen Sie hierfür zunächst eine kleine Hilfstabelle: CREATE TABLE T (F1 varchar2(500)); Und eine Prozedur: CREATE OR REPLACE PROCEDURE P_INSERT_T(AUFRUF IN VARCHAR2) IS BEGIN INSERT INTO T VALUES (Aufruf) ; COMMIT ; END; / Beide Objekte können Sie natürlich auch mit dem Warehouse Builder erzeugen. Oder den Code oben mit Cut / Paste in SQL Plus absetzen. Erzeugen Sie jetzt einen neuen Prozess mit dem Namen P_SQLPLUS. Ziehen Sie die Aktivität SQLPLUS in die Editorfläche und verbinden Sie diese mit dem Start- und End-Punkt. Selektieren Sie die Aktivität SQLPLUS, so dass Sie unter dem Explorer-Fenster und Selected Objects die Eigenschaft SCRIPT anwählen können. Sie können jetzt unter Object Details und Value ein Fenster öffnen, um die SQLPLUSKommandos abzusetzen. Tragen Sie in dieses Fenster den folgenden Code ein: insert into t values ('Dies ist ein Text') ; begin p_insert_t('Aufruf von der Prozedur') ; end ; / exit Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 215/300 Prozess zum Aufruf von SQL Plus und Beispielkommandos Es fehlt jetzt noch die Information, unter welchem Benutzer SQLPlus gestartet werden soll. Das steuern Sie über die Eigenschaften (Configure) des Prozesses. Selektieren Sie dazu mit der rechten Maustaste den Prozess und öffnen Sie die Configuation Properties. Unter den SQL Plus-Eintragungen stellen Sie unter Deployed Location die Location des Zielschemas ein. Also diejenige Location unter der SQL Plus gestartet werden soll. Damit sind auch die Login-Informationen für SQL Plus festgelegt. SQL Plus-Konfiguration Generieren Sie den Prozess und testen sie ihn. Das Ergebnisprotokoll müsste so aussehen: Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 216/300 Ergebnisprotokoll Parameterübergabe an SQL Plus SQL Plus-Aufrufe können über Parameter dynamisiert werden. Anforderung: gehalten werden. Eine Skript-Datei mit SQL-Befehlen soll über Parameteraufrufe dynamisch Zur Lösung der Aufgabe legen Sie zunächst ein Script mit parametrisierten SQL-Befehlen an: File: SQLSCRIPT insert into t values ('Der Wert des ersten Parameters ist &1') ; insert into t values ('Ein zweiter Parameter ist &2') ; exit Erzeugen Sie einen neuen Prozess mit dem Namen P_SQLPLUS_DYN. Ziehen Sie die Aktivität SQLPLUS in die Editorfläche und verbinden Sie diese mit dem Start- und End-Punkt. Selektieren Sie die Aktivität SQLPLUS, so dass Sie unter dem Explorer-Fenster und Selected Objects die Eigenschaft PARAMETER_LIST anwählen können. Sie können jetzt unter Object Details und Value einen Parameterwert eingeben Geben Sie folgenden Wert ein: ?${Target.User}/${Target.Password}@${Target.URL}?@C:/sqlscript.sql?value 1?value 2? Diese Eingabe sollte erläutert werden. Zunächst ein paar grundlegende Eigenschaften. Parameter-Aufrufe werden durch Oracle Warebuilder interpretiert. Bei dieser Interpretation sind Hilfsmittel möglich, z. B. das „?“. Dieses Fragezeichen dient als Separator. Es wird von OWB als solcher erkannt, weil es als erstes Zeichen des gesamten Ausdrucks vorkommt. Damit haben wir schon die Möglichkeit einen Ausdruck zu unterteilen, was wichtig ist, wenn Aufrufe aus mehreren Teilen bestehen. Jetzt zu dem SQL Plus-Aufruf: Ein SQLPlus-Aufruf auf der Kommando-Ebene hat die folgende Form: SQLPLUS user/Passwort@sid @script.sql Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 217/300 Der String ‚SQLPLUS’ wird von OWB intern gesetzt. Dazu müssen wir also nichts mehr tun. User, Passwort und SID sind Informationen, die über die Locations bereits gesetzt sind, d. h. hier benötigen wir OWB-Variablen, um diese Daten abzufragen. Das sind Eigenschaften des internen OWB-Objektes TARGET, also: Target.User Target.Password Target,URL Die Variablen werden über das $-Zeichen gekennzeichnet also: ${Target.User} ${Target.Password} ${Target,URL} Werte, die das System einfach durchreichen soll, sind mit dem Ausdruck „value“ gekennzeichnet. Jetzt muss der Ausdruck nur noch zusammengesetzt werden, so wie oben geschehen. Prozess P_SQLPLUS_DYN und Festlegung der Parameterliste Generieren Sie den Prozess und testen sie ihn. Achten Sie darauf den Prozess richtig zu konfigurieren. Es muss die Location des Zielschemas angegeben werden, so wie das in dem Beispiel zuvor bereits geschehen ist. Das Ergebnisprotokoll müsste so aussehen: Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 218/300 Die Ergebnis-Log-Information Steuerung der Prozesse über das Control Center Aufrufen von Prozessen und Mappings – Scheduling Scheduling mit OWB-fremden Schedulern Warehouse-Prozesse laufen selbständig oder als Folge von Ereignissen. Das manuelle Starten ist nur in Ausnahmefällen üblich. In den Rechenzentren von Unternehmen existieren oftmals SchedulingProgramme, die an einer Stelle zentral alle Jobs starten, die den täglichen Produktionsbetrieb der Softwarelösungen ausmachen. In dieser Weise können auch Warehouse Builder Mappings bzw. Prozesse gestartet werden. Zum Aufrufen hierfür gibt es Hilfsroutinen, die bei der Installation von OWB mit in ein Unterverzeichnis kopiert werden. Sehen Sie hierzu das Unterverzeichnis: OWBHOME\OWB\RTP\SQL. Hier sind es die Scripte sqlplus_exec_template.sql und sqlplus_exec_background_template.sql Diese Scripte sind selbserklärend. D. h. Sie können sie in einen Editor laden und den Hinweisen im Kopfbereich der Scripte folgen. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 219/300 Verzeichnis mit Verwaltungsscripten des OWB, u. a. Hilfsscripte zum Aufrufen mit separaten Schedulern Scheduling mit OWB Der Warehouse Builder besitzt jedoch auch einen eigenen Scheduler. Hierzu definieren Sie zunächst ein Scheduler-Objekt. Hier hinterlegen Sie seine Gesamtgültigkeitsdauer und eine Wiederholerfrequenz mit der Prozesse oder Mapppings aufgerufen werden sollen. Im zweiten Schritt weisen Sie Prozesse oder Mappings diesem Scheduler-Objekt zu. Definieren Sie in dem Design Center unter dem Auswahlpunkt Schedules ein Schedule-Module mit dem Namen S_Minuten_Takt und in diesem Modul das Schedule-Objekt S_MIN1. Bei der Anlage des Moduls, werden Sie nach einer Location gefragt. Wählen Sie hier die Location Ihres Zielschemas.Unter dieser Location generieren Sie später auch das Schedule-Objekt. Anlegen von Schedule-Objekten Ein Wizard startet. In dem Schritt 2 geben Sie die Zeitdauer an, für die Sie Prozesse oder Mappings starten wollen. Sollen Prozesse oder Mapping ständig gestarten werden, so müssen die beiden grünen Häkchen entfernt werden. Wählen Sie hier die Uhrzeit, die in Ihrem Testbereich liegt. Wenn Sie die Prozesse ständig starten, können Sie später das Schedule-Objekt über das Control Center stoppen bzw. starten. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 220/300 Das Festlegen von Start- und Endzeitpunkten einer Laufserie In dem folgenden Schritt legen Sie die Häufigkeit der Aufrufe fest (monatlich, täglich, stündlich usw). Wählen Sie hier minütlich. Festlegen der Wiederholfrequenz Das war die Definition. Jetzt können Sie diese Definition auf Mappings oder Prozesse anwenden. Das soll hier mit Hilfe des Prozesses P_SQLPLUS_DYN aus dem vorigen Abschnitt geschehen. Sie können jeden anderen Prozess oder jedes Mapping ebenfalls benutzen. Selektieren Sie in dem Design Center den Prozess P_SQLPLUS_DYN mit der rechten Maustaste und öffnen Sie den Punkt Configuration. Unter dem Hauptpunkt P_SQLPLUS_DYN finden Sie in dem rechten Bereich des Fensters Referred Calendar. Klicken Sie in das Feld mit den drei Punkten (...), um die Liste der zur Verfügung stehenden Kalenderobjekten angezeigt zu bekommen. Wählen Sie den Kalender S_MIN1 Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 221/300 Zuordnung der Schedule-Definition zu einem Laufobjekt (hier Prozessdefinition) Generieren Sie jetzt das neue Schedule-Objekt über das Control Center und starten Sie es so wie Sie bislang Mappings und Prozesse gestartet haben. Sie sehen in dem rechten Bereich unter Control Center Jobs, drei Reiter. Wählen Sie den rechten mit dem Namen Schedule. Jetzt sehen Sie den Schedule-Job. Wenn Sie den Reiter Execution wählen sehen, dann die im Minutenabstand gestarteten Prozesse. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 222/300 Kontrolle über alle Aufrufe, hier Aufruf eines Prozesses pro Minute Stoppen von laufenden Workflow-Prozessen über SQL*Plus Manchmal kommt es vor, dass Prozesse der Workflow-Engine gestoppt werden müssen hierzu liegen in dem Unterverzeichnis „WF“ (OWB-Installations-Verzeichnis), Skripte, die in SQL*Plus abgesetzt werden können. Starten von SQL*Plus in Workflow-Schema ( Default OWF_MGR/OWF_MGR) Herausfinden von laufenden Prozessen: select item_type,item_key, end_date from wf_items where end_date is Null; Ergebnis: ITEM_TYP ITEM_KEY -------- --------------------------------------WFERROR WF1 AUD_RULE WB_IK_20071206_143741_30917 WFERROR WF21 Beenden der laufenden Prozesse: exec wf_engine.abortprocess('AUD_RULE','WB_IK_20071206_143741_30917'); PL/SQL procedure successfully completed. Beenden der laufenden Prozesse: exec wf_purge.items('AUD_RULE'); PL/SQL procedure successfully completed. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 223/300 7. Aufbauen von Skripten zum automatisierten Ändern der Modelle (OMB Plus – Scriptsprache) Die OMB Plus Scriptsprache (Oracle Meta Base) steht seit dem OWB Release 9.2 zur Verfügung. Sie wurde erstellt, um funktionale Eigenschaften des Warehouse Builder von der Bedienoberfläche zu entkoppeln. Tatsächlich werden viele Bedienschritte, die der Benutzer über die Oberfläche durchführt, zunächst an ein internes API weitergeleitet und erst von dort aus interpretiert und zur Ausführung gebracht. Dieses interne API kann auch über die Scriptsprache OMB angesprochen werden. Die Vorteile liegen auf der Hand: Schritte, die im Rahmen von ETL-Prozessen immer wieder neu entwickelt werden müssen oder einfache Verwaltungsarbeiten wie das Validieren, das Generieren oder der DeployVorgang können automatisiert über Batchaufrufe im Hintergrund gestartet werden. Dieser Einsatz ist sinnvoll für: Regelmäßiges, automatisiertes Erstellen von Sicherungen. Entladen/Beladen/Erstellen von Objekten, wenn diese Online zu viel Aufwand bedeutet. Grössere Löschaktivitäten zum Bereinigen der Modelle. Massenupdates von Attributinhalten z. B. Verwaltungsattribute bei Überführungsarbeiten (Test -> QA -> Produktion). Offline Execution von Verwaltungsarbeiten wie z. B. Validate-Checks, Generierungen, Deployments. Durchführen von Massenupdates bzw. typischen Wiederholeraufgaben z. B. Hinzufügen von Location-Informationen. Und viele andere Beispiele, bei denen automatisiertes Bearbeiten aufwendige manuelle Wiederholertätigkeiten erstzt. Die OMB Plus Scriptsprache besteht aus zwei Sprachkomponenten: 1. Warehouse Builder API Kommandos - Sie werden in den Scripten immer groß geschrieben. Ihre Syntax ist dem OMB Plus Handbuch zu entnehmen, das mittlerweile über 800 Seiten umfasst. 2. Der TCL Scriptsprache, die im UNIX-Umfeld häufig vorkommt. (Siehe hierzu http://tcl.tk/ Auf dieser Webseite ist die genaue Beschreibung zu finden) (Siehe auch die Datei Ein_TCL.pdf auf der CD. Dort ist eine deutschsprachige Einführung, die über das Internet von Holger Jakobs zur Verfügung gestellt wurde). Sie können die Kommandos der Scriptsprache interaktiv mit dem Werkzeug OMBPLUS absetzen. Hierzu rufen Sie OMBPlus über die Startleiste auf: Oder sie benutzen das OMBPlus Fenster des Design Centers: Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 224/300 OMB Plus-Kommando Eingabefenster des Design Centers Wenn dieses Fenster nicht sichbar ist, so sollten Sie es über die Pull Down Liste Window zugänglich machen. Beachten Sie, dass Sie sich in dem Fenster des Design Centers nur innerhalb der durch das Frontend bereits geöffneten Session bewegen können. Es gibt Aktionen (z. B. Metadatenmodelländerungen), die in dieser Weise nicht möglich sind, weil sie das OWB Repository exlusiv für sich beanspruchen. Diese Aktionen gehen dann nur aus dem OMB Plus-Fenster heraus, wobei alle anderen OWB Sessions geschlossen sein müssen. Es gibt noch andere Möglichkeiten OMB Skript Kommandos abzusetzen, wie das folgende Bild zeigt. Einsatzvarianten der OMB-Scriptsprache Scriptbeispiele Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 225/300 (noch nicht kommentiert, es kann sein, dass direkte Kopieren der Scripte aus dem Word-Text heraus zu Problemen mit den verwendeten Hochkommatas. Die Scriptbeispiel können als Textfile direkt vom Autor bezogen werden, oder sind bereits auf der Auslieferungs-CD mit diesem Dokument) --Einloggen Single User – Mode (nur nötig wenn Metadatenänderungen gemacht werden) -- Das Einloggen ist nur nötig, wenn man nicht im Design-Fenster arbeitet).: OMBCONNECT owb10/owb10@localhost:1521:ora10 USE SINGLE_USER_MODE -- Einwählen in einen bestimmten Projekt-Kontext: OMBCC 'MY_PROJECT' -- Navigation allgemein OMBCC ‘STEP_BY_STEP’OMBCC ’WAREHOUSE’ -- Anzeigen der Umgebung set OMBPROMPT on --Aufrufen von Scripten aus OMBPLUS heraus z. B.: source D:\\Szenario\\OMB\\Mod_TBL_Valid_check.tcl -- Einwählen in ein bestimmtes Repository OMBCONNECT owb92/owb92@localhost:1521:ora92 (ist in dem Design Center Fenster nicht nötig und auch nicht möglich) OMBCONNECT owb92/owb92@localhost:1521:ora92 USE SINGLE_USER_MODE -- Ändern des Kontextes OMBCC ‚STEP_BY_STEP’ -- Anlegen eines Modules OMBCREATE ORACLE_MODULE 'MO_BATCH' -- Commit OMBCOMMIT -- Löschen eines Modules OMBDROP ORACLE_MODULE 'MO_BATCH' OMBCREATE ORACLE_MODULE 'MO_BATCH' \ SET PROPERTIES (DESCRIPTION) VALUES ('Automatisiert angelegtes Modul') -- Einschalten des Prompts dann sieht man, auf welchen PCO man sich befindet set OMBPROMPT on --> /MY_PROJECT/WAREHOUSE> -- Anlegen einer User Defined Property OMBREDEFINE CLASS_DEFINITION 'TABLE' ADD PROPERTY_DEFINITION 'UDP_Autor' SET PROPERTIES (TYPE) VALUES('STRING') OMBREDEFINE CLASS_DEFINITION 'TABLE' ADD PROPERTY_DEFINITION 'UDP_Erstellt_Am' SET PROPERTIES (TYPE) VALUES('DATE') OMBREDEFINE CLASS_DEFINITION 'TABLE' ADD PROPERTY_DEFINITION 'UDP_Zuletzt_geaendert_Am' SET PROPERTIES (TYPE) VALUES('DATE') OMBREDEFINE CLASS_DEFINITION 'TABLE' ADD PROPERTY_DEFINITION 'UDP_Zuletzt_Aenderungs_Autor' SET PROPERTIES (TYPE) VALUES('STRING') OMBREDEFINE CLASS_DEFINITION 'TABLE' ADD PROPERTY_DEFINITION 'UDP_Status' SET PROPERTIES (TYPE,DEFAULT_VALUE) VALUES('STRING','Entwicklung') OMBREDEFINE CLASS_DEFINITION 'TABLE' ADD PROPERTY_DEFINITION 'UDP_Version' SET PROPERTIES (TYPE,DEFAULT_VALUE) VALUES('INTEGER','0') -- Löschen von UDPs OMBREDEFINE CLASS_DEFINITION 'TABLE' DELETE PROPERTY_DEFINITION 'UDP_Autor' OMBREDEFINE CLASS_DEFINITION 'TABLE' DELETE PROPERTY_DEFINITION 'UDP_Autor' Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 226/300 -- Ändern eines Columnwertes OMBALTER TABLE 'ARTIKEL_ZIEL' SET PROPERTIES (UDP_Version) VALUES('1') -- Herausschreiben einer MDL-Datei OMBEXPORT TO MDL_FILE 'C:\\WWWW.MDL' \ FROM PROJECT 'MY_PROJECT' \ COMPONENTS (ORACLE_MODULE 'WAREHOUSE') \ OUTPUT LOG TO 'C:\\WWWW.LOG' -- Ändern Business name OMBALTER ORACLE_MODULE 'MO_BATCH' \ SET PROPERTIES (BUSINESS_NAME) \ VALUES ('Metadata_Demo_Modul') ############################################################## #Auflistung aller Tabellen pro Modul # # Durchsucht werden alle Module nach deren Tabellen # Innerhalb der Module Ausgabe des Tabellennamens # # Beginnt auf Kontext: Repository # Endet auf Kontext : Repository # # OMBPLUS Aufruf: source D:\\Szenario\\OMB\\Mod_TBL.tcl ############################################################## OMBCC 'MY_PROJECT' puts " " puts "Liste von Tabellen pro Modul " puts "---------------------------- " OMBLIST ORACLE_MODULES foreach moduleName [OMBLIST ORACLE_MODULES] { puts " " puts "Modul: $moduleName" OMBCC '$moduleName' puts "Folgende Tabellen sind in dem Modul:" foreach tableName [OMBLIST TABLES] { puts " --> $tableName" } OMBCC '..' } OMBCC '..' ############################################################## #Auflistung aller Tabellen und ihrer Columns pro Modul # # Durchsucht werden alle Module nach deren Tabellen # Innerhalb der Module Ausgabe des Tabellennamens # Pro Tabelle Ausgabe aller Columns # Beispiel fuer OMBRETRIEVE # # Beginnt auf Kontext: Repository Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 227/300 # Endet auf Kontext : Repository # # # OMBPLUS Aufruf: source D:\\Szenario\\OMB\\Mod_TBL_COL.tcl ############################################################## OMBCC 'MY_PROJECT' puts " " puts "Liste von Tabellen mit ihren Spalten pro Modul " puts "---------------------------------------------- " OMBLIST ORACLE_MODULES foreach moduleName [OMBLIST ORACLE_MODULES] { puts " " puts "Modul: $moduleName" puts "==============================================" OMBCC '$moduleName' puts "Folgende Tabellen sind in dem Modul:" foreach tableName [OMBLIST TABLES] { puts " " puts " Tabelle: --> $tableName" puts " --------------------------------------------" set columnList [OMBRETRIEVE TABLE '$tableName' GET COLUMNS] foreach colName $columnList { puts " Spalte: $colName" } } OMBCC '..' } OMBCC '..' ############################################################## #Pruefung ob Tabellen in Modulen Valid # # Durchsucht werden alle Module nach deren Tabellen # Innerhalb der Module werden alle Tabellen compiliert # und das Ergebnis festgehalten # # Beginnt auf Kontext: Repository # Endet auf Kontext : Repository # # OMBPLUS Aufruf: source D:\\Szenario\\OMB\\Mod_TBL_Valid_check.tcl ############################################################## OMBCC 'MY_PROJECT' puts " " puts "Pruefung auf Gueltigkeit von Tabellen " puts "------------------------------------- " OMBLIST ORACLE_MODULES foreach moduleName [OMBLIST ORACLE_MODULES] { puts " " puts "Modul: $moduleName" OMBCC '$moduleName' puts "Folgende Tabellen sind in dem Modul:" set tableList [OMBLIST TABLES]; foreach tableName $tableList { puts " --> geprueft wird --> $tableName" if { [OMBCOMPILE TABLE '$tableName'] == "Invalid."} { set context [OMBCC]; Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 228/300 puts "Tabelle $context/$tableName ist invalide"; } else {puts " Tabelle $tableName ist OK!" } } OMBCC '..' } OMBCOMMIT OMBCC '..' ############################################################################# #Auflistung aller Tabellen pro Modul # # Durchsucht werden alle Module nach deren Tabellen # Innerhalb der Module Ausgabe des Tabellennamens # Änderung aller Verwaltungsattribute der Tabellen: # UDP_Version # UDP_Autor # UDP_Zuletzt_Aenderungs_Autor # UDP_Status # UDP_Zuletzt_geaendert_Am # UDP_Erstellt_Am # # # Beginnt auf Kontext: Repository # Endet auf Kontext : Repository # # OMBPLUS Aufruf: source D:\\Szenario\\OMB\\Mod_TBL_Change_UDP.tcl ############################################################################## puts " " puts "Änderung der Verwaltungsattribute aller Tabellen " puts "auf aktuelle Werte" puts "------------------------------------------------ " OMBCC 'MY_PROJECT' OMBLIST ORACLE_MODULES foreach moduleName [OMBLIST ORACLE_MODULES] { puts " " puts "Modul: $moduleName" OMBCC '$moduleName' puts "Folgende Tabellen sind in dem Modul:" foreach tableName [OMBLIST TABLES] { OMBALTER TABLE '$tableName' SET PROPERTIES (UDP_Version) VALUES('1') OMBALTER TABLE '$tableName' SET PROPERTIES (UDP_Autor) VALUES('Warehouse ADM Meier') OMBALTER TABLE '$tableName' SET PROPERTIES (UDP_Zuletzt_Aenderungs_Autor) VALUES('Fr. Friedrich') OMBALTER TABLE '$tableName' SET PROPERTIES (UDP_Status) VALUES('Testraum') OMBALTER TABLE '$tableName' SET PROPERTIES (UDP_Zuletzt_geaendert_Am) VALUES('2003-05-31') OMBALTER TABLE '$tableName' SET PROPERTIES (UDP_Erstellt_Am) VALUES('200301-04') puts " --> geaendert wurde $tableName" } OMBCC '..' } OMBCOMMIT OMBCC '..' ############################################################## Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 229/300 #Auflistung aller Tabellen pro Modul # # Durchsucht werden alle Module nach deren Tabellen # Innerhalb der Module Ausgabe des Tabellennamens # Änderung aller Verwaltungsattribute der Tabellen: # UDP_Version # UDP_Autor # UDP_Zuletzt_Aenderungs_Autor # UDP_Status # UDP_Zuletzt_geaendert_Am # UDP_Erstellt_Am # # # Beginnt auf Kontext: Repository # Endet auf Kontext : Repository # # OMBPLUS Aufruf: source D:\\Szenario\\OMB\\Mod_TBL_Change_Status.tcl ############################################################## puts " " puts "Änderung der Verwaltungsattribute aller Tabellen " puts "auf aktuelle Werte" puts "------------------------------------------------ " OMBCC 'MY_PROJECT' OMBLIST ORACLE_MODULES foreach moduleName [OMBLIST ORACLE_MODULES] { puts " " puts "Modul: $moduleName" OMBCC '$moduleName' puts "Folgende Tabellen sind in dem Modul:" foreach tableName [OMBLIST TABLES] { OMBALTER TABLE '$tableName' SET PROPERTIES (UDP_Version) VALUES('1') OMBALTER TABLE '$tableName' SET PROPERTIES (UDP_Autor) VALUES('Warehouse ADM Meier') OMBALTER TABLE '$tableName' SET PROPERTIES (UDP_Zuletzt_Aenderungs_Autor) VALUES('Fr. Friedrich') OMBALTER TABLE '$tableName' SET PROPERTIES (UDP_Status) VALUES('Testraum') OMBALTER TABLE '$tableName' SET PROPERTIES (UDP_Zuletzt_geaendert_Am) VALUES('2003-05-31') OMBALTER TABLE '$tableName' SET PROPERTIES (UDP_Erstellt_Am) VALUES('200301-04') puts " --> geaendert wurde $tableName" } OMBCC '..' } OMBCOMMIT OMBCC '..' Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 230/300 8. Metadatenmanagement im Data Warehouse Metadaten Alle Design Informationen des Warehouse-Systems sind als Metadaten in dem Warehouse Builder Design Repository gespeichert. Diese Metadaten entsprechen dem Bauplan des Warehouse. Jedes Objekt ist hier verzeichnet. Jede Abhängigkeit dokumentiert. Ändert sich ein Objekt im Entwicklungsprozess, so sind in den Metadaten die abhängigen Objekte zuerkennen, für die Auswirkungen zu erwarten sind. Hintergrund: Der Warehouse Builder erzeugt die Metadaten automatisch im Hintergrund. Jedes Hinzufügen eines Operators in einem Mapping führt zu einem Hinzufügen des Operators in dem Metadatenmodell. Das Metadatenschema ist selbst nach dem von der OMG (Object Management Group, WWW.OMG.ORG) festgelegten Metadatenstandard CWM (Common Warehouse Metamodel) entworfen worden. In seinem Inneren ist es mit XML-Mitteln beschrieben. Dadurch, dass es selbst als Mehrschichtenmodell definiert ist, ist es flexibel erweiterbar. Das spielt zwar für den Entwickler, der mit dem Warehouse Builder arbeitet keine Rolle, er merkt kaum etwas davon. Aber es gibt ein beruhigendes Gefühl wenn die in die Modelle investierte Arbeit über einen allgemein anerkannten Standard abgesichert ist. Mehrschichtig aufgebautes Metadatenrepository Das Metadaten Repository besitzt mehrere Möglichkeiten die beschreibenden Metadaten zu bearbeiten, ein- und auszulesen oder auszuwerten. Hier eine Übersicht: Möglichkeit / Aktion Hilfsmittel / Methode Primäre Verwendung Bearbeiten und Erfassen der Metadaten Herausladen oder Einladen ganzer Modelle über das GUI OWB GUI (Client Oberfläche) Entwicklung des WarehouseModells durch das Projektteam - Archivierung - Metadatenaustausch zwischen OWB-Repositories - Migration der Modelle über Stand/letzte Änderung 13.05.2016 Metadaten Import- / Export in eine MDL-Datei von beliebigen Modellteilen. (in Arbeit) 75875104 Oracle Warehouse step-by-step 231/300 Bearbeiten von Modellen im Batch bzw. auf einer Kommandozeilenebene. Kommandos in Scriptdateien Scriptsprache verwendet über OMBPlus Direktzugriff auf Metadaten über andere Programme. Jede Metadateninformation ist über ein Javaprogrammm abgreifbar Zugriff auf bereitgestellte Datenbankviews Java API Graphische Auswertungen Metadaten Browser im Web Auswertungen im XML-Format XML-Schnittstelle Datenbank SQL OWB-Releases hinweg - Automatisiertes Ändern der Modelle. - Integration des Warehouse Builders in andere Anwendungen (ERP-Systeme) - Sich selbst pflegende Systeme Schnittstellenprogramme zur Versorgung anderer Anwendungen Selbst entworfene textbasierte Reports - Einfache Metadatenauswertungen Metadaten Online Reporting sowohl für Entwickler als auch für Business-User XML-basiertes Reporting - der Metadata Dependancy Managers Die Auswertungen über den Metadatenbowser sind weiter vorne bereits gezeigt worden. Daher kann an dieser Stelle darauf verzichtet werden. Hier nur noch einmal Hinweise für die Bedienung des Metadata Dependancy Managers. Der Dependancy Manager kann entweder über das Design Center Menü (Option Tools) oder direkt aus der Liste der Objekte im Design Center (rechte Maustaste) aufgerufen werden. Öffnen Sie mit der rechten Maustaste das Kontextmenü für die Tabelle REGIONEN. Starten Sie hierüber die Impact-Analyse für diese Tabelle. Sie erhalten eine Darstellung mit der Tabelle REGIONEN im linken Bereich und mehreren dickeren blauen Rechtecken, die durch ein weißes Kreuz gekennzeichnet sind. Diese können Sie nach und nach aufklappen. Kommen Sie auf ein Objekt, das an einer Seite ebenfalls durch ein Plus-Zeichen gekennzeichnet ist, dann können Sie auch dieses weiter öffnen. Schließlich stellen wir fest, dass eine Text-Datei und die Faktentabelle F_UMSATZ Daten aus dieser Tabelle bezieht. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 232/300 Impact Analyse für die Tabelle REGIONEN Eine weitere Analyse kann die Frage sein: In welchen Modulen sind die Objekte zu finden. Diesen Punkt finden Sie unter dem Men[punkt EDIT. Moduldarstellung zur Impact-Analyse Diese beiden Module sind recht überschaubar. Dass die Darstellung auch etwas komplexer sein kann zeigt eine nach Modulen-gruppierte Impact-Analyse der Artikeltabelle aus derm Modul SRC. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 233/300 Nach Modulen gruppierte Impact-Analyse der Artikeltabelle In der Darstellung oben sehen wir zweimal das Objekt F_UMSATZ. Es ist einmal die Cubb-Definition und zum anderen ist es die Tabelle F_UMSATZ. Optisch können wir diese Objekte zusammenfassen. Wählen Sie hierzu die Group Selected Objects Option in der Kopfleiste des Fensters. Die Objekte F_Umsatz sind zur Gruppe Umsatztabelle zusammengefasst Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 234/300 Diagramme ausdrucken In fertigen Umgebungen kommen durchaus komplexere Auswertungen vor. Am Bildschirm wird es schwierig sein. die einzelnen Abhängigkeiten dann noch zu erkennen. Dann hilft das Ausdrucken. Darüber sind sehr brauchbar Ergebnisse zu erzielen. Über die Selektion Print Setup sollten Sie zunächst das Ausdrucken auf „mehrseitig“ stellen, indem Sie die Page Columns und die Page Rows auf Werte > 1 setzen Druckoptionen zum mehrseitigen Drucken Dann können Sie in der grafischen Darstellung die Objekte bei einer kleinen Zoomeinstellung möglichst weit auseinander ziehen. Auseinanderziehen von Objekten und Bereichen in komplexen Darstellungen Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 235/300 Beim Drucken wird dieses Bild auf die verschiedenen Seiten verteilt. Das kann dann eine Wandtapete werden. Die Verteilung der Darstellung auf die Ausdruckseiten Auswertungen mit Application Express Alle Metadatentypen des Repositories stehen für Auswertezwecke zur Verfügung. Öffnen Sie hierzu z. B. mit dem SQL Developer das Schema des Repositories. Hier finden Sie für alle Objekttypen eine View. Diese Views können nach Belieben ausgelesen werden. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 236/300 Ausschnitt Metadaten Views OWB Ein Beispiel zeigt die folgende Application Express-Anwendung, in der mehrere Zugriffe zusammengefasst sind: Eine Auflistung nach Objekttyp Listen aller Tabellen, Mappings und Funktionen Eine listenartige Strukturauflösung Application Express (HTMLDB)-Listenauswertung über Metadaten mit Beschreibungstexten Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 237/300 Application Express (HTMLDB)-Strukturauflösung in Listenform Einfache Liste von Tabellen mit den Modul-Fundstellen. Die Beschreibungsinformationen wurden nicht gepflegt. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 238/300 Liste von Mappings mit Beschreibungstexten Die Grundlage dieser Application Express-Auswertung ist eine Hilfstabelle. Die Metadaten sind innerhalb des Repositories in einer sehr verschachtelten Form abgelegt. Hinzu kommt die Fülle der Informationen. Mit dem „Trick“ der Hilftabelle können solche programmierten Zugriffe erleichtert werden. Die Hilfstabelle hat die gleiche Struktur wir der View ALL_IV_ALL_OBJECTS und wird mit den folgenden Daten gefüllt: insert into t_all_objects select OBJECT_ID, OBJECT_UOID, OBJECT_TYPE, OBJECT_NAME, BUSINESS_NAME, DESCRIPTION, PARENT_OBJECT_ID, PARENT_OBJECT_TYPE, PARENT_OBJECT_NAME, IS_VALID, UPDATED_ON, CREATED_ON, UPDATED_BY, CREATED_BY from OWBR2.all_IV_ALL_objects where object_type != 'Unknown' Eine Strukturauflösung wie in dem Beispiel oben kann erreicht werden über: Select substr('|---------',1,level*2)||substr(OBJECT_NAME,1,25) Name, substr(OBJECT_TYPE,1,20) typ, substr(PARENT_OBJECT_NAME,1,20) Parent , substr(PARENT_OBJECT_TYPE,1,20) Parent_Typ, --CONNECT_BY_ISLEAF, LEVEL, substr(SYS_CONNECT_BY_PATH(OBJECT_NAME, '->'),1,30) Pfad from t_all_objects START WITH OBJECT_ID = 26265 CONNECT BY PRIOR OBJECT_ID = PARENT_OBJECT_ID and OBJECT_TYPE not in ('Unknown') Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 239/300 Die hier vorgestellten Beispiele lassen erahnen, welche komfortablen Browserauswertungen man erzuegen kann. Das ist jedoch die Anwendung von Application Express (HTMLDB) und sollte an anderer Stelle besprochen werden. Leichtes Austauschen von Metadaten zwischen verschiedenen Repositories (MDL-Files) In verschiedenen Situationen will man Metadaten aus dem Repository auslagern und auch wieder in ein Repository zurückschreiben. Diese Situationen können sein: Erstellen von Sicherungskopien der Metadaten Austausch von Metadaten zwischen Repositories Erstellen eines Versionsstands Alle Objekte können komplett oder selektive ausgetauscht werden. Bei diesem Vorgang entsteht eine sog. MDL-Datei. Das ist ein verschlüsseltes Warehouse-Builder – eigenes Format. In dieser Textdatei sind alle Informationen enthalten, um die jeweiligen Objekte wieder neu aufzubauen. Ein komplettes Repository kann damit wieder hergestellt werden. Markieren Sie hierzu in dem Design Browser das Objekt, das Sie als Metadaten herausschreiben wollen. Wenn Sie das Projekt selektieren, wird das komplette Projekt geschrieben. Wählen Sie aus dem Menüpunkt Design die Option Export und hier Warehouse Builder Metadata Starten des Metadaten-Export-Vorgangs Jetzt startet ein Wizard, in dem Sie den Pfad für sie Zieldatei angeben können. Wählen Sie eine Datei aus und starten Sie der Exportvorgang. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 240/300 Metadaten-Export-Wizard Nach dem Abschluss Exportvorgangs sehen Sie das Protokoll. Sie können diese Informationen in dem geschriebenen Log-File nachlesen. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 241/300 Protokollierung des Metadaten-Exports Zur Umkehrung des Vorgangs lesen Sie die Datei einfach wieder ein. Wählen Sie aus dem Menüpunkt Design die Option Import und hier Metadata. Selectieren Sie die zuvor weggeschriebene Datei. Warehouse Builder Sie haben die Option alle Daten zu lesen oder nur einzelne Objekte auszutauschen. Schalten Sie hierzu unter der Option Object Selection. ->Import selected objects from file. Danach sehen sie eine Browser, der dem des Design Centers gleicht und Sie können auch einzelne Objekte zum Zurückladen selektieren. Tip: Erzeugen Sie sich regelmäßig solche MDL-Dateien. Sie können damit Ihre Arbeit absichern. Wenn Sie ein mapping aus Versehen gelöscht oder es so stark modifiziert haben, so dass Sie nicht mehr zum Ursprung zurückkommen, dann können Sie Ihre Ursprungsversion aus der MDLDatei wieder „zurück-retten“. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 242/300 Dialog Wizard zum Zurückladen einzelner Objekte aus einer MDL-Datei Versionierung von Modellen und Modellteilen Modelle bzw. Modellausschnitte können versioniert werden. Dies ist eine Art Snapshot-Verfahren, das dem Speichern der vorher besprochenen MDL-Files gleicht. Die versionierten Informationen bleiben jedoch innerhalb des Repositories. Versionieren wir das Mapping MP_Artikel. Gehen Sie in das Kontextmenü des Mappings MP_ARTIKEL. Wählen Sie dort den Punkt Snapshot und hier die Option New Erstellen einer Version für das Mapping MP_ARTIKEL Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 243/300 Jetzt vergeben Sie den Namen für diese Version, z. B. V1_MP_ARTIKEL. Wählen Sie bei Type FULL. Full speichert alle Informationen zu dem Object. Diese Informationen können auch exportiert werden und man kann daraus wieder ein neues Objekt erstellen. Nachteilig ist allerdings der höhere Platzverbrauch. Die Signature-Variante verbraucht wesentlich weniger Platz. Sie kann alerdings verwendet werden, um Unterschiede zwischen Versionsständen herauszufinden um daraus z. B. die Notwendigkeit für ein Deployment abzuleiten. Hier sollte man sich überlegen, für welche Einsatzfälle man die Versionierung einsetzen will. Bei der Frage nach Dependancy Depth lassen Sie die 0 stehen. Hier würden referenzierte Objekte herangezogen werden. Schließen Sie den Vorgang danach ab. Um die Arbeit mit dieser Version zu testen, können Sie jetzt eine Änderung in dem Mapping vornehmen. Öffnen Sie das Mapping und löschen Sie die Tabelle Artikelsparte weg. Löschen Sie auch die Gruppe Sparte in dem Joiner. Schließen Sie das Mapping und wählen Sie in dem Design Center in dem Kontextmenü des Mappings die Option Snapshot und Compare. Liste der zur Verfügung stehenden Versionen Wählen Sie in der angebotenen Liste die Version V1_MP_ARTIKEL und Sie erhalten Übersicht aller gegenüber dieser Version geänderten Informationen. Stand/letzte Änderung 13.05.2016 (in Arbeit) eine 75875104 Oracle Warehouse step-by-step 244/300 Änderungsliste von aktuellem Mapping gegenüber der gespeicherten Version Change Manager – Zurückholen einer alten Version Jetzt wissen wir zwar, welche Unterschiede sich eingestellt haben. Die alter Version haben wir jedoch noch nicht zurück bekommen. Hierzu wird der Change Manager benötigt. Starten Sie den Change Manger über den Menüpunkt Tools im Design Center. Jetzt sehen Sie in dem linken Bereich die Auflistung der zur Verfügung stehenden Versionen und in dem Kopfbereich haben Sie die Optionen für Zurückholen, Löschen und Vergleichen. Die Compare-Option vergleicht jetzt zwei Versionen. Wenn Sie Compare wählen, erscheinen zwei Listen mit dem gleichen Inhalt. Sie können also mit unterschiedlichen Versionen von dem gleichen Objekt vergleichen. Marken Sie Version und wählen Sie die Option Restore. Kontrollieren Sie das Ergebnis, in dem Sie den Mapping-Editor wieder öffnen. Das Mapping sollte wieder hergestellt sein. Restore, Compare und Delete von Versionen Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 245/300 9. Die Verbesserung der Datenqualität (Dieses Kapitel wird nachgeliefert) Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 246/300 10. Experts (Dieses Kapitel wird nachgeliefert) Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 247/300 11. Implementierung des Starschemas in der Datenbank Oracle 10g °°°° Noch nicht überarbeitet °°°°° Es ist naheliegend, dass ein Modell wie das des Starschemas besondere Herausforderungen aufgrund der zu speichernden Datenmengen mit sich bringt. Während die Dimensionstabellen meist überschaubar klein sind (Produkte etwa 1000 bis 100000, Kunde je nach Einsatz 1000 bis 1 Mio., Regionen/Orte 10 – 20.000, 10 Jahre Zeitdimension 4000) laufen in den Faktentabellen mehrere Millionen bis Milliarden Sätze auf. Hier sind letztendlich Bewegungsdaten gespeichert. Um die Aussagefähigkeit der Daten möglichst hoch zu halten, wird meist auch eine sehr feine Granularität in den Fakten gewählt, z. B. eine konkrete Verkaufsaktivität – eine operative Transaktion. Bei einer Telefongesellschaft mit einem Telefongespräch pro Transaktion sind dann natürlich andere Datenmengen zu erwarten als bei einer Großhandelsgesellschaft wo große Stückzahlen pro Transaktion zu messen sind, oder bei einer Bank, die lediglich Darlehensverträge analysiert. Mit Hilfe einer Join-Operation fragen Sie die hohen Datenmengen in der Faktentabelle und die damit verbundenen Daten in den Dimensionen ab. Mehrere Techniken innerhalb der Oracle 9i Datenbank erlauben auch bei großen Datenmengen in der Faktentabellen performante Abfragen des Warehousebenutzers. Hier eine Vorabübersicht: Materialized Views (Summentabellen) spielen eine wichtige Rolle, weil durch sie eine besonders hohe Performancesteigerung erreichbar ist. Die Abfrageergebnisse eines Views werden physisch gespeichert. Das gespeicherte Ergebnis kann bei nachfolgenden Abfragen anderer Benutzer wiederverwendet werden. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 248/300 Dimensional Tables und Query Rewrite sorgen dafür, dass auch textuell nicht identische Benutzerabfragen bestehende Materialized Views ausnutzen können. Bei einem geschickt aufgebauten Warehouse-System können so fast alle Benutzerabfragen über Materialized Views beschleunigt werden, auch wenn die konkrete Fragestellung bei dem Aufbau des Systems noch unbekannt war. Partitionierung teilt große Datenmengen in kleinere Teilmengen. Lade- und Abfrageaufwand wird minimiert. Bitmap-Indizierung erlaubt gerade bei Warehouse-Abfragen den schnellen Zugriff über Wertekategorien in den Dimensionstabellen. Star Transformation schreibt Benutzerabfragen datenbankintern so um, dass der günstigste Abfrageweg gewählt wird Analytical Functions Statistische und analytische Berechnungen, die ansonsten in den Abfrage-Clientwerkzeugen machbar vorkommen, sind mit analytischen Funktionen direkt innerhalb der Datenbank mit einer erheblich verbesserten Performance machbar. Kombiniert mit Materialized Views entstehen damit gewaltige Performanceverbesserungen. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 249/300 Summentabellen / Materialized Views Eine der wichtigsten Techniken zur Erreichung von Abfrageperformance in einem Starschema sind Materialized Views (Summentabellen). Hier werden die Ergebnisse für mögliche Benutzerabfragen im Vorwege bereits erstellt und physisch innerhalb der Datenbank gespeichert. Wenn die Berechnung der Umsätze pro Monat und Artikelgruppe als z. B. 100-zeilige Ergebnismenge bereits in der Datenbank vorliegt, ist eine Benutzerabfrage in Sekundenschnelle beantwortet. Im anderen Fall müßten erst Millionen von Faktensätzen gelesen werden (u. U. Full Table Scan), um das Ergebnis zu liefern. Zur praktischen Einsetzbarkeit des Konzeptes müssen jedoch noch einige technische Voraussetzungen erledigt sein. Eine erste Herausforderung: Ist ein View auf eine Basistabelle erstellt und das Ergebnis physisch gespeichert, sind die Inhalte des Views bei den nächsten Updates auf die Basistabelle nicht mehr aktuell und Abfragen liefern falsche Ergebnisse. Um dies zu verhindern hat Oracle einen sog. Fast Refresh-Modus eingeführt. Hier werden alle Änderungen in der Basistabelle in DML-Form in sog. View Logs gespeichert. D. h. die auf die Basistabellen wirkenden, ändernden Kommandos sind abgelegt. Jetzt können die Materialized Views modifiziert (Refreshed) werden und zwar „ON DEMAND“, „FAST“, „ON COMMIT“, „FORCE“ und „COMPLETE“ (siehe Manual zur näheren Erklärung der einzelnen Optionen). Die Materialized Views aktualisieren sich also selbst und dies ohne die Performance der Verarbeitung der Basistabellen deutlich zu beeinflussen. Ein Neuaufbau der Views findet nicht statt. Einmal erstellt, sind lediglich Änderungen nachzufahren. Beispieldefinition für eine View Log: create materialized view log on f_umsatz_2 with sequence, ROWID (ARTIKEL_ID, BESTELLMENGE, KUNDEN_ID, ORT_ID, UMSATZWERT, ZEIT_ID, ZEIT_PARTITION ) including new values; Eine zweite Herausforderung besteht in der der Nichtvorhersagbarkeit von nötigen Materialized Views. Denn der Warehousenutzer wird interaktiv virtuell innerhalb des Starschemas Rollup- und RolldownWege gehen und dabei auch eine Vielzahl von unterschiedlichen SQL-Funktionen verwenden. Es kann nicht für alle Abfragemöglichkeiten ein View vordefiniert werden. Hier hilft die Rewrite-Technik der Oracle-Datenbank. Hierbei sucht das Datenbanksystem selbständig ob Materialized-View-Abfragen mit identischem oder teil-identischem Ergebnis bereits in der Datenbank vorliegen, wenn ja, schreibt der Optimizer der Datenbank das Benutzerkommando um und leitet es so auf den passenden View. Der Vorgang ist für den Benutzer vollständig transparent, er spürt lediglich die verbesserte Performance. Wie arbeitet der Optimizer: Zunächst prüft der Optimizer auf volle textliche Identität des Kommandos ( Achtung Groß/Kleinschreibung). Wenn dies nicht zum Erfolg führt, werden Textteile analysiert und zwar Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 250/300 beginnend mit den Einträgen in der FROM-Klausel. Schließlich werden Join-Bedingungen, GroupingSets und Aggregationen herangezogen. Dimensional Table Eine Hilfestellung kann dem Optimizer durch die Definition einer Dimensional Table gegeben werden, wie wir sie als Ergebnis einer Starschema-Generierung aus dem Warehouse Builder bekommen. Haben wir die Dimensionen eines Starschemas definiert, generiert OWB für jede Dimension zwei Datenbankobjekte: eine echte Tabelle, die die Dimensionssätze auch wirklich physisch aufnimmt und eine Dimensional Table, die im Prinzip nur logisch vorhanden ist. Die Dimensional Table beinhaltet die wichtige Information über Hierarchien in der Dimensionstabelle, die der Optimizer auswerten kann. Bei der Definition der Dimensionen haben wir mögliche Aggregatstufen (Level) festgelegt. Hier haben wir uns an den möglichen Drill-Down-Hierarchiestufen orientiert, die auch ein Warehouse-Benutzer wahrscheinlich wählen würde, wenn er Analysen startet. (Umsatz nach Artikelsparte, ... Artikelgruppe,... Artikel). Generierte Dimension Die dazu passende Tabelle CREATE DIMENSION "DIM_ARTIKEL_DIM" LEVEL "ARTIKEL" IS "DIM_ARTIKEL"."ARTIKEL" LEVEL "ARTIKEL_KEY" IS "DIM_ARTIKEL"."ARTIKEL_ID" LEVEL "ARTIKELGRUPPE" IS "DIM_ARTIKEL"."ARTIKELGRUPPE" LEVEL "ARTIKELSPARTE" IS "DIM_ARTIKEL"."ARTIKELSPARTE" HIERARCHY "ARTIKEL_HIER"( "ARTIKEL_KEY" CHILD OF "ARTIKEL" CHILD OF "ARTIKELGRUPPE" CHILD OF "ARTIKELSPARTE" ) ATTRIBUTE "ARTIKELGRUPPE" DETERMINES ("ARTIKELGRUPPEN_" ) ATTRIBUTE "ARTIKELSPARTE" DETERMINES ("ARTIKELSPARTEN_" ) ; CREATE TABLE "DIM_ARTIKEL" ( "ARTIKEL" VARCHAR2(30), "ARTIKELGRUPPE" VARCHAR2(20), "ARTIKELGRUPPEN_" NUMBER(9), "ARTIKELSPARTE" VARCHAR2(20), "ARTIKELSPARTEN_" NUMBER(9), "ARTIKEL_ID" NUMBER(9)) TABLESPACE "USERS" PARALLEL LOGGING ; Beispiel: Es wird ein Materialized View für den Join zwischen der Umsatztabelle F_Umsatz und der oben definierten Artikeldimension (DIM_ARTIKEL) definiert und zwar mit einer Aggregation (Sum() Group By) auf der Artikelebene. Der View liefert Ergebnisse für „Alle Umsätze pro Artikel“. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 251/300 Die Definition des Views innerhalb OWB Das generierte Script: Create Materialized View "MW_ARTIKEL_UMSATZ2" TABLESPACE "USERS" PARALLEL LOGGING BUILD IMMEDIATE REFRESH ON DEMAND ENABLE QUERY REWRITE AS select Dim_artikel.Artikel, sum(f_umsatz_2.UMSATZWERT), count( f_umsatz_2.umsatzwert) from Dim_artikel, f_umsatz_2 where f_umsatz_2.ARTIKEL_ID = Dim_artikel.Artikel_ID group by Dim_artikel.Artikel; Der View kann innerhalb des OWB definiert werden. Das Select-Statement ist allerdings von Hand zu schreiben. (Hier kann man sich mit einem Hilfsmapping helfen, indem man sich die nötigen Tabellen und den Join „zusammenklickt“ und das Ergebnis über Immediate Result und Cut/Paste in das QueryFenster des View-Wizards kopiert. Das spart Schreibarbeit und Schreibfehler). Die Schlüsselwörter wie “Query Rewrite“,“Build Immediate Refresh“ usw. stellt man über die Option „Configuration“ zu den jeweiligen Materialized Views ein. Ist der View generiert, so läuft zunächst jede mit dem View identische Abfrage wesentlich schneller. Eine Testabfrage auf 1 Million Testsätze einer Faktentabelle kann so z. B. von 14 Sekunden auf unter 0,01 Sekunden reduziert werden. Dies ist leicht erklärbar. Aber auch eine Abfrage auf Gruppenebene in dem Beispiel läuft wesentlich schneller, obwohl hierfür kein Materialized View existiert. Über die Dimensional Table DIM_ARTIKEL weiß der Optimizer, dass eine Aggregation aller Umsätze auf Artikellevel eine Vorstufe einer Aggregation auf Artikelgruppenebene ist. Artikelgruppe ist Parent von Artikel in der Dimensionshierarchie. Der Optimizer veranlast jetzt ein zusätzliches Zusammenfassen aller im oben genannten Materialized View bestehenden Artikelaggregate auf Gruppenebene. Tip: Achten Sie unbedingt darauf, dass die Felder, über die in dem Materialized View aggregiert wird, auch tatsächlich als Levelfelder in der Dimension definiert sind. Sonst wird der Query Rewrite nicht stattfinden. In dem oben ausgeführten Beispiel (Dim_Artikel) sind auf der untersten Ebene zwei eigentlich gleichwertige Level definiert (Artikel und Artikel_Key). Einmal ist es der sprechende Artikelname (Artikel) und zum anderen der Primary Key der Dimension (Artikel_Key) der in der Foreign Key-Beziehung zur Faktentabelle genutzt wird. Hier sind zwei Anforderungen erfüllt: Einmal ist die Foreign Key-Beziehung zur Faktentabelle über eine kompakte und auf Dauer stabile laufende Nummer realisiert (Forderung aus der Datenmodellierung) zum anderen ist garantiert, dass auf der untersten Hierarchieebene der Dimension ein sprechender Wert z. B. für die GROUP-BY Klausel genutzt werden kann. Denn es ist kaum zu erwarten, dass spätere Auswertungen über die laufende ID-Nummer der Dimension abfragen: Select A.Artikel_Key, sum(F.Umsatz) from Dim_Artikel A,Umsatz F) where.... Group by A.Artikel_key Die Abfrage wird eher über den Artikel selbst laufen: Select A.Artikel, sum(F.Umsatz) from Dim_Artikel A,Umsatz F) where.... Group by A.Artikel Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 252/300 Voraussetzungen für Query Rewrite Das Query Rewrite bedarf bestimmter Voraussetzungen, die gegeben sein müssen, wenn ein Rewrite auch wirklich stattfinden soll. Materialized-View-Definition Init.ora (oder pfile unter Oracle 9i) Optimizer Mode Analyse auf Basistabellen Integritätslevel Ein View muss definiert sein mit den Schlüsselwörtern: “Enable Query Rewrite“ Parameter Query_Rewrite_Enable=True Der Otimizer Mode muss entweder auf ALL_ROWS oder First_Rows stehen bzw. im Modus Choose sein (Default). Im letzten Fall müssen zu den betroffenen Basistabellen des Views statistische Informationen durch den Analyse-Befehl durch das Datenbanksystem gesammelt worden sein. Im Fall von Optimizer Mode=Choose Es kann eingestellt werden, wie oft ein Materialized View aktualisert wird. Es gibt die Optionen - Stale_Tolerated - Trusted - Enforced (Default) Im letzten Fall ist der View immer aktuell. In den ersten beiden kann es zu einer fehlenden Synchronisierung kommen. Nun kann zusätzlich festgelegt werden, dass ein Query Rewirte nur dann stattfinden soll, wenn ein Materialized View auch wirklich aktuell ist: Set Query_Rewrite_Integrity=ENFORCED (Default) Ist ein View nicht synchronisiert, wird ein Rewrite z. B. bei ENFORCED nicht durchgeführt. Über Hints kann das Ausführen von Rewrites zusätzlich gesteuert werden: Hints Select /*+Rewrite (hintname) */ feld1,feld2 from.... Select /*+NoRewrite (hintname) */ feld1,feld2 from.... Grants (Benutzerrechte) Zum Rewrite sind auch besondere Rechte eines Benutzers nötig. Grant Rewrite auf das eigene Schema und Grant Rewrite auf ein anderes Schema, wenn Basistabellen in einem anderen Schema liegen. Hilfsmittel: Prüfung ob Parameter gesetzt sind: Show Parameters Query... SQL> show parameters Query NAME -----------------------------------query_rewrite_enabled query_rewrite_integrity SQL> TYPE ----------boolean string VALUE -----------TRUE trusted Zum Testen, ob auch wirklich ein Materialized View durch Rewrite erkannt und genutzt wird kann ein Trace eingeschaltet werden: Set autotrace on [explain] Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 253/300 Die Beispielabfrage in SQL*PLUS auf Artikelgruppen: select Dim_artikel.Artikelgruppe,sum(f_umsatz_2.UMSATZWERT), count( f_umsatz_2.umsatzwert) from Dim_artikel, f_umsatz_2 where f_umsatz_2.ARTIKEL_ID = Dim_artikel.Artikel_ID group by Dim_artikel.Artikelgruppe; Die Ausgabe mit dem Trace-Output: SQL> 2 3 4 5 select Dim_artikel.Artikelgruppe,sum(f_umsatz_2.UMSATZWERT), count( f_umsatz_2.umsatzwert) from Dim_artikel, f_umsatz_2 where f_umsatz_2.ARTIKEL_ID = Dim_artikel.Artikel_ID group by Dim_artikel.Artikelgruppe; ARTIKELGRUPPE SUM(F_UMSATZ_2.UMSATZWERT) COUNT(F_UMSATZ_2.UMSATZWE ------------------------------ -------------------------- ------------------------Computerteile 269623219 43 Haushaltswaren 10468546 82 Gartenbedarf 9479235 76 Heimwerker 10633209 80 KFZ-Zubehoer 10273962 78 Abgelaufen: 00:00:01.00 Ausführungsplan ---------------------------------------------------------0 SELECT STATEMENT Optimizer=CHOOSE (Cost=27 Card=5 Bytes=540) 1 0 SORT* (GROUP BY) (Cost=27 Card=5 Bytes=540) 2 1 SORT* (GROUP BY) (Cost=27 Card=5 Bytes=540) 3 2 HASH JOIN* (Cost=12 Card=1263 Bytes=136404) 4 3 VIEW* (Cost=8 Card=74 Bytes=4440) 5 4 SORT* (UNIQUE) (Cost=8 Card=74 Bytes=4440) 6 5 TABLE ACCESS* (FULL) OF 'DIM_ARTIKEL' (Cost=4 Ca rd=74 Bytes=4440) 7 3 :Q223004 :Q223003 :Q223003 :Q223001 :Q223001 :Q223000 TABLE ACCESS* (FULL) OF 'MW_ARTIKEL_UMSATZ2' (Cost=3 :Q223002 Card=1263 Bytes=60624) 1 PARALLEL_TO_SERIAL SELECT /*+ CIV_GB */ A1.C0,SUM(SYS_OP_CSR(A1 .C1,0)),SUM(SYS_OP_CSR(A1.C1,1)) FRO 2 PARALLEL_TO_PARALLEL SELECT /*+ PIV_GB */ A1.C2 C0,SYS_OP_MSR(SUM (A1.C4),SUM(A1.C3)) C1 FROM (SELECT ............... In dem Output kann deutlich gesehen ‚MV_ARTIKEL_UMSATZ2’ gesprungen wird. werden wie auf den Materialized View Ist unbekannt ob ein Query Rewrite für eine Materialized View stattfindet, gibt es ein Hilfspackage das den View analysiert: Führen Sie zunächst das Script Verzeichnis %Oracle_Home%/rdbms/admin/ UTLXMV.SQL und UTLXPLAN.SQL aus. Sie liegen in dem (z. B. D:\ora9\rdbms\admin\utlxmv.sql) ( Achtung als SYS ausführen). Dieses Script erzeugt eine Hilfstabelle MV_CAPABILITIES_TABLE die die benötigten Informationen zu dem zu testenden View aufnimmt Starten Sie jetzt den Aufruf exec dbms_mview.explain_mview(`Viewname`); Folgendes Script wird die Ergebnistabelle auswerten column mvname format a20; column CAPABILITY_NAME format a20; column POSSIBLE format a5; column RELATED_TEXT format a10; column RELATED_NUM format 999999; column MSGNO format 999999; column MSGTXT format a20; Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 254/300 column SEQ format 999999; select mvname, CAPABILITY_NAME, possible, related_text, RELATED_NUM, MSGNO, MSGTXT, SEQ from MV_CAPABILITIES_TABLE; Der Summary Advisor DBMS_SUMMARY gibt zusätzliche Hinweise darüber, welche Materialized Views zusätzlich angelegt werden können. Hierzu nutzt er Statistiken, die im Verlauf der Nutzung des Starschemas das System erstellt. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 255/300 Parallelverarbeitung °°°° Noch nicht überarbeitet °°°°° Parallelität ist eine der Hauptverarbeitungsmuster in der Warehousedatenhaltung. Beladen des Warehouse mit neuen Daten, Umwandeln von Datenbeständen oder die Auswerteoperationen des Endbenutzers über die Auswertungswerkzeuge, sind letztendlich Aktionen, bei denen Summen oder Mengen von vielen Einzelfakten bewegt werden. Ist in operativen Systemen der Ist-Zeitpunkt oder eine einzelne Transaktion relevant, so ist es im Warehouse die Summe all dieser Istsituationen über einen Zeitstrahl verteilt (historische Betrachtung). In der Oracle 9i kann die Verarbeitung von Daten parallel durchgeführt werden. Auch wenn das Maß der Parallalisierung administriert werden kann, so steuert die Datenbank weitesgehend selbständig das Erstellen und Verwalten der einzelnen parallelen Prozesse. Parallelisierung lohnt sich, wenn folgende Voraussetzungen erfüllt sind: - Rechnerarchitekur entweder Symmetric multi-processors (SMP), Clustersystem oder Massiv parallel Process-Maschinen (MPP). - Genügend I/O Bandbreite (d.h. parallele Platten) - Nur z. T. ausgenutzte CPU-Leistung (< 30%) - Genügend Hauptspeicher, um parallelen Prozessen Speicher zu geben. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 256/300 Partitionierung °°°° Noch nicht überarbeitet °°°°° Die Parallelisierung kann zusätzlich durch Partitionierung von Tabellen, Indizes oder Views unterstützt bzw. gesteuert werden. Man unterscheidet zwischen 4 Partitionierungsvarianten: 1. Range: Hier werden die Records einer Tabelle nach den Wertberreichen einer festgelegten Column in Partitionen aufgeteilt. Sinnvolles Beispiel ist hier das Aufteilen der Faktentabelle im Starschema nach Zeiteinheiten, etwa Wochen, Monate, Quartale. Siehe Beispiel unten. 2. Hash: Hier legt das Datenbank-System über einen Hash-Algorithmus die Verteilung der Tabellensätze auf Regionen fest. Beispiel: Eine Faktentabelle, mit detaillierten Einzelverkaufsdaten an Kunden (Transaktionslevel) soll nach Postleitzahlgebieten partitioniert werden. Nun gibt es aber Postleitzahlgebiete mit einer sehr geringen Bevölkerungsdichte und andere, etwa in Städten, mit einer hohen Bevölkerungsdichte. Rangepartitionierung würde hier zu einer ungleichgewichtigen Verteilung von Kundentransaktionen in den einzelnen Postleitzahlgebieten führen. Bei der Hashpartitionierung verteilt das System alle Verkaufstransaktionen gleichmäßig auf die Partitionen. 3. Composit: Dies ist eine Verbindung von Range- und Hashpartitionierung. Um bei den vorgenannten Beispielen zu bleiben, könnten etwa ‚gehashte’ Postleitzahlgebiete zusätzlich über eine Zeiteinheit Range-Partitioniert werden. 4. List: Das Partitionierungskriterium ist hier eine definierte Werteliste. Z. B. entlang der Produktgruppen in eines Vertriebssortiments. Beispiel Rangepartitionierung im Starschema: Gerade in historischen Datenbeständen bietet sich die Rangepartitionierung nach einem Zeitkriterium an. Eine erste Herausforderung stellt jetzt die Auswahl des passenden Feld an, nach dem partitioniert werden soll. Aus der klassischen Datenmodellierungslehre kennen wir die Regel Primary-Keys möglichst knapp und auf Dauer konsistent zu entwerfen. Die einfachste Methode dies zu erreichen ist die Einführung eines künstlichen Schlüssels, im Regelfall eine fortlaufende Nummer. Diese Nummer ist allerdings wenig geeignet , um danach eine Rangpartitionierung durchzuführen. Welche Wertebereiche sollten genommen werden? Daher empfiehlt es sich ein Datumsfeld mit in die Faktentabelle aufzunehmen oder wenn aus Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 257/300 irgendwelchen Gründen ein Datum in der Faktentabelle hinderlich ist, zumindest ein nummerisches Feld, in dem ein Zeitkriterium wieder zu finden ist. In dem nebenstehenden Beispiel wurde eine 1stellige Quartalsnummer und eine 4-stellige Jahreszahl gewählt. Die Definition einer Partitioned Table kann über die Configuration-Option des Table-Kontextmenues im Moduleditor erfolgen. Wird ein echtes Datumsfeld als Partitionierungskriterum benutzt, so generiert OWB die Definition mit samt der nötigen „TO_DATE“ Funktion: Das generierte Ergebnis nach dem oben gennanten Beispiel: CREATE TABLE "F_UMSATZ_3" ( "ARTIKEL_ID" NUMBER(10), "BESTELLMENGE" NUMBER(9), "KUNDEN_ID" NUMBER(10), "ORT_ID" NUMBER(10), "UMSATZWERT" NUMBER(9), "ZEIT_ID" NUMBER(7), "ZEIT_PARTITION" NUMBER(5)) PARALLEL LOGGING PARTITION BY RANGE ("ZEIT_PARTITION") (PARTITION "Q19971" VALUES LESS THAN TABLESPACE "USERS" ,PARTITION "Q19972" VALUES LESS THAN TABLESPACE "USERS" ,PARTITION "Q19973" VALUES LESS THAN TABLESPACE "USERS" ,PARTITION "Q19974" VALUES LESS THAN TABLESPACE "USERS" ,PARTITION "Q19981" VALUES LESS THAN TABLESPACE "USERS" ................................ ,PARTITION "Q20003" VALUES LESS THAN TABLESPACE "USERS" ,PARTITION "Q20004" VALUES LESS THAN TABLESPACE "USERS" ) (19972) (19973) (19974) (19975) (19982) (20004) (20005) ; Definition einer Rangepartion mit OWB Partition Pruning Einer der wichtigsten Vorteile der Partitionierung ist das Partion-Pruning. Kommt in der Where-Klausel einer Abfrage eine Einschränkung auf ein Partition-Kriterum vor, so sorgt der Cost-Based-Optimizer des Oracle-Systems dafür, dass nur die betroffene Partition durchsucht wird. In dem folgenden Beispiel wird auf die oben definierte Fakttabelle zugriffen bevor sie partitioniert wurde und ein zweites Mal, nachdem sie nach dem Schlüssel Quartal/Jahr in 15 Partitionen unterteilt wurde. Beispielabfrage: select substr(A.artikel,1,15) Artikel, sum(U.umsatzwert) from dim_artikel A, f_umsatz_3 U where A.Artikel_ID = U.Artikel_ID and Zeit_Partition = 19994 group by A.Artikel Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step Join über 350.000 Faktsätze ohne Partition 258/300 Join über 350.000 Faktsätze mit Partition Partition-wise Join Das Partitionierungsverfahren kann auch sehr effektiv über einen Join zwischen zwei Tabellen hinweg genutzt werden, wie wir ihn in Starschemen kennen. Hier sind in beiden Tabellen (Parent/Child, oder Dimension/Fakt) gleiche Partitionsmengen zu erstellen, wobei die jeweiligen Partionscolumns sich entsprechend müssen. Beispiel: Ein Starschema besteht aus einer Kundendimension mit dem Primary-Key PK_Kunden_DIM und einer Faktentabelle, in der sich der entsprechende Foreign Key FK_Kunden_DIM wieder findet. Für beide Tabellen werden die gleiche Anzahl Hash-Partitionen über die jeweiligen Schlüssel definiert. Das Datenbanksystem wird bei Abfragen auf beide Tabellen den hierzu nötigen Join in partitionsbezogene, kleinere Joins zerteilen – für jede Partition einen (Hash/Hash-Variante). Vorteile entstehen jetzt einmal durch die leichtere und schnellere Zuteilung der Systemprozesse zu den Partitionen und zum anderen brauch bei einer Einschränkung über die where-Klausel die nicht die gesamte Datenmenge analysiert zu werden. Join-Wise-Partition Hash/Hash-Variante Join-Wise-Partition (Hash/Hash-Variante) Das Beispiel kann noch weiter ausformuliert werden, indem über die Hash-Partitionen in der Faktentabelle zeitbezogene Range-Partition gelegt werden. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 259/300 Join-Wise-Sub Partition Partial Partition-wise Join Eine übliche Variante des Partition-wise Join ist der Partial Partition-wise Join. Hier wird lediglich eine der beiden Tabellen partitionniert (in der Regel die größere Faktentabelle). Das Datenbank-System wird bei späteren Abfragen selbständig die nicht partitionierte Tabelle partitionieren und die entstandenen Datensets den Partitionen der ‚gejointen’ Tabelle zuordnen. Parallelisierungsgrad und Anzahl Partitions Die Anzahl der Partitions sollte immer höher sein, als der eingestellte Grad der Parallelisierung des Datenbanksystems. Empfohlen wird der Faktor 3, also wird von 10 parallelen Datenbankprozessen ausgegangen, so sind 30 Partitionen optimal. Damit kann das sog. Loadbalancing der Datenbank, d. h. das Verteilen von Durchführungsaufgaben auf freie Prozesse, effizienter erfolgen. Die Datenbank kann eine Partition als Maß für Durchführungseinheiten annehmen. Ist ein Prozess mit der Abarbeitung einer Partition fertig, so kann ihm eine andere noch nicht bearbeitete Partition zugewiesen werden. Da i. d. R. einzelne Prozesse unterschiedlich lange brauchen, um eine Partition zu bearbeiten, würde bei gleicher Anzahl von Partitionen und Prozessen regelmäßig Leerlauf für einzelne Prozesse entstehen und das Systeme wäre nicht optimal ausgelastet. Daher Faktor 3 für das Verhältnis Prozesse zu Partitionen. Beispiel: Bei 10 möglichen Prozessen des Systmens 10 * 3 = 30 Partitionen. Zusammenfassende Empfehlung zur Partitionierung In den meisten Fällen haben wir es in Starschemen mit historisierten Faktentabellen zu tun. Hier empfiehlt sich eine Rangepartitionierung über einen Zeitschlüssel (künstlich oder Datum). Zusätzlich kann über den Schlüssel für die Dimension mit den meisten Anfrageanforderung und relativ hoher Anzahl von Sätzen eine Hash-Partitionierung (Partial Join-wise) erstellt werden. Eine Beispielannahme für eine solche Konstellation wäre etwa das Vorhandensein mehreren Millionen Faktensätzen und mehreren Hunderttausend Kundendismensionssätze. Bei kleineren Dimensionstabellen sollte Bitmap-Indizierung überlegt werden. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 260/300 Schnelles Laden von Daten mit Transportable Tablespace In Verbindung mit der Partitionierung von großen Tabellen bietet sich eine zweite Technik zum schnellen Laden bzw. Ergänzen solcher Tabellen an. Mit der Technik des Transportable Tablespace können ganze Datenbereiche schnell und bequem z. B. an eine bestehende Faktentabelle angehängt werden, ohne die Betriebsbereitschaft und Funktionsfähigkeit der Faktentabelle wesentlich zu beeinträchtigen. Angenommen wir haben eine Faktentabelle nach Monatseiheiten partitioniert und diese ist, einmal monatlich um den aktuellen Monat zu erweitern. Man bereitet eine Tabelle mit den neuen Monatsdaten vor. Diese Tabelle liegt in einem eigens hierfür erstellten Tablespace. Dieser Tablespace kann nun an die bereits bestehende Faktentabelle angehängt werden. Der Austausch geschieht letztendlich über das Exportieren/Importieren und Bekanntgeben von Metdaten (siehe Schaubild). Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 261/300 Bitmap-Indizierung Die Bitmap-Indizierung ermöglich an gezielten Stellen innerhalb des Warehouse eine erhebliche Perfomancesteigerung. Bei der Indizierung einer Column wird für jeden möglichen Column-Wert eine Bitmap-Kette als Index aufgebaut. Diese Bitmap-Kette verzeichnet für jeden Record der Tabelle das Vorhandensein des entsprechenden Wertes. Wird die Tabelle über diese Columnwerte abgefragt, so muss jetzt lediglich die viel kompaktere Bitmap-Leiste abgesucht werden. Die Tabelle muss nicht mehr ‚gescannt’ werden. Beispiel: In einer Kundentabelle liegt der Bildungsstatus des Kunden in Form von Codes (0 – 9) vor. Es stehen also in der Column „Bildung“ die Zahlenwerte 0 bis 9. Ein Bitmapindex bewirkt für jeden dieser Werte eine Bitmap-Kette in der für alle Kunden entweder das Vorhandensein oder Nicht-Vorhandensein (1) des Wertes (0) verzeichnet ist. Name Schubert Bauer Baumeister Schubert Schrieder Bach Schmidt Schmidt Bauer Schubert Bildungscode 2 4 5 3 2 4 5 2 4 4 Bit für Wert 2 (Hauptschule) 1 0 0 0 1 0 0 1 0 0 Bit für Wert 3 (Realschule) 0 0 1 0 0 0 0 0 0 0 Bit für Wert 4 (Gymnasium) 0 1 0 0 0 1 0 0 1 1 Bit für Wert 5 (Studium) 0 0 1 0 0 0 1 0 0 0 Abfragen sind davon unberührt, wirken jedoch wesentlich schneller. Ein Bitmap wird für die Tabellen über den Punkt „Configuration“ im Kontextmenu definiert. Create BITMAP Index "IND_BILDUNG" ON "KUNDE"( "BILDUNG"); Abfragebeispiel: select nachname from kunde where bildung = 3 Tip: Das Erstellen eines Bitmap-Index ist nur bei kleinen Wertevorkommen sinnvoll, wenn die Anzahl der unterschiedlichen Werte kleiner als 2% der Recordanzahl ist. Dies ist verständlich, denn für jeden möglichen Wert wird ein eigener Index vorgehalten. Auf das Feld „Name“ einer Kundentabelle würde es z. B. keinen Sinn ergeben. Bitmap-Join-Index Die Technik kann auch auf die Joins in einem Starschema ausgeweitet werden. Hier sind die Werte von Columns einer Dimension mit der Bitliste zu indizieren. Jede Referenz eines Dimensionswertes zu einem Rekord der Faktentabelle stellt eine 1 in der Bitmap-Liste dar. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 . . . . . . . Oracle Warehouse step-by-step 262/300 Beispiel: In einer Dimension wird für das Feld „Ort“ Bitmap-Index gelegt. Eine Join-Abfrage auf Dimensions- und Faktensätze mit einer Einschränkung über dieses Feld wird jetzt schneller Ergebnisse liefern, weil die Faktentabelle selbst nicht mehr gelesen werden muss. Die Definition: CREATE BITMAP INDEX Ind_Umsatz_bit on Umsatz (region.Orte) From Umsatz, Region where umsatz.fk_ort = Region.PK_Region; Wächst der Index in größeren Systemen, so kann der Bitmap-Index noch zusätzlich partitioniert werden. Bitmap-Index oder Join-Bitmap-Index? In dem Beispiel indiziert man die Werte aus der Column „Orte“. Ist „Orte“ gleichzeitig die indentifizierende Column des untersten Levels der Dimension, so ist das Feld identisch mit dem entsprechenden Foreign Key in der Faktentabelle (1:N – Beziehung von Regionendimension und Faktentabelle). D. h. wir können das Verfahren vereinfachen, indem auf die entsprechenden PrimaryKey-Bestandteile der Faktentabelle ein Bitmap-Index gesetzt wird. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 263/300 Empfehlungen zum Optimieren von Ladeläufen Die folgenden Beispiele beziehen sich auf folgende Tabelle: CREATE TABLE "AA" ( "ARTIKEL_ID" NUMBER(10), "BESTELLMENGE" NUMBER(9), "KUNDEN_ID" NUMBER(10), "ORT_ID" NUMBER(10), "UMSATZWERT" NUMBER(9), "ZEIT_ID" NUMBER(7), "ZEIT_PARTITION" NUMBER(5)) NOLOGGING; NOLOGGING Grundsätzlich ist das Arbeiten mit NoLogging-Tabellen schneller. In einer Warehouse-Umgebung muss nicht mit Logging gearbeitet werden. Erzeugen der Tabellen mit NOLLOGING: CREATE TABLE "tablename" ( "F1" NUMBER(10), "F2" NUMBER(9) ) NOLOGGING ; In Teilschritten arbeiten laden in mehreren kleinen Schritten ist u. U. schneller als eine große Tabelle komplett zu beschreiben, -> Ausnutzen der Partitionierung (Erstellen einzelner Partitionen und Partition Exchange) CTAS Tabellen laden mit CREATE TABLE table AS SELECT * FROM source_table; ist schneller als das Beschreiben der Zieltabelle mit INSERT INTO table SELECT * FROM source_table; Bei Tabellen, die bereits bestehen, sollte überlegt werden, ob die Zieltabelle partitioniert werden kann. Der hinzuzufügende Teil stellt dann eine neue Partition dar, die über eine zuvor mit CTAS erstellte temporäre Tabelle und Partition Exchange angefügt wird. Die folgenden Zahlen auf einem 1 CPU Win2000 System mit 600 MHZ belegen das Verhalten: Hinzuführen von Anzahl Sätzen 310.000 in leere Tabelle 723.552 in leere Tabelle 723.552 in Tabelle mit 723.552 bestehenden Sätzen 1.447.104 in leere Tabelle Insert in bestehende Tabelle 13 sec 27 sec 36 sec 1:08 Min CTAS 8 sec 20 sec PEL Verfahren 20 Sec CTAS + 1 Sec PEL 41 sec Ohne Constraints arbeiten (Aus/Einschalten) Nach Möglichkeit ohne Contraints arbeiten. Oft wurde bereits im Verlauf der Transformation und Transport in die Warehouse-Datenhaltung die Richtigkeit der Daten geprüft. Beispiel Ausschalten von Constraints: ALTER TABLE "DW"."KUNDE" DISABLE CONSTRAINT "PK_KD" ALTER TABLE "DW"."KUNDE" Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 264/300 enable CONSTRAINT "PK_KD" Analyze Mit Analyze arbeiten hilft dem Cost Based Optimizer. Beispiel: Tabelle mit 1.447.104 Sätzen Abfrage select count(distinct Ort_ID) from bb; -> ANALYZE TABLE "BB" COMPUTE STATISTICS; Ohne Analyze 7.02 sec Mit Analyze 6.08 sec Bitmap Mit Bitmap Index vor allem bei COUNT-Abfragen arbeiten. Create BITMAP Index "BB_ORT_BITMAP" ON "BB" (Ort_ID) TABLESPACE "INDX" PARALLEL NOLOGGING ; Tabelle mit 1.447.104 Sätzen Abfrage select count(distinct Ort_ID) from bb; Ohne Analyze Mit Analyze Stand/letzte Änderung 13.05.2016 7.02 sec 3.00 sec (in Arbeit) 75875104 Oracle Warehouse step-by-step 265/300 Analytische Funktionen in der Datenbank °°°° Noch nicht überarbeitet °°°°° Die Datenbank Oracle 9 liefert eine Reihe von Standardfunktionen, mit denen Analyseaktivitäten bereits innerhalb der Datenbank durchführbar sind. Damit ist es möglich Frontend- Werkzeuge z. T. erheblich zu entlasten. Rank Top 10 Anforderung: Liefere die 10 umsatzstärksten Artikel. Select * from (select substr(A.Artikel,1,15),sum(U.umsatz) AS Wert, RANK() OVER (ORDER BY sum(U.umsatz) DESC ) AS Rangfolge from f_umsatz U,dim_artikel A where U.artikel_ID = A.artikel_ID group by a.Artikel) where rownum < 11; Ergebnis SUBSTR(A.ARTIKEL,1,15) WERT RANGFOLGE --------------------------------------------- ---------- ---------Teigmaschine 691200 1 Bohrmaschine_40 682560 2 Hydraulik_Wagen 648480 3 Wasservorratsbe 626880 4 AkkuSchrauber 440160 5 Rosenstrauch_1m 414680 6 Felgenkappen 408800 7 Kaffeemaschine_ 401240 8 Stichsaege 384405 9 Zusatzlicht_Fro 361375 10 10 rows selected. SQL> Ranking innerhalb von Gruppen Anforderung: Liefere Liste aller Artikel nach Umsatzstärke innerhalb der jeweiligen Artikelgruppen select substr(A.Artikel,1,15) as Artikel, substr(A.Artikelgruppe,1,15) as Artikelgruppe, sum(U.umsatz) AS Wert, RANK() OVER (partition by a.Artikelgruppe ORDER BY sum(U.umsatz) DESC ) AS Rangfolge from f_umsatz U,dim_artikel A where U.artikel_ID = A.artikel_ID group by a.Artikelgruppe,a.Artikel order by A.Artikelgruppe; ARTIKEL --------------------------------------------Wasservorratsbe Rosenstrauch_1m Schubkarre Kirschbauplanze Pflanzbehaelter Komposter Beeteinfassunge Spaten Stand/letzte Änderung 13.05.2016 ARTIKELGRUPPE WERT --------------------------------------------- -------Gartenbedarf 626880 Gartenbedarf 414680 Gartenbedarf 356230 Gartenbedarf 342930 Gartenbedarf 264600 Gartenbedarf 239750 Gartenbedarf 195910 Gartenbedarf 168000 (in Arbeit) RANGFOLGE 1 2 3 4 5 6 7 8 75875104 Oracle Warehouse step-by-step Gartenschlauch Holzblumenkaest Rasenduenger Hacke_5Kg Rasenmischung Schnittblumen Holzpfosten Bindeseil Teigmaschine Kaffeemaschine_ Kaffeemaschine_ Pfanne_30 Toster_antik Pfanne_20 Topf_Guss_Gross Topf_Guss_Klein Toster_modern Eierkocher Butterschale_Gl Ruehrschuessel Weihnachsmann Besen_Grob Kehrschaufel Eimer_10l Aufnehmer Bohrmaschine_40 AkkuSchrauber Stichsaege Heissluftpistol Hammer_schwer Amboss Schraubendreher Schraubenschlue Kombizange Wasserwaage_1m Holzschauben_2K Metallsaege Hammer_50g Kneifzange Holzschraube_20 Schleifpapier_v Hydraulik_Wagen Felgenkappen Zusatzlicht_Fro Sitzauflage Poliermittel Universal_Wagen Gluebirnen_Set ErsteHilfekoffe Fahrradhalter Reinigungsfilte Abschleppseil Autatlas KaelteSet Oelfilter Aufkleber_D Reinigungstuech 266/300 Gartenbedarf Gartenbedarf Gartenbedarf Gartenbedarf Gartenbedarf Gartenbedarf Gartenbedarf Gartenbedarf Haushaltswaren Haushaltswaren Haushaltswaren Haushaltswaren Haushaltswaren Haushaltswaren Haushaltswaren Haushaltswaren Haushaltswaren Haushaltswaren Haushaltswaren Haushaltswaren Haushaltswaren Haushaltswaren Haushaltswaren Haushaltswaren Haushaltswaren Heimwerker Heimwerker Heimwerker Heimwerker Heimwerker Heimwerker Heimwerker Heimwerker Heimwerker Heimwerker Heimwerker Heimwerker Heimwerker Heimwerker Heimwerker Heimwerker KFZ-Zubehoer KFZ-Zubehoer KFZ-Zubehoer KFZ-Zubehoer KFZ-Zubehoer KFZ-Zubehoer KFZ-Zubehoer KFZ-Zubehoer KFZ-Zubehoer KFZ-Zubehoer KFZ-Zubehoer KFZ-Zubehoer KFZ-Zubehoer KFZ-Zubehoer KFZ-Zubehoer KFZ-Zubehoer 134045 83590 80795 74640 72100 37830 36875 22515 691200 401240 358680 302910 271800 260100 235375 176625 169000 145540 92820 88440 83150 72550 43740 41000 20550 682560 440160 384405 312570 284580 281700 249900 208650 182000 125685 102115 95640 79100 43410 37275 22710 648480 408800 361375 319470 243075 241560 214240 183000 126635 89820 88465 81510 73250 44190 36350 23670 9 10 11 12 13 14 15 16 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Top 3 Artikel pro Artikelgruppe Anforderung: Liefere Liste der Top 3 Artikel nach Umsatzstärke pro Artikelgruppen column Artikel format A25 column Artikelgruppe format A25 column Wert format 9999999 column Rangfolge format 99 select substr(Artikel,1,25) as Artikel, substr(Artikelgruppe,1,25) as Artikelgruppe, Wert, Rangfolge FROM (select Artikel, Artikelgruppe, sum(U.umsatz) AS Wert, RANK() OVER (partition by a.Artikelgruppe ORDER BY sum(U.umsatz) DESC ) AS Rangfolge from f_umsatz U,dim_artikel A where U.artikel_ID = A.artikel_ID group by a.Artikelgruppe,a.Artikel order by A.Artikelgruppe) where Rangfolge < 4; ARTIKEL ARTIKELGRUPPE WERT RANGFOLGE ------------------------- ------------------------- -------- --------Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step Wasservorratsbehaelter Rosenstrauch_1m Schubkarre Teigmaschine Kaffeemaschine_Braun Kaffeemaschine_Sievert Bohrmaschine_400W AkkuSchrauber Stichsaege Hydraulik_Wagenheber Felgenkappen Zusatzlicht_Front 267/300 Gartenbedarf Gartenbedarf Gartenbedarf Haushaltswaren Haushaltswaren Haushaltswaren Heimwerker Heimwerker Heimwerker KFZ-Zubehoer KFZ-Zubehoer KFZ-Zubehoer 626880 414680 356230 691200 401240 358680 682560 440160 384405 648480 408800 361375 1 2 3 1 2 3 1 2 3 1 2 3 12 rows selected. Anteile an einer Gruppe Anforderung: Welchen Anteil an dem Gesamtumsatz einer Artikelgruppe erwirtschaftet ein Artikel column Artikel format A25 column Artikelgruppe format A25 column Wert format 9999999 column Proportion format 99.99 select substr(Artikel,1,25) as Artikel, substr(Artikelgruppe,1,25) as Artikelgruppe, Wert, Proportion FROM (select Artikel, Artikelgruppe, sum(U.umsatz) AS Wert, CUME_DIST() OVER (partition by a.Artikelgruppe ORDER BY sum(U.umsatz) ASC ) AS Proportion from f_umsatz U,dim_artikel A where U.artikel_ID = A.artikel_ID group by a.Artikelgruppe,a.Artikel order by A.Artikelgruppe); ARTIKEL ------------------------Bindeseil Holzpfosten Schnittblumen Rasenmischung Hacke_5Kg Rasenduenger Holzblumenkaest Gartenschlauch Spaten Beeteinfassungen Komposter Pflanzbehaelter Kirschbauplanze Schubkarre Rosenstrauch_1m Wasservorratsbehaelter Aufnehmer Eimer_10l Kehrschaufel Besen_Grob Weihnachsmann Ruehrschuessel Butterschale_Glas Eierkocher Toster_modern Topf_Guss_Klein Topf_Guss_Gross Pfanne_20 Toster_antik Pfanne_30 Kaffeemaschine_Sievert Kaffeemaschine_Braun ARTIKELGRUPPE WERT PROPORTION ------------------------- -------- ---------Gartenbedarf 22515 .06 Gartenbedarf 36875 .13 Gartenbedarf 37830 .19 Gartenbedarf 72100 .25 Gartenbedarf 74640 .31 Gartenbedarf 80795 .38 Gartenbedarf 83590 .44 Gartenbedarf 134045 .50 Gartenbedarf 168000 .56 Gartenbedarf 195910 .63 Gartenbedarf 239750 .69 Gartenbedarf 264600 .75 Gartenbedarf 342930 .81 Gartenbedarf 356230 .88 Gartenbedarf 414680 .94 Gartenbedarf 626880 1.00 Haushaltswaren 20550 .06 Haushaltswaren 41000 .12 Haushaltswaren 43740 .18 Haushaltswaren 72550 .24 Haushaltswaren 83150 .29 Haushaltswaren 88440 .35 Haushaltswaren 92820 .41 Haushaltswaren 145540 .47 Haushaltswaren 169000 .53 Haushaltswaren 176625 .59 Haushaltswaren 235375 .65 Haushaltswaren 260100 .71 Haushaltswaren 271800 .76 Haushaltswaren 302910 .82 Haushaltswaren 358680 .88 Haushaltswaren 401240 .94 Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step Teigmaschine Schleifpapier_versch_Sort Holzschraube_200g Kneifzange Hammer_50g Metallsaege Holzschauben_2Kg Wasserwaage_1m Kombizange SchraubenschluesselSet Schraubendreher_Set Amboss Hammer_schwer Heissluftpistole Stichsaege AkkuSchrauber Bohrmaschine_400W Reinigungstuecher Aufkleber_D Oelfilter KaelteSet Autatlas Abschleppseil Reinigungsfilter Fahrradhalter ErsteHilfekoffer Gluebirnen_Set Universal_Wagenheber Poliermittel Sitzauflage Zusatzlicht_Front Felgenkappen Hydraulik_Wagenheber Haushaltswaren Heimwerker Heimwerker Heimwerker Heimwerker Heimwerker Heimwerker Heimwerker Heimwerker Heimwerker Heimwerker Heimwerker Heimwerker Heimwerker Heimwerker Heimwerker Heimwerker KFZ-Zubehoer KFZ-Zubehoer KFZ-Zubehoer KFZ-Zubehoer KFZ-Zubehoer KFZ-Zubehoer KFZ-Zubehoer KFZ-Zubehoer KFZ-Zubehoer KFZ-Zubehoer KFZ-Zubehoer KFZ-Zubehoer KFZ-Zubehoer KFZ-Zubehoer KFZ-Zubehoer KFZ-Zubehoer 268/300 691200 22710 37275 43410 79100 95640 102115 125685 182000 208650 249900 281700 284580 312570 384405 440160 682560 23670 36350 44190 73250 81510 88465 89820 126635 183000 214240 241560 243075 319470 361375 408800 648480 1.00 .06 .13 .19 .25 .31 .38 .44 .50 .56 .63 .69 .75 .81 .88 .94 1.00 .06 .13 .19 .25 .31 .38 .44 .50 .56 .63 .69 .75 .81 .88 .94 1.00 65 rows selected. SQL> Kumulierte Anteile Anforderung: Erstelle eine Liste der Quartalsumsätze pro Kunde. Kumuliere die Quartalsumsätze in einer separaten Spalte. column Kunde format A25 column Umsatz format 9999999.99 column Umsatz_Summe format 9999999.99 select substr(k.kunden_Name,1,25) as kunde, z.jahr, z.quartal_des_jahr as Quartal, sum(u.umsatz) as Umsatz, sum(sum(u.umsatz)) over (Partition By k.kunden_Name k.kunden_Name,z.jahr,z.quartal_des_jahr ROWS UNBOUNDED PRECEDING) as Umsatz_Summe from dim_kunde K,f_Umsatz U, dim_zeit Z where k.kunde_id = u.kunde_id and to_char(Z.Datum) = to_char(u.Datum) group by K.kunden_Name,z.jahr,z.quartal_des_jahr; ORDER BY KUNDE JAHR QUARTAL UMSATZ UMSATZ_SUMME ------------------------- ---------- ---------- ----------- -----------BASF Farben und Lacke 1997 3 3765.00 3765.00 BASF Farben und Lacke 1999 4 1000.00 4765.00 BASF Farben und Lacke 2000 4 1815.00 6580.00 Baumeister 1997 1 70645.00 70645.00 Baumeister 1997 2 80795.00 151440.00 Baumeister 1997 3 45305.00 196745.00 Baumeister 1997 4 39115.00 235860.00 Baumeister 1998 1 57730.00 293590.00 Baumeister 1998 2 75865.00 369455.00 Baumeister 1998 3 35060.00 404515.00 Baumeister 1998 4 77160.00 481675.00 Baumeister 1999 1 60935.00 542610.00 Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step Baumeister Baumeister Baumeister Baumeister Baumeister Baumeister Baumeister Baumeister Baumeister Baumeister Baumeister Baumeister 269/300 1999 1999 1999 2000 2000 2000 2000 2001 2001 2001 2001 2002 2 3 4 1 2 3 4 1 2 3 4 1 59255.00 90045.00 79870.00 76755.00 62825.00 78070.00 80915.00 97485.00 70890.00 68810.00 93530.00 6285.00 601865.00 691910.00 771780.00 848535.00 911360.00 989430.00 1070345.00 1167830.00 1238720.00 1307530.00 1401060.00 1407345.00 Segmentieren von Gruppen (Kunden) Anforderung: Sortieren alle Kunden nach Umsatz und segmentiere sie gleich große Gruppen mit umsatzstarken und umsatzschwachen Kunden. 25% der Kunden erzielen wie viel % des Gesamtumsatzes. 1. Zuordnung in gleich große Gruppen nachdem die Kunden nach Umsatz sortiert wurden column Kunde format A25 column Umsatz format 9999999.99 select substr(k.kunden_Name,1,25) as kunde, sum(u.umsatz) as Umsatz, ntile(4) over (order by sum(u.umsatz)) as Anteil from dim_kunde K,f_Umsatz U where k.kunde_id = u.kunde_id group by K.kunden_Name; KUNDE UMSATZ ANTEIL ------------------------- ----------- ---------Kaufhof 815.00 1 Ingenieurbüro Lummerbach 1425.00 1 Siemens AG 1445.00 1 Handelshaus KG 1755.00 1 Ingenieurbüro Kesselbach 3120.00 1 Transport Union Darmstadt 4110.00 1 Gustavson GmbH 4765.00 1 Grund- und Bodenanstalt 5855.00 2 Salamander AG Stuttgart 6545.00 2 BASF Farben und Lacke 6580.00 2 Hüsken Co KG 6880.00 2 Deutsche Bundebahn 8515.00 2 Tiemann und Söhne KG 9765.00 2 Natrium Kolmar 10915.00 2 Gerber KG 11235.00 3 Wienerwald 14930.00 3 Schrieder 1160570.00 3 Eberlein 1243150.00 3 Glas 1271120.00 3 1284110.00 3 Bauer 1338455.00 4 Schiller 1359660.00 4 Schmidt 1365465.00 4 Bach 1386595.00 4 Schubert 1395680.00 4 Baumeister 1407345.00 4 26 rows selected. 2. Summieren aller Umsätze innerhalb einer Gruppe column Kunde format A25 column Umsatz format 9999999.99 select sum(umsatz), anteil from Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 270/300 (select substr(k.kunden_Name,1,25) as kunde, sum(u.umsatz) as Umsatz, ntile(4) over (order by sum(u.umsatz)) as Anteil from dim_kunde K,f_Umsatz U where k.kunde_id = u.kunde_id group by K.kunden_Name) group by anteil; SUM(UMSATZ) ANTEIL ----------- ---------17435 1 55055 2 4985115 3 8253200 4 2. Anwenden einer Prozentrechnung column Kunde format A25 column Umsatz format 9999999.99 column Prozent format 999.99 select sum(umsatz), anteil, (sum(umsatz)*100/Gesamt_umsatz) as Prozent from (select substr(k.kunden_Name,1,25) as kunde, sum(u.umsatz) as Umsatz, ntile(4) over (order by sum(u.umsatz)) as Anteil from dim_kunde K,f_Umsatz U where k.kunde_id = u.kunde_id group by K.kunden_Name), (select sum(u.umsatz) as Gesamt_Umsatz from f_Umsatz U) group by anteil,Gesamt_umsatz; SUM(UMSATZ) ANTEIL PROZENT ----------- ---------- ------17435 1 .13 55055 2 .41 4985115 3 37.42 8253200 4 61.95 => ¼ der Kunden liefern fast 62% des Gesamtumsatzes Moving Average Anforderung: Miss den 3-Monats-Durchschnitt des Umsatzes mit einem bestimmten Kunden und verfolge diesen Wert über die gesamte Geschäftsbeziehung hinweg. Hier ist ein rollierendes Zeitfenster von 3 Monaten gefordert. column Kunde format A10 column Mon format 99 column Jahr format 9999 column Umsatz format 9999999.99 column Mov_3M_AVG format 9999999.99 select substr(k.kunden_Name,1,25) as kunde, z.jahr as Jahr, Monat_des_jahres as Mon, Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 271/300 sum(u.umsatz) as Umsatz, avg(sum(u.umsatz)) over (order by K.kunden_Name,z.jahr,z.Monat_des_jahres Rows 2 Preceding) as Mov_3M_AVG from dim_kunde K,f_Umsatz U, dim_zeit Z where k.kunde_id = u.kunde_id and to_char(Z.Datum) = to_char(u.Datum) and k.kunden_name = 'Bauer' group by K.kunden_Name,z.jahr,z.Monat_des_jahres order by z.jahr,z.Monat_des_jahres; KUNDE JAHR MON UMSATZ MOV_3M_AVG ---------- ----- --- ----------- ----------Bauer 1997 1 37310.00 37310.00 Bauer 1997 2 17040.00 27175.00 Bauer 1997 3 23310.00 25886.67 Bauer 1997 4 15820.00 18723.33 Bauer 1997 5 18040.00 19056.67 Bauer 1997 6 36925.00 23595.00 Bauer 1997 7 18585.00 24516.67 Bauer 1997 8 21515.00 25675.00 Bauer 1997 9 16545.00 18881.67 Bauer 1997 10 17515.00 18525.00 Bauer 1997 11 24850.00 19636.67 Bauer 1997 12 22855.00 21740.00 Bauer 1998 1 27235.00 24980.00 Bauer 1998 2 21855.00 23981.67 Bauer 1998 3 12880.00 20656.67 Bauer 1998 4 41230.00 25321.67 Bauer 1998 5 23005.00 25705.00 Bauer 1998 6 16000.00 26745.00 Bauer 1998 7 18640.00 19215.00 Bauer 1998 8 23280.00 19306.67 Bauer 1998 9 20780.00 20900.00 Bauer 1998 10 30115.00 24725.00 Bauer 1998 11 22495.00 24463.33 Bauer 1998 12 43940.00 32183.33 Bauer 1999 1 19140.00 28525.00 ...... Mehrfachverarbeitung innerhalb eines Kommandos – Reporting Aggregate Functions Anforderung: Liste für jede Artikelgruppe das Bundesland mit dem höchsten Umsatz auf. Zunächst die Liste aller Produktgruppen-Umsätze pro Bundesland: column ArtGr format A20 column Land format A20 column Umsatz format 9999999.99 select ARTIKELGRUPPE as ArtGr , BUNDESLAND as Land , sum(umsatz) as Umsatz from dim_region R, dim_artikel A, f_umsatz U where R.ort_ID = U.ort_ID and A.Artikel_ID = U.artikel_ID group by ARTIKELGRUPPE ,BUNDESLAND order by ARTIKELGRUPPE ,BUNDESLAND ; ARTGR -------------------Gartenbedarf Gartenbedarf Gartenbedarf Gartenbedarf LAND UMSATZ -------------------- ----------Baden Wuerttemberg 214580.00 Bayern 459410.00 Brandenburg 349780.00 Hessen 78800.00 Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step Gartenbedarf Gartenbedarf Gartenbedarf Gartenbedarf Gartenbedarf Gartenbedarf Gartenbedarf Haushaltswaren Haushaltswaren Haushaltswaren Haushaltswaren Haushaltswaren Haushaltswaren Haushaltswaren Haushaltswaren Haushaltswaren Haushaltswaren Haushaltswaren Heimwerker Heimwerker Heimwerker Heimwerker Heimwerker Heimwerker Heimwerker Heimwerker Heimwerker Heimwerker Heimwerker KFZ-Zubehoer KFZ-Zubehoer KFZ-Zubehoer KFZ-Zubehoer KFZ-Zubehoer KFZ-Zubehoer KFZ-Zubehoer KFZ-Zubehoer KFZ-Zubehoer KFZ-Zubehoer KFZ-Zubehoer Niedersachsen Rheinland Pfalz Saarland Sachsen Sachsen-Anhalt Schleswig Holstein Thueringen Baden Wuerttemberg Bayern Brandenburg Hessen Niedersachsen Rheinland Pfalz Saarland Sachsen Sachsen-Anhalt Schleswig Holstein Thueringen Baden Wuerttemberg Bayern Brandenburg Hessen Niedersachsen Rheinland Pfalz Saarland Sachsen Sachsen-Anhalt Schleswig Holstein Thueringen Baden Wuerttemberg Bayern Brandenburg Hessen Niedersachsen Rheinland Pfalz Saarland Sachsen Sachsen-Anhalt Schleswig Holstein Thueringen 272/300 220990.00 508930.00 13900.00 170820.00 228425.00 225750.00 258485.00 230020.00 520775.00 359000.00 81055.00 252645.00 535205.00 15965.00 172895.00 296680.00 230880.00 268760.00 279895.00 524080.00 375295.00 94165.00 238985.00 530610.00 13295.00 215770.00 260620.00 261480.00 290055.00 245200.00 439560.00 336285.00 78950.00 207350.00 525570.00 7530.00 199280.00 222860.00 214240.00 269670.00 44 rows selected. Jetzt die Reporting-Aktivität zu dieser Liste: column ArtGr format A20 column Land format A20 column Umsatz format 9999999.99 select ArtGr , Land ,Umsatz from (select ARTIKELGRUPPE as ArtGr , BUNDESLAND as Land , sum(umsatz) as Umsatz, max(sum(umsatz)) over (partition by ARTIKELGRUPPE) as Max_Ums_Land from dim_region R, dim_artikel A, f_umsatz U where R.ort_ID = U.ort_ID and A.Artikel_ID = U.artikel_ID group by ARTIKELGRUPPE ,BUNDESLAND order by ARTIKELGRUPPE ,BUNDESLAND ) where Umsatz = Max_Ums_Land ; ARTGR -------------------Gartenbedarf Haushaltswaren Heimwerker KFZ-Zubehoer LAND UMSATZ -------------------- ----------Rheinland Pfalz 508930.00 Rheinland Pfalz 535205.00 Rheinland Pfalz 530610.00 Rheinland Pfalz 525570.00 Vorjahresvergleiche Anforderung: Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 273/300 Erstelle eine Liste mit aktuellen und Vorjahresumsätzen. column Kunde format A10 column Mon format 99 column Jahr format 9999 column Umsatz format 9999999.99 column vorjahr format 9999999.99 break on kunde on jahr skip 1 select substr(k.kunden_Name,1,25) as kunde, z.jahr as Jahr, Monat_des_jahres as Mon, sum(u.umsatz) as Umsatz, lag(sum(u.umsatz),12) over (order by z.jahr,z.Monat_des_jahres) as vorjahr from dim_kunde K,f_Umsatz U, dim_zeit Z where k.kunde_id = u.kunde_id and to_char(Z.Datum) = to_char(u.Datum) and k.kunden_name = 'Bauer' group by K.kunden_Name,z.jahr,z.Monat_des_jahres order by z.jahr,z.Monat_des_jahres; KUNDE JAHR MON UMSATZ VORJAHR ---------- ----- --- ----------- ----------Bauer 1997 1 74620.00 2 34080.00 3 46620.00 4 31640.00 5 36080.00 6 73850.00 7 37170.00 8 43030.00 9 33090.00 10 35030.00 11 49700.00 12 45710.00 1998 1 2 3 4 5 6 7 8 9 10 11 12 54470.00 43710.00 25760.00 82460.00 46010.00 32000.00 37280.00 46560.00 41560.00 60230.00 44990.00 87880.00 74620.00 34080.00 46620.00 31640.00 36080.00 73850.00 37170.00 43030.00 33090.00 35030.00 49700.00 45710.00 1999 1 2 3 4 5 6 7 8 9 10 11 12 38280.00 35660.00 33170.00 53300.00 29740.00 40270.00 57550.00 45870.00 17320.00 35160.00 53250.00 46190.00 54470.00 43710.00 25760.00 82460.00 46010.00 32000.00 37280.00 46560.00 41560.00 60230.00 44990.00 87880.00 2000 1 2 3 4 5 6 7 8 9 10 18290.00 76420.00 41870.00 75070.00 77570.00 62710.00 51490.00 33050.00 55380.00 52750.00 38280.00 35660.00 33170.00 53300.00 29740.00 40270.00 57550.00 45870.00 17320.00 35160.00 Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 274/300 11 12 13300.00 6970.00 53250.00 46190.00 2001 1 2 3 4 5 6 7 8 9 10 11 12 33360.00 21610.00 35120.00 13440.00 77900.00 19790.00 35660.00 25400.00 70430.00 44390.00 32840.00 15660.00 18290.00 76420.00 41870.00 75070.00 77570.00 62710.00 51490.00 33050.00 55380.00 52750.00 13300.00 6970.00 2002 1 57150.00 33360.00 61 rows selected. Anforderung: Wieviel Prozentanteile des Umsatzes vom Vorjahr ist erreicht column Kunde format A10 column Mon format 99 column Jahr format 9999 column Umsatz format 9999999.99 column vorjahr format 9999999.99 column Prozent format 999 break on kunde on jahr skip 1 select kunde, jahr, mon, umsatz, vorjahr, umsatz*100/vorjahr as Prozent from (select substr(k.kunden_Name,1,25) as kunde, z.jahr as Jahr, Monat_des_jahres as Mon, sum(u.umsatz) as Umsatz, lag(sum(u.umsatz),12) over (order by z.jahr,z.Monat_des_jahres) as vorjahr from dim_kunde K,f_Umsatz U, dim_zeit Z where k.kunde_id = u.kunde_id and to_char(Z.Datum) = to_char(u.Datum) and k.kunden_name = 'Bauer' group by K.kunden_Name,z.jahr,z.Monat_des_jahres order by z.jahr,z.Monat_des_jahres); KUNDE JAHR MON UMSATZ VORJAHR PROZENT ---------- ----- --- ----------- ----------- ------Bauer 1997 1 74620.00 2 34080.00 3 46620.00 4 31640.00 5 36080.00 6 73850.00 7 37170.00 8 43030.00 9 33090.00 10 35030.00 11 49700.00 12 45710.00 1998 1 2 3 4 5 6 54470.00 43710.00 25760.00 82460.00 46010.00 32000.00 Stand/letzte Änderung 13.05.2016 74620.00 34080.00 46620.00 31640.00 36080.00 73850.00 73 128 55 261 128 43 (in Arbeit) 75875104 Oracle Warehouse step-by-step 275/300 7 8 9 10 11 12 37280.00 46560.00 41560.00 60230.00 44990.00 87880.00 37170.00 43030.00 33090.00 35030.00 49700.00 45710.00 100 108 126 172 91 192 1999 1 2 3 4 5 6 7 8 9 10 11 12 38280.00 35660.00 33170.00 53300.00 29740.00 40270.00 57550.00 45870.00 17320.00 35160.00 53250.00 46190.00 54470.00 43710.00 25760.00 82460.00 46010.00 32000.00 37280.00 46560.00 41560.00 60230.00 44990.00 87880.00 70 82 129 65 65 126 154 99 42 58 118 53 2000 1 2 3 4 5 6 7 8 9 10 11 12 18290.00 76420.00 41870.00 75070.00 77570.00 62710.00 51490.00 33050.00 55380.00 52750.00 13300.00 6970.00 38280.00 35660.00 33170.00 53300.00 29740.00 40270.00 57550.00 45870.00 17320.00 35160.00 53250.00 46190.00 48 214 126 141 261 156 89 72 320 150 25 15 2001 1 2 3 4 5 6 7 8 9 10 11 12 33360.00 21610.00 35120.00 13440.00 77900.00 19790.00 35660.00 25400.00 70430.00 44390.00 32840.00 15660.00 18290.00 76420.00 41870.00 75070.00 77570.00 62710.00 51490.00 33050.00 55380.00 52750.00 13300.00 6970.00 182 28 84 18 100 32 69 77 127 84 247 225 2002 1 57150.00 33360.00 171 61 rows selected. Rollup-Option Ausgeworfen wird für jede Aggregationsebene eine zusätzliche Summenzeile als Zusammenfassung Beispiel: select A.Artikelgruppe,Region,Bundesland,substr(kreis,1,20),sum(u.UMSATZWERT) from Dim_artikel A, f_umsatz U, Dim_region R where U.ARTIKEL_ID = A.Artikel_ID and R.Ort_Id = U.Ort_ID and bundesland = 'Schleswig Holstein' group by Artikelgruppe,rollup (Region,bundesland,kreis); Ergebnis: . Haushaltswaren Haushaltswaren Haushaltswaren Haushaltswaren Haushaltswaren Haushaltswaren Haushaltswaren Haushaltswaren Stand/letzte Änderung 13.05.2016 Nord Nord Nord Nord Nord Nord Nord Nord Schleswig Schleswig Schleswig Schleswig Schleswig Schleswig Schleswig Holst Holst Holst Holst Holst Holst Holst (in Arbeit) Ploen Rendsburg-Ecker Schleswig-Flens Segeberg Steinburg Stormarn 2686 3457 6763 1027 5990 1724 39903 39903 75875104 Oracle Warehouse step-by-step Haushaltswaren KFZ-Zubehoer KFZ-Zubehoer KFZ-Zubehoer KFZ-Zubehoer KFZ-Zubehoer KFZ-Zubehoer KFZ-Zubehoer KFZ-Zubehoer KFZ-Zubehoer KFZ-Zubehoer KFZ-Zubehoer KFZ-Zubehoer 70 Zeilen ausgewählt. SQL> 276/300 Nord Nord Nord Nord Nord Nord Nord Nord Nord Nord Nord Schleswig Schleswig Schleswig Schleswig Schleswig Schleswig Schleswig Schleswig Schleswig Schleswig Holst Holst Holst Holst Holst Holst Holst Holst Holst Holst Nordfriesland Ostholstein Pinneberg Ploen Rendsburg-Ecker Schleswig-Flens Segeberg Steinburg Stormarn 39903 6433 1050 1038 2127 3518 3355 423 3934 2165 38971 38971 38971 Cube-Option Bei der Erstellung der Summenergebnisse werden alle Kombinationsmöglichkeiten der beteiligten Dimensionen/Level berücksichtigt. Beispiel: select A.Artikelgruppe,Region,substr(Bundesland,1,15),substr(kreis,1,15),sum(u.UMSATZWERT) from Dim_artikel A, f_umsatz U, Dim_region R where U.ARTIKEL_ID = A.Artikel_ID and R.Ort_Id = U.Ort_ID and bundesland = 'Schleswig Holstein' group by cube (Artikelgruppe,Region,bundesland,kreis); Ergebnisauswurf (Ausschnitt) ...... KFZ-Zubehoer KFZ-Zubehoer KFZ-Zubehoer KFZ-Zubehoer KFZ-Zubehoer Ostholstein Ploen Rendsburg-Ecker Schleswig-Flens Nord Nord Nord Nord Nord Nord Nord Nord Nord Nord Nord Nord Nord Nord Schleswig Schleswig Schleswig Schleswig Schleswig Schleswig Schleswig Schleswig Schleswig Schleswig Schleswig Schleswig Schleswig Schleswig Schleswig Holst Holst Holst Holst Holst Holst Holst Holst Holst Holst Holst Holst Holst Holst Holst Dithmarschen Pinneberg Rendsburg-Ecker Segeberg Stormarn Herzogtum Lauen Nordfriesland Ostholstein Pinneberg Rendsburg-Ecker Schleswig-Flens Steinburg Stormarn Dithmarschen Herzogtum Lauen Nordfriesland Pinneberg Ploen Rendsburg-Ecker Schleswig-Flens Steinburg Stormarn Dithmarschen Nordfriesland Ostholstein Pinneberg Rendsburg-Ecker Stormarn 1050 2127 3518 3355 38971 131797 8429 157944 14061 87019 1558801 273244 208311 6175 8429 157944 258416 217879 87019 131797 273244 208311 8429 195526 157944 258416 217879 87019 131797 208311 6175 8429 157944 87019 1558801 288 Zeilen ausgewählt. Grouping Sets Hier wird nur eine Teilmenge der möglichen Aggregationen ausgewält. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 277/300 Grouping-Sets sind sehr praktisch, weil man hier zielgenaunur die gewünschten Aggregationen erreicht. Beispiel: select Region,substr(Bundesland,1,15),substr(kreis,1,15), substr(Artikelgruppe,1,10),sum(u.UMSATZWERT), grouping(Artikelgruppe) as AG, grouping(Bundesland) as BL from Dim_artikel A, f_umsatz U, Dim_region R where U.ARTIKEL_ID = A.Artikel_ID and R.Ort_Id = U.Ort_ID and bundesland = 'Schleswig Holstein' group by grouping sets (Region,Artikelgruppe,bundesland,kreis) order by region,bundesland,kreis,artikelgruppe / Nord Schleswig Holst Dithmarschen Herzogtum Lauen Nordfriesland Ostholstein Pinneberg Ploen Rendsburg-Ecker Schleswig-Flens Segeberg Steinburg Stormarn Computerte Gartenbeda Haushaltsw Heimwerker KFZ-Zubeho 1558801 1558801 131797 273244 208311 6175 8429 195526 157944 258416 14061 217879 87019 1405195 35066 39903 39666 38971 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 1 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 2843085 13465 160211 131797 111388 6707 273244 269971 108684 45075 208311 141309 127942 6175 85656 151772 8429 195526 157944 34628 258416 14061 217879 87019 27476 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 18 Zeilen ausgewählt. SQL> 2. Beispiel: select Region,substr(kreis,1,15), sum(u.UMSATZWERT), grouping(Region) as RE from f_umsatz U, Dim_region R where R.Ort_Id = U.Ort_ID and region = 'Nord' group by grouping sets (Region,kreis) order by region,kreis; Nord Bad Doberan Demmin Dithmarschen Guestrow Hamburg, Freie Herzogtum Lauen Ludwigslust Mecklenburg-Str Mueritz Nordfriesland Nordvorpommern Nordwestmecklen Ostholstein Ostvorpommern Parchim Pinneberg Ploen Rendsburg-Ecker Ruegen Schleswig-Flens Segeberg Steinburg Stormarn Uecker-Randow 25 Zeilen ausgewählt. Komplexeres Beispiel Beispieltabelle: create table months Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 278/300 (month date, value number(10,2) ); Abfrage: break on year skip 1 column year noprint column value format 9999999 column cy_movsum heading 'Calendar Year|Moving Sum' format 9999999 column cy_movavg heading 'Calendar Year|Moving Average' format 9999999 column fy_movsum heading 'Fiscal Year|Moving Sum' format 9999999 column fy_movavg heading 'Fiscal Year|Moving Average' format 9999999 select to_char(month, 'YYYY') "Year", to_char(month, 'MON-YYYY') "Date", value "Value", sum(value) over (partition by to_char(month, 'YYYY') order by month range between unbounded preceding and current row) cy_movsum, avg(value) over (partition by to_char(month, 'YYYY') order by month range between unbounded preceding and current row) cy_movavg, sum(value) over (partition by to_char(add_months(month,7), 'YYYY') order by month range between unbounded preceding and current row) fy_movsum, avg(value) over (partition by to_char(add_months(month,7), 'YYYY') order by month range between unbounded preceding and current row) fy_movavg from months order by month / clear columns clear breaks Ergebnis: Calendar Year Calendar Year Fiscal Year Fiscal Year Date Value Moving Sum Moving Average Moving Sum Moving Average ------------------------ -------- ------------- -------------- ----------- -------------JAN-1998 496 496 496 496 496 FEB-1998 1274 1770 885 1770 885 MAR-1998 2325 4095 1365 4095 1365 APR-1998 3165 7260 1815 7260 1815 MAY-1998 4216 11476 2295 11476 2295 JUN-1998 4995 16471 2745 4995 4995 JUL-1998 6107 22578 3225 11102 5551 AUG-1998 7068 29646 3706 18170 6057 SEP-1998 7755 37401 4156 25925 6481 OCT-1998 8959 46360 4636 34884 6977 NOV-1998 9585 55945 5086 44469 7412 DEC-1998 10850 66795 5566 55319 7903 JAN-1999 FEB-1999 MAR-1999 APR-1999 MAY-1999 JUN-1999 JUL-1999 AUG-1999 SEP-1999 OCT-1999 NOV-1999 DEC-1999 11811 11494 13640 14115 15531 15945 17422 18383 18705 20274 20535 22165 11811 23305 36945 51060 66591 82536 99958 118341 137046 157320 177855 200020 11811 11653 12315 12765 13318 13756 14280 14793 15227 15732 16169 16668 67130 78624 92264 106379 121910 15945 33367 51750 70455 90729 111264 133429 8391 8736 9226 9671 10159 15945 16684 17250 17614 18146 18544 19061 JAN-2000 FEB-2000 MAR-2000 APR-2000 MAY-2000 JUN-2000 23126 22504 24986 25095 26877 26925 23126 45630 70616 95711 122588 149513 23126 22815 23539 23928 24518 24919 156555 179059 204045 229140 256017 26925 19569 19895 20405 20831 21335 26925 30 rows selected. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 279/300 12. Testdatengenerator Der Testdatengenerator hat die Aufgabe beliebig strukturierte und anonymisierte Daten in beliebiger Menge für Testzwecken in den Datenbanktabellen bereitzustellen. U. U. vergisst der Entwickler, dass bestimmte Zeichenkombinationen in den Quelldaten vorkommen können. Der Testdatengenerator liefert beliebige darstellbare Zeichen. Nicht immer stehen Echtdaten für Testzwecke zur Verfügung. Der Testdatengenerator erstellt Daten mit einer zu den Echtdaten analogen Struktur aber dennoch zufällig. Warehouse-Systeme reizen häufen Systemgrenzen aus, sei es Performance oder Speicherkapazität. Der Testdatengenerator produziert Daten beliebiger Menge und dies sehr realitätsnah genau in der Struktur, in der auch das Warehouse aufgebaut ist. Die Kombination eines Datenbank-nahen ETL-Werkzeuges wie dem Warehouse Builder mit einen Testdatengenerator ist besonders geeignet, die Produktivität des Entwicklers zu steigern. Wenn der Testdatengenerator zu dem noch offene Datenbankmittel benutzt, ist dies ideal. Nutzen Testdatengenerator: anonymisierte Daten als Ersatz zu Echtdaten beliebig strukturierte Daten auch komplexe Strukturen (Master-Detail) ideales Add On zu OWB beliebig viele Daten zum Ausreizen der Systemgrenzen Besondere Aufgabenstellung: Der Entwicklungsprozess eines Data Warehouses kann komplex sein. Daher sollten zumindest die Werkzeuge zur Erstellung des Systems sehr einfachen Grundideen folgen. Der Testdatengenerator ist sehr einfach gebaut und schnell erlernbar. Woraus besteht der Testdatengenerator: OWB MDL Datei mit Beispiel-Tabellen, Funktionen, Prozeduren, Beispiel-Mappings Flat Files mit deutschsprachigen Beispieleinträgen zu üblichen Tabellen wie sie vielen Warehouse-Systemen vorkommen Zu den Flat Files passende CREATE EXTERNAL TABLE Definitionen zum schnellen Einlesen der Flat Files. Die Funktionen Function Paramter RAN_M_N MIN_N, MAX_N, number decimals(optional) Beschreibung of Returns a random number value between parameter1 and parameter2 The optional third parameter indicates the number of digits behind the decimal point. Rules: If the second parameter has a lower value than the first the first parameter will be ignored and set to zero. Maximum 7 digits RAN_ABC_MIXED N(optional) Example: select ran_M_N(1000,2000) from dual Returns a number (parameter1) of letters in mixed cases. Parameter1 is optional. Max number of letters is 256 Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step RAN_ABC123_MI XED N(optional) 280/300 (You get only upper or only lower cases with the SQLupper/lower function around this function.) Returns a number (parameter1) of letters or digits in mixed cases. Parameter1 is optional. Max number of letters is 256 RAN_DATE_ RANGE_FROM RANGE_TO (You get only upper or only lower cases with the SQLupper/lower function around this function.) Returns any date between Parameter1 and Parameter2 Parameter1, Parameter2 are numbers and mean the number of years. Example: Assumed this Day is 16-12-02 select ran_date_n(50,20) from dual --> returns any date between 16-12-52 and 16-12-82 select ran_date_n(10,0) from dual --> returns any date between 16-12-92 and today RAN_ VALUES N, values Returns a number parameter2. (parameter1) of values of With first parameter you specify the number of values with the second one you can specify the values itsself. Example: Select ran_values(5,'.$567{Karl Gustav}') from dual; Returns: 7 {al a$va . su76 Max number of letters is 256. RAN_WORDS WORD_DELIMITER, Words (You get upper or lower cases only with the SQLupper/lower function around this function. ) Returns a word (parameter2) of range of words (parameter2). With first parameter you specify a seperator for the list of word of second paramter. With second you specify a list of words seperated by the separator sign defined in first parameter (last sign must be the seperator itsself). Example: ran_WORDS('/','retail/IT/Medical/finance') RAN_LK TABLE_NAME KEY_FIELD_NAME VALUE_FIELD_NAME Stand/letzte Änderung 13.05.2016 returns one of the words. Returns random column values from a lookup table. Parameter 1 : Name of lookup table Parameter 2 : Name of column with the access key Parameter 3 : Name of column with the values to (in Arbeit) 75875104 Oracle Warehouse step-by-step 281/300 return Example: select RAN_LK('firstname','nr','vorname') from dual Returns: Klaus Egon Chris Beispiel-Mapping: In dem Beispiel-Mapping wird eine Kundentabelle mit beliebig vielen Sätzen erzeugt. Die verschiedenen Columns erfordern unterschiedliche Wertestrukturen. Sammlung von einfachen Zufallsgenerierungen z. B. - Zahlenwerte von 1-10 als Referenzcode für Berufsgruppe - Zahlenwerte von 1000000-99999999 für Telefonnummern usw. Die Generierung der Werte für die einzelnen Columns erfolgt entweder über direkte Funktionsaufrufe oder als Expression-Operatoren. Generierung beliebiger Zahlenwerte: Für einfache Wertestrukturen sind Funktionsaufrufe in dem Expression-Operator mit dem Namen „Collection“ zusammengefasst. Mit der rechten Maustaste auf die einzelnen Outgrp-Felder gelangt man zu den Definitionen: Column Funktionsaufruf Telefon Telefax Branche "RAN_M_N"(1, 99999) "RAN_M_N"(1, 99999) "RAN_M_N"(1, 9) Berufsgruppe "RAN_M_N"(1, 9) Einkommensgruppe "RAN_M_N"(1, 6) Wohnart "RAN_M_N"(1, 16) Bildung "RAN_M_N"(1, 9) Firmenrabatt "RAN_M_N"(1, 40) Beschreibung Beliebige Zahl von 1 bis 99999 Beliebige Zahl von 1 bis 99999 Werte von 1 bis 9 referenzieren eine Codetabelle mit „Branchen“ Werte von 1 bis 9 referenzieren eine Codetabelle mit „Berufsgruppen“ Werte von 1 bis 6 referenzieren eine Codetabelle mit „Einkommensgruppen“ Werte von 1 bis 16 referenzieren eine Codetabelle mit „Wohnarten“ Werte von 1 bis 9 referenzieren eine Codetabelle mit „Bildungsabschlüssen“ Es entsteht ein einfacher Wert von 1 bis 40 (Unter INGRP1 wird die Konstante „Del“ als Input-Parameter entgegengenommen. Dies ist nur eine Hilfskonstruktion, weil OWB das Mapping sonst nicht generieren wird. Der Input-Parameter wird tatsächlich nicht gebraucht.) Generierung einfacher Buchstaben als feststehende Werte: Für das Feld Status sind nur die Buchstaben „F“ (Firmenkunde) und „P“ (Privatkunde) erlaubt. Wahlweise muss also der Buchstabe „F“ oder „P“ generiert werden. Die Funktion „RAN_VALUES“ ist aus der Funktionsbibliothek in das Mapping geladen worden. Die Versorgung der Aufruf-Prameter „Status“ und „Number_of_Status“ übernehmen die Konstanten „Status“ (Wert „FP“) und „Number_of_Status“ (Wert „1“). Generierung von Wörtern als feststehende Werte: Für das Beispielfeld „Titel“ sind z. B. Werte wie „Dr.“, „Magister“, „Prof.“, „Pastor“ erlaubt. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 282/300 Die Funktion „RAN_WORDS“ generiert beliebig Begriffe, die ihr als Parameter übergeben werden. Die einzelnen Wörter sind mit einem Stringdelimiter-Zeichen getrennt, der ebenfalls als Parameteraufruf festgelegt wird. Der Beispielaufruf lautet in diesem Fall: 'Dr./Magister/ /Prof./Pastor/'. Der Stringdelimiter ist das „/“-Zeichen. Generierung von „VON/BIS“-Datumsbereichen: Beispiel Geburtsdatum des Kunden. Wenn z. B. für Bankkunden ein Alter von 18 bis 70 Jahren simuliert werden soll, so ist das Geburtsdatum zwischen Tagesdatum minus (18*365) und Tagesdatum minus 88*365 Tagen zu wählen. Die ermöglicht die Funktion „RAN_DATE_N“ mit zwei Datumsangaben als Aufrufparameter. Um die Formatangaben einfach zu halten, wird lediglich die Anzahl der Jahre übergeben, also RAN_DATE_N(18,88). Generierung von Werten aus einer großen Liste von Werten: Beispiel ist das Erzeugen von Vornamen/Nachnamen aus einer Liste von beliebig Vornamen/Nachnamen die in einer Tabelle gespeichert sind. Dies ist eine wichtige und immer wieder vorkommende Anforderung: Bislang wurden als Quelle für die Zufallswerte eine fest eingrenzbare Liste von Werten genutzt. Diese konnte sehr einfach als Parameterliste einer Funktion übergeben werden. Oft sollen jedoch bestehende Datenbanktabellen mit Tausenden von Sätzen als Quelle genutzt werden. Solche „Referenztabellen“ müssen mindesten ein numerisches Codefeld (1 – n) und das eigentliche Wertefeld besitzen, z. B.: 1;Monika;0;Frau; 2;Sabine;0;Frau; 3;Elke;0;Frau; 4;Nicole;0;Frau; 5;Petra;0;Frau; 6;Claudia;0;Frau; 7;Susanne;0;Frau; 8;Annegret;0;Frau; 9;Michelle;0;Frau; 10;Vanessa;0;Frau; 11;Gudrun;0;Frau; 12;Helene;0;Frau; 13;Ortrud;0;Frau; Aus der vorstehenden Wertetabelle können die erste und zweite Spalte genutzt werden. Die Funktion RAN_LK liest mit dynamische SQL eine solche Wertetabelle aus. Sie stellt die Anzahl der Tabellensätze fest und generiert einen Zufallswert aus dem Bereich „0“ bis „max. Anzahl Sätze“ (count(*)). Die Funktion bedarf als Aufrufparameter den Namen der Tabelle, den Namen der CodeSpalte und den Namen der Spalte mit den eigentlichen Werten. Die Tabelle muss eine echte Tabelle und darf keine External Table sein. Wie entstehen die Sätze und wie wird deren Anzahl festgelegt: Der Warehouse Builder nutzt reines SQL zum Laden und Erzeugen von Sätzen in Zieltabellen. Er nutzt die einfache Form: INSERT INTO zieltabelle SELECT f1,f2 FROM quelltabelle WHERE bedingung; Über dieses SQL-Kommando entstehen auch die Testsätze des Testdatengenerators. Das Mapping visualisiert das Kommando. Alle Bestandteile des Kommandos entstehen durch Operatoren die das Mapping graphisch darstellt. Da bei der Simulation des Testdatengenerators keine echten Quellsätze zur Verfügung stehen, müssen diese simuliert werden. Die Rolle der Quelltabelle übernimmt die Hilfstabelle TRIGGER_TABLE. Sie besteht aus einer einzigen Spalte und 1 bis n Sätzen mit fortlaufenden Zahlenwerten (1 – n). Diese Tabelle wird nur gebraucht, um in der FROM-Klausel einen Tabellennamen verwenden zu können. Weil die Tabelle aber tatsächlich 1 – n Sätze beinhaltet, generiert die Datenbank ein internes Set an Sätzen (SELECT), und reicht es an das folgende INSERT zur Bildung der eigentlichen Zielsätze. Wie in dem Beispiel-Mapping zu sehen ist, kann die Column der Trigger_Tabelle als laufende Nummer in der Zieltabelle genutzt werden. Dies ist allerdings nur optional. In dem SELECT-Zweig können jetzt beliebig viele der oben vorgestellten RANDOMFunktionen eingebaut werden. Die Anzahl der Zielsätze ist über die WHERE-Klausel festlegbar. Das Beispiel-Mapping verwendet hierzu den Filter-Operator. Beispielgenerierung: Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 283/300 INSERT /*+ APPEND PARALLEL("TESTKUNDE", DEFAULT, DEFAULT)*/ INTO "TESTKUNDE" ("KUNDENNR", "GESCHLECHT", "VORNAME", "NACHNAME", "TITEL", "ANREDE", "GEBDAT", "BRANCHE", "WOHNART", "BILDUNG", "ANZ_KINDER", "EINKOMMENSGRUPPE", "BERUFSGRUPPE", "STATUS", "TELEFON", "TELEFAX", "FIRMENRABATT") (SELECT "TRIGGER_TABLE"."Z" "Z", "RAN_WORDS"((FULLPACKAGENAME."CONST_DEL"),(FULLPACKAGENAME."CONST_GESCHLECHT")) "RESULT", "RAN_LK"((FULLPACKAGENAME."CONST_TABLE_1"),(FULLPACKAGENAME."CONST_KEYFIELD"),(FULLPACKAGENAME ."CONST_VALUEFIELD")) "Result", "RAN_LK"((FULLPACKAGENAME."CONST_TABLE_1$0"),(FULLPACKAGENAME."CONST_KEY"),(FULLPACKAGENAME."C ONST_VALUE")) "Result$0", "RAN_WORDS"((FULLPACKAGENAME."CONST_DEL"),(FULLPACKAGENAME."CONST_TITEL")) "RESULT$0", "RAN_WORDS"((FULLPACKAGENAME."CONST_DEL"),(FULLPACKAGENAME."CONST_WORDS")) "RESULT$1", "RAN_DATE_N"((FULLPACKAGENAME."CONST_GEB_DAT_VON"),(FULLPACKAGENAME."CONST_GEB_DAT_BIS")) "RESULT$2", "RAN_M_N"(1, 9) "BRANCHE", "RAN_M_N"(1, 16) "WOHNART", "RAN_M_N"(1, 9) "BILDUNG", "RAN_M_N"(1, 6) "ANZ_KINDER", "RAN_M_N"(1, 6) "EINKOMMENSGRUPPE", "RAN_M_N"(1, 9) "BERUFSGRUPPE", "RAN_VALUES"((FULLPACKAGENAME."CONST_NUMBER_OF_STATUS"),(FULLPACKAGENAME."CONST_STATUS")) "RESULT$3", "RAN_M_N"(1, 99999) "TELEFON", "RAN_M_N"(1, 99999) "TELEFAX", "RAN_M_N"(1, 40) "FIRMENRABATT" FROM "TRIGGER_TABLE" "TRIGGER_TABLE" WHERE ( "TRIGGER_TABLE"."Z" < 100 ) ) Die Flat Files und die dazu passenden EXTERNAL Table Definitionen German Description Wohnart Artikel Artikelgruppe Artikelsparte Firmen Kundenart Bildung Vornamen Berufsgruppe Nachname Gehaltsgruppe Template als Kopiervorlage Branche Gemeinden Stand/letzte Änderung 13.05.2016 Test Data accommodation_type_GR.LST Article_GR.LST Article_Group_GR.LST Article_Group_Line_GR.LST Companies_GR.lst Customer_Type_GR.LST Education_GR.LST First_Name_GR.LST Job_Role_GR.LST Last_Name_GR.LST salary_Range_GR.LST Template.LST Trade_GR.LST Village_GR.LST (in Arbeit) CREATE TABLE Definition CR_accommodation_type.txt CR_Articles.txt CR_Article_Groups.txt CR_Article_Group_line.txt CR_Companies.txt CR_Customer_Type.txt CR_education.txt CR_FirstName.txt CR_Job_Role.txt CR_LastName.txt CR_salary_Range.txt CR_Template.txt CR_Trade.txt CR_Villages.txt 75875104 Oracle Warehouse step-by-step Alle Daten zusammenhängend landen 284/300 All previous lists All_Definitions.txt Die Batch-Datei „All_Definitions.txt „ läd alle Flat File Daten in die Datenbank. Ergebnis sind zum einen External Tables (Präfix EX_) zum anderen aber auch echte Oracle-Tabellen. Echte Oracle-Tabellen sind besser geeignet um im Nachgang Testdaten zu erzeugen, weil über einen Zufallsgenerator immer wieder zufällig auf eine Nummernspalte zugegriffen wird. - Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 285/300 13. Anhang mit Sonderthemen °°°° Noch nicht überarbeitet °°°°° Aufruf eines Mapping im Batch zu Testzwecken In SQLPLUS mit einem Access-User gehen (z. B. OWBRT_AC) Aufruf des folgenden Scriptes mit den entsprechenden Parametern OWB-HOME\owb\rtp\sql\sqlplus_exec_template.sql z. B. start D:\oracle\owb\owb\rtp\sql\sqlplus_exec_template.sql owbrt LOC_DWH PLSQL MP_TZ '','' ,","; Das gleiche Beispiel als Batch-Datei-Aufruf: sqlplus owbrt_ac/owbrt_ac@ora92 @D:\oracle\owb\owb\rtp\sql\sqlplus_exec_template.sql owbrt LOC_DWH PLSQL MP_TZ '','' ,","; In dem Beispiel stehen die Parameter für Owbrt LOC_DWH PLSQL MP_TZ '','' ,","; Runtime-Schema (Owner) Name der Location des Schemas in dem das Mapping laufen soll (Zielschema) Typ des “Laufobjektes” Name des Mappings Parameter, die zunächst nicht benötigt werden Weitere Informationen sind als Kommentare in dem Header der Prozedur enthalten. Tabellen im Speicher vorhalten ALTER TABLE table_name CACHE; Sinnvoll für Referenztabellen (Lookup-Tables), auf die immer wieder zugegriffen werden muss Das Mapping Nützliche Zeitfunktionen zum Erstellen einer Zeitdimension Anwendung Beispielkommando Aktuelles Jahr Quartal im Jahr Monat im Jahr Tag im Monat Woche im Jahr Monat select TO_NUMBER( TO_CHAR(sysdate, 'YYYY' ) ) from dual select TO_NUMBER( TO_CHAR(sysdate, 'Q' ) ) from dual select TO_NUMBER( TO_CHAR(sysdate, 'MM' ) ) from dual select TO_NUMBER( TO_CHAR(sysdate, 'DD' ) ) from dual select to_number(to_char(sysdate,'WW')) from dual select TO_CHAR(sysdate, 'fmMonth', 'nls_date_language = GERMAN') from DUAL; select TO_CHAR(sysdate, 'Mon' ) from dual select TO_CHAR(sysdate, 'fmday', 'nls_date_language = GERMAN') from DUAL; select TO_NUMBER( TO_CHAR(sysdate, 'D' ) ) from dual Kurzform Monat Name Tag der Woche (amerikanisches Format) Tag der Woche (Deutsche Umrechnung) select case to_number(to_char(sysdate,'D'))-1 when 0 then 7 else to_number(to_char(sysdate,'D'))-1 end Stand/letzte Änderung 13.05.2016 (in Arbeit) Ergebnis für Datum 30.06.03 (Montag) 2003 2 6 30 26 Juni Jun montag 2 1 75875104 Oracle Warehouse step-by-step Tag im Jahr Kurzform Tag Stunde am Tag(12) Uhrzeit Stunde am Tag(24) 286/300 from dual / select TO_NUMBER( TO_CHAR(sysdate, 'DDD' ) ) from dual select ( TO_CHAR( sysdate, 'dy' ) ) from dual select to_number(to_char(sysdate,'HH12')) from dual select to_char(sysdate,'HH12:MI:SS') from dual select to_number(to_char(sysdate,'HH24')) from dual 181 Mon 11 11:23:17 23 Funktion zum liefern des 1. Tages des aktuellen Quartals CREATE OR REPLACE FUNCTION F_1_TAG_Q(DATUM IN DATE) RETURN DATE AS BEGIN if to_char(DATUM,'mmdd') < '0331' then return to_date(to_char(DATUM,'YYYY')||'0101','YYYYMMDD'); end if; if to_char(DATUM,'mmdd') < '0630' then return to_date(to_char(DATUM,'YYYY')||'0401','YYYYMMDD'); end if; if to_char(DATUM,'mmdd') < '0930' then return to_date(to_char(DATUM,'YYYY')||'0701','YYYYMMDD'); end if; return to_date(to_char(DATUM,'YYYY')||'1001','YYYYMMDD'); END; Rumpffunktion zu schnellen Erstellen einer Funktion CREATE OR REPLACE FUNCTION F_X(Feld IN number) RETURN number AS BEGIN return Feld; END; Prüfen auf Vorhandensein von Referenzsätzen oder Stammdaten Angenommen Bewegungsdaten (z. B. die Bestelldaten des Beispiels in dieser Unterlage) sollen in ein Warehouse übernommen werden. Im Verlauf dieses Vorgangs soll geprüft werden, ob die dazu passenden Stammdaten (z. B. Kunden) auch vorhanden sind. Wenn nicht müssen Fehlermeldungen geschrieben werden. Lösungsvorschlag: Erstellen einer Funktion (IN_KUNDENSTAMM_CASE), die im Verlauf des Mappings auf die Kundentabelle zu Prüfzwecken zugreift. Bei nicht Vorhandensein eines Kundensatzes wird in eine Fehlertabelle geschrieben, die wie folgt aussieht: create table fehlertabelle (text varchar2(20)); Die Funktion IN_KUNDENSTAMM_CASE liefert bei nicht Vorhandensein eines KUNDENCODEs von BESTELLUNG in der Kundentabelle KUNDE den Wert 0 zurück. Dieser Wert wird in der Splitterbedingung für den Splitterzweig „PROTOKOLL“ geprüft und ein Satz in die Tabelle FEHLERTABELLE geschrieben. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 287/300 Das Mapping zur Erstellung des Fehlerprotokolls Die Funktion IN_KUNDENSTAMM_CASE: Beispiel: Zugriff auf das Runtime-System: Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 288/300 Lesen Runtime column map_run_id format 9999 column map_name format A30 column start_time format A10 column end_time format A10 select map_run_id,map_name,start_time,end_time from all_rt_audit_map_runs; (Create a new sequence in runtime schema let's say 'myseq'.) Create a shell script containing the following steps to be executed in a SQL session for every mapping: 1 - Get a new sequence value with: SELECT myseq.NEXTVAL into :newseq; 2 - Concatenate mapping name with this value you'll have a unique jobname 'mymap_newseq' 3 - Begin the job ==> exec wbprti.job_begin('mymap_newseq'); 4 - Execute your mapping ==> exec mymap.main(........,p_job=>'mymap_newseq'); 5 - Get process ID: SELECT process_id into :get_process_id FROM all_iv_process WHERE process_name = 'mymap_newseq'; 6 - Get map status and map ID: SELECT status , map_run_id into :get_status,:get_map_run_id FROM all_iv_map_run WHERE process_run_id = get_process_id; Optionally you can get the error message with: 6a - SELECT error_number,error_message into :get_error_number,:get_error_message FROM all_iv_run_error WHERE map_run_id = get_map_run_id; If get_status = 'COMPLETE' 7a - Finalize the job with success ==> exec wbprti.job_end('mymap_newseq'); else 7b - Finalize the job with failure ==> exec wbprti.job_fail('mymap_newseq'); Sinnvolle Namenskonventionen Es gibt keine Vorgaben für die Vergabe von Namen, außer dass keine reservierten Wörter genutzt werden dürfen (siehe hierfür die Dokumentation). Aber aufgrund der praktischen Erfahrung können einige Tipps gegeben werden: Gruppenbegriffe in Joinern/Splittern sprechend wählen, sie werden in die Ausgaben der Operatoren weitergereicht und können damit auch in den Folgetabellen für die Columns genutzt werden. Bei Dimensionen kurze Level-Präfixe nutzen, damit sind auf unterschiedlichen Hierarchieleveln gleichlautende Attribute möglich die durch levelspezifische Präfixe wieder unterschieden werden können. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 289/300 Mapping-Namen sollten den Namen der Hauptzieltabellen enthalten (zur Orientierung). Bei allen Namen sollte man sich bewusst sein, dass diese Namen auch in den Metadatenreports genutzt werden. Also je sprechender sie sind um so deutlicher sind die Metadaten. Sprechende Namen für Foreign Keys festlegen, das gilt speziell für die FKs zwischen Fakten und Dimensionen. Wenn man das nicht macht, dann generiert das Systeme kryptische Namen, die in allen Wizards auftauchen und man keinerlei Orientierung. Bei einer Faktentabelle sollten die FKs die Namenskürzel der Dimensionen beinhalten, auf die sie verweisen. Z. B. sind Constraintverletzungen über den Audit-Viewer dann schneller identifizierbar. Ansonsten: MP_ - Mapping MO_ - Modul VW_ - View MAV_ - Mat. View DIM_ - Dimensional Table DBL_ - Database Link TB_ - Tabelle LOC_ - Locations Wie mach ich was: Tips und Tricks Was Ordnung schaffen komplexen Tabellen Wie Bemerkung bei Arbeiten Sie mit Display Sets in Es kann z. B. unterschieden der Tabellendarstellung werden zwischen: - Berechneten Werten Standard_1:1_Zuweisungswerte n Großziehen der Tabellen in dem An der rechten unteren Ecke des Andere Ecken gehen nicht mappingeditor Tabellenobjektes nach rechts unten wegziehen Ausschalten der Wizard- Unter Administrations und dann Geht einfach schneller Übersichtsfenster zu Beginn Preferences eines Wizardablaufs Und hier 'Hide Welcome pages on all Wizards' Ausschalten der Verwendung Rechte Maustaste auf das von DB-Link-Zusetzen bei der jeweilige Mapping und dann Generierung 'Configuration' Hier sind für alle an dem Mapping beteiligten Tabellen die "access Specifications aufgelistet". Der Default beinhaltet immer einen DB-Link zu dem einmal definierten Quellmodul. Das ist dann auch angezeigt und kann abgeschaltet werden Einschalten der Schemangabe (siehe vorgenannter Punkt) für die Generierung Übersichtlichkeit schaffen wenn Nutzen von Display Sets Es werden nur die Columns Tabellen mit zu vielen Columns angezeigt, die man wirklich zu lang werden. braucht. Testabfrage: Wieviele select status,count(status) from Hilfreich zur Überprüfung von Vorkommnisse gibt es von kunde group by status Werten vor und nach einer einem bestimmten Wert in einem Transformation. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 290/300 Feld. Source der generierten Packages anschauen: select text, line from user_source where name = 'MP_TRANSAKTIONEN' and line < 10 CTAS Schnelles Kopieren einer Tabelle gelingt am einfachsten durch die Aktion CTAS (Create table ... As Select). Der Warehouse Builder unterstützt diese Variante in der jetzigen Version nicht, daher müsste diese Möglichkeit in einer Funktion bzw. in einer Prozedur realisiert werden: a. Drop Target-Table; b. Create table Target-Table as Select * from Source-Table; Diese Variante ist deutlich schneller als Insert into Target-Table select * from Source-Table Mengenberechnungstabelle Berechnung des Gesamtplattenbedarfs z. B. mit folgender Tabelle: Tabelle Initial Anzahl Sätze Inserts pro (Zeiteinheit (z. B. Monat) Inserts pro (Zeiteinheit (z. B. Monat) Grösse eines Satzes (KB) Grösse eines Index (KB) Gesamt grösse pro Satz Table Functions Es gibt Anforderungen an die Transformation von Daten, die nicht direkt mit SQL-Mitteln realisiert werden können. In diesen Situation kann mit PL/SQL weiter gearbeitet werden. Doch dann hat man es man es mit Prozeduren zu tun und verlässt den die Möglichkeiten des mengenorientierten SQL. Table Functions bieten ab Oracle 9i eine Lösung: Man kann prozedural programmieren (mit PL/SQL) und behält dennoch die Freiheit der SQL-Kommandos mit all ihren Möglichkeiten. Ein Beispiel: Es soll eine Kundendimension aufgebaut werden. Die einzelnen Sätze von Dimensionen sollten eindeutig sein, in der Kundendimension ist also für jeden Kunden nur ein Satz vorhanden. In dem operativen Quellsystem (vielleicht ein CRM-System) gibt es neben der eigentlichen Kundentabelle eine Tabelle mit möglichen Kundeneigenschaften, die über eine Intersektiontabelle mit der Kundentabelle verbunden ist. So können jedem Kunden mehrere Eigenschaften zugeordnet werden. Über die Intersektiontabelle, sind also für jeden Kunden mehrere Sätze (mehrere Eigenschaften) gleichzeitig möglich. Bei dem Aufbau der Kundendimension im Warehouse sollen alle Eigenschaften „denormalisiert“ in die Kundendimensionstabelle überführt werden, wobei man sich auf eine maximale Anzahl von Kundeneigenschaften beschränkt, jede Eigenschaft wird als separate Column in einen Dimensionssatz aufgenommen werden. Quellstruktur: Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 291/300 Zielstruktur: Technisch muss eine Transformation erstellt werden, die aus Feldern, die sich über mehrere Sätze verteilen, einen einzigen Satz erstellt. Sicher eine Anforderung für eine PL/SQL-Routine. Diese kann jedoch jetzt geschickt gekapselt als Table Function werden. Table Functions erhalten ein „Row Set“ als Input, also eine Menge Datensätzen, wie sie z. B. ein SELECT-Kommando zurückliefert. Als Rückgabe lieferte eine Table Function dann auch wieder ein „Row Set“. Damit ist eine Table Function innerhalb der FROM-Klausel eines SELECT einsetzbar. Zur Übergabe der Sätze wird Objekt- und Cursor-Technik genutzt, letztlich schnelle Operationen, die vollständig innerhalb des Hauptspeichers stattfinden, und Operationen, bei denen z. T. nur Speicheradressen und nicht Daten ausgetauscht werden. In nebenstehendem Beispiel -- PIPELINED Table-Function werden mehrere Sätze der ----------------------------------------------------------Tabelle T1 immer dann -- Beispieltabelle: zusammgefass, wenn das erste Feld F1 gleich ist. Das Feld F3 drop table T1; wird auf das 3. bzw. 4. Output- Create table T1 (F1 number(1), Feld des neuen Satzes F2 number(1), übertragen. Um das Beispiel F3 varchar2(10)); einfach zu halten, ist man davon ausgegangen, dass es in der -- Beispieldaten: Quelltabelle immer nur zwei insert into T1 (F1,F2,F3) values (1,2,'MBN'); Sätze mit gleichem Feld F1 insert into T1 (F1,F2,F3) values (2,1,'ABC'); insert into T1 (F1,F2,F3) values (3,1,'XXX'); geben kann. In dem Beispielaufruf unten ist zu sehen, dass die Funktion in Stand/letzte Änderung 13.05.2016 insert into T1 (F1,F2,F3) values (4,1,'DEF'); insert into T1 (F1,F2,F3) values (1,1,'ADI'); insert into T1 (F1,F2,F3) values (3,1,'LLL'); / (in Arbeit) 75875104 Oracle Warehouse step-by-step der FROM-Klausel eines weiteren SELECT-Kommandos aufgerufen wird. In „*“ des SQLKommandos steht also der Output der Table Function. Der Funktion wird beim Aufruf ein CURSOR mitgegeben, der aus einem weiteren SELECT (Parameter der CURSORFunktion) gespeist wird. Innerhalb der Table Function muss jetzt der Cursor ausgelesen werden. Über ein Gruppenwechselverfahren sammelt die Rourine alle zu einer F1-Nummer passenden Sätze und gibt sie erst zurück, wenn eine neue F1-Nummer über den Cursor geliefert wird. Die Routine ist mit PIPELINED definiert. Damit kann mit der PIPE ROW()-Funktion jeder Satz direkt an das aufrufende SQLKommando zurückgegeben werden. Die nötigen Object-TypDefinitionen fürn die RekordStruktur ist ebenfalls abgedruckt. Pivoting Dies war ein Beispiel für das Überführen mehrerer Sätze in einen Satz. Dies ist ein sog. Pivoting-Vorgang. Analog lässt sich die Technik natürlich auch für das Umwandeln eines einzelnen Satzes in mehrere Sätze anwenden. Das Verfahren ist vor allem deswegen so praktisch, weil es uns nicht zwingt die SET-Based Verarbeitung zu verlassen. Wir bewegen uns nach wie vor auf der schnelleren weil gleichzeitigen Verarbeitung von Mehreren Sätzen. Schachteln von Table Functions Table Functions lassen sich beliebig schachtelt. Es entsteht ein Pipelining, bei dem alle Verarbeitungsschritte in einer einzigen Verarbeitungskette sich die Ergebnis-Record-Sets im Speicher gegenseitig weiterreichen. Stand/letzte Änderung 13.05.2016 292/300 Commit; / -- Die benötigten Typdefinitionen drop type out_t_table ; Drop type out_t; / -- Aufruftypen create or replace package cursor_pkg1 as type XXX_t_rec IS RECORD ( F1 number(1), F2 NUMBER(1), F3 VARCHAR2(10)); TYPE XXX_t_rectab IS TABLE of XXX_t_rec; TYPE strong_refcur_t IS REF CURSOR RETURN XXX_t_rec; TYPE refcur_t IS REF CURSOR; END; / -- Rückgabetypen / Create type out_t as object ( out1 number(1), out2 NUMBER(1), out3 VARCHAR2(10), out4 VARCHAR2(10) ); / create type out_t_table as TABLE of out_t; / -- Die eigentliche Tablefunction create or replace function f_XXX(cur cursor_pkg.refcur_t) RETURN out_t_table PIPELINED IS Y1 Number(5); Y2 NUMBER(5); Y3 VARCHAR2(10); out1 Number(5); out2 number(5); out3 varchar2(10); out4 varchar2(10); Key_alt number(5) := 0; begin LOOP -- read from cursor variable FETCH cur into Y1,Y2,Y3; -- ext when last row EXIT WHEN cur%NOTFOUND; if Key_alt != Y1 then -- Gruppenwechsel, jetzt alten Satz wegschreiben, -- der aller erste Satz wird wohl leer -- bleiben pipe row(out_t(out1,out2,out3,out4)); out4 := NULL; -- neuen Schlüssel Y1 für später retten key_alt := Y1; out1 := Y1; out2 := Y2; out3 := Y3; else -- Folgesatz out4 := Y3; end if; -- pipe row(YYY_t(Y1,Y2,Y3,Y4,Y5)); END LOOP; -- ein letztes Mal schreiben pipe row(out_t(out1,out2,out3,out4)); CLOSE cur; Return; (in Arbeit) 75875104 Oracle Warehouse step-by-step 293/300 END; / -- der Einsatz der Tablefunktion select count(*) from TABLE(f_XXX(CURSOR(select * from T1 order by F1))); select * TABLE(f_XXX(CURSOR(select * from T1 order by F1))); from Table Functions und Warehouse Builder Noch gibt es in dem OWB 9i-Release keine Möglichkeiten Table-Functions zu nutzen. Jedoch können Table Functions über einen View gekapselt werden. Views sind dann in OWB wie normale Quelltabellen zu behandeln. Beispiel passend zu der oben erstellten Table Function: Create Or Replace Force View xxx (x1,x2,x3,x4) as select * from TABLE(f_XXX(CURSOR(select Stand/letzte Änderung 13.05.2016 * (in Arbeit) from T1 order by F1))); 75875104 Oracle Warehouse step-by-step 294/300 Polling Es gibt Anforderungen bei denen Quelldaten in kurzen Zeitabständen (Intervalle von wenigen Sekunden oder Minuten) abgefragt werden sollen. Hierzu ist eine Lese-Routine (z. B. Stored Procedure) regelmäßig zu starten (Polling). Genutzt werden kann hierzu das Datenbank Job-Management-System. Man nutzt einen sog. „Background Prozess“ (SNP process) über den man eine Job-Queue erstellen kann. Eine Prozedur wird in die Job-Queue gestellt, die die Prozedur in Abhängigkeit der gewählten Parameter ausführt. Wichtige Einstellungen in der INIT.ORA: -> JOB_QUEUE_PROCESSES n ( dieser Wert ist auf > 0 zu setzen, festgelegt wird die max. Anzahl der möglichen Prozesse für die Jobs) Zum Starten einer Prozedur über eine Job_Queue ist folgende Routine zu erstellen. begin DBMS_JOB.SUBMIT(job OUT BINARY_INTEGER, 'Name einer Prozedur;' IN VARCHAR2, nächster Startzeitpunkt IN DATE DEFAULT SYSDATE, Intervall in Zeiteinheiten IN VARCHAR2; end; / Beispiel: VARIABLE jobnr NUMBER; begin DBMS_JOB.SUBMIT(:jobnr, 'tempInsert;', sysdate, 'sysdate + (10/(24*60*60))'); end; / jobnr ist ein Platzhalter in den das Jobsystem eine eindeutige interne Nummer schreibt. Über diese Nummer können die Jobs später identifiziert werden. ‚tempInsert;’ ist ein Ausdruck, der zum Aufrufen der eigentlichen Routine gebraucht wird, deswegen ist hier auch ein Semikolon mit in die Anführungsstriche eingeschlossen. Hier können also auch Parameter der Prozedur mitgegeben werden. sysdate ist das Startdatum, also jetzt. 'sysdate + (10/(24*60*60))' ist ein Ausdruck der eine Zeitspanne X von jetzt an berechnet. In diesem Fall werden 10 Sekunden berechnet. Testabfrage zur Ausgabe der Jobnummer im vorigen Beispiel: print jobnr; Orientierung darüber wie viele Jobs laufen: select job, schema_user,interval from user_jobs; In user_jobs stehen alle Informationen über aktuell laufende Jobs. Löschen eines Jobs: begin DBMS_JOB.remove(61); End 61 ist die Jobnummer, die das System intern vergeben hat. Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 295/300 Neu-kompilieren von Sourcen in der Datenbank Durch Einspielen von Patches oder unüberlegte Löschvorgänge können Prozeduren oder Funktionen In den Zustand „INVALID“ gesetzt werden. (Herausfinden von „invalieden“ Sourcen am einfachsten über den Enterprisemanager.). Um für ein ganzes Schema alle kompilierbaren Ressourcen wieder neu zu komplieren kann man folgenden Aufruf auf ein Schema absetzen (hier Schema DW): exec dbms_utility.compile_schema('DW'); Achtung: Je nach Menge der Objekte kann das länger laufen. Testdaten (CSV-File) ORTE.CSV (Beispiel zum Einlesen von Flat Files) Orte_Nr,Ort,PLZ,Bundesland,Region,Nummernfeld 1,'Berlin','D-86269','Berlin','Ost',3 2,'Braunschweig','D-69279','Niedersachsen','Mitte',9 3,'Bremen','D-37053','Bremen','Nord',1 4,'Dortmund','D-71382','Nordrhein-Westfalen','Sued',1 5,'Elmshorn','D-29543','Schleswig Holstein','Nord',1 6,'Essen','D-65922','Nordrhein-Westfale','West',6 7,'Hannover','D-87741','Niedersachsen','West',1 8,'Kaiserslautern','D-47186','Rheinland Pfalz','Mitte',7 9,'Karlsruhe','D-84769','Baden Wuerttemberg','Mitte',4 10,'Kiel','D-27228','Schleswig Holstein','Nord',3 11,'Ludwigsburg','D-43165','Bayern','Mitte',5 12,'Mannheim','D-15059','Baden Wuerttemberg','West',9 13,'Muenchen','D-80639','Bayern','Sued',7 15,'Muenster','D-84407','Nordrhein-Westfalen','West',4 16,'Nuernberg','D-21394','Bayern','Sued',1 17,'Stuttgart','D-41722','Baden Wuerttemberg','Sued',1 18,'Trier','D-63893','Rheinland Pfalz','Sued',6 19,'Ulm','D-62064','Baden Wuerttemberg','Sued',6 20,'Wuerzburg','D-52375','Bayern','Ost',4 21,'Augsburg','D-52375','Bayern','Sued',4 22,'Saarbruecken','D-52375','Saarland','West',7 23,'Leipzig','D-52375','Sachsen','Ost',2 24,'Ludwigshafen','D-52375','Rheinland Pfalz','Mitte',8 25,'Dreieich','D-52375','Hessen','Mitte',4 26,'Darmstadt','D-52375','Hessen','Mitte',9 27,'Freiburg','D-52375','Baden Wuerttemberg','Sued',6 28,'Regensburg','D-52375','Bayern','Sued',7 29,'Potsdam','D-52375','Brandenburg','Ost',3 30,'Duisburg','D-52375','Nordrhein-Westfale','West',5 31,'Koeln','D-52375','Nordrhein-Westfale','West',8 32,'Koblenz','D-52375','Rheinland Pfalz','Mitte',1 33,'Worms','D-52375','Rheinland Pfalz','West',2 34,'Heidelberg','D-52375','Baden Wuerttemberg','Mitte',7 35,'Coburg','D-52375','Bayern','Sued',5 36,'Frankfurt','D-52375','Hessen','Mitte',4 37,'Flensburg','D-52375','Schleswig Holstein','Nord',3 38,'Wiesbaden','D-52375','Hessen','Mitte',8 39,'Mainz','D-52375','Hessen','Mitte',8 40,'Fuerth','D-52375','Bayern','Sued',3 41,'Duesseldorf','D-52375','Nordrhein-Westfalen','West',5 42,'Osnabrueck','D-52375','Nordrhein-Westfalen','Mitte',7 43,'Bielefeld','D-52375','Nordrhein-Westfalen','Mitte',8 44,'Aachen','D-52375','Nordrhein-Westfalen','West',2 45,'Dresden','D-52375','Sachsen','Ost',9 46,'Chemnitz','D-52375','Sachsen','Ost',3 47,'Luebeck','D-52375','Schleswig Holstein','Nord',6 Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 296/300 48,'Wilhelmshaven','D-52375','Nordrhein-Westfalen','Nord',1 49,'Kassel','D-52375','Hessen','Mitte',7 50,'Schweinfurt','D-52375','Bayern','Sued',8 51,'Erfurt','D-52375','Thueringen','Ost',4 52,'Bamberg','D-52375','Bayern','Sued',3 53,'Hamburg','D-52375','Hamburg','Nord',8 Literaturliste (kommentiert) Titel Autor Erscheinungsjahr / ISBN (0 englisch 3 deutsch) Themen Bemerkung (+ ++ +++) Data Warehouse Design Solutions The Data Warehouse Toolkit Adamson 1998 0-471-25195-X Beinhaltet Starschemen zu unterschiedlichen Verticals Als Nachschlage-sammlung gut geeignet ++ Ralph Kimball 1995 0-471-15337-0 Entwickeln multidimensionaler Strukturen (Starschema) für verschiedene Verticals The Webhouse Toolkit Ralph Kimball 2000 0-471-37680-9 Building the Data Warehouse Inmon 1996 0-471-14161-5 Analysen von Webserver Logfiles, Clickstream Data Marts, Publishing von Warehouse-Daten im Web Umfassende Grundlagen zu dem Thema DW, Konzepte, Verfahren Klassiker, sehr viele praktische Hinweise, sollte man kennen +++ Nur interessant für Analysen von Webtraffic + Object Oriented Data Warehouse Design Giovinazzo 2000 0-13-085081-0 Kompletter Abriss eines Warehouse Projektes anhand einer Case Study. Starschemamodellierung Data Warehouse for Dummies Simon 1997 0-7645-0170-4 Globaler Abriss über alles , was mit Warehouse zu tun hat. Der OLAP Markt ForwissStudie FORWISS 1997 3-00-002033-0 OLAP Marktübersicht 1997, mittlerweile veraltet, einleitende Kapitel erklären fast alle Fachbegriffe, die in OLAP Systemen Verwendung finden. Stand/letzte Änderung 13.05.2016 (in Arbeit) Klassiker, während Kimball sehr praktisch schreibt, geht Inmon sehr stark ins Konzeptionelle. Liefert methodisches Rüstzeug +++ Gut geschrieben, leicht verständlich. Dieses Buch sollte für jeden Warehouse Projektmitarbeiter Pflichtlektüre sein. OO spielt nur zu Beginn eine Rolle. +++ Locker (lustig) geschriebene Übersicht für Einsteiger, mehr für Endanwender gedacht, die sich orientieren wollen. Kein Expertenlevel. + Die einleitenden Kapitel sind als gut vermittelnder Einstieg in die multidimensionale Analyse empfehlenswert. Kurzgerafft, schnell gelesen wie eine Seminararbeit. Die Herstellerbeschreibungen sind mittlerweile veraltet. 75875104 Oracle Warehouse step-by-step 297/300 + Nur interessant zum Suchen von speziellen Anwendungen aus der Praxis. Sehr Uni-haft, akademisch. + Data Warehouse und Managemen t Informations systeme Data Warehouse Verschiede ne Autoren, Hannig (Hrsg.) 1996 3-7910-1097-2 Verschiedene Aufsätze zur Methodik, Praxisbeispiele, Ausführungen zu Mining Anahory 1997 3-8273-1288-4 Durchmarsch durch ein Warehouse-Projekt. Strategische Steuerung Horváth (Hrsg) 2000 3-7910-1719-5 Aufsatzsammlung aus dem Bereich des Controlling, mehrere Fallbeispiele Balanced Scorecard Friedag/Sc hmidt 1999 3-448-04061-4 Das Data Warehouse Konzept Mucksch /Behme (Hrsg.) 1996 3-409-12216-8 Abarbeitung von Kennzahlen aus den unterschiedlichen Perspektiven des Geschäftsprozesses, das Prinzip einer Balanced Scorecard wird vorgestellt Architekturen, Datenmodelle, Anwendungen Data Warehouse Practical Advice from the Experts Bischoff (Vorwort von Zachmann) 1997 0-13-577370-9 Beschrieben sind viele Einzelaspekte aus Warehouse-Projekten Data Warehouse gestützte Anwendung en Building a Data Warehouse for Decision Behme/Mu cksch (Hrsg.) 2001 3-409-116559-1 Neben einer Einführung Aufsätze verschiedener Autoren aus diversen Verticals Bleibt viel zu oft im Allgemeinen, viel Text und wenig konkretes, ab und zu kann man was Interessantes entdecken. Erfahrungen aus der Frühzeit des Warehouse. Fast veraltet. + Praktische Anschauung allerdings für die spezielle Zielgruppe derjenigen, die sich um Controllingsysteme / Kennzahlensysteme Gedanken machen. Spezielle mit Blickrichtung Balanced Scorecard ++ Praxisbuch zum Finden der passenden Fragestellungen in einem Analyse/ Steuerungssystems. Empfehlenswert für jeden, der entsprechende Systeme implementiert. ++ Aufsätze aus den verschiedensten Bereichen, z. T. Praxisbereichte. Achtung oft nur akademische Abhandlungen, z. T. allgemein, technische bezüge sind veraltet. + Eine Menge Autoren liefern sehr viel Grundsätzliches, wie vieles, was aus den USA zu dem Themenkomplex kommt, so ist auch dieses sehr bodenständig/praktisch angelegt. + Liefert vertical-spezifisches Eindrücke in WarehouseSzenarien. ++ Poe 1997 0-13-590662-8 Einführung in die Warehouse –Philosophie Grundlagen Nichts, was nicht schon woanders steht. + Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step Support Data Warehouse Data Mining OLAP Martin (Meta Group) 298/300 1998 3-8266-4022-5 Verschiedene Autoren referieren über die unterschiedlichsten Aspekte des Data Warehouse. Kundenbeispiele Sehr viel Akademisches. Wenig für Praktiker. + Aufrufparameter für OWB-Client setzen: - um Hauptspeicherverbrauch zu begrenzen -> in der Datei „X:\OWB_HOME\owb\bin\win32\owbclient.bat” den Parameter –mx setzen also z. B. für 256MB: ..\..\lib\ext\jre\bin\javaw -Xms64M –Xmx256M Testhilfen und hilfreiche Kommandos für SQL*Plus Tests In SQLPLUS: Set timing on set autotrace on explain; show parameters que... SET LINE nn Messung von verbrauchter Zeit Kommandoverarbeitung tracen Abfrage gesetzter init.ora-Parameter Verbreiterung der Ausgabezeilen Select * from Tab; Schneller Zugriff auf die für den USER zur Verfügung stehenden Tabellen. Formatierungen der Ausgaben in SQLPLUS: SET PAGESIZE 0 SET PAGESIZE nn SET HEADING OFF COLUMN column_name FORMAT 9999 COLUMN columname FORMAT A20 CLEAR FORMAT BREAK ON feldname [ON feldname] SKIP n CLEAR BREAKS Spool C:/abc.txt … … Spool off Ausschalten der Seiteneinteilung. Sinnvoll für Listenausgaben ohne störende Seitenköpfe. Erhöhen/Ändern der Anzahl Ausgabezeilen bevor eine neue Überschrift folgt Ausschalten der Column-Überschriften Festelgen von Spaltenausgabeformaten für Listen, z. B. Festlegen der Spaltenbreite. Unterdrücken von Gruppenebene Schreiben in eine Datei Wiederholungen auf Schnelles Erstellen einer CSV-Datei Beispiel für das einfache und schnelle Erzeugen einer CSV-Datei aus den Eintrgägen einer Tabelle. In dem folgenden Beispiel sind Semikolons eingefügt. column VORNMAENNL_NR format 9999 column VORNAME format A20 column GESCHLECHT format 9 column ANREDE format A4 Spool d:\td\xx select VORNMAENNL_NR,';',VORNAME,';',GESCHLECHT,';',ANREDE,';' from vorname; spool off Hintergrund - Erstellen einer Tabelle mit Parameteraufruf Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 299/300 accept TName Prompt "Name einer neu zu erstellenden Tabelle: " drop table &TName; CREATE TABLE &TName(A NUMBER(2)); insert into &TName (A) Values(10); select * from &TName; commit; exit; / Hilfskommandos zum Unterdücken des Outputs im Betriebssystemfenster: set echo off set termout off Beispiel-Init.Ora-Datei für eine Installation von OWB und OracleDatenbank auf einem(!) Rechner. °°°° Noch nicht überarbeitet °°°°° Hier sind die Speicherangaben entsprechend modifiziert, damit man möglichst lange ohne Auslagerungsdatei auf dem NT-Rechner auskommt. db_name = "ORA817" instance_name = ORA817 service_names = ORA817 db_files = 1024 enqueue_resources = 3000 AQ_TM_PROCESSES = 1 JOB_QUEUE_PROCESSES = 2 JOB_QUEUE_INTERVAL = 5 # Schreiben in externe Datei #UTL_FILE_DIR = D:\oracle\ora81\wf\res UTL_FILE_DIR = * #Einstellungen, um das automatische Umschreiben von Abfragen in #Richtung auf Materialized Views zu ermöglichen query_rewrite_enabled=true # Einstellungen für Oracle Workflow open_cursors = 400 max_enabled_roles = 50 db_file_multiblock_read_count = 16 db_block_buffers = 4500 shared_pool_size = 15728640 large_pool_size = 614400 # java_pool_size wird nur gesetzt, wenn Runtimesystem installiert wird oder mit Portal die #Metadatengelesen werden sollen #java_pool_size = 30971520 java_pool_size = 0 log_checkpoint_interval = 200000 log_checkpoint_timeout = 1800 processes = 200 parallel_max_servers = 5 Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104 Oracle Warehouse step-by-step 300/300 log_buffer = 32768 #audit_trail = true # if you want auditing #timed_statistics = true # if you want timed statistics max_dump_file_size = 10240 # limit trace file size to 5M each # Global Naming -- enforce that a dblink has same name as the db it connects to global_names = false db_block_size = 8192 os_authent_prefix = "" #der folgende Parameter ist wichtig, damit überhaupt über einen dblink gelesen werden kann #er ist für beide Datenbanken zu setzten, also auch für die Remote-Instanz, wenn dieser auf Null #steht, geht nichts distributed_transactions = 500 mts_dispatchers = "(PROTOCOL=TCP)(PRE=oracle.aurora.server.SGiopServer)" #sort_area_size = 65536 sort_area_size = 655360 sort_area_retained_size = 65536 hash_area_size = 8388608 Stand/letzte Änderung 13.05.2016 (in Arbeit) 75875104
