SETIT 2007

4th International Conference: Sciences of Electronic, Technologies of Information and Telecommunications March 25-29, 2007 TUNISIA

Limagerie Mdicale Dans une Base De Donnes Distribue Multimdia Sous Oracle 9i.
Djema L*, Boumghar F.O** , Debiane S*
Dpt. Informatique, Universit Tizi-ouzou , Algrie , Dpt. Informatique Universit Tizi-ouzou Algrie

* ldjema@yahoo.fr *sofianedebiane@yahoo.fr

Laboratoire LRPE USTHB- A1LGER Algrie

** linda_oulebsir@yahoo.fr

Rsum : Lobjectif de notre travail est dimplmenter une base de donnes distribue sur trois sites distants ainsi quun schma mdiateur, sous le Systme de Gestion de Bases de Donnes (SGBD) Oracle9i. et de raliser linteroprabilit de ces trois bases. Nous raliserons travers cette base, la gestion des donnes se rapportant aux dossiers mdicaux des patients. Il sagit se placer non pas au niveau dune informatique centralise mais plutt dans le contexte des systmes distribus de grande taille combinant rseaux hauts dbits avec plusieurs usagers rpartis sur des sites distants. On arrive alors au concept de base de donnes multimdia distribue dont les architectures physiques peuvent intgrer diffrentes sources (htrognes) de donnes mais qui doivent rester transparentes par rapport au poste client. Le systme dintgration de donnes que nous proposons est un systme base mdiateur en utilisant lapproche GAV (Global as View). Les donnes seront stockes au niveau source, et le mdiateur sauvegarde son niveau leurs descriptions (sous forme de vues virtuelles). Nous considrons que les schmas des sources locales sont dfinis comme tant des fragments dun schma global. En plus des donnes classiques, un dossier mdical peut galement contenir des donnes volumineuses se rapportant limagerie mdicale et qui peuvent tre dorigine radiologique, IRM ou scanner. Nous utiliserons un nouveau type de donnes dfinit par SQL, qui permet de stocker dans un champ un gros volume d'informations, Il s'agit des LOBs (Large OBject). Mots cls : Base distribue, Multimdia, Mdiateur, imagerie mdicale, Oracle9i, LOB (Large OBjet). Les bases de donnes distribues reprsentent un ensemble de bases stockes sur plusieurs ordinateurs, qui se comporte vis--vis des applications utilisatrices comme une base de donnes unique. Elles permettent de rassembler des donnes plus au moins htrognes au sein dun rseau sous forme de base de donnes globale.

INTRODUCTION
Les rvolutions technologiques intervenues dans le domaine des rseaux de communications ont permis lapproche base de donnes distribue de devenir une solution alternative la centralisation. 1

SETIT2007 Les bases de donnes multimdias se trouvent la croise de lvolution des bases de donnes et de lmergence du multimdia en informatique o de nombreuses applications ont besoin de traiter des donnes non conventionnelles. Les systmes multimdias populariss par des logiciels disponibles sur ordinateur personnel, permettent la manipulation de plusieurs types de donnes : textes, images, sons, vidos. Ils offrent les fonctions de capture des donnes (camra ou carte dacquisition, par exemple), de construction et dexcution de petits scnarios ou prsentations multimdias combinant diffrents objets. Les objets multimdias sont en gnral stocks individuellement dans des fichiers traditionnels et lun des challenges intressant, consiste combiner les fonctions de ces systmes multimdias avec ceux des SGBDR. Il sagit aussi de se placer non pas au niveau dune informatique personnelle mais plutt dans le contexte des systmes distribus de grande taille combinant rseaux hauts dbits et larges communauts dusagers rpartis sur des sites distants. On arrive alors au concept de base de donnes multimdia distribue dont les architectures physiques peuvent intgrer diffrentes sources (htrognes) de donnes mais qui doivent rester transparentes par rapport au poste client. Lobjectif de notre travail est dimplmenter une base de donnes distribue sur trois sites distants ainsi quun schma mdiateur, sous le systme de gestion de bases de donnes Oracle9i. et de raliser linteroprabilit de ces trois bases. A cette fin, lenvironnement dimplmentation, savoir le systme dexploitation et le langage de programmation que nous utiliserons pour le dveloppement de notre application sont respectivement Windows XP et les Langages SQL et PL\ SQL. Optimiser les accs aux donnes en offrant des outils dindexation spcialiss. 1.2. Architecture fonctionnelle dun SGBD multimdia La figure 1 prsente une architecture fonctionnelle en couches pour un SGBD Multimdia. Au plus bas niveau figure un serveur d'objets qui prend en compte les aspects structurels et le volume des donnes. Gnralement un SGBD classique peut servir raliser cette couche mais il doit tre tendu si lon veut grer les diffrents aspects des donnes multimdias qui ont t dcrits plus haut. Cette extension constitue une couche logicielle qui se place au dessus du serveur dobjets et qui est spcialement conue pour traiter les aspects spatiaux et temporels, par exemple. Ainsi elle permet la composition et la prsentation d'objets qui sont grs de manire naturelle au niveau de l'interface.

Interface usager (client)

EDITION PRESENTATION

Prsentations multimdias Aspects spatio-temporels Composition Synchronisation

SERVEUR dOBJETS

Schma, stockage, objets complexes, indexation, interrogation, mises jour, transactions, rgles actives

1. SGBD multimdias
1.1. Caractristiques dun SGBD multimdia Une base de donnes multimdia contient des informations conserves sous diffrents formats multimdias : fichiers sons, fichiers photo, squence vido, donnes textes ect.. Le volume constitue une des principales caractristiques de ces donnes qui peuvent atteindre quelques gigaoctets. A la lumire des caractristiques que nous venons de citer, un SGBD multimdias doit pouvoir : Stocker des objets de gros volumes de donnes. Offrir des outils de modlisation (modle, langage de dfinition de donnes) pour prendre en compte la nature spcifique des objets et les oprations associes. Mettre la disposition des usagers des langages et des interfaces spcifiques pour la manipulation et linterrogation de ces donnes. Figure 1. Architecture fonctionnelle d'un SGBD multimdia

1. 3. Les LOBs (Large OBjets) Un LOB (Large OBject) est un nouveau type de donne qui permet de stocker dans un champ un gros volume d'informations. 1. 3.1. Quest-ce qu'un LOB? Il existe diffrents types de LOBs. Ceux qui sont stocks dans la base de donnes (LOB interne) et ceux qui sont stocks en dehors de la base de donnes (LOB externe). Les LOBs externe sont rfrencs dans la base par un pointeur. LOB interne : BLOB (Binary Large Object): Ddi aux donnes binaires.

SETIT2007 NCLOB (National Character Large Object) : Ddi pour les chanes de caractres Unicode. LOB externe : BFILE (Binary File): Ddi aux fichiers de donnes stocks dans le systme de fichier du systme d'exploitation.

user

Entrept

2. Intgration de Sources de donnes

Un systme dintgration de donnes doit offrir aux utilisateurs une vue uniforme des sources de donnes quil exploite, et permettre de les interroger dune manire transparente, alors quil sagit de donnes distribues sur plusieurs sites. Il fournit une vue unifie des donnes provenant de sources multiples et permet d'accder ces donnes au travers d'une interface, sans se soucier de leur structure ni de leur localisation. Un systme dintgration se compose de deux parties : Une partie externe qui correspond aux utilisateurs du systme intgr Une deuxime partie qui comprend des sources dinformation participantes au processus dintgration, et une interface uniforme qui permet aux utilisateurs ou autres systmes (de partie externe) dinterroger dune manire transparente les sources de donnes. Les lments externes voient donc le systme comme une source unique, le schma global de cette source unique est appel le schma intgr par lequel linterrogation doit se faire. Source1 Source2 Source n

Figure 2 : Intgration par entrept.

Cette matrialisation permet dacclrer le traitement des requtes car il nest pas ncessaire daccder aux sources pour y rpondre, par contre elle exige un cot de stockage trs important et surtout un cot de mise jour, toute modification dans les sources locales doit tre rpercute sur lentrept de donnes. Lapproche virtuelle Mdiateur . Dans cette approche, les donnes ne sont pas stockes au niveau du mdiateur. Elles restent dans les sources de donnes et ne sont accessibles qu ce niveau par lintermdiaire des vues traditionnelles. Cest pour cette raison que cette approche est appele approche virtuelle ( fig 3). user Mdiateur Systme n

2.1. Classification des systmes dintgration La classification des systmes dintgration qui a t propose se base sur les deux critres suivants : la localisation des donnes intgres, quelles restent dans les sources originales, ou quelles migrent vers le systme global. La nature de correspondance entre schma global et schmas locaux. 2.1.1. La localisation des donnes intgres. Il existe principalement deux architectures physiques possibles pour les systmes d intgration de donnes, lorsque les donnes des sources sont stockes dans le systme dintgration on parle d approche matrialise (entrept de donnes) en utilisant des vues matrialises, a linverse, lorsque les donnes intgres ne sont pas rpliques, on parle dapproche virtuelle (systme mdiateur). Lapproche matrialise Entrept Lapproche matrialise consiste stocker localement des donnes issues des diffrentes sources de donnes dans un entrept de donnes en utilisant des vues matrialises. Pour donner une vue globale des sources intgrer, les donnes provenant de diffrentes sources distribues doivent tre organises, intgres et stockes dans lentrept (fig 2). 3 Adaptateur1

Adaptateur 2

Adaptateur n

Source1

Source2

Source n

Figure 3 : Intgration par le mdiateur. La mdiation repose sur deux composants essentiels : Le mdiateur : joue le rle dinterface entre lutilisateur et les sources dinformation en donnant limpression quil interroge un systme centralis et homogne. Ladaptateur : il sagit dune interface entre le mdiateur et les sources de donnes, il fait la traduction de donnes dans un modle commun de donnes dans un sens mdiateur /source ou source /mdiateur. Un programme qui transforme les requtes spcialises du mdiateur en des requtes excutables sur les sources.

SETIT2007 2.2. La nature du mapping. La mthode la plus ancienne pour dfinir un schma intgr est la correspondance entre le schma global et les schmas locaux, Il existe principalement quatre mthodes pour construire le schma mdiateur d'un systme d'intgration de donnes : 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 intgrer soient connues lavance. Le point faible de cette approche est quelle ne permet pas lajout de nouvelles sources de donnes. Cet ajout peut entraner un modification du schma mdiateur car les vues qui le dfinissent seront modifies. Local as View (LaV) . A linverse de lapproche GaV, lapproche LaV suppose que le schma global est dfini indpendamment des sources. Son principe consiste dfinir les sources intgrer comme des vues sur le schma mdiateur. Lapproche LaV est flexible par rapport lajout (ou la suppression) de sources de donnes intgrer, cela na aucune incidence sur le schma global, il suffit pour cela de spcifier les vues qui permettent dintgrer (supprimer) la nouvelle source. Global local as view (GLaV) et both as view (BaV) . Sont deux approches qui combinent les capacits des deux approches prcdentes. Elles ne suscitent pas notre intrt car leur implmentation dans un systme dintgration est complexe. que leur contenu. Les correspondances entre le schma global et les schmas locaux doivent tre galement reprsents. Traitement des requtes des utilisateurs qui posent leurs requtes sur le schma global dfini sur le mdiateur. Localisation des sources de donnes pertinentes. Reformulation de la requte utilisateur en des requtes sur les schmas locaux. Rcupration des rsultats obtenus partir de linterrogation des sources. recomposition des rsultats retourns. Optimisation de requtes. 3.1.2 Les composantes du mdiateur Notre systme dintgration a une architecture 3 niveaux (appeles architecture 3-tiers) : La couche utilisateur ; La couche mdiateur ; la couche de donnes qui reprsente les sources de donnes. 3.1.2.1 La couche utilisateur Cette couche concerne les utilisateurs du systme intgr. Elle permet de linterroger et rcuprer les rsultats des requtes. Dans notre travail, la requte dun utilisateur est quivalente une requte SQL dfinie sur le schma 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 dattributs projeter. LT : ensemble de tables du schma global. Notons que le mdiateur nvalue pas directement les requtes qui lui sont poses car il ne dispose que de la description des donnes qui sont stockes de faon distribue dans des sources indpendantes. Chaque source de donnes est dcrite comme un fragment du schma global 3.1.2.2 La couche mdiateur Elle permet de localiser chaque fragment entrant dans la composition dune relation globale. Lors de lexcution dune requte globale, cette dernire est dcompose en sous requte locales pour accder aux fragments en sappuyant sur la description des sources de donnes au niveau du mdiateur. 3.1.2.3 La couche de donnes Cette couche est reprsente par les sources de donnes participantes au systme dintgration dont leurs descriptions sont schmatises dans la couche mdiateur. 3.2 Formalisation du mapping Nous formalisons notre problme dintgration, en mettant en vidence ses entres, et ses sorties.

3. Notre approche.
Le systme dintgration que nous proposons est un systme base mdiateur en utilisant lapproche GAV. Les donnes seront stockes au niveau source, et le mdiateur sauvegarde son niveau leurs descriptions (sous forme de vues virtuelles). Nous considrons que les schmas des sources locales sont dfinis comme tant des fragments dun schma global. Le choix de cette approche est largement motiv par la simplicit de son implmentation, sachant que les sources de donnes intgrer sont connues davance. Comme linterrogation du systme se fait gnralement en formulant des requtes sur le schma global, on obtient facilement une requte en terme du schma des sources de donnes intgrs en remplaant les prdicats du schma global par leurs dfinitions. 3.1 Architecture du mdiateur 3.1.1 Tches de mdiateur Pour bien rpondre aux besoins dun systme dintgration, un mdiateur doit assurer les tches suivantes : Sauvegarde des informations pertinentes concernant les schmas de sources de donnes ainsi 4

SETIT2007 Nous dfinissons le schma global SG avec n relations globales RG : ( SG < RG1, RG2,, RGn>). Soit S lensemble de sources de donnes, not : S < S1, S2, , Ss > Chaque relation globale RGi est caractrise par un ensemble dattributs et une cl primaire Ki qui peut tre compose de plusieurs attributs Ai : RGi < Ki,Ai1, Ai2, ,Aim > Soit RL lensemble des relations locales not : RL < RL1, RL2, , RLl > , o chaque relation RLj est associ une seule source et une relation globale. Elle est dcrite 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 > lensemble de prdicats simples dfinissant les relations locales (en cas de fragmentation horizontale). Chaque prdicat Pi est dfini par un attribut Ai, un oprateur Oi et une valeur Vi tel que : Oi = { <, >, =, <=, >= } Soit Q une requte pose sur le schma global du mdiateur 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 schma global. Ci : ensemble des conditions. Cette requte 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 donnes. 3.3.1 La Table Relation Cette table contient toutes les relations du systme intgr. Chaque relation est dcrite par un identifiant, un nom, un type (relation globale ou relation locale), lidentifiant de sa relation globale (dans le cas dune relation locale), et le numro de sa source. relation (n, no, t, nr, ns) Relation ssi la relation de numro n et de nom no et de type t rfrenant une relation globale (si n est une relation locale) de numro nr appartenant la source ns. 3. 3. 2 La Table Attribut Elle contient tous les attributs manipuls par le systme intgr. Chaque tuple de cette table est caractris par un identifiant, un nom, et son type. attribut(n, no, t) Attribut ssi lattribut de numro n a pour nom no et de type t rfrenant un attribut dune relation globale ou locale. 3. 3. 3 La Table Source Chaque source a un numro et un nom source(n, no) Source ssi la source de numro n et de nom no appartient lensemble de sources participantes au systme dintgration. 3.3.4 La Table Rel_attribut Cette table reprsente lassociation entre la table relation et la table attribut. Elle contient les cls primaires des deux tables plus un attribut Nature (de type boolen) qui dtermine si lattribut 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 Prdicat Elle contient tous les prdicats de tous les fragment, chaque prdicat est dcrit par un identifiant, lattribut sur lequel on applique la contrainte, loprateur et la valeur de comparaison. prdicat(n, na,o,v) Prdicat ssi le prdicat de numro n est dfinie sur lattribut na avec loprateur o et sur la valeur v. 3. 3.6 La Table Relation_loc_prdicat Cette table reprsente lassociation entre la table relation (le cas o elle est reprsente comme un fragment horizontal) et la table prdicat. Elle contient les cls primaires des deux tables. (nr, np) Relation_loc_prdicat ssi le prdicat de numro np dfinie la relation locale de numro nr.

4. Application
4.1. Introduction Notre application porte sur linformatisation dune partie du dossier mdical du patient. On implmentera une base de donnes distribue sur les sites des diffrents services mdicaux que comptera un centre hospitalier. Le dossier mdical renfermera des informations de nature diffrente (multimdia) et pour les besoins de lapplication son parcours se limitera aux trois services suivants : Service des urgences (admission du patient).

SETIT2007 Service radiologie standard (Avis spcialiste + clichs radio) Service exploration (Avis spcialiste + IRM et/ou scanner) Lobjectif consiste crer un dossier mdical qui sera aliment partiellement au niveau de chaque service et consulter totalement dune faon transparente par tous les services, ce qui donnera lieu ce quon appelle le dossier mdical partag (distribu). La figure 4 montre les cas dutilisation de notre systme dinformation. 4.2. Le diagramme de classe global A partir des diagrammes de squences et des cas dutilisation, nous avons dduit un rseau de classes et dassociations qui nous permettent de modliser la structure de chaque objet, et ses relations avec les autres objets du systme. La figure 5 montre le schma du diagramme des classes. notre approche dcrite au chapitre 3. Ce modle prend en considration la correspondance (le mapping) entre le schma global et les schmas locaux des donnes ainsi que leur localisation dans les diffrentes sources. Le mdiateur 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 )
Spcialiste Medecin Attributs
Enregistrer Patient Examiner Patient Patient Demande examen

Attributs Fonctions Pratique Attributs Medecin-traitant Consultation Attributs Attributs Fonctions

Fonctions

Medecin_ur

Consulter compte rendu radio Consulter compte rendu exploration

Demande Examen Radio Demande Examen IRM

Demande Examen scanner

Fonctions Demande_examen Attributs Fonctions Attributs Fonctions

Enregistrer Clich

Medecin_rs

Radio Attributs

IRM Attributs Fonctions

Scanner Attributs Fonctions

Consulter Dossier Consulter Demande Examen IRM

Fonctions
Consulter demande Examen radio

Figure 5 : Diagramme de classe global.

Consulter demande Examen scanner Enregistrer Medecin_ex

La figure 6 montre le modle logique du mdiateur. Afin dillustrer ce modle logique, nous considrons un exemple simple compos dune seule relation globale Mdecin, qui sera fragmenter horizontalement pour obtenir trois relations locales distribues sur trois sites ( fig 7). Mdecin ( num_med, nom, prnom, spcialit, service) Considrons les trois sources de donnes :

Enregistrer IRM

Enregistrer Scanner

Figure 4. Diagramme de cas dutilisation

4.3. Modle logique du mdiateur Dans ce que suit, nous allons dcrire la structure du mdiateur sous forme de tables relis conformment 6

SETIT2007 Source1 : medecin1 (num_med, spcialit, service) Tel que service= urgence. nom, prnom, -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 dcrits dans la table Attributs. Cest pareil pour les autres relations. Les critres de localisation des relations 1,2,3 sont reprsents dans la table Prdicats. nom, prnom,

Source2 :

medecin2 (num_med, spcialit, service) Tel que service= radiologie. medecin3 (num_med, spcialit, service) Tel que service= exploration.

nom,

prnom,

Source3 :

Mdecin(num_med, nom, prnom, spcialit, service).

Medecin1 (num_med, nom, prnom, spcialit, service) service= urgence.

Medecin2 (num_med, nom, prnom, spcialit, service) service= radiologie.

Medecin3 (num_med, nom, prnom, spcialit, service) service= exploration.

S3 S1 S2 Figure 7 : Exemple de fragmentation dune Limplmentation sous Oracle nous donne la structure de la vue suivante : Create View Medecin as Select num_med, nom, prnom, spcialit, service from Medecin1@site1 Where service= urgence Union Select num_med, nom, prnom, spcialit, service from Medecin2@site2 Where service= radiologie Union Select num_med, nom, prnom, spcialit, service from Medecin3@site3; where service= exploration Linterrogation de cette vue nous permet dobtenir toutes les informations concernant les mdecins avec une totale transparence.

Les relations locales 1,2,3 (respectivement Mdecin1,Mdecin2, Mdecin3) correspondent la relation globale 4 (Mdecin). Ces relations sont distribues sur les trois sites 1,2,3 (table Source), c'est7

4.4 Environnement logiciel. Nous utiliserons lenvironnement Windows XP pour implmenter notre systme de dveloppement Oracle 9i.

SETIT2007 Outre le SGBD, la solution Oracle est un vritable environnement de travail constitu de nombreux logiciels permettant doffrir des outils trs performants. On citera notamment : Les outils d'administration du SGBD. Les outils de dveloppement Les outils de communication Les outils de gnie logiciel Les outils d'aide la dcision 4.5.1. Indexation Pour permettre au systme de gestion de base de donnes de traiter les documents efficacement, ceux-ci doivent subir une indexation documentaire. Cette indexation permet de dgager l'information ncessaire pour leur reprage des listes, tables ou index. L'indexation des documents textes gnre une structure complexe de donnes, alors que celle des images consiste en la gnration d'une signature binaire. C'est la mthode analyze() qui s'occupe de gnrer la signature de limage, compose 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. 4.5.2. Stockage interne des donnes Les donnes volumineuses que nous aurons traiter se rapportent des photos de radiologie, de scanner et dIRM. Elles seront dcrites dans la table des attributs ( fig 8) et seront dclares de types Blob. Vu leur nature confidentielle, ces donnes seront stocker lintrieur de la base de donnes pour bnficier du systme de scurit daccs la base. Oracle met la disposition des administrateurs de bases de donnes diffrentes mthodes et utilitaires pour raliser le chargement de ces donnes dans la base, citons Ctxload, SQL*LOADER, DBMS_LOB.LOADFROMFILE().

4.4.1 Prsentation dOracle Net. Oracle Net, est un ensemble doutils rseau dOracle, qui peuvent tre utiliss pour se connecter des bases de donnes distribues. Oracle Net facilite le partage de donnes entre plusieurs bases, mme si ces dernires sont hberges sur des serveurs qui sexcutent sur des systmes dexploitation et des protocoles de communications diffrents. Larchitecture la plus courante et rentable utilis avec Oracle Net est celle de client lger, autrement appele architecture trois-tiers. Le code de lapplication est maintenu et excut au moyen de scripts Java sur un serveur spar de celui de base de donnes. En plus des implmentations client/ serveur et client lger, des configurations serveur/ serveur sont souvent ncessaires, comme pour notre cas, lorsquun serveur envoie une requte de base de donnes vers un autre serveur, lmetteur joue le rle de client 4.4.2. Assistant configuration Oracle Net (Net configuration assistante) Cet assistant dispose dune interface utilisateur graphique pour effectuer les tapes de configuration initiales du rseau aprs linstallation doracle. Dans ce qui suit, nous prsentons les diffrentes tapes de configuration pour nos trois bases de donnes (ORAL1, ORAL2, ORAL3).

Num_atribut

Listeners - Nom du listner : listner_oracleDB - Protocle de communication : TCP-IP - Port de comunication : 1521( port standard) Mthode de rsolution de noms : Oracle Names Noms de services de rseau local : - Nom de la base de donnes : ORAL1 - Nom dhote ( machine ) : sys1

La mme procdure sera ralise sur les sites des deux autres bases ORAL2 et ORAL3. 4. 5. Gestion de donnes multimdia avec Oracle Les donnes multimdias Oracle sont gres par une des extensions de la base de donnes 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 grer des documents textes, des sons, des images et des vidos. L'ensemble des documents peut tre stocks et diffuss, les images et les textes disposants de plus de fonctionnalits, via leurs index. 8

. 18 19 20 21 22 23 24 25 26 27 28 ..

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 : Aperu de la table des attributs 4.6. Environnement matriel. Pour limplmentation de notre application, nous avons utiliss un rseau de trois PCs. Chaque machine a t installe dans lun des trois services cits au paragraphe 4.1. Les trois machines possdent la mme configuration matrielle suivante : - Microprocesseur Intel Pentium 4 - Frquence dhorloge : 1.4 GHz - Capacit disque dur : 40 Go.

SETIT2007 - Mmoire RAM : 512 Mo. - Carte rseau Realtek RTL 8139/810X Family PCI Fast Ethernet NIC
Decentralized System, 2002. 6-7 Nov. 2002 Pages:132 139. [7]. Ozsu, M.T & Valduriez, P.;Distributed database systems: w here are we now? Computer Volume 24, Issue 8, Aug. 1991 Pages :68 78. [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

5. Conclusion.
Jusque l, les travaux raliss sur limagerie mdicale ont surtout ports sur limplmentation de banques de donnes dimages mdicales et les diffrentes mthodes daccs ces informations. Notre approche est dassocier dans une mme base de donnes des objets de type classique et des objets de type LOBs. La finalit de ce travail est donc de mettre la disposition du corps mdical un outil de travail qui leur faciliterait la gestion des dossiers mdicaux des malades en y incluant des donnes multimdias telles que les diagnostics de type texte classique et les images mdicales (LOBs) qui peuvent tre dorigine radiologique, IRM ou scanner. Bien que limplmentation de notre base de donnes distribue soit limite trois services mdicaux ( urgence, radiologie et exploration) , les malades peuvent passer dun service un autre pour des subir les examens ncessaires sans dplacer leur dossier. Les mdecins traitants ont accs toutes les informations concernant leur patient de faon transparente, sans se soucier du site o se trouve rellement lenregistrement physique des donnes. Si le travail ralis dans cette premire tape, permet de faciliter la gestion des donnes (consultation et stockage) qui se trouvent rparties sur des sites distants, il serait trs intressant dassocier cette base de donnes distribue, des outils de traitement sur limagerie mdicale qui faciliteront laide la dcision du mdecin. Nous pensons que cette extension constituera la deuxime 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 donnes objet, dductives, rparties . 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