ARCHITECTURE TECHNIQUE DU DATAWAREHOUSE
3 architectures technologiques typiques et classiques pour le stockage de grandes quantités de
données pour des fins décisionnelles : SMP, MMP et Cluster.
SMP (Symetric Multi-Processing)
Principe : le modèle d'architecture de type "SMP" est fondé sur l'exploitation de plusieurs
processeurs identiques oeuvrant en parallèle et partageant une mémoire commune.
Inconvénients : la mémoire est unique, la synchronisation de l'accès à la mémoire par les différents
processeurs constitue le principal inconvénient de ce type d'architecture.
MMP (Massively Parallel Processing)
Principe : le modèle d'architecture de type "MPP" est fondé sur l'exploitation d'un nombre
important de processeurs. Chaque processeur dispose de sa propre mémoire.
Inconvénient : il nécessite des développements spécifiques. Les traitements doivent être
prévus dès la conception pour une exécution sur ce type d'architecture.
Cluster
o Principe : : avec l´architecture de type "Cluster", les ordinateurs sont organisés en
"grappes". Ils sont interconnectés par des liaisons rapides Ethernet. Sur le plan du principe,
le fonctionnement est assez proche de l'architecture MMP.
o Inconvénient : : le programme à exécuter doit impérativement être développé pour ce type
d'architecture.
Architecture générale
L’ architecture technique de l’entrepôt de données et de tout ce qui gravite autour de lui qui constitue la
charge principale de développement et d’exploitation du SID.
Entre l’environnement de requête et de présentation offrant à l’utilisateur une information conditionnée selon
son propre point de vue, d’une part, et les sources de cette information (principalement les chaînes de
production, éventuellement complétées par des apports externes) d’autre part, il existe une double distance :
· les données sources ne sont ni sémantiquement cohérentes, ni synchrones, ni liées entre elles d’une
manière adaptée à la perspective décisionnelle;
· les environnements – généralement hétérogènes – d’où proviennent ces données sont conçus et
organisés autour de technologies (anciennes ou récentes) qui se prêtent mal à l’implémentation directe
d’applications décisionnelles avancées.
D’autre part, le SID se doit, par rapport au SIO, d’adopter un profil bas. Pour la production quotidienne, le
déploiement du data warehouse doit être aussi neutre que possible. Même si le SID est, à terme, un
instrument privilégié du changement dans l’organisation, il ne doit pas s’imposer d’emblée comme une
source de contraintes techniques immédiates pour les applications existantes. De même, les utilisateurs du
SID ne doivent pas subir directement les contraintes d’exploitation liées à la production.
L’architecture du système doit donc assurer à la fois le conditionnement informationnel des données en
provenance de la production et le cloisonnement entre l’environnement opérationnel et l’environnement
décisionnel.
Les outils, les modalités d’agencement des composants, les performances requises, peuvent varier à l’infini,
selon la taille et le contenu des projets. Mais, quels que soient les volumes traités, les performances requises
et les périmètres concernés, la chaîne de mise à disposition des données implique quatre fonctions
fondamentales :
· collecte ;
· intégration ;
· diffusion ;
· présentation.
Même si chaque projet présente des aspects irréductiblement spécifiques, ces quatre fonctions sont toujours
présentes dans un Système d’Information Décisionnel. Leur existence implique certaines constantes dans les
architectures. En outre, c’est toujours par référence à l’une ou l’autre de ces fonctions de base que chaque
composant doit s’insérer dans le système.
• La fonction de collecte est celle qui assure l’approvisionnement du SID en données primaires puisées dans
le SIO et subsidiairement à l’extérieur ;
• La fonction d’intégration assure la cohérence globale, au moins à l’échelle d’un domaine, des données
capturées, et leur mise à disposition en un point unique, conformément à un modèle unifié et normalisé ;
• La fonction de diffusion puise les données dans l’entrepôt central produit et maintenu par la fonction
d’intégration, et les met à la disposition des applications, sous une forme dimensionnelle, contexte par
contexte ;
• La fonction de présentation gère, au moyen de services logiciels plus ou moins élaborés et plus ou moins
déterministes, l’accès de l’utilisateur final aux données organisées par la fonction de diffusion.
L’identification de ces fonctions primaires permet de s’appuyer sur un cadre de référence de portée générale
et d’aborder le choix et l’intégration des outils sur des bases plus sûres.
Il serait toutefois excessivement simpliste et contraignant de déduire de l’inventaire de ces quatre fonctions
l’existence obligatoire d’autant de dispositifs techniques (matériels et logiciels) distincts. En fait, il n’y a
jamais de coïncidence précise entre les organes physiques et les fonctions.
Avant d’examiner plus précisément le contenu et l’agencement de ces services, il est utile de faire
l’inventaire des architectures intermédiaires ou dégradées qui, sans correspondre à de véritables SID, sont
souvent mises en œuvre pour produire des tableaux de bord et autres présentations informationnelles de
données.
6.1 Systèmes intermédiaires
L’exploitation informationnelle des données de production n’a pas attendu l’émergence du data warehouse.
Depuis toujours, on met ou on tente de mettre à la disposition des décideurs des données conditionnées de
manière à être plus ou moins assimilables à des informations de pilotage.
6.1.1 Tableaux de bord opérationnels
La distinction entre opérationnel et décisionnel étant très récente, les applications de production elles-mêmes,
dans le prolongement de leurs objectifs principaux, produisent le plus souvent des éditions systématiques.
Faute de mieux, ces états de sortie sont parfois utilisés à des fins décisionnelles. Plus généralement, ils ne
sont là qu’à des fins de contrôle ou de sécurité. A vrai dire, il est même fréquent que ces éditions, nées de
spécifications anciennes et maintenues par routine, soient tout simplement inutilisées.
La fourniture directe d’informations décisionnelles au plein sens du terme par la production n’est pas, en
réalité, sérieusement envisageable, pour les raisons suivantes :
• Une application de gestion ne dispose que de ses propres données et ne peut pas offrir de vision
informationnelle adaptée au périmètre d’un domaine d’analyse ;
• Toute nouvelle requête informationnelle nécessite une activité de maintenance évolutive sur les
programmes, voire sur les structures de données, de l’application. Il en résulte non seulement des coûts de
développement qui peuvent devenir, à terme, astronomiques, mais aussi des délais d’attente prohibitifs ;
Jean-Marie Gouarné 73 Le Projet Décisionnel
• Les contraintes de l’exploitation quotidienne prévalent sur les besoins décisionnels.
L’existence de modules informationnels dans les applications de production, quelle que soit son utilité par
ailleurs, ne peut donc rendre un service comparable à celui d’un SID.
Compte tenu des structures budgétaires et mentales dans lesquelles s’exerce l’activité informatique, il est
beaucoup plus facile d’ajouter une extension informationnelle à une application de production que de
prendre l’initiative d’un data warehouse . Les coûts des extensions de ce type ne sont jamais mesurés de
façon continue et globale. Pourtant, sur une longue période, s’ils apparaissaient consolidés sur une ligne
comptable, ils contribueraient sans doute à relativiser le poids des investissements imputables aux SID !
A ces coûts et contraintes directs s’ajoutent des effets dérivés. A partir des éditions hétéroclites qui leur
parviennent, les utilisateurs ont fréquemment tendance à utiliser des moyens de fortune (tels que des
applications personnelles développées à l’aide de tableurs ou de gestionnaires de bases de données «
portatives ») pour obtenir des vues plus informationnelles sur les données. Ces outils d’analyse éparpillés,
alimentés généralement par des saisies manuelles redondantes, représentent des coûts impossibles à chiffrer.
Leur développement et leur utilisation impliquent notamment que les stratèges et les analystes dépensent une
plus ou moins grande part de leur énergie à faire autre chose que leur métier.
Ce type d’architecture, en tout cas, correspond à ce qu’il faut bien considérer comme le niveau zéro de
l’information décisionnelle.
6.1.2 Interfaces de présentation
Certains systèmes mettent à la disposition des utilisateurs une interface de dialogue autorisant la formulation
de requêtes interactives ou à exécution différée. Les fonctions de collecte, d’intégration et de diffusion étant
absentes, les requêtes s’adressent directement aux bases de données de production.
Interface de Requête
Source Source Source
1 2 3
Figure 6-1 – Accès direct aux données opérationnelles
Cette configuration répond sans doute à l’un des objectifs d’un SID, dans la mesure où elle est théoriquement
capable de traiter des requêtes non prédéterminées. Mais elle laisse subsister les barrières les plus
fondamentales. Elle ne lève qu’un obstacle purement technique, celui de la connexion de l’utilisateur aux
sources de données. Les données restent ce qu’elles sont : hétérogènes et incohérentes. L’outil de
présentation n’est jamais qu’un extracteur de données à partir desquelles la vision du contexte informationnel
est à construire.
Ce type d’environnement présente en outre l’inconvénient majeur d’être entièrement soumis aux contraintes
de la production courante. Face aux bases de données actives, les transactions de production sont
nécessairement prioritaires. Le traitement des requêtes décisionnelles s’effectue donc dans le cadre de règles
d’exploitation classiques, où les notions de file d’attente et de tranche horaire l’emportent sur celles
d’interactivité et de temps de réponse.
Jean-Marie Gouarné 74 Le Projet Décisionnel
6.1.3 Collecte et présentation
Plus élaborées, d’autres architectures assurent, en plus de la fonction de présentation, la fonction de collecte.
Ainsi, les requêtes émises à l’aide de la fonction de présentation portent sur un réservoir de données copiées
(ou, pour employer le terme à la mode, répliquées) à partir des bases de production. Ce type d’organisation,
parfois désigné sous le nom d’infocentre69, est sans doute la forme primitive du data warehouse, avec lequel
il est parfois confondu.
Cette configuration, quelle que soit la désignation qu’on lui donne, représente une avancée considérable en
termes de disponibilité des données, puisqu’elle introduit une séparation physique entre les bases de
production et les bases d’analyse. Les requêtes sont exécutées sur des supports physiques dédiés. L’activité
d’analyse est donc, dans une large mesure, libérée des contraintes les plus directement liées à l’exploitation
opérationnelle.
Interface de Requête
Base de données
dédiée
Collecte
Source Source Source
1 2 3
Figure 6-2 – Architecture d'Infocentre
Cette « libération » est cependant toute relative :
• Faute d’un véritable outil d’intégration, les données provenant des différentes sources sont simplement
juxtaposées. Aucun modèle de données consolidé n’est mis en œuvre. L’unification est seulement
physique ; elle n’est pas réalisée au niveau conceptuel. L’utilisateur ne peut trouver, dans cet entrepôt, que
des bribes de modèles de données hétérogènes et généralement peu documentées. Si son domaine
d’analyse dépasse le périmètre d’une des sources, c’est à lui de naviguer, sous sa responsabilité et
éventuellement sans boussole, dans le flot des données disponibles. L’utilisateur est souvent amené à
choisir entre l’abandon d’une tâche d’analyse trop compliquée et l’appel à l’équipe informatique, avec
toutes les contraintes et les frustrations que suppose une telle alternative ;
• Les données brutes étant dans la plupart des cas inexploitables, l’entrepôt est alimenté, au moins en partie,
par des procédures d’extraction qui opèrent un certain travail de transformation et de mise en forme. Ces
mécanismes d’alimentation sont généralement développés sur la base de besoins exprimés à différentes
époques par différents utilisateurs, sans coordination d’ensemble. Certains d’entre eux ne font d’ailleurs
que répliquer dans des structures différentes des données déjà chargées par d’autres. Il en résulte une
croissance simultanée de la redondance et du désordre, d’où une difficulté croissante à maintenir ce genre
de système ;
69
Le concept d’information center est apparu aux Etats-Unis au début des années 80. Selon certaines définitions, l’ infocentre se
distingue du SID non seulement par son architecture logique (une seule base de données, pas de vision informationnelle unifiée) mais
aussi par sa volatilité (représentation de données actuelles sans conservation d’historique). En réalité, l’infocentre n’a jamais eu de
définition stable et unanimement reconnue.
Jean-Marie Gouarné 75 Le Projet Décisionnel
• En l’absence de service de diffusion, toutes les requêtes agissent directement sur l’entrepôt central de
données, lequel doit par ailleurs être périodiquement rechargé. Il y a là, par conséquent, un point de
contention qui peut faire réapparaître les files d’attente et faire obstacle à un usage intensif de l’infocentre.
6.1.4 Collecte, intégration et présentation
On trouve aussi des infocentres évolués, dans lesquels, en plus des fonctions de collecte et de présentation, la
fonction d’intégration est partiellement ou totalement assurée. Les utilisateurs disposent donc de données non
seulement rassemblées, mais aussi unifiées et normalisées, c’est-à-dire organisées selon un modèle cohérent.
Le développement des environnements de ce type a été favorisé par la généralisation des systèmes de gestion
de bases de données relationnelles (SGBDR) et des environnements client-serveur.
Par rapport au modèle d’infocentre présenté au §6.1.3, l’avantage majeur est l’accès à une véritable base de
données, au lieu d’une collection hétérogène de copies. Les données peuvent donc être organisées selon le
périmètre et le vocabulaire du domaine concerné, et non selon les points de vues disparates des applications
produisant les données primaires, en éliminant toute redondance inutile.
Interface de Requête
Base de données
dédiée
Intégration
Collecte
Source Source Source
1 2 3
Figure 6-3 – Infocentre intégré
Il serait dangereux de croire que la seule combinaison d’une base de données relationnelle et d’un outil de
requête produise d’elle-même un infocentre intégré. L’intégration implique, en aval de la collecte, une
activité de transformation (parfois profonde) des données captées, et cette activité ne peut être spécifiée que
sur la base d’un Modèle Conceptuel de Données.
L’infocentre intégré suppose donc une véritable démarche de génie logiciel et se distingue en cela des
systèmes alimentés par des extractions à la demande.
Le gain pour l’utilisateur, en matière de lisibilité des informations, est sensible par rapport à l’architecture
précédente. D’autre part, l’existence d’un modèle de données d’ensemble est censée éviter le développement
non planifié de nouvelles procédures d’extraction indépendantes les unes des autres.
Jean-Marie Gouarné 76 Le Projet Décisionnel
Ce modèle de données, toutefois, ne correspond pas directement à la vision décisionnelle. Dans la pratique,
même si le modèle est irréprochablement normalisé (ce qui n’est pas toujours le cas), il s’agit presque
toujours d’un modèle de type opérationnel au sens où on l’a présenté dans la section 3.4.
Ceci s’explique naturellement en partie par la tendance générale des administrateurs de données à normaliser
selon les méthodes qu’ils ont apprises (et donc en s’inspirant exclusivement de la 3 ème Forme Normale).
Cette tendance est d’ailleurs encouragée par les éditeurs de logiciels de présentation, qui proclament souvent
que les vues décisionnelles, dans un infocentre, sont du ressort exclusif de leurs produits. Mais à cette
explication culturelle s’en ajoute une autre, plus technique : l’absence de distinction entre la fonction
d’intégration et la fonction de diffusion. Il est en effet difficile de concilier, dans un même modèle de
données, un objectif d’unification de sources opérationnelles avec une approche à base de contextes
dimensionnels (cf. §6.3).
Enfin, comme dans le modèle précédent, les requêtes décisionnelles mettent directement à contribution la
base de données intégrée, et sont donc tributaires du même type de contraintes d’exploitation.
6.2 L’architecture de référence du SID
Le bon sens et la pratique ont déjà largement démontré qu’une architecture monolithique n’était pas en
mesure de faire face à l’ensemble des objectifs et des contraintes qui s’imposent à un véritable Système
d’Information Décisionnel. Entre la donnée opérationnelle brute et l’information décisionnelle effectivement
disponible, les quatre fonctions fondamentales ne peuvent être organisées que selon une architecture en
plusieurs « couches ».
Système de Diffusion
et de Présentation
Système de Collecte
et d'Intégration
Source Source Source
1 2 3
Figure 6-4 – Architecture de référence du SID
L’organisation en couches, popularisée initialement dans le monde des transmissions de données 70, a le
mérite de s’appliquer avantageusement à tous les dispositifs techniques destinés à mettre en relation des
70
Notamment dans le modèle d’interconnexion des systèmes ouverts de l’ISO qui, entre autres qualités, possède 7 couches, et
respecte donc l’usage indiqué dans la note 72.
Jean-Marie Gouarné 77 Le Projet Décisionnel
environnements hétérogènes. Elle permet notamment de limiter l’interdépendance entre les fonctions, et de
mieux maîtriser la complexité des protocoles et des interfaces. Pour ce qui concerne le SID, elle permet
notamment de concevoir les fonctions de diffusion et de présentation indépendamment des fonctions de
collecte et d’intégration, et d’assurer un maximum d’isolation entre l’utilisateur et les sources de données.
Cela dit, il n’est pas absolument indispensable que les quatre fonctions du SID, telles que nous les avons
définies, coïncident précisément avec quatre couches techniques.
Quels que soient le nombre de composants logiques et physiques effectivement mis en œuvre et les
technologies employées, il convient essentiellement de distinguer dans le SID deux dispositifs distincts :
· le Système de Collecte et d’Intégration (SCI) ;
· le Système de Diffusion et de Présentation (SDP).
Chacun de ces deux sous-ensemble gère – comme son nom l’indique – deux des quatre fonctions vitales que
nous avons identifiées.
Ce découpage fondamental est lié à la cohabitation, dans le système, de modèles de données différents, de
contraintes de fonctionnement différentes et des liens d’interdépendance entre les fonctions.
6.3 Architecture et Modèles de Données
L’une des caractéristiques structurantes d’un SID est la nécessité dans laquelle il se trouve de gérer
simultanément, d’une manière ou d’une autre, trois modèles de données :
· le Modèle d’Intégration (MI) ;
· le Modèle de Diffusion (MD) ;
· le Modèle de Présentation (MP).
Le rôle de chaque outil logiciel dans l’architecture du SID se définit et s’apprécie essentiellement par
référence à l’un de ces modèles de données.
Dans la pratique, ces modèles sont désignés par des appellations diverses, souvent liées au vocabulaire
hétérogène des éditeurs de logiciel. Il n’est pas rare, en outre, que la distinction ne soit pas clairement
reconnue et comprise. Ceci produit inévitablement des architectures compliquées et peu maintenables, dans
lesquelles toutes les fonctions sont inextricablement imbriquées.
Jean-Marie Gouarné 78 Le Projet Décisionnel
Modèle de
Présentation
Modèle de
Diffusion
Modèle
d'Intégration
Figure 6-5 – Architecture et modèles de données
Le Modèle Conceptuel de Données qui spécifie et caractérise un domaine d’analyse du SID, tel qu’il est
défini au chapitre 4, correspond au Modèle de Diffusion . Ce dernier représente en effet la structure
dimensionnelle – éventuellement multiforme s’il existe une pluralité de domaines et de contextes – selon
laquelle les données doivent être mises à la disposition des applications décisionnelles. Cette structure,
naturellement, ne correspond pas au schéma selon lequel les données sont manipulées par le Système
d’Information Opérationnel. De là découle la nécessité de distinguer Modèle d’Intégration et Modèle de
Diffusion.
Pendant et/ou après leur concentration physique par la fonction de collecte, les données sources sont filtrées,
transformées et unifiées conformément à un modèle normalisé que nous désignons comme le Modèle
d’Intégration. Ce dernier est le modèle conceptuel d’une base de données logiquement et physiquement
cohérente, mais dont la structure reflète les opérations. En effet, la fonction du Modèle d’Intégration est
d’unifier les données opérationnelles, et non de les structurer en contextes d’analyse décisionnelle. Le MI est
le modèle conceptuel de toutes les données du SID ; à l’échelle d’un projet, il est unique et complet.
La définition du Modèle d’Intégration implique une approche méthodologique classique, fondée sur le
paradigme entité-association et comportant, notamment, le respect des principes de normalisation appropriés
aux modèles de données opérationnels.
Le MI est la description sémantique complète de l’entrepôt de données proprement dit.
Il se distingue en cela du MD. Ce dernier, orienté vers l’utilisateur décisionnel, peut être compartimenté en
domaines distincts et éventuellement disjoints. Chacun de ces domaines peut correspondre à une base de
données particulière alimentée à partir du data warehouse mais physiquement distincte.
Le MD, entendons-nous bien, n’est pas seulement un MI en pièces détachées. Le découpage du MD en sous-
ensembles logiques découle de sa construction à partir de vues dimensionnelles multiples, et non d’un
partitionnement technique du MI. Le MD représente l’ensemble des perspectives spécifiquement recherchées
sur l’information contenue dans l’entrepôt de données.
Pour employer un terme aussi populaire que mal défini dans la littérature informatique, on peut parfois
concevoir le MD comme le modèle conceptuel d’une grappe de data marts (magasins de données) gravitant
autour d’un data warehouse. Mais cette assimilation n’est acceptable qu’avec réserve. Le concept de data
Jean-Marie Gouarné 79 Le Projet Décisionnel
mart évoque sans grande précision une base de données décisionnelle de volume modeste 71. Pour certains, il
ne semble y avoir entre data warehouse et data mart qu’une différence d’échelle. Or un Modèle de Diffusion
peut parfaitement être implémenté dans une base de données unique au moins aussi chargée que la base
d’intégration72. De la boutique au supermarché, les magasins, comme les entrepôts, peuvent être petits ou
grands.
La distinction intégration-diffusion a été mise en évidence, de façon beaucoup plus pertinente, à travers les
notions de Business Data Warehouse (BDW) et de Business Information Warehouse (BIW)73 . Ces deux
concepts relèvent d’une approche méthodologique qui a le double mérite de distinguer donnée et information
et d’en tirer des conclusions précises en termes d’architecture.
La séparation logique (et, si possible, technique) entre le Modèle d’Intégration et le Modèle de Diffusion est
une nécessité confirmée par l’expérience et sur laquelle nous croyons devoir insister.
Le Modèle d’Intégration n’est autre, sur le plan conceptuel, qu’une représentation consolidée et épurée des
sources de données intéressant le SID. A la limite, si la source était une application opérationnelle unique
ayant été conçue selon une approche méthodologique impeccable, le Modèle d’Intégration serait le modèle
de données de cette application, transformé de manière à rendre compte de l’historique. En pratique,
l’élaboration du MI est une œuvre de rétro-conception qui prend en entrée des schémas de données
hétérogènes et produit en sortie un schéma de données unique normalisé. La normalisation signifie ici
notamment l’élimination des redondances et l’unification du vocabulaire. L’unification concerne aussi bien
la désignation des entités et des propriétés que la codification du contenu.
Les structures de données apparaissant dans le Modèle d’Intégration doivent être représentées dans leur
contexte opérationnel, c’est-à-dire agencées les unes par rapport aux autres selon leurs situations respectives
dans les processus de production. En effet, même s’il n’avait pas d’autre objectif, le Modèle d’Intégration,
s’il était exhaustif à l’échelle de l’entreprise, serait une représentation intermédiaire indispensable pour
décrire l’usage de chaque donnée dans l’organisation. La connaissance de l’usage exact des données et de
leurs dépendances fonctionnelles dans le SIO est en effet un préalable à son insertion dans un contexte
dimensionnel du SID. Par conséquent, les principes de construction du MI sont les mêmes que ceux qui
s’appliquent aux Modèles Conceptuels de Données opérationnels (cf. section 3.4). Le Modèle d’Intégration
est donc d’abord un MCD en 3ème Forme Normale.
Un tel Modèle d’Intégration pourrait être considéré comme un simple document intermédiaire de
spécification et n’avoir d’existence que sur le papier. Mais ce choix, loin de simplifier l’architecture,
imposerait des contraintes de conception et de fonctionnement très lourdes dans le SID.
La structure des contextes décisionnels est très éloignée des structures de données traitées par les
applications opérationnelles. D’autre part, les traitements liés à la collecte sont déjà généralement très lourds.
Si l’intégration devait être directement effectuée dans la base de données de diffusion, il faudrait, dans les
mêmes chaînes de traitement, réaliser à la fois l’intégration et la redistribution des données sous forme de
contextes dimensionnels. Un tel choix d’architecture serait très pénalisant en termes de performances,
compte tenu de la complexité de ces différents traitements.
Mais les raisons essentielles de la distinction entre base d’intégration et base(s) de diffusion sont d’un autre
ordre :
• Les besoins des utilisateurs du SID évoluent plus vite que les applications du SIO. Les contextes
dimensionnels qui constituent l’essence du Modèle de Diffusion représentent chacun un parti pris
d’analyse valable à un moment particulier. Or, à terme, les points de vue changent et se multiplient. A
l’opposé, le Modèle d’Intégration présente, au moins en courte période, une structure invariante. Son
évolution suit celle des applications de production sur lesquelles il s’appuie ; elle est donc beaucoup plus
71
Certains préfèrent au data mart la notion, plus significative, de base de données thématique. Mais pour d’autres, le data mart
semble n’être qu’un petit data warehouse, ce qui reflète indirectement un défaut de distinction claire entre les différents organes d’un
SID.
72 Une base de diffusion peut être physiquement plus volumineuse que la base d’intégration qui l’alimente, compte tenu des
techniques employées pour réduire les temps de traitement des requêtes (cumuls pré-calculés, données redondantes, index, etc).
73 Ces notions, introduites par IBM, sont présentées de manière précise dans l’ouvrage de B. Devlin, « Data Warehouse, from
Architecture to Implementation », Addison-Wesley 1996.
Jean-Marie Gouarné 80 Le Projet Décisionnel
lente que celle des applications décisionnelles. Le MI est donc l’élément de référence le plus stable du SID
;
• Le Système de Collecte et d’Intégration synchronise des données qui, dans le SIO, ne sont pas à jour les
unes par rapport aux autres (cf. §3.5.3) et, pour s’approvisionner, doit s’adapter aux contraintes
d’exploitation de chacune de ses sources. En revanche, compte tenu des objectifs du SID, la base de
données de diffusion est obligatoirement dans un état cohérent tant qu’elle est ouverte aux consultations.
Si la base d’intégration et la base de diffusion sont physiquement confondues, l’administration des mises à
jour est nécessairement plus délicate ;
• Les outils et techniques les mieux adaptés au traitement des consultations complexes sur des contextes
dimensionnels ne sont pas les plus efficaces pour la collecte et l’intégration des données à partir de sources
hétérogènes. Pour ce qui concerne plus particulièrement les Systèmes de Gestion de Bases de Données
(SGBD), il convient d’utiliser la technologie la mieux appropriée à chaque fonction, ce qui implique une
séparation physique entre bases d’intégration et bases de diffusion.
Les modèles d’intégration et de diffusion doivent donc non seulement être distingués conceptuellement mais
encore être mis en œuvre séparément sous forme de bases de données distinctes. L’entrepôt de données n’est
pas l’entrepôt d’informations.
Le Modèle de Présentation, lui, n’est pas un élément profondément structurant du SID. Il en constitue en
quelque sorte le décor. Toutefois, l’utilisateur final lui attribue habituellement la primeur, puisque ce n’est
qu’à travers lui qu’il voit les données.
En termes d’architecture, le Modèle de Présentation n’est qu’un masque – plus ou moins transparent – qui
recouvre, pour l’utilisateur, le Modèle de Diffusion. Ce dernier est une représentation interne de la vision
informationnelle. Un utilisateur final ne raisonne pas en termes de dimensions changeantes, de contextes
qualifiés et d’indicateurs semi-additifs. Il maîtrise encore moins les langages d’interrogation des SGBD
(relationnels ou matriciels) qui contrôlent le Modèle de Diffusion. L’accès au MD nécessite donc une
interface homme-machine, elle-même déterminée sur la base d’un Modèle de Présentation.
Le MP, comme le MI, doit être distingué du MD à différents égards :
• Le MP est en réalité multiforme : avec la variété des outils de présentation actuels et la liberté qu’ils
laissent à l’utilisateur, on peut associer une grande variété de cadres de présentation à une même structure
de diffusion ;
• La structure d’un MP (et sa modification éventuelle) n’est pas critique pour le data warehouse. A la limite,
un utilisateur averti peut créer ou détruire des Modèles de Présentation personnels sans conséquence pour
les autres utilisateurs ;
• Dans les environnements client-serveur – les plus généralement utilisés aujourd’hui et sans doute dans
l’avenir à moyen terme pour les projets décisionnels – le MP est normalement mis en œuvre sur le poste
de travail de l’utilisateur (client) tandis que le MD est plutôt implémenté sur un serveur de données 74.
En pratique, un Modèle de Présentation peut être ouvert ou fermé. Dans un MP ouvert, l’utilisateur dispose
d’une vue générale du MD, contexte par contexte, et peut librement composer ses propres requêtes. A
l’opposé, un MP fermé présente un catalogue de requêtes prédéfinies, que l’utilisateur peut seulement
paramétrer. Entre les deux, il existe une gradation infinie de possibilités de compromis entre liberté et facilité
d’utilisation.
Les Modèles de Présentation sont physiquement gérés par des outils très dissemblables (requêteur, tableur,
SIAD75, etc.) provenant de nombreux fournisseurs dont les vocabulaires sont fortement hétérogènes. Une
typologie de ces produits est proposée au chapitre 8. Concernant le rôle du MP dans l’architecture du SID, un
piège classique mérite d’être signalé ici.
La publicité développée autour des outils de présentation et le fait que ces outils soient associés à la partie
émergée du SID tendent à entretenir une certaine confusion, auprès du concepteur naïf, sur le rôle du Modèle
de Présentation, en lui attribuant, de fait, celui du Modèle de Diffusion. En d’autres termes, on imagine
parfois que les outils de présentation produisent à eux seuls des vues décisionnelles sur des bases de
74 La distinction est cependant plus subtile dans une architecture d’hypertexte distribué (Web).
75 Système Interactif d’Aide à la Décision
Jean-Marie Gouarné 81 Le Projet Décisionnel
données opérationnelles. Ceci revient à ignorer les aspects les plus délicats et les plus décisifs de l’entrepôt
de données.
Le Modèle de Présentation a pour vocation de dispenser l’utilisateur de toute manipulation technique directe
sur une base de données et de lui offrir un accès ergonomique à des vues adaptées à son métier. Ces vues
doivent cependant s’inscrire dans des contextes préalablement spécifiés et mis en œuvre dans un Modèle de
Diffusion : le MP est un complément du MD.
Le placage direct d’un Modèle de Présentation sur un Modèle d’Intégration (non organisé pour les requêtes
multidimensionnelles) correspond précisément à l’architecture d’infocentre intégré (voir Figure 6-3) dont on
a présenté les limites. En matière d’accès physique aux données, il comporte en outre deux sortes
d’inconvénients :
· Plus le schéma de la base de données est éloigné de la structure dimensionnelle de chaque contexte,
plus l’effort d’élaboration du MP est important. Or, dans l’état actuel des outils, et toutes choses égales
par ailleurs, le coût de développement d’un MP sur une structure de données interne inadaptée s’avère,
d’après nos observations, à la fois considérable et imprévisible ;
· Les requêtes adressées par l’utilisateur via le MP sont dynamiquement traduites par des requêtes à la
base de données. Si le modèle interne de cette base est un schéma relationnel dans lequel les
informations d’un même contexte sont dispersées dans un grand nombre de tables et si les agrégats les
plus usuels ne sont pas précalculés, l’outil de présentation doit élaborer une stratégie lourde et
soumettre au SGBD des enchaînements de requêtes faisant appel à des jointures complexes. Une
requête mettant en jeu trois à six tables dans un schéma dimensionnel approprié peut parfaitement faire
appel à dix, quinze ou vingt tables dans un schéma classique de type opérationnel. Les temps de
réponse peuvent alors devenir intolérables, et les incidents fréquents.
L’apparente facilité de manipulation et la richesse graphique des outils de requête, ainsi que leur aptitude à
masquer, pour l’utilisateur final, les aspects techniques de la négociation avec les bases de données, ne
doivent donc pas faire illusion. Le MP, à la différence des deux autres modèles de l’architecture, n’est pas
associé à une capacité de stockage significative 76. Il n’est qu’un support du dialogue entre l’utilisateur et la
base de données, et son rôle n’est pas de combler la distance structurelle qui existe entre un modèle de
données opérationnel et un modèle de données décisionnel.
On voit couramment, dans la pratique, des équipes de conception aborder la construction d’une application
décisionnelle par le choix d’un outil interactif de requête et de visualisation, et par l’élaboration de Modèles
de Présentation définis en fonction des possibilités et des limites de cet outil. L’importance du modèle
dimensionnel interne, c’est-à-dire du Modèle de Diffusion, est alors ignorée : on compte sur les astuces de
l’outil de présentation pour s’adapter à un schéma de base de données quelconque. On se heurte alors,
inévitablement, à des problèmes de performances auxquels on fait face en dénormalisant la structure de la
base de manière à optimiser la prise en charge des requêtes connues. Cette démarche est praticable tant qu’il
ne s’agit que de produire des tableaux de bord prédéfinis. Elle est à bannir sans compromis dans un véritable
SID évolutif, sachant notamment que :
· chacune des optimisations successives (faites au coup par coup et sans idée de Modèle de Diffusion) a
pour effet d’augmenter la complexité de la base de données dont la maintenance, à terme, devient de
plus en plus difficile ;
· plus le schéma de la base de données est complexe et éloigné de l’idée de contexte dimensionnel
normalisé, plus le développement et la maintenance des Modèles de Présentation sont coûteux ;
· la base de données d’intégration doit, en priorité, être rafraîchie selon des contraintes d’exploitation
qui peuvent entrer en conflit avec la stratégie d’optimisation des requêtes.
L’agencement des trois modèles de données du SID s’inscrit parfaitement dans l’architecture de référence
présentée à la section 6.2, sachant que :
le Modèle de Présentation ne se conçoit pas indépendamment du Modèle de Diffusion ;
76
Certains outils de présentation sont aujourd’hui capables de mémoriser des extraits de bases de données, sous forme
dimensionnelle. Ce procédé (par ailleurs très limité en volume) équivaut en fait à déporter un sous-ensemble du Modèle de Diffusion.
Jean-Marie Gouarné 82 Le Projet Décisionnel
· les procédures d’acquisition des données sources dépendent du Modèle d’Intégration, mais non
du Modèle de Diffusion ;
· le Modèle d’Intégration et le Modèle de Diffusion, même si le second dépend du premier pour
son alimentation, correspondent à des bases de données logiquement distinctes ;
· les applications décisionnelles utilisant les Modèles de Diffusion et de Présentation sont
asynchrones par rapport aux mécanismes d’acquisition des données.
Il existe donc une ligne de démarcation assez claire entre, d’une part, le SCI, dont la fonction est
d’alimenter et de maintenir un Modèle d’Intégration et, d’autre part, le SDP chargé de la distribution et
de la présentation des données dans un format décisionnel. Que le choix des produits soit arrêté à
l’avance sur la base de critères commerciaux et politiques, ou motivé par des critères techniques à un
stade avancé des projets, il importe que chaque outil soit évalué et mis en œuvre selon sa place dans
cette architecture