今さら聞けない！第5正規形（5NF）でデータベース設計を最適化するコツ

データベース設計において、第5正規形（5NF）は非常に高度な概念です。これは「射影結合正規形（PJNF）」とも呼ばれ、情報の重複を極限まで排除し、データの整合性を完全に保つための手法です。一般的に第3正規形（3NF）やボイス・コッド正規形（BCNF）までで十分とされるケースも多いですが、複雑な関係性を持つデータ構造を扱う際、意図しないデータの不整合（更新異常）を防ぐためには第5正規形への理解が不可欠となります。実務でこのレベルの正規化を適用すべきか、あるいはあえて非正規化を行うべきかの判断基準について解説します。

正規化の話を読むのって好き。だって、バックエンド担当が「そのデータを正規化したらDBが落ちる」って言ってきた時に、分かってる風な会話ができるようになるからさ。そのあと、なぜかUUIDのバージョンで揉めるのがいつものお約束。

データベースの正規化という失われた技術。「なぜクライアントXのARRがこんなに高いんだ？ あー、11回もカウントしてるわw」。日付もキーに加えちゃうのはどうかな？ ダメなアイデア？

遠回しな言い方になるけど、この記事は私が「正規形」という考え方を好きになれない理由をよく捉えてる。特に数字でリスト化されるやつ。重要なのは1. 冗長性を避けること、2. 人間の目からはすぐには分からない関係性を合成する必要があるかもしれないこと、の2点だけ。この2つはいくらでも深掘りできるけど、数字が振られた「正規形」の中間ステップに価値を感じたことは一度もない。問題を考える上でも、誰かに説明する上でも全く役に立たないと思う。

誰かがどこかで書いたリストが「学術的にお墨付き」を得たからといって、実際に役に立つとは限らない。結局、選択肢式の試験問題を作りやすくしただけってこともある。例えば「OSI参照モデルの第2層は何を表す？」なんて問題に対して、現実的には「それが何か重要？」としか言いようがないよね。

これ最高。

https://en.wikipedia.org/wiki/Essential_tuple_normal_form は面白いよ！

記憶力が悪いから、AIに語呂合わせを作ってもらった：

• Every（すべての）
• Table（テーブルは）
• Needs（必要とする）
• Full-keys（結合時にフルキーを）

痛いほど正規化して、うまくいくまで非正規化するんだ！

4NFの形式的な定義をこき下ろしているリンク先の記事が特に気に入った。

DynamoDBとNoSQLばかり使ってたら脳が鈍っちゃって、もう正規化すらできなくなってる。

番号付きの正規形は、エンジニアリングの仕様というより教材として一番役に立つよ。2NFや3NFに違反して痛い目を見るバグを何度か経験すれば、定義をいちいち確認しなくても、感覚で部分関数従属や推移的関数従属を見抜けるようになる。正規形は語彙を与えてくれて、バグが直感を鍛えてくれるんだ。

注：これは記事本体ではなく、記事内のリンク先にある「著者の4NF定義」に対する批判だよ。

4NFを定義する文章を読むと、最初に出てくる新しい言葉が「多値従属」だ。[Kent 1983]では「多値事実」とも呼ばれる。バカかもしれないけど、最近ようやくこれが単に「ユニークな値のリスト」を意味しているだけだと気づいた。ここでは「ユニークなIDのリスト」と言った方がより正確だろう。

この解釈は不正確で、投稿の残りもこの藁人形論法を前提にしているから意味が通らなくなってる。4NFが「妙で遠回しな方法」で説明されるのは、正規形が解決しようとするまさにその問題、つまり「行の組み合わせ爆発」を明示するためなんだ。

もしこんなテーブルがあったとする：
CREATE TABLE Product(product_id INT NOT NULL, supplier_id INT NOT NULL, warehouse_id INT NOT NULL);

ある製品に対してサプライヤーか倉庫のどちらかを追加するだけなら、行は1つ増えるだけ。でも両方追加すると、1つの製品に対して4行になる。もし5つのサプライヤーと3つの倉庫を追加したら、1つの製品に対して15行にもなってしまう。将来の拡張を見越して、このクロス積の問題を考えずにテーブルを作ってしまうと、設計が理にかなっているように見えてしまうからこの事実は見落とされがちだ。

配列をアトミックな値として扱うかどうかは別として、結論から言えばそれは確かに4NFになっている。でも「多値従属」を「集合」と再定義してしまうと、なぜそれが必要なのか全く意味がわからなくなってしまう。