» 【第86号】データモデルの設計思想

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

DRI通信86号「データモデルの設計思想」     2003.11.4
11月を迎え、平地でも木々の葉が色づき始めました。朝早く自転車で北鎌倉駅
まで、ライトをつけ手袋をはめ、さらに冷気で涙が出るのを防ぐためゴーグルを
つけて下る時期となりました。
10月30日(木)第14回K2W勉強会は、35名の参加のもと、「経営に役
立つ情報システム企画を立てるには」というテーマで行いました。サヴィオンテ
クノロジーの宇野澤社長からはBPM、ヘッドストロング瀬賀取締役からは
EAIについてのプレゼンをいただき、活発な議論が展開されました。次回は1
月27日(火)やはりBPMやEA関係のテーマで行いたいと考えています。
■ モデル化の目的と適用範囲
データモデルに限らず、モデルがないとすると、本や新聞のように、対象を自然言語主体で記述しなければなりません。自由度がありすぎて、属人的になり、抜けや矛盾の摘出が難しくなります。モデル化は、対象の持つ構造を捉えて、この自由度を必要十分かつ最低限に抑え、できればパラメータを指定するだけで、記述を完成させようとするものです。したがって、ある対象に対して、自由度のある、いろいろな記述のできるモデルは一般的に自然言語よりの未完成なモデルと考えられます。
化学プラントやデータモデルなど構造を問題とする対象は、一般に要素とその関係から構成されるので、箱と線を主体とした図と表で記述することになります。コンピュータは、図が解釈できないので、コンピュータ処理のためには、これを表−リレーショナルテーブルなど−に変換します。3次元物体は、目に見えるので、これに制約され、図の描き方にバリエーションが出にくいのですが、情報がらみの対象は、目に見えないため、多様な表現が考えられ、その標準化が難しくなります。


モデルの適用範囲を限定すると、モデルはシンプルになりますが、あとでこの適用範囲を拡大しようとするとき、精度が不十分で、大幅な改造が必要になりがちなので、要注意です。
■ THモデル考案の前提
1962年にCODASYL(COBOL言語の標準化団体)がまとめた情報代数なる文献に、Entity、Attribute、Valueと言う概念が紹介されました。私は1965年にこれを読み、データモデリングをスタートしました。エンジニアリング会社の設計から調達、工事にいたるデータをどう整理すべきか、という課題を抱えており、これに適用しながら考えて行きました。1975年にはボストンの国際学会−ERモデルも同時に発表された−で発表しました。大枠は今と変わりませんが、その後の改良を含め、次のような前提だったと思います。
? 実装独立。プログラミング言語やDBMS(当初はまだアクセスメソッド)に独立−さらに言えば、江戸時代の和紙に筆で書く実装でも良い−、したがって機械効率や操作性(当初はまだGUIはなかったが)は、後で別途対応。要するにシステムユーザでなくビジネスユーザのニーズを概念DBとして表現する。
? 適用範囲を限定しない。複雑なエンジニアリング会社のバリューチェーン全体を表現したいと考えていましたので、結果として範囲の限定はできませんでした。
? レガシー、パッケージ、自作、さらに人手の共存。?、?を前提にした青写真つくりですから自然にこうなります。
? 大規模DBの品質保証。テストデータによるテストは原始的過ぎる。この前に鳥瞰図によりデータの意味と整合性をレビューできないか。属人的では品質が上がらないので、レイアウト標準が必要のはず。
? エンティティや属性を分類。エンティティはリソース、イベント、在庫、要約などその性質による分類が可能、また属性もKEY、参照KEY、各種加工データなどの分類が可能。分類対応に共通の振舞いがあるから、その処理を共通化することにより、冗長性を減らすことができるはず。
? データモデルは決め事ではない。データモデルは、業務のデータを観察し、分析整理して導かれるものである。発明できるものでなく、発見すべきものである。この点プログラム言語や「ベータかVHSか」と言った人間による設計の問題と異なる。むしろ「物質は、水素、酸素、炭素などからなる、元素は陽子、中性子、電子からなる」といった物性論に近い。
? 自己記述。メタデータはシステム関係者の扱うデータであるが、これもシステム開発という一種のアプリケーションのデータ。このデータモデル図は、そのデータモデルの品質向上および証明のために必須。
? 人とコンピュータは情報を共有すべし。人が図により読み取る情報は、表(リポジトリのテーブル)に変換し、コンピュータもこれを活用できなければならないはず。
なお、モデリングにあたり、これを客観的に扱うために、記号化はすでに完了しているものとします。この点、記号化以前から扱うオブジェクト指向(OO)とは、若干異なります。
■ 他のモデルとの違い
他のモデルといっても、すべてを調査することはできませんので、多くのユーザの使っているIDEFやこれに基づくツールによるモデルとの比較になるかと思います。
実装独立?は同じはずですが、エンティティがいつの間にか実装従属のRDBのテーブルになってしまう使い方が、多々見られます。これではIMSやADBSなどで構築されたレガシーシステムのAS−ISが同じ形式で表現できません。当該システムのTO−BEが主目的だったためかと思われます。
リソースエンティティ(コードマスター)がアプリケーションごとにつくられている孤島システムが多々見られます。個別アプリケーション対応の適用ニーズが多かったから、これに対応したともいえますが、後に課題を残しました。モデルの前提として、適用範囲の限定?に言及しなかった問題が指摘できるのではないでしょうか。
一般に当該新規システムのDB設計が目的であり、レガシーやパッケージとの関係?は念頭になかったようです。
もし種々のプラットフォームに実現された、n個のアプリケーションを対象にしたデータモデリングが念頭にあったなら、ユーザごとの違った見方を調整するための、代替KEYや、THモデルでのサブストラクチャ表現、また多くのエンティティを系統的に把握するためのレイアウトルールなどが用意されていたのではないかと思われます。
データモデル図の品質保証?については、参照KEYと矢線の照合をとるだけで、その他はテストデータによるテストにゆだねるという考え方かと思われます。レイアウトは属人的で、エンティティが500を越える大規模システムにおいて、効率的な品質アップの方策が見当たりませんが、どう対処するのでしょうか。
イベントエンティティは新聞記事に、またリソースエンティティはこの中で使われる用語辞書、いわば広辞苑に相当しますが、この区別、さらに在庫エンティティや要約エンティティなどの分類?が認識されていません。データ項目もKEY、参照KEYは識別されているものの、各種加工データ?を意識し、これをデータモデル図上でトレースする考え方がありません。恐らくこれらをデータモデルの範疇外の問題としたのだろうと推察します。従来型のプログラム仕様書を作って対処する前提だったように見えます。
また加工データについては、これを分類する以前に、加工データは冗長データだからデータモデルから排除すべきだという考え方もあるようです。DWHで扱う月次サマリデータを扱った例が少ないのはそのためかと思われますが、予実対比が表しにくい。また給与や在庫データなどはどう扱うのでしょうか。さらにエンジニアリングDBは加工データの塊のようなものですが、どう扱うのでしょうか。
私は、10個出荷したら在庫が10個減るのであるから、この整合性−加工データ整合性−は本来DBMSが保障すべきこと、これをアプリケーションプログラムに依存するのはおかしい−インテリジェンス欠如−と考えていますが、これも加工データをデータモデルから排除したためと考えます。正規化の誤った解釈が原因かと思います。RDBの12のルールにこれを入れそこなったところに、Dr. Coddの限界があったのではないでしょうか。
「IDEFはスタンダードだ、全員これに従うべきだ」と言う考え方があります。単なる物理的表記ルールなど、人間の決め事?ならばそのとおりかと思われますが、事柄はどうもそうではないと思われます。ローマ法王が中心になって、多数決で天動説を決めたけれど、撤回しなければならなくなりました。共用のための標準化は大切ですが、一方「決まるもの」を「標準化と称して決めるのは人間の傲慢」となる恐れもあります。両刃の剣となるものです。IDEFモデルも適用範囲を狭く取れば問題がないように見え、「これが標準だ」とされたのかもしれません。孤島システムに終わらない、業務データをより完全に表現できるモデルに置き換えていくべき時期に来ているのではないでしょうか。
データモデリングツールベンダーの中に、そのツールのメタモデル?を提供していないベンダーがあります。紺屋の白袴なのでしょうか。ユーザにはデータモデルの有効性を宣伝し、しかし自らはこれを否定していることになります。それとも自分自身は表現できない不完全なモデルであることを認めているのでしょうか。このようなツールは、往々にしてメタデータ定義に、いろいろな冗長定義や矛盾を含んでいることがあるので要注意です。
エンティティや属性、そしてその関係を図示することによって、人間は−勿論一定の教育・訓練は必要ですが−データモデルを感覚的に理解でき、正確かつ効率的なコミュニケーションができます。しかしこれをコンピュータに理解させるためには、表形式に変換(テキスト/プログラム形式までの変換はここでは考えないものとします)しなければなりません。図を表に変換する方法?は、ユニークではありません。属人性の避けられないところですが、できるだけ本質をついた変換方法が保守などの観点から望まれます。一般には属性が情報をあらわしますから、どの属性がその情報を最も良く表現するかを考えることになります。
■ UMLについて
今UMLが話題となっています。ツール先行で、これをどのような目的、適用範囲、手順で用いるべきかは、後追いで決めるということです。ツールベンダー好みのシナリオでスタートしました。「10種類の図の描き方を標準化したから、これをうまく組合せて、システム開発の合理化をしましょう」ということかと思います。10種類を何時どう使うか、意見もまとまっていませんし、データモデルにレイアウトの標準を用意したとの話も聞きません。まだかなり発展途上にあるもののように見えます。