Dans une base de données, une clé primaire identifie chaque ligne, tandis qu’une clé étrangère relie une table à une autre. Ensemble, ces contraintes limitent les doublons et les références incohérentes, sans remplacer une conception attentive des données.
Pour suivre leur rôle, prenons l’exemple d’une boutique qui enregistre des produits, des fournisseurs et des commandes. La distinction entre identifiant, unicité et intégrité référentielle aide à comprendre comment ces règles protègent ses informations.
A retenir :
- Identification stable des lignes grâce à une clé primaire unique
- Relations contrôlées entre tables par des références valides
- Suppressions encadrées pour limiter les enregistrements orphelins
- Indexation réfléchie des colonnes fréquemment utilisées en jointure
Clé primaire : identifier chaque ligne d’une table
Cette première règle fournit un point d’ancrage aux relations décrites ensuite : chaque ligne doit posséder une identité distincte. Selon Microsoft Learn, SQL Server crée un index unique pour appliquer la contrainte de clé primaire.
Unicité et identifiant fiable
Dans la boutique, ProductID peut distinguer chaque produit, même lorsque plusieurs articles partagent le même nom. Une clé primaire ne peut pas contenir de valeur NULL, car une ligne sans identifiant compromettrait les recherches et les références.
Selon Microsoft Learn, une table ne peut avoir qu’une seule contrainte de clé primaire, composée d’une ou plusieurs colonnes. Une clé composite convient, par exemple, à une table d’association qui relie produits et fournisseurs.
Dans ce cas, ProductID et VendorID forment ensemble l’identifiant : chaque valeur peut se répéter séparément, mais leur combinaison doit rester unique.
Les choix pratiques pour définir cette identité :
- Identifiant technique stable pour les lignes fréquemment référencées
- Clé composite pour les associations naturellement définies par plusieurs colonnes
- Colonnes obligatoires, sans valeur NULL dans la clé
Clé composite et conséquences pratiques
Pour la boutique, une ligne d’association « produit-fournisseur » ne doit pas être enregistrée deux fois avec les mêmes identifiants. Une clé composite bloque ce doublon même si chaque colonne, prise isolément, contient des répétitions.
SQL Server limite une clé primaire à 32 colonnes et à 900 octets au total. Il faut donc choisir des colonnes adaptées, plutôt que d’agréger sans nécessité de nombreux champs métier.
| Configuration | Règle appliquée | Exemple d’usage |
|---|---|---|
| Clé simple | Une colonne identifie chaque ligne | ProductID dans la table des produits |
| Clé composite | La combinaison des colonnes est unique | ProductID et VendorID dans une table d’association |
| Valeur NULL | Non admise dans les colonnes de la clé | Identifiant obligatoire pour chaque ligne |
| Index associé | Index unique créé pour la clé primaire | Recherche par identifiant dans les requêtes |
Une fois les lignes identifiées sans ambiguïté, la boutique peut relier ses commandes aux vendeurs et aux produits sans recopier leurs informations.
Clé étrangère : créer une relation entre deux tables
Une identité unique devient utile à l’échelle du modèle lorsqu’une autre table peut s’y référer. La clé étrangère établit cette liaison et aide à préserver l’intégrité référentielle.
Références valides et intégrité référentielle
Dans la boutique, SalesOrderHeader peut contenir le SalesPersonID du vendeur responsable. Cette clé étrangère doit correspondre à un identifiant présent dans la table SalesPerson, faute de quoi la commande pointerait vers une ligne inexistante.
Selon Microsoft Learn, la contrainte contrôle aussi certaines modifications apportées à la table référencée. Par défaut, supprimer un vendeur déjà associé à des commandes échoue tant que les références concernées ne sont pas traitées.
Les actions possibles dépendent du comportement défini dans la relation :
- NO ACTION, refus d’une modification qui casserait les références
- CASCADE, propagation de la suppression ou de la mise à jour
- SET NULL, effacement de la référence si la colonne l’autorise
- SET DEFAULT, remplacement par la valeur définie par défaut
Choisir une action adaptée aux données
Pour des commandes conservées à des fins de suivi, empêcher la suppression d’un vendeur référencé peut être préférable. À l’inverse, une relation temporaire peut accepter SET NULL si l’absence de responsable reste compréhensible.
CASCADE automatise des changements liés, mais demande de mesurer leurs effets sur toutes les tables concernées. Un choix trop large pourrait effacer des informations que l’entreprise souhaitait conserver.
Contraintes SQL Server : index, portée et vérifications
Le choix des règles de relation gagne à être complété par une vérification des usages quotidiens. Une contrainte protège les données, tandis qu’un index adapté peut faciliter certaines recherches.
Index sur les clés étrangères
Contrairement à la clé primaire, la création d’une clé étrangère ne crée pas automatiquement un index sur ses colonnes. Pourtant, ces colonnes servent souvent aux jointures entre commandes et vendeurs.
Un index peut accélérer la recherche de lignes associées, mais son intérêt dépend des requêtes et des opérations d’écriture. L’équipe doit examiner les filtres, les jointures et le coût de maintenance avant de l’ajouter.
Les vérifications utiles lors de la conception :
- Correspondance des types entre clé référencée et clé étrangère
- Colonnes étrangères réellement sollicitées dans les jointures
- Comportement prévu lors des suppressions et mises à jour
- Absence de références orphelines avant l’ajout d’une contrainte
Portée des références dans SQL Server
Selon Microsoft Learn, SQL Server 2016 et les versions ultérieures autorisent, sous conditions, jusqu’à 10 000 références entrantes vers une table, au niveau de compatibilité 130. Au-delà de 253 références, cette prise en charge concerne les opérations DELETE, avec des restrictions sur UPDATE, MERGE et certains types de tables.
Ce plafond avancé ne concerne pas la plupart des modèles courants ; il rappelle toutefois qu’une architecture très interconnectée mérite une revue attentive. Azure SQL Database et Azure SQL Managed Instance prennent également en charge les contraintes décrites dans la documentation Microsoft applicable.
| Élément | Comportement | Point de vigilance |
|---|---|---|
| Clé primaire | Index unique créé automatiquement | Une seule contrainte par table |
| Clé étrangère | Vérification des références entre tables | Pas d’index automatique correspondant |
| Suppression référencée | Refus par défaut avec NO ACTION | Choisir explicitement toute action en cascade |
| Références entrantes étendues | Jusqu’à 10 000 sous conditions documentées | Compatibilité 130 et restrictions opérationnelles |
Un schéma cohérent associe donc des identifiants stables, des références justifiées et des actions adaptées aux usages réels de chaque table.
Source : Microsoft Learn, « Contraintes de clé primaire et de clé étrangère », Microsoft.
Un mot qui se comprend dossier après dossier
Qu'il s'agisse de philosophie bouddhiste, de méditation, de culture tibétaine, d'industrie durable, de linguistique ou de bien-être, chaque rubrique raconte une facette différente de la même question : comment un même mot peut porter, à la fois, une pensée millénaire et un usage bien actuel. Rien n'est figé : chaque contexte nouveau peut encore faire évoluer ce sens.
Pour aller plus loin
- Comparer plusieurs sources avant de juger la portée d'une traduction ou d'une définition
- Replacer chaque terme dans son contexte culturel réel, pas seulement sa traduction littérale
- S'intéresser aux usages vivants de la langue autant qu'aux définitions figées
- Observer comment un même mot évolue d'un domaine à l'autre au fil du temps
