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 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.
o 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 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.
o les sources traçables qui créent des enregistrements pouvant être consultés afin de
repérer les changements
o 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.
o 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 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.
o 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é.
o 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.
o 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.
o 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 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.
o 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
o 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
o 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.