L?environnement informationnel actuel se caract�rise par des donn�es fortement distribu�es. Ces donn�es surabondantes sont g�n�ralement �parpill�es, puisqu?il existe souvent de multiples syst�mes con�us chacun pour �tre efficace pour les fonctions pour lesquelles il est sp�cialis�. Ces donn�es sont �galement h�t�rog�nes. En effet, avec l?apparition de l?Internet et le d�veloppement des diff�rentes repr�sentations et formats des documents, les donn�es peuvent �tre class�es en plusieurs cat�gories�: structur�es (donn�es relationnelles, donn�es objet), semi-structur�es (HTML, XML, graphes) ou m�me non structur�es (texte, images, son). Dans un tel contexte, le besoin d?int�gration se fait de plus en plus sentir. Cependant, pour r�pondre � ce besoin, le d�veloppement des applications d?int�gration (telles que pour un traitement �labor� de donn�es, pour la construction des entrep�ts de donn�es ou des syst�mes d?aide � la d�cision) se voit contraint de composer avec la r�partition des sources, �l?h�t�rog�n�it� de leurs structures et la complexit� des donn�es.

Afin d?alimenter les processus d?aide � la d�cision, notre travail consiste, d?une part, � int�grer des donn�es h�t�rog�nes pour la construction des entrep�ts de donn�es (ED) et, d?autre part, � les maintenir.

Plusieurs travaux sont men�s par plusieurs �quipes afin de construire des entrep�ts XML (Nassis, Rajugan et al., 2004), (Byung-Kwon Park, Hyoil Han et Il-Yeol Song, 2005), (Boussaid, �Ben Messaoud et Choquet, 2006).

La d�finition de l?h�t�rog�n�it� est assez ambigu� dans la litt�rature. En effet, certains travaux qualifient les donn�es de diff�rentes cat�gories d?h�t�rog�nes (Kim et Park, 2003), (Beneventano, �Bergamaschi et al., 2002), (Maibaum, Zamboulis et al., 2005). Alors que d?autres, traitant des donn�es de m�me cat�gorie mais avec des mod�lisations diff�rentes utilisent aussi le terme d?h�t�rog�n�it� (Saccol� et Heuser, 2002). On trouve m�me des travaux, d�signant des donn�es de m�me cat�gorie avec la m�me mod�lisation qui parlent de donn�es h�t�rog�nes (da Silva, �Evangelista Filha et al., 2002). Ceci est d� au fait qu?il n?y a pas de mod�le de repr�sentation unique pour les donn�es � int�grer. Plusieurs mod�les, selon les caract�ristiques des sources et les manipulations � effectuer peuvent �tre retenus. Il n?existe pas, par ailleurs, un langage universel d?interrogation de donn�es h�t�rog�nes mais plusieurs langages peuvent �tre utilis�s. Le traitement de donn�es compl�tement h�t�rog�nes structur�es, semi-structur�es et non structur�es s?av�re donc un volet de recherche r�cent et assez peu explor�.

Un entrep�t de donn�es, qu?il soit homog�ne ou h�t�rog�ne, n�cessite d?�tre maintenu. Il doit aussi �voluer en fonction de l?�volution des donn�es sources aussi bien au niveau des structures que celui des donn�es.

Le probl�me de la maintenance est �galement tr�s complexe. Les algorithmes propos�s dans la litt�rature traitent essentiellement de donn�es sources (DS) homog�nes (Zhuge, Garcia-Molina et al., 1995), (Zhuge, Garcia-Molina et Wiener, 1996), (O?Gorman, Agrawal et El Abbadi, 1999), (Laurent, Lenchtenboer-Ger et al., 2001).

Cet article est structur� comme suit. Le paragraphe 2 traite de la construction des entrep�ts de donn�es h�t�rog�nes. La concr�tisation de la cr�ation des vues mat�rialis�es de l?entrep�t est pr�sent�e dans le paragraphe 3. Nous abordons ensuite les probl�mes de maintenance des vues mat�rialis�es dans la section 4. L?accent est mis, l� aussi, sur les limites de ce SGBD. Nos travaux futurs sont donn�s en guise de conclusion.

Notre objectif est l?int�gration �de donn�es provenant de sources diff�rentes et h�t�rog�nes afin de construire des entrep�ts de donn�es (cf. figure 1). Dans notre travail, les DS sont dites h�t�rog�nes si elles v�rifient l?une des deux propri�t�s suivantes�:

1. Elles appartiennent � la m�me cat�gorie (structur�es, semi-structur�es et non-structur�es) de donn�es mais elles ont des mod�lisations diff�rentes. Ainsi le traitement d?une base de donn�es relationnelles et d?une base de donn�es objet-relationnelles revient � traiter des donn�es h�t�rog�nes.

2. Elles appartiennent � des cat�gories de donn�es diff�rentes. Ainsi le traitement d?une base de donn�es relationnelles et d?une base de donn�es XML entre dans le cadre du traitement de donn�es h�t�rog�nes.�

Nous ne traitons dans cet article que l?int�gration de donn�es h�t�rog�nes structur�es relationnelles et objet-relationnelles (avec des types d�finis par l?utilisateur ou d?autres types tels que le type texte ou le type XML).

Soit un ensemble E de bases de donn�es � int�grer afin de former un entrep�t de donn�es DW, {E= DB_k, k? }. Dans la suite, nous noterons le sch�ma de la base de donn�es DB_k par S_k. On note S_k =(�R_k, ATT_k, DOM_k).

Rappelons que�pour le mod�le relationnel ou objet-relationnel, un sch�ma S, sans contrainte, repose sur l?existence d?un ensemble R_S de noms de relations, d?un ensemble ATT_S de noms d?attributs et d?un ensemble DOM_S de noms de domaines. Ces ensembles sont consid�r�s comme des donn�es du niveau conceptuel. Un sch�ma de base de donn�es relationnelles ou objet-relationnelles peut donc �tre d�fini comme S = (�R_S, ATT_S, DOM_S)�; tel que :

• Chaque nom d?attribut A ATT_S est associ� � un seul nom de domaine dom_S(A) DOM_S. Cette association d�finit un attribut, not� A�: dom_S(A) ou simplement A, s?il n?y a pas risque de confusion.

• Chaque nom de domaine D DOM_S d�note un ensemble de valeurs atomiques (types de base) ou bien des types compos�s. Dans le cas du relationnel, les types de base sont ceux propos�s par le syst�me de gestion de bases de donn�es (tels que Oracle, DB2).

• Chaque nom de relation �R R_S est associ� � un ensemble fini et non vide d?attributs att_S(R) ATT_S. Cette association d�finit un sch�ma de relation de nom R et de structure (A₁:dom_S(A₁),?,A_n:dom_S(A_n)) not� par� R (A₁ : dom_S (A₁), ?, A_n : dom_S (A_n)) o� n est la cardinalit� de att_S(R).

Notons qu?un ensemble C_s de contraintes peut accompagner la d�finition d?un sch�ma S.

Notre approche d?int�gration de bases de donn�es peut �tre d�crite par plusieurs �tapes. La premi�re se r�sume par le choix des diff�rents composants de l?entrep�t de donn�es � construire. Un ensemble de liens est d�fini ensuite entre les diff�rents composants de sources de donn�es. Cet ensemble est utilis� dans l?�tape suivante qui consiste � filtrer les composants de l?entrep�t. Le sch�ma global de l?entrep�t est ensuite d�fini, cette �tape est suivie par celle de construction qui consiste � alimenter les vues de l?entrep�t par les donn�es des sources.

Dans cette �tape, l?ensemble L des composants de l?entrep�t est s�lectionn�. L constitue l?ensemble des attributs (de type pr�d�fini ou de type utilisateur) ou des �l�ments (XML) des sources de donn�es qui doivent figurer dans l?entrep�t�: .

L?ensemble des composants de l?entrep�t est donc un sous-ensemble de �tous les composants des diff�rentes bases h�t�rog�nes constituant les sources de donn�es.

Plusieurs relations peuvent �tre d�finies entre les diff�rents composants des sources (synonymie, inclusion, disjonction, incompatibilit�?) (Beneventano, Bergamaschi et al., 2000). C?est le concepteur (administrateur) de l?entrep�t qui donne ces liens.

Dans le cadre de ce travail, nous d�finissons deux types de liens�qui peuvent exister entre les diff�rents composants des bases de donn�es concern�es : la SYNonymie et l?INClusion.

Le lien de SYNonymie est alors d�fini en tant qu?une relation d?�quivalence SYN sur L. Celui d?INClusion est d�fini en tant qu?une relation d?ordre stricte INC sur L.

Nous d�finissons, par ailleurs, la compatibilit� entre domaines de la mani�re suivante�:

D�finition 3�(compatibilit� entre domaines)

Etant donn�s deux composants A et A?, Dom(A) et Dom(A?) sont compatibles :

Dans le cas des bases de donn�es relationnelles ou objet-relationnelles les deux liens consid�r�s sont d�finis ci-dessous.

D�finition 4�(Synonymie) : Etant donn�s deux attributs A (AR, RDB1) et A? (A?R?, R?DB2), A SYN A? Si�Dom(A) ? Dom(A?), et si l?ensemble C1 des contraintes de domaine pour A est logiquement �quivalent � l?ensemble C2 des contraintes de domaines pour A?.

D�finition 5 (Inclusion) : Etant donn�s deux attributs A (AR, RDB1) et A? (A?R?, R?DB2), A INC A? Si�Dom(A) ? Dom(A?), et si C1 et C2 ne sont pas logiquement �quivalents et toute contrainte de l?ensemble C2 est impliqu�e par C1.

Dans le cas des attributs compos�s ces deux liens sont d�finis dans ce qui suit.

D�finition 6 (Synonymie, attributs compos�s) : Soient les deux attributs compos�s A et A?o� A={c1,?,cr} et A?={c?1,?,c?r?} avec c1,?,cr et c?1,?,c?r? sont des attributs atomiques. A SYN A? si r = r? et cs SYN c?s pour tout s compris entre 1 et r.

D�finition 7�(Inclusion, attributs compos�s)

Soient les deux attributs compos�s A et A?: A={c1,?,cr} et A?={c?1,?,c?r?} avec c1,?,cr et c?1,?,c?r? sont des attributs atomiques. A INC A? si r ? r? et cs SYN c?s pour tout s compris entre 1 et r.

L?ensemble des composants de l?entrep�t est raffin� en utilisant l?ensemble des liens d�finis dans l?�tape pr�c�dente. En effet, deux �tapes de filtrage sont effectu�es, sur l?ensemble L, selon les liens �tablis.

Etape 1�: Filtrage en �utilisant la relation d?�quivalence SYN

L est filtr� en laissant un seul repr�sentant de chaque classe d?�quivalence correspondante au lien SYN. Le choix du repr�sentant est al�atoire et il n?intervient pas dans le processus d?int�gration. Le domaine associ� au repr�sentant choisi est �gal � l?union des diff�rents domaines de tous les composants de la classe d?�quivalence.

Etape 2�: Filtrage en utilisant la relation d?ordre INC

La deuxi�me op�ration de filtrage consiste � laisser le "plus grand" �l�ment correspondant � la relation d?ordre INC. Le domaine associ� au repr�sentant choisi est �gal � l?union des diff�rents domaines de tous les �l�ments inclus ou �gale (INC) � ce dernier.

L?ensemble L? r�sultat du filtrage est donc form�: L?L. L? peut �tre �crit de la mani�re suivante�:

La g�n�ration du sch�ma global comporte les �tapes suivantes�:

1- Pour chaque L?_k un graphe non orient� G_k est construit. Chaque n?ud correspond � une relation RR_k et chaque arc indique l?existence d?une contrainte de cl� �trang�re entre deux relations. Soit d? le nombre de ces graphes.

2- On d�tecte les sous-graphes connexes pour chaque graphe G_k. Rappelons qu?un graphe est dit connexe s?il existe au moins un chemin entre chaque couple de noeuds du graphe (Lellahi et �Zamulin, 2001). Le graphe G_k est donc l?union de ses �sous graphes connexes.

3- Soit [k �l?ensemble form� de ces sous graphes, � savoir, [k={G_ki / i?T_k} o� T_k d�signe une indexation pour [k

4- Soit . Pour tout u = (u₁,?,u_d) T. On consid�re le graphe C_u form� de l?union de tous les C_ui (i=1,?,d), et on d�note par C l?ensemble des graphes ainsi obtenu�: C={ C_u / u T}

5- Un sch�ma de vue V_u est associ� � chaque sous graphe C_u telles que les relations intervenant dans V_u sont celles repr�sent�es par des n?uds dans le graphe C_u et les attributs de V_u sont ceux de L? qui appartiennent aux relations intervenant dans V_u.

L?�tape pr�c�dente de l?approche a permis d?�tablir le nombre de vues (?) de l?entrep�t et leurs structures (DW={V_i / i [1.. ?]}). Un algorithme de construction ConstruitVue( ) sera appliqu� pour chacune d?entre elles.

Pour toute vue V � construire, l?algorithme construitVue( ) consiste � int�grer des donn�es de diff�rentes bases afin d?alimenter la vue. Cet algorithme est pr�sent� dans la suite�pour une vue V. La proc�dure Cr�er_Vue(Q) consiste � ex�cuter une requ�te de s�lection, des diff�rents composants figurant dans Q. Dans notre cas, la s�lection consiste � interroger la base concern�e avec le langage SQL.

L?exemple sur lequel nous travaillons porte sur les syst�mes d?information de sant�: SIM. En effet, le dossier m�dical informatis� d?un patient, qui peut �tre suivi pour plusieurs pathologies, est un cas tr�s complet d?int�gration de donn�es h�t�rog�nes (web, informations sp�cialis�es, images num�riques, ?) et de leurs mises � jour r�guli�res.

Les diff�rentes �tapes de construction de l?entrep�t de donn�es sont les suivantes�:

-1- Liste des composants de l?entrep�t

L={DB1.MEDECINS.MENUM; DB1.MEDECINS.MENOM�; DB1.VISITES.VINUM�; DB1.VISITES.VIDATE�; DB2.PRATICIENS.PRNUM�; DB2.PRATICIENS.PRNOM�; DB2.ACTES.ACNUM�; DB2.ACTES.ACDATE�; DB2.ACTES.ACCODE}

-2- Etablissement des liens de Synonymie et d?Inclusion

DB1.VISITES.VINUM� SYN DB2.ACTES.ACNUM�

DB1.VISITES.VIDATE� SYN DB2.ACTES.ACDATE

DB1.MEDECINS.MENUM INC DB2.PRATICIENS.PRNUM

DB1.MEDECINS.MENOM INC DB2.PRATICIENS.PRNOM

-3-�Filtrage en �utilisant la relation d?�quivalence SYN et la relation d?ordre INC

Utilisation de la SYNonymie

L={DB1.MEDECINS.MENUM; DB1.MEDECINS.MENOM�; DB1.VISITES.VINUM�; DB1.VISITES.VIDATE�; DB2.PRATICIENS.PRNUM�; DB2.PRATICIENS.PRNOM�; DB2.ACTES.ACNUM�; DB2.ACTES.ACDATE�; DB2.ACTES.ACCODE}

Utilisation de l?INClusion

L={DB1.MEDECINS.MENUM; DB1.MEDECINS.MENOM�; DB1.VISITES.VINUM�; DB1.VISITES.VIDATE�; DB2.PRATICIENS.PRNUM�; DB2.PRATICIENS.PRNOM�; DB2.ACTES.ACNUM�; DB2.ACTES.ACDATE�; DB2.ACTES.ACCODE}

L?={DB1.VISITES.VINUM�; DB1.VISITES.VIDATE�; DB2.PRATICIENS.PRNUM�; DB2.PRATICIENS.PRNOM�; �DB2.ACTES.ACCODE}

-4- G�n�ration du sch�ma global

On a donc une seule vue r�sultat pour l?entrep�t. Elle contient tous les attributs de L?.

V={DB1.VISITES.VINUM�; DB1.VISITES.VIDATE�; DB2.PRATICIENS.PRNUM�; DB2.PRATICIENS.PRNOM�; �DB2.ACTES.ACCODE}

5-En applicant l?algorithme ConstruitVue �� la vue V de l?entrep�t, nous aurons�:

Pour k=1

Q={DB1.VISITES.VINUM�;DB1.VISITES.VIDATE�;DB1.MEDECINS.MENUM�; DB1.MEDECINS.MENOM�; null}

Pour k=2

Q={DB2.ACTES.ACNUM�;DB2.ACTES.ACDATE;DB2.PRATICIENS.PRNUM�; DB2.PRATICIENS.PRNOM�; DB2.ACTES.ACCODE}

Ainsi les composants de l?ED sont d�termin�s. La construction physique des vues est effectu�e � l?aide des requ�tes (SQL dans le cadre du relationnel-�tendu, XML-query pour les donn�es de type XML).

Dans cette section, nous illustrons la gestion (cr�ation et maintenance) des vues mat�rialis�es (VM) � travers le SGBD Oracle. Notre choix de l?outil se justifie essentiellement par la position qu?il occupe sur le march� et notamment par sa r�putation en mati�re de performance et de gestion de gros volumes de donn�es complexes.

Une vue mat�rialis�e (VM) est d�finie sur une ou plusieurs tables � partir d?une ou de plusieurs bases. Ces derni�res peuvent �tre homog�nes ou h�t�rog�nes. La structure d?une vue peut �tre ainsi compos�e d?attributs de types complexes. Les donn�es sont extraites � partir des DS.

L?entrep�t de donn�es mentionn� � construire peut �tre compos� de plusieurs vues issues de l?int�gration de plusieurs sources h�t�rog�nes (cf. Figure 2). Nous avons effectu� des tests de cr�ation de VM sous Oracle en utilisant les diff�rentes combinaisons possibles entre type et p�riodicit� de rafra�chissement. Chaque combinaison est test�e � la fois sur des donn�es de types simples et des donn�es de types complexes. Les m�mes tests ont �t� effectu�s sur des VM mono-table et des VM multi-tables.

Nous constatons, � notre grand �tonnement, que la seule possibilit� pour int�grer des donn�es h�t�rog�nes serait de cr�er une vue multi-tables mono-base avec le type de rafra�chissement le plus co�teux vu qu?il doit �tre complet et sur demande.

Nous avons d�velopp� en PL/SQL le package pck_constvues qui permet la cr�ation d?entrep�ts de donn�es h�t�rog�nes en rempla�ant les vues mat�rialis�es, version Oracle, par des tables classiques (Boufares et Hamdoun, 2005). Nous n?avons pas pu joindre, en annexe, le package par manque de place.

La maintenance des VM revient � r�percuter les changements apparus au niveau des DS. �Afin de s?adapter � l?�volution des processus d?analyse, l?�volution d?un entrep�t requiert, d?une part, la maintenance de structure et, d?autre part, la maintenance de donn�es.

La maintenance structurelle a pour objectif de maintenir le sch�ma des vues de l?ED suite aux changements des structures des DS (ajout/suppression de DS, ajout/suppression de relation/classe, ajout/suppression d?attribut, ?). L?ED peut aussi subir des changements �de structure, ind�pendamment des DS, suite � une red�finition de l?une ou de plusieurs de ses vues, ou suite � la mat�rialisation de vues non mat�rialis�es, ou suite � une reconfiguration (ajout de vues). La maintenance structurelle peut engendrer un changement fondamental du sch�ma de l?ED (Badri, Boufares et al., 2005)

A travers les tests qu?on a effectu� lors de la manipulation des vues mat�rialis�es sous Oracle, nous constatons qu?il est impossible de modifier la structure des donn�es d?une table source si l?un de ses attributs est de type complexe. Il est cependant possible de modifier la structure de certaines donn�es de types simples qui appartiennent � des tables relationnelles, seulement ces modifications ne sont pas r�percut�es sur les VM.

La maintenance des donn�es consiste � alimenter l?entrep�t suite aux mises � jour des sources de donn�es. Oracle assure la maintenance de donn�es � travers le rafra�chissement. Ce dernier est d�clanch� de deux mani�res�selon la p�riodicit� du rafra�chissement choisi lors de la d�finition de la VM (ON COMMIT ou ON DEMAND).

Pour assurer le type de rafra�chissement incr�mental (FAST), un journal de vues mat�rialis�es doit �tre cr�e manuellement par l?utilisateur avec la syntaxe CREATE MATERIALIZED VIEW LOG ON nom_de_la_table. Le journal cr�� est une vue mat�rialis�e qui a pour nom MLOG$_nom_de_la_table. La liste des journaux se trouve dans la m�ta-table USER_MVIEW_LOGS.

La maintenance des VM issues de donn�es h�t�rog�nes et complexes n?est possible, sous Oracle, qu?avec les options COMPLETE et ON DEMAND. Ce qui signifie que les vues sont enti�rement recalcul�es. Afin d?�viter de les r�g�n�rer compl�tement nous proposons une gestion "manuelle" du rafra�chissement. Ceci n�cessite la clause FOR UPDATE�: CREATE MATERIALIZED VIEW nom_de_la_MV FOR UPDATE as sous_requ�te. Ce qui pourrait permettre de reporter des insertions, des modifications ou des suppressions dans la VM selon les op�rations de mise � jour sur les donn�es sources.

Nous remarquons qu?Oracle ne permet pas de cr�er des VM modifiables dans le cas o� les donn�es sources sont issues de plusieurs tables.

Ces manquements dans les versions actuelles 9i/10g d?Oracle < www.oracle.com> nous am�nent � construire un entrep�t de donn�es avec sources h�t�rog�nes non sous forme de vues mat�rialis�es mais sous forme de tables. Celles-ci sont construites � partir de plusieurs tables �ventuellement d�finies sur des colonnes de types complexes. Ainsi, la maintenance de cet entrep�t suivra la proc�dure que nous proposons ci-dessous.

Nous proposons la proc�dure MV_maintenance qui assure la maintenance incr�mentale des VM multi-tables issues de donn�es complexes de type objet. Notre proc�dure, contrairement � celle employ�e par Oracle (DBMS_MVIEW.REFRESH), ne recalcule pas enti�rement la vue mais rajoute uniquement les lignes qui ont �t� mises � jour dans les tables sources.

Dans cet article, nous ne traitons que le cas mono-base. On donne ci-dessous notre d�marche�:

Etant donn�, l?ensemble des relations R_k (k[1..n]) des donn�es sources.

La relation R_k est d�finie sur l?ensemble de ses attributs A_k, on note R_k (A_k) ou R_k, avec A_k = {A_k1, A_k2, ? A_km}.

La vue mat�rialis�e V est d�finie sur le sous-ensemble B des attributs des relations concern�es�: �; On note V(B) ou V.

Les donn�es de la vue V(B) constituent un sous-ensemble du produit (?) des relations R_k. Soit R?₁(A₁) l?ensemble des mises � jour, depuis la derni�re maintenance, dans une relation source donn�e R₁(A₁).

On d�finit la vue V?(B) comme �tant �gale au sous-ensemble du produit de R?₁ et des relations R_j �j [2..n].

Le rafra�chissement de la vue V sera �gal � l?union de V et de V?�:

Nous avons enti�rement termin�, en utilisant Oracle Forms et PL/SQL, le d�veloppement de l?outil HDI. Celui-ci permet d?int�grer des donn�es h�t�rog�nes relationnelles et objet-relationnelles (avec types complexes et XML). L?algorithme pr�sent� prend en consid�ration les relations qui existent entre les composants (attributs ou �l�ments) dans une m�me base et les liens qui existent (synonymie et inclusion) �entre ces composants dans des bases diff�rentes. La maintenance des vues mat�rialis�es qui constituent l?entrep�t s?est av�r�e tr�s limit�e avec le SGBD Oracle. En effet, celui-ci ne permet que la cr�ation de VM multi-tables mono-base et une maintenance en recalculant toute la vue. Nous avons ainsi propos� une proc�dure de maintenance afin de ne r�percuter que les mises � jour n�cessaires.

Des mesures sont en cours de r�alisation sur plusieurs outils afin d?aider � d�terminer le type de VM � cr�er (relationnelles, objet ou XML). L?extension des liens entres les composants dans les DS (autres que la synonymie et l?inclusion) d?une part, et d?autre part, la g�n�ralisation de notre algorithme aux donn�es non structur�es constituent nos travaux futurs.