「一般的には、第3正規形まででよい」の根拠は何か？(4)
前回のエントリから2ヶ月近く経ってしまった。
生焼けの情報を公開して、強引に進めよう。
更新をさぼっていた間に分かったこと・こうじゃないのかなと思ったことは以下の通り。
メモ書きなので現時点では意味不明ですが、きちんと人に説明できるように、一つずつ書き直す予定。
- 「一般的には、第3正規形まででよい」というのは、「第3正規形を超えると関数従属性が失われる可能性があるので、分かっている人以外は止めておきましょう」ということ。
- 第3正規形に変換する操作では完全正規形にならないテーブルの場合＝複合キーの中に結合従属性がある場合は、やはり更新時異状が発生してしまう。このままではアプリケーションが書けない。
- ということは、実務的には「第3正規形まででよい」ということはない。OLTPで更新されるテーブルは、常に完全正規形に分解しなくてはならない。
- 「第3正規形まででよい」とする根拠がなかなか見つからないのは、そもそも根拠がないから...ということではないのか。
- 何でも完全正規形に分解するという方針だと、関数従属性の消滅が問題になる。
- 「第3正規形だが非ボイスコッド正規形」のテーブルをボイスコッド正規形に分解すると、非キー項目からキー項目への関数従属性が消滅してまずい、とよく説明されるが、これは分解するのではなく対照表(validation rule)を新たに追加することで回避できる問題。
- 「ボイスコッド正規形だが非第4正規形」「第4正規形だが非第5正規形」のテーブルに非キー項目があると、分解するときに非キー項目のデータの行き場所がなくなってしまう。この場合も分解不能なので、validation ruleの追加で更新時異状を回避する。
- まとめると、関数従属性を保存するために分解できない場合は、validation ruleの対照表を追加すればよい。
- 正規化理論に登場するスキーマには、実際のDBMSで実装できないものがあるのではないか。
