Discussion :

[ilank]

Bonjour Pierre,
troller non, ce n'est pas mon intention !
J'ai juste relu cette discussion hier au soir en constatant que personne n'évoquait ces points.
Voilà.

[User]

Pour moi, cet argument ne tient pas... Si je supprime le fichier, je perds aussi mes données.

Il est rare de cocher la case de suppression en cascade lors du placement de l'intégrité. On ne le fait qu'à bon escient en maintenance de tables, et avec des backups.

+1

Malheureusement chez un client une suppression en cascade avait été cochée sur une relation entre une table articles et une table détail des commandes et la sauvegarde de la base n'avait pas été faite.

Un utilisateur a malencontreusement supprimé 2, 3 articles qui avait été commandés à plusieurs reprises, résultat on a perdu pas mal de données au niveau du détail des commandes et obligé de ressaisir ces infos à partir des bons de commande

[Bebert70]

Bonjour,

Je tombe par hasard sur ce sujet qui date un peu mais qui correspond à une question que je me pose, peut être que cela contribuera à relancer les débats !

Je n'utilise plus la fenêtre des relations . D'abord parce qu'en général je travaille seul sur mes applications, je connais le schéma par construction et donc pas tellement besoin d'avoir un visuel (même si à long terme cela peut être un problème c'est sûr !). Ensuite parce que je m'assure de l'intégrité référentielle "à la main". Concrètement, via des filtres sur les combos de saisie il n'est pas possible de saisir des informations qui ne sont pas dans les tables de paramètres (dans lesquelles la suppression des enregistrements n'est pas permise). Et en empêchant de supprimer un enregistrement qui a des dépendants (DAO et Recordcount).

Les relations entre tables sont donc définies uniquement dans les différentes requêtes. Je trouve ce système plus pratique, plus fastidieux à mettre en oeuvre mais il oblige à "penser" soi-même l'intégrité référentielle et peut améliorer la compréhension de la base. Je pense qu'au final c'est aussi une question d'habitude.

La question que je me pose concerne les performances : y-a-t-il un gain en rapidité lié à l'écriture des relations "en dur" dans la table des relations plutôt que dans chaque requête qui les utilise ?

Merci pour vos retours d'expérience !

[fsmrel]

Bonjour Bebert,

je m'assure de l'intégrité référentielle "à la main".

Dans le cas général, cela nécessite de développer du code. Dans le cas particulier d’ACCESS, les combos et autres facilités permettent certes d’alléger la tâche du développeur, mais il n’en demeure pas moins que garantir l’IR (intégrité référentielle) n’est pas du ressort d’une combo, l’IR peut être contournée, donc violée. De même, dans un contexte DAO, la propriété RecordCount permet de répondre facilement à une question du genre « La table LC des lignes de commande contient-elle au moins une ligne de commande faisant référence au produit p1 ? », et en cas de réponse négative, conclure que le produit en question peut être supprimé dans la table P des produits. Mais ça serait aller un peu vite en besogne, car si la table P est référencée par d’autres tables, il faudra se poser la même question pour chacune d’entre elles et, lors de la mise en œuvre d’une nouvelle table liée à P — en dépit des mois et des années qui passent ! —, ne pas oublier la programmation du RecordCount qui va bien...

En réalité, tout ce qu’on développe à la main étant faillible, il faut donc utiliser la fonctionnalité offerte par le SGBD et dont la vocation est explicitement de garantir l’intégrité référentielle. Un moyen de savoir si votre base de données est intègre : rien que pour voir, mettez en œuvre l’intégrité référentielle...

Les relations entre tables sont donc définies uniquement dans les différentes requêtes. Je trouve ce système plus pratique, plus fastidieux à mettre en oeuvre mais il oblige à "penser" soi-même l'intégrité référentielle et peut améliorer la compréhension de la base.

Faisons une analogie. A moins qu’il ne s’agisse d’un cabanon, dans le cas de la construction d’une maison, a fortiori d’un immeuble, suite à ses entretiens avec le maître d’ouvrage, un architecte l’a pensée et, grâce à sa compétence, à son art, en a produit les plans dont auront besoin le chef de chantier et son équipe avant de se mettre à l’ouvrage. Il en va de même pour une base de données : avant de commencer à développer quoi que ce soit, on en produit le diagramme de la structure, traduction des règles de gestion des données, c'est-à-dire du QUOI. Ce n’est donc certainement pas au cours des développements qu’on va commencer à s’intéresser à l’intégrité référentielle et « améliorer la compréhension » de la base de données. Qui plus est, outre l’aspect purement structurel, anatomique des choses, on doit prendre en compte dès le début le métabolisme des données. Prenons par exemple le cas des commandes faites par les clients et partons de la structure suivante :




Ce diagramme montre que les lignes de commande sont en relation avec les produits, et l’on va d’instinct être amené à se poser la question : dans quelles conditions peut-on supprimer un produit ? La réponse est claire : seulement quand ce produit n’est pas référencé par des lignes de commande. Cela dit, si l’on y réfléchit, les lignes de commande de la commande c1 ne sont jamais que des propriétés de celle-ci : si on supprime c1, si on a mis en œuvre l’intégrité référentielle, un stimulus est transmis à ses lignes, et celles-ci n’ont aucune raison de s’opposer à leur propre destruction, donc à celle de c1. De la même façon, on ne va attendre le développement pour se poser la question de la suppression d’un client et des stimuli émis. Cela dit, plutôt que de s’appuyer sur des combos ou sur la propriété RecordCount, dont la finalité ne concerne pas la garantie de l’intégrité référentielle, on sous-traite celle-ci au SGBD, il remplit parfaitement son rôle.

En SQL, il suffit de mettre en œuvre les clés étrangères (foreign keys) qui vont bien, ave les règles régissant le métabolisme (CASCADE, NO ACTION) :

CREATE TABLE LIGNE_COMMANDE
(
        ClientId            integer         not null
      , Commandeid          integer         not null
      , LigneCommandeId     integer         not null
      , ProduitId           integer         not null
      , Quantite            integer         not null
    , CONSTRAINT LIGNE_COMMANDE_PK PRIMARY KEY (ClientId, Commandeid, LigneCommandeId)
    , CONSTRAINT LIGNE_COMMANDE_COMMANDE_FK FOREIGN KEY (ClientId, Commandeid)
          REFERENCES COMMANDE (ClientId, Commandeid) ON DELETE CASCADE
    , CONSTRAINT LIGNE_COMMANDE_PRODUIT_FK FOREIGN KEY (ProduitId) 
          REFERENCES PRODUIT (ProduitId) ON DELETE NO ACTION
) ;

Avec ACCESS (fenêtre des relations) :

La question que je me pose concerne les performances : y-a-t-il un gain en rapidité lié à l'écriture des relations "en dur" dans la table des relations plutôt que dans chaque requête qui les utilise ?

A l’époque « lointaine » où DB2 (et a fortiori les autres SGBDR) ne gérait pas encore l’intégrité référentielle, le G.U.I.D.E. (Groupement des utilisateurs IBM) se faisait régulièrement l’écho de la multitude qui suppliait, la réclamait à cor et à cri. Quand, en 1988, DB2 eut quatre ans (aujourd’hui il en a donc 31...), IBM nous la livra enfin, mais changement de discours de la part des impatients, virage à 180° : « Heu... finalement, est-ce bien utile ? Est-ce que ça ne coûterait pas la feau des pesses quant aux performances ? »

Concernant l’utilité, il n’y a pas photo, l’intégrité des données n’a pas de prix. Concernant la performance :

— Déjà, de façon intuitive, en sous-traitant le contrôle de l’intégrité référentielle à un SGBD relationnel, on peut subodorer que la performance des contrôles n’en sera que meilleure, car tout se passe sous le capot, et ceux qui ont conçu le moteur l’améliorent au fil du temps, en conséquence de quoi nos propres requêtes bénéficient de facto des améliorations.

— De façon plus objective, dès 1988 j’ai obtenu une réponse positive, directement de la part du SGBD : chaque fois que j’ai eu à modéliser une base de données, j’ai bâti un prototype de performances en relation avec l’intégrité référentielle (en mise à jour intensive cela va de soi). Quand on a des problèmes de performance, plutôt que chercher à mettre en cause l’intégrité référentielle, il vaut mieux par exemple voir si ce ne sont pas les index qui fichent la patouille, voyez à ce propos ici. Pour ma part, je n’ai pas eu l’occasion de bâtir de prototype de performances avec ACCESS, mais de votre côté rien ne vous empêche de vous y atteler...

En tout cas, disposant des résultats des campagnes de prototypage, chez mes clients j’étais armé pour discuter objectivement avec la Direction de la Production de la mise en œuvre de l’IR. Et puis, vu la garantie offerte par la sous-traitance du contrôle de l’intégrité référentielle au SGBD, je n'ai jamais essuyé de refus quant à sa mise en œuvre.

Merci pour vos retours d'expérience !

Sur le thème : peut-on faire l'impasse sur le contrôle de l'intégrité référentielle par le SGBD ? Demander à l’application de garantir l’intégrité des données suffit-il ?

Pour illustrer, je reprends un échantillon des nombreuses expériences que j'ai vécues chez ceux qu'on appelle les « grands comptes ».

Dans le cas des applications traditionnelles de gestion, mais néanmoins centrales, vitales, dans le monde des entreprises telles que les banques, les sociétés d’assurance, les caisses de retraite, dans la distribution, l’industrie, les administrations, etc., la réponse est non, car si on fait l’impasse, il peut en résulter de très sérieux dommages. Voici quelques péripéties dans lesquelles j’ai trempé, dépêché par mon entreprise (une SSII) pour rattraper le coup quand c’était possible.

Il était une banque où je fus appelé pour essayer de rétablir les liens entre les tables des comptes, des contrats, des clients, etc. La cata. J’ai tout tenté pour remettre les choses d’aplomb. Le Président lui-même me posait tous les matins la même question dans laquelle l’angoisse était à peine voilée : « Alors ? mes en-cours ? » Peine perdue. La banque n’existe plus.

Une société d’assurance. Pour le DSI, la base de données Clients c’était du béton : « En vingt ans, je n’ai jamais entendu parler de quelque problème que ce soit, tout baigne ». J’étais alors chargé de valider un modèle conceptuel de données et le modèle logique dérivé, ceci pour une autre base, alimentée à partir des données de production. Ayant mis en œuvre l’intégrité référentielle pour la nouvelle base, ce qui devait arriver arriva, ce fut un révélateur : 30% de données rejetées lors de la « remontée » dans la base toute neuve. Le DSI verdit et il fallut plus d’un an pour arriver à remettre la base Clients à peu près d’équerre.

Une société de crédit automobile. Pour valider une application en cours de refonte, j’avais été autorisé à copier les données de production. Je fus obligé de porter le pet au plus vite, car il y avait quelques milliers de contrats faisant référence à des clients inconnus au bataillon. Panique à bord, tout le monde sur le pont... Après enquête, il s’est avéré que, suite à un incident matériel en production, il y avait eu une restauration des données Clients/Contrats, mais à partir d’une sauvegarde des clients ayant eu lieu à une date n’ayant rien à voir avec la date de sauvegarde des contrats. Heureusement, il y avait un an de backup en magasin et le coup put être rattrapé. (Le SGBD n’était pas relationnel. Il a par la suite été remplacé par DB2, lequel aurait tout de suite détecté le décalage temporel des sauvegardes.)

Une caisse de retraite. Un décideur (fonctionnel) décide de faire débrancher l’intégrité référentielle pour une partie de la base de données. Prudent, je recopie les tables de production dans un environnement qu’on m’a affecté, j’écris toutes les requêtes SQL pour vérifier (de nuit, car il est hors de question de pomper du temps machine pendant la journée) que les tables impliquées sont restées cohérentes suite à traitement diurne. Au résultat, ça n’a pas traîné : je constate que 780000 périodes passées par les cotisants dans les entreprises se sont envolées (peut-être étaient-ce les vôtres ?) Traitements à refaire, avec ordre cette fois-ci du décideur de brancher l’intégrité référentielle. Qu’est-ce qu’il ne faut pas faire pour que les gens comprennent...

Et j’en ai bien d’autres...

Ma conclusion en ce qui concerne l’intégrité référentielle pour les grandes bases de données (et même pour les autres !) : il faut être naïf pour croire que les contrôles d’intégrité assurés par programme permettent de dormir sur ses deux oreilles. Dans la série « ceinture, bretelles et épingle à nourrice », tout en laissant l’application consciencieusement contrôler ce qu’elle à a à contrôler, mettons en œuvre l’intégrité référentielle, au moins pour les domaines sensibles, ou (parce que le chef s'y oppose), développons et exécutons les requêtes permettant d’auditer le contenu des tables et montrer les dégâts.

Par référence aux trois petits cochons, il faut préférer construire une maison en briques plutôt qu’en paille ou en bois, il faut implanter l’intégrité référentielle. Pour ceux qui préfèrent l’approche Nouf-Nouf et Nif-Nif et effectuent les contrôles au niveau applicatif : Attention au loup !





L’approche Naf-Naf est décisive...