● 原帳票

　たとえば、配送伝票として、以下を例にする。

　配送伝票

｛配送伝票番号、配送便 コード、取引先 コード、商品 コード、届け先 コード、届け先住所、配送日、・・・｝.

　
　● データ 構造

　以下のデータ 構造を前提にする。

　（1） 取引先 [ R ]
　　　｛取引先 コード、取引先名称、取引先所在地、...｝.

　（2） 商品 [ R ]
　　　｛商品 コード、商品名称、...｝.

　（3） 配送便 [ R ]
　　　｛配送便 コード、配送便名称、...｝.

　（4） 届け先 [ R ]
　　　｛届け先 コード、届け先名称、届け先住所、...｝.

　（5） 配送 [ E ]
　　　｛配送伝票番号、取引先 コード （R）、配送便 コード （R）、届け先 コード （R）、商品 コード （R）、
　　　 届け先住所、配送日、・・・｝.

　
　● ソリューション

　「配送」 を指示する際──配送伝票を入力する際──、「届け先住所」 に関して、以下の アルゴリズム が成立している、とする。

　（1） まず、「届け先」 resource の 「届け先住所」 （デフォルト 値） が表示される。

　（2） もし、デフォルト 値と、ちがう値を入力するのであれば、上書きできる。

　
　（デフォルト 値が変更されたかどうか、ということは、プログラム が確認するとして、） デフォルト 値が変更されたら、「届け先住所」 は、データ 構造のなかで、「配送」 event のなかに、一過性の データ として記録される。

　データ 構造としたら、その対応でも良いが、事業の支援を考えるなら、「届け先住所」 が、2つの場所に記録されていることに対して配慮したほうが良い。

　対応手段として、以下のように、概念的 スーパーセット を使って、「届け先住所」 が、2ヶ所に収録されていることを示せば良い。

　　届け先住所 [ 概念的 スーパーセット ]
　　　｜
　　　×
　　　│
　　　├｛届け先 コード、届け先名称、届け先住所、・・・｝.
　　　│
　　　└｛配送伝票番号、・・・、届け先 コード （R）、 届け先住所、・・・｝.

　
　ちなみに、もし、「届け先住所」 を、（入力の省力化のために、プルダウン・メニュー 形式を導入して、デフォルト 値を最初に表示するいっぽうで、かって、一度でも記録された） 履歴のなかから、随時、選ぶようにするのなら、（「配送」 event のなかの 「届け先住所」 を複写して、） 「届け先」 entity の 「VE」 として収録すれば良い。

　（1） 届け先 [ R ]
　　　｛届け先 コード、届け先名称、届け先住所、・・・｝.

　（2） 届け先. 住所変更 [ VE ]
　　　｛届け先 コード （R）、届け先住所 （D）｝.