主キーと外部キー？

Question

データベースを作成するときに、あるテーブルに他のテーブルの2つの主キーのみが含まれていると、何が起きるかは、両方が外部キーであると仮定しています。テーブルにプライマリキーが必要ですか？

Answer 1

テーブルに必ずしもプライマリキーが関連付けられている必要はありません。それは私

を次のように完全に有効なTable_Album

pkey | name 
1 | name1 
2 | name2 

Table_Song

pkey | name 
1 | song1 
2 | song2 
3 | song3 

あなたはその後、

Table_Album_Song_Map

01を述べたテーブルを持つことができます

id | Album | Song # Here id is just row number and not primary key 
1 | name1 | song1 
2 | name1 | song2 
3 | name2 | song3 

Answer 2

いいえ;テーブルはプライマリキーを持つ必要はありません。

このようなリンク/マッピングテーブルの場合は、しばしば（通常は？）しません。

Answer 3

ちょうど2つの外部キーと他には何もしてリンクテーブルを助け希望（何のサロゲートキーは、単純な意味のない主キーを作るために追加されません）通常一意であるように制約されます（そうでない場合は、あなたがされません重複を区別することができます - これは通常の形式にも違反しています）ので、主キーを構成する複合キーとしてこれら2つのキーを一緒に使用します（PKは定義上一意でなければならず、そのようなリンクテーブルのPKのための選択）。主キー内のこれらの列の順序は、通常、最も頻繁な検索順序、すなわちpersonidによって決定されます。accountidは、personidのaccountidのコンポジット主キーでpersonidを最初に持つことがあります。

Answer 4

関連エンティティまたはテーブルがある場合は、両方の親のキーで構成される複合プライマリキーを作成することをお勧めします。この例では、アルバムと歌のコンポジットのAlbum-Song-Mapに一意性の制約があります。これらをプライマリキーにしないで、組み合わせをユニークにすると、Album-Song-Mapで重複を持つことができます。 Album-Song-Mapの複合キーは両方の親のキーですが、個々に、それぞれ親、アルバム、およびソングに戻る外部キーです。私の経験では、アソシエーティブ・エンティティは通常マッピングのためだけでなく、ビジネス・アトリビュートもいくつか含んでいます。たとえば、ある曲のDuration（再生時間）が別の曲と異なるとします。この属性はAlbum-Song-Mapになければなりません。私はダンスのためにたくさんの音楽を使いますが、しばしば曲のデュレーションはアルバムごとに異なります。