2011-09-15 13 views
-1

可能性の重複:
Should each and every table have a primary key?主キー&データベースの正規化

私は、データベースの正規化については、学校のプロジェクトに取り組んできました。 私はとの難しさを抱えている主キー テーブルを持っていないテーブルを正規化するには助けを必要とすることは、サブスクリプションのためのテーブルであり、それは構造だが、このようなものです:

itemSubscribed emailAddress 
-------------- ------------ 
1    [email protected] 
1    [email protected] 
1    [email protected] 
2    [email protected] 
2    [email protected] 
3    [email protected] 

お知らせそのitemSubscribedemailAddress値どちらもプライマリキーになることはありません。

この構造は私のコードではうまくいきます。項目Xに更新があるときに電子メールを送ることができますが、先生は正規化されたデータベースを必要とし、1NFには主キーが必要です。

プライマリキーを持つために自動生成されたプライマリキーを作成した場合、すべてのカラムがプライマリキーに依存する必要があるため、3NFを続行できません。

自動生成された主キーは作成する必要がありますか?私は3NFに関して何かを見逃していますか?

+0

Hm、あなたは質問を定義するのを忘れてしまった! – home

+1

プレースホルダのテキストをコピーしようとするほど難しく、最後にピリオドを忘れてしまいました。 – BoltClock

+0

これは閉鎖されているので、答えとして与えることはできませんが、もちろんこれはもう少し遅いですが、あなたが描いているように見えるのはブリッジテーブルです。ブリッジテーブルは非常に頻繁にはありませんが、複合主キーです。 'itemSubscribed'と' emailAddress'カラムを一緒にプライマリキーにすると、重複はなく、3NFになります。自動生成された主キーは、混乱と余分な作業の原因となるだけなので、ブリッジテーブルでやりたい非常に最後のことですが、重複を実際に促します。 – jmoreno

答えて

0

同じ電子メールアドレスを1つのアイテムに複数回購読することは許可されていますか?あなたの自然な鍵が明らかでない場合は、itemSubscribedとemailAddressです。この場合に人工の主キーを選択したとしても、おそらく2つの列に一意のインデックスが必要です。

0

あなたの質問に答えて、はい、主キーを持っていないのは本当に悪いです。データベースには、特定のレコードを識別する方法が必要です。下の太字ではなく斜体ではないレコードを更新したいとします。主キーなしではどうしますか?データベースにおいて

itemSubscribed EMAILADDRESS


1 [email protected]

1 [email protected]

1 [email protected]

あなたがプライマリキーなしでテーブルを持っていれば、私は失敗するでしょう、それはdatabasにとって非常に重要ですeデザイン。

今は、別の列がある場合を除いて、実際にデータを表示したくないと思われます。同じ商品を購読して同じ電子メールアドレスを持つ2つのレコードが本当に必要なのはなぜですか?この種の不良データを防止するためには、PKまたはユニークなインデックスを持つ方がよいでしょう。あなたは本当に両方のフィールドの自然なキーを持っていると思うし、現在は悪いデータがあります。

1

繰り返しのある行を含む表は関係を表していません。リレーションはタプルの集合です。セット内に同じ要素が複数回存在することはありません。バッグはセットに似ていますが、同じように見える要素の複数のインスタンスを持つことができます。

あなたが私たちに与える表では、itemSubscribedはカウントであり、同じemailAddressを持つitemSubscribedを持つ2つの行は異なるイベントを記述していると考えます。

しかしそれはあなたの心にあり、データには見えません。

この表で問題が発生します。特に、誤った重複エントリと、同様に見える2つの有効なエントリを区別する方法はありません。

関連する問題