Virtabs: Virtab-Vererbung und -Modifikation

Vererbung und Modifikation von Virtab-Definitionen

Bereits definierte Virtabs können in den Definition von anderen Virtabs verwendet werden. Dadurch kann man mit einer Komplexitäts-Hierarchie arbeiten: In Basis-Virtabs werden elementare Verknüpfungselemente definiert, die von komplexeren Virtabs benutzt werden. So kann man auch leicht verschiedene Varianten einer Virtab erzeugen. 

Die hier aufgeführten Anweisungen stehen hinter “VIRTUALTABLE” und können überall mit den Angaben der Virtab-Definition gemischt werden (Ausnahme: MODIFIES). Aus Gründen der Übersichtlichkeit werden sie jedoch von diesen getrennt dargestellt.

Syntax:

[ "MODIFIES" importvirtabname ]
[ "USES" importvirtabname [ "PREFIX" object_prefix ]
[ "COLUMN" ... "PRIVATE" ]
[ "MODIFY TABLE ALIAS" tablealias ]
[ "MODIFY COLUMN" virtab_colname [ "NAME" newname ]]
[ "WITHOUT TABLE" tablealias ]
[ "WITHOUT COLUMN" virtab_colname ]
[ "WITHOUT CONSTRAINT" constraint_name ]
[ "WITHOUT FEATURE" feature_name ]

 

MODIFIES/USES

Beide Anweisungen bewirken, dass die Definition einer schon vorhanden Virtab in die aktuelle Definition importiert wird. Die Wirkung ist so, als würde der Text der angesprochenen Definition an die Stelle des USES oder MODIFIES kopiert. TABLE und COLUMN-Namen aus der importierten Virtab dürfen allerdings noch nicht definiert sein, sonst gibt es Namenskonflikte. PRIVATE-Spalten werden nicht importiert.

Die Unterschiede zwischen MODIFIES und USES sind folgende:

  • MODIFIES darf nur einmal direkt hinter VIRTUALTABLE kommen. USES darf mehrmals überall angegeben werden, wo TABLE oder COLUMN erlaubt ist.
  • Mit MODIFIES werden auch die Virtab-Attribute geerbt, während USES nur TABLE und COLUMN Anweisungen benutzt.
  • Bei USES kann ein PREFIX angegeben werden, das die Namen in der importierten Definition verändert. “object_prefix”  wird vorne an jeden “tablealias”, “spaltenamen”, “query_name” und “constraintnamen” angehängt. Dadurch entsteht ein eigener Namensraum für die importierte Virtab, so können Namenskollisionen zwischen aktueller Definition und importierter Definition verhindert werden.

Das Importieren einer Virtab in eine bestehende Definition bedeutet auch, dass zwei Basistabellen-Netzwerke zu einem verschmolzen werden müssen. Daher sollten nur Virtabs geUSEDed werden, die eigene QUERIES für alle Basistabellen benannt haben, die von den QUERIES in der aktuellen Definition verschieden sind. Dadurch liegen die Netzwerke nachdem Import zunächst sauber getrennt vor. Im zweiten Schritt muss dann eine Verbindung zwischen beiden Netzwerken geschaffen werden. Dies ist hier ausführlich dargestellt.

COLUMN ... PRIVATE

Hat eine Spalte das Attribut “PRIVATE”, kann sie nicht per USES oder MODIFIES importiert werden (siehe die Syntax von “COLUMN”).

MODIFY TABLE ALIAS

Damit können für eine bereits in der Virtab vorhandene Basistabelle die Attribute geändert werden. In der Regel ist das nötig, wenn die Basistabelle über ein USES importiert wurde und angepasst werden muss.

Attribute “addieren sich auf”. Beispiel: Ist eine Basistabelle schon in QUERY A, dann ist sie nach der Anweisung “TABLE ... QUERY B” in den Queries A und B. Analoges gilt für FOREIGNKEY, wobei mit NOFOREIGNKEY allerdings ein Löschen aller bisher definierten Fremdschlüssel erreicht werden kann.

MODIFY COLUMN

Damit können Attribute einer bereits definierten Virtab-Spalte geändert werden. Mit “NAME” kann auch der Spaltenname geändert werden.

Da durch PREFIX alle Spaltennamen der importierten Basistabellen verändert werden, kann man mit “MODIFY COLUMN <bad_name_with_PREFIX>... NAME <good_name>” gezielt die Wirkung von PREFIX rückgängig machen.

WITHOUT TABLE

So wird eine vorhandene Basistabelle wieder aus der Virtab entfernt. Alle Virtab-Spalten dieser Basistabelle werden ebenfalls gelöscht. Falls Spalten aus der " tablealias” in SQL-Ausdrücken (CALCULATES, CONSTRAINT) vorkommen, gibt es einen Fehler. Dann muss die berechnete Spalte bzw. das Constraint vorher explizit gelöscht werden.

WITHOUT COLUMN

Das löscht eine definierte Virtab-Spalte aus der Virtab. Falls die Spalte in SQL-Ausdrücken (CALCULATES, CONSTRAINT) vorkommt, gibt es einen Fehler. Dann muss die berechnete Spalte bzw. das Constraint vorher explizit gelöscht werden.

WITHOUT CONSTRAINT

Damit kann ein defniertes CONSTRAINT wieder gelöscht werden. Es muss allerdings mit Namen defineirt worden sein (“CONSTRAINT NAME“).

WITHOUT FEATURE

Das macht eine vorher angegebene FEATURE-Anweisung ungültig.

 

 

[Referenz] [ER2SQL cmdline] [DB-Voraussetzungen] [Definitionsfile-Aufbau] [Syntax: TABLE und LINK] [Syntax: VIRTUALTABLE] [Syntax: TABLE] [Syntax: COLUMN] [Syntax: CONSTRAINT] [Syntax: USES, MODIFY, ...] [Fehler von ER2SQL] [Laufzeitfehler] [Syntax-Hervorhebung] [SQL-Objekt-Namen]