Die COLUMN-Anweisung von VIRTUALTABLE

Innerhalb von VIRTUALTABLE beschreibt die COLUMN-Anweisung eine Spalte der Virtab. Die Spalte kann aus einer Basistabelle stammen, oder berechnet sein. Es können beliebig viele COLUMN-Anweisungen angegeben werden.

Syntax

Form 1:

"COLUMN" virtab_colname
  [ "=" [ tablealias "." ] basetable_colname ]
  [ "DATATYPE" datatype ]
  [ "INVISIBLE" | "VISIBLE" ]
  [ "DEFAULT" sql_expr ]
  [ "VALUE" sql_expr ]
  [ "IDENTIFYING" | "IDENTIFYING" "NULL" | "NOTIDENTIFYING" ]
  [ "VIRTUAL" "PRIMARYKEY" | "VIRTUAL" "IDENTIFYING" |
     "VIRTUAL" "REFERENCES" virtabname "." virtabcol ]
  [ "ONGET [package "."] getfuncname" ]
  [ "ONINSERT" [package "."] insertprocname ]
  [ "ONUPDATE" [package "."] updateprocname ]
  [ "ONDELETE" [package "."] deleteprocname ]
  [ "PRIVATE"
  [ "FEATURE" feature_name [ feature_argumente ] ]
  [ "FEATURE INFO" feature_name ]
  [ "INFO" text]
  [ "END" ]

Form 2:

"COLUMN" virtab_colname "CALCULATES" sql_expr [ "DATATYPE" datatype ] [ "END" ]
 

virtab_colname

Hier wird der Name der Virtabspalte angegeben, sowie die Spalte der Basistabelle (die unter ihrem ALIAS angesprochen wird), die sie darstellen soll. Wird “tablealias” nicht angegeben, sucht ER2SQL selbst die Basistabelle, das führt zu einem Fehler, wenn mehr als eine Basistabelle eine Spalte “basetable_colname” hat. Wird auch “basetable_colname” weggelassen, wird “basetable_colname”  = “virtab_colname” gesetzt.

DATATYPE

Normalerweise ist der ORACLE Datentyp einer Virtabspalte identisch mit dem Typ der Spalte der Basistabelle. Mit DATATYPE kann ein anderer Typ vereinbart werden, der natürlich mit dem Typ der Basistabellenspalte kompatibel sein muss..
Bei SELECT wird die Spalte der View mit einem CAST() konvertiert, für die INSERT/UPDATE/DELETE-Procedure wird der Typ des entsprechenden Prozedurparameters geändert.

INVISIBLE, VISIBLE

“INVISIBLE” gibt an, das die virtab_spalte nicht Teil der Virtab-View und der Prozedur-Parmeter ist. Trotzdem wird ihr Wert in den Prozeduren verwendet, wenn Basistabellen verändert werden. Daher muss für INVISIBLE-Spalten auch DEFAULT angegeben sein (oder CONSTRAINT DEFAULT). Mit dem Spaltenattribut "INVISIBLE" kann man Spalten, die durch "DEFAULT" auf konstante Werte festgelegt sind, in der View und den INSERT-, UPDATE- oder DELETE-Prozeduren unterdrücken (da ja der Wert der Spalte schon durch die Virtab-Definition festgelegt wird).

“VISIBLE” stellt die Sichtbarkeit wieder her (wenn die Spalte aus einer anderen Virtab unsichtbar geerbt wurde).

DEFAULT, VALUE

Mit diesem Schlüsselworten können einer Virtabspalte Werte zugewiesen werden. Der Wert “sql_expr” wird als Standard-SQL-Ausdruck angegeben

 “DEFAULT” gibt einen Wert an, der eingesetzt wird, wenn der Anwender die Virtabspalte mit NULL belegt. Mit “VALUE” wird die Virtabspalte auf jeden Fall auf den angegeben Wert gesetzt, Anwenderwerte werden so übersteuert.

Eine häufige Anwendungen von DEFAULT sind

• “DEFAULT SYSDATE”, welches die Spalte die Systemzeit des RDBMS setzt,
• “DEFAULT USER”, welches die Spalte auf den Namen des eingeloggten RDBMS-Users setzt
• “DEFAULT another_virtab_colname”, das die Spalte auf den Wert einer anderen Spalte setzt.

sql_expr

An verschiedenen Stellen (DEFAULT, VALUE, CALCULATES, CONSTRAINT) können als Wert SQL-Ausdrücke eingesetzt werden. Dies sind Formeln im SQL-Dialekt des jeweiligen RDBMS, die von ER2SQL nicht verstanden werden und im wesentlichen unverändert in den Code der Virtab-View und der Virtab-Prozeduren übernommen werden. Dadurch bleibt die volle Mächtigkeit dieser Ausdrücke erhalten. Sie können zum Beispiel eigene Unterabfragen mit SELECT oder den Aufruf eigener stored procedures enthalten.
Fehler in “sql_expr” werden erst bei der Übersetzung auf dem RDBMS bemerkt.

Jeder SQL-Ausdruck wird von ER2SQL untersucht, ob er Namen von Virtabspalten (“virtab_colname”) oder Basistabellenspalten (“tablealias.dbcolname”) enthält. Für diese Namen wird ein Zugriff auf die angesprochenen Virtab bzw.Datenbankspalten in den SQL-Ausdruck hineincodiert.
Bekannte Spalten haben also Vorrang gegenüber allen SQL-Schlüsselworten im SQL-Ausdruck!

Aus grammatikalischen Gründen darf ein sqlexpr einige ER2SQL-Schlüsselworte nicht enthalten. Um diese Einschränkung zu umgehen kann man ihn aber in (“...)” Klammern schreiben.

IDENTIFYING

Mit "IDENTIFYING", "IDENTIFYING NULL" bzw. "NOTIDENTIFYING" kann die "IDENTIFYING"-Angabe für Zweitschlüssel, die eigentlich eine Eigenschaft der Basistabellen ist, für die vorliegende Virtab modifiziert werden. Dies ist z. B. sinnvoll, wenn nicht alle Felder eines zusammengesetzten Zweitschlüssels in der Virtab als Schlüssel genutzt werden sollen oder ein Feld in der Virtab als Zweitschlüssel fungieren soll, obwohl es teilweise NULL ist. Diese Angaben übersteuern also die entsprechenden Angaben in der Datenbankdefinition.

VIRTUAL

Mit "VIRTUAL PRIMARYKEY", "VIRTUAL IDENTIFYING" und "VIRTUAL REFERENCES ..." kann die Verknüpfungsstruktur zwischen Virtabs beschrieben werden. Verschiedene Virtabs werden so wieder mit Schlüssel zu einem ER-Diagramms 'höherer Ordnung' (Virtual Relationships) verknüpft. Auf Basis der so verknüpften Virtabs können können weitere Virtabs definiert werden (ER2SQL-Option: -vr). Das Verhalten der so produzierten Virtabs höherer Ordnung, die nicht auf der urprünglichen Datenstruktur, sondern auf anderten Virtabs basieren, ist für schreibende Zugriffe noch nicht verstanden. Der Nutzung für NOCHANGE-Virtabs steht nichts im Wege (mehr dazu).

CALCULATES

Mit diesem Schlüsselwort wird eine Virtab-Spalte definiert, die nicht auf die Spalte einer Basistabelle zugreift, sondern stattdessen einen beliebigen SQL-Ausdruck berechnet. Für sql_expr gelten die üblichen Regeln.

Berechnete Spalten haben nur für den lesenden Zugriff in der Virtab-View eine Funktion. In den Virtab-Prozeduren werden zwar aus Konsistenzgründen auch für berechnete Spalten Übergabe-Parameter definiert, dies sind aber funktionslose Platzhalter.

Mit “DATATYPE” kann ein Basisdatentyp für den Ausdruckswert angeben werden.
Wenn DATATYPE fehlt, werden folgende Datentypen verwendet:

• In der Virtab-View bestimmt ORACLE willkührlich einen Datentyp, abhängig vom SQL-Ausdruck. Dieser ist manchmal nur schwer vorherzusagen.
• Für den Dummy-Parameter in den Virtab-Prozeduren wird “VARCHAR2(255)” verwendet.
   

ONGET ... ONDELETE

Mit diesen Schlüsselworten können stored procedures definiert werden, die in der View und den Prozeduren anstelle der normalen Spaltenverwendung aufgerufen werden. Der Wert der Spalte und das Speicherverhalten wird dann durch eigene Logik “synthetisch” gebildet.
 (Diese Spalten könnten auch “virtuelle Spalten von virtuellen Tabellen” heissen ... das schien mir aber etwas zu virtuell!)

Wichtig ist die Schreib/Lese-Konsistenz: Wird ein Spalten-Wert in UPDATE verwendet, sollte die Procedure “updateprocname” den Wert so verarbeiten, dass er von “getfuncname” auch wieder zurückgegeben wird. Die Prozeduren sollten also intern miteinander kommunizieren.
(Siehe auch die Kommandozeilenoption -defcolprocs, und die Konzeptbeschreibung).

PRIVATE

Mit “PRIVATE” wird eine Spalte gekennzeichnet, die nicht an andere Virtabs vererbt wird (siehe “Vererbung”).

INFO

Mit “INFO” kann ein Kommentar für die Spalte angegeben werden.

FEATURE

Wie für die ganze Virtab kann auch für jede Spalte ein speziell in ER2SQL einkompilierte Sonderfunktion vereinbart werden.

FEATURE INFO

Auch für eine Virtabspalte können beliebige Attribute angegeben werden. Diese bewirken keine Zusatzfunktionen und können von Applikationen über das Application-Interface mit “VTColHasFeature()” abgefragt werden.
Auf diese Weise kann eine Virtabspalte für einen bestimmten Verwendungszweck markiert werden.

END

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