ここでいう 「日付」 とは、「取引日」 のことをいう。
　したがって、たとえば、「取引日」 のほかに、「データ 更新日」 のような 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つの認知番号を使うこと──が良いとは思えないけれど、ユーザ が、認知番号を導入したがらないのであれば、サブセット にするしかないでしょうね。