Schema-Export

Information

• Es besteht die Möglichkeit, die derzeitige Definition der Datenbank (Datentabellen, Spalten, Constraints etc.) im Oracle- bzw. MSSQL-Format zu exportieren.

Voraussetzung

• Das Verzeichnis, in welches exportiert werden soll, muss unter Customizer → Stammdaten → Globale Einstellungen in dem Datenfeld Template-Code für die globale Einstellung export_path_databasescheme definiert werden.
  • In Windows-Systemen werden keine einzelnen \, sondern \\ verwendet.
    • C:\\planta\\export\\schema.

Vorgehensweise

• Wählen Sie Customizer → Datenbanken → Datenbankschema-Export, um einen Schema-Export anzustoßen.
  • Ein Export kann ca. 30 Sekunden bis 1 Minute dauern.
• Danach befindet sich das exportierte Schema in dem angegebenen Verzeichnis unter \SQLServer_<Export-Zeitstempel>\SQLServer_create.sql bzw. \Oracle10g_<Export-Zeitstempel>\Oracle10g_create.sql.
• Die drop -Skripte beinhalten Informationen darüber, wie das derzeitige Schema gelöscht wird.
• Die hibernate_mapping -Unterverzeichnisse enthalten Definitionen der Datenbank-Tabellen für Java.
• Um das exportierte Schema in eine neue Datenbank zu überführen, kann der Inhalt der _create.sql theoretisch einfach ausgeführt werden, z.B. in SqlPlus oder SqlDeveloper.
  • Es wird dringend empfohlen, dies in einem regulären Installationsprozess zu tun.
    • Hierzu reicht es aus, in einem existierenden Installer das exportierte _create.sql -Skript in 00_tables.sql umzubenennen und nach \db\bin\sql\oracle\10_tables bzw. \db\bin\sql\ms-sql\10_tables\ zu kopieren und ggfs. die bereits existierende Datei zu ersetzen.

Hinweise

• Es wird nur die Datenbank-Definition (das Schema) exportiert, nicht der Datenbank-Inhalt (echte Daten).
• Es wird prinzipiell immer ein Schema sowohl im Oracle- als auch im MSSQL-Format erstellt, unabhängig davon, welches Format die tatsächlich verwendete Datenbank hat.
  • Daher ist es nicht nötig, den Schema-Export zweimal (etwa mit einer Oracle- und einer MSSQL-Datenbank) aufzurufen.

Detaillierter Aufbau des Skript-Inhalts

• In einem create-Skript erfolgen zuerst die Definitionen aller Datentabellen einschließlich ihrer Spalten.
• Es werden folgende Datentabellen exportiert:
  • Alle aktivierten PLANTA-Datentabellen, d.h. alle Datentabellen, für deren Schema die Checkbox Aktiviert aktiviert ist und zusätzlich die Checkbox Aktiviert für die Datentabelle selbst aktiviert ist.
  • Für jede Datentabelle der Schemas Q1B und Q2B außerdem eine Datentabelle gleichen Namens mit der Endung _HIS und gleichen Spalten, die Hibernate Envers benötigt, um Historie-Daten zu speichern. Siehe auch Historisierung.
  • Ferner die interne Tabelle REVINFO von Envers.
• Definition der Datentabellenspalten:
  • Sämtliche Spalten, die auf Aktiviert gesetzt sind, werden geschrieben.
  • Jede Datentabelle (mit Ausnahme von REVINFO) hat ab Version S 39.5.0 eine Spalte UUID, die für jeden Datensatz eine eindeutige ID enthält.
  • Die Primärschlüssel stehen jeweils vor dem UUID-Feld und werden am Ende der Datentabelle definiert.
  • Default-Werte und NOT NULL Constraints:
    • Alle Spalten des Primärschlüssels implizieren einen NOT NULL Constraint.
    • Alle numerischen Felder (Integer, Short, Double) haben einen NOT NULL Constraint und als Standardwert 0.
    • Alle Datumsfelder haben einen NOT NULL Constraint und als Standardwert den 01.01.1970 (je in Oracle- oder MSSQL-Notation).
    • Die UUID-Felder kreieren als Standardwert einen neuen, eindeutigen UUID-Wert (je in Oracle- bzw. MSSQL-Notation) und haben ebenfalls einen NOT NULL Constraint.
    • Eine Ausnahme bilden numerische Felder, die Teil eines Fremdschlüssels sind, in deren referenzierter Datentabelle NULL erlaubt aktiviert ist. Solche Spalten haben weder Default-Wert noch NOT NULL Constraint.
• Danach folgen die Definitionen der Indizes und Constraints zu allen Datentabellen.
  • Es gibt dabei verschiedene Arten von Indizes und Constraints:
    • I-Text-Indizes für jede Datentabelle, deren Datensätze einen I-Text beinhalten. Dieser Index-Typ hat keinen Constraint.
    • Fremdschlüssel-Indizes für jede Datentabelle, die einen Link auf eine andere Datentabelle definiert. Dieser Index-Typ definiert zudem noch einen Constraint (oder, in MSSQL, einen Trigger für Update- und Delete-Funktionalität).
    • Envers legt für seine History-Tabellen des Weiteren noch Constraints an, die auf die allgemeine Envers-Tabelle REVINFO verweisen. Envers legt dafür keine Indizes an
• Zuletzt enthält das Skript noch (für Oracle-Datenbanken) eine neue Datenbank-Sequenz, die von Envers benötigt wird.