生活をシンプルに：レプリカでのスキーマ変更の取り扱い

TinaMorgan1

<\/HEAD>

サポートアナリストとして、さまざまな楽しい問題をレビューする機会があります。これらの問題は、ユーザーの環境、データ、ワークフローなどに特有のものかもしれません。時には、単一のワークフローに関連する問い合わせが急増することがあります。 このような場合、ユーザーが利用できるリソースを再確認し、ドキュメントがワークフローの実行方法を明確に説明していることを確認します。<\/P>

最近コールセンターで見られるこれらのワークフローの問題の一つは、レプリカでのスキーマ変更の取り扱いです。 例えば、レプリカを作成した後で、特定のフィーチャクラスにフィールドを追加する必要があることに気づいたり、もはや不要なドメインを削除したりする場合です。 このブログでは、このワークフローをより直感的にし、レプリカの達人たちがスキーマ変更に効率的に対処できるようにいくつかのコツを紹介します。<\/P>
振り返ってみましょう: レプリカが作成されると、複製されるオブジェクトのデータとスキーマは親ジオデータベースと子ジオデータベースに登録されます。 データはテーブル内の行として定義され、GlobalId値を親と子のリンクとして使用し、一方スキーマはフィールド、ドメイン、サブタイプ、および複製されたデータを記述するその他のプロパティで構成されます。 ArcMapのDistributed Geodatabaseツールバーを使用してレプリカを作成し、「既存データのみ登録」オプションを使用した場合、レプリカは作成時に異なるスキーマを持つ可能性があります。 これは一部の組織でこの図式が必要とされているため許容されており、レプリカ作成者が自身のニーズに合わせてデータを準備してからレプリカを作成する責任があります。

理想的には、レプリカ作成時には両方のレプリカでスキーマは同一ですが、時間が経つにつれて各レプリカスキーマに変更が加えられることがあります。例えば、一方のレプリカではプロジェクト完了のために追加フィールドが必要であり、もう一方では既存フィールドに新しいドメインを適用する必要がある場合です。このような場合、レプリカ間でスキーマはもはや同じではありません。 繰り返しますが、親ジオデータベースと子ジオデータベースでスキーマが同一である必要はありません。しかし、その違いが意図されたものでない場合は予期しない動作が発生する可能性があります。

複製されたデータにスキーマ差異があると何が起こるでしょうか?

• 同期しない編集<\/STRONG>- データ同期は両方のレプリカに共通するテーブルとフィールドのみ変更をインポートします。注意: 同期時にスキーマが一致しない場合でも、そのデータは相対レプリカへ送信済みとしてフラグ付けされます。レプリカはスキーマ一致を要求しませんが、一致するスキーマ（例えばフィールド）が相対レプリカ側になくてもすべての編集は同期中に同期済みとしてマークされます。<\/EM><\/EM><\/LI><\/UL><\/LI>無効な値<\/STRONG> - ドメイン違反、サブタイプ違反、接続ルール違反、およびリレーションシップルール違反となる変更も同期時に適用されます。エディタ上の <\/STRONG>検証ツール<\/A><\/STRONG>で新しくインポートされた値をチェックできます。<\/LI>データ同期エラー - <\/STRONG>これは両方のレプリカに手動でスキーマ変更を加えた場合に発生します。例えばテーブルにフィールドを追加したい場合です。この際は必ずすべての場合で全く同じスキーマ変更を行ってください。一方では文字列型だが他方では整数型というような違いがあるとデータ同期エラーになります。<\/A>

  レプリカ間でフィールドタイプ不一致による同期エラー。<\/P><\/DIV><\/LI><\/UL>

  • サポートされていない変更 - <\/STRONG>一部のスキーマ変更は同期失敗を引き起こす可能性がありますが、その変更時には警告が表示されません。これらの変更はジオデータベース複製システムでは検出できません。例としてはデータベース内テーブルへの権限変更などのデータベースレベル操作があります。複製されたデータへの権限が読み取り専用に変更された場合、相対レプリカから変更をインポートすると失敗します。<\/LI><\/UL>レプリカ間でスキーマ変更を適用する - <\/STRONG>相対レプリカのスキーマと一致させるためにレプリカのスキーマを修正することは、データ同期とは完全に別個のプロセスです。 上記で説明した予期しない動作と思われる場合には以下のツールをご利用ください。
    
    3つのツールが提供されており、レプリカスキーマ更新に使用します:
  Export Replica Schema<\/A> <\/STRONG>- スキーマを適用したい相対レプリカ側ジオデータベースからスキーマをエクスポートするために使用します。通常は切断環境やスクリプト処理向けです。<\/LI>Compare Replica Schema<\/A><\/STRONG> - レプリカ内2つのジオデータベース間の差異検出に使用します。 これは常に変更適用先ジオデータベース側から実行します。 接続環境下で作業する際の最初のステップです。<\/LI>Import Replica Schema<\/A> <\/STRONG>- レプリカ比較中に見つかった差異を変更適用先ジオデータベースへインポートするために使用します。<\/LI><\/OL>
  これらツールはCatalogツリー内Distributed Geodatabase右クリックコンテキストメニュー、ArcMap内Distributed Geodatabaseツールバー、およびジオプロセシングツールとして利用可能です。
  <\/A>

  ArcCatalog内Distributed Geodatabase右クリックコンテキストメニュー<\/P><\/DIV>

  ArcMap内Distributed GeodatabaseツールバーData Management ジオプロセシングツール
  
  これら3つの方法には非常にわずかな違いがあります。例えばArcCatalogからDistributed Geodatabase右クリックメニューおよびArcMap内Distributed Geodatabaseツールバー上のImport Replica Schemaウィザードではユーザーが適用または非適用を選択できる変更一覧が表示されます。一方ジオプロセシングツール（主に切断環境や自動化されたスクリプト処理向け）では表示されません。
  
  最後に ジオプロセシングツールは通常3段階（Export, Compare, Import）のプロセスで使われ、この処理が定期タスクの場合によく使われます。一方ArcMap内Distributed GeodatabaseツールバーおよびDistributed Geodatabase右クリックコンテキストメニューは接続環境下で2段階（Compare, Import）だけで使えます。
  
  Export Replica Schemaステップ省略によって時間短縮できますが、どちらのジオデータベーススキーマを入力とすべきか不明な場合やどんな変更が伝播しているか疑問の場合には3段階ジオプロセシングツール方式がより直感的だと思います。一番目のツールは常にExport Schema Changesジオプロセシングツールです。このツールは入力ジオデータベース（相対レプリカへ伝播したいスキーマ保持側）ひとつだけ受け取り単一XMLファイル出力を生成します。
  
  さて次にCompare Replica Schemasジオプロセシングツールを実行します 私たちの入力は相対的なジオデータベースと、先ほど作成したXMLファイルです。 Compare Replica Schema Geoprocessingツールの出力は単一のXMLファイルです。 最後に、3番目のステップとしてImport Replica Schemaを実行します。 入力はジオデータベースで、Export Replica Schemaツールに入力したものに相対的なものであり、先ほど作成したcompare.XMLです。 ジオプロセシングツールは認識されたスキーマの違いを一覧表示する整理されたUIを持っていませんが、この方法は変更がどこから取られ、どこに送られているかについての混乱を明確にすることができます。リソースドキュメントを参照してください:<\/STRONG>Working With Schema Changes<\/A><\/STRONG><\/STRONG><\/LI>Schema Changes<\/A><\/STRONG><\/STRONG><\/LI><\/UL>Tina M. - Geodata Support Analyst<\/EM>
  
  
  
  <\/BODY><\/HTML>

Raj-Chavada

I am looking to simply my life in ArcGIS Pro 2.7.1  while managing schema changes in replica. Any clues or suggestions? I don't see the same tools that we have in ArcMap.