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
);
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}
... ;
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)
...
) ;
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
... ... ...
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...
Répertoire téléphonique
)
Répondre avec citation
) que pour un petit projet avec peu d'utilisateurs, PostgreSQL n'était peut-être pas recommandé (en terme de vitesse) par rapport à MySQL.
Du coup je n'ai pas d'autre choix que d'ajouter un champ "adr_s_complement" en ce cas ?
). Bien faire et laisser dire, le tout est de partir sur la base d’un MCD correct et une fois dans la soute, procéder à des prototypages de performance (pertinence des index, campagnes d’EXPLAINS...)
) excepté une chose parmi les contraintes de la table "COMMENTAIRE" dans le 1er code SQL :
) toutes ces nouvelles infos :
Partager