2004年 11月 1日 1つの 「event」 が、3種類の日付をもつ >> 目次 (テーマ ごと)
  ● QUESTION   1つの 「event」 が、3種類の日付をもつ、ということはあるか。
  ▼ ANSWER   ない。
2009年11月16日 補遺  



 ここでいう 「日付」 とは、「取引日」 のことをいう。
 したがって、たとえば、「取引日」 のほかに、「データ 更新日」 のような IRM に関する 「日付」 があったとしても、(「取引日」と 「データ 更新日」 という) 2種類の 「日付」 とは云わない。

 さて、以下を前提とする。

 (1) 見積番号を認知番号にして、以下のように、3種類の 「日付」 がある。

     - 引き合い日
     - 見積もり作成日
     - 見積もり承認日

 (2) 3種類の 「日付」 が、時系列のなかで、null となるので、以下の措置をした。

     - 見積番号を認知番号にして、「見積」 entity (event) を作る。
     - 引き合い、見積もり、見積もり承認を、それぞれ、「見積」 entity の サブセット とした。

 
 さて、このときに、論点になるのが、1つの 「見積」 entity (event) のなかに、3種類の 「日付」 を記述することは正しいかどうか、という点である。

 
 以下のように、考えれば良い。

[ 1 ] サブセット には、実質的 サブセット と形式的 サブセット がある。

 実質的 サブセット は、「区分 コード」 が明示されている セット に対する真部分集合のことであり、形式的 サブセット は、null を回避するために、相違の サブセット として作る。 null を回避するために作られた形式的 サブセット は、セット の状態遷移を示すことが多い。上述した前提では、「見積」 entity の 「日付」 が、時系列のなかで、null になるので、サブセット として作図したのでしょう。その措置そのものは、それで良い、と思います。

 
[ 2 ] 状態遷移のなかで、3つの日付は、「同時に」 成立しない。

 「形式的」 サブセット して示された 3つの event は、状態遷移です。
 たとえば、「見積もり作成」 が出た時点で、「引き合い」 は、過去の履歴 データ です。
 「実質的」 サブセット は、「或る一時点で (つまり、同時に)」 サブセット の 「すべて」 が成立する状態ですが、「形式的」 サブセット は──とくに、状態遷移を示す 「形式的」 サブセット は──、「異なる時点で」、それぞれが成立します。

 したがって、「形式的」 サブセット──状態遷移を示す サブセット──では、3つの 「日付」 は、それぞれ、「同時に」 成立しないので、或る 「日付」 が成立すれば、それ以前の サブセット の 「日付」 は、「履歴 データ」 だし、それ以後の サブセット の 「日付」 は、将来、起こりうる event です(ただし、起こらないこともある)。

 
[ 3 ] 3つの サブセット のあいだでは、「日付」 のほかの アトリビュート は同じかどうか。

 「形式的」 サブセット (状態遷移を示す サブセット) のなかで、「日付」 が、null のなるのであれば、「日付」 のほかの アトリビュート は、すべての サブセット のあいだでは、同じかどうか、という点を確認してください。
 言い換えれば、「日付」 の null しか違いはないのかどうか──すなわち、「日付」 を除いたら、「同一の サブセット」 になるかどうか。

 もし、そうであれば、「引き合い」 と 「見積もり作成」 と 「見積もり承認」 は、「つよい意味で、進捗を管理する状態遷移ではない」 ので、サブセット にしてないで、以下のように、1つの event (「見積もり作成」) として、「引き合い」 の 「日付」 と 「見積もり承認」 の 「日付」 を、VE にしてください。

   見積もり作成
   {見積もり番号、取引先 コード (R)、見積もり日、・・・}.

   見積もり. 引き合い
   {見積もり番号 (R)、引き合い日}.

   見積もり. 見積もり承認
   {見積もり番号 (R)、見積もり承認日}.

 
 おそらく、「引き合い」 がなくても、「見積もり」 があるでしょうが、「見積もり」 がなくて、「見積もり承認」 はないでしょう。

 
[ 4 ] 状態遷移が、進捗を、つよく管理するのであれば、3種類の 「event」 ではないか。

 もし、「引き合い」 と 「見積もり作成」 と 「見積もり承認」 が、「つよい意味で、進捗を管理する状態遷移である」 ならば、一応、3つの サブセット にしてください。

 ただし、「進捗を管理する状態遷移」 が、「つよい意味で考えられているならば」、認知番号として、「見積もり番号」 のみで良いのかどうか、という点を確認しなければならない。つまり、「引合番号」 と 「見積番号」 と 「見積承認番号」 という認知番号を導入して、それぞれ、event として考えるべきではないか、という点を提示しなければならない。

 
[ 5 ] 3種類の 「event」 であっても、認知番号が同じであれば、相違を判断することはできない。

 もし、「引き合い」 と 「見積もり作成」 と 「見積もり承認」 が、「つよい意味で、進捗を管理する状態遷移である」 のだけれど、「見積もり番号」 以外の認知番号を、「コード 体系として導入するのがむずかしいのであれば」、前述した [ 4 ] のように、サブセット にするしかないでしょうね。

 理論的には、それ──本来、3つの event なのだけれど、1つの認知番号を使うこと──が良いとは思えないけれど、ユーザ が、認知番号を導入したがらないのであれば、サブセット にするしかないでしょうね。

 



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

 [ 4 ] で示した サブセット 化は、勿論、VE として構成しても妥当です──すなわち、「見積もり作成」 と 「見積もり承認」 は、「引き合い」 とは べつの entity である、という 「解釈」 でも OK です。ただ、VE として構成すれば、VE には個体指定子が付与されていないので──この場合は、「見積もり作成」 も 「見積もり承認」 も 「引き合い」 の個体指定子 である 「見積もり番号」 を継承しているだけなので [ したがって、「見積もり番号」 に対して、関係の演算子 (R) が付与されているだけなので ]、「見積もり作成」 と 「見積もり承認」 は、他の entity と関係をもつことができない。もし、「見積もり作成」 と 「見積もり承認」 が他の entity と関係をもつのであれば、サブセット にしたほうがいいでしょうね。

 さて、TM (T字形 ER手法の改良版) では、「日付」 は、つねに 「過去形 (過去日)」 の値を充足されます。言い換えれば、将来日の値は、TM では、(「event」 を識別するための) 「日付」 にはならない。というのは、TM は、関係文法で構成された項に対して、以下の テスト 文を [ 真理条件とか規約-T とか T-文とも云いますが ] 適用して、事実的な 「F-真」 を確認するので。

    文 「p」 が真であるのは、時刻 t において、事態 p と一致したとき、そして、その時に限る。

 この テスト 文のなかの 「時刻 t」 が、TM で云う 「日付」 です。





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