Discussion :

[laurentSc]

Bonsoir,

lorsqu'on déclare un identifiant relatif, la conséquence sur le script SQL de la création de la table associée est que :

1- la clé primaire est composée de 2 colonnes : les identifiants des 2 tables ;

2- la table concernée comporte un attribut déclaré comme clé étrangère vers l'autre table.

Souci : cet attribut-FK est placé avant l'attribut-identifiant, d'où message d'erreur :

Error Code: 1075. Incorrect table definition; there can be only one auto column and it must be defined as a key

Bug vu sous MySQLWorkbench.

Si on déplace l'attribut-identifiant au début du script de déclaration de la table, le message d'erreur disparaît.

Pour éviter ce bug, il serait souhaitable de placer la clé primaire de la classe d'entité en premier dans le script SQL de création de la table SQL correspondante.

EDIT1 : pour reproduire le bug, il faut déclarer la clé primaire en AUTO_INCREMENT

EDIT2 : pour reproduire :

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
CREATE TABLE classB(
   B_ident INT UNSIGNED AUTO_INCREMENT,
   PRIMARY KEY(B_ident)
);
 
CREATE TABLE classA(
   B_ident INT UNSIGNED,
   a_ident INT UNSIGNED AUTO_INCREMENT,
   PRIMARY KEY(B_ident, a_ident),
   FOREIGN KEY(B_ident) REFERENCES classB(B_ident)
);

Pour supprimer le message d'erreur, il faut :

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
CREATE TABLE classB(
   B_ident INT UNSIGNED AUTO_INCREMENT,
   PRIMARY KEY(B_ident)
);
 
CREATE TABLE classA(
   a_ident INT UNSIGNED AUTO_INCREMENT,
   B_ident INT UNSIGNED,  
   PRIMARY KEY(B_ident, a_ident),
   FOREIGN KEY(B_ident) REFERENCES classB(B_ident)
);

[Paprick]

Bonsoir,

Vous avez déjà posé la même question il y 3 semaines et voici la réponse faite par escartefigue et confirmée par fsmrel :

bonjour Laurent
Il faut rapprocher cette remarque du MCD auquel elle se rapporte et dont je reproduis l'extrait ci-dessous

Dans ce MCD, LO_location est identifié relativement (R) à COU_country, la localisation étant une entité-type faible du pays.
Dans la table issue de l'entité-type faible, la clef primaire doit être, dans cet ordre, l'identifiant de l'entité-type forte complété de l'identifiant de l'entité-type faible
Il est donc normal d'avoir dans la table LO_location, une PK composée dans cet ordre de COU_ident puis LO_ident.
Ce faisant, avec la PK déclarée comme CLUSTER (pour MYSQL, cluster index et index primaire ne font qu'un), les lignes de la table LO_location d'un même pays seront rangées de façon contiguë, ce qui est bénéfique aux performances d'accès.
Si on construisait la PK dans l'autre sens (id location puis id country) alors on dégraderait fortement les performances d'accès.

Il faut noter que l'erreur produite par MySQL n'en est pas une pour les autres SGBD, c'est l'une des bizarreries de ce SGBD.

De plus, comme je l'ai déjà signalé également, si LO_ident est auto-incrémenté, il représente à lui seul une clé primaire : le rajout de l'identifiant relatif provoque donc forcément une surclé, ce qui est très discutable du fait du non-respect de la propriété d'irréductibilité (clé minimale).

[laurentSc]

En effet ; je me rappelais pas d'en avoir déjà parlé...
Merci pour votre remarque sur l'irréductibilité. C'est vrai qu'ici, il faut enlever AUTO_INCREMENT.