Application-Interfaces
“Application-Interfaces” ist der pauschale Begriff für
Software-Module, die eine Benutzung von Virtabs ermöglichen
oder erleichtern.
Server: Interface-Tabellen (x-Tables)
Dies ist ein völlig überholtes Konzept aus der Zeit, als
ORACLE noch keine INSERT-, UPDATE oder DELETE- Trigger auf
Views zuliess (vor 8.0.3). Um serverseitig eine Virtab wie
eine tabelle ansteuern zu können, wurde eine
“Interface-Tabelle” erzeugt, in der Datensätze manipuliert
werden konnten. Bei diesen Schreibvorgänge wurden mit
Table-Triggern auch die Virtab-Prozeduren aufgerufen. Die
Datensätze exisiterten dannach zweimal: einmal (ungewollt) in
der Interface-Tabelle, und dann wie gewünscht in der
“richtigen” Datenbank.
Dieses Konzept wurde nur in
spezeillen Szenarien eingesetzt, z.B. beim Import von Daten,
wo ausschliesslich INSERT-Anweisungen abgesetzt wurden. Nach
dem Import wurde die Interfacetabelle samt Inhalt komplett
vernichtet, da Daten darin nciht DELETETed werden konnten:
dies hätte sie ja auch wieder aus der echtne Datenbank
entfernt.
Server: View-Trigger
Lange nach Erfindung der Virtabs wurden bei ORACLE (ab
8.0.3) Trigger auf Views erlaubt (“INSTEAD OF”), mit
denen Schreibvorgänge auf Views abgefangen werden können.
Dies ist der natürliche Mechanismus, mit dem ein Schreiben in
eine Virtab-View den Aufruf der Virtab-Prozeduren bewirken
kann. Erst seitdem können Virtabs sowohl serverseitig als
auch von jedem Clienten aus angesteuert werden.
Mit der Option -deftrigger erzeugt er2sqlo den Definitionscode für diese View-Trigger.
Beispiel für den Update-Trigger aus dem Beispiel “depts”:
|
CREATE OR REPLACE TRIGGER tu_DEPTS
INSTEAD OF UPDATE ON VT_DEPTS FOR EACH ROW
BEGIN
pu_DEPTS (:new.REGIONAL_GROUP,:new.DEPARTMENT,:new.STREET,:new.CITY,
:new.STATE,:new.ZIP_CODE ) ;
END ;
/
|
|
Client-Interfaces
Warum muss es überhaupt noch spezielle Client-Interfaces geben, wenn doch serverseitig eine Virab schon als Table gekaspelt wird?
-
Die Kapselung ist nicht 100%ig: Die Datenbankschicht von Borland Delphi ist zum Beispiel so
intelligent, dass sie es bemerkt, wenn eine View statt einer Table angesteuert wird. In diesem Fall
verweigert sie das Absetzen von Insert/Edit/Delete-Anweisungen über ihre Datatsets. Nur direkte
SQL-Ausgabe könnte die Virtab-View schreibend ansteuern.
-
Die Virtab-Prozeduren haben Zusatzfunktionen, die die übergebenen Feldwerte verändern (z.B.
Generieren von Primärschlüsseln, oder Setzen von Default-Werten. Dadurch entspricht der Inhalt
der Client-Recordsets nicht mehr der tatsächlichen Datenlage im Server. Als Folge müsste nach
jeder clientseitigen Datenmanipulation ein “Refresh” durchgeführt werden, was eine zusätzliche
Belastung von Server und Netzwerk darstellen würde.
Application-Interfaces sind spezielle Datasets, die die von der Virtab geänderten Werte sofort
enthalten.
Die Systemarchitekturen sind hier noch einmal grafisch dargestellt:
Client: Delphi
Für Delphi wurden im Laufe der Zeit drei verschiedene Interface-Units benutzt.
Das Interface “Delphi 1” wurde für das alte 16-Bit Delphi 1.0 entwickelt.
Die Interface “Delphi 2” und “Delphi 3” laufen (verwirrender Weise) beide ab Delphi 3.0. “Delphi 2” sollte
nicht verwendet werden. “Delphi 3” stellt Virtabs als visuelle Komponenten dar.
Das Interface “Delphi 3 ODAC” entspricht dem Delphi-Interface 3, setzt aber nicht auf der BDE (Borland
Database Engine) auf, sondern auf dem ODAC-Package, das eine BDE-kompatible Direktansteuerung
von ORACLE-Datenbanken bietet.
Client: Java
Das Interface für Java ist noch ein Prototyp. Es definiert einen Nachfahren für java.sql.ResultSet, basiert
also auf JDBC. Es kann derzeit nur innerhalb von POLARIS verwendet werden. Der Grund für den
Einsatz des Java-Interfaces ist nur Nr 2: automatische Aktualisierung des Recordsets nach
Datenmanipulation.
Varianten der Benutzung von Virtabs in verschiedenen Systemumgebungen
|
Varianten-Alias
|
Anforderung Server
|
Anforderung Client
|
Features
|
ER2SQL-Optionen
|
|
x_table
|
traditionelles View-Konzept, prozedurales SQL, table
trigger
(Oracle7+,
MS SQLServer6+)
|
keine
|
Interface zur Virtab wird über physikalisch
existierende Hilfstabelle gebildet
Das Resultat
ist doppelte Datenhaltung!
Delphi-unabhängig, Zugriff über Table-Objekt der
eingesetzten Umgebung
|
-defview
-defprocs
-deftable
|
|
Stored Procs
|
traditionelles View-Konzept, prozedurales SQL
(Oracle7+,
MS SQLServer6+)
|
Interface zu serverseitigen
stored procedures
|
direkte Benutzung der VT-View und ihrer Prozeduren,
keine Simulation einer tabellenartigen Komponente
(VirTab ist kein Objekt)
|
-defview
-defprocs
|
|
Delphi1
|
wie oben
|
Delphi1.0 C/S
(BDE ohne cache),
modifizierte
Delphi-Unit db.pas
|
tabellenähnliche Komponente, damit
DataSet-spezifische Zugriffe möglich
(Virtab ist Objekt TVirtabT/Q, aber keine visuelle
Komponente)
|
-defview
-defprocs
-delphi
|
|
Delphi3
|
wie oben
|
Delphi3.0 C/S
(cachende BDE /
UpdateSQL-Komponente)
Kein Support für BDE ab
Delphi 7!
|
kein modifiziertes db.pas
(Virtab ist visuelle Komponente
TVirtabTable/Querydbname)
|
-defview
-defprocs
-dbname
-dbschema
-delphi3
|
|
Delphi3-ODAC
|
wie oben
|
ab Delphi 5, ODAC-Lizenz!
|
(Virtab ist visuelle Komponente
TVirtabTable/Querydbname)
|
-defview
-defprocs
-dbname
-dbschema
-delphi3_odac
|
|
Java
|
wie oben
|
JDBC 2.0
|
Prototyp für POLARIS!
|
-defview
-defprocs-java
|
|
view trigger
|
traditionelles View-Konzept, prozedurales SQL;
Möglichkeit, modifizierende Zugriffe auf Views durch
Trigger abzufangen (Oracle8+)
|
keine
|
Client-unabhängig, Zugriff über Table-Objekt des
eingesetzten Entwicklungswerkzeugs
|
-defview
-defprocs
-deftrigger
|
|
