Discussion :

[SteffieLili]

Me revoilà encore une fois car j'ai un autre problème sur mes données et sur leur analyse.

En effet, ma modélisation actuelle est la suivante :


Les CMD par exemple, qui proviennent initialement de la table RSA, ne sont pas récupérable si on sélectionne 'DAS' en Nature de code. Je suppose que cela vient du fait d'avoir concaténer les tables et de ne pas avoir fait de jointure. Cependant, mon outil doit pouvoir remonter ce genre d'information.

Comment faire remonter des données juste à partir des codes de Nature 'DAS' ?

Une nouvelle fois merci

[PhunkyBob]

MODERATION : Sujet séparé de http://www.developpez.net/forums/d14...nation-tables/

[SteffieLili]

Merci d'avoir déplacé le sujet, je n'avais pas osé en créer un autre.

J'ai passé la matinée à essayer de débuguer ces incohérences dans les données. Si bien que je me demande si je ne doit pas créer ma table de fait de toute pièce afin de réaliser les jointures qui m'intéressent. Au lieu de concaténer les tables RSA, RUM et DAS en table FAIT_HOSPIT, ces tables deviendraient des dimensions. Le soucis, c'est que certaines tables risquent de se joindre entre elles car elles ont besoin de thésaurus (sorte de dictionnaire) qui sont les mêmes (pour les codes notamment). Ainsi, des noms de champs seront identiques et des jointures non voulues entre les dimensions se feront.

Je ne sais plus vraiment quoi faire pour être sure de modéliser des données cohérentes

[FORMULARY]

Il suffit de définir les champs que tu charges en utilisant le mot-clé AS pour renommer les champs si besoin ...

[SteffieLili]

Le soucis n'est pas la Formulary, je n'ai pas dû être très clair, je m'en excuse. J'ai bien compris le principe de renommer les champs et des jointures par homonymie.
Si j'intègre ma table de fait, voici mes dimensions et leurs "jointures" en relationnel. Les tables établissements et THS_CIM10 sont des tables de dictionnaires, donc doivent être liées aux dimensions RUM et RSA.


A la base, j'ai implémenté la table RSA et RUM concaténées et j'ai décidé que la table résultante serait une table de fait (puisque le résultat de la concaténation contient toutes les clés étrangères de mes autres tables). En revanche, j'ai un soucis de données manquantes pour les données qui ne sont reliées qu'aux champs de RSA mais qui pourtant pourraient être reliées à RUM (cf CMD de la table GHM dans le modèle de données que j'ai donné dans mon premier message). Aucun CMD ou GHM n'est cochable (couleur grise) quand on sélectionne un RUM.
Du coup, pour palier à cela, si je passe par une table de fait à part, comment réaliser mes jointures avec ces "dictionnaires" sans réaliser de cycle ?

Ais-je été plus claire ?

Je précise que j'ai le même problème avec la table DAS dont je parlais en début de message pour faire suite à mon autre sujet. La table DAS contient elle aussi FINESS, index_RSA, index_RUM, Nature et Codes

[FORMULARY]

A force de lire et relire tes différents posts, je commence à comprendre

A mon avis, il y a peut-être une erreur de conception. Apparemment, tu as inclus dans une seule table de faits deux tables :
Une RSA qui contient des indications au niveau hospitalisation, et une RUM qui contient des indications au niveau unités, elle-mêmes dépendant de l'hospitalisation.

Du coup, si on sélectionne une RUM, on n'a plus les éléments RSA (et inversement, si on sélectionne une valeur propre à une RSA, on n'aura plus les éléments relatifs aux RUM)

Pourquoi avoir concaténé les tables ?

Refaites-moi aussi un explicatif : Qu'est-ce qu'un RSA, un RUM, un DAS ?
Peut-on avoir des RSA sans RUM ou des RUM sans RSA ???

[SteffieLili]

D'accord, merci de prendre le temps. Je vais essayer d'être le plus claire possible.

Pourquoi avoir concaténé les tables ?

Très bonne question, car mon axe d'analyse doit absolument porter sur les 3 tables ensembles. Je peux sinon axer tout sur le RSA mais je devrai lier la table RUM et DAS à RSA. Je pensais que concaténer les tables était une bonne solution mais apparemment, si les lignes ne correspondent pas, cela ne me semble pas faisable.

Refaites-moi aussi un explicatif : Qu'est-ce qu'un RSA, un RUM, un DAS ?

Je vais vous faire un cours de médical

Un RSA est un résumé de sortie anonymisé. C'est tout un tas d'informations administratives et un peu médicales d'un patient qui résultent d'une hospitalisation. Un RSA est le produit de un ou plusieurs RUM.
Un RUM est un résumé d'unité médicale. Ce sont des informations administratives mais surtout médicales lors du passage du patient dans une unité médicale (Urgences, oncologie...). Lors d'une hospitalisation dans un établissement, le patient peut passer dans plusieurs RUM (urgences PUIS oncologie), il y aura alors deux RUM qui génèreront un seul RSA. Ce RSA correspondra à l'hospitalisation entière du patient.
Dans les RUM et les RSA, des codes de diagnostics sont rentrés. Ce sont les fameux codes de nature DP et DR dont je parle. Les DAS sont aussi des codes. C'est un autre type de nature mais ce sont les mêmes codes que les DP et DR. Ils sont eux aussi rattachés à un RSA et à un RUM mais dans ma base de données Access, ils sont renseignés dans une table à part.

Peut-on avoir des RSA sans RUM

Comme expliqué plus haut, non, on ne peut pas avoir de RSA sans RUM. Si le patient ne passe que dans une unité médicale, il aura un RUM et de ce RUM sera généré un RSA.

ou des RUM sans RSA ???

Non plus, il n'y pas pas de RUM sans RSA.

Voilà pour la petite explication, je me rends compte que je suis bien plus à l'aise avec les notions que je code que pour les implémenter

[FORMULARY]

Ca devient plus clair tout à coup

Je propose :
Une table RSA avec un idRSA et tous les champs propres au RSA
Une table RUM avec un idRSA et tous les champs propres au RUM
Chaque table aura ses champs propres, le seul commun étant idRSA

Pour les établissements on peut :
- Lier le code des tables RSA à une table CodesRSA et les codes RUM à une table RUM
- Utiliser JOIN LOAD dans le script pour implémenter un champ rsaRaisonSociale dans la table RSA
et utiliser JOIN LOAD dans le script pour implémenter un champ rumRaisonSociale dans la table RUM

Pareil bien sûr pour la table THS_CIM10

Exemple de script :

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
RSA:
Load Index_RSA as rsaID,
     mois_sortie as rsaMoisSortie,
     annee_sortie as rsaAnSortie,
     FINESS as rsaEtab,
     Nature as rsaNature,
     Codes as rsaCodes
     from ...
Join LOad FINESS as rsaEtab,
          Raison_sociale as rsaRaisSoc
          resident Etablissements
Join LOad Codes as rsaCodes,
          Libellé as rsaLibCodes
          resident THS_CIM10
RUM:
Load Index_RSA as rsaID,
     Index_RUM as rumID,
     FINESS as rumEtab,
     Nature as rumNature,
     Codes as rumCodes
     from ...
Join LOad FINESS as rumEtab,
          Raison_sociale as rumRaisSoc
          resident Etablissements
Join LOad Codes as rumCodes,
          Libellé as rumLibCodes
          resident THS_CIM10

Je ne sais pas quelles sélections de codes vous voulez faire. Il faudra regarder d'un peu plus près.
Par exemple, si je sélectionne le code 01 :
Faut-il sélectionner tous les RSA ayant ce code + les lignes RUM ayant ce code,
ou toutes les lignes RUM d'un RSA ayant ce code + les lignes RUM ayant ce code même si le RSA ne l'a pas ?

[SteffieLili]

Contente d'avoir pu être un peu plus claire Formulary

J'ai pris toute la matinée pour bien comprendre votre code, l'appliquer et le tester. Cela résout mon problème de donnée absente en fonction que l'on requête sur les RUM ou sur les RSA.

Si j'ai bien compris, dans mon modèle "vectoriel", je suis en présence de deux tables de fait : RSA et RUM. Elles sont liées par Id_RSA généré par la concaténation de FINESS et index_RSA ( en fait, index_RSA n'est pas clé primaire dans ma base de données, ce champs me génère des doublons).

Ensuite, dans l'intégration des données aux champs communs qui posent problème, je peux soit réaliser des tables à part avec les codes liés à mes tables de fait (mais cette solution là, je ne l'ai pas très bien comprise ), soit inclure les champs qui m'intéressent directement dans la table en les implémentant à l'aide d'un JOIN LOAD. En implémentant ce JOIN, j'ai remarqué que les établissements n'ayant pas de RSA sont bien comptabilisés, cela réalise donc une jointure externe. Ai-je bien compris ?
Pour l'analyse des données, j'ai réalisé des conditions pour, si on se situe sur un RUM, prendre les rumEtab, et sur un RSA prendre les rsaEtab, cela pour être bien sur d'avoir nos données qui se croisent.

En ce qui concerne l'implémentation, j'ai dû réaliser préalablement un LOAD sur les tables établissements aquitains et THS_CIM10 pour que le "resident" puisse se faire. Cela est obligatoire il me semble. Ai-je raison ?

Faut-il sélectionner tous les RSA ayant ce code + les lignes RUM ayant ce code,

Oui, je pense qu'il faudra pouvoir sélectionner un code qu'il soit RSA ou RUM, je pense que cela ne doit pas trop poser de problème avec le JOIN non ?

ou toutes les lignes RUM d'un RSA ayant ce code + les lignes RUM ayant ce code même si le RSA ne l'a pas ?

Alors oui, il faut que je sois capable de sortir les RSA mono ou multi-RUM par exemple. Savoir quel RUM appartient à quel RSA et les codes des DP et DR des RUM doivent ressortir pour avoir une granularité plus fine. Certains codes de ces RUM n'appartiendront donc pas aux RSA.
J'ai l'impression qu'avec le JOIN LOAD, cela marche plutôt bien pour requêter dans ce sens.

Je vais essayer d'implémenter la table DAS maintenant.
Ma compréhension de la nouvelle modélisation est-elle bonne ?

Merci encore Formulary

[FORMULARY]

En ce qui concerne l'implémentation, j'ai dû réaliser préalablement un LOAD sur les tables établissements aquitains et THS_CIM10 pour que le "resident" puisse se faire. Cela est obligatoire il me semble. Ai-je raison ?

Oui, Resident signifie qu'il prend les infos dans la table vectorielle qu'il a en mémoire. Il faut donc qu'elle soit déjà chargée dans le script au moment où on veut l'utiliser.

il faut que je sois capable de sortir les RSA mono ou multi-RUM par exemple. Savoir quel RUM appartient à quel RSA et les codes des DP et DR des RUM doivent ressortir pour avoir une granularité plus fine. Certains codes de ces RUM n'appartiendront donc pas aux RSA.
J'ai l'impression qu'avec le JOIN LOAD, cela marche plutôt bien pour requêter dans ce sens.

Le probleme ne vient pas du join load. Il sert à récupérer les libellés de code dans la table RSA ou dans la table RUM.
Le souci, mais là tout dépend de ce que vous voulez faire, c'est quand vous avez par exemple cette table :

Code :

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

1
2
3
4
5
6
7
8
9
10
RSA:
IdRSA   rsaCode
RSA01  C1
RSA02  C2
RUM:
IdRUM   idRSA   rumCode
RUM01  RSA01   C1
RUM02  RSA01   C2
RUM03  RSA02   C1
RUM04  RSA02   C2

Si je clique sur rsaCode C1, je vais sélectionner RSA01 et donc RUM01 et RUM02. RUM03 ne sera pas sélectionné.
Ca peut vous convenir tout à fait, mais c'est là qu'il y a un "risque" dans vos sélections et donc dans le résultat de vos expressions.
Tout va donc dépendre des expressions que vous allez utiliser et des sélections que vous allez faire.
J'espère avoir été suffisamment clair

[SteffieLili]

C'est tout à fait clair avec le petite exemple bien illustré Formulary

Dans le "requêtage", il va falloir choisir un code soit sur une granularité de type RSA, soit sur une granularité de type RUM. Ainsi, dans votre exemple, cela ne pose aucun problème.
Cependant, cette manière d'intégrer les données risque de poser un problème pour la table DAS (qui intègre une nature supplémentaire aux codesRSA ou codesRUM), un DAS est comme un DP ou un DR sauf qu'ici c'est une table à part que l'on peut lier au RUM et au RSA.
Ici, il va falloir, en sélectionnant un codeRUM ou un codeRSA, donner tous les idRSA par exemple (ou idRUM) quelque soit la nature de ce code (DP,DR ou DAS). Et là, cela coince au niveau des DAS.

J'ai donc un peu changé l'implémentation pour la table DAS avec le script suivant :

Code :

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

1
2
3
4
5
6
7
8
// ############################## CHARGEMENT DE LA TABLE DE DIMENSION DAS ######################################################
DAS:
LOAD
	FINESS & '-' & index_RSA & '-' & index_RUM AS Id_RUM,
	'DAS' as Nature,
	DAS as Code;
 
SQL SELECT * FROM DAS;

Du coup, la table DAS est jointe sur la granularité la plus fine (RUM) et la table THS_CIM10 est jointe à la table DAS via Code.

Cela me donne les tables suivantes :



Cela peut-il répondre à mon besoin de requêter sur tous les codes ? J'ai l'impression que cela marche !
Après, cela me donne un affichage pas top, puisque ce qui aurait été bien, c'est d'avoir une liste de sélection NatureRSA avec les DP,DR et DAS dedans, et pareillement pour les RUM. Là, cela me donne un affichage comme tel :



EDIT : En fait, cela ne marche pas pour les DAS, si on requête sur un code RSA, on ne prendra que les DP ou les DR. Avez vous une solution pour palier à ce problème ?