IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Faut-il définir les relations dans une base de données Access ?

Le , par vlksoft

0PARTAGES

0  0 
Bonjour à tous,

je monte souvent des appli en access. Mais dans ma manière de faire, souvent, je ne fais rien dans la fenêtre des relations. Uniquement au niveau des requetes, je défini les relations. Pourriez vous me conseiller que faire pour un meilleur developpement.

merci à tous.

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de fsmrel
Expert éminent sénior https://www.developpez.com
Le 28/08/2015 à 2:46
Bonjour Bebert,

Citation Envoyé par Bebert70
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...

Citation Envoyé par Bebert70
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) :



Citation Envoyé par Bebert70
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.

Citation Envoyé par Bebert70
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...

2  0 
Avatar de Chtulus
Modérateur https://www.developpez.com
Le 24/04/2009 à 11:15
Bonjour,

Citation Envoyé par vodiem
"que me jette un octet celui qui n'a jamais omis sciemment de faire une relation."

Méga octet jeté mon petit vodiem

Citation Envoyé par vodiem
ainsi naît la notion de relations
De quelle relation ? Car il ne faut pas confondre relation entre les tables et relation faisant référence aux tables elle même et étant la définition du R dans SGBDR

l'intégrité référentielle n'était pas indispensable et à l'ajout d'une nouvelle donnée, une série des questions pour confirmer si l'orthograhe et tous les bazars sont bons. Et le tour est joué.
Le fait d'avoir un modèle relationnel facilite le travail, n'impacte pas la vue de l'utilisateur et permet des traitements mieux adaptés.

Pour les contraintes d'intégrité, elles permettent de renseigner unitairement les attributs concernant quelque information que ce soit et permet de gérer les formes normales. Atomicité, constance, non redondance...
Cela permet d'éviter un encombrement de la mémoire et de l'espace disque, voir la perte d'information.

A vous de voir, mais je plussois à Philippe, curt et Jeannot... Et en partie de vodiem

C'est dommage que @fsmrel ne passe pas par là tiens

[Edit]J'espère que je n'ai pas écrit trop vite....[/Edit]

1  0 
Avatar de f-leb
Responsable Arduino et Systèmes Embarqués https://www.developpez.com
Le 15/10/2009 à 18:28
SQLPro a tranché:

Contraintes FOREIGN KEY SQL vs code client

Citation Envoyé par SQLPro
Se poser la question d'implanter ou pas les contraintes d'intégrité référentielle dans une base de données est aussi stupide que de se demander s'il faut vraiment des roues à une voiture...
voilà, c'est pas autrement, na. Mettez des roues à vos bases, quoi !
1  0 
Avatar de Pierre Fauconnier
Responsable Office & Excel https://www.developpez.com
Le 21/09/2010 à 11:32
Ilank, c'est juste pour "bêtement" troller?

Sinon, relis le sens des messages de ceux qui prônent l'intégrité référentielle dans la base plutôt que par code (forcément, jusqu'à Access 2010, hors de la structure des données) et tu comprendras que les mêmes prôneront évidemment l'utilisation des triggers et des procédures stockées en Access 2010
1  0 
Avatar de
https://www.developpez.com
Le 02/03/2009 à 8:11
Bonjour

Je conseille d'utiliser la fenêtre relation, cela te permet d'avoir un vrai visualisation de ton schéma, et de bien gérer les intégrités entre tes différents éléments.

De plus, tu peux grâce à cela définir facilement des listes déroulantes dans tes tables qui se répercutent dans tes formulaires, ce qui te donne un gain de productivité.

Philippe
0  0 
Avatar de curt
Membre émérite https://www.developpez.com
Le 03/03/2009 à 13:10
Bonjour,

tout comme Philippe, j'affectionne la fenêtre des relations.

ça reste un excellent moyen de visualiser les relations, d'en faire un état, voir ou revoir les règles d'intégrités, etc...

A consommer sans modération (à mon avis).

Curt
0  0 
Avatar de vlksoft
Membre actif https://www.developpez.com
Le 04/03/2009 à 9:16
Merci beaucoup pour vos contributions à cette discussion. Mais jusque là, il n'y a qu'un seul son de cloche. J'attends bien d'autres sons de cloche, qui déclencheraient bien sur une discussion constructive, qui pourraient me permettre ou aider les multitudes des membres d'adopter une attitude vraiment conséquente.
bye
0  0 
Avatar de
https://www.developpez.com
Le 04/03/2009 à 10:47
Bonjour

A mon avis tu auras un seul son de cloche, la fenêtre relation est un outil indispensable.
Il te permet lorsque tu reprends un application fait par un tiers (dans la mesure où il a bien fait son travail), de voir la logique de l'application.

Pourquoi dans le forum Conception d'Access, on demande à voir une copie d'écran de cette fenêtre, c'est pour avoir un visuel rapide de la conception de la base.

Philippe
0  0 
Avatar de curt
Membre émérite https://www.developpez.com
Le 04/03/2009 à 13:46
Bonjour,

"Un seul son de cloche" !! merci du compliment.

C'est peut-être parce qu'on est du même avis Philippe et moi qu'il faudrait en tenir compte ?

Maintenant si tu préfères avoir raison et attendre qu'on te conforte sur la mauvaise voie utilisée....

Bonne journée.
Curt
0  0 
Avatar de lucienkany
Membre actif https://www.developpez.com
Le 04/03/2009 à 14:01
Bonjour à tous.

Je pense que pour aborder dans le même sens et essayer de donner raison à vlksoft, il faut adopter intentionnellement sa méthode quand on ne souhaite pas qu'un autre développeur ne s'y retrouve. Peut être pour raison de sécurité. Mais quand on veut partager (c'est le cas sur ce forum) on utilise bien la fenêtre des relations.

Donc avis partagé!
0  0