Le concept de clé candidate n'existe-t-il que dans la théorie?
Je connais le concept de clé candidate dans la théorie des RDBMS, mais les clés candidates existent-elles vraiment dans des moteurs SQL actuels? Je veux dire, c'est qu'il y a un moyen de désigner une colonne ou un ensemble de colonnes particulières en tant que clé candidate dans l'un des systèmes de gestion de la base de données SQL, dites SQL Server, Postgres, MySQL, Oracle, etc.?
Existe-t-il un mot-clé réservé pour désigner des colonnes comme une clé candidate comme PRIMARY KEY ou UNIQUE en cas de colonne principale et de colonne unique?
Je ressens UNIQUE la contrainte elle-même fournit la mise en œuvre du concept de clé candidat. Je ne vois aucune valeur pratique d'avoir une CANDIDATE KEY mot-clé. Est-ce tellement?
Autant que je sache, aucun système de gestion de la base de données SQL (SGMS) fournit le CANDIDATE KEY Mot-clé comme tel, mais (comme je considère que vous suggérez dans la question) qui ne signifie pas que la notion (ou la fonctionnalité) de clé candidate Ne peut pas être configuré dans une table SQL.
Comment représenter une clé candidate
Par exemple, si
- il n'y a pas de primaire déclaré pour la table considérée et
- un ensemble complet de colonnes (c'est-à-dire une ou plusieurs) configurée avec une contrainte unique est également fixée avec la ou les contraintes (s) nulle (s) nulle (s) correspondantes,
ensuite, le concepteur est, précisément, représentant une clé candidate.
Par exemple, le tableau suivant montre trois clés de candidat distinctes:
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
);
Comme vous le savez, une clé candidate constituée de cette manière susceptible d'être la référence d'une ou de plusieurs contraintes de clé étrangère.
Il vaut la peine de souligner le fait que, puisque SQL et ses dialectes incluent l'idée de marques nulles, une contrainte unique seule n'est pas suffisante pour représenter une clé candidate (comme exposée dans l'échantillon DDL ci-dessus). Ce point est particulièrement important car la ou les colonnes contraintes comme une clé candidate ne peuvent pas conserver des marques nulles, sinon elles ne pouvaient pas être considérées comme une véritable clé candidate (en plus, il y a des raisons de faire valoir qu'une table entourant des marques nulles dans l'une de ses colonnes. ne peut pas être considéré comme une table relationnelle, mais oui, c'est un sujet différent).
Comment cela diffère-t-il de l'CANDIDATE KEY approche de mots clés?
De cette manière, si les fournisseurs/développeurs d'un certain SQL SGBM souhaitent fournir le CANDIDATE KEY Mot-clé, alors ce type de contrainte, mis à part l'application de la créance d'unicité évidente, doit également garantir le rejet de toute tentative d'insertion des marques nulles dans les colonnes pertinentes, facteur qui le ferait différent de l'approche combinant l'unique et ne sont pas une contrainte (s) nulle (s).
Comment décrire une clé alternative
Si, au contraire,
- un certain ensemble de colonnes a été choisi et défini comme clé primaire d'une table donnée et
- une autre série de colonnes est contrainte comme unique et chacun des membres de cet ensemble est également fixé avec une contrainte non nulle,
ensuite, le concepteur représente une touche alternative (si, une table donnée a une ou plusieurs clés candidates, et l'une d'entre elles est accordée au statut de primaire, Ensuite, les restants deviennent des clés alternatives).
Par exemple, le tableau suivant présente une clé primaire et trois clés alternatives:
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
);
Une autre clé maquillée comme illustrée ci-dessus peut être, évidemment, référencée d'une ou plusieurs contraintes de clé étrangère.
En utilisant le CANDIDATE KEY mot clé quand il y a déjà une clé primaire?
En supposant qu'il y ait un SGBD qui fournit le CANDIDATE KEY Mot clé, si une table a une clé primaire déclarée, la création d'une clé candidate doit être rejetée et la SGBD devrait aussi bien fournir le ALTERNATE KEY Mot-clé de représenter une ou plusieurs touches alternatives applicables.
Illustration de la même table (i) avec une clé candidate et (ii) avec clé primaire
Oui, au niveau logique de l'abstraction d'une base de données, une clé candidate qui est établie au moyen d'une contrainte unique de niveau de table en conjonction avec le niveau de colonne applicable non null des contreparties (s) NULL), comme indiqué comme suit:
CREATE TABLE Foo (
FooId INT NOT NULL,
Bar CHAR(30) NOT NULL,
Baz DATETIME NOT NULL,
CONSTRAINT Foo_CK UNIQUE (FooId)
);
... serait équivalent à une clé primaire configurée comme indiqué ci-dessous:
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.
);
En effet, si une table donnée n'a qu'une seule clé candidate (qui, comme illustré précédemment, peut être composite, c'est-à-dire composé de deux colonnes ou plus), il peut alors être pris en compte, automatiquement la clé primaire .
Soutien au niveau physique
Et, oui, afin de soutenir une contrainte unique, certains SGMS peuvent utilisent un index dont le type est différent de celui de l'indice utilisé pour soutenir une Contrepartie principale (par exemple, non groupée vs en cluster ), mais Il s'agit d'un facteur qui fait partie du niveau d'abstraction physique (ou interne) (qui, au fait, pourrait ou non s'appliquer en fonction de la DBMS d'utilisation), il est donc entièrement en dehors de la portée des contraintes de niveau logique Configuré pour une table (tant que la DBMS garantit le caractère unique des valeurs contenues dans la colonne [S] impliquée).
Je vais sortir sur un membre et supposer que vous avez fait un cours basé sur le manuel d'Elmasri et de Navathe. Ce livre est tout à fait théorique et n'est pas le plus clair de la prose, et il a tendance à utiliser la terminologie qui n'est pas largement utilisée ailleurs. L'effet net qu'il semble confondre les élèves de manière semi-régulière - beaucoup, sinon la plupart des questions, comme cela semblent provenir d'élèves essayant de donner un sens à ce manuel.
Dans la modélisation des données, une clé candidate est une clé possible que vous pourrait utilisation pour identifier un enregistrement. Il peut y avoir juste un ou plusieurs qu'un; Certains peuvent être des références simples, certaines peuvent être des combinaisons d'attributs. C'est purement un concept de modélisation pour décrire les clés que vous pourrait Sélectionnez à utiliser comme identifiant principal.
Les tables d'une SGBDM ne peuvent avoir qu'une seule clé primaire (sélectionnée au moment de la conception), mais elles peuvent avoir plusieurs contraintes d'unicité. Normalement, vous sélectionneriez une clé (ou d'ajouter une clé synthétique) et d'utiliser cela comme identifiant principal. Vous pouvez également créer des contraintes d'unicité sur les colonnes qui composent d'autres clés candidates, bien que ce ne soient pas appelés clés candidates lorsqu'elles soient physiques de cette manière.