実践的な正規化のルール

業務システムのための上流工程入門―要件定義から分析・設計まで」では、正規化されたテーブルの実践的な作成ルールとして、次の3つを提示しており、それぞれを具体的な例で説明すると次のようになる。
  1. 入れ子構造の解消

  2. この意味には2つある。1つは内部構造を持つフィールドは許されないといことである。たとえば、お客さんからのクレームを管理するシステムにおいて、クレーム受付番号を20071201043というような番号で管理するとする。番号には意味を持たせており、2007年12月10日の43番目に受け付けたクレームであることが番号を見てわかるようになっている。番号自身に日付の数字を含んでいること自身には問題はないが、クレーム受付番号から日付を取り出すことを前提にしたフィールド(内部構造を持つフィールド)を定義してはらなないということである。年月日が必要であれば、発生日という日付フィールドを用意せよということである。
     もうひとつは、レコードに繰り返しの項目を作ってはならないということである。たとえば、セミナーの参加者を管理するテーブルがあり、そのテーブルに参加者1、参加者2、参加者3・・・・・参加者100というような、同じ意味を表すフィールドを繰り返し定義することは駄目ですよということである。「100人分フィールドを用意すれば大丈夫だろう。」という考えのもとにテーブルを作ってはならないのである。この場合は、参加者を子テーブルとした参加者テーブルを用意すべきである。ただし、例外もある。同じ意味を表すフィールドの数が数件で上限が決まっているような場合は、あえて繰り返し構造を許す場合がある。
  3. モデル上で宣言されている以外の関数従属は存在しない

  4. 基本的な関数従属を見つけるのはそれほど難しくないが、背後に隠れている関数従属を見つけるのは難しい。たとえば、フィールドdがaとbとcの組み合わせに関数従属する場合(フィールドa,b,cを識別子とするテーブルがあり、属性フィールドにdがある)、aはbに関数従属してはならないし、その逆も関数従属してはならない。cがaとbの組み合わせに関数従属していてはならないなど、その他のあらゆる組み合わせについても同様に成立してはならないということである。
  5. 有効な識別子の網羅

  6. これは、識別子として定義されるべきものは必ず定義しなければならないということである。当たり前のようであるが見落としがちな識別としては、フィールドが1つで存在するテーブルがそのひとつである。たとえば、商品の注文を管理するシステムにおいて、一つの注文で商品は最大4つしか注文できないというケースを考える。通常、注文見出しテーブルと注文詳細テーブルがあり、注文詳細テーブルの識別子は注文番号+行番号が識別子となる。このとき、行番号をNumber型(Integer型)にすると5件以上登録できてしまう。そうではなく行番号テーブルを用意し識別子1~4までをインスタンスとして登録する。(属性フィールドは存在しない)
    ほかの例としては、組み合わせを管理するテーブルがそうである。靴を扱うシステムにおいて靴の商品コードと色の組み合わせのみを管理するテーブルでは、商品コード+色コードが識別子となり、属性フィールドは存在しない。ある靴Aは黒とブラウンがあるが、靴Bは黒しかないといった組み合わせを管理する。
一般的に実務では第三正規形で良いといわれるが、渡辺氏の書籍では完全正規形(第五正規形)にしないと使い物にならないらしい。この3つのルールに従ってデータモデルを作れば完全正規形(第五正規形)になる。

トラックバック

トラックバックURL:
http://www.apricot-jp.com/cgi/mt/mt-tb.cgi/332

関連情報

Copyright(C) 2007 アーキテクト360 Allrights reserved.