Discussion :

[pachou8]

Salut!
Je suis nouveau ici, alors, j’espère que vous ne serez pas trop dur avec mon titre et que vous allez m'aider sur le mcd d'un hôpital. C'est un peut large, alors, je vais me centrer sur les entités concernées. Je vous remercie à l'avance!

J'ai 3 entités:
patient (id_patient, nom, naissance,etc)
analyse_medicale(id_analyse, description,etc)
test_medical(id_test, description_test, valeurs_normales,etc)

- Un patient peut effectuer un ou plusieurs analyses et une analyse peut être effectuée par un ou plusieurs patients
- dans une analyse, on peut rencontrer un ou plusieurs tests médicaux mais, un test concerne une et une seule analyse

Mon problème survient lorsque je veux considérer les résultats des analyses effectuées par un patient. J'ai fait le petit schema suivant:



Mon problème c'est que ça boucle et j'ai appris qu'il n'est pas conseillé quand on modélise.
J'ai essayé avec une entité pour les résultats: resultat_analyse(id_resultat, valeurs_normales). Non seulement j'ai toujours une boucle mais, j'ai aussi eu une relation fantôme entre resultat_analyse et test_medical. Je voudrais savoir si le fait de continuer ainsi va poser problème, si je passe nettement à côté ou si quelqu'un aurait une meilleure idée.

[fsmrel]

Bonjour pachou8,

j’espère que vous ne serez pas trop dur avec mon titre et que vous allez m'aider sur le mcd d'un hôpital.

Rassurez-vous, vous êtes ici à l’hôpital des MCD

La boucle vous tracasse... Traduisons cela ainsi : selon votre MCD, si le patient <Pj> fait l’objet du type d’analyse <Ai> et du test de type <Tk>, rien n’interdit que <Tk> relève du type d’analyse <Ah> différent de <Ai> et ne concerne donc aucunement ce malheureux patient qui n’a pas jamais l’objet de <Ah> (ou s’il l’a fait, c’est pour un test <Tk’> qui n’a rien à voir avec son analyse <Ai> : ça devient la grande salade...)

Est-ce bien ainsi qu’il faut interpréter votre problème ?

Si oui, pour garantir que le test de type <Tk> relatif au patient <Pj> concerne bien l’analyse de type <Ai> à laquelle a été soumis <Pj>, on peut mettre en œuvre ce qu’on appelle une contrainte d’inclusion :

Si I est l’ensemble (au sens de la théorie des ensembles) résultant de l’opération de composition ayant pour opérandes les ensembles représentés par les relations CONCERNER et EFFECTUER, alors I doit être inclus dans l’ensemble inféré de la relation EFFECTUER.

Graphiquement :




Bon, ça nous fait une belle jambe, car nous n’avons ni vous ni moi l’AGL permettant de produire de façon mécanique les tables SQL telles que la contrainte d'inclusion soit automatiquement assurée...

Rassurez-vous, on arrivera à produire ces tables. Avant cela, quelques précisions à apporter :

(1) Soit <Ai> un type d’analyse dont le patient <Pj> fait l’objet. <Pj> peut-il être soumis plus d’une fois à <Ai> ?

(2) Pour une paire <Pj, Ai> donnée, peut-on avoir plus d’un test ?

[pachou8]

Bonsoir fsmrel, et merci pour votre réponse!
Je suis désolé pour mon retard, c'est difficile pour moi d’être ici le week-end...
Vous venez de me montrer une nouvelle faille dans mon mcd et c'est vraiment le bazar... Et, vous avez également cerné ce que je veux faire:

Quelque soit le test concernant un patient, ce test doit relever de l'analyse a laquelle a été soumis ce patient

.

Pour les précisions, c'est oui pour les deux questions. Et je rappelle aussi qu'un test ne peut se trouver que dans une seule analyse.
Merci encore!

[fsmrel]

Bonsoir Pachou,

Je suis désolé pour mon retard, c'est difficile pour moi d’être ici le week-end...

Ne soyez pas désolé, le week-end est fait pour que vous puissiez vous changer les idées...


Pour en venir à votre diagramme : j’utilise ici PowerAMC, mais je ne sais pas si l’outil que vous utilisez vous permettra d’arriver au même résultat. Quoi qu’il en soit, la contrainte d’inclusion est représentée sous forme de cercle, ce qui incite à mettre en œuvre une association entre les associations EFFECTUER et CONCERNER. Certains auteurs ont — à juste titre — franchi le pas, mais en Merise classique, on ne fait pas ça (hélas !)

On va donc tricher un peu, mais en tout bien tout honneur, c'est-à-dire qu’on va déguiser ces associations en entités-types, ce dont ne s’offusque pas PowerAMC (je rappelle en passant que l’AGL ne sait pas ce qu’est une contrainte d’inclusion, c’est pourquoi j’avais surchargé le diagramme à l’aide de PAINT) :




Vous observerez que certaines cardinalités 1,1 sont mises entre parenthèses, cas par exemple de la cardinalité 1,1 portée par la patte connectant EFFECTUER et EFF_PAT : ceci a été réalisé automatiquement par l’AGL quand je lui ai demandé (par un clic à la souris) de transformer l’association EFFECTUER en entité-type, et ça a un sens précis : l’entité-type EFFECTUER est désormais identifiée relativement à PATIENT, comme elle l’est du reste relativement à ANALYSE pour des raisons de symétrie évidentes : contrairement aux entités-types PATIENT, ANALYSE et TEST, EFFECTUER n’a pas d’identifiant propre, elle hérite d’office des identifiants de PATIENT et ANALYSE, ce qu’on voit parfaitement dans le MLD dérivé automatiquement par l’AGL :




Dans le MCD, on est maintenant en droit de remplacer la contrainte d’inclusion par une association, mais cette fois-ci à l’aide de l’AGL, puisqu’on est dans l’orthodoxie (en souvenir, on garde la trace du lien entre EFF_CON et POSSEDER) :




Pour des raisons de commodité, je renomme les entités-types et les associations :



Une règle de gestion dit qu’un test relatif à un patient fait référence à au moins et au plus une analyse faite pour ce patient, la cardinalité portée par la patte connectant TEST et TEST_ANA est donc 1,1, et même (1,1), car si une analyse peut comporter plusieurs tests, un test n’est jamais qu’une propriété multivaluée d’une analyse :




On se rend compte qu’à partir de l’entité-type TEST, on a maintenant deux chemins pour savoir quel est le patient concerné :

1) Via l’association TEST_PAT ;

2) Via l’association TEST_ANA, puis l’entité-type ANALYSE, puis l’association ANA_PAT.

Il y a donc redondance et il faut ne conserver qu’un chemin, sinon rien n’interdirait de mélanger les tests et analyses des patients. Comme on a eu assez de mal à brancher TEST su ANALYSE, on va donc passer TEST_PAT au rasoir d’Ockham. Le MCD devient :





MLD proposé par l’AGL :



Cette fois-ci, le diagramme montre qu’un test fait référence à une seule analyse, donc à un seul patient. Mais un risque subsiste, celui d’associer le test T1 de l’analyse A1 du patient P1 avec une analyse A2 qui ne le concerne pas :


TYPE_ANALYSE

Code :

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

1
2
3
4
IdTypeAnalyse    DescriptionAnalyse
-------------
            1    descr 1
            2    descr 2

TYPE_TEST

Code :

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

1
2
3
4
IdTypeTest    IdTypeAnalyse    ValeurNormale
----------
         1                1    vn1
         2                2    vn2

PATIENT

Code :

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

1
2
3
IdPatient    NomPatient
---------
        1    Raoul

ANALYSE

Code :

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

1
2
3
4
IdPatient    IdTypeAnalyse    DatePrelevement
---------    -------------
        1                1    dp1
        1                2    dp2

TEST

Code :

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

1
2
3
4
IdPatient    IdTypeAnalyse    IdTypeTest    DateResultat    ValeurTest
---------    -------------    ----------
        1                1             1    dt1             vt1
        1                1             2    dt2             vt2

Les lignes de la table TEST sont conformes au modèle, et pourtant la 2e ligne contient la valeur <1, 2> pour la paire {IdTypeAnalyse, IdTypeTest}, alors que cette paire est illégale car absente de la table TYPE_TEST. Pour être sûr de rester dans la légalité, il faudrait que la paire {IdTypeAnalyse, IdTypeTest} de l’en-tête de la table TEST fasse référence à la paire {IdTypeAnalyse, IdTypeTest} de l’en-tête de la table TYPE_TEST : qu’à cela ne tienne, allons-y ! On serait en relationnel pur, avec un langage de type D, on déclarerait la contrainte qui va bien, mais nos SGBD SQL nous imposent plutôt d’en passer par des triggers : on va éviter et tenir le raisonnement suivant :

Un type de test n’a de sens qu’en association avec un type d’analyse, il en est même une propriété multivaluée (comme un ligne de facture est une propriété multivaluée d’une facture) : TYPE_TEST est une entité-type faible (weak entity chez Chen) relativement à TYPE_ANALYSE. On va donc mettre en œuvre l’identification relative :

[TYPE_ANALYSE]----1,N--------(POSSEDER)--------(1,1)----[TEST]

En conséquence de quoi une analyse se compose de tests tout comme une facture se compose de lignes de facture :

TYPE_ANALYSE

Code :

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

1
2
3
4
IdTypeAnalyse    DescriptionAnalyse
-------------
            1    descr 1
            2    descr 2

TYPE_TEST

Code :

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

1
2
3
4
5
6
7
8
9
IdTypeAnalyse    IdTypeTest    ValeurNormale
-------------    ----------
            1             1    vn11
            1             2    vn12
            1             3    vn13

            2             1    vn21
            2             2    vn22
            2             3    vn23

Disons que la numérotation des types de test commence à 1 pour chaque type d’analyse.

Dans ces conditions, le MCD devient :




MCD que l’on peut simplifier ainsi (ce qu’on aurait du reste pu faire dès la figure 6, du fait de l’élimination de l’association TEST_PAT) :





MLD proposé par PowerAMC




Où l’on observe que l’en-tête de la table TEST comporte les colonnes suivantes :

— IdTypeAnalyse, héritée de ANALYSE,

— TYP_IdTypeAnalyse, héritée de TYPE_TEST.

L’AGL n’est pas au courant de toutes nos règles de gestion, aussi supprime-t-on manuellement une de ces deux colonnes, par exemple TYP_IdTypeAnalyse, en prenant soin de modifier les propriétés du lien menant de TEST à TYPE_TEST (y remplacer TYP_IdTypeAnalyse par IdTypeAnalyse) :





On devrait commencer à arriver à ce qu’on veut ^^... Tout au long, j’ai utilisé PowerAMC pour rester au niveau conceptuel. Je ne sais pas si l’outil que vous utilisez permet de mettre en œuvre l’identification relative (vous me direz), mais quoi qu’il en soit, pour obtenir directement le MLD de la figure 11, vous pouvez utiliser MySQL Workbench (gratuit), voyez l’article qui va bien.




Script SQL

TABLE PATIENT

Code SQL :

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

1
2
3
4
5
6
CREATE TABLE PATIENT 
(
   IdPatient            INT NOT NULL,
   NomPatient           VARCHAR(64) NOT NULL,
   CONSTRAINT PATIENT_PK PRIMARY KEY (IdPatient)
) ;

TABLE TYPE_ANALYSE

Code SQL :

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

1
2
3
4
5
6
CREATE TABLE TYPE_ANALYSE 
(
   IdTypeAnalyse        INT NOT NULL,
   DescriptionAnalyse   VARCHAR(64) NOT NULL,
   CONSTRAINT TYPE_ANALYSE_PK PRIMARY KEY (IdTypeAnalyse)
) ;

TABLE TYPE_TEST

Code SQL :

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

1
2
3
4
5
6
7
8
9
CREATE TABLE TYPE_TEST 
(
   IdTypeAnalyse        INT NOT NULL,
   IdTypeTest           INT NOT NULL,
   ValeurNormale        VARCHAR(64) NOT NULL,
   CONSTRAINT TYPE_TEST_PK PRIMARY KEY (IdTypeAnalyse, IdTypeTest),
   CONSTRAINT TYPE_TEST_TYPE_ANALYSE_FK FOREIGN KEY (IdTypeAnalyse)
      REFERENCES TYPE_ANALYSE (IdTypeAnalyse)
) ;

TABLE ANALYSE

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
CREATE TABLE ANALYSE 
(
   IdPatient            INT NOT NULL,
   IdTypeAnalyse        INT NOT NULL,
   DatePrelevement      DATE NOT NULL,
   CONSTRAINT ANALYSE_PK PRIMARY KEY (IdPatient, IdTypeAnalyse),
   CONSTRAINT ANALYSE_PATIENT_FK FOREIGN KEY (IdPatient)
      REFERENCES PATIENT (IdPatient),
   CONSTRAINT ANALYSE_TYPE_ANALYSE_FK FOREIGN KEY (IdTypeAnalyse)
      REFERENCES TYPE_ANALYSE(IdTypeAnalyse)
) ;

TABLE TEST

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
CREATE TABLE TEST 
(
   IdPatient            INT NOT NULL,
   IdTypeAnalyse        INT NOT NULL,
   IdTypeTest           INT NOT NULL,
   DateResultat         DATE NOT NULL,
   ValeurTest           VARCHAR(64) NOT NULL,
   CONSTRAINT TEST_PK PRIMARY KEY (IdPatient, IdTypeAnalyse, IdTypeTest),
   CONSTRAINT TEST_ANALYSE_FK FOREIGN KEY (IdPatient, IdTypeAnalyse)
      REFERENCES ANALYSE (IdPatient, IdTypeAnalyse),
   CONSTRAINT TEST_TYPE_TEST_FK FOREIGN KEY (IdTypeAnalyse, IdTypeTest)
      REFERENCES TYPE_TEST (IdTypeAnalyse, IdTypeTest)
) ;

Un peu d'aspirine ?

Et n’oubliez pas de voter au passage pour les réponses qui ont pu vous apporter quelque chose...

[Oishiiii]

Je n'ai rien à apporter à la discussion mais je voulais simplement féliciter fsmrel pour ses interventions qui sont toujours d'une très grande qualité.
Bravo !

Bonne journée

[fsmrel]

Merci vaillant Oishiiii, je me demandais ce que vous deveniez, j’étais inquiet ^^

[pachou8]

Bonsoir fsmrel!
J'ai du revoir le cours pour cerner votre réponse et je dois aussi avouer qu'elle a été toute une séance de pratique pour moi.
Ce fut un bon petit bout de chemin et, comme vous l'avez prévu, j'ai du tenir bon pour éviter l'aspirine.
Merci beaucoup!
Juste pour élargir mes connaissances sur le sujet, est-ce ainsi qu'il faut toujours traduire les contraintes d'inclusion?
pourriez-vous me référer un article qui traite ce sujet, au cas où je voudrais traduire en MPD, d'autres contraintes entre associations?
Merci!

[fsmrel]

Bonsoir Pachou,

Juste pour élargir mes connaissances sur le sujet, est-ce ainsi qu'il faut toujours traduire les contraintes d'inclusion?
pourriez-vous me référer un article qui traite ce sujet, au cas où je voudrais traduire en MPD, d'autres contraintes entre associations?

En ce qui concerne les contraintes d’inclusion, je n’ai malheureusement pas de références à des articles portant sur le sujet, et ne peux que souhaiter ne pas dire de bêtises quand j’écris... Dans la discussion avec Merisier, voyez le post #7 et suivants, notamment le post #10 où je désosse. En passant, je pense que dans nos forums, JPhi33 est celui qui est le plus au courant des contraintes en Merise. Quoi qu’il en soit, dès qu’on arrive au niveau SQL, je cherche le plus possible la représentation qui fera qu’on pourra éviter les triggers et se limiter à sous-traiter l’inclusion à l’intégrité référentielle (voyez à ce propos le problème des contraintes de chemin, par exemple dans la discussion avec Benallasiham). En relationnel pur, je peux avoir recours à l’instruction CONSTRAINT, absente de SQL qui se cantonne (dans la norme) à l’instruction CREATE ASSERTION, non proposée du reste par les SGBD actuels (d'où le recours aux triggers quand on ne peut pas faire autrement).

Je pense que l’ouvrage le plus complet au sujet des contraintes en Merise est celui de D. Nanci et Bernard Espinasse, Ingénierie des systèmes d'information : Merise Deuxième génération, mais il semble se faire de plus en plus rare chez les libraires, hélas...

[pachou8]

Salut fsmrel,

J'ai fait le tour des discussions que vous m'avez proposées, je n'ai pas tout mais, j'ai plein de bagages, maintenant, pour des recherches plus profondes. A vous suivre ici, je crois que je ne serai plus bientôt débutant!

Merci infiniment!