2001年 6月10日 「event」 か 「resource」 か。 >> 目次 （作成日順）
　　●　QUESTION 　　製品 リコール などの 「トラブル」 entity は、「resource」 か 「event」 か。
　　▼　ANSWER 　　どちらにも解釈できる。
2006年 7月16日 補遺 　




　どちらとも （「resource」 とも 「event」 とも） 解釈できる。

　
1． 「DATE （トラブル発生日）」 を重視する。

　（1） 「トラブル」 を 「event」 として扱う。
　（2） 「名称 （トラブル名称）」 を 「ＶＥ （みなし entity）」 として扱う。

　

　┌─────────────────┐　　　　　┌───────────────────┐
　│　　　　　　　トラブル　　　　　Ｅ│　　　　　│　　　　　トラブル. 名称　　　　　ＶＥ│
　├────────┬────────┤　　　　　├─────────┬─────────┤
　│トラブル番号　　│トラブル発生日　│　　　　　│トラブル番号（Ｒ）│トラブル名称　　　│
　│　　　　　　　　│　　　　　　　　├┼───┼┤　　　　　　　　　│　　　　　　　　　│
　│　　　　　　　　│　　　　　　　　│　　　　　│　　　　　　　　　│　　　　　　　　　│
　│　　　　　　　　│　　　　　　　　│　　　　　│　　　　　　　　　│　　　　　　　　　│
　│　　　　　　　　│　　　　　　　　│　　　　　│　　  　　　　　　│　　　　　　　　　│
　└────────┴────────┘　　　　　└─────────┴─────────┘

[ 註釈 ]

　以上の作図は、おそらく、「予測できない」 トラブル が起こったので記録して、トラブル を徹底的 に解析して、もし、似たような トラブル が再び起こったら、事例を参照できるようにした データ 構造である。



2．逆に、「名称」 を重視する。

　（1） 「トラブル」 を 「resource」 として扱う。
　（2） 「DATE （トラブル 発生日）」 を 「ＶＥ （みなし entity）」 として扱う。

　

　┌─────────────────┐　　　　　┌───────────────────┐
　│　　　　　　　トラブル　　　　　Ｒ│　　　　　│　　　　　トラブル. 発生　　　　　ＶＥ│
　├────────┬────────┤　　　　　├─────────┬─────────┤
　│トラブル番号　　│トラブル名称　　│　　　　　│トラブル番号（Ｒ）│トラブル発生日　　│
　│　　　　　　　　│　　　　　　　　├┼───┼┤　　　　　　　　　│　　　　　　　　　│
　│　　　　　　　　│　　　　　　　　│　　　　　│　　　　　　　　　│　　　　　　　　　│
　│　　　　　　　　│　　　　　　　　│　　　　　│　　　　　　　　　│　　　　　　　　　│
　│　　　　　　　　│　　　　　　　　│　　　　　│　　  　　　　　　│　　　　　　　　　│
　└────────┴────────┘　　　　　└─────────┴─────────┘

[ 註釈 ]

　以上の作図は、おそらく、（トラブル を 「不可避的事象」 として扱わざるを得ない） 製造元や ベン ダー の データ 解析であろう。そして、トラブル が実際に起こったときに記帳するという データ 構造である。



[ 補遺 ] （2006年 7月16日）

　TM （Ｔ字形 ER手法） は、個体の認知に関して、システム・エンジニア の恣意性 （解釈） を、極力、排除するようにしているが、認知行為を すべて 自動化できる訳ではない。TM では、個体 （entity） を event 概念と resource 概念という 2つの クラス にしているが、event を 「事象」 として、いっぽうで、resource を 「事物」 とするような曖昧な定義を下している訳ではない点に注意されたい。TM では、時系列のなかで並びが論点になる個体を event として定義しているのであって、event に対して 「事象」 という邦訳を適用している訳ではない。

　「事象」 とか 「事物」 という邦訳を適用しなかった理由は、「事象 （こと）」 と 「事物 （もの）」 を単純に判断できないからである。とくに、対照表に対して、「事象」 なのか 「事物」 なのか を判断するのが、（第一階の述語論理のなかでは、） 難しい。対照表では、「個体と関係は同一 レベル にある」 （ウィトゲンシュタイン） という命題が真となる。たとえば、以下を考えてみる。

　　｛生地コード、...｝.

　　｛サイズ・コード、...｝.

　　｛生地コード (R)、サイズ・コード (R)｝.

　
　さて、対照表 ｛｛生地コード (R)、サイズ・コード (R)｝ は、「event」 なのか 「resource」 なのか と問われたら--もし、対照表のなかに、なんら性質が記述されていないのであれば--、判断できない。
　もし、この対照表のなかに、性質として 「日付 （DATE）」 が帰属するのであれば、この対照表は、「裁断」 という 「event」 を言及する。しかし、もし、「日付」 が帰属しないのであれば、この対照表は、「型紙」 という 「resource」 を示す。

　対照表は、経営の文脈のなかで、「あきらかに」、「日付」 が帰属すると判断できるとき、そして、そのときにかぎり、「event」 を言及する。同じような事態が、本 ページ に記述した 「トラブル」 の例でも起こる。

　TM が entity を定義したときに、以下の公理を使ったことを ご理解いただけるでしょう。

　　　　entity である ＝ Df 認知番号を付与された管理対象である。

　　　　event である ＝ Df entity のなかで、性質として、「日付」 が帰属する個体である。

　　　　resource である ＝ Df event 以外の entity である。




　 << もどる HOME すすむ >>
　 データ解析に関するＦＡＱ