Candidate Key –候補キーは、データベース内の一意のキーとして修飾できる任意の列または列の組み合わせです。 1つのテーブルに複数の候補キーを含めることができます。各候補キーは、主キーとしての資格があります。
Primary Key –主キーは、レコードを一意に識別する列または列の組み合わせです。主キーにできる候補キーは1つだけです。
ジョン・ウーの答えは、正しい限り正しいです。ここにいくつかの追加のポイントがあります。
主キーは常に候補キーの1つです。かなり頻繁に、それが唯一の候補です。
候補キーのないテーブルは、リレーションを表しません。リレーショナルモデルを使用して適切なデータベースを構築する場合、設計するすべてのテーブルには少なくとも1つの候補キーがあります。
リレーショナルモデルは、主キーの概念なしで完全になります。リレーショナルモデルの元のプレゼンテーションにはありませんでした。実際問題として、主キーが宣言されていない外部キー参照を使用すると、混乱が生じます。それは論理的に正しい混乱かもしれませんが、それでも混乱です。主キーを宣言すると、DBMSはデータルールの実施を支援します。ほとんどの場合、DBMSを使用してデータルールの実施を支援することは良いことであり、コストに見合うだけの価値があります。
一部のデータベース設計者と一部のユーザーは、主キーがテーブル内の行（レコード）を識別するのか、テーブルが表す主題のエンティティのインスタンスを識別するのかについて、精神的に混乱しています。理想的な世界では、両方を行うことが想定されており、エンティティテーブルの行と対応するエンティティのインスタンスの間には1対1の対応が必要です。
現実の世界では、物事は台無しになります。誰かが同じ新しい従業員を2回入力すると、従業員は2つのIDになります。誰かが雇われますが、データ入力は何らかの手動プロセスでクラックをすり抜け、従業員は省略が修正されるまでIDを取得しません。最初に問題が起きても崩壊しないデータベースは、崩壊するデータベースよりも堅牢です。
プライマリキー->テーブル内のレコードを一意に識別する-=カラムまたはカラムセットはプライマリキーです。 （テーブルには1つのプライマリキーのみがあります）
候補キー-> 主キーになる候補の列または列セットは候補キーです。 （テーブルには1つ以上の候補キーがあり、候補キーが1つしかない場合は、それを主キーとして選択できます）
違いはありません。主キーは候補キーです。慣例により、リレーション内の1つの候補キーは通常「プライマリ」キーとして選択されますが、選択は基本的に任意であり、データベースユーザー/設計者/開発者にとって便利です。 「プライマリ」キーは、他の候補キーと根本的には異なりません。
主キーは、次の特別な種類のインデックスです。
there can be only one;
it cannot be nullable
it must be unique.
候補キーはスーパーキーのセットから選択されます。候補キーを選択する際に注意する唯一のことは、冗長な属性を持たないことです。
Employeeテーブルの例：Employee（Employee ID、FullName、SSN、DeptID）
候補キー：すべての行の一意性に適格なテーブル内の個々の列です。ここで、EmployeeテーブルのEmployeeIDとSSNは候補キーです。
プライマリキー：テーブルの一意性を維持するために選択する列です。ここで、Employeeテーブルでは、EmployeeIDまたはSSN列のいずれかを選択できます。SSNは安全な値であるため、EmployeeIDが望ましい選択です。
代替キー：EmployeeIDがPKの場合、SSNが代替キーになるなど、プライマリ列以外の候補列。
スーパーキー：他の列/属性を主キーに追加すると、それはEmployeeID + FullNameなどのスーパーキーになり、スーパーキーになります。
複合キー：テーブルに候補キーに適格な単一の列がない場合は、2つ以上の列を選択して行を一意にする必要があります。 EmployeeIDまたはSSN列がない場合と同様に、FullName + DateOfBirthを複合主キーとして作成できます。それでも、行が重複する可能性はわずかです。
テーブルには、行を一意に識別できる非常に多くの列を含めることができます。この列は候補キーとして参照されますが、テーブルには1つの主キーで十分なので、主キーはそれらの1つである必要があります。そのため、主キーの選択は、多くの候補キーの中で重要です。それが主な違いです。
プライマリキー
テーブルの主キーは、そのテーブル内の行の一意の識別として使用される列（または列の組み合わせ）です。つまり、テーブル内の2つの異なる行が主キーで同じ値を持つことは決してなく、テーブル内のすべての行について、主キーは常に1つの値を持っている必要があります。キー。
どこでも主キーに出くわします。たとえば、銀行が銀行口座に関するデータを格納するテーブルには、列銀行口座番号が主キーとしてあります。同様に、異なる車が登録されているテーブルでは、ナンバープレートが主キーとして使用されます
候補キー
一部のテーブルには、主キーとして機能できる複数の列（または列の組み合わせ）が含まれています。これらの列はすべて、主キーの一意性プロパティを保持しています。ここでも、null値は許可されていません。これらの列は候補キーと呼ばれます。ただし、主キーとして指定されるのは1つだけです。したがって、テーブルには常に少なくとも1つの候補キーがあります。
クラブのPLAYERSテーブルにもパスポート番号が含まれていると仮定すると、パスポート番号は一意であるため、その列が候補キーとして使用されます。 2人のプレーヤーが同じパスポート番号を持つことはできません。この列は、主キーとして指定することもできます。
代替キー
テーブルの主キーではない候補キーは、代替キーと呼ばれます。特定のテーブルに対してゼロ個以上の代替キーを定義できます。候補キーという用語は、すべての主キーと代替キーの一般的な用語です。
外部キー
外部キーは、母集団がテーブルの主キーの母集団のサブセットであるテーブルの列（または列の組み合わせ）です（これは別のテーブルである必要はありません）。外部キーは、参照キーと呼ばれることもあります。
整数の主キーを持つ車両のテーブルを考えてください。
登録番号は候補キーになります。
現実の世界では、登録番号は変更される可能性があるため、候補キーとして適格となる状況によって多少異なります。
主キーは、テーブル内の行を一意に識別するテーブル内の列です。
CUSTOMERS
CustomerNo FirstName LastName
1 Sally Thompson
2 Sally Henderson
3 Harry Henderson
4 Sandra Wellington
たとえば、上の表では、CustomerNoが主キーです。
主キー列に配置される値は、行ごとに一意である必要があります。重複は許容されません。また、主キー列ではヌルを使用できません。
1つまたは複数の列を主キーとして使用することが可能であることを説明したので、どの列（およびいくつ）を選択するかをどのように決定しますか？
さて、複数の列を使用することが賢明または不可欠な場合があります。ただし、複数の列を使用する理由がすぐにわからない場合は、1つ使用してください。これは絶対的なルールではなく、単なるアドバイスです。ただし、単一の列で構成された主キーは、一般に保守が容易で、操作が高速です。つまり、データベースにクエリを実行する場合、テーブルに単一列の主キーがあると、通常、回答がより速く返されます。
次の質問—どの列を選ぶべきですか？列を主キーとして選択する最も簡単な方法（および合理的に一般的に採用されている方法）は、データベース自体が各行に一意の番号を自動的に割り当てるようにすることです。
従業員の表では、従業員の名を制御できないため、明らかにFirstNameなどの列は適切ではありません。上記の場合のように、多くの場合、主キーの選択肢は1つだけです。ただし、複数ある場合、これらは「候補キー」として説明できます。名前は、それらが主キーの責任あるジョブの候補であることを反映しています。
まず、determinant？とは何かを知る必要があります。決定要因は、同じテーブル内の別の属性を決定するために使用される属性です。 SO 行列式は候補キーでなければなりません。そして、複数の行列式を持つことができます。ただし、primary keyはレコード全体を決定するために使用され、1つの主キーのみを持つことができます。主キーと候補キーの両方を1つ以上の属性で構成できます