L`imagerie Médicale Dans une Base De Données Distribuée

SETIT 2007
4th International Conference: Sciences of Electronic,
Technologies of Information and Telecommunications
March 25-29, 2007 – TUNISIA
1
L’imagerie Médicale Dans une Base
De Données Distribuée Multimédia Sous Oracle 9i.
Djema L*, Boumghar F.O** , Debiane S*
Dépt. Informatique, Dépt. Informatique
Université Tizi-ouzou , Université Tizi-ouzou
Algérie , Algérie
* [email protected]
*[email protected]
Laboratoire LRPE
USTHB- A1LGER
Algérie
** [email protected]
Résumé :
L’objectif de notre travail est d’implémenter une base de données distribuée sur trois sites distants ainsi qu’un
schéma médiateur, sous le Système de Gestion de Bases de Données (SGBD) Oracle9i. et de réaliser l’interopérabilité
de ces trois bases. Nous réaliserons à travers cette base, la gestion des données se rapportant aux dossiers médicaux des
patients.
Il s’agit se placer non pas au niveau d’une informatique centralisée mais plutôt dans le contexte des systèmes
distribués de grande taille combinant réseaux hauts débits avec plusieurs usagers répartis sur des sites distants. On
arrive alors au concept de base de données multimédia distribuée dont les architectures physiques peuvent intégrer
différentes sources (hétérogènes) de données mais qui doivent rester transparentes par rapport au poste client.
Le système d’intégration de données que nous proposons est un système à base médiateur en utilisant l’approche
GAV (Global as View). Les données seront stockées au niveau source, et le médiateur sauvegarde à son niveau leurs
descriptions (sous forme de vues virtuelles). Nous considérons que les schémas des sources locales sont définis comme
étant des fragments d’un schéma global.
En plus des données classiques, un dossier médical peut également contenir des données volumineuses se rapportant
à l’imagerie médicale et qui peuvent être d’origine radiologique, IRM ou scanner. Nous utiliserons un nouveau type de
données définit par SQL, qui permet de stocker dans un champ un gros volume d'informations, Il s'agit des LOBs (Large
OBject).
Mots clés : Base distribuée, Multimédia, Médiateur, imagerie médicale, Oracle9i, LOB (Large OBjet).
INTRODUCTION
Les révolutions technologiques intervenues dans le
domaine des réseaux de communications ont permis à
l’approche base de données distribuée de devenir une
solution alternative à la centralisation.
Les bases de données distribuées représentent un
ensemble de bases stockées sur plusieurs ordinateurs,
qui se comporte vis-à-vis des applications utilisatrices
comme une base de données unique. Elles permettent de
rassembler des données plus au moins hétérogènes au
sein d’un réseau sous forme de base de données globale.

SETIT2007
2
Les bases de données multimédias se trouvent à la
croisée de l’évolution des bases de données et de
l’émergence du multimédia en informatique où de
nombreuses applications ont besoin de traiter des
données non conventionnelles.
Les systèmes multimédias popularisés par des
logiciels disponibles sur ordinateur personnel,
permettent la manipulation de plusieurs types de
données : textes, images, sons, vidéos. Ils offrent les
fonctions de capture des données (caméra ou carte
d’acquisition, par exemple), de construction et
d’exécution de petits scénarios ou présentations
multimédias combinant différents objets. Les objets
multimédias sont en général stockés individuellement
dans des fichiers traditionnels et l’un des challenges
intéressant, consiste à combiner les fonctions de ces
systèmes multimédias avec ceux des SGBDR. Il s’agit
aussi de se placer non pas au niveau d’une informatique
personnelle mais plutôt dans le contexte des systèmes
distribués de grande taille combinant réseaux hauts
débits et larges communautés d’usagers répartis sur des
sites distants. On arrive alors au concept de base de
données multimédia distribuée dont les architectures
physiques peuvent intégrer différentes sources
(hétérogènes) de données mais qui doivent rester
transparentes par rapport au poste client.
L’objectif de notre travail est d’implémenter une
base de données distribuée sur trois sites distants ainsi
qu’un schéma médiateur, sous le système de gestion de
bases de données Oracle9i. et de réaliser
l’interopérabilité de ces trois bases.
A cette fin, l’environnement d’implémentation, à
savoir le système d’exploitation et le langage de
programmation que nous utiliserons pour le
développement de notre application sont respectivement
Windows XP et les Langages SQL et PL\ SQL.
1. SGBD multimédias
1.1. Caractéristiques d’un SGBD multimédia
Une base de données multimédia contient des
informations conservées sous différents formats
multimédias : fichiers sons, fichiers photo, séquence
vidéo, données textes ect.. Le volume constitue une des
principales caractéristiques de ces données qui peuvent
atteindre quelques gigaoctets.
A la lumière des caractéristiques que nous venons de
citer, un SGBD multimédias doit pouvoir :
• Stocker des objets de gros volumes de données.
• Offrir des outils de modélisation (modèle, langage
de définition de données) pour prendre en compte
la nature spécifique des objets et les opérations
associées.
• Mettre à la disposition des usagers des langages et
des interfaces spécifiques pour la manipulation et
l’interrogation de ces données.
• Optimiser les accès aux données en offrant des
outils d’indexation spécialisés.
1.2. Architecture fonctionnelle d’un SGBD
multimédia
La figure 1 présente une architecture fonctionnelle
en couches pour un SGBD Multimédia. Au plus bas
niveau figure un serveur d'objets qui prend en compte
les aspects structurels et le volume des données.
Généralement un SGBD classique peut servir à réaliser
cette couche mais il doit être étendu si l’on veut gérer
les différents aspects des données multimédias qui ont
été décrits plus haut. Cette extension constitue une
couche logicielle qui se place au dessus du serveur
d’objets et qui est spécialement conçue pour traiter les
aspects spatiaux et temporels, par exemple. Ainsi elle
permet la composition et la présentation d'objets qui
sont gérés de manière naturelle au niveau de l'interface.
1. 3. Les LOBs (Large OBjets)
Un LOB (Large OBject) est un nouveau type de
donnée qui permet de stocker dans un champ un gros
volume d'informations.
1. 3.1. Qu’est-ce qu'un LOB?
Il existe différents types de LOBs. Ceux qui sont
stockés dans la base de données (LOB interne) et ceux
qui sont stockés en dehors de la base de données (LOB
externe). Les LOBs externe sont référencés dans la base
par un pointeur.
¾ LOB interne :
• BLOB (Binary Large Object): Dédié aux données
binaires.
EDITION PRESENTATION
Interface usa
g
er
(
client
)
Présentations multimédias
Aspects spatio-temporels
SERVEUR d’OBJETS
Schéma, stockage, objets complexes,
indexation, interrogation, mises à jour,
transactions, règles actives
Composition Synchronisation
Figure 1. Architecture fonctionnelle
d'un SGBD multimédia

SETIT2007
3
• NCLOB (National Character Large Object) : Dédié
pour les chaînes de caractères Unicode.
¾ LOB externe :
• BFILE (Binary File): Dédié aux fichiers de données
stockés dans le système de fichier du système
d'exploitation.
2. Intégration de Sources de données
Un système d’intégration de données doit offrir aux
utilisateurs une vue uniforme des sources de données
qu’il exploite, et permettre de les interroger d’une
manière transparente, alors qu’il s’agit de données
distribuées sur plusieurs sites.
Il fournit une vue unifiée des données provenant de
sources multiples et permet d'accéder à ces données au
travers d'une interface, sans se soucier de leur structure
ni de leur localisation.
Un système d’intégration se compose de deux
parties :
• Une partie externe qui correspond aux utilisateurs
du système intégré
• Une deuxième partie qui comprend des sources
d’information participantes au processus
d’intégration, et une interface uniforme qui
permet aux utilisateurs ou autres systèmes (de
partie externe) d’interroger d’une manière
transparente les sources de données. Les éléments
externes voient donc le système comme une
source unique, le schéma global de cette source
unique est appelé le « schéma intégré » par lequel
l’interrogation doit se faire.
2.1. Classification des systèmes d’intégration
La classification des systèmes d’intégration qui a
été proposée se base sur les deux critères suivants :
• la localisation des données intégrées, qu’elles
restent dans les sources originales, ou qu’elles
migrent vers le système global.
• La nature de correspondance entre schéma
global et schémas locaux.
2.1.1. La localisation des données intégrées.
Il existe principalement deux architectures
physiques possibles pour les systèmes d ‘intégration de
données, lorsque les données des sources sont stockées
dans le système d’intégration on parle d ‘approche
matérialisée (entrepôt de données) en utilisant des vues
matérialisées, a l’inverse, lorsque les données intégrées
ne sont pas répliquées, on parle d’approche virtuelle
(système médiateur).
 L’approche matérialisée « Entrepôt »
L’approche matérialisée consiste à stocker
localement des données issues des différentes sources
de données dans un entrepôt de données en utilisant des
vues matérialisées. Pour donner une vue globale des
sources à intégrer, les données provenant de différentes
sources distribuées doivent être organisées, intégrées et
stockées dans l’entrepôt (fig 2).
Cette matérialisation permet d’accélérer le
traitement des requêtes car il n’est pas nécessaire
d’accéder aux sources pour y répondre, par contre elle
exige un coût de stockage très important et surtout un
coût de mise à jour, toute modification dans les sources
locales doit être répercutée sur l’entrepôt de données.
 L’approche virtuelle « Médiateur ».
Dans cette approche, les données ne sont pas
stockées au niveau du médiateur. Elles restent dans les
sources de données et ne sont accessibles qu’à ce niveau
par l’intermédiaire des vues traditionnelles. C’est pour
cette raison que cette approche est appelée approche «
virtuelle » ( fig 3).
La médiation repose sur deux composants essentiels :
• Le médiateur : joue le rôle d’interface entre
l’utilisateur et les sources d’information en donnant
l’impression qu’il interroge un système centralisé et
homogène.
• L’adaptateur : il s’agit d’une interface entre le
médiateur et les sources de données, il fait la
traduction de données dans un modèle commun de
données dans un sens médiateur /source ou
source /médiateur.
Un programme qui transforme les requêtes
spécialisées du médiateur en des requêtes
exécutables sur les sources.
Entre
p
ô
t
Source1 Source2 Source n
user
…
Figure 2 : Intégration par entrepôt.
Figure 3 : Intégration par le médiateur.
Source1 Source2 Source n
user
Adaptateur1 Adaptateur 2 Adaptateur n
Médiateur
Système n

SETIT2007
4
2.2. La nature du mapping.
La méthode la plus ancienne pour définir un schéma
intégré est la correspondance entre le schéma global et
les schémas locaux, Il existe principalement quatre
méthodes pour construire le schéma médiateur d'un
système d'intégration de données : les approches GAV
(Global as View) et LAV (Local as View), GLAV
(Global Local as View) et BAV (Both as View ).
 Global as View (GaV)
Cette approche suppose donc que les sources à
intégrer soient connues à l’avance.
Le point faible de cette approche est qu’elle ne
permet pas l’ajout de nouvelles sources de données. Cet
ajout peut entraîner un modification du schéma
médiateur car les vues qui le définissent seront
modifiées.
 Local as View (LaV) .
A l’inverse de l’approche GaV, l’approche LaV
suppose que le schéma global est défini
indépendamment des sources. Son principe consiste à
définir les sources à intégrer comme des vues sur le
schéma médiateur.
L’approche LaV est flexible par rapport à l’ajout (ou
la suppression) de sources de données à intégrer, cela
n’a aucune incidence sur le schéma global, il suffit pour
cela de spécifier les vues qui permettent d’intégrer
(supprimer) la nouvelle source.
 Global local as view (GLaV) et both as view
(BaV) .
Sont deux approches qui combinent les capacités
des deux approches précédentes. Elles ne suscitent pas
notre intérêt car leur implémentation dans un système
d’intégration est complexe.
3. Notre approche.
Le système d’intégration que nous proposons est un
système à base médiateur en utilisant l’approche GAV.
Les données seront stockées au niveau source, et le
médiateur sauvegarde à son niveau leurs descriptions
(sous forme de vues virtuelles). Nous considérons que
les schémas des sources locales sont définis comme
étant des fragments d’un schéma global. Le choix de
cette approche est largement motivé par la simplicité de
son implémentation, sachant que les sources de
données à intégrer sont connues d’avance. Comme
l’interrogation du système se fait généralement en
formulant des requêtes sur le schéma global, on obtient
facilement une requête en terme du schéma des sources
de données intégrés en remplaçant les prédicats du
schéma global par leurs définitions.
3.1 Architecture du médiateur
3.1.1 Tâches de médiateur
Pour bien répondre aux besoins d’un système
d’intégration, un médiateur doit assurer les tâches
suivantes :
 Sauvegarde des informations pertinentes
concernant les schémas de sources de données ainsi
que leur contenu. Les correspondances entre le
schéma global et les schémas locaux doivent être
également représentés.
 Traitement des requêtes des utilisateurs qui posent
leurs requêtes sur le schéma global défini sur le
médiateur.
 Localisation des sources de données pertinentes.
 Reformulation de la requête utilisateur en des
requêtes sur les schémas locaux.
 Récupération des résultats obtenus à partir de
l’interrogation des sources.
 recomposition des résultats retournés.
 Optimisation de requêtes.
3.1.2 Les composantes du médiateur
Notre système d’intégration a une architecture à 3
niveaux (appelées architecture 3-tiers) :
 La couche utilisateur ;
 La couche médiateur ;
 la couche de données qui représente les sources
de données.
3.1.2.1 La couche utilisateur
Cette couche concerne les utilisateurs du système
intégré. Elle permet de l’interroger et récupérer les
résultats des requêtes. Dans notre travail, la requête d’un
utilisateur est équivalente à une requête SQL définie sur
le schéma global :
SELECT liste attributs (LA)
FROM liste tables (LT)
WHERE condition1
AND condition2
AND ….
GROUP BY liste attributs
HAVING condition1
ORDER BY liste attributs
Où :
« LA » : ensemble d’attributs à projeter.
« LT » : ensemble de tables du schéma global.
Notons que le médiateur n’évalue pas directement
les requêtes qui lui sont posées car il ne dispose que de
la description des données qui sont stockées de façon
distribuée dans des sources indépendantes. Chaque
source de données est décrite comme un fragment du
schéma global
3.1.2.2 La couche médiateur
Elle permet de localiser chaque fragment entrant
dans la composition d’une relation globale. Lors de
l’exécution d’une requête globale, cette dernière est
décomposée en sous requête locales pour accéder aux
fragments en s’appuyant sur la description des sources
de données au niveau du médiateur.
3.1.2.3 La couche de données
Cette couche est représentée par les sources de
données participantes au système d’intégration dont
leurs descriptions sont schématisées dans la couche
médiateur.
3.2 Formalisation du mapping
Nous formalisons notre problème d’intégration, en
mettant en évidence ses entrées, et ses sorties.

SETIT2007
5
Nous définissons le schéma global SG avec n
relations globales
RG : ( SG < RG1, RG2,…, RGn>).
Soit S l’ensemble de sources de données, noté :
S < S1, S2, …, Ss >
Chaque relation globale RGi est caractérisée par un
ensemble d’attributs et une clé primaire Ki qui peut être
composée de plusieurs attributs
Ai : RGi < Ki,Ai1, Ai2, …,Aim >
Soit RL l’ensemble des relations locales noté :
RL < RL1, RL2, …, RLl > ,
où chaque relation RLj est associé à une seule source et
à une relation globale. Elle est décrite comme suit :
RLj < Kj, Aj1, Aj2, …,Ajl , RGj , Sj> ,
où :
 RLj
∩ RGi ≠ φ
 Kj =Ki (Ki est la clé de sa relation globale
RGj)
 Sj sa source
Soit P < P1, P2, …..,Pp > l’ensemble de prédicats
simples définissant les relations locales (en cas de
fragmentation horizontale). Chaque prédicat Pi est défini
par un attribut Ai, un opérateur Oi et une valeur Vi tel
que : Oi = { <, >, =, <=, >= }
Soit Q une requête posée sur le schéma global du
médiateur dont la structure est la suivante :
SELECT liste attributs (LA)
FROM liste tables (LT)
WHERE C1
AND C2
AND ….
GROUP BY liste attributs
HAVING condition1
ORDER BY liste attributs
Avec :
LA < A1, A2, …, At > : ensemble des attributs à
projeter
LT : ensemble de tables du schéma global.
‘’Ci ‘’ : ensemble des conditions.
Cette requête globale Q (LT, LA, C) est traduite sur
les relations locales comme suit :
Q (LT, LA, C) = Q (RLi1, LAi1, Ci1) ∧
Q (RLi2, LAi2, Ci2) ∧ Q (RLi3, LAi3, Ci3) ∧ ….
3.3. Structures des tables de description de sources
de données.
3.3.1 La Table Relation
Cette table contient toutes les relations du système
intégré. Chaque relation est décrite par un identifiant, un
nom, un type (relation globale ou relation locale),
l’identifiant de sa relation globale (dans le cas d’une
relation locale), et le numéro de sa source.
relation (n, no, t, nr, ns)
∈ Relation ssi la relation de
numéro n et de nom no et de type t référençant une
relation globale (si n est une relation locale) de numéro
nr appartenant à la source ns.
3. 3. 2 La Table Attribut
Elle contient tous les attributs manipulés par le
système intégré. Chaque tuple de cette table est
caractérisé par un identifiant, un nom, et son type.
attribut(n, no, t)
∈ Attribut ssi l’attribut de numéro n a
pour nom no et de type t référençant un attribut d’une
relation globale ou locale.
3. 3. 3 La Table Source
Chaque source a un numéro et un nom
source(n, no)
∈ Source ssi la source de numéro n et de
nom no appartient à l’ensemble de sources
participantes au système d’intégration.
3.3.4 La Table Rel_attribut
Cette table représente l’association entre la table
relation et la table attribut. Elle contient les clés
primaires des deux tables plus un attribut Nature (de
type booléen) qui détermine si l’attribut est une clé
primaire ou pas.
(nr, na, nt)
∈ Rel_attribut ssi la relation nr a pour
attribut na de nature nt.
3. 3.5 La Table Prédicat
Elle contient tous les prédicats de tous les fragment,
chaque prédicat est décrit par un identifiant, l’attribut
sur lequel on applique la contrainte, l’opérateur et la
valeur de comparaison.
prédicat(n, na,o,v)
∈ Prédicat ssi le prédicat de numéro
n est définie sur l’attribut na avec l’opérateur o et sur
la valeur v.
3. 3.6 La Table Relation_loc_prédicat
Cette table représente l’association entre la table
relation (le cas où elle est représentée comme un
fragment horizontal) et la table prédicat. Elle contient
les clés primaires des deux tables.
(nr, np)
∈ Relation_loc_prédicat ssi le prédicat de
numéro np définie la relation locale de numéro nr.
4. Application
4.1. Introduction
Notre application porte sur l’informatisation d’une
partie du dossier médical du patient. On implémentera
une base de données distribuée sur les sites des
différents services médicaux que comptera un centre
hospitalier. Le dossier médical renfermera des
informations de nature différente (multimédia) et pour
les besoins de l’application son parcours se limitera aux
trois services suivants :
 Service des urgences (admission du patient).