表形式のデータモデルの設計
このページでは、共通データ仕様を継承してCSV等の表形式のデータ仕様を設計する際の考え方について説明します。共通データ仕様はドメインデータモデル、つまり多様な業務に継承される事を前提とした多目的データ仕様として策定されていますし、日本語の項目名の参考となる様に「呼称」という名前を項目に付与していますので、それを活用して表形式のデータ仕様を策定します。
ここでいうデータ仕様とは、どの様な項目を設けるか、それらの項目名は何にするか。そしてそれらの項目にはどの様な数値や文字列を登録するかの決め事です。表形式のデータ仕様の策定手順はあまり主流となるものはない様に思いますが、本章では整理のために以下の手順で行います。尚、使用しているFMシステムが共通データ仕様通りのデータ仕様を実装しているかどうかは表形式のデータ仕様の策定に関係ありません。
尚、CSV等の表形式のデータは、「表形式」という制約が大きいものの、かなり自由度が高いデータの形式です。そこでここでは、施設管理の事業者がオーナー(公共施設では自治体等)に提出するデータであるとします。つまり、保存したり後で集計や突き合わせなどの二次加工をすることを前提とします。以降、順を追って説明します。
①データの利用目的を明確にする
データを表形式にまとめる事は、人間にとって視認性が良く、集計やグラフ化などの二次加工も容易である事からとても便利な方法方です。一方で、後で詳しく記載しますが表形式のデータは非常に制約が多くあります。制約を回避するためには、登録する情報を減らすなどの妥協を行って無理やり表形式に収める必要があります。当然ながらデータの利用目的に反する妥協はやりたくないですから、目的を明確にしてなるべく影響が無い様に工夫して妥協していく必要があります。
もうひとつ、目的を明確にする事で表の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) | 観測手順 部位/設備 | 測定や確認の対象であった部位や設備、観測活動を定義した観測手順の情報を取り込む事が可能です。 |
取り込む項目も、表形式の項目名として共通データ仕様のデータモデルの説明にある「呼称」を使えないか検討してください。
④主キーを決める
主キーとはデータを一意に識別する項目の事で、識別子と呼ぶこともあります。コンピューターの世界ではデータの一つひとつに必ずデータの主キーを付与します。共通データ仕様ではデータはモノやコト毎に作成されますから、結局モノやコトに主キーが付与される事になります。この考え方は実生活でも広く採用されています。自治体であれば自治体コード、人間であればマイナンバー、法人であれば法人番号が付与されています。この主キーが無いと、同姓同名の人の区別が付けられないなどがあります。データの主キーは一つの項目で構成されるとは限りません。部門であれば法人番号と部門番号を組み合わせれば一意に識別可能です。主キーを項目として持つ事で、他のデータと突き合わせをして二次利用する事が可能となります。
表形式のデータ仕様を策定する際には、主キーとなる項目を必ず含む様にする事を強く推奨します。尚、表データの行番号の様に変化する値や、部門や作業の範囲だけで通用する情報を主キーとする事は出来る限り避けて下さい。それをやるとそのデータを保存しておいても後で役に立たなかったり、人手をかけてデータを揃え直す事になります。
| 主キー候補と補足説明 | 注意点 | |
|---|---|---|
| 理想論 | モノやコトに付与された文字列であり、母集団の中の一つひとつのモノやコトを識別できるものです。以下の特徴があります。 ・すべてのモノやコトに別の文字列が付与される ・一つのモノやコトに複数の主キーは付与しない ・モノやコトが存在する間だけ手なく、無くなっても変化しない ・同じ文字列は再利用されない これら以外にも、なりすましや改竄を防ぐ機能を有する事を条件とする場合もあります。 実装方式としては幾つかあります。 ・集中型 主キーを作成するシステムや組織があり、前記の条件を満たす文字列を発行する ・分散型 中心となる組織と主キーを付与する組織があり、中心となる組織が重複が発生しない様にそれぞれの付与する組織の採番ルールを定める ・その他 UUIDやGUIDなどの乱数を使った重複のない文字列を発生させる 適切な主キーが無い時には、主キーを新たに生み出す事が必要です。この時には、その識別子をデータベースや台帳などで管理して重複や変更が発生しない様に管理する必要があります。 | データが表現するモノやコトが消失するまで変化せず、消失後も同じ主キーが付与されない様に運用する必要があります。また、主キーは組織や業務が異なっても、同じモノやコトであれば同じ主キーが付与されるように運用される必要があります。 集中型、分散型、その他のどの方法にせよ、個々の自治体や法人が単独で実施する事は不可能です。また、分散型のルールを誰かが決めたとしても主キーの採番を手作業で行う事は困難であり、通常は何らかのシステムを利用します。例えば、デジタル庁が推し進めるエリアデータ連携基盤などがあれば運用可能です。 |
| 法人番号、マイナンバー、JANコードの様に変わらず重複がないもの。「法人番号+部門番号」「法人番号+型番」「法人番号+製造番号」の組み合わせの様に変化させず業務や担当範囲を超えて重複がない様に運用されているものを項目として選びます。また、名称と住所など、識別子としては不完全であっても、組み合わせによってかなり識別子に近い項目も後で役に立つかもしれません。 | 法人番号は多くの町内会やボランティアグループは付与されていません。同様にマイナンバーは海外からの旅行者や制度が始まる前に亡くなった方には付与されていませス。従って、これらの項目を主キーとすると使える業務が限られてしまいます。防災や観光など対象が絞れない業務でのデータ活用を考える場合、名寄せという運用を考慮しておく必要があります。名寄せを行う場合、主キーは前記の「理想例」のものを使いつつ、左記の項目を使って同じモノ・コトである事を確認する運用が多いです。 | |
| 悪い例 | 児童の出席番号の様に期間限定のもの。名称など変化するもの。建物名の様に建て直して別のモノになつても同じである可能性があるもの。氏名、住所、生年月日、電話番号の様に重複や変更があり得るもの。同じモノやコトを表現するデータなのに違う識別子が割り振られるもの。モノやコトの一部だけを取り出して、その中だけで一意に識別するもの。例えば、災害発生時の被災者番号や避難所番号は主キーとして使用すべきではなく、二次キーとして活用すべきです。被災者は人というモノの一部(部分集合)であり、避難所は多様な施設の一部であるためです。 | これらの情報がキーとして意味がないと言っている訳ではありません。識別に寄与できる参考情報として有用なので、項目としては設定しておくべきと考えます。 |
主キーは他のデータからそのデータを参照される時に利用されます。例えるなら沢山の帳票が保存されている台帳における各帳票の通し番号の様なものです。台帳の帳票は多くの場合、その対象となるモノやコトが無くなってもその帳票は残しておく必要があります。例えば、施設台帳というものがあってその施設が立て替えられたからといって施設の情報を削除してしまうと、その施設に関する過去の分析が出来なくなってしまいます。そこで、主キーを決めた時には併せてそのデータの対象となるモノやコトが現在どういう状況であるかを示す項目の要否も考えておく必要があります。
⑤項目を決める
いよいよ表形式の項目を決める手順です。ここまでの手順でどの情報を取り込みたいかは決まっていますから、ここではそれぞれの情報をどういう形式で取り込むかを決めます。この検討で大事なことは、表形式のデータの制約をどう回避するかです。表形式のデータには多くの制約があります。以下に制約事項を列挙します。
| 制約の説明 | 回避方法例 | |
|---|---|---|
| リスト表現ができない | 共通データ仕様ではひとつの項目に複数の値を持つリスト表現を許しています。リスト表現とは”通称”の様に幾つもの値を持つものを指します。例えば法人の通称を登録する事を考えると、東日本旅客鉄道株式会社の場合利用者はJR東日本、JR東、JR East、JREなどの多様な呼び方をしていますが、世の中の法人が最大幾つの通称を持っているかは分かりません。 | 通称一覧の様な別のファイルを作るか、通称の数を制限して「通称1」「通称2」「通称3」などといった複数の項目を設けるなどの方法をとる必要があります。尚、カンマなどを挟んで複数の値を一つの項目内に並べて記述するなど、独自の記述方法で回避する場合もありますが、データを受け取った側は個別に対応する必要があり、余り望ましい回避方法とは言えません |
| 数値表現があいまい | CSVでは数値含めてすべての値は文字列で表現しますが、文字列が数字だけからなり、数値にも見える場合の処理は処理系に依存します。例えば、Excelでは何も属性を指定しないで”0123”という文字列を読み込むと、数値であると解釈され”123″と書き換えられてしまい頭の”0″と言う文字が消えてしまいます。 | 数字が並んでいても文字として扱いたい場合は、表の作成者や利用者にその旨を事前に伝えておく必要があります。 |
| 論理表現ができない | 普及している表形式の仕様には値をTrueやFalseで表現する論理表現はありません。 | 一般には”有”と”無”や、”真”と”偽”の文字を入れる事で代替えします。勿論、”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に掲載しましたので、参考にしてください。
