Standard または Advancedのライセンスで利用可能。
バージョニングは、さまざまなシナリオで適用でき、各組織のビジネス用件によって異なります。 ワークフロー編集時の一般的な注意事項と推奨のバージョニング構成を以下の図で説明します。
組織によってワークフローは異なります。 多くの場合、ワークフローは段階的に発展し、それぞれの段階で異なるリソースの割り当てやビジネス ルールが必要になります。 一般に、プロセス全体の各段階は、作業指示など、個々の作業単位を表します。 各作業指示を管理するために、個別のバージョンを作成して、それを編集することができます。 作業が完了したら、変更内容をデータベースのマスター バージョンに統合することができます。 バージョンをこのように操作すれば、最も基本的なワークフローから複雑なワークフローまで、柔軟に対応することができます。
バージョニングのコンセプトは、ブランチ バージョニング シナリオを使用する場合でも、トラディショナル バージョニング シナリオを使用する場合でも同じです。 バージョニングにより、データをコピーしなくても、データの複数のリプレゼンテーションを作成できるため、同時編集が可能になります。また、ユーザーは長期間にわたってバージョンを使用することができます。 詳細については、バージョニングの概要をご参照ください。
トラディショナル バージョニング - エンタープライズ ジオデータベースから直接アクセスした場合はロング トランザクションのバージョン内で柔軟に作業でき、フィーチャ サービスを使用してショート トランザクションに対応する場合は簡単に操作できます。
ほとんどの場合は、(複数の編集ユーザーがデフォルト バージョンを編集する) マスター データベース構成の同時編集か、またはその他の設定の組み合わせを使用します。 組織とビジネスの要件、および各設定のメリットと制限事項を理解すれば、組織に最適なトラディショナル バージョン シナリオを選択するのに役立ちます。
ジオデータベースの管理をより合理的に行うために、必要最低限の階層を持つバージョン ツリーを構成したり、複数の編集者でデフォルト バージョンを同時に編集したりするなどの方法をお勧めします。
デフォルト バージョンの編集
デフォルト バージョンは、データをトラディショナル バージョン対応として登録したときに作成される初期バージョンです。 トラディショナル バージョニングを使用しており、バージョン アクセスが [パブリック] に設定されている場合、複数の編集者がデフォルト バージョンを使用してデータを同時に編集し、表示できます。 マルチユーザー編集をサポートする最もシンプルな方法とは、複数の編集者がデフォルト バージョンを直接編集できるようにすることです。
各編集者がデフォルト バージョンの編集を開始すると、編集セッションごとに名前のないテンポラリ バージョンが自動的に作成されます。 このテンポラリ バージョンにアクセスできるのは現在の編集者だけです。 編集者が編集内容を保存する、または編集セッションを終了すると、テンポラリ バージョンに記録された変更内容がデフォルト バージョンにポストされます。
編集を開始した後に別の編集者がデフォルト バージョンを編集していた場合、編集内容を保存すると、ArcGIS が自動的にリコンサイルを実行し、変更をポストします。 DEFAULT バージョンが変更されていることが通知されるので、編集を適用する場合は、もう一度保存する必要があります。 競合 (コンフリクト) が存在する場合、編集内容を正常に保存するには、[競合] ダイアログ ボックスで競合を解決する必要があります。
検討事項
デフォルト バージョンを操作したり編集したりする場合には、次のメリットと制限事項に留意してください。
- メリット
- この方法では、ユーザーがデータを編集するための新しいバージョンを作成する必要がない、シンプルなデータベースの更新方法を実装できます。 作業単位が極めて小さい場合、または永続的な設計変更が不要である場合に適しています。
- 競合が存在しない場合、保存した編集内容は直接デフォルト バージョンにポストされます。
- 制限事項
- デフォルト バージョンが絶えず変更され、間違って変更されたり不正に変更されたりする可能性が高まります。このため、データベース管理者がより頻繁にデータベースのバックアップを作成する必要があります。
- 複数の編集セッションにまたがるロング トランザクションや設計案の作成などはサポートされません。
- ジオデータベースに対して実行できるリコンサイル処理は一度に 1 つだけです。 さまざまな編集セッションからリコンサイルとポストが頻繁に実行される場合、変更内容を保存する編集ユーザーは、実行中のリコンサイルとポストが完了するまで待機しなければならない可能性があります。 大規模なマルチユーザー ジオデータベースでは、多くのユーザーが共通バージョンに対してリコンサイル/ポストする状況は避けてください。 リコンサイルとポストはバージョンを排他的にロックします。 このロックが適用されている間、他のユーザーがリコンサイルポストを行うことはできません。
子バージョンの編集
複数のプロジェクト、作業指示、ジョブを管理している場合は、ワークフローを管理するための構造化された手法が必要です。 複数の編集セッション、および数日、数週間、数か月におよぶ個々の作業単位を、デフォルト バージョンに影響を与えずに管理する必要があります。 こうした作業単位の例としては、幹線道路の舗装計画、新しい電話サービスの導入、ガス パイプラインを継続的に管理するプロジェクトなどがあります。
トラディショナル バージョニングを使用する場合、作業指示またはプロジェクトが開始されると、デフォルト バージョンの子として新しいバージョンが作成されます。
作業指示またはプロジェクトが完了するまで、1 人以上の編集者がこのバージョンを操作することができます。 子バージョンへのすべての変更が完了したら、編集者または管理者がデフォルト バージョンに対してリコンサイルし、すべての競合を解決します。 その後、デフォルト バージョンへの変更内容がポストされ、変更内容が公開データベースに統合されます。 この時点で、子バージョンを削除することができます。
デフォルト バージョンへのユーザーのアクセス権限をこのワークフローに合わせて制限し、デフォルト バージョンが変更されないようにすることもできます。 管理者は、デフォルト バージョンの権限を [プロテクト] に設定することができます。この場合、ユーザーは引き続きデフォルト バージョンを参照できますが、アクセス レベルは読み取り専用に制限されます。 データを変更したい編集者は、新しい子バージョンを作成しなければなりません。
トラディショナル バージョニングを使用する場合、バージョン アクセスはデータベース ユーザーの権限と、バージョンに対して設定されたアクセス権レベル ([パブリック]、[プロテクト]、[プライベート]) の組み合わせによって決まります。
検討事項
子バージョンを操作または編集する場合、次のメリットと制限事項を考慮してください。
- メリット
- 単純さ - 各作業単位がシンプルなバージョン構造によって論理的に分離されます。
- 複数の編集セッションにまたがるロング トランザクションおよび代替設計の作成がサポートされるため、マスター データベースに影響を与えずに提案を策定することができます。
- デフォルト バージョンから新しいバージョンを作成すると、マスター データベースが想定外の変更から保護されます。 個々の作業プロジェクトが完了すると、それらはマスター データベースに統合されます。
- バッチ リコンサイルとポスト プロセスがサポートされます。
- 制限事項
- 他の多層バージョン設定と同様に、バージョンの差分テーブルで管理する行の数が増えるにつれ、バージョンのクエリ パフォーマンスに与える影響は大きくなります。 このオーバーヘッドを最小限に抑えるには、データベースを定期的に圧縮し、DBMS の統計情報を更新します。
編集者と閲覧者のサポート
組織において、編集者のグループや、読み取り専用アクセス権でシステムにアクセスするユーザーをサポートする必要がある場合、編集者は「子バージョンの編集」に記載のトラディショナル バージョニング ワークフローを実施する必要があります。 デフォルト バージョンにポストされた変更内容に読み取り専用ユーザーがすぐにアクセスする必要がない場合は、それらのユーザー用に、保護された静的バージョンをデフォルト バージョンから作成することができます。 このバージョンは、データベースが圧縮され、インデックスと統計情報が再構築された後に作成する必要があります。 そうすると、読み取り専用バージョンを表すために必要なすべての行が差分テーブルからベース テーブルに移行され、データベースのパフォーマンスが最適化されます。 このシナリオでは、読み取り専用ユーザーのデータベース バージョンは変更されないので、バージョンの差分を検索する必要はなく、データベースの統計情報やインデックスが古くなる、または断片化することはありません。 データベースの定期的な圧縮の後、このバージョンを再作成して、読み取り専用ユーザーが最後のデータベース圧縮以降の変更にアクセスできるようにします。
分散データ管理
組織内でバージョン対応データを分散し、さまざまなワークフローを簡素化するには、いくつかの方法があります。
ジオデータベース レプリケーション
ジオデータベース レプリケーションは、ジオデータベースまたはジオデータ サービスと直接連動し、同期状態を維持するためのワークフローをサポートします。 ジオデータベース レプリケーションを実行するためのツールは、ArcGIS Desktop と同様に、ArcGIS Pro でも提供されています。 ほとんどのワークフローには、トラディショナル バージョン対応データが必要です。
たとえば、一部のプロジェクトでは、2 つ以上のオフィスで同じデータを整備する必要があります。 どのオフィスでもデータベースへのローカル アクセスが必要なので、それぞれがデータベースのコピーを作成します。 あるオフィスでデータを変更した場合は、変更内容を別のオフィスのデータに適用する必要があります。 データベースのコピーを同期のとれた状態に保つために、オフィス間で定期的に変更内容を転送することができます。 この機能は、ジオデータベース レプリケーションと呼ばれます。
レプリケーションは、本来なら低速なネットワークでデータを編集しなければならない編集者にも役立ちます。 この場合、レプリケーションを行うことでデータのサブセットをローカルのコンピューターに抽出できるようになるため、編集者はネットワークを使用しなくても作業を行えます。 編集が終了したら、変更内容をネットワーク経由で転送し、マスター データベースに統合することができます。 詳細については「分散データのシナリオ」をご参照ください。
フィーチャ サービス
トラディショナル バージョン対応データは、同期対応のフィーチャ サービスとして公開することもできます。 これらのフィーチャ サービスは、ArcGIS Collector または ArcGIS Pro を使用したモバイル エディターのワークフローをサポートします。編集者がデータのコピーをダウンロードし、ローカルで編集を行って、フィーチャ サービスを同期できます。 トラディショナル バージョン対応データとモバイル エディターを使用するには、オフラインにしたフィーチャ サービスでトラディショナル バージョン対応データを使用し、操作する方法を理解しておく必要があります。
フィーチャ サービスは、分散型のコラボレーション ワークフローにも追加できます。 たとえば、分散コラボレーション (単純に「コラボレーション」と呼ばれることもあります) は、トラディショナル バージョン対応データで実行されるフィーチャ レイヤーを含むフィーチャ サービスをサポートします。 これにより、コラボレーションで共有されているフィーチャ サービスが、データの別のコピーで実行されているときに、同期対応のフィーチャ サービスをコピーとして共有できるようになります。 コラボレーション プロセスおよびコラボレーションの概念の詳細については、「コラボレーションのしくみ」をご参照ください。