Concevoir et déployer un data warehouse

Concevoir
et déployer un
data warehouse
Ralph Kimball
Éditions Eyrolles
ISBN : 2-212-09165-6
2000
Définition de
l'architecture
technique
Planification
du projet
Définition
des
besoins de
l'entreprise
Modélisation
dimensionnelle
Installation
et sélection
des produits
Conception
du modèle
physique
Spécification de
l'application
utilisateur
Conception et
développement
des éléments
de la zone de
préparation
des données
Déploiement
Maintenance
et
croissance
11
Développement
de l'application
utilisateur
Gestion du projet
Infrastructure et métadonnées
L’infrastructure et les métadonnées sont les fondations des composantes architecturales que
nous avons décrites dans les chapitres 8, 9 et 10. L’infrastructure d’un entrepôt de données
inclut le matériel, les réseaux et les fonctions de bas niveau, telles que la sécurité, que les
composants de haut niveau considèrent comme acquises. Les métadonnées sont un peu moins
concrètes que l’infrastructure, mais constituent tout de même la couche de base des outils
d’arrière-plan (back room) et frontaux (front room). Ce chapitre identifie et définit les principaux composants de l’infrastructure et des métadonnées du data warehouse.
Dans la première partie de ce chapitre, nous examinons les principaux éléments à prendre en
compte en matière d’infrastructure des outils d’arrière-plan (back room). Ensuite, nous aborderons quelques considérations relatives au matériel, aux systèmes d’exploitation et aux
plates-formes de bases de données, en donnant au passage quelques définitions de base. Nous
en ferons ensuite de même pour les outils frontaux (front room). Enfin, pour relier l’ensemble,
nous évoquerons brièvement la connectivité et les réseaux.
La seconde partie de ce chapitre examine les métadonnées sous toutes les coutures. Il s’achève
par un exemple d’utilisation des métadonnées et par quelques réflexions sur leur maintenance.
2
Architecture
PARTIE 3
Bien qu’assez technique, ce chapitre concerne tous les membres de l’équipe ; il est en effet
important que chacun connaisse bien ces pièces maîtresses du data warehouse.
Infrastructure
Plusieurs facteurs doivent être combinés pour déterminer l’infrastructure adaptée à une implémentation donnée ; ils ne sont pas forcément tous techniques. Les auteurs de ce livre ne sont
pas des experts en infrastructure. Notre stratégie 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 l’entrepôt. Cette section identifie et définit les principaux
composants de l’infrastructure d’un data warehouse typique.
Éléments clés de l’infrastructure
Même dans les couches techniques les plus profondes de l’entrepôt, les besoins métier restent
les éléments déterminants de la mise en œuvre. Au niveau de l’infrastructure, les besoins métier
sont représentés par des mesures plus techniques. Par exemple, l’activité détermine le niveau de
détail auquel l’entrepôt doit descendre et le nombre d’années d’historique qu’il doit conserver.
Ces informations nous indiquent le volume de données que l’infrastructure aura à gérer. La
fréquence de chargement des données et la complexité des règles régissant les processus de
transformation peuvent également fournir des indications. Estimez ainsi le « nombre de chevaux »
dont il faudra doter votre configuration matérielle pour que tout se passe bien.
Les problèmes techniques et système conduisent également à certains choix relatifs à l’infrastructure. Dans certains cas, le processus d’extraction représente une charge trop lourde pour
les systèmes opérationnels ; cette situation peut déboucher sur un investissement dans un environnement matériel miroir. Les compétences et l’expérience des équipes chargées de la mise
en œuvre de l’entrepôt entrent aussi en ligne de compte. Les équipes responsables des outils
d’arrière-plan (back room) expérimentées en gros systèmes auront tendance à développer des
entrepôts de données sur gros systèmes, et vice versa. Il en est de même pour les plates-formes
de base de données. Si les administrateurs des bases de données ont investi beaucoup de temps
et d’énergie dans l’apprentissage d’un SGBD bien précis, il ne sera pas aisé de les orienter
vers un autre produit.
Les problèmes politiques et organisationnels jouent également un rôle dans le choix de
l’infrastructure. Les gros investissements sont souvent soumis à des limites « temporaires » ;
dans un tel cas, vos réflexions sur l’infrastructure devront faire preuve de davantage de créativité. Par ailleurs, la stratégie informatique de l’entreprise guidera certaines décisions relatives
au matériel. En effet, la standardisation des plates-formes permet de réaliser d’importantes
économies d’échelle, de capitaliser les compétences, et enfin de développer des applications
dont le portage d’un système à un autre sera relativement aisé.
Évolution de l’infrastructure
L’infrastructure matérielle de l’entrepôt de données englobe les plates-formes matérielles de
chaque magasin de données, de chaque serveur d’applications et des postes de travail.
ASTUCE
À propos des plates-formes matérielles, il convient de garder à l’esprit qu’un entrepôt de données connaît
sa croissance la plus significative au cours des dix-huit premiers mois de son existence, à la fois en
termes de données et d’utilisation.
Infrastructure et métadonnées
CHAPITRE 11
La première étape consiste à déterminer les plates-formes réellement nécessaires. Quels
magasins de données allez-vous mettre en œuvre ? Parmi eux, combien devront disposer de
leur propre plate-forme ? La figure 11.1 illustre quelques configurations matérielles typiques
correspondant à des projets de tailles diverses.
Entrepôt et
préparation
Petit/début
Moyen/
deuxième
phase
Grand/
entreprise
Entrepôt de
données/
data mart
Préparation et
développement
Test/
développement
Zone de
préparation
des données
Data mart
de données
atomiques
Plusieurs
data marts
Plusieurs
data marts
Serveur
d’applications
Outils
du poste
de travail
Serveur
d’applications
Outils
du poste
de travail
Serveur
d’applications
Serveur
d’applications
Outils
du poste
de travail
Outils
du poste
de travail
Figure 11.1
Plates-formes matérielles correspondant à des entrepôts de données de tailles et de maturité variées.
Chaque boite de cette figure représente une machine ou un ensemble de composants physique
de l’entrepôt. Un environnement à deux niveaux (2 tiers) suffit pour un projet modeste ou pour
un premier déploiement. Cependant, même les systèmes les plus petits doivent prévoir un
serveur d’applications pour permettre l’accès aux données via le Web. Dans les entrepôts de
données plus ambitieux ou arrivés à maturité, la zone de préparation des données est généralement séparée de l’entrepôt ou du data mart. De nombreuses entreprises commencent directement à ce niveau, car elles ont l’intention de faire croître leur data warehouse en évitant
d’avoir à migrer vers une architecture à trois niveaux (3 tiers). Au bas de la figure, un entrepôt
de données étendu à toute l’entreprise est implémenté sur plusieurs serveurs séparés. 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 manière non négligeable.
Infrastructure des outils d’arrière-plan (back room)
Dans tout processus de sélection de plates-formes, la première étape consiste à bien assimiler
les besoins. Le simple fait de comprendre ce qu’une plate-forme doit faire et la façon dont elle
doit le faire du point de vue technique ne suffit pas. Il est essentiel de prendre aussi en compte
les besoins métier. Ce faisant, vous constaterez que le nombre de solutions à examiner se
réduit considérablement et vous pourrez comparer leurs coûts respectifs, ainsi que d’autres
facteurs, en vue de déterminer la meilleure. Dans presque tous les projets de data warehouse,
3
4
Architecture
PARTIE 3
le serveur de la base de données est peut-être la décision la plus délicate en matière de matériel.
Voici quelques facteurs à évaluer pour choisir vos serveurs :
• Volumétrie. Le volume de données à gérer est déterminé par les préoccupations métier que
vous avez pour objectif de résoudre. Si la stratégie de l’entreprise est de développer des
relations client one-to-one, le niveau de détail des transactions devra être le client. La
plupart des projets d’entrepôt de données et de data marts se contentent de 200 gigaoctets
au départ. Souvent, ils sont même encore plus modestes et se mettent à croître au fur et à
mesure de l’accumulation des historiques, de la création d’agrégats et de l’apparition de
nouvelles sources de données. Toute configuration en deçà de 200 gigaoctets est facile à
administrer. Pour vous aider à vous y retrouver, nous qualifierons de petits les entrepôts de
données dont la capacité est inférieure à 100 gigaoctets, de moyens ceux allant de 100 à
500 gigaoctets et de grands ceux dépassant 500 gigaoctets.
• Volatilité. Elle mesure le dynamisme de la base de données via la fréquence des mises à
jour, le volume des données modifiées ou remplacées à chaque mise à jour et la taille de la
fenêtre de chargement. Encore une fois, les besoins métier fournissent de bonnes indications sur la volatilité. Bien évidemment, les données quotidiennes sont plus volatiles que
les données hebdomadaires ou mensuelles. Les réponses à ces questions ont une incidence
directe sur la taille et sur les performances de votre plate-forme matérielle.
• Nombre d’utilisateurs. Bien évidemment, le nombre d’utilisateurs, la fréquence selon
laquelle ils utilisent le data warehouse, le nombre de connexions simultanées et les pics
d’activité (fin de mois, par exemple) sont autant de facteurs importants dans la sélection
d’une plate-forme. Pour une entreprise digne de figurer au palmarès des 1 000 premières
dans Fortune, l’effort 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 d’utilisateurs, notamment si l’entrepôt est utilisé à la fois
pour des requêtes ad hoc et pour créer des états standard ou presse-bouton dans une grande
entreprise. La répartition géographique des utilisateurs est également importante. S’ils sont
disséminés sur toute la planète, le système devra bien évidemment être disponible 24 heures
sur 24, ce qui a des conséquences sur le matériel. Dans un tel cas de figure, si les systèmes
opérationnels sont centralisés l’entrepôt de données devra probablement l’être également,
mais le matériel devra autoriser les chargements en parallèle ou « au compte-gouttes » pour
permettre une disponibilité constante. Si les systèmes opérationnels sont décentralisés, il
semble logique de décentraliser également les data marts.
• Nombre de processus métier. Le nombre de processus métier pris en charge par l’entrepôt
influe énormément sur sa complexité. Vous pouvez envisager une plate-forme matérielle
par processus si les utilisateurs sont suffisamment nombreux ou si l’activité le justifie.
Cependant, vous aurez peut-être également besoin d’un gros serveur centralisé si les
données consolidées sont indispensables aux dirigeants de l’entreprise et si les méthodes
middleware de consolidation virtuelle sont inadaptées à votre situation.
• Type d’utilisation. Le type d’utilisation et les outils frontaux sélectionnés ont également
une incidence sur le choix des plates-formes. En effet, une poignée d’« utilisateurs ad hoc »
peut peser lourdement sur les performances de l’entrepôt de données. Il est difficile d’optimiser un data warehouse pour ce type d’utilisation, car les bons analystes compulsent sans
cesse les données à la recherche de niches. Au contraire, un système presse-bouton essentiellement destiné à produire des états standards peut être optimisé pour ce type
d’utilisation ; toutefois, si vous avez l’intention d’en rester aux états standard, vous ne
Infrastructure et métadonnées
CHAPITRE 11
tirerez pas le meilleur parti de votre investissement. La plupart des générateurs d’états du
marché permettent de planifier l’exécution d’états prédéfinis tôt le matin, après le chargement des données et avant l’arrivée du personnel. Cette démarche vise à mieux répartir la
charge de traitement en générant la plupart des états standard en dehors des heures de
pointe. Le data mining à grande échelle représente également une lourde charge pour le
matériel, tant du point de vue du volume des données que de celui des entrées-sorties. Il
faudra alors prévoir des « bêtes de course » capables d’absorber d’énormes volumes de
données, de les « ratisser » au moyen des outils de data mining les plus scrutateurs et de
retourner des résultats à l’analyse et à la conduite de l’activité. Il est donc primordial
d’étudier les différents types de requêtes, parce que l’utilisation ad hoc, la génération
d’états et le data mining ont des profils différents et que leurs performances varient selon
les plates-formes.
• Compétences techniques. Du point de vue de l’administration, l’environnement serveur
est comparable à l’environnement gros système sur le plan conceptuel mais très différent
sur le plan de l’implémentation. N’espérez pas pouvoir installer un serveur Unix, ni même
un système NT important, si l’équipe ne compte aucun expert en ressources système. La
gestion d’un serveur implique des tâches et des compétences nombreuses : administration
de base du matériel et des logiciels systèmes, connectivité (avec les postes de travail et les
systèmes source), compétences en administration de données, sauvegardes et restaurations,
etc. Malheureusement, dans l’état actuel de l’évolution technologique, il n’est pas question
de se contenter de mettre en route les serveurs et de ne plus s’en occuper. Du moins pas
encore… Choisissez donc les plates-formes matérielles en fonction des compétences
internes, à la fois en termes qualitatifs et quantitatifs.
• Disponibilité logicielle. Il arrive fréquemment que l’analyse des besoins mette en évidence
des fonctionnalités manquantes, par exemple un système d’information géographique
permettant de situer les informations de l’entrepôt sur des cartes. Le processus de sélection
des logiciels peut révéler que le logiciel de cartographie qui répond le mieux à vos besoins
ne fonctionne que sur une plate-forme graphique haut de gamme ; dans un tel cas, la décision
sera vite prise !
• Ressources financières. Le budget alloué à un projet dépend généralement des bénéfices
attendus. En matière de data warehouse, c’est un peu le problème de l’œuf et de la poule.
Dans le chapitre 3, nous avons parlé de la justification. Il est ardu de décrire et de vanter les
mérites d’un entrepôt avant d’en avoir mis un en œuvre. En terme de matériel, la conclusion est simple : choisissez les plus gros serveurs que votre budget vous permet d’acquérir.
Plates-formes matérielles et systèmes d’exploitation
Dans la mesure où un ordinateur ne fonctionne pas sans système d’exploitation, le matériel et
le système d’exploitation forment un tout. Dans les environnements gros système, vous n’avez
pas le choix du système d’exploitation. En revanche, dans le monde des systèmes ouverts
chaque constructeur de matériel implémente sa propre version d’Unix. Même NT existe en
plusieurs versions, qui n’acceptent pas toutes les logiciels Intel/NT de base en natif. Voici les
principales catégories de combinaisons matériel/système d’exploitation :
• Gros systèmes. Dernièrement, une série d’articles a fait état d’applications qui regagnaient
l’environnement gros système après avoir subi un échec dans l’environnement clientserveur. Le data warehouse est certainement le domaine auquel cette observation ne
s’applique pas. En règle générale, le gros système n’est pas la plate-forme idéale pour un
5
6
Architecture
PARTIE 3
entrepôt de données et les quelques réussites en la matière sont des exceptions : il s’agit soit
d’entrepôts de données implémentés sur gros système depuis longtemps et dont la migration coûterait trop cher, soit d’entrepôts de données qui exploitent un excédent de capacité
du gros système, entraînant ainsi des coûts marginaux relativement faibles. Cependant, le
data warehousing sur gros système est en général peu rentable. Les coûts relatifs à l’administration, au matériel et à la programmation sont plus élevés que ceux des systèmes
ouverts, en partie parce que le gros système dispose d’une infrastructure de traitement des
transactions poussée, qui ne présente aucun intérêt dans le cadre du data warehousing.
En outre, étant donné que le gros système est essentiellement conçu pour gérer les transactions, il manque de souplesse sur le plan de la programmation. Les outils et les techniques
sont fiables, mais difficiles à exploiter. L’ajout de nouvelles sources de données, ou même
la maintenance des extractions existantes, peut être très pénible.
Enfin, de nombreuses entreprises sont équipées de gros systèmes offrant des capacités limitées et n’envisagent aucune extension en vue d’applications nouvelles. Alors si vous avez
de la place, occupez-la ; si vous devez envisager un nouvel investissement, optez pour un
environnement serveur.
• Serveurs de systèmes ouverts. Les serveurs de systèmes ouverts, ou Unix, sont
aujourd’hui les plates-formes les plus courantes pour les entrepôts de données de moyenne
et de grande dimension. Unix est généralement assez robuste pour gérer correctement les
applications de production et pratique le traitement parallèle depuis plus de dix ans. Le
marché des serveurs Unix est relativement accessible. D’un point de vue fonctionnel, Unix
peut sembler étrange aux habitués des gros systèmes et aux programmeurs PC par exemple,
la plupart des utilitaires ne sont pas standard. L’équipe du data warehouse devra donc
posséder les compétences requises par l’installation et la gestion d’un environnement Unix.
Veillez à la participation active des administrateurs. L’équipe du data warehouse devra
également connaître les commandes et les utilitaires Unix pour pouvoir développer et gérer
l’entrepôt ; prévoyez des formations le cas échéant. Gardez surtout à l’esprit qu’Unix n'est
pas un environnement standard et que chaque constructeur propose sa propre version du
système d’exploitation, dotée de ses propres particularités.
• Serveurs NT. Bien qu’étant de loin le système d’exploitation connaissant la plus forte
croissance sur le marché, NT vient seulement d’atteindre les capacités nécessaires à
l’implémentation d’un entrepôt de données de taille moyenne. Des plates-formes matérielles NT étendues et viables font leur apparition. Les capacités de traitement parallèle ont
longtemps été limitées à des architectures mono-processeurs et les clusters sous serveur NT
sont opérationnels depuis peu. Étant donné les antécédents de Microsoft, on peut penser
que NT va devenir une plate-forme d’exploitation puissante ; à l’heure actuelle, ce système
n’est toutefois pas le mieux adapté aux entrepôts de données de moyenne et de grande
dimension. Il est en revanche rentable dans le cadre de data warehouses modestes ou de
data marts peuplés de données atomiques.
Architectures de traitement en parallèle
Les constructeurs se sont toujours montrés créatifs en matière de sigles et continuent à en
inventer régulièrement de nouveaux. Le marché des serveurs offre trois architectures matérielles de traitement parallèle, illustrées par la figure 11.2 : SMP (Symmetric Multiprocessing), MPP (Massive Parallel Processing) et NUMA (Non-Uniform Memory Architecture).
Ces architectures diffèrent dans la manière dont les processeurs interagissent avec les disques
Infrastructure et métadonnées
CHAPITRE 11
durs, avec la mémoire et entre eux. Les frontières entre ces architectures s’estompent à mesure
que les constructeurs optimisent leurs offres. Les sections qui suivent évoquent l’application
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 matérielles.
SMP (fonctionnement en multi-processeur symétrique)
L’architecture SMP présente une machine unique équipée de plusieurs processeurs, chacun
étant géré par un système d’exploitation et accédant à son propre disque et à sa zone de
mémoire. Une machine SMP équipé de 8 à 32 processeurs, une base de données parallèle,
beaucoup de mémoire (deux gigaoctets ou plus), un bon disque et une conception adaptée
conviennent parfaitement à un entrepôt de données de taille moyenne. Pour tirer parti de
processeurs multiples, la base de données doit être capable d’exécuter ses opérations en parallèle et les processus de l’entrepôt doivent être conçus pour exploiter les fonctionnalités du traitement en parallèle.
ASTUCE
L’architecture en « partage intégral » rend les machines SMP bien adaptées aux requêtes ad hoc. Dans un
environnement ad hoc, les chemins d’accès ne sont pas connus par avance. La nature à la fois centralisée et partagée de l’architecture SMP permet au système d’allouer de la puissance de traitement à
l’ensemble de la base de données.
7
8
Architecture
PARTIE 3
Le « partage intégral » représente à la fois la force et la faiblesse de l’architecture SMP. Les
processeurs peuvent accéder aux ressources partagées (mémoire et disque) très rapidement,
mais les chemins qu’ils emploient risquent fort de produire des goulets d’étranglement en cas
de forte sollicitation. Étant donné que la machine SMP est une entité unique, plus rien ne fonctionnera en cas de panne. Pour remédier à cet inconvénient, les constructeurs mettent au point
des techniques permettant à plusieurs ordinateurs SMP d’être reliés entre eux ou de former
des clusters. Dans un cluster, chaque nœud est une machine SMP possédant son propre
système d’exploitation, mais le cluster inclut des logiciels de connexion et de contrôle qui
permettent aux machines de se partager les disques et de pourvoir à la réparation des
défaillances. Ainsi, si une machine cesse de fonctionner, les autres se répartiront temporairement sa charge de travail. Bien entendu, cet avantage a un coût car les clusters sont complexes
et difficiles à gérer. Enfin, la technologie de base de données nécessaire à la prise en compte
des clusters évolue sans cesse.
MPP (traitement massivement parallèle)
Les configurations MPP sont fondées sur des chaînes d’ordinateurs relativement indépendants
les uns des autres, équipés chacun de son propre système d’exploitation, de sa mémoire et de
son disque dur, le tout étant coordonné par des échanges de messages. La force de MPP réside
dans sa capacité à connecter des centaines de nœuds (c’est-à-dire de machines) en vue de leur
soumettre un problèmes selon l’approche par la force. Par exemple, pour sonder une grosse
table de fond en comble, vous obtiendrez rapidement un résultat en recourant à un système
MPP de 100 nœuds, chaque nœud étant chargé de traiter un centième de la table. C’est la
notion de « petite main » appliquée à l’informatique. Les difficultés surgissent lorsque le fractionnement du problème à traiter est malaisé. Par exemple, une jointure entre deux grosses
tables peut poser problème si elles doivent toutes deux être traitées par les cent nœuds. En
effet, chaque enregistrement d’une des tables peut être lié à des enregistrements de l’autre
table, qui peuvent se trouver sur n’importe lequel des 99 autres nœuds ! La tâche de coordination des nœuds peut alors subir une surcharge. Bien entendu, les développeurs de systèmes
utilisant la technologie MPP ont mis au point des moyens de contourner ce problème et de
résoudre d’autres questions liées au parallélisme.
Les systèmes MPP sont bien adaptés aux entrepôts de données de grande taille (au-delà du
téraoctet) et aux applications qui accèdent aux données de manière intensive (data mining).
Dans ces systèmes, vous pouvez optimiser l’accessibilité aux données en stockant celles-ci en
miroir sur plusieurs nœuds. Les machines MPP fonctionnent mieux lorsque les chemins
d’accès aux données sont prédéfinis et que les données peuvent être distribuées sur les nœuds
et sur les disques en fonction de ces chemins.
ASTUCE
Les systèmes MPP sont fréquemment employés pour gérer les environnements de requêtes prédéfinies
ou d’états standard ou encore pour alimenter les data marts en données atomiques. Leur coût est réputé
élevé ; leur administration et leur optimisation sont délicates. Encore une fois, la base de données doit être
conçue pour tirer parti de cette structure matérielle (la conception physique adaptée à un système MPP
peut être très différente de celle conçue pour un système SMP).
NUMA (architecture de mémoire non uniforme)
L’architecture 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 parallèle du second. Il s’agit
d’une innovation relativement récente, qui a des chances d’être viable à long terme sur le
Infrastructure et métadonnées
CHAPITRE 11
marché du data warehouse. Du point de vue conceptuel, l’architecture NUMA reprend l’idée
des clusters de machines du SMP, mais avec des connexions plus « serrées » de la bande
passante supplémentaire et une meilleure coordination des nœuds. S’il vous est possible de
segmenter votre entrepôt de données en groupes d’utilisation relativement autonomes et de placer
chaque groupe sur son propre nœud, l’architecture NUMA vous donnera satisfaction.
Considérations générales sur les architectures parallèles
Quelle que soit la plate-forme, il est conseillé de s’interroger sur la disponibilité des logiciels
et sur la complexité de l’administration des systèmes. Voici quelques-unes de ces questions :
• Quels sont le type et la version du système d’exploitation requis ? Rappelez-vous notamment qu’Unix n’est pas un standard.
• Quelles sont les applications disponibles compatibles avec cette version du système
d’exploitation ? Si l’éditeur du logiciel que vous voulez acheter n’a pas porté son produit
sur le système d’exploitation que vous utilisez, le logiciel ne fonctionnera pas. Vérifiez
également si ce dernier est compatible avec votre version du SGBDR, avec vos utilitaires
de base de données, avec vos serveurs d’applications, etc.
Facteurs stimulant les performances matérielles
En matière de data warehouse, le débit des disques et de la mémoire sont importants car les
requêtes peuvent solliciter fortement les données. En règle générale, une requête adressée à un
système transactionnel retourne un enregistrement unique issu d’une table optimisée de
manière que l’enregistrement se trouve déjà dans le cache. En revanche, une requête adressée
à un entrepôt de données peut nécessiter l’agrégation de milliers d’enregistrements provenant
de plusieurs tables.
Les disques
Les lecteurs de disques influent fortement sur les performances, la flexibilité et l’évolutivité
d’une plate-forme matérielle. Le prix des serveurs de disques oscille autour de 400 francs le
gigaoctet. Dans les systèmes haut de gamme, les lecteurs sont installés sur un ordinateur autonome ou sur un sous-système dédié à la gestion des accès disque. Ces systèmes sont rapides,
évolutifs et portables (il est possible de les réutiliser sur d’autres serveurs ou avec d’autres
systèmes d’exploitation). On peut les configurer conformément aux standards de sécurisation
du stockage des données RAID (Redundant Array of Inexpensive Disks) 1 ou 5, afin d’optimiser la disponibilité de l’entrepôt de données. Sachez que les bases de données ont besoin de
gros volumes de mémoire temporaire pour effectuer les tris, les jointures et les agrégats. Ce
volume doit résider sur des lecteurs et des contrôleurs performants mais n’a pas besoin d’être
placé en miroir (ce qui reviendrait plus cher). Ces systèmes de lecteurs peuvent être remplacés
à chaud, ce qui réduit la durée d’indisponibilité en cas de problème. La redondance et
l’échange à chaud sont importants dans la mesure où les lecteurs sont les composants les plus
sujets aux pannes. Les sous-systèmes de lecteurs de disques coûtent plus cher mais sont rentables à long terme. Prévoyez au départ assez d’espace disque pour un ou deux ans et gérez
votre expansion en fonction des besoins et des baisses de prix.
La mémoire
Plus un data warehouse dispose de mémoire, mieux c’est ; voici une différence supplémentaire entre l’aide à la décision et le traitement transactionnel. Les requêtes sur les transactions
9
10
Architecture
PARTIE 3
sont généralement peu gourmandes en mémoire. Les requêtes d’aide à la décision sont plus
exigeantes et impliquent souvent plusieurs passes dans des tables volumineuses. Si la
mémoire contient la totalité de la table interrogée, les performances peuvent théoriquement
être multipliées par un facteur compris entre 10 et 100. C’est l’un des gros avantages des
plates-formes 64 bits. Les systèmes 32-bits sont limités à 2 gigaoctets (parfois 4), tandis que
les processeurs 64-bits sont capables d’adresser un espace mémoire plus important. Remarquez au passage que pour que le 64-bits soit effectif, l’ordinateur, son système d’exploitation
et la base de données doivent également être en 64-bits.
ASTUCE
La tentation de favoriser la mémoire au détriment des disques revient régulièrement à l’ordre du jour, en
raison de la différence des temps d’accès. Un accès disque prend environ 10 millisecondes, tandis qu’un
accès mémoire est 100 fois plus rapide (0,1 milliseconde). Cependant, le traitement des données d’une
base en mémoire ne sera pas pour autant 100 fois plus rapide, car de nombreux autres facteurs entrent en
ligne de compte : antélecture de disque et mémoire cache sur le contrôleur ou dans le système d’exploitation. Néanmoins, vous pouvez multiplier les performances d’un entrepôt de données par un facteur compris
entre 10 et 30 en ajoutant simplement de la mémoire à la configuration de la base de données.
Niveau de service attendu
Le type et la puissance du matériel requis dépendent du degré de disponibilité que vous devez
offrir. Si les données doivent être accessibles au monde entier, des machines en parallèle et
une forte redondance des composants seront nécessaires (le problème consistera à trouver des
heures creuses pour effectuer les chargements et la maintenance). La disponibilité du data
mart des données atomiques est décisive dans la mesure où ce data mart contient les données
du niveau de détail 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
données atomiques est le point central du processus de chargement et doit être capable de
transférer des données vers les autres data marts dans un délai relativement court.
Stockage secondaire
Assurez-vous que votre configuration permet la gestion des sauvegardes et de l’archivage. Si
possible, optez pour un système de sauvegarde assez rapide pour effectuer son travail pendant la
durée impartie au chargement. Bien qu’il soit possible de sauvegarder le contenu d’un entrepôt
de données à un moment où les utilisateurs s’en servent, une telle opération risque d’engendrer
une charge importante qui disputera les ressources processeur aux requêtes des utilisateurs.
Autres facteurs
Les environnements serveur Unix et NT sont à ce jour les plates-formes les mieux adaptées aux
entrepôts de données, Unix représentant la meilleure option pour les systèmes de moyenne ou
de grande dimension. Voici quelques avantages des serveurs par rapport aux gros systèmes :
• Un choix d’outils plus étendu. Aujourd’hui, la plupart des nouveaux outils de data warehouse sont d’abord, voire exclusivement, développés pour les serveurs.
• Options de développement des constructeurs de bases de données. La plupart des constructeurs effectuent leurs développements sur un système d’exploitation donné. Il s’agit généralement de la première plate-forme mise en œuvre par la société et de celle sur laquelle le
produit fonctionne le mieux. Après son développement, le produit initial est porté sur d’autres
Infrastructure et métadonnées
CHAPITRE 11
systèmes d’exploitation et sur d’autres versions d’Unix. Bien entendu, il peut être judicieux
d’attendre une nouvelle version ; les premiers acquéreurs font office de cobayes…
ASTUCE
Plus votre plate-forme sera éloignée de celle du produit initial, plus la nouvelle version sera longue à
venir ; de plus, le support spécifique dont vous pourrez bénéficier sera moindre.
• Les serveurs d’applications requièrent des plates-formes Unix ou NT. Certains produits
d’accès aux données sont livrés avec un composant serveur d’applications qui doit obligatoirement s’exécuter sur une plate-forme serveur. Si l’entrepôt de données comporte déjà
des serveurs, les serveurs d’applications peuvent partager la plate-forme existante, ce qui
vous évite d’engager des investissements supplémentaires. L’idée n’est peut-être pas excellente à long terme, mais elle simplifie le démarrage. Nous évoquons également les serveurs
d’applications dans la section de ce chapitre consacrée aux outils frontaux (front room).
• Souplesse. L’environnement serveur est moins sévèrement gardé que le gros système,
notamment si le serveur est dédié à l’entrepôt de données. L’équipe locale pourra accéder
directement à l’entrepôt de données pour tester de nouveaux scénarios, construire de
nouvelles tables, etc., sans dépendre de ressources distantes.
Considérations relatives à la plate-forme de la base de données
Dans le monde du data warehouse, le choix de la plate-forme de la base de données est ultrasensible. Il existe plus d’une dizaine de possibilités ; chacune d’elles offre des exemples
d’implémentations de data warehouses réussies et est défendue par ses supporteurs. En dehors
des produits les plus connus, la plupart des entreprises du secteur des langages de quatrième
génération (L4G) ont des offres de data warehouse. Certains entrepôts sont implémentés à
l’aide de produits gros système, d’autres au moyen de bases de données multidimensionnelles
spécialisées nommées moteurs MOLAP (Multidimensional On-Line Analytical Processing).
Les facteurs qui guident votre décision en matière de matériel s’appliquent également au
choix de la plate-forme de la base de données. Notre expérience nous dit que votre décision
dépend des spécificités de votre situation. Commencez par faire votre choix entre les bases de
données relationnelles et leurs homologues multidimensionnelles.
Base de données relationnelle ou multidimensionnelle ?
D’après les chiffres, le débat principal oppose les bases de données relationnelles aux bases
de données dimensionnelles, les premières menant la danse. Depuis quelques années, le
marché de l’aide à la décision est le théâtre de discussions visant à déterminer l’approche
convenant le mieux au traitement analytique. Le débat est passionné mais apporte malheureusement peu de réponses.
Le problème devient plus facile à appréhender sous l’angle des besoins métier. Les bases de
données multidimensionnelles, également baptisées moteurs MOLAP, sont apparues pour
répondre à trois besoins essentiels des utilisateurs : simplicité de l’accès aux données, états de
type tableau croisé et temps de réponse faibles. Certains ont développé des bases de données
spécialisées parce que les bases de données relationnelles standard et leurs « ancêtres » étaient
incapables de satisfaire ces trois exigences. La majeure partie des produits MOLAP existent
depuis une dizaine d’années. Les sections suivantes mettent en lumière les avantages et les
inconvénients des deux solutions.
11
12
Architecture
PARTIE 3
Caractéristiques des moteurs relationnels
La plupart des constructeurs de bases de données relationnelles ont investi dans le développement d’adaptations spécifiques au data warehouse et offrent aujourd’hui des performances
acceptables. Les principaux constructeurs de SGBDR ont introduit plusieurs nouveautés :
prise en charge du modèle dimensionnel, jointures en étoile, indexation bitmap et optimiseurs
de requêtes plus efficaces. Ces progrès, accompagnés d’avancées technologiques telles que la
sensibilité aux agrégats, ont réduit de manière considérable les différences de performances
entre les produits. Les bases de données relationnelles présentent l’avantage de pouvoir
stocker plus de données au niveau de détail le plus fin. Il est entendu que les systèmes spécialisés dans la résolution de certains problèmes sont avantagés par rapport aux produits plus
généralistes ; il en va de leur survie sur le marché.
ASTUCE
Si vous avez décidé de fonder votre entrepôt de données sur une plate-forme relationnelle et si votre
projet est de faible ou de moyenne envergure, il serait absurde d’envisager des solutions n’appartenant
pas à la tendance générale du marché des SGBDR.
De toute façon, il est extrêmement intéressant de vous renseigner sur les implémentations
existantes et de vous livrer à quelques tests. Identifiez quelques états un peu délicats, comportant notamment des jointures multiples entre plusieurs tables, et voyez ce qu’ils donnent. En
règle générale, les constructeurs mettent à votre disposition des ressources pour vous aider
dans ce processus de test. Profitez des éventuelles expériences internes de sélection de
produits acquises dans le cadre de projets informatiques antérieurs.
ASTUCE
Certaines bases de données relationnelles sont spécialement conçues pour gérer les configurations de
bases de données et les requêtes de type data warehouse. Elles sont plus rapides que les principaux
SGBDR et sont intéressantes (presque obligatoires, en fait) pour les entrepôts de données de grande
envergure.
Caractéristiques des moteurs MOLAP
Les moteurs MOLAP, également nommés systèmes de gestion de bases données multidimensionnelles, sont des systèmes propriétaires conçus pour permettre des analyses très poussées.
Les moteurs MOLAP peuvent constituer d’excellentes plates-formes de data mart pour les
besoins auxquels il est possible de répondre par un schéma en étoile. Le nombre des dimensions et des lignes doit être relativement restreint. Le moteur MOLAP introduit une couche
supplémentaire dans les processus de chargement et d’administration.
ASTUCE
Partant du principe de la présence d’un data mart de données atomiques sur une plate-forme SGBDR,
l’implémentation d’un moteur MOLAP signifie que vous aurez un environnement distinct à administrer et
que celui-ci aura probablement besoin d’un serveur dédié.
Le principal avantage du moteur MOLAP réside dans les performances des requêtes. Les faits
correspondant à toutes les combinaisons de dimensions valides sont préstockés. Les temps de
réponse sont étonnants. En contrepartie, le stockage de tous ces agrégats accroît le volume des
données. Or, le volume de données qu’il est possible de stocker dans une base de données
multidimensionnelle est, pour des raisons historiques, limité à 10 gigaoctets ; les constructeurs font leur possible pour résoudre ces restrictions portant sur le stockage physique. Une
limitation subsiste néanmoins, imposée par la durée nécessaire au chargement de nouvelles
Infrastructure et métadonnées
CHAPITRE 11
données ou à l’actualisation de la base de données. Aujourd’hui, la plupart des utilisateurs ont
autant besoin de données détaillées que d’informations agrégées. Pour répondre à ce besoin,
la faculté de forer directement au niveau du moteur MOLAP a été ajoutée à la plupart des
produits de cette gamme. Leurs aptitudes à gérer les modifications, les calculs complexes et
les sous-totaux, autres avantages non négligeables des moteurs MOLAP, en font des candidats
idéaux pour les systèmes budgétaires et prévisionnels.
L’évaluation des moteurs multidimensionnels ne peut pas être dissociée de celle des outils
d’accès aux données, que nous décrivons en détail au chapitre 13. Certains produits MOLAP
offrent des outils d’interface utilisateur complets ainsi que l’environnement bases de données.
D’autres proposent le moteur MOLAP et un environnement de développement ; dans ce cas,
vous pouvez soit développer les applications utilisateur en interne, soit vous les procurer
auprès d’un fournisseur extérieur.
ASTUCE
Au moment où nous écrivons ces lignes, les fonctionnalités de forage des SGBDR de type SQL via des
moteurs MOLAP peuvent tout au plus être qualifiées de rudimentaires. Ce problème de liaison entre les
moteurs MOLAP et l’environnement relationnel est la raison pour laquelle nous préconisons le stockage
des données détaillées au sein d’un modèle dimensionnel. Si ces deux niveaux représentent des conceptions radicalement différentes, il sera difficile de fournir un accès performant aux données détaillées.
Mettez en concurrence les différents produits MOLAP et confrontez-les aux besoins des utilisateurs en procédant à des tests d’utilisation. Les solutions postes de travail, légères, peuvent
sembler intéressantes à court terme mais risquent de générer, au fil du temps, plus de travail
que de valeur ajoutée. L’équipe chargée du data warehouse doit évaluer avec soin les limitations et les fonctionnalités des produits. L’évolutivité doit être privilégiée.
ASTUCE
Sur le plan de l’évolutivité, l’inconvénient majeur des produits MOLAP réside actuellement dans la limitation du volume des données en entrée pour la table des faits principale et du nombre de lignes dans les
dimensions. Début 1998, ces limitations tournaient autour de 5 gigaoctets de données en entrée et de
300 000 lignes dans la dimension la plus importante.
Le problème de la multiplicité des constructeurs et des produits tend à s’estomper à mesure
que les constructeurs de SGBDR incorporent des fonctionnalités MOLAP à leurs logiciels.
Les implémentations deviennent hybrides, mais cette intégration n’entraîne pas systématiquement une baisse des prix ; le budget disponible reste donc un facteur à part entière du choix
entre SGBDR et MOLAP.
Infrastructure des outils frontaux (front room)
L’infrastructure des outils frontaux (front room) dépend plus fortement de l’activité et des
outils que celle des outils d’arrière-plan (back room) et les choix à faire y sont plus nombreux.
Commençons par quelques considérations générales.
Serveur d’applications
Du côté des outils frontaux (front room), les serveurs d’applications tendent à proliférer à
toute vitesse. Les uns gèrent l’accès aux données via le Web, les autres gèrent les requêtes, les
états standard, l’authentification, les bases de données de métadonnées, etc. Apporter des
informations intéressantes et des conseils en ce domaine n’est pas simple, car les produits sont
13
14
Architecture
PARTIE 3
très nombreux et très différents. La meilleure tactique consiste à interroger très tôt les constructeurs sur les détails de leurs configurations. Voici quelques questions clés à poser :
• Mémoire. Combien de mémoire faut-il prévoir ? Quel est le temps de formation nécessaire
à une utilisation efficace ?
• Disque. Quels facteurs déterminent l’utilisation du disque ? Quelle capacité faut-il envisager ?
• Partage de plate-forme. Est-il possible d’exécuter plusieurs services sur la même plateforme matérielle ? Dans ce cas, comment se comportent les performances ? Quels sont les
compromis à envisager ? Certains produits ont-ils une compatibilité réduite ?
• Goulets d’étranglement. À quoi les goulets d’étranglement du système sont-ils dus ? À
quoi les ralentissements du système sont-ils dus ? Le produit est-il réellement multithread ?
Peut-il vraiment exécuter plusieurs processus simultanément ? Quels seraient les avantages
de l’installation de plusieurs processeurs ? Combien d’utilisateurs simultanés le produit
peut-il gérer ?
Poste de travail
La puissance du poste de travail dépend de son utilisateur et de ses besoins en matière d’outils.
L’utilisateur occasionnel qui se contente de quelques états HTML qu’il consulte à partir de
son navigateur favori sera satisfait si on lui fournit assez de puissance pour lancer son navigateur Web. À l’autre extrême, l’utilisateur aguerri qui construit des requêtes complexes et lance
des analyses personnalisées devra être équipé d’un 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 ; d’autres sociétés utilisent des stations de travail Unix pour les études et pour la
production. Le support de plates-formes multiples entraîne une lourde tâche pour l’équipe
chargée des outils frontaux. Les problèmes d’installation et de support varient d’une plateforme à l’autre et l’équipe doit être compétente dans tous les domaines. D’autre part, les
problèmes ne prennent pas fin une fois que les logiciels sont installés. Il est souvent nécessaire
de créer les états sur chaque plate-forme, ce qui peut multiplier par deux le travail de développement et de maintenance. Les concepteurs d’outils frontaux sont peu nombreux à supporter
d’autres plates-formes que le duo Windows/Intel. Si vous êtes obligé de supporter plusieurs
plates-formes poste de travail, le processus de sélection des outils d’accès aux données s’en
trouvera simplifié.
Système d’exploitation du poste de travail
Même si tous les utilisateurs emploient la même base matérielle, cela ne signifie pas que tous
seront compatibles avec les logiciels client car la version du système d’exploitation peut être
inadapté. Renseignez-vous sur la version du système d’exploitation requise par vos outils et
vérifiez qu’elle correspond bien à la réalité.
ASTUCE
Dans le monde Windows, si vos utilisateurs ne disposent pas de Windows 95 et versions ultérieures ou de
NT 4 et versions ultérieures, vous pouvez vous attendre à des problèmes.
Infrastructure et métadonnées
CHAPITRE 11
Distribution des logiciels
Ce problème est insidieux : il s’installe lentement et sans faire de bruit puis, un beau jour, vous
saute d’un seul coup à la figure. L’installation des premiers groupes d’utilisateurs est aisée.
Vous les connaissez, car ils ont participé aux réunions du processus de conception ; ils sont
impatients de commencer à travailler sur les nouveaux produits. Puis d’autres personnes
demandent à accéder au data warehouse, bientôt rejoints par des utilisateurs géographiquement
distants, et vous finissez par vous retrouver en train de gérer plusieurs centaines de copies des
logiciels destinés aux poste de travail, réparties aux quatre coins de l’entreprise. C’est 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 précédente version n’est
pas garantie ; une mise à jour de l’ensemble des postes de travail du parc vous attend…
Outils Web
L’indépendance des plates-formes et la facilité de diffusion sont des attraits majeurs du Web
et des technologies connexes. Or, ces avantages ne sont effectifs qu’en théorie et se limitent à
l’accès aux états simples. La présence du poste de travail est indispensable aux analyses ad
hoc. Il est pourtant possible de faire de l’analyse ad hoc au moyen d’une grosse applet ; chez
Metaphor, nous avons même développé des applications complexes sur un réseau d’ordinateurs dépourvus de disque dur dès 1984. Mais les fournisseurs d’outils ont mis des années à
développer le volume de code actuel et n’ont aucun moyen de le porter (et l’infrastructure de
développement n’est pas encore assez robuste). Les nouveaux venus qui proposent une offre
d’outils Web ne sont entravés par aucun passif, mais ils n’ont pas encore eu le temps de développer un outil puissant et manquent d’expérience. Ils devront d’abord franchir plusieurs
étapes, à l’instar de la génération qui les a précédés.
Mémoire
Vous ne serez pas étonné d’apprendre que la mémoire a une forte incidence sur les performances des postes de travail. Nous avons eu l’occasion de travailler pour une entreprise qui
avait consacré beaucoup de temps et d’énergie à rechercher la cause d’un problème du côté du
réseau alors que le goulet d’étranglement était dû à une capacité mémoire insuffisante sur les
postes de travail. Ceux-ci passaient le plus clair de leur temps à paginer les données et les
programmes dans la mémoire virtuelle.
Conclusion sur le poste de travail
Choisissez une plate-forme standard et déterminez la configuration minimale pour implémenter votre série d’outils de manière réactive ; elle doit être suffisamment riche pour être efficace. Par ailleurs, prévoyez une configuration plus puissante réservée 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, l’utilité de ce dernier) en vue
d’économiser quelques milliers de francs sur l’achat des ordinateurs.
D’autre part, nous recommandons de prévoir un poste par utilisateur ; la baisse des prix le
permet. Les stations partagées ne sont pas très fonctionnelles car elles font augmenter le coût
perçu de l’utilisation de l’entrepôt pour l’analyste. Si celui-ci doit se lever de son siège,
s’installer près du poste de travail partagé, y lancer quelques requêtes puis revenir chercher les
résultats un peu plus tard, il aura probablement du mal à s’y mettre.
15
16
Architecture
PARTIE 3
Connectivité et réseau
La connectivité et le réseau relient les outils d’arrière-plan (back room) et les outils frontaux
(front room). En règle générale, la connectivité est un composant de l’infrastructure. Étant
donné qu’elle constitue un prérequis à la mise en œuvre de n’importe quel application clientserveur, le travail préparatoire est généralement déjà terminé. La plupart des entreprises
possèdent un réseau local (LAN) ou un groupe de réseaux locaux interconnectés, ainsi qu’une
équipe chargée de les faire fonctionner. Si ce n’est pas le cas dans votre société, il est urgent
de mettre en place un groupe de travail afin d’évaluer les besoins. Plusieurs autres problèmes
de connectivité que vous risquez de rencontrer sont énumérés ci-dessous.
Bande passante
Il est souvent judicieux d’isoler la base de données et les serveurs d’applications sur un réseau
local à haut débit dédié (Ethernet ou FDDI à 100 Mo/s). Cette configuration procure la bande
passante nécessaire au transfert de gros volumes de données avec des performances optimales.
Accès à distance
Si vous avez affaire à des utilisateurs distants, il est entendu que ceux-ci devront pouvoir
accéder à l’entrepôt de la même manière que les utilisateurs locaux. Prévoyez à cet effet une
connexion à large bande passante, fiable, entre le réseau local des utilisateurs distants et celui
qui héberge la base de données et les serveurs d’applications.
La bande passante prend de l’importance en raison de la mutation des outils frontaux. De
nombreux outils permettent à présent de définir un sous-ensemble de données particulièrement
intéressant, de le récupérer et de l’analyser en local. Une telle opération représente un flux de
données descendant assez considérable. Après avoir évalué les besoins, contactez l’équipe
réseau afin de déterminer si la bande passante prévue pour ces connexions est suffisante.
Si vos utilisateurs distants ne sont pas regroupés en réseau local, vous devrez mettre en place
un accès par les lignes téléphoniques. Effectuez des tests de performances poussés et lisez
attentivement le chapitre 12, qui traite de la sécurité.
Passerelles
La plupart des constructeurs de bases de données proposent des passerelles, qui permettent
d’établir des liens avec les bases de données concurrentes et avec les sources de données de
production. La mise en œuvre d’une passerelle sera par exemple très utile pour accéder aux
données localisées dans d’autres base de données de l’entrepôt. Certains middleware offrent
également ce type de connectivité et y ajoutent la possibilité de combiner les données en
provenance de plusieurs sources au moyen de jointures hétérogènes. Ces passerelles ont
tendance à être assez lentes ; elles rendent particulièrement service dans le cadre des importations batch et de recherches dans les petites tables. Faites des tests grandeur nature pour vérifier
qu’elles ne s’effondrent pas.
Transfert de fichiers
Il existe un large éventail de protocoles de transfert de fichiers et de programmes chargés de
les implémenter. Le principal est le protocole FTP (File Transfer Protocol), qui est un utilitaire de transfert de données universel. FTP remonte aux débuts de l’Internet ; il offre des
services de transfert de fichiers entre les ordinateurs reliés à l’Internet, quel que soit leur type.
Infrastructure et métadonnées
CHAPITRE 11
Ses fonctionnalités de base sont l’établissement des connexions entre ordinateurs et le transfert de fichiers séquentiels via cette connexion. L’un des protocoles les plus récents, SSL
(Secure Sockets Layer), émane de Netscape. Il présente l’avantage d’inclure une fonction de
cryptage des données transmises, qui permet de sécuriser les informations sensibles. SSL est
très largement implanté dans le monde Unix, dans lequel il sécurise les transactions entre les
navigateurs Web et les serveurs. SSL a été soumis à l’IETS (Internet Engineering Task Force)
afin qu’il soit déclaré protocole standard.
Connectivité des bases de données
La connectivité des bases de données fait généralement partie de l’offre des outils frontaux.
La plupart des fournisseurs proposent plusieurs possibilités de connexion, dont, pour presque
toutes les bases de données, le mode natif. Il existe toutefois quelques standards en matière de
connectivité de base de données, notamment ODBC (Open Database Connectivity), originellement développé par Microsoft, et JDBC (Java Database Connectivity), initialement conçu
par JavaSoft. ODBC est une méthode standard d’accès aux bases de données qui permet
d’accéder à n’importe quel type de base de données depuis n’importe quelle application.
ODBC insère une couche chargée de traduire les requêtes en provenance de l’application en
commandes compréhensibles par la base de données. Historiquement, ODBC est devenu un
pilote de connectivité de second ordre parce que beaucoup d’implémentations spécifiques
n’ont pas donné d’aussi bons résultats que l’utilisation du mode natif. Toutefois, des pilotes
plus puissants existent aujourd’hui et la popularité d’ODBC augmente. JDBC a profité de
l’évolution d’ODBC et est de plus en plus employé.
Entre-temps, le marché évolue. Microsoft a créé une nouvelle série de standards de connectivité sous le sigle OLE DB, qui promettent d’améliorer encore la connectivité des bases de
données.
Service d’annuaire
Votre infrastructure de réseau doit prévoir des fonctionnalités destinées à attribuer des noms
aux hôtes et à assurer l’indépendance des adresses. Au départ, l’Internet et/ou les intranets
dépendent d’un DNS (Domain Name Service), qui recherche un nom dans une liste et
retourne l’adresse IP (Internet Protocol) correspondante. Cela vous permet d’assigner un nom
à l’adresse IP de votre serveur de base de données et de configurer vos outils frontaux de
manière qu’ils se servent de ce nom. Le nom du serveur est ensuite dynamiquement converti
en adresse IP, celle de l’ordinateur où réside la base de données. Si vous déplacez la base sur
un autre ordinateur, il suffit de modifier l’entrée 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 envoyée au site concerné.
Il existe des services d’annuaire plus complexes : les annuaires X.500 ou LDAP (Lightweight
Directory Access Protocol). Ils hébergent des informations bien plus riches que les simples
adresses IP. Ils peuvent concerner plusieurs types de données : noms et adresses, adresses email, listes téléphoniques et annuaires de matériel (imprimante, ordinateur, etc.). Ces
annuaires peuvent servir de liste d’inventaire pour le recensement des serveurs, d’annuaire des
utilisateurs pour la mise à disposition des données, de listes de diffusion pour les états standard, etc. Dans le chapitre 12, nous vous incitons à centraliser l’administration de votre configuration (« logons », etc.) au moyen d’un serveur d’annuaire LDAP.
17
18
Architecture
PARTIE 3
Conclusion sur l’infrastructure
Comme nous l’avons vu, l’infrastructure du data warehouse regroupe plusieurs composants :
plate-forme matérielle, connectivité et réseau, poste de travail. Dans chacun de ces trois
domaines, il est nécessaire comprendre les besoins métier et de mettre en adéquation la réponse
à ces besoins. Heureusement, la portée de l’infrastructure s’étend bien au-delà de l’entrepôt de
données. Les nouveaux systèmes opérationnels client-serveur ont des besoins en infrastructure
similaires à ceux des data warehouses ; en conséquence, dans la plupart des cas l’entrepôt de
données peut s’appuyer sur l’infrastructure existante. Cela dit, les questions d’infrastructure sont
très sensibles ; vos décisions se retourneront contre vous si vous avez fait le mauvais choix.
Métadonnées et catalogue des métadonnées
Les métadonnées sont un vaste champ de bataille terminologique. Dans cette section, nous
allons décrire les métadonnées afin de vous aider à les identifier lorsque vous en rencontrerez.
Nous illustrerons par un exemple le rôle de soutien que les métadonnées jouent au sein d’un
entrepôt de données. Enfin, nous décrirons le concept de catalogue de métadonnées et ferons
quelques suggestions relatives au suivi des métadonnées.
Métadonnées : qu’est-ce que c’est ?
Les métadonnées 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 inquiéter et à nous sentir coupable de ne pas nous en
occuper suffisamment. Il y a quelques années, on a décrété que les métadonnées désignaient
les données relatives aux données. Cette définition imprécise ne nous a pas beaucoup aidés.
La notion s’est cependant peu à peu clarifiée et il est même question, depuis quelque temps,
de « métadonnées de la zone de construction (back room) » et des « métadonnées des outils
frontaux (front room) ». Les métadonnées des outils d’arrière-plan (back room) sont
procédurales ; elles guident les processus d’extraction, de nettoyage et de chargement. Les
métadonnées des outils frontaux (front room) sont plus descriptives et aident les outils de
requête et les générateurs d’états à fonctionner du mieux possible. Bien entendu, les métadonnées procédurales et les métadonnées descriptives se recoupent, mais le fait de les distinguer
ainsi peut aider à mieux les comprendre.
Les métadonnées de la zone de construction (back room) sont censées aider l’administrateur
de la base de données à alimenter l’entrepôt ; elles sont également susceptibles d’intéresser les
utilisateurs qui souhaitent connaître la provenance des informations. Les métadonnées des
outils frontaux (front room) bénéficient essentiellement à l’utilisateur final ; elles ne se
contentent pas de mettre de l’huile dans les rouages des outils : elles constituent aussi une
sorte de dictionnaire de l’activité.
Cependant, ces deux définitions, aussi intéressantes soient-elles, ne donnent pas à l’administrateur de l’entrepôt de données une idée précise de l’intérêt des métadonnées. Essayons donc
de considérer ces dernières selon une perspective de traitement de l’information classique.
Nous devrons :
• élaborer une liste détaillée de toutes les métadonnées ;
• déterminer l’importance de chaque élément ;
• désigner le responsable des métadonnées ;
Infrastructure et métadonnées
CHAPITRE 11
• déterminer un ensemble opérationnel et cohérent de métadonnées ;
• décider s’il convient de développer les outils d’exploitation des métadonnées en interne ou
d’en acheter ;
• stocker les métadonnées dans un emplacement spécifique à des fins de sauvegarde et de
restauration ;
• les mettre à la disposition des personnes qui en ont besoin ;
• veiller à leur qualité, s’assurer qu’elles sont complètes et à jour ;
• les gérer de manière centralisée ;
• décrire toutes ces tâches assez précisément en vue de pouvoir les déléguer.
Un problème subsiste : nous n’avons pas encore vraiment expliqué ce qu’est une métadonnée… Remarquez que le dernier point de la liste ci-dessus n’est pas une métadonnée, mais
une information relative aux métadonnées. Serons-nous amenés à faire appel à des métamétadonnées ? Pour y voir plus clair, élaborons une liste de tous les types de métadonnées
possibles. Celle-ci ne sera peut-être pas exhaustive du premier coup mais nous en apprendra
certainement beaucoup.
Métadonnées des systèmes source
Revenons tout d’abord aux systèmes source : gros systèmes, serveurs autonomes, postes de
travail, fournisseurs de données externes et même Internet. Nous supposerons ici que nous
nous contentons de lire les données source et de les déposer dans la zone de préparation des
données, qui peut se situer sur le site central ou sur un ordinateur en aval.
Structures des sources
• Bibliothèques ;
• schémas des sources ;
• description de structures de données sous la forme de programmes (copy book cobol par
exemple) ;
• schémas de bases propriétaires ou issues de tiers ;
• structure des fichiers des files d’attente d’impression ;
• anciens formats des données gros système archivées ;
• tables et DDL des systèmes source relationnels ;
• feuilles de calcul ;
• bases de données Lotus Notes ;
• graphiques de présentation (Power Point, par exemple) ;
• spécifications des URL (Universal Resource Locator) sources.
Informations descriptives des sources
• Description du responsable de chaque source ;
• description métier de chaque source ;
• fréquence des mises à jour ;
• limitations juridiques à l’exploitation de chaque source ;
• méthodes d’accès, droits d’accès, privilèges et mots de passe associés aux accès aux sources.
19
20
Architecture
PARTIE 3
Information sur les processus
• Plannings des tâches gros système ou du système source ;
• langage d’implémentation de l’extraction : Cobol et JCL, C, Basic, etc. ;
• paramètres des outils d’extraction automatisée (le cas échéant) ;
• résultats de tâches d’extraction, notamment heure exacte, contenu et état d’achèvement.
Métadonnées de la zone de préparation des données
Élaborons maintenant la liste des métadonnées requises pour placer les données dans la zone
de préparation et pour préparer leur chargement dans un ou plusieurs data marts. L’opération
peut être accomplie sur le site central au moyen d’un programme Cobol développé à cet effet
ou à l’aide d’un outil d’extraction automatisée. Il est également possible de stocker les fichiers
séquentiels extraits sans y toucher dans une zone de préparation des données autonome, sur
un ordinateur distinct. En tout cas, nous devons nous préoccuper des métadonnées, notamment des points décrits ci-après.
Information sur l’acquisition des données
• Planification de la transmission des données et résultat de transmissions ;
• utilisation des fichiers au sein de la zone de préparation des données : durée, volatilité et
responsable.
Gestion des tables dimensionnelles
• Définition des dimensions conformes et des faits conformes ;
• spécification des tâches pour les opérations de jointures, d’élimination de champs et de
recherche d’attributs ;
• règles à appliquer aux nouveaux attributs descriptif dans les dimensions changeantes (écrasement, création d’un nouvel enregistrement, création d’un nouveau champ) ;
• attribution d’une clé de substitution à chaque clé de production, prévoyant notamment une
table de correspondance performante pour effectuer cette mise en relation en mémoire ;
• une copie des dimensions de production datant de la veille, à utiliser comme base de DIFF
COMPARE.
Transformation et agrégation
• Spécification du nettoyage des données ;
• optimisation des données et transformations par rapprochement (par exemple, développement des abréviations et ajout de détails) ;
• transformations nécessaires au data mining (par exemple, interprétation des valeurs nulles
et détermination des plages numériques) ;
• schéma cible, flux entre les données source et cible, responsable des données cible ;
• scripts de chargement du SGBD ;
• définitions des agrégats ;
• statistiques d’utilisation des agrégats, statistiques d’utilisation des tables de base et agrégats
possibles ;
Infrastructure et métadonnées
CHAPITRE 11
• journaux des modifications d’agrégats.
Audit, journaux des tâches et documentation
• Traçabilité des données et audit des enregistrements (d’où provient exactement cet enregistrement et de quand date-t-il ?) ;
• journaux d’exécution des transformations des données, synthèse des résultats et heures des
exécution ;
• numéros de versions des logiciels de transformation des données ;
• descriptions métier du processus d’extraction ;
• mesures de sécurité associées à l’extraction des fichiers, aux logiciels d’extraction et aux
métadonnées d’extraction ;
• mesures de sécurité associées à la transmission des données (mots de passe, certificats) ;
• journaux d’archivage de la zone de préparation des données et procédures de restauration ;
• mesures de sécurité associées à l’archivage de la préparation des données.
Métadonnées SGBD
Après avoir transféré les données dans le SGBD du data warehouse ou du data mart, un autre
groupe de métadonnées entre en scène :
• contenu des tables du SGBD ;
• paramètres de partitionnement ;
• index ;
• spécifications de répartition des données sur plusieurs disques ;
• priorités de traitement
• droits et privilèges d’accès au SGBD ;
• définition des vues ;
• procédures stockées et scripts d’administration SQL ;
• état des sauvegardes du SGBD, procédures de sauvegarde et sécurité des sauvegarde.
Métadonnées des outils frontaux (front room)
Du côté des outils frontaux (front room), les métadonnées se multiplient à l’infini :
• noms et descriptions utilisateur des colonnes, des tables et des regroupements ;
• définitions des requêtes et des états prédéfinis ;
• paramètres des outils de spécification des jointures ;
• spécification des outils d’impression (attribution de noms clairs aux champs) ;
• documentation destinée à l’utilisateur et support de formation (élaboré à la fois par le constructeur et le service informatique) ;
• profils des privilèges utilisateur dans la sécurité réseau ;
• certificats d’authentification de la sécurité réseau ;
21
22
Architecture
PARTIE 3
• statistiques d’utilisation relatives à la sécurité réseau : tentatives de connexions, tentatives
d’accès et état des ID utilisateur par localisation ;
• profils utilisateur individuels reliés aux ressources humaines pour le suivi des événements
qui affectent les droits d’accès (promotions, transferts, démissions) ;
• liaisons avec les sous-traitants et les partenaires impliquant des droits d’accès ;
• tableau de l’utilisation et des accès aux données, tables, vues et états ;
• statistiques pour la refacturation des ressources ;
• sites Web favoris (un paradigme de l’accès pour tous les data warehouse).
Vous comprenez maintenant pourquoi nous ne savions pas exactement ce que représentaient
les métadonnées ! Elles englobent tout, sauf les données elles-mêmes, et les données semblent
soudain être la composante la plus simple de l’ensemble. Les métadonnées sont en quelque
sorte l’ADN du data warehouse. Elles décrivent les éléments et la façon dont ils coopèrent.
Alors que cette liste vous a présenté les métadonnées sous un angle descriptif ; nous allons à
présent les observer en pleine action.
Exemple de métadonnées dynamiques
La tâche qui consiste à collecter et à maintenir les métadonnées n’est pas une fin en soi. Les
métadonnées sont au data warehouse ce que la documentation est aux systèmes traditionnels ; du
coup, on a facilement tendance à les délaisser au profit de projets plus urgents. Les métadonnées
dynamiques tentent de résoudre ce problème. Ces métadonnées pilotent les processus ; ce
faisant, elles produisent de la documentation, qui est en fait une sorte d’effet secondaire fortuit.
Étudions le fonctionnement de ce processus en parcourant le graphique d’un flux des métadonnées simple. Vous avez d’abord besoin d’un modèle de données du data warehouse.
L’opération est techniquement simple si vous recourez à un outil de modélisation standard. La
plupart de ces outils sont fonctionnels en amont et en aval ; vous pouvez donc les utiliser pour
extraire les métadonnées des bases de données existantes. Créez des modèles logiques et
physiques incluant les noms logiques (métier) des colonnes, leur nom physique, leur description métier, des exemples de valeurs et des astuces de requêtes. Une fois votre modèle construit, enregistrez-le dans la base de données relationnelle prévue dans l’outil pour le stockage
des métadonnées. L’étape 1, figure 11.3, illustre ce processus.
Ajoutez ensuite quelques métadonnées de préparation des données (data staging) à ce flux. Les
modèles de data warehouse élaborés à l’étape 1 apportent les informations nécessaires à l’identification des cibles du processus de préparation. L’outil de préparation des données doit également connaître les sources. L’étape 2 consiste donc à capturer les définitions des sources.
Comme nous l’avons déjà précisé, il peut aussi bien s’agir, par exemple, de fichiers séquentiels
que de bases de données sur gros système. Généralement, l’outil de préparation des données
dispose d’un moyen intégré de capturer ces informations, dont il a impérativement besoin. Lors
de l’étape 3, nous utilisons l’outil de préparation pour injecter les définitions 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 préparation. Si vous disposez d’un bon outil de préparation, celui-ci potentialisera
les métadonnées que vous avez déjà créées au niveau des tables cibles lors de l’étape 1.
Enfin, lors de l’étape 4, nous allons enregistrer tout cela dans le modèle de stockage ouvert
relationnel de l’outil de préparation des données. La figure 11.4 illustre cette opération.
Infrastructure et métadonnées
CHAPITRE 11
Figure 11.3
Capture des modèles
de données de l’entrepôt.
Outil de
modélisation
(1) Modèle de
l’entrepôt
Catalogue des métadonnées
Modèle
physique
Modèle
logique
Figure 11.4
Capture de la définition
des sources et rapprochement avec les cibles.
Outil de
modélisation
(1) Modèle de
l’entrepôt
Catalogue des métadonnées
Modèle
physique
(2) Définitions
des sources
Modèle
logique
Définitions
des sources
Rapprochements
source/cible
(3) Définitions
des tables
Systèmes
source
(4) Rapprochements
source/cible
Outil de
préparation
des
données
23
24
Architecture
PARTIE 3
Notez que le processus de création de ces rapprochements, à l’étape 3, consiste essentiellement à définir des relations entre des métadonnées existantes. Le plus gros du travail a été
accompli lors de la construction du modèle de données ; nous pouvons mettre en place autant
de rapprochements que nous le souhaitons et les stocker dans le catalogue des métadonnées.
Lorsque toutes ces définitions sont complètes, nous pouvons commencer à charger les
données, comme le montre la figure 11.5. Au cours de l’étape 5, l’outil de préparation des
données interroge les métadonnées afin de récupérer les informations requises : type et
localisation des données source, type et localisation des données cible, rapprochements
entre les deux.
Figure 11.5
Étapes 5 à 8 :
extraction, transformation et chargement.
Outil de
modélisation
(1) Modèle de
l’entrepôt
Catalogue des métadonnées
Modèle
physique
(2) Définitions
des sources
Modèle
logique
Définitions
des sources
Rapprochements
source/cible
(3) Définitions des tables
(5) Informations de
rapprochement et
de transformation
Systèmes
source
(6) Données extraites
(4) Rapprochements source/cible
(8) Statistiques de chargement
Outil de
préparation
des
données
(7) Données transformées
(5a) Informations physiques
(tablespaces, etc.)
Data
warehouse
Infrastructure et métadonnées
CHAPITRE 11
Nous pouvons également interroger la base de données cible au cours de l’étape 5a pour récupérer des informations sur l’état physique du système, notamment sur l’espace disque disponible. Au cours de l’étape 6, nous procédons à l’extraction proprement dite des sources de
données brutes et dans l’étape 7, nous chargeons les données transformées dans l’entrepôt.
L’étape 8 capture des statistiques et des informations de surveillance relatives à la charge et
les enregistre dans le catalogue des métadonnées.
Nous avons donc réussi à charger des données ; les utilisateurs brûlent d’impatience de les
exploiter, mais il faudrait qu’ils disposent d’indications sur leur contenu. Heureusement,
l’ensemble des informations de l’entrepôt est décrit dans le modèle des données. Tout y est :
nom des colonnes et des tables, descriptions et exemples de valeurs. Toutefois, avant d’ouvrir
grand les portes, il convient de donner à l’entrepôt un abord plus « métier ». Une liste des
tables et des colonnes classées par ordre alphabétique ne suffira pas, car l’utilisateur raisonne
en types d’activités et non par ordre alphabétique… Les regroupements à opérer découlent de
la table des faits. Les outils frontaux et les serveurs d’applications permettent habituellement
de générer ces métadonnées.
Les métadonnées utilisateur sont maintenant prêtes ; l’étape 9 montre l’intérêt d’un outil Web
destiné à exploiter les métadonnées. L’utilisateur peut consulter les types d’activités, identifier
les tables qui appartiennent à tel ou tel type d’activité et même consulter leur contenu. En
outre, à l’aide d’un simple outil de recherche, l’utilisateur 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 données qu’ils recherchent, ils peuvent formuler une
requête et la soumettre à la base de données (étape 10). Remarquez au passage que la requête
s’appuie aussi sur les descriptions physiques des tables et des colonnes, récupérées à l’étape 9,
pour générer la syntaxe correcte. L’étape 11 envoie le résultat à l’utilisateur ; l’étape 12 est
prise en charge par un bon outil de requête capable de générer un certain nombre d’informations relatives à l’utilisation.
Cette progression illustre le rôle central du catalogue des métadonnées dans le contexte d’un
entrepôt de données simple. Vous remarquerez par ailleurs que sur les douze étapes décrites,
seulement trois impliquent les données ; toutes les autres concernent les métadonnées. Remarquez également que, dans certains cas, des composants d’une seule et même métadonnée
apparaissent en différents endroits. Par exemple, le modèle que nous avons créé dans l’étape 1
contient les définitions des tables physiques. L’outil d’accès aux données s’en sert lors du
rapprochement source/cible puis, plus tard, pour transformer et charger les données. Enfin,
l’outil de requête et le serveur d’applications ont besoin de connaître les définitions des tables
physiques pour formuler de bonnes requêtes.
La liste des métadonnées et l’exemple de flux ont finalement réussi à vous donner une vue
d’ensemble de ces fameuses métadonnées. Mais est-il vraiment nécessaire de suivre un tel
cheminement ? Nous pensons que oui. Cette liste de métadonnées est la charpente de votre
entrepôt de données. Le simple fait d’en élaborer la liste apporte une aide. La liste est longue,
mais elle permet d’identifier le type, l’intérêt et le lieu de stockage de chaque métadonnée.
La modération est toutefois de mise. En effet, la plupart de ces métadonnées doivent résider
sur des ordinateurs situés près des lieux où les tâches se déroulent. Les programmes, les paramètres et les spécifications qui pilotent les processus doivent connaître des destinations
certaines et des formats certains, et cela ne va pas changer dans les prochains temps.
25
26
Architecture
PARTIE 3
Outil de
modélisation
(1) Modèle de
l’entrepôt
Catalogue des métadonnées
Modèle
physique
(2) Définitions
des sources
Modèle
logique
Définitions
des sources
Rapprochements
source/cible
(3) Définitions des tables
(12) Statistiques d’utilisation
des requêtes
(9) Descriptions
métier (noms
et contenu
des tables et
des colonnes,
exemples de
valeurs, etc.)
(4) Rapprochements
source/cible
(5) Informations de
rapprochement et
de transformation
Systèmes
source
(6) Données extraites
(8) Statistiques de
chargement
Outil de
préparation
des
données
(7) Données transformées
Outils
frontaux
(5a) Informations physiques
(tablespaces, etc.)
(10) États, requêtes
(11) Données
Data
warehouse
Figure 11.6
Rôle des métadonnées dans le pilotage des outils frontaux.
Maintenance du catalogue des métadonnées
Les termes bibliothèque d’information, référentiel, dictionnaire de métadonnées et métabase
de données sont, parmi d’autres, utilisés pour décrire le catalogue des métadonnées. Nous
avons choisi le terme catalogue des métadonnées pour décrire l’ensemble des métadonnées
présentes dans l’entrepôt. Idéalement, ce catalogue devrait être le lieu de stockage unique des
informations qui pilotent des processus dans l’entrepôt. Toutes les procédures internes de
Infrastructure et métadonnées
CHAPITRE 11
l’entrepôt, du modèle initial à la navigation et à l’accès aux données en passant par les extractions récurrentes et les processus de chargement, devraient faire appel au catalogue des métadonnées. Malheureusement, une mise en œuvre aussi parfaite est impossible à l’heure
actuelle ; nous considérerons donc le catalogue des métadonnées comme un concept logique
réparti dans plusieurs emplacements physiques.
ASTUCE
Procurez-vous un outil pour cataloguer et suivre toutes ces métadonnées. Il ne sera probablement pas
capable de lire et d’écrire toutes les métadonnées directement mais, étant donné leur éparpillement, il
vous aidera au moins à gérer.
Il existe heureusement une catégorie d’outils, judicieusement nommés outils pour catalogues
de métadonnées, qui se consacrent à cette tâche. Le site Web de Larry Greenfield en fournit
une liste intéressante à l’adresse http :/pwp.starnetinc.com/larry/catalog.html.
L’équipe du data warehouse doit envisager l’acquisition d’outils de maintenance en vue
d’administrer les métadonnées du catalogue non gérées par les outils et les services en place.
Par exemple, les commentaires saisis par les utilisateurs, les hiérarchies personnalisées ou les
spécifications qui accompagnent les data marts personnels peuvent ne pas être pris en charge
par les produits existants et nécessiter la mise en place d’un service spécifique.
Dans l’environnement du catalogue des métadonnées, une autre fonctionnalité pourra être
mise en œuvre afin de créer des RPC (Remote Procedure Calls), qui procureront aux systèmes
source et aux outils de navigation un accès direct aux métadonnées.
Enfin, les services de préparation et d’accès aux données doivent être en mesure d’exploiter
les métadonnées relatives à la sécurité. Celles-ci doivent être développées et maintenues au
moyen d’un outil ou d’une fonction quelconque. Il s’agit d’ajouter et de supprimer des utilisateurs et des groupes d’utilisateurs, d’assigner des droits d’accès à ces utilisateurs et à ces
groupes, etc. Ces métadonnées doivent également être intégrées aux tables de sécurité de la
plate-forme de la base de données (encore des métadonnées !).
La maintenance du catalogue des métadonnées implique un certain nombre de fonctions et de
services :
• intégration et fusion des informations du catalogue (depuis le modèle de données vers la
base de données, puis vers les outils frontaux) ;
• administration des métadonnées (suppression des entrées inutilisées ou obsolètes) ;
• capture des métadonnées existantes (DDL du gros système ou autres sources) ;
• gestion et présentation de graphiques et de tableaux illustrant le contenu du catalogue des
métadonnées (le navigateur de métadonnées) ;
• maintenance des profils utilisateur au profit des applications et de la sécurité ;
• sécurité du catalogue des métadonnées ;
• gestion locale ou centralisée du catalogue des métadonnées.
Ayant pris les premières dispositions pour regrouper et contrôler nos métadonnées, pouvonsnous espérer nous tourner vers des outils encore plus puissants qui rassembleront les métadonnées en un lieu unique et qui seront capables de les lire et de les écrire ? Ce type d’outil nous
apporterait une interface utilisateur uniformisée, appréciable dans un cadre aussi disparate, et
nous permettrait en outre de prendre des instantanés cohérents de toutes les métadonnées d’un
seul coup (puis de les sauvegarder, de les sécuriser et de les restaurer en cas de besoin).
27
28
Architecture
PARTIE 3
À notre avis, ce type d’outil n’est pas près d’inonder le marché. Le problème est très
complexe ; la prise en compte de toutes les formes de métadonnées requiert un type d’intégration entre les systèmes qui n’existe pas encore. Nous sommes convaincus que la Metadata
Coalition (un groupe de constructeurs qui s’est attelé à la résolution du problème des métadonnées) réalisera des progrès intéressants dans la définition d’une syntaxe et d’une sémantiques communes pour les métadonnées. Signalons toutefois que ce groupe a vu le jour en
1995… Malheureusement, Oracle et Microsoft, qui sont les deux grands du SGBD, ont décidé
de ne pas s’associer à cette initiative et ont fait la promesse de publier leurs propres standards
de métadonnées propriétaires. Si les avantages de ces standards sont assez importants pour
attirer d’autres fournisseurs, nous pouvons espérer que le problème des métadonnées sera
résolu une bonne fois pour toutes.
Conclusion sur les métadonnées
Les métadonnées sont le nœud gordien du data warehouse, mais Alexandre et son épée ne sont
pas encore en vue. Comment faire face en attendant ? Voici quelques mesures qui vous
permettront au moins de desserrer un peu le nœud :
• Insistez lourdement pour que les fournisseurs choisis proposent des fonctionnalités
d’échange ouvert des métadonnées.
• Prenez en charge les points faibles à l’aide d’utilitaires simples qui vous aideront à copier
les métadonnées depuis leurs sources vers les emplacements où vous en aurez besoin et à
administrer les tâches de gestion des métadonnées les plus répétitives.
• Le reste devra être fait « manuellement ». Élaborez le catalogue de vos métadonnées afin de
pouvoir les maintenir correctement. Vous opérerez une migration vers le catalogue des
métadonnées intégré lorsque celui-ci fera son apparition. Rappelez régulièrement à vos
fournisseurs qu’ils se sont engagés à travailler sur l’échange ouvert des métadonnées.
En résumé
L’infrastructure et les métadonnées sont les fondations du data warehouse. Une infrastructure
insuffisante ou des métadonnées trop limitées et négligées risquent d’affaiblir l’entrepôt entier.
Il ne sert à rien de produire des données parfaites si vous ne parvenez pas à les acheminer
jusqu’au poste de travail de l’utilisateur sous une forme fiable, compréhensible et prévisible.