Discussion :

[lmc71]

Bonjour le Forum
Tout d'abord Bonnes Fêtes de fin d'année à tous.
Je bute actuellement sur le regroupement des valeurs de 6 champs dans une table issus de 3 tables soit 18 champs au total dans une nouvelle table.
Je m'explique.
Je créée une base de santé avec entre autre une table de Consultation et 3 tables d'ordonnance comprenant 6 champs de médicament chacune.
Les médicaments sont issus de la table T_Medicament.
Le but final, je voudrais sortir une liste des médicaments ( avec le nombre de chacun ) pris par moi même ou par mon épouse.
Actuellement je ne sais pas comment faire pour pouvoir réunir tous les médicaments présents par les 3 ordonnances d'une consultation d'un prénom.
Mon docteur peut me délivrer (éventuellement) plusieurs ordonnances contenant de 1 à 6 médicaments par ordonnance lors d'une consultation.
La relation entre ces 4 tables se fait par la clef primaire de la table de Consultation.
Si quelqu'un peut me débloquer je suis preneur.
Merci d'avance
Cordialement

[hyperion13]

Salut
Une capture d'écran de la fenêtre des relations serait la bienvenue.

[Pierre Fauconnier]

Salut.

Des explications données, je pense qu'il n'est pas nécessaire d'avoir des tables à regrouper en une seule à un moment donné. La modélisation des données impose qu'il y ait UNE table pour chaque entité. Ici, on parle de personnes (toi, ton épouse et les toubibs), de médicaments et d'ordonnances. Cela fait trois tables. Dans la mesure où une ordonnance est composée de plusieurs lignes (on peut prescrire plusieurs médicaments sur la même ordonnance), il faut une table pour les lignes des ordonnances. Une cinquième table contiendra les rôles de chaque personne (patient ou toubib).

Voici, d'une rapide analyse, ce que je proposerais comme structure de base. Elle te permettra d'encoder les patients (ton épouse et toi-même, voire d'autres personnes), les médecins prescripteurs, les médicaments, ainsi que les ordonnances avec le détail de celles-ci. Avec cette architecture, je considère qu'un "patient" ne peut pas en même temps être "médecin" , ce qui est suffisant pour le cas que tu exposes.

Si une personne était à la fois patient et toubib, il faudrait soit l'encoder deux fois, une fois comme patient et une fois comme toubib, mais cela créerait un problème de structure des données, ou alors modifier la structure des tables en passant par une table Personne/Rôle, seule capable de modéliser la relation Plusieurs à plusieurs qui serait créée (si on exclut les champs multivalués d'Access, ce que je conseille car c'est une horreur inepte qui ne respecte pas les formes normales de conception de bases de données relationnelles). Note bien que sur le diagramme ci-dessous, Personne et Personne_1 pointent vers la même table, Access imposant de placer la table Personne une seconde fois dans le diagramme puisqu'une table (Ordonnance) utilise deux clés externes vers cette table (une pour le patient et l'autre pour le toubib).

Dans le fichier joint, tu trouveras un exemple avec quelques saisies ainsi que deux jeux de formulaires/sous-formulaires, un pour le patient et pour le médecin.





Grâce à cette architecture de tables, tu vas pouvoir faire ce que tu veux avec tes données, tant au niveau de la saisie que du reporting et de l'analyse. Au niveau de la saisie, tu peux encoder une ordonnance sur la fiche du patient ou sur la fiche du médecin, selon ton choix et la configuration du moment. Tu pourrais également créer un formulaire Ordonnance dans lequel tu renseignerais le patient et le médecin. Sur le plan de l'analyse, le modèle relationnel permet d'aller d'aller de n'importe quelle table à n'importe quelle autre, puisque toutes les tables sont liées entre-elles.

[lmc71]

Bonjour Pierre et Hyperion13
Pierre je te remercie pour tes explications très détaillées que je vais étudier demain. Je reviendrai vers vous pour vous informer.
Actuellement j'ai bidouillé un résultat par l'intermédiaire de 18 requêtes ajout qui remplissent une table de tous les médicaments qui sont présentes dans les ordonnances.
Encore merci
Cordialement

[lmc71]

Re
Je joins une photo pour Hyperion13.
Pour Pierre, pourrais-tu m'expliquer la différence entre les requêtes L_Medecins et Medecins, L_Patients et Patients. Apparemment Medecins et Patients sont la source des formulaires Medecin et Patient, mais à quoi servent L_Medecins et L_Patients.
Il est vrai que je me peut-être compliqué l'existence avec beaucoup de précisions qui alourdissent l'ossature. Je vais essayer de refaire cette base avec tes précieux conseils.
Cordialement

[lmc71]

Bonjour
Bon réveillon à tout le Forum et mes voeux pour cette année 2020
Bonjour Pierre
Je reviens vers toi pour un explication concernant tes formulaires Médecin et Patient.
Après inséré un prénom (Serge) dans la table Personne et pour rôle Patient et que je veux utiliser le formulaire Patient avec un nouvel enregistrement en cliquant sur l'étoile jaune et inscrit mon prénom dans le contrôle Prénom et déplacé le curseur avec la touche TAB je me retrouve avec une fenêtre d'erreur figurant ci-dessous.
Je n'ai pas l'habitude de travailler sous cette forme d'architecture est-il possible de mettre le contrôle Prénom du formulaire Patient en liste déroulante ?
Cordialement

[Pierre Fauconnier]

Bonjour, et bonne année 2020

Il faut ajouter la liste déroulante de choix du rôle dans les formulaires patient et médecin... Voici un fichier adapté

[lmc71]

Bonjour
Merci de ta réponse.
Et apparemment pour mettre le prénom ou nom en liste déroulante dans les formulaire Patient ou Medecin il faut passer par une table spécifique prénom ou autre.
Passes une bonne journée.
Cordialement

[lmc71]

Re
Je suis vraiment un nul avec cette architecture d'apparence facile est très troublante (pour moi).
En effet avec un nouveau Prénom et un nouveau médecin voici le message d'erreur dans le sous formulaire des médicaments. Je n'arrive pas à saisir d'où vient cette erreur.
Cordialement

[Pierre Fauconnier]

Ici, le but était surtout de montrer la structure des tables, pour éviter les x tables et les x requêtes pour réunir le tout. Après, sur le plan de l'ergonomie, j'ai été très minimaliste pour montrer que l'on peut prendre l'encodage d'une ordonnance par le formulaire du patient ou par le formulaire du médecin.

On pourrait imaginer un troisième formulaire qui permette d'encoder une ordonnance, en partant de la table ordonnance. On voit que dans les trois cas, on utilise le formulaire sfOrdonnanceDetails qui n'est donc créé qu'une fois.




Ce qu'il est important de voir ici, c'est que toutes ces ergonomies sont possibles uniquement parce nos tables sont bien construites et respectent les normes qui président aux bases de données relationnelles. La base essentielle en Access, c'est l'architecture des tables, sur laquelle tout le reste de l'application repose.

[Pierre Fauconnier]

Re
Je suis vraiment un nul avec cette architecture d'apparence facile est très troublante (pour moi).[...]

Ici, on part du principe que les médicaments existent déjà dans la table des médicaments. A nouveau, c'est une question d'ergonomie. Access permet d'associer un formulaire de saisie à une liste déroulante lorsque l'on saisit dans la liste une valeur qui ne s'y trouve pas. Je ne suis personnellement pas très chaud pour ce genre d'ergonomie si on la met en place sans alerte, car elle amène inévitablement à créer des pseudo-doublons dans les tables. Il suffit d'un moment d'inattention sur la saisie du nom d'un médicament pour créer un "doublon" sur base d'une simple faute de frappe.

Comme je l'ai dit dans mon message précédent, c'est d'abord une question de structure des tables avant d'être une question d'ergonomie. Pour le cas que tu as initialement soulevé, il n'y a à mon avis qu'une bonne structure de table, celle que j'ai proposée. Par contre, les ergonomies qui s'appuieront dessus peuvent varier considérablement selon les développeurs, le fait que l'on met ou pas des macros ou du vba derrière, etc.

[Pierre Fauconnier]

Re
Je suis vraiment un nul avec cette architecture d'apparence facile est très troublante (pour moi).[...]

Non non, tu n'es pas nul... C'est moi qui suit nul (comme les bulles de hier soir?).

Dans le diagramme relationnel, j'avais mal relié les tables Medicament et OrdonnanceDetail... (J'ai glissé, chef). Désolé!!

J'ai corrigé. Dans le fichier joint, tu n'auras plus ce souci... Désolé pour la perte de temps.

[lmc71]

Re
En espérant que tu n'as pas passé ce jour si merveilleux devant toi clavier......
Ne te traite pas de nul vu les étoiles......
Je n'arrive pas à déceler l'anomalie de cette relation car je pensais qu'elle était voulue.....
Je te rejoins dans le fait de dire qu'une bonne charpente, ossature ou architecture d'une basse évite bien des maux, mais faut-il encore trouver et penser la bonne combinaison ou le bon chemin pour arriver au but final.
Je t'en supplies ne me qualifie pas de Chef, car je se le suis tu es Capitaine de Vaisseau.....
Allez laisse tomber le clavier et termine bien la soirée.
Je vais essayer de progresser dans ton idée.
cordialement