更新：ArcGIS Pro 3.4／ArcGIS Enterprise 11.4で導入されましたトリガーフィールドこれはイベントによる編集の影響を軽減する議論に影響します。
サブネットワーク管理の理解シリーズへようこそ。このシリーズでは、サブネットワーク管理のより高度なトピックを深く掘り下げます。サブネットワークとは何か、またはそれがどのように機能するかに慣れていない場合は、まずArcGIS Utility Networkによるサブネットワーク管理学習シリーズの記事とチュートリアルを読むことをお勧めします。
サブネットワークの管理は、サブネットワークが作成または再構成される際に数百または数千のフィーチャ編集を伴うことがよくあります。そのため、システムはこれらの更新を行うために使用できるいくつかの異なる編集モードを提供しています。
この記事を読むことで、この設定がupdate subnetworkのパフォーマンスに与える影響と、特定のワークフローでパフォーマンスに影響を与えるにもかかわらずeventingを有効にしたい理由を理解できます。
編集モードとは何ですか？
編集モードとは何ですか？編集モード？ArcGIS Utility Networkでは、編集モードとは、サブネットワークが管理される際にフィーチャ上のシステムフィールドをソフトウェアがどのように管理するかを指します。現在、編集モードには2つのオプションがあります。eventingありまたはeventingなし.
「eventing」とは何を指しているのでしょうか？データをeventingありで管理するまたはeventingなしで管理すると言うとき、特に編集に応じてトリガーされるジオデータベースイベントを指しています。ジオデータベースイベントは、ArcGISがジオデータベース内のオブジェクトが編集されたときに特別な動作をトリガーする方法の一つです。一般的な例としては、エディタートラッキングフィールドの自動入力、属性ルールの発火、関連オブジェクトへの変更メッセージ送信、およびフィーチャリンク注釈の更新などがあります。
これはサブネットワークと何の関係があるのでしょうか？ユーザーが編集ワークフローの一環としてよく実行するツールの一つに、update subnetworkツールがあります。このツールは、参加しているサブネットワークを説明するユーティリティネットワークフィーチャ上のシステムフィールドを管理します。これら各フィーチャが編集されるたびに異なる編集イベントがトリガーされます。リレーションシップや属性ルールを含むデータモデルは、それらが少ないモデルよりもupdate subnetwork中に多くのイベントを発火させます。すべてのイベント、ルール、およびリレーションシップはupdate subnetworkプロセスに追加時間を加えます。
この状況に対処するために、管理者はネットワーク内のティアで通常のジオデータベースイベント（eventingあり）を使用するか、通常のジオデータベースイベントモデル（eventingなし）をバイパスする編集モードを設定できます。この決定方法についてビジネス要件とベストプラクティスを評価する簡単な議論はこの記事の最後にあります。さらに、トリガーフィールドを使用して属性ルールが反応する編集内容を正確に制御し、update subnetwork中の編集イベントの影響を軽減できます。
では今からいくつか異なる構成例を見てみましょう。それぞれの例では、一連のフィーチャが特定条件下でどのように反応するか見ていきます。各フィーチャには4つのフィールドラベルが付いており、その値が変更されるとそのフィールド／値は太字になります：
- Asset ID - 各フィーチャ固有の識別子です。フィーチャ作成時に入力されます。
- Date Modified - ジオデータベースによって維持されるエディタートラッキングフィールドです。
- Subnetwork Name - ユーティリティネットワークによって維持されるサブネットワーク名フィールドです。
- Network Region - フィーチャのサブネットワーク名を使ってルックアップテーブルから「region」値を取得する属性ルールによって維持されるフィールドです。
注：もし属性ルールがサブネットワーク情報利用しない場合、すべての属性ルールはupdate subnetwork中の更新でトリガーしないよう設定可能であり、それによってupdate subnetwork中に属性ルールによるパフォーマンス影響を軽減できます。
デフォルトでeventingなしで更新する場合
最初に見る例は、新しいデータベースでdefaultバージョン上でupdate subnetworkを実行するというほぼすべてのプロジェクトで一度は行う操作です。この場合、データベース内すべてのサブネットワーク名フィールドには「Unknown」という値が入り、それ以外のフィールドにはデータロード時点で初期値が入っています。以下図で例を見ることができます。
図1 初期データベース状態
Network A上でupdate subnetwork実行後、サブネットワーク名フィールドはそのサブネットワーク内すべてのフィーチャで更新されていますが、エディタートラッキングや属性ルールはこれら更新中にはトリガーされませんでした。もしクラスにフィーチャリンク注釈があれば、その注釈もこのイベント中には変更されませんでした。
図2 デフォルトでeventingなしでupdate subnetwork実行後
次に同じ操作でもedit modeが設定された場合（つまり、eventingあり.）システム挙動との比較です。
デフォルトでeventingありで更新
ユーティリティネットワークがsubnetwork更新時にeventingあり設定の場合、update subnetworkによる属性更新時すべてジオデータベース動作がトリガーされます。前述例がeventingありで実行された場合結果は以下図となります。
図3 デフォルトでeventingありでupdate subnetwork実行後
サブネットワーク名入力だけでなくLast Modifiedフィールドもエディタートラッキングによって更新され、Operating Areaフィールドも属性ルールによって更新されています。またこれら複数フィールド参照するフィーチャリンク注釈も更新されます。
しかしこれら追加トリガーや更新にはパフォーマンスコストがあります。そのため、多数属性ルールや／または多数フィーチャリンク注釈クラスある場合、この影響について慎重な検討が必要です。
名前付きバージョンでeventingなしで更新
最も興味深い状況は名前付きバージョン上でeventingなし設定時update subnetwork挙動を見ることです。これはシステム既定動作でもあり最もパフォーマンス良好です。名前付きバージョン上でeventingなし設定時update subnetwork実行すると、そのバージョン内でまだ編集されていないフィーチャ上ではサブネットワーク情報更新できない欠点がありますこれら例示挙動がお好みでない場合、本記事次節（名前付きバージョン上eventingあり設定時更新）で説明する新オプションをご検討ください。
この問題について十分議論するため2つ別々例示します。名前付きバージョン上では条件次第では期待通り結果出ないこともありますが、その後defaultバージョンへポストしdefault上でupdate subnetwork実行すると正しい結果になりますのでご安心ください。
新規作成されたフィーチャ
最初例は前述例踏まえています。subnetwork情報未入力状態データベースから始めdefault上update subnetwork実行前に新規名前付きバージョン作成しそのバージョン内へ新サービス追加したと仮定します。この名前付きバージョン内新規作成されたフィーチャ群図示します：
図4 名前付きバージョン内新規作成されたフィーチャ
名前付きバージョン上eventingなし設定時update subnetwork実行後、不思議な現象があります。このバージョン内新規作成されたフィーチャのみサブネットワーク名入力されます.
図5 名前付きバージョン内新規作成されたフィーチャへのeventingなし更新結果
名前付きバージョン上eventingなし設定時update subnetwork実行すると、そのバージョン内作成または編集済みのみ更新可能です. なぜなら未修正の場合ジオデータベースイベント発火して編集内容挿入必要になるためです。
既存フィーチャ
次例では名前付きバージョン上eventingなし設定時update subnetwork実行した際予期せぬ結果生じる具体例として、一部機器間接続変更によってあるサブネットワークから別サブネットワークへ移動した場合どうなるか見ます。
2つサブネットワーク（Network A と Network 
) が結合装置（開閉スイッチや閉弁など）によって分離されています。それぞれdefault版上全て更新済みなので属性適切入力済みです。また結合装置は複数サブネット所属なのでサブネット名欄にはセミコロン区切り複数値入っています。
図6 default版上2つサブネットワーク状態
この例では結合装置としてDevice 3からDevice 1へ変更します。この種変更は回路や圧力ゾーンなど長期的また季節的顧客需要変化対応として頻繁に起こります。そのため両機器状態変更しDevice 1 を結合装置化しDevice 3 は障壁解除します。
図7 結合装置変更後状態
図示通り結合装置指標Device 3からDevice 1へ移動し最終修正日付も更新済みです。また各機器色分け変更し各々属するサブネット追跡可能視覚化しています。ただしまだupdate subnetwork未実行なので旧サブネット名表示継続中です。この条件下update subnetwork実行時起こる全属性変化図示します：
図8 名前付きバージョン内update subnetwork結果予想図
期待通り、このバージョン内編集した両機器上サブネット名欄更新されています。しかしNetwork A接続だったものがNetwork B接続になった機器群は旧サブネット名およびOperating Area値継続していますこのバージョンアップデートでこれらのフィーチャが編集されなかったため、サブネットワークは編集イベントをトリガーせずにそれらを編集できません。
これらの例はどちらも、イベントなしで名前付きバージョン内のサブネットワークを更新する際の制限を示しています。多くの顧客にとって、これらの制限はこの編集モードのパフォーマンス上の利点や、データがデフォルトに投稿されて全員が結果を確認できるupdate subnetworkが実行された後に正しく表示されるため、許容範囲です。しかし、他の顧客は特定のビジネス要件を満たすためにupdate subnetworkの実行時間が長くなることを受け入れる意向がありました。このため、私たちはupdate subnetworkで編集できる機能を導入しました。イベントありで次のセクションで説明します。
名前付きバージョンでのイベントありによる更新
上記の2つのシナリオを再検討し、ティアが編集モードとしてイベントありで設定されている場合に名前付きバージョン内でサブネットワークを更新したときの動作を見てみましょう。
新規作成されたフィーチャ
以下は最初の例で、既存と新規のフィーチャが混在して更新する必要がある場合です。
図9 バージョン内の新しいフィーチャ
そして以下はイベントありでupdate subnetworkを実行した後の結果です。
図10 名前付きバージョンでイベントありによるupdate subnetwork
ご覧の通り、すべてのフィーチャには正しいサブネットワーク名と操作エリアがあります。より多くのフィーチャを編集し、各フィーチャがエディタートラッキングや属性ルールなどを処理するために追加編集をトリガーするため、ネットワークの処理にはより時間がかかります。
既存フィーチャ
次に、いくつかのサブネットワークを再構成した2番目の例を見てみましょう。以下はupdate subnetwork実行前のデータです。
図11 update subnetwork前のバージョン内フィーチャ
そして以下は名前付きバージョンでイベントありによるupdate subnetwork実行後のフィーチャ状態です。
図12 バージョン内の新しいフィーチャ
再度、すべてのフィーチャ属性が正しい値になっていることがわかります。これはイベントなしで同じ操作を行うよりも時間がかかることは言うまでもありません。ただし、その所要時間は設定している属性ルール数や複雑さ、およびメッセージング有効なリレーションシップ数（フィーチャリンク注釈含む）に直接関連します。品質保証プロセス中にネットワーク情報の視覚的検査や属性レビューが重要な場合は、これらパフォーマンスコストと重要性を測定・検討する価値があります。
構成
これらの動作がどのように機能するかをご覧いただいたので、ユーティリティネットワークでどのように構成されているか見てみましょう。これらオプションはSet Subnetwork Definitionツールで設定します。このツールではネットワーク内特定ティア用に構成変更できるため、それぞれ異なる動作（例：SystemやPressure）を定義可能です。各ティアごとに異なる動作オプションがあることは便利ですが、多くのお客様は一貫した編集ワークフロー確保のため全ティア同じ動作にすることを好みます。
サブネットワーク定義用編集モード設定には2つの異なるフィールドがあり、それぞれ2つずつ選択肢があります。つまり編集モードには4つ組み合わせがあります：
- デフォルトではイベントなし、名前付きバージョンでもイベントなし（デフォルト）
- デフォルトではイベントなし、名前付きバージョンではイベントあり
- デフォルトでも名前付きバージョンでもイベントあり
- デフォルトではイベントあり、名前付きバージョンではイベントなし
どれを選ぶべきか悩む前に知っておいてほしいことがあります。Esri提供ユーティリティネットワーク基盤データモデルはすでに編集モードが設定済みです。それぞれ業界専門家とコミュニティによって推奨構成セットが開発され、その業界向け幅広いワークフローに適合する構成となっています。
これら構成はほとんどのお客様ニーズに合致していますが、ご自身のビジネス要件や構成・データモデル変更内容と照らし合わせて典型的な構成が依然最適かどうか確認することは常に良い考えです。
ベストプラクティス
よく聞かれる質問は「ユーティリティネットワークで編集モード設定ベストプラクティスは何か？」ですが、一律回答はありません。ただし判断材料となる基準はいくつかあります。それらは主にワークフロー、注釈、および属性ルールという3つカテゴリに分けられます。
最初に考慮すべきはあなたの バージョン管理された編集ワークフローです。もし名前付きバージョン内で品質保証を行い、その過程でフィーチャ属性（サブネットワーク名や伝播値など）に依存するツールやレイヤーを使うならば、名前付きバージョン用編集モードは「イベントあり」に設定すべきです。これによりバージョン内すべてフィーチャについてサブネットワークフィールドが常に正しく埋められ品質保証利用可能になります。一方QAプロセスが完全にデフォルト内だけで行える場合やトレース機能利用可能ならば、「イベントなし」に設定しても問題ありません。
次に考慮すべきは フィーチャリンク注釈です。もしフィーチャリンク注釈やサブネットワーク情報（サブネット名や伝播値など）を含まない注釈式がないならばどちらの編集モードでも適切です。ただしメッセージング有効なリレーションシップクラス（例えばフィーチャリンク注釈クラス）は編集時パフォーマンスコストがありますので注意深く監視してください。しかしそれ以上に重要なのは、もしあなたのフィーチャリンク注釈がサブネットワーク情報を含むなら決断が必要です。注釈クラスへサブネット情報格納は注釈静的性質とサブネット動的性質および同期維持コストからベストプラクティスとは言えません。その場合ラベルへの置換検討推奨です。ただし必須要件ならば両方（名前付きバージョン・デフォルト）とも「イベントあり」に設定しupdate subnetwork実行時注釈テキスト更新保証します。ただしupdate subnetworkパフォーマンス影響あること認識してください。
三番目に考慮すべきはあなたが定義した 属性ルール です。更新時発火設定された属性ルールは割り当て先フィールド問わず該当フィーチャ更新時必ず評価されます。つまり「イベントあり」編集モード使用時にはupdate subnetwork中更新された全フィーチャについて即時計算ルール全て発火します。この要件厳守しパフォーマンスコスト受容可能ならば属性ルール見直ししupdate subnetwork中早期終了ロジック組み込み推奨です。またサブネット変更応答属性ルール利用している場合、それ自体ベストプラクティスとは言えません。しかし必須ならば「イベントあり」に設定しupdate subnetwork中属性ルール発火保証してください。イベントありで
これら考慮事項踏まえ4つオプションそれぞれ適切な場面を見てみましょう。
デフォルトも名前付きバージョンもイベントなしの場合. このオプションはシステム標準動作です。一番パフォーマンス良いですがバージョン内フィーチャ更新やフィーチャリンク注釈には制限があります。
デフォルトではイベントなし、名前付きバージョンではイベントありの場合. このオプションはパフォーマンスと機能性とのバランス良好です。デフォルト内update subnetwork時最高パフォーマンスと名前付きバージョン内最高品質保証体験両立します。
デフォルトも名前付きバージョンもイベントありの場合. このオプションは最も多機能ですが最も高いパフォーマンスコストも伴います。この構成採用時には修正時発火属性ルール全般見直ししupdate subnetwork中早期終了可能な設定になっているか確認してください。
デフォルトではイベントあり、名前付きバージョンではイベントなしの場合. これは最も稀な構成です。デフォルト内のみ注釈や属性ルール実行必要だがバージョン内では不要なお客様向けです。
結論
この記事をご覧になったことでサブネットワーク管理用編集モードそれぞれ長所短所理解でき、ご自身のデータモデル・編集ワークフロー・ビジネス要件に適したモード選択可能になるでしょう。
属性ルールへの編集イベント影響軽減方法について学びたい場合はこちらの記事をご覧ください： Attribute Rule Triggering Fields
サブネットワーク管理についてさらに学びたい方やハンズオンチュートリアル試したい方にはこちら業界別例がおすすめです： Getting Started with ArcGIS Utility Network
ユーティリティネットワークサブネット管理機能詳細や深掘り記事についてはこちらEsriコミュニティページをご覧ください： ArcGIS Utility Network
