itemanblr.
RSSPosts tagged with "modeling"
そういうわけなので、最初から単独主キーだけでＤＢ設計を進めるクセをつけてはいけない。関数従属要件の取りこぼしを避けるためだ。すなわち、まずは複合主キーを含めた形で論理設計を誠実にまとめる。その後で、実装環境に合わせてサロゲートキーを必要に応じて組み込む。そんな設計手順が「無難」だ。
データベースシステムには「複雑さの保存則」のようなものがある。「データ構造の複雑さ」と「データ処理の複雑さ」の総量は一定である。つまり、同一のデータ要件において、データ構造を単純化すればデータ処理が複雑化する。たとえば私の言う「森羅万象テーブル」は、たったひとつのテーブルでシステムの全データを保持しようとするチャレンジングな設計スタイルなのだが、これほど「ベストっぽいシンプル」なＤＢ構造はない。しかし、そのデータ処理様式の複雑さは想像に余りある。
Tumblrについて itemanblr.
