des bases de données
3.8 MODIFICATION ET CONTRAINTES D’INTÉGRITÉ
© Dunod – La photocopie non autorisée est un délit.
3.8 MODIFICATION ET CONTRAINTES D’INTÉGRITÉ
Les propriétés structurelles (identifiant, contrainte référentielle, colonne obligatoire/
facultative) associées aux données doivent être respectées à tout instant; elles cons-tituent donc des contraintes imposées aux opérations de modification de ces données. Ajouter une ligne, supprimer une ligne ou modifier une valeur de colonne d’une ligne sont des opérations qui ne sont autorisées que si ces propriétés sont toujours respectées par les données après l’opération. Si ces propriétés sont violées, on dira que les données ont perdu leur intégrité. Ces propriétés constituent dès lors des contraintes d’intégrité. Nous examinerons brièvement l’impact de ces contraintes sur les opérations de modification du contenu d’une base de données.
3.8.1 Les contraintes d’unicité (identifiants)
Un identifiant constitue une contrainte d’unicité imposant qu’à tout instant les lignes d’une table possèdent des valeurs distinctes pour une ou plusieurs colonnes. Il ne peut exister, à aucun moment, plus d’une ligne de CLIENT ayant la même valeur de NCLI.
• Création d’une ligne : il ne peut exister de ligne possédant la même valeur de l’identifiant.
• Suppression d’une ligne : pas de contrainte.
• Modification de l’identifiant d’une ligne : il ne peut exister de ligne possédant la nouvelle valeur de l’identifiant.
3.8.2 Les contraintes référentielles (clés étrangères)
Une contrainte référentielle précise que certaines colonnes d’une table, appelées clé étrangère, doivent à tout instant, pour chaque ligne, contenir des valeurs qu’on retrouve comme identifiant primaire d’une ligne dans une autre table12. C’est ainsi que la table DETAIL est soumise à deux contraintes référentielles. La première indique que toute valeur de NCOM doit identifier une ligne de COMMANDE. La seconde indique que toute valeur de NPRO doit identifier une ligne de PRODUIT.
Les règles qui régissent les opérations de modification des données sont plus complexes que pour les autres contraintes. Nous raisonnerons sur les tables CLIENT et COMMANDE (figure 3.11), cette dernière faisant l’objet d’une contrainte réfé-rentielle, puisque la valeur de NCLI de toute ligne de COMMANDE doit être présente dans la colonne NCLI d’une ligne CLIENT (en termes de la réalité de l’entreprise, toute commande doit appartenir à un client enregistré). On ignorera dans cette analyse l’impact des autres contraintes référentielles du schéma sur les opérations.
12. Il peut d’ailleurs s’agir de la même table.
Figure 3.11 - Schéma d’étude de l’intégrité référentielle
Création d’une ligne de COMMANDE
La valeur de NCLI de cette ligne doit être présente dans la colonne NCLI d’une ligne de CLIENT (si la colonne NCLI de COMMANDE avait été déclarée facultative, alors la valeur de NCLI de la ligne pourrait être absente).
Suppression d’une ligne de COMMANDE Effectuée sans restriction13.
Modification de la valeur de NCLI d’une ligne de COMMANDE
La nouvelle valeur de NCLI de la ligne doit être présente dans la colonne NCLI d’une ligne de CLIENT (si NCLI de COMMANDE avait été déclarée facultative, alors on aurait pu effacer la valeur de NCLI de la ligne).
Création d’une ligne de CLIENT Effectuée sans restriction.
Suppression d’une ligne de CLIENT
Le problème se pose lorsque ce client possède des commandes; il existe alors des lignes dans COMMANDE qui référencent la ligne de CLIENT à supprimer. On définit trois comportements possibles qui laissent la base de données dans un état correct.
• Blocage. Le premier consiste à refuser la suppression de la ligne de CLIENT afin d’éviter de laisser dans la base de données des lignes de COMMANDE orphelines.
• Propagation ou cascade. Le deuxième consiste à supprimer non seulement la ligne de CLIENT, mais aussi toutes les lignes de COMMANDE qui la référen-cent14.
13. Pour être tout à fait précis, n’oublions pas que DETAIL est aussi lié à COMMANDE par une contrainte référentielle. La suppression d’une ligne de COMMANDE n’a pas d’impact sur sa relation avec CLIENT, mais elle en a sur celle qui concerne DETAIL, que nous ignorons ici pour simplifier le raisonnement.
14. Et bien sûr aussi les lignes de DETAIL qui référencent les lignes de COMMANDE ainsi supprimées.
3.9 La normalisation 45
© Dunod – La photocopie non autorisée est un délit.
• Indépendance. Le troisième est possible lorsque la clé étrangère est constituée de colonnes facultatives. Il consisterait ici, si NCLI de COMMANDE avait été déclarée facultative, à effacer la valeur de la colonne NCLI des lignes de COMMANDE qui référencent la ligne de CLIENT à supprimer. De la sorte, ces commandes n’appartiennent plus à aucun client après l’opération.
Modification de NCLI d’une ligne CLIENT
Si aucune ligne de COMMANDE ne référence cette ligne de CLIENT, la contrainte référentielle n’impose pas de restriction. Si au contraire de telles lignes existent, on admet trois comportements similaires à ceux de l’opération de suppression : refus de modification, modification des valeurs de clés étrangères qui référencent cette ligne, effacement des valeurs de clés étrangères qui référencent cette ligne.
On voit donc que l’impact d’une contrainte référentielle n’est pas unique et que, selon la réalité à représenter et la politique de gestion des données, on sera amené à choisir l’un ou l’autre des comportements décrits.
3.8.3 Les colonnes obligatoires
Si une colonne est déclarée obligatoire, chaque ligne doit en posséder une valeur.
Lors des opérations de création et de modification de lignes, cette colonne devra recevoir une valeur significative. Par exemple, il est permis de créer une ligne de CLIENT sans valeur pour CAT, mais pas sans valeur pour LOCALITE.
3.9 LA NORMALISATION
Les tables que nous avons rencontrées jusqu’ici représentaient chacune un ensemble d’entités clairement identifié : des fournisseurs, des clients, des commandes, des comptes ou des achats. Certaines tables peuvent présenter une structure plus complexe, généralement considérée comme indésirable. Tel est le cas de la table de la figure 3.12, que nous allons examiner de plus près.
Figure 3.12 - La table LIVRE enregistre les informations sur les livres disponibles dans une bibliothèque
3.9.1 Le phénomène de redondance interne
Le propriétaire de la table LIVRE désire manifestement y enregistrer les livres de la bibliothèque dont il est responsable. Pour chaque livre, il a repris le numéro, le titre, l’auteur, le code ISBN, la date d’achat et son emplacement dans les rayonnages. Un livre qui fait l’objet d’une demande importante de la part des lecteurs peut être acquis en plusieurs exemplaires, qui font chacun l’objet d’une ligne distincte de la table.
Pour naturelle qu’elle puisse paraître, cette représentation pose cependant un problème : lorsqu’un livre existe en plusieurs exemplaires, les lignes décrivant ceux-ci reprennent les mêmes valeurs du titre, de l’auteur et du code ISBN.
On nomme ce phénomène redondance d’information, puisqu’une même informa-tion est enregistrée plusieurs fois. Si par inadvertance nous effacions le titre du livre 1067, il serait aisé de le restaurer par une recherche d’un autre livre qui posséderait le même code ISBN, et qui aurait aussi le même titre. Une telle situation viole le principe fondateur des bases de données : tout fait pertinent du domaine d’applica-tion doit y être enregistré une et une seule fois. Sur le plan pratique, la redondance n’est pas sans inconvénients.
1. Avant tout, la table occupe un espace excessif.
2. Ensuite, la modification ultérieure du titre ou de l’auteur d’un livre exigera la même modification des lignes de tous les exemplaires de ce livre, à défaut de quoi les données deviendraient incohérentes.
3. Si l’enregistrement d’un premier exemplaire d’un livre peut se faire librement, celui des exemplaires suivants doit être conforme aux informations déjà présen-tes.
4. Plus subtilement encore, l’effacement du seul exemplaire d’un livre entraî-nerait la perte définitive des informations sur son titre et son auteur.
Cette analyse montre donc que la table est soumise à une contrainte d’intégrité d’un type nouveau : si deux lignes ont la même valeur d’ISBN, alors elles ont les mêmes valeurs de TITRE et d’AUTEUR. On dira aussi que la valeur de TITRE (et d’AUTEUR) est principalement fonction de celle d’ISBN, colonne qui n’est pas l’identifiant de la table.
3.9.2 Normalisation par décomposition
L’observation attentive des données contenues dans la table LIVRE montre que celle-ci contient des renseignements sur deux catégories d’entités : les livres eux-mêmes et les ouvrages dont les livres sont des exemplaires multiples. Il faudrait par exemple distinguer l’ouvrage Mercure d’A. Nothomb (ISBN 2 253 14911 X) des trois exemplaires de celui-ci que constituent les livres 1032, 1067 et 1022. Les données concernant un ouvrage sont enregistrées autant de fois que cet ouvrage a d’exemplaires.
3.9 La normalisation 47
© Dunod – La photocopie non autorisée est un délit.
La résolution de ce problème passe par la décomposition de la table LIVRE en deux tables distinctes, auxquelles nous donnerons de nouveaux noms, pour éviter toute ambiguïté (figure 3.13). La première, OUVRAGE, contient la description des ouvrages. On y reprend le code ISBN, le titre et l’auteur de chacun de ceux-ci. La seconde table, EXEMPLAIRE, décrit les exemplaires, éventuellement multiples, de ces ouvrages. On y indique, pour chacun d’eux, le numéro d’exemplaire, le code ISBN de l’ouvrage (référence à OUVRAGE), la date d’achat et l’emplacement dans les rayonnages.
Ce processus de décomposition en vue d’éliminer les redondances internes porte le nom de normalisation. Les tables de la figure 3.13 sont dites normalisées, alors que la table LIVRE ne l’est pas.
Figure 3.13 - Dans une base de données normalisée, on distingue les exemplaires des ouvrages dont ils sont la matérialisation. Les redondances présentes dans la table de la figure 3.12 sont ainsi éliminées
3.9.3 Analyse du phénomène
La propriété qui veut que deux lignes qui ont la même valeur d’ISBN ont les mêmes valeurs de TITRE et d’AUTEUR porte le nom de dépendance fonctionnelle, et se note
ISBN→TITRE, AUTEUR
en vertu du fait que cette propriété spécifie simplement une fonction, au sens mathé-matique du terme (à une valeur d’ISBN correspond une seule valeur de TITRE et d’AUTEUR). La partie gauche se nomme le déterminant de la dépendance et la partie droite le déterminé.
On notera deux propriétés importantes : (1) un identifiant d’une table est un déterminant de chacune des (autres) colonnes de la table, (2) inversement, toute colonne, ou groupe de colonnes, qui est un déterminant pour chacune des (autres) colonnes de la table est un identifiant. En particulier, on a :
NUMERO→TITRE, AUTEUR, ISBN, DATE_ACH, PLACE
Ces définitions et observations nous permettent de répondre à trois questions impor-tantes.