» 【第114号】リレーショナルモデルの問題点

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

■アクセスメソッドからDBMSへ
今やRDB全盛、RDBによらないシステムはほとんどない、と言って良いほ
どです。しかし、近頃よくそのベースとなるRDM(Relational Data Model)
に起因すると思われる問題に遭遇します。そこでDBMS誕生のころからかか
わってきたモデル屋として、「私見が強すぎる」との批判を覚悟して、以下ま
とめてみたいと思います。

外部記憶へのアクセスは、初めはテープに対するBSAM、QSAMといわれ
る順次アクセスメソッドでスタートしました。ディスクが登場してから、ISAM、
DAM、さらにVSAMなどの直接アクセスメソッドが生まれました。物理的
なIOの単位、物理レコードは、当初アプリケーションの処理する単位、論理
レコードを固定数まとめたブロックと言うものでしたが、最終的に物理レコー
ドの大きさは、論理レコードとは独立に、たとえば4Kバイトなどと固定的に
なっていきました。物理は論理の制約がない方がその役割を果たしやすいから
でしょう。
直接アクセスとともに、外部記憶にはアプリケーションデータの構造を表現す
る機能が求められ、階層型(IMSなど)やネットワーク型(TOTAL、
IDMS、AIMほか多数)、またインデックス型(ADABAS、S/2000、
DATACOMなど)のいわゆる構造型DBMSが登場しました。主に1970
年代のことです。これによって受注−受注明細のようなヘッダ−ディテイル構造や
BOM(部品表)のデータ構造が表現でき、業務アプリケーションが作りやすくなり
また排他制御機能が用意され、複数ユーザの同時更新が可能になりました。
しかし、作られたデータベースは、原則として特定のアプリケーション・プログラム
の専用ファイルでした。
■Coddの提案
3年前に亡くなったE. F. Coddに今さら確認するわけにはいきませんが、1970
年に論文 ”Large Shared Data Banks” を書いたCoddは「データベースとは
もっと大きな共用資源であり、高級アクセスメソッドともいわれる構造型DBMS
で間に合うものではない」と思っていたに違いありません。そこで1985年
にDBMSの満たすべき12のルールを提案します。これを筆者は「共有資源
であるからには、DBは実世界の写像であり、整合性を保証しなければならない。
そのためにはOne Fact in One Placeにより冗長性を排除し、さらに参照制約も
必須。そしてDBサーバーに対して必要なデータを一括して要求できるもので
なければならない」と主張していたように解釈します。
後述するように種々の問題が残されているのですが、この論文ほど市場の風向
きを大きく変えた例を知りません。一番大きなダメージを受けたのはIDMS
でしょうか、かなり好調であった商品ですが、急速に衰退していきました。
そして他のネットワーク型、階層型、インデックス型も次第にRDBMSに代
替されていきました。
自社IBMのRDBMS製品DB2についても、Coddは不満を持っていたとの
ことですが、大筋はCoddのRDMに基づいて作られているはずであり、多くの
ユーザ(データ管理者、SEを含む)はRDBMSを介してRDMを理解して
いったものと思われます。Coddは12のルールは必要条件だと言ったのであっ
て、十分条件だとまでは言わなかったのかもしれません。しかし世間は、ツール
ベンダーの宣伝もあって、12のルールを満たしたツールは完璧だ、それを用
いてシステムを作れば完璧なシステムができる、と受け取ったようでした。
■4つの問題
筆者が問題とするものは、次の4つです。
① RDMは実装独立の概念モデルではない
② ①により加工データが冗長データとして排除されているためか、加工・加工
  元データ整合性についての言及がない
③ DBのスコープの設定について言及がない
④ DB設計の素材について言及がない

① は「RDMがカラムとタプルから成るテーブル形式のストレイジを前提とし
た実装のモデルであり、意味論モデルでない(注1)」ということです。処理
は本来セマンティクスを持つ属性値に対するオペレーションとして規定される
べきです。RDBのカラムが属性にかなり良く対応するので、実害が少ないと
して見過ごされるのでしょうが、属性と定義域(特に参照KEYとKEY定義
域、たとえば受注品番、発注品番、親品番、登録品番など)の区別を理解しな
い多くの人々を生み出し、データの意味を考察する場合に行き違いが発生しや
すくなりました。SQLが、本来DB設計時に決まっているKEYと参照KEY
の関係を、実行時に指定させるのも混乱を助長しているようです。必然的に、
RDBのカラムとして実装されない属性は設計対象外とされ、加工データ(特
に中間加工データ)やチェックデータ(ロジックを分岐させるスイッチなど)
が属性として扱われず、プログラム仕様としてこれを扱うため、これを複雑化
させました。また異なったデータモデルで構築されたレガシーシステムのデータ
との関係−同じか違うか、どう違うかなど−が分かりにくくなりました。概念、
論理、物理の3階層において、論理を概念の代用とすることになりますが、論
理は一番概念に近いけれど、やはり物理の範疇であり、無理があるようです
(Coddも意味論的に完全でないことは分かっていたようです)。
(注1)Coddは12のルールの法則1として「すべてのデータはテーブル形式
でユーザに表現されなければならない」と述べていますが、その根拠や意味論
との関係については述べていません。一方「ストレイジは前提とするが、テーブル
形式にはこだわらない」という意味論モデルに近い論理モデル派もありますが、
ここでは対象外とします。
②は、在庫数量、給与金額、月次売上金額、また多くのエンジニアリングデータ
−たとえば柱の太さ、鉄骨重量−など多くの加工データを冗長としてDBから
排除する(Coddの真意だったかどうかは分かりません)ものです。正規化に関
する冗長データとの混同に起因するものと思われますが、実用上困りますので、
多くの設計者はRDMの基準を無視してこれを扱っているものと思われます。
DBMSが整合性を保証するためには、参照整合性とならんで本来加工・加工
元データ整合性−5個出荷すれば在庫は5個減るなど−も保証すべきですが、
このためには加工・加工元関係をDDLとして定義しなければなりません。
しかしこれも12のルールに言及がなかったためか、どのDBMSも取り組ん
でいません(目下外付けのリポジトリやストアドプロセジャーによって補完せ
ざるを得ないようです)。このため「DOAはDB設計の方法であり、処理は
扱わない」との誤解を生む原因にもなっているようです。
③は、Large Sharedと言うけれど「どこまでか」に言及しないため、スポンサー
の資金、希望納期、プロマネ/SEの思い込みなどによって、DBの範囲が決
まってしまい、多くの孤島システムが作られた問題です。DBは通信の場です
から、同じDBを共用する範囲でデータが流通します。そこがデータ標準化に
よって作られる文化圏となります。技術屋、営業、経理屋を同じ文化圏に入れ
ることは一般に困難です。家電と重電を同じ文化圏として一括することも必ず
しも得策とはいえません。こうして文化圏が決まり、そこに個別アプリDBが
作られます。しかし、これらが協調的にコミュニケーションして全社システム
を構成しなければなりません。
このためには、各DBで共有するリソースデータ(商品や取引先などのマスター
データ)の値や形式についての標準化が必要になります。またDB間でやり取
りされるデータ/トランザクション−A2A(Application to Application)
のハイレベルメッセージ−に関する通信場が必要になります。こうして個別ア
プリDBが協調するための、3種のインフラDB−リソースDB、メタDB、
EDW(Enterprise Data Warehouse、アプリケーション間でやり取りされる
データをストアする)−が必要になりますが、このようなDB複合体に関する
言及がありませんでした(Coddはディレクトリが1個のDB、メタDBを構成
することに気づいていたのかどうかはっきりしません)。このため、DB設計
担当者は、与えられたアプリDBだけを念頭に孤島システムを作ってきてしま
いました。
④は、設計されたDBとその根拠の関係です。組立加工工業の部品表ならば、
その部品は製品との関連がつけられています。同様にDBの部品、すなわち属
性は製品である画面・帳票の各データと対応付けられるはずです。したがって
AsIsのDBはAsIsの画面・帳票と、ToBeのDBはToBeの画面・
帳票と対応づくはずです。それによって正しいか否かが検証できます。時間を
節約するためにトップダウンにDB設計をしても良いのですが、画面・帳票に
よる検証を忘れて、思い込み先行の不整合や抜けだらけのDB設計がまま見ら
れます。これはRDMが何を素材としてモデリングすべきかに言及していれば
防げた問題と考えます。
特に指摘しておきたいのは、メタデータリポジトリの設計素材です。メタデータ
リポジトリはシステム設計というひとつのアプリケーションのDBですから、
システム設計で用いる画面・帳票との対応があるはずです。システム設計で用
いる画面・帳票は方法論によって決まりますから、メタデータリポジトリの構造は
方法論によって変わってくるはずです。1990年代はじめのIBMのリポジトリプロ
ジェクトの失敗の原因は、方法論、したがってそこで用いる設計ドキュメントの
未確定にあったものと解釈されます。ちなみにわれわれは、THeRepositoryの
設計にあたり、PLAN−DB要件定義基本4ドキュメント(概念DB構造図、データ
定義書、IPFチャート、画面・帳票イラスト)を素材にデータモデリングを行いました。
各種標準化団体でメタデータリポジトリ標準化の動きがあるようですが、開発方法
論およびその中での設計ドキュメントとの対応はどうなっているのでしょうか。実装
以前の領域での標準が、一流の関係者の同意だけで作られて良いのでしょうか。
■RDMの功罪
RDMに基づいてRDBMSが開発され、DBは特定プログラムの専用ストレ
イジから、特定アプリケーションの共用ストレイジに進化していきました。
必要なデータがWHATの形式で一括指定でき、オプティマイズが可能になり
大幅な性能アップが実現されました。こうしてRDBが普及して行きましたが、
さきの4つの問題は、アプリケーション横断における高品質の−ユーザ要件を
正しく反映し、整合性のとれた−データベース環境の構築への障害となりました。
データモデルは、DBMS設計のベースであると同時に、開発方法論の中核と
なるデータモデリングのベースでもあります。多くの関係者はツールすなわち
DBMSやモデリングツールを通じて、データモデルのコンセプトに接し、影
響を受けます。RDMの上記4つの問題点は、RDBMSやこのためのデータ
モデリングツール設計者に引き継がれ、「エンティティタイプとテーブルを同
一視し、レガシーシステムとRDBシステムの統一的可視化や、業務ルールの
正確な記述によるプログラミング自動化を難しくする」など、種々の影響を残
したものと思われます。この影響はまた今日、オブジェクト指向設計者にも、
色濃く引き継がれているように見えます。
(注2)問題点3、4をRDMに帰するのは、CO2増加を自動車発明に帰す
るようなもので、酷ではないか、という評価も理解できます。しかし筆者はT
Hデータモデルを提案した1970年代前半から、エンジニアリング会社のトー
タルシステムを視野に、各種DBからなるDB複合体システムが必然と考えて
いました。1980年度にIPAへ提出した「DBCMS−データベース・コ
ンプレックス・マネジメントシステム」は、そのためのDB複合体を管理する
ツールの提案書(実装には至らず)です。DB複合体のアーキテクチャを前提
に、DBMSを考えなくては、孤島システムが発生して混乱するとの理解の下
に、先に述べた構造型DBMSの出現と衰退、これに続くRDBMSの発展の
歴史を心配しながら見てまいりました。「リソース系エンティティとイベント
系エンティティを同居させるDBは禍根を残す、これはDBMS/データモデ
ルとして防止すべきである。RDB全盛となってもシステムの混乱は本質的に
は解決しない」と考えていましたので、Coddに責を問わないまでも、今やこれ
を超えた認識の基にシステム問題に取り組むべき時代であると考え、上記の記
述といたしました。