Metadaten-Repository Framework - Oracle Data Web viewKomponenten wie APEX oder die Oracle-Datenbank sind natürlich nicht mit ausgeliefert, weil sie zu den Voraussetzungen des Frameworks

Metadaten-Repository Framework Dokumentation V3 1

Metadaten-Repository Framework

Dokumentation

Business Information Cataloguefür das Data Warehouse

Beispielmodell: Data Warehouse Information Model


InhaltMetadaten-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)

Die Methodik eines Repository-Systems

Die Bedeutung von MetadatenMetadaten ü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 RepositoriesMetadaten 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

mailto:[email protected]


Es fehlt eine Übersicht über alle zur Verfügung stehenden Kennzahlen. ….

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 FrameworksDieses Framework zeigt Funktionen und die Machbarkeit eines sehr einfachen aber generisch-flexiblen 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ösungDas 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.


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 Warehouse-Tabellen 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ändnisFü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:

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.

1 Weiter unten im Text wird diese Schicht näher beschrieben.


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

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.


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

DefinitionstabellenGenutzt werden folgende Tabellen

META_OBJECT_TYPES -> Meta Object Type META_RELATIONSHIP_TYPES -> Meta Relationship Type META_ATTRIBUTE_TYPES -> Meta Attribute Type META_OT_AT_TYPES -> Zuordnungstabelle von Attribut-Typen zu Object -

Typen META_VARIANTS -> Definition von Varianten META_OBJECT_TYPE_GROUPS -> Zusammenfassen von Meta_Object_Types zu

Gruppen

(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.

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.


Die Festlegung der Metadaten-Typen (Ebene 3)Die Definition von Metadaten-Typen entsteht durch Eintragungen in die zuvor beschriebenen Tabellen der Ebene 4.

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 Metadaten-Typen 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:

beginMETA_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.

beginMETA_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:

beginMETA_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' );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 ObjektenEs gibt einige Attribute, die nicht als Attribute-Type definiert werden müssen, weil sie bereits fester Bestandteil von allen Objekt-Definitionen sind4.

Version Description Note Business_Name External_Reference Time_Created Time_Modified

3 Der Name der Datei lautet Data_Warehouse_Information_Modell_....sql4 vgl. hierzu auch Tabelle META_OBJECTS


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 Metadaten Objekte (Name und zugehöriger Metadaten-Objekttyp

META_ATTRIBUTES Attribute zu dem Objekt. Es sind nur diejenigen Attributtype-Definitionen möglich, die in der Tabelle MOTMAT für den gewählten Metadaten-Objekttyp gültig sind

META_RELATIONSHIPS 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.


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:


Interne Repository-Tabellen


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 number; l_Ot_ID number; l_OV_ID number; l_rt_id number;

begin-- 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;/

In den beigefügten Beispieldaten können noch mehr Skripte für die Metadatentypen des DWH-Information-Models eingesehen werden.6

6 Unterverzeichnis Daten


Laden mit einfachen Prozeduren

Wenn das Schreiben der INSERT-Skripte für viele Objekte zu aufwendig ist, können kleine PL/SQL-Prozeduren 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 , l_Definition ,

l_time_created , l_time_modified );

-- Schreiben Attribut: Definiton

7 In Unterverzeichnis Procedures


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' zum Data_User

select rt_id into l_rt_id from meta_relationship_types where name = upper('is_responsible_for'); l_SRC_OBJ_ID := meta_load_utl.get_obj_id(DATA_USER); l_TGT_OBJ_ID := l_Obj_ID;

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 A.AT_ID = OA.AT_ID and OA.OT_ID = l_Ot_ID;

dbms_output.put_line(l_oat_ID);

-- Objekt schreiben

8 In Unterverzeichnis Procedures


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.


Beschreibung der Repository-Oberfläche mit APEX

Start und AufrufBei 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 Entwickler-Oberflä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

http://rechnername:8080/apex/


Der erste BlickIn dem oberen Bereich sind zwei Reiterleisten (Tab-Leisten) zu erkennen.

In der oberen kann man wählen zwischen o Arbeiten mit den Metadaten-Einträgen -> Objectso 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


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:

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.

9 Scope wird in künftigen Erweiterungen des Frameworks durch Meta Type Groups ersetzt.


Hilfetext für Suchfelder

Suche über Strings in Standard-Attributen

Hilfetext für Suchfelder


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 vor jedem Objekt gelangt man ebenfalls zu einer Komplettdarstellung der Objekte


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


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 drücken.

Über die -Zeichen in dem unteren Bereich können Attribute und Beziehungen erfasst werden.


StrukturauflösungenEine 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 .


Zusätzliche Generierung von HTML-Berichten zu einzelnen ObjektenDas 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.

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:


Der fertige Bericht mit Links für die jeweilge Unterobjekt in der Struktur


Data Warehouse Information ModelDas 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 ModelsDas 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.

:



Data Warehouse Information Model


Die Installation

Ausgelieferte DateienIn 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 InstallationsschritteHier eine Übersicht über die Installationsschritte

1. Voraussetzungen klären a. Oracle Datenbank 11.2b. 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 heraus6. 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 InstallationInstalliert 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 FramworksEin Repository – Benutzer benötigt später nur einen Browser-Zugriff und die jeweiligen Datenbank-Zugriffs-Rechte.

10 Siehe hierzu die Kurzanleitung zur Installation von APEX 4.0 am Ende dieses Dokuments


Entpacken der ausgelieferten InstallationsdateiDie kann mit einem üblichen Komprimierungstool geschehen.

Einrichten des Datenbankschemas für das RepositoryZur 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.txtIn_Glossar.txtIn_Rel_General.txtIn_Rule.txt

Die Dateien sind inline-kommentiert.

Das DWH-Informationsmodell ladenEventuell 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 ladenDamit 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.


Will man alle Beispieldaten laden, so kann man das Skript starten:

Alle_Beispieldaten.sql

Die APEX-Bedienoberfläche installierenIn 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-Anwendungf751_METADOC_20110725_0351.sql11

3. Importieren der Imagesmeta_img.sql12

Installation Application Express 4.0

Apex-InstallationDiese 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 OTNhttp://www.oracle.com/technetwork/developer-tools/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 APEXcd {stage-verzeichnis}/apexsqlplus sys/... as sysdba@apexins SYSAUX SYSAUX TEMP /i/

11 Name kann sich ändern12 Name kann sich ändern

http://www.oracle.com/technetwork/developer-tools/apex/downloads/index.html?ssSourceSiteId=ocomen

http://www.oracle.com/technetwork/developer-tools/apex/downloads/index.html?ssSourceSiteId=ocomen


(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-Passwortsqlplus sys/... as sysdba@apxchpwd

5. [Konfiguration des EPG bei Erstinstallationsqlplus 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 wurdesqlplus 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 Accountsqlplus sys/... as sysdbaALTER 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üfenSELECT DBMS_XDB.GETHTTPPORT FROM DUAL;-- setzenEXEC DBMS_XDB.SETHTTPPORT(8080);

9. Prüfen / Setzen von System-Parametern:sqlplus sys/... as sysdba-- prüfenshow parameter JOB_QUEUE_PROCESSESshow parameter SHARED_SERVERS-- setzenALTER 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.


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 booleanis 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


$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 /nologconnect dba/....col OBJECT_NAME form a30set pages 1000set lines 120select 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;

Documents

Metadaten-Repository Framework - Oracle Data Web viewKomponenten wie APEX oder die Oracle-Datenbank sind natürlich nicht mit ausgeliefert, weil sie zu den Voraussetzungen des Frameworks