Customizing
Customizing
Breadcrumbs

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.