Vous êtes sur la page 1sur 29

Concevoir

et dployer un
data warehouse
Ralph Kimball

ditions Eyrolles
ISBN : 2-212-09165-6
2000

Dfinition de
l'architecture
technique

Planification
du projet

Dfinition
des
besoins de
l'entreprise

Modlisation
dimensionnelle

Installation
et slection
des produits

Conception
du modle
physique

Spcification de
l'application
utilisateur

Conception et
dveloppement
des lments
de la zone de
prparation
des donnes

Dploiement

Maintenance
et
croissance

11

Dveloppement
de l'application
utilisateur

Gestion du projet

Infrastructure et mtadonnes

Linfrastructure et les mtadonnes sont les fondations des composantes architecturales que
nous avons dcrites dans les chapitres 8, 9 et 10. Linfrastructure dun entrept de donnes
inclut le matriel, les rseaux et les fonctions de bas niveau, telles que la scurit, que les
composants de haut niveau considrent comme acquises. Les mtadonnes sont un peu moins
concrtes que linfrastructure, mais constituent tout de mme la couche de base des outils
darrire-plan (back room) et frontaux (front room). Ce chapitre identifie et dfinit les principaux composants de linfrastructure et des mtadonnes du data warehouse.
Dans la premire partie de ce chapitre, nous examinons les principaux lments prendre en
compte en matire dinfrastructure des outils darrire-plan (back room). Ensuite, nous aborderons quelques considrations relatives au matriel, aux systmes dexploitation et aux
plates-formes de bases de donnes, en donnant au passage quelques dfinitions de base. Nous
en ferons ensuite de mme pour les outils frontaux (front room). Enfin, pour relier lensemble,
nous voquerons brivement la connectivit et les rseaux.
La seconde partie de ce chapitre examine les mtadonnes sous toutes les coutures. Il sachve
par un exemple dutilisation des mtadonnes et par quelques rflexions sur leur maintenance.

Architecture
PARTIE 3

Bien quassez technique, ce chapitre concerne tous les membres de lquipe ; il est en effet
important que chacun connaisse bien ces pices matresses du data warehouse.

Infrastructure
Plusieurs facteurs doivent tre combins pour dterminer linfrastructure adapte une implmentation donne ; ils ne sont pas forcment tous techniques. Les auteurs de ce livre ne sont
pas des experts en infrastructure. Notre stratgie a toujours consist travailler en troite
collaboration avec les experts en infrastructure de nos clients et les aider bien comprendre
les besoins en infrastructure de lentrept. Cette section identifie et dfinit les principaux
composants de linfrastructure dun data warehouse typique.

lments cls de linfrastructure


Mme dans les couches techniques les plus profondes de lentrept, les besoins mtier restent
les lments dterminants de la mise en uvre. Au niveau de linfrastructure, les besoins mtier
sont reprsents par des mesures plus techniques. Par exemple, lactivit dtermine le niveau de
dtail auquel lentrept doit descendre et le nombre dannes dhistorique quil doit conserver.
Ces informations nous indiquent le volume de donnes que linfrastructure aura grer. La
frquence de chargement des donnes et la complexit des rgles rgissant les processus de
transformation peuvent galement fournir des indications. Estimez ainsi le nombre de chevaux
dont il faudra doter votre configuration matrielle pour que tout se passe bien.
Les problmes techniques et systme conduisent galement certains choix relatifs linfrastructure. Dans certains cas, le processus dextraction reprsente une charge trop lourde pour
les systmes oprationnels ; cette situation peut dboucher sur un investissement dans un environnement matriel miroir. Les comptences et lexprience des quipes charges de la mise
en uvre de lentrept entrent aussi en ligne de compte. Les quipes responsables des outils
darrire-plan (back room) exprimentes en gros systmes auront tendance dvelopper des
entrepts de donnes sur gros systmes, et vice versa. Il en est de mme pour les plates-formes
de base de donnes. Si les administrateurs des bases de donnes ont investi beaucoup de temps
et dnergie dans lapprentissage dun SGBD bien prcis, il ne sera pas ais de les orienter
vers un autre produit.
Les problmes politiques et organisationnels jouent galement un rle dans le choix de
linfrastructure. Les gros investissements sont souvent soumis des limites temporaires ;
dans un tel cas, vos rflexions sur linfrastructure devront faire preuve de davantage de crativit. Par ailleurs, la stratgie informatique de lentreprise guidera certaines dcisions relatives
au matriel. En effet, la standardisation des plates-formes permet de raliser dimportantes
conomies dchelle, de capitaliser les comptences, et enfin de dvelopper des applications
dont le portage dun systme un autre sera relativement ais.

volution de linfrastructure
Linfrastructure matrielle de lentrept de donnes englobe les plates-formes matrielles de
chaque magasin de donnes, de chaque serveur dapplications et des postes de travail.
ASTUCE

propos des plates-formes matrielles, il convient de garder lesprit quun entrept de donnes connat
sa croissance la plus significative au cours des dix-huit premiers mois de son existence, la fois en
termes de donnes et dutilisation.

Infrastructure et mtadonnes
CHAPITRE 11

La premire tape consiste dterminer les plates-formes rellement ncessaires. Quels


magasins de donnes allez-vous mettre en uvre ? Parmi eux, combien devront disposer de
leur propre plate-forme ? La figure 11.1 illustre quelques configurations matrielles typiques
correspondant des projets de tailles diverses.

Entrept et
prparation

Petit/dbut

Moyen/
deuxime
phase

Grand/
entreprise

Entrept de
donnes/
data mart

Prparation et
dveloppement

Test/
dveloppement
Zone de
prparation
des donnes

Data mart
de donnes
atomiques

Plusieurs
data marts
Plusieurs
data marts

Serveur
dapplications

Outils
du poste
de travail

Serveur
dapplications

Outils
du poste
de travail

Serveur
dapplications
Serveur
dapplications

Outils
du poste
de travail
Outils
du poste
de travail

Figure 11.1

Plates-formes matrielles correspondant des entrepts de donnes de tailles et de maturit varies.

Chaque boite de cette figure reprsente une machine ou un ensemble de composants physique
de lentrept. Un environnement deux niveaux (2 tiers) suffit pour un projet modeste ou pour
un premier dploiement. Cependant, mme les systmes les plus petits doivent prvoir un
serveur dapplications pour permettre laccs aux donnes via le Web. Dans les entrepts de
donnes plus ambitieux ou arrivs maturit, la zone de prparation des donnes est gnralement spare de lentrept ou du data mart. De nombreuses entreprises commencent directement ce niveau, car elles ont lintention de faire crotre leur data warehouse en vitant
davoir migrer vers une architecture trois niveaux (3 tiers). Au bas de la figure, un entrept
de donnes tendu toute lentreprise est implment sur plusieurs serveurs spars. Bien
entendu, les variantes possibles de ces trois suggestions sont nombreuses ; dans tous les cas,
rappelez-vous que le nombre de serveurs peut augmenter de manire non ngligeable.

Infrastructure des outils darrire-plan (back room)


Dans tout processus de slection de plates-formes, la premire tape consiste bien assimiler
les besoins. Le simple fait de comprendre ce quune plate-forme doit faire et la faon dont elle
doit le faire du point de vue technique ne suffit pas. Il est essentiel de prendre aussi en compte
les besoins mtier. Ce faisant, vous constaterez que le nombre de solutions examiner se
rduit considrablement et vous pourrez comparer leurs cots respectifs, ainsi que dautres
facteurs, en vue de dterminer la meilleure. Dans presque tous les projets de data warehouse,

Architecture
PARTIE 3

le serveur de la base de donnes est peut-tre la dcision la plus dlicate en matire de matriel.
Voici quelques facteurs valuer pour choisir vos serveurs :
Volumtrie. Le volume de donnes grer est dtermin par les proccupations mtier que
vous avez pour objectif de rsoudre. Si la stratgie de lentreprise est de dvelopper des
relations client one-to-one, le niveau de dtail des transactions devra tre le client. La
plupart des projets dentrept de donnes et de data marts se contentent de 200 gigaoctets
au dpart. Souvent, ils sont mme encore plus modestes et se mettent crotre au fur et
mesure de laccumulation des historiques, de la cration dagrgats et de lapparition de
nouvelles sources de donnes. Toute configuration en de de 200 gigaoctets est facile
administrer. Pour vous aider vous y retrouver, nous qualifierons de petits les entrepts de
donnes dont la capacit est infrieure 100 gigaoctets, de moyens ceux allant de 100
500 gigaoctets et de grands ceux dpassant 500 gigaoctets.
Volatilit. Elle mesure le dynamisme de la base de donnes via la frquence des mises
jour, le volume des donnes modifies ou remplaces chaque mise jour et la taille de la
fentre de chargement. Encore une fois, les besoins mtier fournissent de bonnes indications sur la volatilit. Bien videmment, les donnes quotidiennes sont plus volatiles que
les donnes hebdomadaires ou mensuelles. Les rponses ces questions ont une incidence
directe sur la taille et sur les performances de votre plate-forme matrielle.
Nombre dutilisateurs. Bien videmment, le nombre dutilisateurs, la frquence selon
laquelle ils utilisent le data warehouse, le nombre de connexions simultanes et les pics
dactivit (fin de mois, par exemple) sont autant de facteurs importants dans la slection
dune plate-forme. Pour une entreprise digne de figurer au palmars des 1 000 premires
dans Fortune, leffort initial de data mart/data warehouse devra commencer par 25 50 utilisateurs actifs. Durant les dix-huit premiers mois, ce nombre passera 100 ou 200 ; trois ans
plus tard, on comptera des milliers dutilisateurs, notamment si lentrept est utilis la fois
pour des requtes ad hoc et pour crer des tats standard ou presse-bouton dans une grande
entreprise. La rpartition gographique des utilisateurs est galement importante. Sils sont
dissmins sur toute la plante, le systme devra bien videmment tre disponible 24 heures
sur 24, ce qui a des consquences sur le matriel. Dans un tel cas de figure, si les systmes
oprationnels sont centraliss lentrept de donnes devra probablement ltre galement,
mais le matriel devra autoriser les chargements en parallle ou au compte-gouttes pour
permettre une disponibilit constante. Si les systmes oprationnels sont dcentraliss, il
semble logique de dcentraliser galement les data marts.
Nombre de processus mtier. Le nombre de processus mtier pris en charge par lentrept
influe normment sur sa complexit. Vous pouvez envisager une plate-forme matrielle
par processus si les utilisateurs sont suffisamment nombreux ou si lactivit le justifie.
Cependant, vous aurez peut-tre galement besoin dun gros serveur centralis si les
donnes consolides sont indispensables aux dirigeants de lentreprise et si les mthodes
middleware de consolidation virtuelle sont inadaptes votre situation.
Type dutilisation. Le type dutilisation et les outils frontaux slectionns ont galement
une incidence sur le choix des plates-formes. En effet, une poigne d utilisateurs ad hoc
peut peser lourdement sur les performances de lentrept de donnes. Il est difficile doptimiser un data warehouse pour ce type dutilisation, car les bons analystes compulsent sans
cesse les donnes la recherche de niches. Au contraire, un systme presse-bouton essentiellement destin produire des tats standards peut tre optimis pour ce type
dutilisation ; toutefois, si vous avez lintention den rester aux tats standard, vous ne

Infrastructure et mtadonnes
CHAPITRE 11

tirerez pas le meilleur parti de votre investissement. La plupart des gnrateurs dtats du
march permettent de planifier lexcution dtats prdfinis tt le matin, aprs le chargement des donnes et avant larrive du personnel. Cette dmarche vise mieux rpartir la
charge de traitement en gnrant la plupart des tats standard en dehors des heures de
pointe. Le data mining grande chelle reprsente galement une lourde charge pour le
matriel, tant du point de vue du volume des donnes que de celui des entres-sorties. Il
faudra alors prvoir des btes de course capables dabsorber dnormes volumes de
donnes, de les ratisser au moyen des outils de data mining les plus scrutateurs et de
retourner des rsultats lanalyse et la conduite de lactivit. Il est donc primordial
dtudier les diffrents types de requtes, parce que lutilisation ad hoc, la gnration
dtats et le data mining ont des profils diffrents et que leurs performances varient selon
les plates-formes.
Comptences techniques. Du point de vue de ladministration, lenvironnement serveur
est comparable lenvironnement gros systme sur le plan conceptuel mais trs diffrent
sur le plan de limplmentation. Nesprez pas pouvoir installer un serveur Unix, ni mme
un systme NT important, si lquipe ne compte aucun expert en ressources systme. La
gestion dun serveur implique des tches et des comptences nombreuses : administration
de base du matriel et des logiciels systmes, connectivit (avec les postes de travail et les
systmes source), comptences en administration de donnes, sauvegardes et restaurations,
etc. Malheureusement, dans ltat actuel de lvolution technologique, il nest pas question
de se contenter de mettre en route les serveurs et de ne plus sen occuper. Du moins pas
encore Choisissez donc les plates-formes matrielles en fonction des comptences
internes, la fois en termes qualitatifs et quantitatifs.
Disponibilit logicielle. Il arrive frquemment que lanalyse des besoins mette en vidence
des fonctionnalits manquantes, par exemple un systme dinformation gographique
permettant de situer les informations de lentrept sur des cartes. Le processus de slection
des logiciels peut rvler que le logiciel de cartographie qui rpond le mieux vos besoins
ne fonctionne que sur une plate-forme graphique haut de gamme ; dans un tel cas, la dcision
sera vite prise !
Ressources financires. Le budget allou un projet dpend gnralement des bnfices
attendus. En matire de data warehouse, cest un peu le problme de luf et de la poule.
Dans le chapitre 3, nous avons parl de la justification. Il est ardu de dcrire et de vanter les
mrites dun entrept avant den avoir mis un en uvre. En terme de matriel, la conclusion est simple : choisissez les plus gros serveurs que votre budget vous permet dacqurir.
Plates-formes matrielles et systmes dexploitation
Dans la mesure o un ordinateur ne fonctionne pas sans systme dexploitation, le matriel et
le systme dexploitation forment un tout. Dans les environnements gros systme, vous navez
pas le choix du systme dexploitation. En revanche, dans le monde des systmes ouverts
chaque constructeur de matriel implmente sa propre version dUnix. Mme NT existe en
plusieurs versions, qui nacceptent pas toutes les logiciels Intel/NT de base en natif. Voici les
principales catgories de combinaisons matriel/systme dexploitation :
Gros systmes. Dernirement, une srie darticles a fait tat dapplications qui regagnaient
lenvironnement gros systme aprs avoir subi un chec dans lenvironnement clientserveur. Le data warehouse est certainement le domaine auquel cette observation ne
sapplique pas. En rgle gnrale, le gros systme nest pas la plate-forme idale pour un

Architecture
PARTIE 3

entrept de donnes et les quelques russites en la matire sont des exceptions : il sagit soit
dentrepts de donnes implments sur gros systme depuis longtemps et dont la migration coterait trop cher, soit dentrepts de donnes qui exploitent un excdent de capacit
du gros systme, entranant ainsi des cots marginaux relativement faibles. Cependant, le
data warehousing sur gros systme est en gnral peu rentable. Les cots relatifs ladministration, au matriel et la programmation sont plus levs que ceux des systmes
ouverts, en partie parce que le gros systme dispose dune infrastructure de traitement des
transactions pousse, qui ne prsente aucun intrt dans le cadre du data warehousing.
En outre, tant donn que le gros systme est essentiellement conu pour grer les transactions, il manque de souplesse sur le plan de la programmation. Les outils et les techniques
sont fiables, mais difficiles exploiter. Lajout de nouvelles sources de donnes, ou mme
la maintenance des extractions existantes, peut tre trs pnible.
Enfin, de nombreuses entreprises sont quipes de gros systmes offrant des capacits limites et nenvisagent aucune extension en vue dapplications nouvelles. Alors si vous avez
de la place, occupez-la ; si vous devez envisager un nouvel investissement, optez pour un
environnement serveur.
Serveurs de systmes ouverts. Les serveurs de systmes ouverts, ou Unix, sont
aujourdhui les plates-formes les plus courantes pour les entrepts de donnes de moyenne
et de grande dimension. Unix est gnralement assez robuste pour grer correctement les
applications de production et pratique le traitement parallle depuis plus de dix ans. Le
march des serveurs Unix est relativement accessible. Dun point de vue fonctionnel, Unix
peut sembler trange aux habitus des gros systmes et aux programmeurs PC par exemple,
la plupart des utilitaires ne sont pas standard. Lquipe du data warehouse devra donc
possder les comptences requises par linstallation et la gestion dun environnement Unix.
Veillez la participation active des administrateurs. Lquipe du data warehouse devra
galement connatre les commandes et les utilitaires Unix pour pouvoir dvelopper et grer
lentrept ; prvoyez des formations le cas chant. Gardez surtout lesprit quUnix n'est
pas un environnement standard et que chaque constructeur propose sa propre version du
systme dexploitation, dote de ses propres particularits.
Serveurs NT. Bien qutant de loin le systme dexploitation connaissant la plus forte
croissance sur le march, NT vient seulement datteindre les capacits ncessaires
limplmentation dun entrept de donnes de taille moyenne. Des plates-formes matrielles NT tendues et viables font leur apparition. Les capacits de traitement parallle ont
longtemps t limites des architectures mono-processeurs et les clusters sous serveur NT
sont oprationnels depuis peu. tant donn les antcdents de Microsoft, on peut penser
que NT va devenir une plate-forme dexploitation puissante ; lheure actuelle, ce systme
nest toutefois pas le mieux adapt aux entrepts de donnes de moyenne et de grande
dimension. Il est en revanche rentable dans le cadre de data warehouses modestes ou de
data marts peupls de donnes atomiques.
Architectures de traitement en parallle
Les constructeurs se sont toujours montrs cratifs en matire de sigles et continuent en
inventer rgulirement de nouveaux. Le march des serveurs offre trois architectures matrielles de traitement parallle, illustres par la figure 11.2 : SMP (Symmetric Multiprocessing), MPP (Massive Parallel Processing) et NUMA (Non-Uniform Memory Architecture).
Ces architectures diffrent dans la manire dont les processeurs interagissent avec les disques

Infrastructure et mtadonnes
CHAPITRE 11

durs, avec la mmoire et entre eux. Les frontires entre ces architectures sestompent mesure
que les constructeurs optimisent leurs offres. Les sections qui suivent voquent lapplication
de ces configurations au data warehouse.
SMP
Processeur

Processeur

Processeur

Processeur

MPP

Processeur

Processeur

Processeur

Processeur

NUMA
Processeur

Processeur

Processeur

Processeur

Figure 11.2

Principales architectures matrielles.

SMP (fonctionnement en multi-processeur symtrique)


Larchitecture SMP prsente une machine unique quipe de plusieurs processeurs, chacun
tant gr par un systme dexploitation et accdant son propre disque et sa zone de
mmoire. Une machine SMP quip de 8 32 processeurs, une base de donnes parallle,
beaucoup de mmoire (deux gigaoctets ou plus), un bon disque et une conception adapte
conviennent parfaitement un entrept de donnes de taille moyenne. Pour tirer parti de
processeurs multiples, la base de donnes doit tre capable dexcuter ses oprations en parallle et les processus de lentrept doivent tre conus pour exploiter les fonctionnalits du traitement en parallle.
ASTUCE

Larchitecture en partage intgral rend les machines SMP bien adaptes aux requtes ad hoc. Dans un
environnement ad hoc, les chemins daccs ne sont pas connus par avance. La nature la fois centralise et partage de larchitecture SMP permet au systme dallouer de la puissance de traitement
lensemble de la base de donnes.

Architecture
PARTIE 3

Le partage intgral reprsente la fois la force et la faiblesse de larchitecture SMP. Les


processeurs peuvent accder aux ressources partages (mmoire et disque) trs rapidement,
mais les chemins quils emploient risquent fort de produire des goulets dtranglement en cas
de forte sollicitation. tant donn que la machine SMP est une entit unique, plus rien ne fonctionnera en cas de panne. Pour remdier cet inconvnient, les constructeurs mettent au point
des techniques permettant plusieurs ordinateurs SMP dtre relis entre eux ou de former
des clusters. Dans un cluster, chaque nud est une machine SMP possdant son propre
systme dexploitation, mais le cluster inclut des logiciels de connexion et de contrle qui
permettent aux machines de se partager les disques et de pourvoir la rparation des
dfaillances. Ainsi, si une machine cesse de fonctionner, les autres se rpartiront temporairement sa charge de travail. Bien entendu, cet avantage a un cot car les clusters sont complexes
et difficiles grer. Enfin, la technologie de base de donnes ncessaire la prise en compte
des clusters volue sans cesse.
MPP (traitement massivement parallle)
Les configurations MPP sont fondes sur des chanes dordinateurs relativement indpendants
les uns des autres, quips chacun de son propre systme dexploitation, de sa mmoire et de
son disque dur, le tout tant coordonn par des changes de messages. La force de MPP rside
dans sa capacit connecter des centaines de nuds (cest--dire de machines) en vue de leur
soumettre un problmes selon lapproche par la force. Par exemple, pour sonder une grosse
table de fond en comble, vous obtiendrez rapidement un rsultat en recourant un systme
MPP de 100 nuds, chaque nud tant charg de traiter un centime de la table. Cest la
notion de petite main applique linformatique. Les difficults surgissent lorsque le fractionnement du problme traiter est malais. Par exemple, une jointure entre deux grosses
tables peut poser problme si elles doivent toutes deux tre traites par les cent nuds. En
effet, chaque enregistrement dune des tables peut tre li des enregistrements de lautre
table, qui peuvent se trouver sur nimporte lequel des 99 autres nuds ! La tche de coordination des nuds peut alors subir une surcharge. Bien entendu, les dveloppeurs de systmes
utilisant la technologie MPP ont mis au point des moyens de contourner ce problme et de
rsoudre dautres questions lies au paralllisme.
Les systmes MPP sont bien adapts aux entrepts de donnes de grande taille (au-del du
traoctet) et aux applications qui accdent aux donnes de manire intensive (data mining).
Dans ces systmes, vous pouvez optimiser laccessibilit aux donnes en stockant celles-ci en
miroir sur plusieurs nuds. Les machines MPP fonctionnent mieux lorsque les chemins
daccs aux donnes sont prdfinis et que les donnes peuvent tre distribues sur les nuds
et sur les disques en fonction de ces chemins.
ASTUCE

Les systmes MPP sont frquemment employs pour grer les environnements de requtes prdfinies
ou dtats standard ou encore pour alimenter les data marts en donnes atomiques. Leur cot est rput
lev ; leur administration et leur optimisation sont dlicates. Encore une fois, la base de donnes doit tre
conue pour tirer parti de cette structure matrielle (la conception physique adapte un systme MPP
peut tre trs diffrente de celle conue pour un systme SMP).

NUMA (architecture de mmoire non uniforme)


Larchitecture NUMA est une combinaison de SMP et de MPP qui vise allier la souplesse du
partage des disques du premier aux performances de traitement en parallle du second. Il sagit
dune innovation relativement rcente, qui a des chances dtre viable long terme sur le

Infrastructure et mtadonnes
CHAPITRE 11

march du data warehouse. Du point de vue conceptuel, larchitecture NUMA reprend lide
des clusters de machines du SMP, mais avec des connexions plus serres de la bande
passante supplmentaire et une meilleure coordination des nuds. Sil vous est possible de
segmenter votre entrept de donnes en groupes dutilisation relativement autonomes et de placer
chaque groupe sur son propre nud, larchitecture NUMA vous donnera satisfaction.
Considrations gnrales sur les architectures parallles
Quelle que soit la plate-forme, il est conseill de sinterroger sur la disponibilit des logiciels
et sur la complexit de ladministration des systmes. Voici quelques-unes de ces questions :
Quels sont le type et la version du systme dexploitation requis ? Rappelez-vous notamment quUnix nest pas un standard.
Quelles sont les applications disponibles compatibles avec cette version du systme
dexploitation ? Si lditeur du logiciel que vous voulez acheter na pas port son produit
sur le systme dexploitation que vous utilisez, le logiciel ne fonctionnera pas. Vrifiez
galement si ce dernier est compatible avec votre version du SGBDR, avec vos utilitaires
de base de donnes, avec vos serveurs dapplications, etc.
Facteurs stimulant les performances matrielles
En matire de data warehouse, le dbit des disques et de la mmoire sont importants car les
requtes peuvent solliciter fortement les donnes. En rgle gnrale, une requte adresse un
systme transactionnel retourne un enregistrement unique issu dune table optimise de
manire que lenregistrement se trouve dj dans le cache. En revanche, une requte adresse
un entrept de donnes peut ncessiter lagrgation de milliers denregistrements provenant
de plusieurs tables.
Les disques
Les lecteurs de disques influent fortement sur les performances, la flexibilit et lvolutivit
dune plate-forme matrielle. Le prix des serveurs de disques oscille autour de 400 francs le
gigaoctet. Dans les systmes haut de gamme, les lecteurs sont installs sur un ordinateur autonome ou sur un sous-systme ddi la gestion des accs disque. Ces systmes sont rapides,
volutifs et portables (il est possible de les rutiliser sur dautres serveurs ou avec dautres
systmes dexploitation). On peut les configurer conformment aux standards de scurisation
du stockage des donnes RAID (Redundant Array of Inexpensive Disks) 1 ou 5, afin doptimiser la disponibilit de lentrept de donnes. Sachez que les bases de donnes ont besoin de
gros volumes de mmoire temporaire pour effectuer les tris, les jointures et les agrgats. Ce
volume doit rsider sur des lecteurs et des contrleurs performants mais na pas besoin dtre
plac en miroir (ce qui reviendrait plus cher). Ces systmes de lecteurs peuvent tre remplacs
chaud, ce qui rduit la dure dindisponibilit en cas de problme. La redondance et
lchange chaud sont importants dans la mesure o les lecteurs sont les composants les plus
sujets aux pannes. Les sous-systmes de lecteurs de disques cotent plus cher mais sont rentables long terme. Prvoyez au dpart assez despace disque pour un ou deux ans et grez
votre expansion en fonction des besoins et des baisses de prix.
La mmoire
Plus un data warehouse dispose de mmoire, mieux cest ; voici une diffrence supplmentaire entre laide la dcision et le traitement transactionnel. Les requtes sur les transactions

10

Architecture
PARTIE 3

sont gnralement peu gourmandes en mmoire. Les requtes daide la dcision sont plus
exigeantes et impliquent souvent plusieurs passes dans des tables volumineuses. Si la
mmoire contient la totalit de la table interroge, les performances peuvent thoriquement
tre multiplies par un facteur compris entre 10 et 100. Cest lun des gros avantages des
plates-formes 64 bits. Les systmes 32-bits sont limits 2 gigaoctets (parfois 4), tandis que
les processeurs 64-bits sont capables dadresser un espace mmoire plus important. Remarquez au passage que pour que le 64-bits soit effectif, lordinateur, son systme dexploitation
et la base de donnes doivent galement tre en 64-bits.
ASTUCE

La tentation de favoriser la mmoire au dtriment des disques revient rgulirement lordre du jour, en
raison de la diffrence des temps daccs. Un accs disque prend environ 10 millisecondes, tandis quun
accs mmoire est 100 fois plus rapide (0,1 milliseconde). Cependant, le traitement des donnes dune
base en mmoire ne sera pas pour autant 100 fois plus rapide, car de nombreux autres facteurs entrent en
ligne de compte : antlecture de disque et mmoire cache sur le contrleur ou dans le systme dexploitation. Nanmoins, vous pouvez multiplier les performances dun entrept de donnes par un facteur compris
entre 10 et 30 en ajoutant simplement de la mmoire la configuration de la base de donnes.

Niveau de service attendu


Le type et la puissance du matriel requis dpendent du degr de disponibilit que vous devez
offrir. Si les donnes doivent tre accessibles au monde entier, des machines en parallle et
une forte redondance des composants seront ncessaires (le problme consistera trouver des
heures creuses pour effectuer les chargements et la maintenance). La disponibilit du data
mart des donnes atomiques est dcisive dans la mesure o ce data mart contient les donnes
du niveau de dtail le plus fin et sera probablement reli tous les autres data marts sur le
mode du forage. La puissance de traitement est galement essentielle, car le data mart des
donnes atomiques est le point central du processus de chargement et doit tre capable de
transfrer des donnes vers les autres data marts dans un dlai relativement court.
Stockage secondaire
Assurez-vous que votre configuration permet la gestion des sauvegardes et de larchivage. Si
possible, optez pour un systme de sauvegarde assez rapide pour effectuer son travail pendant la
dure impartie au chargement. Bien quil soit possible de sauvegarder le contenu dun entrept
de donnes un moment o les utilisateurs sen servent, une telle opration risque dengendrer
une charge importante qui disputera les ressources processeur aux requtes des utilisateurs.
Autres facteurs
Les environnements serveur Unix et NT sont ce jour les plates-formes les mieux adaptes aux
entrepts de donnes, Unix reprsentant la meilleure option pour les systmes de moyenne ou
de grande dimension. Voici quelques avantages des serveurs par rapport aux gros systmes :
Un choix doutils plus tendu. Aujourdhui, la plupart des nouveaux outils de data warehouse sont dabord, voire exclusivement, dvelopps pour les serveurs.
Options de dveloppement des constructeurs de bases de donnes. La plupart des constructeurs effectuent leurs dveloppements sur un systme dexploitation donn. Il sagit gnralement de la premire plate-forme mise en uvre par la socit et de celle sur laquelle le
produit fonctionne le mieux. Aprs son dveloppement, le produit initial est port sur dautres

Infrastructure et mtadonnes
CHAPITRE 11

systmes dexploitation et sur dautres versions dUnix. Bien entendu, il peut tre judicieux
dattendre une nouvelle version ; les premiers acqureurs font office de cobayes
ASTUCE

Plus votre plate-forme sera loigne de celle du produit initial, plus la nouvelle version sera longue
venir ; de plus, le support spcifique dont vous pourrez bnficier sera moindre.

Les serveurs dapplications requirent des plates-formes Unix ou NT. Certains produits
daccs aux donnes sont livrs avec un composant serveur dapplications qui doit obligatoirement sexcuter sur une plate-forme serveur. Si lentrept de donnes comporte dj
des serveurs, les serveurs dapplications peuvent partager la plate-forme existante, ce qui
vous vite dengager des investissements supplmentaires. Lide nest peut-tre pas excellente long terme, mais elle simplifie le dmarrage. Nous voquons galement les serveurs
dapplications dans la section de ce chapitre consacre aux outils frontaux (front room).
Souplesse. Lenvironnement serveur est moins svrement gard que le gros systme,
notamment si le serveur est ddi lentrept de donnes. Lquipe locale pourra accder
directement lentrept de donnes pour tester de nouveaux scnarios, construire de
nouvelles tables, etc., sans dpendre de ressources distantes.
Considrations relatives la plate-forme de la base de donnes
Dans le monde du data warehouse, le choix de la plate-forme de la base de donnes est ultrasensible. Il existe plus dune dizaine de possibilits ; chacune delles offre des exemples
dimplmentations de data warehouses russies et est dfendue par ses supporteurs. En dehors
des produits les plus connus, la plupart des entreprises du secteur des langages de quatrime
gnration (L4G) ont des offres de data warehouse. Certains entrepts sont implments
laide de produits gros systme, dautres au moyen de bases de donnes multidimensionnelles
spcialises nommes moteurs MOLAP (Multidimensional On-Line Analytical Processing).
Les facteurs qui guident votre dcision en matire de matriel sappliquent galement au
choix de la plate-forme de la base de donnes. Notre exprience nous dit que votre dcision
dpend des spcificits de votre situation. Commencez par faire votre choix entre les bases de
donnes relationnelles et leurs homologues multidimensionnelles.
Base de donnes relationnelle ou multidimensionnelle ?
Daprs les chiffres, le dbat principal oppose les bases de donnes relationnelles aux bases
de donnes dimensionnelles, les premires menant la danse. Depuis quelques annes, le
march de laide la dcision est le thtre de discussions visant dterminer lapproche
convenant le mieux au traitement analytique. Le dbat est passionn mais apporte malheureusement peu de rponses.
Le problme devient plus facile apprhender sous langle des besoins mtier. Les bases de
donnes multidimensionnelles, galement baptises moteurs MOLAP, sont apparues pour
rpondre trois besoins essentiels des utilisateurs : simplicit de laccs aux donnes, tats de
type tableau crois et temps de rponse faibles. Certains ont dvelopp des bases de donnes
spcialises parce que les bases de donnes relationnelles standard et leurs anctres taient
incapables de satisfaire ces trois exigences. La majeure partie des produits MOLAP existent
depuis une dizaine dannes. Les sections suivantes mettent en lumire les avantages et les
inconvnients des deux solutions.

11

12

Architecture
PARTIE 3

Caractristiques des moteurs relationnels


La plupart des constructeurs de bases de donnes relationnelles ont investi dans le dveloppement dadaptations spcifiques au data warehouse et offrent aujourdhui des performances
acceptables. Les principaux constructeurs de SGBDR ont introduit plusieurs nouveauts :
prise en charge du modle dimensionnel, jointures en toile, indexation bitmap et optimiseurs
de requtes plus efficaces. Ces progrs, accompagns davances technologiques telles que la
sensibilit aux agrgats, ont rduit de manire considrable les diffrences de performances
entre les produits. Les bases de donnes relationnelles prsentent lavantage de pouvoir
stocker plus de donnes au niveau de dtail le plus fin. Il est entendu que les systmes spcialiss dans la rsolution de certains problmes sont avantags par rapport aux produits plus
gnralistes ; il en va de leur survie sur le march.
ASTUCE

Si vous avez dcid de fonder votre entrept de donnes sur une plate-forme relationnelle et si votre
projet est de faible ou de moyenne envergure, il serait absurde denvisager des solutions nappartenant
pas la tendance gnrale du march des SGBDR.

De toute faon, il est extrmement intressant de vous renseigner sur les implmentations
existantes et de vous livrer quelques tests. Identifiez quelques tats un peu dlicats, comportant notamment des jointures multiples entre plusieurs tables, et voyez ce quils donnent. En
rgle gnrale, les constructeurs mettent votre disposition des ressources pour vous aider
dans ce processus de test. Profitez des ventuelles expriences internes de slection de
produits acquises dans le cadre de projets informatiques antrieurs.
ASTUCE

Certaines bases de donnes relationnelles sont spcialement conues pour grer les configurations de
bases de donnes et les requtes de type data warehouse. Elles sont plus rapides que les principaux
SGBDR et sont intressantes (presque obligatoires, en fait) pour les entrepts de donnes de grande
envergure.

Caractristiques des moteurs MOLAP


Les moteurs MOLAP, galement nomms systmes de gestion de bases donnes multidimensionnelles, sont des systmes propritaires conus pour permettre des analyses trs pousses.
Les moteurs MOLAP peuvent constituer dexcellentes plates-formes de data mart pour les
besoins auxquels il est possible de rpondre par un schma en toile. Le nombre des dimensions et des lignes doit tre relativement restreint. Le moteur MOLAP introduit une couche
supplmentaire dans les processus de chargement et dadministration.
ASTUCE

Partant du principe de la prsence dun data mart de donnes atomiques sur une plate-forme SGBDR,
limplmentation dun moteur MOLAP signifie que vous aurez un environnement distinct administrer et
que celui-ci aura probablement besoin dun serveur ddi.

Le principal avantage du moteur MOLAP rside dans les performances des requtes. Les faits
correspondant toutes les combinaisons de dimensions valides sont prstocks. Les temps de
rponse sont tonnants. En contrepartie, le stockage de tous ces agrgats accrot le volume des
donnes. Or, le volume de donnes quil est possible de stocker dans une base de donnes
multidimensionnelle est, pour des raisons historiques, limit 10 gigaoctets ; les constructeurs font leur possible pour rsoudre ces restrictions portant sur le stockage physique. Une
limitation subsiste nanmoins, impose par la dure ncessaire au chargement de nouvelles

Infrastructure et mtadonnes
CHAPITRE 11

donnes ou lactualisation de la base de donnes. Aujourdhui, la plupart des utilisateurs ont


autant besoin de donnes dtailles que dinformations agrges. Pour rpondre ce besoin,
la facult de forer directement au niveau du moteur MOLAP a t ajoute la plupart des
produits de cette gamme. Leurs aptitudes grer les modifications, les calculs complexes et
les sous-totaux, autres avantages non ngligeables des moteurs MOLAP, en font des candidats
idaux pour les systmes budgtaires et prvisionnels.
Lvaluation des moteurs multidimensionnels ne peut pas tre dissocie de celle des outils
daccs aux donnes, que nous dcrivons en dtail au chapitre 13. Certains produits MOLAP
offrent des outils dinterface utilisateur complets ainsi que lenvironnement bases de donnes.
Dautres proposent le moteur MOLAP et un environnement de dveloppement ; dans ce cas,
vous pouvez soit dvelopper les applications utilisateur en interne, soit vous les procurer
auprs dun fournisseur extrieur.
ASTUCE

Au moment o nous crivons ces lignes, les fonctionnalits de forage des SGBDR de type SQL via des
moteurs MOLAP peuvent tout au plus tre qualifies de rudimentaires. Ce problme de liaison entre les
moteurs MOLAP et lenvironnement relationnel est la raison pour laquelle nous prconisons le stockage
des donnes dtailles au sein dun modle dimensionnel. Si ces deux niveaux reprsentent des conceptions radicalement diffrentes, il sera difficile de fournir un accs performant aux donnes dtailles.

Mettez en concurrence les diffrents produits MOLAP et confrontez-les aux besoins des utilisateurs en procdant des tests dutilisation. Les solutions postes de travail, lgres, peuvent
sembler intressantes court terme mais risquent de gnrer, au fil du temps, plus de travail
que de valeur ajoute. Lquipe charge du data warehouse doit valuer avec soin les limitations et les fonctionnalits des produits. Lvolutivit doit tre privilgie.
ASTUCE

Sur le plan de lvolutivit, linconvnient majeur des produits MOLAP rside actuellement dans la limitation du volume des donnes en entre pour la table des faits principale et du nombre de lignes dans les
dimensions. Dbut 1998, ces limitations tournaient autour de 5 gigaoctets de donnes en entre et de
300 000 lignes dans la dimension la plus importante.

Le problme de la multiplicit des constructeurs et des produits tend sestomper mesure


que les constructeurs de SGBDR incorporent des fonctionnalits MOLAP leurs logiciels.
Les implmentations deviennent hybrides, mais cette intgration nentrane pas systmatiquement une baisse des prix ; le budget disponible reste donc un facteur part entire du choix
entre SGBDR et MOLAP.

Infrastructure des outils frontaux (front room)


Linfrastructure des outils frontaux (front room) dpend plus fortement de lactivit et des
outils que celle des outils darrire-plan (back room) et les choix faire y sont plus nombreux.
Commenons par quelques considrations gnrales.
Serveur dapplications
Du ct des outils frontaux (front room), les serveurs dapplications tendent prolifrer
toute vitesse. Les uns grent laccs aux donnes via le Web, les autres grent les requtes, les
tats standard, lauthentification, les bases de donnes de mtadonnes, etc. Apporter des
informations intressantes et des conseils en ce domaine nest pas simple, car les produits sont

13

14

Architecture
PARTIE 3

trs nombreux et trs diffrents. La meilleure tactique consiste interroger trs tt les constructeurs sur les dtails de leurs configurations. Voici quelques questions cls poser :
Mmoire. Combien de mmoire faut-il prvoir ? Quel est le temps de formation ncessaire
une utilisation efficace ?
Disque. Quels facteurs dterminent lutilisation du disque ? Quelle capacit faut-il envisager ?
Partage de plate-forme. Est-il possible dexcuter plusieurs services sur la mme plateforme matrielle ? Dans ce cas, comment se comportent les performances ? Quels sont les
compromis envisager ? Certains produits ont-ils une compatibilit rduite ?
Goulets dtranglement. quoi les goulets dtranglement du systme sont-ils dus ?
quoi les ralentissements du systme sont-ils dus ? Le produit est-il rellement multithread ?
Peut-il vraiment excuter plusieurs processus simultanment ? Quels seraient les avantages
de linstallation de plusieurs processeurs ? Combien dutilisateurs simultans le produit
peut-il grer ?
Poste de travail
La puissance du poste de travail dpend de son utilisateur et de ses besoins en matire doutils.
Lutilisateur occasionnel qui se contente de quelques tats HTML quil consulte partir de
son navigateur favori sera satisfait si on lui fournit assez de puissance pour lancer son navigateur Web. lautre extrme, lutilisateur aguerri qui construit des requtes complexes et lance
des analyses personnalises devra tre quip dun ordinateur beaucoup plus puissant. Vous
trouvez ci-dessous des conseils qui vous aideront configurer le poste de travail.
Support inter-plate-forme
Dans certaines entreprises, le service marketing compte encore des inconditionnels du
Macintosh ; dautres socits utilisent des stations de travail Unix pour les tudes et pour la
production. Le support de plates-formes multiples entrane une lourde tche pour lquipe
charge des outils frontaux. Les problmes dinstallation et de support varient dune plateforme lautre et lquipe doit tre comptente dans tous les domaines. Dautre part, les
problmes ne prennent pas fin une fois que les logiciels sont installs. Il est souvent ncessaire
de crer les tats sur chaque plate-forme, ce qui peut multiplier par deux le travail de dveloppement et de maintenance. Les concepteurs doutils frontaux sont peu nombreux supporter
dautres plates-formes que le duo Windows/Intel. Si vous tes oblig de supporter plusieurs
plates-formes poste de travail, le processus de slection des outils daccs aux donnes sen
trouvera simplifi.
Systme dexploitation du poste de travail
Mme si tous les utilisateurs emploient la mme base matrielle, cela ne signifie pas que tous
seront compatibles avec les logiciels client car la version du systme dexploitation peut tre
inadapt. Renseignez-vous sur la version du systme dexploitation requise par vos outils et
vrifiez quelle correspond bien la ralit.
ASTUCE

Dans le monde Windows, si vos utilisateurs ne disposent pas de Windows 95 et versions ultrieures ou de
NT 4 et versions ultrieures, vous pouvez vous attendre des problmes.

Infrastructure et mtadonnes
CHAPITRE 11

Distribution des logiciels


Ce problme est insidieux : il sinstalle lentement et sans faire de bruit puis, un beau jour, vous
saute dun seul coup la figure. Linstallation des premiers groupes dutilisateurs est aise.
Vous les connaissez, car ils ont particip aux runions du processus de conception ; ils sont
impatients de commencer travailler sur les nouveaux produits. Puis dautres personnes
demandent accder au data warehouse, bientt rejoints par des utilisateurs gographiquement
distants, et vous finissez par vous retrouver en train de grer plusieurs centaines de copies des
logiciels destins aux poste de travail, rparties aux quatre coins de lentreprise. Cest bien
entendu ce moment-l que votre fournisseur choisit pour commercialiser la nouvelle version de
son produit, qui fait absolument tout mais dont la compatibilit avec la prcdente version nest
pas garantie ; une mise jour de lensemble des postes de travail du parc vous attend
Outils Web
Lindpendance des plates-formes et la facilit de diffusion sont des attraits majeurs du Web
et des technologies connexes. Or, ces avantages ne sont effectifs quen thorie et se limitent
laccs aux tats simples. La prsence du poste de travail est indispensable aux analyses ad
hoc. Il est pourtant possible de faire de lanalyse ad hoc au moyen dune grosse applet ; chez
Metaphor, nous avons mme dvelopp des applications complexes sur un rseau dordinateurs dpourvus de disque dur ds 1984. Mais les fournisseurs doutils ont mis des annes
dvelopper le volume de code actuel et nont aucun moyen de le porter (et linfrastructure de
dveloppement nest pas encore assez robuste). Les nouveaux venus qui proposent une offre
doutils Web ne sont entravs par aucun passif, mais ils nont pas encore eu le temps de dvelopper un outil puissant et manquent dexprience. Ils devront dabord franchir plusieurs
tapes, linstar de la gnration qui les a prcds.
Mmoire
Vous ne serez pas tonn dapprendre que la mmoire a une forte incidence sur les performances des postes de travail. Nous avons eu loccasion de travailler pour une entreprise qui
avait consacr beaucoup de temps et dnergie rechercher la cause dun problme du ct du
rseau alors que le goulet dtranglement tait d une capacit mmoire insuffisante sur les
postes de travail. Ceux-ci passaient le plus clair de leur temps paginer les donnes et les
programmes dans la mmoire virtuelle.
Conclusion sur le poste de travail
Choisissez une plate-forme standard et dterminez la configuration minimale pour implmenter votre srie doutils de manire ractive ; elle doit tre suffisamment riche pour tre efficace. Par ailleurs, prvoyez une configuration plus puissante rserve aux utilisateurs experts,
qui sont peu nombreux mais qui ont un impact important. Il vaut mieux viter de limiter artificiellement leur usage du data warehouse (et, ce faisant, lutilit de ce dernier) en vue
dconomiser quelques milliers de francs sur lachat des ordinateurs.
Dautre part, nous recommandons de prvoir un poste par utilisateur ; la baisse des prix le
permet. Les stations partages ne sont pas trs fonctionnelles car elles font augmenter le cot
peru de lutilisation de lentrept pour lanalyste. Si celui-ci doit se lever de son sige,
sinstaller prs du poste de travail partag, y lancer quelques requtes puis revenir chercher les
rsultats un peu plus tard, il aura probablement du mal sy mettre.

15

16

Architecture
PARTIE 3

Connectivit et rseau
La connectivit et le rseau relient les outils darrire-plan (back room) et les outils frontaux
(front room). En rgle gnrale, la connectivit est un composant de linfrastructure. tant
donn quelle constitue un prrequis la mise en uvre de nimporte quel application clientserveur, le travail prparatoire est gnralement dj termin. La plupart des entreprises
possdent un rseau local (LAN) ou un groupe de rseaux locaux interconnects, ainsi quune
quipe charge de les faire fonctionner. Si ce nest pas le cas dans votre socit, il est urgent
de mettre en place un groupe de travail afin dvaluer les besoins. Plusieurs autres problmes
de connectivit que vous risquez de rencontrer sont numrs ci-dessous.
Bande passante
Il est souvent judicieux disoler la base de donnes et les serveurs dapplications sur un rseau
local haut dbit ddi (Ethernet ou FDDI 100 Mo/s). Cette configuration procure la bande
passante ncessaire au transfert de gros volumes de donnes avec des performances optimales.
Accs distance
Si vous avez affaire des utilisateurs distants, il est entendu que ceux-ci devront pouvoir
accder lentrept de la mme manire que les utilisateurs locaux. Prvoyez cet effet une
connexion large bande passante, fiable, entre le rseau local des utilisateurs distants et celui
qui hberge la base de donnes et les serveurs dapplications.
La bande passante prend de limportance en raison de la mutation des outils frontaux. De
nombreux outils permettent prsent de dfinir un sous-ensemble de donnes particulirement
intressant, de le rcuprer et de lanalyser en local. Une telle opration reprsente un flux de
donnes descendant assez considrable. Aprs avoir valu les besoins, contactez lquipe
rseau afin de dterminer si la bande passante prvue pour ces connexions est suffisante.
Si vos utilisateurs distants ne sont pas regroups en rseau local, vous devrez mettre en place
un accs par les lignes tlphoniques. Effectuez des tests de performances pousss et lisez
attentivement le chapitre 12, qui traite de la scurit.
Passerelles
La plupart des constructeurs de bases de donnes proposent des passerelles, qui permettent
dtablir des liens avec les bases de donnes concurrentes et avec les sources de donnes de
production. La mise en uvre dune passerelle sera par exemple trs utile pour accder aux
donnes localises dans dautres base de donnes de lentrept. Certains middleware offrent
galement ce type de connectivit et y ajoutent la possibilit de combiner les donnes en
provenance de plusieurs sources au moyen de jointures htrognes. Ces passerelles ont
tendance tre assez lentes ; elles rendent particulirement service dans le cadre des importations batch et de recherches dans les petites tables. Faites des tests grandeur nature pour vrifier
quelles ne seffondrent pas.
Transfert de fichiers
Il existe un large ventail de protocoles de transfert de fichiers et de programmes chargs de
les implmenter. Le principal est le protocole FTP (File Transfer Protocol), qui est un utilitaire de transfert de donnes universel. FTP remonte aux dbuts de lInternet ; il offre des
services de transfert de fichiers entre les ordinateurs relis lInternet, quel que soit leur type.

Infrastructure et mtadonnes
CHAPITRE 11

Ses fonctionnalits de base sont ltablissement des connexions entre ordinateurs et le transfert de fichiers squentiels via cette connexion. Lun des protocoles les plus rcents, SSL
(Secure Sockets Layer), mane de Netscape. Il prsente lavantage dinclure une fonction de
cryptage des donnes transmises, qui permet de scuriser les informations sensibles. SSL est
trs largement implant dans le monde Unix, dans lequel il scurise les transactions entre les
navigateurs Web et les serveurs. SSL a t soumis lIETS (Internet Engineering Task Force)
afin quil soit dclar protocole standard.
Connectivit des bases de donnes
La connectivit des bases de donnes fait gnralement partie de loffre des outils frontaux.
La plupart des fournisseurs proposent plusieurs possibilits de connexion, dont, pour presque
toutes les bases de donnes, le mode natif. Il existe toutefois quelques standards en matire de
connectivit de base de donnes, notamment ODBC (Open Database Connectivity), originellement dvelopp par Microsoft, et JDBC (Java Database Connectivity), initialement conu
par JavaSoft. ODBC est une mthode standard daccs aux bases de donnes qui permet
daccder nimporte quel type de base de donnes depuis nimporte quelle application.
ODBC insre une couche charge de traduire les requtes en provenance de lapplication en
commandes comprhensibles par la base de donnes. Historiquement, ODBC est devenu un
pilote de connectivit de second ordre parce que beaucoup dimplmentations spcifiques
nont pas donn daussi bons rsultats que lutilisation du mode natif. Toutefois, des pilotes
plus puissants existent aujourdhui et la popularit dODBC augmente. JDBC a profit de
lvolution dODBC et est de plus en plus employ.
Entre-temps, le march volue. Microsoft a cr une nouvelle srie de standards de connectivit sous le sigle OLE DB, qui promettent damliorer encore la connectivit des bases de
donnes.
Service dannuaire
Votre infrastructure de rseau doit prvoir des fonctionnalits destines attribuer des noms
aux htes et assurer lindpendance des adresses. Au dpart, lInternet et/ou les intranets
dpendent dun DNS (Domain Name Service), qui recherche un nom dans une liste et
retourne ladresse IP (Internet Protocol) correspondante. Cela vous permet dassigner un nom
ladresse IP de votre serveur de base de donnes et de configurer vos outils frontaux de
manire quils se servent de ce nom. Le nom du serveur est ensuite dynamiquement converti
en adresse IP, celle de lordinateur o rside la base de donnes. Si vous dplacez la base sur
un autre ordinateur, il suffit de modifier lentre correspondante dans la liste du DNS. Cette
conversion se produit chaque fois que vous utilisez un navigateur Web pour vous rendre sur
un site quelconque. Lorsque vous tapez www.nomdusite.com, ce nom est converti en adresse IP
par un serveur DNS avant que la demande de page soit envoye au site concern.
Il existe des services dannuaire plus complexes : les annuaires X.500 ou LDAP (Lightweight
Directory Access Protocol). Ils hbergent des informations bien plus riches que les simples
adresses IP. Ils peuvent concerner plusieurs types de donnes : noms et adresses, adresses email, listes tlphoniques et annuaires de matriel (imprimante, ordinateur, etc.). Ces
annuaires peuvent servir de liste dinventaire pour le recensement des serveurs, dannuaire des
utilisateurs pour la mise disposition des donnes, de listes de diffusion pour les tats standard, etc. Dans le chapitre 12, nous vous incitons centraliser ladministration de votre configuration ( logons , etc.) au moyen dun serveur dannuaire LDAP.

17

18

Architecture
PARTIE 3

Conclusion sur linfrastructure


Comme nous lavons vu, linfrastructure du data warehouse regroupe plusieurs composants :
plate-forme matrielle, connectivit et rseau, poste de travail. Dans chacun de ces trois
domaines, il est ncessaire comprendre les besoins mtier et de mettre en adquation la rponse
ces besoins. Heureusement, la porte de linfrastructure stend bien au-del de lentrept de
donnes. Les nouveaux systmes oprationnels client-serveur ont des besoins en infrastructure
similaires ceux des data warehouses ; en consquence, dans la plupart des cas lentrept de
donnes peut sappuyer sur linfrastructure existante. Cela dit, les questions dinfrastructure sont
trs sensibles ; vos dcisions se retourneront contre vous si vous avez fait le mauvais choix.

Mtadonnes et catalogue des mtadonnes


Les mtadonnes sont un vaste champ de bataille terminologique. Dans cette section, nous
allons dcrire les mtadonnes afin de vous aider les identifier lorsque vous en rencontrerez.
Nous illustrerons par un exemple le rle de soutien que les mtadonnes jouent au sein dun
entrept de donnes. Enfin, nous dcrirons le concept de catalogue de mtadonnes et ferons
quelques suggestions relatives au suivi des mtadonnes.

Mtadonnes : quest-ce que cest ?


Les mtadonnes sont un sujet un peu part dans le monde du data warehouse. Comme nous
ne savons pas exactement en quoi elles consistent ni o elles se trouvent, nous passons beaucoup de temps en parler, nous en inquiter et nous sentir coupable de ne pas nous en
occuper suffisamment. Il y a quelques annes, on a dcrt que les mtadonnes dsignaient
les donnes relatives aux donnes. Cette dfinition imprcise ne nous a pas beaucoup aids.
La notion sest cependant peu peu clarifie et il est mme question, depuis quelque temps,
de mtadonnes de la zone de construction (back room) et des mtadonnes des outils
frontaux (front room) . Les mtadonnes des outils darrire-plan (back room) sont
procdurales ; elles guident les processus dextraction, de nettoyage et de chargement. Les
mtadonnes des outils frontaux (front room) sont plus descriptives et aident les outils de
requte et les gnrateurs dtats fonctionner du mieux possible. Bien entendu, les mtadonnes procdurales et les mtadonnes descriptives se recoupent, mais le fait de les distinguer
ainsi peut aider mieux les comprendre.
Les mtadonnes de la zone de construction (back room) sont censes aider ladministrateur
de la base de donnes alimenter lentrept ; elles sont galement susceptibles dintresser les
utilisateurs qui souhaitent connatre la provenance des informations. Les mtadonnes des
outils frontaux (front room) bnficient essentiellement lutilisateur final ; elles ne se
contentent pas de mettre de lhuile dans les rouages des outils : elles constituent aussi une
sorte de dictionnaire de lactivit.
Cependant, ces deux dfinitions, aussi intressantes soient-elles, ne donnent pas ladministrateur de lentrept de donnes une ide prcise de lintrt des mtadonnes. Essayons donc
de considrer ces dernires selon une perspective de traitement de linformation classique.
Nous devrons :
laborer une liste dtaille de toutes les mtadonnes ;
dterminer limportance de chaque lment ;
dsigner le responsable des mtadonnes ;

Infrastructure et mtadonnes
CHAPITRE 11

dterminer un ensemble oprationnel et cohrent de mtadonnes ;


dcider sil convient de dvelopper les outils dexploitation des mtadonnes en interne ou
den acheter ;
stocker les mtadonnes dans un emplacement spcifique des fins de sauvegarde et de
restauration ;
les mettre la disposition des personnes qui en ont besoin ;
veiller leur qualit, sassurer quelles sont compltes et jour ;
les grer de manire centralise ;
dcrire toutes ces tches assez prcisment en vue de pouvoir les dlguer.
Un problme subsiste : nous navons pas encore vraiment expliqu ce quest une mtadonne Remarquez que le dernier point de la liste ci-dessus nest pas une mtadonne, mais
une information relative aux mtadonnes. Serons-nous amens faire appel des mtamtadonnes ? Pour y voir plus clair, laborons une liste de tous les types de mtadonnes
possibles. Celle-ci ne sera peut-tre pas exhaustive du premier coup mais nous en apprendra
certainement beaucoup.

Mtadonnes des systmes source


Revenons tout dabord aux systmes source : gros systmes, serveurs autonomes, postes de
travail, fournisseurs de donnes externes et mme Internet. Nous supposerons ici que nous
nous contentons de lire les donnes source et de les dposer dans la zone de prparation des
donnes, qui peut se situer sur le site central ou sur un ordinateur en aval.
Structures des sources
Bibliothques ;
schmas des sources ;
description de structures de donnes sous la forme de programmes (copy book cobol par
exemple) ;
schmas de bases propritaires ou issues de tiers ;
structure des fichiers des files dattente dimpression ;
anciens formats des donnes gros systme archives ;
tables et DDL des systmes source relationnels ;
feuilles de calcul ;
bases de donnes Lotus Notes ;
graphiques de prsentation (Power Point, par exemple) ;
spcifications des URL (Universal Resource Locator) sources.
Informations descriptives des sources
Description du responsable de chaque source ;
description mtier de chaque source ;
frquence des mises jour ;
limitations juridiques lexploitation de chaque source ;
mthodes daccs, droits daccs, privilges et mots de passe associs aux accs aux sources.

19

20

Architecture
PARTIE 3

Information sur les processus


Plannings des tches gros systme ou du systme source ;
langage dimplmentation de lextraction : Cobol et JCL, C, Basic, etc. ;
paramtres des outils dextraction automatise (le cas chant) ;
rsultats de tches dextraction, notamment heure exacte, contenu et tat dachvement.
Mtadonnes de la zone de prparation des donnes
laborons maintenant la liste des mtadonnes requises pour placer les donnes dans la zone
de prparation et pour prparer leur chargement dans un ou plusieurs data marts. Lopration
peut tre accomplie sur le site central au moyen dun programme Cobol dvelopp cet effet
ou laide dun outil dextraction automatise. Il est galement possible de stocker les fichiers
squentiels extraits sans y toucher dans une zone de prparation des donnes autonome, sur
un ordinateur distinct. En tout cas, nous devons nous proccuper des mtadonnes, notamment des points dcrits ci-aprs.
Information sur lacquisition des donnes
Planification de la transmission des donnes et rsultat de transmissions ;
utilisation des fichiers au sein de la zone de prparation des donnes : dure, volatilit et
responsable.
Gestion des tables dimensionnelles
Dfinition des dimensions conformes et des faits conformes ;
spcification des tches pour les oprations de jointures, dlimination de champs et de
recherche dattributs ;
rgles appliquer aux nouveaux attributs descriptif dans les dimensions changeantes (crasement, cration dun nouvel enregistrement, cration dun nouveau champ) ;
attribution dune cl de substitution chaque cl de production, prvoyant notamment une
table de correspondance performante pour effectuer cette mise en relation en mmoire ;
une copie des dimensions de production datant de la veille, utiliser comme base de DIFF
COMPARE.
Transformation et agrgation
Spcification du nettoyage des donnes ;
optimisation des donnes et transformations par rapprochement (par exemple, dveloppement des abrviations et ajout de dtails) ;
transformations ncessaires au data mining (par exemple, interprtation des valeurs nulles
et dtermination des plages numriques) ;
schma cible, flux entre les donnes source et cible, responsable des donnes cible ;
scripts de chargement du SGBD ;
dfinitions des agrgats ;
statistiques dutilisation des agrgats, statistiques dutilisation des tables de base et agrgats
possibles ;

Infrastructure et mtadonnes
CHAPITRE 11

journaux des modifications dagrgats.


Audit, journaux des tches et documentation
Traabilit des donnes et audit des enregistrements (do provient exactement cet enregistrement et de quand date-t-il ?) ;
journaux dexcution des transformations des donnes, synthse des rsultats et heures des
excution ;
numros de versions des logiciels de transformation des donnes ;
descriptions mtier du processus dextraction ;
mesures de scurit associes lextraction des fichiers, aux logiciels dextraction et aux
mtadonnes dextraction ;
mesures de scurit associes la transmission des donnes (mots de passe, certificats) ;
journaux darchivage de la zone de prparation des donnes et procdures de restauration ;
mesures de scurit associes larchivage de la prparation des donnes.

Mtadonnes SGBD
Aprs avoir transfr les donnes dans le SGBD du data warehouse ou du data mart, un autre
groupe de mtadonnes entre en scne :
contenu des tables du SGBD ;
paramtres de partitionnement ;
index ;
spcifications de rpartition des donnes sur plusieurs disques ;
priorits de traitement
droits et privilges daccs au SGBD ;
dfinition des vues ;
procdures stockes et scripts dadministration SQL ;
tat des sauvegardes du SGBD, procdures de sauvegarde et scurit des sauvegarde.

Mtadonnes des outils frontaux (front room)


Du ct des outils frontaux (front room), les mtadonnes se multiplient linfini :
noms et descriptions utilisateur des colonnes, des tables et des regroupements ;
dfinitions des requtes et des tats prdfinis ;
paramtres des outils de spcification des jointures ;
spcification des outils dimpression (attribution de noms clairs aux champs) ;
documentation destine lutilisateur et support de formation (labor la fois par le constructeur et le service informatique) ;
profils des privilges utilisateur dans la scurit rseau ;
certificats dauthentification de la scurit rseau ;

21

22

Architecture
PARTIE 3

statistiques dutilisation relatives la scurit rseau : tentatives de connexions, tentatives


daccs et tat des ID utilisateur par localisation ;
profils utilisateur individuels relis aux ressources humaines pour le suivi des vnements
qui affectent les droits daccs (promotions, transferts, dmissions) ;
liaisons avec les sous-traitants et les partenaires impliquant des droits daccs ;
tableau de lutilisation et des accs aux donnes, tables, vues et tats ;
statistiques pour la refacturation des ressources ;
sites Web favoris (un paradigme de laccs pour tous les data warehouse).
Vous comprenez maintenant pourquoi nous ne savions pas exactement ce que reprsentaient
les mtadonnes ! Elles englobent tout, sauf les donnes elles-mmes, et les donnes semblent
soudain tre la composante la plus simple de lensemble. Les mtadonnes sont en quelque
sorte lADN du data warehouse. Elles dcrivent les lments et la faon dont ils cooprent.
Alors que cette liste vous a prsent les mtadonnes sous un angle descriptif ; nous allons
prsent les observer en pleine action.

Exemple de mtadonnes dynamiques


La tche qui consiste collecter et maintenir les mtadonnes nest pas une fin en soi. Les
mtadonnes sont au data warehouse ce que la documentation est aux systmes traditionnels ; du
coup, on a facilement tendance les dlaisser au profit de projets plus urgents. Les mtadonnes
dynamiques tentent de rsoudre ce problme. Ces mtadonnes pilotent les processus ; ce
faisant, elles produisent de la documentation, qui est en fait une sorte deffet secondaire fortuit.
tudions le fonctionnement de ce processus en parcourant le graphique dun flux des mtadonnes simple. Vous avez dabord besoin dun modle de donnes du data warehouse.
Lopration est techniquement simple si vous recourez un outil de modlisation standard. La
plupart de ces outils sont fonctionnels en amont et en aval ; vous pouvez donc les utiliser pour
extraire les mtadonnes des bases de donnes existantes. Crez des modles logiques et
physiques incluant les noms logiques (mtier) des colonnes, leur nom physique, leur description mtier, des exemples de valeurs et des astuces de requtes. Une fois votre modle construit, enregistrez-le dans la base de donnes relationnelle prvue dans loutil pour le stockage
des mtadonnes. Ltape 1, figure 11.3, illustre ce processus.
Ajoutez ensuite quelques mtadonnes de prparation des donnes (data staging) ce flux. Les
modles de data warehouse labors ltape 1 apportent les informations ncessaires lidentification des cibles du processus de prparation. Loutil de prparation des donnes doit galement connatre les sources. Ltape 2 consiste donc capturer les dfinitions des sources.
Comme nous lavons dj prcis, il peut aussi bien sagir, par exemple, de fichiers squentiels
que de bases de donnes sur gros systme. Gnralement, loutil de prparation des donnes
dispose dun moyen intgr de capturer ces informations, dont il a imprativement besoin. Lors
de ltape 3, nous utilisons loutil de prparation pour injecter les dfinitions des tables et pour
tablir les rapprochements entre les sources et les cibles. Cette tape est galement celle de la
capture des informations relatives aux transformations susceptibles de se produire au cours du
processus de prparation. Si vous disposez dun bon outil de prparation, celui-ci potentialisera
les mtadonnes que vous avez dj cres au niveau des tables cibles lors de ltape 1.
Enfin, lors de ltape 4, nous allons enregistrer tout cela dans le modle de stockage ouvert
relationnel de loutil de prparation des donnes. La figure 11.4 illustre cette opration.

Infrastructure et mtadonnes
CHAPITRE 11
Figure 11.3

Capture des modles


de donnes de lentrept.

Outil de
modlisation

(1) Modle de
lentrept

Catalogue des mtadonnes


Modle
physique
Modle
logique

Figure 11.4

Capture de la dfinition
des sources et rapprochement avec les cibles.

Outil de
modlisation

(1) Modle de
lentrept

Catalogue des mtadonnes


Modle
physique

(2) Dfinitions
des sources

Modle
logique

Dfinitions
des sources

Rapprochements
source/cible

(3) Dfinitions
des tables

Systmes
source

(4) Rapprochements
source/cible

Outil de
prparation
des
donnes

23

24

Architecture
PARTIE 3

Notez que le processus de cration de ces rapprochements, ltape 3, consiste essentiellement dfinir des relations entre des mtadonnes existantes. Le plus gros du travail a t
accompli lors de la construction du modle de donnes ; nous pouvons mettre en place autant
de rapprochements que nous le souhaitons et les stocker dans le catalogue des mtadonnes.
Lorsque toutes ces dfinitions sont compltes, nous pouvons commencer charger les
donnes, comme le montre la figure 11.5. Au cours de ltape 5, loutil de prparation des
donnes interroge les mtadonnes afin de rcuprer les informations requises : type et
localisation des donnes source, type et localisation des donnes cible, rapprochements
entre les deux.
Figure 11.5

tapes 5 8 :
extraction, transformation et chargement.

Outil de
modlisation

(1) Modle de
lentrept

Catalogue des mtadonnes


Modle
physique

(2) Dfinitions
des sources

Modle
logique

Dfinitions
des sources

Rapprochements
source/cible

(3) Dfinitions des tables


(5) Informations de
rapprochement et
de transformation
Systmes
source

(6) Donnes extraites

(4) Rapprochements source/cible


(8) Statistiques de chargement

Outil de
prparation
des
donnes

(7) Donnes transformes

(5a) Informations physiques


(tablespaces, etc.)

Data
warehouse

Infrastructure et mtadonnes
CHAPITRE 11

Nous pouvons galement interroger la base de donnes cible au cours de ltape 5a pour rcuprer des informations sur ltat physique du systme, notamment sur lespace disque disponible. Au cours de ltape 6, nous procdons lextraction proprement dite des sources de
donnes brutes et dans ltape 7, nous chargeons les donnes transformes dans lentrept.
Ltape 8 capture des statistiques et des informations de surveillance relatives la charge et
les enregistre dans le catalogue des mtadonnes.
Nous avons donc russi charger des donnes ; les utilisateurs brlent dimpatience de les
exploiter, mais il faudrait quils disposent dindications sur leur contenu. Heureusement,
lensemble des informations de lentrept est dcrit dans le modle des donnes. Tout y est :
nom des colonnes et des tables, descriptions et exemples de valeurs. Toutefois, avant douvrir
grand les portes, il convient de donner lentrept un abord plus mtier . Une liste des
tables et des colonnes classes par ordre alphabtique ne suffira pas, car lutilisateur raisonne
en types dactivits et non par ordre alphabtique Les regroupements oprer dcoulent de
la table des faits. Les outils frontaux et les serveurs dapplications permettent habituellement
de gnrer ces mtadonnes.
Les mtadonnes utilisateur sont maintenant prtes ; ltape 9 montre lintrt dun outil Web
destin exploiter les mtadonnes. Lutilisateur peut consulter les types dactivits, identifier
les tables qui appartiennent tel ou tel type dactivit et mme consulter leur contenu. En
outre, laide dun simple outil de recherche, lutilisateur peut rechercher les noms ou les
descriptions de colonnes et de tables contenant par exemple le mot vente ou le mot recette.
Quand les utilisateurs ont trouv les donnes quils recherchent, ils peuvent formuler une
requte et la soumettre la base de donnes (tape 10). Remarquez au passage que la requte
sappuie aussi sur les descriptions physiques des tables et des colonnes, rcupres ltape 9,
pour gnrer la syntaxe correcte. Ltape 11 envoie le rsultat lutilisateur ; ltape 12 est
prise en charge par un bon outil de requte capable de gnrer un certain nombre dinformations relatives lutilisation.
Cette progression illustre le rle central du catalogue des mtadonnes dans le contexte dun
entrept de donnes simple. Vous remarquerez par ailleurs que sur les douze tapes dcrites,
seulement trois impliquent les donnes ; toutes les autres concernent les mtadonnes. Remarquez galement que, dans certains cas, des composants dune seule et mme mtadonne
apparaissent en diffrents endroits. Par exemple, le modle que nous avons cr dans ltape 1
contient les dfinitions des tables physiques. Loutil daccs aux donnes sen sert lors du
rapprochement source/cible puis, plus tard, pour transformer et charger les donnes. Enfin,
loutil de requte et le serveur dapplications ont besoin de connatre les dfinitions des tables
physiques pour formuler de bonnes requtes.
La liste des mtadonnes et lexemple de flux ont finalement russi vous donner une vue
densemble de ces fameuses mtadonnes. Mais est-il vraiment ncessaire de suivre un tel
cheminement ? Nous pensons que oui. Cette liste de mtadonnes est la charpente de votre
entrept de donnes. Le simple fait den laborer la liste apporte une aide. La liste est longue,
mais elle permet didentifier le type, lintrt et le lieu de stockage de chaque mtadonne.
La modration est toutefois de mise. En effet, la plupart de ces mtadonnes doivent rsider
sur des ordinateurs situs prs des lieux o les tches se droulent. Les programmes, les paramtres et les spcifications qui pilotent les processus doivent connatre des destinations
certaines et des formats certains, et cela ne va pas changer dans les prochains temps.

25

26

Architecture
PARTIE 3

Outil de
modlisation

(1) Modle de
lentrept

Catalogue des mtadonnes


Modle
physique

(2) Dfinitions
des sources

Modle
logique

Dfinitions
des sources

Rapprochements
source/cible

(3) Dfinitions des tables

(12) Statistiques dutilisation


des requtes

(9) Descriptions
mtier (noms
et contenu
des tables et
des colonnes,
exemples de
valeurs, etc.)

(4) Rapprochements
source/cible

(5) Informations de
rapprochement et
de transformation
Systmes
source

(6) Donnes extraites

(8) Statistiques de
chargement
Outil de
prparation
des
donnes

(7) Donnes transformes

Outils
frontaux

(5a) Informations physiques


(tablespaces, etc.)
(10) tats, requtes

(11) Donnes

Data
warehouse

Figure 11.6

Rle des mtadonnes dans le pilotage des outils frontaux.

Maintenance du catalogue des mtadonnes


Les termes bibliothque dinformation, rfrentiel, dictionnaire de mtadonnes et mtabase
de donnes sont, parmi dautres, utiliss pour dcrire le catalogue des mtadonnes. Nous
avons choisi le terme catalogue des mtadonnes pour dcrire lensemble des mtadonnes
prsentes dans lentrept. Idalement, ce catalogue devrait tre le lieu de stockage unique des
informations qui pilotent des processus dans lentrept. Toutes les procdures internes de

Infrastructure et mtadonnes
CHAPITRE 11

lentrept, du modle initial la navigation et laccs aux donnes en passant par les extractions rcurrentes et les processus de chargement, devraient faire appel au catalogue des mtadonnes. Malheureusement, une mise en uvre aussi parfaite est impossible lheure
actuelle ; nous considrerons donc le catalogue des mtadonnes comme un concept logique
rparti dans plusieurs emplacements physiques.
ASTUCE

Procurez-vous un outil pour cataloguer et suivre toutes ces mtadonnes. Il ne sera probablement pas
capable de lire et dcrire toutes les mtadonnes directement mais, tant donn leur parpillement, il
vous aidera au moins grer.

Il existe heureusement une catgorie doutils, judicieusement nomms outils pour catalogues
de mtadonnes, qui se consacrent cette tche. Le site Web de Larry Greenfield en fournit
une liste intressante ladresse http :/pwp.starnetinc.com/larry/catalog.html.
Lquipe du data warehouse doit envisager lacquisition doutils de maintenance en vue
dadministrer les mtadonnes du catalogue non gres par les outils et les services en place.
Par exemple, les commentaires saisis par les utilisateurs, les hirarchies personnalises ou les
spcifications qui accompagnent les data marts personnels peuvent ne pas tre pris en charge
par les produits existants et ncessiter la mise en place dun service spcifique.
Dans lenvironnement du catalogue des mtadonnes, une autre fonctionnalit pourra tre
mise en uvre afin de crer des RPC (Remote Procedure Calls), qui procureront aux systmes
source et aux outils de navigation un accs direct aux mtadonnes.
Enfin, les services de prparation et daccs aux donnes doivent tre en mesure dexploiter
les mtadonnes relatives la scurit. Celles-ci doivent tre dveloppes et maintenues au
moyen dun outil ou dune fonction quelconque. Il sagit dajouter et de supprimer des utilisateurs et des groupes dutilisateurs, dassigner des droits daccs ces utilisateurs et ces
groupes, etc. Ces mtadonnes doivent galement tre intgres aux tables de scurit de la
plate-forme de la base de donnes (encore des mtadonnes !).
La maintenance du catalogue des mtadonnes implique un certain nombre de fonctions et de
services :
intgration et fusion des informations du catalogue (depuis le modle de donnes vers la
base de donnes, puis vers les outils frontaux) ;
administration des mtadonnes (suppression des entres inutilises ou obsoltes) ;
capture des mtadonnes existantes (DDL du gros systme ou autres sources) ;
gestion et prsentation de graphiques et de tableaux illustrant le contenu du catalogue des
mtadonnes (le navigateur de mtadonnes) ;
maintenance des profils utilisateur au profit des applications et de la scurit ;
scurit du catalogue des mtadonnes ;
gestion locale ou centralise du catalogue des mtadonnes.
Ayant pris les premires dispositions pour regrouper et contrler nos mtadonnes, pouvonsnous esprer nous tourner vers des outils encore plus puissants qui rassembleront les mtadonnes en un lieu unique et qui seront capables de les lire et de les crire ? Ce type doutil nous
apporterait une interface utilisateur uniformise, apprciable dans un cadre aussi disparate, et
nous permettrait en outre de prendre des instantans cohrents de toutes les mtadonnes dun
seul coup (puis de les sauvegarder, de les scuriser et de les restaurer en cas de besoin).

27

28

Architecture
PARTIE 3

notre avis, ce type doutil nest pas prs dinonder le march. Le problme est trs
complexe ; la prise en compte de toutes les formes de mtadonnes requiert un type dintgration entre les systmes qui nexiste pas encore. Nous sommes convaincus que la Metadata
Coalition (un groupe de constructeurs qui sest attel la rsolution du problme des mtadonnes) ralisera des progrs intressants dans la dfinition dune syntaxe et dune smantiques communes pour les mtadonnes. Signalons toutefois que ce groupe a vu le jour en
1995 Malheureusement, Oracle et Microsoft, qui sont les deux grands du SGBD, ont dcid
de ne pas sassocier cette initiative et ont fait la promesse de publier leurs propres standards
de mtadonnes propritaires. Si les avantages de ces standards sont assez importants pour
attirer dautres fournisseurs, nous pouvons esprer que le problme des mtadonnes sera
rsolu une bonne fois pour toutes.

Conclusion sur les mtadonnes


Les mtadonnes sont le nud gordien du data warehouse, mais Alexandre et son pe ne sont
pas encore en vue. Comment faire face en attendant ? Voici quelques mesures qui vous
permettront au moins de desserrer un peu le nud :
Insistez lourdement pour que les fournisseurs choisis proposent des fonctionnalits
dchange ouvert des mtadonnes.
Prenez en charge les points faibles laide dutilitaires simples qui vous aideront copier
les mtadonnes depuis leurs sources vers les emplacements o vous en aurez besoin et
administrer les tches de gestion des mtadonnes les plus rptitives.
Le reste devra tre fait manuellement . laborez le catalogue de vos mtadonnes afin de
pouvoir les maintenir correctement. Vous oprerez une migration vers le catalogue des
mtadonnes intgr lorsque celui-ci fera son apparition. Rappelez rgulirement vos
fournisseurs quils se sont engags travailler sur lchange ouvert des mtadonnes.

En rsum
Linfrastructure et les mtadonnes sont les fondations du data warehouse. Une infrastructure
insuffisante ou des mtadonnes trop limites et ngliges risquent daffaiblir lentrept entier.
Il ne sert rien de produire des donnes parfaites si vous ne parvenez pas les acheminer
jusquau poste de travail de lutilisateur sous une forme fiable, comprhensible et prvisible.

Vous aimerez peut-être aussi