« Les bases de données/Le vocabulaire de base des BDD » : différence entre les versions

Contenu supprimé Contenu ajouté
Ligne 169 :
 
En théorie, l'ajout ou la modification d'un enregistrement dans la table ne doit pas pouvoir permettre la présence de doublons : chaque ligne n'est présente que dans un seul exemplaire dans la table. Dans la pratique, c'est une autre paire de manche : de nombreux SGBD acceptent d'avoir des lignes en plusieurs exemplaires dans une table sans problème. Mais nous allons passer cette contrainte sous le tapis pour le moment.
 
===Clés primaires et secondaires===
 
Comment le SGBD peut-il éviter les doublons ? Une solution simple consisterait à interdire l'ajout d'une ligne si on trouve une ligne identique dans la table. Mais cette solution pose un léger problème quand les valeurs NULL sont autorisées dans la table : on peut ajouter une ligne identique à une autre dans la table, si ce n'est qu'un champ autrefois à NULL a été modifié. Or, je rappelle que NULL peut signifier que la valeur de l'attribut n'était pas connue lors de la création de la ligne. Dans ce cas, rien ne nous garantit que les deux lignes correspondent à des clients/objets/personnes différents : il se peut très bien que la ligne ajoutée corresponde à la même personne ou au même objet, mais pour lequel on dispose de plus d'informations qu'avant.
 
Pour éviter ce genre de désagrément, et quelques autres que nous aborderons plus tard, on doit trouver un mécanisme pour identifier chaque donnée dans la table. Ce mécanisme consiste à choisir un ensemble de colonnes qui détermine un objet ou une personne unique dans la table : on sait que si ces ensembles d'attributs ont la même valeur dans deux lignes, alors les deux lignes correspondent à une même donnée. Cet ensemble de colonnes est ce qu'on appelle une '''clé'''. Les clés peuvent très bien contenir une seule colonne, mais c'est tout sauf systématique. Dit autrement, chaque personne ou objet donnera une seule et unique valeur pour chaque attribut de la clé : deux données différentes auront au moins un attribut dont la valeur sera différente. Par exemple, prenons le cas d'un établissement scolaire qui établit une liste d'élèves. Il arrivera certainement que deux élèves aient le même prénom ou le même nom de famille : dans ce cas, l'ensemble des colonnes nom et prénom ne peuvent pas servir de clé primaire.

Un même enregistrement peut très bien avoir plusieurs clés. Dans ce cas, on choisit le plus souvent une clé parmi toutes les autres, qui sera considérée comme une meilleure clé que les autres : c'est la '''clé primaire'''. Les autres clés seront alors appelées des '''clés secondaires''' ou clés alternatives. Petit détail : dans une clé primaire, les attributs ne peuvent pas être à NULL. Dit autrement, seules les colonnes qui n'appartiennent pas à la clé primaire peuvent contenir des NULL. Généralement, on peut préciser au SGBD quelles sont les colonnes qui peuvent servir de clé primaire : tout introduction d'un NULL dans un attribut de cette colonne se soldera par un message d'erreur et un refus d'insérer la ligne dans la table. Cette contrainte est ce qu'on appelle la contrainte de clé.
 
===Clés artificielles===
 
Certaines clés ne sont même pas dérivées des informations présentes dans la ligne : on peut très bien ajouter un identifiant sans signification pour chaque ligne de la table. Par exemple, on peut attribuer arbitrairement un identifiant numérique pour chaque élève d'un établissement scolaire, à une personne dans la population (pensez au numéro de sécurité sociale), à tout livre publié (ISBN), ou à toute autre forme de donnée présente dans une table. Ces identifiants attribués arbitrairement sont appelés des '''clés artificielles''', et sont généralement des nombres entiers.