TIBCO EBX® リポジトリに格納されているデータを専用のリレーショナルテーブルにミラーリングして、SQL リクエストとビューによるデータへの直接アクセスを可能にすることができます。
履歴と同様に、このデータレプリケーションはエンドユーザーとクライアントアプリケーションに対して透過的です。特定のアクションは、データベース内のレプリカへの自動変更をトリガーします。
モデルレベルでレプリケーションをアクティブ化すると、必要な DDL ステートメントが自動的に実行され、データベーススキーマが更新されます。
新しい列の作成など、レプリケートされたテーブルに影響を与えるデータモデルの進化も、DDL ステートメントを使用してデータベーススキーマを自動的に更新します。
「onCommit」更新モードを使用する場合：EBX® リポジトリのデータを更新すると、レプリカデータベーステーブルで関連する挿入、更新、および削除がトリガーされます。
複製されたテーブル：複製されたプライマリデータテーブルを参照します。
レプリカテーブル (レプリカ)：レプリケーションのターゲットであるデータベーステーブルを参照します。
データモデルでレプリケーションユニットを定義するには、エレメント annotation/appinfo の下にあるエレメント osd:replication を使用します。各レプリケーションユニットは、特定のデータスペース内の単一のデータセット内のテーブルを指定します。
ネストされたエレメントは次のとおりです。
エレメント | 説明 | 必須 |
|---|---|---|
| レプリケーションユニットの名前。この名前は、現在のデータモデルのレプリケーションユニットを識別します。一意である必要があります。 | はい |
| このレプリケーションユニットに関連するデータスペースを指定します。スナップショットまたはリレーショナルデータスペースにすることはできません。 | はい |
| このレプリケーションユニットに関連するデータセットを指定します。 | はい |
| データ同期ポリシーを指定します。可能なポリシーは次のとおりです。
| はい |
| データベースに複製される現在のデータモデルのテーブルのパスを指定します。 | はい |
| データの複製先となるデータベース内のテーブルの名前を指定します。この名前は、すべてのレプリケーションユニット間で一意である必要があります。 | はい |
| データベースに複製されるテーブル内の集約リストのパスを指定します。 | はい |
| 集約リストのデータが複製されるデータベース内のテーブルの名前を指定します。この名前は、すべてのレプリケーションユニット間で一意である必要があります。 | はい |
例：
<xs:schema> <xs:annotation> <xs:appinfo> <osd:replication> <name>ProductRef</name> <dataSpace>ProductReference</dataSpace> <dataSet>productCatalog</dataSet> <refresh>onCommit</refresh> <table> <path>/root/domain1/tableA</path> <nameInDatabase>PRODUCT_REF_A</nameInDatabase> </table> <table> <path>/root/domain1/tableB</path> <nameInDatabase>PRODUCT_REF_B</nameInDatabase> <element> <path>/retailers</path> <nameInDatabase>PRODUCT_REF_B_RETAILERS</nameInDatabase> </element> </table> </osd:replication> </xs:appinfo> </xs:annotation> ... </xs:schema>
注意：
レプリケートされたテーブルのデータモデルの制限を参照してください。
データモデルのコンパイル時に、指定されたデータセットやデータスペースが現在のリポジトリに存在しない場合、警告が報告されますが、レプリカテーブルはデータベースに作成されます。指定されたデータスペースとデータセットが作成されると、レプリケーションがアクティブになります。
データモデルのコンパイル時に、テーブルレプリケーションが削除された場合、または上記のプロパティの一部が変更された場合、レプリカテーブルはデータベースから削除され、必要に応じて新しい定義で再作成されます。
レプリケートされたテーブルの場合、デフォルトの動作では、サポートされているすべてのエレメントがレプリケートされます (レプリケートされたテーブルのデータモデルの制限を参照)。
データモデルアシスタントを使用するか、基になるデータモデルを編集することにより、特定のフィールドまたはグループのレプリケーションを無効にすることができます。
データモデルを編集してフィールドまたはグループのレプリケーションを無効にするには、属性 disable="true" を持つエレメント osd:replication を使用します。
<xs:element name="longDescription" type="xs:string">
<xs:annotation>
<xs:appinfo>
<osd:replication disable="true" />
</xs:appinfo>
</xs:annotation>
</xs:element>
データモデルアシスタントを介したフィールドまたはグループのレプリケーションを無効にするには、エレメントの詳細プロパティのレプリケーションプロパティを使用します。
このプロパティがグループで定義されている場合、そのすべての子孫に対してレプリケーションが再帰的に無効になります。グループがレプリケーションを無効にすると、子孫でレプリケーションを具体的に再度有効にすることはできません。
フィールドまたはグループを含むテーブルが複製されていない場合、このプロパティは効果がありません。
主キーフィールドのレプリケーションを無効にすることはできません。
このセクションでは、SQL を使用してレプリカテーブルに直接アクセスする方法について説明します。
複製された EBX® テーブルごとに、対応するテーブルが RDBMS に生成されます。EBX® ユーザーインターフェイスを使用して、テーブルのドキュメントペインをクリックすると、このデータベーステーブルの名前を見つけることができます。
レプリカデータベーステーブルには、読み取り専用モードでのみ直接アクセスする必要があります。EBX® が使用するユーザーを除くすべてのデータベースユーザーへの書き込みアクセスをブロックするのは、データベース管理者の責任です。
直接 SQL 読み取りは、適切に管理された、できれば短期間のトランザクションで可能です。ただし、このようなアクセスの場合、EBX® 権限は考慮されません。その結果、読み取りを実行する権限を与えられたアプリケーションは、他の認証プロセスと権限を通じて信頼されている必要があります。
「onDemand」更新ポリシーでは、レプリケートされたテーブルデータを更新するための明示的なリクエストが必要です。
レプリケーションの更新を要求するには、いくつかの方法があります。
ユーザーインターフェイス：データセットアクションメニューで、グループ「レプリケーション」の下のアクション「レプリカの更新」を使用して、レプリケーション更新ウィザードを起動します。
データサービス：レプリケーションの更新データサービス操作を使用します。詳細については、データサービスのレプリケーションの更新を参照してください。
Java API：ReplicationUnit.performRefresh メソッド ( ReplicationUnit API にあります) を呼び出して、レプリケーションユニットの更新を開始します。
レプリケーション機能には、以下に示すように、いくつかの既知の制限と副作用があります。レプリケーションを使用する場合は、このセクションを注意深く読み、質問があれば Cloud Software Group, Inc. のサポートに問い合わせることを強くお勧めします。
レプリケーションがサポートされているデータベースについては、サポートされるデータベースを参照してください。
一部の EBX® データモデルの制約は、レプリケーションが有効になっている場合にブロッキング制約になります。詳細については、構造上の制約を参照してください。
複製されるテーブルを含むデータモデルには、いくつかの制限が適用されます。
指定されたデータセットがルートデータセットではないか、まだ作成されていない場合、データセットの継承は「onCommit」更新ポリシーではサポートされません。詳細については、データセットの継承を参照してください。
フィールド継承は、「onDemand」更新ポリシーでのみサポートされます。これは、データモデルのコンパイル時に、更新モードが「onCommit」であり、レプリケートされるテーブルに継承されたフィールドがある場合にエラーが報告されることを意味します。詳細については、継承されたフィールドを参照してください。
計算された値は無視されます。
リンクされたフィールドは無視されます。
別の集約リストの下の集約リストと、端末グループの下の集約リストの2種類の集約リストには制限があります。このような集約リストを含むデータモデルを使用できますが、これらのリストは無視されます (複製されません)。
ユーザー定義の属性はサポートされていません。それらがレプリケーションユニットに含まれている場合、コンパイルエラーが発生します。
関連するテーブルにすでに含まれているデータによっては、データモデルの進化が基盤となる RDBMS によって制約される場合もあります。
Update 操作は、最後の更新以降に (作成と削除に関して) 変更されたソーステーブルの行のみを送信するように最適化されています。ただし、交換されるデータの量によっては、これは集中的な操作であり、大規模なトランザクションが必要になる場合があります。特に、最初の Update 操作は多数の行に関係する可能性があります。このようなトランザクションを最適な条件下で実行できるように、データベースを適切に構成する必要があります。
Oracle の例は、次のとおりです。
レプリケーションユニット内のすべてのレプリカテーブルの大部分が「UNDO」テーブルスペースに収まることが必須です。
これらのトランザクションを最小限のディスクアクセスで実行できるように、バッファキャッシュに十分なスペースを提供することをお勧めします。
これらのトランザクションが「db_writer」プロセスを待機するのを回避するのに十分な大きさの「REDO」ロググループをプロビジョニングすることをお勧めします。
レプリケーションは、D3 プライマリとレプリカ配信データスペースの両方で利用できます。プライマリデータスペースでは、レプリケーションの動作は標準のセマンティックデータスペースと同じですが、レプリカデータスペースでは、レプリケートされたコンテンツは最後のブロードキャストスナップショットのコンテンツです。
レプリカ配信データスペースでは、いくつかの制限が発生します。
データモデルで定義された更新ポリシーは、上記の動作には影響しません。レプリケーションは常にスナップショットで行われます。
アクションアイテムレプリカの更新は使用できません。
ReplicationUnit.performRefresh メソッドを呼び出すことは許可されていません。
継承の場合、レプリカレコードフィールドは「値の継承」フラグ (AdaptationValue.INHERIT_VALUE) を保持できません。そのような場合にのみ継承された値を保持します。より一般的には、継承状態と上書き状態を区別することはできません。