Discussion :

[ctobini]

Bonjour,

Je bute sur un petit problème: j'aborde la méthode Merise et ça va plutôt pas mal dans la théorie mais j'ai un petit problème dans la pratique: j'ai résolu un exercice dans lequel je passe par une table de transition où (d'après la méthode et également le corrigé) j'ai 3 clés primaires/secondaires se référant à 3 autres tables.

Le problème est que lorsque je passe ceci :

create table tab1 (id int);
create table tab2 (id int);
create table tab3 (id int);

create table entre (
id_tab1 int primary key,
id_tab2 int primary key,
id_tab3 int primary key,
foreign key (id_tab1) references tab1(id),
foreign key (id_tab2) references tab2(id),
foreign key (id_tab3) references tab3(id)
);

dans Postgresql j'ai une erreur :

ERREUR: les clés primaires multiples ne sont pas autorisées pour la table «entre»

Sur ce que je peux en lire et les corrigés des exercices, une table faisant la liaison avec des cardinalités (X, n) vers d'autres tables prends en PK et FK les PK des autres tables :

table entre
id_table1 pk,fk
id_table2 pk,fk
id_table3 pk,fk
...

Auriez-vous un conseil à ce sujet ?

En vous remerciant,

[fsmrel]

Une table ne peut posséder qu'une seule clé primaire, par exemple id_tab1 pour la table Entre.

id_tab2 et id_tab3 sont alors des clés alternées, ce qui implique qu'en SQL vous remplaciez la clause "PRIMARY KEY" par la clause 'UNIQUE" pour ces deux colonnes. L'effet est le même...

[ctobini]

Bonjour et merci de votre intervention,

Du coup je comprends mieux que les 3 tables id soient en clé étrangères et avec une contrainte unique. Cela-dit la notation pk,fk induit en erreur.

Merci encore en bonne soirée,

C. Tobini

[*alexandre*]

une clef primaire peut être composé

[ctobini]

Bonjour,

C'est à dire avoir des attributs supplémentaires à la clé comme par exemple :

table
id_table pk
attribut1
attribut2
#ref_autre_table fk

Ou cela a t'il une autre signification ?

C. Tobini

[qi130]

Je pense plutôt à une autre signification:

Code :

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

1
2
3
create table entre
....les colonnes..
PRIMARY KEY (id_tab1,id_tab2,id_tab3)

Puis ajouter les contraintes de FK

Selon les SGBD, on peut passer toutes ces déclarations dans le même script, ou alors il faut fragmenter : création, puis déclaration de la PK, puis ajout des FK.

[ctobini]

Bonjour et merci beaucoup, j'ai bien ajouté la contrainte PK puis FK sur les 2 variables après les avoir déclarées, c'est impeccable

Merci encore et bon week-end,

C. Tobini

[fsmrel]

Bonjour C. Tobini,

Je pense que le forum Merise n’est pas le plus indiqué pour parler de concepts relevant du Modèle Relationnel de Données. Le forum Général SGBD est plus approprié.

Je répondrai quand même, d’abord au niveau Merise, puis au niveau relationnel.

Considérez l’entité-type Commande dans un MCD. Cette entité-type a des propriétés monovaluées comme le numéro de commande, la date de commande, mais aussi des propriétés multivaluées comme les lignes de commande. Il est d’usage en Merise de transformer les propriétés multivaluées en entités-types, en conséquence de quoi, outre l’entité-type Commande, on met en œuvre une entité-type Ligne de Commande.

Mais, pour se souvenir que les entités-types Commande et Ligne de Commande n’ont pas le même poids, on dit que cette dernière est une entité-type faible (weak) par rapport à la première, considérée par contraste comme entité-type forte (ce qui n’empêche pas de voir Ligne de Commande comme entité-type forte relativement à une entité-type plus faible, telle que Engagement sur Ligne de Commande, dans la mesure où une ligne de commande est composée à son tour d’engagements en fonction de la disponibilité des produits en stock).

La relation entre Commande et Ligne de Commande est une surjection, les cardinalités qu’on lui attribue étant de type 1,n/1,1 (une commande est composée de 1 à n lignes de commande et une ligne de commande entre dans la composition d’une et une seule commande).

Pour signifier qu’une ligne de commande est une entité-type faible, on symbolise ceci en enrichissant la cardinalité 1,1 par un symbole supplémentaire au niveau du MCD :

1,1 devient (R) 1,1 avec Win’Design,
1,1 devient (1,1) avec PowerAMC,
etc.

Étant donné que l’entité-type Ligne de commande est en réalité une propriété de l’entité-type Commande, elle a fondamentalement pour identifiant celui de Commande (que j’appellerai identifiant générique). Cela dit, si l’on en restait là, toutes les lignes de commande d’une même commande doublonneraient au niveau de cet identifiant générique. Pour résoudre ce problème, soit on dote Ligne de Commande d’un nouvel identifiant absolu, soit on complète l’identifiant générique (par exemple au moyen d’un séquenceur (dont la valeur repart à 1 avec chaque nouvelle commande) ou du numéro de ligne de commande) auquel cas l’identifiant de Ligne de Commande est appelé Identifiant relatif. Supposons que l’identifiant de Commande soit Cde_Id et que l’on complète par un séquenceur Ligne_Cde_Id, l’identifiant de Ligne de Commande est donc le suivant, composé de 2 propriétés :

{Cde_Id, Ligne_Cde_Id}

Nous traitions d’un problème relevant du forum Merise. Venons-en au sujet relevant des bases de données relationnelles.

Clé candidate

Quand vous passez du niveau conceptuel au niveau relationnel, les entités-types Commande et Ligne de Commande deviennent des tables et leurs propriétés deviennent des colonnes (ou attributs). Ces colonnes constituent des ensembles que l’on appelle entêtes de tables. Par exemple, les tables Commande et Ligne de Commande ont pour entêtes respectives :

Commande (Cde_Id, No_Commande, Date_Commande, Fournisseur_Id, ...)
Ligne de Commande (Cde_Id, Ligne_Cde_Id, No_Ligne_Commande, Article_Id, Quantité, ...)

Qu’advient-il des identifiants ? La théorie relationnelle traite du concept que l’on appelle "Clé candidate" (Candidate key).

Soit K un sous-ensemble de l’entête d’une table T ; K est une clé candidate pour T si et seulement si :

a) Il n’est pas possible que deux lignes distinctes de T aient même valeur pour K (propriété d’unicité).
b) En outre, aucun sous-ensemble strict de K ne vérifie la propriété d’unicité (propriété d’d’irréductibilité).

On a précisé au niveau conceptuel que la propriété Cde_Id identifie l’entité-type Commande. On infère qu’au niveau tabulaire, {Cde_Id} est donc clé candidate pour la table Commande. A contrario, le couple {Cde_Id, Date_Commande} n’est pas clé candidate pour cette table, car s’il vérifie la propriété d’unicité, il ne vérifie pas la propriété d’irréductibilité puisqu’il comporte le sous-ensemble strict {Cde_Id} vérifiant cette propriété.

Une table peut comporter plus d’une clé candidate. Supposons en effet qu’un sous-ensemble K’ de l’entête de la table Commande soit composé de la seule colonne No_Commande. Si deux commandes ne peuvent pas avoir le même numéro de commande, alors K’ vérifie la propriété d’unicité pour la table Commande. K’ étant singleton, il est vérifie de facto la propriété d’irréductibilité : No_Commande est clé candidate, au même titre que Cde_Id.

A titre d’exercice, je vous laisse le soin de montrer que le couple {Cde_Id, Ligne_Cde_Id} est clé candidate pour la table Ligne de Commande et de déterminer le nombre de clés candidates que comporte cette table.

Surclé

On appelle ainsi un sous-ensemble de l’entête d’une table T, vérifiant nécessairement la propriété d’unicité mais pas nécessairement celle d’irréductibilité. Une clé candidate est un cas particulier de surclé, plus restrictif. Le concept de surclé est surtout utilisé dans la théorie de la normalisation.

Clé primaire

Le Modèle Relationnel de Données ne mentionne plus le concept de clé primaire qu’à titre historique. Par contre, vu le nombre d’instructions CREATE TABLE actives au niveau planétaire, les SGBDR sont astreints à le conserver. Une clé primaire est une clé candidate que l’on a privilégiée parmi l’ensemble des clés candidates d’une table (en SQL, si on utilise le concept, il existe au moins et au plus une clé primaire par table). Quand, par exemple, on dérive un MCD Merise, il est d’usage de faire de l’identifiant d’une entité-type, la clé primaire de la table correspondante. Ainsi, {Cde_Id} sera clé primaire de la table Commande et le couple {Cde_Id, Ligne_Cde_Id} clé primaire de la table Ligne de Commande.

Clé alternative

On appelle clé alternative (ou alternée, ou de rechange, etc., en anglais Alternate key) une clé candidate non retenue comme clé primaire.

A noter qu’avec le langage SQL, l’instruction CREATE TABLE comporte la clause PRIMARY KEY pour définir la clé primaire d’une table, et la clause UNIQUE pour les clés alternatives. Cela dit, certains SGBDR (SQL Server 2005 par exemple) permettent de remplacer la clause PRIMARY KEY par la clause UNIQUE.

Clé étrangère

Soit T1 et T2 deux tables, non nécessairement distinctes, et soit K1 une clé candidate de T1, K1 étant composée des colonnes A1, A2, ..., Am. Soit FK un sous-ensemble de colonnes de T2 tel que chaque colonne B1, B2, ..., Bm de FK soit du même type que son homologue A1, A2, ..., Am.
FK est une clé étrangère si et seulement si, à tout moment, pour chaque ligne de T2, il existe dans T1 une ligne (nécessairement unique) pour laquelle la valeur de FK est égale à celle de K1.
T1 est la table référencée et T2 la table référençante. La contrainte entre ces deux tables est appelée contrainte d’intégrité référentielle (ou contrainte référentielle).

Vous observerez que la colonne Cde_Id de la table Ligne de Commande est nécessairement clé étrangère par rapport à la colonne Cde_Id de la table Commande, sinon on pourrait se retrouver avec des lignes de commande référençant des commandes inexistantes, un truc à se faire virer de l’équipe des DBA.
Vous noterez que, par voie de conséquence, tout où partie d’une clé candidate d’une table peut aussi être clé étrangère.

J’espère avoir répondu à quelques questions que vous vous posiez.

Bon courage,

Fsmrel

[ctobini]

Bonjour, je reviens sur le forum un petit peu tardivement, je n'avais pas vu votre réponse car je n'ai pas d'avertissement par mail et je l'avais mis comme 'résolu'.

Je viens de lire avec attention votre message qui est plus que complet pour un début, merci beaucoup d'avoir pris le temps de le rédiger, je vais m'attarder sur certaines notions que je ne maitrise pas (comme la question sur la clé candidate :-) ) et l'importance de trouver la 'bonne' clé.

Bonne journée et à bientôt,

C. Tobini

[fsmrel]

Bonjour C. Tobini,

Vous pouvez également vous intéresser à la discussion qui est une variation sur le thème dont nous avons débattu :

http://www.developpez.net/forums/sho...d.php?t=281221