関数従属性と正規形の理論(BCNF・4NF・5NF)

関数従属性：正規形を測る物差し

正規化を「経験則の段階表」として暗記すると、なぜその分割が正しいのかを説明できません。理論の出発点は**関数従属性（FD: Functional Dependency）**です。属性集合 X と Y について、X の値が決まれば Y の値が一意に定まるとき X → Y と書き、「X が Y を関数的に決定する」と言います。

FD はデータの一時的な状態ではなく、ドメインが課す意味的な制約です。たとえば 社員ID → 部署名 は「同じ社員IDの行は必ず同じ部署名を持つ」という業務ルールであり、これに反する状態は不正データとみなされます。正規形とは結局のところ、与えられた FD 集合 F に対してスキーマが満たすべき条件にすぎません。

正規化で扱う 2NF・3NF も、厳密にはこの FD の言葉で定義されます。2NF は「候補キーの一部分への部分従属の排除」、3NF は「キー以外の属性経由の推移従属の排除」です。

アームストロング公理と属性閉包

FD 集合 F から論理的に導けるすべての FD の集合を閉包 F+ と呼びます。これを生成する健全かつ完全な推論規則がアームストロング公理です。

ここから合併律（X → Y と X → Z で X → YZ）や分解律などの便利な系が導けます。健全（導けるものは必ず成り立つ）かつ完全（成り立つものは必ず導ける）なので、この3公理だけで F+ を尽くせます。

ただし F+ 全体を列挙するのは指数的で非現実的です。実務で使うのは属性閉包 X+（X から到達できる属性の集合）です。X → Y が F+ に属するか否かは、Y ⊆ X+ かどうかで多項式時間で判定できます。

属性閉包 X+ の計算(各 FD を最大1回適用するまで反復)
  closure = X
  repeat:
    for each (A → B) in F:
      if A ⊆ closure: closure = closure ∪ B
  until 変化なし
  return closure

この X+ がスキーマの全属性を含むなら、X はその関係のスーパーキーです。さらに X のどの真部分集合もスーパーキーでないなら X は候補キー。正規形の判定は、すべて「左辺の閉包がキーを含むか」という閉包計算に帰着します。

無損失結合分解：分けても情報を失わない条件

テーブルを分割する以上、JOIN で元に戻せなければ意味がありません。分解 R を R1, R2 に分けたとき、R1 ⋈ R2 が常に元の R に一致する（偽の行が増えない）分解を**無損失結合分解（lossless-join）**と呼びます。

二分解の判定条件は明快です。共通属性が少なくとも一方のキーになっていればよい、つまり次のいずれかが F+ にあれば無損失です。

(R1 ∩ R2) → R1   または   (R1 ∩ R2) → R2

直感的には、共通列が片側の関係を完全に決定するなら、JOIN 時に1対多で正しく対応づけられ、無関係な行同士が結びつく「偽タプル」が生じません。逆にこの条件を欠く分解は、JOIN で元データに存在しなかった組み合わせを生成してしまいます。

BCNF：左辺はすべてスーパーキー

**ボイス・コッド正規形（BCNF）**の定義は1行です。関係 R のすべての非自明な FD X → Y について、X がスーパーキーであること。3NF が「右辺がキーの構成属性（素属性）なら例外的に許す」という緩和を持つのに対し、BCNF はこの逃げ道を塞いだ厳格版です。

3NF と差が出るのは、複数の重なり合う候補キーがある場合です。古典例として (学生, 科目) → 教員、教員 → 科目（各教員は1科目だけ担当）という関係を考えます。候補キーは (学生,科目) と (学生,教員)。教員 → 科目 の左辺 教員 はスーパーキーではないため BCNF 違反ですが、科目 は素属性なので 3NF は満たします。

この例を BCNF へ分解すると {教員, 科目} と {学生, 教員} に分かれますが、(学生,科目) → 教員 がどちらの関係にも収まらず保存されません。つまり BCNF は冗長を完全に消す代わりに従属性保存を犠牲にしうる、というトレードオフを持ちます。実務では「BCNF を取るか、3NF に留めて従属性保存を守るか」を制約の検査コストで判断します。

4NF：多値従属を断つ

FD だけでは捉えられない冗長があります。1つの属性が、互いに独立な複数の多値属性を持つ場合です。社員が複数のスキルと複数の資格を独立に持つとき、これらを1つの関係 {社員, スキル, 資格} に入れると、スキル数×資格数の直積行が生じます。

これを記述するのが多値従属性（MVD） X ↠ Y で、「X を固定したとき Y の集合が他の属性と独立に決まる」を意味します。**第4正規形（4NF）**は、すべての非自明な MVD X ↠ Y で X がスーパーキーであることを要求します。先の関係は 社員 ↠ スキル の左辺がキーでないため違反で、{社員, スキル} と {社員, 資格} に分解すべきです。すべての FD は MVD の特殊形（X → Y ならば X ↠ Y）なので、4NF を満たせば自動的に BCNF も満たし、4NF は BCNF を内包します。

5NF：結合従属と偽タプル

最後の段が**第5正規形（5NF、PJ/NF とも）です。ここで扱うのは結合従属性（JD: Join Dependency）**で、関係が3つ以上の射影に無損失分解できる、より一般的な状況を指します。二分解では無損失にできないのに、三分解なら復元できるケースが存在します。

典型は {業者, 部品, 案件} の3項関係に「業者が部品を扱い、案件が部品を要し、業者が案件に関わるなら、その業者はその案件にその部品を供給する」という巡回ルールが成り立つ場合です。このとき関係は3つの2項射影 {業者,部品}・{部品,案件}・{業者,案件} に無損失分解でき、どの2つの JOIN でも復元できないが3つすべての JOIN で正しく戻ります。

JD は実在のビジネスルールとしては稀で、5NF が問題になる設計は多くありません。しかし「無損失性は二分解の枠を超えて定義される」という理解は、多対多を結ぶ中間テーブルの設計判断で効いてきます。

包含関係と実務上の落としどころ

正規形は 1NF ⊃ 2NF ⊃ 3NF ⊃ BCNF ⊃ 4NF ⊃ 5NF という入れ子で、上位は下位を必ず満たします。各段は「左辺がキーであること」を、扱う従属性の種類（FD → MVD → JD）へ順に拡張したものだと見ると一貫します。

実務の到達目標は依然として 3NF または BCNF です。多くの設計はここで冗長と異常をほぼ排除でき、4NF・5NF が問題になるのは独立な多値属性や巡回的な多対多を1表に詰めた設計に限られます。重要なのは段階表の暗記ではなく、FD/MVD/JD を明示し、属性閉包で判定するという手順で「なぜこの分割か」を証明できることです。この数理的根拠こそが、勘に頼らない正規化と、必要十分なインデックス設計の土台になります。