» 【第33号】データのからみ

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

DRI通信33号 「データのからみ」 1999.6.1
梅雨と株主総会の季節となりました。景気もユーゴの戦争も、またカレー事件
もオームも、そして受注案件もみなペンディングのまま推移して鬱陶しいこの
ごろです。皆様は如何ですか。
いつも時期はずれで、クレームの出ていた七夕会(DRI通信読者同士のFace
to Faceの議論の場)は、このところお休みでしたが、7月5日(月)16時か
らDRIにて開きたいと思います。今回は「リポジトリのメンテナンス」にし
ます。追って詳細をお知らせいたします。
さて今月は、データのからみについて考察します。ビジネスの状態やこれを実
現する仕掛けの状態がDB――DBMS上のデータだけでなくVSAMや
EXCEL上のデータも含めて――に表現されますが、One
fact in one
place でかつ個々のデータが独立ならば、DBのメンテナンスは極めて容易に
なります。意義のあるデータを忘れずに観測し、速やかに反映しさえすれば良
いからです。


しかし現実には、冗長データや相互のからみがあっちこっちにあり、これを担
当SEが、メンテすることになりますが、自分の守備範囲について、大体理解
している程度ですから、いざとなると犯人捜索のための聞き込みのような生産
性の悪いメンテ作業をしなければなりません。個々の業務アプリはその時々の
目的に応じて作られますから、開発時期も開発担当者も使用技術も異なり、そ
のつけがメンテ時に回ってくるわけです。
メンテを合理化するには、まずは冗長データを無くすことですが、これが難し
いときはこれを把握・対応する仕掛けを用意することが必要になります。
次は、データのからみを把握することです。データのからみにはどのような種
類があるのでしょうか。これを言及する論文を知りませんが、私は原則として
次の3種(再定義データを除く)があると独断しています。
(1) KEYと従属データ
(2) KEYとRKEY
(3) 加工データと加工元データ
(1) は最も基本的なエンティティレコードに関わるからみで、
[DRI01]−(椿正明、男、19351229、鎌倉市、…)
とするとき、顧客DRI01が削除されたとき、椿正明以下のデータは意味が
なくなるので、削除されないとDBに不整合が残るというものです。一般には
物理的に連続してストアされているため、メンテは容易で、軽視されているか
もしれませんが、異なったアプリで異なった従属項目を扱うため、別レコード
がストアされているときなど、このからみの把握が問題になります。
(2) はいわゆる参照整合性――RI, Referential
Integrity――の問題で
す。顧客DRI01からの受注が、DRI01が削除されると、意味がなくな
るとすると、これを削除波及として処理しなければなりません。この場合は物
理レコードは別の場所にありますから、ソフト的にからみを記述してトレース
しなければなりません。
(3) はデータモデル論として、不思議に議論されていない問題ですが、私が
加工データ整合性と呼んでいるものます。RIに倣ってDI,
Derived Data
Integrityと呼ぶことができるでしょう。たとえば顧客DRI01に対する売掛
残が100万円あったとして、新たに80万円の売上げが発生したら、売掛残
は180万円になるわけで、この場合は、
加工データ :180万円(売掛残)
加工元データ:80万円(売上金額)、100万円(売掛残)
;DRI01(売上顧客#)
となります(下図参照)。
[顧客#]−(顧客名、…<売掛残>)
DRI01 椿正明 100

[売上#]−(売上顧客#、売上¥、…)
1234 DRI01 80
なお;は加工元データというより加工元参照データである売上顧客#DRI01
を示すものです。これがないと180万円が正しく算出できませんので加工元
データと同様に関連付けます。
もし売上げが50万円に変更されるならば、売掛残も150万円に変更しなけ
れば不整合が残ることになります。従来この加工データ整合性は、ユーザがア
プリケーションの中でサポートしてきました。
従来DBMSは、データのロジカルな入出力を引き受ければ良い、と考えられ
てきたようですが、私は「これでは不備である」、というより「その位置づけ
からすると間違っている」と思います。データサーバーの主役として共用デー
タの管理一切を引き受けるべきであるから、加工データ整合性も本来参照整合
性と同様にDBMSが支援すべきものと考えます。DBMSベンダーの認識は
まだそこまで行っていないため、DBMSの要求するDDLは、加工データに
関する仕様を含みません。仕方なくユーザは自らこれをアプリの中でサポート
せざるを得ないのです。この機能欠如が多くのスパゲッティプログラムを作り
出すのに関わったと、私は考えています。
今顧客DRI01の預信限度額が150万円だとします。180万円では明ら
かに限度額オーバーです。このチェックのための預信X(このXは真偽値をと
るチェックデータと読んでください)は、顧客の属性であり
預信X=[売り掛け残−預信限度額≧0]
が真か偽かを示す加工データとして定義できます。これは一般にプログラムの
作業域に一時的に現われ、物理ファイル上には見えない、したがって概念と
物理とを区別する人にしか認識されないデータです。そのため、このような
チェックは「プログラムで扱う以外にない、だからプログラムレスなどはない」
と頭から決めて掛かっているシステム屋が大部分ではないでしょうか。
以上のようにデータのからみは3種類あるわけですが、その記述と対策はプロ
グラムロジックによって不完全になされているのが実態と言えます。そのため
あるデータの変更が他のデータにどのような影響を持つかは、関係しそうなプ
ログラムをすべて読みこまないと分からないと言った事が起こります。
データとデータのからみの種類は、データ項目の数の2乗に比例すると考えら
れます。N個の要素があるとき、その組み合わせの数はN*(N−1)/2と
なるからです。システムの規模は、競争力を求めてERPだ、SCMだと拡大
の一途をたどります。するとそのデータのからみは2次曲線を描いて複雑化し
ます。そのからみを書いたプログラムを作った人は「もう会社にいない」など
ということも今日決して珍しくありません。「からみはメタデータとしてリポ
ジトリとして書け、プログラムに書くのが混乱の元である」というのが私の主
張です。
このような状態のまま、これからの21世紀やっていけるのでしょうか。われ
われはこの混沌から脱する道は、「ビジネスモデル(ユーザ要件)とソフトウエ
ア(実装)を分離したデ−タモデリング以外にない」と確信して、「これをいか
にすばやく、しかも品質高く行うか」と、その実践と改良に勤めている次第で
す。「うちはERPでやるから良いんだ」、「うちはアウトソースするから必要
ない」はあり得ない。アウトソースするにしても、自社の業務仕様は、自ら把
握・明記した上でアウトソースしなければなりません。よろしくご検討いただ
きたく思います。