年月日を表すデータ項目に着目すると、イベントエンティティを簡単に見つけることができます。しかし、これだけでは危険です。
受注伝票に、受注年月日、納入予定年月日、最新更新年月日の３つが存在したと仮定して、話を進めます。
受注年月日があるから受注エンティティ見つけた！
納入予定年月日があるから納入予定エンティティ見つけた！
ここまではＯＫです。
仮に、受注年月日と納入予定年月日のＫＥＹを捜した結果、両方とも受注番号だった場合、どのようにモデリングすべきでしょうか。逆の言い方をすれば、納入予定のために、わざわざ納入予定番号を設けていない場合です。
ＫＥＹが同じ場合、一旦２つを同じエンティティとみなします。そして、これらを同じエンティティの状態遷移として位置づけます。（モデル図の表現では、受注エンティティを表現し、納入予定サブエンティティをその隣におきます。）
ここで大切なことは、「ＫＥＹが同じなら１つのエンティティ」というモデリングのルールを合意しておくことです。
・・・・（イベントエンティティ?につづく）
« ＫＥＹは参照ＫＥＹの総和であるイベントエンティティ? »
