データ整備の方策

地理データに対するトランザクションでは、長さと複雑さに大きなばらつきがあります。ジオデータベースは、単純または複雑なデータに対してショート トランザクションもしくはロング トランザクションを実行するユーザおよびアプリケーションのニーズを満たすために、データを整備する方法として、バージョンを使用する方法とバージョンを使用しない方法の 2 つをサポートしています。

これらの方法はフィーチャクラスまたはテーブルごとに適用できるため、同じジオデータベースで 2 つの方法を組み合わせて使用することもできます。

どちらの方法でも、データを編集する方法は同じです。編集は編集セッションで行い、ほぼ同じツールを使用します。両者の違いは、元のデータ ソースを管理する方法にあります。また、編集できるデータと実行できるワークフローの種類にもいくつかの違いがあります。このトピックでは、これらの違いについて説明します。

バージョンを使用しないデータ整備

複数のバージョンを管理せずに、DBMS のトランザクション モデルをそのまま利用する方法です。バージョン非対応の編集は、標準のデータベース トランザクションに相当します。

データを編集するには、[編集オプション] ダイアログ ボックスでバージョン非対応の編集を有効にして編集セッションを開始し、フィーチャの追加、削除、移動、属性の更新といった必要な操作を実行します。編集を開始した時点でトランザクションが始まります。編集を保存すると、実行した個々の編集操作は単一のトランザクションとしてデータベースにコミットされます。保存後に次の編集を行うと、新しいトランザクションが始まります。編集セッション中に一度に保存できる操作の数は任意ですが、編集中のデータはロックされ、他のユーザによるアクセスまたは編集をブロックするため、頻繁に保存することをお勧めします。保存すれば、変更はそのデータにアクセスする他のどのユーザやアプリケーションからも共有できるようになります。

編集内容をデータベースにコミットしたくない場合は、編集を保存せずに終了します。前回に編集を保存した時点、または編集を一度も保存していない場合は編集を開始した時点からの編集操作はすべて削除され、データベースにコミットされることはありません。

編集の際には、DBMS のデータに定義されている一意のインデックス、制約、トリガが適用され、DBMS のデータに対して直接トランザクションを実行している場合と同じロック メカニズムがすべて適用されます。このため、同じデータにアクセスするユーザまたはアプリケーションが互いをブロックする可能性があります。マルチユーザ編集環境でバージョン非対応編集を使用する場合は、DBMS の分離レベルとロックの仕組みを理解しなければなりません。また、ArcGIS で作業を開始する前に、必要に応じて、DBMS で分離レベルを適切に設定する必要があります。

このバージョン非対応編集は、履歴を管理したりバージョンを使用して複数のデータの状態を保持する必要がない、シンプルなワークフローに適しています。バージョンを使用してデータを参照する必要がないので、GIS アプリケーションと非 GIS アプリケーションで同じデータベースを共有しなければならない場合にも役立ちます。

適用例

• ArcGIS アプリケーションがアクセスする同じデータを（Esri のソフトウェアで作成されていない）サードパーティ アプリケーションからも参照/編集できるようにすることで、地理データを既存のアプリケーションに簡単に統合することができます。
• プロジェクトを単純なワークフローと編集によって管理します。トランザクションが常にシンプルなショート トランザクションであるため、データを直接編集することが可能であり、編集内容のマージや定期的な差分テーブルの管理をする必要はありません。

制限

• 編集できるのは、シンプル データ（ポイント、ライン、ポリゴン、アノテーション、リレーションシップ）のみです。トポロジ、ネットワーク データセット、ジオメトリック ネットワーク、またはテレインに参加しているフィーチャクラスは編集できません。
• DBMS のトランザクションを使用してデータ ソースを直接編集するため、間違えても個々の編集を元に戻したり、やり直すことはできません。編集内容を元に戻すには、編集セッションを保存せずに終了し、前回保存した時点から行ったすべての編集を取り消す（ロールバックする）必要があります。
• トランザクションはそれぞれ、単一の編集セッションで開始し、完了しなければなりません。通常は、編集セッションを継続できる時間は業務フローなどにより制限されるため、制限時間内にトランザクションを完了する必要があります。
• バージョン非対応編集では、編集競合の検出はありません。あるユーザがフィーチャを更新して保存し、別のユーザが同じフィーチャを更新して保存した場合、最後の更新によって最初の更新が上書きされます。

  詳細については、「バージョン非対応データ操作の概要」をご参照ください。

バージョンを使用するデータ整備

ジオデータベースは、データベースの複数の状態（バージョン）を同時に存在させることで、DBMS の標準のトランザクションを拡張します（バージョニング）。各バージョンは、設計や作業工程といったある作業の状態を表すことができます。必要であればこれらの作業（トランザクション）を完了するまでに数週間または数か月の期間、自由にデータベースへの接続、切断を繰り返すこともできます。また、バージョニングを使用すれば、同じジオデータベースのデータに対する過去、現在、あるいは将来の計画案に基づいた変更を管理することも可能です。

過去の変更を管理するには、データに対する変更をすべて別の履歴管理テーブルに保存します。これらの変更を不要になるまで保管しておけば、ユーザが任意の過去の時点でのデータベースの状態を確認することができます。この機能は履歴管理と呼ばれ、ArcGIS に組み込まれているので、何らかの開発をする必要もありません。履歴管理を有効にすると、（通常はデータベースのマスタ バージョンとして使用される）DEFAULT バージョンへの変更履歴が自動的に管理されます。

現在の変更を管理するには、それぞれの編集者がジオデータベースのプライベートなバージョンを編集して、作業が完了するまでの中間的な状態を他のユーザから参照できないようにします。あるバージョンのデータを編集する際、編集するデータに対してロックは適用されません。つまり、データを編集している間も他のユーザが同じデータを参照/編集できるので、同時実行性のメリットが最大化されます。データベースへのアクセスによってユーザが互いにブロックされることはありません。また、データの編集が完了したら、それぞれのバージョンの編集をマスタ バージョンに統合することもできます。

将来の計画案に基づいた変更を管理するには、データベースの 1 つのバージョンを使用して想定されるシナリオに基づいて編集を行ったり、仮説検証を実行します。複数の編集セッションにまたがり、数日、数週間、数か月におよぶ変更を、1 つのトランザクションとして管理することができます。提案されているフィーチャの追加、地理解析の実行、マップの生成を自由に行うことができ、どれも独立したバージョン内での変更なので、他のユーザがアクセスしているデータに影響を与えません。変更が完成し、承認されたら、それらをマスタ バージョンに統合することもできます。

ジオデータベースに作成できるバージョンの数に制限はありません。バージョンはさまざまな構成で作成することができ、幅広いワークフローをサポートすることができます。ただし、ジオデータベースの管理をより合理的に行うために、必要最低限の階層を持つバージョン ツリーを構成したり、複数の編集者で DEFAULT バージョンを同時に編集するなどの方法をお勧めします。

バージョニングをサポートするために、ArcGIS はデータ複製しません。元のフィーチャクラスやテーブルには変更を行わず、編集内容を差分テーブルと呼ばれる別のテーブルに記録します。差分テーブルは、追加および更新データを記録する ADD テーブルと、削除データを記録する DELETE テーブルで構成されます。いずれかのバージョンでレコードを更新または削除するたびに、これらのテーブルのどちらかまたは両方に行が追加されます。あるバージョンでフィーチャクラスまたはテーブルを検索または表示すると、差分テーブルと元のテーブル（ベース テーブル）から関連する行が組み立てられて、使用しているバージョンにおけるデータの状態が表示されます。

バージョン対応フィーチャクラスを編集

バージョニングを使用して編集されるテーブル（バージョン対応のテーブル）については、データベース管理者が定期的にメンテナンスを実施する必要があります。バージョニングを使用した編集がジオデータベースで行われるに従って、差分テーブルのサイズが大きくなり、データの表示や検索のパフォーマンスに影響をおよぼします。データベース管理者は、データベースのパフォーマンスを維持するために、データベースを定期的に圧縮することができます。これにより、差分テーブルから不必要な情報が削除されます。バージョン対応のデータベースは、作業の終了時や新しいデータを読み込んだ後など、データベース操作のピークが終了するたびに圧縮する必要があります。圧縮プロセスは、他のユーザがデータベースに接続して使用している状態でも実行することができます。

ArcGIS は、バージョンをサポートする差分テーブルを次のどちらかの方法で管理することができます。

• バージョンに関係なく、すべての変更を差分テーブルに保存します。
• DEFAULT 以外のバージョンへの変更は差分テーブルに保存し、DEFAULT バージョンへの変更はすべてベース テーブルに保存します。

1 つ目の方法は、通常、ArcGIS アプリケーション専用のデータベースで使用されます。2 つ目の方法は、ArcGIS アプリケーションとサードパーティ アプリケーションの両方でデータを管理する必要がある場合に有効です。

ArcGIS アプリケーションのみを対象としたデータの管理

ArcGIS アプリケーションでのみデータを管理する環境では、バージョンを管理する最も効果的な方法はすべての変更を差分テーブルに保存することです。これにより、履歴管理、レプリケーション、ジオメトリック ネットワークおよびトポロジの編集など、ジオデータベースの機能を最大限に利用することができます。

フィーチャクラスまたはテーブルでこの設定を有効にするには、ベース テーブル移行オプションを使用せずに、データをバージョン対応レイヤとして登録します。このようにして登録されたデータセットの変更はすべて差分テーブルに保存されます。この方法では、データのベース テーブルへ直接アクセスすることはできません。ユーザは常にデータの 1 つのバージョンにアクセスします。

以下は、バージョンを使用してすべてのデータを管理する設定の一例を示しています。編集ユーザがデータを変更するには、ArcGIS アプリケーションまたは他の Esri アプリケーションを使用する必要があります。ArcGIS 以外のサードパーティ アプリケーションは、バージョン対応ビューを使用することで、マスタ バージョンやその他のバージョンにアクセスすることができます。

バージョンは差分テーブルやその他のシステム テーブルによって実装されるため、Esri のソフトウェア ライブラリを使用せずに DBMS に直接アクセスするアプリケーションには、そもそもバージョンを読み取る機能がありません。ArcGIS は、これらのアプリケーションが特定のバージョンを SQL で読み取ることができるバージョン対応ビューを提供します。バージョン対応ビューを使用することで、テーブルとフィーチャクラスの両方にアクセスできます。バージョン対応ビューを使用してフィーチャクラスのジオメトリ属性にアクセスするには、ArcGIS が完全にサポートする SQL ジオメトリ タイプを使用する必要があります。

この方法には、次のような利点があります。

• 編集中に変更内容を元に戻したり、やり直すことが可能です。
• ロックが適用されないために編集内容が競合する可能性がありますが、ArcGIS には、競合を簡単に検出し、リコンサイルして解決する機能があります。
• 履歴管理機能を使用すれば、変更履歴が自動的に管理され、特定の時点でのデータベースの状態を参照することができます。
• ジオメトリック ネットワーク、ネットワーク データセット、またはトポロジのフィーチャを編集することができます。
• 複数の地理的に離れたオフィスで、同期をとりながらジオデータベースを管理することができます。変更内容を定期的にやり取りして同期をとり、それぞれのジオデータベースを最新の状態に保ちます。ArcGIS では、この機能をジオデータベース レプリケーションと呼んでいます。
• ネットワークに接続していないモバイル ユーザが、現場のラップトップやモバイル デバイスを使用してジオデータベースのデータの一部を編集することができます。ユーザはオフィスに戻ったときに、各自の編集内容をジオデータベースに統合します。ArcGIS では、この機能もジオデータベース レプリケーションと呼んでいます。

適用例には、次のものがあります。

• 履歴データの蓄積と参照が必要なプロジェクト。
• 仮説検証が必要なプロジェクト。新しい設計を別のバージョンで作成し、設計が承認されたら、それをマスタ バージョンに統合することができます。設計が承認されなかった場合は、破棄することができます。
• 特定の品質保証要件を持つプロジェクト。他のデータベース ユーザから隔離されたバージョンに、一括インポートなどのデータへの変更を行います。変更のテストと承認が済んでから、それらをデータベースのマスタ バージョンにマージします。
• 作業が機能単位または地理単位に分かれているプロジェクト。たとえば、新しいショッピング センターを設計/施工するプロジェクトでは、工期が東部区画と西部区画に分かれていたり、建物の建設、公共設備の導入、造園などの施工作業別に分かれていることがあります。これらの作業単位は異なるバージョンで実行され、各バージョンが完成した時点で、データベースのマスタ バージョンに反映されます。
• あらかじめ決められた、または規制された段階を通過し、各段階が技術的、事務的、または法的に承認されて初めて完了したと見なされるプロジェクト。これらのプロジェクトのワークフローでは、各段階を異なるバージョン（たとえば、初期設計または提案バージョン、承認されたバージョン、施工段階のバージョン）として管理することができます。プロジェクトがさまざまなマイルストーンを通過する過程で、各段階が確認および承認され、最後の段階に到達して完了します。各段階ごとのプロジェクトの状態はバージョンで置き換えられていきます。
• 監査が必要なプロジェクト。変更履歴の参照をサポートするために履歴情報を保存、蓄積します。
• 地理的に離れた複数のオフィスで同じジオデータベースを同時に操作する必要のあるプロジェクト。この場合は、各オフィスのデータのコピーを定期的に同期する機能が必要です。
• 現場の保守担当者がモバイル コンピュータを使用してジオデータベースのデータを更新しなければならないプロジェクト。
• ソフトウェア開発者が各自のデータベース バージョンで SQL ステートメントとアプリケーション ロジックをテストしなければならないプロジェクト。

バージョンには多くの利点がありますが、いくつかの制限もあります。

• サードパーティ アプリケーションを使用してデータを読み取るには、バージョン対応ビューを使用する必要があります。
• バージョン対応のデータを操作する際には、一意性制約やトリガといった DBMS の機能の使用が制限されます。これは、挿入データや更新データがベース テーブルに適用されるのではなく、その都度、差分テーブルに新しい行として保存されるためです。

ArcGIS とその他のアプリケーションを対象としたデータの管理

さまざまな部署の異なるアプリケーションが同じデータベースにアクセスする環境では、ArcGIS アプリケーションとサードパーティ アプリケーションの両方をサポートしなければならない場合があります。たとえば、データベース内の地理データを ArcGIS で管理している部署と、同じデータベース内の顧客レコードをカスタム アプリケーションで管理している部署がある場合です。カスタム アプリケーションがトランザクションを実行すると DBMS の制約とトリガが適用されますが、その際にバージョン対応のテーブルが考慮されない可能性があります。その一方で、他の部署では、地理データを独自のバージョンで編集する必要があり、編集が完了して承認されるまでその内容を他の部署と共有しません。

これらの要件を踏まえて、ArcGIS では、フィーチャクラスやテーブルにおいて、バージョニングを使用した編集を実行できるようにするとともに、サードパーティ アプリケーションなど編集内容を共有できる機能を提供しています。この機能をフィーチャクラスまたはテーブルで有効にするには、ベース テーブル移行オプションを使用して、データをバージョン対応レイヤとして登録します。このオプションは、データをバージョン対応登録する際に表示される、[バージョン対応レイヤとして登録] ダイアログ ボックスで設定できます。

ベース テーブル移行オプションを使用して登録されたデータを編集する場合でも、バージョンは先に説明した手法と同じように機能します（変更内容は差分テーブルに保存されます）。ただし、DEFAULT バージョンは例外です。DEFAULT バージョンへの直接の編集または別のバージョンからの変更内容のマージによって DEFAULT バージョンに編集内容を保存するたびに、編集情報はベース テーブルに即座に移行されます。ベース テーブル移行オプションを使用していない場合のように、DEFAULT バージョンの編集内容が差分テーブルに残ることはありません。

ベース テーブル移行オプションを使用することにより、すべてのアプリケーションが同じデータベースを操作できます。

• Esri のソフトウェア ライブラリを使用しないアプリケーションは、変更対象のデータが DEFAULT バージョンや他のバージョンで同時に編集されている場合でも、標準のトランザクションを使用してそのデータを参照/変更することができます。
• ArcGIS アプリケーションまたは ArcObjects を使用して作成されたアプリケーションが DEFAULT バージョンに変更を保存する、または変更をマージするたびに、DBMS のデータに定義された一意のインデックス、制約、トリガが適用されます。
• あるアプリケーションでデータを変更すると、その変更内容は同じデータにアクセスするすべてのアプリケーションに直ちに共有されます。DEFAULT バージョンへの変更は差分テーブルに保存されないので、サードパーティ アプリケーションでこれらのテーブルを読み取るためにバージョン対応ビューを使用する必要はありません。

適用例

• ArcGIS アプリケーションおよび他のアプリケーションでデータを編集する必要のあるプロジェクト。他のアプリケーションが DBMS の標準トランザクションを使用してデータベースの非空間データを参照/変更する一方で、ArcGIS アプリケーションは同じデータの特定のバージョンを操作し、比較的長いトランザクションを実行します。バージョンを使用してデータを更新するトランザクションは、DEFAULT バージョンにマージされるまで、他のすべてのデータベース ユーザから隔離されます。
• ArcGIS アプリケーションでのみデータを保守する場合と同様の適用例。
  • 仮説検証が必要なプロジェクト。
  • 特定の品質保証要件を持つプロジェクト。
  • 作業が機能単位または地理単位に分かれているプロジェクト。
  • あらかじめ決められた、または規制された段階を通過するプロジェクト。
  • 保守担当者がモバイル コンピュータを使用してデータベースのデータを現場で更新しなければならないプロジェクト。
  • ソフトウェア開発者が各自のデータベース バージョンで SQL ステートメントとアプリケーション ロジックをテストしなければならないプロジェクト。

制限

データセットをバージョン対応レイヤとして登録する際にベース テーブル移行オプションを使用すると、バージョンを操作する方法が以下のように制限されます。

• 編集できるのは、シンプル データ（ポイント、ライン、ポリゴン、アノテーション、リレーションシップ）のみです。トポロジ、ネットワーク データセット、ジオメトリック ネットワーク、またはテレインに参加しているフィーチャクラスは編集できません。
• 履歴管理機能を使用することはできません。
• ジオデータベース レプリケーション機能を使用することはできません。
• DEFAULT バージョンを編集する、または DEFAULT バージョンに編集内容をマージする際、競合を解決することはないため、他のユーザの編集を上書きする可能性があります。

バージョンとそれらの機能の詳細については、「バージョニングの概要」と「バージョンのシナリオ」をご参照ください。