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