前に書いた、Hello World程度のデータベースのための準備として、思ったことをメモするコーナーです。
■第四、第五正規形について
ここがくわしい
第四正規形と第五正規形
http://itpro.nikkeibp.co.jp/article/lecture/20061128/255079/?ST=lecture&P=4
自分へのメモ：
第四正規形は、順番にやっていくと、多くは第一正規形でひっかかることを
書くかどうか、検討する。
■正規化をくずすとき
一般に、第二正規形は行うのですが、第三正規形は、行わない場合があります。
その理由は以下のとおりです。
１．（昔言われていた理由）第三正規化まですると、テーブルがふえ、検索が遅くなる
→いま、この考えの信憑性は？といわれている。
正規化をして、インデックスを多く張り、インデックスだけでＳｅｌｅｃｔしたほうが、
結果としては早くなるというのが、佐藤氏の考え
２．第三正規化まですると、テーブルがふえ、”更新が”遅くなる
インデックスが増えると、インデックスの書き出しもしないといけない。
なので、テーブルがふえると、遅くなる。
３．第三正規形を行ったあとで、仕様変更になった場合、手が付けられなくなる。
エンティティによって分ける第二正規形の場合、実体がある（エンティティがある）ので、
これが、なくなる可能性は低い（従業員が急になくなったり、商品がなくなることは、まずない）
一方、第三正規形は、関係によって成り立っている。たとえば、部署と内線番号の場合、部署が決まれば、内線番号が決まるといったとき、第三正規形として、部署テーブルを作成し、そちらに内線番号を持っていくこともできる。
しかし、この場合、部署が決まれば、内線番号が決まるという関係は、現時点の話であり、たとえば、「開発部に新人が入って大きくなったので、開発部は、内線を２つもつことにする」といって、部署と内線が、１対Ｎの関係になり、部署が決まっても（開発部と決まっても）、内線が決まらない（２本のどっちかわからない）っていう話は、あり得る。
また、逆のケースも考えられる。「今日からリストラ部というのをつくったけど、ウィリアムのいたずら１人だけ配属なので、開発部といっしょに、電話を使ってくれ」といわれたら、１つの内線番号で２つの部署、どっちかわかんなくなる。
つまり、もし、内線番号と部署の間に第三正規形が成立すると思って、元のテーブルに部署ＩＤだけを入れておいた後で、上記のように、その「関係」を崩す事態が起こったら。。テーブルをきりなおすことになる。
このように、第三正規形はエンティティの裏づけではなく、関係（１部署１内線）にもとづいて作成される場合があり、このようなケースでは、将来的なリスクを考えて、今、再三正規形にできても、あえてしないこともある。
自分へのメモ：
・データの説明から、３層スキーマにもっていって、概念スキーマから、
その作り方の方法として、正規化理論と、佐藤氏の方法を紹介する。
・データのところ、説明については、
ＮＡＳＡの命名言語、OF LANGUAGEのありかがわかったら、
書いておく（主要語（ドメイン）-分類語）
すみません。おもいつきをかいてるだけなので、意味通じないですよね。
ちゃんと、来年に入ったら、まとめますので、
こうご期待
アクセス
トータル
ランキング
