「データを整理するなら、重複をなくして完璧な表を作るのが正解だ」
もしあなたがそう信じているなら、少しショッキングかもしれない。コンピュータ科学の世界には、理論上の「完璧」を追求しすぎた結果、人間にとってもコンピュータにとっても不便極まりない「ゴミ」が生み出されるという、奇妙で残酷な皮肉が存在するからだ。
情シス22年の現場で、正規化を極めすぎたシステムを引き継いだことがある。テーブルが30以上に分割され、1つのデータを取得するために毎回10個以上のJOINが必要な設計だった。理論上は完璧だが、クエリを書くたびに疲弊し、パフォーマンスも悲惨だった。その設計者は「正規化の理論に忠実だった」のかもしれないが、使う人間のことを考えていなかった。
この記事でわかること：
- 「チョイカスの表」から卒業する分割統治の考え方
- 第5正規系という「理論上の完璧」が実務の地獄になる理由
- エンジニアリングの本質「妥協の芸術」とは何か
- NotionがリレーショナルDB理論をどう解放したか
1. チョイカスの表を卒業せよ：「ディバイド＆コンカー」の精神
📌 要点：1セルに複数情報を詰め込む「非正規」から抜け出すのが第1正規系。しかしそれだけでは「同じデータが複数行に繰り返される」チョイカスな状態になる。正解は分割統治（表を分けること）だ。
私たちが日常で作成する多くの表は、まだ「洗練の余地」にあふれている。
例えば、1つの単語に「知らなかった語」と「語釈が面白い語」の2つの性質を持たせたいケース。最も素朴な方法は2行に繰り返し書くことだ。
アサスズ ｜ 知らなかった語
アサスズ ｜ 語釈が面白い語これは「第1正規系」の条件は満たすが、内容に被りが多すぎる。この状態を「チョイカスの表（理論上は正しいが、まだ洗練されていない表）」と呼ぶ。
正解はディバイド＆コンカー（分割統治）だ。単語の表、性質の表、そしてそれらを紐づけるだけの「関係の表」。情報をバラバラに分解し、IDで再構成していく。このプロセスこそがデータベース設計の醍醐味だ。
2. 第5正規系という名の狂気。理論上の頂点が「実務の地獄」に変わるとき
📌 要点：第5正規系では1つの情報の登録に3つのテーブルが必要になる。「人間が読めない」「JOIN多発でパフォーマンスが低下する」という致命的な欠点があり、実務では使われない。
情報の整理を極限まで突き詰め、あらゆる重複と不整合の可能性を排除した最終形態、それが「第5正規系」だ。
ここでは1つの情報を登録するために表を3つに分割する。
- 単語の表：単語IDと単語名（例：1番＝アサスズ）
- 性質の表：性質IDと性質名（例：1番＝知らなかった語）
- 関係の表：単語IDと性質IDを紐づけるだけの表
1つの情報を登録するのに、3つの表にそれぞれIDを書き込み、パズルのように組み合わせる。タイプミスによる情報の不整合は完全に防げる。しかし正直なところ、これは「狂気の沙汰」だ。
致命的なデメリットが2つある：
① 人間が読めない
IDの数字ばかりが並んだ表を見ても、人間は何が書いてあるか直感的に理解できない。
② パフォーマンスの低下
人間で例えるなら、1つの言葉の意味を調べるために10回も別の部屋へ移動して別々の辞書を引かされるようなもの。コンピュータにとっても処理速度が劇的に落ちる。
「一番破綻がなく正しい整理方法」と「実際に使う上での便利さ」が一致しない。これがデータベース理論における最大の皮肉だ。
3. エンジニアリングの本質は「妥協の芸術」。あえて正解を選ばない勇気
📌 要点：エンジニアリングにおける「妥協」は怠慢ではなく相反する制約の中で最適解を見つける高度な知的営み。戦闘機設計と同じく「目的に合わせたバランス」を探ることが本質だ。
この理想と現実のギャップを埋める考え方が「妥協の芸術」だ。
エンジニアリングの世界において「妥協」はネガティブな意味ではない。相反する制約の中で最適解を見つけ出す、高度に知的な営みを指す。
例えば戦闘機の設計を考えてみよう。「防御を固めるために装甲を厚くしたいが、厚くしすぎると重くて飛べない」。この矛盾を抱えながら、その機体の目的に合わせて最適なバランスを探る。データベース設計も全く同じだ。
「ベストはこれ（第5正規系）だけど、パフォーマンスを考えるとこっちかな」と妥協したところに落ち着く。その泥臭い判断の裏にあるのは怠慢ではなく「使う人（あるいはマシン）への配慮」だ。
引き継いだ過正規化システムの改修では、思い切って3つのテーブルを1つにまとめ（非正規化）、クエリのシンプルさとパフォーマンスを回復させた。理論的には「後退」だが、実際には誰もが使いやすくなった。これが妥協の芸術だ。
正規化すべき場面 vs 非正規化を選ぶ場面：
| 判断軸 | 正規化を徹底する | 非正規化を選ぶ |
|---|---|---|
| チームサイズ | 3人以上 | 1〜2人 |
| 運用期間 | 1年以上 | 短期・一時的 |
| 整合性の重要度 | 高い（金融・医療） | 低い |
| クエリの複雑さ | 許容できる | シンプルさ優先 |
| パフォーマンス要件 | 通常レベル | ミリ秒単位の高速が必要 |
4. Notionはリレーショナルデータベースの「解放者」だった
📌 要点：伝統的なRDBMSが厳禁としていた「1セルに複数値」をタグ機能として実装したNotionは、複雑なDB理論を隠蔽して個人・チームレベルでの利用を可能にした革命的なツールだ。
伝統的なリレーショナルデータベースが何十年も守り続けてきた「1つのセルに複数の値を放り込むのは禁じ手」という鉄の掟。Notionはこれを「タグ機能」という形で軽やかに踏み倒した。
かつてエンジニアが自分の進捗管理のためにわざわざコードを書いてデータベースを構築していた苦労を、NotionはJSONのような現代的なデータ構造を採用することで直感的な操作感へと昇華させた。私たちはもはや複雑な正規化理論に頭を悩ませることなく、「多対多」のデータを一発で管理できるようになった。
ただし、Notionも魔法ではない。1万行を超える大量データをミリ秒単位で処理するなら、伝統的なデータベースの「正しさ」には勝てない。しかし個人やチームの知的生産を支えるツールとして、リレーショナルデータベースの煩わしい制約から解放してくれた価値は計り知れない。
FAQ：よくある質問
- Q実際の業務では何正規系まで対応すれば十分ですか？
- A
多くの実務システムでは第3正規系（3NF）が目安だ。更新時の異常（更新異常・挿入異常・削除異常）を防ぎつつ、パフォーマンスとのバランスが取れるラインがここになる。
- Q「非正規化」を選ぶ判断はいつ正当化されますか？
- A
読み取りが書き込みより圧倒的に多いシステムで、JOINコストがパフォーマンスのボトルネックになる場合だ。分析系DB・データウェアハウスでは意図的に非正規化した「スタースキーマ」が標準的に使われる。
- Qデータベース設計を学ぶには何から始めればいいですか？
- A
「第1〜第3正規系」を理解してから実際に小さなシステムを設計することを勧める。
理論だけ学んでも体得できないため、「自分のタスク管理DB」を設計→運用→改善のサイクルを回すのが最速だ。
- QORMを使えば正規化を意識しなくても大丈夫ですか？
- A
ORMはSQL記述を減らしてくれるが、テーブル設計の責任は開発者にある。
N+1問題などのパフォーマンス問題はORM利用時でも発生し、その原因を理解するにはDB設計の知識が必要だ。ORMは「設計を代わりにやってくれるツール」ではない。
- Q第4正規形・第5正規形を学ぶ意味はありますか？
- A
実務で使う機会は少ないが、「なぜ実務では使わないか」を理解するために一度は学ぶ価値がある。「正規化の限界」を知ることで、非正規化の判断に自信を持てるようになる。
まとめ
DB設計における「妥協の芸術」の本質は3点に集約される。
- 理論上の完璧（第5正規系）は「人間が読めない・遅い」という実務の地獄になりえる
- エンジニアリングとは相反する制約の中で最適解を見つける知的な営みだ
- 正規化と非正規化は「どちらが正しいか」ではなく「何を優先するか」で選ぶ
正直なところ、「正解」という言葉に弱すぎる。本当の知性はツールの外側にある。完璧だけど使いにくい設計に気づいたら、勇気を持って「妥協の芸術」を実践してほしい。その少しの「不純さ」が、あなたの設計を劇的に使いやすくしてくれる。
関連記事：Notionの破綻を防ぐ「関係モデル」の極意
関連記事：あなたのNotionが散らかる理由。「概念設計」の極意
“`
