Nom de la clé primaire vue par les utilisateurs?

Bonjour,

Quel est le nom que l'on donne à la clé primaire qui peut être modifié par l'utilisateur?

Dans mes schémas, j'utilise toujours une clé primaire invisible à l'utilisateur et qui est celle qui est utilisée pour faire les relations. Parfois, les utilisateurs peuvent voir un champ qui doit être unique qui pourrait être une clé primaire.

Par exemple:
Produits(pkProduitID, UPC, description, ...)
detailFacture(pkDetailProduitID, ..., fkProduitID)

pkProduitID est un numéro de série invisible et qui est la vrai clé.
UPC est le code à barre d'un produit qui est unique et que l'utilisateur peut modifier.

Quel est le nom que l'on donne pour l'UPC?

Merci

Citation:

---

Envoyé par el_pablo

... Quel est le nom que l'on donne pour l'UPC?

---

Une clé candidate, je dirais ... ( "surrogate key" en anglais )

Mais ce n'est pas une clé primaire puisque par définition la clé primaire est toujours unique pour une table donnée ...

C'est ce que je croyais, mais après avoir vérifié avant de "poster" la clé candidate semble être un amalgame de plusieurs champs tel une clé composée.

Structurellement parlant, il n'y a pas de problème à ce qu'une table possède plusieurs clés primaire?

Il n'y a pas "plusieurs clés primaires" dans une table ! Il n'y en a qu'une qui sert à distinguer chaque ligne de la table.

Par contre, cette clé primaire peut être composée de plusieurs colonnes. Imaginons une table mémorisant le thème du mois :
Themes(T_Annee, T_Mois, T_LibelleTheme)
La clé primaire est ici composée de l'année et du mois.

C'est le cas aussi dans les tables associatives. La clé primaire est alors composée des clé étrangères issues des clés primaires des tables entrant en jeu dans l'association.
Exemple :
"Une personne peut travailler à plusieurs projet et un projet fait travailler de une à plusieurs personnes"
Personne -0,n----Travailler----1,n- Projet

Personne (P_Id, P_Nom, P_Prenom...)
Projet (Pj_Id, Pj_NomProjet, ...)
Travailler (T_IdPersonne, T_IdProjet, ...)

Dans ton cas, le code barre est unique pour un produit mais n'est pas la clé primaire, c'est donc une clé candidate.

La démarche normale serait de dire dans le cahier des charges que le produit est identifié par son code barre. Le code barre est alors un candidat pour être clé primaire (donc on l'appelle clé candidate) mais c'est la bonne pratique informatique qui justifie la préférence d'un identifiant entier auto-incrémenté et invisible pour l'utilisateur plutôt qu'un code pouvant être alphanumérique (donc moins performant à traiter) et changeant (ce qui impliquerait de modifier les clés étrangères où il serait utilisé). L'exigence du cahier des charges fait qu'on va implémenter une contrainte UNIQUE sur la colonne stockant le code barre.

Avant le choix de la clef primaire toutes les clés potentielles sont appelées clefs candidates.
Lorsque le choix de la clef primaire est effectué, alors toutes les autres clefs sont nommées clefs subrogées (ce qui signifie "pouvant est substituée à").
En principe toutes les clefs subrogées doivent être transformée en caintraintes d'unicité.

A

Clé subrogée... première fois que j'entends ce terme! Je présume que c'est la surrogate key en anglais. À rajouter dans mon vocabulaire francophone!

Suite à vos réponses, j'ai une nouvelle question. Comment fait-on pour contraindre l'unicité des clés composés?

Merci

NB

Code:

---

1 2	ALTER TABLE LaTable ADD CONSTRAINT UNIQUE (Col1, Col2)

---

Les clefs subrogées sontparfois aussi mentionnées sous le terme de clefs "alternatives" (alternate key) mais je préfère la subrogation qui indique, avec justesse, un idée de "soumission" !

A +