推移的関数従属性とは、「AがBを決定し、BがCを決定する」という間接的な依存関係のことです。

例えば、「従業員ID → 部署コード → 部署名」という関係がある場合、従業員IDから部署コードを経由して部署名が決まるため、これは推移的関数従属性です。

第3正規形では、このような間接的な依存関係を排除し、主キー以外のカラムが主キー以外のカラムに依存しないようにします。

はい、推移的関数従属性があります。

推移的関数従属性：
商品ID → 仕入先ID → 仕入先名

説明：
商品IDが決まれば仕入先IDが決まり、仕入先IDが決まれば仕入先名が決まります。つまり、仕入先名は商品IDに直接依存しているのではなく、仕入先IDを経由して間接的に依存しています。

第3正規形にするには：
products テーブルから仕入先名を削除し、別途 suppliers（仕入先）テーブルを作成します。

推移的関数従属性の分析：

• 主キー = (従業員ID, プロジェクトID)
• 従業員ID → 部署ID → 部署名（推移的従属）
• プロジェクトID → プロジェクト名（部分関数従属も残っている）

第3正規形への変換：

推移的関数従属性の分析：

• 主キー = (注文ID, 商品ID)
• 注文ID → 顧客ID → 顧客名、都道府県、市区町村（推移的従属）
• 商品ID → 商品名（部分関数従属）

第3正規形への変換：

推移的関数従属性の分析：

• 主キー = 科目ID
• 科目ID → 教員ID → 教員名、教員所属学部（推移的従属）

第3正規形への変換：

ポイント：教室番号は科目IDに直接依存しているので、courses テーブルに残します。

問題点の分析：

1. 第1正規形違反：履修科目、科目ID、担当教員、教員学部に繰り返し項目がある
2. 第2正規形違反：学生名は学生IDのみに依存（部分関数従属）
3. 第3正規形違反：教員学部は科目ID → 担当教員 → 教員学部（推移的従属）

第3正規形への完全な変換：

改善点：
✅ 繰り返し項目を排除（第1正規形）
✅ 部分関数従属性を排除（第2正規形）
✅ 推移的関数従属性を排除（第3正規形）
✅ すべてのデータが1回だけ記録される
✅ データの整合性が完全に保証される

推移的関数従属性の分析：

• 主キー = (売上ID, 商品ID)
• 売上ID → 顧客ID → 顧客名、地域（推移的従属）
• 商品ID → カテゴリ（部分関数従属）
• 商品ID → 商品名（部分関数従属）

第3正規形のテーブル設計とCREATE TABLE文：

データ投入例：

正規化問題の指摘：

1. 推移的関数従属性①：予約ID → 患者ID → 患者名、患者生年月日
2. 推移的関数従属性②：予約ID → 医師ID → 医師名、診療科

第3正規形への変換：

改善点：
✅ 患者情報は1回だけ記録
✅ 医師情報は1回だけ記録
✅ 患者や医師の情報変更が簡単
✅ データの整合性が保証される

第3正規形への変換：

すべての注文と顧客情報を取得するSQL：

第3正規形への変換：

東京都に住む顧客の注文情報を取得するSQL：

実行結果：

推移的関数従属性の分析：

• 従業員ID → 部署コード → 部署名、部署場所（推移的従属）
• 従業員ID → 役職ID → 役職名（推移的従属）

第3正規形への変換：

各部署の従業員数を集計するSQL：

実行結果：

推移的関数従属性の分析：

• 主キー = (売上ID, 商品コード)
• 売上ID → 店舗コード → 店舗名、地域（推移的従属）
• 商品コード → カテゴリ（部分関数従属も含む）

第3正規形への変換：

2025年1月の売上合計を商品カテゴリ別に集計するSQL：

実行結果：

計算内訳：
電子機器：(2 × 80000) + (5 × 2000) + (1 × 80000) = 160000 + 10000 + 80000 = 250000円
文房具：10 × 100 = 1000円