多目的なデータモデルの策定手順
多目的なデータモデルの策定手順として確立したものは無い様に思います。そこで、本協議会では、特定目的のデータモデルから多目的なデータモデルを策定する方法を採用しています。
これを図にすると、右の様になります。特定目的のデータモデルとしては、データモデルその物でなくても意味のある項目が分かればいいので、例えば実際の業務で使われている帳票やアプリや他システムとのインタフェース仕様を使います。
最初のユースケースである施設管理では、初めに今まで業務で使っていた各種帳票を収集し、それらを整理する事で、多目的のデータモデルを策定しています。従って、多目的のデータモデルは各種帳票の最小公倍数的なデータモデルになります。
図の中で、「記入ルールの融合」と言う記述がありますが、特に「用語」定義の融合が重要となります。用語とは、帳票の項目に登録する値のことで、例えば「バス」や「乗合自動車」いう用語は「バス」に統一する事にしよう、と決めることになります。この際に帳票間で共通化するだけでなく、法人間でも共通化する事が重要です。共通化した用語の事をEnumと言います。Enumとは、英語のEnumerationから派生した技術用語で各種コンピュータ言語で用いられています。
多目的データモデルに基づいてデータを蓄積すると、そのデータには各種帳票の情報が包含されますので、右図の様に各種帳票の記入を自動化する事が可能です。
項目に登録する「用語」が共通化されていますので、当然ながら各種帳票に記入される用語の共通化されます。つまり、データ仕様を共通化するということは、人間が使う帳票の用語の共通化されるという事になります。
データモデルにおけるidの役割
コンピュータでは、個々のEntityを区別する必要があります。この区別には二つの流儀があり、ひとつは通番を振る方法、もうひとつは名前をつける方法があります。通番を付ける方法は帳票を途中に追加すると、通番が変わってしまうため表計算ソフトなどで扱える程度の小さなデータでは使う事がありますが、スマートシティなどでは名前を付ける方法が採用されます。その帳票を識別するための名前をIDまたはidと言います。
idは元々はidentifierの略です。identifierは日本語では識別子などと呼びますが、Entityの識別だけでなく、Attribute名やEntity typeなどの各種名前もidentifierと言うため、区別のために通常idまたはIDと二文字で表現します。尚、例えば自治体標準オープンデータセットの様にNOなどと別の呼び方をする場合もあります。また、「共通データ仕様とは」の説明では、日本語で帳票番号と表現しました。協議会では、NGSIの規格に倣い、idと表現します。
idの役割は二つあり、ひとつはEntityを区別する事、もう一つは特定のEntityを読み出す事です。Entityを区別するとは、Entityを登録する時、idが同じだと同じEntityだと考えるルールになっているという事です。例えばある建物があり、その建物の情報を”abc000″というidを持つEntityで登録することを考えましょう。最初にEntityを登録する時にidは”abc000″、Attributeとしてその土地の住所を登録したとします。次にEntity登録する時、idはabc000で同じですが、Attributeとしてその土地の座標の情報を登録したとします。すると、idが同じなので同じEntityだと理解されます。その結果、そのEntityには住所と座標の二つのAttributeが登録される事になります(正確には、APIの指定により追加するモードと二回目をエラーにするモードがあります)。NGSI V2に準拠するシステムにはidを指定してEntityを読み出す機能が実装されていますから、”abc000″というidでEntityを読み出すと、そのEntityには住所と座標の情報が登録されている事になります。
次にこのEntityを読み出す機能を使ってリンクを利用する例を記載しましょう。「建物」のEntityにはその建物が建っている「土地」のEntityへのリンクを登録しておくと、建物の帳票を読み出すと、そのリンクから土地のEntityのidが分かりますので、いつでも土地の情報も得る事が出来ます。
idはEntityを区別するための名前であると書きました。従って、別のEntityに同じidを付けてはいけません。この際に考えておかないとならないのは、どの範囲で名前が重複しない様にしなければならないかというルールです。例えば、以下の様になっています。
- NGSI V2
NGSI V2はデジタル庁がエリア・データ連携基盤の推奨モジュールとしているFiware/Orionの規格です。この規格では、データモデル(Entity type)毎に重複が無い様にするルールです。従って、データモデルが違うと同じ名前がidになっている可能性があります。このため、帳票を特定するためにはデータモデル名とidの両方を指定する必要があります。また、重複を許さない範囲は、エリア・データ連携基盤の個々のシステム(技術用語では実装といいます)の中だけです。つまり、別の実装とはidが重複する事があります - NGSI-LD
NGSI-LDは、NGSI V2の後継規格です。この規格では、全てのデータモデルで重複が無い様にするルールです。このため、idを指定するだけで、帳票を特定できます。但し、実装が異なればidが重複する可能性があります - 推奨データセット
自治体内とデータモデル内で重複しなければ良いというルールです。従って、自治体名(自治体コード)とデータモデル(自治体標準オープンデータセットではデータセット名)とNOのみっつを指定すると、Entityが特定できます - 本協議会
本協議会では、データ仕様はNGSI V2に準拠していますが、idだけは、NGSI-LDに準拠しています。従って、idを指定すると帳票が特定できます。尚、idのルールはデータモデル毎に異なりますので、詳しくは各データモデルのidを確認してください。可能な範囲で実装が異なってもidが重複しない様に工夫しています
一般に公開されている識別子のidへの活用
では、どの様な名前をidとして使えば良いかについて、考えてみましょう。
多目的なデータモデルでは、データモデルは「モノ」や「コト」の単位に策定すると記載しましたが、モノやコトによっては、特定する番号や文字列から振られている場合があります。例えば、土地や建物であれば不動産IDがありますし、法人であれは法人コードがあります。その様な場合はその番号や文字列から機械的にidを生成できる様にすると便利です。例えば、共通データ仕様の「法人」では、idを
”urn:ngsi-ld:Organization:”<国名コード><法人番号>
と規定しています。国名コードは日本の場合は”JP”です。従って、情報を知りたい法人のの法人番号が分かれはその法人に対応する帳票のidを機械的に生成できるので、その法人の情報が直接読み出す事が可能となります。また、これらのコードに重複が無い事は公的な機関などが保証してくれるので、利用者が心配する必要はありません。この様に公開されていて、「モノ」や「コト」に紐づいている重複のない番号や文字列があれば、それをidに活用すると何かと便利です。
