» 【152号】 現行DBMSの欠陥

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

■現行DBMSの欠陥
現行DBMSとは、ほとんどRDBMSかと思われます。RDBMSは構造型D
BMSのポインター操作からプログラマーを開放し、オプティマイザーを始め多
くの改良を施し、E. F. Coddの提案する12のルールを消化して、多くの情報シ
ステムの不可欠の基盤となっています。しかし一方、いま多くの情報システム部
門の抱えている問題のうち、現行RDBMSに起因すると考えられるものも少な
くないので、これについて私見を述べたいと思います。

DB設計において、まず問題になるのは「正規化」かと思われます。正規化によっ
て、「One Fact in One Place」の実現をねらうわけですが、これはDBが実務
の世界の写像であることを要件とするためだと解釈されます。実務の世界の情報
には矛盾・不整合はありませんから、「正規化によって実世界を正しく反映した
DBをつくり、これによってビジネスを支援しよう」というものだと思われます。

しかし多くの企業において、冗長データを含むSILOシステムが作られ、今M
DM(Master Data Management)問題が、騒がれています。また多くのプロジェ
クトにおいて、不整合の残る要件定義のため、実装設計段階から、逆に要件定義
段階への手戻りが発生して混乱を招いています。これを「ユーザ側のDBMSの
使い方によるのだ」とする見方もあるようですが、これは「正しい設計思想のD
BMSによって防げる課題だ」と私は考えます。

また、最近のDBMSベンダーの改良によって実現の方法が用意されつつあるよ
うですが、追加機能でもあり、まだ多くのシステム設計担当者が、これを活用す
べく設計方法論を改変するには至っていないようです。

■4つの不備
DBMSの不備は、主として次の4つにまとめられるかと思います。
 ①マルチDB構成への配慮不足
 ②実装独立への配慮不足
 ③DI(Derivation Integrity、加工データ整合性)の抜け
 ④値の正当性チェック機能の不備

①は、購買・生産・物流・販売・経理・人事などを含む全社システムとDBが
どのように対応すべきかの問題が十分配慮されていなかった、ということです。
当初は、これらを1個のDBとして実装するつもりだったのかもしれませんが、
実際にできたのは個別DBからなるSILOシステムでした。多くの場合、社内
外組織、原材料・製商品などに関する共用資源データが冗長にストアされること
になりました。「アプリごとにDBを作ってもよいが、共用資源データは一元化
すべし」のガイドがなかったのが致命的でした。またE. F. Coddは、DBのスキー
マをCatalogと呼んで、これが一種のDB(メタDB=リポジトリ)だとまでは
考えていなかったかに見えます。当時はまだ、複数個のDBをどう関連付けるか
という、DBアーキテクチャの課題が解決できていなかったように思います。

②は、ストレージのデータ独立性の重要性を主張しながらも、実装独立と実装
従属の分離関連付けまでは、配慮しなかったことです。このためユーザから見え
るのは実装屋の意識する論理テーブルであり、これは厳密にはビジネスユーザの
認識するエンティティタイプではありません。エンティティタイプにはサブタイ
プやサブストラクチャ(注1)などが含まれ、論理テーブルとの対応に無理があ
ります。後から登場した仮想テーブルはこれをカバーするためのものと思われま
すが、設計はビジネスニーズから行いますので、まず仮想テーブルを設計し、こ
れを実テーブルに変換するのが、正しい順序ではないかと思われます。

(注1)エンティティタイプを分類するTHデータモデルの用語です。工事エン
ティティでは、工事見積金額や実行予算金額は当初はNULLで、後から入力さ
れるのが一般的です。このように時間の推移とともに値が定義されていくような
エンティティタイプをTHデータモデルでは、サブストラクチャと呼んでいます。
このほか属性の性質によって分類する場合も、サブストラクチャとします。

また実装を前提とするため、一般にストアされない加工データ(注2)はデータ
モデリングの対象から外されました。さらにストアされる加工データも正規化の
誤解からか、データモデリングから外される場合が多々あり、在庫データや要約
データの扱いに明快な指導がありませんでした。

(注2)受注明細中の、受注単価=標準単価や、これから計算される受注金額、
また在庫数と安全在庫から計算できる在庫ステイタスC(0:十分あり、1:手
配要、2:自動発注要)-これは多分プログラムの中に一瞬登場し、メッセージ
を出力したら忘れられてしまい、アウトプットからも見えない-など物理テーブ
ルにストアされない加工データ。

③は加工データがデータモデリングの対象から外されたためとも言えますが、
この整合性管理が、DBMSの責務から外され、アプリケーションプログラムの
責務になったことです。たとえば、いま品番Pが倉庫Sに20個あるとき、ここ
から5個出庫すると在庫は15個になるはずです。これは
 在庫数量=在庫数量―出庫数量
のDIから決まるわけですが、一般にDBMSは出庫レコードを登録するだけで、
在庫データとの整合性管理には関与しません。このようなDI機能のDBMSか
らの分離は、システム開発の生産性において、つぎのような大きなマイナスを生
ずることとなりました。
 ・要件定義で作られるデータモデル図がDIを保障しないので、後のプログラ
  ム設計時にチェックされ手戻りが発生する
 ・アプリケーションプログラムの構造がDBの整合性管理とユーザIO処理を
  受け持つため複雑化する

このように、DBMSの機能がいわば「属性名とエンティティIDをもとに、ア
ドレスを計算しデータの出し入れを受け持つに過ぎない」ため、DBが実務の世
界を表現するためには、アプリケーションプログラムの正しい協力が不可欠となっ
ています。

④はRI(Referential Integrity、参照整合性)の拡張ともいえますが、属性
値が正しいか否かをDBMSとして保障する機能です。多くのDBMSベンダー
は、RIについては、E. F. Coddの指摘でこれを用意したわけですが、DIに加
えて、
   参照KEY以外についての定義域チェック
   存在制約チェック
は、通常アプリケーションプログラムに任せることになっています。定義域チェ
ックとは、データタイプのチェックを拡張するものであり、たとえば整数の場合
その値が、1-10であるべきなど最小・最大を含めてチェックするものです。
また存在制約チェックとは、単に値が存在すべきというだけでなく、サブタイプ
条件対応のチェック-顧客ならば与信限度が必須、サプライヤーならば口座番号
が必須など-や、サブストラクチャでのステイタス条件対応のチェック-受注時
はNULLでも良いが、見積後ならば見積金額が必須、また着工後ならば実行予
算確定など-を行うものです。

このように、現在はアプリケーションプログラムに依存している機能を、リポジ
トリを拡張して、本来はDBMSが行うべきと考えます。存在制約はサブタイプ
や、エンティティのステイタスの進捗に応じて変化しますので、サブタイプ条件
や、ステイタス条件との関係を明示して規定することになります。これをプログ
ラム屋ではなく、データモデル屋が、データモデリング時に、要件定義に含めて
従来より前倒しに、行うことになります。

こうして要件定義時に、DBの整合性が保障されると(注3)、ビジネス要件は
確定しており、処理設計は、意思決定のための試行計算(注4)を除けば、アプ
リケーション対応の入力順序の決定、およびユーザ対応のメニュ表示などの非機
能要件に焦点を当てた、ユーザフレンドリなIO設計に専念することになるはず
と考えます。

(注3)以上のDBMSの欠陥を解決する商品がすぐに提供されることは期待薄
ですが、設計工程において、整合性の取れた実装独立設計を先行させる手順や体
制を用意することは、実際弊社がこれまで行ってきたことであり、可能かつ有効
です。またリポジトリを付加してDI機能等を実現する露払いをDBMSの前に
用意し、DIをアプリケーションプログラムから切り離すこともさほど難しいこ
とではないと考えます。

(注4)板厚やパイプサイズなどの技術計算結果、決算のためのBS/PL試算
表、給与計算結果など、担当者による意思決定/承認を要する加工データは、意
思決定元データであり、意思決定者の制御下で計算されるので、ここでの加工デー
タからは除外するものとします。

■犯人さがし
一体誰が悪くてこうなったのか。「12のルールをこれさえ守れば万全とった言
い方をしたE. F. Coddが悪い」、「いや彼は数学者で、その言いなりに実装した
ベンダーが悪い」、「いやツールは使いようだ。使い方を考えなかったユーザが
悪い」、などいろいろの見方ができるかと思います。しかしこの議論は生産的で
はありません。「データ屋とプロセス屋がSQLを介して、別々の世界で作業し
ているのがまずい」と私は考えます。今は、上記4つの問題を吟味し、皆で共有
して、ツールと方法論について解決の方向を見出して行くべき時と考えますが、
いかがでしょう。