#この記事について
BCNFをちょっと勉強したので、自分のためにもまとめます。
#ボイス・コッド正規形（Boyce–Codd normal form）を使う理由
稀に第３正規形まで正規化しても更新異常が起こる場合がある。
#BCNFを使う例
例えばこう云う第３正規化までされた表があるとする。
| 学生ID | 教科 | 先生 |
|---|---|---|
| 100 | Java | 高橋 |
| 100 | Python3 | 田中 |
| 101 | Java | 伊藤 |
| 102 | C# | 鈴木 |
ただし、
- 一人の学生は複数の教科を受講できる
- 各先生は一つの教科を担当する
- 同じ教科を複数の先生が教えることがある
とします。この条件下では、以下のような時に更新異常にぶつかります。
学生ID = 100 の学生がJavaの履修をやめた時、高橋教授がJavaを担当しているという情報が失われる。
#BCNFを使う
前述の表では
- 主キーの{学生ID, 教科}の組み合わせで先生が一つに決まり、
- 先生が決まれば教科が決まります。
この２つ目の
先生→教科
ですが、これが更新異常を起こしている原因です。
なので、
| 学生ID | 先生ID |
|---|---|
| 100 | 1 |
| 100 | 2 |
| 101 | 3 |
| 102 | 4 |
と
| 先生ID | 先生 | 教科 |
|---|---|---|
| １ | 高橋 | Java |
| ２ | 田中 | Python3 |
| ３ | 伊藤 | Java |
| ４ | 鈴木 | C# |
に表を分ければ大丈夫です。
#BCNFの定義
BCNFの定義は以下の通りです。
A→Bを表の任意の関数従属性としたとき、次のいずれかが成立する。
- A→Bは, 自明な関数従属性である。
- 決定項のAは, スーパーキーである。
（データベーススペシャリストより）
つまり先生→教科について、
この関数従属性は自明でない（教科は先生の部分集合じゃない）し、
先生はスーパーキーではないことからも、BCNFでないことはわかります。
#第３正規形の定義
一方で、第３正規形の定義は以下の通りです。
A→Bを表の任意の関数従属性としたとき、次のいずれかが成立する。
- A→Bは, 自明な関数従属性である。
- 決定項のAは, スーパーキーである。
- Bが候補キーの一部である。
（データベーススペシャリストより）
先生→教科を見ると、教科はキー属性なので、第３正規形であることがわかります。
#BCNFと第３正規形の違い
それは関数従属性が保存されないことです。
上で表を分けた際、
{学生ID, 教科}の組み合わせで先生が一つに決まる
という関数従属性が消えました。
#参考文献
- 山本森樹『2020 データベーススペシャリスト「専門知識+午後問題」の重点対策』株式会社アイテック, 2019年
- Boyce-Codd Normal Form (BCNF) | Database Normalization | DBMS（https://youtu.be/NNjUhvvwOrk）