代理キーはどの通常の形式に違反しますか？
次の質問があります：
「代理キーはどの通常の形式に違反しますか？」
私の考えは第3正規形でしたが、それが私がしている仮定にすぎないかどうかはよくわかりません。誰かがそれを私に説明できますか？
間違いなく、代理キーはテーブルの自然なキーではないため、3-NFの 'キー以外のもの' の原則に違反していると言えます。実際には、代理キーは自然キーの単なるプレースホルダーなので、この議論はせいぜい学術的なものです。
一部のあいまいな通常のフォームでは、関連するために複合キーが必要です。この場合、5NF違反を可能にするために、M：M関係で複数の重複する複合キーが必要になるため、5NFが頭に浮かびます。
間違いなくそうではありません。
代理キーを追加することは、実装時に（RDBMSの動作を尊重するために）実装の決定を行うことです。モデリングと正規化の間に、代理キーなしで [〜＃〜] bcnf [〜＃〜] （少し厳密でより正確な3NF）になるはずです。
つまり、設計プロセスの最初に代理キーを導入することは間違っています。私たちはみんなそれをしますが...
そうではありません。あらゆる種類のキー自体は、通常の形式に違反しません。 NFが満たされているかどうかを定義するのは、テーブルが表すと予想される依存関係のセットです。
代理キーを追加すると、そのキーに対する追加の依存関係が含まれることは事実です。定義により、これらの追加の依存関係は、スーパーキーによって暗示される結合依存関係です。つまり、たとえば5NFおよびDKNFは違反されません。唯一可能な例外は、サロゲートの属性（部分キー）の適切なサブセットがそれ自体で決定要因である場合です。 「代理」は通常、値が任意である単一の属性キーを意味するため、このような部分的なキーの依存関係はほとんどありません。
6NFは、代理キー属性の追加によって違反される可能性がありますが、そうである場合、それは単に属性を追加することによるものです-代理キーに関する問題ではありません。
受け入れられた答えは正しくありません。 @sqlvogelと@gbnの答えは正しいです。
サロゲートキーは、ドメインに依存しないキーであり、自然キー（ドメインから派生する機能的な依存関係を持つキー）の代わりになります。
たとえば、独立した重複しないキーを持つテーブル（People、id、およびssnをキーとするemailという名前のテーブル）があるとします。 。 ssnとemailはどちらも自然な鍵です（私たちは、社会保障番号のみ、または個人を一意に識別できる電子メールのみを指定することを決定しました）。 idは代理キーです。これは、個人を一意に識別するという明確な目的のために追加したキーです。人々はidsを使用する傾向はありませんが、リレーションには通常idという名前の代理キーがあります。したがって、idキーはPersonhoodのドメインから派生したものではありません。
つまり、id、email、およびssnはそれぞれ、Personテーブルの他のすべての属性を機能的に決定します。これらはすべて候補キー（およびスーパーキー）です。
BCNF違反は、非キー属性が機能的に他の属性を決定する場合、または候補キーの一部のみが他の属性を決定する場合に発生します。各属性自体が候補キーであるため、BCNF違反はありません。
キーは最小限である必要はありませんか？
代理キーが複合自然キーの代わりになる場合はどうなりますか？たとえば、Filmsテーブルはtitleとoriginal_release_dateを組み合わせて自然キーを形成し、idフィールドは代理キーとして機能します。 {title、original_release_date}キーは、キーを最小限にするという要件に違反していませんか？
これは、最小性の定義についての誤解です。代理キーが自然キーよりも少ない属性で構成されているからといって、それが唯一の最小キーであるとは限りません。候補キーでもあるキーの適切なサブセットが存在しない場合、候補キーは最小限です。 titleはFilmを一意に識別せず、original_release_dateも識別しません。したがって、代理キーが複合自然キーの代わりをする場合でも、通常のフォーム違反はありません。