200541

基準編-1 「T字形 ER手法」 の位置づけ

>> 目次にもどる

201031日 補遺

 

 

 T字形 ER手法は、データベース 設計法として作られ、SDI/RAD は、システム 構築法として作られた。
 T字形 ER手法および SDI/RAD は、拙著 「実践 クライアント/サーバ データベース 設計 テクニック」(1993年出版) のなかで、「原型」 が出ている。当時、公表した 「原型」 は、すでに、以下の 2つの概念を導入している。

 (1) 「event」 概念
 (2) 「resource」 概念

 
 そして、「event」 と 「resource」 の間に成立する相関関係として、以下の 3つの生成規則を提示している。

 (1) 「resource」 と 「resource
 (2) 「resource」 と 「event
 (3) 「event」 と 「event

 
 また、サブタイプ を記述している。「同一」 の サブタイプ は、Shlaer/Mellor 方式を流用して、「相違」 の サブタイプ は、Ozsu/Valduriez 方式を流用している。しかしながら、(現時点から振り返れば、) 当時 公表した 「原型」 は、不完全な技術体系であった。不完全だった点を、以下に列挙する。

 (1) 「resource」 概念と 「event」 概念を マスター・ファイル と トランザクション・ファイル としている。
   すなわち、当時、「event」 を定義していなかった。

 (2) 対応表 (on-to mapping) と再帰 (recursive) を記述していない。

 (3) タイプ (type) とセット (set) の違いを理解していない。

 
 Entity は、identifier を使って認知して、identifier として、すでに、コード 体系を使うことにしていたが──(事業過程に対する) 管理過程の記述と データ 設計を、なんとか、1つの手法を使って同時に実現しようとしていたが──、(R) は、いまだ、「参照 キー(foreign-key)」 という言いかたをしていた。そして、(R) に関して、概念的な混乱は、「黒本」 でも、整理 (訂正) されないまま、継承されてしまった。

 コッド 正規形が、「意味」 を制約条件として記述したことに対して、小生は、不満を感じていたので、データ 正規形を作る時点で、意味論(semantics)──「event および resource」 という指示関係──を導入したが、T字形 ER手法は、いまだ、データ 設計法としての性質が強かった。ただ、当時、小生が、ひたすら、狙っていた点は、SE の恣意性 (恣意的な認識) を排除することだった。Entity を認知するために、コード 体系を使った時点で、(事業過程そのものを対象にしないで、) 管理過程を対象にして、「情報」 のなかで、ことば が、いかに使われているか、という点を重視していたので、ウィトゲンシュタイン 氏の 「論理哲学論考」 を底本にして、T字形 ER手法を作ったが、いまだ、データ 設計法として、コッド 関係 モデル の影響のほうが強かった。

 システム 作りとして、waterfall モデル を信用していない小生は、RAD Rapid Application Development)を、1980年代後半から使っていた。そして、RAD とT字形 ER手法は、それぞれ、相互作用を及ぼしながら、改良されてきた。
 RAD も、拙著 「クライアント/サーバ」 (1993年) と 「黒本」 (1998年) では、(5年のあいだで) 体系が変わった。「黒本」 を出版するまで──RAD は、途中、1995年に、書物として、体系を整理したが──、RAD もT字形 ER手法も、数多くの システム 作りのなかで──ステップ 数に換算すれば、数億 ステップ を超える実際の システム 作りのなかで──、験証して改良してきた。

 SDI/RAD は、百万 ステップ くらいの システム であれば、10数名──DADBA および SWAT チーム の合計人数──が、6ヶ月以内に導入することを実績値として示してきた。この生産性を実現するためには、SDLC の上流工程 (分析工程と設計工程) が、2ヶ月くらい──最悪でも、3ヶ月ほど──で完了しなければならない。したがって、工程を短縮するためには、1つの手法を使って、(事業の) 管理過程の記述と データ 設計を、同時に実現しなければならなかった。
 しかも、T字形 ER手法を使って記述された構造は、SDI/RAD の起点となるので、品質の観点から言えば、網羅性 (値の真理性) と検証可能性 (構造の妥当性) を実現していなければならなかった。

 T字形 ER手法と SDI/RAD の相互作用 (関係) を、基準編-1 として、まとめた。 □

 



[ 補遺 ] 201031日)

 T字形 ER手法 (TM の前身) と RAD (今風に謂えば、Agile) の どちらが先に生まれたのかを私自身の記憶をたぐってみて ハッキリ と断言することができない──たぶん、ふたつは、相乗作用のなかで整えられてきたのだと思います。敢えて謂えば、RAD のほうが先だったと思います。というのは、RAD は、1980年代後半に 「原型」 を考えていて、T字形 ER 手法のほうは、私が独立開業したあとで [ 1990年代初頭に ] 整え始めたので。RAD を実施していた頃にも 「T之字」 の記法を使っていましたが、コッド 正規形を作るための仕訳帳であって──私の恩師 Eric Vesely 氏から習った やりかた であって [ 本 ホームページ 「黒本を読む」 基準編-5 参照 ]──、T字形 ER手法の特徴点になっている 「関係文法」 は いまだ提示されていなかった。つまり、当時、私の最大関心事は、RAD [ 具体的には、本 エッセー のなかで記したように、百万 ステップ 規模の システム を 10数名の プロジェクト 構成で 6ヶ月以内に導入すること ] にあったと推測していいでしょうね。

 1980年代後半、コンピュータ 業界では、「生産性向上」 が テーマ になっていました。そして、当時、「SDLC System Development Life Cycle) の全工程 (分析・設計・製造・保守) を自動化する」 ことを狙って CASE Computer-Aided Software Engineering) ツール が マーケット に多数投入されました。私の処女作は、1989年に出版した 「CASE ツール 入門解説」 でした。ただし、私は、SDLC で使われている構造化手法を自動化しても さして生産性が向上するとは思っていなかったので、構造化手法の自動化とは違う やりかた を考えていて、CASE ツール のなかで、プロトタイプ (prototyping) を front-end にした ツール を使って システム を作って生産性を向上していました──当時、RAD という ことば を使ってはいなかった。RAD という ことば を使うようになった理由は、私が American Airline 社といっしょに講演した以後です。当時、American Airline 社が日本で講演をするので、私が前座でしゃべったのですが、かれらの やりかた が私の やりかた に似ていたので、かれらが使っていた ことば を借用した次第です。

 当時、プロトタイプ で screen-painting した項目を対象にして、T之字の仕訳帳──上述した コッド 正規形を作るための仕訳帳──を使っていました。ただ、この時点で、私は、コッド 正規形の 「意味論」 が弱いことを実地の システム 作りで痛感していて、なんとか コッド 関係 モデル に対して 「意味論」 を補強したいと考えていました。この時点を T字形 ER手法の 「着想」 が生まれたときだとすれば、RAD とT字形 ER手法は、ほぼ、同じ時期に生まれたということになります。

 RAD を実現するためには、本 エッセー のなかで綴りましたが、分析・設計は 2ヶ月 (あるいは、3ヶ月) で終わらなければならない。とすれば、分析と設計をべつべつに実施している時間的余裕はないので、分析と設計の二つを一つの モデル で同時に実現しなければならない。それがT字形 ER手法が出てくる要請だったと云っていいでしょうね。

 T字形 ER手法を 「それなりの形で」──すなわち、「関係文法」 を明示した形で──示した著作が 「クライアント/サーバ データベース 設計 テクニック」 (1993年出版) だったと記憶しています。すなわち、この時点で、「event resource」 という概念を導入して、以下の 「関係文法」 を公にしました。

 (1) 「event--event」 の関係文法
 (2) 「resource--resource」 の関係文法
 (3) 「event--resource」 の関係文法

 これらの文法を作るときに、私は、「直積集合」 に そうとうに悩まされていました。「直積集合」 を使った 「関係」 の一般式は、以下のとおりです。

  R { s1X1, s2X2, ・・・, snXnP (s1, s2, ・・・, sn }.

 この一般式においては、「項」 は あくまで 「項」 であって、「event」 だの 「resource」 だのという 「意味論」 を混入してはいけない。もし、「event resource」 という概念を導入するのであれば、そして、それを なんらかの有向 グラフ として図にするのであれば、それぞれの 「項」 のあいだで 「対応表」 を作ればいい、と私は当初思っていたのですが──すなわち、「event--event」 において 「対応表」 を作り、「resource--resource」 において 「対応表」 を作り、「event--resource」 において 「対応表」 を作ればいいと思っていたのですが──、そういう やりかた (対応表) では、「事態」 の構成を形式化できない。たとえば、以下を考えてみます。

  { 受注番号、顧客番号、商品番号、受注日、受注数 }.

 この構成を、もし、上述した 「対応表」 で記述すれば以下のようになるでしょう。

  { 受注番号、受注日、受注数 }.

  { 顧客番号、顧客名称 }.

  { 商品番号、商品名称 }.

  { 受注番号、顧客番号 }.

  { 受注番号、商品番号 }.

  { 顧客番号、商品番号 }.

 この構成だと、「受注」 という 「事態」 が形式的に構成されていないので、現実的事態と モデル との指示関係 (意味論) が かえって逸脱してしまう。

 T字形 ER手法の 「関係文法」──そして、それは、TM に そのまま継承されましたが──が整えられたのは、(「クライアント/サーバ データベース 設計 テクニック」 を執筆した以前で、) データベース 設計法の講師をしたとき、ハンドアウト に記されたのが最初だったと記憶しています。ハンドアウト を作成する数日前まで、「関係文法」 は、上述したように、すべての 「項」 (entity) のあいだで 「対応表」 を構成するという やりかた を考えていました──すなわち、「構成」 は、すべて、「対応表」 で記す [ ふたつの集合のあいだの写像を 「対応表」 で記す ]、と。そして、ハンドアウト を作成している最中に、「関係文法」 は、今の形として整えられました。もし、「対応表を使った構成法」 を 当時 公表していたら、、、と想像すると冷や汗が出ます──というのは、その やりかた には、なんら、理論的な妥当性がないので。

 「event resource」 という考えかたは、そもそも、項の 「並び」 を意識して導入されたので、全順序を示す 「event」 どうしの関係と半順序を示す 「resource」 どうしの関係を文法として構成するのは難しくなかったのですが、最大の論点になったのが、「event--resource」 の関係でした。当時から、私は、意味論上、「事態 (event)」 が事業を構成しているという考えかたを モデル の中核に置いていたので [ それは ウィトゲンシュタイン 氏の 「論理哲学論考」 からの影響でしたが ]──しかし、当時、「event」 を定義していなかったのですが──、たとえば、上述した 「受注」 の例でいえば、以下の構成を説明できる文法 (証明) を考えなければならないと思っていました。

  { 受注番号、顧客番号 (R)、商品番号 (R)、受注日、受注数 }.

 ここで (R) は 「関与」 を示しているのですが、当時、本 エッセー で述べたように、いまだ、コッド 正規形の考えかたを継承していて、「外来 キー (あるいは、参照 キー)」 というふうに考えていました。この正規形を前提にして、「resource identifier event のほうに挿入される」 という文法にしていた次第です──したがって、当時、(R) に関して、理論的な証明は一切されていない。しかし、一見常識に思われる この考えかた [ resource identifier event のほうに挿入される、ということ ] が、その後、私を 10数年苦しめることになったのです。というのは、その構成が理論的に妥当であるという証明を考えなければならなかったので。

 TM (T字形 ER手法の改良版) では、「関係文法」 は以下のように まとめられています──ただし、ここでは、「多値」 の論点を除いておきます。

  (1) 「event--event」 の並びは、全順序 (先行・後続 関係) である。
    したがって、先行 event の個体指定子を後続 event に挿入する。

  (2) 「resource--resource」 の並びは、半順序である。
    ふたつの集合を前提にして和集合 (event) を構成する。

  (3) 「event--resource」 の関係では、以下の規約を使う。
    「resource event に関与する」。

  (4) ひとつの集合のなかの メンバー を並べる (再帰)

 ただし、(3) は、哲学的 ソリューション であって、数学的 ソリューション ではない点に注意してください。この点は、関係主義と実体主義とのはざまで グレーゾーン になっている点です──私の観る限りでは、この点に言及している数学者・哲学者は [ 関係主義の立場にいて、かつ、実体主義的な視点を持っている数学者・哲学者は ] ホワイトヘッド 氏と パース 氏だと思います。そして、私は、かれらの説を TM で借用しました。





 

<< もどる

HOME

すすむ >>

 

「T字形 ER データベース設計技法」を読む