スキーマの変更の操作

このトピックは、ArcEditor および ArcInfo にのみ適用されます。

レプリカを作成すると、親ジオデータベースからデータとスキーマが子ジオデータベースへコピーされます。このデータには、レプリカのデータセットから複製される行が含まれています。スキーマは、フィールド、ドメイン、サブタイプ、およびその他のプロパティなどの複製されるデータの情報で構成されます。

初期状態では、スキーマはどちらのレプリカでも同じですが、各レプリカのスキーマに変更が加えられる可能性があります。たとえば、一方のレプリカではプロジェクトを完了するための追加フィールドが必要で、相対レプリカでは既存のフィールドに新しいドメインを適用する必要があるとします。この場合、両方のレプリカのスキーマはもはや同じではありません。

次に、レプリカ間のスキーマの違いに対処する方法について説明します。

スキーマの違いを維持 — 他のレプリカとレプリカのスキーマの変更の同期をとらずに、独自にレプリカのスキーマを変更することが可能です。ジオデータベース レプリケーションは、レプリカ間のスキーマの違いを基本的に許容するように設計されているので、ほとんどの場合、データの同期は引き続きうまく機能します。

ただし、スキーマの変更を一方のレプリカに適用し、もう一方のレプリカに適用しない場合には、次のような問題が予測されます。

レプリカ間のスキーマ変更の適用 — レプリカのスキーマを相対レプリカのスキーマと一致するように変更することは、データの同期とはまったく別のプロセスです。スキーマ変更の適用のために、[レプリカ スキーマの比較]、[レプリカ スキーマのインポート]、[レプリカ スキーマのエクスポート] という 3 つのツールが提供されています。これらのツールは、ArcMap の [分散ジオデータベース] ツールバーか、カタログ ツリーの [分散ジオデータベース] サブメニューで、またはジオプロセシング ツールとして使用できます。

これらのツールは 2 段階のプロセスで使用します。まず、[レプリカ スキーマの比較] ツールを実行してスキーマ変更を格納する XML ファイルを生成し、次に [レプリカ スキーマのインポート] ツールを使用して、これらの変更をインポートします。非接続環境で操作している場合は、最初に [レプリカ スキーマのエクスポート] ツールを使用して、変更を含むスキーマを XML ファイルにエクスポートします。このファイルを CD や DVD などのメディアなどを使用して相対レプリカの環境に移して、[レプリカ スキーマの比較] ツールへの入力データとして使用することができます。

次に、スキーマの変更とそれらがレプリカに適用可能かどうかを示します。

追加

変更

削除

フィールド

◎(ドメイン)

ドメイン

テーブル/フィーチャクラス

◎(ドメイン、フィールドの追加/削除)

ジオメトリック ネットワーク

×

×

トポロジ

×

×

フィーチャ データセット

×

×

リレーションシップ クラス

×

◎(フィールドの追加/削除、ドメイン)

次の表は、複製されたデータセットに対して実行されるスキーマ変更について示しています。

レプリカへのフィーチャクラスまたはテーブルの追加は、上で示したツールでは実行できません。ArcObjects を使用したコードを実行する必要があります。サンプル コードはこちらをご参照ください。

レプリカからのデータの削除 ─ 各レプリカに含まれるデータセットのリストは、レプリカ ジオデータベースに格納されます。これらのデータセットの 1 つを削除すると、警告が表示されます。削除を続行した場合、そのデータセットはレプリカのデータセット リストから削除されます。ArcObjects API を使用して、データを再びレプリカに追加することができます。次の注意事項も参照してください。

スキーマの違いの特定スキーマの変更を厳重に監視したい場合は、これらのツールを使用してレプリカのスキーマを比較し、違いを特定することができます。[レプリカ スキーマのインポート] ウィザードで、スキーマの違いが表示されます。

Web アプリケーションを作成するためのガイドライン

一般に、スキーマの変更は避けるべきです。スキーマの変更は、レプリカ間で一貫性が失われる原因となり、スキーマの変更を適用するための余分なタスクのせいで、パフォーマンスに悪影響がおよびます。ただし、スキーマの変更を適用しなければならない場合もあります。

次に、スキーマの変更に対処するための方法を示します。

  1. システムをロック ダウンする ─ システムを使用するユーザが適切な権限で作業していることを確認します。列の追加や削除といった、無計画なスキーマの変更を実行できないアプリケーションの設計が必要になることもあります。
  2. 定期的にスキーマを比較する ─ レプリケーションはフォールト トレランスなので、ほとんどの場合、同期を実行するシステムはスキーマの変更によって中断されません。ただし、スキーマを定期的に比較して、無計画なスキーマの変更が適用されないようにすると効果的です。
  3. 保守作業が完了するまで同期しない ─ 保守作業を行うために、一時的なスキーマの変更を適用しなければならない場合があります。たとえば、ジオメトリック ネットワークを削除し、バージョン対応登録を解除した後、再びジオメトリック ネットワークを構築し、バージョン対応登録しなければならない場合があります。ネットワークが再びバージョン対応登録されない限り、データの同期は失敗します。
  4. システム全体にスキーマの変更を適用する ─ スキーマの変更を適用する必要がある場合は、それらの変更をシステム全体に組織的に適用します。たとえば、トップ ダウン方式を使用して、ルート レプリカから順に変更を適用していくことができます。
スキーマの変更

7/10/2012