Lie la table Résidents à la table Séjours sur le N°DeSS (que tu as oublié dans la table séjour), la table Séjours à la table Etablissements par le N° d'établissement (Que tu dois donc supprimer de la table résidents)

La clé primaire de la table Séjours sera sur trois champs:
N°Résident
N°Etablissement
DateArrivée
(Au cas où ils fassent plusieurs séjours dans le même établissement)

Le reste fonctionne suivant le même principe Pourquoi se compliquer la vie à faire simple, quand c'est si simple de faire compliqué?

Merci de la réponse, je vois ce que j'avais bêtement manqué pour la 1ère partie de la réponse.

Par contre pour la seconde partie de la réponse, dois-je comprendre que je dois créer ma clef primaire sur la réunion des 3 champs?

Une dernière question: pour toutes les autres liaisons (en particulier avec les résultats d'examen complémentaires?) est-il pertinent de relier le N° SS de la table Résident à un N° de clef secondaire qui est le même N° de SS (ce que j'ai fait, et qui me semble trop facile puisque globalement ma clef secondaire est la même dans toutes les tables) ou bien dois-je créer un N° d'examen qui est ma clef primaire de cette table?

Merci

(Désolé si mes questions sont un peu idiotes, mais j'avais pensé que le concept de modélisation entité-association seraiit plus complexe pour mon exemple)

Première réponse: La clé est constituée de trois champs. Tu sélectionnes les trois par un cliquer/glisser, avant de cliquer sur le bouton Clé, et un symbole clé s'affiche devant les trois champs. C'est l'ensemble de ces trois qui devra être unique et identifiera l'enregistrement.

Pour le reste, voilà la logique.
UN résident peut subir PLUSIEURS examens. Il y a donc deux tables, une table résident et une table examen. La clé de la table résident est le N°SS (UN champ), qui sert de lien entre les deux tables, et la clé de la table examen est N°SS et DateExamen par exemple - clé sur PLUSIEURS champs.

C'est toujours comme ça. Dans une relation un-à-plusieurs, la clé du côté "un" doit dans la mesure du possible TOUJOURS porter sur UN champ. 'C'est techniquement possible de faire autrement mais c'est plus compliqué et lourd à gérer.)
Quant au coté "plusieurs" de la relation, tout dépend de ce qui se passe après. Si la table est également du côté "un" d'une autre relation, il faut lui attricuer un champ qui puisse servir de clé unique.

Cas simple: Une gestion de facture.
UN client peut avoir PLUSIEURS factures: La clé de la table Clients porte sur UN champ, NClient.
Le lien avec la table Factures se fait sur le NClient.
UNE facture a PLUSIEURS lignes de détail: La clé de la table Factures porte sur UN champ, NFacture.
Le lien avec la table DétailFactures se fait sur le champ NFacture
UN code article peut être présent dans PLUSIEURS détails de facture: La clé de la table Articles porte sur UN champ, NArticle.

Et la Table DétailFactures? Elle n'est QUE du côté "plusieurs" de ses relations, donc sa clé porte sur DEUX champs, NFacture et NArticle, les deux champs qui servent à faire le lien avec les tables factures et Articles.

Simple, non?







Pourquoi se compliquer la vie à faire simple, quand c'est si simple de faire compliqué?

Bonjour,

Merci pour les réponses: quelquefois la solution est si évidente qu'elle vous crève les yeux!

Bonjour,

Je rencontre encore le problème suivant:

J'ai une table RESIDANT (simplifiée)

Clef_Primaire: N°_de_ SS
Nom
Prénom

Ainsi qu'une Table MEDICAMENT

Clef primaire: Code_CIP
Nom_Médicament
Heure_de_Prise_du_Médicament (Liste à Choix multiples avec posologie Unitaire par incréments de 1/4) (Ex: à 08H00: on a une liste 1/4; 1/2; 1; 1.25 etc...de même à 09H00, puis 10H00...etc;)

-Un résidant peut prendre 1 à n médicaments.
-Chaque Médicament peut être pris par 0 à n résidants.

-Je fais une table de liaison Résidant-Médicament:

N°_de_ SS
Code_CIP

Problème #1: Il peut y avoir plusieurs prises quotidiennes d'un médicament donné (Ex: 08H00, 12H00, 19H00 et 23H00) pour un résidant donné. (Ou n'importe quelle tranche horaire avec plusieurs tranches possibles)

Problème #2: La posologie en nombre unitaire de dose peut être variable par prise et par résidant: Ex: un résident peut prendre 1 comprimé à 08H00; 1/2 à 12H00; 3/4 à 20H00) alors qu'un autre résidant peut prendre des doses différentes, soit aux mêmes horaires, soit à des horaires différents en tout ou partie.

Comment puis-je résoudre ces problèmes qui ne sont pas résolus par ma table intermédiaire?

merci

Merci.

Forcément, plus on avance, plus cela génère d'autres questions...En voici 2...

- Soit une relation n-m entre deux tables A et B, chacune ayant une Clef primaire PK1 et PK2.

Supposons qu'une (ou les 2) PK de ces 2 tables est un N° auto-incrémentable,

Je crée donc une table de liaison entre les 2 tables précédentes de façon à avoir 2 relations 1-n, cette table de liaison A-B a donc la PK1 et PK2 comme Clefs étrangères. FK1 et FK2;

Or, dans ACCESS, comment mes champs (de ma table de liaison) de même nom que les 2 PK des 2 autres tables pourront être reliées puisque les attributs Integer auto_increment de ces mêmes clefs seront forcément différents entre les champs de même nom de la table A et de la table A-B? Or si je ne mets pas le même attribut dans les FK de la table de liaison, les jointures ne se feront pas. Comment régler ce problème?

Table A
PK1 (Attribut Long_Integer Auto_Increment )
Champ2
.
..
Champ n

Table B
PK2
Champ 2'
.
..
Champ n'

Table de liaison A-B
PK1 Comment l'attribut peut-il être le même que dans la table A puisqu'il va changer à chaque ligne dans la table A ?
PK2


-Une 2nde question par rapport à ma future base (qui avance): mes résidants peuvent être porteurs de prothèses (pace-maker, lunettes, prothèses auditives, prothèses dentaires etc). Le renseignement est suffisant avec Y/N pour chacune des variables.
Ces critères étant dépendant du résidant uniquement, il serait logique (?) de mettre chacun de ces critères dans la table résidant... Mais cela va être gourmand en taille de la base.. N'y a -t'il pas un moyen de créer une table prothèse, mais quel identifiant donner? Cela reviendrait à donner à chaque groupe d'association de prothèses un N° ID ce qui semble idiot. Lorsqu'un résidant a une prothèse en moins ou en plus dans le cours de sa vie, il faudra un nouveau de N° d'association de prothèses... Qu'en pensez-vous?

Merci.

Merci pour vos réponses.
Je crois que j'ai bien avancé dans ma base.
Je rencontre un autre problème, une fois les relations déterminéesentre les tables, pour la saisie/récupération des données:

Imaginons des tables simplidfiées:

1.Table_Residant

ID_Residant (=PK Auto-incrémenté)
Nom_Residant
Sexe_Residant

2.Table_GIR

3.ID_GIR (=PK Auto-incrémenté)
Coherence
Orientation

4.Table_Appareillages

ID_Continence
Continence_Urinaire
Continence_Fécale

La table résidant ayant des relation PLUSIEURS à PLUSIEURS avec les tables GIR et Continence (Un résidant peut avoir plusieurs évaluations GIR et plusieurs évaluations de Continence; une grille d'évaluation GIR peut être faite pour plusieurs résidants, idem Continence), on crée 2 tables de liaison:

5.Table_LIAISON_Residant_GIR
ID_Residant
ID_GIR

6. Table_LIAISON Residant_Continence
ID_Residant
ID_Continence


Le problème est le suivant: je souhaite entrer des données pour tous les résidants avec un formulaire

-Si je fais un formulaire avec la table Residants, je ne peux y ajouter TOUTES les données de TOUTES les tables, or dans l'exemple simple sus-cité:

-je peux voir une table avec les données de la table Residants ET de la table GIR en faisant un formulaire avec la table de LIAISON_Residant_GIR

-je peux voir les données de la table Residant ET de la Table Continence en faisant un formulaire avec la Table de LIAISON_Residant_Continence

-Mais comment voir les données de la table Residants ET de la Table GIR ET de la Table Continence (et de toutes les tables reliées dans ma vraie base???) sur un même formulaire???

Merci

Dans ce cas-là, il faut procéder en plusieurs étapes, c'est-à-dire créer le côté 1 de la relation dans les deux tables et ensuite seulement créer l'enregistrement côté n-n dans la table intermédiaire (table liaison).

Ensuite, un affichage dans un formulaire sera possible. Mais en tout cas, pas de création d'un 'n' sans avoir crée le '1' avant (intégrité référentielle).

A+ Blux           

 "Les cons, ça ose tout.
C'est même à ça qu'on les reconnait"

C'est malheureusement ce que je craignais et c'est un peu décevant: on ne peut avoir une vision d'ensemble de la base, mais seulement une vision selon plusieurs angles de cette base...

Comment-font-ils dans les applications professionnelles qui ne sont finalement qu'une interface avec un SGBD en arrière plan même si ce n'est pas Access?

Ou bien est-ce uniquement Access qui ne permet pas cette souplesse?

Merci

AUCUN SGBDR ne te permettra de faire cette création en une seule fois, il y a forcément conservation des informations saisies pour remplir les tables dans l'ordre dans lequel elles doivent être remplies...

mais seulement une vision selon plusieurs angles de cette base...
Une fois que les informations sont remplies, on peut avoir une vision de synthèse de l'ensemble des éléments, grâce à une requête complète...

A+ Blux           

 "Les cons, ça ose tout.
C'est même à ça qu'on les reconnait"

Le mieux que tu puisses faire est un méga-formulaire, avec des onglets contenant eux-mêmes des formulaires avec sous-formulaires, mais de toute façon si tu réfléchis tu verras qu'il est IMPOSSIBLE de visualiser TOUTES les infos en une seule fois sur un écran d'ordinateur, juste parce que ben... Il est trop petit!!!

Prenons un exemple bête de logiciel de facturation: JAMAIS tu ne peux voir en un seul aperçu la liste de TOUTES les factures d'un client avec TOUS les articles commandés sur toutes ces factures ainsi que TOUS les prix tarif de cet article (en fonction des types de clients ou des quantités) et le stock actuel et les tailles et couleurs disponibles pour cet article.
Par contre si tu les demandes correctement, tu peux obtenir toutes ces infos.

Avec Access c'est la même chose! Je ne vois pas bien ce qui te heurte... Pourquoi se compliquer la vie à faire simple, quand c'est si simple de faire compliqué?

Bonjour,

En fait ce qui me pose problème, ce n'est pas d'avoir toutes les infos lorsque je fais des formulaires, c'est que je perds l'intégrité référentielle. Je m'explique avec un exemple:

Voici trés simplifiées une table Parent et uneTable Fille dans une relation UN à PLUSIEURS avec Intégrité Réferentielle car je ne veux pas saisir des séjours sans avoir un résidant!!!

Table_Residant:

ID_Residant=PK Auto_Incrementable
Nom_Residant
Prenom_Residant

Table_Sejour:

ID_Sejour=PK Auto_Incrementable
ID_Residant= Clef_Secondaire
Date_Entree
N°_Chambre

1.Je fais un formulaire en cliquant sur ma table Residant dans la partie Gauche du Panneau d'Access 2007: Tous les Champs de la table Residant s'y trouvent.

2.Je fais un formulaire de la même façon avec la table Sejour: j'y insère les champs de la table Residant, et j'y vois le nom etc... Lorsque je veux créer un nouveau séjour dans la table séjour, j'ai une liste déroulante qui ne me permet de ne créer des séjour que pour les Residants déjà inscrits dans la table Residant.
C'est bien ce que je veux, SAUF qu'il faut d'abord que je fasse un Formulaire pour la Table Residant, PUIS un autre pour la Table Séjour.


3. Si je veux mettre les champs de la table Sejour (outre le fait que ceux-ci s'insèrent dans un tableau type "Excel" qui n'est pas trés convivial) sur le même formulaire que celui me permettant de rentrer mes Residants , je peux rentrer autant de fois TARTEMPIOM comme Résidant et l'intégrité Référentielle n'est plus respectée. A chaque fois que je rentrerai TARTEMPION, cela correspond à un NOUVEAU Residant.

4. De la même façon, si en mode Création je mets sur un même formulaire les champs des tables en relations qui m'interessent dans la disposition et formatage qui me plaît, l'intégrité Référentielle n'est pas respectée

Ma question est POURQUOI l'intégrité Référentielle n'est pas respectée lorsque l'on fait des formulaires avec les champs des tables en relation incluant la table Parent, sans avoir fait au préalable, de façon distincte un formulaire (ou une saisie directe dans la table appropriée) dans la table PARENT???

En pratique, j'aimerais que les personnes ayant à saisir les informations puissent saisir à la fois un nouveau séjour pour un nouveau résidant, ou un nouveau séjour pour un résidant existant déja, ce dans le même formulaire (pour des raisons évidentes de simplification pour ceux qui saisissent l'information)

En espérant que mes explications soient un peu claires...
AI-je manqué quelque chose??

Merci

3 - je peux rentrer autant de fois TARTEMPIOM comme Résidant et l'intégrité Référentielle n'est plus respectée. A chaque fois que je rentrerai TARTEMPION, cela correspond à un NOUVEAU Residant.
C'est que le champ qui contient TARTEMPION n'est pas la clé primaire, donc ce n'est pas le même individu.
L'intégrité référentielle est parfaitement respectée, mais tu confonds les clés primaires (sûrement un champ 'numéroauto').

4. De la même façon, si en mode Création je mets sur un même formulaire les champs des tables en relations qui m'interessent dans la disposition et formatage qui me plaît, l'intégrité Référentielle n'est pas respectée
Comment peux-tu le dire ? Tu as un message d'erreur ? sur quelle action ?

Ma question est POURQUOI l'intégrité Référentielle n'est pas respectée lorsque l'on fait des formulaires avec les champs des tables en relation incluant la table Parent, sans avoir fait au préalable, de façon distincte un formulaire (ou une saisie directe dans la table appropriée) dans la table PARENT???
L'intégrité reférentielle n'est testée qu'en ajout de données et non pas à la création d'on ne sait quelle structure (formulaire et autres). Ce qui explique que tu peux créer des formulaires et des sous-forms avec des liens 'impossibles' entre eux, mais lorsque tu voudras valider ton montage en écrivant des lignes dans les tables, ACCESS fera le contrôle et te signalera les incohérences...

Je ne sais pas si je réponds à tes interrogations.

A+ Blux           

 "Les cons, ça ose tout.
C'est même à ça qu'on les reconnait"

Je n'obtiens AUCUN message d'erreur.


Ce que je constate:

Je rentre dans mon formulaire -comprenant des champs de tables reliées entre elles (bien évidemment)- pour utiliser l'exemple précédent: Une table Residant reliée par sa clef Primaire ID_Residant à la Clef Secondaire ID_Residant dans la table Sejour

Je rentre le Nom_Residant"TARTEMPION"; La table Residant lui affecte l'ID_Residant (Clef Primaire) 1.

Si je crée un nouveau dossier avec le nom TARTEMPION, TARTEMPION a cette fois le N°2 etc...

En clair, mon formulaire dans cette configuration ne reconnais pas que le TARTEMPION est le même donc avec le même numéro que le TARTEMPION précédent qui devrait avoir ID_Residant=1.

Alors que si je fait un formulaire avec la TAble Residant puis un formualire avec la table Sejour, je ne peux bien évidemment pas saisir un autre nom que ceux qui sont déjà rentrés (rentrés dans la Table Residant) dans la table séjour.

Je peux créer autant de séjours que je veux avec TARTEMPION, mais si je veux créer DUPONT, avec un séjour, mon champ Nom_Residant dans mon formulaire comprenant les tables Residant et table Sejour, (avec le Champ Nom_Residant qui vient de ma table Residant) m'empêche de saisir un nouveau nom.


En fait ta remarque est pertinente, ma clef Primaire est un N° autoincrementable et mon champ Nom_Residant n'est lui pas la clef Primaire, donc en effet mon Intégrité référentielle est respectée.

Mais en bon Français, ce que qui me parle, c'est le Nom_Residant, l'être humain reconnait le nom, pas le numéro.
Bien évidemment je peux voir le N° puis aller chercher dans la table Residant à quel nom ce N° correspond, mais il doit bien y avoir moyen d'affiche le N° (Clef primaire) ET le NOM?? dans ce type de formulaire?

ENcore une fois j'espère que ce que j'écris est un peu compréhensible parce que le non expert que je suis a du mal à expliquer!!

Merci quand même!

Bonjour,

Oui bien sûr, mais comment puis-je faire pour que lorsque je saisis mes informations, par exemple Dupont, mon formulaire montre les Duponts déjà présents (ou bien une fois que j'ai rentré le nom, le prénom, voire la date de naissance ou le nombre de critères suffiamment discriminants) pour être sûr que mon Dupont va bien être un nouveau Dupont auquel sera affecté un nouveau N° ou au contraire que je puisse utiliser un Dupont existant et lui créer un nouveau séjour ou quoi que ce soit dans une table reliée?

Encore une fois je parle ici d'un formulaire créé à partir de plusieurs tables reliées.

merci

J'ai plusieurs champs avec listes multi-colonnes dans ma base (par ex un champ medecin_traitant qui va chercher dans une table multi colonne le medecin avec son nom, prénom, tel etc...)

Mais ici, comment est-ce que je fais ça en pratique? Je suis dans un formulaire???? et le champ nom_residant qui m'interesse (dans l'exemple plus haut) qui vient de ma table Residant se remplit justement au fur et à mesure.

Il faut donc que dans mon formulaire je vois apparaitre dans une liste déroulante au moins l'ID_Resiant, le nom, le prenom voire la DdN avant de saisir un nouveau nom.

Peux-tu détailler STP comment je fais?

Merci

En fait je viens d'essayer la chose suivante:

Ma table Residant a donc un PK qui est ID_Residant (attribut = N° auto incrémentable)

Elle était reliée à ma table fille dans ma relation 1 à plusieurs à ma clef Secondaire (champ ID_Residant qui avait l'attribut Entier long)

J'ai dans la table fille changé l'attribut Entier long du champ ID_Residant pour une liste déroulante multi colonne (1ère colonne = ID_Residant).

Apparemment cela marche bien.

Cela devrait être ma dernière question: La liaison se fait sur 2 champs qui ont désormais des attributs différents: je croyais qu'il fallait que les champs sur lesquels se faisaient les jointures devaient avoir les mêmes attributs?

Merci pour les réponses

je crois que ma petite base tourne au poil!