http:www.sip-ac.jp/sip/konan_text/dbm04-04.html,        © 2001 Ayumi Yoshikawa
主観情報処理研究所

データベースマネジメント:正規化(最終更新:2015/12/06 16:33:44 JST)

正規化(その4)

BC正規形(教科書54ページ)

不要な関数従属性の解消(教科書54ページ)

第3正規形までで最低限の関係データベースとしての要件を満たすことは既に説明した.しかし,第3正規系でもデータ登録や更新に問題が生じる場合がある.その場合にはさらに高次の正規化を進める必要がある.まずボイスコッド正規形(Boyce-Codd normal form)から取り上げる.ちなみに,BoyceさんはSQLの開発者で,Coddさんは関係データベースの考案者である.

BC正規形は,属性項目から候補キーへの不要な関数従属性を解消するプロセスである.教科書55ページの[受講]テーブルの例は{受講者名,セミナー名}が複合主キーで<講師名>がデータ項目であるので第3正規形の要件を満たしている.この[受講]テーブルの<講師名>に新しい講師を追加しようとする.担当するセミナーが決まったとしても,受講者が現れるまで登録できないことになる(∵受講者名は主キーの一部なのでヌルは許されない).

{受講者名,セミナー名}→講師名
講師名→セミナー名

これらの関係{A, B}→C,C→Bを一般的に図示すると次の図のように表すことができる.

図を表示するためにはSVG対応ブラウザを使ってください

BC正規系への変換は複合主キー{受講者名,セミナー名}の代わりに,複合主キーを{受講者名,講師名}として一つのテーブルを作り,別テーブルとして<講師名>を主キー,<セミナー名>をデータ項目としたテーブルを作成すればよい.なお教科書55ページの表の変形例は誤りである.

{受講者名,講師名}
講師名→セミナー名

次のような例を考えてみてみる.[学生の受講]テーブルでは{学生番号,科目C}が複合主キーとなる.しかしながら<担当者C>から<科目C>に関数従属性がある.したがって,{学生番号,科目C}と担当者C→科目Cの2つのテーブルに分割することでBC正規形に変換できる.

[学生の受講]
学生番号科目C担当者C
1100176
1100286
5100174
6100286
[受講科目]
学生番号担当C
176
186
574
686
[担当科目]
担当者C科目C
741001
761001
861002

参考文献

一般的に不要な関数従属性となるものは次のように表せる.

例えば,複合キー{d1,d2},属性項目<d3>,<d4>からなるテーブルでは,{d1,d2}→d3と{d1,d2}→d4だけが成立し,その他は成立してはいけない.上記の規則に照らして,違反するものは下の通り.

  1. d1→d3,d1→d4,d2→d3,d2→d4(部分関数従属性)
  2. d1→d2,d2→d1
  3. d3→d4,d4→d3(推移関数従属性)
  4. {d1,d3}→d4,{d1,d4}→d3,{d2,d3}→d4,{d2,d4}→d3
  5. d3→d1,d3→d2,d4→d1,d4→d2,{d1,d3}→d2,{d1,d4}→d2,{d2,d3}→d1,{d2,d4}→d1,{d3,d4}→d1,{d3,d4}→d2,{d1,d3,d4}→d2,{d2,d3,d4}→d1

[*]下へ▼ ▲[#]上へ

第4正規形(教科書55ページ)

多値従属性(教科書55ページ)

教科書55ページの[受講]テーブルでは,各行は{セミナー名,講師名,受講者名}の複合キーにより特定される.ここで{セミナー名,受講者名}と<講師名>の関係を見てみると,<講師名>は<受講者名>によらず<セミナー名>のみで決定される.このとき「セミナー名→→講師名」と表し,<講師名>は<セミナー名>に多値従属であるという.また他方,<セミナー名>と<受講者名>も<講師名>によらず決定される.同様に「セミナー名→→受講者名」と表し,多値従属であるという.この場合,セミナー名は同時に多値従属性が成り立ち,「セミナー名→→講師名|受講者名」と表す.このように複数の候補キーが1つの候補キーに同時に多値従属する場合を「対称性のある多値従属」あるいは「自明でない多値従属」と呼ぶ.

セミナー名→→講師名
セミナー名→→受講者名
が同時に成立
セミナー名→→講師名|受講者名

対称性のある多値従属性が存在する場合,例えばセミナー名と講師名だけを追加することやセミナー名と受講者名だけを追加することはできない.

次のような例を考えてみる.

テーブル[受講と資格]は複合キーとして{学生番号,科目名,資格名}を持っている.

[受講と資格]
学生番号科目名資格名
1001監査論簿記2級
1001簿記論簿記2級
1001監査論システム監査技術者
1001簿記論システム監査技術者
1002財務諸表公認会計士短答式
1002監査論公認会計士短答式

上記のテーブルで,例えば<学生番号>と<科目名>に着目すると,<資格名>に依存せずに<学生番号>が決まれば<科目名>が決まる.すなわち「学生番号→→科目名」.同様に<学生番号>と<資格名>も,<科目名>に依存せずに<学生番号>が決まれば<資格名>が決まるので,「学生番号→→資格名」.よって対称性のある多値従属性が存在している.

[*]下へ▼ ▲[#]上へ

第4正規系への変換(教科書56ページ)

第4正規形(forth normal form)への変換は,対称性のある多値従属性の解消することである.教科書55ページの[受講]テーブルは,それぞれ[講師]と[受講者]テーブルに分割してやることで対称性のある多値従属を解消することができる.

上の例の場合は次のとおり.

この例のテーブル[受講と資格]は2つのテーブル[受講]と[資格]のそれぞれに分割することで変形できる.

[受講]
学生番号科目名
1001監査論
1001簿記論
1002財務諸表
1002監査論
[資格]
学生番号資格名
1001簿記2級
1001システム監査技術者
1002公認会計士短答式

[*]下へ▼ ▲[#]上へ

第5正規形(教科書56ページ)

結合従属性(教科書56ページ)

結合従属性とは,あるテーブルから列の組を取り出してテーブルを作ったときに,それらのテーブルの自然結合で元のテーブルに戻ることを指す.例えば教科書57ページの[受講]表を[講師]表と[受講者]表に分割したとする.このとき分割した[講師]表と「受講者]表の自然結合してやると,元の[受講]表になかったレコードが現れる.

[*]下へ▼ ▲[#]上へ

第5正規形への変換(教科書57ページ)

教科書57ページの[受講]表は結合従属性を保つように分解するためには,先の[講師]表と[受講者]表に加えて,[セミナー]表が必要となる.この3表に分解することで結合従属性を保ち分解が可能となる.これを第5正規形(fifth normal form)と呼ぶ.

例えば次のような例を見てみる.

テーブル[科目とコース]は3つの識別子からなる複合キーである.<学生番号>に対して<科目名>,<希望コース>とも独立に定めることができないため,このテーブルは第4正規形になっている.

[科目とコース]
学生番号科目名希望コース
1001簿記会計士
1001財務諸表会計士
1001税務税理士
1002簿記会計士

ここで,識別子を2つずつ組み合わせたテーブルをそれぞれ考える.

{学生番号,科目名}の[履修科目],{学生番号,希望コース}の[コース希望],{科目名,希望コース}の[コース設計]はそれぞれ次のようになる.

[履修科目]
学生番号科目名
1001簿記
1001財務諸表
1001税務
1002簿記
[コース希望]
学生番号希望コース
1001会計士
1001税理士
1002会計士
[コース設計]
科目名希望コース
簿記会計士
財務諸表会計士
税務税理士

なお3つのテーブルを自然結合という演算により合成すると元のテーブルが得られる.

[履修科目]と[コース希望]を学生番号が等しいという条件で自然結合した結果は次のようになる.

自然結合結果
学生番号科目名希望コース
1001簿記会計士
1001簿記税理士
1001財務諸表会計士
1001財務諸表税理士
1001税務会計士
1001税務税理士
1002簿記会計士
[コース設計]
科目名希望コース
簿記会計士
財務諸表会計士
税務税理士
[科目とコース]
学生番号科目名希望コース
1001簿記会計士
1001財務諸表会計士
1001税務税理士
1002簿記会計士

このテーブルと[コース設計]を{科目名,希望コース}が等しいという条件で自然結合すると,上記のテーブルのレコードの内で,[コース設計]のレコードと等しいものだけが残ることになり,元の[科目とコース]に一致する.

第5正規形の特徴は,例えば第4正規形の[科目とコース]では,科目名とコースの組合せだけを追加することはできない.つまり3つのデータ項目の組合せがそろわないとデータベースに登録することができない.しかし第5正規形であれば,例えば科目名:IT基礎,コース名:ITを受講者の有無に関わらず登録することができるメリットがある.

参考文献

[*]下へ▼ ▲[#]上へ

このサイトに関するお問い合わせは,連絡先のページをご覧ください.

このページのボトムへ講義資料このページのトップへ

前のページに戻る  1  2  3  4  次のページへ進む   データベースマネジメントの目次に戻る ,        © 2001 Ayumi Yoshikawa