« モデリングのスタイル:意味論と統辞論 | トップページ | アナログ人間ほどコンピュータに向いている »

2006.12.24

「何かと便利」な設計方針?

 データベースの「正規化崩し」の理由としてしばしば聞くのが「何かと便利なのでこのようにした」である。

 たとえば、次のような関数従属要件があるとする。
Image061224a_1

 これが、たとえば次のように物理設計される。
Image061224b

 なぜテーブルDやDFに、本来並ばなくていい項目がごそごそ並ぶのかと問うと、「これらを置くことで、関連テーブルを読まずに値が手に入る。プログラムがシンプルになるし、何かと便利だろうから」と説明される。

 この種の設計の妥当性を吟味するためには、「継承属性」と「スナップショット項目」の違いを理解しておく必要がある。継承属性とは、あるテーブルから見て多重度1のテーブル上に載っている項目(テーブルDから見ればA、DFから見ればAとD)のことで、インデックスを張るとか参照キー制約を組み込むといった明確な目的にもとづいて実装される。実装された継承属性については、もともと載っていた項目の値が変更されたら、すかさず値を同期させるようなプログラムを用意しておかねばならない。

 いっぽうの「スナップショット項目」は、あるテーブルのインスタンスが生じた時に「多重度1の関連インスタンスの状態を記録しておく必要がある」といったケースで組み込まれる。正規化違反しているように見えるが、スナップショット項目はそのテーブルの識別子に非推移的に関数従属するれっきとした固有属性である。顧客毎に定まる営業担当者コードを受注データ上に「受注時営業担当者コード」として置くなどといった例が典型的だ。

 冒頭に示した設計方針は、「スナップショット項目」や「実装されるべき継承属性」といった明確な目的意識にもとづくものではない。テーブルDFを読んだときに、テーブルAやD上の項目の値が問題になることが多いため、そこにあれば「プログラミングの際に何となく便利そう」という「気分」にもとづく方針である。

 そのような「気分」で設計するとどんな問題が起こるか。「実装されるべき継承属性」と「スナップショット項目」とが区別されていないゆえに、テーブルAの当該項目が更新されたときに、テーブルDやDF上の項目の値を同期させるべきかどうかがわからない。たいていは、スナップショット項目も継承属性もクソミソで放置されてしまう。遅かれ早かれ、データベースは矛盾の地雷原と化す。「何かと便利」なデータベースはしばしば「何かと危険」なのである。

|

« モデリングのスタイル:意味論と統辞論 | トップページ | アナログ人間ほどコンピュータに向いている »

コメント

 仰ることは理解出来ます。

 ただ、例えば商品単価など変更がある「可能性」があるものをどう扱えばよいかいつも迷います。

 ほとんどの既存商品は単価変更しませんので、一生継承属性ですが、変更ある場合だけは、一時的にスナップショットで扱いたいという要件です。旧単価と新単価の切替を受注時にする場合と出荷時の場合があるでしょう。

 スーパーなどで特売期間や特売時刻を定期的に設定するときには特売単価マスタなどでコントロールしますが、めったにない価格改定は要件として明確に出てこないので忘れがちです。この要件を忘れて設計されたシステムを導入されたお客様は、その時になって大変な思いで運用されてるのでしょう。

 そのうち、ブログネタででも考えをお聞かせ下さい。

投稿: HAT | 2007.01.14 12:07

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: 「何かと便利」な設計方針?:

« モデリングのスタイル:意味論と統辞論 | トップページ | アナログ人間ほどコンピュータに向いている »