2005年 9月16日 作成 単純定義域と複合定義域 >> 目次 (テーマ ごと)
2009年10月16日 補遺  


 
 コッド 関係 モデル では、単純定義域が、「現実世界の」 個体を記述する訳ではない。

 コッド 関係 モデル では、個々の タプル (テーブル) は、まったく独立であり、「或る テーブル のなかの属性 a と、ほかの テーブル のなかの属性 b は、『現実の世界のなかで』 同じ エンティティ に帰属する」 という情報は、データ 構造のなかには、記述されていない。そういう情報は、「テーブル に対する演算操作」 としてしか示すことができない。つまり、複数の タプル にまたがる属性を合成して、情報を作るしかない。その合成の鍵が、reference-key であり、演算操作の join である。たとえば、書物という モノ に対して、以下の テーブル がある、とする。

  書物 テーブル {書物番号、書物名称、出版年度、作者 コード (R)}.
  作者 テーブル {作者 コード、作者名}.

 
 データ 構造としての書物 テーブル は、「現実の世界のなかの entity」 ではない。
 データ 構造としての書物 テーブル は、「現実の書物」 を記述してはいない。したがって、「現実の書物」 を記述しようとすれば──現実の書物の情報を得ようとすれば──、作者 コード を使って、2つの テーブル を合成して、以下の テーブル を作らなければならない。

  {書物名称、作者名称、出版年度}.

 
 論点を際立たせるために、作者は、以下のように、2人の共著とする。

  {書物名称、{作者名称、作者名称}、出版年度}.

 
 コッド 正規形では、{作者名称、作者名称} という 「(複合構成的な) 集合 オブジェクト」 は、(atomic な定義域ではないので、) 繰返項目とされるので、上述した タプル は、非正規形である。

 さて、論点は、上述した タプル は、「現実世界の」 個体を指示していて、かつ、それは、過去に生起した事実であり、かつ、その事実は、そのまま、持続されるので、(データ 入力の単純な ミス を除けば、) データ は変更の対象にはならないし、過去に生起した現実的な事実および持続する現実的な事物は、そのままの状態として、データベース のなかに実装すればよいのではないか、という点である。 この点が、記述的意味論と、(構文論を前提とした) 論理的意味論が、「構造」 を作る際に、相違点となる。

 さらに、(構文論を前提とした) 論理的意味論でも、{作者名称、作者名称} を、繰返項目として扱うか、あるいは、「集合 オブジェクト」 (対照表)として扱うか、という点は、解釈上、相違がでるかもしれない──なお、{作者名称、作者名称}として指示される 「共著」 は、自己言及の再帰ではない。

 TM は、データ 設計法である。認知の 「同意」 として、コード 体系を、まず、前提にして、データ 構造を設計するので、(構文論を前提にした) 論理的意味論の立場を採用している。したがって、TM は、記述的意味論のように、以下の 「(現実的な) 事実」 を、そのまま、データ 構造として記述することはしない。

  {書物名称、{作者名称、作者名称}、出版年度}.

 
 TM では、以下の構造となる。

  書物 {書物番号、書物名称、出版年度}.

  作者 {作者コード、作者名}.

  書籍. 作者. 対照表 {書物番号 (R)、作者コード (R)}.

 
 したがって、もし、{書物番号 (R)、作者 コード (R)} が、1件の データ であれば、単独の作者であるし、2件以上であれば、「共著」 である。対照表を観ても、或る 1冊の書物が 「共著」 であるかどうか、という点は、「構造」 では判断できない、という弱点がある──「値」 を入手しなければ、判断できない、という弱点がある。対照表では、作者 コード の値は、「少なくとも 1つ」という構成になっている。そして、それは、コッド 関係 モデルの 「繰返項目の除去」 でも、同じ弱点となる。

 
 たとえば、作者 コード が、書物番号に対して、少なくとも、1つ以上の値が対応するのであれば、以下の構造となる。

  {書物番号、書物名称、出版年度}.
  {書物番号、作者 コード}.

 
 この構造では、やはり、作者が、単独執筆なのか、共著なのか、という点を、構造のみを観て判断できない。
 かりに、以下のように、単独作者と共著を、べつべつの テーブル として作った、とする。

  {書物番号、作者 コード、書物名称、出版年度}.

  {書物番号、書物名称、出版年度}.
  {書物番号、作者 コード}.

 
 しかし、「同一 キー 構成」の タプル は、同じ タプル として統合しなければならない。
 とすれば、やはり、以下の構成となる。

  {書物番号、書物名称、出版年度}.
  {書物番号、作者 コード}.

 
 あるいは、「意味論的に」、「書物」 に対して、「単独作者」 と 「共著」 として、それぞれ、サブタイプ にするかもしれない。
 あるいは、オブジェクト 指向的に、以下のように考えてもよい。

  {書物名称、作者名称、出版年度}.
  {書物名称、{作者名称、作者名称}、出版年度}.

 
 上述した それぞれを、「単独作者の書物」 クラス と 「共著の書物」 クラス として、上位 クラス として、書物 クラス を作っても──「現実の事実」 を記述すると言っても──配列の数を、すべて、対応するのが むずかしいので、(書物と作者のあいだに) 関連 クラス を作って、「対照表」 の構造にするはずである──あるいは、コッド 正規形の 「繰返項目」 除去を使うかもしれない。

 さて、「書物」が、データ 構造として、「単独作者」 あるいは 「共著」 とされたのは、コッド 関係 モデル では、構文論的に、「関数従属性 (one-to-one correspondence)」 に従ったのであって、「意味」 は、構造のなかで、正当に示されている。したがって、たとえば、「書物」 に対して、意味論的に、サブセット を生成して、「単独作者」 と 「共著」 として、切り離すことは、管理上の目的であって、そういうふうな サブセット を作らなければならない 「意味」 は、「書物」 そのものにはない──「現実の書物」 と 「記号の書物」 とのあいだに成立する指示関係はない。

 われわれは、「現実の事実」 を、そのまま、記述する訳ではない──そもそも、それはできない。というのは、「視点」 が関与するから。そして、その 「視点」 というのは、モデル を作る人の 「視野」 ではなくて、「(構造を作る) 文法」 なのである。小生が、記述的意味論を嫌う理由は、「視野」 が提示されても、「文法」 が提示されていない点にある。



[ 補遺 ] (2009年10月16日)

 本 エッセー を (4年後に) 読み返してみて、グダグダ・ダラダラ と綴られている中身が どういうことの説明なのかが 私は直ぐには飲み込めなかった (苦笑)──本 エッセー を読まれた人たちも同じ感を抱かれたのではないかしら、、、申し訳ない。

 本 エッセー は、(執筆当時に、) たぶん、「複合定義域」 としての 「共著」 を TM で いかに構成するかを検討したかったのだと想像します。そうだとしたら、TM の性質を以下のように簡明に説明したほうが良かったと思います。

   自然言語で記述された文に対して 「形式的構成」 を与える。

 「形式的構成」 を与える限りにおいて、モデル は 「文法 (生成規則)」 を持っていなければならない。そして、その 「文法」 では、「共著」 は 「再帰」 として構成される──すなわち、1つの集合 (「作者」 の集合) から 2つ以上の メンバー を選んで並べるというふうに構成される──、と簡明に説明したほうが良かったでしょうね。モデルは、以下の 2つの規則を持っていなければならない。

 (1) 「妥当な構造」 を作る生成規則
 (2) 「真とされる値」 を実現する指示規則

 「共著」 かどうかは、(2) の規則において、「充足される値」──しかも、「事実」 と対比して 「真とされる値」──で判断される事態です。すなわち、{書物番号、作者 コード} の値が 2つ (以上) 充足されたならば 「共著」 であるということ──もし、「共著」 のなかで、「責任編集」 などの役割があって、作者たちの 「並び」 が重視されるのであれば、なんらかの 「種別 コード」 が導入されるでしょう [{書物番号、作者 コード、作者 種別 コード}]。

 さらに、もし、「共著」 の書物と それ以外の書物を意識して管理するのであれば、1つの集合を切断するための 「区分 コード」 が導入されるかもしれない──たとえば、「共著 区分コード」 とか。逆に謂えば、そういう 「区分 コード」 が導入されていないのなら、「共著」 の書物と それ以外の書物という管理形態が導入されておらず、作者が複数 (2名以上) であれば 「共著」 であるという 「事実」 のみが記述されていると判断していいでしょう。





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