データモデルがバラバラにならない仕組み
データモデルが人間が使う「帳票」と同じ考え方である事は既に説明しました。この観点でもう少し掘り下げて説明します。
人間が使う紙帳票では、帳票を各自治体などの法人がてんでバラバラに策定するのではなく、帳票の標準的な様式を政府や業界団体が公開し、各法人はその標準的な様式を踏襲しつつ、地域性や業務の特性を加味して帳票を用意する方法が採用されています。この様に帳票の様式の定義を階層化する事で帳票を策定する側は項目の抜けなどの誤りを起こしにくくなり、利用者は帳票を提出する法人が異なっても似た帳票で申請等の手続きを行うことが出来るので戸惑いません。コンピュータ用の帳票も同様で、データモデルのひな形が用意されています。データモデルのひな形の関係を以下に示します。上に行くほど基本的なひな形で、下に行くほど具体的な業務に最適化されます。尚、この整理は人によって議論が食い違う所であり、専門や業界によっても整理の仕方が異なります。下図の説明は共通データ仕様がどの様な考え方で策定されているのかを理解するための整理だと理解してください。
| 説明 | 参考情報 | |
|---|---|---|
| 概念モデル | 「人」「組織」「場所」等の基本的な「概念」と概念間の「関係」を定義したものです。ここでいう概念とは「モノ」や「コト」の事だと理解してください。モノやコトとしては現実世界のモノやコトをイメージすると分かりやすいですが、定義の上ではネットワーク上や仮想空間上のモノやコトも含みます。 | 英語ではConcepttual Modelsと言います。 デジタル庁のコアデータモデルはこの概念モデルの役割を兼ねていると思われます。 |
| コアデータモデル(+コア語彙) | 分野横断で共通利用される「人」「組織」「場所」等の基本的な「概念」に対しどの様な属性(項目)があるのかを定義してある、最も基本となるデータモデルのひな形です。システム間の相互運用性を確保し、円滑なデータ連携を実現するための基礎となるデータ構造の定義集です。このデータモデル群は利用目的を限定しませんので、多目的データモデルです。つまり、概念モデルと同様にモノやコト毎に策定され、それらが関係づけられます | EUののデジタル戦略の定義でもデジタル庁同様にコアデータモデルと呼びます。当初「コア・データモデル」と中点をつけて表記する事が多かったので、その様な表記も同じものだと考えて下さい。 |
| ドメインデータモデル | 各分野の実情に合わせた概念を定義するデータモデルです。コア・データモデルを継承してデータモデルのひな形として策定されます。人間の言葉にも方言や業界用語がありますが、それに該当します。各業界団体などが策定する事を期待されています。どの様な項目が存在し得るのか、各項目にはどの様な制約があるのか、概念間の関係はどうなっているのかについて記載はありますが、具体的にどう実装するのかについては全てが記述されているとは限りません。このデータモデル群もコアデータモデルと同様に利用目的を限定しませんので、多目的データモデルです。 | EUののデジタル戦略の定義でもデジタル庁同様にドメインデータモデルと呼びます。当初「ドメイン・データモデル」と中点をつけて表記する事が多かったので、その様な表記も同じものだと考えて下さい。「デジタル化」はドメインの壁を越えて情報共有する事もひとつの重要な要素ですから、このドメインデータモデルの在り方もまだまだ議論が必要です。 |
| データモデル アプリケーションプロファイル 実装データモデル | ドメインデータモデルを継承して策定する、具体的に実装上のデータの構造や制約を決めるための約束事です。ここでは、データの構造だけでなく、具体的な実装方法まで決める事になります。例えば、既に例示したJSONで記述するとか、CSVでデータを作成するなどです。 このレベルを二つまたはそれ以上のレベルに分ける考え方もあります。例えば、ドメインデータモデルを継承して会社の標準のデータモデルを策定し、各部門はそれを更に継承して実装するデータモデルを最終的に決定する様な考え方です。 このレベルでは多目的データモデルと目的別データモデルがあります。つまり、実装や利用目的に合わせて適切に仕様を決定していくという事になります。 | 自治体標準オープンデータセットはこのレベルですが、その場合はこのレベルを2レベルに分け、デジタル庁の自治体標準オープンデータセットはひな形、個々の自治体のオープンデータの仕様は具体的な実装仕様となります。 |
共通データ仕様は、3番目のドメイン・データモデルと4番目のデータモデルに該当します。尚、用語についてはそのまま準拠する事を求めていますので、一番下のデータモデルの性格を帯びています。
共通データ仕様を活用する方はドメイン・データモデルとデータモデルとしての共通データ仕様を「継承」して個々にデータを定義する必要があります。継承の方法については後述します。
データモデルの「継承」
コアデータモデル(コア語彙を含む。以下同様)は最も基本的なデータモデルのひな形ですから、色々な目的で利用可能でなくてはなりません。人間の認識や行動は現実の世界、例えば施設管理であれば「施設」「建物」「設備」などのモノや、「不具合」「修繕」「報告」などのコトを対象に行います。従って、コンピュータ内にデータを取り込む際に、もし現実世界のモノやコトの情報をそのままコンピュータ上のデータとして写し取る事ができれば人間は色々な行動に利用できることが出来ます。そこで、コアデータモデルは現実の世界(正確には仮想世界も含めて)写し取る事が出来る様に考えてあります。具体的には、「法人」「人」「施設」「土地」などの現実のモノや「イベント」などのコト単位に策定されています。つまり、コアデータモデルは多目的データモデルです。
では、各モノやコトの定義はどうなっているのでしょうか。答えは簡単で、項目が並んでいるだけです。つまり、人であれば「氏名」「生年月日」「性別」「住所」などの項目が並んでいます。例えばある人の「氏名」は「西郷隆盛」で、「生年月日」は「1828年1月23日」で「性別」は「男性」で、、、という具合です。何のことはない、大仰な説明をしてきましたが、単なる帳票そのものですね。台帳と言った方がしっくりくるかもしれませんね。大事なのはモノやコトの単位に帳票を作ると言う事なのです。
ドメインデータモデルはコアデータモデルを継承すると説明しました。ではこの継承とは何でしょうか。例えば、人事向けのデータモデルであれば、「社員番号」とか「入社年月日」など、人事に特有な情報を登録する項目を追加する必要がありそうです。一方で、「本籍」は不要でしょうし、「身長」や「体重」は変化しますから登録する事は難しそうですし、人事としての意味は薄そうです。この様に目的に合わせて追加や取捨選択などの最適化を行う事が継承という事になります。モノやコト自体を追加する事もあり得ます。
データモデル間の「関係」
データモデルを理解するうえでもうひとつ大事な考え方があります。それはモノやコトの間の関係です。例えば、「建物」というモノと「人」というモノ(モノという表現は違和感はありますがご容赦下さい)との関係には「住居」が考えられます。例えば「田中」さんの「住居」は「〇丁目〇番地の一軒家」と言った感じです。田中さんのデータの「住居」という項目には「〇丁目〇番地の一軒家」を示す情報が格納されているイメージです。この田中さんの情報の中の住居を示す項目で「〇丁目〇番地の一軒家」を示す情報としては、通常は建物の帳票の主キーを使用します。主キーは他の建物と必ず違う値(識別子)が登録されているので、主キーが分かれば住居となっている建物の情報を取り出す事ができます。この様にモノやコトのデータ(帳票)がコンピューター内に沢山登録されていて、そのデータ間が網の目の様に関係づけられている事で現実世界のモノやコトの情報を写し取る事が可能となっています。実は、人間用の帳票でもこの考え方を活用している場合もあります。例えば、会社で社員が何かの申請を会社に提出する時、全ての社員情報を帳票に記入する代わりに社員番号を記入するやり方はどこの組織でも採用されていると思います。そうする事で、帳票を受け取った側がもし帳票の項目に無い情報も知りたいときは社員番号から必要な情報を求める事が可能となります。
ドメインデータモデルはコアデータモデルを継承しつつ、その業界や専門分野で多様なデータのひな形となるものです。従って、コアデータモデル同様にモノやコトの単位に策定されています。共通データ仕様はドメインデータモデルでもあるので、やはりモノやコト毎に策定されています。また、「関係」も定義されています。共通データ仕様のこれらの点については詳しく後述します。データモデルとは既に説明した様に個々の帳票のひな形の様なものですから、データは帳票そのものです。その帳票の様子を以下の図にしました。この図では、帳票は束ねられて台帳になっています。各帳票にはidがあり、そのidを使って、帳票間の関係が表現されています。
