Discussion :

[ed222]

Bonjour,

Débutant dans le domaine des SGBDR, je rencontre un problème.
Je dispose de 2 tables:
Table Liste : ID_personne(PK) / nom / prenom / tel
Table Metier : ID_metier(PK) / Metier

il faudrait que je crée une table qui associerait à 1 personne, 1 ou plusieurs métiers.
Je pensais en faire une qui n'aurait que 2 colonnes : ID_Metier / ID_Personne dont la clé primaire serait l'association des 2 colonnes. Mon idée est-elle bonne? Est-il possible de faire ça? (j'ai essayé mais je n'arrive pas à le spécifier).

Merci,

Ed.

Edouard.

[elsuket]

Bonjour,

Je pensais en faire une qui n'aurait que 2 colonnes : ID_Metier / ID_Personne dont la clé primaire serait l'association des 2 colonnes. Mon idée est-elle bonne?

Oui, puisque c'est une relation n à n.

Est-il possible de faire ça?

Il vous faut créer la table en mettant les contraintes de clé étrangère, et un spécifiant la clé primaire sur les deux colonnes :

Code :

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

1
2
3
4
5
6
CREATE TABLE personne_metier
(
	ID_personne INT NOT NULL CONSTRAINT FK_personne_metier__ID_personne FOREIGN KEY (ID_personne) REFERENCES dbo.Liste
	, ID_metier INT NOT NULL CONSTRAINT FK_personne_metier__ID_metier FOREIGN KEY (ID_metier) REFERENCES dbo.metier
	, CONSTRAINT PK_personne_metier PRIMARY KEY (ID_personne, ID_metier)
)

Néanmoins comme je l'ai dit ici, il n'est pas très avantageux d'avoir une clé primaire composite.

Si vous allez référencer cette table dans d'autres tables, vous avez tout intérêt à spécifier votre table comme suit :

Code :

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

1
2
3
4
5
6
7
CREATE TABLE personne_metier
(
	ID_personne_metier INT NOT NULL IDENTITY CONSTRAINT PK_personne_metier PRIMARY KEY
	, ID_personne INT NOT NULL CONSTRAINT FK_personne_metier__ID_personne FOREIGN KEY (ID_personne) REFERENCES dbo.Liste
	, ID_metier INT NOT NULL CONSTRAINT FK_personne_metier__ID_metier FOREIGN KEY (ID_metier) REFERENCES dbo.metier
	, CONSTRAINT UQ_personne_metier__ID_personne__ID_metier UNIQUE (ID_personne, ID_metier)
)

De cette façon vous n'avez plus qu'à référencer une seule colonne : ID_personne_metier.

@++

[ed222]

Si vous allez référencer cette table dans d'autres tables, vous avez tout intérêt à spécifier votre table comme suit :

Code :

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

1
2
3
4
5
6
7
CREATE TABLE personne_metier
(
	ID_personne_metier INT NOT NULL IDENTITY CONSTRAINT PK_personne_metier PRIMARY KEY
	, ID_personne INT NOT NULL CONSTRAINT FK_personne_metier__ID_personne FOREIGN KEY (ID_personne) REFERENCES dbo.Liste
	, ID_metier INT NOT NULL CONSTRAINT FK_personne_metier__ID_metier FOREIGN KEY (ID_metier) REFERENCES dbo.metier
	, CONSTRAINT UQ_personne_metier__ID_personne__ID_metier UNIQUE (ID_personne, ID_metier)
)

De cette façon vous n'avez plus qu'à référencer une seule colonne : ID_personne_metier.

@++

Bonjour, merci pour le message. Mais j'avoue ne pas avoir compris cette deuxième solution, notamment "référencer cette table dans d'autres tables"...

encore merci,

Edouard.

[elsuket]

Bonjour, merci pour le message. Mais j'avoue ne pas avoir compris cette deuxième solution, notamment "référencer cette table dans d'autres tables"...

Supposons que vous souhaitiez créer une table, que nous appelons formation_personne_metier, qui pour chaque métier exercé par une personne, stocke la liste des formations suivies.
Pour ce faire vous devez donc référencer par une contrainte de clé étrangère la table personne_metier.

Vous allez donc :

- avec la première table personne_metier que je vous ai donné, devoir ajouter deux colonnes qui correspondent à la clé primaire de celle-ci dans la table formation_personne_metier
- avec la seconde, seulement une colonne, puisque la clé primaire n'est composée que d'une seule colonne

Cela permet donc :

- d'avoir des tables moins larges (moins de colonnes), donc les pages de données de la table seront plus riches, donc vos requêtes plus rapides, d'autant que vos index seront moins larges et moins profonds
- de simplifier vos jointures, puisqu'au lieu de devoir comparer deux entiers deux à deux entre ces deux tables (c'est à dire pour celle que je vous ai donné : 2 INT = 16 octets), vous n'en comparez qu'une seule (8 octets).
Donc vous utilisez moins de puissance de calcul

@++

[ed222]

Re,

très bien, j'ai compris!
merci beaucoup pour ces explications et de prendre un peu de votre temps pour les écrire.

Edouard.

[elsuket]

Avec plaisir

@++