2007年 7月 1日 特論-12 T字形 ER手法 (その 2) [ 対照表の根拠 ] >> 目次に もどる
2012年 6月 1日 補遺  


 前回 述べたように、entity を定立したあとで、私が考えた点は、「論理哲学論考」 で示された 「真理値表」 を 「データ 構造を作る (すなわち、「事実」 を写す) 像」 にするという点でした。言い換えれば、コッド 関係 モデル の射影を 「真理値表」 で記述するということでした。たとえば、2つの entity { E1, E2 } があったとして、それらが関与して起こる 「事態」 を { (T, T) (T, F) (F,T) (F, F) } という形式で記述しようと考えました。 したがって、いまでは TM (T字形 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 が起こるので サブセット 化すること) として、以下のように記述されます。

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

 
 「対照表」 は、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) } として、しかじかの取引先では かくかくの商品を扱っているなど。

 当初 (T字形 ER法を考えはじめた頃)、「対照表」 は真理値表として使うことを考えていたのですが──すなわち、(3) の使いかたを想定していたのですが──、「T之字」 記法で 「対照表」 を記述するときに、右側 (アトリビュートの記述) が論点になった。すなわち、「対照表」 の アトリビュート として 「日付」 を仮想すれば、あるいは、「日付」 の データ が実存すれば、「対照表」 は (T字形 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 すすむ >>
  「T字形ER データベース設計技法」を読む