[ご参考] 多目的なデータモデルの策定手順
多目的なデータモデルの策定手順として確立したものは無い様に思います。そこで、本協議会では、目的別データモデルから多目的データモデルを策定する方法を採用しています。
これを図にすると、右の様になります。目的別データモデルとしては、データモデルその物でなくても意味のある項目が分かればいいので、例えば実際の業務で使われている帳票・Excel等の表計算ソフト・アプリや他システムとのインタフェース仕様などを使います。
最初のユースケースである施設管理では、初めに今まで業務で使っていた各種帳票を収集し、それらを整理する事で、多目的のデータモデルを策定しています。従って、多目的データモデルは各種帳票の最小公倍数的なデータモデルになります。
図の中で、「記入ルールの融合」と言う記述がありますが、特に「用語」定義の融合が重要となります。用語とは、帳票の項目に登録する値のことで、例えば「バス」や「乗合自動車」いう用語は「バス」に統一する事にしよう、と決めることになります。この際に帳票間で共通化するだけでなく、法人間でも共通化する事が重要です。共通化した用語の事を技術用語ではEnum1と言います。Enumとは、英語のEnumerationから派生した技術用語で各種コンピュータ言語で用いられています。
多目的データモデルに基づいてデータを蓄積すると、そのデータには各種帳票の情報が包含されますので、右図の様に各種帳票の記入を自動化する事が可能です。
項目に登録する「用語」が共通化されていますので、当然ながら各種帳票に記入される用語の共通化されます。つまり、データ仕様を共通化するということは、人間が使う帳票の用語の共通化されるという事になります。
目的別データモデルの策定
ここまでは、多目的データモデルを中心に記述してきましたが、実際の業務ではcsvやExcelの電子データの提供を求められる事が良くあります。多目的データモデルのままで提供する事もできますが、ここでは電子データの要求に従い目的別データモデルで提供する事を考えます。目的別データモデルは多目的データモデルから策定する事が可能です。この様に、目的別データモデルと元となって多目的データモデルは相互に変換が可能です。具体的な事例はケーススタディで紹介しますが、ここでは考え方について記述します。
① リンクの解消
共通データ仕様は基本的に多目的データモデルなので、リンクを含んでいます。Excel等表計算ソフトではのリンクを辿って値を参照する機能を備えている事が多いですが、ここではリンクを解消して電子データを提供する事を考えます。
目的別データモデルは、リンク先の項目(Attribute)をリンク元の項目として取り込むことでリンクを解消しする事ができます。例えば右図の様に、土地(Land)と建物(Building)とはリンクで結ばれていますが、そのリンクを使って土地の項目(Attribute)を建物に取り込んでリンクの無いデータモデルを策定します。
この様なリンクの解消は、報告(Report)と案件(Complaint)、施設(Facilityと建物(Building)、部門(Department)と組織(Organization)の間にも成り立ちます。
リンクの解消では、複数のリンクを解消したり、リンクを何度も辿って解消する事も可能です。そのため、かなり自由に項目を取り込んで目的別データモデルを策定する事が可能です。この様にして、電子てたの要求に従った目的別データモデルを策定します。
② システムとの整合
目的別データモデルを策定できたからと言って、どのコンピューターシステムでも目的別データモデルルに合致する電子データを出力できるとは限りません。電子データを出力できるかどうかは以下の二点に依存します。
- システムの機能
システムの内部データベースは一般的には多目的データモデルと同様な考え方で作成されています。従って、システムがデータベースから複数の情報を組み合わせて出力する機能をどこまで実装しているかを確認する必要があります。また、データベースを直接アクセスする事が可能なタイプのシステムの場合は、リンクを辿る機能(製品により、ルックアップやジョインなどの呼び方があります)を使って目的別データモデルに従った電子データを作成します - システムへのデータ登録ルール
共通データ仕様では、建物、報告、案件などの情報は一つずつ登録する事を前提としています。これは、後でデータ分析する際などには情報が一件一葉でないと分析が困難なためです。一方、システムによっては自由度が高いものがあり、例えばひとつの案件情報に複数の不具合を一括して登録可能なものもあります。例えばある建物で、複数の部屋の照明機器がそれぞれ壊れた際に、壊れた照明の情報をここに登録せず、「図書室、校長室など3ヶ所」などと登録してしまうと、後で分析が困難になってしまいます。そこで、個々に登録するなどのルールを定めておく必要があります
目的別データモデルの電子データから多目的データモデルへの変換
前項とは逆に、システムが出力するCSVなどの電子データから多目的データモデルの電子データへの変換について記載します。一般的にCSV等の目的別の電子データはシステムやお客様の都合により決められてしまい、必ずしも目的別データモデルに変換しやすいとは言えません。
以下、特定目的データモデルに基づく電子データを多目的データモデルに変換する際に障害となる主な項目について紹介します。
- 定義が曖昧な項目
例えば自治体標準オープンデータセットのAED設置場所一覧の「名称」という項目では「建物”等”の名称」を登録する事になっています。これは、AEDの一覧という趣旨では決して曖昧ではなく「最もAEDがどこにあるのか分かりやすい名称を適切に選択して登録する」という事なのだと思います。一方、AED一覧である事から離れて一般的な場所の名称という観点ではとても曖昧です。形式変換する事を考えると、「○○ショッピングセンター」等という施設全体を示す名称なのか、その中の特定の建築物を指す「○○棟」なのか、更にそこに入居しているテナントを特定する「○○ショップ」なのかの区別がついた方が良いでしょう。一般的にはモノやコト毎に項目を分けておく方が処理しやすいです。 - 複数の意味がある項目
同様に、どの様な属性を表すのかが分からない項目も見受けられます。例えば公園の管理業務で使うデータモデルに「設備」という項目があったとします。あるデータではその項目には「鉄棒」と記入され別のデータでは「○○花壇」となっている様な例は良く見受けられます。この項目は設備の名称の情報と設備の種類の情報が混在しています。 - 一意に識別する項目が無いデータ
CSVでは何行目のデータなのかでデータを区別する事が出来ますが、この情報はデータを生成するたびに変化してしまいます。変換のためには変化しない項目が要です。例えば、法人ならば法人番号、個人であれば(法的に許されるのであれば)マイナンバーなどがあると良いでしょう。適当な項目が見つからない場合は、関係者で相談して管理上の番号(キーや識別子などと言います)を付与すると良いでしょう。
このような項目がある場合は多目的データモデルに変換する前にデータを前処理して変換できる様に項目を書き換えます。この前処理は手作業で行う必要がある事が多く、データ収集で最もコストがかかる手順です。逆に言うと、この様な手作業が発生しない様にCSV等の目的別データモデルを策定しておけばほとんど機械的に多目的データモデルに基づく電子データに変換する事が可能です。詳しくはケーススタディ#1で紹介します。
- 「イーナム」と読みますが、元の英単語の発音から「エナム」と読むこともあります ↩︎