Bonsoir Éric,
Envoyé par
debutant001
La 3ème contrainte ok : création de la clé étrangère "COMMENTAIRE_USER_AK" (que veut dire le AK à ce propos ?)
"AK" en l’occurrence est une coquille (suite à copié/collé) : remplacer par "FK" (abréviation de « Foreign Key »). J’ai corrigé le message en conséquence.
Envoyé par
debutant001
C'est la 2ème contrainte que je ne comprends pas : vous créez quelque chose (mais quoi ?) s'appelant "COMMENTAIRE_AK" (encore ce AK, K pour Key je suppose mais le A... c'est peut-être ça qui me manque pour comprendre ?) qui sera à priori unique et qui aura comme attribut "UserId" ?
A quoi cela sert-il ?
Reprenons l’instruction :
create table COMMENTAIRE
(
CommentaireId int not null,
UserId int not null,
CommentaireContenu varchar(255) not null,
constraint COMMENTAIRE_PK primary key (CommentaireId),
constraint COMMENTAIRE_AK unique (UserId),
constraint COMMENTAIRE_USER_FK foreign key (UserId)
references USER (UserId) ON DELETE CASCADE
);
Dans le cadre de la théorie relationnelle, il existe un concept primordial, celui de clé candidate, dont un cas particulier est celui de clé primaire. Je vous renvoie au billet où j’aborde le sujet, ainsi qu’au paragraphe 3.2 de l’article où j’en traite plus à fond.
Une table possède au moins une clé candidate (sinon c’est un sac, non manipulable au moyen de l’algèbre relationnelle), mais elle peut aussi en posséder plusieurs. Reportons-nous au tableau des éléments chimiques (message #6). Si l’on en fait une table, appelons-la ELEMENT, celle-ci doit être dotée d’un certain nombre de clés candidates :
{NumeroAtomique}, {Nom}, {SymboleChimique}, etc., sinon on pourrait stocker dans la table ELEMENT des éléments distincts portant le même nom, le même symbole, etc. Par ailleurs comme ça n’est pas mon application qui maîtrise les valeurs de ces clés — celles-ci étant imposées par un système externe — il est prudent de mettre en œuvre une clé dont on ait la maîtrise totale, échappant au système externe. A cet effet, ajoutons un attribut ElementId, faisant lui aussi l’objet d’une clé candidate, plus précisément de la clé primaire {ElementId} de la table (notez l’emploi des accolades, car une clé est un ensemble au sens de la théorie des ensembles, en l’occurrence c’est un singleton, mais néanmoins un ensemble).
Dans le cadre de la théorie relationnelle :
VAR ELEMENT BASE RELATION
{
ElementId INTEGER
, NumeroAtomique INTEGER
, Nom CHAR
, SymboleChimique CHAR
, ... ...
}
KEY {ElementId}
KEY {NumeroAtomique}
KEY {Nom}
KEY {SymboleChimique}
... ;
Dans le contexte SQL :
CREATE TABLE ELEMENT
(
ElementId INT NOT NULL
, NumeroAtomique INT NOT NULL
, Nom VARCHAR(24) NOT NULL
, SymboleChimique VARCHAR(4) NOT NULL
, ... ... ...
, CONSTRAINT ELEMENT_PK PRIMARY KEY (ElementId)
, CONSTRAINT ELEMENT_NUMERO_AK UNIQUE (NumeroAtomique)
, CONSTRAINT ELEMENT_NOM_AK UNIQUE (Nom)
, CONSTRAINT ELEMENT_SYMBOLE_AK UNIQUE (SymboleChimique)
...
) ;
Vous aurez noté que dans le cadre de la théorie relationnelle, il n’y a que des clés (sous-entendu candidates). A une époque, cette théorie prenait en compte le concept de clé primaire, mais il a été démontré que ce concept était inessentiel et a donc été éliminé de la théorie.
Dans le contexte particulier du langage SQL, le concept est resté, car on ne pas imposer la réécriture de l’ensemble des instructions CREATE / ALTER TABLE à l’ensemble de la planète !
{ElementId} est donc clé primaire de la table ELEMENT, et par contraste, {NumeroAtomique}, {Nom}, {SymboleChimique} sont des clés alternatives (alternate keys), d’où l’abréviation « AK » que j’utilise dans les noms des contraintes (pour savoir rapidement de quoi il en retourne quand le SGBD me renvoie une erreur « duplicate key... ») Cela dit, pour marquer le distinguo entre clé primaire et clé alternative, les responsables de la norme SQL ont préféré utiliser le terme « UNIQUE » plutôt que « ALTERNATE KEY » :
CONSTRAINT ELEMENT_NOM_AK UNIQUE (Nom)
Au lieu de
CONSTRAINT ELEMENT_NOM_AK ALTERNATE KEY (Nom)
Pour en revenir à votre interrogation, concernant "COMMENTAIRE_AK", il s’agit donc du nom que j’ai donné à une contrainte selon laquelle l’attribut UserId fait l’objet d’une clé candidate, en l’occurrence alternative {UserId}.
Vous posez la question « A quoi cela sert-il ? »
Vous avez proposé la représentation merisienne :
tUser --(0,1)----(Posséder)----(1,1)--tCommentaire
Ce qui traduit les règles de gestion des données suivantes :
(RG1) Un utilisateur fait l’objet d’au plus un commentaire ;
(RG2) Un commentaire concerne un et un seul utilisateur.
Supposons que je ne déclare pas la contrainte COMMENTAIRE_AK. Rien n’interdit alors d’avoir le contenu suivant pour la table COMMENTAIRE :
CommentaireId UserId CommentaireContenu
1 1 commentaire 1
2 5 commentaire 2
3 1 commentaire 3
... ... ...
C'est-à-dire que l’utilisateur 1 fait l’objet de plus d’un commentaire, en contradiction avec la règle (RG1).
Envoyé par
debutant001
Ben je dois pas avoir le même facteur
Estimez-vous heureux de ne pas avoir eu le mien... On ne recevait plus de courrier et l’on a demandé à La Poste pour quelle raison. On a eu la réponse quelques jours plus tard : ils l’ont suivi discrètement et l’ont vu balancer le courrier dans une bouche d’égout : en effet, il faisait sa tournée à vélo et la pente menant à notre quartier était trop raide pour lui...
Partager