2005年 7月16日 2項関係 と 3項態 >> 目次 (テーマ ごと)
  ● QUESTION   「構成」 は、「L-真」 なので、実装しないのではないか。
  ▼ ANSWER   実装することが多い。
2010年 8月 1日 補遺  



 たとえば、以下を考えてみる。

 (1) 工程番号を認知番号にして、「工程」 entity が認知されている。
 (2) 「工程」 entity の データ (instance) を使って、工程の構成を作る。

 
 さて、この事象は、以下に記述するように、いわゆる 「再帰 (recursive)」 を使って記述される 「構成」 である。

 ┌─────────────────┐     ┌─────────────────┐
 │       工 程      R│     │    工程. 工程. 再帰表    │
 ├────────┬────────┤     ├────────┬────────┤
 │工程番号    │工程名称    │     │工程番号(R) │        │
 │        │        ├┼─○─<│工程番号(R) │        |
 │        │        │  │  │        │        │
 │        │        ├──┘  │        │        │
 │        │        │     │         │        │
 └────────┴────────┘     └────────┴────────┘

 
 再帰表は、(「F-真」 を示す) 「工程」 entity を基礎にして導出された (「L-真」 を示す) 「構成」 である。第 1階の述語では、「構成」 は、あくまで、「L-真」 にすぎない。しかし、階を、ひとつ、上位にすれば──第 2階から観れば──、「構成」 を、1つの 「もの」 として考えることができる。すなわち、この 「構成」 を、「一者」 として、考えることはできる。すなわち、個々の工程を組んだ 「構成表」 を、1つの 「対象」 として考えることができる。言い換えれば、1つの 「もの (「構成」 を使って記述された事態)」 を、2項関係として、記述したのが、再帰表である。

 分析段階で使われる ER手法では、再帰は、「構成」 を (データ 構造として、) 記述しないで、自己言及であることを示す矢線を使って記述するのが、ふつうである。なぜなら、その 「構成」 は、「帰納的関数」 を意味しているから──すなわち、「関数」 であって、「変項 (パラメータ)」 ではない、ということ。

 しかし、いっぽうで、「工程」 の データ を使って、工程の構成を示す 「情報」 が示されている。この 「情報」 を 「L-真」 として、データ を組んで作る、と考えるか、それとも、「構成」 そのものが意識されている──ただし、「構成」 に対して認知番号を付与していないとすれば、──と考えるか は 「モデル (modeling)」 の論点である。

 TM では、entity は、認知番号を付与されていることが前提である。そして、関係 R は、以下の文法に従って記述される。

 まず、aRb として、「a ≠ b」 のとき、

 R1: 「event」 と 「resource」 のあいだに成立する関係を記述する。
 R2: 「event」 と 「event」 のあいだに成立する関係を記述する。
 R3: 「resource」 と 「resource」 のあいだに成立する関係を記述する。

 さらに、aRb として、「a = b」 のとき、

 R4: 「自己言及 (再帰)」 を記述する。

 
 R2 では、「対応表」 が作成され──精確には、「全射」 のときに作成され──、R3 では、「対照表」 が作成され、R4 では、「再帰表」 が作成される。いずれも、「...表」 というふうに記述されているように、(「L-真」 として、) 「構成」 を示す。

 そして、もし、それらの 「構成」 に対して、属性値が付与されていれば──たとえば、上述した 「工程」 の構成では、たぶん、工程を並べるための序数 (順序を示す 「種別 コード」) が付与されて、投入量とか産出量などが記録されるかもしれないので──、あきらかに、「構成」 を、ひとつの 「もの (事態)」 として、みなしている。すなわち、2項関係が、3項態として、あらたな 「もの」──集合値を組とする オブジェクト──を示している。
 したがって、そういう 「構成」 は、「もの」 として認知されていて、属性値を付与されているので、データ 構造として、実装しなければならない。

 



[ 補遺 ] (2010年 8月 1日)

 本 エッセー で述べている説明は、たぶん、正しいと思うのですが、歯切れが悪いなあ (inarticulate)、、、。

 たとえば、「工程」 の集合 { x1, ・・・, xn } を考えて、製品 A を生産するために、((x1, x2), (x2, x3)) という標準工順 (routings) を構成して、製品 B を製造するために、(x1, x3) という標準工順を構成しているとします。そして、x1 において、製品 A と製品 B を生産するために、── x1 で使われる マシーン a の capacity が同じであるとしても──それぞれの計画投入量が違えば、「工程」 を メンバー にした 「再帰表」 は、あきらかに、アトリビュート をもつことになるでしょう。したがって、「再帰表」 は、ひとつの 「事態」 として認知されることになります。

 同じような現象が 「部品表」 でも生じます。たとえば、部品 a が、製品 A と製品 B の ふたつのなかで使われているとして、それぞれの部品表において、スクラップ 比率 (shrinkage) が違うことが起こります──たとえば、スクラップ 比率が、製品 A では 5% で、製品 B では 10%である、というように。スクラップ 比率は、「部品」 そのものに帰属するのではなくて 「部品表」 上でしか記述できない。そして、上位の階の item (部品) を作るために、下位の階の item の所要量 (requirements) が記述されていれば、この場合でも、「部品表」 の 2項関係は、なんらかの 「事態」 として認知されることになります。

 そもそも、なんらかの アトリビュート で構成された対象は、明らかに、管理対象 (オブジェクト) です。ただ、その オブジェクト を 「(事実的な) F-真」 として考えるかどうかという点が、意味論上、難しい。あるいは、こう言ってもいいかもしれない──なんらかの管理対象は、たとえ、それが 「L-真」 としての構成であっても、かならず、なんらかの 「事態 (あるいは、行為)」 によって構成される、と。すなわち、「事実」 が 「事態」 の集まりであれば、「事態」 には、以下の 2つの態がある、と。

 (1) 過程としての構成 (英語で言えば、-ing)
 (2) 結果としての構成 (英語で言えば、-ed)

 (1) は 「時刻」 を付与されて 「事態」 として認知され、(2) は 「事態」 の アウトプット としての 「事物」 として認知できるでしょうね。たとえば、{ 部門 コード (R)、従業員番号 (R) } は──TM で云う 「対照表」 ですが──、「過程」 として認知すれば、「配属」 という事態を指示しますが、「結果」 として認知すれば 「組織構成」 として認知することもできます。同じことが 「再帰表」 にも適用できるのでしょうね。だから、本 エッセー で述べている説明の歯切れが悪い。





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