DB初学者です。初歩的な質問で申し訳ありません。

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

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

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

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

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

当方、DB構築経験がないため、常識的なノウハウを身に着けておりません。もし、そういう慣例でしたら、その慣例が存在する理由等も教えていただけると大変助かります。

https://www.db-siken.com/kakomon/05_aki/am2_8.html
>→商品名が一意と断定できないため？
まあ、この表だけだとそうですね。一般的に、コードで紐づけます。名称をキーとして信用するべきではありません。
>「｛商品コード、受注数｝→受注金額」の従属関係も成立するのではないか。
つまり
※1,275,000：(10+3+2)×85,000
ができるということですか？
これは、内部で集約して演算しなければ、こういうことはできませんよね。正規化は、そういう演算をするものではありません。

＞＞GinSana様

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

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

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

失礼いたしました。ありがとうございます。勉強になりました。

商品コード、受注数を主キーにして受注金額を関数従属させる、という考え方がまずいのは、明細単位にデータが出来上がって、その商品をいくつ買った、の組み合わせは容易に重複する可能性があるわけです。
テレビを1つ買う、という明細だけでも重複するのは容易に想像がつくと思います。
主キーというのは重複するわけにいきませんから、せいぜいできるのは商品コードで単価（あと名称）が決まる、ということになります。
データを集約とかせずにそのまま分解してみて、困ったことにならないか？など、考えながらやってみてください。