初めてのデータベース設計

第3回 リレーショナルモデルへの変換

この記事を読むのに必要な時間:およそ 2 分

第2正規形

第2正規形(Second Normal Form;2NF)は,テーブルが第1正規形であり,なおかつ,主キーである列の値によって主キーではない列の値が一意に特定できるテーブルのことです。

ある列の値によってその他の列の値が一意に特定できるという性質は関数従属性(Functional Dependency;FD)と呼ばれます。なお,複数の列からなる主キーの値が部分的に関数従属性をもつテーブルは,第2正規形ではありません。

たとえば,表2の第2正規形に変換する前のテーブル「注文明細」では,⁠注文番号」「製品番号」が主キーとなっています。しかし,⁠製品名」「価格」といった列の値は「製品番号」の値のみによって一意に特定することができます。そこで,部分的に関数従属性をもつ列を「製品」という別のテーブルとして分割することにより,表3のように第2正規形に変換することができます。

表3

注文

表3 注文

注文明細

表3 注文明細

製品

表3 製品

テーブルを第2正規形に変換することにより,データの冗長性の一部を減少させることができます。たとえば,⁠注文明細」から「製品」を別のテーブルとして分割すると,それまで「注文明細」に繰り返し出現していた「製品名」「価格」といった列の値が1行にまとめられます。

第3正規形

第3正規形(Third Normal Form;3NF)は,テーブルが第2正規形であり,なおかつ,主キーではない列が関数従属性をもたないテーブルのことです。

たとえば,表3の第3正規形に変換する前のテーブル「注文」では,⁠顧客番号」の値によって「氏名」「住所」⁠⁠電話番号」といった列の値を一意に特定でき,主キーではない列が関数従属性をもっています。そこで,関数従属性をもつ列を「顧客」という別のテーブルとして分割することにより,表4のように第3正規形に変換することができます。

表4

注文

表4 注文

顧客

表4 顧客

注文明細

表4 注文明細

製品

表4 製品

テーブルを第3正規形に変換することにより,データの冗長性や不整合の発生をさらに減少させることができます。テーブルを適切に第3正規形に変換すれば,関数従属性に関して不整合が発生することはほぼ解消されます。

なお,正規形にはこの他にも第4正規形や第5正規形,ボイス・コッド正規形といったものがありますが,これらの正規形では関数従属性が保持されないなどといったことから,正規化は一般的に第3正規形までに留めることが多いようです。


今回は,リレーショナルモデルへの変換について正規形に関する説明を中心に行いました。テーブルを正規化する手順や正規形に変換することによって,データの冗長性や不整合の発生を減少できることを,理解してもらえたと思います。

次回からは,データベースとしてオープンソースのPostgreSQLを取り上げ,列のデータ型として何を選択するべきかといったことなど,データベースで実際に管理するために考慮することについて説明していきます。

著者プロフィール

佐藤友章(さとうともあき)

SRA OSS, Inc. 日本支社 チーフエンジニア。入社以来,オープンソースデータベースPostgreSQLに関する業務に携わり,現在,PostgreSQLのサポートやコンサルティング,トレーニングの講師を務める。

URLhttp://www.sraoss.co.jp/

コメント

  • 間違うと思う

    「注文」と「製品」を多対1の関連
    ー>
    「注文」と「製品」を多対多の関連だと思う。

    注文    製品
    book注文 BOOK_1, book2

    book1注文 BOOK_1,book3

    私がまちがったら説明していただけば幸いです。

    よろしくお願いいたします。

    Commented : #1  dien (2015/03/03, 18:57)

コメントの記入