Integration Donnees - Traduction Synthese Taf Widom Stanford

Research Problems in Data Warehousing par Jennifer WIDOM Cet article a été écrit en Novembre 1995 par Jennifer Widom du département informatique de l'université de Stanford. L'auteur développe les aspects de migration de données des sources disponibles et d'intégration de ces données au sein du datawarehouse. Tout d'abord, elle présente les fondements de l'architecture d'un système fournissant ces fonctionnalités. Puis, elle présente les possibilités de recherche pour résoudre les problèmes d'architecture permettant plus de souplesse, plus de puissance et plus d'efficacité. La problématique du datawarehouse est de rassembler des données provenant d'informations internes à l'entreprise ou de sources d'informations externes afin de permettre aux utilisateurs un accès direct aux données pour des interrogations ou pour des analyses. L'approche datawarehouse, adaptée à des scénarios particuliers, se distingue d'une approche classique par plusieurs points. En approche classique, nommée approche "paresseuse" ou "sur commande", les informations ne sont disponibles que si la demande en a été faite. Elle est appropriée lorsque les informations changent rapidement, lorsque les désirs clients ne sont pas, à priori, déterminés ou pour des requêtes sur plusieurs grandes sources d'informations d'origine diverse. Ce processus se décompose en deux étapes : • •

A partir des requêtes, identifier les sources fournissant les informations demandées et les interroger. Obtenir le résultat, effectuer les traductions, les filtrages et les assemblages des données pour les fournir aux demandeurs.

Cependant, pour des raisons de coût, d'efficacité voir d'impossibilité d'obtenir le résultat attendu, on peut envisager une autre approche. Cette approche, nommée approche "impatiente" ou "en avance", est associée communément au stockage de données de type datawarehouse et à pour but d'entreposer et ne conserver que les données dignes d'intérêt pour des utilisateurs. Cette approche peut être aussi décomposée en deux étapes : •

Toutes les informations désirées sont extraites des sources à l'avance, traduites, filtrées de manière appropriée, agrégées et stockées dans un dépôt centrale.

•

La requête soumise est estimée par le dépôt sans accès aux sources originales. Dans cette approche, les informations sont immédiatement accessibles, avec des performances intéressantes, pour des requêtes et des analyses spécifiques à certains utilisateurs ou applications, sur des données historiques par exemple.

Les perspectives industrielles A la date de parution de cet article, pour les éditeurs de SGBD et chez de nouveaux acteurs, ce sujet est d'actualité. Ce type de système semble correspondre répondre aux besoins des entreprises : rassembler toutes leurs informations dans un unique endroit pour des analyses en profondeur et séparer cette partie analyse de la partie transactionnelle (OLTP). La plupart de ces offres étaient rigides et limités. Or un datawarehouse se doit d'être général, efficace, souple et mesurable, car il doit permettre des requêtes complexes avec peu ou pas de mise à jour et avec des temps d'accès les plus petits possible. De plus, on voit apparaître de nouveaux acteurs dans le domaine de l'aide à la décision ou le data-mining qui sont associés à ce domaine. Bien sur, il ne faut pas confondre la conception d'un datawarehouse avec l'aide à la décision bien que la justesse de l'un facilitera grandement l'utilisation de l'autre.

Architecture d'un système d'entrepôt de données. Cet article se concentre sur l'intégration de données. Cette partie est largement influencée par la conception de l'architecture du système. La figure suivante, tiré de l'article, schématise l'architecture fondamental du système sur lequel repose le datawarehouse

Cette figure représente un dépôt central mais on peut bien sûr considérer un système distribué avec parallélisme par exemple. Nous distinguons deux composants permettant l'intégration des données dans le datawarehouse Tout d'abord, en prise directe avec chaque source de données particulière, le préparateur ("wrapper") traduit les données au format et au modèle de données du datawarehouse. Le contrôleur ("monitor"), associé au préparateur, doit repérer automatiquement les changements intéressants dans les sources de données et en prévenir l'intégrateur. L'intégrateur joue un rôle de filtrage, de synthèse et d'agrégation ou d'unification des données afin de les intégrer au datawarehouse. Pour intégrer de nouvelles informations, l'intégrateur doit pouvoir obtenir des données supplémentaires ou manquantes (action représentée par les flèches en pointillées). Lorsqu'une modification importante dans les sources de données intervient (ajout ou suppression d'une source) pour le datawarehouse ou lorsque les informations changent, ces changements doivent être envoyés à l'intégrateur par le composant préparateur/contrôleur (action représentée par les flèches pleines). Des hypothèses sont émises en général pour les systèmes actuels. On suppose que l'entrepôt et les sources sont implémentés suivant un modèle unique (relationnel en général), que les procédures de mise à jour du datawarehouse sont faites en différés et que les requêtes de l'intégrateur vers les sources ne sont pas nécessaires.

Sujets de recherche En se basant sur l'architecture définie précédemment, l'auteur expose 5 thèmes de recherches pour améliorer les résultats de cette architecture. Notons, dès maintenant, une notion permettant de mieux comprendre les développements suivants. Au niveau abstrait, le datawarehouse peut être considéré comme un entrepôt de collections de vues matérialisées. Le module préparateur/contrôleur Ce type de composant assure deux rôles étroitement liés : o o

un rôle de traduction afin de présenter au datawarehouse des données intégrables. Ce problème est inhérent à l'intégration de données. un rôle de détection de changement afin d'avertir de toutes modifications pouvant être essentielles pour le datawarehouse, les modifications devant être bien sûr traduites.

Afin de bien comprendre l'importance d'un tel module, il faut s'intéresser aux sources de données. L'auteur les caractérise en 4 catégories : o

o o

o

les sources coopératives qui possèdent toutes les fonctionnalités des bases de données actives (triggers) et permettent d'obtenir les changements pertinents automatiquement. les sources traçables qui créent des enregistrements pouvant être consultés afin de repérer les changements les sources interrogeables qui permettent au préparateur/contrôleur, par sondages périodiques, d'interroger leurs informations afin de repérer les changements. Les performances sont fonction de la pertinence désirée des données et de la fréquence des sondages. Si la fréquence est trop élevée, les performances en pâtissent. Si elle trop faible, certains changements ne seront pas pris en compte. les sources statiques qui n'ont aucunes des fonctionnalités précédentes et dont les informations sont fournies "statiquement". Cela implique que les changements sont repérés par comparaisons de versions. On peut donc se douter de la difficulté d'une telle opération pour des masses importantes de données et surtout sur le fait qu'il faut repérer les changements pertinents à répercuter.

Quel que soit le type de source de données, l'aspect de traduction du préparateur reste indispensable. Il faut donc développer des représentations appropriées des changements de données surtout si le modèle n'est pas relationnel. Une autre solution pourrait être d'ignorer les changements et d'envoyer toutes les données périodiquement. Dans ce cas, l'intégrateur doit combiner ces données avec les données du datawarehouse ou réintégrer dans le datawarehouse toutes les données de la source. Cette

approche est envisageable lorsqu'il est possible de mettre hors service le datawarehouse. Cependant, le but visé étant l'efficacité, un accès continu aux données, il est préférable de repérer, d'envoyer de conserver les changements. Donc, le préparateur/contrôleur dépend de la source à traiter. Il est préférable ne pas le rendre statique. Une des attentes des concepteurs est de pouvoir développer des techniques et des outils qui automatisent la création de tels composants. l'intégrateur Si le datawarehouse est initialisé, le rôle de l'intégrateur est de gérer les informations provenant des modules préparateur/contrôleur. Il doit en assurer la maintenance. Les techniques classiques ne pouvant être envisagées, l'auteur propose plusieurs axes de recherches : o

o

o

o

o

Les vues du datawarehouse sont plus complexes que dans un système classique et notamment, il pose les problèmes des données historiques. On peut donc s'intéresser à l'inclusion de bases de données temporelles et sur les moyens de contrôler les informations historiques. Les datawarehouse contiennent des données très agrégées et synthétisées qui peuvent être décrite par un langage de vue classique bien que cela soit souvent difficile. La maintenance efficace de ces informations pose donc un problème ouvert. Une alternative pourrait être d'utiliser un langage de description adapté. La mise à jour des données dans les sources se font indépendamment du système où les vues sont stockées. Généralement, ces sources ne sont pas adaptées pour résoudre ce problème, la maintenance des vues étant souvent liée intimement au système sur lequel repose ces sources. Les types de sources vus précédemment nous démontrent la réalité du problème. Les sources ne participe pas à la maintenance des vues mais ne font qu'en rapporter les changements ou encore certaines sources ne fournissent pas de verrous et pas de transactions globales pour faciliter la tâche de l'intégrateur. Cela implique que des anomalies surviennent lors de la maintenance des vues et posent des problèmes de consistance. Il faudrait donc déterminer des algorithmes de mise à jour plus complexes que ceux disponibles à ce jour. La modification des vues à chaque mise à jour d'une information n'est pas nécessaire donc les grandes mises à jour classiques en différé ne sont pas la solution. Il faut proposer quelque chose de plus efficace. Il peut être nécessaire de modifier les sources de données avant leur intégration. Ces transformations peuvent comprendre l'agrégation ou la synthèse des données afin de réduire la taille du datawarehouse. Il peut être aussi souhaitable de corriger ou de supprimer des données, de créer des valeurs par défaut ou d'éliminer les doublons et les inconsistances.

Donc, au lieu de baser les intégrateurs sur le modèle de données du datawarehouse, il faut envisager un intégrateur particulier à chaque datawarehouse tant qu'il faudra considérer des vues différentes sur des sources différentes. Comme pour le préparateur/contrôleur, il

ne faut pas que l'intégrateur soit statique mais il faudrait plutôt fournir des outils et technique pour les générer automatiquement.

Spécification du datawarehouse En partant de l'analogie faite au début du chapitre, dans un contexte idéal, on peut considérer la maintenance du datawarehouse comme la maintenance de vues matérialisées. Les tâches de mise à jour sont faites par l'intégrateur et les changements sont repérés automatiquement par le préparateur. Classiquement, la maintenance des vues est effectuée par des algorithmes automatiques ou semi-automatique générés par des règles comme pour les bases de données actives. Chaque vue est associée à un trigger qui se déclenche lors des mises à jour. Une approche similaire peut être envisagée pour les datawarehouse lorsque l'intégrateur possède de telles fonctions. Cependant, les règles appropriées doivent être attachée à des fonctions bien plus complexes comme la récupération et le nettoyage d'informations complémentaires souvent sur des systèmes distants. De telles fonctions peuvent être automatiquement. Il faudrait, pour simplifier cette tâche, déterminer un langage de spécification, possédant des règles, des interfaces de préparateur/contrôle, des algorithmes appropriés permettant de générer l'intégrateur et un mécanisme automatique de détection de changement.

Optimisations Les optimisations peuvent être considérée sur 3 thèmes différents. Filtrer les modifications non pertinentes des sources et mise à jour des flux Par analogie avec la maintenance de vue et en considérant le cas relationnel, toutes les modifications participant aux vues du datawarehouse devraient se propager. Il serait donc appréciable de pouvoir déterminer les modifications laissant les vues inchangées, mais aussi d'établir des techniques permettant de vérifier les contraintes d'intégrité sur une source distante lors des modifications. Tout ceci afin de choisir le filtrage des sources à la propagation totale vers l'intégrateur. Stocker les données supplémentaires du datawarehouse pour une auto - maintenance. L'intégrateur peut avoir besoin de récupérer des données supplémentaires auprès d'une source lorsqu'il reçoit une notification de changement. Soumettre les requêtes lourdes directement aux sources peut occasionner des délais de traitement long. Cela peut aussi générer des anomalies d'intégration ou des problèmes de sécurité pour les sources. Afin de garder la consistance, il faut éviter d'interroger directement les sources de données. D'où l'idée d'une vue "automaintenable" n'ayant pas besoin de requêtes supplémentaires pour gérer la maintenance. Pour cela, il faut stocker les données supplémentaires dans le datawarehouse. Pour que cela soit acceptable, il faut le nombre minimum d'informations supplémentaires afin d'assurer l'automaintenabilité d'une vue. Avec cela, il faut déterminer

le moyen de mesurer le coût de maintenance de données supplémentaire par rapport au coût des requêtes directes aux sources. Gérer efficacement les vues matérialisées et optimiser la multiplicité des vues. Si l'on peut générer des "sous vues" partagées permettant d'obtenir toutes les vues du datawarehouse, on peut réduire les coûts de stockage et réduire l'effort fourni pour les modifications. Cependant, il faut opposer à cela la lenteur de la réponse des requêtes du fait d'une génération dynamique de vues. Il faut donc trouver le moyen de déterminer la solution idéale en fonction du contexte.

Autres sujets d'étude o

o

o

o

La gestion de l'entrepôt Ce problème a été au cours des études notamment la conception, le chargement et gestion des méta données. L'évolution des sources et du datawarehouse Le datawarehouse doit offrir la possibilité de gérer les changements des sources de données comme le changement de schéma, la disparition ou l'apparition de sources. Il doit être aussi capable d'accepter les modifications apportées à son schéma Doublons et inconsistance En environnement hétérogène, des données peuvent être répétées plusieurs fois et conduisent à l'inconsistance, l'intégrateur doit être capable de nettoyer les données de sources multiples pour éliminer les doublons et les inconsistances Informations périmées Le datawarehouse est un système de gestion de l'historique. Néanmoins, on ne garde pas éternellement toutes les informations. Des techniques doivent être mise en oeuvre pour gérer automatiquement ce type de problème.

Conclusion Dans cet article, l'auteur réalise un exposé clair et complet sur la problématique posée par la migration et l'intégration des données. Cependant, elle n'évoque pas des problèmes caractéristiques aux gestionnaires de bases de données comme les problèmes de reprise sur panne : Qui doit effectuer les reprises nécessaires lorsque la migration des données est interrompue ? L'intégrateur ou le préparateur/contrôleur directement en prise avec l'information ? Un autre type de problème en marge de ceux évoqués dans l'article est l'aspect hardware sur lequel réside tout le système datawarehouse et notamment la communication des systèmes d'exploitation pour la conception du préparateur/contrôleur. Comment intégrer des données provenant de système Macintosh ou windows pour un datawarehouse sur UNIX par exemple ? Bien sur, il existe des passerelles logiques pour palier à ces problèmes. Dans ce cas, où doit résider le préparateur/contrôleur ?

Plus généralement, est ce que l'environnement du système du datawarehouse n'influence pas les décisions quant aux choix des outils de migrations ? Depuis la parution de cet article, l'évolution de cette discipline montre que dans le but d'intégrer des sources multiples, hétérogènes, distribuées, le datawarehouse est une approche viable et souvent supérieure aux solutions classiques. Pour finir quelques chiffres. Les effets de l'acquisition d'un tel système dans une entreprise sont en général très sensible. En moyenne, on peut estimer un retour sur investissement médian de 167% sur une période de 1,67 ans (étude IDC96). Les problèmes évoqués par l'auteur restent toujours d'actualité et intéresserons, je pense, aussi bien les sociétés spécialisées que le monde de la recherche.