Discussion :

[West01]

Bonjour,

Je n'arrive pas a comprendre la différence entre une clé candidate, clé primaire et clé unique.

Je trouve que ce sont tous des synonymes et je n'arrive pas a faire la différence ?

Une aide serait appreciée.

Merci.

[SQLpro]

Un clef candidate est un concept au niveau modélisation. Ce sont n'importe quels attributs d'une relation capable de retrouver un élément unique de la relation (tuple) par leur(s) valeur(s).

Une clef primaire est un concept au niveau du modèle mais aussi des SGBDR.
La clef primaire est une clef choisit parmi les clef candidates.

Une clef unique, cela n'existe pas. En revanche il existe des CONTRAINTES D'UNICITÉ. (SGBDR).

Petit exemple :

SALARIÉ(Nom, Prenom, DateNaissance, Matricule, N°Sécu)

Clef candidate : Matricule ou N°Sécu
Si je prends comme clef primaire de ma relation le Matricule, alors la relation devient :
SALARIÉ(N°Sécu, Nom, Prenom, DateNaissance, Matricule)

Lorsque je vais traduire cela en tables, j'aurais intérêt à définir en sus de la clef primaire une contrainte d'unicité sur la colonne Matricule, afin d'éviter que l'on ne saisisse par erreur un même matricule à deux employés différents.

A +

[West01]

Merci pour la reponse.

Mais je ne comprends pas toujours le concept de clé candidate . Je trouve trop abstrait la definition que vous m'avez envoyé. (Ca ressemble a la definition que j'ai dans mon livre).

Est-ce possible d'avoir un exemple concret.


Pour ce qui est des autres clés, ca va.

Merci.

[Zelphalya]

Si je comprends bien (me corriger si je me trompe) :

Imaginons que je définisse une contrainte d'unicité sur le trio "Nom", "Prenom", "dateNaissance". Ce trio est une clef candidate ? (car il me permet de retrouver une unique entrée)

[Xo]

Mais je ne comprends pas toujours le concept de clé candidate .

Pour une voiture, une clé candidate pourrait être son n° d'immatriculation, ou son n° de série, qui sont censés être uniques.
Pour une personne, son numéro de sécu (en France) est une clé candidate. Son adresse mail peut en être une autre (si toutes les personnes gérées ont un mail)
Pour des livres, le n° d'ISBN est une clé candidate

Si je comprends bien (me corriger si je me trompe) :

Imaginons que je définisse une contrainte d'unicité sur le trio "Nom", "Prenom", "dateNaissance". Ce trio est une clef candidate ? (car il me permet de retrouver une unique entrée)

Hum, presque, mais avoir des doublons sur cette combinaison reste possible, bien que assez improbable en fonction de la population que tu veux gérer

[Zelphalya]

Comment avoir des doublons si j'ai défini une contrainte d'unicité (comme j'ai dit)

[Xo]

Comment avoir des doublons si j'ai défini une contrainte d'unicité (comme j'ai dit)

Si tu définis une telle contrainte, tu n'auras pas de doublons dans tes données.

Ma remarque portait sur la pertinence de la définition d'une telle contrainte, il est possible de trouver des homonymes nés à la même date in the real life

[Zelphalya]

Je suis tout à fait d'accord à ce niveau, mais bon c'était pour travailler sur l'exemple déjà donné

[fsmrel]

Bonjour West01,

Voici ce qu’écrivait en 1971 Ted Codd, père du Modèle Relationnel de Données (je traduis) :

Clés candidates

Chaque clé candidate K d’une relation R (sous-entendez table) est par définition une combinaison d’attributs de R (à la limite un attribut unique) possédant les propriétés P1 et P2 suivantes :

P1 : (Unicité) Pour chaque tuple de R (sous-entendez ligne), la valeur de K identifie (de manière unique) ce tuple ; c’est-à-dire R.K --> R.OMEGA, OMEGA représentant la collection de l’ensemble des attributs de la R ;

P2 : (Non redondance) Aucun attribut de K ne peut en être évacué sans détruire la propriété P1.

Évidemment, il existe toujours au moins une clé candidate, parce que la combinaison de l’ensemble des attributs de R possède la propriété P1. Reste le problème de chercher les sous-ensembles ayant la propriété P2.

Mon commentaire personnel : la dernière affirmation peut être infirmée si un des attributs de R peut être NULL. Bon, ça n’est pas le problème, à la limite on crée un attribut non NULL dont le rôle est d’être clé primaire, cf. ci-dessous.


Un peu plus loin :

Pour chaque relation R d’une base de données, une de ses clés candidates est arbitrairement désignée comme clé primaire de R. La distinction habituelle que l’on fait entre la clé primaire et les autres clés candidates (s’il y en a d’autres) est qu’un tuple ne peut comporter de valeur indéfinie pour les composants de cette clé, alors que les composants hors la clé peuvent être indéfinis.
Cette restriction est imposée à cause du rôle vital joué par la clé primaire dans les algorithmes de recherche....

Pour imager, je dirais que la clé primaire est aux clés candidates non retenues ce qu’est Miss France pour ses dauphines...

Une clé candidate non retenue comme clé primaire est encore appelée clé alternée ou encore de rechange (Alternate key)

Référence :
E. F. Codd: Further Normalization of the Data Base Relational Model. IBM Research Report RJ 909, San Jose, California: (1971)

Bonne quête...