L`application de l`intégrité des données garantit la qualité des

INTEGRITE DES DONNEES ET BASE DE DONNEES
L'application de l'intégrité des données garantit la qualité des données stockées dans la base. Par
exemple, si un employé est défini avec un ID d'employé égal à 123, la base de données ne doit pas
autoriser qu'un autre employé ait la même valeur d'ID. Si une colonne employe_evaluation est
destinée à accueillir des valeurs comprises entre 1 et 5, la base de données ne doit pas accepter de
valeur en dehors de cette plage. Si la table contient une colonne dept_id qui stocke le numéro de
service de l'employé, la base de données ne doit accepter que des valeurs correspondant bien aux
identificateurs de service de la société.
Lors de la planification des tables, deux étapes importantes consistent d'une part à identifier les valeurs
valides pour une colonne et d'autre part à décider de la façon d'appliquer l'intégrité des données dans
cette colonne. L'intégrité des données se répartit entre les catégories suivantes :

Intégrité d'entité

Intégrité de domaine

Intégrité référentielle
* Intégrité d'entité ou de relation : L'intégrité d'entité définit une ligne comme étant une entité unique
pour une table particulière. Elle garantit l'intégrité des colonnes d'identification ou de la clé primaire
d'une table, par le biais d'index UNIQUE, de contraintes UNIQUE ou de contraintes PRIMARY KEY.
* Intégrité de domaine : L'intégrité de domaine fait référence à la fourchette (au domaine) des entrées
valides pour une colonne spécifique. Vous pouvez mettre en application l'intégrité de domaine pour
restreindre le type, à l'aide des types de données, le format, à l'aide des contraintes CHECK et des
règles, ou la fourchette des valeurs possibles, à l'aide des contraintes FOREIGN KEY et CHECK, des
définitions DEFAULT et NOT NULL, et des règles.
* Intégrité référentielle : L'intégrité référentielle préserve les relations définies entre les tables lors de
l'insertion ou de la suppression de lignes. Dans SQL Server 2005, l'intégrité référentielle est fondée sur
les relations entre les clés étrangères et les clés primaires ou entre les clés étrangères et les clés
uniques, via les contraintes FOREIGN KEY et CHECK. Elle garantit la cohérence des valeurs de clés entre
les tables. Ce type de cohérence impose qu'il n'y ait aucune référence à des valeurs inexistantes et que,
si la valeur d'une clé change, toutes les références qui y sont faites soient modifiées en conséquence
dans l'ensemble de la base de données.
Lorsque vous mettez en application l'intégrité référentielle, SQL Server interdit aux utilisateurs
d'effectuer les opérations suivantes :

ajouter ou modifier des lignes dans une table connexe lorsqu'il n'y a aucune ligne associée
dans la table primaire ;

changer des valeurs dans une table primaire qui engendreraient des lignes orphelines dans
une table connexe ;

supprimer des lignes dans une table primaire si des lignes connexes correspondantes existent.
Page 1 sur 2
INTEGRITE DES DONNEES ET BASE DE DONNEES
Les options de l’intégrité référentielle :
Sans intégrité référentielle les deux tables ne sont pas liées par une contrainte.
Exemple :
Attention ! le SGBD refusera d'appliquer l'intégrité référentielle si les deux champs liés par la
relation ne possèdent pas le même type de données. Seule exception : si le champ côté 1 est du
type NuméroAuto, il doit être du type numérique (entier long) du côté n. De même, le SGBD
refusera d'appliquer l'intégrité référentielle si les tables contiennent déjà des données, dont
certaines ont des valeurs empêchant l'intégrité référentielle de s'appliquer. Exemple : un nom de
commune dans la table "Personnes" ne figure pas dans la table "Communes".
Si nous demandons l'intégrité référentielle (et il est très fortement conseillé de le faire !), le
système nous propose deux autres choix. Le premier, "Mettre à jour en cascade les champs
correspondants", signifie que si nous modifions l'écriture du nom d'une commune du côté 1 de la
relation, cette modification sera reportée partout du côté n. D'une manière générale, il est
recommandé d'activer cette mise à jour en cascade. Si nous ne le faisons pas, et si nous tentons
de modifier un nom de commune (pour corriger une faute d'orthographe, par exemple), le système
nous arrêtera, avec le message suivant : "Impossible de supprimer ou de modifier l'enregistrement
car la table 'Personnes' comprend des enregistrements connexes". C'est clair, n'est-ce pas ?
Le second choix, "Effacer en cascade les enregistrements correspondants", signifie que si
nous supprimons une donnée du côté 1 de la relation, tous les enregistrements utilisant cette
donnée du côté n seront supprimés. Cela implique que, si nous supprimons par erreur un nom de
commune dans la table "Communes", nous supprimons en même temps de la table "Personnes"
toutes les personnes habitant cette commune. Il ne faut donc pas activer cette option, sauf
momentanément et en cas de besoin spécifique.
Supposons par exemple que des noms de fournisseurs se trouvent du côté 1 de la relation, et des
noms de produits du côté n. Si un fournisseur disparaît, nous pouvons activer l'effacement en
cascade. Quand nous supprimons le nom du fournisseur côté 1, tous ses produits disparaissent du
côté n. Nous effectuons ainsi la mise à jour de la base. Ensuite, nous décochons l'effacement en
cascade pour éviter tout risque d'effacement involontaire
Page 2 sur 2