疑問1.設問1の解説で、選択肢ウについての部分…
「"販売"表の"席種"列が"商品詳細"表の"席種"列を参照している」ということがわかる根拠はどの部分でしょうか？

疑問2.設問2の解説で、LEFT OUTER JOIN（左外部結合）について…
「基準となる左表の行を全て抽出し、右表からは左表の行と結合できる行のみを抽出する結合方法」とありますが、左表や右表というのはどうやって判断するのでしょうか？
今回の場合は、販売表と決済表ですが…、どちらが左表でどちらが右表になるのか、その判断基準がわかりません。

わかる方、疑問1か2のどちらかでも良いので、教えてくださると幸いです。

疑問1.「"販売"表の"席種"列が"商品詳細"表の"席種"列を参照している」ということがわかる根拠はどの部分でしょうか？

答) 販売表ではコンサートIDを外部キーとして席種を参照しています。「参照」とは今回の場合ではコンサートIDが決めれば商品詳細表から席種が一意（一つ）に決まるということです。よって販売表の席種カラムは商品詳細表の席種カラムを参照していると言えます。

疑問2.設問2の解説で、LEFT OUTER JOIN（左外部結合）について…

答) ここは難しく考えず簡単に捉えてください。
FROM 販売表 LEFT OUTER JOIN 決済表
今回は左側に販売表があるので販売表が左表です。同様に決済表は右側にあるので右表となります。
LEFT OUTER JOINは左表を優先して右表を無理やり結合するようなイメージです。

この投稿は投稿者により削除されました。(2019.10.15 01:36)

>SQL大好きマンさん
早速の解説、ありがとうございます。

疑問1について
販売表のコンサートIDが決定されれば、商品詳細表から席種が一つに特定出来る ということは理解出来ました。
しかし、逆に、商品詳細表ではなく販売表のコンサートID、座種の列が既に埋まっており（入力されており）、商品詳細表のコンサートIDが決定されれば、販売表から座種が一つに特定出来る。
この場合だと、「商品詳細表の席種カラムは販売表の席種カラムを参照している」ということになると思うのですが、おそらくそのケースはあり得ないということですよね。とはいえ、そのケースがあり得ない（想定しなくてよい）と考えられる理由が今度はわかりません…。

疑問2について
FROM 販売表 LEFT OUTER JOIN 決済表
このSQL文で、「左の表」「右の表」という意味だったのですね。
お恥ずかしい限りですが、SQL文を全然見ずに、表ばかりを見比べて、「左とか右とか何のこっちゃ？上と下ならまだわかるが…」と悩んでいたもので…盲点でした。
LEFT OUTER JOINのイメージについても、とてもよくわかりました。ありがとうございます。

>しかし、逆に、商品詳細表ではなく販売表のコンサートID、座種の列が既に埋まっており（入力されており）、商品詳細表のコンサートIDが決定されれば、販売表から座種が一つに特定出来る。

コンサートIDが販売表にあって商品詳細表にないというケースはおかしいと思います。商品が売られていないのに販売は出来ないので。
あと、主キーに参照制約はつけられないと思います。参照制約は外部キー制約とも呼ばれ、外部キーを設定したときに付加されます。商品詳細表.席種は主キーの一部なので、外部キー制約をつけるのはおかしいと思います。

一応指摘しておくと、商品詳細表の主キーはコンサートIDと席種の複合キーなので、コンサートIDから席種は一意に決まりません。
一つのコンサートで、S席もA席もありますからね。（全席Aの同一料金！みたいなコンサートがあること自体はかまいませんが。）
なので、販売表から参照するにあたっても、コンサートIDと席種の組を使って参照しているはずです。

で、参照について。

まず、形式的な話でいくと。
外部キーを通じた参照先は、別の表の主キーです。
主キーでないと、参照先のレコードが一意に決まらない可能性があり、どのレコードの情報と結び付けたらいいか判りません。
そして、販売表においてコンサートIDと席種は主キーにはなりえません。
同じコンサートの同じ種類の席を買った人は、多数いるからです。

単純に現実的な順序でも考えてみましょう。
「コンサート１ではS席を6000円で500席、A席を4000円で600席販売する」といったこと（商品詳細表）を決めてから、チケットを売り出します。
それを見て、「コンサート１のS席のチケットを2枚買います」という注文（販売表）ができるわけです。
これが逆だと、先に勝手にチケットを売って、その結果を見て価格や枚数を決めるというおかしなことになってしまいます。

こんな感じの説明でいかがでしょう？