Discussion :

[majudis]

Bonjour,

J'ai une question concernant la façon de construire une base de données, car on m'a donné des avis différents sur la question.

Certaines personnes me conseillent de travailler avec des numéro automatique et des relations dans chacune de mes tables, et d'autres me disent au contraire de ne les utiliser que si c'est vraiment nécéssaire.

Jusqu'à présent j'ai construis mes base de données avec très peu de relations et numéro auto, et je me suis rendu compte que cela rendait la construction beaucoup plus facile. Mes bases de données fonctionnent très bien.

En revanche, j'ai un collègue qui utilise un numéro auto dans toutes ses tables, et chacune ont une relation, mais cela rend la conception plus difficile pour moi.

Quel est votre avis ?

Merci d'avance

[Tofalu]

Bonjour

Access est un SGDBR c'est à dire un Système de Gestion de Base de Données RELATIONNELLE. Il intègre des mécanismes permettant de garantir l'intégrité des données et leur cohérence. Ces mécanismes sont défini d'une part par l'unicité des clés primaire et d'autre part par les règles de validation des relations (ce qu'access nomme dans son interface : l'application de l'intégrité référentielle).

Si le numAuto n'est pas obligatoire, il permet quand même de générer sans la moindre difficulté une valeur qui sera pour sûr unique. Il est donc idéal comme clé primaire.

Quant aux relations, elles sont obligatoires. Certains diront que non car ils préférent utiliser VBA ... ce à quoi je leur répondrais : et comment votre VBA est il exécuté lorsqu'une requête externe est exécutée ou que la base est interrogée par un programme tiers ?

Comme dirait SQLPro (Frédéric Brouard, auteur de plusieurs ouvrage sur SQL), ne pas poser les relations et l'intégrité référentielle partout où c'est possible (impossible par exemple entre des tables provenant de plusieurs bases sous Access) est une faute professionnelle.

[Invité]

Bonjour

Je suis tout à fait d'accord avec Tofalu, d'autant plus qu'une base bien conçue avec des relations bien pensées permettra d'éviter une bonne partie du travail de contrôle de saisie pour éviter les erreurs d'incohérences, car Access fera le travail pour vous.

Philippe

[f-leb]

bonjour à tous,

Comme dirait SQLPro (Frédéric Brouard, auteur de plusieurs ouvrage sur SQL), ne pas poser les relations et l'intégrité référentielle partout où c'est possible (impossible par exemple entre des tables provenant de plusieurs bases sous Access) est une faute professionnelle.

http://sqlpro.developpez.com/article/fk-sql-vs-appli/

c'est même criminel

L'absence de FOREIGN KEYs dans une base de données apporte de multiples préjudices que nous venons d'énumérer. Le fait que la structure de la base, comme le code applicatif, ne sont pas de votre oeuvre, ne peut en aucun cas justifier l'absence de professionalisme. Par conséquent, le préjudice subit par l'absence de ces FOREIGN KEYs peut donc être condamné devant les tribunaux.

En revanche, j'ai un collègue qui utilise un numéro auto dans toutes ses tables, et chacune ont une relation, mais cela rend la conception plus difficile pour moi

en quoi un numAuto dont la gestion est justement automatique, et l'intégrité référentielle obtenue en quelques clics dans la fenêtre des relations d'Access rend la conception "plus difficile" ? Un exemple ?

[majudis]

en quoi un numAuto dont la gestion est justement automatique, et l'intégrité référentielle obtenue en quelques clics dans la fenêtre des relations d'Access rend la conception "plus difficile" ? Un exemple ?

Oh et bien par exemple si je veux archiver mes données dans une table, cela est plus difficile car etant données que les données sont éparpillées un peu partout.

L'affichage est certes rendu plus simple gràace aux relations, mais pour faire une sorte de table d'archive je n'ai aucune idées de comment procéder.

[Tofalu]

Oh et bien par exemple si je veux archiver mes données dans une table, cela est plus difficile car etant données que les données sont éparpillées un peu partout.

Que l'intégrité référentielle des relations soit en place ou non, la structure des objets reste la même : elle répond à une méthodologie : Merise. Rassurez-moi, lorsque vous dites que vous n'utilisez pas de relations, vous avez quand même un schéma normalisé ?

[majudis]

Depuis que je suis rentré en école d'informatique, oui je fonctionne toujours avec des relations

Mais il est vrai que du temps où je travaillais en entreprise, j'y connaissais trop rien en BD, et c'est mon patron qui m'a appris cela, il m'a dit qu'il ne faut pas mettre de clé pirmaires ni de relations, car ça rendait cela plus difficile.

C'est pour cela que j'ai ouvert ce post d'ailleurs

[f-leb]

...et c'est mon patron qui m'a appris cela, il m'a dit qu'il ne faut pas mettre de clé primaires ni de relations, car ça rendait cela plus difficile.

décidémment, j'ai bien du mal à saisir ce genre d'arguments qu'on peut entendre ici ou là.
désolé si je me répète mais en quoi cela est plus difficile ?

...mais pour faire une sorte de table d'archive je n'ai aucune idées de comment procéder.

ben par exemple avec une requête du style SELECT ...INTO, non ?

Pour éviter de tourner en rond sur le sujet, tu pourrais donner un exemple concret (avec 2,3 tables et quelques champs) de ce que recommande ton patron et qui rend les choses plus "faciles" ?

[majudis]

décidémment, j'ai bien du mal à saisir ce genre d'arguments qu'on peut entendre ici ou là.
désolé si je me répète mais en quoi cela est plus difficile ?

Désolé, j'en sais trop rien, on m'a appris comme ça, faudrait que tu débates avec mon ancien patron la dessus

[f-leb]

il m'a dit qu'il ne faut pas mettre de clé pirmaires ....

par exemple, une table Tbl_Client:

Tbl_Client(idClient, NomClient, PrenomClient, Adresse1Client,....)

Avec idClient comme clé primaire de type NumAuto.

Il ferait comment ton patron ? Différemment ?

[Tofalu]

De toute façon, même si cela rendait le développement plus compliqué, l'intégrité des données ne doit pas souffrir du manque de compétences du(des) développeur(s).

L'utilisation des feux clignotant sur une voiture rend la conduite forcément plus compliquée (une action en plus à réaliser), ce n'est pas pour autant qu'il ne faut pas les utiliser.

L'utilisateur confie à son système des données, la moindre des choses qu'il attend en retour c'est que cette saisie soit conforme à ses attentes et pérennes. Les bases de données Access évoluent pour la plupart dans le domaine de la gestion, il parait inconcevable qu'une entreprise puisse se permettre de réaliser une commande, de la confier à un livreur sans que personne ne puisse dire à qui elle appartient. Tout comme un client ne doit pas être en mesure de commander des produits qui n'existent pas.

Jusqu'à présent j'ai construis mes base de données avec très peu de relations et numéro auto, et je me suis rendu compte que cela rendait la construction beaucoup plus facile.

Manifestement, il n'y a pas que votre patron qui pense cela, puisqu'à vous lire, vous éprouvez, vous aussi, le sentiment de simplicité. Mais regardons d'un peu plus prés ce qui se passe dans le cas d'une commande client.

Un client réalise une commande à une date. Cette commande contient des produits. On en déduit donc les règles suivantes :

- Le client doit exister pour pouvoir commander
- Le client ne peut commander que des produits existants

Avec un modèle normalisé, ces règles s'obtiennent aisément avec un simple glisser-déposer dans la fenêtre des relations entre les tables.

Si 'lon confie ces règles à l'applicatif, il faudra au moment de la création de la commande :

• Vérifier que le client existe.
• Empêcher tout le monde de travailler sur ce client
• Créer la commande
• Vérifier que les produits existent
• Empêcher tout le monde de travailler sur ces produits
• Créer les lignes de commande
• Mettre en place un système qui garantira que personne ne supprimera ce client ou ces produits dans les X années à venir faute de quoi toute la comptabilité sera bancale (ce qui est impossible faute de trigger ...)

Vous trouvez vraiment cela plus simple qu'un glisser-deposer avec la souris ?

[Invité]

Bonjour,
Très amusant ce genre de discussion.
Ma spécialité est l'informatique scientifique, donc je ne ferai ombrage à personne, mais je vais tout de même intervenir.
En informatique, il y a un principe général qui est que une information ne doit exister qu'à un seul endroit. Cela peut se traduire comme ceci :
Soit une information A.
L'utilisateur X a besoin de cette information il va donc la mettre dans une table TA.
L'informateur Y récolte des informations du type A. S'il les accumule dans une table TB pour ensuite mettre à jour la table TA, il se trompe.
L'administrateur Z a la charge de mettre à jour (cad assurer la maintenance) des information du type A. De la même façon que Y, s'il travaille sur une table TC et non pas LA TABLE TA, il se trompe.
Etc.
Il n'y a qu'une solution à cela, c'est de réaliser des liaisons de tables avec indexation unique, relation dans les deux sens etc. C'est à dire tous les outils de BD disponibles.

Ce qui distingue un individu (le fameux patron en l'occurrence) et la machine est que le patron possède une sorte de mémoire intuitive et pas la machine.

C'est fondamental et évident en gestion, ça l'est moins en DAO (Dessin Assisté par Ordinateur). Mais je vais tout de même citer un exemple : il est très désagréable de produire un plan à l'échelle du 1/500 alors que sur la page garde, il est inscrit 1/200.
Bon courage

[Arkham46]

bjr,

je suis bien d'accord avec chacun, mais je trouve le vocabulaire un peu confus

une base de données n'est pas mieux avec uniquement des relations et des numéroAuto

Relation :
une relation n'est pas grand chose en soi
il faut surtout mettre en place l'intégrité référentielle

Numéro auto :
même remarque : un numéro auto n'est qu'une numérotation automatique
ce qui importe c'est d'avoir une clé primaire
cette clé primaire n'est pas forcément sur un numéro auto
mais il est préférable d'utiliser numauto si possible car c'est rapide et ça prend peu de place (comparé un id généré avec de l'alphanumérique par exemple)
donc pour un client par exemple, même s'il existe un numéro de client interne à l'entreprise, je rajouterais un numéroAuto comme clé primaire (et un index sans doublon pour le code client interne)
ce numAuto est purement technique et invisible pour l'utilisateur
le code client interne lui, peut éventuellement changer
le mécanisme fonctionne à merveille, il ne faut pas s'en priver

[majudis]

Manifestement, il n'y a pas que votre patron qui pense cela, puisqu'à vous lire, vous éprouvez, vous aussi, le sentiment de simplicité.

Je n'éprouve rien du tout, je n'ai jamais utilisé ACCESS au par avant. C'est mon patron qui m'a fait découvrir cela. Il est donc évident que j'ai construis mes premières bases de données en suivant sa methode.

Aujourd'hui, je suis des cours sur Access en école d'informatique. Et j'ai découvert depuis peu, le système relationnel. Voilà pourquoi j'ai ouvert ce post. Pour tenter d'avoir plus d'informations à ce sujet, et savoir si l'importance se fait sentir d'utiliser les relations.

A parrement, j'en conclu que oui.

Toutefois, ce n'est pas en me disant que je suis aussi nul que mon patron, ou encore que ma méthode de travail est une atteinte aux valeurs de l'humanité , que je vais comprendre pourquoi cette méthode de travail que l'on m'a appris au tout début, est une erreur.

Je souhaitais tout simplement en savoir un peu plus. En effet, mon patron utilisait la méthode des fichiers plein texte, et aujourd'hui il est clair que je me rends compte, en reprenant l'exemple des factures clients expliquées plus haut dans ce post, que le système relationnel est incontournable pour le bon fonctionnement d'une base.

Maintenant, il est clair que pour vous cela parrait evidement, sauf que moi je ne maitrise pas du tout access, donc si certaines personnes sont prêt à m'aider, je veux bien vous poster mon schéma relationnel et vous expliquer les points qui me posent problème.

Sincères salutations,

Majudis

[Tofalu]

Toutefois, ce n'est pas en me disant que je suis aussi nul que mon patron, ou encore que ma méthode de travail est une atteinte aux valeurs de l'humanité , que je vais comprendre pourquoi cette méthode de travail que l'on m'a appris au tout début, est une erreur.

Les cours que vous suivez sont là pour ça : vous apprendre les théories du modèles relationnel. Que l'on peut compléter par ces quelques liens :

http://mhubiche.developpez.com/Access/cours/bases/
http://mhubiche.developpez.com/Access/tutoJointures/
http://cyril-gruau.developpez.com/um.../ConceptionBD/

Mais ça reste de la théorie qui ne sera réellement comprise qu'avec de la pratique. C'est clair qu'au début, cela reste confus.

L'intéret d'une telle conception est de limiter aux maximum les doublons et l'absence de données qui sont sources d'erreur.
Avec une conception à la Excel, on se retrouve vite avec :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
Commande	DateCommande	NomClient	AdresseClient	VilleClient
1	10/02/2000	Martin	12 Grande Rue	LYON
2	11/02/2000	Paul	12 Rue de Lyon	MACON
3	12/02/2000	Martin	123 Grande Rue	LYON
4	11/02/2000		11 Boulevard	PARIS
5	13/02/2000	Martin	Grande Rue	69

Rien n'est normalisé, quelle est la vraie adresse de martin ?

Alors qu'il est bien plus sécurisé d'avoir une liste des clients

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
NumClient	NomClient	AdresseClient	VilleClient
1	Martin	12 Grande Rue	LYON
2	Paul	12 Rue de Lyon	MACON

Et dans la commmande de faire référence au numéro du client plutot qu'à son identité complète. Le développeur se chargera alors de créer une interface qui fera la synthèse entre les deux (requête avec jointure)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

je veux bien vous poster mon schéma relationnel et vous expliquer les points qui me posent problème.

Vas-y,

[majudis]

Merci Tofalu pour les liens, je vais y jeter un coup d'oeil.

Voici mon schéma de relations :

[Tofalu]

Sans juger si c'est correct ou non, voilà ce que j'en comprend. Si ça ne colle pas avec ce que tu souhaitais, c'est qu'il y a des erreurs. Cette approche inversée permet parfois de voir le problème sous un autre angle.

• Il s'agit d'un suivi de risques professionnels.
• On stcoke les données de chaque personnel ainsi que le nom de leur médecin.
• On stocke l'historisque d'affectation des personnes à un poste. La personne entre à Année pendant Durée.
• On a une liste de risques
• Un produit peut engendrer plusieurs risques (ex je suppose : irritation des bronches, irritation de la peau, etc)
• Un poste est exposé à plusieurs produits, donc de fil en aiguille à plusieurs risques.

En revanche, partons de l'hypothèse que Jean entre dans l'atelier peinture qui, à cette époque ne fait que de la peinture. Il est exposé au risque irritation des bronches exclusivement, car seul risque du produit Peinture. En 2005, Jean quitte l'atelier peinture et rejoint les bureaux. On estime qu'il n'y a plus de risque (on imagine hein). Toujours en 2005 et alors que Jean a quitté l'atelier peinture, l'atelier peinture se voit confier une nouvelle tâche : le décapage des matériaux avant la pose du revetement. Les ouvriers manipulent des décapants dont le risque est l'irritation de la peau.

Si en 2005, Jean consulte la base de données, il verra que de 2004 à 2005 il a été au poste "Atelier Peinture" avec les risques :
- Irritation des bronches
- Irritation de la peau

Mais il n'a jamais été exposé au risque de l'irritation de la peau puisqu'à son époque, on ne manipulait pas de décapant dans l'atelier.

Là où je veux en venir : c'est qu'on a un historique correct des affectation mais pas des expositions. Ca pourrait se faire simplement en ajoutant deux champs dans la table exposition : dateDebutExpo, DateFinExpo

On peut ainsi en requetant faire le lien entre les affectations de Jean et les dates d'expositions aux produits et donc au risque.

[majudis]

Bonjour,

Mon problème en fait, c'est qu'on me demande d'archiver chaque année dans une table archives.

Seulement je ne vois pas du tout comment faire car les données sont éparpillées dans plusieurs tables.

Alors j'ai pensé a sauvegardé l'intégralité de la table Affectation dans une table archives, mais je crois que cette methode va poser problème lorsque qu'un poste va être modifié au niveau des produits.

Je sèche un peu :s

[Tofalu]

Mon problème en fait, c'est qu'on me demande d'archiver chaque année dans une table archives.

Dans un domaine d'action qui gère des intervalles de durée et assez peu de données, j'ai du mal à comprendre comment on peut parler d'archivage.

A la limite qu'on archive conditionnellement des données devenues obsoltètes : personnels en retraite, pourquoi pas, mais un archivage annuel sans "exercice" annuel, ça n'a pas vraiment de sens ici.

Honnêtement, ici, je ne vois ni l'intéret, ni la solution

[majudis]

Cette base de données permet de sortir les fiches d'expositions de chaque salarié. Ainsi on sait que tel personne a été exposé a tel produit pendant l'année en cours.

Et quand je parle d'archivage, je veux dire par là qu'il faut que je garde les données une fois l'année terminée.