こんにちは

平成18年春期、問62番の問題で質問です。

解説に

「顧客コード」から「顧客名」「住所」が一意に定めることが分かる

とありますがその根拠はなんでしょうか？
よろしくお願いします。

第3正規化の部分ですね。
「主キー以外の項目によって一意に決まる項目を別表に移す」が第3正規化で
行う作業です。

問題では第2正規化までで、
【伝票番号（主キー）】【日付】【顧客コード】【顧客名】【住所】
というフィールドを持つテーブルができることになります。
このうち、一意に決まる項目を別表に移す（別のテーブルにする）わけですが、
次のように考えると分かりやすいです。
「データベースを検索した際に、該当データが必ず一つにしかならないもの」
順に見ていきます。

【日付】
関連する項目をまず探します。【伝票番号】が関連していそうです。
例えば、2019年7月5日と記載のある日付を検索したとします。すると、2019年
7月5日にあった取引が複数ヒットします。日付は主キーではないため、同じ
日付のデータが複数あり得る状態です。これではレコードが一意に決まるとは
言えないので、候補から外します。他のテーブルでも日付は主キーになっていません。
（ちなみに主キーにしてしまうと、同一の日に1件しか取引できないシステムに
なってしまいます）

【顧客コード】
問題にはいちいち書いてありませんが、【顧客コード】は顧客一人一人に割り振られた
固有番号です。関連する項目を探します。顧客は氏名と住所をもっているので、
【顧客名】と【住所】が関連する項目です。顧客コードで検索をかけると、
顧客一人分の検索しか該当しません。これにより【顧客名】と【住所】も
必ず一つに定まります。これは一意であるということです。
従って、【顧客コード】を主キーとして、【顧客名】と【住所】を独立した
テーブルとして作成します。

【顧客名】
関連項目は【顧客コード】【住所】です。
顧客名を「応用一郎」で検索をかけたとします。名前ですが同姓同名というものが
存在します。「応用一郎」という名前の人が複数ヒットしてしまい一意に定まりません。
顧客名が他で主キーになっていないのはそのためです。仮に主キーとしてしまうと、
同姓同名の人が登録できなくなってしまいます。これを避けるために、同姓同名の場合でも
顧客コードを割り振っています。候補から外します。

【住所】
関連項目は【顧客コード】【顧客名】です。
住所で検索すれば一見、一意にレコードが定まりそうですが、同一の住所に
同居者がいた場合を考えます。同一住所に複数の顧客が登録していれば、
複数ヒットします。住所は他のテーブルでも主キーになっていません。
一意でないので候補から外します。

すると、問題の答えのようなテーブル構成になります。フィーリングに
頼るような解説になってしまいましたが、応用情報の午前試験ではそこまで
ひねくれた問題は見たことがないので、慣れてしまえばフィーリングで
対応できると思います。

以降は私が過去に迷った部分なので、同じことを考えていたら参考にしてください。
●【商品コード（主キー）】【単位】【単価】の【単位】を別テーブルにできね？
確かにできます。【単位コード】と主キーとしてフィールドに【単位名】とします。
システムとしても問題なく動きますが、そもそも問題の前提でそのようなフィールド名は
登場していません。ここまで考えなくていいです。
問題文のフィールド名に「コード」とか「番号」とつくものがあったら、第3正規化の
最有力候補です。

●「番号」なら「電話番号」も第3正規化させるべきだよね？
問題文に出てはいませんが、前の項目の関連として考えてみます。
これは住所と同じです。同居人がいたときに同じ電話番号で登録される可能性があります。
携帯電話やスマートフォンの電話番号が主キーになっている可能性があるシステムがこの世に
実在しますが、考え過ぎです。午後問題の長文問題なら詳しい説明とともに出題も
あり得ますが、午前問題で何の説明もなしにひねくれたものを出したらクレームもの
なので、おそらく出ないでしょう。

長文になってしまい、質問内容とぼやけるところがあったので、端的にまとめます。

【顧客コード】は、そもそもが前の投稿のような問題を避けるために、顧客が必ず一意に
定まるように個人一人一人に割り振られた番号です。
そこに【顧客コード】に関連する項目を加えて一つのテーブルにしてあるだけです。

おそらく双葉さんが回答されている「問題にはいちいち書いてありませんが、【顧客コード】は顧客一人一人に割り振られた固有番号です。」という部分が肝なのだと思います。

【顧客コード】というものがどのような役割を果たすべきものなのかは、実際にデータベース設計の経験が無いと理解しづらいのではないかと思います。

昔の問題には、このような実務経験がものをいうような不親切（？）な問題が多いような気がします。