L’intégrité garantit l’absence
d’incohérence Le concept d'intégrité ou de cohérence (integrity, consistency, en
anglais) signifie l'absence d'incohérence dans les ensembles de données. Si les données enregistrées étaient introduites sans erreur et qu'elles délivrent les informations désirées de manière correcte, on dit que la base de données en question est intègre ou cohérente. En revanche, l'intégrité d'une base de données est violée si les données présentent des ambiguïtés ou des incohérences. Quand nous certifions par exemple que la table EMPLOYÉ est cohérente, nous admettons par là que les noms des employés, les noms des rues et des villes, etc., sont corrects et existent aussi dans la réalité.
Quelles sont les contraintes d’intégrité structurelles ?
Lescontraintes d'intégrité structurelles établissent des règles qui doivent s'appliquer à un schéma de base de données pour assurer sa cohérence. Dans le contexte des bases de données relationnelles, les contraintes d'intégrité structurelles sont classées en trois catégories :
contrainte d'unicité : chaque table possède une clé d'identification (un attribut ou une combinaison d'attributs) qui sert à différencier les tuples dans la table de manière unique ;
contrainte de domaine : un attribut dans une table ne peut prendre que des valeurs appartenant à un domaine prédéfini ;
contrainte d'intégrité référentielle : chaque valeur d'une clé étrangère doit correspondre à une valeur existante de la clé dans la table référencée.
L’unicité doit être assurée par le système de gestion des bases de données
Lacontrainte d'unicité requiert une clé par table. Lorsqu'il existe plusieurs clés candidates dans une même table, la contrainte d'unicité nous oblige à en déclarer une comme clé primaire. C'est le système de gestion des bases de données qui vérifie l'unicité des valeurs d'une clé primaire.
Comment vérifier les contraintes de domaine ?
En revanche, ce système ne peut pas garantir le respect total d’une contrainte de domaine. Certes, nous pouvons définir un domaine par colonne dans une table, mais les domaines ne représentent qu'une petite partie des règles de validation. Par exemple, la définition d'un domaine n'a pas de sens lorsqu'il s'agit de vérifier la correction des noms de ville ou de rue. En effet, la spécification
«CHARACTER (20)» qui désigne le type et la taille d'une chaîne de caractères ne permet pas de vérifier si le nom d'une ville ou d'une rue existe. Il incombe aux utilisateurs, dans une large mesure, de définir jusqu’à quel point le contenu des tables doit être validé.
Importance des contraintes de domaine
La définition d'une contrainte de domaine basée sur les types énumérés est une technique importante qui consiste à créer une liste de toutes les valeurs possibles d'un attribut. Comme exemples de types énumérés, nous pouvons imposer aux attributs Profession et Année les contraintes de domaine suivantes : Profession = {Programmeur, Analyste, Organisateur}, Année = {1950..1990}. La
plupart des systèmes de gestion de bases de données actuels prennent en charge ce genre de règles de validation.
Que signifie l’intégrité référentielle ? Le concept d'intégrité référentielle (referential integrity, en
anglais) introduit une classe importante de règles de validation des données. Une base de données relationnelle respecte la contrainte d'intégrité référentielle si, pour toute valeur d'une clé étrangère, il existe une valeur identique de la clé primaire correspondante.
Considérons l'exemple dans la figure 2-21. La table DÉPARTEMENT admet le numéro de département D# comme clé primaire. Celle-ci est utilisée dans la table EMPLOYÉ comme clé étrangère associée à l'attribut D#_Affectation qui détermine le département auquel un employé est affecté. Le lien entre les clés primaire et secondaire respecte la contrainte d'intégrité si, dans la table EMPLOYÉ, tous les numéros de département de la clé étrangère existent comme valeurs de la clé primaire dans la table DÉPARTEMENT. Dans notre exemple, nous constatons qu'aucune affectation ne transgresse la règle de l'intégrité référentielle.
Figure 2-21 La garantie de l’intégrité référentielle
Violation de l’intégrité Soit «E20, Morel, chemin du Cerisier, Marly, D7» un nouveau
tuple que nous désirons insérer dans la table EMPLOYÉ. Cette insertion sera rejetée par un système de gestion de base de données
D# Description
E# Nom Rue Ville D#_Affectation
E19
avenue de la Gare rue Faucigny
qui supporte l'intégrité référentielle. La valeur D7 sera déclarée invalide, car elle n'existe pas dans la table référencée DÉPARTEMENT.
La garantie de l'intégrité référentielle déclenche des actions spécifiques non seulement lors de l'insertion des données, mais aussi dans les autres opérations sur une base de données. Lorsqu'on veut supprimer un tuple dans une table, et que ce tuple est référencé par d'autres tuples dans une table étrangère, le système peut se comporter de plusieurs manières.
Suppression restreinte
En mode de suppression restreinte (restricted deletion, en anglais), l'opération ne sera pas exécutée tant que le tuple à supprimer est référencé par un tuple dans une autre table. Par exemple, si nous voulons détruire le tuple «D6, Finances» dans la figure 2-21, notre opération sera refusée en vertu de la règle de suppression restreinte, car les deux employés Savoy et Brodard travaillent dans le département D6.
Suppression en cascade
Au lieu de la suppression restreinte, nous pouvons opter pour le mode de suppression en cascade (cascaded deletion, en anglais) dans la spécification des deux tables EMPLOYÉ et DÉPARTEMENT. En mode cascade, la suppression d'un tuple entraîne celle de tous les tuples dépendants. Dans notre exemple de la figure 2-21, si nous demandons la suppression en cascade du tuple «D6, Finances», alors les deux tuples «E19, Savoy, avenue de la Gare, Romont, D6» et «E4, Brodard, rue du Tilleul, Fribourg, D6» seront détruits en même temps.
Suppression avec mise à la valeur nulle
Dans le cadre de l’intégrité référentielle, une troisième option consiste à donner la valeur «inconnue» aux clés étrangères référencées lors d'une suppression. Nous reviendrons à cette troisième règle en détail au chapitre 3 lors de notre discussion sur les valeurs nulles. Enfin, les opérations de mise à jour peuvent aussi être soumises à des contraintes qui garantissent en permanence l'intégrité référentielle d'une base de données.