主キーに関してです。DBスペシャリストの過去問を解いていると〇〇明細のような関係がある場合に、決まって〇〇番号と〇〇明細番号の2つが明細の関係の中で、主キーになっています。
例えば、注文の場合、注文番号、注文明細番号の2つの属性が主キーになってます。主キーとは、どのタプル（行）かが一意に決まるキーだと思うのですが、そうすると注文明細番号だけで一意に決まると思うのですが、なぜ上記の2つを主キーとしているのでしょうか？主キーがその2つでも、行は特定できると思いますが、明細番号だけでも決まるのではないでしょうか？

入荷（｛入荷番号｝、入荷年月日、発注番号）
入荷明細（｛入荷番号｝、｛入荷明細番号｝、発注番号、発注明細番号、、部品番号、・・・）

入荷（{1}、2012/12/12,1)
       ({2}、2013/12/13,2)
入荷明細（{1},{1},....)
         ({1},{2},.....)
         ({2},{1},....)
          ({2},{2},...)

とあった場合、明細番号だけでは一意に定まりませんよね？

ピノッキさん、ご回答ありがとうございます。


入荷明細（{1},{1},....)
         ({1},{2},.....)
         ({2},{1},....)
          ({2},{2},...)

上記の例ですが、そもそも入荷明細番号1の入荷明細が複数の入荷(入荷番号1と2)に紐づく事自体がおかしいのでは？と思っています。

なぜなら、入荷の明細なので、入荷明細は入荷に対して一意に決まるものではないのですか？

例えば、入荷番号1の入荷に対して入荷明細番号1の入荷明細の属性：部品がAだとして、
入荷番号2の入荷が入ったとします。その入荷明細の属性：部品もAだとしても、それはまた新たにまた別の入荷明細が紐づくものではないでしょうか（入荷明細番号2の入荷明細のように）？

さちりんさんのおっしゃるテーブル構造にしたいなら
主キーは明細番号のみでいいですね。
設計次第です。
ただ、問題で連関エンティティ構造（主キーが２つある構造）になっているならば
そういう構造にはなっていません。

ピノッキさん、ありがとうございます。

なるほど。テーブル構造と設計とで頭の中でこんがらがっていたかもしれません。

たしかに連関エンティティの場合はそうですね。

考えを整理することができました。ありがとうございました！