254
Chapitre 10 • Élaboration d’un schéma conceptuel
10.7 LES CONTRAINTES D’INTÉGRITÉ
Les contraintes d’intégrité formalisent certaines propriétés importantes du
domaine d’application que les données devront respecter. Le plus souvent, c’est
l’énoncé lui-même qui indiquera ces contraintes de manière explicite. Il sera parfois
nécessaire de recourir à des sources d’information complémentaires telles qu’une
conversation avec les utilisateurs, la connaissance que nous pourrions avoir du
domaine ou encore le simple bon sens.
Pratiquement, on examinera avec soin chaque type d’entités, chaque type d’associations et chaque attribut afin d’y relever les contraintes à retenir. Il faudra rester
réaliste dans ce repérage. En effet, chaque contrainte déclarée entraîne un bénéfice
et un coût. Le bénéfice est une plus grande précision des données et un meilleur
contrôle de la qualité. Le coût sera celui de la complexité et des ressources informatiques nécessaire à la validation des données qui doivent se conformer à cette
contrainte. Les opérations de mise à jour seront d’autant plus coûteuses qu’il y aura
de contraintes à vérifier.
a) Les contraintes statiques (section 9.5.1)
Les principales contraintes statiques sont les identifiants, les attributs obligatoires, et
les contraintes de cardinalités portant sur les rôles. D’autres contraintes pourraient
s’avérer utile, auquel cas on les indiquera par des annotations ajoutées au schéma
conceptuel (figure 10.19).
b) Les contraintes dynamiques (section 9.5.2)
Les contraintes sur les changements autorisés de valeurs peuvent être extrêmement
variées, et une analyse approfondie peut amener à en définir un grand nombre. Leur
validation par le SGBD fera appel au mécanisme des déclencheurs, dont on sait
qu’ils est très puissant mais complexe et délicat à manier (section 6.6). Il faudra
donc, plus encore que pour les contraintes statiques, rester raisonnables. Ceci
d’autant plus que la frontière entre la validation des contraintes dynamique par le
SGBD et la validation par les programmes d’application peut être floue.
Figure 10.19 - Description de contraintes statiques au moyen d’annotations
Montant > 0
Modalité Paiement = {A, Q, ST}
Date Paiement >= Date Livraison
(Date Paiement non vide) si (Date Livraison non vide)
Date Livraison >= Date Commande
ACHAT
Code Achat
Date Commande
Date Livraison[0-1]
Date Paiement[0-1]
Modalité Paiement
Montant
id: Code Achat
Chapitre 10 • Élaboration d’un schéma conceptuel
10.7 LES CONTRAINTES D’INTÉGRITÉ
Les contraintes d’intégrité formalisent certaines propriétés importantes du
domaine d’application que les données devront respecter. Le plus souvent, c’est
l’énoncé lui-même qui indiquera ces contraintes de manière explicite. Il sera parfois
nécessaire de recourir à des sources d’information complémentaires telles qu’une
conversation avec les utilisateurs, la connaissance que nous pourrions avoir du
domaine ou encore le simple bon sens.
Pratiquement, on examinera avec soin chaque type d’entités, chaque type d’associations et chaque attribut afin d’y relever les contraintes à retenir. Il faudra rester
réaliste dans ce repérage. En effet, chaque contrainte déclarée entraîne un bénéfice
et un coût. Le bénéfice est une plus grande précision des données et un meilleur
contrôle de la qualité. Le coût sera celui de la complexité et des ressources informatiques nécessaire à la validation des données qui doivent se conformer à cette
contrainte. Les opérations de mise à jour seront d’autant plus coûteuses qu’il y aura
de contraintes à vérifier.
a) Les contraintes statiques (section 9.5.1)
Les principales contraintes statiques sont les identifiants, les attributs obligatoires, et
les contraintes de cardinalités portant sur les rôles. D’autres contraintes pourraient
s’avérer utile, auquel cas on les indiquera par des annotations ajoutées au schéma
conceptuel (figure 10.19).
b) Les contraintes dynamiques (section 9.5.2)
Les contraintes sur les changements autorisés de valeurs peuvent être extrêmement
variées, et une analyse approfondie peut amener à en définir un grand nombre. Leur
validation par le SGBD fera appel au mécanisme des déclencheurs, dont on sait
qu’ils est très puissant mais complexe et délicat à manier (section 6.6). Il faudra
donc, plus encore que pour les contraintes statiques, rester raisonnables. Ceci
d’autant plus que la frontière entre la validation des contraintes dynamique par le
SGBD et la validation par les programmes d’application peut être floue.
Figure 10.19 - Description de contraintes statiques au moyen d’annotations
Montant > 0
Modalité Paiement = {A, Q, ST}
Date Paiement >= Date Livraison
(Date Paiement non vide) si (Date Livraison non vide)
Date Livraison >= Date Commande
ACHAT
Code Achat
Date Commande
Date Livraison[0-1]
Date Paiement[0-1]
Modalité Paiement
Montant
id: Code Achat