第３正規化とは何でしょうか

質問

データベースの第三正規化がよく分かりません。
第二正規化との違いがよく分かりません。

第２→主キーの一部に従属する項目を分離
第３→主キーに従属しない項目を分離
という説明があったり
（このテキストでは、主キーを常に複合キーとしているようであり、その複合キーの（２つとして）どちらかを主キーとする表をつくるのが２で、その複合キーのどちらとも関係しない列を主キーとする表を３としているようなのですが、そもそも主キーは複合キーとは限らないはずだと思うのですが・・）

別のテキストでは（ある基本情報技術者試験のテキスト）
第２→関数従属
第３→推移的関数従属
という説明があったりします（推移的関数従属というのをネットで調べてみましたが、その概念がここでどう当てはまるのか分かりません）

このへん教えていただけませんでしょうか？
あるいは、分かりやすくある程度体系的に教えているページや本があれば教えてください。

回答No.3

hue2011

むつかしいことだと思うから疑問になるんです。ことはシンプルです。

たとえば販売記録があるとしますね。
日付　2018/10/20 12:22:45
バーコード　49xxxxxxxxxxx
販売品　マヨネーズ
単価　　230
数量　　　２
合計　　460
税　　　 36
総計　　436
お預かり　1000
おつり　　　564
これだと冗長で管理しずらいから、項目名は抜き出し、タイトルにして

日付,バーコード,商品,単価,数量,合計,税,総計,お預かり,おつり
2018/10/20 12:22:45,49xxxxxxx.マヨネーズ,230,２,460,36,436,1000,564

このように考えることが第一正規化ですね。これをすると、2枚目以降のデータは数字と文字だけであってタイトルは意識しないですみます。

ただ、同じバーコードのマヨネーズは何度も売る可能性があり、こういう記録は冗長です。

日付,バーコード,数量,合計,税,総計,お預かり,おつり564
2018/10/20,49xxxxxxxxxxx,２,460,36,436,1000,564

バーコード,商品名,価格
49xxxxxxxxxx,マヨネーズ,230

という風に2つの管理部分にわけるといいでしょうね。これが第二正規化です。

ところで、数量により合計金額とか消費税とか総合計金額なんていうのは自動的にだせますね。データ保持する理由がありますか。また、預かったお金でおつりを出すのも、簡単に出せる話ですね。
そこで
日付,バーコード,数量,お預かり
2018/10/20,49xxxxxxxxxxx,２,1000

バーコード,商品名,価格
49xxxxxxxxxx,マヨネーズ,230

としても、別段業務に差し支えないし、間違って余計なデータを破壊することもなくなりますね。
これが第三正規化ということになります。

一番わかりやすいようにあっさり説明したものがこうなります。

参考URL：

https://high-programmer.com/2017/10/21/db-normalization-difference/

お礼

ありがとうございます。第三のご説明については、数値の集計データはデータとして保存しないという一般論は分かりますが、テキストで出てくる第三正規化はまた別の趣があるようで、なかなか理解できないのです。リンクもなかなか難しいです・・どれもある程度はしょってしまっているようで、私自身、正式なデータベースの理論のテキスト（資格試験用とかのテキストではなく）をきちんと学ばないといけないような気がしています。

回答No.2

noname#251548

第二正規化については、次のようなファイルでしたら店舗コードが単体に主キーになります。

・店舗コード
・店舗名
・地域コード
・地域名
・店長コード
・店長名
・累計売上額

この例と先の説明で考えてみてください。

みっともない回答となってしまいました。ごめんなさい。

回答No.1

noname#251548

私も第二正規化と第三正規化の違いがなかなかわからず苦労しました。
私なりの理解で説明します。

先に第三正規化を理解した方がわかりやすいと思いますので、第三正規化から先に説明します。
データベースにおいて項目の従属でよくあるのか「コード」と「名前」ですよね。
例えば店舗コードと店舗名、商品分野コードと商品分野名、商品コードと商品名、といった「コード」と「名前」がよくあります。

会社全体の日別の売り上げファイルがあったとして
・日付
・店舗コード
・商品分野コード
・商品コード
・売上額

コードさえあればそれぞれに名前は各名前ファイルから調べる事が可能なので、このファイルのレコードには各名前を入れる必要はないですよね。
このように、「名前」を【【全て】】排除した状態が第三正規化です。

【【全て】】と強調したのは、全てではなく一部の名前を排除した状態なのが第二正規化だからです。
第二正規化で排除されている一部に名前とはどれか・・・それが、主キーの従属している名前の項目です。
各店舗ごとのこれまでの全累計売り上げファイルがあったとして
・店舗コード
・店舗名
・商品分野コード
・商品分野名
・商品コード
・商品名
・売上額
・累計売上額

このファイルの場合は店舗コードが単体の主キーです。
この状態から主キーに従属している店舗名【だけ】を排除したのが第二正規化の状態です。
第二正規化では商品分野名や商品名はまだ排除しません。
第三正規化までする場合には商品分野名や商品名も排除します。

以上でわかりますでしょうか・・・？

お礼

確かにこの見方でだいぶすっきりするように思われます。
全てを１つの表にしたあと、その表の主キーを考える。
売上のデータでいくと、上記ですと、おそらく（解説とは変わりますが）店舗コード×商品コード（あるいは実際的には　×売上日　が付く）　が複合主キーになるのではないでしょうか。
これに対して売上コードという単一の主キーを立ててもよいかと思います。
要するにそれ以上細分化できない（する必要のない）最小の各データ（行）に対して、一つ一つ割り振られたコードになります。
このコード（の生成）に直接かかわるような店舗コードと商品コードが、第二正規化で扱われ、別表化されることになる表の主キーであり、それ以外の商品グループコードという、あってもなくてもよいような、（仕事上は重要であるかもしれないが、データベース体系的には重要ではない）データで、主キーを立てて別表化できるものを、別表化するのが、第三正規化ということで、とりあえず考えておけばよいのかと理解しました。
おそらく、原始的なデータを集めて作成したデータベースを考えたとき、そのデータベース（１つの表）はどんな区別をもとに、単一の個々のデータ（個々の行）になっているのか？　という問いに対して、常にどれかとどれかの列（２つか３つ）の、組み合わせとして主キーが立てられるということになっているのではないかと思います（原理的に）。
となればあるテキストで、毎回第二正規化が複合主キーになっているのも当然ということになり、またそのへんの正規化を解説した、テキストやWebサイトで、複合主キー関連の学術的説明が続くのも合点がいく気がします。
わたしはいつも複合主キーというのは主キーのイレギュラー形かと思っていたのですが、上記ふまえると、複合主キーのほうが、一番最初の主キー決定において、むしろ本質的概念であるということになります。
（私がACCESSで売上データを作るときは、複合主キーは気持ち悪いので、単一の主キーを作っていました。業務的にはそれでよいかもしれませんが、本質的には余計な情報追加ということになるかと思います）
まだまだ全体をきちんと理解できていないですが、いろいろ気づかせていただきました。ありがとうございます。