2004年 3月 1日 | 「resource : event = 複数 : 複数」 の関係 | >> 目次 (テーマ ごと) |
● QUESTION | 推論 ルール のなかで、「resource : event = 複数 : 複数」 がないのは、どうしてか。 | |
▼ ANSWER | 言語の形態論では、特殊形態として扱う。一律の ルール が適用できない。 | |
2009年 3月16日 補遺 |
● 4つの推論 ルール T字形 ER手法の推論 ルール は、以下の 4つである。
(1) resource : resource 関係の論理 (aRb) では、a および b は個体として扱う。つまり、a および b は、entity である。個体 (a および b) の間に成立する作用を、関連 (relationship) として扱うか、関係 (関数、relation) として扱うか、という点は、モデル を作る際、1つの前提となる。T字形 ER手法は、R (relation) を関数として扱わないで、関連として扱う公理系である。 ただし、T字形 ER手法では、entity として、以下の 2つを サブセット にしている。
(1) 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」 では、関係 R が entity (event) として扱われるので、「1:複数」 関係であれば、resource の認知番号を event のなかに複写すればよい (153ページ 参照)。さて、論点になるが、「resource : event」 の 「複数:複数」 関係である。「resource : event = 複数:1」 関係は、「複数:複数」 関係の特殊形であるので──というのは、event が 1回切りしかない、という現象なので──、「複数:複数」関係について考えればよい。
(1) 多義 (ただし、多義は、対照表のなかで除かれる) まず、多義として──ただし、多義は、対照表のなかで排除されているが──、以下の例がある。
- 営業活動のなかで、「訪問」 (event) を記録している。 1つの顧客に対して複数の訪問が起こり、1つの顧客を複数の従業員が担当するが、「訪問」 する従業員は 1人である。言い換えれば、1つの 「訪問」 に対して、複数の従業員が 「多義」 になっているが、「多義」 は、対照表 (顧客. 従業員. 対照表) を仲立ちにして排除されている。データ 構造は、以下になる。
顧客
従業員
顧客. 従業員. 対照表
訪問 次ぎに、複数の resrouce を 1つの event のなかで扱う形態として、以下の例がある。
- 営業活動のなかで、「訪問」 (event) を記録している。 データ 構造は、以下になる。
訪問
訪問. 従業員
従業員
ちなみに、2つの従業員番号は 「多義」 ではない──どれか 1つしか成立しない、ということではない。 「再帰」 の形態として、以下の例がある。
- 営業活動のなかで、「訪問」 (event) を記録している。 データ 構造は、以下になる。
訪問
従業員
従業員. 従業員. 再帰 「HDR-DTL」 の形態になる例としては、たとえば、1つの受注のなかで、複数の商品が扱われ、1つの商品は複数の受注のなかで扱われる、という形態である。この形態に関する詳細な注釈は、85ページ を参照されたい。
顧客
商品
受注 HDR
受注 DTL
出荷 以上に述べてきたように、「resource : event」 の関係は、モデル (推論ルール) のなかでは、resource の認知番号を event のなかに複写する、という点は 「同じ ルール」 が適用できるが、resource が複数となるなら、resource の 「意味」 を判断して、多義・並列・再帰・HDR-DTL のいずれかの形態を作らなければならない。そして、多義・並列・再帰・HDR-DTL の 「選択」 は、「意味」 の判断が前提になっているので、1つの (一律の) 推論 ルール として提示することができない。
コッド 正規形は、以下の 2つの従属性 (dependency) を前提にしている。
つまり、数理 モデル では、従属性を 「制約」 として使って 「意味」 を記述する。包含従属性 (A ⊃ B) というのは、「A の テーブル のなかの キー 値は、B の テーブル のなかにも記述される」ということである。関数従属性というのは、タプル のなかで、或る属性値に対して、ほかの属性値が 「高々」 1つ──ゼロ でもよい──しかない、ということである。関数従属性を前提にして提示された テーブル 割り (decomposition) が 「第 3正規形」 である。
さらに、「多値従属性 (multivalued dependency)」 を考慮して提示されたのが 「第 4正規形」 である。
また、「結合従属性 (join dependency)」 を考慮して提示されたのが 「第 5正規形」である。
本文の例では、2人が組になっているのだから、意味論上、「訪問」 を以下のように記述するかもしれない。
{訪問番号、顧客番号 (R)、従業員番号 (R)、従業員番号 (R)、訪問日、・・・}
しかし、構文論上、従業員番号を 「繰返項目」 と扱って、以下のように記述するかもしれない。
{訪問番号、顧客番号 (R)、訪問日、・・・}
もし、訪問番号が、一意の値を付与されているなら、以下のように記述するかもしれない。
{訪問番号、顧客番号 (R)、訪問日、・・・}
ただし、以下の 2つの意味は、べつべつの記述である。
(1) 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 |