Discussion :

[curt]

Bonsoir à tous,

j'ai vu de la lumière en passant alors j'suis monté...

Une question concernant les relations : Comment faire pour expliquer les liens entre les tables quand on n'a pas pris le soin de poser les relations dans Access ??? On fait un long discours ou peut-être un croquis à la main... qui correspondra aux relations !!! Autant mettre ça dans la base et avoir toujours le schéma (visuel) sous la main et pouvoir le montrer (sur mon forum préféré tant qu'à faire) pour que les aides généreuses puissent comprendre quelque chose au problème posé... Voilà déjà une aide précieuse si on veut faire abstraction de l'utilité fondamentale des relations. ()

En ce qui me concerne, c'est l'outil essentiel sur lequel repose ma base... les fondations en quelque sorte !! (les fondations de la base... toute une théorie à développer !!)

Curt

[Chtulus]

Bonsoir curt,

les fondations de la base... toute une théorie à développer !!

Je verrais plus cela comme un axiome...

Comment faire pour expliquer les liens entre les tables quand on n'a pas pris le soin de poser les relations dans Access ???

Ben, en fait, le fait d'avoir les DDL des tables permet de deviner les relations (Liens) entre les tables au travers des PK et FK !

Est-ce bien dans ce sens que tu as posé ta question ?

[Pierre Fauconnier]

J'ai vu aussi de la lumière...

Je ne conçois pas de base de données ACCESS sans intégrité référentielle, à tous les coups. C'est inévitablement courir droit dans le mur que de ne pas placer d'intégrité référentielle lors de la création des tables (sauf manipulations très spéciales, et en levant l'intégrité de manière temporaire).

Bien sûr, pas sur une base de données de tests pour DVP, mais toujours lorsqu'une base va être mise en production, même pour une utilisation uniquement personnelle.

Et croire que l'on peut remplacer l'intégrité référentielle par du code de sécurisation est oublier que l'on peut "attaquer" une base ACCESS par d'autres canaux que l'appli développée.

Donc oui, mille fois oui pour une utilisation de la table des relations, et pas seulement pour créer les relations qui seront proposées par défaut dans les requêtes, formulaires/sous-formulaires et autres joyeusetés, mais surtout pour garantir l'intégrité référentielle, ce qui, en Access, ne sait se faire (hors code vba) que via la table des relations.

[vodiem]

salut curt et Pierre Fauconnier, il y a beaucoup de lumière ce soir...

je ne remets pas en cause ce travaille préliminaire: une feuille et un crayon c'est rapide et ca mange pas de pain.

moi je suis pour la diversité: s'il existe différentes possibilités j'aime savoir les utiliser à bon escient.
donc avoir les avantages et les inconvénients de chacun et ne pas me contenter d'avoir la bonne façon et la mauvaise.

même s'il y avait 99.99% de cas où il est préférable de procéder ainsi. je trouve plus intéressant de trouver des arguments pour le 0.01%

[Pierre Fauconnier]

Salut Vodiem,

...Je trouve plus intéressant de trouver des arguments pour le 0.01%

Oui, mais à mon avis, il n'y en pas!! Je ne vois aucun cas où ne pas placer l'intégrité est préférable à la placer. Les arguments en faveur de l'intégrité sont nombreux, et je n'ai encore trouvé personne ici qui ait UN argument en faveur d'une absence d'intégrité, avec cas détaillé à l'appui de ses dires...

[Chtulus]

Salut Pierre ,

[Edit] Mince [/Edit]

De plus plus besoin de calculer le delta, 0,01% ne représente rien sur les 99,99%

On en revient au temps.... Si la personne a 1H à perdre tous les mois (a minima) pour savoir pourquoi il a des soucis, ben je le félicite

[francishop]

Bonsoir,

De la lumière... De la lumière! Qu'ont-ils tous à voir de la lumière? Je ne vois pas.
Bref :

De nombreuses personnes se projettent dans les formulaires, le VBA, leurs états, bref... la finalité alors qu'ils n'ont pas pris le temps de penser aux règles de gestion ni à la modélisation et partent tête baissée à créer des tables car c'est jolie !

Exactement moi!
J'aime bien voir de suite le résultat du travail. Combien de fois je suis parti "tête baissée" et me suis retrouvé à bidouiller pour essayer de rattraper les dégats... Résultats : Une de ces bases qui ont fait la réputation d'Access --> Une usine à gaz et X heures perdues à faire n'importe quoi.
Il m'a fallu quelques temps et déboires pour me calmer.
Depuis, passer un peu de temps dans la fenêtre des relations ..............................................................
..................................................................................(Vide pour laisser Vodiem, et, ou Chtulus placer leur C.......) est devenu l'étape primordiale qui m'empêche de faire n'importe quoi (quoi que...)

Cordialement.

[vodiem]

@Pierre,
comme je disais plus haut, il existe des cas où l'intégrité référentiel posent problème lorsqu'il s'agit de remplacer une table par exemple.

si je fais un journal événementiel: une table [personne] et [événements]. je fais mes formulaires, états... je m'embarrasse pas de faire une relation dans la fenêtre de relation qui n'aura aucune influence sur la db et je fourni une doc technique je vois pas le soucis que ce soit sur papier ou dans la db.

quand je veux faire un test, je crée mes tables et ma requete, je m'embarrase pas de compléter les relations.

...

@Chtulus,

De plus plus besoin de calculer le delta, 0,01% ne représente rien sur les 99,99%

0.01% d'erreur sur un programme c'est suffisant pour qu'il plante.
0.01% c'est même pas la chance de gagner au loto et pourtant 99.999..% des perdants jouent.
- de 0.001% c'est le temps que l'homme est sur terre
...

On en revient au temps.... Si la personne a 1H à perdre tous les mois (a minima) pour savoir pourquoi il a des soucis, ben je le félicite

et tu peux me félicité je suis à plus d'1h par mois.
et ca m'enrichi. :p

bonsoir francishop ,

De la lumière... De la lumière! Qu'ont-ils tous à voir de la lumière? Je ne vois pas.

justement on n'y vois plus parce qu'on est éblouie.

passer un peu de temps dans la fenêtre

attention de ne pas passer à travers.
chez moi j'ai les volets sont fermés donc ceci explique surement cela.
mais attention: ne pas confondre passer du temps dans la fenêtre et temps passer à conceptualiser les relations qui peut se faire sans fenêtre... :p

[Chtulus]

Punaise ce soir il n'y a que des lumières et c'est super sympa d'avoir autant de beau monde

@vodiem, oui c'est ce que je dis plus haut

Sauf dans le cas d'une dénormalisation de base

je m'embarrasse pas de faire une relation dans la fenêtre de relation qui n'aura aucune influence sur la db et je fourni une doc technique je vois pas le soucis que ce soit sur papier ou dans la db

Hé, pas d'accord, comment gère tu ce que je disais plus haut...

Atomicité, constance, non redondance...
Cela permet d'éviter un encombrement de la mémoire et de l'espace disque, voir la perte d'information.

Mais sinon je suis pas trop têtu (^^) et je comprends tes arguments pour des tests mais en prod?!?

il existe des cas où l'intégrité référentiel posent problème lorsqu'il s'agit de remplacer une table par exemple

Heu... c'est pas courant ça
Tu pourrais explicité la chose car là j'ai du mal (Surtout à cette heure ==> Je vais faire un tour de cadran si ça continue )

[Domi2]

Bonsoir à tous ,

Plus beaucoup de lumière...

EDF est en panne ?

Je me permet d'en rajouter une "couche"...

J'ai lu et relu la discussion, et je rejoint les "relationistes"...

Je ne me permettrais pas de contredire les tenants de l'absence de relations (tout ou partie) dans une application Access... Encore faut-il maîtriser...

L'avis de Pierre Fauconnier me semble le plus pertinent... Etablir les relations dans tous les cas, et surtout pour un débutant (qu'il soit stagiaire, non professionnel mais passionné, etc...) amène de la rigueur dans le développement. Donc à mon sens, une bien meilleure conception de base d'une application, et par conséquent une plus grande facilité de développement...

Argument supplémentaire : quand un membre déclare avoir mis deux tables en relation 1 - n, créé un formulaire et un sous-formulaire, renseigné correctement les champs pères/fils et qu'il rencontre un problème, il me semble qu'il obtient souvent une solution (qui plus est rapide). Ce qui n'est pas forcément le cas de celui qui a "bidouillé" pour obtenir un résultat identique...

Ce qui n'interdit certainement pas, une fois qu'on maîtrise parfaitement Access, de s'en passer... Mais cela reste certainement réservé à un petit nombre de développeur... A mon avis.

Domi2

[LE VIEUX]

Bonjour et bon WE la compagnie,
Intéressant et amusant débat d’experts, personne ne remettant en cause la notion de relation et c’est encore heureux s’agissant de SGDB »R » dont la relation et l’intégrité référentielle que l’on s’en serve où pas a absolument sa place.
si je remonte au 1er post qui a déclenché tout cela c’est l’utilisation ou non d’un outil « qui semble être le seul » à moins d’y inclure « VBE » qui est effectivement un outil et avec lequel l’on peut effectivement créer des relations avec VBA. A mon avis c’est le seul débat – comme tous le monde bien sur je me sers des deux, mais il faut reconnaître que l’outil relation est bien adapté et plus rapide pour déterminer « facilement » les relations.
Toujours vis-à-vis du premier post
Citation :

Uniquement au niveau des requetes, je défini les relations

Dans le cadre des requêtes il est préférable de parler de jointure ou d’union que de véritable « relation ».
Voila pour ma modeste contribution ne venant certainement pas d’une lumière…..
bonne continuation
A bientôt tous le monde.

[Pierre Fauconnier]

Salut Le Vieux,

personne ne remettant en cause la notion de relation et c’est encore heureux s’agissant de SGDB »R » dont la relation et l’intégrité référentielle que l’on s’en serve où pas a absolument sa place.

Il me semble que Vodiem la remet en cause ici

si je fais un journal événementiel: une table [personne] et [événements]. je fais mes formulaires, états... je m'embarrasse pas de faire une relation dans la fenêtre de relation qui n'aura aucune influence sur la db et je fourni une doc technique je vois pas le soucis que ce soit sur papier ou dans la db.

Qui n'aura aucune influence??? Bien sûr que si. Pas de relation => pas d'intégrité référentielle => risque d'avoir des enregistrements d'une table qui pointent vers des enregistrements fantômes d'une autre table.

Si on ne met pas de relation, on ne sait pas mettre d'intégrité référentielle, les deux étant liés au niveau de la fenêtre des relations (on peut mettre des relations sans intégrité, mais on ne sait pas, avec Access, placer d'intégrité sans relations)... => On risque de planter à un moment donné.

Je préfère d'ailleurs, comme Le Vieux, parler de jointures plutôt que de relations. Placer des relations dans la table des relations sans utiliser l'intégrité référentielle revient à définir les jointures par défaut qui seront proposées lorsque l'on utilisera les tables liées au travers de l'IDE d'Access (Requêtes, formulaires/sous-formulaires et états/sous-états). Et de cela on peut effectivement se passer (d'autres IDE ne le proposent pas) alors que l'on ne peut se passer de l'intégrité référentielle, placée, dans l'IDE d'Access, via la table des relations (ou par code VBA utilisant des requêtes SQL...).

Bien entendu qu'une doc technique expliquera qu'un événement est lié à une personne, mais sans intégrité référentielle, on pourrait avoir un événement qui pointe vers une personne qui n'existe pas ou plus => C'est cela que l'intégrité référentielle empêchera.

L'intégrité référentielle n'est en rien liée à la doc technique d'une base de données. Elle n'est pas là pour documenter la base ou expliquer les liaisons, elle est là pour garantir... l'intégrité référentielle, sur le plan informatique! La table des liaisons ne suffit pas, loin s'en faut, à documenter la base de données.

@Domi2: Je ne te suis pas lorsque tu dis qu'une bonne maîtrise peut amener à se passer d'intégrité. Je ne vois pas le lien entre les deux. Bien entendu, on pourrait, par code sur formulaire, empêcher la suppression d'un enregistrement utilisé par une autre table (encore que ce serait lourd à mettre en place), mais cela n'empêcherait nullement que l'enregistrement soit supprimé via une "attaque" de la base à partir d'une autre application par ODBC, par exemple, alors que l'intégrité référentielle est liée à la base, et donc indépendante de tout code d'où qu'il provienne. Je ne comprends pas en quoi on peut lier l'intégrité référentielle à une expertise supposée ou avérée.

[vodiem]

salut Domi2 et LE VIEUX,

Ce qui n'interdit certainement pas, une fois qu'on maîtrise parfaitement Access, de s'en passer... Mais cela reste certainement réservé à un petit nombre de développeur... A mon avis.

c'est l'idée que je m'en fait. ne pas faire ces relations mais en toute connaissance de cause.

comme le rappel LE VIEUX, cette fenetre de relation ne fait que reprendre graphiquement ce que l'on peut faire par code sql en définissant les contraintes des champs.

@Pierre,

Qui n'aura aucune influence??? Bien sûr que si. Pas de relation => pas d'intégrité référentielle => risque d'avoir des enregistrements d'une table qui pointent vers des enregistrements fantômes d'une autre table.

pas de relation n'implique pas forcement pas d'intégrité.
le pointage sur des enregistrements fantômes existe s'il y a suppression, hors dans certain cas: par exemple, dans la comptabilité, il est formellement interdit de supprimer, donc en mode ajout il n'y aura donc pas d'erreur.
de plus rien n'interdit de travailler avec la logique des procédures stockées et gérer chaque manipulation de données à part.

mais cela n'empêcherait nullement que l'enregistrement soit supprimé via une "attaque" de la base à partir d'une autre application par ODBC

si l'on autorise l'accès à la base à une personne néophyte, l'intégrité seul ne protègera pas de tous les risques.
si on peut d'ailleurs voir là un avantage c'est aussi un inconvénient puisque qu'il est moins permissif et même si des cas sont rare (je doute qu'il soit inexistant) il pourrait être intéressant de pouvoir s'affranchir de l'intégrité, ne serait ce que temporairement.

@Chtulus,
bon je sais que mes exemples sont discutable. mais rappelons qu'il est un fait qu'une base peut fonctionner correctement sans définir préalablement cette fenêtre et sans avoir de pb.

pour exemple de définition de relation contraignante:
une base qui travaille avec une table dont on met à jour quotidiennement et qui serait lié à plusieurs autres tables.
à la maj des données avec des relations établis:
>suppression des enregistrements de la table
>import nouvelle table2
>insertion nouveaux enregistrements table2 dans la table
>delete table2
à la maj des données sans relations établis:
>delete table
>import table
si on procède ainsi avec des relations établis à la suppression de la table on perds toutes les relations et il faut les remettre après l'import.

d'ailleurs il n'est pas exclus d'imaginer un système qui exploiterait des changements de contraintes et ainsi la fenêtre de relations n'aurait pas de sens.

[Chtulus]

Bonsoir,

à la maj des données sans relations établis:
>delete table
>import table

Certes c'est tentant mais, la première chose qui me viens à l'esprit c'est "comment es-tu sûr de l'unicité, atomicité de tes données ?" entre autre.

D'ailleurs je viens de relire un article de SQLpro, certes on sent qu'il parle de SGBDR un peu plus costaud mais dans l'idée.

Cela donne quelques pistes et beaucoup d'indications peuvent aider.

bon je sais que mes exemples sont discutable. mais rappelons qu'il est un fait qu'une base peut fonctionner correctement sans définir préalablement cette fenêtre et sans avoir de pb.

J'ai déjà dit que c'était possible, bien sûr Mais cela n'est pas optimisé !

Dans le cadre des requêtes il est préférable de parler de jointure ou d’union que de véritable « relation ».

Effectivement, puisqu'une requête utilise des relations et des jointures... (cf plus haut dans un de mes post.)

Plus beaucoup de lumière...

Faut dire qu'a 3H25 du matin

Par contre je te rejoins là dessus ==>

Établir les relations dans tous les cas, et surtout pour un débutant (qu'il soit stagiaire, non professionnel mais passionné, etc...) amène de la rigueur dans le développement.

Bref je finirais en disant qu'il n'y a pas de méthode et que chacun à son point de vue et peut faire ce qu'il veut, mais le fait d'optimiser et de normaliser au maximum vos bases de données facilitera toujours leurs utilisations et permettra à tout à chacun de changer d'éditeur sans perdre cette notion.

Et sinon pourquoi T. CODD aurait fournis certaines règles ? Déjà à l'époque il s'était pris la tête avec des éditeurs ^^

[vodiem]

Salut Chtulus ,

Plus beaucoup de lumière...

Faut dire qu'a 3H25 du matin

y a pas d'heure pour briller. ;p

Certes c'est tentant mais, la première chose qui me viens à l'esprit c'est "comment es-tu sûr de l'unicité, atomicité de tes données ?" entre autre.

oui tentant surtout lorsque tu n'as pas besoin d'unicité, atomicité... que la base tout simplement ne fait que des modifications: pas d'ajout ni de suppression. ex: la base d'origine contrôle l'intégrité, l'envoie à une autre (sans relations) qui valide, complète et renvoie le traitement. mais rien n'empêche de faire des contrôles d'intégrités par code.

Je vous rejoins sur les recommandations: "prenez de bonnes habitudes" mais je rajouterais: "consciemment".

[Arkham46]

[...] et je fourni une doc technique [...]

Voilà un bon point qui ne mérite pas de jet d'octet...
La fenêtre des relations est un outil de développement, pas une documentation.
Qui s'est déjà jeté sur la fenêtre des relations pour comprendre une BD?
C'est fouillis quand on a plus de 2 tables, on n'y voit pas grand chose.
Un bon document word, voilà ce qui est nécessaire.

Le cas où les relations s'imposent : les tables d'en-tête et de postes.
Si j'ai une table de factures et une une table de lignes de facture, je mettrai de l'intégrité avec mise à jour/suppression en cascade.
Comme ça je supprime l'en-tête et ça me supprime les lignes qui correspondent.
Cela évite d'avoir des enregistrements orphelins.
En plus quand je crée une requête avec QBE j'ai tout de suite les jointures qui vont bien.
Sinon ça me gave les relations : quand il n'y a pas d'intégrité je zappe.

[Pierre Fauconnier]

Le cas où les relations s'imposent : les tables d'en-tête et de postes.

C'est quoi des tables d'en-tête et de postes??

Si j'ai une table de factures et une une table de lignes de facture, je mettrai de l'intégrité avec mise à jour/suppression en cascade.
Comme ça je supprime l'en-tête et ça me supprime les lignes qui correspondent.
Cela évite d'avoir des enregistrements orphelins.

Si tu as une table avec des contacts qui habitent dans des localités situées dans un pays... Tu as intérêt à mettre l'intégrité sur les pays, et surtout à ne pas cocher la suppression en cascade...

De l'étude de pas mal de bases que j'ai créées, il ressort qu'il est tout de même malaisé de se priver de l'intégrité, sauf à recopier une multitude de champs dans différentes tables...

Sinon ça me gave les relations : quand il n'y a pas d'intégrité je zappe.

C'est peut-être gavant, mais à mon sens vachement utile, et je serais curieux d'étudier les cas où l'on peut s'en passer (ils existent, bien sûr, mais il me semble tout de même qu'ils font plutôt partie des exceptions que de la règle...)

[Arkham46]

C'est quoi des tables d'en-tête et de postes??

Les postes c'est tout simplement les lignes de détails.
Pour une facture :
- dans l'en-tête il y a le numéro de facture, la date, le fournisseur, ...
- dans les postes il y a une ligne par poste de facturation (on peut facturer plusieurs choses sur une même facture, ce sont différents postes)

[Pierre Fauconnier]

Si tu veux pouvoir saisir un identifiant générique vide, tu ne peux pas avoir d'intégrité à moins de créer un enregistrement générique bidon (ce qu'on fait souvent).

Pas compris...

[Chtulus]

Coucou tout le monde,

tu n'as pas besoin d'unicité, atomicité... que la base tout simplement ne fait que des modifications: pas d'ajout ni de suppression. ex: la base d'origine contrôle l'intégrité, l'envoie à une autre (sans relations) qui valide, complète et renvoie le traitement

ils existent, bien sûr

Ben... Des sauvegardes