Eine wesentliche Eigenschaft der Virtabs ist die Möglichkeit, Datenmengen der Datenbank durch inhaltliche Kriterien reduziert darzustellen. Dies erleichtert das Schreiben von Anwendungen, und sichert die Datenbank gleichzeitig gegen gewollte oder ungewollte Zerstörungen durch Zugriff von aussen.
Wichtig ist auch hier wieder die Möglichkeit, auf reduzierte Datensätze schreiben zu können, wobei die Virtabs “im Hintergrund” die fehlenden Informationen ergänzen.

Dadurch kann einer Anwendung gegenüber nur der Teil-Datenbestand veröffentlicht werden, den sie wirklich braucht und versteht (Grafik).

Es gibt zwei unterschiedliche Mechanismen:

• das Verbergen von Basistabellen-Spalten
• das Verbergen von Basistabellen-Records

Spalten verbergen mit COLUMN ... INVISIBLE DEFAULT

Natürlich brauchen Spalten zunächst nicht “versteckt” zuwerden, sie werden ja erst bei Bedarf inenrhalb einer Virtab definiert. Manchmal muss aber eine Datenbankspalte mit einem Wert belegt werden, obwohl die Spalte in der Virtab nicht erscheine soll.

Es ist möglich, beliebige Spalten einer Virtab mit Defaultwerten zu belegen, z.B. in Situationen, wo Teile eines zu übergebenden Datensatzes noch unbekannt, aber trotzdem strukturell obligatorisch sind.  Spalten, für die Defaultwerte angegeben wurden, können versteckt werden. Sie sind dann nach aussen hin nicht als Spalten sichtbar, bleiben aber bei Operationen mit der Virtab wirksam. Die Virtab-Prozeduren tragen die Werte unsichtbarer Spalten in die Basistabellen ein.

Unsichtbare Spalten müssen mit konstanten Werten belegt werden, dies geschieht mit der DEFAULT-Anweisung. Wenn mehr Logik in die Virtab implementiert werden soll, kann man mit ONINSERT, ONUPDATE und ONDELETE arbeiten.

Records verbergen mit CONSTRAINT

Zur Definition einer Virtab kann neben der Auswahl von Spalten aus der Datenbank auch die Auswahl der in die Virtab aufzunehmenden Zeilen (= Datensätze) gehören. Dies geschieht über die CONSTRAINT-Bedingungen.

• Bei der Abfrage werden nur Zeilen geliefert, die allen Constraints genügen.
• Es können nur Zeilen in eine gegebenen Virtab eingefügt werden, die den Constraints genügen.
• Ebenso müssen die Tupel, die mit update/delete behandelt werden sollen, allen Constraints genügen.

Eine Basis-Virtab kann mit dieser Funktionalität z.B. durch zwei sich wechselseitig ausschließende Constraints in zwei inhaltlich disjunkte Virtabs geteilt werden, die dennoch auf die gleichen Datenbank-Spalten zugreifen.

Beispiel: Angenommen, es wurde eine Virtab “depts” erzeugt, die die Beschreibungen von Geschäftstellen und Abteilungen mit deren Adressen zusammenfasst (siehe Beispiel). Es sei aber wünschenswert, für verschiedene Bearbeiter die Daten verschiedener Geschäftsstellen als logisch getrennte Virtabs darzustellen. Dazu wird die Virtab “depts” unter verschiedenen Namen mehrfach angelegt, die einzelnen Definitionen unterscheiden sich nur in ihren CONSTRAINTs.

In Pseudocode:

1. CREATE VIRTUALTABLE depts_NewYork
         ....
         Definitionscode von DEPTS
         ....
   CONSTRAINT regional_group = 'New York' ;

2. CREATE VIRTUALTABLE depts_Boston
         ....
         Definitionscode von DEPTS
         ....
   CONSTRAINT regional_group = 'Boston' ;

So werden mehrere schnittmengenfreie Untergruppen von “depts” beschrieben, die datenbanktechnisch in sich konsistent sind.

INVISIBLE ergänzt CONSTRAINT

Unter pragmatischen Gesichtspunkten wird es oft nahe liegen, CONSTRAINT-Anweisungen mit DEFAULT oder auch INVISIBLE DEFAULT zu verbinden. Denn wenn der Zweck einer Virtab gerade die Einschränkung der bearbeitbaren Datensätze ist, sollten die Kriterien der Einschränkung nicht nur überwacht, sondern bereits von der Virtab selbst vorgegeben werden. Das einschränkende Kriterium kann dann zusätzlich auch noch versteckt werden (INVISIBLE).

3. CREATE VIRTUALTABLE depts_Dallas
         ....
         Definitionscode von DEPTS
         ....
   COLUMN regional_group ... INVISIBLE
         ....
CONSTRAINT DEFAULT regional_group = 'Dallas' ;