地理データを使用したワークフローでは、長さと複雑さに大きなばらつきがあります。 エンタープライズ ジオデータベースは、データに対してショートおよびロング トランザクションを実行するユーザーとアプリケーションのワークフロー ニーズの均衡を図る 2 通りのデータ管理方法 (すなわち、バージョン対応のデータ管理とバージョン非対応のデータ管理) をサポートしています。 バージョン非対応の方法では、ショート トランザクション編集を管理し、バージョン対応の方法では、ロング トランザクションを取り扱います。
これらの方法は、バージョン対応かバージョン非対応かに関係なく、フィーチャクラスまたはテーブルごとに適用できるため、同じエンタープライズ ジオデータベースで 2 つの方法を組み合わせて使用することもできます。 バージョン対応のデータ管理は、ブランチ バージョニング、トラディショナル バージョニング、ベース テーブル移行オプションを使用したバージョニングという 3 つのオプションにさらに拡張されます。 編集できるデータおよび実行できるワークフローのタイプには違いがあるため、選択する方法は、GIS で必要な機能に応じて決定します。
エンタープライズ ジオデータベース内のデータセット タイプでサポートされている編集ワークフロー オプションのサマリーを次の表に示します。
| データセット タイプ | ブランチ バージョニング | トラディショナル バージョニング | トラディショナル バージョニング (ベース テーブルへの移行) | バージョン非対応編集 |
|---|---|---|---|---|
フィーチャクラス |  | | | |
テーブル | | | | |
アノテーション | | | | |
ディメンション | | | | |
リレーションシップ クラス | | | | |
3D オブジェクト フィーチャクラス | | |||
トレース ネットワーク | | |||
ユーティリティ ネットワーク | | |||
パーセル ファブリック | | |||
トポロジ | | | ||
ネットワーク データセット | | |||
テレイン データセット | |
注意:
上記の表に示されたデータセット タイプに加えて、特定のジオデータベース登録データセットでのみ有効なジオデータベース機能 (レプリケーション、履歴管理、属性ルール) もあります。 詳細については、これらの機能ごとのトピックをご参照ください。
バージョン非対応のデータ管理
複数バージョンのデータを使用せずに、基になる DBMS トランザクション モデルを利用する方法です。 バージョン非対応の編集は、標準のデータベース ショート トランザクションに相当します。
データを編集するには、リボン上の [編集] タブをクリックして、フィーチャの追加、削除、移動や属性の更新など、必要な操作を実行します。 編集セッションでの最初の編集からトランザクションが開始され、実行した個々の編集操作が単一のトランザクションとしてデータベースにコミットされます。 ArcGIS AllSource でバージョン非対応データを編集する場合は、各トランザクションが自動的にデータベースにコミットされるため、編集内容を保存する必要はありません。 変更した内容は、トランザクションが完了した時点で、データにアクセスするその他すべてのユーザーとアプリケーションで使用できるようになります。
編集の際に、DBMS のデータに定義されている一意のインデックス、制約、およびトリガーが適用されます。 DBMS のデータに対して直接トランザクションを実行している場合と同じロック メカニズムが適用されます。 このため、同じデータにアクセスしているか、同じデータを変更しているユーザーまたはアプリケーションが互いをブロックし合う可能性があります。
注意:
マルチユーザー編集環境でバージョン非対応編集を使用する場合は、DBMS の分離レベルとロックの仕組みを理解しなければなりません。また、ArcGIS で作業を開始する前に、必要に応じて、DBMS で分離レベルを適切に設定する必要があります。
この方法は、バージョン内で複数のデータ表現が含まれていない単純なフィーチャに適しています。 また、バージョンを使用してデータを参照しないので、GIS アプリケーションと非 GIS アプリケーションで同じデータベースを共有しなければならない場合にも役立ちます。
メリット
バージョン非対応のデータ管理のメリットを次に示します。
- ArcGIS アプリケーションからアクセスする同じデータを (Esri のソフトウェアで作成されていない) サードパーティ アプリケーションからも参照/編集できるようにすることで、地理データを既存のアプリケーションに統合できます。 たとえば、Esri のビジネス パートナーは、基になる DBMS に格納されたデータを更新するためにオープン アクセスを必要とするアドオンやエクステンション アプリケーションを作成することがよくあります。
- プロジェクトを単純なワークフローと編集によって管理します。 トランザクションが常にシンプルなショート トランザクションであるため、データを直接編集することが可能であり、編集内容のマージや定期的な差分テーブルの管理をする必要はありません。
制限事項
バージョン非対応のデータ管理の制限事項を次に示します。
- 編集できるのは、単純なフィーチャ (ポイント、ライン、ポリゴン、アノテーション、リレーションシップ) のみです。 トポロジ、ユーティリティ ネットワーク、パーセル ファブリック、その他の高度な機能のデータセットに属しているフィーチャクラスは編集できません。
- データ ソースを直接編集するため、個々の編集を元に戻したり、やり直したりすることはできません。
- バージョン非対応編集では、編集競合の検出はありません。 あるユーザーがフィーチャを更新して変更内容を保存した後、別のユーザーが同じフィーチャを更新して変更内容を保存した場合は、最後の更新によって最初の更新が上書きされます。
- マルチユーザー編集シナリオでは、1 人のユーザーがフィーチャを編集すると、DBMS でロックが適用されるため、他の編集者はそのフィーチャに同時に編集を加えることができなくなります。
バージョン対応のデータ管理
エンタープライズ ジオデータベースでは、マルチユーザー編集シナリオとロング トランザクションに対応するためにバージョニングを使用しています。 ジオデータベースは、データベースの複数の状態 (バージョン) を同時に存在させることで、DBMS の標準トランザクション モデルを拡張します。 これにより、データにロックを適用したりデータを複製したりせずに、複数のユーザーが同時にジオデータベースの同じデータを編集できます。
編集者は、他のユーザーが不完全な作業を閲覧したり、編集者同士がデータへのアクセスを妨害し合ったりしないように、独自のパーソナル ジオデータベースで作業することができます。
各バージョンは、設計や作業指示といったある作業の状態を表すことができます。必要であればこれらの作業 (トランザクション) を完了するまでに数週間または数か月の期間、自由にデータベースへの接続、切断を繰り返すこともできます。 編集者は、作業が完了したら、変更内容を親バージョンに統合することができます。
バージョンを使用したワークフローの例を次に示します。
- 仮説検証が必要なプロジェクト - 設計を別のバージョンで作成します。 設計が承認されたら、その内容を残りのデータベースにマージすることができます。 設計が承認されなかった場合は、破棄することができます。
- 特定の品質保証要件のあるプロジェクト - 他のデータベース ユーザーから隔離されたバージョンに、一括インポートなどのデータへの変更を収集します。 変更のテストと承認が済んでから、それらをデータベースのマスター バージョンにマージします。
- 作業が機能単位または地理単位に分かれているプロジェクト - たとえば、新しいショッピング センターを設計/施工するプロジェクトでは、工期が東部区画と西部区画に分かれていたり、建物の建設、公共設備の導入、造園などの施工作業別に分かれていたりすることがあります。 これらの作業単位は異なるバージョンで実行され、各バージョンが完成した時点で、データベースのマスター バージョンに反映されます。
- あらかじめ決められた段階または規制された段階を通過し、各段階が技術的、事務的、または法的に承認されて初めて完了したと見なされるプロジェクト - これらのプロジェクトのワークフローでは、各段階を異なるバージョン (たとえば、初期設計または提案バージョン、承認されたバージョン、施工段階のバージョン) として管理することができます。 プロジェクトがさまざまなマイルストーンを通過する過程で、各段階が確認および承認され、最後の段階に到達して完了します。各段階ごとのプロジェクトの状態はバージョンで置き換えられていきます。
- 現場の保守担当者がモバイル デバイスを使用してジオデータベースのデータを更新しなければならないプロジェクト - 現場の編集者は独自のバージョン内で作業し、オフィスの編集者が加えた更新内容とマージすることができます。
どのエンタープライズ ジオデータベースにも、Default というバージョンが設定されています。 他のバージョンと異なり、Default バージョンは常に存在し、削除することはできません。 ほとんどのワークフローでは、デフォルト バージョンはデータベースのマスター バージョンであり、モデルとなるシステムの現在の状態を表します。 他のバージョンからの変更をポスト (反映) することにより、Default バージョンを管理および更新します。 また、他のバージョンと同様に、Default バージョンを直接編集することもできます。 Default バージョンはルート バージョンであり、他のすべてのバージョンの上位バージョンになります。
バージョニングは、データ管理方法に柔軟性と拡張性をもたらすことができます。 次の 2 種類のバージョニングが用意されており、どちらも特定のワークフローと配置オプションに適用されます。
バージョニング テクノロジを組織内に適用する方法を説明したブランチ バージョンの構成のシナリオおよびトラディショナル バージョンの構成のシナリオをご参照ください。