Virtabs sind schreibfähige Views:

Wer schon einmal mit relationalen Datenbanken gearbeitet hat, kennt die Begriffe “Tabelle” und “View” (sonst braucht er nicht mehr weiter zu lesen :-).
 “Virtuellen Tabellen” (kurz: “Virtabs”) sind eine neue Schicht im RDBMS: Es handelt sich um Views über mehrere Tabellen hinweg, die aber voll schreibfähig sind: INSERT-, UPDATE, und DELETE-Operationen sind möglich und beinflussen mehr als eine der hinter der View liegenden Tabellen.
Mit Virtabs können neue, anwendungsnahe Datenmodelle geschaffen werden, die die Entwicklung und Pflege von Datenbankanwendungen erleichtern.

Die klassischen RDBMS-Views sind zwar vielseitiger einsetzbar als Virtabs, erlauben aber nur den lesenden Zugriff. Die gängigen Datenbanken unterstützen zwar auch Schreibvorgänge auf Views, aber nur unter strengen Einschränkungen und immer nur auf einer Basistabelle.

Virtabs bilden eine neue Modellierungsebene, die im bekannten Schichtenmodell für Datenbankanwendungen zwischen Applikationslogik und RDBMS-Tabellen angesiedelt ist.

Schichtenmodell ohne Virtabs:

Das klassische Schichtenmodell besteht (abhängig von der Anwendung) typischerweise aus den Schichten Client, middle-tier, und RDBMS, bzw. ER-Diagramm:

Schichtenmodell mit Virtabs:

Die Schicht der “Virtabs” stellt den Anwendungen Pseudotabellen zur Verfügung, die eher der Anwendungslogik entsprechen. Das ursprüngliche ER-Diagramm kann dadurch komplett gekapselt werden:

Technische Realisierung:

Die Virtabs werden in einer eigenen Deklarationssprache definiert (Basistabellen, Spalten, Constraints und andere Eigenschaften). Aus dieser Definition erzeugt der Codegenerator ER2SQL den SQL-Code für die Virtab-View und für drei stored procedures (für INSERT, UPDATE und DELETE). Dieser SQL-Code muss dann im RDBMS übersetzt werden.

Um eine “Virtab” als eigenes Objekt zu etablieren, müssen View und Prozeduren noch zu einer Einheit gebündelt werden. Dies geschieht durch verschiedene Mechanismen:

1. Trigger auf der Virtab-View rufen direkt die entsprechenden Virtab-Prozeduren auf. Man kann also per SQL direkt “INSERT INTO <virtab> .. “ schreiben.
2. Für Java (im middle-tier) erzeugt ER2SQL den Sourcecode einer Interfaceklasse, die die Virtab als JDBC-ResultSet darstellt.
3. Für Borland Delphi erzeugt ER2SQL den Sourcecode einer Interfaceklasse, die die Virtab als TDataSet verwendbar macht.

Einsatzmöglichkeiten:

Für den Einsatz von Virtabs gibt es verschiedene Gründe:

Konzeptuell: Sie können bereits bei der Datenmodellierung eingesetzt werden. Dies bietet sich an, wenn auf einem einheitlichen abstrakten Datenmodell verschiedene Benutzeroberflächen aufgesetzt werden sollen, die den Endnutzern verschiedene konkrete Datenmengen präsentieren sollen, die im RDBMs so nicht abgelegt werden sollen.

Als Tool: Sie können als Entwicklungs-Werkzeug eingesetzt werden. Da Virtabs die Anwendungslogik von der Datenbank trennen, kann die Datenbank auch zu späten Zeitpunkten noch modifiziert werden. Änderungen schlagen sich dann nur in den Virtabdefinitionen nieder, die darauf aufbauenden Anwendungen müssen nicht geändert werden. Da der Virtab-SQL -Code automatisch erzeugt wird, ist er sehr zuverlässig und muß nicht ständig neu debugged werden..

Das Virtab-System habe ich für ORACLE entwickelt. Es gab auch mal eine Version für Microsoft-SQLServer, die aber nicht weitergepflegt wird.

Virtabs wurden bereits erfolgreich in den beiden großen Datenbankprojekten ECO und POLARIS eingesetzt.

Danksagung:

An dieser Stelle muss ich meinen Kollegen Andreas Schulze von der Niedersächsischen Forstlichen Versuchsanstalt erwähnen. Er hat das “Projekt Virtabs” jahrelang kritisch begleitet und auch an dieser Dokumentation mitgewirkt. Thanks!.