» 【第90号】データモデルの進化

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【第90号】データモデルの進化

DRI通信90号「データモデルの進化」  2004.3.1
氷の張るのを見ないまま、22日には21度になって、あっけなく冬が通り過ぎ、冬大好きのスキーファンにとっては、ちょっとさびしい気がします。花粉を防ぐためのマスクが目立ち始めましたが、皆様お元気ですか。
昨年暮れから始めたDOA+コンソーシアムには、皆様の関心が予想以上に高く、分科会も会場探しに苦労するほどの参加をいただき、今後どう運用しようかが、幹事会の課題となっている状況です。このエネルギーを日本の情報システムのレベルアップにどう活かすか、皆様とともに考えて行きたいと思っています。
■ データモデル
データモデルとは、データ構造、データ仕様を把握する枠組み・型・パターンと言う意味で用いられていますが、2つの使われ方があります。ひとつは「A社の販売システムのデータモデル」、「B社の生産管理システムのデータモデル」といったデータモデル個体に、もうひとつは「ERモデル」、「THモデル」といったデータモデルの種別を表すものに、です。学者は後者をDMF(Data Modeling Facility)と呼ぼうと提案しましたが使われていないようです。ここでは後者についてその進化を検討します。やや独断が混じりますが、ことの性質上客観は難しいので、ひとつの見方としてご容赦いただきたいと思います。
■ DMMM
前々回から進化を成熟度モデルとして扱ってきましたので、今回のはDMMM(Data Model Maturity Model)ということになります。次の5段階に分けて考えました。
(1)構造型DBMSモデル
(2) リレーショナルモデル
(3)ERモデル
(4) THモデル
(5) THeモデル


(1)と(2)はDB設計のためのモデル、(3)と(4)は業務要件定義のためのモデル、(5)は開発保守の自動化やEA(Enterprise Architecture)、BPM(Business Process Management)をねらったさらに高度なモデルとなります。
■ 構造型DBMSモデル
1960年代からのTOTAL、IMS、CODASYL型DBMS(IDMS、ADBS、AIM−NDB、DMS1100)などを設計するときに用いられたデータモデルです。それぞれ個性的なのでひとつではありませんが、代表はBachman図を用いるデータモデルでしょう。プログラマはデータ構造を表すポインターを操作しなければなりませんので、データ独立性がない(データ構造が変わるときプログラムを変更しなければならない)HOWのインターフェースだ、として批判されました。
■ リレーショナルモデル
1970年に登場した有名なCoddのモデルです。正規化されたテーブルでDBを構成し、プログラマは属性を指定するWHATのインターフェース−SQL−でアクセスできるため、データ独立性が保障されるとして評価され、1980年以降のORACLEやDB2などの開発につながりました。
しかしデータモデルとしては、エンティティタイプとテーブルがうまく対応付けられる単純な事例はよかったのですが、意味が問題となる情報を、リレーショナルモデルがベースとする数学「関係代数」が処理できる、という保証があるわけでもなく、ヌルデータの対処に苦慮することになりました。
また大規模システムのモデルを理解・共有するために、一般には図表現を活用するわけですが、Coddはこれを拒否したため、結局次のERモデルがこれを補うことになりました。また冗長データの排除の行き過ぎか、加工データを排除したため、在庫データ、要約データ、エンジニアリングデータなどへの適用に支障が発生しました。リレーショナルモデルはやはりDBMS実装のためのモデルとするのが無理がないようでした。
■ ERモデル
ERモデルは1975年の第1回VLDB(Very Large Data Base)に、MITの若手(20代)教授だったChenが発表した意味論モデルです。「IMSやCODASYLなどのトリーやネットワークの構造型モデル、またリレーショナルの表型モデルが提案されているが、いずれも実装レベルのモデルであって、これらが表そうとする実世界の意味は、ERモデルによって統一的に扱える」という主張でした。この論文についてはCoddの強硬な異議が出され事務局は紛糾し大変だったということでした。
しかしERモデル図の箱や菱型がリレーショナルDBの表に対応させられるため、図表現を持たないリレーショナルDBの設計に活用され、リレーショナルDBの普及に大いに役立ったこと、また本来実装独立の意味論モデルだったERモデルが(堕落して)リレーショナルDB実装のモデルとして使われてしまったのは、歴史の成り行きとは言え、皮肉でした。
(注)ERモデルはChenの発案によるものですが、その後ERモデル国際学会などが継続的に開かれ、システム開発方法論のベースとしていろいろな展開がありました。J. MartinのよるIE手法や米国防省によるIDEF1Xなどはその代表です。ここではそのうちのどれかまでは意識しないで書いていますので、あるいは該当しないコメントになる場合があるかもしれません。
■ THモデル
TH(椿・穂鷹)モデルは同じ1975年の第1回VLDBに私が発表したものです。THモデルをベースにしたエンジニアリングDBMS「DPLS」の設計思想を主題としたため、データモデルについては比較的簡単に発表することになりました。ERモデルは、EntityとRelationshipの2元論ですが、THモデルは、Relationshipは参照KEY(RDBの外部キー)で表現するのでEntityのみの1元論です。
(注)当初のERモデルではリレーションシップを表す菱形が用いられましたが、今はすべて箱で書きますので、Entity1元論になっているともいえます。THモデルはERモデルとは独立にスタートし、その後も影響を受けていませんが、ERモデルを「意味論モデル」という普通名詞として使用する(ヨーロッパにはNIAMの流れを汲むモデルなど種々ありやや無理かとも思われるが日本に限定して)ならば、THモデルもそのうちの(自称最も進化した)ひとつとすることができます。
エンジニアリング会社のトータルシステム設計方法論を指向し、情報代数の「Entity, Attribute, Value」を公理として、データモデリングを行いながら完成をめざしていきました。設計、工事、販売など複数の業務アプリが対象になりますので、リソース系(マスター類)は独立に用意することを前程といたしました。
またこれら一般の業務アプリとならんで、情報システム開発業務をもデータモデリングの対象として扱いましたので、メタデータのモデリングを行い、DD/D(今で言うリポジトリ)が内蔵されるもの(自己記述型)となりました。この過程でエンティティは、リソース、イベント、在庫型、要約、断面に分類できること、またデータ項目にはKEY、参照KEY、各種加工データが含まれること、などが判明して行きました。
1982年ころ、DB中のデータ(部品)から加工データ(中間部品)を導出し、さらにこれらから画面・帳票(製品)を作る処理過程を、実装独立に記述するSPFチャート記法を思いつきました。これによって処理とその結果としてのデータの関係が
 レベル1の処理:加工元データ→加工データ
 レベル2の処理:データ→画面・帳票
のようにレベル分けして記述できることが分かりました。
SPFチャートでは、結合(Join)、要約(Summary)、抽出(Extract)、不定形加工(Generate)などの操作が定義されていますが、チャートを書かずDB構造図上でこれをトレースすることができます。エンティティの粒度や発生順序を考慮したレイアウト標準、およびこのDB構造図上でのSPF操作のトレースによって、DB構造図の品質を効率的に上げることができます。
■ THeモデル
TH拡張(extended)モデルという意味でTHeと表現しました。まずは、プログラミングレスを狙います。情報要求を完璧に記述するだけでなく、ソフト環境やハード環境に合わせて操作性や機械効率を満足させるための、実装従属メタ情報を如何に規定/標準化するかが課題となります。
またグローバルリアルタイム経営を支援すべく、企業全体から企業横断の、遅れの少ないデータ流通を実現する、EAやBPMのためのデータモデルやメタモデルが要求されています。これは恐らくTHモデルの拡張によって実現できるのではないか、と考えていますが、いま立ち上げているDOA+コンソーシアムの中で進展できるかもしれません。そうなれば名前はDOA+モデルと改名できるかもしれません。
■データモデルの進化
以上データモデルの進化について、私見を述べました。データモデルといっても、その対象をメタデータに拡張すると、プロセスが対象になり、さらに企業横断の実装独立および実装従属のシステムが対象になってくる必然性があるように思われました。