SYSTÈMES INFORMATIQUES Systèmes d'aide à la décision

Stratégies de rafraîchissement

L'extracteur doit appliquer une stratégie de rafraîchissement : périodique ou sur déclenchement. Dans le cas d'un rafraîchissement périodique, les données sont systématiquement exportées à intervalle fixe vers l'entrepôt, par exemple tous les jours. Le deuxième type de rafraîchissement déclenche l'exportation sur un événement. Cette dernière solution permet par exemple d'exporter toutes les données concernant le séjour d'un patient à l'hôpital à la survenue de l'événement « fin du séjour », car ce n'est qu'ensemble qu'elles fourniront des informations d'intérêt médical. Pour réaliser une alimentation en temps réel, on déclare événement déclencheur l'insertion d'un nouvel enregistrement dans la source.

Le mode d'extraction le plus fréquemment appliqué est celui d'une extraction périodique journalière déclenchée tous les soirs vers 19 heures et s'exécutant la nuit, lorsque les traitements de productions sont moins sensibles aux perturbations. Notons que les différentes données d'une même source n'ont pas obligatoirement le même mécanisme d'extraction.

Mise en œuvre

Pour programmer les extracteurs, le développeur peut s'aider des fonctionnalités de réplication de haut niveau fournies par les systèmes de gestion de base de données (S.G.B.D.), par exemple les déclencheurs, les mécanismes de vue concrète ou l'exploitation des journaux.

Les extracteurs peuvent également être automatiquement générés par un outil ETL (extraction transformation loading) : par une interface graphique de très haut niveau, l'utilisateur trace un trait de la table source vers la table cible et peut spécifier quelques règles de transformation à effectuer au passage. L'ETL fournit le code source des extracteurs et les scripts assurant le bon enchaînement de leurs déclenchements.

Conflits fréquemment rencontrés lors de l'intégration

Les conflits les plus fréquemment rencontrés lors de l'intégration de données sont les suivants :

– Différence de codage. Le sexe peut par exemple être codé M/F dans une source et 1/2 dans l'autre. La différence peut être particulièrement difficile à détecter, par exemple entre les tailles de prêt-à-porter françaises et espagnoles qui ne diffèrent que d'une unité ;

– Différence d'unité. Le poids d'un produit peut être en kg dans une source et en livres dans l'autre ;

– Différence de granularité. Par exemple, le salaire peut être donné par an ou par semaine ;

– Différence de fraîcheur entre deux sources. Les données ont pu évoluer entre les deux sources, par exemple l'âge peut avoir augmenté sans qu'il y ait pour cela contradiction ;

– Imprécision. Le poids peut par exemple être stocké au gramme près dans une source (54,57) et d'une façon moins précise dans l'autre source (54) sans qu'il y ait de contradiction ;

– Erreurs dans une source. Il peut s'agir de fautes d'orthographe, de fautes de frappe ou toute autre petite erreur dans la transcription de la valeur ;

– Différences de partitionnement. Une source peut découper les tranches d'âges par exemple en [10, 20[, [20, 30[, [30, 40[ et une autre source en [10, 25[, [25, 40[ ;

– Différence de contenu dans les textes libres. Typiquement, lors du remplissage du champ « adresse » il ne faut normalement inscrire que l'adresse « Cercle Polaire, Rovaniemi, Finlande », mais il est fréquent d'y trouver aussi le nom du destinataire : « Père Noël, Cercle Polaire, Rovaniemi, Finlande » ;

– Différence linguistique de niveau de perception. Par exemple, la valeur de l'attribut « couleur » d'une voiture est sujette à des variations, sans pour autant que la voiture en question ait été repeinte. À l'achat, la voiture peut être insérée dans la base de données avec une couleur précise, par exemple « vermillon », puis, lors de sa déclaration à la préfecture, avec un niveau de précision moindre et la valeur « rouge ». De même, le champ « médicament » d'un patient à l'hôpital peut recevoir la valeur précise « Efferalgan » ou une valeur plus générique « paracétamol », pour en fait le même antalgique administré au patient ;

– Différence de règles métier dans la mesure de la valeur. Par exemple le salaire peut être noté brut, ou net, avec ou sans les primes. Les modes opératoires doivent également être pris en compte pour comparer deux valeurs, une mesure du nombre de germes chez un patient ne pourra être comparée avec une autre que si elles ont été effectuées dans les même conditions, par exemple toutes les deux avant l'antibiothérapie ou toutes les deux après celle-ci.

Solutions à la résolution des conflits

Lorsque ces situations génératrices de conflits de valeurs sont détectées, des solutions peuvent être mises en place pour les résoudre automatiquement lors de l'alimentation de l'entrepôt. Voici ci-dessous quelques types de solutions :

– Résolution manuelle des conflits. Les cas à problèmes sont envoyés dans une table de rejets en l'attente d'un traitement manuel au cas par cas. Bien que ce soit une solution fiable, celle-ci est très coûteuse et doit donc, dans la mesure du possible, être remplacée par les solutions automatiques suivantes ;

– Règles de transformations. Des tables de correspondances suffisent pour résoudre les problèmes de codifications différentes, de synonymes, d'abréviations. Des fonctions de conversion résolvent les problèmes de différences d'unités ;

– Critères de fiabilité des sources. En cas de conflit, on peut privilégier la source la plus fiable, ou la source la plus récente. Des informations sur la fiabilité et la fraîcheur des sources doivent être disponibles dans le référentiel ;

– Utilisation de données implicites. Parfois une donnée paraît absente, alors qu'en fait elle est implicite. Par exemple, dans la base de données d'un constructeur de voitures japonais, la nationalité de ses voitures n'apparaîtra pas car elle est implicite pour toute la base ;

– Normalisation en amont. Cette méthode impose aux propriétaires des sources d'utiliser les mêmes conventions de codification, les mêmes tranches d'âge, les mêmes unités, etc.

– Techniques de matching indépendantes du contexte. Des techniques d'appariement purement syntaxique, c'est-à-dire indépendant du sens des mots, peuvent être appliquées pour détecter qu'il s'agit de la même valeur. Par exemple, si deux chaînes de caractères diffèrent seulement d'un caractère (ex : « citron » et « ciyron ») et si les deux caractères différents (« t » et « y ») sont très proches l'un de l'autre sur le clavier, on conclut à une faute de frappe sur l'une des chaînes et les valeurs sont considérées comme identiques ;

– Techniques de matching dépendantes du contexte. Pour certains champs importants et très touchés par le problème d'hétérogénéité de représentation, des logiciels spécifiques sont disponibles. Par exemple, des logiciels sont capables de normaliser des adresses pour pouvoir les comparer et vérifier si elles sont identiques ;

– Utilisation d'ontologies de domaine. Une ontologie est une conceptualisation du monde réel destinée à en partager la compréhension ; on peut la comparer à un dictionnaire de langue qui permet à différentes personnes de se comprendre via un consensus sur le sens des mots. Une ontologie est destinée aux ordinateurs et non aux humains, elle est généralement composée d'une hiérarchie de concepts (taxonomie) et autres liens sémantiques (« est-partie-de », « est-relié-à », etc.). L'ontologie des couleurs de voitures dont on peut voir l'extrait figure 2a peut aider à effectuer automatiquement une intégration sémantique sur les sources de la figure 2b telle qu'elle aurait été faite par un humain. Par exemple l'algorithme peut voir que la voiture n^o 1 a la couleur « azur » dans la source 1 et la couleur « bleu » dans la source 2 ; l'ontologie montre que « bleu » est un ancêtre (terme plus générique) d'« azur », il s'agit donc de la même couleur. L'ontologie montre également que les couleurs « vermillon » et « bleu » attribuées toutes deux à la voiture n^o 2 ne correspondent pas à la même couleur. Les techniques sont les mêmes que celles qui sont utilisées dans le Web sémantique pour étendre la portée d'une requête si celle-ci n'obtient pas assez de réponses.

Métadonnées destinées à la gestion des données

On trouve tout d'abord les métadonnées habituelles de toute base de données : les types de données, les contraintes d'intégrité, les droits d'accès, etc.

Métadonnées destinées aux responsables des processus

Cette partie est propre aux entrepôts de données. C'est dans le référentiel que doivent puiser les équipes et outils responsables du processus de transformation des données de production vers l'entrepôt afin de retrouver toutes les informations nécessaires aux processus. Ces métadonnées comprennent tous les flux et les règles d'alimentation de l'entrepôt et des magasins ainsi que les règles de transformation des données.

Métadonnées destinées aux utilisateurs

Les utilisateurs de l'entrepôt ont particulièrement besoin d'information et de documentation sur les données stockées dans l'entrepôt afin d'en comprendre la sémantique. Les utilisateurs ne sont pas des programmeurs mais des décideurs. De plus, les données proviennent de diverses bases de données dont le contenu n'est pas familier aux utilisateurs de l'entrepôt, contrairement au contexte d'un système d'information de production où la même équipe gère et interroge sa base de données. Cette documentation peut être fournie par une interface de navigation. Elle doit par exemple pouvoir dire que la table « produit » de l'entrepôt contient l'union des tables « produit » des sources « filiale Paris », « filiale Milan » et « filiale New York » sur les dix dernières années, pour tous les produits de la gamme textile.

Standardisation des métadonnées

Tous les outils de la chaîne décisionnelle vont chercher dans le référentiel les métadonnées nécessaires à l'exécution de leur tâche. Il y a donc un besoin de standardisation des métadonnées, afin de permettre l'utilisation d'outils d'éditeurs différents. Dans les premières années d'existence des entrepôts de données, chaque partie de la chaîne était associée à de grands noms d'éditeurs spécialisés dans un type de logiciel : ETL, S.G.B.D., outils de restitution, outils de fouille de données. Chacun de ces logiciels avait son propre référentiel et la communication était difficile, ce qui a ouvert la voie à des offres intégrées, les éditeurs les mieux implantés en rachetant d'autres, complémentaires, afin d'offrir des chaînes complètes.

Une première tentative de standardisation a eu lieu en 1995 : le « metadata Council » réunissait les principaux acteurs du marché. Il a ensuite successivement rejoint les deux grands groupes concurrents sur la proposition d'un modèle de standardisation :

– OIM (open information model), modèle proposé par Microsoft en 1996 ;

– CWMI (commun warehouse metadata interchange), modèle fondé sur XML et proposé par l'O.M.G. (Object Management Group) en 1998. De plus en plus d'outils deviennent compatibles avec ce dernier modèle, qui est en train de devenir un standard.