Day 7 - 本日のサマリー: システムの「舞台裏」を設計する日

• 日程: Day 7
• 本日のゴール: 情報モデルを第三正規形まで正規化し、テーブル定義書（DBMS 不使用チームはファイル設計書）と ER 図を時間内に作成する
• 対応する到達目標: No.5
• 本日の成果物: テーブル定義書（または正規化したファイル設計書）、ER 図

昨日まで作ってきたのは「ユーザに見える顔」だった。今日からの2日間（Day7-8）は内部設計、つまり「ユーザに見えない舞台裏」を設計する。レストランで言えば、外部設計がホールの様子なら、内部設計は厨房の動線・調理器具・食材の保管方法。今日は特に「データをどう正しく保管するか」を扱う。正規化でデータの異常（更新・挿入・削除）を防ぎ、ER 図でテーブル間の地形を1枚に見える化する。

午前は「正規化を理解する → 自分のデータで実践する」、午後は「テーブル同士の関係を見える化する」流れ。

テーブル定義書には全テーブルの「物理名・論理名・型・桁数・NULL 可否・主キー・外部キー・制約・説明」が並ぶ。例えば members テーブルなら、email VARCHAR(100) NOT NULL UNIQUE のように、桁数と制約に根拠を持って書ける状態を目指す。ER 図ではエンティティ間に ||--o{（1対多）や中間テーブルが明示され、テーブル定義書と1対1でクロスチェックできる。

DBMS を使わないチームは、テーブル定義書の代わりにファイル設計書（ファイル名・項目・型・例）を作る。正規化の考え方はそのまま使える。

各セッションファイルの「つまずきやすいポイント」から特に効きそうなものを抜粋する。

• 第二正規化と第三正規化の違いが曖昧（S1）: 「主キー全体に依存しない＝2NF 違反、主キー以外に依存する＝3NF 違反」と覚える。
• 桁数が決められない（S2）: 「現実の最大長 × 2」を初期値にする。氏名=50、メール=100 が定番。「とりあえず 255」は避ける。
• 外部キーの方向が逆になる（S2・S3）: 「多側が外部キーを持つ」と覚える。会員1：予約多なら、予約テーブルが member_id を持つ。
• 多対多に気づかず1対多で描く（S3）: 「同じ商品に複数のタグ」「同じタグに複数の商品」両方 YES なら多対多。中間テーブルで分解する。

安心材料: 正規化は完璧主義より「各段階でどの異常を防いだか説明できる」ことのほうが大事。AI に各段階を検証してもらうと抜けが減る。

まず自分で正規化してみる → 段階ごとに AI に検証を頼む、が今日の基本姿勢。

• 「私たちのチームの情報モデル『○○』を仮テーブルにしたとき、第二正規化で分離すべき列はどれか教えて。理由も併せて」
• 「私たちのテーブル定義書（貼り付け）から ER 図のたたき台を Mermaid erDiagram で書いて。多対多があれば中間テーブルに分解して」