表と表の結合について

質問

新人研修で、「表の結合の際に、結合する列がなぜその列なのか？」を説明する方法を悩んでおります。

<元表>
商品コード、商品名、購入数、顧客情報

<正規化>
商品テーブル：商品コード、商品名
売り上げテーブル：商品コード、購入数量、顧客I

これを見たとき、私は
「商品コード」で　結合すれば、「どこ顧客が、何の商品」を購入されたかというのがわかるのですが、

[質問1]
なぜ商品コードで、「結合する仕様になっているか」の説明を求められたとき
うまく説明する方法が思いつきません・・・。

「売り上げ伝票から正規化されて作成されたから、正規化する前の情報を出せるように関連付けするために、主キーの商品コードを、各表2つに残しておく。」
と言う説明しか出来ないのです。

もっとわかりやすい説明がありましたらご教授のほうお願いします。
できれば、正規化と言う情報を使わずに、「商品コード」で結合する理由を説明したいのです。

回答No.3

jjon-com

質問文に <元表> と <正規化> が載せてありますけれど，正規形が必ずそれになるとは言えないです。前提条件が変われば正規形も変わりますから。

次の３つの例を検討してみます。

▼条件１
・１つの商品はただ１人の顧客だけが購入できる

▼条件２
・１つの商品は複数の顧客が購入できる
・１人の顧客は同一商品をただ１度だけ購入できる

▼条件３
・１つの商品は複数の顧客が購入できる
・１人の顧客は同一商品を複数回購入できるが，１日あたりの同一商品の購入は１度だけ

それぞれの場合，正規形の例は次のようになります。

▼条件１の正規形
商品コードが決まればそれに対応する商品名，購入数，顧客コードすべて一意に決まります。
イメージとしては，オークションにおける出品と同じく，まったく同じ書籍が複数出品されたとしてもそれぞれ別々の商品コードが割り振られる条件だということです。

関数従属ではこれを，商品コード →（商品名，購入数，顧客コード）のように表現します。
したがって，この条件における正規形は「商品コード，商品名，購入数，顧客コード」です。複数の表には分離されません。

▼条件２の正規形
商品：購入 の対応は １：Ｎ です。
商品名は，商品コードが決まれば一意に決まりますが，
購入数は「商品 SH01 を顧客 KY01 が 10個購入」「商品 SH01 を顧客 KY02 が 20個購入」のように，
商品コードが決まっただけではダメ，顧客コードが決まっただけでもダメで，商品コードと顧客コードのペアが決まると購入数が一意に決まります。

それぞれを関数従属で表現すれば次のようになります。正規形の２つの表もこうなります。
商品コード→商品名
（商品コード，顧客コード）→ 購入数

▼条件３の正規形
質問文で挙げられた次の表は，
　　> <正規化>
　　> 売り上げテーブル：商品コード、購入数量、顧客I

次のような現象が起こることを想定していません。
「【1月23日に】商品 SH01 を顧客 KY01 が 10個購入」
「【1月24日も】商品 SH01 を顧客 KY01 が 10個購入」

そういう現象が発生するのなら，購入日付の情報を持たねばなりません。
関数従属 および 正規形 は次のようになるでしょう。
商品コード→商品名
（商品コード，顧客コード，購入日付）→ 購入数

それでも「同一顧客による１日あたりの同一商品の購入は１度だけ」という制限は残ります。
１日に何度も購入が発生する状況であるなら，購入の時分秒まで含めるなり，購入トランザクション毎に購入コードを割り当てるなりする必要があります。

----------------------------------------
以上，述べてきましたが，結論としては，

> 正規化する前の情報を出せるように関連付けするために、
> 主キーの商品コードを、各表2つに残しておく。

という人間の意図で商品コードを２つの表に含ませているのではなく，
元表の項目を分析したら，主キーが異なる２つのグループに分離されたから，２つの表に分割したのだ，ということになります。

> なぜ商品コードで「結合する仕様になっているか」

という質問が出てくるということは，購入数という項目が「何に対する」購入数なのかを理解していないということだと思います。

お礼

正規化の指摘ありがとうございます。

> なぜ商品コードで「結合する仕様になっているか」

という質問が出てくるということは，購入数という項目が「何に対する」購入数なのかを理解していないということだと思います。

少し考えて見ます。ありがとうございました。

回答No.2

Siegrune

う～ん、「なぜ商品コードで、結合する仕様になっているか」と聞かれるようなレベルなら、
その前に、なぜ商品コードが元表に必要かを先に説明したほうがいいのでは？

注文って普通商品名と数量をお客さん（顧客情報）からもらいますよね。
そこに商品コードなんて出てきません。
（お客さんとこちらで商品コードが一致するとも限りませんし。）

実をいうと、商品名が非常に短い（例えば型番など）場合、
「商品コード」で結合する必然性はありません。

※例えば、世の中には、１製品しか作っていない製造業がまれにあって
（製薬業とかであるのを知っているのですが。）、
製品の種別は100錠入り、200錠入り・・・しかありません等ということもあります。
これなら、ABC-100、ABC-200・・・で製品名がすんでしまいます。
このとき、製品コードって本当に必要？

ということで説明をしようとすると
<元データ>
商品名、購入数、顧客情報
↓
商品名は文字数が多いから、商品コードを入力して指定したほうが楽。
顧客情報も毎回住所や名前を入力するのが面倒だから顧客コードを指定するほうが楽。
↓
<元表>
商品コード、商品名、購入数、顧客コード、顧客情報
↓
同じ商品コードと商品名が、同じ顧客コードと顧客情報がいっぱい入っている。
↓
<正規化>
商品テーブル：商品コード、商品名
顧客テーブル：顧客コード、顧客情報（住所、氏名等）
売り上げテーブル：商品コード、購入数量、顧客コード

あるいは、
<元データ>
商品名、購入数、顧客情報（住所、氏名等）
↓
同じ商品名や、同じ顧客情報がいっぱい入っている。
同じ商品名は商品コードをつけて、短い文字数で表すと、簡単になる。
同じ顧客情報は顧客コードをつけると、住所や氏名という複数の文字数が多い情報が、
短い文字数であらわすことができる。
↓
（間に<元表>を入れるべきかどうかは悩ましいですが。）
↓
<正規化>
商品テーブル：商品コード、商品名
顧客テーブル：顧客コード、顧客情報（住所、氏名等）
売り上げテーブル：商品コード、購入数量、顧客コード

といった感じでどうでしょう。

お礼

>う～ん、「なぜ商品コードで、結合する仕様になっているか」と聞かれるようなレベルなら、
その前に、なぜ商品コードが元表に必要かを先に説明したほうがいいのでは？

ちょっとこれについて説明するということで考えて見ます。

後は、正規化のやり方については確かに商品コードに商品名が入るケースも考えられますね。
ありがとうございます。

回答No.1

toshi_2000

商品名が変更になった場合、正規化した場合は、商品テーブルの１レコードのみを変更すれば済みます。
正規化しなかった場合、元表にある複数のレコード全ての商品名を変更する必要があります。

こんな説明で分かりますか？

お礼

回答ありがとうございます。
確かに正規化する理由としては、教えて頂いた内容で問題ないと思いました。

ただ、結合する列の説明がやはりできないので、考えて見ます。