データモデルとは (2/3)

データモデルがバラバラにならない仕組み

　データモデルが人間が使う「帳票」と同じ考え方である事は既に説明しました。この観点でもう少し掘り下げて説明します。

　人間が使う紙帳票では、帳票を各自治体などの法人がてんでバラバラに策定するのではなく、例えば政府や業界団体が標準的な帳票のひな形を公開し、法人はその標準的なひな形を踏襲しつつ、地域性や業務の特性を加味して帳票を用意する方法が採用されています。この様にする事で帳票を策定する側は項目の抜けなどの誤りを起こしにくくなり、利用者は帳票を提出する法人が異なっても似た帳票で申請等の手続きを行うことが出来るので戸惑いません。コンピュータ用の帳票も同様で、データモデルのひな形が用意されています。データモデルのひな形の関係を以下に示します。上に行くほど基本的なひな形で、下に行くほど具体的な業務に最適化されます。尚、この整理は人によって議論が食い違う所であり、専門や業界によっても整理の仕方が異なります。下図の説明は共通データ仕様がどの様な考え方で策定されているのかを理解するための整理だと理解してください。

デジタル庁の定義	説明	参考情報
コア・データモデル(+コア語彙)	分野横断で共通利用される「人」「組織」「場所」等の基本的な「概念」を定義してあり、基本となるデータモデルのひな形です。ここでいう概念とは「モノ」や「コト」の事だと理解してください。システム間の相互運用性を確保し、円滑なデータ連携を実現するための基礎となるデータ構造です。	EUののデジタル戦略の定義でもデジタル庁同様にコアデータモデルと呼びます
ドメイン・データモデル	特定分野の専門的な概念を定義するデータモデルです。コア・データモデルを継承して(ひな形として)策定されます。各業界団体などが策定する事を期待されています。どの様な項目が存在し得るのか、各項目にはどの様な制約があるのか、概念間の関係はどうなっているのかについて記載はありますが、具体的にどう実装するのかについては全てが記述されているとは限りません。	EUののデジタル戦略の定義でもデジタル庁同様にドメインデータモデルと呼びます
データモデル (このカテゴリを総称する名称は定義されていないと思われます。人によってはドメイン・データモデルに包含されていると解釈しています)	ドメイン・データモデルを継承して策定する、具体的にデータの構造や制約を決めるための約束事です。一般的にデータモデルと言うと、このカテゴリのデータモデルを指すことが多いようです。ドメイン・データモデルと明確に区別したい場合にはアプリケーションプロファイル(AP)などと呼ばれる事もあります。例えば、デジタル庁が公開している自治体オープンデータセットがこれに該当します。また、デジタル庁では「実装データモデル」という呼び方をする場合がありますが、それはドメイン・データモデルとこのアプリケーションプロファイルを合わせたものと解釈できます。	EUの例では「DCAT-AP」があります。欧州のデータポータル間で国境を越えた検索を可能にします。DCATの一般的概念に対し「どの要素は必須か」「どのEU標準のコードリストを使用すべきか」といった厳格なルールを適用することで、欧州全域でのデータ交換を実現しています。
	アプリケーションプロファイルに従って決めたデータの形式です。自治体のオープンデータでは各自治体のデータの定義そのものです。この個々の定義をデータモデルと呼ぶ場合もあります。	EUののデジタル戦略ではスペシフィケーションとよぶ場合やインタフェース仕様などと呼ぶ場合があります

　共通データ仕様は、二番目のドメイン・データモデルと三番目のアプリケーションプロファイルに該当します。但し、独自の項目の追加を許すなど、アプリケーションプロファイルとして全ての決め事を厳格に定義してある訳ではありません。尚、用語については準拠を求めています。

　共通データ仕様を活用する方はドメイン・データモデルとAPとしての共通データ仕様を「継承」して個々にデータを定義する必要があります。継承の方法については後述します。

データモデルの仕組み

　コア・データモデル(コア語彙を含む。以下同様)は最も基本的なデータモデルのひな形ですから、色々な目的で利用可能でなくてはなりません。人間の認識や行動は現実の世界、例えば施設管理であれば「施設」「建物」「設備」などのモノや、「不具合」「修繕」「報告」などのコトを対象に行います。従って、コンピュータ内にデータを取り込む際に、もし現実世界のモノやコトの情報をそのままコンピュータ上のデータとして写し取る事ができれば人間は色々な行動に利用できることが出来ます。そこで、コア・データモデルは現実の世界(正確には仮想世界も含めて)写し取る事が出来る様に考えてあります。具体的には、「法人」「人」「施設」「土地」などの現実のモノや「イベント」などのコト単位に策定されています。

　では、各モノやコトの定義はどうなっているのでしょうか。答えは簡単で、項目が並んでいるだけです。つまり、人であれば「氏名」「生年月日」「性別」「住所」などが並んでいます。例えばある人の「氏名」は「西郷隆盛」で、「生年月日」は「1828年1月23日」で「性別」は「男性」で、、、という具合です。何のことはない、大仰な説明をしてきましたが、単なる帳票そのものですね。台帳と言った方がしっくりくるかもしれませんね。大事なのはモノやコトの単位に帳票を作ると言う事です。

　ドメイン・データモデルはコア・データモデルを継承すると説明しました。ではこの継承とは何でしょうか。例えば、人事向けのデータモデルであれば、「社員番号」とか「入社年月日」を追加する必要がありそうです。一方で、「本籍」は不要でしょうし、「身長」や「体重」は変化しますから登録する事は難しそうですし、人事としての意味は薄そうです。この様に目的に合わせて追加や取捨選択などの最適化を行う事が継承という事になります。モノやコト自体を追加する事もあり得ます。

　データモデルを理解するうえでもうひとつ大事な考え方があります。それはモノやコトの間の関係です。例えば、「建物」というモノと「人」というモノ(モノという表現は違和感はありますがご容赦下さい)との関係には「住居」が考えられます。例えば「田中」さんの「住居」は「〇丁目〇番地の一軒家」と言った感じです。田中さんのデータの「住居」という項目には「〇丁目〇番地の一軒家」を示す情報が格納されているイメージです。この「〇丁目〇番地の一軒家」を示す情報としては、通常は建物の帳票の”id”を使用します。”id”は他の建物と必ず違う値(文字の並びなど)が登録されているので、”id”が分かれば住居の情報は取り出す事ができます。この様にモノやコトのデータ(帳票)がコンピューター内に沢山登録されていて、そのデータ間が網の目の様に関係づけられている事で現実世界のモノやコトの情報を写し取る事が可能となっています。実は、人間用の帳票でもこの考え方を活用している場合もあります。例えば、会社で社員が何かの申請を会社に提出する時、全ての社員情報を帳票に記入する代わりに社員番号を記入するやり方はどこの組織でも採用されていると思います。そうする事で、もし帳票の項目に無い情報を知りたいときは社員番号から必要な情報を求める事も可能となります。

　ドメイン・データモデルはコア・データモデルを継承しつつ、その業界や専門分野で多様なデータのひな形となるものです。従って、コア・データモデル同様にモノやコトの単位に策定されています。共通データ仕様はドメイン・データモデルでもあるので、やはりモノやコト毎に策定されています。また、「関係」も定義されています。共通データ仕様のこれらの点については詳しく後述します。

構造を持つデータを定義する場合の共通データ仕様の使い方 — この節は改版中です。掲載場所を移動予定です。

　「構造を持つ」とは例えばXMLやJSONなどと言った流儀で表現されたデータの事です。一般の利用者からは見えませんが、インターネットを飛び交うデータの多くはこの「構造を持つ」データです。以下に「構造を持つ」とはどういうことなのかを例示します。

構造を持つデータの特徴	説明
複数の情報を持つ事ができる	法人や施設の通称の様に複数ありえる情報です。例えば、「東日本旅客鉄道株式会社」の通称は「JR東日本」「JR東」「JR East」「JRE」など多様な名前で呼ばれています。
項目名が階層を持つ事が出来る	ひとつの項目に複数の項目を含む事を指します。例えば氏名という項目には「性」という項目と「名」という項目が含まれるイメージです

　この他に、表現する流儀によっては項目に補足的な情報を追加する事が出来るなど、色々な表現が可能です。

　この様な構造を持つデータのデータ仕様を定義する際には、共通データ仕様は構造含めてそのまま継承します。但し、”x-…”で始まる項目を追加したり、不要な項目を省略する事は構いません。共通データ仕様はデジタル庁がエリアデータ連携基盤の推奨モジュールであるFiwareの仕様であるNGSI V2に準拠していますが、個々のデータモデルは、他の形式、たとえばNGSI-LDを策定する際に困らない様に、NGSI V2の一部の規定を使用しない様に配慮してあります。

表形式のデータを定義する場合の共通データ仕様の使い方 — この節は改版中です。掲載場所を移動予定です。

　表形式とは、CSVの様に行と列からなるデータの事です。表計算ソフトなどとも親和性が高い事から一般的に広く利用されています。一方で、前記の様な構造は表現できませんので、目的ごとに策定する必要があります。

　以下、表形式で共通データ仕様の規定をどう扱う事が望ましいかを記載します。具体的な事例はケーススタディ#1に掲載してあります。

共通データ仕様の定義	表形式のデータ定義での使い方
項目名	項目名はそのまま使用しても構いませんが、分かりにくい場合は各項目に記載してある「呼称」の利用を検討してください。本ホームページのケーススタディでは、呼称を項目名として使用していますので、ケーススタディがそのまま活用できます。
階層を持つ項目名	一番細かい項目を表形式の一つの項目とします。例えば、住所の場合は「都道府県」「市区町村」「町字以下」「郵便番号」のよっつの項目に分けるなどです
“id”	“id”はデータを一意に識別するための文字列です。”id”はデータ同士の突き合わせなどの二次利用に必要な項目です。従着て、このまま表形式の項目として継承するか、”id”と変換可能な項目を一つ以上項目として採用します。例えば、法人情報であれば”id”の代わりに法人番号の項目を設ける、施設の場合は施設の通番の項目を設けるなどが考えられます。”id”とそれらの項目の内容は機械的に変換できる必要があります。
回数	ここで言う回数とは複数の情報を持つことが出来る場合の情報の個数です。表形式では複数の情報をひとつの項目に登録する事は出来ませんので、最大の個数を決める必要があります。例えば「通称は最大3っつとし、項目をみっつ使う」などと決めます。
typeがBoolean	Booleanとは真と偽を表現できるという意味です。表形式ではこの様な表現は出来ませんので、例えば”あり”と”なし”の二種類の文字列に書き換えるなどの決まりです。
typeがRelationship	Relationshipとは、他のデータをリンクする情報、具体的にはリンク先のデータの”id”が登録されています。例えば、施設-建物-土地の情報はリンクで繋がっています。表形式では他のデータと同期をとった保存や処理が難しいので、リンク先の項目の内、必要な項目の内容を表形式のデータの項目として取り込みます。例えば、ある建物の一覧を表形式のデータとして策定する場合、建物が属する施設の名称や敷地の住所も表形式の項目に取り込むという意味です。