Discussion :

[poulping]

Bonjour.
J ai un probleme pour un bout de MCD :
Je dois relier plusieurs entites entre elles au sein d'une relation, hors une de celles ci ne doit pas etre source de l'identifiant .... ce qui a premiere vue viole une regle de validation de base.
Une de ces entites est une date (pas de probleme) puis les 3 autres que l on peut nommer A B C.
Ma solution est la suivante mais je n en suis pas reellement satisfait :

Faire de C une entite faible de A afin que l'identifiant ne soit plus compose que de A B et la date.
Je debute en merise et ne sais pas trop si j ai le droit de faire cela.

Merci pour votre aide.

[Médiat]

Crée une entité associative plutôt qu'une association, tu auras pleine maîtrise des cardinalités et des identifiants

[poulping]

Bonjour.
Merci de ta reponse.
Je ne connaissais pas ce concept.
En cherchant j ai trouve que l'entite associative relie deux concepts lies qui forment l association a l'entite.
Mon probleme etant que l'entite C n a pas de dependance directe avec A . Je en sais comment la lier :
Si je lie A et D avec des cardinalite a 1,1 du cote de A et 1,n du cote de D, je lie la date a A avec une 1,n j ai deja presque ce que je veux : un identifiant compose de B D et A.
Si je lie C a A par l'intermediaire d'une association 1,1 du cote de A et 1,n du cote de C je change mon identifiant non ?

En realite A represente une consultation, C un medecin et B un patient

Ma solution consistait a faire de consultation une entite faible ayant pour identifiant la concatenation de B et D et relier C a A par une 1,n

Est ce acceptable ?

[Médiat]

Si j'ai bien compris, voila ce que cela donne. C'est à dire qu'un patient ne peut avoir qu'une seule consultation par jour, et que celle-ci est donnée par un seul médecin, est-ce la réalité ?

C'est à dire pour le modèle Physique :

Code :

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

1
2
3
4
5
6
create table CONSULTATION  (
   LADATE               DATE                            not null,
   IDPATIENT            INTEGER                         not null,
   IDMEDECIN            INTEGER                         not null,
   constraint PK_CONSULTATION primary key (IDPATIENT, LADATE)
);

[poulping]

C'est presque ca puisque dans ma date je rajoute une deuxieme propriete (ordre) qui permet de lever la contrainte d'une consultation par jour
J'ai regarde ton schema, seulement je debute (je fais une formation a distance) et n ai pas encore etudie les extensions Merise je suppose que les differents symboles representent ces extensions et traduisent le fait que Medecin n'est pas identifiant.
Cette entite Consultation represente donc une entite associative ?
Sachant que je ne suis pas "sense" connaitre ce type d'objet d'apres mon cours j'ai longuement hesite entre une association ternaire avec consultation en association porteuse entre les 3 entites, mais dans ce cas l'identifiant est la concatenation des 3 entites... et la solution que je t ai presente au dessus.

P.S : j ai un clavier Anglais donc pas d'accent desole !

[Médiat]

C'est presque ca puisque dans ma date je rajoute une deuxieme propriete (ordre) qui permet de lever la contrainte d'une consultation par jour

Dans ce cas est-ce qu'un DATETIME ne suffirait pas ?

Je n'ai pas utilisé la notation Merise, mais tu as bien décodée celle-ci.

[poulping]

Effectivement le DATETIME serait une solution efficace mais le reel decrit que ma consultation doit etre identifiee par l'annee, l ID du patient et l'ordre (de 1 a n et repartant de 1 pour chaque patient) d ou l idee de regrouper Date et Ordre comme identifiant de Date.
Je ne vois vraiment pas d autre solution que celle que j ai presente mais si vous pensez qu elle n est pas viable, je vais encore me creuser un peu la tete !