バージョン対応環境でのリプレゼンテーションの仕組みを理解するためには、まずバージョニングの原理とフィーチャクラス リプレゼンテーションがジオデータベースに格納される方法を十分に理解することが重要となります。
バージョン対応環境でのリプレゼンテーションの仕組み
リプレゼンテーションを持つフィーチャクラスは、リプレゼンテーションを持たないフィーチャクラスとほぼ同じように、バージョン対応環境に参加します。これには、注意点がいくつかあります。
- リプレゼンテーションを作成するとスキーマが変化する - スキーマの変更はバージョンに対応できないため、バージョン対応のフィーチャクラスに追加されたリプレゼンテーションはすべてのバージョンで表示されます。同様に、フィーチャクラスからリプレゼンテーションを削除すると、すべてのバージョンに反映されます。リプレゼンテーションは編集セッションの外でのみ作成することができます。 リプレゼンテーション ルール情報はバージョン未対応のシステム テーブルに格納されるため、データベース内で維持されます。
- リプレゼンテーション ルールを変更するとスキーマが変化する - ルールを追加するか、またはリプレゼンテーション ルールの構造、プロパティ値、またはフィールド割り当てを変更すると、スキーマが変化し、すべてのバージョンに直ちに反映されます。リプレゼンテーション ルール情報はバージョン未対応のシステム テーブルに格納されるため、データベース内で維持されます。リプレゼンテーション ルールは編集セッションの外でのみ変更することができます。
- リプレゼンテーション ルールをフィーチャに割り当てると属性が変化する - リプレゼンテーション ルールは、ルール ID フィールドを通じてフィーチャに割り当てられます。フィーチャに別のルールを割り当てる (またはフィーチャを NULL ルールに設定する) と、属性が変化します。変更は現在のバージョンにのみ反映されます。競合は標準リコンサイルおよびポスト プロシージャを使用して解決できます。
- シェープをオーバーライドすると属性が変化する - シェープ オーバーライドは、リコンサイルおよびポストが実行されるまで、現在のバージョンにのみ反映されます。
- リプレゼンテーション ルールのプロパティをオーバーライドすると属性が変化する - オーバーライドは現在のバージョンにのみ反映されます。競合は標準リコンサイルおよびポスト プロシージャを使用して解決できます。
- フィーチャ リプレゼンテーションをフリー リプレゼンテーションに変換すると属性が変化する - フリー リプレゼンテーションを作成するプロセスでは、ルール ID フィールドとオーバーライド フィールドの両方が変化します。フィーチャ リプレゼンテーションがフリー リプレゼンテーションの場合、ルール ID の値は常に -1 です。競合は標準リコンサイルおよびポスト プロシージャを使用して解決できます。
バージョン対応環境でリプレゼンテーションを使用する場合の推奨されるワークフロー
シナリオ 1
- 親バージョン (ターゲット バージョン) が、フィーチャ リプレゼンテーションのルール ID を R から R* に変更します。
- 子バージョン (編集バージョン) は、同じフィーチャ リプレゼンテーションを編集しますが、代わりに属性のオーバーライドを追加し、オーバーライド フィールドに O* として格納されます。
- 子バージョンが、親バージョンに対してリコンサイルされます。競合の定義方法により、結果は異なります。
- オブジェクト (行) 単位:両方のバージョンで同じフィーチャが編集されているので、競合が検出されます。競合は、優先度に基づき、どちらかのバージョンを使用することで解決できます。したがって、最終的なリプレゼンテーションは、ルール ID が R でオーバーライドが O*、またはルール ID が R* でオーバーライドが O のいずれかになります。結果は一貫しています。
- 属性 (列) 単位:同じフィーチャ リプレゼンテーションが編集されますが、編集は 2 つの異なるフィールドまたは属性 (ルール ID とオーバーライド) で行われたので、競合は検出されません。リコンサイルでは、フィーチャ リプレゼンテーションはルール ID が R* で属性オーバーライドが O* です。フィーチャ リプレゼンテーションの属性オーバーライドは、表現されているリプレゼンテーション ルールに属さないプロパティに対するものです。結果は一貫していません。
- この状況を避けるには、代わりに row_level オプションを使用します。
シナリオ 2
- 親バージョン (ターゲット バージョン) は、フィーチャ リプレゼンテーションのシェープを変更するか、またはシェープ オーバーライドを追加します。このオーバーライドは、オーバーライド フィールドに O* として格納されます。
- 子バージョン (編集バージョン) は、同じフィーチャ リプレゼンテーションを編集しますが、代わりに属性のオーバーライドを追加します。このオーバーライドは、オーバーライド フィールドに O** として格納されます。
- 子バージョンが、親バージョンに対してリコンサイルされます。競合を解決するためどちらのバージョンを選択しても、同じ結果になります。
- オブジェクト (行) 単位または属性 (列) 単位:同じフィーチャ リプレゼンテーションが両方のバージョンで編集されます。また、編集は同じ属性オーバーライドに対して行われます。シェープと属性のオーバーライドは 2 つの異なるエンティティですが、これらを編集すると、同じオーバーライド フィールドに結果が保存されます。競合が検出され、どちらかの編集 (O* または O**) を保持することになります。
- 回避策: 属性の編集結果を、オーバーライド フィールドに格納する代わりに、明示的なフィールドに格納します。リコンサイル時に、属性 (列) 単位の定義を選択すると、編集結果は 2 つの異なるフィールド (オーバーライド フィールドと明示的フィールド) に格納されるので、競合は発生しません。結果として、両方の編集を維持できます。
シナリオ 3
- 親バージョン (ターゲット バージョン) が、フィーチャ リプレゼンテーションに対する属性オーバーライドを作成します。オーバーライド フィールドは O* に更新されます。
- 子バージョン (編集バージョン) は、同じフィーチャ リプレゼンテーションを編集しますが、フィーチャ リプレゼンテーションをフリー リプレゼンテーションに変換します。ルール ID の値は -1 に変化し、グラフィックス オブジェクトがオーバーライド フィールドに設定されます。その結果、このステップはルール ID フィールドとオーバーライド フィールドを R* および O** に変更します。
- 子バージョンが、親バージョンに対してリコンサイルされます。
- オブジェクト (行) 単位または属性 (列) 単位: 競合があります。親 (ターゲット) バージョンを優先して競合を解決すると、結果は一貫性がなくなります。属性オーバーライド O* が、ルール ID の値 -1 または R* とともに存在します。
- 回避策：一貫性のない結果を避けるには、子バージョンを優先して競合を解決します。この場合は、子バージョンによって行われた変更を保持し、親バージョンによって行われた編集を無視します。ただし、この場合は親バージョンによって行われた編集が失われることに注意する必要があります。
シナリオ 4
同じフィーチャクラスに存在する複数のフィーチャクラス リプレゼンテーションに基づく複数の地図を調整する場合は、複数プロジェクトのシナリオを使用して地図を編集します。たとえば、地図ごとに M1、M2、M3 などのような異なるバージョンを作成します。これらのバージョンを編集した後、属性 (列) 単位の定義を使用して親バージョン (または SDE.Default) でリコンサイルとポストを行い、競合はすべて編集バージョンを優先して解決します。オーバーライド フィールドの代わりに明示的フィールドに属性オーバーライドを書き込みたい場合は、地図ごとに異なる明示的フィールドを作成します。
ベスト プラクティス
- フィーチャの 2 つのプロパティを 2 つのバージョンでオーバーライドすると、属性 (列) 単位の競合が発生するのはなぜですか？
2 つのプロパティを 2 つのバージョンでオーバーライドすると、混乱を招くおそれがあります。オーバーライド フィールドはすべてのオーバーライドのデフォルトの格納場所なので、このフィールドに両方のオーバーライドが格納されると競合が発生します。たとえば、フィーチャがバージョン 1 とバージョン 2 で荷車用道路ルールに従うとします。バージョン 1 では、そのフィーチャに対する荷車用道路シンボルのライン幅がオーバーライドされています。バージョン 2 では、そのフィーチャの荷車用道路シンボルの色だけがオーバーライドされていますが、ライン幅フィーチャは依然としてルールに従います。両方の変更がオーバーライド フィールドに格納されるため、オブジェクト (行) 単位と属性 (列) 単位の両方の競合解決を使用するリコンサイルでは、変更が実際には競合していない場合でも競合が発生します。この状況を回避するために、オーバーライドする可能性が高いプロパティは明示的なフィールドに割り当てることをお勧めします。これにより、変更が一意のフィールドに分離されるため、属性 (列) 単位のチェックでは検出されなくなります。
- 多くのバージョンと長い系統を持つ大規模な運用データベースがあります。リプレゼンテーションを有効にするために、フィーチャクラスのバージョン対応としての登録を解除する必要はありますか？
新しいフィーチャクラス リプレゼンテーションを作成すると、すべてのバージョンのフィーチャクラス テーブルに新しいフィールドが 2 つ (ルール ID およびオーバーライド) 追加されます。シンボル表示されたレイヤーを変換してリプレゼンテーションを作成した場合は、現在のバージョンにのみルール ID フィールドが作成されます。実際のフィーチャクラス リプレゼンテーションはその他すべてのバージョンに表示されますが、これらのバージョンのルール ID 値は NULL になります。この場合、ルール ID をすべてのバージョンのデータベースにわたって更新するのは困難かもしれません。ワークフローでそれが可能であれば、データベースをバージョン対応登録する前に、リプレゼンテーションを作成します。これにより、デルタ テーブルを設定する必要がなくなるため、リプレゼンテーションをバージョン対応フィーチャクラスで作成するよりも短時間で済みます。すべての編集が DEFAULT バージョンにポストされる (または編集を維持するためにデータベースが圧縮されている) 場合は、新しいフィーチャクラス リプレゼンテーションを作成する前に、データのバージョン対応としての登録を解除します。新しいリプレゼンテーションを作成すると、ルール ID とオーバーライドという 2 つの新しいフィールドが作成され (スキーマの変更)、ルール ID フィールドに値が入力されます。子/下位バージョンに新しいフィーチャクラス リプレゼンテーションを作成すると、他のすべてのバージョンに新しいフィールドが作成されますが、上位バージョンではルール ID フィールドに値は入力されません。SDE.Default バージョンに新しいフィーチャクラス リプレゼンテーションを作成し、ルール ID フィールドに存在するリプレゼンテーション ルールの値がすべての下位バージョンに伝達されるようにするのが、よい方法です。
すべてのフィーチャのルール ID フィールドが更新され、デルタ テーブルも更新されるので、バージョン対応登録されているフィーチャクラスに対しての新しいリプレゼンテーションの作成は遅くなります。この処理は時間がかかり、データベースのサイズに直接依存します。