関数従属性 (Functional Dependency)

「A が決まれば B も決まる」= 関数従属

「社員ID が分かれば、その人の氏名は 1 つに決まる」— これは当たり前に感じる関係だが、 正規化の議論では大事なので名前が付いている。関数従属 (functional dependency, FD) だ。 矢印で書くと 社員ID → 氏名。矢印の左が「決める側」、右が「決まる側」。

「決まる」というのは、あるテーブルのどの行を見ても「社員ID が同じなら氏名も同じ」 が成り立つ、という意味。 たまたま同じだった、ではなく、業務ルールとして「社員ID が同じなら氏名も同じはず」と言えるものだけを関数従属として扱う (1 件でも例外が出れば関数従属とは呼ばない)。

3 種類の関数従属 (これから何度も出てくる)

関数従属には 3 種類あり、それぞれが 2NF・3NF が扱うテーマに対応している。 今は名前と雰囲気だけ覚えておけば OK。実例は各正規形のページで詳しく見る。

• 完全関数従属: 「A と B が両方揃って初めて C が決まる」タイプ。 例: (注文ID, 商品ID) → 数量。注文ID だけ、商品ID だけでは数量は決まらない。 これは正常な関数従属で、排除の対象ではない。
• 部分関数従属: 「(A, B) の一部分 (例えば B だけ) で決まってしまう」タイプ。 例: (注文ID, 商品ID) → 商品名 は実は 商品ID → 商品名 だけで成り立つので、注文ID は不要。 これがあると同じ商品名が何度も繰り返されるので、第2正規形 で切り出す対象になる。
• 推移関数従属: 「A → B → C と経由してしまう」タイプ。 例: 社員ID → 部署ID → 部署名。社員ID から部署名を「直接」決めているのではなく、部署ID を経由している。 これがあると同じ部署名が何度も繰り返されるので、第3正規形 で切り出す対象になる。

なぜこの概念が正規化の判定基準になるのか

「同じ情報を 1 か所に書く」を判定するとき、関数従属で見るのが一番シンプル。 例えば 部署ID → 部署名 という関数従属があるということは、 「部署ID が同じ行は部署名も必ず同じ」= 部署名が繰り返し書かれている、ということ。 つまり関数従属を見つけると、そのまま「重複している情報の場所」も見つけたことになる。

正規化 (1NF → 2NF → 3NF) は、こうした「重複を生む関数従属」を段階的に切り出していく手順として理解できる。 各正規形が「どのタイプの関数従属を排除するのか」を意識すると、全体の流れがすっきり見えてくる。

先に「キーの階層」を押さえておこう

関数従属の話を正確にするには キーの階層(スーパーキー・候補キー・主キー) の理解が前提になる。 「主キー全体で決まる」のか「主キーの一部で決まってしまう」のかが、2NF・3NF の判定を分けるからだ。