RDB正規化とIAの違い考察
概要
- 日程: Day 3 / セッション 07
- 時間: [13:30-14:00]
- 形式: 演習
- ゴール: RDB正規化と情報アーキテクチャの整理分類の違いを4観点以上で表に整理でき、目的の違い（重複排除 vs ペルソナへの価値提供）を1分で説明できる
- 学習形式: AIディスカッション
導入（5分）
前のセッションで「RDBは表形式で整然とデータを持つ」と学びました。実はRDBの世界には「正規化（Normalization）」という、データを綺麗に整理する手法があります。これ、Day 1で学んだ「IAの整理・分類」と似てる気がしませんか？
似ているけど、目的が違う。今日はその違いを表で整理して、Day 1とDay 3を頭の中で繋げます。
「正規化」と「整理分類」、どちらも「データを綺麗にする」活動ですが、誰のために、何のためにやるかが違います。
本編（20分）
1. RDB正規化とは
正規化は「データの重複と矛盾を防ぐためにテーブルを分割していく手法」です。1970年代、E.F.コッドが第1〜3正規形を定義し、後にBC正規形、第4・5正規形まで拡張されました。実務では「第3正規形（3NF）まで」が一般的です。
非正規形の例
| 注文ID | 顧客名 | 顧客住所 | 商品1 | 単価1 | 商品2 | 単価2 |
|---|---|---|---|---|---|---|
| 1 | 田中 | 東京 | 鉛筆 | 100 | 消しゴム | 50 |
| 2 | 田中 | 東京 | ノート | 200 | NULL | NULL |
問題点:
- 田中の住所が複数行に重複（更新漏れリスク）
- 商品が増えると列が増える
- NULL列が発生する
第3正規形まで分割した例
注文ID, 顧客ID"] --> C["customers
顧客ID, 顧客名, 顧客住所"] O --> OI["order_items
注文ID, 商品ID, 数量"] OI --> P["products
商品ID, 商品名, 単価"]
| 正規形 | やること |
|---|---|
| 第1正規形（1NF） | 繰り返し列をなくし、1セル1値にする |
| 第2正規形（2NF） | 主キーの一部にだけ依存する列を別表に切り出す |
| 第3正規形（3NF） | 非キー列に依存する列を別表に切り出す |
ここがポイント
正規化の目的はシンプル：「同じ事実を1か所にだけ持つ」こと。これで更新の整合性が保たれます。
2. IAの整理分類とは（Day 1の復習）
Day 1で学んだIAの整理・分類は、「ペルソナにとって価値ある情報を見つけやすく届ける」ことが目的でした。
- 整理: 不要なものを捨てる
- 分類: ペルソナの探し方に合わせてカテゴリ分け（LATCH法）
- カードソーティング: 利用者の視点でグルーピング
例: レシピアプリで「肉料理」「魚料理」「野菜料理」と分類するか、「平日5分」「週末ごちそう」と分類するかは、ペルソナによって変わる。
3. 違いを表で整理
| 観点 | RDB正規化 | IAの整理分類 |
|---|---|---|
| 目的 | データの重複と矛盾を防ぐ | ペルソナに価値ある情報を届ける |
| 主役 | データ（マシン） | 利用者（ヒト） |
| 評価軸 | 更新時の整合性 | 探しやすさ・分かりやすさ |
| 手法 | 関数従属性の分析、分割 | LATCH法、カードソーティング |
| 出力 | テーブル構造（ER図） | 情報構造（情報定義書、サイトマップ） |
| 制約条件 | スキーマ、主キー、外部キー | ペルソナの認知、UI制約 |
| 何が正解か | 数学的に決まる | 利用者の反応で決まる |
| 変更タイミング | 業務ルール変更時 | ペルソナや市場変化時 |
ここがポイント
両者は「同じデータを違う視点で整理した結果」とも言えます。RDBは「マシンが扱いやすい整理」、IAは「ヒトが理解しやすい整理」です。
4. 両立させる方法
実は、RDB正規化とIAの整理分類は、片方を選ぶものではありません。両方を別の場所でやります。
- データ層（DB近く）: 正規化したテーブル
- プレゼンテーション層（画面近く）: 利用者目線の情報整理（カテゴリ・タグ等）
- 中間のロジック層がその橋渡しをする
コラム
コッド博士の論文（1970）は、当時のIBMの幹部から「役に立たない」と冷遇されました。実用化されたのは10年以上後の1980年代、Oracle社のラリー・エリソンらによってです。エリソンは論文を読んで「これはビジネスになる」と直感し、IBMより先に商用RDBMSを作り上げました。同じ論文を読んでも、見える未来は人によって違うのです。
コラム
日本の有名なIA実践家、長谷川敦士さんは「情報アーキテクチャはデータベース設計とは別物だが、両方を行き来できるエンジニアが最強」と述べています。データの構造を、マシン視点とヒト視点の両方で語れる人材が、これからの開発現場で重宝されます。
💬 AIに聞いてみよう
ここまでの内容で疑問があれば、AIに質問してみましょう。たとえば：
- 「正規化を進めすぎると検索パフォーマンスが落ちると聞いた。なぜ？」
- 「非正規化（あえて正規化を崩す）が必要な場面の例を教えて」
- 「IAの分類とRDBの正規化を、ECサイトの商品データで対比して」
演習（5分）
課題
自チームの開発テーマで、以下の2つを書き出してください。
- RDB正規化視点での整理: 主な情報モデル3つを、3NFを目指してテーブル分割するメモ
- IA視点での整理: 同じ情報モデルを、ペルソナの視点でどんなカテゴリやタグで見せるか
その後、AIに「この2つの整理は両立できるか？」を相談。
成果物
- 上記2つの整理メモ
- AIからのフィードバックを踏まえた気づき1行
ヒント
- DB設計とUI設計の「カテゴリ名がズレる」のは自然なこと（例: DBは「product_category」、UIは「平日ごちそう」）
- 一致させようとすると、どちらかが不自然になる
まとめ（5分）
RDB正規化は「マシンのため」、IAの整理分類は「ヒトのため」の整理。両方をやる必要があり、それぞれ別の層で実現します。Day 1で学んだIAの考え方は、データベース設計とは違う、独立した価値を持っています。
次のセッションでは、画面（UI）とロジック（API）をつなぐ「通信」の話に入ります。RDBに溜めたデータを、どうやってUIに届けるかの仕組みです。
🔄 振り返りチェック
- RDB正規化とIA整理分類の違いを、4つ以上の観点で挙げられますか？
- 「重複排除」と「ペルソナへの価値提供」の目的の違いを1分で説明できますか？
- 自チームの開発テーマで、両者の視点を別々に整理できますか？
補足資料
- 参考リンク: 増永良文『リレーショナルデータベース入門』、Day 1セッション07・08（IAの整理分類）
- 発展課題: 自分が使っているWebサービスのURL構造を見て、「正規化視点で美しいURL」「IA視点で分かりやすいURL」の両方を書き分けてみる
学習ガイド
想定される質問と回答例
| 質問 | ヒント |
|---|---|
| 正規化したらUIに出すときに毎回JOINが大変では？ | その通り。だから「読み込み専用のビュー」や「キャッシュ」で工夫する |
| IAの整理分類は分類学（taxonomy）と違うの？ | 分類学はIAの中の1つの手法。IAはもっと広く「探しやすさ・伝わりやすさ」を扱う |
| 正規化しないとどうなる？ | 矛盾データが発生、更新コストが増、データ量が肥大化 |
つまずきやすいポイント
| つまずきポイント | ヒント |
|---|---|
| 「同じデータを違う視点で見る」が腑に落ちない | 1つの料理を「栄養成分表」と「メニュー写真」で見せ分ける、と置き換えてみる |
| 第1〜3正規形の定義が暗記しづらい | 「1NF=セル1値、2NF=部分関数依存除去、3NF=推移関数依存除去」で覚える |
| どこまで正規化すべきか分からない | 業務システムは3NFまでが定石。それ以上は性能を見ながら判断 |