2007年 7月 1日

特論-12　Ｔ字形 ER手法 （その 2） [ 対照表の根拠 ]

>> 目次に もどる

2012年 6月 1日 補遺

　



　前回 述べたように、entity を定立したあとで、私が考えた点は、「論理哲学論考」 で示された 「真理値表」 を 「データ 構造を作る （すなわち、「事実」 を写す） 像」 にするという点でした。言い換えれば、コッド 関係 モデル の射影を 「真理値表」 で記述するということでした。たとえば、2つの entity ｛ E1, E2 } があったとして、それらが関与して起こる 「事態」 を ｛ (T, T) (T, F) (F,T) (F, F) } という形式で記述しようと考えました。　したがって、いまでは TM （Ｔ字形 ER手法） の特徴点になっている 「event と resource」 に対して、event であろうが resource であろうが、つねに、entity のあいだでは、「対応表」 を作るという 「構造」 を考えていました。しかし、この 「構造」 が、いわゆる 「event」 を適切に指示しないことに気づいて、「関係 R (a, b)」 に対して TM の 「関係文法」 を作りました。

　TM の 「関係文法」 を、以下の 4点として整えました。
　なお、R (a, b) では、a と b を entity （同じ性質をもつ個体の集合） とし、関係は 2項関係とします。

　（1） a と b が、それぞれ、べつべつの集合である。

　　（1）-1　resource と event のあいだの関係

　　（1）-2　event どうしの関係

　　（1）-3　resource どうしの関係

　（2） a と b が同じ外延 （集合） である。

　　　いわゆる 「再帰 （recursive）」。
　　　すなわち、1つの集合のなかの メンバー を 「並べる」。

　
　さて、TM では、「resource どうしの関係」 として記述される構造が 「対照表」 です。
　Event は、TM の定義では、「性質として 『DATE （取引日』 が帰属する」 個体とされています。言い換えれば、event は、「生起する現実的な事象 （受注、出荷、請求など）」 です。いっぽう、resource は、（event の補集合とされ、） 「持続する現実的な事物 （商品、従業員、取引先など）」 および 「反復する抽象的な事物 （カラー・コード を個体指示子にして認知される カラー [ 色 ] とか、サイズ・コード を個体指示子にして認知される サイズ [ 寸法 ] など）」 です。「対照表」 は、2つの resource の対 （組） を記述します。したがって、「対照表」 は、2つの resource の成立・不成立 ｛ (T, T) (T, F) (F,T) (F, F) } を記述する 「真理値表」 です。たとえば、｛従業員、部門｝ の対照表では、以下の 4つの場合分けを考えることができます。

　（1） ｛T, T｝　すべての従業員が すべての部門に配属されている。
　（2） ｛T, F｝　従業員のなかで、配属されていない従業員がいる。
　（3） ｛F, T｝　部門は設立されているが、だれも配属されていない。
　（4） ｛F, F｝　従業員も存在しないし 部門も存在しない。

　（4） は、事実上、データ として起こり得ない。そして、（3） も、たぶん、データ として起こり得ない （しかし、そういう現象は皆無とも言い切れないかもしれない）。したがって、TM では、｛従業員、部門｝ の対照表は、形式的 サブセット （null が起こるので サブセット 化すること） として、以下のように記述されます。

　　　　　　　　　　　　　┌─────────────────┐
　　　　　　　　　　　　　│　　　従業員. 部門. 対照表　　　　│
　　　　　　　　　　　　　├────────┬────────┤
　　　　　　　　　　　　　│従業員番号（Ｒ）│　　　　　　　　│
　　　　　　　　　　　　　│部門コード（Ｒ）│　　　　　　　　│
　　　　　　　　　　　　　│　　　　　　　　│　　　　　　　　│
　　　　　　　　　　　　　└────────┼────────┘
　　　　　　　　　　　　　　　　　　　　　　｜
　　　　　　　　　　　　　　　　　　　　　　×　null （部門コード）
　　　　　　　　　　　　　　　　　　　　　　｜
　　　　　　　　　　┌───────────┴───────────┐
　　　　　　　　　　｜　　　　　　　　　　　　　　　　　　　　　　　｜
　┌────────┴────────┐　　　　　┌────────┴────────┐
　│　　　　　　　配　属　　　　　　　│　　　　　│　　　配属されていない従業員　　　│
　├────────┬────────┤　　　　　├────────┬────────┤
　│従業員番号（Ｒ）│　　　　　　　　│　　　　　│従業員番号（Ｒ）│　　　　　　　　│
　│部門コード（Ｒ）│　　　　　　　　│　　　　　│　　　　　　　　│　　　　　　　　│
　│　　　　　　　　│　　　　　　　　│　　　　　│　　  　　　　　│　　　　　　　　│
　└────────┴────────┘　　　　　└────────┴────────┘

　
　「対照表」 は、2つの resource に関する 「真理値表」 として作用しますが、いっぽうで、本 エッセー では論点先取りになってしまいましたが、2つの resource が関与して起こる 「事態」 --この例では、「配属」--を言及しています。ただし、event ではありません。というのは、event は、TM の定義では、個体指示子 （認知番号） を付与されていなければならないから。「黒本」 では、このことを、以下のように綴っています。

　　　　「対照表」 は、「事態」 （および、「事実」） を表現する。ただし、「事態」 の中には、「名辞」 として
　　　　扱う モノ が多い。

　ここで云う 「『名辞』 として扱う モノ」 というのが event のことです。すなわち、「対照表」 は、事態を言及しているけれど-- event の性質を帯びているけれど--、個体指示子を付与されていないので、event ではないということです。また、「多い」 と綴った理由は、「対照表」 は、かならずしも、event を言及する訳ではなくて、ときには、2つの resource を制御する 「制約・束縛 （constraint）」 を示すこともあるということです。「黒本」 の これらの記述は、のちのち、「赤本」 （「黒本」 の間違いを訂正した書物） で、意味論上、「真」 概念 （「事実的な 『F-真』」 と 「導出的な 『L-真』」） を使って整えられました。「事実的な 『F-真』」 は、「対照表」 が現実の事態を指示する event 的性質をもっていることを云い、「導出的な 『L-真』」 は、「対照表」 が （現実の事態を指示するのではなくて、） 2つの resource のあいだの 「制約・束縛 （constraint）」 を記述していることを云います。
　「黒本」 では、「対照表」 の性質を以下のようにも記述しています。

　　　　「途中生成の対照表」 は、蓋然的命題である。蓋然的命題は、いわば他の命題の抜粋である。

　この記述は、TM の関係文法が数学的な 「解析」 を前提にして作られていることを示しています。「解析」 とは、数学的な論法の一つであって、証明しなければならない対象 A が存在しているとき、A が成り立つためには、B1 が成り立たなければならないことを示し、さらに、B1 が成り立つためには、B2 が成り立たなければならないことを示すというふうに、以下のように、順次、対象を導出する手順です。

　　　　　A → B1 → B2 → ... → Bn.

　そして、A を、終いには、「既知の ことがら」 Bn に帰着する やりかた を 「解析」 と云います。TM では、「既知の ことがら」 Bn として--すなわち、最小単位たる 「打ち止め」 として-- entity を考えています。entity は、認知番号を付与された 「合意された、既知の ことがら」 とされています。そして、A が 「情報 （帳票、画面など）」 です。「構造」 は、「解析」 の逆の道を辿ることになります。すなわち、起点となる entity を組み合わせて 「構造」 を作ります。そして、entity が resource どうしであれば、（TM の関係文法に従って、） 「対照表」 が生成されます。言い換えれば、「対照表」 は、「解析」 上、ひとつの複文 （複合命題） たる A を構成する蓋然的命題であって、「真理値表」 のなかで真偽を問われる事態であるということです。

　以上の諸点を お読みいただければ、私が 「論理哲学論考」 （ウィトゲンシュタイン） を使って、「『事実』 を記述する」 やりかた を考えた次第を ご理解いただけるでしょう。



[ 補遺 ] （2012年 6月 1日）

　「対照表」 は、次の 3つの構成的性質のいずれかを示します。

　　（1） event 的性質

　　（2） resource 的性質

　　（3）（resource のあいだに成立する） 制約・束縛

　それらのいずれの性質であるかは、文脈の中で判断するしかない。

　たとえば、（1） の例として、「在庫」 を考えることができるでしょう── { 倉庫 コード (R), 棚番号 (R), 商品番号 (R), 棚卸日, 数量, ・・・ }.（2） の例として、「銀行口座」 を考えることができるでしょう── { 銀行コード (R), 支店コード (R), 口座番号 (R), 名義人名称, ・・・ }.（3） の例として、たとえば、{ 取引先 コード (R), 商品番号 (R) } として、しかじかの取引先では かくかくの商品を扱っているなど。

　当初 （Ｔ字形 ER法を考えはじめた頃）、「対照表」 は真理値表として使うことを考えていたのですが──すなわち、（3） の使いかたを想定していたのですが──、「Ｔ之字」 記法で 「対照表」 を記述するときに、右側 （アトリビュートの記述） が論点になった。すなわち、「対照表」 の アトリビュート として 「日付」 を仮想すれば、あるいは、「日付」 の データ が実存すれば、「対照表」 は （Ｔ字形 ER法上、entity の定義を準用すれば、） event 的性質を帯びます [ （1） の例 ]。そして、（1） は、もし、「日付」 が実存しなければ、（3） の性質 [ 制約・束縛 ] としても 「解釈」 できます──すなわち、しかじかの倉庫には かくかくの棚が設置されている （あるいは、設置されるべき） という構成状態を示すことになります。そういう次第で、「対照表」 の意味を一律に定立することができないのです。言い替えれば、文脈の中でしか把握できないのです。そのために、TM では、「対照表」 の 「解釈」 規則として次の規則を置いています。

　　　　対照表は、その性質として、「日付」 が帰属するか、あるいは、「日付」 を仮想したいとき、
　　　　そして そのときに限り event として 「解釈」 する。

　「対照表」 を一つの射影として考えた時、（1） および （2） を TM 上で定義域として構成することは TM の 「公理 （前提）」 に反します──というのは、TM では、entity は 「個体指示子」 を付与された管理対象として定義されているので。しかし、たとえば、（1） のように、「日付」 が実存するのであれば、明らかに、event としての性質が考えられている。すなわち、「関係」 R (a, b)　において、a および b が resource の時、「関係」 が event を構成できるが、「個体指示子」 を付与されていないという状態です。逆に言えば、event は、「個体指定子」 を付与されていなくても 「構成できる」 ということ。この 「関係」 を TM の文法として認めるかどうかを私は ずいぶんと悩みました。

　そして、私が導入した文法は、真理値表としての「対照表」 を拡充して、構成文法の一つとすることでした。そして、その文法から （3） が導出されることになった。その文法が 「関数」 としてしか示すことができないので──言い替えれば、合意された 「個体指示子」 を付与されていないので──、entity と同次元で扱うことができないし、したがって、entity と同じ文法を適用することができないのを私は困惑していました。そのために、たとえば、関係文法 R { event, 対照表 } や R { resource, 対照表 } として如何なる文法を立てればいいのか私にはわからなかった。

　当初、「対照表」 について私が考えた関係文法は、「対照表」 が event の性質を帯びているのであれば、event としての文法を適用すべきだ、という文法でした──実際、「黒本」 では、そういう文法を適用していました。しかし、その後に、「対照表」 が （2） の性質を示すことが生じるのを知って、「対照表」 を event と同一視する文法が正しくないことをわかった。この間違いを犯した理由を簡単に言えば、私は 「構文論」 と 「意味論」 とをごっちゃにしていたということです。言い訳すれば、entity に対して 「event」 「resource」 という意味論的性質を導入したので、それに引き摺られてしまったということです。関係文法上は、「対照表」 は 「resource の束」 として扱うべきです──すなわち、「resource」 の文法を適用すべきです。この辺の迷いは、「黒本」 の後に出版した 「論考」 「赤本」 でも出ています。今では、「対照表」 は、当初の 「真理値表としての役割」 を拡充して、（1） (2) および （3） を配慮して、関係文法は 「resource の束」 として扱うようにしています。






　

<< もどる

HOME

すすむ >>

　

「Ｔ字形ＥＲ データベース設計技法」を読む