Doku_MD_V3
Werbung
Metadaten-Repository Framework Dokumentation V3 Metadaten-Repository Framework Dokumentation Business Information Catalogue für das Data Warehouse Beispielmodell: Data Warehouse Information Model 1 Metadaten-Repository Framework Dokumentation V3 Inhalt Metadaten-Repository Framework .......................................................................................................... 1 Die Methodik eines Repository-Systems ............................................................................................. 3 Die Bedeutung von Metadaten ......................................................................................................... 3 Eigenschaften und Ziele eines Metadaten Repositories .................................................................. 3 Ziele des Frameworks.......................................................................................................................... 4 Flexibilität entsteht durch Mehr-Schichten-Lösung .......................................................................... 4 Zur Terminologie und zum Verständnis ........................................................................................... 5 Das Prinzip der Eindeutigkeit, Versionen und Varianten ................................................................. 6 Die technische Umsetzung des Frameworks ...................................................................................... 8 Beschreibung der Definitionsschicht (Ebene 4) ............................................................................... 8 Definitionstabellen ............................................................................................................................ 8 Die Festlegung der Metadaten-Typen (Ebene 3) ............................................................................. 8 Erfassen der Metadaten (Level 2) .................................................................................................. 11 Beschreibung der Repository-Oberfläche mit APEX ......................................................................... 18 Start und Aufruf .............................................................................................................................. 18 Der erste Blick ................................................................................................................................ 18 Objekt-Sichten und Suchstrategien ................................................................................................ 20 Anzeigen einzelner Objekte mit Attributen und Beziehungen ........................................................ 22 Änderungen an bestehenden Objekten vornehmen ...................................................................... 23 Objekte neu Erfassen ..................................................................................................................... 23 Strukturauflösungen ....................................................................................................................... 25 Zusätzliche Generierung von HTML-Berichten zu einzelnen Objekten ......................................... 26 Data Warehouse Information Model .................................................................................................. 29 Graphische Darstellung des Data Warehouse Information Models ............................................... 29 Die Installation ................................................................................................................................... 31 Ausgelieferte Dateien ..................................................................................................................... 31 Reihenfolge der Installationsschritte .............................................................................................. 31 Vorausetzungen für die Installation ................................................................................................ 31 Vorausetzungen für den Betrieb des Framworks ........................................................................... 31 Entpacken der ausgelieferten Installationsdatei ............................................................................ 32 Einrichten des Datenbankschemas für das Repository ................................................................. 32 Installieren der Repository-Tabellen und Prozeduren.................................................................... 32 [Zusätzliche Hilfsprozeduren installieren]....................................................................................... 32 Das DWH-Informationsmodell laden .............................................................................................. 32 Die Beispiel-Daten für das DWH-Informationsmodell laden .......................................................... 32 Die APEX-Bedienoberfläche installieren ........................................................................................ 33 Apex-Installation ............................................................................................................................. 33 Zulassung von PL/SQL Procedures als URL Function wwv_flow_epg_include_mod_local ......... 35 Version 3, Stand August. 2011, Die Verwendung ist frei. Die einzelnen Komponenten und Modelle können mit PL/SQL bzw. APEX weiter entwickelt werden. Bezug der Sourcen und Feedback über [email protected] (Hamburg 040 89091132) 2 Metadaten-Repository Framework Dokumentation V3 Die Methodik eines Repository-Systems Die Bedeutung von Metadaten Metadaten übernehmen in Data Warehouse-Systemen die wichtige Aufgabe der Dokumentation. Sie geben den Warehouse-Benutzern Orientierung über Art, Struktur und Inhalt der angebotenen Data Warehouse-Informationen und Funktionen. Fast jedes Werkzeug, das zur Entwicklung von Data Warehouse-Systemen eingesetzt wird, verfügt über ein Metadaten-Repository. Diese Tools decken jedoch meist nur einen spezifischen Ausschnitt des potentiellen Metadaten-Universums ab. Diesen Ausschnitt dokumentieren sie dagegen extrem detailliert und der Gesamtkontext bleibt verborgen. „Den Wald vor lauter Bäumen nicht sehen“ beschreibt die Situation treffend. Was fehlt ist ein einfaches aber übergreifendes Metadaten-System, das sehr schnell einen strukturierten Überblick zu den jeweils relevanten Informationen bereitstellen kann. Ein solches System sollte von spezifischen Sichten und Bereichen wie etwa ETL-Entwicklung, Datenmodellierung, Reporterstellung usw. abstrahieren können, aber dennoch die Verbindungen dazwischen herstellen. Das System soll Fragen beantworten wie: Wer benutzt welche Berichte? Wem gehören welche Daten? Wer pflegt sie und ist verantwortlich dafür? Welche Daten und Berichte entstehen aus welchen Tabellen? Welche Kennzahlen gibt es in welchen Berichten? Welche Daten kommen in welchen Vorsystemen mit synonymen Ausprägungen vor? Wie sind Begriffe definiert? Und vieles mehr. Eigenschaften und Ziele eines Metadaten Repositories Metadaten werden in Repositories gespeichert. Andere Namen hierfür sind Dictionaries oder auch Daten-Katalogen. Repositories gibt es in der IT an mehreren Stellen. Auch in einem Data Warehouse finden wir oft mehrere Repositories. Diese Systeme decken jedoch meist nur einen Teilbereich und oft auch nur technische Metadaten ab. Folgende Situation kann immer wieder in Data Warehouse - Umgebungen beobachtet werden: Lade-Routinen sind, wenn überhaupt, nur Inline, d. h. im programmierten Skript-Code, dokumentiert. Eventuell gibt es ein ETL-Werkzeug, das eine graphische Darstellung der Mapping-Routinen anbietet. Die Werkzeuge stehen aber nur Technikern zur Verfügung und auch nur diese können die Mapping „lesen“ und verstehen. Die Datenstrukturen findet man in dem jeweiligen Datenbank-Katalog oder in einem Datenmodellierungs-Werkzeug. Die dazu gehörigen Geschäftsprozesse, aus denen das Data Warehouse gefüllt wird, sind nicht beschrieben, allenfalls die OLTP-Tabellen aus denen der ETL-Prozess seine Daten liest. Sind die Prozesse doch (z. B. in entsprechenden Tools, oder auch nur in Excel/Word) beschrieben, so ist die Dokumentation veraltet. Datenqualitäts-Regeln, die in dem ETL-Prozess zu prüfen sind, sind nicht beschrieben. Sie müssen aus dem Code innerhalb der ETL-Werkzeuge abgelesen werden (was meist nur der jeweilige Techniker kann, der Werkzeug bedient). Standardberichte sind entweder in Text-Listen oder in den jeweiligen Reporting-Tools dokumentiert Es fehlt eine Übersicht über alle zur Verfügung stehenden Kennzahlen. …. 3 Metadaten-Repository Framework Dokumentation V3 Die Liste könnte fortgeführt werden. Auch wenn alle Beschreibungen / Metadaten vorhanden sind, so sind sie meist nur an unterschiedlichen Stellen vorhanden. Benötigt man ein zusammenhängendes Bild, so muss man sich alle Teile aufwendig zusammensuchen. 1. Das hier dargestellte Metadaten Repository Framework will Metadaten an einer zentralen Stelle zusammenführen. 2. Es minimiert damit die Suchzeit und sorgt für eine schnelle Bereitstellung eines Überblicks über Strukturen und Zusammenhänge in einem Data Warehouse. 3. Durch das Zusammenführen der verteilten Informationen vermeidet das Repository Redundanzen und damit Doppeldeutigkeiten Es muss damit automatisch neutral gegenüber den einzelnen Anwendungsgebieten sein und ersetzt daher nicht die vorgenannten Repositories mit ihren dedizierten Aufgabengebieten. Ziele des Frameworks Dieses Framework zeigt Funktionen und die Machbarkeit eines sehr einfachen aber generischflexiblen und universell einsetzbaren Metadaten - Repositories. Er ist die Grundlage für eine Weiterentwicklung und für firmenspezifische Anpassungen. Es genügt folgenden Anforderungen: Abbilden durchgängiger Metadaten über alle Aspekte des DWH-Einsatzes hinweg (technische und fachliche Beschreibungen). Er zeigt die nötige Flexibilität, um alle Informationsarten dokumentieren zu können, d. h. seine Informationsstruktur ist erweiterbar. Es ist leicht beherrschbar. Die bereits bestehende Funktionalität ist einfach realisiert. Die Einarbeitung ist in wenigen Stunden möglich. Das Framework kann mit PL/SQL, SQL und einer APEX-Entwicklungsumgebung weiterentwickelt werden und ist daher extrem offen für eine individuelle Ausgestaltung mit allgemein bekannten Programmiermitteln. Die Metadaten können auch mit anderen Werkzeugen (als APEX) gelesen und geschrieben werden. Die Verwendung der Sourcen und Beispiele ist frei und nicht an Urheberrechte gebunden. Ziel ist vor allem die Hürden eines Repository-Einsatzes im Data Warehouse so gering wie möglich zu halten. Flexibilität entsteht durch Mehr-Schichten-Lösung Das Framework erhält seine Generik durch die Verwendung des klassischen 4- Schichten Repository-Modells, das auch vielen anderen Repositories zugrunde liegt. Diese Vorgehensweise erlaubt die Erstellung/Definition von Beschreibungsstrukturen für beliebige Informationen und deren Zusammenhänge selbst als Modell (Ein Modell definiert ein Modell). Die abgebildeten Informationen lassen sich daher beliebig strukturieren und beschreiben. Das Hinzufügen von Beschreibungstypen (Objekttypen bzw. Metadaten-Typen) ist nur ein administrativer Schritt und benötigt keine Programmierung. 4 Metadaten-Repository Framework Dokumentation V3 MetaMeta-Layer 4 oder Definitionsschicht In einem ersten Schritt (Ebene 4) stellt dieses Framework ein einfaches Tabellen-Schema bereit, um darin die eigentlichen Meta-Modelle (Ebene 3) zu speichern. Ebene 4 ist eine Hilfsschicht, die das Repository die nötige Generik verleiht.1 Meta Modell oder Informationsmodell (Level 3) Auf der Ebene 3 beschreibt man die Metadaten-Typen, über die später auf Ebene 2 die Metadaten erfasst werden können. Auf der Ebene 3 erfasst man z. B. das weiter unten beschriebene Data Warehouse Information Model. Das Data Warehouse Information Model wird als Start-Modell mitgeliefert. An dieser Stelle definiert der Repository-Administrator neue Objekttypen oder Metadaten-Typen. Anwender werden die hier definierten Typen nutzen, um ihre Beschreibungen abzulegen.Die Typen kann man als „leere“ Templates verstehen, aus denen die Anwender durch das Ausfüllen von Webseiten-Formularen konkrete Objekt-Beschreibungen machen. Metadaten-Schicht (Level 2) Auf der Ebene 2 liegen dann die eigentlichen Metadaten, also die Beschreibungen, mit denen die Benutzer arbeiten. Das sind die Namen und Beschreibungen der konkreten Reports, Mappings, Tabellen, Columns usw. eines Data Warehouses. Hier erhält man Listen aller Data WarehouseTabellen aufgegliedert nach ihren Spaltennamen, Listen von allen Kennzahlen, Listen von allen Berichten oder auch Regeln, nach denen die Warehouse-Daten geprüft werden. Zur Terminologie und zum Verständnis Für „Repository“-unerfahrene Anwender kann der Umgang mit den verschiedenen Schichten und der speziellen Repository-Terminologie verwirrend vorkommen. Die Schwierigkeit besteht meist in der Notwendigkeit zwischen konkreten sog. Objekten und deren Beschreibungsmöglichkeiten (Objekttypen) zu unterscheiden. Dabei nutzen wir in unserem IT-Alltag regelmäßig solche Beschreibungen: 1 Weiter unten im Text wird diese Schicht näher beschrieben. 5 Metadaten-Repository Framework Dokumentation V3 Eine Datenbank-Tabelle ist in dem Datenbank-Katalog beschrieben. Hier gibt es Name und z. B. ein Comment-Eintrag. Das sind typische Metadaten-Einträge, die auch in einem Repository so vorkommen. Ein Text-Dokument (z. B. Word-Datei) ist auf einem PC in einer Liste mit seinem Namen, Ablageverzeichnis, Größe und Erstellungsdatum dokumentiert ( z. B. Windows-Explorer). Auch diese Informationen können in einem Repository stehen. Das hier beschriebene Repository erlaubt jedoch im Unterschied zu dem Datenbank-Katalog und dem Windows-Explorer nicht nur die Beschreibung von Objekten wie Tabellen und Text-Dokumenten, sondern zusätzlich noch von beliebig vielen anderen Objektarten (Objekttypen) und das zusammengefasst in einem einzigen System an einer Stelle. Außerdem können diese Objekte in eine Beziehung zueinander gestellt werden (Relationships/Beziehungstypen): Textdokument A beschreibt Tabelle A usw. Die Objekte können zusätzlich attributiert werden (Attribute-Types), z. B. können Tabellen zusätzliche Erläuterungen erhalten wie „Description“, „Definition“, „Notes“, „Freigabedatum“ usw. Objekttypen Zusammenfassung von gleichartigen Objekten. Objekttypen können z. B. sein: BERICHT, TABELLE, ORG-EINHEIT. Objekttypen sind das Strukturierungsmittel für Objekte. Z. B. werden alle Berichte eines Unternehmens unter dem Objekttyp BERICHT angelegt. Objekte Alle zu beschreibenden Informationseinheiten. Objekte sind die Einträge des Repository-Systems. Werden z. B. alle Berichte eines Unternehmens erfasst, dann entsprechen die Eintragungen der Berichte mit ihren Namen den Objekten in dem Repository-System. Objekte werden zu Objekttypen zusammengefasst. Attribute Objekte lassen sich beschreiben. Ein Bericht verfügt z. B. über ein Erstellungsdatum oder einen Autor. Objekttypen unterscheiden sich neben ihrem Namen vor allem durch die Unterschiedlichkeit der ihnen zugeordneten Attribute voneinander. Beziehungstyp Objekte stehen in einer Beziehung zueinander. Ein Bericht beinhaltet z. B. Kennzahlen. Dieser Umstand kann als Beziehung „Bericht enthaelt Kennzahl“ zwischen den beiden Objekttypen BERICHT und KENNZAHL erfasst werden. Diese Art der Beziehung zwischen zwei Objekttypen nennt man Beziehungstyp. Metadaten-Typ Analoge Bezeichnung zu Objekttyp. Metadatenmodell Zusammenfassende Darstellung aller Metadaten-Typen, bzw. Objekttypen. Meist als graphisches Modell. Objekttypen werden mit ihren möglichen Beziehungen (Beziehungstypen) zueinander dargestellt. Das unten vorgestellte Data Warehouse Information Model ist ein Metadatenmodell. Das Prinzip der Eindeutigkeit, Versionen und Varianten Die einmalige Existenz von Objekt-Einträgen in einem Repository gehört zu den Grundprinzipien eines solchen Systems. Denn die wichtigsten Zielsetzungen des Repositories sind: Vermeidung von Redundanzen (inkl. Synonyme und Homonyme) Schnelles Wiederfinden von Informationen, Sachverhalten, Beschreibungen 6 Metadaten-Repository Framework Dokumentation V3 Die Objekte des vorliegenden Frameworks sind über ihre Namen eindeutig. Das bedeutet, dass es nicht gelingen sollte, zwei Objekte mit dem gleichen Namen zu erfassen. Es gibt zwar eine interne Objektnummer, die ebenfalls eindeutig in dem gesamten System ist. Eine solche Nummer ist jedoch für den Benutzer wenig praktikabel, weil sie über das Objekt nichts aussagt. Sollen gleiche Objekte in unterschiedlichen Zusammenhängen genutzt werden, so kann man hierfür Versionen und Varianten nutzen. Hat ein Objekt mehrere Versionen sind sollte nur die letzte Version gültig sein. Mehrere Varianten eines Objektes können jedoch gleichzeitig aktiv bzw. gültig sein. Eine Eindeutigkeit der Objekte ist daher immer nur über die zusammengefassten Eigenschaften: Name Variante Version gegeben. 7 Metadaten-Repository Framework Dokumentation V3 Die technische Umsetzung des Frameworks Beschreibung der Definitionsschicht (Ebene 4) In einem ersten Schritt wird die Möglichkeit gegeben, Objekt-Typen definieren zu können. Z. B. ein Objekt-Typ „KENNZAHL“ besteht aus: Dem Namen des Objekt-Typen: KENNZAHL Der Typ verfügt über mehrere Attribute: “BESCHREIBUNG“, ZULETZT-GEÄNDERT“, usw. Die Möglichkeit Beziehungen zu anderen Objekt-Typen eingehen zu können Definitionstabellen Genutzt werden folgende Tabellen META_OBJECT_TYPES META_RELATIONSHIP_TYPES META_ATTRIBUTE_TYPES META_OT_AT_TYPES Typen META_VARIANTS META_OBJECT_TYPE_GROUPS Gruppen -> Meta Object Type -> Meta Relationship Type -> Meta Attribute Type -> Zuordnungstabelle von Attribut-Typen zu Object -> Definition von Varianten -> Zusammenfassen von Meta_Object_Types zu (Die Namen dieser Tabellen sind so auch in dem jeweiligen Datenbank-Schema zu finden). Über diese Tabellen können die Metadaten-Modelle erfasst werden. D. h. die Eintragungen in diesen Tabellen ergeben die Metadaten-Typen, ihre Attributierung und die möglichen Beziehungen zwischen den Metadaten-Typen. Diese Eintragungen dienen später auch dazu, die semantische Korrektheit der von den Benutzern eingetragenen Metadaten zu überprüfen. Das weiter unten beschriebene Data Warehouse Information Model wird über Eintragungen in diese Tabellen beschrieben. Die Definition der Tabellen der Ebene 4 ist in der Installations-Datei META_MODEL.DDL zu finden2. Die Festlegung der Metadaten-Typen (Ebene 3) Die Definition von Metadaten-Typen entsteht durch Eintragungen in die zuvor beschriebenen Tabellen der Ebene 4. 2 Diese Datei sollte nicht verändert werden, weil sonst einige der Funktionen des Frameworks nicht mehr gegeben sind. Die darin enthaltenen Tabellen kann man sich mit entsprechenden graphischen Tools zur Orientierung anzeigen lassen. Eine solche Graphik ist weiter unten dargestellt. 8 Metadaten-Repository Framework Dokumentation V3 Hier hat man die Möglichkeit alle Informationsarten oder Metadaten-Typen zu beschreiben, die man in seinem Repository benötigt. Will man Berichte dokumentieren, dann definiert man einen MetadatenTypen BERICHT. Will man Kennzahlen dokumentieren, dann definiert man einen Metadaten-Typen KENNZAHL usw. Das sind einfache Eintragungen in den zuvor definierten Tabellen. Die Definition kann entweder über die APEX-Oberfläche erfolgen oder mit Hilfe eines Skriptes. Bei der Vorgehensweise mit einem Skript, kann man den Vorgang in einer dokumentierten Art und Weise wiederholen. Skript-basiertes Erfassen von Metadaten-Typen Zum Erfassen von Metadaten-Typen, ihren Attribut-Typen und den Beziehungen, die sie zu anderen Typen eingehen können, stehen in dem Framework Hilfsfunktionen über eine PL/SQL-Package bereit. META_LOAD_UTL mit den Funktionen Ins_OBJECT_type(p_name,p_description) Ins_RELATIONSHIP_type(p_SRC_OT_NAME, p_TGT_OT_NAME, p_RT_NAME) Ins_ATTRIBUTE_type(p_name,p_description) Für einen funktionierenden Metadaten-Typen sind also diese 3 Definitionen nötig. Beispiel: Es sollen die Typen KENNZAHL und BERICHT definiert werden: begin META_LOAD_UTL.ins_OBJECT_type( p_name=>'KENNZAHL', p_description=>'Objekttyp zum Beschreiben von Kennzahlen'); META_LOAD_UTL.ins_OBJECT_type(p_name=>'BERICHT', p_description=>'Objekttyp zum Beschreiben von Berichten'); Commit; End; Zwischen diesen Typen soll eine Beziehung mit dem Namen „enthaelt“ bestehen. Diese wird definiert: Achtung: Beziehungsnamen sollten eindeutig sein. begin META_LOAD_UTL.ins_RELATIONSHIP_type( p_SRC_OT_NAME=>'BERICHT', p_TGT_OT_NAME=>'KENNZAHL', p_RT_NAME=>'enthaelt'); Commit; end Die Definition von Attribut-Typen erfolgt: begin META_LOAD_UTL.ins_ATTRIBUTE_type( p_name=>'DESCRIPTION',p_DATA_TYPE=>'TEXT' , p_description=>'Beschreiben von Kennzahlen'); Commit; End; Jetzt muss dieses Attribut noch den vorher definierten Metadaten-Typen zuweisen werden. Dazu benötigt man die in dem System gepflegte Objektnummer. Diese erhält man über die Funktion META_LOAD_UTL.get_OT_id Das entsprechende Beispiel lautet dann: declare l_ot_id number; l_at_id1 number; begin l_ot_id := META_LOAD_UTL.get_OT_id ( 'BERICHT' ); 9 Metadaten-Repository Framework Dokumentation V3 l_at_id1 := META_LOAD_UTL.get_AT_id ( ' DESCRIPTION ' ); META_LOAD_UTL.ins_OBJECT_ATTRIBUTE_type( p_ot_id => l_ot_id, p_at_id => l_at_id1 , p_at_no => 1 ); commit; end; Mit dem Framework wird das Data Warehouse Information Model als Start-Set ausgeliefert. Man kann die Definitionsdatei hierzu als weiteres Beispiel verwenden.3 Standardattribute Bestimmte Attribute sollten als Standard-Attribute immer, d. h. für alle Objekttypen vorhanden sein. Solche Attribute sollten grundsätzlich zu allen Metadaten-Typen zugewiesen werden. Sinnvolle Standardattribute sind z. B.: Autor Language Owner DEFINITION … Feste Attribute von allen Objekten Es gibt einige Attribute, die nicht als Attribute-Type definiert werden müssen, weil sie bereits fester Bestandteil von allen Objekt-Definitionen sind4. 3 4 Version Description Note Business_Name External_Reference Time_Created Time_Modified Der Name der Datei lautet Data_Warehouse_Information_Modell_....sql vgl. hierzu auch Tabelle META_OBJECTS 10 Metadaten-Repository Framework Dokumentation V3 11 Erfassen der Metadaten (Level 2) Bis hier hin wurden Vorarbeiten bzw. Definitionen getätigt. Die eigentlichen Metadaten werden jetzt in separaten generischen Tabellen erfasst. Das sind: META_OBJECTS META_ATTRIBUTES META_RELATIONSHIPS Metadaten Objekte (Name und zugehöriger Metadaten-Objekttyp Attribute zu dem Objekt. Es sind nur diejenigen Attributtype-Definitionen möglich, die in der Tabelle MOTMAT für den gewählten MetadatenObjekttyp gültig sind Beziehungen zu anderen Objekten. Es gelten nur die Beziehungen, die in der Tabelle MRT für den Metadaten-Objekttyp definiert wurden. (In den Tabellen sind bereits Columns für Varianten und Versionen aufgenommen. In diesem Framework bleiben diese Spalten ungenutzt. Sie zeigen jedoch die Machbarkeit eines Varianten/Versionen-Konzepts). Die Definition zu diesen Tabellen befindet sich ebenfalls in der Installations-Datei5: META_MODEL.DDL Die Eintragungen in diesen Tabellen folgen zum Teil den weiter oben gemachten Definitionen zu den Metadaten-Typen, Attribut-Typen und Beziehungs-Typen. Die Zusammenhänge sind in dem folgenden Bild dargestellt. 5 An dieser Datei sollten keine Änderungen vorgenommen werden. Metadaten-Repository Framework Dokumentation V3 Zusammenhänge zwischen den Tabellen der Ebene 4 (Objekt-Typ-Definitionen) und den Objekten auf der Ebene 2 In dem Bild sind alle für das Repository benötigten Tabellen dargestellt. Es ist eine überschaubare Anzahl mit wenigen Columns, um die Anforderung der Einfachheit zu erfüllen. Das Datenmodell zu allen Repository-Tabellen mit allen Foreign Key und Primary Keys sieht wie folgt aus: 12 Metadaten-Repository Framework Dokumentation V3 13 Interne Repository-Tabellen Metadaten-Repository Framework Dokumentation V3 14 Das Erfassen der Metadaten kann erfolgen über: Manuelle Inserts Einfache Prozeduren Die APEX-Oberfläche Erfassen über manuelle Inserts An dieser Stelle soll nur beispielhaft gezeigt werden, wie man mit einzelnen Inserts Metadaten erfassen kann, denn einzelne Objekte sind mit der Oberfläche leichter erfassbar. Zur Orientierung ist das oben dargestellte Datenmodell sehr hilfreich. In dem folgenden Beispiel wird: ein Objekt mit dem Namen 'OU_BUCHHALTUNG‘ unter dem Meta-Objekt-Typ ‚ORG_UNIT‘ erfasst. Die Funktion meta_load_utl.getnextnr('meta_objects') liefert eine freie Objektnummer OBJ_ID, die eindeutig sein muss. Version wird auf 1 gesetzt Variante mit VAR1 belegt Es folgt ein zweites Beispiel für das Objekt DU_MEIER mit dem Meta-Objekt-Typ ‚DATA_USER‘ Am Ende werden die beiden definierten Objekte über die Beziehung ‚group_of‘ miteinander verbunden. declare l_Obj_ID l_Ot_ID l_OV_ID l_rt_id begin -- number; number; number; number; l_Obj_ID := meta_load_utl.getnextnr('meta_objects'); l_Ot_ID := meta_load_utl.get_OT_ID('ORG_UNIT'); l_OV_ID := meta_load_utl.get_OV_ID('VAR1'); insert into META_OBJECTS (OBJ_ID,OT_ID,OV_ID,VERSION,NAME,DESCRIPTION,NOTE) VALUES(meta_load_utl.getnextnr('meta_objects'), meta_load_utl.get_OT_ID('ORG_UNIT'), meta_load_utl.get_OV_ID('VAR1'), 1, 'OU_BUCHHALTUNG', 'Beispielfirma', 'Note'); insert into META_OBJECTS (OBJ_ID,OT_ID,OV_ID,VERSION,NAME,DESCRIPTION,NOTE) VALUES(meta_load_utl.getnextnr('meta_objects'), meta_load_utl.get_OT_ID('DATA_USER'), meta_load_utl.get_OV_ID('VAR1'), 1, 'DU_MEIER', 'Dr. Klaus Meier, Würzburg', 'Note'); select rt_id into l_rt_id from meta_relationship_types where name = upper('group_of'); insert into META_RELATIONSHIPS (SRC_OBJ_ID,TGT_OBJ_ID,RT_ID) values (meta_load_utl.get_obj_id('OU_BUCHHALTUNG') , meta_load_utl.get_obj_id('DU_MEIER'), l_rt_id); commit; end; / Metadaten-Repository Framework Dokumentation V3 In den beigefügten Beispieldaten können noch mehr Skripte für die Metadatentypen des DWHInformation-Models eingesehen werden.6 Laden mit einfachen Prozeduren Wenn das Schreiben der INSERT-Skripte für viele Objekte zu aufwendig ist, können kleine PL/SQLProzeduren bei der Erfassung helfen. Dabei ist es manchmal einfacher eine weniger generische Prozedur für einen bestimmten Meta-Objekt-Typen zu erstellen. Denn dann kann man auf die spezifische Attributierung des Typen und seine Beziehungen zu anderen Typen eingehen, bzw. auch leichter Vorbelegungen machen. Im Folgenden ist ein Beispiel für den Typen GLOSSAR mit dem Attribut Definition und der Beziehung 'is_responsible_for' abgedruckt7. -------------------------------------------------------------------------------------------- Name: IN_GLOSSAR -- Typ Prozedur -- Beispiel für eine Objekt-Type-spezifische Prozedur -- hier für Objekt-Type GLOSSAR --- Aufrufparameter: -- p1: Name des neu zu erfassenden Glossar-Objektes -- p2: Definitionstext -- p3: Data_User, der verantwortlich für den Begriff ist ---- Beispielaufruf: exec IN_GLOSSAR('GL_TRANSFORMATION','Wandlung von Informationen','DU_SCHMIDT'); -------------------------------------------------------------------------------------------create or replace PROCEDURE IN_GLOSSAR ( NAME IN VARCHAR2 , DEFINITION VARCHAR2 , DATA_USER VARCHAR2 ) AS l_Obj_ID number; l_Ot_ID number; l_OV_ID number; l_Oat_ID number; l_rt_id number; l_SRC_OBJ_ID number; l_TGT_OBJ_ID number; l_OBJ_Name varchar2(50); l_Definition varchar2(4000); l_time_created date; l_time_modified date; BEGIN l_OBJ_Name := name; l_Definition := DEFINITION; l_Obj_ID := meta_load_utl.getnextnr('meta_objects'); l_Ot_ID := meta_load_utl.get_OT_ID('GLOSSAR'); l_OV_ID := meta_load_utl.get_OV_ID('VAR1'); l_time_created := sysdate; l_time_modified := sysdate; -- Finden der OAT_ID für das Attribut: Definition select OA.OAT_ID into l_oat_ID from META_OT_AT_TYPES OA, META_ATTRIBUTE_TYPES A where A.NAME = 'DEFINITION' and A.AT_ID = OA.AT_ID and OA.OT_ID = l_Ot_ID; dbms_output.put_line(l_oat_ID); -- Objekt schreiben insert into META_OBJECTS (OBJ_ID,OT_ID,OV_ID,VERSION,NAME,DESCRIPTION,TIME_CREATED,TIME_MODIFIED) VALUES(l_obj_ID, l_Ot_ID, l_OV_ID ,1, l_OBJ_Name , 6 7 Unterverzeichnis Daten In Unterverzeichnis Procedures 15 Metadaten-Repository Framework Dokumentation V3 16 l_Definition , l_time_created , l_time_modified ); -- Schreiben Attribut: Definiton insert into META_ATTRIBUTES (OBJ_ID,OAT_ID,DATA_VALUE) values ( l_Obj_ID, l_oat_ID, l_Definition ); -- Einhängen des neuen Objektes in eine Beziehung 'is_responsible_for' select rt_id into l_rt_id from meta_relationship_types l_SRC_OBJ_ID := meta_load_utl.get_obj_id(DATA_USER); l_TGT_OBJ_ID := l_Obj_ID; zum Data_User where name = upper('is_responsible_for'); insert into META_RELATIONSHIPS (SRC_OBJ_ID,TGT_OBJ_ID,RT_ID) values (l_SRC_OBJ_ID , l_TGT_OBJ_ID , l_rt_id); commit; END IN_GLOSSAR; / Eine generische Prozedur zu beliebigen Objekt-Typen ist hier zu finden8 -------------------------------------------------------------------------------------------- Name: IN_GENERAL -- Typ Prozedur -- Beispiel für eine Objekt-Type-spezifische Prozedur -- hier für Objekt-Type GLOSSAR --- Aufrufparameter: -- p1: Name des MetaObjekt_Types -- p2: Name des neu zu erfassenden Glossar-Objektes -- p2: Definitionstext -- p3: Data_User, der verantwortlich für den Begriff ist --- Beispielaufruf: exec IN_GENERAL('KENNZAHL','KZ_Umsatz_Woche','Umsatz stellt den Wert der verkauften Waren und Dienstleistungen pro Woche dar'); -------------------------------------------------------------------------------------------create or replace PROCEDURE IN_GENERAL ( MetaType varchar2 , NAME IN VARCHAR2 , DEFINITION VARCHAR2 ) AS l_Obj_ID number; l_Ot_ID number; l_OV_ID number; l_Oat_ID number; l_rt_id number; l_SRC_OBJ_ID number; l_TGT_OBJ_ID number; l_OBJ_Name varchar2(50); l_Definition varchar2(4000); l_time_created date; l_time_modified date; BEGIN l_OBJ_Name := name; l_Definition := DEFINITION; l_Obj_ID := meta_load_utl.getnextnr('meta_objects'); l_Ot_ID := meta_load_utl.get_OT_ID(MetaType); l_OV_ID := meta_load_utl.get_OV_ID('VAR1'); l_time_created := sysdate; l_time_modified := sysdate; -- Finden der OAT_ID für das Attribut: Definition select OA.OAT_ID into l_oat_ID from META_OT_AT_TYPES OA, META_ATTRIBUTE_TYPES A where A.NAME = 'DEFINITION' and 8 In Unterverzeichnis Procedures Metadaten-Repository Framework Dokumentation V3 A.AT_ID = OA.AT_ID and OA.OT_ID = l_Ot_ID; dbms_output.put_line(l_oat_ID); -- Objekt schreiben insert into META_OBJECTS (OBJ_ID,OT_ID,OV_ID,VERSION,NAME,DESCRIPTION,TIME_CREATED,TIME_MODIFIED) VALUES(l_obj_ID, l_Ot_ID, l_OV_ID ,1, l_OBJ_Name , l_Definition , l_time_created , l_time_modified ); -- Schreiben Attribut: Definiton insert into META_ATTRIBUTES (OBJ_ID,OAT_ID,DATA_VALUE) values ( l_Obj_ID, l_oat_ID, l_Definition ); commit; END IN_GENERAL; / Erfassen von Objekten mit der APEX-Oberfläche Hierzu wählt man in der APEX-Oberfläche den entsprechenden Punkt aus. Die Bedienung hierzu ist weiter unten erklärt. 17 Metadaten-Repository Framework Dokumentation V3 Beschreibung der Repository-Oberfläche mit APEX Start und Aufruf Bei einem fertig eingerichteten APEX-System stehen mehrere Benutzer zum Einwählen zur Verfügung. I. d. R. gibt es neben einem Administrator-Account mehrere Benutzer-Accounts. Die Einrichtung hierzu kann der APEX-Dokumentation entnommen werden. Benutzer-Accounts werden direkt in die Repository-Anwendung geführt, der Administrator gelangt zunächst in die EntwicklerOberfläche. APEX ist eine Web-Anwendung, d. h. die Repository-APEX-Anwendung kann über entsprechende Browser zugegriffen werden. Der Aufruf lautet http://rechnername:8080/apex/ <Rechnername> ist der Name des Servers, auf dem APEX installiert ist. Der Port <8080> kann je nach Art der Installation variieren. Einwahl in Web-Browser Danach wird man aufgefordert, seine Einwahldaten einzugeben. Diese sind zugleich die Zugriffsdaten für das Datenbank-Schema, also letztlich für die Metdaten. Einwahlmaske Es erscheint die Repository-Bedien-Oberfläche. Repository-Auswahl-Tabs Der erste Blick In dem oberen Bereich sind zwei Reiterleisten (Tab-Leisten) zu erkennen. 18 Metadaten-Repository Framework Dokumentation V3 In der oberen kann man wählen zwischen o Arbeiten mit den Metadaten-Einträgen -> Objects o Administrative Tätigkeiten -> Types, Doc Setup, Setup, Log Die untere Reiterleiste verändert ihre Menü-Punkte entsprechend der Auswahl in der oberen Leiste o Objects -> Bearbeiten von konkreten Metadaten (Objekte, Attribute, Relationships, Strukturauflösungen, Auswertungen und Berichte o Types -> Arbeiten auf der Administrationsebene mit der Verwaltung von ObjectTypes, ObjectTypeGroups,AttributeTypes,Relationshiptypes, Variants, Scopes o DocSetup -> Festlegen von Auswerteformaten o Weitere Administrations-Optionen, die hier nicht näher betrachtet werden 19 Metadaten-Repository Framework Dokumentation V3 Objekt-Sichten und Suchstrategien (Für das erste Kennenlernen der Oberfläche ist das Laden des mitgelieferten Data Warehouse Informationsmodells und der zugehörigen Beispieldaten sinnvoll.) Für die Suche nach bestimmten Objekten bieten sich mehrere Suchstrategien an: 9 Suchen über Namen bzw. Namensbestandteilen: wird in den Feldern im Kopfbereich nichts eingetragen, so listet die Darstellung alle Objekte auf. In dem Feld Obj. ist eine Einschränkung z. B. mit Wildcards möglich (Siehe Bild Hilfetext für Suchfelder) Suchen über Object-Typen: Angezeigt werden nur die Objekte des jeweiligen Typen Suche über Scope9: Scopes oder auch Object Type Groups sind eine Zusammenfassung von Object-Typen nach bestimmten Kriterien, z. B. alle Objekt-Typen des Ausschnitts Dimensional Model aus dem Data Warehouse Informationsmodell. Scope wird in künftigen Erweiterungen des Frameworks durch Meta Type Groups ersetzt. 20 Metadaten-Repository Framework Dokumentation V3 Hilfetext für Suchfelder Suche über Strings in Standard-Attributen Hilfetext für Suchfelder 21 Metadaten-Repository Framework Dokumentation V3 Anzeigen einzelner Objekte mit Attributen und Beziehungen Über den Reiter Attributes können Objekte zusammen mit Ihren Attributen angezeigt werden: Anzeige des Objekts R_F_P_Kunde vom Type RULE In dem im Bild gezeigten Beispiel wird das Objekt R_P_F_Kunde gemeinsam mit seinen Attributen angezeigt.. Für jedes Attribut wird eine Zeile verwendet. Über das Bleistift-Symbol der Objekte vor jedem Objekt gelangt man ebenfalls zu einer Komplettdarstellung 22 Metadaten-Repository Framework Dokumentation V3 Detail-Darstellung eines Objektes Änderungen an bestehenden Objekten vornehmen Über die zuvor gezeigte Darstellung kann man auch die Werte der einzelnen Attribute verändern. Hierzu ist auf das Bleistift-Symbol vor den Attribut-Namen zu drücken. Sollen bislang noch nicht genutzte Attribute oder Beziehungen benutzt werden, so startet man einen Erfassungsdialog über das Plus-Symbol . Objekte neu Erfassen Über das grüne Plus-Symbol in dem Objects-Tab kann man neue Objekte erfassen. Einstieg in das Erfassen von neuen Objekten 23 Metadaten-Repository Framework Dokumentation V3 In dem folgenden Erfassungs - Dialog wählt man zunächst in dem rechten Bereich einen Objekt-Typ aus. Danach legt man den Namen fest und speichert den Eintrag ab -> Erfassungs-Dialog für neue Objekte. Hier ist zunächst der Objekt-Typ festzulegen. Anschließend sieht man die möglichen Attribute und Beziehungstypen zu diesem Objekt. Wichtig ist hier die Reihenfolge in der Bedienung, denn erst wenn der Objekt-Type ausgewählt wurde, stehen die möglichen Attribute zu diesem Objekt-Typen fest. D. h. man muss (!) nach dem Festlegen von Typ und Namen des Objektes den Speicher-Button Über die drücken. -Zeichen in dem unteren Bereich können Attribute und Beziehungen erfasst werden. 24 Metadaten-Repository Framework Dokumentation V3 Strukturauflösungen Eine wichtige Funktion ist die zusammenhängende Darstellung von Objekten, die über Beziehungen miteinander verbunden sind. Hierzu gibt es zwei Vorgehensweisen: Einstieg über den Tab Resolution und die Auswahl von Objekt-Typ und Name. Einstieg über den Tab Objects und die kleine Lupe im rechten Bereich in den jeweiligen Listen-Zeilen. Hier wird kurz auf die erste Variante eingegangen. Die zweite Variante erfolgt analog zur ersten. Strukturauflösung / Auswertung über Beziehungen In dem gezeigten Beispiel wurde als Start-Objekt OU_CONTROLLING (Typ ORG_UNIT) gewählt. Auf dem Level 1 gibt es mehrere Beziehungen: Zu DU_MEIER (Data User) über die Beziehung GROUP_OF, die besagt, dass der Data User Mitarbeiter der ORG Unit Controlling ist. Zu den Berichten RE_UMSATZLISTE_MAI und RE_UMSATZLISTE_JUNI über die Beziehung nutzt. Ausgehend von den Berichten findet man über die Beziehung ENTHAELT die Kennzahlen, die in den Berichten angesprochen werden. Will man die so gefundenen Objekte dann näher betrachten und z. B. deren Attributierung bzw. Beschreibungen sehen, so wählt man wieder das Lupen-Symbol . 25 Metadaten-Repository Framework Dokumentation V3 Zusätzliche Generierung von HTML-Berichten zu einzelnen Objekten Das aktuelle Framework verfügt bereits über einen Berichte-Generator, mit dem man Objekte zusammen mit Attributen und Beziehungen zu anderen Objekten als Bericht in einem HTML-Format darstellen kann. Die Berichte-Formate kann man sebst unter dem Auswahlpunkt DocSetup definieren. Ein Beispielformat docTyp1 ist mitausgeliefert. Setup für Berichte-Format. Hier das Beispielformat docType1 Solche Bereichte kann man unter der Detail-Ansicht der einzelnen Objekte ansteuern. 26 Metadaten-Repository Framework Dokumentation V3 Einstieg über die Detailbearbeitung In der Detail-Darstellung befindet sich in dem rechten Bereich unter Special Functions die Möglichkeit ein Report-Format unter DocTyp auszuwählen. Im dargestellen Beispiel ist es docType1. Auswahl des Doc-Formats Die Ausführung erfolgt jetzt über den Export Object Document – Knopf. Starten des Reports Der fertige Bericht sieht dann wie folgt aus: 27 Metadaten-Repository Framework Dokumentation V3 Der fertige Bericht mit Links für die jeweilge Unterobjekt in der Struktur 28 Metadaten-Repository Framework Dokumentation V3 Data Warehouse Information Model Das hier dargestellte Data Warehouse Information Model dient der Beschreibung von Strukturen und Zusammenhängen sowie der Informationen eines Data Warehouse-Systems. Die Erfassung des Modells ist ein guter Praxistest des oben beschriebenen Frameworks-Repository. Das Modell kann ein Ausgangspunkt für ein eigenes firmenspezifisches Informationsmodell sein. Das Repository ist, wie oben beschrieben, entsprechend generisch aufgebaut, um eigene Objekttypen zu erfassen. Graphische Darstellung des Data Warehouse Information Models Das folgende Beispiel-Modell wird exemplarisch erfasst. Die Metadaten-Typen und deren Beziehungen sind in dem Script DWH_Information_Model_load_TYPES_prozedural_.....sql beschrieben und können darüber erstellt werden. : 29 Metadaten-Repository Framework Dokumentation V3 30 Data Warehouse Information Model Metadaten-Repository Framework Dokumentation V3 Die Installation Ausgelieferte Dateien In der aktuellen Version wird eine komprimierte Datei ausgeliefert, die alle Komponenten des Frameworks enthält. Entpackt entstehen folgende Verzeichnisse: Komponenten wie APEX oder die Oracle-Datenbank sind natürlich nicht mit ausgeliefert, weil sie zu den Voraussetzungen des Frameworks gehören. Reihenfolge der Installationsschritte Hier eine Übersicht über die Installationsschritte 1. Voraussetzungen klären a. Oracle Datenbank 11.2 b. APEX 4.0 (entweder „Embedded PL/SQL Gateway“ (EPG) oder mit APEX Listener)10 2. Kopieren aller ausgelieferten Dateien in ein frei wählbares Verzeichnis aus dem heraus SQL Plus aufrufbar ist. 3. Einrichten eines Datenbank-Users (Standard-User) 4. Laden der Repository-Tabellen und Prozeduren (Aufruf von INSTALL-Prozedur) 5. Importieren der APEX-Anwendung aus der APEX-Entwicklungs-Umgebung heraus 6. Importieren der Images für die APEX-Anwendung aus der APEX-Entwicklungs-Umgebung heraus. 7. (Optional aber als Start gut geeignet) Laden des Data Warehouse Information Models 8. (Optional aber sinnvoll für erste schnelle Demos) Laden der Beispieldaten zu dem Data Warehouse Information Model Vorausetzungen für die Installation Installiert werden kann das Framework auf einem Windows-Rechner (ab XP aufwärts) . Zum Installieren benötigt man einen Zugriff auf eine Oracle 11.2 Datenbank-Instanz entweder über SQLPlus oder ähnliche Zugriffstools über das Skripte gestartet werden können. Es muss ein Zugriff auf eine APEX 4.0 – Umgebung bestehen (Browser-Zugriff). Vorausetzungen für den Betrieb des Framworks Ein Repository – Benutzer benötigt später nur einen Browser-Zugriff und die jeweiligen DatenbankZugriffs-Rechte. 10 Siehe hierzu die Kurzanleitung zur Installation von APEX 4.0 am Ende dieses Dokuments 31 Metadaten-Repository Framework Dokumentation V3 Entpacken der ausgelieferten Installationsdatei Die kann mit einem üblichen Komprimierungstool geschehen. Einrichten des Datenbankschemas für das Repository Zur Aufnahme der Repository-Tabellen und Prozeduren ist ein Datenbank-Schema anzulegen. Zum Beispiel: create user md02 identified by md02; Die Rechte entsprechen einem normalen Datenbank-Benutzer, der - Tabellen, Indexe, Views lesen / beschreiben / anlegen darf. - Prozeduren aufrufen darf Installieren der Repository-Tabellen und Prozeduren Im Explorer in das Verzeichnis wechseln, in das die Install-Objekte entpackt wurden. Aufruf des Skripts CD install_Verzeichnis Dann der Aufruf der zentralen installations-Prozedur: @install.sql [Zusätzliche Hilfsprozeduren installieren] (ist bereits in der Prozedr INSTALL enthalten, wenn nicht prüfen) Das sind: Get_rel_komplett_mit _prozeduren.txt In_General.txt In_Glossar.txt In_Rel_General.txt In_Rule.txt Die Dateien sind inline-kommentiert. Das DWH-Informationsmodell laden Eventuell das Data Warehouse Information Model laden. Das kann als erster Startpunkt hilfreich sein. DWH_Information_Model_load_Types…..SQL Die Datei ist inline-kommentiert. Die Beispiel-Daten für das DWH-Informationsmodell laden Damit man sich schnell einen Überblick über das Framework verschaffe kann, sind einige Beispieldaten passend für das DWH-Informationsmodell mit ausgeliefert. Diese befinden sich in dem Verzeichnis Daten Die einzelnen Themenbereiche sind mit führenden Nummern versehen, weil sie aufeinander aufbauend geladen werden müssen. 32 Metadaten-Repository Framework Dokumentation V3 Will man alle Beispieldaten laden, so kann man das Skript starten: Alle_Beispieldaten.sql Die APEX-Bedienoberfläche installieren In einer installierten APEX-Umgebung sind folgende Schritte durchzuführen: 1. Einrichten eines neuen Workspace. Das oben angelegte Datenbank-Schema muss dem Workspace zugewiesen werden. 2. Importieren der APEX-Anwendung f751_METADOC_20110725_0351.sql11 3. Importieren der Images meta_img.sql12 Installation Application Express 4.0 Apex-Installation Diese Kurzanleitung enthält die wichtigsten Schritte zur Installation von APEX 4.0 mit „Embedded PL/SQL Gateway“ (EPG) unter einer Oracle 11.2 Datenbank. Diese Kurzanleitung ist ohne Gewähr – und ersetzt nicht die Durchsicht und das Vorgehen nach dem Installation-Guide für APEX. Die Installation über dieses Embedded Gateway erlaubt einfaches Testen einer APEX-Anwendung auf nur einem Rechner. Soll APEX unternehmensweite von mehreren Rechnern aus zugegriffen werden, so ist mit einem Web-Server bzw. dem APEX Listener zu arbeiten. Die Informationen hierfür müssen aus dem Installationshandbuch entnommen werden. Wird eine Oracle 11.2 Datenbank neu und mit allen Defaults installiert, so ist bzgl. APEX nur noch wenig zu tun, weil die Komponenten für die Kommunikation zwischen der APEX-Anwendung und einem Web-Browser bereits in der Datenbank vorhanden sind. Folgende Schritte sind zu tun: 1. download APEX 4.02 aus OTN http://www.oracle.com/technetwork/developertools/apex/downloads/index.html?ssSourceSiteId=ocomen 2. unzip apex_4.zip in eine Staging Area; im Verzeichnis DOC ist u.a. auch die aktuelle Installations-Doku zu finden. 3. Installation APEX cd {stage-verzeichnis}/apex sqlplus sys/... as sysdba 11 12 Name kann sich ändern Name kann sich ändern 33 Metadaten-Repository Framework Dokumentation V3 @apexins SYSAUX SYSAUX TEMP /i/ (i ist ein Laufwerksname für künftige Einsätze. Er kann einfach i genannt werden) (Dieser Vorgang kann bis zu 10 Minuten und weniger schnellen Rechnern auch länger dauern). 4. Setzen eines Admin-Passwort sqlplus sys/... as sysdba @apxchpwd 5. [Konfiguration des EPG bei Erstinstallation sqlplus sys/... as sysdba @apex_epg_config {stage-verzeichnis} Hinweis: {stage-verzeichnis} ist der komplette Pfad ohne das letzte "/apex". unter Windows funktioniert das evtl. nicht über Laufwerke, die mit dem MS-Win-Explorer als externe Laufwerke angebunden wurden.] 6. Laden der APEX-Images bei Upgrade – falls Schritt 5 nicht benutzt wurde sqlplus sys/... as sysdba @apxldimg {stage-verzeichnis} Hinweis: {stage-verzeichnis} ist der komplette Pfad ohne das letzte "/apex". unter Windows funktioniert das evtl. nicht über Laufwerke, die mit dem MS-Win-Explorer als externe Laufwerke angebunden wurden. Wenn z.B. APEX in dem Verzeichnis D:\APEX installiert wurde, dann lautet der Aufruf: @apxldimg d:\ 7. Freigabe des APEX Nutzungs Account sqlplus sys/... as sysdba ALTER USER ANONYMOUS ACCOUNT UNLOCK; Hinweis: das EPG arbeitet nicht wie der http-Server über den APEX_PUBLIC_USER, sondern mit ANONYMOUS. 8. Setzen des APEX-EPG Ports sqlplus sys/... as sysdba -- prüfen SELECT DBMS_XDB.GETHTTPPORT FROM DUAL; -- setzen EXEC DBMS_XDB.SETHTTPPORT(8080); 9. Prüfen / Setzen von System-Parametern: sqlplus sys/... as sysdba -- prüfen show parameter JOB_QUEUE_PROCESSES show parameter SHARED_SERVERS -- setzen ALTER SYSTEM SET JOB_QUEUE_PROCESSES = 20 SCOPE=BOTH; ALTER SYSTEM SET SHARED_SERVERS = 5 SCOPE=BOTH; 10. nun müsste APEX aus einem lokalen WEB-Browser aufrufbar sein: http://localhost:8080/apex/apex_admin 11. Für den einfachen Zugang vom lokalen Server sind die bisherigen Schritte zunächst ausreichend. Falls das EPG nicht nur vom "localhost" verwendet wird, ist zusätzlich gem. APEX Installation Guide zu verfahren. 34 Metadaten-Repository Framework Dokumentation V3 35 Zulassung von PL/SQL Procedures als URL Function wwv_flow_epg_include_mod_local Um für die APEX-Applikationen zu XUTL benötigte PL/SQL-Prozeduren als URL-Call zuzulassen, muss die folgende Funktion im APEX-Schmea angepasst werden. sqlplus sys/……… as sysdba alter session set current_schema = APEX_040000; create or replace function wwv_flow_epg_include_mod_local ( procedure_name in varchar2 ) return boolean is begin --# return false; -- remove this statement when you modify this function --- Administrator note: the procedure_name input parameter may be in the format: --procedure -schema.procedure -package.procedure -schema.package.procedure --- If the expected input parameter is a procedure name only, the IN list code shown -- below can be modified to itemize the expected procedure names. Otherwise you -- must parse the procedure_name parameter and replace the simple code below with -- code that will evaluate all of the cases listed above. -if substr(upper('.'||procedure_name),instr('.'||procedure_name,'.',-1)) in ('.XUTL_DUMP_APEX_DOWNLOAD','.XUTL_APEX_LOGOUT') then return TRUE; --# --# --# if upper(procedure_name) in ( '') then return TRUE; else return FALSE; end if; end wwv_flow_epg_include_mod_local; / Bei Einsatz von EPG Beim EPG ist genau die soeben beschriebene Funktion im APEX-Owner mit dem Namen der wwv_flow_epg_include_mod_local zu verwenden. Bei Einsatz von HTTP-Server (Apache) Wenn der HTTP-Server (Apache) verwendet wird, ist für die Zulassung von Stored Procedures evtl. eine Funktion unter einem anderen Namen im Einsatz. Dies muss ggf. mit der Konfiguration des „modplsql“ für den HTTP-Server koordiniert werden. Der Config-Parameter zur Definition der Validierungs-Funktion ist: PlsqlRequestValidationFunction my_schema.my_package.my_function wobei die Funktionsparameter der wwv_flow_epg_include_mod_local entsprechen. Die Konfiguration ist in der Regel unter den Pfaden des HTTP-Servers : $HTTPserveHome/Apache/modplsql/conf oder Metadaten-Repository Framework Dokumentation V3 $HTTPserveHome/Apache/Apache/conf zu finden, die häufig verwendeten Konfigurationsfiles dazu sind in der Regel: oracle_apache.conf dads.conf plsql.conf Achtung: bei bestehenden APEX-Installationen ist zuvor zu überprüfen ob diese Funktion bereits geändert wurde und noch zusätzlich andere Prozeduren zuzulassen sind. Der aktuelle Stand lässt sich in etwa wie folgt ermitteln: sqlplus /nolog connect dba/.... col OBJECT_NAME form a30 set pages 1000 set lines 120 select owner,object_name from dba_objects where object_name = 'WWV_FLOW_EPG_INCLUDE_MOD_LOCAL'; select text from dba_source where owner = 'APEX_030200' and name = 'WWV_FLOW_EPG_INCLUDE_MOD_LOCAL' order by line; 36
