2006年 3月16日 対照表の 「event/resource」 化 (その 2) >> 目次 (作成日順)
  ● QUESTION   対照表は、event/resource でないとしたら、どういう文法を適用するのか。
  ▼ ANSWER   対照表は 構文論上、「resource」 の文法を適用して、意味論上、「event」 と考える。
2011年 4月 1日 補遺  



 TM は、以下の 「前提」 を導入しています。

 (1) entity に対して、意味論を適用して、以下の 2種類に類別する。
   (1)-1 event (その性質として、日付が帰属する。)
   (1)-2 resource (event 以外の entity である。)

 (2) 対照表は、resource のあいだで 「関係」 として生成する。
    aRb 上、a および b が resource であれば、R を対照表として記述する。

 (3) 対照表は、「関係」 を示す 「構成表」 である。

 
 entity は、「合意」 概念を導入して意味論的に 「event と resource」 に 類別しています。したがって、この前提に立つかぎり、「F-真」 および 「L-真」 という 「真」 概念を導入しなくても良いのですが、そういう 「真」 概念を 導入しなければならなかった理由は、対照表の性質を判断するためです。

 対照表は 「構成表」 です。「構成表」 は、以下の 2つの性質を示します。

  (1) 「過程」 としての構成 (-ing)
  (2) 「結果」 としての構成 (-ed)

 (1) は行為・現象を示して──生起する現実的な事物を示して── 「event 的」 な 性質を帯びています。したがって、性質として、「日付」 を付与することができます。 悩ましい点は、構成表の 「すべて」 が、この性質を帯びるという点です。いっぽうで、(2) は、個体 (resource) の複合概念を示すことがあります。その典型的な現象を、「赤本」 (「データベース 設計論--T字形ER」) の最終 ページ で示しました。それは、以下の例です。

  {銀行 コード (R)、支店 コード (R)、支店名称、・・・}.

 「赤本」 以前では──「黒本」 (「T字形 ER データベース 設計技法」) および 「論考」 (「論理 データベース 論考」) では──構成表に対して 「意味論上の解釈」 しか示していなかった。当然ながら、構成表を、「構文論上」、どのように解釈 すれば良いのかという点を示さなければならない。対照表 (構成表) は、以下の ように考えれば理解しやすい。

  (1) 構成表は、構文論上、「resource」 の文法を適用する。
  (2) 構成表は、意味論上、「event」 を言及する。

 (2) では、「赤本」 の最終 ページ に示したように、「resource 的」 な構成表が出るのですが、「反 コンピュータ 的断章」 (2月16日) で綴りましたが、 「resource 的」 な構成表を、「resource」 として判断するかどうかという 点は、TM の 「前提」 (実 データ および それらの セット 概念、第一階の述語論理) を 超えてしまいます。

 TM を作ったときに、この点が 私を悩ました点です。
 構成表の 「すべて」 を 「過程(-ing)」 として考えれば、構成表の 「すべて」 を 「event 的」として解釈することもできるし、構成表を 「結果(-ed)」 として 考えれば、「resource 的」 として解釈することもできるので、「日付」 が 明示 されている (あるいは、文脈のなかで、付与できる) 対象のみを 「event」 として 認知するという点で止めています。あるいは、逆に、構成表が 「組 オブジェクト」 として resource を示す性質が明示されていたら、「resource 的」 として認知することが できます。

 構成表は個体を 「言及 (refer to)」 しても 「指示 (designate)」 している訳じゃない。「合意」 概念を前提にすれば、もし、構成表のなかに 性質が記述されるのであれば──たとえば、「日付」 とか──、「意味」 を 示しますが、構成表として、性質が記述されていないとき──すなわち、 T字形表記として、右側が ブランク であるとき──、「event」 とも 「resource」 とも 解釈できるのです。

 赤本の最終 ページ で、「組 オブジェクト」 として、{銀行 コード (R)、支店 コード (R)、支店名称・・・} の 構成表を示した理由は、「関係」 が、「resource」 的性質を示すこともある点を示すためです。

 ちなみに、「対照表-対-event」 の 「複数-対-1」 関係では、興味深いことに、 それらのあいだに、なんらかの 「event」 が入って、「event」 どうしの 「複数-対-1」 に消去されるようです。たとえば、典型的な例として、以下を考えてみます。

 [ 入荷 ] (event)
 {入荷番号、商品番号 (R)、入荷日、入荷数、・・・}.

 [ 入荷. 入庫. 対応表 ]
 {入荷番号 (R)、入庫番号 (R)}.

 [ 入庫 ] (event)
 {入庫番号、倉庫番号 (R)、商品番号 (R)、入庫日、入庫数、・・・}.

 [ 在庫 ] (対照表)
 {倉庫番号 (R)、商品番号 (R)、記録日、在庫数、・・・}.

 複数の 「入荷」 を一括して、「在庫」 にします。観てのとおり、「入荷」 と対照表 は、対応表を作成しないで、「入庫」 があいだに入って、入荷と入庫のあいだで対応表が作成 されます。その逆として、以下を考えてみます。

 [ 在庫 ] (対照表)
 {倉庫番号 (R)、商品番号 (R)、記録日、在庫数、・・・}.

 [ 出庫 ] (event)
 {出庫番号、倉庫番号 (R)、商品番号 (R)、出庫日、出庫数、・・・}.

 [ 出庫. 出荷. 対応表 ]
 {出庫番号 (R)、出荷番号 (R)}.

 [ 出荷 ] (event)
 {出荷番号、商品番号 (R)、出荷日、出荷数、・・・}.

 
 ほかの例として、「配属」 を前提にした 「研修」 を考えてみます。

 [ 配属 ]
 {部門 コード (R)、従業員番号 (R)、配属日、・・・}.

 [ 研修 ]
 {研修番号、部門 コード (R)、従業員番号 (R)、研修実施日、・・・}.

 配属日の相違する──つまり、複数の配属ということですが──複数の従業員 に対して、1つの研修を実施したとします。このときも、構成表 (対照表) の (R) が 「event」 に複写されるのみで 対応表はでない。

 逆を考えてみます。
 すなわち、いくつかの研修を終えてから配属するとします。

 [ 研修 ]
 {研修番号、従業員番号 (R)、研修実施日、・・・}.

 [ 配属 ]
 {部門 コード (R)、従業員番号 (R)、配属日、・・・}.

 このときも、対応表はでない。
 どの研修と どの研修を終えたら配属されたかは、あくまで、「研修」 event のなかで示される。もし、どの研修と どの研修を終えないと配属されないと いう ルール があるのならば、「研修」 event の 「再帰」 として記述されます。

 以上の点が対照表の 「構成表」 としての特徴なのです。
 すなわち、構成表は認知番号をもたないので、構成表のなかの (R) の いちぶ──基本的に、全部──が、後続 event (あるいは、先行 event)の (R) として作用するということです。

 

 



[ 補遺 ] (2011年 4月 1日)

 取り立てて補足説明はいらないでしょう。





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