2001年 9月30日 「対照表」 の区別 >> 目次 (テーマごと)
  ● QUESTION   「event」 系の対照表と 「validation-rule」 系の対照表を区別する判断基準は、なにか。
  ▼ ANSWER   「DATE (取引日)」 を使えばよい。
2006年11月 1日 補遺  




 「DATE (取引日)」 を使えばよい。
 「event」 系の対照表は、「性質 (アトリビュート)」として、「DATE」 を帰属することができる。
 「性質」 として 「DATE」 を仮想することができる対照表は、「疑似 event (quasi-event)」 である。
 しかし、「validation-rule」 系の対照表は、「DATE (取引日)」 を仮想することができない。

 
▼ 具体例 [ 拙著 「論理 データベース 論考」 191ページ 参照。]

 
 以下の 2つの「resource」を使う。

 (1) 顧客 {顧客番号、名称,...}.
 (2) 製品 {製品コード、名称,...}.

 以上の 2つの 「resource」 を組とした--ただし、unordered な--以下の対照表を生成することができる。
 {顧客番号 (R)、製品コード (R)}.

 この対照表の 「性質 (アトリビュート)」 として 「DATE (取引日 )」 を仮想すれば、「受注」 という 「event」 が成立する。
  {顧客番号 (R)、製品コード (R)、DATE (受注日)}.

 したがって、この対照表は 「event」 系の対照表である

 次に、以下の 3つの 「entity」 (2つの 「resource」 と 1つの 「event」) を考えてみる。

 (1) 顧客 {顧客番号、名称,...}.
 (2) 製品 {製品コード、名称,...}.
 (3) 受注 {受注番号、 顧客番号 (R)、製品コード (R)、受注日、受注数}

 「顧客」 と 「製品」 を組とした--ただし、unordered な--以下の対照表を生成することができる。
 {顧客番号 (R)、製品コード (R)}.

 この対照表の 「性質 (アトリビュート)」 として 「DATE (取引日)」 を仮想すれば、「受注」 という 「event」 が成立する。しかし、「受注」 は既に成立している。とすれば、この対照表の性質として 「DATE」 を仮想することができない。たとえば、顧客ごとに受注される製品が制約されているのなら、「顧客」 と 「製品」 の間には、コンビネーション (構成) が成立する。とすれば、その (対応関係の) 構成から外れた製品の受注があれば、accept してはいけない。この対応関係の validation は、アルゴリズム のなかで扱うこととされてきた。しかし、この対応関係を対照表の形として--つまり、データ 構造として--記述しておけば、アルゴリズム を記述しなくてもよい (対応関係の検証は、一回の I/O で済む)。

 ちなみに、アルゴリズム を記述するとしても、アルゴリズム のなかで、この対応関係の internal-table を用意しなければならない。とすれば、この対応関係を データ 構造として用意しておけば、プログラム の ステップ 数は少なくなるし 、プログラム の生産性は高くなる。

 この対照表は、(データ に帰属する ルール を記述した) 「真理値表」 として機能している。すなわち、3つの entity (顧客、製品、受注) という実 データ を コントロール する 「メタ・データ」 である。したがって、「メタ・データ」 は (述語論理の観点からすれば、) 「関数」 として扱うこととされている。いっぽう、データ指向 (Data-Oriented) の観点からすれば、データ に帰属する対応関係 (データ に帰属する ルール)は、そもそも、DD (Data Dictionary) が扱うべきなのであるが、現時点では、そういう対応関係の ルール を記述できる精巧な DD は マーケ ット にはない。

 とすれば、データ 間の対応関係を記述する 「メタ・データ」 は、実 データ といっしょに 「実装する」 ほうがよい。「event」 系の対照表は、(命題論理の観点からすれば) 「実装しなければならない」 (a must の) table であるが、「validation-rule」 系の対照表は、「実装してもいいし、実装しなくてもよい」 (実装しなければ、アルゴリズム のなかで扱うことになる)。ただ、実装したほうが、アルゴリズム の負荷が軽減される、ということである。

 



[ 補遺 ] (2006年11月 1日)

 カルナップ 氏によれば、論理的意味論は、以下の規則を提示していなければならない。

  (1) 指示規則 (記述的定項--個体と述語--を定義する).
  (2) 生成規則 (許された文の形式を定義する).
  (3) 真理性 (「真」 を定義する).
  (4) 範囲規則 (与えられた文が成立する状態記述--真/偽--の集合を定義する).

 「関係の論理 R (a, b)」 において、R (Relation) は、個体 a と個体 b のあいだに成立する 「関係」 である。もし、個体 a および 個体 b が 「resource」 であれば、関係 R は、指示規則 上、基本的に、「event」 を示す。言い換えれば、R (a, b) は、一つの事態 (occasion、event) であって、その事態に個体が関与していることを示している。
 そして、一つの事態 (event) には、性質として、(事態が生じた) 「日付」 が帰属する。

 「基本的に」 と綴ったように、R (a, b) は、「event」 という事態のほかを示すことがある。すなわち、「真」 とされる集合 (範囲規則) を示すことがある。これが、TM 上、いわゆる 「validation-rule」 の対照表として記述される。

 データベース・パラダイム の観点で言えば、以上の 4つの規則は、すべて、Data Dictionary のなかに記述されていなければならない。しかし、それを実現できる Data Dictionary は、遺憾ながら、マーケット にはないのが現状である。したがって、TM では、範囲規則を対照表として示して、実 データ といっしょに データベース のなかに実装しているにすぎない。




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