データの準備
まず、文化部門と観光部門間のデータ配布方法として、他のタイプのレプリカよりも双方向レプリカが最適なソリューションであることを確認します。 次に、データをダウンロードし、両部門のエンタープライズ ジオデータベースに接続して、文化データがレプリケーション向けに正しく構成されていることを確認します。
双方向レプリカを使用する理由
ジオデータベース レプリケーションは、複数の位置やジオデータベース間で空間データを管理し、分散する際に便利です。 ソース ジオデータベースのデータのレプリカ (コピー) を作成し、それらのレプリカをターゲット ジオデータベースに転送する手順を行います。 レプリカの利点の 1 つとして、ソース データと定期的に同期されることが挙げられます。 同期とは、ソース データに加えた変更がレプリカ データにも反映されることを意味し、頻繁に更新されるデータの管理にも便利です。
一方向、双方向、チェックアウト/チェックインの 3 種類のジオデータベース レプリケーションがあります。 どのタイプを使用するかは、データの格納方法、データの配布方法、データの編集要件によって異なります。
このチュートリアルでは、観光部門と文化部門間でのレプリカを取り上げます。 ここで使用するレプリカのタイプは、双方向レプリカです。
文化部門と交通部門で使用するレプリケーションのタイプとして、双方向レプリカが最適である理由 ワークフローの次の側面を考慮に入れます。
- 両部門とも、エンタープライズ ジオデータベースにデータを格納しています。
- 文化部門は観光部門にデータを共有する必要があります。
- 観光部門は、文化部門がデータ クリーニング処理を行えるよう支援します。 この処理により、データを一般公開する前にデータの正確度を担保できるようになります。
- 両部門とも、データへの編集アクセス権が必要です。
双方向レプリケーションでは、親レプリカから子レプリカ、および子レプリカから親レプリカにデータ変更を繰り返し送信できます。 両方のレプリカ ジオデータベースで同じデータが編集された場合には、レプリカを同期する際に競合が検出されます。 競合は、いずれかのレプリカ ジオデータベースを優先することで自動的に解決されるか、バージョニングを使用して手動でレビューできます。
データのダウンロード
このワークフローでは双方向レプリケーションが最適であることがわかったので、このチュートリアルで使用されるデータを含む ArcGIS Pro プロジェクト パッケージをダウンロードして開きます。
注意:
このチュートリアルでは、各自のエンタープライズ ジオデータベースを使ってワークフローを実施します。 ArcGIS Server がインストールおよび認証されていること、Microsoft SQL Server (または別のサポートされているリレーショナル データベース管理システム) がインストールされていることを確認してください。 これらのコンポーネントのインストールに関する詳細については、「ArcGIS Enterprise の基本デプロイメント」ドキュメントと「はじめての ArcGIS Enterprise Builder」チュートリアルをお読みください。
- Tourism_and_Culture プロジェクト パッケージをダウンロードします。
- コンピューター上で、ダウンロードしたファイルを選択します。
注意:
お使いの Web ブラウザーによっては、ダウンロードを開始する前に、ファイルの場所を選択するよう求めるメッセージが表示される場合があります。 ほとんどのブラウザーでは、デフォルトでコンピューターのダウンロード フォルダーがダウンロード先の場所になります。
- コンピューターに ArcGIS Pro がインストールされている場合は、[Tourism_and_Culture.ppkx] をダブルクリックしてプロジェクトを開きます。 サイン インを求められたら、ライセンスが割り当てられた ArcGIS アカウントを使用してサイン インします。
注意:
ArcGIS Pro へのアクセス権限または組織アカウントがない場合は、ソフトウェア アクセスのオプションをご参照ください。
プロジェクトには、レプリケーションに参加する部門ごとに [Culture] と[Tourism] の 2 つのマップがあります。 これらのマップはアルゼンチンのブエノス アイレスにズームしますが、ベースマップ以外のデータは含まれていません。
プロジェクトには、プロジェクト ジオデータベースのデータも含まれています。
- [カタログ] ウィンドウで [データベース] を展開し、[tourism_and_culture.gdb] を展開します。
データベースには、[Libraries]、[Museums]、[Religious_sites] の 3 つのフィーチャクラスが含まれています。 このチュートリアルでは、文化部門が管理するこれらのデータセットを観光部門のマップで使用します。
エンタープライズ ジオデータベースへの接続
現在、データはファイル ジオデータベースに格納されています。 双方向レプリケーションは、親データベースと子データベースがエンタープライズ ジオデータベースである場合にのみ行えるので、これらのデータを移動する必要があります。
エンタープライズ ジオデータベースは ArcGIS Enterprise を使用します。 追加の機能とデータセット タイプが提供されるほか、データから公開されたフィーチャ サービスとの同期も行えます。
まず、文化部門で使用されるエンタープライズ ジオデータベースを作成するか、そこに接続します。 ファイル ジオデータベースのデータをコピーします。 次に、観光部門で使用されるエンタープライズ ジオデータベースを作成するか、そこに接続します。
- 必要であれば、SQL Server (またはサポートされている別のリレーショナル データベース管理システム) のインスタンスに、[Culture_BA] というエンタープライズ ジオデータベースを作成します。
注意:
エンタープライズ ジオデータベースがすでに存在する場合は、新規作成する代わりに使用できます。 新しいエンタープライズ ジオデータベースを作成する方法については、「不動産用エンタープライズ ジオデータベースのデプロイ」チュートリアルの「エンタープライズ ジオデータベースの作成」セクションをご参照ください。
次に、エンタープライズ ジオデータベースに接続します。
- [カタログ] ウィンドウで [データベース] を右クリックし、[新しいデータベース接続] を選択します。
[データベース接続] ウィンドウが表示されます。 エンタープライズ ジオデータベースに接続するために使用するパラメーターは、SQL Server またはリレーショナル データベース管理システム (RDBMS) インスタンスによって異なります。
- [データベース プラットフォーム] で、インスタンスで使用される RDBMS を選択します。 [インスタンス] で、RDBMS インスタンス名を入力します。
注意:
サンプル画像では、BASQL という SQL Server インスタンスを使用しています。実際のインスタンスは異なります。
- [認証タイプ] で、[データベース認証] を選択します。
- [ユーザー名] と [パスワード] に、エンタープライズ ジオデータベースのデータにアクセスし、データを読み込むことができるアカウントの認証情報を入力します。
このユーザーが、文化部門のエンタープライズ ジオデータベースのデータ所有者になります。 通常のワークフローでは、このユーザーはジオデータベース ユーザーおよびデータベース管理者ユーザーとは異なります。
注意:
サンプル画像では、ユーザー名は BRUNO です。実際のユーザー名は異なります。
- [データベース] で、作成した [Culture_BA] エンタープライズ ジオデータベース (または、このチュートリアル用にアクセスでき、変更を加えることができる別のエンタープライズ ジオデータベース) を選択します。
- [OK] をクリックします。
エンタープライズ ジオデータベースが [カタログ] ウィンドウに追加されます。 デフォルトでは、データベース名はインスタンスと同じ名前になります (たとえば、サンプル データベースの名前は BASQL.sde です)。データベースの名前を、データベース名_データベース ユーザー.sde の形式になるよう変更します。
- [カタログ] ウィンドウで、エンタープライズ ジオデータベースを右クリックして [名前の変更] を選択します。 名前を「Culture_BA_[データベース ユーザー名].sde」に変更します。
注意:
サンプル画像では、ユーザー名は BRUNO なので、エンタープライズ ジオデータベース名は Culture_BA_BRUNO_sde になります。 実際のユーザー名は異なります。
次に、ファイル ジオデータベースのデータをエンタープライズ ジオデータベースにコピーします。
- [Libraries]、[Museums]、[Religious_sites] の各フィーチャクラスを [tourism_and_culture.gdb] から [Culture_BA.sde] にドラッグします。
ヒント:
Ctrl キーを押しながら各フィーチャクラスをクリックして 3 つすべてのフィーチャクラスを一度に選択し、ドラッグすると 3 つとも同時にコピーできます。
- [Culture_BA.sde] を展開してコンテンツを表示します。
データがコピーされました。 コピーの先頭には、データの所有者名が付きます。 サンプル画像では、データ所有者は BRUNO というアカウントです。実際のユーザー名は異なります。
- [tourism_and_culture.gdb] を折りたたみます。
次に、観光部門で使用されるエンタープライズ ジオデータベースに接続します。 双方向レプリケーションでは、子データベースもエンタープライズ ジオデータベースである必要があります。
- 必要であれば、SQL Server (またはサポートされている別のリレーショナル データベース管理システム) のインスタンスに、[Tourism_BA] というエンタープライズ ジオデータベースを作成します。
- [カタログ] ウィンドウで [データベース] を右クリックし、[新しいデータベース接続] を選択します。
- [データベース接続] ウィンドウで、作成した Tourism_BA ジオデータベース (またはこのチュートリアル用にアクセスでき、変更を加えることができる別のエンタープライズ ジオデータベース) に接続するために適切なパラメーターを設定します。
- [OK] をクリックします。
- 新しいデータベース接続の名前を「Tourism_BA_[データベース ユーザー名].sde」に変更します。
サンプル画像では、tourism データベースのユーザー名は EMMA です。実際の名前は異なります。
これで、2 つのエンタープライズ ジオデータベースが接続されました。 片方は文化部門が管理するエンタープライズ ジオデータベースで、市内の文化施設に関するデータが格納されています。 もう 1 つは観光部門が管理するエンタープライズ ジオデータベースで、まだ何も格納されていません。
Global ID の有効化
次に、文化部門のデータのレプリケーションを準備します。 まず、データベース接続で、ブランチ バージョニングではなくトラディショナル バージョニングを使用していることを確認します。 レプリカを編集するにはジオデータベースへのダイレクト コネクションが必要なので、ブランチ バージョニングではレプリケーションはサポートされていません。 次に、フィーチャクラスの Global ID を有効にします。 編集によってデータがバージョン対応になると、Global ID は同じデータの複数バージョンで行われた編集のマッピングに役立ちます。
- [カタログ] ウィンドウで[Culture_BA.sde] を右クリックし、[ジオデータベース コネクション プロパティ] を選択します。
- [ジオデータベース コネクション プロパティ] ウィンドウで [バージョニング タイプ] が [トラディショナル] に設定されていることを確認します。
- [ジオデータベース コネクション プロパティ] ウィンドウを閉じます。
次に、トラディショナル バージョニングを有効にし、3 つのフィーチャクラスのそれぞれに対して Global ID を有効にします。
- [カタログ] ウィンドウで [Libraries] を右クリックし、[管理] を選択します。
[フィーチャクラス プロパティ] ウィンドウが表示されます。
- [管理] タブで [バージョニング] をオンにして [トラディショナル] を選択します。 [Global ID] がオンになっていることを確認します。
- [OK] をクリックします。
- [Museums] フィーチャクラスと [Religious_sites] フィーチャクラスで [フィーチャクラス プロパティ] ウィンドウを開き、トラディショナル バージョニングを有効にして、Global ID が有効化されていることを確認します。
これで、3 つすべてのフィーチャクラスでレプリケーションの準備が整いました。
- [クイック アクセス ツールバー] で、[保存] ボタンをクリックして、プロジェクトを保存します。
ここまでの手順では、文化部門と観光部門間でデータを配布するレプリケーション タイプとして、双方向レプリカが最適であることを確認しました。 また、チュートリアルで使用するエンタープライズ ジオデータベースに接続し、データベース接続とフィーチャクラスをレプリケーションに向けて準備しました。
双方向レプリカの作成
次に、culture ジオデータベースと tourism ジオデータベース間で双方向レプリカを作成します。
レプリカの作成
レプリカを作成するには、ジオプロセシング ツールを実行します。
- [カタログ] ウィンドウで [Culture_BA.sde] を右クリックし、[分散ジオデータベース] をポイントして [レプリカの作成] を選択します。
[ジオプロセシング] ウィンドウが開き、[レプリカの作成] ツールが表示されます。 まず、レプリケーションを行うデータセットを設定します。
- [レプリカ データセット] で [参照] ボタンをクリックします。
- [レプリカ データセット] ウィンドウの [プロジェクト] で [データベース] を展開します。 [Culture_BA.sde] をクリックします。
- Ctrl キーを押しながら [Libraries]、[Museums]、[Religious_sites] をクリックして、3 つすべてを選択します。
- [OK] をクリックします。
データセットが [ジオプロセシング] ウィンドウのパラメーターに追加されます。
- [レプリカ タイプ] で [双方向レプリカ] を選択します。 [出力タイプ] が [ジオデータベース] に設定されていることを確認します。
次に、データが観光部門のデータベースに複製されていることを確認します。
- [複製したデータを格納するジオデータベース] で [参照] ボタンをクリックします。
- [複製したデータを格納するジオデータベース] ウィンドウの [プロジェクト] で [データベース] をクリックします。 [Tourism_BA.sde] を選択して [OK] をクリックします。
- [レプリカ名] に 「Culture_to_Tourism」と入力します。
- [実行] をクリックします。
ツールが実行され、レプリカが作成されます。
- [ジオプロセシング] ウィンドウを閉じます。
レプリカの探索
レプリカが作成されたので、次に、親データベースと子データベースの両方の観点からレプリカを調査します。
- [カタログ] ウィンドウで [Culture_BA.sde] を右クリックし、[分散ジオデータベース] をポイントして [レプリカの管理] を選択します。
[レプリカの管理] ウィンドウが表示されます。 ここには、先ほど作成した [Culture_to_Tourism] レプリカがリストされます。
- [Culture_to_Tourism] で、矢印をクリックしてレプリカを展開します。
レプリカに関する情報が表示されます。 レプリカ所有者は、レプリカを作成したデータベース ユーザーです (サンプル画像では BRUNO)。 情報には、データベースが親であるか子であるか、データの送信側であるか受信側であるかも含まれます。
このインスタンスでは、culture データベースが親であり、データの受信側です。 レプリカは双方向レプリカなので、ステータスが受信側として設定されていても、データベースはデータの送信と受信の両方を行えます。
- [レプリカの管理] ウィンドウを閉じます。
次に、データが子データベースに複製されたことを確認します。
- [カタログ] ウィンドウで、[Tourism_BA.sde] を右クリックして [更新] を選択します。
- [Tourism_BA.sde] を展開します。
3 つのフィーチャクラスが子データベースに正常に複製されました。
- [Tourism_BA.sde] を右クリックし、[分散ジオデータベース] にポイントして [レプリカの管理] を選択します。
- [レプリカの管理] ウィンドウで [Culture_to_Tourism] レプリカを展開します。
tourism データベースからレプリカの情報にアクセスすると、ロールが子であることと、ステータスがデータ送信側 (データ受信側ではない) であることが表示されます。 双方向レプリカを使用しているため、ステータスにかかわらず、データベースはデータの送信と受信の両方を行えます。
- [レプリカの管理] ウィンドウを閉じます。 [Tourism_BA.sde] 接続を折りたたみます。
- プロジェクトを保存します。
culture データベースと tourism データベース間で双方向レプリカを作成しました。 データが正常に複製されたことを確認し、親と子の両方の観点からレプリカを調査し、データ フローを評価しました。 これで、データの編集の同期の準備ができました。
変更の同期
ここまでの手順で双方向レプリカを作成したので、次に、データの同期の機能を活用します。 このワークフローでは、データを一般公開する前に、正確さを担保するために文化部門がデータをクリーニングするとします。 膨大な量のデータが存在するので、観光部門も支援を申し出ました。 しかし、両方の部門が同じデータを同時に編集するため、競合が発生します。
まず、両方のデータベースのデータを使用して編集を行います。 次に、変更を同期して、発生した競合を確認します。
データをマップに追加
Religious_sites フィーチャクラスのフィーチャの 1 つが複製されています。 あなたは、文化部門の GIS 専門家として、データを編集して重複するフィーチャを削除します。 まず、マップにデータを追加してシンボルを変更します。
- [Culture] マップがアクティブなマップであることを確認します。
- [カタログ] ウィンドウの [Culture_BA.sde] で [Religious_sites] を右クリックして [現在のマップに追加] を選択します。
フィーチャクラスがマップに追加されます (デフォルトのシンボルはこの画像例とは異なる場合があります)。
次に、シンボル表示を変更します。 時間を節約するために、プロジェクト フォルダーにレイヤー ファイルが含まれています。 これらのファイルからシンボルをインポートします。
- [コンテンツ] ウィンドウで [Religious sites] が選択されていることを確認します。
- リボンの [フィーチャ レイヤー] タブをクリックします。 [描画] グループで、[インポート] をクリックします。
[シンボルのインポート] ウィンドウが表示されます。
- [入力レイヤー] で [Religious sites] が選択されていることを確認します。 [シンボル レイヤー] で、[参照] ボタンをクリックします。
- [シンボル レイヤー] ウィンドウの [プロジェクト] で [フォルダー]、[Tourism_and_Culture]、[commondata] を展開します。 [userdata] をクリックします。
- [Religious_sites.lyrx] をクリックし、[OK] をクリックします。
ファイルがツール パラメーターに追加されます。
- [OK] をクリックします。
シンボルが適用されます。
文化部門のデータの編集
重複するフィーチャの位置に移動して、削除します。
- リボンの [マップ] タブをクリックします。 [ナビゲーション] グループで [ブックマーク] をクリックし、[Iglesia San Francisco] を選択します。
マップが、ブエノス アイレスの教会である Iglesia San Fransisco に移動します。 教会には、2 つのフィーチャが関連付けられているようです。
各フィーチャを調査し、詳細を把握します。
- マップ上で左側にあるフィーチャをクリックします。
ポップアップが表示されます。 このフィーチャの ID は 99 です。 特に注目すべきことは、このフィーチャの [Altura] (高さ) フィールドの値が 0 である点です。 この値は不正であるため、このフィーチャはおそらく誤っています。
- 他方のフィーチャをクリックします。
このポップアップには、重複する 2 つのフィーチャがあることが示されます。 1 つは ID が 27 で Iglesia San Fransisco を表し、正確な属性情報を持ちます。 もう 1 つは ID が 34 で Iglesia San Roque を表します。これは正しくありません。
2 つの不正なフィーチャを削除します。 また、正しいフィーチャの名前から「Basilica」という単語を削除して修正します。
- ポップアップを閉じます。
- リボンの [編集] タブをクリックします。 [選択] グループの [選択] ボタンをクリックします。
- マップで、ID が 99 のフィーチャ (左側のフィーチャ) をクリックします。
フィーチャが選択されました。
- リボンの [フィーチャ] グループで、[削除] をクリックします。
注意:
データの削除は完全な削除です。 フィーチャを削除する前に、データのバックアップを保存しておくことをお勧めします。 このチュートリアルでは、[tourism_and_culture] ファイル ジオデータベースにバックアップ コピーがすでに作成されています。
- データを本当に削除するかどうか確認されたら、[はい] をクリックします。
フィーチャが削除されます。
- マップで、残りの Iglesia San Fransisco フィーチャの周囲に四角形を描画し、そのフィーチャを選択します。
注意:
フィーチャはクリックせずに四角形で囲む必要があります。そうしなければ、2 つの重複するフィーチャのうち 1 つしか選択されません。
2 つのフィーチャは重複しているため、正しい方を確実に削除する必要があります。
- リボン上の [選択] グループで [属性] をクリックします。
- [属性] ウィンドウで [San Roque] を右クリックして [削除] を選択します。
注意:
San Fransisco オプションのみが表示され、San Roque オプションが見当たらない場合は、マップ上のフィーチャを四角形で囲み、重複する両方のフィーチャが選択されていることを確認します。
- データを本当に削除するかどうか確認されたら、[はい] をクリックします。
フィーチャが削除されます。 最後に、San Fransisco フィーチャの名前を編集します。
- [属性] ウィンドウで [San Francisco (Basilica)] が選択されていることを確認します。 [Nombre] で、名前から [(Basilica)] を削除して Enter キーを押します。
- このウィンドウの下部にある [適用] をクリックします。 [属性] ウィンドウを閉じます。
- リボンの [編集の管理] グループで [保存] をクリックします。
- [編集の保存] ウィンドウで [はい] をクリックします。
文化部門のデータベースのデータへの編集内容が保存されました。
観光部門のデータの編集
今回も同じフィーチャに編集を加えますが、ここでは tourism データベースのデータを使用します。 文化部門で加えられた変更が同期されていないため、観光部門のデータには新しい編集内容は含まれていません。
観光部門の編集内容は、文化部門による編集部門とは異なります。 変更を後から同期すると、2 つのデータセット間に競合が発生するため、解決する必要があります。
- [Tourism] マップをアクティブ化します。
- [カタログ] ウィンドウで [Tourism_BA.sde] データベース接続を展開します。 観光部門の [Religious_sites] フィーチャクラスを右クリックし、[現在のマップに追加] を選択します。
- 必要に応じ、[Religious sites] レイヤーで [Religious_sites.lyrx] を使用してシンボルをインポートします。
注意:
サンプル画像では、インポートされたシンボルを示しますが、シンボルをインポートしなくてもワークフローは続行できます。
- リボンの [マップ] タブをクリックします。 [ナビゲーション] グループで [ブックマーク] をクリックし、[Iglesia San Francisco] を選択します。
マップが対象地域にズームします。 文化部門のデータのコピーで、表示されているフィーチャの 1 つを削除しましたが、観光部門のコピーにはそのフィーチャがまだ存在します。
データを調べると、観光部門では、データの編集について文化部門とは異なる結論に達したことが判明しました。 文化部門では、属性情報が異なっていることから、左側のフィーチャ (フィーチャ 99) を削除しました。 対照的に、観光部門では右側のフィーチャ (フィーチャ 27) を削除します。ポイントがベースマップ上の教会の位置の中心に配置されていないからです。
しかし、観光部門は文化部門と同様に San Roque フィーチャを削除します。
- リボンで [選択] ボタンがアクティブなままであることを確認します。
- マップ上で、右側のフィーチャの周囲に四角形を描画し、そのフィーチャを選択します。
- リボンの [編集] タブをクリックします。 [選択] グループで、[属性] をクリックします。
- [属性] ウィンドウで Ctrl キーをクリックしながら [San Francisco (Basilica)] と [San Roque] をクリックして両方とも選択します。 いずれかのフィーチャを右クリックして [削除] を選択します。
- データを本当に削除するかどうか確認されたら、[はい] をクリックします。
両方のフィーチャが削除されます。 次に、残りのフィーチャの属性が正確になるよう編集します。
- マップ上で、残りのフィーチャをクリックして選択します。
- [属性] ウィンドウの [Altura] (高さ) に「380」と入力します。 [Tipo] (タイプ) に「Iglesia」と入力します。
- このウィンドウの下部にある [適用] をクリックします。 [属性] ウィンドウを閉じます。
- リボンの [編集の管理] グループで [保存] をクリックします。 [編集の保存] ウィンドウで [はい] をクリックします。
変更の同期
どちらの部門も、それぞれのデータのバージョンに対して編集を行いました。 次に、変更を同期して、他方の部門のデータ バージョンに編集を反映させます。
双方向レプリケーションでは、親 (culture) データベースと子 (tourism) データベースがどちらも変更を同期できます。 このシナリオでは観光部門が後から変更を加えたので、観光部門が同期を行います。
- [カタログ] ウィンドウで [Tourism_BA.sde] を右クリックし、[分散ジオデータベース] をポイントして [変更の同期] を選択します。
[ジオプロセシング] ウィンドウが開き、[変更の同期] ツールが表示されます。 ツール パラメーターが自動的に入力されます。 ジオデータベース 1 は変更を同期するデータベース (tourism データベース) で、ジオデータベース 2 は双方向レプリカに関与する他方のデータベース (culture データベース) です。
デフォルトでは、同期の方向は [双方向] です。 競合がある場合、同期を行うデータベースを優先して自動的に解決されます。 しかし、ここでは競合を手動で解決するため、自動的には同期を行いません。 そのため、パラメーターを調整します。
- [変更の同期] ツールの [方向] で [ジオデータベース 1 → ジオデータベース 2] を選択します。 [競合解決ポリシー] で [競合を手動で解決] を選択します。
- [実行] をクリックします。
ツールが実行されますが、警告ありで完了します。
- [同期の変更が警告とともに完了しました] で [詳細の表示] をクリックします。
ツール ウィンドウが表示されます。 警告には、同期は正常に実行されたが競合が検出されたことが示されます。 レプリカから変更をエクスポートする前に競合を解決する必要があります。
- ツール ウィンドウを閉じます。 [ジオプロセシング] ウィンドウを閉じます。
競合の解決
競合を確認するには、親データベースである Culture_BA.sde からバージョニングを管理します。
- [Culture] マップをアクティブ化します。
このマップのデータは、Culture_BA.sde から取得されています。
- [コンテンツ] ウィンドウで [データ ソース別にリスト] ボタンをクリックします。
データは、データのソースごとに整理されます。 マップには 3 つのデータ ソースがあります。2 つはベースマップ用、もう 1 つは文化部門のデータ用です。
- [Religious sites] レイヤーのデータベース接続をクリックし、選択します。
注意:
実際のデータベース接続の名前は、サンプル画像とは異なることがあります。
リボンで、コンテキスト対応の [バージョニング] タブが使用できるようになります。
- [バージョニング] タブをクリックします。 [バージョニング] グループで [バージョンの管理] をクリックします。
データベースの [バージョン] ビューが表示されます。 2 つのバージョンがあります。1 つは文化部門のデータベースに最初に接続したときに作成されたデフォルト バージョンです。もう 1 つは競合を格納するために自動的に作成された [Culture_to_Tourism_15] 相対レプリカバージョンです。 バージョン名はレプリカ名と同じであり、新しいバージョンの所有者は Culture_BA.sde への接続に使用したユーザー名になります (サンプル画像では BRUNO)。
データベースが使用しているバージョンを新しいバージョンに変更します。
- [バージョン] ビューを終了します。 必要に応じて [Culture] マップをアクティブ化します。
- [コンテンツ] ウィンドウで、[Religious sites] レイヤーのデータベース接続を右クリックし、[接続バージョンの変更] を選択します。
- [接続バージョンの変更] ウィンドウで、自分の名前が冒頭に付いた [Culture_to_Tourism] バージョンを選択します。
- [OK] をクリックします。
バージョンが変更されます。 [コンテンツ] ウィンドウで、[Religious sites] レイヤーのデータ ソースが [Culture_to_Tourism] バージョンに変わりました。 さらに、マップには、文化部門による編集ではなく、観光部門のデータ編集が表示されます。
次に、2 つのバージョン間の違いを比較し、リコンサイルします。
- リボンの [バージョニング] タブの [バージョニング] グループで [リコンサイル] をクリックします。
- [リコンサイル] ウィンドウで、デフォルト パラメーターをそのままにして [OK] をクリックします。 競合を確認するかどうかを示す警告ウィンドウで [はい] をクリックします。
[競合] ビューが表示されます。
- [競合] ビューで [Religious_sites] を展開します。 [削除‐更新] と [更新-削除] を展開します。
競合には 2 種類あります。 [削除‐更新] の競合には 27 という数字が示されています。これは、ID が 27 のフィーチャを表します。 この競合では、フィーチャ 27 は現在のバージョン (観光部門のバージョン) では削除されているが、ターゲット バージョン (文化部門のバージョン) では更新されたことを示しています。
反対に、[更新‐削除] の競合では、フィーチャ 99 が現在のバージョンで更新されているが、ターゲット バージョンで削除されたことを示しています。 San Roque フィーチャは両方のバージョンで削除されているので、競合はありません。
- [27] をクリックします。
現在のバージョン、ターゲット バージョン、共通の上位バージョン (元のデータ) のフィーチャの属性が表示されます。
競合を確認した後、文化部門ではターゲット バージョンが正しいと判断しました。 そのバージョンを優先して競合を解決します。
- [27] を右クリックし、[ターゲット バージョンで置換] を選択します。
- [27] を右クリックし、[確認済みとしてマーク] を選択します。
また、ターゲット バージョンを優先してフィーチャ 99 を解決します。
- [99] を右クリックし、[ターゲット バージョンで置換] を選択します。 [99] を右クリックし、[確認済みとしてマーク] を選択します。
次に、デフォルト バージョンに対する編集を行います。
- [競合] ビューを終了します。 リボン上の [バージョニング] タブで [ポスト] をクリックします。
このボタンをクリックすると、編集内容も保存されます。
競合を手動で確認し、保持する編集を決定したので、変更を同期して子データベースに反映します。
- [カタログ] ウィンドウで [Culture_BA.sde] を右クリックし、[分散ジオデータベース] をポイントして [変更の同期] を選択します。 [変更の同期] ツールで、次のパラメーターを変更します。
- [方向] で [ジオデータベース 1 → ジオデータベース 2] を選択します。
- [競合解決ポリシー] で [競合を手動で解決] を選択します。
- [実行] をクリックします。
今回は、ツールが実行されますが、競合は解決済みなので警告なしで完了します。
- [Tourism] マップをアクティブ化します。
これで、tourism マップには文化部門による変更内容が反映されます。
- プロジェクトを保存します。
このチュートリアルでは、文化部門が観光部門にデータを共有する手順を実行しました。 そのワークフローに最適なジオデータベース レプリケーションのタイプとして、双方向レプリカを特定しました。 次に、2 つのエンタープライズ ジオデータベース間でレプリカを作成しました。 最後に、データの両方のバージョンを編集し、変更を同期し、競合を解決しました。 この双方向レプリカにより、両方の部門が必要に応じてデータを更新し、正確さを担保できるようになります。
このチュートリアルでは、双方向レプリカを使用して、文化部門と観光部門間でデータを配布する方法を取り上げました。 このシリーズの他のチュートリアルでは、交通部門と小売部門間で一方向レプリカとチェックアウト/チェックイン レプリカを使用してデータを配布する方法を取り上げています。
他のチュートリアルについては、チュートリアル ギャラリーをご覧ください。