Discussion :

[Tagada_Or]

Bonjour à tous,

Je dois créer une base de données pour des patients subissant certains examen une seule fois au début de leur suivi puis des examens répétés lors de visites régulières.
J'ai pensé créer la structure de ma base de données de la façon suivante (les champs soulignés constituent la clé primaire) :

Table Patients : Numpat, Sexe, Date de naissance etc.....
Pour les examens réalisé une seule fois : Exemple (le diagnostic initial) : Table Diagnostic : Numpat, Diagnostic
Les tables patients et Diagnostic sont liées entre elles par le champ Numpat.

En ce qui concerne les examens répétés, je pensais faire une table intermédiaire appelée Table Visite : Numpat, Numvis, Date_Vis. Cette table est liée à la table patient par le Numpat.
Puis une table pour chacun des examens : Exemple (évaluation de la douleur) : Table Douleur : Numpat, Numvis, Score_douleur.
Cette table est liée à la table visite par Numpat et Numvis.

Je ne suis pas sûre que cette structure soit optimale, quelqu'un aurait-il un avis sur cette structure ou bien une solution plus optimisée ?

Merci beaucoup.

[jimbolion]

Tagada_or

Une discussion à peu près semblable ici :

http://www.developpez.net/forums/d14...nregistrement/

Jimbolion

[Tagada_Or]

Bonjour Jimbolion,

Merci beaucoup pour ce retour, cependant quelques doutes persistent.
En effet, contrairement à la discussion vers laquelle vous m'avez envoyé, dans ma structure de base de données je ne veux pas attribuer un numéro incrémentiel à la table visite puisque je veux que chaque patient puisse avoir sa visite 01, 02, 03 etc...

C'est donc principalement à ce niveau là que je ne suis pas sûre de mon schéma, au niveau de la liaison entre la table visite et les tables correspondant aux examens répétés. Cette liaison basé sur une double clé primaire est-elle correcte ?

De plus, je ne veux pas créer une table visite unique reprenant tous les examens réalisés de façon répétés (car beaucoup trop de champs et il me parait plus clair d'avoir chaque examen dans une seule table avec le numéro de la visite et le numéro du patient).

Merci encore,

tagada_or

[jimbolion]

Tagada_Or,

C'est bien ce que prévois mon modèle...

Une visite a un numéro incrémental, donc une visite par enregistrement en relation avec chaque client. Si tu souhaites gérer un numéro d'ordre tu peux l'insérer dans le modèle, cela t'obligera à chaque fois à rechercher le dmax du numéro précédent. En manipulant tes futures requêtes, tu verras que l'auto increment N° de visite sera bien utile.

Par contre le modèle que je te livre comme exemple ne réponds pas aux techniques de normalisation, mais le modèle structuré est bon.

Une visite peut recevoir plusieurs soins (chez un dentiste c'est le cas) et cette notion réponds là encore à ta demande : tous les examens réalisés de façon répétés.

JimboLion

[fsmrel]

Bonsoir,

Je ne suis pas sûre que cette structure soit optimale, quelqu'un aurait-il un avis sur cette structure ou bien une solution plus optimisée ?

La structure que vous proposez est tout à fait correcte, elle est en 5e forme normale. Tout au plus pourrait-on ajouter une clé candidate {Numpat, Date_Vis} pour la table VISITE si un patient n’avait droit qu’à une visite par jour.

En l’occurrence, vous utilisez l’identification relative, ce qui — conceptuellement parlant — est une pratique recommandée : une visite n’a de sens que relativement à un patient, et l’entité-type VISITE est une propriété multivaluée de l’entité-type PATIENT.

En passant du niveau conceptuel au niveau « logique », dans le contexte ACCESS, la situation est la suivante (j’ai renommé les attributs, mais peu importe) :




Représentation graphique dans laquelle la paire {PatientId, VisiteId} est clé primaire de la table VISITE et le singleton {PatientId} clé étrangère par rapport à la clé primaire {PatientId} de la table PATIENT. Vous noterez au passage qu’il y a économie d’index concernant VISITE, puisque le même sert pour la clé primaire {PatientId, VisiteId} et pour la clé étrangère {PatientId} (il n’y a pas de petits profits...)

Techniquement, les choses peuvent être un peu plus compliquées quand il s’agit ne numéroter automatiquement les visites par rapport aux patients. On peut mettre en oeuvre un trigger (comme l’illustre CinePhil dans un de ses billets, quand on utilise par exemple MySQL) mais, avec ACCESS, on peut par exemple utiliser VBA ou des « Data macros ».

Allons-y pour VBA et utilisons le modeste formulaire suivant, devant nous permettre de créer le suivi des patients :



On fournit l’identifiant du patient (champ PatientId) et la date de visite. Le champ VisiteId n’est pas accessible, histoire de montrer que c’est l’application qui va en calculer la valeur :




En utilisant le bouton « Ajouter », on déclenche le calcul de la valeur que doit prendre le champ VisiteId :




Manifestement, le patient 2 en est à sa 6e visite. De fait, le contenu de la table est le suivant après cette saisie :




Si cela peut vous aider, voici le code attaché au formulaire VISITE et permettant d’incrémenter automatiquement VisiteId :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
Option Compare Binary
 
'-------------------------------------
' Chargement du formulaire
'-------------------------------------
 
Private Sub Form_Load()
 
Me.PatientId = 0
Me.VisiteId = 0
Me.VisiteDate = Now()
 
End Sub
 
'-------------------------------------------------
' Cézigue a cliqué sur le bouton "Ajouter"
'-------------------------------------------------
Private Sub Ajouter_Click()
 
Dim theVisiteId As Integer
 
'------------------------------
' Contrôle de la date
'------------------------------
 
If IsNull(VisiteDate) Or Not IsDate(VisiteDate) Then
    R = MsgBox("Veuillez fournir une date de visite", vbExclamation, Me.Name)
    Exit Sub
End If
 
'------------------------------------------------------
'Contrôle de la structure de l'identifiant du patient
'------------------------------------------------------
If Not IsNumeric(Me.PatientId) Then
    R = MsgBox("Id du patient : numérique svp", vbExclamation, Me.Name)
    Exit Sub
End If
 
'--------------------------------------------------------------------------
'Relais à la fonction incrémentant VisiteId
'--------------------------------------------------------------------------
If Not IncrementerVisiteIdOK(Me.PatientId, theVisiteId, VisiteDate) Then
    Exit Sub
End If
 
'---------------------------------------
'Affichage de VisiteId incrémenté
'---------------------------------------
 Me.VisiteId = theVisiteId
 
End Sub
 
'------------------------------------------------------------------------------------------
'Fonction permettant d'incrémenter Visiteid et effectuant les inserts dans la table VISITE
'------------------------------------------------------------------------------------------
 
Function IncrementerVisiteIdOK(ByRef Patient As Integer, ByRef Visite As Integer, ByRef VisiteDate As String) As Boolean
 
Dim MaBase As dao.Database, SqlResult As dao.Recordset, R As String
 
On Error Resume Next
 
IncrementerVisiteIdOK = False
 
Set MaBase = CurrentDb
 
'-----------------------------------
' On vérifie que le patient existe
'-----------------------------------
 
R = "SELECT  '' FROM PATIENT WHERE PatientId = " & Patient
 
Set SqlResult = MaBase.OpenRecordset(R, dbOpenDynaset)
 
theKount = SqlResult.RecordCount
 
If theKount = 0 Then
    Reponse = MsgBox("Le patient '" & Patient & "' est inconnu au bataillon", vbExclamation, Me.Name)
    Exit Function
End If
SqlResult.Close
 
'-------------------------------------------------
'On vérifie si c'est une 1re visite du patient
'-------------------------------------------------
R = "SELECT  '' FROM VISITE WHERE PatientId = " & Patient
 
Set SqlResult = MaBase.OpenRecordset(R, dbOpenDynaset)
 
theKount = SqlResult.RecordCount
 
If theKount = 0 Then
    '-------------------------------------------------------
    'C'est la 1re visite du patient
    '-------------------------------------------------------
    R = "INSERT INTO VISITE (PatientId, VisiteId, VisiteDate) VALUES (" & Patient & ", 1, '" & VisiteDate & "') ;"
Else
    '-------------------------------------------------------
    'Ça n'est pas la 1re visite du patient, on incrémente
    '-------------------------------------------------------
    R = "INSERT INTO VISITE (PatientId, VisiteId, VisiteDate) "
    R = R & "SELECT PatientId, (SELECT MAX(VisiteId)+1 FROM VISITE WHERE PatientId = " & Patient & "), '" & VisiteDate & "' "
    R = R & " FROM VISITE "
    R = R & " WHERE PatientId = " & Patient & " And VisiteId = (SELECT MAX(VisiteId) FROM VISITE WHERE PatientId = " & Patient & ") ;"
End If
''Debug.Print Chr(13) & R & Chr(13)
MaBase.Execute R, dbFailOnError
x = Err.Number
 
If x = 0 Then
    IncrementerVisiteIdOK = True
    '--------------------------------------------------------------
    'On récupère la valeur résultant de l'incrémentation
    '--------------------------------------------------------------
    R = "SELECT  MAX(VisiteId) AS MaxVisite FROM VISITE WHERE PatientId = " & Patient
    Set SqlResult = MaBase.OpenRecordset(R, dbOpenDynaset)
 
    Visite = SqlResult.Fields("MaxVisite").Value
    SqlResult.Close
Else
    Reponse = MsgBox("Access rouspète : " & vbCr & vbCr & Err.Description, vbCritical, Me.Name)
End If
 
End Function
 
'----------------------------------------
'Cézigue en a terminé
'----------------------------------------
 
Private Sub Terminer_Click()
 
DoCmd.Close
 
End Sub

Précision : pour le formulaire VISITE, les contrôles que j’utilise sont indépendants (unbound) :

[Tagada_Or]

Bonjour,

Merci à vous deux pour ces retours très intéressant ! L'incrémentation automatique des numéro de visite me semble tout à coup bien pratique.

Enfin, si je peux abuser de vos connaissances, j'aurais une dernière question par rapport à cette base de données : en effet, toutes les visites ne seront pas identiques en termes de contenu (examens réalisés).

Il y aura :
- une visite préopératoire
- une visite concernant l'intervention (très différente des autres)
- une visite post-opératoire
- des visites de suivi identiques entre elles

Les visites préopératoire, post-opératoire et les visites de suivi sont assez similaire même si quelques différences existent.
Au niveau des formulaires de saisie, j'avoue avoir un peu de mal à voir comment organiser tout cela.

J'aurai souhaité réaliser un formulaire pour la visite préopératoire qui contiennent les données de la table patient, de la table visite puis les examens correspondants à cette visite puis créer sur ce formulaire un bouton commande qui m'ouvre le second formulaire concernant l'intervention. Dans ce formulaire intervention, à nouveau les données de la table patient, les données de la tables visites puis les examens correspondant à cette visite et le bouton commande pour ouvrir le troisième formulaire et ainsi de suite.....
Cela vous semble-t-il pratique d'utilisation ? Y a-t-il un élément que je n'aurais pas pris en compte et qui pourrait me bloquer au niveau d'Access. Bien que je me sois creusé la tête, je n'ai pas trouvé d'autre façon d'organiser mes formulaires qui soit simple.

Merci encore,

Tagada_or

[jimbolion]

Tagada_Or,

Lorsque les visites ont des natures très différentes, il faudra nécessairement des table différentes. Lorsque celle ci sont similaires il faudra typer une information dans des tables référencielles

Exemple

T_Patients(id, nom, prenom....)
T_Visites(id, numero, #idpatient, date...)
T_TypesVisites(id, description) ex. préopératoire, postoperatoire
T_Visitescomplements (id,#idevisite,#idtypevisite,datevistecomplement...)
T_Vistesoperatoires(id,#idevisite,datevisteoperatoire...)
T_Visitessuivi(id,#idevisite,datevistesuivi...)

Les dates te permettent d'avoir un ourdre chronologique et t'affranchir dans ce cas de l'ordonnancement des visites. Dans chaque table le #idvisite (clé secondaire) te rattache donc à ta table visites et par conséquent au patient (il est inutile de rattacher donc le patient au niveau de chaque détail)

JimboLion

[fsmrel]

Bonsoir,


Avant de traiter de l’organisation des formulaires, Il faudrait assurer les fondations, et construire un modèle des données. En théorie, il s’agit d’un modèle conceptuel des données ou d’un diagramme de classes, mais dans votre cas je pense que vous pouvez élaborer directement un diagramme dans le genre de ceux qu’on produit avec MySQL Workbench. Dans cet exercice, il vaut mieux ne pas modéliser avec ACCESS, car celui-ci ne permet pas de représenter les cardinalités minimales. Ainsi, dans le diagramme ci-dessous, on ne sait pas si un patient devra avoir fait l’objet d’au moins une visite, ou si cela est optionnel :






Quoi qu'il en soit, à vous lire, on relève les concepts suivants relatifs à un patient :

Diagnostic,

Examen,

Visite préopératoire,

Visite concernant l'intervention,

Visite post-opératoire,

Visite de suivi,

Douleur...



Il serait bon que vous fournissiez la liste précise de ces concepts, ainsi que leurs attributs naturels (c'est-à-dire intéressant directement l’utilisateur), dans le but de définir les entités-types inférables de ces concepts, ainsi que les relations (associations) que ces entités-types entretiennent, donc produire un modèle structurellement complet et solide.


A défaut, vous courrez le risque de bâtir un système instable et à reprendre plus tard à zéro. Concernant les formulaires on passe au stade du comment, aussi est-il plus important de commencer par s’assurer du quoi.

[Tagada_Or]

Bonjour,

Pour vous aider à mieux comprendre l'organisation de la structure de ma base, voici une capture d'écran de celle-ci.

Au départ, le patient subira une seule fois uniquement les examens suivants :
- ASA/DO
- ATCD_CHIRU
- ATCD_NON_CHIRU
- DIAGNOSTIC
d'où la relation 1---1 entre la table INCLUSION et ces différentes tables.

Par la suite, le patient aura plusieurs visites, d'où la relation 1 ---- ∞ entre les tables INCLUSION et VISITE.
Ces visites sont :

- Visite préopératoire avec les examens correspondants aux tables suivantes : AL, HD, ODI, VIE_PRO, EVA, TRAITEMENT, COMM d'où la double relation 1---1 entre les champs NUMPAT et NUMVIS de ces tables avec la table visite puisque un patient ne réalise chacun de ces examens qu'une seule fois par visite. En revanche la table COMM a une triple clé primaire et une relation 1 ---- ∞ car plusieurs commentaires peuvent être saisis pour un même patient au cours de la même visite.

- Visite intervention avec les examens correspondants aux tables suivantes : INTERVENTION, EIG, COMM. Tout comme la table COMM, la table EIG a une triple clé primaire et une relation 1 ---- ∞ car plusieurs EIG peuvent être saisis pour un même patient au cours de la même visite.

- Visite post-opératoire avec les examens correspondants aux tables suivantes : HOSPITALISATION, IMMOBILISATION, EVA, HD, AL, COMPLICATION_GAL, COMPLICATION_MAT, EIG, COMM

- Plusieurs visites de suivi identiques : VIE_PRO, TRAITEMENT, EVA, FUSION, HD, AL, ODI, COMPLICATION_GAL, COMPLICATION_MAT, EIG, COMM

- Visite de fin : FIN_ETUDE, EIG, COMM.

Je sens bien que ma structure présente des défauts mais je ne parviens pas à trouver comment l'améliorer...

Merci,

Tagada_or

[Tagada_Or]

Re Bonjour,

En me relisant, je me rends compte que le but et l'utilisation finale de ma base de données ne sont pas forcément clairs...

Je vous mets donc en pièce jointe une ébauche manuscrite de l'utilisation que je voudrais pouvoir faire de cette base. Cela vous semble-t-il possible à obtenir ?

Merci encore !! J'ai quelques base mais je suis loin d'être douée avec Access..

Tagada_or

[fsmrel]

Bonjour Tagada,

J'ai quelques base mais je suis loin d'être douée avec Access..

Confidence pour confidence, j’ai une connaissance limitée d’Access, l’ayant seulement regardé d’un œil amusé pendant une semaine il y a 20 ans, même chose il y a 10 ans, et je commence à l’explorer un peu plus avant depuis un mois. Mais il demeure qu’Access ne permet pas de modéliser les données aussi bien que les AGL dont c’est vraiment l’objet : c’est comme si en mathématiques on ne pouvait pas faire la distinction entre bijection et injection, ou encore comme si en logique on pouvait utiliser la quantification universelle mais pas la quantification existentielle : Adieu la logique !


Revenons donc à l’essentiel : la structure des données.

Bien que stricto sensu ça ne soit pas nécessaire, mais la curiosité m'aiguillonne, quel sens donnez vous au mot « INCLUSION » ? Est-il synonyme de « PATIENT » ? Je connais l’inclusion dans le contexte de la théorie des ensembles, mais là, I give my tongue to the cat...

Vous écrivez :

« Au départ, le patient subira une seule fois uniquement les examens suivants :
- ASA/DO
- ATCD_CHIRU
- ATCD_NON_CHIRU
- DIAGNOSTIC
d'où la relation 1---1 entre la table INCLUSION et ces différentes tables. »

Même si on a le sentiment que c'et le verbe devoir qui s'impose, reste une ambiguïté entre devoir et pouvoir. Puisqu’on ne peut pas représenter les cardinalités minimales avec ACCESS, complétons en utilisant MySQL Workbench (déjà évoqué dans mon message précédent).

Prenons l’exemple de la table répondant au doux nom de ASA/DO (pour la petite histoire, dans mon entreprise, il y avait une DO (direction opérationnelle) nommée ASA, chargée des relations avec les sociétés d’assurance, mais je pense que tel n’est pas votre cas ) : si chaque patient doit faire l’objet d’un asa/do, la modélisation est la suivante (bijection) :





A contrario, si un patient ne fait pas nécessairement l’objet d’un asa/do (nuance importante !) alors la modélisation devient la suivante (injection) :



Où le caractère optionnel est mis en évidence par la cardinalité minimale 0, symbolisée par « 0..1 ».


Question : qu’en est-il pour la partie gauche de votre modèle ? Existe-t-il des associations porteuses d’une cardinalité minimale 0 ? Si oui lesquelles ?

Une fois traitée la partie gauche du modèle, on expertisera a partie copieuse à droite...



Vu votre PDF, concernant vos formulaires et votre souci de ne pas avoir à saisir à chaque fois les données du patient, ça ne devrait pas poser de problème, mais attendons que le modèle soit d'équerre.

[Tagada_Or]

Bonjour,

Merci beaucoup pour ce retour même si j'avoue être un peu perdue.

Tout d'abord, "INCLUSION" correspond à l'entrée du patient dans l'étude, on parle de l'inclusion d'un patient.

Ensuite, j'avoue n'avoir jamais utilisé "MySQL Workbench" et son utilisation reste plus ou moins un mystère....

Enfin, en ce qui concerne la partie gauche de mon modèle, le patient doit forcément avoir un diagnostic, mais les examens ASA/DO, CIRS, ATCD_CHIRU et ATCD_NON_CHIRU ne seront pas obligatoirement réalisés donc oui pour ces tables là, il s'agit bien d'une cardinalité minimale 0.

Encore merci de m'aider, je sens que le chemin va être long pour arriver à ce que je souhaite obtenir.

Tagada_Or

[fsmrel]

"INCLUSION" correspond à l'entrée du patient dans l'étude, on parle de l'inclusion d'un patient.

D’accord. Toutes les données du patient sont-elles dans cette table (Nom, prénom, NIR, ...) ? Ou seulement celles qui sont utiles pour votre application ?

j'avoue n'avoir jamais utilisé "MySQL Workbench" et son utilisation reste plus ou moins un mystère....

C’est comme la mayonnaise, une fois que ça aura pris, ça sera tout bon. J’illustrerai au fur et à mesure...

En ce qui concerne la partie gauche de mon modèle, le patient doit forcément avoir un diagnostic, mais les examens ASA/DO, CIRS, ATCD_CHIRU et ATCD_NON_CHIRU ne seront pas obligatoirement réalisés donc oui pour ces tables là, il s'agit bien d'une cardinalité minimale 0.

D’accord. Peut-on inférer que, quel que soit le patient, les données correspondant à la partie droite du diagramme ne pourront pas exister tant qu’il n’y aura pas eu de diagnostic préalable ?

Je sens que le chemin va être long pour arriver à ce que je souhaite obtenir.

Là encore, c’est comme pour la mayonnaise (ou le vélo...), au démarrage ça peut être laborieux, mais ensuite ça roule. Et puis vous avez quand même déjà réalisé la majeure partie du travail, on est dans la phase de vérification.

En ce sens, dans votre diagramme Access, les tables ASA/DO, ATCD_CHIRU, ATCD_NON_CHIRU et DIAGNOSTIC ne sont pas en relation avec les tables de type visite, mais seulement avec la table INCLUSION ; toutefois, vous avez écrit :




Ce qui, après tout, laisse supposer qu'il pourrait y avoir des relations directes entre les tables que j’ai énumérées et certaines visites. Qu’en est-il ?

[Tagada_Or]

Pour répondre à vos questions :

- seules les données patients qui sont utiles à mon application apparaissent dans la table INCLUSION

- Oui, en ce qui concerne les données correspondant à la partie droite, un diagnostic préalable doit avoir été établi

- En ce qui concerne les tables ASA/DO, ATCD_CHIRU, ATCD_NON_CHIRU et DIAGNOSTIC, en effet elles ne sont pas liées à la table VISITE mais comme vous l'avez fait remarqué ces examens sont également réalisés au cours de la première visite (visite préopératoire) avec en plus d'autres examens.
Pourquoi ne les ai-je pas liés à la table VISITE ? Car pour moi ces examens n'étaient pas répétitifs à la différence des autres. Etant données qu'ils ne sont réalisés qu'à la visite préopératoire, je ne voyais pas l'intérêt de les lier à une visite en particulier. Or cela semble maintenant beaucoup moins logique de ne pas les avoir liées à la table VISITE surtout en sachant que les tables FIN_ETUDE et INTERVENTION sont également des "examens" unique (qui ne sont réalisé qu'à une seule visite : VISITE OPERATOIRE et VISITE DE FIN d'ETUDE) et que celles-ci je les ai liées à la table VISITE....
Faut-il donc lier ces 4 tables à la table VISITE ?

Je constate que la principale difficulté qui me pose problème est que les 9 visites ne sont pas toutes identiques entre elles.... J'avais pensé au début créer des tables différentes pour chacune de mes visites mais comme certains examens sont répétés et d'autres non, c'est pourquoi j'ai opté pour la structure que je vous ai proposé.

Merci,

Tagada_or

[fsmrel]

Bonsoir Tagada,


Toujours en faisant abstraction des formulaires...


Quelques remarques et questions préalables à propos de la modélisation des données :

(R1) Selon votre diagramme, à une inclusion peuvent être attachées plusieurs visites : ainsi, pour une inclusion donnée, rien n’empêche d’avoir plusieurs visites préopératoires, post-opératoires, etc., cela vaut pour type de visite.

(R2) Dans le cadre de votre application, les données sont-elles saisies quand toutes les visites ont été faites, ou bien la saisie peut-elle être effectuée au fil des visites ?

(R3) Y a-t-il bijection entre une inclusion et la visite préopératoire correspondante ? Autrement dit, à supposer que la saisie des données puisse être faite au fil du temps, c'est-à-dire des visites, doit-on quand même saisir simultanément les données d’une inclusion et celle de cette visite, ou bien la saisie des données de cette dernière peut-elle être effectuée postérieurement à celle de l’inclusion ?

(R4) Il y a manifestement bijection entre une visite préopératoire et un diagnostic : pourquoi ne pas faire figurer dans une seule table les données correspondant à ces deux concepts ?

[Tagada_Or]

Bonsoir fsmrel,

Voici mes réponses à vos remarques :

(R1) Non, à une inclusion est prévue une seule visite préopératoire, une seule visite post-opératoire etc.... Chaque type de visite à un numéro différent : Visite préopératoire (01), Intervention (02), Visite post-opératoire (3), Visite 1 mois (4), visite 6 mois (5), visite 12 mois (6), visite 12 mois (7), visite 24 mois (8), visite de fin d'étude (9)

(R2) La saisie peut être effectuée au fil des visites

(R3) La saisie des données de la visite préopératoire peut être effectuée postérieurement à celle de l’inclusion. Il n'y a pas de bijection entre ces 2 visites.

(R4) "Il y a manifestement bijection entre une visite préopératoire et un diagnostic : pourquoi ne pas faire figurer dans une seule table les données correspondant à ces deux concepts ? " En fait le diagnostic fait partie de la visite préopératoire. Il n'y a pas de table pour la visite préopératoire qui contiennent tous les examens réalisés au cours de cette visite. La visite préopératoire est constituée de plusieurs tables (tous comme les autres visites).

Merci,

Tagada_or

[fsmrel]

(R1) Non, à une inclusion est prévue une seule visite préopératoire, une seule visite post-opératoire etc.

J’entends bien, c’est ce qui doit être modélisé, mais malheureusement ça n’est pas le cas...



Une remarque :

La table DIAGNOSTIC comporte un attribut DIAGNOSTIC encapsulant une autre table : du point de vue de la modélisation, il faudrait que celle-ci soit visible. Quelle est-elle ?




A ceci près, voici ce que je comprends de la partie gauche du modèle (aux attributs ésotériques et/ou non visibles près) :

— A une inclusion correspond au plus un diagnostic (injection) ;

— Je pars du principe que les données facultatives telles que ASA_DO peuvent être indifféremment attachées à INCLUSION ou DIAGNOSTIC : ci-dessous, je les ai accrochées à DIAGNOSTIC (donc à la 1re visite), mais si vous estimez que sémantiquement parlant il est préférable que ce soit à INCLUSION, pas de problème...




A suivre...

[Tagada_Or]

J’entends bien, c’est ce qui doit être modélisé, mais malheureusement ça n’est pas le cas...

Voilà donc qui confirme mes doutes sur cette structure !

En ce qui concerne l'attribut diagnostic, il n'encapsule pas réellement une autre table mais une liste déroulante à choix multiples.

En effet, la structure que vous proposez semble plus simple à appréhender conceptuellement que ce que j'avais fait ! Et du fait la liaison des tables plus évidente !

Merci encore !
Je vais me pencher des demain sur la partie droite de ma structure en essayant de proposer un modèle qui puisse prévoir le fait qu'une seule visite de chaque type puisse être réalisée par patient et je viendrais vous la resoumettre si vous le voulez bien ?

Tagada_or

[fsmrel]

Bonjour Tagada,


Si l’on suit les événements d’un point de vue chronologique, une intervention se raccroche à un et un seul diagnostic, une visite post-opératoire à une et une seule intervention, et les visites de suivi à une et une seule visite post-opératoire. Le cas de la visite de fin d’étude est plus délicat, car il faudrait la rattacher à la dernière visite de suivi : plutôt que compliquer la modélisation, on pourra assurer le coup de façon transparente, au moyen d’un trigger attaché à la table FIN_ETUDE, lequel permettra automatiquement de contrôler que la date correspondante est postérieure à la date du dernier suivi. Du point de vue du modèle, on peut se contenter de considérer qu’une visite de fin d’étude est attachée à une et une seule visite post-opératoire. Tout cela représente en gros le fil conducteur (ou rouge...) du système, symbolisé ci-dessous par les tables DIAGNOSTIC, INTERVENTION, POST-OPERATOIRE, SUIVI et FIN_ETUDE :




En admettant que cette ossature vous convienne peu ou prou, viennent s’y accrocher des tables telles que AL (c’est quoi cette chose-là ?), EIG, EVA (et celles-là ? ^^), etc. Pour le moment, je suggère une mise plat : ainsi, au lieu de modéliser une seule table EVA, on pourrait en modéliser trois (même principe pour les autres concepts) :

— Pour les visites préopératoires, une table EVA_PRE (ou un nom comme ça, pour symboliser le type « EVA préopératoire »), attachée à INCLUSION ;

— Pour les visites post-opératoires, une table EVA_POST attachée à POST_OPERATOIRE ;

— Pour les visites de suivi, une table EVA_SUIVI attachée à SUIVI.

L’avantage est qu’on sait quoi est accroché à quoi, sans confusion, on peut donc suivre facilement le film et enchaîner les actions. L’inconvénient est qu’on multiplie les tables, mais est-ce bien critiquable ? Si d’aventure on avait besoin d’une table réunissant toutes les EVA, il faut savoir que cette table existe ! C’est l’union (au sens de la théorie des ensembles) des tables de type EVA qu’on vient de voir. En SQL :

Code SQL :

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

 SELECT * FROM EVA_PRE UNION ALL SELECT * FROM EVA_POST UNION ALL SELECT * FROM EVA_SUIVI

Concernant les tables actuelles se greffant sur l’ossature : AL, HD, ODI, VIE_PRO, EVA, TRAITEMENT, COMM, etc., quelles sont les cardinalités portées pas les pattes de connexion ?

Par exemple, pour un diagnostic, combien a-t-on de « AL » : un seul au plus (0,1 — autrement dit injection) ? Au moins et au plus un seul (1,1 — autrement dit bijection) ? De zéro à plusieurs (0,N — autrement dit application) ? au moins un et plus plusieurs (1,N — autrement dit surjection) ?


J’espère qu’on ne piétine pas trop ^^ Bon courage !

[Tagada_Or]

Bonjour fsmrel,

Merci beaucoup pour votre implication.

Oui, cette ossature me convient, seulement je ne vois pas où se trouve la visite préopératoire, ne devrait-elle pas se situer entre le diagnostic et la visite intervention ?
Je me pose également la question de la numérotation de mes visites : où va-t-elle se situer ? Ne faut-il pas ajouter un champ NUMVIS à chacune des visites ? J'ai bien vu qu'il existe un champ NumSuivi dans la table suivi mais celui-ci semble lputôt correspondre à la distinction des visites de suivi entre elles, non ?

AL (c’est quoi cette chose-là ?), EIG, EVA (et celles-là ? ^^)

EVA correspond à un examen permettant d'évaluer la douleur, quand à AL (et également HD), il s'agit de mesures radiographiques.

Pour le moment, je suggère une mise plat : ainsi, au lieu de modéliser une seule table EVA, on pourrait en modéliser trois (même principe pour les autres concepts)

Je suis d'accord avec cette proposition, il est vrai que pour obtenir tous les EVA dans une seule table, la requête est simple.

Concernant les tables actuelles se greffant sur l’ossature : AL, HD, ODI, VIE_PRO, EVA, TRAITEMENT, COMM, etc., quelles sont les cardinalités portées pas les pattes de connexion ?

Pour toutes les tables se greffant sur l'ossature, les cardinalités sont un seul au plus (0,1 — autrement dit injection) à l'exception des tables COMM et EIG qui ont des cardinalités de zéro à plusieurs (0,N — autrement dit application) puisque plusieurs commentaires ou plusieurs EIG peuvent être saisis pour une même visite.

Merci encore,

Tagada_or