堀川です、こんにちは

-----Original Message-----
From: Tadashi Nakamura [mailto:who@example.com] 
Sent: Friday, February 08, 2002 12:46 PM
To: who@example.ne.jp
Subject: [ml-msde-beg:00054] Re: 正規化のこと


>ざっと読んでみたのですが、
>正規化とは要するに、デ−タの「冗長度」を低くする、というように
>理解してよいでしょうか。

データベースの設計に慣れていない段階では、『正規化』を意識
するよりは、『データの整合性の維持』や『メンテナンスのしやすさ』
を実現するためには、どのようなテーブル設計の工夫が必要なのか
を考えると良いでしょう。

そうすれば、おのずとテーブルは正規化されます。

例えば
             会社 {会社番号,会社名,住所}
             個人 {個人番号,会社番号,会社名,住所,個人名}
『会社』と『個人』の２個のテーブルがあったときに、個人のデータを
見るときは常に会社のデータも一緒に見たいという要求があるとします。
個人テーブルの中に会社情報を抱えてしまうという考えがあります。

この場合、個人のレコードを取り出せば、会社情報もわかるので
すばやくデータの閲覧ができるメリットがあります。
が、しかし、会社情報の変更があるときは、会社テーブルを修正し、
個人テーブルも修正しと大変な作業になります。

また１つの会社に複数人の個人が存在するときは、そのレコード分
だけ、会社情報の修正が必要です。

『データの整合性の維持』という観点から考えれば、データの
修整行為はできる限り最小にするのが良いわけです。
修正をし忘れると、整合性の維持ができません。

       データの閲覧が早いという利点を選ぶのか？
       データ整合性の維持が簡単になる方を選ぶのか？

これは開発しているアプリケーションの内容などにより決める
べきことになります。

まあ一般的には、個人テーブルの中には、会社番号だけを入れて
会社名などの情報は入れないようにする、参照整合性関係を
取り入れます（テーブルの正規化）。
これは、データの修正行為が簡単になる利点があります。




          主キー  コード1  コード2  コード3  値
というテーブル（５列構成）があり、それに応じたアプリケーション
を作ったとします。

　将来、もし、このテーブルに『コード4』という新しい列を追加
する可能性があるとしたら、その時点でアプリケーションの大幅
な変更が必要です。
　テーブルに列を追加するという行為は、大変な修正作業になります。

また、『コード1』と『コード2』と『コード3』に共通した値が入力される
としたら検索条件の作成では、
            コード1=値A  OR  コード2=値A  OR  コード3= 値Ａ
のようなOR条件を書くことになり、大変です。
将来、新しいコード列4が追加されたら、この検索条件も直さないと
いけません。

それだったら、

   最初のテーブルの主キーだった列  ,  列番号(1,2,3,4など） ,  コード

というテーブルを用意して、コード１,コード2,コード3に相当するもの
を番号1,2,3で表現します。
こうすれば、将来コードNという列が増えても容易に対応ができますね。

そして、値は、
                    最初のテーブルの主キーだった列  ,  値
で管理します。


このようにテーブルを設計すれば、

>「主キー、コード１、コード２、コード３、、、コードｎ、値」という
>Fields 構成の一つの Table の計ｎ＋１個の Table

コード番号が増えても容易に対応ができるし、検索条件の与え方も
簡単になります。

リレーショナルデータベースでは、後から列を増やすことは
避けるようにしてください。
レコード（行）は、いくらでも登録しても構いません。
可変個になりそうな列は、行の追加で逃げるようにしましょう。

このような工夫を日頃から心がけて下さい。

------------------------------------
（株）日本技術ソフト開発
  　    　堀川　明  (Akira Horikawa)
    ０２月０８日（金曜日）　１４時１４分記
        mailto:who@example.ne.jp
        http://www.horikawa.ne.jp/msde/