2005年 9月16日 参照キーと (R) >> 目次 (作成日順)
  ● QUESTION   (R) を参照キーと云わないのは、どうしてか。
  ▼ ANSWER   (R) が複合定義域 (非正規形) を作ることがあるから。
2010年10月 1日 補遺  



 (R) は、「黒本」 では、参照 キー (Reference-key) の略語として使っていた。しかし、「論考」 では、参照 キー と云うことを止めて、「Re-uesed」 の略語として使うようになった。

 T字形 ER手法は、当初、コッド 関係 モデル を起点にして作られた。データ・モデル は、{データ 構造、データ 演算、integrity 制約} を組とした構成をいう。したがって、T字形 ER手法は、正確に言えば、データ・モデル ではない──というのは、データ 代数演算の構造を示していないから。

 T字形 ER手法は、コッド 関係 モデル のいくつかの前提に対して、それらとは違う 「解釈」 を導入した体系である。違う 「解釈」 というのは、以下の諸点である。

 (1) Null を認めない。
 (2) 関係のなかで、対称性・非対称性を、つよく適用する。
 (3) Entity のほかに、構成表 (集合 オブジェクト、組 オブジェクト) を導入する。

 (2) として、「event」 概念および 「resource」 概念を導入した。そして、2つの 「resource」 のあいだに成立する関係には、(3) として、対照表を導入した。

 対照表は、(もし、対照表に帰属する データ 項目が存在しないし、かつ、「resource」 のあいだに成立する関連が 「1対1」であるならば、) 構文論的に、コッド 関係 モデル の用語法に従えば、参照 キー のみから構成される テーブル である。そして、それは、「非正規形」 である。

 ただし、対照表は、意味論的に解釈すれば、「resource」 のあいだに成立する 「できごと (event)」 を指示することが 「できる」。TM の定義によって、対照表のなかに、もし、配属日を定義すれば、対照表は、「配属」 という 「event」 を指示する。つまり、事実的な 「F-真」 を示す。したがって、対照表は、構文論的には、コッド 正規形の用語法に従えば、部門 コード (参照 キー) の セット と従業員番号 (参照キー) の セット を使って構成される複合定義域 (非正規形) であるが、意味論的には、「F-真」 を示す個体概念 (集合の集合) として考えることができる。

 対照表が 「event」 を指示する (designate) ことが 「できる」 ということは、認知番号を付与することが 「できる」 ということである。とすれば、対照表を構成している部門 コード (R)・従業員番号 (R) は、意味論的には、「できごと」 に対して、関与している個体を言及している (refer to)。パース 氏の用語法を使えば、対照表は、「2項関係が 3項態を示している」 状態である。

 T字形 ER手法は、TM として整えられる過程のなかで、関係主義を離れて、実体主義的な前提を導入した。関係主義のなかで、包摂従属性を示す参照 キー を、実体主義のなかで、しかも、(関係主義的に観れば、) 「非正規形」 のなかで、参照 キー という用語を使うことはできない。構文論的には、(R) は、TM の文法に従って、複写されたにすぎない──意味論的には、「関与」 を示しているが。

 以上に述べた諸点を考慮して、(R) を参照 キー (Reference-key) と云うことを止めて、「Re-used」 の略語にすぎない、と変更した次第である。

 



[ 補遺 ] (2010年10月 1日)

 コッド 関係 モデル は、「Relational Completeness」 が証明されている代数系であって、チューリング 賞を受賞した理論です。その理論 (の公理・定理) について、私のような数ならぬ エンジニア が どうこう論駁できるはずもないのであって、私が コッド 正規形を実務上適用するときに、「不便だった」 と実感した点を使いやすいようにするために施した点が本 エッセー のなかで述べた 3点なのです。ただ、そういうふうな施しをしたがために、TM は、「関係主義と実体主義」 「構文論と意味論」 の境界を跨 (また) いでしまった。その典型的な現象が、TM において、「entity」 概念と 「セット」 概念 (および、「クラス」 概念) を混和しなければならなかった次第です。すなわち、TM では、まず、「個体指定子」 を付与された管理対象を 「entity」 として認知して、次に、「entity」 が 「セット」 概念と一致するかどうかを検証する、という手続きにしなければならなかった次第です。そして、構文論であるべき関係文法のなかで、意味論 (「event」 概念と 「resource」概念) を意識しなければならなかった──勿論、「event」 を 「全順序」 の関数として扱い、「resource」 を 「半順序」 の関数として扱うことはできるのですが [ 構文論として純粋に扱うことができるのですが ]、「event-対-resource」 の文法は、数学的構文論では説明し切れない。この混和 (「関係主義と実体主義」 の混和、および 「構文論と意味論」 の混和) は、数学上、認められない──ラッセル 氏の 「タイプ 理論」 が、当初、構文論と意味論の ふたつを扱っていたけれど、その後、数学者たちによって、構文論のみに限った 「単純 タイプ 理論」 として使われるようになったことを私は承知しています。

 ただ、たとえ、正規形の構成を構文論のみに限ったとしても、そして、構文論のなかに意味論を混和するのは邪道だと詰問する人たちにたいして、私が問題にしたい点は、たとえば、以下の措置を いかにして説明してくれるのか、という点です。

 (1) 「商品」 と 「受注」 とのあいだに写像がある。

 (2) f: 商品 → 受注. [ 全射 ]

 (3) g: 受注 → 商品. [ 全射 ]

 このときに、f (x) = y あるいは g (y) = x という ふたつの関数のいずれを使うのか、そして、いずれを使うかの判断は どのような理由で正当化されるのか、という点です。あるいは、もっと正確に謂えば、以下の 「直積」 を構成する判断は どのような理由で正当化されているのか、という点です──{ 受注番号、顧客番号、商品番号、受注日、受注数 } という 「直積」 において、「受注と顧客」 および 「受注と商品」 は、「one-header-many-details」 の多値関数とします。

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

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

 単純に謂えば、どうして、「受注」 を構成するときに、「商品」 を従属関数として扱うのか、という点です。「『商品』 が 『受注』 に関与する」 という 「(意味論的な) 解釈」 がなければ、「受注」 を構成できない──「商品」 を従属関数として扱うことができない──でしょう。もし、「構文論のなかに、意味論を混和してはいけない」 というのであれば、「そんなことは常識だ」 などと謂えないでしょう。ほんとうに 「常識だ」 と思ったならば、「event-対-resource」 の文法を非難できないでしょう。コッド 正規形をわかったつもりでいる連中は、はたして、コッド 氏が前提として置いた 「個体は記号化されている」 ということが、どれほど 「自明であるが故に困難である」 ことなのか実感しているのかしら。この困難は、「実務家 (practitioner)」 が コッド 正規形を実地に適用するときに実感するはずです。TM は、それにこだわっただけです。





  << もどる HOME すすむ >>
  データ解析に関するFAQ