[Script]prob de clés étrangères

**Seb7** · 08/07/2003, 14h44

Salut !

J'ai un ptit prob de requête pour créer mes clés étrangères. Je sui débutant dans ce domaine, j'ai donc créé ma base sous AMC Designor et j'ai généré le script à partir du modèle physique pour avoir un modèle. Il m'a donné le script des tables suivi de celui des clés étrangères.
Mon prob est le suivant (exemple sur une partie de ma Bdd):
J'ai ma table SALARIE(mat_sal, nom_sal, pren_sal, num_bad) et ma table ABSENCE (code_abs, lib_abs). J'ai placé une liaison HIST_ABS (date_abs) entre ces 2 tables.
Quand je génère le modèle physique, mat_sal et code_abs se transmettent à HIST_ABS en clès étrangère (ce qui est normal).
Mais quand je génère le script j'ai ceci:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
/* ============================================================ */
/*   Table : SALARIE                                            */
/* ============================================================ */
create table SALARIE
(
    MAT_SAL          NUMERIC(7)             not null,
    CODE_ETAB        CHAR(2)                not null,
    CODE_CY          CHAR(10)               not null,
    CODE_GRILLE      CHAR(10)               not null,
    NOM_SAL          CHAR(25)                       ,
    PREN_SAL         CHAR(25)                       ,
    NUM_BAD          NUMERIC(7)                     ,
       constraint PK_SALARIE primary key (MAT_SAL)
); 
 
/* ============================================================ */
/*   Table : ABSENCE                                            */
/* ============================================================ */
create table ABSENCE
(
    CODE_ABS         CHAR(3)                not null,
    LIB_ABS          VARCHAR(25)                    ,
    constraint PK_ABSENCE primary key (CODE_ABS)
);
 
/* ============================================================ */
/*   Table : HIST_ABS                                           */
/* ============================================================ */
create table HIST_ABS
(
    CODE_ABS         CHAR(3)                not null,
    MAT_SAL          NUMERIC(7)             not null,
    DATE_ABS         DATE                           ,
    constraint PK_HIST_ABS primary key (CODE_ABS, MAT_SAL)
);

Dans SALARIE

Code :

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

1
2
3
4
 
    CODE_ETAB        CHAR(2)                not null,
    CODE_CY          CHAR(10)               not null,
    CODE_GRILLE      CHAR(10)               not null,

sont des clés primaires d'autres tables, pouquoi elles ont été transmis comme ça je sais pas?

Mais c'est dans HIST_ABS que ça me plait pas. CODE_ABS et MAT_SAL sont tranmis comme des clés primaires alors que se sont des clés étrangères !?!
De plus j'ai aussi ceci:

Code :

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

1
2
3
4
5
6
7
alter table HIST_ABS
    add constraint FK_HIST_ABS_ABSENCE foreign key  (CODE_ABS)
       references ABSENCE;
 
alter table HIST_ABS
    add constraint FK_HIST_SALARIE foreign key  (MAT_SAL)
       references SALARIE;

Ceci afin de déclarer mes relations avec les clés étrangères qui vont avec.
Comment puis-je mixer tout ceci? Si je le laisse tel quel, lorsque je veux éxécuter ce script j'ai:

Unsuccessful metadata update
object ABSENCE is in use
Statement: alter table HIST_ABS
add constraint FK_HIST_ABS_ABSENCE foreign key (CODE_ABS)
references ABSENCE

Quelqu'un pourrait-il m'indiquer une syntaxe correcte?
Merci beaucoup d'avance
Seb

**colomban** · 08/07/2003, 14h53

Pour que ce soit clair , la ligne :

Code :

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

1
2
 
constraint PK_HIST_ABS primary key (CODE_ABS, MAT_SAL)

signifie que les champs Code_Abs et Mat_Sal forment à eux deux la clé primaire (et non que chacun d'eux est clé primaire).
Je n'y vois rien que de très logique, non?
Pour la syntaxe quel est le SGBD?

**Gillou** · 08/07/2003, 15h20

essaye ça :

Code :

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

1
2
3
4
5
6
7
alter table HIST_ABS
    add constraint FK_HIST_ABS_ABSENCE foreign key  (CODE_ABS)
       references ABSENCE (CODE_ABS);
 
alter table HIST_ABS
    add constraint FK_HIST_SALARIE foreign key  (MAT_SAL)
       references SALARIE (MAT_SAL);

**Seb7** · 08/07/2003, 15h21

Salut colomban,

signifie que les champs Code_Abs et Mat_Sal forment à eux deux la clé primaire (et non que chacun d'eux est clé primaire).

C'est justement ce qui m'ennuie, ce code a été généré par AMC Designor et il ne me convient pas trop. La théorie vaudrait que Code_Abs et Mat_Sal soit déclaré comme des clés étrangères dans HIST_ABS alors est-ce correct de garder ce script (tout en conservant le script Alter Table... où sont déclarés les relations).

Je n'y vois rien que de très logique, non?

Tu veux dire par là que ce code est correct ? Ou faudrait-il écrire un truc du style:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
/* ============================================================ */ 
/*   Table : HIST_ABS                                           */ 
/* ============================================================ */ 
create table HIST_ABS 
( 
    CODE_ABS         CHAR(3)                not null, 
    MAT_SAL          NUMERIC(7)             not null, 
    DATE_ABS         DATE                           , 
    constraint FK_HIST_ABS1 foreign key (CODE_ABS), 
    constraint FK_HIST_ABS2 foreign key (MAT_SAL) 
);

Le SQL n'est pas mon fort...

Pour la syntaxe quel est le SGBD?

Interbase 6.01 (IBConsole)

**Seb7** · 08/07/2003, 15h29

Salut Gillou comme on se retrouve

essaye ça :
Code:
alter table HIST_ABS
add constraint FK_HIST_ABS_ABSENCE foreign key (CODE_ABS)
references ABSENCE (CODE_ABS);

alter table HIST_ABS
add constraint FK_HIST_SALARIE foreign key (MAT_SAL)
references SALARIE (MAT_SAL);

Sur les conseils de Barbibulle concernant mon error SQL:

Celà arrive lorsque la table ABSENCE est ouverte ou dans une transaction non fermée...
Ferme tous tes logiciels qui accédent à ta base et rééxecute le script e création de tes clés etrangères...

J'ai tout fermé et effectivement, là, ça a marché, mais par contre, j'aimerai savoir ce que ça change d'écrire :

Code :

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

references ABSENCE (CODE_ABS);

au lieu de:

Code :

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

references ABSENCE;

Peux-tu préciser?

**wello00** · 08/07/2003, 15h29

moi je ne vois pas le problème d'avoir en même des primary key et des foreign key sur les mêmes attributs, c'est logique sauf comme il a été dit faut rajoutre les contrainbtes feorign key

**Seb7** · 08/07/2003, 15h35

wello00 a dit:

moi je ne vois pas le problème d'avoir en même des primary key et des foreign key sur les mêmes attributs

Ha, c'est justement ce qui me dérange, ce qui veut dire que mon code est correct alors?

c'est logique sauf comme il a été dit faut rajoutre les contrainbtes feorign key

Tu veux dire :

Code :

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

1
2
3
4
5
6
7
alter table HIST_ABS 
    add constraint FK_HIST_ABS_ABSENCE foreign key  (CODE_ABS) 
       references ABSENCE (CODE_ABS); 
 
alter table HIST_ABS 
    add constraint FK_HIST_SALARIE foreign key  (MAT_SAL) 
       references SALARIE (MAT_SAL);

?

**Gillou** · 08/07/2003, 16h03

comme te l'a expliqué barbibulle dans l'autre thread , n'oublie pas que ta relation entre salarié et absence à entrainé la création d'une nouvelle table : hist_abs. cette table nécessite une clé primaire( enfin, en tout cas c'est plus propre ), de la meme manière que tes tables salarié ( le matricule )et absence (le code ) en nécessitaient. pour hist_abs, ton générateur à considéré que la PK etait le couple(mat_sal, code_abs), qui est une clé primaire tout a fait valide (bien que pas nécessairement le meilleurschoix)

enfin, une fois que tes tables sont créées avec leur clé primaire, tu peux définir les relations entre les tables, sous forme de clés étrangères.

bref, tout le code que tu nous a montré est totalement valide. y compris la création de la clé primaire de hist_abs, y compris l'alter table pour rajouter les clés étrangères, y compris le fait que certaines colonnes servent à la fois de clé primaire et clé étrangère.

pour ma correction à ta syntaxe : si ta syntaxe passe, tant mieux, personnellement je n'avais jamais essayé. J'aime avoir le champ , ç'est plus long a écrire mais je trouve que ça facilite ensuite, lorsque on relit

EDIT : tant que j'y pense :
pour le SQL , le site de [link="sqlpro.developpez.com"]SQLPro[/link] est tres bien.

**Seb7** · 08/07/2003, 16h24

OK OK merci Gillou, je comprends mieux maintenant.

En plus de ça, j'ai bien étudié la dernière réponse de Barbibulle et j'y vois plus clair.
Mon seul prob maintenant (vu mon manque total d'expérience là dedans) est de savoir comment procéder pour HIST_ABS, quel est la meilleur solution?
Car comme le dit si bien Barbibulle je me retrouve avec :

NON pas DES CLES PRIMAIRE mais UNE clé primaire (elle a juste la particularité de porter sur plusieurs colonnes). De plus dans ton cas il se trouve que ces deux colonnes correspondent (en plus) à des clés étrangères...

Et franchement je ne sais pas les conséquences que cela peut avoir dans mes accés futures par mon appli à ma Bdd

Dois-je utiliser.... Que la clé primaire. Que les clés etrangères, les deux !
Je manque un peu de recul pour trancher, je vais y réfléchir mais si quelqu'un à une idée, je suis preneur, merci.
A bientôt
Seb

**Gillou** · 08/07/2003, 16h35

ben .. tu as une table avec des entrées ... ça , c'est un point qui ne se discute pas...

une clé primaire sert à identifier chaque entrée dans une table ... donc puisque tu as une table, vaux mieux avoir une clé primaire.

de la même manière, une clé étrangère sert a modéliser une relation entre 2 tables, donc autant les utiliser...

l'interet de les utiliser : le SGBD effectue tout seul des vérifications lors de chaque modification de ta base, afin d'etre certain de l'intégrité des données stockées ( histoire de pas se retrouver avec une absence pour un salarié qui n'existe pas , dans ton cas). raison de plus pour les utiliser.

pour les clé étrangères , pas de soucis, tu sais quel champ va servir de clé étrangère.
pour la clé primaire ... on attaque le bon vieux débat : faut il utiliser comme clé primaire une info existante ou bien un identifiant totalement artificiel ? les deux sont possibles. Pour simplifier cependant , il vaut généralement mieux éviter de mettre des clés primaires sur plus d'une colonne.

**Seb7** · 08/07/2003, 16h56

Ok pour le principe général, je suis d'accord avec toi.

Moi, tout ce que je veux, c'est que date_abs de HIST_ABS répertorie toutes les absences des membres du personnel (ceci, individuellement via mat_sal), et que ces absences soient identifiables par un code (code_abs) qui me fournira le libellé correspondant (lib_abs).

J'ai déjà créé un calendrier où sont représentées, par un système de légende couleur, toutes les absences. Il suffira de sélectionner un membre du personnel dans une TListBox pour voir apparaitre le calendrier avec les absences (notées en couleur) qui lui correspondent. Via la souris on pourra sélectionné un jour d'absence (ou un pavé) et il faudra que les dates correspondantes avec le code absence qui va avec soient enregistrés dans la Bdd.
A savoir comment définir les clés dans ma table HIST_ABS

Je sais juste que mat_sal et code_abs doivent être pris en compte.
Peut être faire un truc du style:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
/* ============================================================ */ 
/*   Table : SALARIE                                            */ 
/* ============================================================ */ 
create table SALARIE 
( 
    MAT_SAL          NUMERIC(7)             not null, 
    CODE_ETAB        CHAR(2)                not null, 
    CODE_CY          CHAR(10)               not null, 
    CODE_GRILLE      CHAR(10)               not null, 
    NOM_SAL          CHAR(25)                       , 
    PREN_SAL         CHAR(25)                       , 
    NUM_BAD          NUMERIC(7)                     , 
       constraint PK_SALARIE primary key (MAT_SAL) 
); 
 
/* ============================================================ */ 
/*   Table : ABSENCE                                            */ 
/* ============================================================ */ 
create table ABSENCE 
( 
    CODE_ABS         CHAR(3)                not null, 
    LIB_ABS          VARCHAR(25)                    , 
    constraint PK_ABSENCE primary key (CODE_ABS) 
); 
 
/* ============================================================ */ 
/*   Table : HIST_ABS                                           */ 
/* ============================================================ */ 
create table HIST_ABS 
( 
    CODE_ABS         CHAR(3)                not null, 
    MAT_SAL          NUMERIC(7)             not null, 
    DATE_ABS         DATE                           , 
    constraint PK1_HIST_ABS primary key (CODE_ABS),
    constraint PK2_HIST_ABS primary key (MAT_SAL) 
);
 
 
alter table HIST_ABS 
    add constraint FK_HIST_ABS_ABSENCE foreign key  (CODE_ABS) 
       references ABSENCE (CODE_ABS); 
 
alter table HIST_ABS 
    add constraint FK_HIST_SALARIE foreign key  (MAT_SAL) 
       references SALARIE (MAT_SAL);

Ou carrément supprimer code_abs et mat_sal de la table HIST_ABS.
si quelqu'un se sent inspiré, je l'en remercie d'avance.

**Gillou** · 08/07/2003, 17h10

comme je t'ai dis ton code de départ etait tres bien ... celui que tu viens de donner un peu moins : on ne peut pas avoir 2 clés primaires dans une même table.

Arete de mélanger clé primaire et clé étrangère STP ... etre une clé primaire ne signifie RIEN, sauf que la valeur sera différente pour chaque entrée de la table, ainsi la valeur de la clé primaire permet d'identifier précisément de quelle entrée on parle. c'est comme le numéro de sécu ou la plaque d'imatriculation : en donnant uniquement cette valeur, tu peux retrouver toutes les infos de la personne / du véhicule.

une clé étragère, en revanche, sert à faire référence aux informations contenues dans une autre table...

pour les clés étrangères, le code que tu nous a montré etait tres bien et ça l'est toujours ... arete de te prendre la tête avec ça.

je croyais que tu n'avais pas de problème avec ce qu'était une clé étrangère et une clé primaire ?
je te renvoie au site de SQLPRO : sqlpro.developpez.com , dans lequel tu devrais trouver pas mal d'explication pour t'éclaircir les idées