分散データのシナリオ

ジオデータベース レプリケーションは、トラディショナル バージョニングの機能をベースに、さまざまなワークフロー オプションをサポートします。次に、ジオデータベース レプリケーションを使用して実現可能なシナリオをいくつか紹介します。

レプリカ ツリー

ジオデータベース レプリケーションを使用して、バージョン ツリーと同様のレプリカ ツリーを作成し、階層構造の複数のジオデータベースにデータを分散させることができます。

たとえば、組織全体の情報を格納したジオデータベースを複数の支社に複製するとします。各支社は、担当地域に該当するデータだけで構成されたレプリカ (複製) を持ち、そのデータの変更を本社に転送することができます。これにより、本社オフィスでは全地域にわたって最新のデータで解析を行うことができます。また、オフィス内接続はオフィス間接続より速い、というメリットもあります。本社のジオデータベースが支社に複製されるのと同じ方法で、支社のジオデータベースをさらに各支店に複製することもできます。

可能な分散データ シナリオとしての階層構造

中央ハブ

レプリカ ジオデータベースは、読み取りユーザーと編集ユーザーをホストするための中央ハブとして使用することができます。接続速度を高速に維持するために、編集ユーザーは中央ハブからデータをチェックアウトしてレプリカを作成し、編集を実行した後、変更をチェックインしてジオデータベースと同期させることができます。

中央ハブを使用して、複数の子レプリカ間で変更を伝達することもできます。レプリカ間で変更を移動するには、まず、1 つ目のレプリカの変更を親 (ハブ) レプリカと同期させます。次に、2 つ目の子レプリカを親レプリカと同期させ、これらの変更を取得することができます。

可能な分散データ シナリオとしての中央ハブ構造

モバイル ユーザー

保守担当者といった組織内のモバイル ユーザーは、エンタープライズ ジオデータベースの一部のデータを現場で編集する必要があります。モバイル ユーザーは組織のインフラストラクチャから完全に切断された状態で編集を行わなければならず、多くの場合はそれが長時間におよびます。このような場合、特定の作業やプロジェクトへの準備の際に、レプリカを作成し、関連データをノート パソコンなどの携帯機器に転送します。携帯機器はネットワークから切断され、モバイル ユーザーがネットワークに接続せずに作業を行います。モバイル ユーザーは、ネットワークに接続していない状態でも、転送されたデータを引き続き操作することが可能であり、 ネットワークとの接続が再確立されたときに、データへの変更を転送し、エンタープライズ ジオデータベースのデータとマージすることができます。

ヒント:

このシナリオでは、フィールドのユーザーごとに操作対象として独自のレプリカを設定することをお勧めします。同時に多くのユーザーが同期を行う場合、ユーザーごとに独自のバージョンを設定し、そのバージョンからレプリカを作成することをお勧めします。これにより、同期プロセスが簡素化され、データ収集の競合が発生しなくなります。

可能な分散データ シナリオとしてのモバイル ユーザーまたは現場スタッフ

契約業者

組織によっては、ジオデータベースの一部について外部業者と保守契約を結び、ジオデータベースを数か月おきに更新してもらう必要があります。この場合は、データ全体を再インポートするのではなく、契約業者が行った変更のみをジオデータベースに統合できなければなりません。また、データセット全体の品質テストを実施するのではなく、その月の更新だけを確認するための簡単な方法も必要です。

これを実現するには、更新用の適切なデータが含まれたレプリカを契約業者に送信します。契約業者が変更を返送してきたら、エンタープライズ ジオデータベースで管理されているデータと同期させることができます。

可能な分散データ シナリオとしてのサードパーティ契約業者の読み取り専用アプローチ

マスター ジオデータベースと公開用ジオデータベース

組織は、編集ユーザーのグループだけでなく、読み取り専用でシステムにアクセスするユーザーもサポートする必要があります。各グループの要件を満たすためには、2 つのエンタープライズ ジオデータベースが必要です。1 つは編集ユーザーが直接編集するマスター ジオデータベース、もう 1 つはこのジオデータベースのレプリカで、読み取りユーザーがアクセスします。読み取りユーザーは、ArcGIS Enterprise を介してこのデータにアクセスします。

このシナリオでは、公開用ジオデータベースのレプリカは、マスター ジオデータベースの読み取り専用のコピーです。公開用ジオデータベースのデータは、バージョン対応登録されている必要はありません。レプリケーションは、データを一方向でのみ送信するように制限できます。編集は、マスター ジオデータベースで実行され、公開用ジオデータベースに送信されます。これらの編集は、公開用ジオデータベースのデータと同期された後、読み取りユーザーに提供されます。

可能な分散データ シナリオとしてのマスター/公開用ジオデータベース構造

複数のグループによるデータ管理

組織では、データの管理が複数のグループに分割されることがあります。たとえば、物理的アセットの管理を担当するグループと、同じ地域の土地データの管理を担当するグループがある場合です。別の例としては、組織内の複数の独立したプロジェクトに異なるチームが従事している場合が挙げられます。各プロジェクトのデータセットの大部分は地理的に異なる地域のデータですが、組織にはすべてのプロジェクトの中央リポジトリが必要です。

組織は、ジオデータベース レプリケーションを使用して、さまざまなグループ間にデータを分散させ、データを適切なプロジェクトに振り分けることができます。各プロジェクト チームは、中央のエンタープライズ ジオデータベースからの必要なデータが含まれたレプリカを受け取ります。そして、それぞれのレプリカを独立した状態で編集し、編集内容を中央のエンタープライズ ジオデータベースへ転送します。その一方で、中央のエンタープライズ ジオデータベースに対する編集も、プロジェクト チームの適切なレプリカへ転送されます。

可能な分散データ シナリオとしての、複数のグループによるデータ管理

多くのソースからの一元化されたデータ

もう 1 つのレプリケーションの実行例として、一元的な場所にデータを収集する方法があります。この方法でレプリケーションを利用する組織では、他の支社からのデータを収集して中央のジオデータベースに集約します。

このシナリオの例としては、各地方の機関と国の機関の間のデータ分散が挙げられます。各地方の機関は独立して業務を行っており、独自のデータセットを管理し、定期的に更新データを国の機関に送信しています。各地方で編集された内容は、国のジオデータベースにある 1 つの包括的なデータセット内で同期されます。この、子から親へのレプリケーション構成では、国のジオデータベースに親の役割が割り当てられ、各地方のジオデータベースに子の役割が割り当てられます。

可能な分散データ シナリオとして使用される場合の、多くのソースからのデータの一元化の例

関連トピック