You are on page 1of 9

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** , Debiane S*
Dépt. Informatique, Université Tizi-ouzou , Algérie , Dépt. Informatique Université Tizi-ouzou Algérie

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

Laboratoire LRPE USTHB- A1LGER Algérie
** linda_oulebsir@yahoo.fr

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 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. • 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.

Interface usager (client)
EDITION PRESENTATION

Présentations multimédias Aspects spatio-temporels Composition Synchronisation

SERVEUR d’OBJETS

Schéma, stockage, objets complexes, indexation, interrogation, mises à jour, transactions, règles actives

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. Figure 1. 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. 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. 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. Source1 Source2 … Source n

Figure 2 : Intégration par entrepôt.

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). user Médiateur Système n

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). 3 Adaptateur1

Adaptateur 2

Adaptateur n

Source1

Source2

Source n

Figure 3 : Intégration par le médiateur. 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.

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. 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. 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.

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 4

SETIT2007 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).

5

SETIT2007 Service radiologie standard (Avis spécialiste + clichés radio) Service exploration (Avis spécialiste + IRM et/ou scanner) 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. 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. 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. 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 )
Spécialiste 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 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). Médecin ( num_med, nom, prénom, spécialité, service) Considérons les trois sources de données :

Enregistrer IRM

Enregistrer Scanner

Figure 4. Diagramme de cas d’utilisation

4.3. Modèle logique du médiateur 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. 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. Les critères de localisation des relations 1,2,3 sont représentés dans la table Prédicats. nom, prénom,

Source2 :

medecin2 (num_med, spécialité, service) Tel que service= radiologie. medecin3 (num_med, spécialité, service) Tel que service= exploration.

nom,

prénom,

Source3 :

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.

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'est7

4.4 Environnement logiciel. Nous utiliserons l’environnement Windows XP pour implémenter notre système de développement Oracle 9i.

SETIT2007 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.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. 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. 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().

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. 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. 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. Dans ce qui suit, nous présentons les différentes étapes de configuration pour nos trois bases de données (ORAL1, ORAL2, ORAL3).

Num_atribut

• •

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. 4. 5. Gestion de données multimédia avec Oracle 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. 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 : Aperçu de la table des attributs 4.6. Environnement matériel. 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.

SETIT2007 - Mémoire RAM : 512 Mo. - Carte réseau 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 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. 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