Discussion :

[ziliass]

Bonjour,
Merci de corrigé l'MCD en pièce jointe.
ci-dessous les règles de gestion :

- Chaque patient est identifié par un matricule.
- Chaque patient doit fournir au service facturation le numéro de la carte d'identité et le téléphone de son tuteur.
- Chaque patient peut être hospitaliser plusieurs fois dans des périodes différentes.
- Chaque patient doit avancer un montant avant d'être hospitalisé
- Chaque patient peut subir plusieurs opérations.
- Chaque patient peut consommer plusieurs médicaments.
- En cas de décès d'un patient ses coordonnées sont enregistrer dans une fiche.
- Dans la clinique travaille plusieurs médecins en vacation.
- Chaque medecin est identifié par un numéro.
- Chaque patient a un seul medecin traitant.
- Chaque médecin est payé selon son propre tarif par jour.
- Les honoraires des médecins sont calculés selon le nombre de jour que leurs patients passent en hospitalisation et leurs tarifs.

Merci d'avance pour votre aide

P.J : MCD Clinique

[JPhi33]

Bonjour,

- Chaque patient est identifié par un matricule.

OK

- Chaque patient doit fournir au service facturation le numéro de la carte d'identité et le téléphone de son tuteur.

KO.
1) cin est un mauvais identifiant. Si le tuteur perd sa carte d'identité (il en aura donc une nouvelle avec un n° différent) il faudra créer un tuteur doublon ou modifier le cin avec toutes les conséquences que cela implique dans la base de données.
2) Chaque patient a un seul tuteur ---> Cardinalités fausses

- Chaque patient peut être hospitaliser plusieurs fois dans des périodes différentes.

KO. Non modélisé.

- Chaque patient doit avancer un montant avant d'être hospitalisé

OK.

- Chaque patient peut subir plusieurs opérations.

KO.
1) Si Opération représente un type d'opération, alors le MCD interdit à un patient de subir plusieurs fois la même opération.
2) Si Opération représente une opération unique, alors les cardinalités sont fausses (côté Opération), les propriété de Subir doivent appartenir à Opération, il manque une entité Type_Opération contenant le libellé et le tarif.

- Chaque patient peut consommer plusieurs médicaments.

KO. Le MCD interdit à un patient de prendre le même médicament à des dates différentes.

- En cas de décès d'un patient ses coordonnées sont enregistrer dans une fiche.

KO. L'entité DECES ne sert à rien.

- Dans la clinique travaille plusieurs médecins en vacation.

OK

- Chaque medecin est identifié par un numéro.

OK

- Chaque patient a un seul medecin traitant.

KO (cardinalités)

- Chaque médecin est payé selon son propre tarif par jour.

KO. Aucune notion de tarif liée au médecin dans le MCD

- Les honoraires des médecins sont calculés selon le nombre de jour que leurs patients passent en hospitalisation et leurs tarifs.

OK mais il n'y avait rien à modéliser en considèrant que le nb de jours d'hospitalisation d'une patient est une propriété calculée.


5 OK, 7 KO ---> 8/20 peut mieux faire

[ziliass]

Bonjour Mr JPhi33,

Merci pour votre réponse.

1-J'ai supprimé l'entité Décès et j'ai ajouté "état", qui va définir l'état de sortie de chaque patient de la clinique.(guéri, mort, en cours de traitement).

2- Pour opération et médicament j'ai ajouté une autre entité Type_médicament et type_opération comme vous me l'avez recommandé, mais je ne sais pas si j'ai utilisé le conseil comme il faut !? .

3 - Est ce que je peux ajouter un attribut "Tarif" dans l'entité médecin pour pouvoir après calculer les honoraires en fonction de la date_début de traitement et la date_fin ?

4-J'ai changé l'identifiant de l'entité Tuteur.

Merci de me dire s'il y a des choses à modifier ou à ajouter.

J'espère que cette fois j'aurai 10/20



P.J: MCD Clinique1

[JPhi33]

Bonjour ziliass,

1-J'ai supprimé l'entité Décès et j'ai ajouté "état", qui va définir l'état de sortie de chaque patient de la clinique.(guéri, mort, en cours de traitement).

C'est un bon principe

2- Pour opération et médicament j'ai ajouté une autre entité Type_médicament et type_opération comme vous me l'avez recommandé, mais je ne sais pas si j'ai utilisé le conseil comme il faut !? .

C'est correct

3 - Est ce que je peux ajouter un attribut "Tarif" dans l'entité médecin

Oui, c'est même la meilleure manière d'associer un tarif à chaque médecin.

pour pouvoir après calculer les honoraires en fonction de la date_début de traitement et la date_fin ?

Cette partie du modèle est incorrecte. L'énoncé dit : "Les honoraires des médecins sont calculés selon le nombre de jour que leurs patients passent en hospitalisation et leurs tarifs." Le calcul à effectuer dépend donc du nombre de jours d'hospitalisation du patient mais attention, on dit aussi "Chaque patient peut être hospitalisé plusieurs fois dans des périodes différentes." et cette règle n'est toujours pas modélisée. Lorsque ce sera fait, on obtiendra la durée d'hospitalisation qui permettra de calculer les honoraires.
En conséquence, les dates figurant dans l'association Traiter sont inutiles. De plus, il y a une erreur sur les cardinalités de cette association (KO n° 6) puisque "Chaque patient a un seul medecin traitant." ce qui invalide la présence des dates dans cette association.

4-J'ai changé l'identifiant de l'entité Tuteur.

OK

J'espère que cette fois j'aurai 10/20

Il reste 2 KO donc on va dire 16/20

[ziliass]

Bonjour JPhi33,

Merci pour votre réponse.

1- J'ai supprimé l'association "Traiter" comme vous me l'avez recommandé, et j'espère que j'ai bien fait pour les cardinalités,

2- J'ai ajouter une entité "Hospitalisation" avec un ID , Date_Début et Date_Fin.

Question :
- Quand on a une association porteuse de données, qui reçoit deux clés étrangères,est ce qu'on peut les considérer comme clés primaires pour cette association?

Merci infiniment pour votre aide.



P.J :MCD Clinique2

[CinePhil]

Je laisse JPhi répondre sur le MCD puisqu'il le connait déjà bien.

Sur ceci :

Question :
- Quand on a une association porteuse de données, qui reçoit deux clés étrangères,est ce qu'on peut les considérer comme clés primaires pour cette association?

Une table issue d'une association (dans le cas de cardinalités maximales n-m ou 1,n) a pour clé primaire composée les identifiants des entités entrant en jeu dans l'association.

Ce n'est donc pas seulement lié au fait qu'une association est porteuse de donnée.

[ziliass]

Bonjour Mr CinePhil,

Merci pour votre réponse.

Un ami m'avais dit que même si elles sont des clés primaires,on peut tout simplement ajouter une autre clé "N_Auto" par exemple pour permettre a une entité d'accepter des doublants de ces clés primaires.
est ce possible??!

Merci

[CinePhil]

Je ne suis pas sûr de comprendre ce que vous suggérez.

Si vous suggérez qu'on peut ajouter une clé primaire auto-incrémentée à une table issue d'une association de type n/m, c'est généralement une mauvaise idée parce qu'il faut alors ajouter une contrainte d'unicité sur la clé composée "naturelle".

Exemple 1 :
Personne -0,n----Participer----0,n- Forum

Les tables qui en découlent doivent être :
Personne (p_id, p_nom, p_prenom...)
Forum (f_id, f_titre...)
Participer (par_id_personne, par_id_forum)

Ici les tables Personne et Forum auront une clé primaire autoincrémentée et la table participer aura pour clé primaire le couple formé par les identifiants des deux tables entrant en jeu dans l'association.

Cependant, ce que je crois avoir compris de votre message peut parfois être utile, même si ce n'est pas forcément la solution optimale.
Exemple 2:
Une commande est composée de 1 à plusieurs produits et un produit peut figurer dans plusieurs commandes.

Le MCD qui découle de la règle de gestion précédente :
Commande -1,n----Composer----0,n- Produit

Les tables :
Commande (c_id, c_numero...)
Produit (pr_id, pr_reference, pr_nom...)
Composer (cp_id_commande, cp_id_produit, cp_quantite...)

Si maintenant on veut gérer les livraisons, pouvant être partielles, des commandes, il faut associer les livraisons aux lignes de commande (le contenu de la table Composer). On peut alors transformer l'association Composer en entité que l'on nommera d'une façon plus claire : ligne_commande. On peut alors lui donner une clé primaire auto-incrémentée qui sera utilisée dans les relations avec les lignes de livraison ou les lignes de facture.

[JPhi33]

Bonjour ziliass,

1- J'ai supprimé l'association "Traiter" comme vous me l'avez recommandé

Pas l'association, seulement les dates. Cette imprécision mise à part, c'est correct.

, et j'espère que j'ai bien fait pour les cardinalités,

OK

2- J'ai ajouté une entité "Hospitalisation" avec un ID , Date_Début et Date_Fin.

C'est conceptuellement approximatif mais ça fonctionne.

[ziliass]

Bonjour,

Merci JPhi33 et CinePhil pour vos réponses et votre aide

Ziliass

[ziliass]

Bonjour CinePhil,
Je reviens vers vous pour cette question :

Envoyé par :CinePhil
Une table issue d'une association (dans le cas de cardinalités maximales n-m ou 1,n) a pour clé primaire composée les identifiants des entités entrant en jeu dans l'association.

Peut -on dire dans ce cas qu'il ne faut pas permettre des doublants pour ces identifiants("personne1" et "forum2" par exemple est ce que la personne1 ne peut pas participer au forum2 plusieurs fois et si je veux avoir le nombre de participations de la personne1 dans le forum2 ) dans cette table? si oui comment?

Envoyé par :CinePhil
Les tables qui en découlent doivent être :
Personne (p_id, p_nom, p_prénom...)
Forum (f_id, f_titre...)
Participer (par_id_personne, par_id_forum)

Ici les tables Personne et Forum auront une clé primaire auto-incrémentée et la table participer aura pour clé primaire le couple formé par les identifiants des deux tables entrant en jeu dans l'association.

Merci

[CinePhil]

Peut -on dire dans ce cas qu'il ne faut pas permettre des doublants pour ces identifiants("personne1" et "forum2"

Si les identifiants de la personne et du forum constituent la clé primaire de la table, l'interdiction de doublons, autrement dit la contrainte d'unicité, sur ce couple sera automatique.

par exemple est ce que la personne1 ne peut pas participer au forum2 plusieurs fois et si je veux avoir le nombre de participations de la personne1 dans le forum2 ) dans cette table? si oui comment?

Mon exemple n'est pas forcément à prendre au pied de la lettre. Plutîot qu'une "participation", il pourrait s'agir d'une inscription à des forums à accès réservé par exemple.
personne -0,n----inscrire----0,n- forum
Dans ce cas, il est logique de n'avoir qu'une seule inscription par personne à un forum.

Ce que tu suggères est plutôt pour le postage de messages dans un forum. On pourrait avoir ceci :
personne -0,n----poster_message---0,n- forum

Auquel cas évidemment une personne pourrait poster plusieurs messages dans un forum, comme nous le faisons allègrement dans cette discussion !
Si on conserve ce schéma, il faudrait alors ajouter par exemple la date de postage à la clé primaire. Le schéma introduirait alors une entité fictive 'Date_heure' et nous aurions une association ternaire :
personne -0,n----poster_message---0,n- forum
date_heure -0,n---------|

Autre exemple avec le même schéma :
Une chaîne de magasins veut savoir dans quels magasins vont ses clients porteur de carte de fidélité.
Client -0,n----Acheter_dans----0,n- Magasin
Date -0,n-------------|

Dans la pratique, pour les forums, on aurait plutôt une entité Message :
Personne -0,n----Poster----1,1- Message -1,1----Situer----0,n- Forum