Hello World程度のデータベース（その８：概念スキーマ（６）第二正規形とは）

　情報処理とは何から、データベースの基本的な話(情報処理試験のデータベーススペシャリスト程度の話まで）を書く、土日のシリーズ「Hello World程度のデータベース」です。

現在、正規化についてやっています。
データを１箇所にだけ現れるようにする手法が正規化で、正規化のレベルとして、第一正規形から第五正規形まであります。でも、普通ＤＢを作るには第一～第三正規形まででよく、それは、以下のとおりです。

第一正規形：繰り返しをなくす
第二正規形：エンティティごとにまとめ、主キーを決め、
　　　主キーが決まると、他の属性値の値がきまるようにする
　　　　→これを主キーに対して完全関数従属といいます
第三正規形：主キー以外で、ある値が決まると、他の値が決まってしまう

　前回までで、第一正規形は終わりました。なので、今回は第二正規形です。

---

■第二正規形の定義

　第二正規形は、「主キーに対して完全関数従属」にするということです。

　つまり、「主キーが決まると、他の属性値の値がきまるようにする」ように、テーブルをわけて、主キーをきめます。
　実際にはテーブルというよりは、エンティティごとにわけるわけなのですが。。

　なにいってるんだ？っていう状態だと思うので、もっと具体的に書きましょう。

たとえば、受注データがこんなふうにあったとします。

　　受注日：２００７年２月２５日
　　おきゃくさん：ウィリアムのいたずら商事
　　お客さんの住所：東京都杉並区
　　お客さんの電話番号：１１９番（うそです。かけないでね　＾＾；）
　　受注商品：特注のすっごい機械
　　納品日：２００７年３月１日
　　納品場所：お客さんの住所と同じ
　　支払い方法：代引き（って、どんな機械だよ　＾＾；）
　　価格：３００００円（って、なおさら、どんな機械だよ　＾＾；）

ま、どんな機械なのかはおいておいて、このとき、

おきゃくさん：ウィリアムのいたずら商事
お客さんの住所：東京都杉並区
お客さんの電話番号：１１９番（うそです。かけないでね　＾＾；）

は、おきゃくさんが、ウィリアムのいたずら商事なら、住所と電話番号はきまってしまいます。逆に、お客さんが変われば（いたずら興業とか）、住所と電話番号はかわります。

　このとき、もし、お客さんっていうエンティティを作って（実際には、取引先っていうけど）そこに、住所、名前、電話番号をいれて、エンティティの要素を区別できるように番号を振ると、こんなかんじになります。

＜＜お客さん＞＞
　　お客さん番号：１番
　　おきゃくさん：ウィリアムのいたずら商事
　　お客さんの住所：東京都杉並区
　　お客さんの電話番号：１１９番（うそです。かけないでね　＾＾；）

そして、元のテーブルには、
＜＜受注＞＞
　　受注日：２００７年２月２５日
　　お客さん番号：１番
　　受注商品：特注のすっごい機械
　　納品日：２００７年３月１日
　　納品場所：お客さんの住所と同じ
　　支払い方法：代引き（って、どんな機械だよ　＾＾；）
　　価格：３００００円（って、なおさら、どんな機械だよ　＾＾；）

のように、お客さん番号だけ入れておけば、いいことになります。
このように、エンティティ（お客さん）ごとに属性値をまとめて、主キー（お客さん番号）をふって、エンティティをわけ、元のテーブルには、その主キーだけを入れておく操作が第二正規形になります。

　このとき、元のテーブルにはいった、他のテーブルの主キー（上記の例だと、受注テーブルのお客さん番号）を、参照キーとか、外部キーとかいいます。

---

■なぜ、こんなことをするのか？

もし、さっきの例で、こんな受注データもあったとします。
　　受注日：２００７年２月２５日
　　おきゃくさん：ウィリアムのいたずら商事
　　お客さんの住所：東京都杉並区
　　お客さんの電話番号：１１９番（うそです。かけないでね　＾＾；）
　　受注商品：特注のすっごい機械を入れる棚
　　納品日：２００７年３月１日
　　納品場所：お客さんの住所と同じ
　　支払い方法：代引き（って、どんな棚だよ　＾＾；）
　　価格：１２００円（って、なおさら、どんな棚だよ　＾＾；）

こうすると、機械の受注と棚の受注のどちらにも、

　　おきゃくさん：ウィリアムのいたずら商事
　　お客さんの住所：東京都杉並区
　　お客さんの電話番号：１１９番（うそです。かけないでね　＾＾；）

っていうデータが入ってしまいます。
　まあ、このうち、名前は、しょうがないかもしれません。じゃないと、どのお客さんからの受注だかわかんないから。
　でも、住所と電話番号は、完全にダブってます。
　これは、データベースが１事実１箇所にするという話と食い違ってくるので、まずいです。そこで、受注エンティティには、お客さんが特定できるお客様番号だけを入れて、それ以外の情報は、お客さんエンティティに入れようっていう話です。

---

■主キーとは、一意とは？

　ここで、名前でない理由は、同じ名前の会社があると困るからです。
　そこで、主キーとして、お客様どうしでダブらないように番号を振ってしまい、その番号を名前の変わりにいれます。
　主キーとは、エンティティ内で、それぞれのレコード（構成員。。。なんか危ない表現だな　＾＾；）において、ダブらないように振った項目であって、この項目は、構成員がダブらないで、特定できるのであれば、複数項目をまとめて、主キーとすることがあります。
（たとえば、課テーブルなどでは、部番号＋（部内の）課番号で主キーってこともあります）
　なお、レコードにダブらないように振っている状態を（１つに特定できるということで）一意になっているというように言います。

---

　ということで、次回から、具体的に第二正規形にする方法と、その際の注意点について書きたいと思います。