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

• 日程: Day 7 / セッション 2
• 時間: [10:00-11:00]
• 形式: 実習
• ゴール: 情報モデル定義書のデータを第三正規形まで正規化し、テーブル定義書（またはファイル設計書）を時間内に作成できる
• 学習形式: ハンズオン実習（AIサポートあり）

前のセッションで、注文票を第三正規形まで正規化する流れを見ました。
今度は自分たちの番です。

材料はDay 4で作った情報モデル定義書です。
「会員情報」「予約情報」のような情報モデルを、重複や矛盾のないテーブルの形に変換します。

ここで考えてみてください。
自チームの情報モデルの中に「繰り返し項目」が潜んでいそうなものはどれでしょうか？
1つの予約に複数の参加者、1つの投稿に複数のタグ……。
そういう「1対多のにおい」がする場所が、今日の正規化の主戦場です。

DBMSを使わないチームも進め方は同じです。
正規化したデータの形を決め、保存先をテーブルではなくファイルとして設計します。

手順は5ステップです。

1. 情報モデル定義書から、情報モデルを1つ選ぶ（一番データ項目が多いものがおすすめ）
2. その情報モデルの具体的なデータ例を2〜3行書いてみる（架空でよい）
3. 第一→第二→第三正規化を順に適用する
4. できあがった各テーブルについてテーブル定義書を書く
5. 残りの情報モデルを分担して同様に進める

ポイントは手順2です。
抽象的な項目名だけを眺めて正規化するのは難しいものです。
「佐藤さんが6/10にボールペンを3本」のような具体的なデータを書くと、重複と依存関係が目に見えます。

テーブル定義書には次の項目を書きます。

DBMS不使用チームのファイル設計書の例も挙げます。

• 型: 文字列（VARCHAR）、整数（INTEGER）、日付（DATE）、真偽（BOOLEAN）など
• 桁数: 文字列の最大長など。「名前は何文字まで？」を決めるのは設計者の仕事
• 制約: 主キー、NOT NULL（空を許さない）、UNIQUE（重複を許さない）、外部キー

• 型・桁数・制約まで決めて初めて「定義書」。列名だけの一覧はまだメモ
• 「NULLを許すか」は1列ずつ判断する。迷ったら「この値が無い会員は存在しうるか？」と自問する
• 外部キー（他テーブルの主キーを参照する列）を書くと、次セッションのER図がそのまま描ける
• DBMS不使用チームは「テーブル名」を「ファイル名」、「列」を「項目」と読み替え、ファイル形式（JSON/CSV）と1件分の構造例を書く

「名前は50文字で足りるか」問題は実務で本当に揉めます。
世界最長級の地名、ニュージーランドの丘「タウマタファカタンギハンガコアウアウオタマテアトゥリプカカピキマウンガホロヌクポカイフェヌアキタナタフ」は85文字。
姓名でも、スペイン語圏のフルネームは母方・父方の姓が連なって非常に長くなります。
桁数を決めるとは「どこまでの世界を相手にするか」を決めることでもあるのです。
ちなみに郵便番号を数値型にすると「0始まり」が消える事故（北海道の001-0000など）は新人がよく踏む地雷です。

実習を始める前に、不安があればAIに聞いておきましょう。たとえば：

• 「予約情報という情報モデルのデータ例を一緒に作って。項目は○○と△△」
• 「メールアドレスの最大長は何桁にすべき？根拠も教えて」
• 「日付を文字列型で持つのと日付型で持つのはどちらがいい？」

情報モデル定義書のすべての情報モデルを対象に、以下を行ってください。

1. 各情報モデルの具体的なデータ例（2〜3行）を書く
2. 第一正規化→第二正規化→第三正規化を適用し、各段階で「何を分離したか」をメモする
3. 正規化後の全テーブルについて、テーブル定義書（列名・型・桁数・制約・説明）を作成する
4. 正規化の各段階をAIに見せ、「この正規化は正しいか。見落としている従属関係はないか」を検証してもらう
5. （DBMS不使用チーム）正規化したデータの構造を確定し、ファイル設計書（ファイル名・形式・項目・1件分のデータ例）を作成する

進め方の推奨:

• 最初の1つはチーム全員で正規化し、やり方の認識を揃える
• 残りは分担し、終わったら相互レビュー
• 「正規化したら何も分割されなかった」情報モデルがあっても問題ない。確認できたこと自体が成果

• テーブル定義書（全テーブル分。列名・型・桁数・制約・説明を含む）
• （DBMS不使用チーム）正規化したデータ・ファイル設計書
• 正規化の過程メモ（第一→第二→第三で何を分離したか）

• 繰り返し項目が見つからない場合: 「この情報モデルで、1件に対して複数になりうる項目は？」とAIに聞いてみましょう
• 主キーが決まらない場合: 自然なキーがなければ連番ID（サロゲートキー）を追加して構いません
• 第二正規化で手が止まる場合: 主キーが1列だけのテーブルでは第二正規化は何も起きません。複合キーのテーブルだけ確認すればOKです
• AIへの検証依頼の例: 「このテーブルは第三正規形ですか？違反があれば、どの列がどの列に従属しているか指摘して」
• 型に迷ったら: 「金額は整数型（円単位）」「フラグは真偽型」が無難。小数や文字列での金額管理はトラブルのもとです
• 時間配分: 正規化25分、定義書作成20分、AI検証・相互レビュー5分が目安

今回学んだことを一言でまとめると「正規化は具体的なデータ例で考えると手が動き、型・桁数・制約まで決めて初めてテーブル定義書になる」です。

• 抽象論ではなくデータ例を書いてから正規化する
• 各段階で「何を分離したか」を言語化すると理解が定着する
• 定義書は実装者（来週の自分たち）への手紙。迷わせない粒度で書く

次のセッションでは、今作ったテーブルたちの「関係」をER図として描き、テーブル設計を完成させます。

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

• 自チームのテーブルのうち、正規化で分割が発生したのはどれですか？その理由は？
• 各テーブルの主キーを即答できますか？
• NOT NULLにした列とNULL可にした列の判断基準を説明できますか？

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

• 参考リンク: 使用するDBMSの公式ドキュメント「データ型」一覧
• 発展課題: 自チームのテーブル定義書から CREATE TABLE 文をAIと一緒に書いてみましょう。実装フェーズの先取りになります

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