Über die bereits geschilderten Grundfunktionen hinaus haben die Virtabs folgende erweiterte Eigenschaften:

Kapselung der Schlüsselstruktur

Virtabs sind Datenbankobjekte, die wie Views verschiedene Tabellen über 1:n-Schlüssel verbinden, sich ansonsten aber wie reguläre Tabellen präsentieren. Die Mechanismen der Tabellenverknüpfung über Primärschlüssel-Fremdschlüssel-Paare werden dabei vollständig gekapselt.
Schon am Beispiel der Virtab depts wird deutlich, dass die numerische, technische Schlüsselreferenzstruktur, die aus Primär- und Fremdschlüsseln gebildet wird, von einer Virtab vollständig verborgen werden kann. Beim Zugriff auf die Datenbank über eine durch eine Virtab gebildete Sicht sind nur noch anwendungsbezogene, inhaltlich Bedeutung tragende Zweitschlüssel (im Beispiel regional_group und name) relevant, nicht aber die für das RDBMS optimalen numerischen Primärschlüssel (im Beispiel location_id, department_id und address_id). Die mehr technischen Aspekte des ER-Diagramms (Implementierung der Schlüsselstruktur) werden also von den Virtabs gekapselt.

Zweitschlüssel (Attribut “IDENTIFYING”)

Mehrere Spalten einer Tabelle können gemeinsam als Zweitschlüssel markiert werden, Virtab-Records sind dann auch über eine Kombination von Werten für diese Spalten lokalisierbar. Eine konkrete Virtab muss aber nicht alle IDENTIFYING-Felder jeder Basistabelle enthalten: die Virtab-Prozeduren prüfen zur Laufzeit, ob die Records in den Basistabellen mit den angegeben Spalten eindeutig lokalisiert werden können. Zweitschlüssel können bei UPDATE allerdings nicht geändert werden, wenn kein Primärschlüssel verwendet wird.

Schreibgeschützte Basistabellen (NOCHANGE)

Grundsätzlich kann über eine Virtab eine beliebige Menge von miteinander über Schlüsselverweise verknüpften Tabellen manipuliert werden. Es ist aber sinnvoll und auch möglich, innerhalb einer Virtab eine Menge von Tabellen anzugeben, die nicht verändert werden dürfen (z.B. reine Stammdaten). Sind alle Tabellen in einer Virtab schreibgeschützt, hat die Virtab nur noch die Funktionalität der klassischen View.
Mit depts _2 (vgl. 5.2.3) wird die Ausgangsfunktionalität von depts dahingehend eingeschränkt, dass mit dieser Virtab nur noch neue Abteilungen, nicht aber Geschäftsstellen angelegt bzw. modifiziert werden können.

Änderungszwang für Basistabellen (MUSTCHANGE)

Es ist möglich, innerhalb einer Virtab diejenigen Datenbanktabellen zu spezifizieren, die bei einer per Virtab ausgeführten Einfüge- oder Löschoperation geändert werden müssen, indem in diese Tabellen neue Records geschrieben oder existierende gelöscht werden können müssen. Das Standardverhalten der Virtabs gewährleistet dagegen dieses Verhalten nicht, weil es ausreicht, irgendwelche Datenbankinhalte, die von der Virtab angesprochen werden, einzufügen oder zu löschen. Der Versuch des Einfügens eines bereits komplett in der Datenbank vorliegenden Virtab-Records führt z.B. zur stillschweigenden Ignorierung dieser Operation, wenn nicht bestimmte Tabellen in der Virtab-Definition als MUSTCHANGE qualifiziert sind. Beim Löschen wird im Normalfall nicht das Löschen des gesamten Virtab-Records als erfolgreiche Ausführung der Operation gewertet, sondern bereits das erfolgreiche Löschen eines einzigen beteiligten Datenbankattributs. Über die MUSTCHANGE-Qualifizierung von Datenbanktabellen in einer Virtab erhält der Benutzer die Gewähr, dass er entsprechende Fehlermeldungen erhält, wenn die Operationen nicht entsprechend ausführbar sind.

Vorbelegen von Virtab-Spalten mit Werten (DEFAULT)

Für beliebige Spalten einer Virtab können mit Defaultwerten belegt werden. Dies können Konstanten, aber auch der Inhalt einer anderen Virtab-Spalte sein. Der Default wird verwendet, wenn bei einem schreibenden Zugriff ein NULL-Wert für die betreffende Spalte gesetzt ist. Mit depts_3 (vgl. 5.2.5) ist eine modifizierte Virtab definiert, die die Spalte regional_group automatisch mit 'New York' vorgibt. Im Unterschied zum Beispiel 6 ist es hier jedoch möglich, andere Werte als 'New York' zu übergeben bzw. abzufragen.
Das Schlüsselwort VALUE wirkt wie DEFAULT, es setzt aber die betreffende Virtab-Spalte auf jeden Fall auf den angegeben Wert.

Verstecken von vorbelegten Virtab-Spalten (INVISIBLE DEFAULT)

Spalten, für die Defaultwerte angegeben wurden, können zusätzlich versteckt werden. Sie sind dann nach außen hin nicht als Spalten sichtbar, bleiben aber bei Operationen mit der Virtab wirksam (vgl. 5.2.6). Die Datenbank wird also “unsichtbar” über die Virtab mit konstanten Werten belegt.

Ausdrücke als Virtab-Spalten (COLUMN CALCULATES)

Normalerweise ermöglicht eine Spalte einer Virtab den direkten Zugriff auf eine Spalte einer Basistabelle. Es können aber auch Virtab-Spalten definiert werden, die bei Abfragen das Ergebnis bestimmter SQL-Ausdrücke liefern (“calculated columns”). Bei INSERT-, UPDATE- und DELETE-Operationen werden Werte in diese Spalten dann ignoriert.

“Synthetische” Virtab-Spalten

Als Erweiterung von berechneten Spalten (CALCULATES) sind synthetische Virtab-Spalten ebenfalls unabhängig von den Basistabellen, zusätzlich können aber auch Schreibzugriffe auf diese Spalten ausgewertet werden. Dies geschieht, in dem bei der Abfrage mit SELECT und beim Schreiben mit INSERT, UPDATE und DELETE jeweils bestimmte stored procedures aufgerufen werden, die dann beliebiges Verhalten der Spalte implemenetiren können. Die Schreib/Lese-Konsistenz  sollte allerdings bewahrt werden. Die zugehörigen Schlüsselworte sind ONGET, ONINSERT, ONUPDATE und ONDELETE.

Prüfbedingungen (CONSTRAINT)

Da Virtabs tabellenübergreifende Objekte sind, lassen sich auch tabellenübergreifende Prüfbedingungen (Constraints) definieren. Constraints können beliebige SQL-Ausdrücke sein, die verschiedene Virtabspalten miteinander verknüpfen. Diese sind so implementiert, dass in einer Virtab bestimmte Bedingungen zwischen den Datenspalten bei jedem Prozeduraufruf eingehalten werden müssen, und die entsprechende View auch nur Datensätze liefert, die diesen Bedingungen entsprechen.
Das depts-Beispiel könnte zur zusätzlichen Virtab depts_5 modifiziert werden, die die Spalte regional_group automatisch zwingend mit 'New York' oder 'Boston' vorgibt (vgl. 5.2.7). Alle Operationen auf depts_5 würden dann immer nur solche Spalten aus department betreffen, deren locatation_id auf regional_group = 'New York' bzw. 'Boston' zeigt. Es findet also eine explizite thematische Vorauswahl statt.
Prüfbedingungen können auch mit (versteckten) Vorbelegungen kombiniert werden (vgl. 5.2.8).
 

Virtabs sind damit generell in der Lage, nicht nur bestimmte Spalten verschiedener Datenbanktabellen, sondern auch bestimmte Zeilen dieser Tabellen als neue, virtuelle Tabellen zu präsentieren. Virtab-Constraints garantieren dabei jedoch nur die Schreib- und Lesekonsistenz bzgl. jeweils einer Virtab, sie stellen keine RDBMS-Constraints dar. So dürfen z.B. die Vorbelegungen von Spalten die RDBMS-Constraints nicht verletzen.

Eine Besonderheit stellen Eindeutigkeits-Constraints (UNIQUE CONSTRAINTS) dar: Bei diesen wird nicht der aktuelle Datensatz geprüft, sondern es wird kontrolliert, ob alle Datensätze der Virtab-View hinsichtlich bestimmter Schlüsselfelder unterscheidliche Werte haben.

Mehrfach-Zugriff auf Tabellen (QUERY)

In einer Virtab ist es möglich, gleichzeitig mehrere Datensätze aus einer Tabelle in die interne Verknüpfungsstruktur einzubetten. Dies geschieht über den Mechanismus, dass innerhalb der Virtab für jede dieser multiplen Auswahlen eine gesonderte Abfrage (Query) definiert wird. Alle einzelnen Virtab-Queries müssen dabei aber durch eine Query verbunden sein, die Elemente jeder Teilquery beinhaltet.
Diese Funktionalität wird durch die Virtab letter_data (siehe 5.2.9) veranschaulicht, die man z.B. für die Ausgabe eines Briefkopfs mit Absender- und Empfängerdaten auf Basis einer Datenbankabfrage einsetzen könnte. Dies bedeutet zwangsläufig einen doppelten Zugriff auf address.
Sie benutzt im Kern die Tabellen der Angestellten (employee) und Kunden (customer), die beide auf (verschiedene) Einträge in address verweisen.
Diese Möglichkeit zum Mehrfachzugriff hat eine interessante Konsequenz: Informationen, die in mehreren Zeilen einer Datenbank-Tabelle stehen, können der Anwendung gegenüber als mehrere Spalten eines Datensatzes einer Virtab präsentiert werden.

Explizite Auswahl der Schlüsselstruktur zwischen Basistabellen (FOREIGNKEY / NOFOREIGNKEYS)

Im Normalfall erkennt die Virtab-Implementierung selbständig die Schlüsselstruktur, die nötig ist, um die Einträge aller in einer Virtab angesprochenen Tabellen eindeutig miteinander zu verbinden. Diese Automatik kann jedoch manuell beeinflusst werden. Bei komplexen Datenstrukturen und komplizierten Virtab-Anforderungen muss diese Funktionalität benutzt werden.
Diese Funktionalität wird ebenfalls in 5.2.9 dargestellt. Die FOREIGNKEY-Anweisung legt fest, welche Fremdschlüssel (ggf. welcher Teil-Query) in einer Virtab dazu benutzt werden sollen, Detail-Informationen zuzuordnen. Mit NOFOREIGNKEYS wird ausgedrückt, dass dem betreffenden (Teil-)Datensatz keine Detail-Informationen zugeordnet werden sollen, er also in der Virtab das Blatt eines Hierarchie-Teilbaumes darstellt (vgl. 5.2.10).

Rekursives Löschen

Das RDBMS beherrscht in der Regel eine Operation wie 'delete ... cascade', die alle Detaildatensätze eines zu löschenden Masterdatensatzes löscht. Die Delete-Prozedur der Virtabs implementiert das umgekehrte Verhalten: Ein Masterdatensatz kann erst (optional) gelöscht werden, wenn sein letzter Detaildatensatz gelöscht werden konnte.

“Optionale” Basistabellen (OPTIONAL)

Das Konzept der “optionalen” Basistabelle erweitert den Mechanismus des “OUTER JOIN” des SELECT-Statements auf die Schreibfähigkeiten der Virtabs.
Normalerweise muss in jeder Basistabelle der Virtab ein Record vorhanden sein. Andernfalls kann der Virtab-Record von der View nicht angezeigt werden, und die Lokalisierung bei UPDATE und DELETE schlägt fehl.
“Optionale” Basistabellen sind Datenbank-Tabellen, bei denen Records fehlen dürfen, ohne das die Virtab dies als Fehler wertet.
In der erzeugte Viewdefinition werden für solche Tabellen OUTER JOINS eingebaut, die Virtab-Prozeduren behandeln diesen Fall mit besonderer Logik.

Hints

Es kann nötig werden, die Performance der Virtab-View manuell zu beschleunigen. Zu diesem Zweck können mit der HINT-Anweisung Optimierungsregeln für die Virtab-View eingestellt werden.
Mit TABLEORDER kann eine bestimmte Tabellen-Reihenfolge in der FROM-Klausel der Virtab-View erzwungen werden.
Mit “TABLEORDER FOR <tablename>” kann eine Tabellenreihenfolge eingestellt werden, die mit <tablename> beginnt und dann nach den Master-Detail-Beziehungen ist. Dies ist die optimale Reihenfolge, wenn die Virtab-View beim SELECT-WHERE durch Spalten von <tablename> eingeschränkt wird.

Freie Views definieren mit VIRTUALTABLE CALCULATES

Manchmal ist es nötig, eine beliebige SQL-View als Virtab zu deklarieren (zum Beispiel, wenn die View aus einer Virtab abgeleitet wurde, oder um sie über ER2SQL erzeugen zu können).
Eine solche SQL-View wird mit VIRTUALTABLE <virtabname> CALCULATES <select-statement> definiert. Ein so erzeugte Virtab ist immer NOCHANGE, Prozeduren und Trigger werden für sie nie erzeugt.
Um für verschiedene Datenbanktypen verschiedenes SQL anzugegben, kann man die erweiterte Syntax “CALCULATES <dbcode>” benutzen.

Projektspezifische Features

In ER2SQL sind für spezielle Projekte individuelle Varianten der Code-Erzeugung eingebaut. Diese projektspezifischen Funktionen werden in den SQL-Code eingebaut, wenn für die Virtab ein “FEATURE <featurename>” definiert wurde.
Derzeit ist z.B. eine Zugriffsverwaltung als Teil der Virtab-Definitionen derart aktivierbar.

Vererben von Virtab-Eigenschaften

Häufig ist es nötig, ähnliche Virtabs mit leicht verschiedenen Eigenschaften zu konstruieren (Varianten mit und ohne Primärschlüssel für Basistabellen, mit und ohne bestimtme Basistabellen-Spalten, eine vorhandene Virtab um noch eine Basistabelle erweitern).
Mit dem Schlüsselwort MODIFIES kann eine Virtab von einer anderen Virtab abgeleitet werden. Mit der Anweisung USES kann die Basistabellen-Struktur einer oder mehrerer anderen Virtab in eine neue Virtab eingebaut werden.
In beiden Fällen brauchen dann nur noch die Unterschiede zu den derart benutzten Basis-Virtabs definiert zu werden. Ausgetestetete Basis-Virtabs können so in anderer Virtabs “eingesetzt” werden, was den Entwicklungsprozess beschleunigt.
Spalten aus Basis-Virtabs, die in abgeleiteten Virtabs unsichtbar sein sollen, werden mit dem Attribut PRIVATE gekennzeichnet.
Durch den Vererbungs-Mechanismus lassen sich Virtab-Hierarchien aufbauen, die den Klassenhierarchien aus objektorientierten Programmiersprachen entsprechen. Die USES Anweisung ermöglicht dabei Mehrfachvererbung, wie in C++.

Virtabs als Basis-Tabellen: “VR-Diagramm”

Ein weiterer Weg, Virtabs auf anderen Virtabs aufzubauen, ist der, alle definierten Virtabs als reguläre Basistabellen der benutzten Datenbank zu deklarieren (“Option “autovr”). Nach der Verarbeitung einer Virtab durch ER2SQl wird diese dann der Datenbankbeschreibung hinzugefügt und kann von nachfolgenden Virtabs benutzt werden.
Diese Virtabs werden dann (konsequenterweise) in einem “virtuellen ER-Diagramm” (“VR-Diagramm”) untereinander verknüpft. Primär-, Zweit- und Fremdschlüssel werden ausdrücklich neu definiert, sodass ein Cluster von Virtabs de fakto eine neue Datenbankdefinition bildet.

Gegenseitige Beeinflussungen verschiedener Virtabs

Da Virtabs naturgemäß denormalisierte Objekte sind (d.h. Daten applikationsspezifisch gebündelt repräsentieren), sind bestimmte Datenfelder der Ursprungsdatenbank in der Regel immer über diverse Virtabs zugreifbar. Beim Entwurf und der Nutzung der Virtabs muss daher ständig auf die Nutzung oder Vermeidung von 'Seiteneffekten', d.h. auf den Einfluss von Virtabs einer Applikation auf Daten anderer Applikationen geachtet werden. Die Datenbestände, die von verschiedenen Virtabs einer Datenbank repräsentiert werden, sind immer potentiell miteinander verknüpft.

Schemata und Rechtekontrolle

Virtabs sind frei bezüglich der verwendeten Datenbankschemata, dadurch kann wie gewohnt mit der User- und Schemastruktur der Datenbank gearbeitet werden.
Im einfachsten Fall werden keine Schemata verwendet, dann liegen die SQL-Objekte (View, Procedures) der Virtab im Schema des DB-Users, der die erzeugten SQL-Skripte ausführt.
Für jede Virtab kann aber das Schema angegeben werden, in dem die zugehörigen SQL-Objekte angelegt werden. Jede Virtab kann ausserdem Datenbanktabellen aus verschiedenen anderen Schemata nutzen. Dadurch lassen sich Schema-übergreifende Virtabs konstruieren. Optional wird für jede Virtab ein PUBLIC SYNONYM erzeugt, für das einer bestimmten Rolle Zugriffsrechte gewährt werden. Hat diese Rolle keinen Zugriff auf das Schema der Virtab-Objekte, ist der Zugriff auf Datenbankinhalte nur noch über Virtabs möglich.

Reports

ER2SQL gibt bei Bedarf verschiedene Reports über die eingelesenen Virtabs aus. Dabei handelt es sich einerseits um eine Übersicht der Virtabs und ihrer Spaltenattribute, andererseits um eine vollständige Darstellung der internen Struktur der Virtabs zu Debugzwecken.