Syntax der Basistabellen-Definition:

In diesem Abschnitt des Definitionsfiles muss für jede in eine Virtab einzubeziehende Datenbank-Tabelle eine exakte Kopie der Datenbank-Definition angegeben werden.

Für jede Tabelle muss die Beschreibung nach folgendem Muster erfolgen:

 "TABLE" [ schema "." ] tablename
  ["TABLESPACE" tablespace_name]
  ["SMALL"]
  ["INDEXED"]
  ["NOCHANGE"]
  "COLUMN" colname "DATATYPE" [schema "."] oracle_datatype
     [ "PRIMARYKEY" | "PRIMARYKEY2" |
       "IDENTIFYING" | "IDENTIFYING"  "NULL"]
     [ "NOCHANGE" ]
     [ "NULL" ]
     [ "NOT NULL" ]
     [ "UNIQUE" ]
     [ "INDEXED" ]
     [ "CASEINSENSITIVE" ]
     [ "INFO" info_text ]
  "COLUMN" colname .......
  "COLUMN" colname .......
 ";"

Die Tabellen- und Spaltennamen müssen wie in der Datenbank geschrieben erscheinen, ohne Schema-Prefix. Viele Attribute beinflussen nur die Erzeugung des Datenbank-SQL, aber nicht die Funktion der Virtabs.

Tabellen-Attribute

SCHEMA

Datenbanktabellen müssen nicht dem Schema angehören, unter dem die Virtabs übersetzt werden. In diesem Fall muss dem Tabellennamen das Schemaprefix vorangestellt werden.

ACHTUNG: derzeit müssen sich alle Tabellen im Namen unterscheiden, auch, wenn zwei Tabellen gleichen Namens zu verschiedenen Schemas gehören!

TABLESPACE

Wenn “tablespace_name” angegeben wurde, wird die Tabelle selbst im Tablespace “data_<tablespace_name>” angelegt. Indexstrukturen werden in “idx_<tablespace_name>” angelegt.

SMALL

die “SMALL”-Option bewirkt die Implementierung der Tabelle mit der CACHE-Option, was für häufig abgefragte Tabellen den Zugriff optimiert. Für Fremdschlüsselverweise auf mit “SMALL” generierte Tabellen (mit dann jeweils sehr vielen identischen Mastereinträgen) wird in Zukunft ein BITMAP-Index erzeugt. Beides ist aktuell nur für die Datenbankdefinition selbst relevant, nicht aber für produzierte Virtabs.

INDEXED

“INDEXED” markiert Tabellen, die nach ihrem Primärkey sortiert gespeichert werden (ORACLE: “ORGANIZATION INDEX”).

NOCHANGE

“NOCHANGE” markiert Tabellen, die von keiner Virtab verändert werden können (Stammdaten, die mit anderen Mechanismen gepflegt werden).

INFO

Mit “INFO” kann ein beliebiger Text angegeben werden. Im SQL-Code für CREATE TABLE wird dieser Text als SQL-Kommentar mit ausgeben.

Spalten-Attribute:

DATATYPE

“oracle_datatype” ist der Oracle-Datentyp der Spalte, wie in der Datenbank angegeben: also “char(30)” oder “number(12,5)”. Auch anwendungspezifische Typen (“MDSYS.SDO_GEOMETRY”) sind erlaubt.

PRIMARYKEY, PRIMARYKEY2

“PRIMARYKEY” markiert den Primärschlüssel, ist somit nur für eine Spalte in einer Tabelle erlaubt. Für diese Spalte muss ein Numerngenerator (SEQUENCE) mit dem Namen “SEQ_<colname>” in der Datenbank vorhanden sein.

“PRIMARYKEY2” markiert eine Schlüsselspalte, die ebefalls als Primärkey genutzt werden kann (alternativer Primärkey), für die aber keine Sequenzwerte generiert werden.

IDENTIFYING

“IDENTIFYING” ist für mehrere Spalten erlaubt und markiert alle Spalten des Zweitschlüssels, der datenbankseitig über eine entsprechende UNIQUE-Bedingung ausgedrückt wird.
“IDENTIFYING NULL” bedeutet, dass in der Datenbank auch der Wert NULL als gültiger Schlüsselwert anzusehen ist. Dies ist vor allem relevant bei zusammengesetzten Schlüsseln, bei denen nicht immer alle Felder NOT NULL sind.
Normalerweise wird eine Schlüsselspalte mit einem NULL-Wert bei der Record-Lokalisierung ignoriert.

Erweiterte Spalten-Attribute:

NOCHANGE

“NOCHANGE” markiert schreibgeschützte Spalten, die von den Virtabs nie geändert werden (nicht implementiert).

NULL

“NULL” heisst, dass in der Datenbankdefinition kein “NOT NULL” Constraint für die Spalte erzeugt wird. Nur in Zusammenhang mit “IDENTIFYING NULL” beinflusst es die Virtab-Funktionalität.

NOT NULL

“NOT NULL” heisst, dass in der Datenbankdefinition ein “NOT NULL” Constraint für die Spalte erzeugt wird. Die Virtab-Funktionalität wird nicht beeinflusst.

UNIQUE, INDEXED

“UNIQUE”: Für die Spalte wird ein UNIQUE-Constraint erzeugt (keine Auswirkung auf Virtabs).

“INDEXED”: Die Spalte soll indiziert werden (keine Auswirkung auf Virtabs)

 CASEINSENSITIVE

Die Gross/Kleinschreibung der Werte in dieser Spalte soll beliebig sein. ER2SQL reagiert darauf wie folgt (Beispiel für ORACLE):

• Wenn INDEXED angegeben ist, wird der Index “function-based” auf “NLS_UPPER(column)” gesetzt. Ähnliches gilt für “UNIQUE”.
• Der UNIQUE-Index für IDENTIFYING-Spalten wird ebenfalls auf 
  “NLS_UPPER(column)” gesetzt.
• Die Such-Cursoren für IDENTIFYING-Spalten suchen case-unabhängig.

Achtung: In der von ER2SQL erzeugten Datenbankdefintion wird eine CASEINSENSITIVE-Spalte nicht direkt indiziert, es gibt nur noch einen Index auf “NLS_UPPER(column)”. Anwender dürfen daher in den WHERE-Klauseln ihrer SELECT-Anweisungen nur noch mit “NLS_UPPER(column)” verwenden, sonst wird für die Abfrage kein Index genutzt.
 

Beschreibung der 1:n- Beziehungen in der Datenbank

In diesem Abschnitt werden alle Fremdschlüssel-Primärschlüssel-Referenzen zwischen verschiedenen Datenbank-Tabellen angegeben (soweit sie für die Virtabs nötig sind). Es können 1:n, 1:0/1 und 1:1-Beziehungen verwendet werden. Die 1:1-Beziehung ist dabei im wesentlichen als 1:n-Beziehung implementiert, mit etwas anderer Semantik.

Für jede Referenz muss die Beschreibung nach folgendem Muster aufgebaut sein:

"LINK" mastertable ( "1:N" | "1:1" | "1:0/1" ) detailtable "BY" foreignkey [ "TO" primarykey2 ] [ "ON DELETE CASCADE" ]";"

• “foreignkey” ist die Spalte in “detailtable”, die auf den Primärschlüssel von mastertable zeigt.
• Der Primärkey von mastertable wird nicht erwähnt. Soll stattdessen der Link auf den alternativen Primärkey geführt werden, muss man “TO primarykey2” hinzugefügen.
• “1:N” gibt an, dass es mehrere Records in “detailtable” geben darf, die den gleichen Record in “mastertable” referenzieren.. Dies ist der Normalfall.
• “1:1” gibt an, dass nur ein Record in “detailtable” einen Record in “mastertable” referenzieren darf. Es werden jeweils Paare von records miteinander verbunden. Diese Art der Referenz erzwingt ein UNIQUE auf “foreignkey”, und ermöglicht es ER2SQL bessere Lokalisierungsstrategien, zu nutzen. Beim Löschen eines Records aus “detailtable” wird geprüft, ab der Record aus “mastertable” auch gelöscht wird.
• “1:0/1” ist ein Mittelding aus “1:1” und “1:N”: “foreignkey” muss auch UNIQUE sein, das Löchen des Records aus “detailtable” erwzingt aber kein Löschen aus “mastertable”.
• Mit “TO” wird ein anderer Primärkey in mastertable angegeben, falls nicht die mit PRIMARYKEY markierte Spalte referenzeirt werden soll. Es kann nur PRIMARYKEY2 genannt werden.
• ON DELETE CASCADE bewirkt, dass Detailtabellen automatisch gelöscht werden, wenn ein Master gelöscht wird.