データ分散のシナリオ

Standard または Advancedのライセンスで利用可能。

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

レプリカ ツリー

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

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

データ分散のシナリオで考えられる階層構造

中央ハブ

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

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

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

モバイル ユーザー

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

ヒント:

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

データ分散のシナリオで考えられるモバイル ユーザーまたは現場作業者

契約業者

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

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

データ分散のシナリオで考えられるサードパーティの契約業者の読み取り専用アプローチ

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

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

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

データ分散のシナリオで考えられるマスター/公開用構造

データ分散のシナリオで考えられるマスター/公開用構造

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

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

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

データ分散のシナリオで考えられる複数のグループによるデータ管理構造

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

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

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

データ分散のシナリオで使用される、多くのソースからのデータの一元化の例