DB設計について考える（その２）
前回は、100%リソースの設計と100%イベントの設計の使い分けについて考察してみた。しかしながら実際には100%リソースの設計はあっても、100%イベントの設計というのは見られない*1。なぜであろうか。
答えは単に正規化の議論を思いだしてもらえばよい。正規化がなぜ必要かという議論は、通常同じ情報が多くの場所に散乱してしまうとメンテナンスは非常に面倒になるという所から始まる。共通化できる情報はくくりだし一元管理するべきだということになる。この議論を理論化したものが第１〜第３正規形である。
第３正規形までは元の情報は失われない。きちんと外部キーを保持すれば結合することで元の100%イベントの状態に復元が可能である。それに対し、100%リソースやイベントからリソースをくくりださないT-ER手法などの設計手法では、元の業務は復元できない。なお、このときID/複合主キーのないイベントはありえてもID/複合主キーのないリソースは存在しえないという知見も得られる。
ここで、はぶ先生の在庫管理のER図を見ると、結果としてイベントの共通項目がリソースとしてくくりだされているのがわかる。すなわち、このモデルから100%イベントは復元可能である。繰り返すようであるが、復元可能ということは情報が落ちていないということであるわけだから、変更に対処しやすいのも道理である。もし新しい業務が発生すれば、それは新しいイベントが増加するわけだからイベントのエンティティを追加し正規化すればよいし、旧来の業務の管理項目が増えたならばどこかに対応するイベントがあるわけだからそこかリレーション先のリソースに項目を増やせばよいだけだということになる。
さて、次回は「数量」や「登録／更新日付」という問題にチャレンジしてみよう（＜本気か？）
