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
L’imagerie Médicale Dans une Base
De Données Distribuée Multimédia Sous Oracle 9i.
Djema L*,
Boumghar F.O** ,
Dépt. Informatique,
Université Tizi-ouzou ,
Algérie ,
Debiane S*
Dépt. Informatique
Université Tizi-ouzou
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).
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.
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.
1
SETIT2007
• Optimiser les accès aux données en offrant des
outils d’indexation spécialisés.
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.
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.
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.
Interface usager (client)
EDITION
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.
PRESENTATION
Présentations multimédias
Aspects spatio-temporels
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.
Composition
Synchronisation
SERVEUR d’OBJETS
Schéma, stockage, objets complexes,
indexation, interrogation, mises à jour,
transactions, règles actives
1. SGBD multimédias
Figure 1.
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.
Architecture fonctionnelle
d'un SGBD multimédia
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.
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.
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.
2
SETIT2007
• 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.
user
Entrepôt
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.
Source1
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.
ƒ
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).
Système n
user
Médiateur
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 :
Adaptateur1
• 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.
Source1
Adaptateur 2
Adaptateur n
Source2
Source n
Figure 3 : Intégration par le médiateur.
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).
ƒ
Source n
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.
Un système d’intégration se compose de deux
parties :
•
…
Figure 2 : Intégration par entrepôt.
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.
•
Source2
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.
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).
3
SETIT2007
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.
ƒ
ƒ
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.
ƒ 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.
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
ƒ 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.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.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
3.2 Formalisation du mapping
Nous formalisons notre problème d’intégration, en
mettant en évidence ses entrées, et ses sorties.
4
SETIT2007
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.
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
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.
Ai : RGi < Ki,Ai1, Ai2, …,Aim >
Soit RL l’ensemble des relations locales noté :
RL < RL1, RL2, …, RLl > ,
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.
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
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.
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 = { <, >, =, <=, >= }
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.
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
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.
Avec :
LA < A1, A2, …, At > : ensemble des attributs à
projeter
LT : ensemble de tables du schéma global.
‘’Ci ‘’ : ensemble des conditions.
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 :
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
ƒ Service des urgences (admission du patient).
5
SETIT2007
ƒ Service radiologie standard (Avis spécialiste +
clichés radio)
ƒ Service exploration (Avis spécialiste + IRM et/ou
scanner)
notre approche décrite au chapitre 3. Ce modèle prend
en considération la correspondance (le mapping) entre
le schéma global et les schémas locaux des données
ainsi que leur localisation dans les différentes sources.
L’objectif consiste à créer un dossier médical qui
sera alimenté partiellement au niveau de chaque service
et consulter totalement d’une façon transparente par
tous les services, ce qui donnera lieu à ce qu’on appelle
le dossier médical partagé (distribué).
La figure 4 montre les cas d’utilisation de notre
système d’information.
Le médiateur contiendra les tables suivantes :
• Table_ relation (Num_rel, Nom_rel , Type_rel
, Num_relg , Num_source )
• Table_attribut (Num_attribut , Nom_attribut ,
Type_attribut )
• Relation_atttribut (Num_rel , Num_attr ,
Nature )
• Source (Num_source , Nom )
• Relation_loc_predicat
( Num_rel_loc ,
Num_p )
• Predicat ( Num_p , Num_attr , operateur ,
valeur )
4.2. Le diagramme de classe global
A partir des diagrammes de séquences et des cas
d’utilisation, nous avons déduit un réseau de classes et
d’associations qui nous permettent de modéliser la
structure de chaque objet, et ses relations avec les autres
objets du système.
La figure 5 montre le schéma
du diagramme des classes.
Spécialiste
Medecin
Attributs
Attributs
Enregistrer
Patient
Fonctions
Fonctions
Pratique
Attributs
Examiner
Patient
Medecin_ur
Patient
Medecin-traitant
Demande
examen
Consulter
compte rendu
radio
Demande
Examen
Radio
Consulter
compte rendu
exploration
Consultation
Attributs
Attributs
Fonctions
Demande
Examen
scanner
Fonctions
Demande
Examen
IRM
Demande_examen
Attributs
Attributs
Fonctions
Fonctions
Enregistrer
Cliché
Consulter
Dossier
Medecin_rs
Consulter
demande
Examen radio
Radio
IRM
Scanner
Attributs
Attributs
Attributs
Fonctions
Fonctions
Fonctions
Figure 5 : Diagramme de classe global.
Consulter
Demande
Examen IRM
Consulter
demande
Examen scanner
La figure 6 montre le modèle logique du médiateur.
Afin d’illustrer ce modèle logique, nous considérons
un exemple simple composé d’une seule relation
globale Médecin, qui sera fragmenter horizontalement
pour obtenir trois relations locales distribuées sur trois
sites ( fig 7).
Enregistrer
Medecin_ex
Enregistrer
IRM
Enregistrer
Scanner
Médecin ( num_med, nom, prénom, spécialité, service)
Figure 4. Diagramme de cas d’utilisation
4.3. Modèle logique du médiateur
Considérons les trois sources de données :
Dans ce que suit, nous allons décrire la structure du
médiateur sous forme de tables reliés conformément à
6
SETIT2007
Source1 :
medecin1 (num_med,
spécialité, service)
Tel que service= urgence.
Source2 :
medecin2 (num_med,
spécialité, service)
Tel que service= radiologie.
Source3 :
medecin3 (num_med,
spécialité, service)
Tel que service= exploration.
nom,
nom,
prénom,
à-dire que ces relations sont des fragments de la relation
globale 4.
La relation1 contient les attributs 1,2,3,4,5 (table
Rel_attribut) dont les nom sont décrits dans la table
Attributs. C’est pareil pour les autres relations.
prénom,
Les critères de localisation des relations 1,2,3
sont représentés dans la table Prédicats.
nom,
prénom,
Médecin(num_med,
nom,
prénom,
spécialité, service).
Medecin1
(num_med,
nom, prénom,
spécialité,
service)
service=
urgence.
Medecin2
(num_med,
nom, prénom,
spécialité,
service)
service=
radiologie.
Medecin3
(num_med,
nom, prénom,
spécialité,
service)
service=
exploration.
S3
S1
S2
Figure 7 : Exemple de fragmentation d’une
L’implémentation
sous Oracle nous donne la
structure de la vue suivante :
Create View Medecin as
Select num_med, nom, prénom, spécialité, service from
Medecin1@site1
Where service= ‘urgence’
Union
Select num_med, nom, prénom, spécialité, service from
Medecin2@site2
Where service= ‘radiologie’
Union
Select num_med, nom, prénom, spécialité, service from
Medecin3@site3;
where service= ‘exploration’
L’interrogation de cette vue nous permet d’obtenir
toutes les informations concernant les médecins avec
une totale transparence.
4.4 Environnement logiciel.
Les relations locales 1,2,3 (respectivement
Médecin1,Médecin2, Médecin3) correspondent à la
relation globale 4 (Médecin). Ces relations sont
distribuées sur les trois sites 1,2,3 (table Source), c'est-
Nous utiliserons l’environnement Windows XP
pour implémenter notre système de développement
Oracle 9i.
7
SETIT2007
4.5.1. Indexation
Pour permettre au système de gestion de base de
données de traiter les documents efficacement, ceux-ci
doivent subir une indexation documentaire. Cette
indexation permet de dégager l'information nécessaire
pour leur repérage des listes, tables ou index.
L'indexation des documents textes génère une structure
complexe de données, alors que celle des images
consiste en la génération d'une signature binaire. C'est la
méthode analyze() qui s'occupe de générer la signature
de l’image, composée d'informations relatives aux
couleurs, à la structure et à la texture de l'image. La
comparaison d'image se fera alors uniquement à partir
de cette signature.
Outre le SGBD, la solution Oracle est un véritable
environnement de travail constitué de nombreux
logiciels permettant d’offrir des outils très performants.
On citera notamment :
•
•
•
•
•
Les outils d'administration du SGBD.
Les outils de développement
Les outils de communication
Les outils de génie logiciel
Les outils d'aide à la décision
4.4.1 Présentation d’Oracle Net.
Oracle Net, est un ensemble d’outils réseau
d’Oracle, qui peuvent être utilisés pour se connecter à
des bases de données distribuées. Oracle Net facilite le
partage de données entre plusieurs bases, même si ces
dernières sont hébergées sur des serveurs qui
s’exécutent sur des systèmes d’exploitation et des
protocoles de communications différents.
4.5.2. Stockage interne des données
Les données volumineuses que nous aurons à traiter
se rapportent à des photos de radiologie, de scanner et
d’IRM. Elles seront décrites dans la table des attributs (
fig 8) et seront déclarées de types Blob. Vu leur nature
confidentielle, ces données seront stocker à l’intérieur
de la base de données pour bénéficier du système de
sécurité d’accès à la base.
L’architecture la plus courante et rentable utilisé
avec Oracle Net est celle de client léger, autrement
appelée architecture trois-tiers. Le code de l’application
est maintenu et exécuté au moyen de scripts Java sur un
serveur séparé de celui de base de données.
Oracle met à la disposition des administrateurs de
bases de données différentes méthodes et utilitaires
pour réaliser le chargement de ces données dans la base,
citons
Ctxload,
SQL*LOADER,
DBMS_LOB.LOADFROMFILE().
En plus des implémentations client/ serveur et client
léger, des configurations serveur/ serveur sont souvent
nécessaires, comme pour notre cas, lorsqu’un serveur
envoie une requête de base de données vers un autre
serveur, l’émetteur joue le rôle de client
4.4.2. Assistant configuration Oracle Net
(Net
configuration assistante)
Cet assistant dispose d’une interface utilisateur
graphique pour effectuer les étapes de configuration
initiales du réseau après l’installation d’oracle.
Num_atribut
………
…….
18
19
20
21
22
23
24
25
26
27
28
……..
Dans ce qui suit, nous présentons les différentes
étapes de configuration pour nos trois bases de données
(ORAL1, ORAL2, ORAL3).
•
•
•
Listeners
- Nom du listner : listner_oracleDB
- Protocle de communication : TCP-IP
- Port de comunication : 1521( port standard)
Méthode de résolution de noms : Oracle Names
Noms de services de réseau local :
- Nom de la base de données : ORAL1
- Nom d’hote ( machine ) : sys1
La même procédure sera réalisée sur les sites des
deux autres bases ORAL2 et ORAL3.
Nom_attribut
………….
………..
Num_radio
Photo_radio_gif
Interpret_radio
Num_scan
Photo_scan_gif
Interpret_scan
Num_IRM
Photo_IRM_gif
Interpret_IRM
Num_med_tr
Nom_med_tr
……………..
Type_attribut
……..
……..
Number
Blob
Long
Number
Blob
Long
Number
Blob
Long
Number
Varchar2
………
Figure 8 : Aperçu de la table des attributs
4. 5. Gestion de données multimédia avec Oracle
4.6. Environnement matériel.
Les données multimédias Oracle sont gérées par une
des extensions de la base de données Oracle qui permet
de faire de la recherche de documents au travers des
interrogations plus ou moins complexes, selon le genre
de documents. Oracle interMedia est capable aussi de
gérer des documents textes, des sons, des images et des
vidéos. L'ensemble des documents peut être stockés et
diffusés, les images et les textes disposants de plus de
fonctionnalités, via leurs index.
Pour l’implémentation de notre application, nous
avons utilisés un réseau de trois PCs. Chaque machine a
été installée dans l’un des trois services cités au
paragraphe 4.1. Les trois machines possèdent la même
configuration matérielle suivante :
- Microprocesseur Intel Pentium 4
- Fréquence d’horloge : 1.4 GHz
- Capacité disque dur : 40 Go.
8
SETIT2007
Decentralized System, 2002. 6-7 Nov. 2002
Pages:132 – 139.
- Mémoire RAM : 512 Mo.
- Carte réseau Realtek RTL 8139/810X Family
PCI Fast Ethernet NIC
[7]. Ozsu, M.T & Valduriez, P.;Distributed database
systems: w here are we now? Computer Volume 24,
Issue 8, Aug. 1991 Pages :68 – 78.
5. Conclusion.
Jusque là, les travaux réalisés sur l’imagerie
médicale ont surtout portés sur l’implémentation de
banques de données d’images médicales et les
différentes méthodes d’accès à ces informations. Notre
approche est d’associer dans une même base de données
des objets de type classique et des objets de type LOBs.
La finalité de ce travail est donc de mettre à la
disposition du corps médical un outil de travail qui leur
faciliterait la gestion des dossiers médicaux des malades
en y incluant des données multimédias telles que les
diagnostics de type texte classique et les images
médicales (LOBs) qui peuvent être d’origine
radiologique, IRM ou scanner.
[8]. Payne, A Designing the databases of the intelligent
network. Software Engineering for Telecommunication
Systems and Services, 1992.
[9]. Razvan Bizoi ; Oracle 9i SQL/PLSQL ,
Edition Eyrolles 03
Bien que l’implémentation de notre base de données
distribuée soit limitée à trois services médicaux
( urgence, radiologie et exploration) , les malades
peuvent passer d’un service à un autre pour des subir les
examens nécessaires sans déplacer leur dossier.
Les médecins traitants ont accès à toutes les
informations concernant leur patient de façon
transparente, sans se soucier du site où se trouve
réellement l’enregistrement physique des données.
Si le travail réalisé dans cette première étape, permet
de faciliter la gestion des données (consultation et
stockage) qui se trouvent réparties sur des sites distants,
il serait très intéressant d’associer à cette base de
données distribuée, des outils de traitement sur
l’imagerie médicale qui faciliteront l’aide à la décision
du médecin. Nous pensons que cette extension
constituera la deuxième étape de ce travail.
REFERENCES.
[1]. Braham, T.O, Integrating of inherit and reference links
in the building of an object distributed database management
system Database and Expert Systems Applications, 1997
[2].G. Gardarin, P. Valduriez; SGBD AVANCES, Bases de
données objet, déductives, réparties . Edition Eyrolles
1991.
[3]. Georges et Olivier Gardarin ; Le client-Serveur ;
Edition Eyrolles 1996.
[4]. Johnson, R.B.; Internet multimedia databases
Multimedia Databases and MPEG-7,
IEE Colloquium 29 Jan. 1999
[5]. Kalipsiz, O. ; Multimedia databases
Information Visualization, 2000.
IEEE International Conference
19-21 July 2000 Page(s):111 – 115.
[6]. Munir, K.; Waseem Hassan, M.; Ali, A.; McClatchey,
R.; Willers, I.; Database independent migration of
objects into an object-relational database , Autonomous
9