バージョンのシナリオ

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

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

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

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

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

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

DEFAULT バージョンの同時編集

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

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

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

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

長所

短所

複数のプロジェクト

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

複数のプロジェクトの管理

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

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

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

複数のプロジェクトの管理: 1 つのバージョンで高速な検索と表示をサポート

長所

短所

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

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

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

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

長所

短所

段階的なプロジェクト

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

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

段階的なプロジェクト

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

長所

短所

履歴管理

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

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

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

履歴目的でのバージョンの作成

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

分散データ管理

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

地理的に離れたオフィス間でのジオデータベースの同期

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

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

関連トピック

5/10/2014