プロが教えるわが家の防犯対策術!

第3正規化ってどういう条件でやるものなのでしょうか?

http://su10.sgu.ac.jp/~morita/Seminar/6thStudent …

上記だと第3正規化でGenre_nameを分離していますが、
Genre_codeで定まる値が一つならGenre_codeをなくしてGenre_nameをCinemaに直接書いても大差ないように思えます。
(Genre_codeに従属している項目が複数だったらやるべきだと思いますが)

現在テーブルを作成しているのですが、
上記のようにコードをつけて分離しようと思えばできる項目が複数あり、
やるべきかやらざるべきかで悩んでおります。

基本的にやれるところはやった方がいいのでしょうか?
(個人的にはテーブルが増えると管理が面倒なのでコードにするにしても、
参照するプログラム側で連想配列でも持たした方が楽かなと思っているのですが)

A 回答 (3件)

 追加でもう一点。


 データベースシステムを利用する、最大の動機と利点は、複数のアプリケーションで、同じデータを扱う時に、統一した方法で同じデータをアクセスできるということです。
 この目標を達成するためには、データそのものがもつ性質は可能な限りデータベースだけで実現しなければなりません。データの整合性もそのひとつですし、データの制約もそうです。(例えば、数値は正の数値であるはずとか、この項目は絶対に定義されていなければならないとか、そういった類の指定です。)
 従って、「(個人的にはテーブルが増えると管理が面倒なのでコードにするにしても、参照するプログラム側で連想配列でも持たした方が楽かなと思っているのですが)」という発想はやめましょう。これをやると、総てのアプリケーションが、この約束を守るための同じコードを書かなくてはならないと言うことになります。これは、最初の目標に背を向ける行為ですから。

 これにより、考え方として、もう一つ追加しておきます。
 データのチェックや処理ロジックにまつわる事項は、可能な限りデータベース側で実現できるように考えてください。単純な値のチェックはもちろんのこと、データの抽出や選別・集計などはSQL文で行うことを前提にすることです。
 
 最後に、「上記のようにコードをつけて分離しようと思えばできる項目が複数あり、やるべきかやらざるべきかで悩んでおります。」の基準ですが、現実世界で、単独で存在し得る事項はコードをつける価値があると思ってください。(もし、今は必要ないが、実は、もっと項目がある可能性がある場合には、分ける価値がある可能性が高いです。例えば、人名。今は必要なくても、人名テーブルには性別や生年月日など他の項目がつく可能性があります。)
 元の事例に戻ると、Genre_nameは単独で存在し得ますね。「SF」とか「ラブストーリー」とかは、なにも映画の世界に依存する分類項目ではないです。一方、これは極端な例ですが、w_dateは、この項目単独では価値がありません。
 こう考えれば、少し解決の導入になるかもしれません。
    • good
    • 0
この回答へのお礼

お二方の意見を読ませていただき、
将来的なことも考えてコードをつけての第3正規化をやることにしました。

面倒くさいからやらないとかはDBの整合性とかを考えたらなしですね。

回答ありがとうございました。

お礼日時:2009/05/11 17:59

 正規化の必要性の第一の側面が、No.1の方が言われるようにデータの整合性をデータベース内で保つことです。

この副作用として、データの拡張性も手に入れることができます。
 このテーブルだけを見るならGenre_codeを無くせば、遷移従属性も無くなり第3正規性を手に入れることができます。ところで、例えば、書籍データも整理しようとしたら、どうしましょうか?似たような項目もあるでしょうが違う項目もありますから、まず、別テーブルを構築することになるでしょう。でも、Genre Tableはそのまま使えそうですね。映画も書籍も、まぁ、この手の分類項目は似たような物ですから。
 ちゃんと正規化しておくと、このようなデータの転用が容易にできるようになります。さらに、映画と書籍の関連性も設計が可能になります。Genre_codeを無くしてしまえばという手を使った時にはできなかったことです。

 さて、理論的に考えれば、正規化はできる限り上位の正規化を、最低でも、第3正規化までは行うべきとされています。これは、無限の資源があればの話。
 現実のシステムでは、CPUパワーは有限の資源ですし、人間の時間も有限です。
 そして、正規化を行うことによりテーブルを分けると言うことは、データを使う時に、テーブルを結合する必要があると言うことを意味します。この結合にかかるコストが大きすぎる時に、最適化の作業として、もう一度テーブルを統合するがあります。
 ただし、このテーブルの統合も、正規化を崩すことによるデメリットと、手に入れられる性能を充分に比較考慮した上で、さらに、他に方法が無いかを検討した上で行うこととされています。それほどに、データの整合性をデータベースに任せられるという価値は大きいと言うことです。
    • good
    • 0

・アクション、ラブストーリー、SF以外のジャンルが登場したら?


・SFを「サイエンスフィクション」に変更したい言われたら?
・ジャンルに「ラブストーリ」「Action」などと入れさせないようにするには?
・ジャンルコードの一覧を表示するには(まだ1件も登録がないものを含む)?
上記のようなニーズをすべてデータベース内で解決しようとするアプローチが正規化です。
楽をするためにやるのではなく、必要最小限の処理で整合性を保てるようにするためにやるものですね。

分けるかどうか迷ったら、上記のようなニーズが発生したときのことを考えれば判断できるかなと思います。

プログラム側で値を持つということは、その項目については、ある意味データベースでの整合性管理をあきらめたということです。
(データベースを見ても、構造やコードの意味が分からない)
    • good
    • 0

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!