この章では、データモデルで可能な変更と、潜在的な制限について説明します。
データモデラーがテーブルの主キーに対して展開を実行するときはいつでも、結果の定義は新しいテーブルと見なされます。このような場合、既存のデータを何らかの方法で保存する必要がある場合は、新しいデータモデルを公開または展開する前に、データ移行計画を設定して運用する必要があります。また、データモデルの進化の直後にデータが破棄されないことにも注意してください。データモデルが前の状態にロールバックされると、前のデータが取得されます。
特定の型のデータモデルの展開は、ユーザーインターフェイスで直接実行できないため、データモデルをエクスポートし、XSD形式で変更してから、再インポートする必要があります。構造だけでなく構成に影響を与えるデータモデルへの変更については、XSDをモジュールからTIBCO EBX®にインポートする必要があります。それ以外の場合、構成の変更は考慮されません。
このセクションでは、データモデルの作成後に可能な変更について説明します。
既存のデータモデルに次の変更を加えることができます。
レプリケーションユニットをデータモデルに追加できます。更新ポリシーが「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
型のカーディナリティは変更できます。変換がサポートされている場合、次のように動作します。
単一のエレメントを集約リストに変更すると、以前の単一の値が保持され、新しい集約リストに追加されます。
集約リストを単一のエレメントに変更すると、集約リストの最後の値のみが単一のエレメントに保持されます。他の値は失われます。
グループおよび複合型は、他の型への（および他の型からの）変換をサポートしていません。さらに、グループまたは複合型が単一発生と複数発生の間で変化する場合、変換は、グループまたは複合型がターミナルである場合にのみサポートされます。