正規化とテーブル定義書の作成

• 日程: Day 7 / セッション 2
• 時間: 10:00-11:00（60分）
• 形式: 実習
• ゴール: 情報モデル定義書のデータを第三正規形まで正規化し、型・桁数・制約まで定義したテーブル定義書（DBMS不使用チームはファイル設計書）を時間内に完成できる
• 学習形式: ハンズオン実習（AIサポートあり）

前のセッションで「正規化のなぜ」を学びました。受注伝票デモで第一→第二→第三と段階的に整理する流れが見えたと思います。

ここからは自チームのデータで実際に手を動かします。

問いかけ：自チームの情報モデル定義書（Day4成果物）の中で、「繰り返しが起きそうな項目」はどれですか？

→ 例：「会員の予約一覧」「商品のタグ一覧」「ユーザのコメント一覧」。これらが第一正規化の対象候補です。

テーブル定義書とは、1つのテーブルが持つカラムの設計を一覧化した表です。実装者はこの表を見てDDLを書き、設計通りのテーブルを作ります。

カラム一覧

• 物理名は小文字スネークケース・複数形（例：members, order_details）
• 論理名は日本語で書く（実装者・レビュアー全員が読める）
• 型と桁数は実データの最大長から決める（メール100、氏名50など）
• NOT NULL を初期値に。NULL を許す列だけ理由を持って許可

チーム内で命名規約を最初に決めます。途中で変えると混乱します。

世の中には「テーブルは単数形派（member）」と「複数形派（members）」があります。Ruby on Rails は複数形、Java の JPA はデフォルト単数形が多いです。どちらが正解ではなく、チーム内で統一することが大事です。命名規約は チームの方言。一度決めたらブレない、これが守れているチームはコードもきれいに育ちます。

DBMSを使わないチームは、テーブル定義書の代わりに ファイル設計書 を作ります。

項目一覧

ファイル設計書でも、マスタとなるデータは別ファイルに切り出すことで、正規化の精神を活かします。

自チームの情報モデル定義書（Day4成果物）を入力として、テーブル定義書（またはファイル設計書）を作成します。

• テーブル定義書（DBMS使用チーム）
• ファイル設計書（DBMS不使用チーム）

すべての情報モデルを網羅し、主キー・外部キー・型・桁数・制約が定義されていること。

正規化の各段階で、次のように AI と対話しましょう。

私たちのチームの情報モデルは「予約」「会員」「店舗」です。
予約には以下の属性があります：予約番号、予約日、会員名、会員電話、店舗名、店舗住所、利用人数、利用時間。

(1) これを第一正規化したテーブル構成を提案して
(2) (1)の結果を第二・第三正規化した最終形を提案して
(3) 各テーブルの推奨カラム型・桁数も併せて教えて
(4) 残っている異常があれば指摘して

AI の答えをそのまま使わず、チームで吟味して採否を決めるのがポイントです。

• 主キーが定義されているか
• 外部キーの参照先が存在するか
• VARCHARの桁数に根拠があるか（「とりあえず255」を避ける）
• 日時カラムの型は揃っているか
• NULL を許す列に理由があるか

• 「members テーブルの email 列に UNIQUE 制約を付けるべきか？理由とともに教えて」
• 「メールアドレスは何文字あれば足りる？RFCではどう定義されている？」
• 「論理削除（is_deleted 列）と物理削除はどちらを選ぶべき？」
• 「JSON ファイル管理で複合主キーが必要になったらどうする？」

今日のセッションの要点を3つに絞ります。

1. テーブル定義書は 物理名・型・桁数・NULL可否・主キー・外部キー・制約 を必ず明記する
2. 命名規約は最初に合意。途中変更は混乱の元
3. AI に 正規化の各段階を検証 させると抜け漏れが減る

次のセッション（Session 3）では、ここで作ったテーブルどうしの関係を ER図 で見える化します。

• チームの命名規約を3つ以上挙げられる
• テーブル定義書のカラム属性を6つ以上挙げられる
• 自チームの全情報モデルがテーブル化されている
• 主キー・外部キーが全テーブルに定義されている
• AI に正規化のレビューを依頼した

• 前セッション資料：Day7_Session01_内部設計とDBMS_正規化の考え方.md
• Day4 情報モデル定義書（自チーム成果物）
• 参考: 各DBMSのデータ型一覧（MySQL / PostgreSQL / SQLite）