Modèle relationnel

Etape 4: Les contraintes d'intégrités

Le concept d'intégrité signifie l'absence d'incohérence dans une base de données. Les contraintes d'intégrité structurelles établissent des règles qui viennent compléter le schéma relationnel de la base de données pour assurer sa cohérence et seront par la suite traduites en SQL dans le système de gestion de base de données afin d'assurer la cohérence de la base de données. Ajouter un enregistrement, supprimer un enregistrement ou modifier la valeur d'attribut d'un enregistrement sont des opérations qui ne sont autorisées par le SGBD que si les contraintes d'intégrité structurelles sont toujours respectées par les données après l'opération. Si les contraintes sont violées, nous dirons alors que les données ont perdu leur intégrité.

Les contraintes d'intégrité sont classées en quatre catégories:

• Contrainte de domaines

  Dans une table, un champ ne peut prendre que des valeurs appartenant à un domaine de valeurs prédéfinies. Comme nous le verrons par la suite, le langage SQL admet divers types de données pour la déclaration d'un champ de table, parmi lesquels nous retiendrons:

  • INT: entiers signés longs;
  • DECIMAL(p, q): nombres décimaux d'au moins p chiffres dont q après le point décimal;
  • CHAR(p): chaîne de longueur fixe de p caractères;
  • TEXT: zone de texte standard;
  • VARCHAR(p): chaîne de longueur variable d'au plus p caractères;
  • DATE: dates au format anglophone (années, mois et jour);

  Ce domaine de valeurs peut être rajouté à chaque attribut d'une table directement dans le schéma relationnel:

  EMPLOYE(employeID INT, Nom VARCHAR(20), Rue VARCHAR(30), Ville VARCHAR(20), AffectationID INT)
  

• Contrainte de valeur non nulle

  En travaillant avec une base de données, nous rencontrerons souvent des données dont les valeurs ne sont pas (ou pas encore) connues dans une table. Par exemple, un employé peut être inséré dans la table EMPLOYE sans qu'on connaisse son adresse complète. Dans pareils cas, il s'avère judicieux d'insérer des valeurs dites nulles au lieu de valeurs peu significatives voire fausses. Une valeur nulle est donc une donnée de remplissage fictive représentant une valeur de donnée qui n'est pas (ou pas encore) connue dans une colonne d'une table. Naturellement, les attributs d'une table ne doivent pas tous admettre des données de valeurs nulles, sinon des conflits surgiront inévitablement. Pour empêcher un attribut d'être mis à la valeur nulle, il faut lui appliquer une contrainte de valeur non nulle lors de la définition de la table. Cette contrainte est indispensable, par exemple, pour assurer le caractère complet d'une spécialisation ou pour préciser qu'une association est de type simple (1) et non conditionnel (c).

  Dans l'exemple suivant, la contrainte de valeur non nulle assure que chaque employé est affecté à un département:

  EMPLOYE(employeID INT, Nom VARCHAR(20), Rue VARCHAR(30), Ville VARCHAR(20), AffectationID INT NOT NULL)
  

• Contrainte d'unicité

  Chaque table de la base de données doit posséder une clé d'identification (un attribut ou une combinaison d'attributs) qui sert à différencier les enregistrements dans la table de manière unique. Lorsqu'il y a 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 de bases de données qui vérifie l'unicité des valeurs d'une clé primaire.

  La contrainte d'unicité est représentée dans le schéma relationnel par un soulignement de l'attribut (ou de la combinaison d'attributs) jouant le rôle de clé primaire:

  EMPLOYE(employeID INT, Nom VARCHAR(20), Rue VARCHAR(30), Ville VARCHAR(20), AffectationID INT NOT NULL)
  

• Contrainte d'intégrité référentielle

  Chaque valeur d'une clé étrangère doit exister comme valeur de la clé d'identification correspondante dans la table référencée.

  Cette contrainte est traduite dans le schéma relationnelle en indiquant l'attribut lié à la clé étrangère dans la table étrangère:

  EMPLOYE(employeID INT, Nom VARCHAR(20), Rue VARCHAR(30), Ville VARCHAR(20), AffectationID INT NOT NULL)
        FOREIGN KEY (AffectationID) REFERENCES DEPARTEMENT (departementID)
  

  Dans notre exemple, la table DEPARTEMENT admet le numéro de département departementID comme clé primaire. Celle-ci est utilisée dans la table EMPLOYE comme clé étrangère associée à l'attribut AffectationID 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é référentielle si, dans la table EMPLOYE, tous les numéros de département de la clé étrangère existent comme valeurs de la clé primaire dans la table DEPARTEMENT:

  

  Garantie de l'intégrité référentielle

La garantie de l'intégrité référentielle déclenche des actions spécifiques lors de la suppression d'un enregistrement provenant d'une table et référencé par d'autres enregistrements dans une table étrangère. Le système de gestion de base de données peut alors se comporter de plusieurs manières:

• Suppression restreinte

  Avec la suppression restreinte, l'opération ne sera pas exécutée tant que l'enregistrement à supprimer est référencé par un enregistrement dans une autre table. Par exemple, si nous voulons détruire l'enregistrement «6, Finances» dans la table DEPARTEMENT, notre opération sera refusée en vertu de la règle de suppression restreinte car deux employés (Savoy et Brodard) travaillent dans ce département.

• Suppression en cascade

  Avec la suppression en cascade, la suppression d'un enregistrement entraîne celle de tous les enregistrements dépendants. Par exemple, si nous demandons la suppression en cascade de l'enregistrement «6, Finances» de la table DEPARTEMENT, notre opération entraînera la destruction simultanée des enregistrements «Savoy» et «Brodard» dans la table EMPLOYE.

• Suppression avec mise à la valeur nulle

  Une suppression avec mise à la valeur nulle signifie que les valeurs d'une clé étrangère deviennent nulles lors de la suppression des enregistrements référencés. Par exemple, si nous supprimons l'enregistrement «6, Finances» de la table DEPARTEMENT en appliquant cette règle d'intégrité, les valeurs de la clé étrangère AffectationID située dans la table EMPLOYE deviendront nulles pour les employés Savoy et Brodard.

Notons finalement que les opérations d'insertion et de mise à jour peuvent également être soumises à des contraintes qui garantissent en permanence l'intégrité référentielle d'une base de données. Par exemple, l'insertion du tuple «20, Morel, Chemin du Cerisier, Marly, 7» sera rejetée par un système de gestion de base de données qui supporte l'intégrité référentielle. En effet, la valeur «7» sera déclarée invalide car elle n'existe pas dans la table référencée DEPARTEMENT.