2004年 3月 1日 「resource : event = 複数 : 複数」 の関係 >> 目次 (テーマ ごと)
  ● QUESTION   推論 ルール のなかで、「resource : event = 複数 : 複数」 がないのは、どうしてか。
  ▼ ANSWER   言語の形態論では、特殊形態として扱う。一律の ルール が適用できない。
2009年 3月16日 補遺  



4つの推論 ルール

 T字形 ER手法の推論 ルール は、以下の 4つである。

 (1) resource : resource
 (2) resource : event
 (3) event : event
 (4) 再帰 (recursive)

 関係の論理 (aRb) では、a および b は個体として扱う。つまり、a および b は、entity である。個体 (a および b) の間に成立する作用を、関連 (relationship) として扱うか、関係 (関数、relation) として扱うか、という点は、モデル を作る際、1つの前提となる。T字形 ER手法は、R (relation) を関数として扱わないで、関連として扱う公理系である。

 ただし、T字形 ER手法では、entity として、以下の 2つを サブセット にしている。

 (1) event (時系列のなかで並べられる データ)
 (2) resource (event 以外の entity)

 
「複数 : 複数」 の関係、「resource : resource」 と 「event : event」

 aRb では、a および b が resource (個体) であり、R は event (作用) である、というのが基本形である。しかし、T字形 ER手法では、entity の定義──認知番号が付与されていること──を満たせば、R も entity として扱われる。

 「resource : resource」 は、リレーションシップ の タイプ (「1:1」、「1:複数」、「複数:1」、「複数:複数」) が、いずれであれ、対照表を作る。なぜなら、T字形 ER手法は、関係の論理 (aRb) を 「関数」 として扱わないで、命題論理を使って、R を真理値表として扱うから。

 「event : event」 では、event は、時系列のなかで並べられるから、先行する event の認知番号を 後方の event に複写する。ただし、リレーションシップ・タイプ が 「複数:1」 (あるいは、「複数:複数」) であれば、先行する複数の event が後方の 1つの event に対して 「多価」 対応になるので、「一価」 対応に変換するために、対応表を作る。

 
「複数 : 複数」 の関係、「resource : event」

 「resource : event」 では、関係 R が entity (event) として扱われるので、「1:複数」 関係であれば、resource の認知番号を event のなかに複写すればよい (153ページ 参照)。さて、論点になるが、「resource : event」 の 「複数:複数」 関係である。「resource : event = 複数:1」 関係は、「複数:複数」 関係の特殊形であるので──というのは、event が 1回切りしかない、という現象なので──、「複数:複数」関係について考えればよい。
 「複数:複数」関係は、以下の 4つの形態のいずれかになる。

 (1) 多義 (ただし、多義は、対照表のなかで除かれる)
 (2) 並列 (1つの event のなかで、複数の resource の組が 1つの意味を記述する。)
 (3) 再帰
 (4) HDR-DTL

 
多義の現象

 まず、多義として──ただし、多義は、対照表のなかで排除されているが──、以下の例がある。

 - 営業活動のなかで、「訪問」 (event) を記録している。
 - 1つの顧客に対して、複数の従業員が担当している。
 - ただし、1つの「訪問」では、1人の従業員が出向く。

 1つの顧客に対して複数の訪問が起こり、1つの顧客を複数の従業員が担当するが、「訪問」 する従業員は 1人である。言い換えれば、1つの 「訪問」 に対して、複数の従業員が 「多義」 になっているが、「多義」 は、対照表 (顧客. 従業員. 対照表) を仲立ちにして排除されている。データ 構造は、以下になる。

 顧客
{顧客番号、顧客名称、・・・}

 従業員
{従業員番号、従業員名称、・・・}

 顧客. 従業員. 対照表
{顧客番号 (R)、従業員番号 (R)}

 訪問
{訪問番号、顧客番号 (R)、従業員番号 (R)、訪問日、・・・}

 
並列の現象

 次ぎに、複数の resrouce を 1つの event のなかで扱う形態として、以下の例がある。

 - 営業活動のなかで、「訪問」 (event) を記録している。
 - 1つの 「訪問」 では、2人の従業員がいっしょに出向いている。
 - 2人の従業員の組 (a pair) には、誰が誰と組む、という ルール はない

 データ 構造は、以下になる。

 訪問
{訪問番号、顧客番号 (R)、訪問日、・・・}

 訪問. 従業員
{訪問番号、従業員番号 (R)}

 従業員
{従業員番号、従業員名称、・・・}

 ちなみに、2つの従業員番号は 「多義」 ではない──どれか 1つしか成立しない、ということではない。
 したがって、「訪問. 従業員」 のなかでは、「並び (関係)」 は論点にならない (種別 コードは付加されない)。(注意)

 
再帰の現象

 「再帰」 の形態として、以下の例がある。

 - 営業活動のなかで、「訪問」 (event) を記録している。
 - 1つの 「訪問」 では、2人の従業員がいっしょに出向いている。
 - 2人の従業員の組 (a pair) には、誰が誰と組む、という ルール がある。たとえば、mentor 制とか。

 データ 構造は、以下になる。

 訪問
{訪問番号、顧客番号 (R)、従業員番号 (R)、訪問日、・・・}

 従業員
{従業員番号、従業員名称、・・・}

 従業員. 従業員. 再帰
{従業員番号 (R)、従業員番号 (R)、・・・}

 
HDR-DTL の現象

 「HDR-DTL」 の形態になる例としては、たとえば、1つの受注のなかで、複数の商品が扱われ、1つの商品は複数の受注のなかで扱われる、という形態である。この形態に関する詳細な注釈は、85ページ を参照されたい。

 顧客
{顧客番号、顧客名称、・・・}

 商品
{商品番号、商品名称、・・・}

 受注 HDR
{受注番号、顧客番号 (R)、受注日、・・・}

 受注 DTL
{受注番号、明細行番号、商品番号 (R)、受注数、・・・}

 出荷
{出荷番号、受注番号 (R)、明細行番号 (R)、出荷日、・・・}

 
「resource : event = 複数 : 複数」 の関係は、単純な推論 ルール では判断できない。

 以上に述べてきたように、「resource : event」 の関係は、モデル (推論ルール) のなかでは、resource の認知番号を event のなかに複写する、という点は 「同じ ルール」 が適用できるが、resource が複数となるなら、resource の 「意味」 を判断して、多義・並列・再帰・HDR-DTL のいずれかの形態を作らなければならない。そして、多義・並列・再帰・HDR-DTL の 「選択」 は、「意味」 の判断が前提になっているので、1つの (一律の) 推論 ルール として提示することができない。

 
[ 注意 ]

 コッド 正規形は、以下の 2つの従属性 (dependency) を前提にしている。
 (1) 包含従属性
 (2) 関数従属性

 つまり、数理 モデル では、従属性を 「制約」 として使って 「意味」 を記述する。包含従属性 (A ⊃ B) というのは、「A の テーブル のなかの キー 値は、B の テーブル のなかにも記述される」ということである。関数従属性というのは、タプル のなかで、或る属性値に対して、ほかの属性値が 「高々」 1つ──ゼロ でもよい──しかない、ということである。関数従属性を前提にして提示された テーブル 割り (decomposition) が 「第 3正規形」 である。

 さらに、「多値従属性 (multivalued dependency)」 を考慮して提示されたのが 「第 4正規形」 である。
 多値従属性は、1つの値に対して、「1つ以上の」 値が対応する。ファギン (Fagin, R.) が提示した。したがって、「高々」 1つの対応である関数従属性は、「1つ以上の」 値の従属性のなかの 「特殊な」 形である、と思ってよい。

 また、「結合従属性 (join dependency)」 を考慮して提示されたのが 「第 5正規形」である。
 結合従属性は、「多値従属性」 のなかで、連言 (and) が成立する現象だと思ってよい。ウルマン (Ulmann, J.)が提示した。この従属性が、本稿で扱った 「並列」 である。

 本文の例では、2人が組になっているのだから、意味論上、「訪問」 を以下のように記述するかもしれない。

   {訪問番号、顧客番号 (R)、従業員番号 (R)、従業員番号 (R)、訪問日、・・・}

 しかし、構文論上、従業員番号を 「繰返項目」 と扱って、以下のように記述するかもしれない。

   {訪問番号、顧客番号 (R)、訪問日、・・・}
   {訪問番号、顧客番号 (R)、従業員番号 (R)、・・・}

 もし、訪問番号が、一意の値を付与されているなら、以下のように記述するかもしれない。

   {訪問番号、顧客番号 (R)、訪問日、・・・}
   {訪問番号、従業員番号 (R)、・・・}

 ただし、以下の 2つの意味は、べつべつの記述である。

 (1) 1人の従業員が複数の訪問をおこなう、という事態
 (2) 1回の訪問では、複数の従業員から構成される、という事態

 端的に言えば、複数の従業員構成 {従業員番号 (R)、従業員番号 (R)}は、組番号を付与しても良い。
 つまり、従業員の組編成と、従業員の訪問は、べつの「意味」である。
 この点に関しては、後日、再度、論点として取り扱う。
 

 



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

 私は、「resource-event」 の関係が 「複数-対-複数」 という現象に 7年間も悩まされていました──7年間のあいだ、的確な説明ができなかった [ 関係文法のなかで整合的に説明できなかった ]。というのは、その現象は、構文論上、「合成関数」 として扱えば、なんら齟齬はないのですが、意味論上、「合成関数」 を ひとつの entity として認知する文法がT字形 ER手法のなかになかったので、その現象を整合的に扱えなかったという次第です──この悩みは、「黒本」 (1998年) で明らかにして、「論考」 (2000年) で 「合成関数」 であることに気づいて、「赤本」 (2005年) で 「合成関数」 を entity として認知するために (セット 概念のほかに) クラス 概念を導入しました、という道程を歩んできました。

 このような苦労をしてきた理由は、T字形 ER手法が セット 概念を前提にして entity を考えていたがゆえに、「合成関数」 を なんとか 「相違の サブセット」 (あるいは、それに準ずる形式) で扱おうとしていたからです。ちなみに、「『関係』 が、そのまま、『個体』 になる」 という事態が──すなわち、「resource-event」 の関係が 「複数-対-複数」 のなかで起こる HDR-DTL 構成のことが──命題論理では説明できないことは 「黒本」 のなかで認めていました。ただ、その現象を 「合成関数」 として説明したほうが妥当であることに気づいたのは、「論考」 を執筆していたときでした。「合成関数」 として扱えばいいことに気づいたことは気づいたのですが、「resource-event = 複数-対-複数」 が、事業過程・管理過程を対象にした データ 構造では必ずしも つねに HDR-DTL になると限らないことにも気づきました。本 エッセー では、「resource-event = 複数-対-複数」 が必ずしも HDR-DTL にならない例を検討しています。そして、この検討が 「赤本」 に流用されました (「赤本」 166ページ - 169ページ)。





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