Aselmeyer_HTMLDB mit HTMLDB ergänzen

HTMLDB mit HTMLDB ergänzen
Nützliche Erweiterungen für den SQL Workshop
Autor(en): Gerhild Aselmeyer, Dipl. Math. – Analysen, Konzpte & Anwendungsentwicklung für EDV
Vorstellung einer HTMLDB-Applikation, welche die
Funktionalitäten von SQL Workshop Object Browser auf
Objekte in Fremddatenbanken – angebunden über
Datenbanklinks – erweitert. Zwar sind noch nicht alle
Informationen, die aus dem Object Browser für die
Objekte der Workspace-Schemata bekannt sind, für die
Remote-Objekte verfügbar, aber die wichtigsten
Funktionen sind realisiert und machen den Entwickler in
HTMLDB (bzw. APEX) unhabhängiger von zusätzlichen
Tools wie SQL*Plus oder TOAD.
• anlegen von Views und Synonymen auf Basis von Objekten über
Datenbanklinks,
• grundlegende Objektbeschreibung von Funktionen, Prozeduren
und Packages,
• alle weiteren Objektinformationen für Tabellen, Views und
Indices außer dem zugehörigen DDL-Statment (CREATE),
• grundlegende Objektbeschreibung aller übrigen Objekte,
• anzeigen des CREATE-Statments für Tabellen, Views und
Indices,
• alle verbleibenden Informationen.
Auf Grund des recht leichten Einstiegs durch die Vielzahl von
Wizards und des umfangreichen SQL Workshops mit der
graphischen Unterstützung für die Generierung von SQL-Statments
eignet sich APEX nicht nur für erfahrene Entwickler und SQLSpezialisten als Entwicklungs-umgebung für Web-Anwendungen,
sondern auch für die schnelle Erstellung von Berichten oder kleinen
Tools für EDV-Fachbetreuer der Fachabteilungen. Allerdings fiel
mir als Schnittstellen- und Integrationspezialistin auf, daß die
Erstellung eines Berichtes über den Status von Bewegungsdaten
zwischen zwei Softwaresystemen zu einem Bruch in APEX führt, da
in den Bewegungsdaten im allgemeinen lediglich numerische Codes
zur Verfügung stehen und die umfangreichen textuellen
Informationen der Stammdaten fehlen, die aber für die Anzeige in
einem Bericht meist sinnvoller sind. Selbst wenn entsprechende
Datenbanklinks zu den Systemdatenbanken existieren, bietet der
SQL Workshop höchstens die Möglichkeit über SQL Commands
oder SQL Scripts entsprechende Recherchen durchzuführen. Hierfür
benötigt man aber schon entsprechendes SQL-Know-How und
detaillierte Kenntnisse bzgl. des Systemkataloges einer Oracle
Datenbank. Daraus entstand die Idee - mir bzw. bei Interesse meinen
Kunden - zur Unterstützung für Projekte, in denen HTMLDB zum
Einsatz kommt, eine entsprechende ‘HTMLDB Add On’-Applikation
zu erstellen.
Nachdem das Konzept stand und die Prioritäten der Entwicklung
festgelegt waren, stellten sich drei Hauptaufgaben heraus:
• zusammenstellen der notwendigen Information aus dem
Datenbanksystemkatalog und erstellen der dynamischen Queries
unter Berücksichtigung älterer Oracle-Versionen (8.x) für
entfernte Datenbanken,
• erstellen von Datenbankfunktionen und –prozeduren zum
Erzeugen von fehlerfreien dynamischen Selektstatements auf
Basis der Information aus den Systemtabellen, um die Daten aus
beliebiegen Tabellen und Views anzuzeigen,
• erstellen von Funktionen und Prozeduren zur Generierung von
DDL-Statments zum Anlegen von Views und Synonymen auf
Basis der Angaben in der Anzeige.
Daß auch die Queries aus dem Systemkatalog als dynamische
Select-Statements realsiert werden müssen, hat folgende Gründe:
DBMS_DESCRIBE.DESCRIBE_PROZEDURE läßt sich nicht für
Remote-Objekte einsetzen und ein Datenbanklink kann nicht als
Bind-Variable in ein Select-Statement eingefügt werden. Daher
haben die Report-Queries für die Objektbeschreibungen alle in etwa
folgendes Aussehen
Entwicklung und erster Einsatz
Vorbereitung
Zunächst habe ich ein grobes Konzept erstellt und festgelegt, welche
Funktionalitäten das Add On umfassen sollte; dabei habe ich mich an
den im Object Browser zur Verfügung gestellten Informationen
orientiert. Allerdings kam ich zu dem Schluß, die Objekt- und
Datenmanipulationen, die dort zur Verfügung stehen, nicht für
Objekte in Fremddatenbanken anzubieten, da dieses leicht zu
Konflikten führen kann. Daher sollen in der kompletten ersten
Aufbaustufe alle Informationsanzeigen wie in APEX für Objekte in
der entfernten Datenbank sowie das Anlegen von Views und
Synonymen im ausgewählten Workspace-Schema auf deren Basis
verfügbar sein.
Für die Realisierung gilt folgender Prioritätenplan:
• grundlegende Objektbeschreibung für Tabellen, Views und
Indices,
• Datenanzeige für Tabellen und Views,
Abbildung 1:APEX-Report basierend auf Systemkatalog der entfernten
Datenbank
Nachdem jetzt die ersten Schwierigkeiten mit den Differenzen im
Systemkatalog überwunden und die Funktionen und Prozeduren
erstellt und weitestgehend getestet sind, stehen die Funktionalitäten
der ersten zwei Punkte bereits zur Verfügung und bringen schon
erheblichen Nutzen. Der einzige Nachteil ist, daß ich keine
Möglichkeit gefunden habe, einen zusätzlichen Link für den direkten
Aufruf der Applikation in APEX zu integrieren, damit auf ein
separates Login verzichtet werden kann.
Aber diesen Nachteil nehme ich gern in Kauf, denn jetzt habe ich bei
der Entwicklung alles übersichtlich in einem Fenster .
Abbildung 2:Entwicklung mit APEX in einem Tab-fähigen Browser
Ohne die Entwicklungsumgebung von HTMLDB vollständig zu
verlassen, lassen sich die Objektbeschreibungen für
Tabellen, ...
Abbildung 3: Objektbeschreibung Tabelle
Views ...
und Indices ...
Abbildung 5: Objektbeschreibung Index
ansehen.
Ebenso stehen die Daten in Tabellen und Views jeder Zeit zur
Verfügung.
Abbildung 6: Daten in der Tabelle AQ$_QUEUE_TABLES einer Oracle 8
Datenbank
Nach Abschluß der Tests für das Anlegen von Views und
Synonymen sind die drei entscheidenden Punkte der Add On
Entwicklung erledigt.
Abbildung 4: Objektbeschreibung View
Abbildung 7:Anlegen von Views und Synonymen basierend auf Objekten
einer entfernten Oracle-Datenbank
Inzwischen ist die Entwicklung vollständig abgeschlossen –
allerdings etwas später als zunächst geplant. Dieses hatte zwei
Gründe:
1.
Query bei Datenanzeige
Um die Anwendung auch ohne ‘Vier-Augen-Prinziep’ ausgiebig zu
testen, hatte ich die Realisierungsreihenfolge der Funktionen so
gewählt, daß ich die bereits abgeschlossenen Funktionen während
der weiteren Entwicklung einsetzen und damit aus Anwendersicht
testen konnte. Dabei fiel mir auf, daß ich eine Zusatzfunktion ohne
Auswirkungen auf Daten und Struktur bei der Datenanzeige nicht
mit in mein Konzept aufgenommen hatte, da diese auf derselben
Ebene im SQL-Workshop zur Verfügung steht wie die
Änderungsfunktionen (s. oben unter Vorbereitung) – die Eingabe
von Einschränkungen für die Anzeige von Tabellen- und
Viewinhalten. Da mir diese Funktion während meiner Arbeit aber
ständig fehlte, habe ich das Konzept ergänzt und die Realisierung
noch vor ‘alle(n) weiteren Objektinformationen für Tabellen, Views
und Indices ...’ eingeschoben.
Jetzt kann man wie im SQL-Workshop die Inhaltsanzeige einer
Tabelle oder View einschränken, ...
Als die Entwicklung abgeschlossen war und der Abnahmetest
anstand, fehlte noch eine Kleinigkeit – so dachte ich jedenfalls: das
Umsetzen des Parsing Schemas analog zur Auswahlliste, damit die
privaten DB-Links zur Verfügung stehen. Aber hierfür fand ich
keine Funktion und in dem einschlägigen Forum bei Oracle, daß
dieses nicht vorgesehen ist.
Eine Analyse von HTMLDB und dem HTMLDB_PBULIC_USER
ergab, daß
•
das Parsing Schema identisch mit dem Flow-Owner ist,
•
bei jedem Request das Parsing Schema aus der Datenbank
gelesen wird,
•
der Zugriff durch den DAD-User nicht über ein Synonym oder
eine View erfolgt und damit eine Manipulation auf einer
zwischengeschobenen Ebene (z.B. View mit Funktion)
ausgeschlossen ist,
•
der Flow-Owner auf Datenbankebene aus einer Anwendung
heraus geändert werden kann – allerdings mit großer Vorsicht,
um
Auswirkungen
auf
die
Workspace-Zuordnung
auszuschließen.
Daher läßt sich zwar das Parsing Schema zur Laufzeit ändern, aber
mit der Auswirkung, daß es dann für alle Anwender – auch bereits
laufender Sessions – umgesetzt wird. Da dies nicht sinnvoll ist, habe
ich eine administrative Funktion ergänzt, mit der der Flow-Owner
von einem ADMIN-Anwender umgesetzt werden kann.
Abbildung 8: Einschränkungen für Daten-Query angeben
was z.B. die Suche nach geeigneten Testdaten erheblich erleichtert.
Abbildung 10: Umsetzen des Parsing Schemas durch einen Administrator
Allerdings leidet die Anwendung etwas darunter, da diese trotzdem
entweder mehrfach installiert werden muß oder alle Datenbanklinks
PUBLIC deklariert werden müssen, außer denen im eingestellten
Parsing-Schema. Damit aber jeder Nutzer stets darüber informiert
ist, in welchem Parsing-Schema er arbeitet, wird dieses jetzt in
Klammern hinter dem Anwendernamen auf jeder Seite mit
angezeigt.
■ Fazit
Abbildung 9: Eingeschränkte Anzeige aus der ALL_TABLES-View des
Schemas SYS einer Oracle 8 -Datenbank
2.
Kein Wechsel des Parsing Schemas zur Laufzeit
möglich
HTMLDB
(bzw.
APEX)
stellt
eine
hilfreiche
Entwicklungsumgebung dar – nicht nur für professionell Entwickler.
Durch die Wizards und SQL Workshop ist ein Einstieg mit
schnellem Erfolg auch für Anwender mit wenig Oracle
Datenbankerfahrung und SQL Grundkenntnissen möglich.
Noch fehlende Erweiterungen lassen sich mit Hilfe des Tools selbst
ergänzen. Nur zwei Wünsche bleiben offen: Die Möglichkeit eigene
Add Ons in die Applikation so einzubinden, daß die
Authentifizierung übernommen werden kann und die Entkoppelung
von Flow-Owner und Parsing Schema mit der Möglichkeit letzteres
zur Laufzeit umzustellen.
Kontakt:
Gerhild Aselmeyer
[email protected]