ＤＢ設計

本職はプログラマですが、人不足なのでＤＢ設計をすることもあります。プログラマの片手間の知識でやっているので、かなり危なっかしいなぁと思っていたところで、今回、ＤＢ設計の講習会に参加する機会があり、行ってきました。講習会のコースは上級となっていたのですが、正規化のおさらいと概念設計、論理設計だったので自分の知識の再確認となりました。とりあえず、そんなに変なことはやっていなかったことが分かって安心しましたが、もう少し突っ込んだ内容でもよかったかな？というのが正直なところ。

正規化の話が出ると必ず「業務では第３正規形までで十分」と言われますが、だからと言ってボイスコッド、第４、５正規形を知らなくて良いわけじゃないと思うので、出来れば説明して欲しかったです。気になって素早く正規形を見抜く実践テクニック (3/4)：データベースエンジニアへの道（3） - ＠ITを読んでみたら、

稼働しているシステムのテーブル構造を変えるのは非常に大変な作業です。できればこういったビジネスルールはテーブル構造に実装するのではなく、アプリケーションプログラムとして実装した方が保守性の高いシステムとなります。

とあり、第三正規形はデータの整理＆(不必要かもしれない)業務ルールを含んだ形になるようで、実装の都合上、ＤＢで業務ルールを表現する方が良い場合は第３正規形で止めて、業務ルールに依存させない方が良い場合は、正規化を更に進めれば良いようです。私は今まで業務ルールを表現するＤＢ設計が良いと思っていたので、ちょっと考えなおさないといけないです。