Gestion d'une pharmacie

**guipe** · 18/04/2010, 19h18

Bonjour tout est dans le titre, je dois réaliser un MCD par rapport à des instructions, ce MCD correspond à la gestion d'une pharmacie !

Voici le texte :

On s'intéresse aux paiements de produits achetés dans une pharmacie par les usagers bénéficiaires
de la sécurité sociale.
Ces usagers sont représentés par les attributs nom, adresse, date de naissance, numéro
d'identification de la sécurité sociale.
S'ils ont une mutuelle, alors on regarde leurs numéros d'adhérent à la mutuelle, les modes de
remboursement. Le remboursement de la part complémentaire par la mutuelle dépend de la
cotisation de chaque usager.
Chaque mutuelle a un nom, et plusieurs centres de gestion. Chaque usager a un seul centre local
pour les remboursements.
Les droits de la mutuelle d'un usager peuvent être changés d'une année a l'autre, en fonction de sa
cotisation.
Sur un produit on voit les informations suivants : nom de produit, classe pharmaceutique, nom de
fabricant, numéro de lot, date d'expiration, et type de remboursement (attribuée par la sécurité
sociale) qui peut être changé dans le temps. Un produit est déterminé par son nom et son numéro de
lot.
Le pourcentage de remboursement d'un produit dépend de sa classe pharmaceutique. Le prix d'un
produit n'est pas fixe, il varie selon les périodes (promotions, augmentation de prix des fabricants,
etc).
L'achat d'un produit remboursable nécessite une ordonnance d'un médecin. Un médecin est
représenté par un nom, une adresse, un numéro d'agrément et une spécialité. Sur une ordonnance on
voit les informations concernant le médecin et le patient, la date de consultation, et une liste de
médicaments avec les prescriptions de traitements. La pharmacie garde une copie de chaque
ordonnance à laquelle est attribué un numéro unique.
D'après la liste de produits sur l'ordonnance, une préparatrice (ou préparateur) de la pharmacie
cherche les produits et établit une facture. Chaque préparateur (ou préparatrice) est représenté(e) par
un nom, une adresse et un numéro d'identication.
Chaque facture a une liste de produits avec leur quantité. Si une facture a des produits
remboursables, alors on distingue la somme à payer par l'usager lui-même, la somme à rembourser
par la sécurité sociale et la somme à rembourser par la mutuelle.
Dans ce cas les copies de l'ordonnance et de la facture sont envoyées au centre de gestion de
remboursement de l'usager. Les remboursements effectifs doivent être suivis et vérifiées. Par
ailleurs, on considère que les usagers bénéficiaires de la sécurité sociale doivent y contribuer pour
chaque produit remboursable, en versant par exemple un euro, dans la limite de cinquante euros par
an.
Un traitement prescrit sur une ordonnance est valable pour un nombre précis de fois, donc une
ordonnance peut donner lieu à une ou plusieurs factures. Chaque facture a une date d'achat et un
numéro d'identification.

Voici mon MCD que j'ai mis en archive rar, j'aimerai avoir votre avis:
J'ai différents problèmes, j'ai mis en gras dans le texte ce que j'ai du mal à modéliser. Notamment si j'ai besoin d'une table SECURITE SOCIALE et tout ce qui est gestion des remboursements par la mutuelle et la secu,le prix du produit ....

J'ai vraiment besoin de votre aide !
Merci!

**f-leb** · 19/04/2010, 21h36

Bonsoir,

Comme l’énoncé est un peu long, je me suis arrêté à la première partie : usager-mutuelle-centre.
Je propose le schéma suivant :

Le triangle avec son lien orienté entre UsagerMutuelle et Personne traduit la notion d’héritage :
Un UsagerMutuelle est une Personne, une Personne peut être est un UsagerMutuelle.

Un usager à un centre local de gestion et cotise tous les ans (MontantCotisation).
A mon avis les droits résultent plus d’un calcul selon le montant de la cotisation, il s’agit d’un traitement à part. Je supprimerais donc cet attribut "droits" du MCD.

Tu noteras l’identification du Centre relativement à la Mutuelle (cardinalité 1,1 avec le (R) )

MLD :

Voila pour moi ce soir…

**guipe** · 19/04/2010, 22h09

Je n'ai pas vu la notion d'héritage donc je ne peux l'utiliser !

Je pense que la cardinalité 0,n entre Usagers et Mutuelle suffira à montrer que l'usager n'a pas forcément de mutuelle.

Les problèmes qui me restent sont dois-je faire une table sécurité sociale?

Et comment gérer les remboursements de la part de la secu et de la mutuelle

J'ai actualisé mon schéma sur le premier post.

J'espère que tu continueras à m'aider ! Merci beaucoup !

**f-leb** · 20/04/2010, 19h42

Bonsoir guipe,

je reviens tout de même sur la 1ère partie : Usager-Mutuelle-Centre

Il va falloir en effet tenir compte de certaines contraintes dans l’implémentation car en l’état de ton MCD:
- Rien n’empêche à un usager de cotiser même s’il bénéficie d’aucune mutuelle
- Rien n’empêche de saisir un centre à un usager qui ne bénéficie pas de mutuelle, voire pire, un adhérent pourrait se faire rembourser dans un centre d’une mutuelle alors qu’il cotise dans une autre

…

On devrait pouvoir y remédier en modélisant autrement.

Usager----0,1---EtreAdherent---1,1---AdherentMutuelle

Un adhérent de mutuelle est un usager, un usager peut être un adhérent d’une mutuelle

AdherentMutuelle---1,n---cotiser(montant)---0,n---AnneeCotisation

Il s’agit dans l’énoncé de la cotisation pour la mutuelle.

AdherentMutuelle---1,1---rembourser---0,n---CentreGestion---1,1---dependre---0,n---Mutuelle

A priori, il n’est pas utile d’associer AdherentMutuelle à Mutuelle. Connaissant son centre de gestion, on remonte à la mutuelle dont dépend le centre.

Si tu connais le principe d’identification relative, je verrais même :
CentreGestion---1,1(R)---dependre---0,n---Mutuelle

Par la suite,

Le pourcentage de remboursement d'un produit dépend de sa classe pharmaceutique.

Il est donc temps de créer une entité ClassePharma(idClassePharma, NomClassePharma, PourcentageRembourst).
Produit---1,1---AvoirClasse---0,n---ClassePharma

Le prix d'un produit n'est pas fixe, il varie selon les périodes…

Ici l’énoncé n’est pas très précis. On peut simplement rajouter un attribut PrixArticle dans l’entité Article et on se contente des mises à jour de la colonne au gré des périodes (il faudra probablement rajouter quelque part dans la partie facturation que je n’ai pas encore lue un attribut PrixProduitFacturé).

Si on soupçonne l’auteur de l’énoncé de vouloir un historique de ces mises à jour, on peut rajouter :
Produit----0,n----historiserPrix(PrixArticleHisto)---0,n---DateChangementPrix

Je crois qu’il y a une question sur la modélisation des historiques dans la FAQ Merise (comme sur les notions d’héritage et d’identification relative d’ailleurs).

…et type de remboursement (attribuée par la sécurité sociale) qui peut être changé dans le temps.

Même principe que pour les prix je suppose.

Bon, je regarde le reste (j’avance pas vite hein ?)….

Note : pour faire tes MCD, tu peux utiliser Open ModelSphere qui est assez convivial et gratuit en plus (Win’design est plus complet mais dans la version démo que j’ai utilisé dans mon message précédent, on ne peut pas sauvegarder le MCD arghhh

)

**fsmrel** · 21/04/2010, 01h21

Quelques tuyaux concernant Open ModelSphere, quant à l’héritage et autres joyeusetés.

Voyez les discussions avec dxerty ou avec Locus51.

**guipe** · 21/04/2010, 08h00

Merci !

Pour les attributs tels que id_usager,id_mutuelle ....

Ce sont des AUTO INCREMENT et pas nécessairement des clés primaires non?

Si oui comment faire pour définir des AUTO INCREMENT dans OpenModelSphere !

**guipe** · 21/04/2010, 14h23

J'ai vu aussi qu'il y avait des clés alternatives:

Les clés alternatives sont des combinaisons d'une ou plusieurs attributs qui permettent d'identifier les occurrences d'une entité autrement que par la clé primaire.

Donc dans mon cas pour id_usager,id_mutuelle, c'est plus simple de les définir en AUTO INCREMENT car comme ceci les lignes sont obligatoirement différenciées!

Donc ce que je peux faire c'est mettre tous mes id_... en PK AUTO INCREMENT et ensuite de définir des clés alternatives.

Par exemple dans le cas de Produit:Il est dit qu'un produit est défini par son nom et son numéro de lot.
Donc je fais id_produit en PK AUTO INCREMENT puis (nom,numero_lot) en clés alternatives ?

Si tu pouvais m'éclairer sur ça aussi.Merci encore !

Il faudrait que j'arrive à finaliser mon MCD d'ici ce week end. Il est pas mal avancé.Ce serait vraiment génial ! Merci !

J'ai d'autres doutes aussi.Concernant type_remboursement(attribué par la secu) et pourcentage_remboursement.

Je vois pas l'intéret de type_remboursement, c'est quoi, une chaine de caractères ? A quoi va t-elle servir ?

Puis une autre question :

On considère que les usagers bénéficiaires de la sécurité sociale doivent y contribuer pour
chaque produit remboursable, en versant par exemple un euro, dans la limite de cinquante euros par
an.

La c'est flou pour moi aussi !

Et puis toutes les histoires de si la facture a des produits remboursables....

Bref dur dur pour un débutant je trouve !

Tu dis que tu n'avances pas vite mais si, tu m'aides beaucoup !

**fsmrel** · 22/04/2010, 03h34

Bonsoir,

Envoyé par guipe

Pour les attributs tels que id_usager, id_mutuelle ....

Ce sont des AUTO INCREMENT et pas nécessairement des clés primaires non?

Si oui comment faire pour définir des AUTO INCREMENT dans Open ModelSphere !

Ne faites pas d’amalgame !

Avant de commenter, je commencerai par quelques définitions de concepts.

Tout d’abord, le concept de clé primaire est un cas particulier du concept de clé candidate (ou plus simplement clé).

Dans ce qui suit, quand je parle de variable relationnelle (en abrégé relvar), j’utilise le terme utilisé dans la théorie relationnelle. Vous pouvez traduire par table dans le contexte SQL.
Toujours dans le cadre de la théorie relationnelle (pour laquelle le concept de clé primaire n’existe pas), une clé candidate est définie de la façon suivante :

Une clé candidate (clé en abrégé) est un sous-ensemble d’attributs K de l’en-tête d’une relvar R, respectant les deux contraintes suivantes :

Unicité. Deux tuples distincts de R ne peuvent avoir même valeur de K.
Irréductibilité (ou minimalité). Il n’existe pas de sous-ensemble strict de K garantissant la règle d’unicité.

Toujours concernant la terminologie, le tuple (ou n-uplet) de la théorie relationnelle a pour homologue la ligne en SQL. L’en-tête d’une relvar correspond à la liste de colonnes d’une table SQL (ou des propriétés d'une entité-type en Merise).

Et surtout, ne perdez pas de vue qu’avec la théorie relationnelle on raisonne sur des ensembles : une relvar est une variable dont les valeurs successives sont des relations (au sens ensembliste et pas merisien), et les éléments d’une relation sont ses tuples. De même, l’en-tête d’une relvar R (ou d’une relation) est un ensemble (toujours au sens de la théorie des ensembles) dont les éléments sont les attributs de R.

Considérons maintenant l’entité-type USAGER. Lors du passage au MLD, cette entité-type fera l’objet d’une table SQL. Le singleton {Id_Usager} (ou {PersonneId} dans le MCD que je propose) sera clé candidate de la table USAGER, car ce sous-ensemble répond aux contraintes d’unicité et d’irréductibilité des clés. Même chose pour le singleton {NumeroSecu}. Un triplet tel que {Nom de la personne, Adresse, DateNaissance} n’est pas clé, sinon on ne pourrait pas avoir de jumeaux demeurant sous le même toit. Pour la petite histoire, le quadruplet {Nom de la personne, Prenom, AdresseUsager, DateNaissance} aurait une meilleure chance de constituer une clé.

Venons-en au concept de clé primaire parce qu’il fait partie de la culture SQL, même si ontologiquement il n’a aucune justification. Disons que parmi l’ensemble des clés candidates d'une table, on en retiendra une pour jouer ce rôle de clé primaire et faire plaisir à SQL.

Comme dit Yves Tabourier dans son remarquable ouvrage De l’autre côté de MERISE (Les Éditions d’organisation, 1986) :

« ... la fonction d’une propriété est de décrire les objets (et les rencontres), alors que l’identifiant ne décrit rien. Son rôle fondamental est d’être sûr de distinguer deux jumeaux parfaits, malgré des descriptions identiques.
L’expérience montre d’ailleurs que l’usage des “identifiants significatifs” (ou “codes significatifs”) a pu provoquer des dégâts tellement coûteux que la sagesse est d’éviter avec le plus grand soin de construire des identifiants décrivant les objets ou, pis encore, leurs liens avec d’autres objets... »

Autrement dit, parmi l’ensemble des clés candidates il doit en exister une sur laquelle l’utilisateur n’a aucun pouvoir, elle doit être d’une stabilité à toute épreuve et n'avoir absolument aucune signification. Il ne s’agit pas d’un caprice, il y va de la stabilité de la base de données. Disons que la clé primaire d’une table a pour objet de répondre au voeu de Tabourier, du fait de sa stabilité à toute épreuve et de l'absence totale d'information qu'elle porte en théorie.

Consciemment ou non, un peu comme M. Jourdain faisait de la prose, vous avez mis en œuvre un attribut Id_Usager, lequel ne correspond à aucune propriété naturelle de l’entité-type USAGER, mais est bien un attribut artificiel dont la finalité est d’être l’identifiant de l’entité-type USAGER, donc de donner lieu à la clé primaire {Id_Usager}.

Quand on descend dans la soute, se pose maintenant le problème de l’affectation des valeurs de cette clé primaire : il y a un certain nombre de solutions techniques, dont l’une d’elles est l’auto-incrémentation proposée par certains SGBD, qui est une variation sur le thème : la prochaine valeur prise par la clé primaire de la table T sera la plus grande valeur actuelle de la clé, augmentée d’une unité. Personnellement je n’utilise pas la technique de l’auto-incrément, mais à chacun ses habitudes.

Open ModelSphere ne prévoit pas la génération du paramètre AUTO INCREMENT puisque c’est une affaire d’épicerie propre à tel ou tel SGBD. Si vous y tenez vraiment, vous l’ajouterez manuellement ou bien vous ferez par exemple une rétro-conception du code SQL généré (les instructions CREATE TABLE) au moyen de MySQL Workbench (encore un gratuit !) qui permet de générer automatiquement ce paramètre.

Je vous laisse maintenant le soin de répondre vous-même à la question que vous posez.

Envoyé par guipe

J'ai vu aussi qu'il y avait des clés alternatives.

Ce sont donc les clés candidates qui n’ont pas été jugées dignes d’être retenues pour être miss clé (primaire), cas par exemple de la paire {NomProduit, NumeroLot} pour la table PRODUIT. Ces clés alternatives correspondent aux clés connues de l’utilisateur : La clé primaire (artificielle) ne doit pas être connue de l’utilisateur et lors des manipulations elle ne servira qu’à effectuer les jointures entre tables.

Voici par ailleurs un exemple de MCD vite fait sur le gaz, donc non garanti :

A noter :

USAGER, MEDECIN et PREPARATEUR sont des spécialisations de PERSONNE.

{NumeroSecu} est une clé alternative pour USAGER, visuellement : cf. le mickey <1>.

Un adhérent est un usager, mais un usager n’est pas forcément un usager, d’où la spécialisation ADHERENT. L’attribut NoAdherent participe à une clé alternative {MutuelleId, NoAdherent}. D’après le MCD, cette clé serait le triplet {MutuelleId, CentreId, NoAdherent}, mais on fait ce qu’on peut avec ce qu’on a : c’est au niveau du MLD que l’on réduira le triplet à la paire.

COTISATION est identifiée relativement à ADHERENT. La clé en est {PersonneId, DateEffet} En toute rigueur, on aurait dû mettre en œuvre un attribut CotisationId et avoir une clé primaire {PersonneId, CotisationId}, {PersonneId, DateEffet} devenant clé alternative. mais COTISATION est « en bout de chaîne » et on peut se permettre cette entorse : une modification de date est sans conséquence.

En toute rigueur, ORDONNANCE est une association entre USAGER, MEDECIN, DATE, mais on vous a collé un numéro d’ordonnance. Il n’en demeure pas moins que si un usager se fait faire au plus une ordonnance par jour par un médecin, le triplet {PersonneUsagerId, PersonneMedecinId, DateConsultation} est clé alternative (voyez les mickeys <1>). Mais libre à vous de ne pas tenir compte de cette règle non précisée.

PRESCRIPTION est une association entre ORDONNANCE et PRODUIT, mais à cause de FACTURE on la déguise en entité-type identifiée relativement à ORDONNANCE et PRODUIT.

Important : le MCD permet qu’on facture un produit qui n’a pas été prescrit. En Merise/2, on définirait une contrainte de simultanéité entre les associations-types Concerne et Refere. Any way : au niveau SQL on supprimera un des deux attributs ProduitId (résultant de la propagation de cet attribut du fait de l’identification relative) dans la table LIGNE_FACTURE. Je vous expliquerai comment préserver l’intégrité référentielle et garantir la contrainte de simultanéité.

Concernant le type de remboursement, on manque effectivement d’informations. En attendant, vous pouvez toujours définir une entité-type ad-hoc, avec une date d’effet, un libellé descriptif et un attribut valeur, des fois que l’on ait affaire à un nombre...

Ligne de facture : on a le sentiment qu’on demande de faire figurer sur la ligne la part payée par chaque partie : usager, sécu, mutuelle. Ce sont des données calculées sue la base du prix figurant sur la ligne de facture (attribut Prix Facturé), donc déductibles de règles fixées par le spoliateur en chef et qui n’ont donc pas à figurer dans le MCD mais dans la partie programmée, à moins qu’on vous demande de faire figurer les pourcentages correspondants. Pour le moment vous les envoyez paître (à moins que vous ne vouliez vous acharner...).

L’histoire des euros limités à 50, c’est pour vous impressionner. En fait, vous avez toutes les informations dans le MCD pour savoir combien un usager a dépensé chez le pharmacien. Je suppose que tant que le plafond des 50 euros n’a pas été atteint, on affichera sue la facture : « spoliation sécu de 1 euro... ». Là où ça deviendrait intéressant, c’est si la barre de 50 euros correspondait à une limite à ne pas dépasser non pas chez un seul, mais chez tous les pharmaciens chez qui on a fait ses courses dans le pays.

**guipe** · 22/04/2010, 10h56

Merci beaucoup donc si j'ai bien compris il faut que dans ma table il y ait au moins un attribut indépendant de la connaissance de l'utilisateur, c'est la clé primaire et elle peut être en AUTO INCREMENT.Les autres clés n'ayant pas été prises en compte sont les clés alternatives qui peuvent elle,être connues par l'utilisateur.

Pourquoi dans ORDONNANCE à l'image de FACTURE, on n'a pas rajouté un Id_ordonnance?Et ne faut-il pas rajouter un attribut dans ordonance qui permet de voir pour combien de factures l'ordonnance est valable ?

Pour la table TYPE REMBOURSEMENT, ne faudrait-il pas juste un booléen pour dire si le produit est remboursable ou non?

Et dans ce cas ne manque t-il pas une association ENVOYER entre (ordonnance,facture) et CENTRES comme c'est marqué en fin de l'énoncé ?

Je n'ai pas très bien compris non plus le rôle de PRESCRIPTION.

PS: Pourrais-tu éditer ton message pour qu'on ne puisse plus voir le MCD.Juste pour une question de confidentialité.Je l'ai enregistré.Ce serait vraiment sympa !

La je commence à faire le MRD pour voir ce que ça donne !

**guipe** · 22/04/2010, 16h06

Je l'ai fait manuellement mais je n'arrive pas à le faire sur le logiciel.

J'ai voulu faire moi même le MCD pour pouvoir ensuite générer le MRD mais je n'arrive pas à faire les associations.Enfin j'arrive à lier deux tables mais je ne sais pas comment mettre la sorte de bulle ou est marqué le nom de l'association.

**fsmrel** · 22/04/2010, 18h46

Bonsoir,

Envoyé par guipe

Les attributs comme par exemple numero_agrement dans Medecin sont des clés primaires ?

Non. Lors de la dérivation, l’AGL produit le MLD suivant :

Et le mickey <1> signifie que {NumeroAgrement} est clé alternative, tandis {PersonneId} est clé primaire. Noter l’emploi des accolades : en effet une clé est un ensemble.

Envoyé par guipe

Si j'ai bien compris il faut que dans ma table il y ait au moins un attribut indépendant de la connaissance de l'utilisateur, c'est la clé primaire et elle peut être en AUTO INCREMENT.

Considérez le MCD suivant (Open ModelSphere), selon lequel des fournisseurs fournissent des produits selon une certaine quantité :

Et le MLD produit par l’AGL :

Concernant la table FOURNISSEUR, les attributs NumeroSiret et FournisseurNom représentent respectivement le numéro Siret du fournisseur et son nom, c'est-à-dire les propriétés naturelles de l’entité-type FOURNISSEUR figurant dans le MCD. Or les numéros Siret sont attribués par l’INSEE, qui régulièrement met à jour les numéros erronés qu'il faut donc à remplacer dans les bases de données : à nous de faire en sorte que l’impact soit le plus faible possible, en évitant par exemple de faire de ce numéro une clé primaire se propageant dans nombre de tables sous la forme de clés étrangères.

Le bon réflexe est donc de faire de {NumeroSiret} une clé alternative et de mettre en œuvre une clé primaire {FournisseurId}, FournisseurId étant un attribut purement factice mais invariant et sans signification. Du point de vue de sa valorisation, libre à vous d’utiliser l’auto-incrémentation ou tout autre moyen permettant de garantir l’unicité des lignes de la table FOURNISSEUR.

Maintenant, quand vous écrivez « il faut que dans ma table il y ait au moins un attribut indépendant de la connaissance de l'utilisateur, c'est la clé primaire », on peut dire que cela est vrai des entités-types dites « fortes », celles qui ne dépendent d’aucune autre et ont leur autonomie propre telles que FOURNISSEUR et PRODUIT. Cela ne vaut pas pour une table telle que FOURNIR, que l’on peut qualifier d’associative et traduit dans le MCD une association-type entre FOURNISSEUR et PRODUIT. En effet, la table FOURNIR a pour clé primaire la paire {ProduitId, FournisseurId} dont les éléments ProduitId et FournisseurId sont déjà des attributs artificiels, inconnus de l’utilisateur. Si celui-ci a besoin de connaître la quantité de tel produit fourni par tel fournisseur, il lui suffit de proposer un numéro Siret et un code EAN13.

Du point de vue SQL, on écrira :

Code SQL :

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

1
2
3
4
5
6
7
8
SELECT y.Quantité
FROM        PRODUIT AS x 
       JOIN FOURNIR AS y
              ON x.ProduitId = y.ProduitId
       JOIN FOURNISSEUR AS z
              ON y.FournisseurId = z.FournisseurId
WHERE  x.EAN13 = '1234567890123'
  AND  z.NumeroSiret = '98765423109876' ;

Envoyé par guipe

Les autres clés n'ayant pas été prises en compte sont les clés alternatives qui peuvent, elles, être connues par l'utilisateur.

Non seulement elles peuvent, mais elles doivent, puisqu’elles représentent les points d’entrée de l’utilisateur dans le système, par exemple le numéro Siret de l’entreprise, le code EAN13 du produit, le numéro de sécurité sociale de l’usager, le numéro ADELI du médecin, etc.

Envoyé par guipe

Pourquoi dans ORDONNANCE à l'image de FACTURE, on n'a pas rajouté un Id_ordonnance?

Disons que l’utilisateur a le plus souvent une idée sur la façon dont le numéro des factures doit être structuré, auquel cas il est d’usage d’en faire une clé alternative. Si l’utilisateur s’en remet à vous et n’a aucune prétention à influencer la valorisation du numéro de facture, vous pouvez en faire une clé primaire puisque c’est vous qui en aurez la maîtrise (donc vous pourrez utiliser l’auto-incrémentation puisqu’elle vous tien tant à cœur), et supprimer l’attribut FactureId devenu inutile. Si un jour le potard en chef impose la façon de valoriser ce numéro, vous renommerez FactureNumero en FactureId et ajouterez un attribut FactureNo à l’usage de l’utilisateur. Mais quelques requêtes SQL seront à revoir...

Il en va du numéro d’ordonnance comme du numéro de facture : si le potard en chef vous laisse le soin d’attribuer les numéros d’ordonnance, vous en avez la maîtrise, et NoOrdonnance est un attribut artificiel sans signification, invariant, propre à jouer le rôle de clé primaire. Il est alors inutile d’ajouter un 2e attribut artificiel, à savoir OrdonnanceId, sauf si bien sûr le chef se pique de maîtriser la structure et la valorisation de NoOrdonnance.

Envoyé par guipe

Je n'ai pas très bien compris non plus le rôle de PRESCRIPTION.

Dans l’énoncé, on lit ceci : Sur une ordonnance on voit les informations concernant le médecin et le patient, la date de consultation, et une liste de médicaments avec les prescriptions de traitements. »
Si donc un médicament est un produit, on est amené à établir une association entre les entités-types ORDONNANCE et PRODUIT, association de type N,N que l’on peut appeler PRESCRIPTION (et peut être porteuse de propriétés). Mais à une prescription correspondront des factures et il faudrait établir une association entre l’entité-type FACTURE et l’association-type PRESCRIPTION, ce que les AGL orientés Merise se refusent à faire : on est obligé de déguiser PRESCRIPTION en entité-type (disons associative...), ce que j’ai fait.

Envoyé par guipe

Ne faut-il pas rajouter un attribut dans ordonnance qui permet de voir pour combien de factures l'ordonnance est valable ?

Oui, ajoutons un attribut en ce sens.

Envoyé par guipe

Pour la table TYPE REMBOURSEMENT, ne faudrait-il pas juste un booléen pour dire si le produit est remboursable ou non?

Pourquoi pas, et l’attribut Valeur correspond à cela, en ce sens qu’on peut lui donner la signification : Si Valeur = 0 alors le produit n’est pas remboursable. Maintenant, on peut prévoir trois attributs : pourcentage à appliquer au montant remboursé par la sécu, pourcentage à appliquer au montant remboursé par la mutuelle et pourcentage à appliquer au montant à régler par l’usager.

Envoyé par guipe

Et dans ce cas ne manque t-il pas une association ENVOYER entre (ordonnance, facture) et CENTRES comme c'est marqué en fin de l'énoncé ?

Créer une association-type, non. En effet, connaissant la facture, on connaît l’ordonnance (une facture détermine exactement une ordonnance), donc l’usager (une ordonnance détermine exactement un usager), donc la mutuelle (un usager détermine exactement une mutuelle). Par contre, dans l’état du MCD, on ne sait pas si l’envoi des copies des documents a été effectué (et à quelle date tant qu’à faire). En conséquence, vous pouvez prévoir un attribut DateEnvoiMutuelle pour l’entité-type ORDONNANCE et pour l’entité-type FACTURE. Ou, comme ces données sont facultatives (tout le monde n’a pas une mutuelle), prévoir une entité-type « appendice » attachée à ORDONNANCE et une autre attachée à FACTURE. par exemple :

Envoyé par guipe

Pourrais-tu éditer ton message pour qu'on ne puisse plus voir le MCD. Juste pour une question de confidentialité. Je l'ai enregistré. Ce serait vraiment sympa !

L’objet du forum est que tous puissent retirer du profit à étudier les discussions. Si je supprime le MCD, nos échanges deviennent pratiquement inintelligibles. Je vais voir comment saucissonner le MCD et ne pas faire tout figurer.

**guipe** · 22/04/2010, 20h17

Merci pour tes réponses.

Une dernière chose.

Une clé alternative n'est donc pas différenciée lors de la création de mes tables?

On les définit comme des attributs normaux ?

**fsmrel** · 22/04/2010, 20h17

Envoyé par guipe

J'ai voulu faire moi même le MCD pour pouvoir ensuite générer le MRD mais je n'arrive pas à faire les associations.

Vous n'arrivez pas à établir d'association entre deux entités-types du MCD ?

**guipe** · 22/04/2010, 20h29

Oui,j'arrive à faire le trait entre les 2 mais pas à créer la bulle avec le nom de l'association !

Et quand tu parles de ça :

Pourquoi pas, et l’attribut Valeur correspond à cela, en ce sens qu’on peut lui donner la signification : Si Valeur = 0 alors le produit n’est pas remboursable. Maintenant, on peut prévoir trois attributs : pourcentage à appliquer au montant remboursé par la sécu, pourcentage à appliquer au montant remboursé par la mutuelle et pourcentage à appliquer au montant à régler par l’usager.

Les 3 attributs sont des attributs de chaine de caractère ?

Car on a déjà le taux de remboursement d'un produit par la secu dans l'entité Classe.

**fsmrel** · 22/04/2010, 20h51

Envoyé par guipe

Oui, j'arrive à faire le trait entre les 2 mais pas à créer la bulle avec le nom de l'association !

Sans doute êtes-vous en train de construire un MLD plutôt qu'un MCD.

Pour créer un MCD :

Fichier > Nouveau modèle > Créer un nouveau modèle > Modèle de données > Modèle conceptuel de données > Choisir un formalisme : Entité Association

Ce qui fait apparaître ceci :

Une fois dans le diagramme, pour créer une association, utiliser l’icône « Création d’associations » (drag/drop de Client vers Order pour reprendre l’exemple ci-dessus).