リレーショナルモデルの正規化 (ja)

(カテゴリに反してOracleと直接関係ありませんがご容赦下さい)

データベースのテーブルを正規化するとき、どこまで正規化を進めればよいのでしょうか? 国内の多くの情報源(特にネットのコラム)では第3正規形までで止めておくべきという意見が多数を占めているようです。これに対してリレーショナルデータベースの権威である Christopher J. Date (RDBの父 Edgar F. Codd の片腕であった人物です)は、その著書において正規形の数は大きほどよいと主張しています。すなわち現時点では第5正規形にするのがベストということになります。

筆者は Date の主張を全面的に支持しますが、中でも Date が重視しているボイス・コッド正規形と第5正規形について説明しましょう。

1. ボイス・コッド正規形
ボイス・コッド正規形 Boyce/Codd Normal Form とは、第3正規形を別の視点から再定義したものです。従って、世の中で第3正規形と呼ばれているものは、(ごく一部の例外を除いて)ボイスコッド正規形と等価です。

ボイス・コッド正規形:
関係変数 R は、R によって満たされるすべての非自明な関数従属性 A → B が R の上位キーである場合にのみ、ボイスコッド正規形である。

ここで関数従属性という言葉が出てきますが、これは例えば次のようなことをいいます。

関係変数 R が生の学籍情報を表すものとします。R の属性には学籍番号、氏名、学科、住所があるとしましょう。ここで、学籍番号が決まると氏名も一意に決まります。これを関数従属性 { 学籍番号 } → { 氏名 } と呼びます。この例では同様に、{ 学籍番号 } → { 学科 } 、 { 氏名 } → { 住所 } などが存在します。
この関係変数 R には、{ 学籍番号 } → { 学籍番号 } 、 { 学籍番号, 氏名 } → {氏名} などのような関数従属性も存在します(学籍番号が決まれば、学籍番号が決まるのは当然ですよね)。このような(わかりきった)関数従属性を「自明」な関数従属性と呼びます。最初に挙げた例はいずれも自明でない関数従属性です。

もう一点、上位キーについて説明が必要ですが、その前に候補キーについて説明しなければなりません。

候補キー:
K が関係変数 R の見出しの部分集合であるとすれば、K は以下の特性を両方とも有する場合に限り、R の候補キー(または単にキー)である。
  • 一意性 - R が取り得る値に、K の値が同じである2つの異なるタプルが含まれることはない。
  • 既約性 - 一意性を持つ K の真部分集合は存在しない。
リレーショナル理論では候補キーは複数存在することができ、その1つを「主キー」とします。一方でRDBMS実装は候補キーに当たる存在を1つしか許容せず、候補キー=主キーとなります。

前置きが長くなりましたが、上位キーとは候補キーを含む集合のことを言います。先の学籍情報の例でいうと、候補キー { 学籍番号 } について、例えば上位キー { 学籍番号, 氏名 } が存在します。

以上のことから、ボイス・コッド正規形の定義は実務上、次のように言い換えることができます。
  • 主キーが決定すればすべての属性が決定する。
  • 主キー以外の属性は、それが決定したとしても他の属性は決定しない。
繰り返しになりますが、世間一般で第3正規形と呼ばれているものは、ごく一部の例外を除いてボイスコッド正規形を満たします。逆説的な言い方をすれば、第3正規形を満たすがボイスコッド正規形を満たさないケースはその設計に誤りがあることになります。

2. 第5正規形
第5正規形は、現時点で確定している最終正規形となります。データベース設計において本来目指すべきところはこの第5正規形と言えるでしょう。まずは定義を示します。

第5正規形:
関係変数 R は、R によって満たされる自明でない結合従属性がすべて R の上位キーによって暗示される場合に限り、第5正規形である。

またまた難しい用語が出てきました。まずは結合従属性という言葉ですが、関係変数 R と、関係変数 R の部分集合である A, B, ..., Z の射影の結合(=JOINしてDISTINCTした結果の全フィールドと考えて良いです)が一致している場合をいいます。このとき、R は結合従属性 ☆ { A, B, ..., Z } を満たす、という言い方をします。
先の学籍情報の例でいうと、R が学籍番号、氏名、学科、住所ですから、少なくとも関数従属性 { 氏名 } → { 住所 } が成り立ちます。ここで R の部分集合 A を { 学籍番号、氏名、学科 } 、 B を { 氏名、住所 } とすると、A と B の射影の結合は 学籍番号、氏名(重複は省かれる)、学科、住所となり、R と一致します。従ってこの場合 R ☆ { A, B } が成立します(※R の2つのサブクエリ、{ 学籍番号、氏名、学科 } と { 氏名、住所 } を自然結合(NATURAL JOIN)するイメージです)。

自明な結合従属性は、例えば関係変数 R に対して ☆ { R } のようなケースを指します。また、結合従属性が上位キーによって暗示されるとは、R の部分集合 A, B, ..., Z がそれぞれ R の上位キーあることを意味します。

以上から、第5正規形は実務上、次のように言い換えることができます。
  • すべての属性について、主キーが決定すれば、その値が決定する。
  • 上記より複合主キーはその存在を許されない。

3. なぜボイス・コッド正規形と第5正規形が重要なのか?
まず、国内の情報源の多くが第3正規形を支持する一方でボイス・コッド正規形を敬遠する理由を述べましょう。すなわち、すべての第3正規形は第2正規形(さらに第1正規形)に非正規化できるが、ボイス・コッド正規形はすべてが第3正規形(またはそれ以下)に正規化できるとは限らないという点です。それは一見正しいようにも見えますが、実際には第3正規形の論理的欠陥に対する認識がないだけなのです。

また、非正規形→第1正規形→第2正規形→第3正規形と決まった手順で正規化を行う現場のやり方にも問題があります。筆者のこれまでの経験では、要求定義にブレがなければ直接ボイス・コッド正規形(あるいは第5正規形)で設計することが可能でした。その域に達するには相応の知識と経験が要求されますが、むしろそれを持たないエンジニアが悪いデータベース設計を行うことの方が危険と言えます。

さて、このエントリの締めくくりとして、ボイス・コッド正規形と第5正規形に関するある定理をご紹介します。これまでの長々とした説明は、すべてこの定理のためのプロローグなのです。

定理:
R がボイスコッド正規形の関係変数であり、複合キー(複数の属性からなるキー)を持たないとすれば、R は第5正規形である。


(参考・引用文献)

データベース実践講義―エンジニアのためのリレーショナル理論―
C. J. Date / 株式会社クイープ訳
オライリー・ジャパン、2006年2月
ISBN 978-4873112756

SQLのテクニックではなく、Oracle その他RDBMSの管理ノウハウでもなく、純粋にリレーショナル理論を学びたい人にお薦めします。ハイレベルですが、読破した暁にはデータベースに対するイメージが全く異なっていることでしょう。