Die TABLE-Anweisung von VIRTUALTABLE

Innerhalb von VIRTUALTABLE beschreibt die TABLE-Anweisung die Eigenschaften einer Datenbank-Basistabelle.

Mit jeder "TABLE"-Anweisung wird eine Tabelle explizit in die Virtab aufgenommen. Dies ist nötig ...

1. Falls die bei "COLUMN" genannten Tabellen keinen über die Schlüsselstruktur zusammenhängenden Graphen bilden (der Verbindungsgraph muss durch Nennung zusätzlicher Tabellen, aus denen aber keine Spalten in der Virtab vorkommen, zusammenhängend gemacht werden)
2. Bei mehrfachen Queries. Dann muss für jede Erwähnung einer Tabelle in einer Query eine Tabellen-Doublette angegeben werden.
3. Wenn es innerhalb des Netzes der Basistabellen nicht eindeutig klar ist, durch welche Schlüssel die Tabellen in Master-Detail-Paaren anzuordnen sind (“FOREIGNKEY”)
4. Wenn bestimmte Tabellen schreibgeschützt werden sollen ("NOCHANGE"), oder andere Attribute gesetzt werden sollen.

Die “TABLE”-Anweisung kann entfallen, falls für eine Tabelle keine besonderen Attribute zu definieren sind, da die COLUMN-Anweisung die benutzte Tabelle ebenfalls implizit definiert.

Syntax:

"TABLE" tablename tabellen_attribute [ "END" ] ]

tabellen_attribute :=
[ "QUERY" querylist  ]
[ "ALIAS" tablealias ]
[ "NOFOREIGNKEYS" ]
[ "FOREIGNKEY" key_or_link [ "," ... ] ]
[ "NOCHANGE" | "MUSTCHANGE" | "MAYCHANGE" ]
[ "OPTIONAL" ]
[ "UPDATEONINSERT" column-list ]

querylist := queryname [ "," ... ]

key_or_link := [ "LINK" ] detailtablealias "." fremdschluessel
           [ "TO" primaerschluessel ]

QUERY, ALIAS

Wird in einer Virtab eine Tabelle mehrfach referenziert, müssen mit “QUERY” und ”ALIAS”  (mehr zu Queries) für jede Erwähnung einer Tabelle in einer Query eine Tabellen-Doublette angegeben werden.
Beispiel:

TABLE mytable QUERY a ALIAS mytable_a
TABLE mytable QUERY b ALIAS mytable_b

legt fest, dass auf “mytable” zweimal verschieden zugegriffen wird, wobei beide Instanzen für Spaltendefinitionen unter verschiedenen Namen (hier "mytable_a" und "mytable_b") angesprochen werden.

TABLE mytable QUERY a, c

legt fest, dass der aktuelle Record von “mytable” zu zwei Querys gleichzeitig gehört, so dass die Queries A und C über einen gemeinsamen Eintrag in”mytable” miteinander verbunden sind.

Mittels "ALIAS" kann für eine Instanz einer Datenbanktabelle ein anderer Name vereinbart werden, unter dem bei "FOREIGNKEY" und "COLUMN"-Anweisungen diese Tabelleninstanz bezeichnet werden kann. Fehlt die "ALIAS"-Anweisung, wird als Alias der Name der Basistabelle benutzt.

FOREIGNKEY, NOFOREIGNKEY

Mit "FOREIGNKEY" werden die Referenzen auf die Tabelle "tablename" ausgewählt, die in das interne Verweisdiagramm der Virtab aufgenommen werden sollen (mehr). Jeder Fremdschlüssel, der auf den Table-record verweisen soll, wird mit einem “key_or_link” angegeben. Normalerweise wird einfach Datenbankspalten in der Form “detailtablealias.fremdschluessel” angegeben. Jeder dieser “fremdschluessel” muss mittels einer LINK-Anweisung als referenzierend markiert worden sein, ansonsten gibt ER2SQL einen Fehler aus.
Bei wilden ad hoc Verknüpfungen über Spalten, die eigentlich keine Fremdschlüssel sind, kann man mit “LINK fremdschluessel TO primaerschluessel” eine Verbindung zwischen einer Detailtabelle und einer beliebigen Spalte (“primaerschluessel”) aus Table tablename herstellen. Diese eingebettete “LINK ...TO”-Anweisung erweitert innerhalb der Virtab die LINK-Anweisungen der Datenbankdefinition.
Durch verschiedene LINK...TO kann ein Fremdschlüssel (versehentlich oder absichtlich) auf mehrere Mastertabellen gerichtet werden. Dies ist nur für NOCHANGE-Virtabs (reine Views) erlaubt.

Die FOREIGNKEY-Angabe ist dann Pflicht, wenn es mehr als eine Fremdschlüsselreferenz auf die Tabelle “tablename” gibt, also auch, wenn alle möglichen Referenzen benutzt werden sollten. Ein Tabelleneintrag wird ggf. durch mehrere Fremdschlüssel gleichzeitig ausgewählt. Welche dies sind, lässt sich aus der erzeugten View-Definition erkennen.

Mit der Angabe "NOFOREIGNKEYS" bleiben alle Referenzen auf die Tabelle "tablename" in der Virtab unberücksichtigt. Die Tabelle wird dadurch zu einer reinen Detailtabelle, auf die innerhalb der Virtab keine Fremdschlüssel mehr zeigen.

NOCHANGE, MUSTCHANGE, MAYCHANGE

Mittels "NOCHANGE" können auch einzelne Tabellen innerhalb einer Virtab schreibgeschützt werden (mehr). “MUSTCHANGE” erzwingt für die entsprechenden Tabellen, dass bei mittels Virtab ausgeführten Einfüge- und Löschoperationen tatsächlich neue Records in diese Tabellen eingefügt oder bestehende aus ihnen gelöscht werden. Bei Verletzung dieser Vorgaben wird ein Laufzeitfehler produziert.
“MAYCHANGE” stellt das Standardverhalten wieder her: Es hängt dann von der Datenlage zum Zeitpunkt einer bestimmten INSERT- oder DELETE-Anweisung ab, ob sich die Recordanzahl in der Basistabelle ändert.

OPTIONAL

Eine oder mehrere Basistabellen dürfen “OPTIONAL” sein. Für diese Tabellen stellt es keinen Lokalisierungsfehler dar, wenn die Virtab-Prozeduren in ihnen keinen Record über die Schlüsselfelder gefinden können. Diese Tabellen sind dann sozusagen mit einem (nicht vorhandenen) “NULL-Record” in der Virtab vertreten.
In die erzeugte View-Definition werden für solche Tabellen OUTER JOIN-Verknüpfungen eingebaut. Die Virtab-Prozeduren behandeln diesen Fall mit besonderer Logik: Falls bei der Lokalisierung kein Record für eine OPTIONAL-Basistabelle gefunden wird, wird kein Laufzeit-Fehler ausgegeben und der Record-Primärschlüsselwert bleibt einfach NULL.

Es gilt folgende Einschränkung: OPTIONAL-Tabellen dürfen keine Detail-Tabellen haben, die nicht auch wieder OPTIONAL sind (sonst würde das Schlüssel-Netz zerreißen).

UPDATEONINSERT

Diese Option erweitert das Verhalten der INSERT-Prozedur.

INSERT legt normalerweise für eine Virtab nicht für jede Basistabelle einen neuen Record an, sondern nur für Tabellen, für die kein den Schlüsselfeldern entsprechender record gefunden wird. Spaltenwerte in schon gefundenen (und nicht neu angelegten) Records werden normalerweise nicht aktualisiert. Das soll sicherstellen, das INSERT nicht auch automatisch ein UPDATE auf manchen Tabellen durchführt, führt aber dazu, dass in manchen Anwendungen ein UPDATE nachträglich veranlasst werden muss.

Mit “UPDATEONINSERT” kann bestimmt werden, das für die angegebene Datenbank-Basistabelle automatisch UPDATE durchgeführt wird, wenn für die Tabelle bei INSERT schon ein record gefunden wird. Dabei werden nur die Tabellenspalten aktualisiert, die in column-list angegeben wurden (column-list ist eine Kommaliste).

END

Mit “END” kann das TABLE-Statement abgeschlossen werden, wenn dies wegen der Syntax des folgenden Befehls nötig werden sollte.