■ 正規化について
設計がうまく作れてないと必要以上にシステムの作成期間が
長くなります。
設計次第でシステムが決まると言っても過言ではありません。
多少時間をかけても構わないと思います。
シンプルな設計を心がけましょう。
データーベースを設計するには、どのような表の集合体にするかです
表のデータ間の意味的な関係に注目して、できる限り不必要な項目の
重複がないような表に分割していくことを正規化といいます。
では、わかりやすく簡単に記述します。
正規化には、第１正規化、第２正規化、第３正規化などがあります。
１．第１正規化
繰り返しのグループを取り除きます。
例えば売上伝票は、売上トランと売上明細トランで構成
されているとします。
売上トランが１に対して、売上明細トランは複数あります。
つまり、売上明細トランは繰り返しのグループとなります。
それを分離させます。
「売上トラン」 「売上明細トラン」
売上伝票番号（主キー） 売上伝票番号（主キー１）
売上日付 商品コード（主キー２）
得意先コード 商品名
得意先名 数量
担当者名 単価
＊売上明細トランの売上伝票番号（主キー１）、商品コード
（主キー２）を合わせて複合キーと呼びます。
２．第２正規化
売上明細トランの複合キーの一部（ここでは、商品コード）にのみ
関係従属しているデータ項目を取り出して別の新しい表を
作成し分離する。
＜＜正規化前＞＞ ＜＜正規化後＞＞
「売上明細トラン」 --------> 「売上明細トラン」
売上伝票番号 売上伝票番号
商品コード 商品コード
商品名 数量
数量
単価
I-----------------------> 「商品マスタ」
商品コード（主キー）
商品名
単価
３．第３正規化
主キー以外（ここでは、得意先コード）に、データ項目同士に
従属関係がある場合、それを分離する。
＜＜正規化前＞＞ ＜＜正規化後＞＞
「売上トラン」 -----------> 「売上トラン」
売上伝票番号 売上伝票番号
売上日付 売上日付
得意先コード 得意先コード
得意先名
担当者名
I------------------------>
「得意先マスタ」
得意先コード（主キー）
得意先名
担当者名
第４正規化もありますが、今回は説明を省きます。
第３正規化までできればよいと思います。
では、正規化すればどうなるのか。
そのメリットとデメリットとは。
＊メリット
・重複を排除できてデーターベースを小さくできる。
・全体の整合性を高める。
・データの更新、追加、削除を効率化できる。
＊デメリット
・検索処理には適さない。
・正規化しすぎるとわかりにくい。
・正規化しすぎてスピードが落ちる場合がある。
＜まとめ＞
正規化は、更新処理を主とした処理の効率化を重視した考え方です。
とにかく、正規化に努めればよいというものではありません。
つまり、細かく分割さえすればよいとはいえません。
分割されたテーブル同士をリレーションで連結します。
が、テーブルを正しく正規化されていて、なおかつリレーションも
うまく結合されているはずなのにレスポンスが遅いと感じる事が
あります。
これを回避する場合、結合の数を減らすなどの処理をします。
あまりにも、正規化にこだわり過ぎるとこのような結果を招くわけです
安易な設計もいけませんが、正規化にばかりこだわりすぎるのも
考えものです。
正規化も適度に。
===================================================================
◆
実践テクニック、Accessで作るクラサバシステム ◆
Accessの扱い方を教わるには、システムの完成品から学ぶのが一番
編集・構成：高橋浩
提供・発行：ティウェア
http://www.1tware.com/index.html
Access2000+MSDE2000、Access2002+MSDE2000、Access2003+MSDE2000で
作る販売管理ソフト、クライアントサーバーシステムを構築
※当メールマガジンに掲載された記事を許可なく転載することを禁じます。
===================================================================
実践テクニック、Accessで作るクラサバシステム（隔週 火曜日発行中）
ＳＥが１０年以上の開発ノウハウを惜しみなく完全公開！
|