Voir aussi : DOMAINE, CLÉ PRIMAIRE, CLÉ ÉTRANGÈRE, IDENTIFIANT, CARDINALITÉ, DICTIONNAIRE DES DONNÉES , SCHÉMA CONCEPTUEL

REPRÉSENTATIONS/EXEMPLES/APPLICATIONS

    Dans le modèle relationnel, on admet trois contraintes implicites :

• L'intégrité de domaine implique qu'un attribut prend, pour chaque n-uplet, une valeur dans le domaine sur lequel il a été défini.

• L'intégrité d'entité implique qu’une clé primaire est toujours renseignée (not null, en anglais) et prend, pour chaque n-uplet, une valeur unique qui n’est pas modifiable (" Une fois sa valeur établie elle ne peut changer. Toutefois des procédures spéciales de mise à juste doivent être prévues en cas d’erreur à la saisie. " J. MORÉJON, MERISE : vers une modélisation orientée objet.).

• L'intégrité de référence implique qu’une clé étrangère prend, pour chaque n-uplet où elle est renseignée, l’une des valeurs prises par la clé primaire à laquelle elle se réfère.

             Soit la relation DISCIPLINE (CodeDiscipline, LibelléDiscipline, CodeResponsable#), où :

• L’attribut CodeDiscipline, clé primaire de la relation, est défini sur un domaine correspondant à un intervalle d’entiers.
• L’attribut LibelléDiscipline est défini sur un domaine composé des chaînes d’au plus 20 caractères.
• L’attribut CodeResponsable# est une clé étrangère, se référant à CodeProfesseur, attribut clé primaire de la relation PROFESSEUR (CodeProfesseur, NomProfesseur).

             Dans la relation DISCIPLINE :

• Il est impossible de donner à l'attribut CodeDiscipline la valeur "B" (intégrité de domaine).
• Il est impossible de trouver un n-uplet <, "anglais", 4> dans lequel l'attribut CodeDiscipline n'a pas de valeur (intégrité d’entité).
• Il est impossible de trouver au même instant les deux n-uplets <3,"anglais",7> et <3,"allemand",5>, car ces deux n-uplets ont la même valeur de clé (intégrité d’entité).
• Il est impossible d’insérer le n-uplet <7,"anglais",3> s'il n'existe pas dans la relation PROFESSEUR de n-uplet possédant pour clé primaire la valeur 3 (intégrité de référence).

             Dans la relation PROFESSEUR :

• Il n'est pas possible de supprimer le n-uplet (5,"NEWTON") s'il existe au moins un n-uplet dans la relation DISCIPLINE qui lui fait référence (intégrité de référence).

    Les langages de définition de données des SGBDR permettent d’automatiser le respect de certaines contraintes (clauses PRIMARY KEY, REFERENCES, WITH CHECK OPTION, UNIQUE, NOT NULL, etc en SQL, par exemple). Celles qui ne peuvent pas être automatisées lors de la définition des données le seront à l’aide d’un langage de définition de contraintes (instruction DEFINE CONSTRAINT) ou d’outils spécialisés (trigger, rule). À défaut, on définira des procédures spécifiques, dont certaines seront " automatisées ", les autres demeurant " manuelles ". C’est pourquoi il est si important de mesurer la portée d’une contrainte dans la vie de l’objet qu’elle concerne (création, modification, suppression).

    Avec le modèle entité-association,

• On exprime certaines contraintes sur le schéma conceptuel des données :

• L’identifiant des entités.
• Les cardinalités des associations.

• On exprime d’autres contraintes dans le dictionnaire de données :

• Le type de chaque donnée.
• Les règles de gestion qui peuvent contraindre les valeurs admissibles.

• D’autres contraintes restent implicites :
• C’est le cas des " cardinalités " caractérisant, du côté de l’association, chaque rôle d’entité. S’il s’agit d’exprimer, pour chaque rôle, combien il y a au minimum et au maximum d’occurrences de l’entité pour une occurrence de l’association, la réponse est invariablement la même : " 1 " (contrainte de contribution). Puisqu’elle est toujours vraie, cette contrainte n’est pas mentionnée.

    Qu’il s’agisse d’une donnée élémentaire ou d’une structure de données, la spécification s’appuie sur l’observation de l’information à représenter et se traduit par une approximation plus ou moins fine à l’aide des types de données qui composent la panoplie du langage de spécification et des contraintes sémantiques qu’on pourra formuler.

• Problématique de la spécification d’une donnée représentant la situation maritale :

• Choix entre un code ou un libellé complet : c’est la part la plus subjective de la spécification.
• Définition du type correspondant (caractère ou chaîne) plus ou moins restreint, donc plus ou moins contraint. On choisira, par exemple, une énumération des codes possibles ("C", "M", "D", "V") ou une énumération des libellés possibles ("célibataire", "marié", "divorcé", "veuf"). On se rapproche d’une formalisation rigoureuse.
• Définition des autres contraintes, intrinsèques ou en rapport avec d’autres données, " statiques " ou " dynamiques ", etc. C’est ici que la spécification deviendra formelle ou non. Dans le cas présent, la modification de la valeur prise par la donnée " situation maritale " est fortement contrainte.

• Problématique de l’" implantation " de la donnée spécifiée :

• Le type " énumération " existe-t-il ? Quel est le type d’interface ? (On remarquera qu’une interface graphique diminue l’intérêt des codes.) Existe-t-il un moyen d’automatiser la contrainte sur les mises à jour, à l’aide de triggers, par exemple ?

• D’une façon plus générale, il s’agit de comparer le coût de l’automatisation d’une contrainte (développement, volume, temps de réponse, etc) et le coût d’une intégrité logique dégradée. Le cahier des charges d’une application devrait recenser les décisions prises en ce domaine.