2004年 3月16日 作成 データ 設計技法 （関係 モデル と DBTG 図） >> 目次 （テーマ ごと）
2008年 4月16日 補遺 　


　
　関係 モデル は、直積集合の考えかたを前提にして、複数の 「属性値集合」 （セット） のなかから、メンバー を１つずつ選んできて、タプル （a tuple） を構成する やりかた である。したがって、主体集合は、記号化されていることを前提にして、（横列の） タプル として記述されるが、属性値に対する アクセス は、（縦列の） セット を単位とする。そのために、関係 モデル の アクセス 法のことを 「セット・アット・ア・タイム （set-at-a-time）」 法という。コッド 氏　(Codd, E.F.) が提示した やりかた である。セット・アット・ア・タイム 法を前提にした データベース が リレーショナル・データベース （RDB） である。

　いっぽう、複数の属性値の集まりを 1つの 「レコード （a record）」 とみなして、複数の レコード の集まりとして、1つの主体集合を構成する やりかた もある。レコード 集合間の構造を記述した ネットワーク・モデル として、バックマン （Backman）・ダイアグラム がある──バックマン （Backman, C.） 氏が提示した やりかた である。レコード を単位とする データ・アクセス のことを、「レコード・アット・ア・タイム （record-at-a-time）」 法という。ネットワーク・データベース （NDB） は、レコード・アット・ア・タイム 法を前提にしている。

　データシステムズ 言語協議会 （CODASYL）（注 1） の データベース 作業 グループ （DBTG）（注 2）は、1969年、データベース 作成基準を提案し、いわゆる DBTG 図が提示された。DBTG 図は、バックマン・ダイアグラム を、ほぼ、そのまま転用している──バックマン 氏が、DBTG 委員会の議長であった。

　
　さて、歴史上、興味深い点は、DBTG 図が 1969年に提示され、コッド 論文が、1970年に提示され、ほぼ、同じ時期に、データベース の モデル として、レコード 系と セット 系の モデル が提示されている、という点である。さらに、後年 （1976年）、どのような データベース 構造に対しても、概念設計上、「意味論 （semantics、セマンティックス）」 を前提にして 「構造」 を記述する ER手法を、チェン氏 （Chen P.）が提示した。

　当時から ほぼ 30年の歴史が流れ、以上の 3つの手法の関係は、およそ、それらの手法の目的・前提から離れた使いかたをされて、（プロダクト としては、NDB に比べて、RDB のほうが多く使われてはいるが、） コッド 正規形の描画手法として チェン ER図が使われ、セット・アット・ア・タイム 法が レコード・アット・ア・タイム 法として使われている、という奇妙な （整合的ではない） 状態になっている。
　そして、整合的ではない、それらの使いかたは、1980年代、小生が RDB を日本のなかに導入して普及する際、小生も犯した間違いであった。（注 3）

　整合的でない使いかたをすれば、概念設計と論理設計と物理設計の間には、SDLC のなかに生じている 「溝」 が、そのまま写像されて、概念設計の アウトプット を論理設計として変換する作業は、システム・エンジニア の力量に任され、およそ、データベース 設計が、単なるファイル 設計に成り下がってしまうし、RDB の高 パフォーマンス を実現することができない。
　幸い、小生が使っていた RDB は、驚異的な パフォーマンス を実現する プロダクト であったので、パフォーマンス に関しては、問題点を意識したことはなかったが、データ 設計に関しては、概念設計 （意味論） と論理設計・物理設計 （数理 モデル） との断絶は埋めがたい現象であった。

　小生が、その間違いに気づいたのは、1990年代初期であった。（注 3）
　その間違いを訂正するために、小生が提示した手法が、「Ｔ字形 ER手法」 であり、「INDEX-only」 であった。

　
[ 注釈 ]

（注 1）
　Conference on Data System Languages の略称。「コダシル」 と発音される。

（注 2）
　Data Base Task Group の略称。

（注 3）
　拙著 「CASE ツール」 （SRC 社刊）は、1989年に出版したが、いまだ、「間違い」 の痕跡が遺っている。
　拙著 「CASE ツール」 のなかでは、DBTG 図が チェン ER図よりも重視されている。
　Ｔ字形 ER手法の 「原型」 が出てくるのは、1993年に出版した 「クライアント/サーバ データベース 設計 テクニック」 （SRC 社刊）である。

　幸いだったのが、「CASE ツール」 （1989年） と 「リポジトリ 入門解説」 （1991年） のなかで、SDLC の断層を意識していた、という点である。この意識が、DBTG 図 （レコード系）・コッド 正規形 （セット 系）・チェン ER図 （意味論） のそれぞれの着想を融合する動因となった。
　コッド 正規形 （数理 モデル） と チェン ER （意味論） の相克を取り除くために、Ｔ字形 ER手法が生まれた。
　コッド 正規形 （セット系） と DBTG 図 （レコード 系） の相克を取り除くために、「INDEX-only」 が生まれた。



[ 補遺 ] （2008年 4月16日）

　私は、当時 （RDB を日本に導入した 1980年代）、いまだ、「数学基礎論」 を体系だって学習していなくて、「モデル （論理的意味論）」 という考えかたを持っていませんでした。したがって、当時の私は、「モデル」 を、事実上、「記述的意味論」 であると思っていました──記述的意味論の 「典型」 が チェン ER手法でしょうね。

　DBTG 図は、当時、私の恩師 Eric Vesely から習いました。当時、私の頭のなかでは、コッド 正規形、DBTG 図、チェン ER図が、なんら、脈絡のないまま──言い換えれば、それぞれの底辺を作っている思想を理解しないまま──、べつべつに立っていました。それらの べつべつに立っていた やりかた を 「強引に」 接続して、「コッド正規形 → チェン ER図 → DBTG 図」 という妙な体系を作ってしまいました （反省）。当時、コッド 正規形を （今はやりの ことば で言えば、） 「見える化」 （give visibility） するために チェン ER図 （および、DBTG 図） を借用した、と言っていいでしょうね。こういう やりかた は、「工夫」 ではなくて、「誤用」 です。

　ただ、幸いにも、本 エッセー のなかで述べたように、当時から、「コッド 正規形 vs. チェン ER手法」 と 「コッド 正規形 vs. DBTG 図」 を意識していました。そして、私が 当時 争点にしたのは、「『分析と設計』 の乖離」 と 「entity 捕捉の恣意性」 でした。そういう意識を抱いていたので、私には、論理的意味論に移る下地があった、ということです。論理的意味論は、「『分析と設計』 の乖離」 に対する ソリューション を示してくれましたが、「entity 捕捉の恣意性」 に対して ソリューション を示してくれなかった。「entity 捕捉の恣意性」 を除去するために、私がとった やりかた は、「合意された認知」 という概念でした。事業過程のなかで伝達される 「情報 （画面・帳票・レポート など）」 で示されている コード （個体指示子） を 「合意された認知番号」 として使うことにしました。したがって、「数学基礎論」 の モデル 理論 （論理的意味論） を基底にして、変項に対して 「（コード [ 個体指示子 ] を使った） 認知」 という 「解釈」 を導入しました。言い換えれば、コッド 関係 モデル に対して、意味論を 「強く」 適用して モデル を整えました──それが、TM （Ｔ字形 ER手法の改良版） です。
　ちなみに、モデル 理論を丁寧に学習した時期は、1990年代の後半であって、それ以前に、「Ｔ字形 ER手法」 は生まれていて、実地に使っていましたが、「Ｔ字形 ER手法」 を モデル 理論の観点から検討し直しました──まず、拙著 「論理 データベース 論考」 （2000年出版） で構文論を検討して、次に、拙著 「データベース 設計論」 （2005年出版） で意味論を検討しました。そして、従来の 「Ｔ字形 ER手法」 を改良した形になったので、新たな名称として、TM （および、TM’[ TM ダッシュ、あるいは TM プライム と発音します ]） にしました。TM という呼称は、従来の 「Ｔ字形」 の T に対して メソッド の M を合成したのではなくて、チューリング・マシーン の頭文字を借用しました──というのは、論理的意味論の観点に立って、データ を構成する 「アルゴリズム」 を示す、という意味を込めているので。 　




　 << もどる ベーシックス すすむ >>
　 ▼ データベースの基礎知識