» 【133号】データモデリングの課題−その2

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

■DOAの問題―加工データの排除
先の132号において、DOA最大の問題は「個別アプリケーションへの適用
に限られ、孤島システムを乱立させたこと」と述べました。

もうひとつは美しいCODDのデータモデルから排除されたことに起因する、一部
のDOA手法に見られる「加工データ(導出データ)の排除」であると私は考えます。
種々「わるさ」をする冗長データを正規化によって排除するのは良かったので
すが、これと同列に加工データをも「冗長だ」としてDBの中から排除した(注1)
のは、アプリケーションニーズやこれを扱う関係者の対応に関する理解不足か
ら来る、エンジニアリング的大失敗だったのではないかと私は考えます。
(注1)正確には「加工データは当該データモデル論の外にあるから、図に書く
べきでないとし、一見排除すべきとの誤解を与えたこと」と言うべきかもしれま
せん。いずれにしても結果として、加工データに関する正しい扱い方が多くの
方々に理解されず、不適切な種々の対応を生じさせたことは事実かと思われます。
現実世界を写像するDBに不整合があってはならないので、加工データを排除
することによって、加工・加工元データ間の不整合を管理しなくてよくなるの
は良いことといえますが、情報システムとして目をつぶることのできない、た
とえば次のような加工データ(〈〉つき、なお!は意思決定データを表す)を
どう扱えばよいのでしょうか。
(1)[受注#]−(・・、〈受注合計¥〉)
(2)[品#.倉#]−(〈在庫Q〉、・・)
(3)[営業所#.年月]−(売上予定¥!、〈売上実績\〉)
(4)[社員#.年月]―(・・、〈残業H合計〉、〈給与¥〉)
(5)[機器#.部品#]−(・・、材質c、温度、圧力、〈所要板厚〉、採用板厚!)
(6)[熱交換器#]−(タイプc、〈所要伝熱面積〉、採用伝熱面積!、・・)
(7)[配管#]−(流体c、温度、〈蒸気圧〉、〈粘度〉、・・)
これらの加工データと加工元データの関係は、実装手段に関係なく決まる、概
念レベルのユーザ要件/ビジネスルールです。また、ほとんどが物理DB上に
スペースを要求するものと思われます。物理設計段階になって突如登場してく
るものではありません。当初排除したこれらのデータを何時どのように認識し、
物理DB設計するのでしょう。さらに、概念レベルの設計内容とするならば、
そのとき物理スペースを必要とするか否かを先取りして決めてもよいのでしょ
うか。
■関係線/参照KEYとの関係
加工データの処理は一般に
・加工元データを取り揃える
・取り揃えられた加工元データを演算し加工データを得る
の2ステップに分けられますが、前段において、結合(JOIN)、要約(S
UM)、在庫(INVENTORY_SUM)、抽出(EXTRACT)など
が行われます。結合、要約、在庫においては1:nの関係が、また抽出におい
ては1:1の関係が用いられますので、データモデル図における関係線/参照
KEYが活用できます。
データモデル図において1:nの関係線/参照KEYを書く目的は何でしょう
か。リソース系においては、リソースの粒度/分類軸を表すのが重要でしょう。
次の在庫の例は在庫Qの計算順序(ただし在庫なので矢印と逆)と、リソース
に準じて在庫をどのような粒度で扱っているかを表すものといえます。
 [品#]−(〈在庫Q〉)
  ↓
 [品#.倉#]−(〈在庫Q〉)
  ↓
 [品#.倉#.棚#]−(〈在庫Q〉)
イベント系においては、
・関与のリソース(受注イベントにおける受注顧客#、受注品#など)を表す
・粒度(HEADER/DETAILなど)を表す
・先行イベント(受注→引当→出荷など)を表す
・加工・加工元関係(出庫Q、入庫Q、在庫Qの関係など)を表す
などが主なものと言えます。最も数の多い−おそらく90%近いと思われる−
関与のリソースとの関係は、リソースエンティティの配置基準を用意すれば、
参照KEYによってその関係は把握できますので、関係線は省略できます。残
り3つのうち粒度と先行イベントは不可欠ですが、最も注意を要するものは加
工・加工元関係と、私は考えます。
■品質/整合性アップの要
その理由はDBの品質/整合性アップに大きくかかわるからです。システム/
DBの品質不全は、例外事項の抜け洩れや誤処理に起因するものがほとんどか
と思われますが、加工・加工元データの関係の追跡によって、例外事項/サブ
タイプが発見され、これが品質向上につながったケースが多かったからです。
実際データモデリング/DB設計における難物はサブタイプです。たとえば社
員が1000人いれば、各人異なった属性を持ちますので、厳密にはサブタイ
プは1000個存在し得ます。重要でない属性を除外し、ヌルデータを許容し
て、経済最適な個数にまで絞り込んで公認のデータモデルとすることになりま
す。イベントにおいても、社員ほどではないまでも、かなりのサブタイプが存
在します。そしてこのとき、加工データ処理の違いが、サブタイプ識別の重要
なファクターになることが多々あります。データモデル図において、サブタイ
プ対応の加工データを明示しトレースすることによって、格段の品質向上が期
待できるからです。
この品質向上のための加工データ導出過程をトレースする便宜として、THモ
デルでは、1:n関係にあるエンティティタイプは、1側を上に、n側を下に
配置するものとしました。これによって、SPF(Schema Process Flow)チ
ャート記法をベースに、結合処理は下に、要約・在庫処理は上に行われます。
なお抽出は横に行われることになります。すなわちデータの意味を構成する粒
度やエンティティタイプの詳細(サブタイプやサブストラクチャ)がレイアウ
トとして表現されるため、人間の意味把握がパターンとして行われ、効率と品
質の向上を支援することになります。
■データモデリングの目的
データモデリングの二大目的は、
A)RDB設計の前段
B)ユーザ情報要求定義
かと思われますが、今はAからBにシフトする過程にあるかに見えます。
Aにおいては、RDBの空間とプログラムの空間は別立てで、この間をSQL
が繋ぐというアーキテクチャ−これがOOによる実装工程でインピーダンスミ
スマッチを招来する−であり、加工データ処理はプログラム空間の話題として
データモデリングから除外されてきたものかと思われます。逆に後段のRDB
実装設計との境界は曖昧になりやすく、実装独立の段階から、実装時スペース
を用意すべきかどうかが考慮したりする傾向がみられるのかと思われます。
一方Bにおいては、RDBやプログラムといった実装手段とは独立に、ユーザ
の認識する情報空間の全データおよびその相互関係が識別され、可視化されま
す。整合性は不可欠の条件となりますので、データの意味の把握、加工・加工
元データの関係の把握などは必須となります。同じ処理結果(データ)を得る
ための処理はn個ある、すなわちデータ:処理=1:nであり、処理結果は必
ずデータとして把握できますので、処理仕様や物理DBでのスペースの要否を
考えることなく、まずユーザの認識するデータを1個の空間で整理する進め方
になります。
たとえば物理スペースを用意しないであろう在庫チェックというデータを
 在庫チェック=0;在庫Q/安全在庫Q>2
       =1;1<在庫Q/安全在庫Q≦2→警戒メッセージ
       =2;在庫Q/安全在庫Q≦1→自動発注
のように定義すれば、通常、処理手順として書いていたロジックをメタデータ
として明快に定義でき、さらに自動化(注2)を実現することもできます。
(注2)画面/帳票のレイアウトなどの物理的性質に対応するロジックは、標
準パターンを選択することでプログラミングレスを狙うことになります。標準
パターンで対応しきれない特殊レイアウトなどについては、スーパープログラ
マに依頼することになると思われますが、それは5%以下になると考えます。
データモデル手法の特徴を見ると、欧米/欧米系のDOAは、Aの特徴を色濃
く持っているように思われます。THモデルは、業務を正確に表現してから実
装を考えるべきとの方針から、当初よりB指向で進化してきました。UMLは
AというよりB指向かと思われますが、情報要求をメタデータとしてリポジト
リに記述するという指向は、はっきりいたしません。
■人とデータの品質が課題
システム化の進展とともに、業務の品質はシステムの品質に依存し、システム
の品質はデータの品質に、さらにデータの品質はこれを造る人の品質に依存す
ることになります。すなわち品質は
 人→データ→システム→業務
の順に決まってくるようです。システムが大規模化するにしたがって、品質の
重要性が高まりますので、人とデータの品質を如何に上げるかが、今後の課題
としてますます注目されるのではないでしょうか。データモデリングにおける
加工データ分析は、その意味で極めて重要な作業と認識されてくるものと思わ
れます。