DB設計を語るスレ 6

>>68
正規化を考えて普通にDB設計すれば、顧客(そのもの)と顧客履歴は別々のエンティティになるよね
・顧客(顧客ID, 取引開始日時)
　　　-- 顧客IDがプライマリキー
・顧客履歴(顧客ID, 履歴番号, 履歴変更日時, 名前, 住所, メールアドレス, ...etc)
　　　-- 顧客IDと履歴番号との対(つい)でプライマリキー
　　　-- 顧客IDは顧客テーブルへの参照キー

人は引っ越しがあれば住所や電話番号は変わるし、氏名も結婚で変わることがある
でも、もしも顧客そのものに一意性(identity)が無ければ(無くしたDB設計にしてしまえば)、
後々の監査の時に、ある対象顧客の取引記録を追跡できなくなる
(あるいは社会保険庁での事例の様に、血税を使って人海戦術で追跡することになる)

ここで、もし「正規化」を崩すのであれば以下のようになるけど、これをOKとするのかな？って話だ
・顧客(顧客ID, 取引開始日時, 履歴番号, 更新日時, 名前, 住所, メールアドレス, ...etc)