web-dev-qa-db-ja.com

候補キーの概念は理論にのみ存在しますか？

RDBMS理論では候補キーの概念を知っていますが、候補キーは実際のSQLエンジンに実際に存在しますか？つまり、特定の列または列のセットを、SQL Server、Postgres、MySQL、OracleなどのSQLデータベース管理システムの候補キーとして指定する方法はありますか？

主キー列と一意の列の場合、PRIMARY KEYまたはUNIQUEのような候補キーとして列を指定するための予約済みキーワードはありますか？

UNIQUE制約自体が、候補となる主要な概念の実装を提供していると思います。個別のCANDIDATE KEYキーワードを使用することの実用的な価値はありません。そうですか？

primary-keyrelational-theoryrdbmsunique-constraintcandidate-key
5
anir

私の知る限り、SQLデータベース管理システム（DBMS）はCANDIDATE KEYキーワード自体を提供していませんが、（質問で提案していると私が考えるように）これは概念（または機能）を意味するものではありませんの候補キーはSQLテーブルで構成できません。

候補キーを表す方法

たとえば、

  • 検討中のテーブルに宣言されたプライマリはありません。
  • uNIQUE制約で構成されている列のセット全体（つまり、1つ以上）も、対応するNOT NULL制約で修正されます。

その場合、デザイナーは正確に候補キーを表します。

たとえば、次の表は3つの異なる候補キーを示しています。

CREATE TABLE Foo (
    FooId  INT      NOT NULL,
    Bar    CHAR(30) NOT NULL,
    Baz    DATETIME NOT NULL,
    Qux    INT      NOT NULL,
    Corge  CHAR(25) NOT NULL,
    Grault INT      NOT NULL,
    Garply BIT      NOT NULL,
    Plugh  TEXT     NOT NULL,
    CONSTRAINT Foo_CK1 UNIQUE (FooId),          -- Single-column CANDIDATE KEY
    CONSTRAINT Foo_CK2 UNIQUE (Bar),            -- Single-column CANDIDATE KEY
    CONSTRAINT Foo_CK3 UNIQUE (Baz, Qux, Corge) -- Multi-column  CANDIDATE KEY
);

この方法で設定された候補キーは、ご存じのように、1つ以上の外部キー制約の参照である可能性があります。

SQLとその方言にはNULLマークの概念が含まれているため、（上記のDDLサンプルで説明されているように）UNIQUE制約だけでは候補キーを表すのに十分ではないという事実を強調することは価値があります。候補キーとして制約されている列はNULLマークを保持できないため、この点は特に重要です。そうでない場合、真の候補キーとは見なされません（その上、列のいずれかにNULLマークを含むテーブルがあると主張する理由があります。リレーショナルテーブルと見なすことはできませんが、はい、それは別の主題です）。

これはCANDIDATE KEYキーワードアプローチとどう違うのですか？

このように、特定のSQL DBMSのベンダー/開発者がCANDIDATE KEYキーワードを提供したい場合、この種の制約は、明らかな一意性の強制とは別に、NULLマークを挿入する試みの拒否も確実にする必要があります。関連する列で、UNIQUEおよびNOT NULL制約を組み合わせたアプローチとは異なる要因。

代替キーを描く方法

逆に、

  • 列の特定のセットが選択され、特定のテーブルの主キーとして定義されている。
  • 他の列のセットはUNIQUEとして制約され、そのようなセットの各メンバーもNOT NULL制約で修正されます。

次に、デザイナーは代替キーを表します（特定のテーブルに1つ以上の候補キーがあり、これらの1つにプライマリのステータスが付与されている場合、その後、残りのキーは代替キーになります）。

たとえば、次の表は、1つの主キーと3つの代替キーを示しています。

CREATE TABLE Foo (
    FooId  INT,
    Bar    CHAR(30) NOT NULL,
    Baz    DATETIME NOT NULL,
    Qux    INT      NOT NULL,
    Corge  CHAR(25) NOT NULL,
    Grault INT      NOT NULL,
    Garply BIT      NOT NULL,
    Plugh  TEXT     NOT NULL,
    CONSTRAINT Foo_PK  PRIMARY KEY (FooId),           -- Single-column PRIMARY KEY
    CONSTRAINT Foo_AK1 UNIQUE      (Bar),             -- Single-column ALTERNATE KEY
    CONSTRAINT Foo_AK2 UNIQUE      (Baz, Qux, Corge), -- Multi-column  ALTERNATE KEY
    CONSTRAINT Foo_AK3 UNIQUE      (Grault)           -- Single-column ALTERNATE KEY
);

上記のように作成された代替キーは、明らかに、1つ以上の外部キー制約から参照できます。

すでにPRIMARY KEYがあるときにCANDIDATE KEYキーワードを使用しますか？

CANDIDATE KEYキーワードを提供するDBMSがあるとすると、テーブルに主キーが宣言されている場合、候補キーの作成は拒否され、前述のDBMSはALTERNATE KEYも提供する必要があります。該当する場合に1つ以上の代替キーを表すキーワード。

同じテーブルの図（i）1つの候補キーと（ii）主キー

はい、データベースの抽象化の論理レベルでは、次の例に示すように、テーブルレベルのUNIQUE制約と、適切な列レベルのNOT NULLの対応物を組み合わせて確立される候補キー。

CREATE TABLE Foo (
    FooId  INT      NOT NULL, 
    Bar    CHAR(30) NOT NULL,
    Baz    DATETIME NOT NULL,
    CONSTRAINT Foo_CK UNIQUE (FooId)
);

…以下に示すように設定された主キーと同等です。

CREATE TABLE Foo (
    FooId  INT,
    Bar    CHAR(30) NOT NULL,
    Baz    DATETIME NOT NULL,
    CONSTRAINT Foo_PK PRIMARY KEY (FooId) -- Single-column PRIMARY KEY, constraint that implies the rejection of NULL marks.
);

これは、特定のテーブルに候補キーが1つしかない場合（前に示したように、2つ以上の列で構成される複合キーである場合）、自動的に考慮されるためですthe主キー。

物理レベルのサポート

そして、はい、UNIQUE制約をサポートするために、一部のDBMSmayは、型を維持するために使用されるインデックスの1つとは異なるタイプのインデックスを使用しますPRIMARY KEY対応（たとえばnon-clusteredvsclustered）、ただしこれは、抽象化の物理（または内部）レベルの一部である要因です（使用するDBMSに応じて適用される場合と適用されない場合があります）。したがって、論理レベルの制約の範囲外です。テーブル用に構成されている（DBMSが関連する列に含まれる値の一意性を保証する限り）。

7
MDCCL