0

ここで、機能依存関係と候補キーを見つけるように求められます。

FD と候補キーを理解するとき、私は少し混乱しています。私の理解では、「X の 1 つの値が与えられた場合、Y の 1 つの値を知っているか」という場合に FD を見つけることができますか? たとえば、studentID が与えられた場合、studentName はわかりますか? はい。それは簡単です。

候補キーについては、おそらく主キーになる可能性がありますが、必然的に主キーとして使用されるキーだと思います。

今、私はシナリオを持っています:

人材紹介会社は、面接の予約の詳細を記録するデータベースを作成しています。この機関は、「候補者」(CND) が仕事を見つけるのを支援する「プレースメント マネージャー」(PLM) を採用しています。各プレースメント マネージャーは、多くの候補者と面接します。ただし、候補者は 1 人の配置マネージャーに割り当てられます。これは、候補者が持つ各予定について、常に同じプレースメント マネージャーとの予定であることを意味します。任意のアポイントメントは、1 人の候補者と割り当てられたプレースメント マネージャーの間で行われます。

代理店の初期スキーマは次のとおりです。

Appt は予約の日時です。PLM# & PLMname はプレースメント マネージャーの ID と名前、CND# は候補の ID です。CNDname は候補者の名前です。CNDaddress は、候補者の連絡先です。仕事は面接で話されている仕事です。

したがって、上記のシナリオでは、候補キーは次のようになります。

{PLM# Appt} and {CND#, Appt}

ここでの私の問題は、上記のように書き出すか、候補キーを1つだけ持つかがわからないことです

{PLM#, CND#, Appt}

FD:

PLM# -> PLMName
CND# -> CNDName
CND# -> CNDAddress
CND#, PLM# -> Appt
CND#, Appt -> Job
CND# -> Appt
CND# -> Job
CND# -> PLM#

前提条件 1 面接時に仕事について話し合う 候補者は 1 日に 1 回だけ面接を受けることができます

正規化する前にFDをチェックしたいだけです。

4

1 に答える 1

1

FDCND ⟶ Jobは、特に与えられた場合、疑わしいCND, Appt ⟶ Jobです。これは、CND が 1 つの仕事にしか応募または相談できないことを意味します。

FDCND ⟶ Apptが疑わしい。つまり、PLM が 50 ある場合でも、2 人が同時に予約することはできません。

キーに関する質問については、2 列のキーのそれぞれが候補キーであり、既約です。提案された 3 列のキーは還元できません (2 つの 2 列の候補キーのいずれかに還元できるため)。したがって、3 列のキーは (厳密な) スーパーキーであり、候補キーではありません。

于 2012-10-05T06:01:57.997 に答える