表形式のデータモデルの設計
共通データ仕様を活用してCSV等の表形式のデータ仕様を設計する際の考え方について説明します。
ここでいうデータ仕様とは、どの様な項目を設ける、それらの項目名は何にするか。そしてそれらの項目にはどの様な数値や文字列を登録するかの決め事です。表形式のデータ仕様の策定手順はあまり主流となるものはない様に思いますが、本章では整理のために以下の手順で行います。尚、使用しているFMシステムが共通データ仕様通りのデータ仕様を実装しているかどうかは表形式のデータ仕様の策定に関係ありません。勿論、最終的にどこなも無い情報は項目としては成立しませんが、それは最後の調整の手順で検討します。以降、順を追って説明します。
①データの利用目的を明確にする
データを表形式にまとめる事は、人間にとって視認性が良く、集計やグラフ化などの二次加工も容易である事からとても便利な方法方です。一方で、後で詳しく記載しますが表形式のデータは非常に制約が多く、自由に情報を表現する事が困難です。そこで登録する情報を減らすなどの妥協を行って無理やり表形式に収める必要があります。当然ながらデータの利用目的に反する妥協はやりたくないですから、目的を明確にしてなるべく影響が無い様に工夫して妥協していく必要があります。
もうひとつ、目的を明確にする事で表の1行をどの様なモノやコトに対応するべきかが明確になります。例えば、設備の管理をするために設備一覧が欲しいのか、予算の消化状況を管理するために案件一覧が欲しいのかなどです。
ここまでは、表形式のデータを作った事がある人であれば、言われるまでもなく当たり前に実施していたかと思います。しかし、次のステップ以降でこの目的が意味を持ってきます。
②継承するデータモデルを決める
目的を明確にしたことで、どの様なモノやコトを1行にまとめるのかが決まりました。共通データ仕様のデータモデルはモノやコト毎に作られていました。そこで目的に合致するデータモデルを継承するデータモデルとします。以下、共通データ仕様の各データモデル(2025-12-21現在)が対応するモノやコトを一覧にします。
| データモデル | 説明 | |
|---|---|---|
| 法人 (Organization) | 自治体 事業者 メーカー | 自治体と民間団体共通の法人を表現するデータモデルです。名称、通称、法人番号、自治体コードなどを登録できます。 |
| 部門 (Department) | 部門 | 法人 (Organization) 内の部門や機能を表現するデータモデルです。実際の部門だけ手なく、コールセンターや総合窓口などの組織内の機能も部門と同様に表現できます。部門名、部門番号、連絡先などを登録できます。 |
| 土地 (Land) | 土地 敷地 | 土地や敷地を表現するデータモデルです。住所、用途、名称、面積、座標、形状(ポリゴン)、防火地域、建蔽率、容積率などを登録できます。 |
| 建物 (Building) | 建物 棟 | 建物や建物を構成する棟を表現するデータモデルです。名称、構造などを登録できます。 |
| 施設 (Facility) | 施設 テナント | 施設を表現するデータモデルです。通常施設管理の単位となる建物や敷地も含めた施設全体と、施設内に入居するテナントの両方を表現できます。 |
| 部位 (BuildingComponent) | 部位 | 天井、窓、床などの施設を構成する部位を表現します。建築物だけでなく、部屋の空間なども表現できます。名称(管理上付与する名称)、施設内の位置などを登録できます。 |
| 設備 (Device) | 設備 | 照明器具や空調機などの設備を表現できます。設備の種類、場所(設置位置)、設置日、製造日、製造番号などを登録できます。 |
| 案件 (Complaint) | 不具合 クレーム 要望 | 施設や設備の修繕の起点となる不具合(障害)などを表現できます。発生日、完了日、現象、原因、処置などを登録できます。 |
| 報告 (Report) | 報告 | 報告に関する情報を表現できます。報告書名、報告書の所在場所、報告日などを登録できます。 |
| 観測手順 (Procedure) | 作業手順 | 各種計測機器による計測や確認作業の手順を表現できます。手順の名称、実施手順、良否の判断基準などを登録できます。 |
| 観測活動 (Observation) | 測定 確認 | 各種計測機器による計測や確認作業の実施結果を表現できます。確認の良否、測定結果、不良であった場合の処置、手順の名称、実施手順などを登録できます。 |
どのデータモデルを継承するのかを決めたら、表形式のデータの項目として採用したい項目を選択します。例えば、設備一覧であれば名称と種類と場所と設置日を項目に採用しようというイメージです。この際、表形式の項目名として共通データ仕様のデータモデルの説明にある「呼称」を使えないか検討してください。本ホームページのケーススタディでは項目名に呼称を用いているため、ケーススタディを使いやすくなります。
③項目を取り込む範囲を決める
前の手順で継承するデータモデルを決めましたが、表形式の項目として採用できるのは、そのデータモデルだけではありません。そのデータモデルが他のデータモデルとの関係を登録してある場合、関係先のデータモデルの項目も取り込む事が可能です。以下、共通データ仕様の各データモデル(2025-12-21現在)が関係するデータモデルを一覧にします。
| 継承データモデル | 説明 | |
|---|---|---|
| 法人 (Organization) | 施設 土地 | 法人の本社が入居する施設やその敷地の情報です。住所などが登録されています。 |
| 部門 (Department) | 法人 施設 土地 | 所属する法人と、部門が所在する施設やその敷地の情報です。法人名や住所が登録されています。 |
| 土地 (Land) | 土地は建物と関係していますが、土地から見ると複数の建物があり得るので、もし建物の情報が必要であれば建物一覧を作成する事を検討してください。 | |
| 建物 (Building) | 土地 建物 | 建物全体を表現する「建物」の場合、土地に敷地の情報が登録されています。土地の情報としては住所が最も重要な情報です。 棟を表現する「建物」の場合、棟を含む「建物」の情報が登録されています。 |
| 施設 (Facility) | 建物 | 施設が入居する建物の情報を取り込むことが出来ます。更に建物のデータモデルを経由して、土地の情報も取り込む事が出来ます。 |
| 部位 (BuildingComponent) | 施設 建物 | 部位が属する建物や施設の情報を取り込む事ができます。 |
| 設備 (Device) | 施設 建物 機種 (DeviceModel) | 部位が属する建物や施設の情報を取り込む事ができます。また、機種からは機種名、メーカ名、型番などの情報を取り込む事ができます。 |
| 案件 (Complaint) | 設備 建物 部位/設備 | 案件が発生した施設、建物、部位または設備の情報を取り込む事ができます。 |
| 報告 (Report) | 法人 報告 施設 建物 案件 | 報告者の法人情報、報告が複数に分かれている場合の関連する報告、報告対象の不具合等を示す案件情報、およびその案件の施設や建物の情報を取り込む事ができます。 |
| 観測手順 (Procedure) | 施設 部位/設備 設備(センサ―) | 測定や確認の対象となる施設や部位または設備、および測定に使用するセンサーの情報を取り込む事が可能です。尚、観測手順は複数のステップから構成されるので、単純に「観測手順一覧」の様な表形式には変換できません。この点については、⑤の手順を参照してください。 |
| 観測活動 (Observation) | 観測手順 部位/設備 | 測定や確認の対象であった部位や設備、観測活動を定義した観測手順の情報を取り込む事が可能です。 |
取り込む項目も、表形式の項目名として共通データ仕様のデータモデルの説明にある「呼称」を使えないか検討してください。
④識別子を決める
識別子とは聞きなれない方も多いかと思いますが、他と重複しない名前の事を識別子と言います。コンピューターの世界ではデータの一つひとつに必ずデータの識別子を付与します。共通データ仕様ではデータはモノやコト毎に作成されますから、結局モノやコトに識別子が付与される事になります。この考え方は実生活でも広く採用されています。自治体であれば自治体コード、人間であればマイナンバー、法人であれば法人番号が付与されています。この識別子が無いと、同姓同名の人の区別が付けられないなどがあります。データの識別子は一つの項目で構成されるとは限りません。部門であれば法人番号と部門番号を組み合わせれば一意に識別可能です。識別子を項目として持つ事で、他のデータと突き合わせをして二次利用する事が可能となります。
表形式のデータ仕様を策定する際には、識別子となる項目を必ず含む様にする事を強く推奨します。尚、表データの行番号の様に変化する値や、部門や作業の範囲だけで通用する情報を識別子とする事は避けて下さい。それをやるとそのデータを保存しておいても後で役に立たなかったり、人手をかけてデータを揃え直す事になります。
| 識別子候補と補足説明 | |
|---|---|
| 共通データ仕様の”id”、法人番号、マイナンバー、JANコードの様に変わらず重複がないもの。「法人番号+部門番号」「法人番号+型番」「法人番号+製造番号」の組み合わせの様に変化させず重複もない様に運用されているもの。 適切な識別子が無い時には、識別子を新たに生み出す事が必要です。この時には、その識別子をデータベースや台帳などで管理して重複や変更が発生しない様に管理する必要があります。 | |
| 悪い例 | 児童の出席番号の様に期間限定のもの。名称など変化するもの。建物名の様に建て直して別のモノになつても同じ可能性があるもの。氏名、住所、生年月日、電話番号の様に重複や変更があり得るもの。 |
⑤項目を決める
いよいよ表形式の項目を決める手順です。ここまでの手順でどの情報を取り込みたいかは決まっていますから、ここではそれぞれの情報をどういう形式で取り込むかを決めます。この検討で大事なことは、表形式のデータの制約をどう回避するかです。表形式のデータには多くの制約があります。以下に制約事項を列挙します。
| 制約の説明 | 回避方法例 | |
|---|---|---|
| リスト表現ができない | 共通データ仕様ではひとつの項目に複数の値を持つリスト表現を許しています。リスト表現とは”通称”の様に幾つもの値を持つものを指します。例えば法人の通称を登録する事を考えると、東日本旅客鉄道株式会社の場合利用者はJR東日本、JR東、JR East、JREなどの多様な呼び方をしていますが、世の中の法人が最大幾つの通称を持っているかは分かりません。 | 通称一覧の様な別のファイルを作るか、通称の数を制限して「通称1」「通称2」「通称3」などといった複数の項目を設けるなどの方法をとる必要があります。尚、カンマなどを挟んで複数の値を一つの項目内に並べて記述するなど、独自の記述方法で回避する場合もありますが、データを受け取った側は個別に対応する必要があり、余り望ましい回避方法とは言えません |
| 数値表現があいまい | CSVでは数値含めてすべての値は文字列で表現しますが、文字列が数字だけからなり、数値にも見える場合の処理は処理系に依存します。例えば、Excelでは何も属性を指定しないで”0123”という文字列を読み込むと、数値であると解釈され”123″と書き換えられてしまい頭の”0″と言う文字が消えてしまいます。 | 数字が並んでいても文字として扱いたい場合は、表の作成者や利用者にその旨を事前に伝えておく必要があります。 |
| 論理表現ができない | 普及している表形式の仕様には値をTrueやFalseで表現する論理表現はありません。 | 一般には”有”と”無”や、”真”と”偽”の文字を入れる事で代替えします。尚、利用者が勝手に”調査中”とか”不明”などの文字列を登録する事が可能となるので、その旨を徹底しておく必要があります。 |
| 構造表現ができない | 表形式では構造を持つ値は表現できません。構造を持つ項目とは例えば住所の様に「都道府県、市区町村、それ以下」の複数の値から構成されている様な項目です。 | 一般的に項目を分けます。左記の例ではみっつの項目に分けて「住所の都道府県」「住所の市区町村」「住所のそれ以下」等の様に登録します。尚、住所の場合はそれらをくっつけて、一つの項目で住所全体を表現する項目を別に設ける事も可能です |
| 不定な項目名を表現できない | 共通データ仕様はGIFのコア・データモデルのID情報型では、 [{“ID種別”: “自治体コード”, “ID”: “0123456”},{“ID種別”: “法人番号”, “ID”: “4321-4940980123456”}] などと記載する事を可能としています。 | 表形式では項目名を予め決めておく必要があるので、「自治体コード」と「法人番号」に項目を分けて登録します。但し、新たな項目を追加すると仕様が変わってしまい、柔軟性が低下してしまいます。 |
| 項目が無い状態を表現できない | CSVでは各行の構造は一致している必要があるので、ある行だけある項目が無いという状態を表現できません。まだ登録していない項目が、未登録なのか値が無いのかが区別がつきません。例えば前記の”通称”の例では、CSVでは通称をまだ登録していない状態と通称は無い事を登録している状態が区別できません。 | 長さがゼロの文字列として表現されると定義します。 |
| 値が無い状態を表現できない | 前項と似ていますが、CSVでは項目はあるが値が無いという状態を表現できません。値が空であるとか長さがゼロの文字列であるという事とは厳密には違います。表形式の場合は長さがゼロの文字列となってしまいます。 | 長さがゼロの文字列として表現されると定義します。前の項目の状態とは区別がつきません。 |
| 項目の順番が意味を持つ | 表形式の場合、項目には順番があり何番目の項目なのかに意味を持たせることが可能です。この様な使い方をすると、項目を追加すると順番がずれたりして処理する際に不具合を発生させます。 | 既に説明した識別子の項目で識別するデータとします。 |
| 文字コードが多様 | インタネット上の文字コードはUTF-8に収れんしつつあります。NGSI V2の文字コードもUTF-8であり共通データ仕様もUTF-8ですが、CSVや表計算ソフトは多様なコードを許しています。 | 特段の事情が無い限り文字コードはUTF-8を採用します。別の文字コードを採用すると、変換時に文字化けするリスクがあります。 |
⑥関係者と調整します
ここまでで、どの様な項目を表形式の項目として採用したいがどうかが決まりました。しかし、管理してない情報を提供する事はできない(その分余計に費用や時間が掛かる)ので、関係者間で調整が必要です。他にも調整が必要な項目が幾つかあります。以下、例示します。
- 「年月日」はGIFやISOでは”YYYY-MM-DD”の形式であり、共通データ仕様もその標準に従っていますが、一部の表計算ソフトでは”YYYY/MM/DD”の形式の場合があります
- 「住所」は共通データ仕様ではグローバル標準に合わせて「都道府県」「市区町村」「町字以下」のみっつの項目で構成されています。一方、GIFでは多様な表現を許容しており、何らか対応が必要な可能性があります
- 「住所」内における特別区以外の区(政令市の区)の扱いも、共通データ仕様ではグローバル標準に合わせて「町字以下」に含めています。この点についても何等かの対応が必要な可能性があります
以上で共通データ仕様を継承した表形式のデータ仕様の策定方法の説明は終了です。尚、実際にCSVの項目を策定した事例はケーススタディ#1に掲載しましたので、参考にしてください。
