共通データ仕様の基礎知識 (4/5)

データの利用目的によるデータモデルの違い

 コンピュータとスマホとのデータのやりとりや、コンピュータ間のデータのやりとりはコンピュータ用の帳票を受け渡すことで実現しています。この帳票の一枚いちまいのことを技術用語ではEntityと言い、帳票のひな形のことをデータモデルと言うという事は既に述べました。一般の帳票はその目的に合わせて設計されますが、コンピュータ用の帳票のひな形であるデータモデルも同様に目的に合わせて設計します。逆に言うと、目的が決まらないとデータモデルは設計できません。

 一般の帳票でよく目にするものは、何か特定の目的に絞って策定されたものです。例えば、市役所に行くと、住民票請求用の帳票、印鑑証明請求用の帳票など、各帳票の目的は一つです。この様な帳票は目的が絞れるので、記入すべき項目が少なく、単純なものが多いと思います。しかし、一般には目にしませんが、多目的に使う事を前提とした帳票もあります。例えば、ひところニュースなどで耳にした、新型コロナの医療機関から行政機関への届け出は、色々な分析に備えて非常に多くの項目の記入が必要となっていました。データモデルも同様で、特定目的のデータモデルと多目的のデータモデルがあります。特定目的のデータモデルは一般に単純で、Attribute数も絞られます。これに対し、多目的のデータモデルは何も考えずに設計するとAttribute数が多くなってしまいますし、運用も難しいものになってしまいます。そこで、多目的のデータモデルは、後で述べるように「リンク」とか「データモデルの分離」という手法で単純化しています。

 本Webページでは、多目的のデータモデルと特定目的のデータモデルについて概説します。

多目的データモデルと特定目的データモデル

■多目的データモデル

 データを多目的に利用する事を想定したデータモデルです。何にでも使える「汎用」ではない事に留意が必要です。データを多目的に利用する場合、データモデルには一般的に以下の様な特性が必要です

  • 多目的データモデルは文字通り、色々な業務やアプリから利用されます。このため多目的データモデルは、データが長期間継続的に利用できる様にることを想定して設計します。長期間継続して利用するという事は、その期間の間にデータの一部が更新される事を想することが必要となります。例えば、企業情報であれば、所在地が変わったり連絡先の電話番号が変わったりするなどが想定されます。このため、変化に強いデータモデルである事が必要です。同じ情報がアチコチに登録される様なデータモデルだと、更新時に苦労する事になるだけでなく、不整合が発生する元となります

 この特性をデータモデルに実装するために、以下の様な手法を用います。

 〇データモデルを「コト」「モノ」単位に分割

モノとは建物、土地、ヒトなどの事であり、分割や融合が起きにくい単位です。コトとは「事故」「出荷」などの事象を指します。データモデルをこれらの「コト」や「モノ」の単位に合わせる事により、変化が少なく、変化時にも対応可能なデータモデルになります。例えば、住民の情報を登録する業務があったときに「個人」のデータモデルを作成します。そうすると、個人単位にEntityを作成する事になります。そうすると、名前が変わったときには、その個人のEntityに記載されている名前の情報を更新するだけで済みます。また、新たな住民が転居してきたら、その個人のEntityを一枚追加するだけで済みます

 〇リンクの利用

前記の個人を表現するデータモデルの例で、個人のEntityに住所情報も登録しておきたいと考えたとします。個人のEntity毎に住所情報を登録すると、同じ建物に住んでいる個人の住所情報は同じ内容がそれぞれ登録されることになります。

この様な煩雑さを避けるためには、建物というコトのデータモデルを新たに策定し、その建物のEntityに住所情報を登録します。各個人のEntityには住所情報を登録する代わりに、建物を求められる様にします。この個人から建物を辿る仕組みをリンクと言います。このリンクは実際には建物のEntityを区別するための名前を格納しています。この名前のことをid(アイディー)と言います。一般の名前と異なり、idは同姓同名は許されません。全てのEntityのidは異なっています。

この様にリンクを使うと便利なことが幾つかあります。例えば、以下のメリットがあります。

  • 上図の様に建物の情報が一つにまとめられていますので、例えば建物の住所表記が変更になっても一ヶ所を書き換えるだけで済みます
  • 図の建物では住所情報しかありませんが、建物を管理する別の業務があって、その業務の都合で例えば築年・耐震基準・地図などの情報も登録したとすると、各個人からも求められる情報量か増えます。そうすると、新たなアプリの開発などの応用も考えられるかもしれません。つまり、多目的データモデルの「多目的」とは、登録されている色々な情報が色々な目的で活用できる事を指しているのです

 〇外部のidの利用

リンクと同様な手法ですが、法人名・住所などの公開されている情報がある場合には、帳票を登録する代わりに法人番号や町字IDを登録する様にする手法もあります。企業所在地を知りたい場合は、何らかの方法で法人番号からその都度法人の所在地を求める様にすることで、変化し得る情報は登録せずに済みます。現在、日本でもベース・レジストリが整備されつつあり、この手法の現実性が出てくると思われます

尚、「多目的データモデル」と次項の「特定目的データセット」は一般的に通じる用語ではありません。一般的にデータの利用形態によるデータモデルの設計の相違を述べた文書は少なく、決まった用語は無いようです。本サイトでのみ通じる用語とお考え下さい。

■特定目的データモデル

 データの利用目的が予め限定される事を想定できるデータモデルです。目的に合わせて最適化する事が可能である事から、以下の様な特性を持っています。

  • 表形式など、シンプルな形式になっている事が多い
  • シンプルにするために、複数の「コト」「モノ」の情報が混在して一括登録されている事が多い
  • 情報を受け取った人が処理しやすいように、同じ情報が複数のEntityのAttributeにそれぞれ登録している事が多く、後で更新するには向かない形式である事がある
  • データセット(帳票の束)を一括して扱う事が多く、データをまとめて転送する場合に便利

特定目的データモデルの例としては、デジタル庁が公開している「自治体標準オープンデータセット(旧称: 推奨データセット)」があります。自治体標準オープンデータセットは多目的に活用できるオープンデータ向けのデータモデルなので「特定目的」との表現は誤解を招きそうですが、特性としては特定目的データモデルの特徴をよく表しています。

 右図は自治体標準オープンデータセットの「AED設置場所一覧」というデータモデルの抜粋です。項目を見ていくと、「モノ」としては、都道府県、市区町村、建物、土地、フロア、AED、団体の項目が一枚の帳票の中に一覧になる様に登録する仕様になっています。このため、利用者はこのデータを見るだけで、必要な情報が一気に取得できます。一方で団体の項目を見るとも、団体名や電話番号が記載されており、その団体の電話番号が変わったときには関係するデータ全てを洗い出して書き換える必要性が出てきてしまいます。このため、自治体標準オープンデータセットに準拠してオープンデータを公開している自治体は、定期的にデータ内容を最新化する必要があります。

 また、AED以外に都道府県、市区町村、建物、土地、フロア、団体の情報が登録されていますが、他の目的にこれらの情報を使おうとしても、それぞれのモノの項目はごく限られており、なかなか流用は難しいと思われます。

 余談ですが、特定目的データモデルでよく利用される表形式のデータモデルをフラット型とかカラム型と呼ぶこともあるようです。どちらも定義が定まった用語ではあません。内容から見ると、以下の意味を持つようです。

  • 階層を持たない (正確には2階層です)
  • リンクを持たない

もう一つ余談です。ここでいう階層ですが、2階層とは項目名と項目の値が対応している一般的な表形式の事で、3階層とはデータの値に更に補足情報が付属している事を指します。3階層の例としては「部屋」というモノのAttributeのひとつに「室温」があり、そこに「20度」という値が登録してあったときその「20度」に「10時ちょうどに測定した」という補足情報が付属している感じです。尚、座標というAttributeが「東経」と「北緯」というAttributeに分かれている事を階層とは呼びません。この様な場合は「値が構造を持っている」と言います。表形式(=フラット型・カラム型)のデータモデルと言った場合、値が構造をもっている項目を含めるかどうかは、人によって異なっている様です。

推奨データセットの「AED設置場所一覧」の項目一覧

2種類のデータモデルの使い分け

 実際にデータモデルを設計する場合には、両方のデータモデルを適材適所で使い分けます。

 「マスタデータ」と呼ばれる色々な目的で使われるモノやコトの基本情報であれば、多目的データモデルにすべきです。また、データを蓄積する目的の場合も同様です。特定目的データモデルが適しているもののひとつは、色々な団体が公開する実績情報の様にある時点のスナップショットや統計情報です。これらの情報は基本的に更新しませんから、利用者の視認性が高い特定目的のデータモデルの方が適していると思われます。

 ただ、色々な方にお話を聞くと、多目的データセットの実装はハードルが高いと感じている方が多いようです。これは、一般に見る帳票は殆どが特定目的データモデルに該当するものですし、前出の推奨データセットの様に公開されているデータモデルの多くは特定目的データモデルのものである事が多いこと。それに対し、多目的データモデルがあまり知られていない事が要因だと思われます。また、GIFがの規定が特定目的データセットの考え方であるとの誤解が拡がっていること。および、リンクの利用は難しいと感じている方が多いことも要因のひとつだと思われます。

 実際は、多目的データセットで必須となるリンクはデータベースの世界ではリレーションと呼んでいて、データベースのエンジニアにとっては入門レベルの知識です。このため、データベースのエンジニアにとって多目的データセットは簡単な話なのですが、例えば自治体職員が調達仕様として記載する場合などには結構難しいと理解されていると思われます。

 そこで、多目的データモデルをまとめて特定目的データモデルを作成する手法が良く採用されます。この手法はデータベースでは「Viewを作る」などと言い、一般的によく使われる手法です。特定目的データモデルはリンクを含まない事が多いため、一般の利用者にとってもなじみやすいデータモデルになります。

 本協議会で策定したデータモデルの内、「統計(FacilityStatistics)」は特定目的のデータモデルであり、それ以外は多目的のデータモデルです。但し、「統計」の場合も施設名などは直接登録せず、「施設(Facility)」へのリンクで表現しています。そうすることで、施設に含まれる多くの項目の情報も参照できますし、施設から更にリンクを辿ることで、建物・土地・自治体などの多様な情報も得る事ができる様にしてあります。