したがって、「有効日」 や 「適用日」 などの予定日は、Ｔ字形 ER手法がいう 「日付」 ではない。
　それらは、名称とか数量のような テ゛ータ 項目と同じ性質として扱われる。

　以下を例にする。

　（1） 部品番号を認知番号にして、「部品」 entity がある。
　（2） 部品に対して設計変更 （いわゆる「設変 （せっぺん）」） が起こる。
　（3） 設計変更は事象として記録される--設計変更番号を認知番号にして、「設計変更」 entity がある。

　以上を前提にすれば、以下のような テ゛ータ 構造になる。

[ 具体例（1）]

　部品： 　｛部品番号、部品名称、適用日、...｝. [ R ]

　設計変更： 　｛設計変更番号、部品番号 (R)、設変日｝. [ E ]

　
　すなわち、「部品」 のなかの適用日は将来日として記述されていて、実際の設変が実施された日付は、「設計変更」 の 「設変日」 を使って記述される。
　上述した「適用日」 の考えかたについては、「履歴 テ゛ータ の扱い」 （193ヘ゜ーシ゛） を参照されたい。

　
　ただし、以下のような構造になれば、「適用日」 は 「日付」 となる（！）

[ 具体例（2）]

　部品： 　｛部品番号、部品名称、...｝. [ R ]

　部品. 適用： 　｛部品番号 (R)、適用日｝. [ VE ]

　設計変更： 　｛設計変更番号、部品番号 (R)、設変日｝. [ E ]

　
　「部品. 適用」 のなかの適用日は実施された日付として扱われる。
　したがって、「設計変更」 のなかの設変日は適用日よりも過去の日付となる （「設変 --> 適応」 の順序になる）。

　
[ 具体例（3）]

　部品： 　｛部品番号、部品名称、...｝. [ R ]

　部品. 部品. 再帰： 　｛部品番号 (R)、部品番号 (R)、適用日｝. [ 再帰 ]
　--この再帰は、いわゆる「部品表」を記述する再帰ではなくて、設計変更の対象を記述する再帰である。

　設計変更： 　｛設計変更番号、部品番号 (R)、設変日｝. [ E ]

　
　この適用日も 「event」 を生成する日付であるが、具体例 （2） の適用日と具体例 （3） の適用日では、「意味」 が微妙に違っている。具体例 （2） は、変更された部品の適用日であるが、具体例 （3） は、同じ部品の設計変更ではなくて、代替部品を使った変更である可能性が高い。