| Auszug | ||
|---|---|---|
| ||
Nuclos Datenmigration: Importstrukturdefinition, SQL, JDBC, ID-Factory, idfactory, T_EO_, Altsystem, CSV. |
Sprache: Deutsch · English
Bestandsdaten nach Nuclos übernehmen – Importstrukturdefinitionen für Einfaches, SQL/Programm für Komplexes.
| Status | ||||
|---|---|---|---|---|
|
| Status | ||||
|---|---|---|---|---|
|
| Status | ||||
|---|---|---|---|---|
|
| Status | ||||
|---|---|---|---|---|
|
| Panel | ||||||
|---|---|---|---|---|---|---|
| ||||||
Auf dieser Seite
|
Wege, um Bestandsdaten aus Altsystemen nach Nuclos zu übernehmen.
Für die Migration mit Bordmitteln stehen Ihnen die Importstrukturdefinitionen zur Verfügung, siehe auch Import & Export.
Über Importstrukturdefinitionen. Für komplexe Migrationen
...
(Umbau von Datenstrukturen
...
, Umformatierungen) nur bedingt geeignet
...
: es sind meist manuelle Zwischenschritte
...
nötig (CSV-Export, Löschen vor erneutem Lauf, gleiche Formate/Zeichensätze), die Übersichtlichkeit und Protokollierung leiden, und Umformatierungen mithilfe weiterer Datenquellen sind nicht möglich.
Für komplexe
...
Fälle empfiehlt sich ein SQL-Skript (gleiches DBMS) oder ein Programm (unterschiedliche DBMS, z.B. via JDBC zu beiden Datenbanken), das die Migration synchron und automatisiert durchführt.
| Warnung | |||||
|---|---|---|---|---|---|
| |||||
IDs immer über die Nuclos-ID-Factory vergeben – je nach DBMS unterschiedliche Syntax:
|
| Info |
|---|
Für eine Migration mittels SQL empfiehlt es sich, vor Ausführung sämtliche Constraints zu deaktivieren, und am Ende der Migration wieder zu aktivieren, um die Reihenfolge der zu migrierenden Tabellen während der Migrationsausführung frei wählen zu können (und auf eine Wartbarkeit des Migrationsskriptes hin optimieren zu können). In den meisten DBMS stehen Systemtabellen zur Verfügung, aus denen man alle Constraints dynamisch ermitteln kann (z.B. Tabelle user_constraints in Oracle). |
| Info |
|---|
Für eine idempotente Migration sollte das Skript im ersten Schritt sämtliche Inhalte der Zieltabellen der Migration löschen, auf diese Weise stellt das Skript selbst einen immer gleichen (leeren) Ausgangszustand für die Migration sicher. |
Bei der Migration muss grundsätzlich unterschieden werden zwischen Businessobjekten ohne Statusmodell und Businessobjekten mit Statusmodell (siehe Statusmodell). Bei den im Folgenden beschriebenen Migrationsanforderungen handelt es sich um Mindestanforderungen. Situationsbedingt können im Einzelfall weitere Anforderungen hinzukommen.
Bei der Befüllung von Tabellen ohne Statusmodell ist lediglich zu beachten, dass die Systemattribute INTID, DATCREATED, STRCREATED, DATCHANGED, STRCHANGED, INTVERSION korrekt und sinnvoll befüllt werden.
...
Empfohlen wird die Befüllung über die Nuclos Sequenz IDFACTORY.
Euch möglich ist eine Befüllung mit beliebiger Zahl, es ist dabei die Eindeutigkeit innerhalb der Tabelle sicherzustellen.
Um Verletzungen der Eindeutigkeit nach der Migration zu vermeiden, ist die Sequenz IDFACTORY auf den über alle Tabellen vergebenen höchsten Wert +1 zu setzen.
...
Beliebiger String, z.B. der Benutzername der letzten Änderung des Datensatzes im Altsystem oder ein generischer String wie "MIGRATION".
...
Postgres
...
|
...
|
...
Oracle
...
|
Zusätzlich zu den Systemattributen, wie sie auch für Businessobjekte ohne Statusmodell (siehe vorhergehender Abschnitt) zu migrieren sind, sind weitere Systemattribute zu befüllen.
| Systemattribut | Hinweise |
|---|---|
| STRUID_NUCLOSSTATE | Referenz auf Status (siehe Statusmodell). |
| STRUID_NUCLOSPROCESS | Referenz auf Aktion (siehe Aktionen), soweit für das betreffende Businessobjekt Aktionen definiert sind. |
| STRNUCLOSSYSTEMID | Beliebiger String, der den Datensatz fachlich eindeutig identifiziert. |
| BLNNUCLOSDELETED | false |
| STRNUCLOSORIGIN | NULL |
Darüberhinaus sind folgende Systemtabellen zu befüllen, dabei ist jeweils ein Datensatz je migriertem Datensatz für Businessobjekte mit Statusmodell einzutragen.
Empfohlen wird die Befüllung über die Nuclos Sequenz IDFACTORY.
Euch möglich ist eine Befüllung mit beliebiger Zahl, es ist dabei die Eindeutigkeit innerhalb der Tabelle sicherzustellen.
Um Verletzungen der Eindeutigkeit nach der Migration zu vermeiden, ist die Sequenz IDFACTORY auf den über alle Tabellen vergebenen höchsten Wert +1 zu setzen.