（演習）RDBの正規化と情報アーキテクチャの違いを考察する

• 日程: Day 3 / セッション8
• 時間: [14:10-14:50]
• 形式: 演習
• ゴール: RDBの正規化とIA（情報アーキテクチャ）の整理・分類（Day1）の共通点・相違点を2つ以上挙げられる
• 学習形式: AIディスカッション

🗣️ 要約

• RDBの正規化とDay1のLATCH法・カードソーティングは、どちらも「情報を整理する」行為である
• 正規化とIAの整理・分類は、目的（誰のための整理か）が異なる

前回のセッションでは、ACID特性とRDBの正規化について学びました。「重複を排除してテーブルを分ける」という作業、実はもうひとつ似たようなことを、私たちはこの研修の中で既にやっています。

Day1の（演習）情報定義書の整理・分類を覚えていますか？ LATCH法で整理軸を決め、カードソーティングで情報をグルーピングしましたね。あれも「情報を整理する」行為でした。

正規化の目的とLATCH法・カードソーティングの目的、実は似ていると思いますか？ それとも違うと思いますか？ このセッションでは、その問いをチームで深掘りしていきます。終わる頃には「正規化とIAはどちらも情報整理だが、誰のための整理なのかが違う」と説明できるようになっています。

🗣️ 要約

• 正規化は重複データを排除しテーブルを分割する作業、IAの整理・分類はペルソナが情報を見つけやすくする作業
• 両者は「情報をまとめる」という点で似ているが、誰のための整理かという視点が異なる

🗣️ 要約

• 正規化とは、1テーブルに詰め込まれた重複データ（顧客名・住所など）を、顧客テーブル・商品テーブル・注文テーブルに分割し、IDで関連づける作業
• 一度書いた情報を他の場所に書き写さないことで、更新時に1箇所を直せば済むようになる

まず具体例から入ります。あるオークションシステムで、次のような1枚のテーブルに全部の情報を詰め込んだとします。

• 注文ID・顧客名・顧客住所・商品名・商品価格を1行にまとめたテーブル

この場合、同じ顧客が3回注文すると、顧客名と住所が3回重複して書き込まれます。正規化とは、こうした重複を見つけて「顧客テーブル」「商品テーブル」「注文テーブル」に分割し、それぞれをIDで関連づける作業でした。

これは、いわば「同じ話を何度も違う言い方で言わない」ようにする整理整頓のようなものです。一度書いた顧客の住所は、もう二度と別の場所に書き写さない。そうすることで、住所が変わったときも1箇所を直せば済みます。

特に注意してほしいのは、正規化の目的が「データの重複を排除し、更新時の矛盾を防ぐこと」であって、「ユーザーにとってわかりやすくすること」ではない、という点です。よくある誤解として「正規化すれば使いやすいシステムになる」と思われがちですが、正しくは、正規化は内部のデータ構造をきれいにする作業であり、ペルソナにとっての使いやすさは別途IAで設計する必要があります。

正規化の考え方を生み出したのは、IBMの研究者エドガー・F・コッド（Edgar F. Codd）です。1970年に発表した論文で「関係モデル（リレーショナルモデル）」を提唱し、そこから正規化の理論が体系化されました。

面白いのは、正規化には第一正規形から第五正規形、さらにボイス・コッド正規形まであるのに、実務でよく使われるのはせいぜい第三正規形までだという点です。正規化をやりすぎると、テーブルを結合する処理（JOIN）が増えすぎて、逆に検索が遅くなることがあります。「きれい好きすぎて逆に不便になる」というのは、情報の世界でもよくある話です。

🗣️ 要約

• 正規化とIAの整理・分類は、どちらもバラバラな情報をまとめる点で似ている
• 正規化には「並べ方・見せ方」の視点がなく、IAはペルソナがどう探すかという視点を持つ
• 正規化は「システムの整合性」、IAの整理・分類は「ペルソナの見つけやすさ」のための整理

ここで少し考えてみてください。正規化で「顧客」と「注文」を分けるのと、Day1のカードソーティングで情報をグループ分けするのは、どちらも「バラバラだった情報をまとまりにする」という意味では似ています。

一方で、正規化には現れない視点があります。それは「この注文一覧を、時系列で見せるべきか、金額順で見せるべきか」という並べ方・見せ方の視点です。これはLATCH法のTime軸やCategory軸のように、ペルソナがどう情報を探すかという視点であり、正規化の理論の中には出てきません。

つまり、正規化は「システムの中でどう整合性を保つか」という視点、IAの整理・分類は「ペルソナがどう情報を見つけやすくするか」という視点です。同じ「情報を整理する」でも、誰のための整理なのかが違います。

ここまでで、正規化とIAの違いについてイメージできましたか？ もし曖昧なところがあれば、次の演習で実際に手を動かしながら確認していきましょう。

🗣️ 要約

• 正規化とカードソーティングの違いの別の具体例、正規化の第一〜第三正規形の違い、実務での決定順序をAIに質問できる

ここまでの内容で疑問があれば、AIに質問してみましょう。たとえば：

• 「正規化とカードソーティングの違いを、別の具体例を使って説明して」
• 「第一正規形・第二正規形・第三正規形の違いを簡単に教えて」
• 「実務では正規化とIAの整理、どちらを先に決めることが多いの？」

🗣️ 要約

• Day2の情報モデルをRDBのテーブルとして正規化した案と、Day1の整理分類済み情報定義書を見比べ、共通点・相違点をそれぞれ2つ以上挙げる演習

🗣️ 要約

• 情報モデルをテーブルとして正規化した案と、整理分類済み情報定義書を見比べ、共通点2つ以上・相違点2つ以上をチームで書き出す

チームの開発テーマについて、次の2つを見比べてください。

• Day2で作った「情報モデル」を、RDBのテーブルとして正規化するとどうなるか（テーブル分割案）を簡単に書き出す
• Day1で作った「整理分類済み情報定義書」（LATCH法・カードソーティングの結果）を見返す

その上で、両者の共通点を2つ以上、相違点を2つ以上、チームで話し合って書き出してください。

🗣️ 要約

• 「正規化 vs IAの整理・分類」考察メモ（共通点2つ以上・相違点2つ以上）

• 「正規化 vs IAの整理・分類」考察メモ（共通点2つ以上・相違点2つ以上）

🗣️ 要約

• 詰まったら「これは誰のための整理か」という問いに立ち返る
• 意見が割れるのは良い議論のサインであり、無理に1つにまとめなくてよい
• うまく言葉にできないときはAIに具体例を出してもらうと別の角度から理解しやすい

• 詰まったら、「これは誰のための整理か（システムのためか、ペルソナのためか）」という問いに立ち返ってみてください
• 意見が割れたときほど、良い議論ができているサインです。無理に1つの答えにまとめなくても構いません
• うまく言葉にできない場合は、AIに「正規化とカードソーティングの違いを例を使って説明して」と伝えると、別の角度からの説明が得られます

🗣️ 要約

• 正規化はシステムのための整理、IAの整理・分類はペルソナのための整理であり、目的が違えば結果も変わる
• 次回は「UIと機能の通信」「実行方式」「開発手法」を学び、今日の情報モデルがREST APIやUIとして動く形につながっていく

今回学んだことを一言でまとめると、「正規化はシステムのための整理、IAの整理・分類はペルソナのための整理」です。目的が違えば、同じ情報でも整理の結果は変わってきます。

次回は「UIと機能の通信」「実行方式」「開発手法」を学びます。今日整理した情報モデルが、明日以降どうやってREST APIやUIとして動く形になっていくのか、そのつながりを意識しておきましょう。

🗣️ 要約

• 正規化の目的を一言で説明できるか
• RDBの正規化とIAの整理・分類の共通点・相違点をそれぞれ1つ挙げられるか

以下の問いに答えられるか確認してみましょう：

• 正規化の目的を一言で説明できますか？
• RDBの正規化とIAの整理・分類の共通点を1つ、相違点を1つ挙げられますか？

答えに自信がない場合は、該当部分を読み返すか、AIに質問してみてください。

🗣️ 要約

• 参考資料はリレーショナルデータベースの正規化に関する入門書
• 発展課題は、開発テーマのテーブル案を第一正規形→第二正規形→第三正規形の順に正規化し、各段階の変化を記録すること

• 参考リンク: リレーショナルデータベースの正規化に関する教科書・データベース設計の入門書の該当章
• 発展課題: 開発テーマのテーブル案を、実際に第一正規形→第二正規形→第三正規形の順に手順を追って正規化し、各段階で何が変わったかを記録してみる

🗣️ 要約

• 受講者からよく出る質問への回答例と、つまずきやすいポイントへの対処法をまとめている

このセクションは、受講者が理解を深めることをサポートする参考情報です。

🗣️ 要約

• 正規化しすぎるとテーブル結合が増え、検索処理が複雑・低速になり得る
• IAの分類軸は「見せ方」の話で、テーブル構造の重複排除とは別レイヤー
• 決まった順序はないが、一般には情報モデル・IAを固めてから正規化を設計する

🗣️ 要約

• 正規化すればUIも使いやすくなると誤解しやすいが、見せ方は別に設計が必要
• 共通点・相違点が思いつかず議論が止まりやすい