Tweet

■ボイスコッド正規形（BCNF：Boyce-Codd Normal Form）

　ボイスコッド正規形は、第3正規形で非キー属性からキー属性に関数従属性がある場合に、これを取り除くことで得られます。

図5　ボイスコッド正規化 ボイスコッド正規化は「非キーからキー」への関数従属性を排除する。

　ただし、ボイスコッド正規形は第3正規化までと違い、注意しなくてはならない点が2つあります。

• 間違った分解を行うと結合従属性を失う
• 元のテーブルにあった関数従属性を失う

　具体例として表2を見てみましょう。学生がある科目を履修するとき、下記の条件があったとします。

• 学生と科目が決まると講師が決まる（1科目を複数の講師から教えられることはない）
• 1人の講師は1科目だけを担当する。同じ科目を担当する講師は複数いる
• 1人の学生は複数の科目を履修する

　表2はボイスコッド正規形ではないため下記の問題点があります。

• 学生が科目を履修しないと、講師が科目を担当するという情報を登録できない
• 講師が担当する科目を変更したとき、重複更新が発生する
• 学生の履修情報を削除すると、講師が科目を担当する情報も削除される

　このテーブルには「｛学生, 科目｝→講師」「講師→科目」の2つの関数従属性があります。このテーブルは第3正規形ですが、「講師→科目」という、非キーからキーへの関数従属性があるのでこれを取り除きます。

表2　ボイスコッド正規化の対象となるテーブル

　では分解してみましょう。表3のように考えた方もいるのではないでしょうか。しかし、この2つのテーブルを結合しても元のテーブルに戻らずに、どの学生がどの講師の科目を履修していたのか分からなくなってしまいます。これが注意点の1つ目「間違った分解を行うと結合従属性を失う」です。結合従属性を失うとデータの整合性が失われてしまいます。

表3　結合従属性を失う間違った分解

　それでは結合従属性を失わないように分解するにはどうしたらいいでしょうか。元のテーブルと関数従属性をよく見てください。このテーブルのキーは｛学生, 科目｝ですが、｛学生, 講師｝もキーにすることができそうです。こちらをキーにすると「講師→科目」（「キー→非キー」）という部分関数従属性を含む、第1正規形になります。この部分関数従属性を取り除いて第2正規化を行うと表4のように分解できます。このテーブルを結合すると元のテーブルに戻ります。

表4　結合従属性を維持した分解

　これでボイスコッド正規形が得られたのですが、テーブルを分解する前にキーを変更したことによって、もともとあった「｛学生, 科目｝→講師」という関数従属性が失われてしまいました。テーブルのデータが現状のままであれば問題ないのですが、表4の中央のテーブルに「学生：佐藤」「講師：宮本先生」という行が追加されたとしてこのテーブルを結合すると、表5となり、佐藤くんが同じ科目を違う講師で履修することになります。

　元の表2では、｛学生, 科目｝がキーになっているために、このようなデータは登録できないのですが、ボイスコッド正規形にしたことで登録できるようになります。これを避けるには、正規化以外の方法、例えばテーブルの制約や、アプリケーションプログラムによるバリデーションルールの実装が必要となります。これが注意点の2つ目「元のテーブルにあった関数従属性を失ってしまう」です。

表5　以前は登録できなかったデータが登録できる

ボイスコッド正規化が不要になる条件とは？

　この例では「1人の学生が同じ科目を異なる講師で履修できない」というビジネスルールがテーブル構造から失われてしまいました。こういったビジネスルールをテーブル構造に持たせ過ぎるとボイスコッド正規化が必要になります。

　この例の最初に指定された条件はすべてビジネスルールと考えられます。これらはビジネスの都合により変更される可能性が大いにあります。例えば、学生は科目を選択するだけで講師を特定する必要がなくなったり、1人の講師が複数の科目を担当できるようになることは十分に考えられます。

　稼働しているシステムのテーブル構造を変えるのは非常に大変な作業です。できればこういったビジネスルールはテーブル構造に実装するのではなく、アプリケーションプログラムとして実装した方が保守性の高いシステムとなります。

　この例でビジネスルールを排除し、下記のデータの関連性だけに注目すると、表6のようなテーブル構造になります。

• 学生は科目を履修する
• 講師は科目を担当する
  

表6　データの関連性に注目したテーブル

図6　表6のER図（ビジネスルールが排除されている）

　このように、正規化を行う以前の設計でビジネスルールが排除されていて、このようなテーブル構造を示唆する図6のようなER図が描かれていれば、ボイスコッド正規化が行われることはありません。もし、ボイスコッド正規化が必要になったら、必要なビジネスルールやデータの整合性か失われていないか、注意深く確認してください。

3/4

Index
連載：データベースエンジニアへの道（3） 　素早く正規形を見抜く実践テクニック
	Page 1 ・はじめに ・正規化の位置付け ・正規化の目的
	Page 2 ・第1正規形（1NF） ・第2正規形（2NF） ・第3正規形（3NF）
	Page 3 ・ボイスコッド正規形（BCNF：Boyce-Codd Normal Form）
	Page 4 ・第4、第5正規化の対象となるテーブルの特徴 ・第4正規形（4NF） ・第5正規形（5NF／PJNF） ・まとめ

データベースエンジニアへの道

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）

RSSフィード