» 【第82号】高品質データモデリングの要諦

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

DRI通信82号「高品質データモデリングの要諦」   2003.7.1
厳しい第1四半期が終わりました。SARSも終盤のようです。梅雨は奄美大島までが明けたとか、風邪などにも注意してがんばりましょう。
弊社では恒例の夏のセミナーとして、今年はデータインフラ−?メタデータ、?コードデータ、?オペレーショナルDW−を取り上げました。?はリアルタイムDWとも言われますが、このところ非常に注目されてきています。システム間でやり取りされるハイレベルメッセージをストアし、オペレーショナル業務の意思決定のスピードと品質向上を狙うもの、ERPパッケージの狙いをより容易かつスマートに実現する可能性を持っていると期待されます。
■ データモデリング復活のきざし
情報産業はファッション産業でしょうか、90年代C/S、ERPなどに押されて影の薄かったデータモデリングが、こところ復活してきたように見えます。「既存システムのDB構造を見れば大体のデータ構造は分かる」、「小ぶりのC/Sシステムならデータモデリングと言うほどのものは必要ない」、「One Fact in One Placeなどと言っていると調整に時間がかかって間に合わない」、などの理由からしばらく敬遠されていたわけですが、SCM、CRM、連結会計など、出来上がった孤島システムを繋ぐニーズが顕在化して、「システム間インターフェースはデータから成る、その意味を合わせるデータモデリングと、その形式を合わせるコード統一が不可欠」となってきたのではないでしょうか。


また「DOAは古い、これからはOO」と言ってきた人たちも、「ソフトウエアは業務モデルに立脚すべき、業務要件は画面・帳票に現れる、画面・帳票はデータから成る、また所詮RDBを使うことになる、だから最上流ではデータモデリングは必須」として、いかにこれをOOの実装に結びつけるかを検討し始めたこともあるように見えます。
そこでデータモデル図やUMLのクラス図が描かれるわけですが、どうも皆でこれを共有し、品質を上げるには不便な書き方が多く見られるように思われます。情報システムは、建築などと同種の、一種の製造業の成果物であり、データモデル図は建築の平面図と同様、成果物イメージやこれに基づく活動イメージの湧くものでなければならないはずです。そこで僭越ながらTHモデルで採用している、使い込まれて実証されてきた、高品質のための最も基本的な2つのノウハウを紹介しましょう。
■ 配置で意味(セマンティックス)を表す
Entityの意味は、まずはその名前で表現するわけですが、他のEntityとの関係がこれを補います。一番大きいのは粒度の関係でしょう。リソース系(マスター類)ですと、[法人]→[部署]→[社員]や[品種]→[品番]など、またイベント系ですと、[受注]→[受注明細]のように、粒度の大きいものを上に、小さいものを下に配置します。Cardinalityと称して、1、0、nなどを書くやり方も取られていますが、図示して得られるメリットの大部分は粒度の把握とサブタイプの発見ではないでしょうか(更新時の制約などは、図から規定するよりデータ定義から規定した方が良い)。それならば配置で読み取る方がはるかに効果的です。
リソース系とイベント系をごちゃ混ぜに書く書き方も良く見ますが、これは孤島システム指向で、後に大きな禍根を残します。「イベントは新聞記事に相当し、リソースは用語の定義だから広辞苑に相当する」と私は説明していますが、リソース系DBは1社に1個が理想です。できればグループ会社で1個にしたいところです。したがって各業務アプリとは独立に記述すべきと考えます。
リソース系のEntityの意味は、先に述べた粒度に加えて、イベントで使われるときの役割、Who、Whom、Where、What、When、Howなどによって把握されますから、これを意識した配置にします。われわれは左から右へ、社内組織、設備、社外組織、製商品・部品、その他の順に並べています。これによって「社員は一番左の下の方」、「品番は真ん中の少し右の下の方」とどんなアプリケーションでも、そのあるべき場所が決まってしまいます。配置によってEntityの意味が理解できEntityを探すのが簡単、またM&Aなどのときの統合も容易になります。
イベント系のEntityの意味は、粒度のほか業務の順序、たとえば[発注]→[受入]→[受注]→[出荷指図]→[出荷]→[請求]などによって大きく把握されます。したがってこれを左から右へ配置します。実際イベント系のデータモデル図は、ビジネスライフサイクルを表す巻物になりますが、上下と左右のどの辺にあるか、その配置からEntityの意味がつかめるようになります。また抜けがあるとすぐ発見できるという利点があります。
■ 関係線は処理線
Entityは箱で、関係は線で書かれますが、「線は関係」でとどまっているケースがほとんどのように見受けられます。線は処理と
1対N:結合(Join)/要約(Summaryおよび在庫型Summary)
1対1:(抽出(Extract)/マージ(Merge))および結合
などのように対応しますから、これを活用しない手はありません。
一般にイベント系Entityには、5W1Hなどを表す参照KEY(外部キー)があります。たとえば受注Entityですと、
[受注#]−(顧客#、届先#、品#、(@)、数量、<金額>、納期、受注日、・・)
における顧客#、届先#、品#などですが、これはリソースEntityとの結合に使われます。この参照KEYが表現する1対Nの関係を、関係線として明示するケースを良く見ますが、数が多いだけに、この線を明示するのはスパゲッティ図になるだけで、リソースEntityの場所さえ分かるならばメリットはありません。われわれはリソース系を別図にすることもあって、これは一切書きません。書くのはリソース系内、あるいはイベント系内の関係だけですが、後者は加工処理を追跡するものにほぼ一致します。粒度の大きいもの、またイベントでは先行イベントが左に配置されますから、結合は左上から右下へ、要約はこの逆へ行われます。また抽出はサブタイプの方向へ、マージはスーパータイプの方向へと行われます。こうして配置ルールによって効率的に処理を追跡することができます。
われわれはまた、加工処理の追跡の便を考えて、加工データには上述(@)や<金額>のように括弧を付加しています。()は冗長データを、また<>は加工データを表すもので、
 (@)=Join(@、via(品#))
 <金額>=Gen((@)、数量)    
ただしGenはGenerateの意、同じEntity内のいくつかの加工元データから計算
なお計算式は別途個別ロジックとして定義
のような読み方をします。われわれのデータモデル図はTH(椿・穂鷹)図と命名しましたが、その役割からするとER図でなくEP(Entity Processing)図と呼んでも良いものかと思います。データモデル図上で処理を読むことによって、図は静的でなく非常に動的なものとなり、品質が向上します。ERという命名が処理まで読まなくなった原因だったとしたら残念なことです。
われわれは、(@)や<金額>のように、データ項目対応に処理を考えますので、Join、Sum、Genなど10個程度のパターンに分類して記述し、データモデル図上で処理過程を追跡することができます。こうして加工データ(チェックデータはこの1種とする)が規定できるので、IOに関する処理は汎用のCRUDロジック(操作性を含む)として解決できます。OOはデータ項目対応でなくIOないし、Entity対応だけで処理を規定しようとするため、Entityごとの処理規定(メソッド名の記述)を必要としているかに見えるのですが違いますでしょうか。
以上THモデルで実施し、効果を挙げているノウハウのうち図の描き方に関する2つ
・ 配置で意味を表す
・ 関係線は処理線
を紹介しましたが、僭越ながら日本のソフト業界のレベルを底上げするためには、このような個人差の出にくい、品質の上げやすい図面言語が、システム関係者の共通言語にならなければならないのではないかと思っています。そのためには大学教育から見直さなければならない、大学の情報関係の教育は、これまでプログラム言語に偏している、システムエンジニアと言うより、システムワーカーを育てようとしているのではないか、と心配しています。
なお日頃より気になっているツールベンダーのアプローチについて以下付記いたします。
■ 参照関係のリポジトリでの扱い
THモデルでは、「参照KEYが1対N関係を発生させている、これは省略不可である−ただしこれは概念モデルでの話しで、IMSやCODASYL型の物理DBで参照KEYがポインターで実装されることを妨げるものではない」としています。したがって矢線は、参照KEYから生成表示されるもの、言わば「参照KEYを実像とするなら、これを図示するための虚像」になります。
「参照KEYが1対N関係を発生する」は複合的KEY−参照KEYにおいても守られなければなりませんから、受注Entityから[品#.届先#]−(標準倉庫)を参照するときは、受注Entityの品#と届先#を連結した参照KEYを定義することになります。ツールによっては矢線そのものをメタメタEntityとして定義するものがあるようですが、参照KEYの定義は必要でしょうから冗長定義になり、メタメタの世界でOne Fact in One Placeの原則を侵しているように見えます。
■ 追伸
PRになりますが、弊社のツールTHモデラーは、上記技法を実現すべく便利に作られています。しかし市販のツールでも上記の配置ルールを採用し処理をトレースするメリットは十分にあると考えますので、ご検討ください。