2004年 9月 1日 デフォルト 値と一過性の属性値 >> 目次 (作成日順)
  ● QUESTION   デフォルト 値以外の値が入力される際、どのように対応すればよいか。
  ▼ ANSWER   概念的 スーパーセット を記述して、デフォルト 値との関連を指示しておけばよい。
2009年 9月16日 補遺  



 ● 原帳票

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

 配送伝票

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

 
 ● データ 構造

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

 (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)}.

 



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

 この例は、「概念的 スーパーセット」 を アトリビュート に対して適用した例です。
 類似例は、拙著 「赤本 (データベース 設計論)」 113 ページ に記載した 「単価」 の例を参照してください。





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