[付録] リンクとは
あるEntityの項目に他のEntityのidを格納する場合、その項目をリンクと言います。但しこのリンクは、リンクの考え方の内の一つを表しているに過ぎません。本コラムでは、色々なリンクについて説明します。
■Entityの関係を表すリンク
既に述べた、あるEntityを他のEntityから結びつけるリンクです。本協議会のデータ仕様では、項目の一つに他のEntityのidを登録する事により実装しています。このタイプのリンクは、Relationshipと呼ぶ場合もあります。本協議会で断りなくリンクと言った場合、このリンクを指します。
■他のシステムのデータに対するリンク
Entityの中には、AttributeにURLを登録しているものがあります。これは、他のシステムに対するリンクです。この他に、BIMのIFC Server (またはIFC Web Server)や建物OSに対するリンクも考えられます。BIMのIFC Serverの場合は、サーバ自体のURLに加え、部屋や設備などのGUIDを登録しておくなどが考えられます。BIMのIFCの規格では、部屋などの各オブジェクトにはGUIDを振ることが規定されており、それをスマートシティ側のシステムにも登録しておくことにより、アプリケーションはスマートシティとBIMの両方の情報を使って高度な処理を行う事が可能となります。この様なリンクを特に「外部リンク」と表現する場合もあります
■定義情報に対するリンク
例えば、二種類のデータモデルに住所という項目が含まれる場合、二つの住所の記載ルールが同じとは限りません。「広島県呉市中央４丁目１−６」という住所は、「広島県呉市中央4-1-6」と記載しても良いですし、「広島県呉市中央４丁目１番地6号」と記載しても構いません。この様な定義や記載ルールが異なる事を明確にするために、項目名や項目のタイプをURLで記載する事があります。他えば、住所のタイプであるPostalAddressは以下の様にURLで記述します。
https://schema.org/PostalAddress
正確には、URLではなく、IRIと呼ぶのですが、本データ仕様では各データモデルやデータパーツの技術情報にURIとして記載してあります。尚、本協議会ではこのリンクは現在は利用していません。NGSI V2の後継規格であるNGSI-LDではこのリンクが必要となるため、将来の準備としてURIを記載してあります。
余談ですが、URLは皆様ご存知と思いますが、URIとはURLを一般化したものです。IRIはURIを更に一般化したものです。ご興味がある方は、共有資料の用語集をご覧ください。
[付録] リンクの形
本節は、上記の「帳票間の関係を表すリンク」についての記述です。
個々のリンクは、既に述べたように、あるEntityの項目に他のEntityのidを格納するだけなのですが、リンクを活用する事で色々な事が表現できます。色々あるのですが、ここでは代表的な構造を紹介します。データモデル間の関係を表現する場合には、これらの関係を組み合わせて実現します。とは言っても、心配する必要はありません。本協議会では現実に使われている帳票を元にデータモデルを策定しますが、現実に使われている帳票が(誰も意識していないとは思いますが)元々これらの構造を実現する様に策定されているので、殆どの場合は気にする必要はありませんし、技術者同士の議論でも殆ど言及する事はありません。まあ、余談だと思って読んで頂ければ十分です。
■スター型
この形は右図の様にひとつのEntityを起点として、他のEntityをリンクしていく形態です。特的目的データモデルをモノ・コト単位に分解していくとこの形態になります。右図の矢印がリンクなのですが、鏃側のEntityのidを矢羽根側のEntityの項目に登録するイメージです。
例えば、推奨データセットの「AED設置場所一覧」は右図のようになります(事務局注: 自治体標準オープンデータセットに移行した後に確認はしていません)。
■階層型
この形は右図の様にEntityから自分と同じデータモデルの別のEntityをリンクする形態です。この形態では無限階層の階層を表現できます。
例えば、建物を表現しようと考えた場合、学校という建物は体育館・校舎・調理室などの複数の建物から構成されている場合があります。また、大きなビルでは、下の階は商業施設になっていて、途中から上はマンションやホテルになっていたりします。この様な構造を表現したい場合、この階層型が便利です。
■単純ネットワーク
この構造も前記の階層型と同様に、無限階層の階層を表現できます。階層型との違いは、階層に「重み」を持たせられる点です。帳票Bが重みを表現するEntityです。重みと言う表現が分かりにくいかと思いますが、次の例を見るとわかると思います。
右図は単純ネットワークを利用して「部品展開」または「BOM」と呼ばれる情報を表現した例です。帳票Aが「部品」で帳票Bが「個数」を表現します。この図では、自転車が一つのボディと二つの車輪からできていて、ボディは更に一つのフレームと二つのペダルからできていると表現しています。この様に個数という重みが表現されている事になります。
尚、矢印を逆にたどっているではないかと思われる方もいらっしゃると思いますが、殆どのシステムでリンクは逆にもたどる事が出来る様になっています。リンクは相手のEntityのidを格納すると記載しましたが、右図の様な矢印の向きにすると格納するidが一つで済むため、登録が楽なのです。実用上は後から登録するであろうEntityから予め登録されているEntityにリンクするという意味もあります。
■複合ネットワーク
この構造も前記の単純ネットワークと同じ「ネットワーク」という言葉が付いていますが、階層は表現せず、N対Mの対応関係を表現します。右図では、帳票Aと帳票Bとの関係がN対Mであるという事を表現しています。間に挟まって両方をリンクしている帳票Cは、帳票Aと帳票Bとの関係を表現するEntityであるという事になります。この様な関係は、在庫管理、注文など、多くの帳票間の関係で出て来ます。
例えば右図は商品と小売店との間の注文の関係を表現しています。従って、間に挟まって両方をリンクしているEntityは「注文伝票」という事になります。商品から見ると、個々の商品は複数の小売店から注文されるでしょうし、小売店から見ると複数の商品を注文する事になります。現実世界の注文伝票は複数の商品を一括して記入できると思いますが、右図は一つの種類の商品しか記入できないとして例示しました。
