Database Reference
In-Depth Information
Une clé naturelle peut ne pas être connue lors de la saisie primale… Que se passe-t-il si
le patient que vous avez modélisé avec comme identiiant son numéro de Sécurité sociale
arrive à l'hôpital sans ses papiers et dans le coma ?
Une clé naturelle peut évoluer dans le temps… Que se passe-t-il si ayant modélisé vos
adhérents par leurs nom et prénom, Marie DUPONT se marie avec Albert DUVAL ? Quid
des données des nombreuses tables illes ?
Une clé naturelle est souvent longue… Un numéro de Sécurité sociale (13 caractères),
comme le couple nom et prénom (en moyenne, 15 caractères), c'est 3 à 4 fois plus long
qu'un entier et permet environ 6 fois moins de combinaisons (en pratique, on ne peut uti-
liser qu'une quarantaine de caractères sur les 25 possibles). C'est donc facilement 24 fois
moins performant !
Préférez une clé arbitraire la plus courte possible. Par exemple, un entier auto-incrémenté
(
SEQUENCE
,
IDENTITY
en SQL). L'utilisation des GUID (Globally Unique IDentiier)
ou UUID (Universally Unique Identiier) posant d'autres problèmes en plus de ne pas
garantir l'unicité absolue…
Plusieurs, c'est possible ?
Un objet peut être identiié par différents attributs. L'exemple suivant illustre cette possibilité :
tout livre peut être référencé par plusieurs identiiants (un code éditeur, des numéros ISBN, des
codes-barres…). Ce raisonnement vaut pour la majorité des autres types de produits.
Figure 1-12
. Plusieurs identifiants
Il.est.possible.de.définir.dans.une.classe.plusieurs.identifiants.à.la.condition.qu'un.seul.soit.
principal.
