バージョンのシナリオ

このトピックでは、バージョニングの適用例（このテクノロジを組織内で適用する方法）と利用可能なバージョン設定について説明します。

組織によってワークフローは大きく異なります。多くの場合、ワークフローは段階的に発展し、それぞれの段階で異なるリソースの割り当てやビジネス ルールが必要になります。一般に、プロセス全体の各段階は、作業指示など、個々の作業単位を表します。各作業指示を管理するために、個別のバージョンを作成して、それを編集することができます。作業が完了したことを確認したら、変更内容をデータベースのマスタ バージョンに統合することができます。バージョンをこのように利用すれば、最も基本的なワークフローから複雑なワークフローまで、柔軟に対応することができます。

ほとんどの場合は、（多くの編集ユーザが DEFAULT バージョンを編集する）マスタ データベースの同時編集か、またはその他の設定の組み合わせを導入します。組織とビジネスの要件、および各設定の長所と短所を理解すれば、組織に最適な設定を選択するのに役立ちます。

ジオデータベースの管理をより合理的に行うために、必要最低限の階層を持つバージョン ツリーを構成したり、複数の編集者で DEFAULT バージョンを同時に編集するなどの方法をお勧めします。

マスタ データベースの同時編集

多くのユーザが同じバージョンを同時に編集できることから、マルチユーザ編集をサポートするための最も単純な方法は、多くの編集ユーザが直接 DEFAULT バージョンを編集することです。

各編集ユーザが DEFAULT バージョンの編集を開始すると、編集セッションごとに名前のないテンポラリ バージョンが自動的に作成されます。このテンポラリ バージョンにアクセスできるのは現在の編集ユーザだけです。編集ユーザが編集内容を保存する、または編集セッションを終了すると、テンポラリ バージョンに記録された変更内容が DEFAULT バージョンにポストされます。

編集を開始した後に別のユーザが DEFAULT バージョンを編集していた場合、編集内容を保存すると、ArcGIS が自動的にリコンサイルを実行し、変更をポストします。DEFAULT バージョンが変更されていることが通知されるので、編集を適用する場合は、もう一度保存する必要があります。ArcMap の [オプション] ダイアログ ボックスで自動リコンサイルを有効にすると、この警告を非表示にすることができます。この警告を表示するかどうかにかかわらず、競合（コンフリクト）が存在する場合、編集内容を正常に保存するには、[競合] ダイアログ ボックスで競合を解決する必要があります。

データを保存するための設定の詳細

データ競合を解決する方法

長所

• この方法では、ユーザがデータを編集するための新しいバージョンを作成する必要がない、シンプルなデータベースの更新方法を実装できます。作業単位がきわめて小さい場合、または永続的な設計変更が不要である場合に適しています。
• 競合が存在しない場合、保存した編集内容は直接 DEFAULT バージョンにポストされます。

短所

• DEFAULT バージョンが絶えず変更され、間違って変更されたり不正に変更されたりする可能性が高まります。このため、データベース管理者がより頻繁にデータベースのバックアップを作成する必要があります。
• 複数の編集セッションにまたがるロング トランザクションや設計案の作成などはサポートされません。
• ジオデータベースに対して実行できるリコンサイル処理は一度に 1 つだけです。さまざまな編集セッションからリコンサイルとポストが頻繁に実行される場合、変更内容を保存する編集ユーザは、実行中のリコンサイルとポストが完了するまで待機しなければならない可能性があります。大規模なマルチユーザ ジオデータベースでは、多くのユーザが共通バージョンに対してリコンサイル/ポストする状況は避けてください。リコンサイルとポストはバージョンを排他的にロックします。このロックが適用されている間、他のユーザがリコンサイルポストを行うことはできません。
• すべてのリコンサイルが自動的に処理されるため、この方法ではバッチ リコンサイル プロセスはサポートされません。バッチ リコンサイル処理については、「リコンサイルとポストの自動化」をご参照ください。

複数のプロジェクト

複数のプロジェクトまたは作業指示を管理している場合は、ワークフローを管理するためのより構造化された手法が必要です。複数の編集セッション、および数日、数週間、数か月におよぶ個々の作業単位を、DEFAULT バージョンに影響を与えずに管理する必要があります。こうした作業単位の例としては、幹線道路の舗装計画、新しい電話サービスの導入、ガス パイプラインを継続的に管理するプロジェクトなどがあります。

作業指示またはプロジェクトが開始されると、DEFAULT バージョンの子として新しいバージョンが作成されます。作業指示またはプロジェクトが完了するまで、1 人以上の編集ユーザがこのバージョンを操作することができます。バージョンへのすべての変更が完了したら、編集ユーザまたは ArcSDE 管理者が DEFAULT バージョンに対してリコンサイルし、検出されたすべての競合を解決します。その後、変更内容を DEFAULT バージョンにポストして、変更内容をマスタ データベースに統合します。この時点で、子バージョンを削除することができます。

DEFAULT バージョンへのユーザのアクセス権限をこのワークフローに合わせて制限し、DEFAULT バージョンが変更されないようにすることもできます。ArcSDE 管理者は、DEFAULT バージョンの権限を Protected に設定することができます。この場合、ユーザは引き続き DEFAULT バージョンを参照できますが、アクセス レベルは読み取り専用に制限されます。データを変更したいユーザは、新しいバージョンを作成しなければなりません。

DEFAULT バージョンにポストされた変更内容に読み取り専用ユーザがすぐにアクセスする必要がない場合は、それらのユーザ用に、DEFAULT バージョンから Protected バージョンを作成することができます。このバージョンは、データベースが圧縮され、インデックスと統計情報が再構築された後に作成する必要があります。そうすると、読み取り専用バージョンを表すために必要なすべての行が差分テーブルからベース テーブルに移行され、データベースのパフォーマンスが最適化されます。このシナリオでは、読み取り専用ユーザのデータベース バージョン（次の図の「FastTrak」）は変更されないので、バージョンの差分を検索する必要はなく、データベースの統計情報やインデックスが古くなる、または断片化することはありません。データベースの定期的な圧縮の後、このバージョンを再作成して、読み取り専用ユーザが最後のデータベース圧縮以降の変更にアクセスできるようにします。

長所

• 単純さ：各作業単位がシンプルなバージョン構造によって論理的に分離されます。
• 複数の編集セッションにまたがるロング トランザクションおよび代替設計の作成がサポートされるため、マスタ データベースに影響を与えずに提案を策定することができます。
• DEFAULT バージョンから新しいバージョンを作成すると、マスタ データベースが想定外の変更から保護されます。個々の作業プロジェクトが完了すると、それらはマスタ データベースに統合されます。
• バッチ リコンサイル/ポスト プロセスがサポートされます。

短所

• 他の多層バージョン設定と同様に、バージョンの差分テーブルで管理する行の数が増えるにつれ、バージョンのクエリ パフォーマンスに与える影響は大きくなります。このオーバーヘッドを最小限に抑えるには、データベースを定期的に圧縮し、DBMS の統計情報を更新します。

サブプロジェクトに分かれた複数のプロジェクト

より大規模で複雑なプロジェクトでは、上述の「同時編集」または「複数のプロジェクト」によって実現されるワークフローよりも厳密なバージョニング構造が必要です。これらのプロジェクトは、さらに複数の機能単位または地理単位に分かれることがあり、バージョニング階層はますます複雑になります。たとえば、新しいショッピング センターを設計/施工するプロジェクトでは、工期が東部区画と西部区画に分かれていたり、建物の建設、公共設備の導入、造園などの施工作業に分かれていることがあります。

さまざまなチームと数多くの作業単位からなる大型プロジェクトでは、ワークフローを組織化する効果的な方法は多層バージョン ツリーです。同じプロジェクトのさまざまな側面に従事するチームごとに、その更新内容を管理するためのバージョンを作成します。プロジェクトが完了したら、変更を行ったバージョンをDEFAULTバージョンにリコンサイル/ポストし、マスタ データベースに変更を統合します。

長所

• 複雑なプロジェクトがサポートされます。
• 複数の編集セッションにまたがるロング トランザクションがサポートされます。
• 自動化されたバッチ リコンサイル/ポスト プロセスがサポートされます。

短所

• DEFAULT バージョンから最も階層が離れているバージョンからさかのぼる形で、バージョンのリコンサイルとポストを順番に行う必要があります。つまり、DEFAULT バージョンの 3 番目のレベルに位置する（ひ孫）バージョンは、その親である DEFAULT バージョンの 2 番目のレベルに位置する（孫）バージョンにポストしなければなりません。そして、2 番目のレベルに位置するバージョンを、DEFAULT バージョンの 1 番目のレベルに位置する（子）バージョンにポストします。最後に、1 番目のレベルに位置する（子）バージョンを、DEFAULT バージョンにポストします。

  子バージョンをそれぞれの親バージョンにポストしたら、子バージョンを削除することができます。

• リコンサイルとポストを実行できるのは、バージョンツリーにおいて同じ系統のバージョン間に限られます。バージョン系統をまたがってリコンサイルとポストを実行することはできません。
• 複雑なバージョン ツリーを構成すると、パフォーマンスが代償となることがあります。バージョンの差分テーブルで管理される行の数が増えるにつれ、クエリのパフォーマンスへの影響は大きくなります。

段階的なプロジェクト

多くのプロジェクトは、技術的に、事務的に、または法的に承認されて初めて次の段階へと進む、あらかじめ決められた、または規制された段階を通過していきます。たとえば、公共設備のプロジェクトなどでは、「処理中」、「提案済」、「承認済」、「施工中」、「施工済」などの段階があります。基本的に、このプロセスは循環的です。最初に設計が行われ、さまざまな段階を経てプロジェクトが徐々に変更され、最終的にマスタ データベースに完全に統合されます。

この手法では、このプロセスの各段階（初期設計または設計案バージョン、承認バージョン、施工段階のバージョンなど）を表すバージョンが作成されます。プロジェクトがさまざまなマイルストーンを通過する過程で、各段階が確認および承認され、最後の段階に到達して完了するまでプロジェクトの状態がその段階を表すバージョンに置き換えられていきます。古いバージョンは、必要に応じて履歴として管理するか、削除することができます。

プロジェクトが完了したら、施工済みバージョンを直接 DEFAULT バージョンにリコンサイル/ポストします。バージョンツリーの系統の前のバージョンに対してリコンサイル/ポストする必要はありません。

長所

• この方法は、複数の段階で構成され、各段階を個別の作業単位として分離しなければならないプロジェクトに適しています。
• 他のすべての多層設定と同様に、このワークフローではマスタ データベースに影響を与えずに、設計案と設計代案を作成することができます。
• 変更内容を直接 DEFAULT バージョンにポストできるので、DEFAULTバージョンに向かってバージョン ツリーに変更をポストしていくオーバーヘッドがありません。

短所

• バッチ リコンサイル/ポスト プロセスに適していません。

履歴管理

多くのプロジェクトの重要となる要件として、データベースの変化の過程におけるさまざまな状態を保持する必要がある場合があります。ジオデータベースの標準的なクエリで次のような履歴に対するクエリをサポートしなければならない場合があります。

• 特定の時点のデータベースはどのような状態か
• 特定のフィーチャがどのように変化してきたか
• データベースから特定の日時にフィーチャが削除された場合、削除されたフィーチャが存在していた場所に現在どのようなフィーチャが存在するか

履歴レコードを管理するための共通の要件は、DEFAULT バージョンの変更履歴を保存することです。これは、DEFAULT バージョンが一般にデータベースのマスタ バージョンを表すためです。DEFAULT バージョンへの変更は、DEFAULT バージョンへの編集の結果であるか、他のバージョンから変更がリコンサイル/ポストされた結果です。ジオデータベースは、これらの変更を自動的に記録するように設定できます。この機能はジオデータベースに組み込まれているので、自動的な履歴管理をサポートするために新しいデータ モデルを作成したり、アプリケーションをカスタマイズしたりする必要はありません。

一部のプロジェクトでは、DEFAULT バージョン以外のバージョンの変更履歴が必要です。バージョンは、そのバージョンを作成した時点の親バージョンの状態を表すため、特定の時点の親バージョンの状態を記録することを目的として、子バージョンを作成することもできます。例として、設計バージョンから新しい履歴バージョンを作成することができます。設計バージョンを親バージョンに対してリコンサイル/ポストしても、設計バージョンか作成した履歴バージョンは特定の時点の設計の記録として残ります。

履歴管理の詳細については、「履歴管理プロセス」をご参照ください。

分散データ管理

一部のプロジェクトでは、2 つ以上のオフィスで同じデータを整備する必要があります。どのオフィスでもデータベースへのローカル アクセスが必要なので、それぞれがデータベースのコピーを作成します。あるオフィスでデータを変更した場合は、変更内容を別のオフィスのデータに適用する必要があります。データベースのコピーを同期のとれた状態に保つために、オフィス間で定期的に変更内容を転送することができます。この機能は、ジオデータベース レプリケーションと呼ばれます。

レプリケーションにより、ジオデータベースの一部のデータを現場でオフラインで編集することもできます。これは保守担当者に共通する要件です。オフィスに戻ったら、ネットワークへの接続を再確立して、変更内容をマスタ データベースに統合します。

レプリケーションは、本来なら低速なネットワークでデータを編集しなければならないユーザにも役立ちます。この場合は、レプリケーションを利用して一部のデータをローカル コンピュータに取り出し、ネットワークに接続せずにデータを整備することができます。編集が終了したら、変更内容をネットワーク経由で転送し、マスタ データベースに統合することができます。詳細については、「データ分散を使用するシナリオ」をご参照ください。