「完璧な表」は、なぜゴミになるのか？ データベースの正解をあえて捨てる“妥協の芸術”

「データを整理するなら、重複をなくして完璧な表を作るのが正解だ」

もしあなたがそう信じているなら、この記事は少しショッキングかもしれません。コンピュータ科学の世界には、理論上の「完璧」を追求しすぎた結果、人間にとってもコンピュータにとっても不便極まりない「ゴミ」が生み出されてしまうという、奇妙で残酷な皮肉が存在するからです。

これはデータエンジニアだけの話ではありません。Excelの管理表を細かく分けすぎて自分でも何がどこにあるか分からなくなっている「真面目すぎる」あなたや、プロジェクト管理を緻密にしすぎてメンバーのやる気を削いでいるマネージャーへの、痛烈な警告でもあります。

今回は、データベース設計の最終形態「第5正規系」の仕組みと、なぜ時にあえて「ダウングレード」することが必要なのか。理想と現実の板挟みで苦しむ設計者たちを救う、エンジニア流「妥協の芸術」の深淵を覗いてみましょう。

1. チョイカスの表を卒業せよ。解決策は「ディバイド＆コンカー」の精神
2. 第5正規系という名の狂気。理論上の頂点が「実務の地獄」に変わるとき
3. エンジニアリングの本質は「妥協の芸術」。あえて正解を選ばない勇気
4. Notionはリレーショナルデータベースの「解放者」だった
まとめ
1. 配信元
2. 配信元

1. チョイカスの表を卒業せよ。解決策は「ディバイド＆コンカー」の精神

私たちが日常で作成する多くの表は、コンピュータ科学の視点から見ると、まだ「洗練の余地」にあふれています。

例えば、1つのセルに情報を詰め込みすぎる「非正規リレーション」。これを卒業し、1セル1情報の原則を守るのが「第1正規系」ですが、これだけではまだ不十分です。例えば、1つの単語（アサスズ）に「知らなかった語」と「語釈が面白い語」という2つの性質を持たせたい場合を考えてみましょう。

最も素朴な方法は、その単語を2行にわたって繰り返し書くことです。
1行目：アサスズ｜知らなかった語
2行目：アサスズ｜語釈が面白い語

これは「第1正規系」の条件は満たしていますが、内容に被りが多すぎます。エンジニアの堀本さんは、この状態をあえて親しみを込めて「チョイカスの表（理論上は正しいが、まだ洗練されていない表）」と呼びます。

「正解はディバイド＆コンカー（分割統治）です。」

コンピュータ科学における問題解決の鉄則に従えば、この重複を排除する唯一の方法は「表を分けること」にあります。単語の表、性質の表、そしてそれらを紐づけるだけの「関係の表」。このように情報をバラバラに分解し、再構成していくプロセスこそが、データベース設計の醍醐味なのです。

2. 第5正規系という名の狂気。理論上の頂点が「実務の地獄」に変わるとき

情報の整理を極限まで突き詰め、あらゆる重複と不整合の可能性を排除した最終形態。それが「第5正規系」です。

ここでは、驚くべきことに1つの情報を登録するために表を3つに分割します。

単語の表：単語IDと単語名（例：1番＝アサスズ）
性質の表：性質IDと性質名（例：1番＝知らなかった語）
関係の表：単語IDと性質IDを紐づけるだけの表（例：1番の単語は1番の性質を持つ）

1つの情報を登録するのに、3つの表にそれぞれ数字（ID）を書き込み、それらをパズルのように組み合わせる。これによって、「アサスズ」という文字列を何度も書く必要がなくなり、タイプミスによる情報の不整合（ある行では「アサスズ」、別の行では「アサスズ」と誤記するなど）を完全に防ぐことができます。

しかし、正直なところ、これは「狂気の沙汰」と言わざるを得ません。

なぜなら、この「理論上、最も破綻がなく正しい整理方法」は、実務においては致命的なデメリットを抱えているからです。
第一に、「人間が読めない」こと。IDの数字ばかりが並んだ表を見ても、人間は何が書いてあるのか直感的に理解できません。
第二に、「パフォーマンスの低下」です。人間で例えるなら、1つの言葉の意味を調べるために、10回も別の部屋へ移動して別々の辞書を引かされるようなもの。そりゃあ、コンピュータだって嫌気が差しますし、処理速度は劇的に落ちてしまいます。

「一番破綻がなく正しい整理方法」と「実際に使う上での便利さ」が一致しない。これがデータベース理論における最大の皮肉なのです。

3. エンジニアリングの本質は「妥協の芸術」。あえて正解を選ばない勇気

この理想と現実のギャップを埋める考え方が「妥協の芸術」です。

エンジニアリングの世界において、「妥協」という言葉は決してネガティブな意味ではありません。むしろ、相反する制約の中で最適解を見つけ出す、高度に知的な営みを指します。

例えば戦闘機の設計を考えてみてください。「防御を固めるために装甲を厚くしたいが、厚くしすぎると重くて飛べない」。この矛盾を抱えながら、その機体の目的に合わせて最適なバランスを探る。データベース設計も全く同じです。

「ベストはこれ（第5正規系）なんだけどな、でもパフォーマンス考えるとこっちかなって結構妥協したところに落ち着く妥協の芸術が見られるんですよね。」

実際のところ、現場で第5正規系なんて持ち出したら、同僚に白い目で見られるでしょう。あえて理論的な正解を捨て、正規化を途中で止めたり、一度分けた表をあえてくっつけ直したりする（非正規化）。その泥臭い判断の裏にあるのは、怠慢ではなく「使う人（あるいはマシン）への愛」です。

理論を完璧にこなせば素晴らしいシステムができると信じたくなる気持ちはわかります。しかし、真に優れた設計とは、理論の美しさに固執せず、現場のパフォーマンスを優先して「あえて正解を選ばない」という勇気を持つことなのです。

4. Notionはリレーショナルデータベースの「解放者」だった

さて、こうしたデータベース理論のジレンマを、驚くほどスマートに解決してしまったのが「Notion」です。

伝統的なリレーショナルデータベースが何十年も守り続けてきた「1つのセルに複数の値を放り込むのは禁じ手」という鉄の掟。Notionはこれを「タグ機能」という形で軽やかに踏み倒しました。

「豚に真珠だな、水野にノーションだなって思ってました。」

かつてエンジニアが自分の進捗管理のためにわざわざコードを書いてデータベースを構築していた苦労を、NotionはJSONのような現代的なデータ構造を採用することで、直感的な操作感へと昇華させました。私たちはもはや、複雑な正規化理論に頭を悩ませることなく、「多対多」のデータを一発で管理できるようになったのです。

もちろん、Notionも魔法ではありません。1万行を超えるような巨大なデータをミリ秒単位で処理するなら、やはり伝統的なデータベースの「正しさ」には勝てません。しかし、個人やチームの知的生産を支えるツールとして、リレーショナルデータベースの煩わしい制約から私たちを解放してくれた価値は、計り知れないものがあります。

私たちはNotionという「現代最強の妥協ツール」を手に入れたことで、ようやく理論の檻から脱出し、情報の海を自由に泳げるようになったのかもしれません。