Standard または Advancedのライセンスで利用可能。
レプリカを作成すると、親ジオデータベースからデータとスキーマが子ジオデータベースへコピーされます。このデータには、レプリカのデータセットから複製される行が含まれています。スキーマは、フィールド、ドメイン、サブタイプ、およびその他のプロパティなどの複製されるデータの情報で構成されます。
初期状態では、スキーマはどちらのレプリカでも同じですが、各レプリカのスキーマに変更が加えられる可能性があります。たとえば、一方のレプリカではプロジェクトを完了するための追加フィールドが必要で、相対レプリカでは既存のフィールドに新しいドメインを適用する必要があるとします。この場合、両方のレプリカのスキーマはもはや同じではありません。
次に、レプリカ間のスキーマの違いに対処する方法について説明します。
スキーマの違いを維持 — 他のレプリカとレプリカのスキーマの変更の同期をとらずに、独自にレプリカのスキーマを変更することが可能です。ジオデータベース レプリケーションは、レプリカ間のスキーマの違いを基本的に許容するように設計されているので、ほとんどの場合、データの同期は引き続きうまく機能します。
ただし、スキーマの変更を一方のレプリカに適用し、もう一方のレプリカに適用しない場合には、次のような問題が予測されます。
- 同期しない編集 — データの同期では、両方のレプリカに共通するテーブルおよびフィールドへの変更だけがインポートされます。相対レプリカに存在しないフィールドへの編集は、変更をインポートする際に相対レプリカに適用されません。もう 1 つの例は、ジオメトリック ネットワークが一方のレプリカで削除され、もう一方のレプリカで削除されない場合です。この場合、参照されなくなったジャンクション クラスは削除されるため、相対レプリカのジャンクション クラスからの変更は適用されません。
- 無効な値 ─ ドメイン、サブタイプ、接続性ルール、およびリレーションシップ クラスのルールに違反する変更が、変更を同期する際に適用される場合があります。エディターの整合チェック ツールを使用して、新たにインポートされた値をチェックする必要があります。
- データの同期エラー — 両方のレプリカに対して手動共通のスキーマ変更を行った場合に、このエラーが発生する場合があります。たとえば、テーブルにフィールドを追加するような場合、 すべてのレプリカにまったく同じスキーマの変更が適用されることを確認してください。違いが存在する場合 (一方のレプリカでは追加したフィールドの型がテキスト型であり、もう一方のレプリカでは整数であるなど)、データの同期はエラーになります。
- サポートされていない変更 ─ 一部のスキーマの変更は同期を失敗させる原因になりますが、そのような変更を加えたとしても警告は表示されません。これらの変更はジオデータベース レプリケーション システムによって検出されません。たとえば、データベース テーブルでの権限の変更など、データベース レベルでの操作が挙げられます。複製されたデータの権限が読み取り専用に変更された場合、相対レプリカから変更をインポートしようとするとエラーになります。
レプリカ間のスキーマ変更の適用 — レプリカのスキーマを相対レプリカのスキーマと一致するように変更することは、データの同期とはまったく別のプロセスです。スキーマ変更の適用のために、[レプリカ スキーマの比較]、[レプリカ スキーマのインポート]、[レプリカ スキーマのエクスポート] という 3 つのツールが提供されています。これらのツールは、ArcMap の [分散ジオデータベース] ツールバーか、カタログ ツリーの [分散ジオデータベース] サブメニューで、またはジオプロセシング ツールとして使用できます。
これらのツールは 2 段階のプロセスで使用します。まず、[レプリカ スキーマの比較] ツールを実行してスキーマ変更を格納する XML ファイルを生成し、次に [レプリカ スキーマのインポート] ツールを使用して、これらの変更をインポートします。非接続環境で操作している場合は、最初に [レプリカ スキーマのエクスポート] ツールを使用して、変更を含むスキーマを XML ファイルにエクスポートします。このファイルを CD や DVD などのメディアなどを使用して相対レプリカの環境に移して、[レプリカ スキーマの比較] ツールへの入力データとして使用することができます。
次に、スキーマの変更とそれらがレプリカに適用可能かどうかを示します。
追加 | 変更 | 削除 | |
フィールド | Y | Y (ドメイン) | Y |
ドメイン | Y | Y | Y |
テーブル/フィーチャクラス | Y | Y (ドメイン、フィールドの追加/削除) | Y |
ジオメトリック ネットワーク | N | N | Y |
トポロジ | N | N | Y |
フィーチャ データセット | N | N | Y |
リレーションシップ クラス | N | Y (フィールドの追加/削除、ドメイン) | Y |
レプリカへのフィーチャクラスまたはテーブルの追加は、上で示したツールでは実行できません。ArcObjects を使用したコードを実行する必要があります。サンプル コードはこちらをご参照ください。
レプリカからのデータの削除 ─ 各レプリカに含まれるデータセットのリストは、レプリカ ジオデータベースに格納されます。これらのデータセットの 1 つを削除すると、警告が表示されます。削除を続行した場合、そのデータセットはレプリカのデータセット リストから削除されます。ArcObjects API を使用して、データを再びレプリカに追加することができます。次の注意事項も参照してください。
- テーブルまたはフィーチャクラスを削除した後、レプリカに再び追加したい場合は、追加するためのコードを実行する必要があります。単に再作成しても追加されません。
- ジオメトリック ネットワークまたはトポロジを削除した場合、レプリカに再び追加することはできません。レプリカの同期は維持されますが、トポロジの例外の同期はサポートされません。また、参照されなくなったジャンクションへの変更を同期することはできません。
- フィーチャ データセットを削除し、再びレプリカに追加しても、影響は一切ありません。
- リレーションシップ クラスを削除した後で再びレプリカに追加することはできません。
スキーマの違いの特定 — スキーマの変更を厳重に監視したい場合は、これらのツールを使用してレプリカのスキーマを比較し、違いを特定することができます。[レプリカ スキーマのインポート] ウィザードで、スキーマの違いが表示されます。
ベスト プラクティス
一般に、スキーマの変更は避けるべきです。スキーマの変更は、レプリカ間で一貫性が失われる原因となり、スキーマの変更を適用するための余分なタスクのせいで、パフォーマンスに悪影響がおよびます。ただし、スキーマの変更を適用しなければならない場合もあります。
次に、スキーマの変更に対処するための方法を示します。
- システムをロック ダウンする ─ システムを使用するユーザーが適切な権限で作業していることを確認します。列の追加や削除といった、無計画なスキーマの変更を実行できないアプリケーションの設計が必要になることもあります。
- 定期的にスキーマを比較する ─ レプリケーションはフォールト トレランスなので、ほとんどの場合、同期を実行するシステムはスキーマの変更によって中断されません。ただし、スキーマを定期的に比較して、無計画なスキーマの変更が適用されないようにすると効果的です。
- 保守作業が完了するまで同期しない ─ 保守作業を行うために、一時的なスキーマの変更を適用しなければならない場合があります。たとえば、ジオメトリック ネットワークを削除し、バージョン対応登録を解除した後、再びジオメトリック ネットワークを構築し、バージョン対応登録しなければならない場合があります。ネットワークが再びバージョン対応登録されない限り、データの同期は失敗します。
- システム全体にスキーマの変更を適用する ─ スキーマの変更を適用する必要がある場合は、それらの変更をシステム全体に組織的に適用します。たとえば、トップ ダウン方式を使用して、ルート レプリカから順に変更を適用していくことができます。
