データモデルの進化
この章では、データモデルで可能な変更と、潜在的な制限について説明します。
注意:
データモデラーがテーブルの主キーに対して展開を実行するときは、いつでも結果の定義は新しいテーブルと見なされます。このような場合、既存のデータを何らかの方法で保存する必要がある場合は、新しいデータモデルを公開または展開する前に、データ移行計画を設定して運用する必要があります。また、データモデルの進化の直後にデータが破棄されないことにも注意してください。データモデルが前の状態にロールバックされると、前のデータが取得されます。
注意:
特定の型のデータモデルの展開は、ユーザーインターフェイスで直接実行できないため、データモデルをエクスポートし、XSD 形式で変更してから、再インポートする必要があります。構造だけでなく構成に影響を与えるデータモデルへの変更については、XSD をモジュールから TIBCO EBX® にインポートする必要があります。それ以外の場合、構成の変更は考慮されません。
以下も参照してください。:
Related information
許可される進化の種類
このセクションでは、データモデルの作成後に可能な変更について説明します。
モデルレベルの進化
既存のデータモデルに次の変更を加えることができます。
-
レプリケーションユニットをデータモデルに追加できます。更新ポリシーが「onCommit」の場合、対応するレプリカテーブルが作成され、次のスキーマコンパイル時に更新されます。
-
レプリケーションユニットはデータモデルから削除できます。対応するレプリカテーブルはすぐに削除されます。
-
データモデルは削除できます。レプリケーションユニットを宣言すると、対応するレプリカテーブルはすぐに削除されます。履歴テーブルが含まれている場合、この変更により、関連するマップされたテーブルが無効としてマークされます。関連するデータベースオブジェクトの実際の削除については、データベースマッピング を参照してください。
テーブルレベルの進化
テーブルレベルでデータモデルに次の変更を加えることができます。
-
新しいテーブルを追加できます。作成時に、テーブルは 1 つ以上のマップモードを宣言することもできます。
-
既存のテーブルを削除できます。レプリケーションユニットを宣言すると、対応するレプリカテーブルはすぐに削除されます。履歴がある場合、この変更により、マップされたテーブルが無効としてマークされます。関連するデータベースオブジェクトの実際の削除については、データベースマッピング を参照してください。
-
履歴は、テーブルで有効または無効にできます。履歴では、無効になっている間に実行された操作は考慮されません。
-
テーブルの名前を変更できます。この変更は削除と作成の組み合わせと見なされるため、XML またはアーカイブファイルをエクスポートしてから再インポートすることにより、データを手動で移行する必要があります。
フィールドレベルの進化
フィールドレベルでデータモデルに次の変更を加えることができます。
-
新しいフィールドを追加できます。
-
既存のフィールドは削除できます。削除されたフィールドのデータは、次回の更新時に各レコードから削除されます。レプリカテーブルの場合、対応する列は自動的に削除されます。履歴モードでは、フィールドは無効としてマークされます。
-
属性
disable="true"を使用して、フィールドを含むテーブルに適用される履歴またはレプリケーションからフィールドを明確に無効にすることができます。レプリカテーブルの場合、対応する列は自動的に削除されます。履歴テーブルの場合、列は残りますが、無効としてマークされます。特定のフィールドまたはグループの履歴の無効化 および 特定のフィールドまたはグループでのレプリケーションの無効化 を参照してください。 -
制限/制約 にリストされているファセットを除いて、フィールドのファセットを変更できます。次の変更は受け入れられますが、データが失われる可能性があります。これらの変更は削除と作成の組み合わせと見なされるため、XML またはアーカイブファイルをエクスポートしてから再インポートすることにより、データを手動で移行する必要があります。
-
フィールドの名前を変更できます。
-
フィールドの型は変更できます。
制限/制約
主キーの進化に関する制限
主キー定義が変更された場合
-
すべてのデータセットとデータスペースで、テーブルの内容が空の内容にリセットされます。
-
新しい主キーが過去に使用されている場合、テーブルの内容は、すべてのデータセットとデータスペースで、この主キーが使用された時点で存在していた以前のデータにリセットされます。
-
主キーフィールドの型変換はサポートされていません。したがって、以前の主キー定義ですでに使用済みの型を再利用する場合でも、主キーの型を変更するとテーブルのコンテンツは常に空にリセットされます。
-
既存のデータスペースでテーブルの履歴がアクティブになっている場合、またはアクティブになっていた場合、変更は拒否されます。回避策として、まず専用テーブルに関連付けられている履歴テーブルを削除してから、主キーの変更に進みます。マップされたテーブルデータベースリソースを削除する手順については、データベースマッピングを参照してください。
注意:
変更された主キーが別のテーブルの主キーで参照されている場合、上記のすべての制限がターゲットテーブルに適用されます。
外部キーの進化に関する制限
-
osd:tableRefファセットの宣言が追加または変更された場合、またはそのターゲットテーブルの主キーが変更された場合、既存の値は空から再開されます (この変更が以前の定義に戻る場合を除きます。この場合は、以前のコンテンツが取得されます)。 -
レプリケーションモードでは、外部キーフィールドの構造は、ターゲットのプライマリ キーの構造と一致するように設定されます。
osd:tableRef制約を宣言する単一のフィールドは、ターゲットのプライマリキーの数とタイプに対応する数とタイプの列に分割される可能性があります。したがって、次の進化のケースは、マップされたテーブルの構造に影響を与えます。-
テーブルフィールドに新しい
osd:tableRef制約を宣言します。 -
テーブルフィールドの既存の
osd:tableRef制約を削除します。 -
既存の
osd:tableRef制約によって参照される主キーに列を追加 (または削除) します。 -
既存の
osd:tableRef制約によって参照される主キーの任意の列の型またはパスを変更します。
これらの進化のケースでは、フィールドの削除と作成の組み合わせが発生します。したがって、既存のデータは手動で移行する必要があります。 -
フィールドレベルの進化に関する制限
フィールドの型を互換性のない型またはカーディナリティに変更すると、フィールドは新しいフィールドと見なされ、空のコンテンツで開始されます。モデルが以前の定義にロールバックされると、以前のコンテンツが取得されます。
-
次の型は完全に相互変換可能です (つまり、これらの型はまったく同じ永続表現を持ち、次のチャートで互いに置き換えることができます)。
-
xs:string -
osd:color -
osd:datasetName -
osd:dataspaceKey -
osd:email -
osd:html -
osd:local -
osd:resource -
xs:nmtoken -
xs:nmtokens -
osd:text -
xs:anyUri -
xs:name
-
-
次の変換は完全にサポートされています (つまり、カーディナリティに関係なく)。
-
xs:decimalからxs:string -
xs:datetimeからxs:string -
xs:dateからxs:string -
xs:integerからxs:string -
xs:intからxs:decimal -
xs:integerからxs:decimal -
xs:decimalからxs:integer(小数部は失われる) -
xs:intからxs:integer -
xs:datetimeからxs:date(時間部分は失われる) -
xs:dateからxs:datetime(時間部分はデフォルトで 0 に設定)
-
-
次の変換は、元の型が単一値の場合にのみ可能です。
-
xs:booleanからxs:string -
xs:timeからxs:string -
xs:intからxs:string -
xs:longからxs:string
型のカーディナリティは変更できます。変換がサポートされている場合、次の動作になります。 -
-
単一のエレメントを集約リストに変更すると、以前の単一の値が保持され、新しい集約リストに追加されます。
-
集約リストを単一のエレメントに変更すると、集約リストの最後の値のみが単一のエレメントに保持されます。その他の値は失われます。
注意:
グループと複合型は、他の型への変換 (および他の型からの変換) をサポートしていません。さらに、グループまたは複合型が単一オカレンスと複数オカレンスの間で変更される場合、変換はグループまたは複合型がターミナルである場合にのみサポートされます。