Description du schéma Prise_SSR et de ses dimensions

Dans cette relation, il y aura un enregistrement pour chaque séjour effectué dans la partie long séjour d’un établissement (Soins de Suite ou de Réadaptation). La taille estimée pour la relation Prise_SSR est d’environ 4 millions d’enregistrements par an correspondants à des séjours hebdomadaires. La figure 3.9 représente le troi-sième schéma Prise_SSR.

Fig. 3.9 – Schéma en flocon de neigePrise_SSR

Un schéma de cube est un n-uplet Cs = (cn, M, D), où cn = Prise_SSR

M = {CompteJoursenwk, CompteJourshorswk}

D = {Etablissment, CIM10, Mode_sortie, Temps, Age, Zone_geo, Semaine_debut, Semaine_fin}

Un schéma de dimension est un n-uplet Ds = (dn, P, H), où dn = Semaine_debut P = {Cle_Semdebut} H = {∅} dn = Semaine_fin P = {Cle_Semfin} H = {∅}

Les autres dimensions ont été traitées au paragraphe 3.5.3.

Un schéma de hiérarchie est un n-uplet Hs = (hn, L, ≺)

A l’intérieur du cube Prise_SSR, nous avons les hiérarchies H_Geo et H_Temps, néanmoins, elles aussi ont été traitées au paragraphe 3.5.3.

3.6 Bilan

Dans ce chapitre, nous avons présenté la première partie de ce que nous appe-lons le processus de structuration. Nous avons conçu d’abord une architecture pour un système décisionnel basée sur trois composants, une interface graphique pour la génération semi-automatique des indicateurs, un entrepôt multidimensionnel qui rassemble les données internes et externes et les versions de schémas bitemporels.

Dans une deuxième phase, nous nous sommes focalisé sur le métamodèle et le mo-dèle multidimensionnel. Pour le métamomo-dèle, nous avons spécifié trois métaclasses : Cube, Dimension et Hiérarchie. Nous avons proposé un ensemble de définitions pour chaque métaclasse et leurs instances, ainsi qu’une définition d’une base de données multidimensionnelle et de son instance. Ceci nous a permis d’aboutir à la conception d’un schéma en constellation pour la construction d’un entrepôt multidimensionnel de données médicales. Nous avons utilisé les informations concernant l’ensemble des sources de données réelles et des indicateurs du projet ADELEM pour prouver et vérifier le modèle proposé.

Pendant la première étape de notre expérimentation, nous avons analysé les sources de données. Ceci nous a permis d’identifier deux types de données, les don-nées démographiques (RP99) et les dondon-nées publiques concernant la santé (RSA, RHA, CIM10 et FINESS). Principalement, dans ces dernières, nous avons constaté le besoin d’offrir des mécanismes pour une manipulation efficace de l’ensemble d’in-formation. Pour le projet, nous avons conçu un tableau d’analyse qui regroupe les données sur dix années. Ce tableau nous a permis d’identifier les sources qui ont besoin d’utiliser des techniques d’optimisation de stockage comme la création des agrégats.

L’analyse des indicateurs établis pour le projet nous a permis de les classer en trois types. Les deux premiers rassemblent les identificateurs d’offre "géographiques" et les identificateurs de consommation, de besoins et de flux "temporels". Le troisième type correspond à des nouveaux indicateurs également "temporels". Nous les avons identifiés comme des indicateurs de consommations et de flux. Ils nous permettent de faire des analyses par rapport à l’âge du patient ainsi qu’à son mode de sortie de l’hôpital.

multidimensionnel pour le projet. Nous avons conçu une constellation composée de trois schémas : Prise_MCO, Prise_SSR etPopulation, où chacun est composé de ses propres dimensions ainsi que des dimensions partagées pour l’ensemble de schémas. Nous avons utilisé les définitions proposées pour aboutir à la description des schémas.

Nous avons dit précédemment que l’ensemble des sources comporte aussi bien des données réparties et hétérogènes qu’externes au domaine médical. Ainsi, nous avons d’un côté des problématiques liées à la nature particulière des données médicales : type, format, sémantique, confidentialité, degré de fiabilité et de confiance, infor-mations manquantes ou incomplètes, et d’un autre côté l’hétérogénéité des données fournies par des organismes hors du contexte médical. Par exemple : les renseigne-ments sur l’origine géographique des patients pour la consommation de soins sont basés sur les codes postaux et non pas sur le code INSEE de la commune de rési-dence du patient.

Dans le chapitre suivant, nous décrivons la deuxième partie du processus de struc-turation. Elle consiste en la sélection de l’ensemble optimal de vues à matérialiser. Nous présentons aussi le fonctionnement de l’interface graphique conçue pour la génération semi-automatique de requêtes à partir des indicateurs.

Système d’aide à la décision

médicale : une expérimentation

Dans le chapitre précédent, nous avons décrit le modèle multidimensionnel conçu pour le projet ADELEM. Tout au long de ce chapitre, nous focalisons notre expéri-mentation sur un système décisionnel.

Nous avons divisé le travail réalisé en trois parties. La première décrit le schéma en étoile construit et la matérialisation de l’hypercube pour celui-ci. La deuxième partie traite le sujet des vues matérialisées qui nous permettent d’optimiser l’exé-cution de requêtes. Nous avons construit le schéma Adelem_MCO et nous avons crée la base de données correspondante en utilisant un échantillon du 10% des données réelles du projet. Nous avons utilisé le système décisionnel d’Oracle9i Entreprise Edition Release 9.2.0.1.0 pour la création du schéma et pour la génération des vues matérialisées. Ceci nous a permis de connaître le coût de stockage (représenté par le nombre de n-uplets du résultat) de chaque vue et de pouvoir facilement déterminer leur coût de calcul (produit des cardinalités approximatives des relations de base). Nous proposons un algorithme pour la sélection de l’ensemble optimal des vues à sélectionner qui utilise comme paramètres la fréquence d’utilisation, le coût de calcul et la probabilité de changement des relations de base. Nous terminons cette partie avec les relations de dépendance et la création des vues à matérialiser de cet en-semble optimal.

Finalement, la troisième partie se focalise sur le fonctionnement de l’interface pour la génération semi-automatique d’indicateurs. Nous donnons d’abord l’architecture pour cette interface et la description de ses composants. L’utilisation de l’interface requiert un module pour la création du schéma, ainsi, nous décrivons d’abord le fonctionnement de ce module, ensuite, nous classifions les types de requête à exécuter et finalement, nous décrivons le fonctionnement de l’interface graphique en utilisant un exemple de requête.

4.1 Construction du schéma

Dans cette section, nous décrivons la construction du schéma en étoileAdelem_MCO. Il est composé d’une relation de faits et de quatre relations de dimensions. Nous définissons d’abord la structure de chaque relation qui intègre le schéma et la ma-térialisation de l’hypercube.