L’intégration structurelle

Dans cette approche d’intégration, les différents systèmes possèdent des structures et des modèles différents pour le stockage et la gestion de leurs schémas et données. Afin d’intégrer les sources d’informations, les conflits structurels qui existent entre les descriptions des sources d’information doivent être éliminés. En général, un processus d’intégration structurel suit principalement ces phases :

• La phase pré intégration analyse les schémas de chaque système. Puis, elle détermine la technique et l’ordre d'intégration.

• La phase comparaison des schémas compare les schémas en vue de trouver les conflits et les propriétés de chaque source de données. Dans cette phase on détermine les éléments qui peuvent entrer ou non dans l’intégration.

• La phase conformité des schémas consiste à résoudre les conflits existants. • La phase fusionner et restructurer permet de raffiner le schéma final et d'assurer sa conformité vis à vis des critères posés.

L’objectif final est de proposer un schéma global qui permet d’avoir une seule vue sur les différents schémas locaux. La création de ce schéma global va permettre la réalisation de deux tâches indispensables pour l’intégration, à savoir le mapping et la transformation de requêtes.

• Le mapping permet d’établir les correspondances entre les éléments des schémas locaux et le schéma global.

• La transformation de requêtes a pour rôle de créer des requêtes adaptées aux sources locales à partir d’une requête globale. Ainsi, chaque système local est invoqué par une requête qui peut l’exécuter. La technique de transformation de requêtes se base essentiellement sur le mapping déjà établi.

L’exemple suivant illustre l’idée de l’intégration structurelle. On considère deux systèmes pour la gestion commerciale des produits et les tables des produits de chaque système, la table « Catalogue_Produit » du système 1 et la table «Tprd » du deuxième système.

Ref_Produit Nom_Produit Prix_Produit

ICDuo6600 Intel Core Duo E 6600 220

P4V32 Pentium 4 3.2 GHZ 120

AA64V4800+ AMD Athlon 64 4800+ 180

Table III.1 : La table « Catalogue_produit » du système 1

Code_Prd Désignation_Prd Prix_Vente Prix_Achat 1 Intel Core Duo 2.13 Ghz 27000 25000

2 Pentium 4 3.2 GHZ 9000 8000

3 Imprimante Pixma 1500 4500 4000

Table III.2 : La table « Tprd » du système 2

En analysant les deux schémas, on peut constater les conflits suivants :

• Les conflits de noms entre les attributs (Ref_Produit, Code_Prd), (Nom_Produit, Désignation_Prd) et (Prix_Produit, Prix_Vente). L’attribut

Prix_Achat de la table Tprd n’a pas de correspondance dans la première table.

• Un conflit de type de données entre (Ref_Produit) et (Code_Prd). Le premier est alphanumérique tandis que le deuxième est numérique.

Pour résoudre les conflits de noms, il faut proposer un schéma global dons lequel chaque attribut correspond à un attribut local. Ainsi, on peut avoir trois attributs globaux. La figure III.1 montre un mapping entre les attributs globaux et locaux.

Figure III.1 : La correspondance entre le schéma global et les schéma locaux

Après la création du schéma global et l’établissement des mapping adéquats, le transformateur de requêtes permet de générer les requêtes locales appropriées.

D’après l’exemple précédent, on remarque que l’intégration structurelle constitue une approche intéressante dans le contexte d’intégration de données. Néanmoins, cette approche souffre de plusieurs faiblesses qui sont principalement :

• La création du schéma global nécessite d’avoir la structure exacte des différents schémas locaux. Or, cette connaissance n’est pas garantie.

• La structure des données n’est pas aussi simple que dans l’exemple. On peut avoir des structures plus complexes, par exemple : dans une source, on peut avoir un attribut Adresse, mais dans une autre, on trouve plusieurs attributs (Cite, Rue, Ville) qui ont le même rôle que Adresse.

• Les sources d’informations peuvent utiliser des modèles différents (relationnel, objet, semi structuré…). Si la création du mapping est complexe dans le cas où les sources d’informations utilisent le même modèle, elle est encore plus complexe dans le cas d’utilisation de plusieurs modèles de représentation.

• Même si l’extraction de la structure de chaque source est réalisable, celle de la sémantique est plus complexe. Cela rend le mapping entre les attributs une tâche très difficile.

• Dans l’intégration structurelle, l’aspect sémantique des données à intégrer n’est pas pris en charge. On ne peut pas déterminer les équivalences sémantiques entre les différents attributs des schémas. Ce problème est encore plus délicat dans le cas des conflits entre les données.

La dernière faiblesse est de loin la plus délicate. Afin d’illustrer l’intérêt et l’importance de la sémantique dans l’intégration, on va utiliser l’exemple précédent.

Dans cet exemple, on a établi un mapping entre les deux attributs

Catalogue_Produit (Ref_Produit) et Tprd (Code_Prd), en se basant sur le nom de

chaque attribut. Cependant, l’établissement du mapping entre les valeurs de ces deux attributs n’est pas évident. Des valeurs comme {1, 2, 3} ou {P4V32, ICDuoi6600} n’ont pas une sémantique apparente. Pour avoir le sens pour des valeurs, il faut analyser les autres attributs, spécialement les attributs Nom_produit et Désignation_Prd. Dans notre cas, l’enregistrement de la première source dont l’attribut Ref_produit a la valeur

P4V32 est équivalent à celui de la deuxième source dont l’attribut Code_Prd a pour

valeur 2. Pour cela, il a fallu investir les autres attributs pour établir ce mapping, (Cf. figure III.2).

On remarque que ce problème d’interprétation est le résultat du conflit de type de données qui sont utilisés par les deux sources. Néanmoins un conflit sémantique peut apparaître même entre les attributs du même type, ce que nous allons voir dans le cas suivant.

Figure III.2 : Equivalence entre les deux enregistrements

Un mapping existe entre les deux attributs, Catalogue_Produit (Prix_Produit) et Tprd (Prix_Vente). Le conflit qui existe, est un conflit de nom, mais le type de donnée utilisé est le même (Numérique). Malgré la similitude du type, on constate l’existence d’un conflit sémantique, qui réside dans l’interprétation des valeurs de chaque attribut. L’équivalence déjà établie entre les deux enregistrements des deux sources d’information et l’utilisation du même type de données n’est pas suffisante pour une utilisation judicieuse des valeurs. En fait, les deux attributs Catalogue_Produit

(Prix_Produit) et Tprd (Prix_Vente) n’utilisent pas le même type monétaire. Le

premier utilise l’Euro, tandis que le deuxième utilise le Dinar algérien. Cette différence de type monétaire influe sur l’interprétation des valeurs. Ainsi, si une requête est établie dans le but d’avoir le meilleur prix entre les deux sources, il ne faut pas comparer directement les valeurs 120 de la première source et 9000 de la deuxième. Une conversion vers une unité monétaire unique est primordiale pour établir une comparaison exacte. Bien que la valeur 9000 soit supérieure à 120, ce n’est pas le cas si on interprète la sémantique de chaque valeur. Dans ce contexte, la valeur 9000 de la deuxième source est inférieure à la valeur 120 de la première source.

Ainsi, on remarque que la prise en charge de l’aspect sémantique est très importante dans le cadre d’une intégration de données. Pour cela, plusieurs travaux sont proposés dans ce sens. La section suivante présente l’intégration sémantique.