投稿する

R5 秋季 午前2 問8 [0656]

 ダイヤモンド新人さん(No.1) 
DB初学者です。初歩的な質問で申し訳ありません。

R5 秋季 午前2 問8について質問です。

第3正規形に正規化を行う際、最終的に4つに分割されるという回答でしたが、こちらについて腹落ちしていません。

2点気になるところがあります。

1.最終的に{商品コード、商品名、単価}の表が作成されると回答にはあったが、
「商品名→単価」の従属関係も成立するのではないか。
→商品名が一意と断定できないため?

2.最終的に{受注番号、顧客コード、受注日}の表が作成されると回答にはあったが、「{商品コード、受注数}→受注金額」の従属関係も成立するのではないか。
→冗長な構成になるため?

当方、DB構築経験がないため、常識的なノウハウを身に着けておりません。もし、そういう慣例でしたら、その慣例が存在する理由等も教えていただけると大変助かります。
2024.04.19 15:25
GinSanaさん(No.2) 
DB シルバーマイスター
https://www.db-siken.com/kakomon/05_aki/am2_8.html
>→商品名が一意と断定できないため?
まあ、この表だけだとそうですね。一般的に、コードで紐づけます。名称をキーとして信用するべきではありません。
>「{商品コード、受注数}→受注金額」の従属関係も成立するのではないか。
つまり
T035  15  1,275,000
※1,275,000:(10+3+2)×85,000
ができるということですか?
これは、内部で集約して演算しなければ、こういうことはできませんよね。正規化は、そういう演算をするものではありません。
2024.04.19 16:15
 ダイヤモンド新人さん(No.3) 
>>GinSana様

>>まあ、この表だけだとそうですね。一般的に、コードで紐づけます。名称をキーとして信用するべきではありません。

ありがとうございます。
慣例的にコードで管理するものとなっているのですね。

>>内部で集約して演算しなければ、こういうことはできませんよね。正規化は、そういう演算をするものではありません。

失礼いたしました。ありがとうございます。勉強になりました。
2024.04.19 17:46
GinSanaさん(No.4) 
DB シルバーマイスター
商品コード、受注数を主キーにして受注金額を関数従属させる、という考え方がまずいのは、明細単位にデータが出来上がって、その商品をいくつ買った、の組み合わせは容易に重複する可能性があるわけです。
テレビを1つ買う、という明細だけでも重複するのは容易に想像がつくと思います。
主キーというのは重複するわけにいきませんから、せいぜいできるのは商品コードで単価(あと名称)が決まる、ということになります。
データを集約とかせずにそのまま分解してみて、困ったことにならないか?など、考えながらやってみてください。
2024.04.19 21:42

返信投稿用フォーム

スパム防止のためにスレッド作成日から30日経過したスレッドへの投稿はできません。
© 2016-2024 データベーススペシャリストドットコム All Rights Reserved.

Pagetop