concevoir et déployer un data warehouse - eyrolles.com · 11 infrastructure et métadonnées...

Concevoir et déployer un

data warehouse

Ralph Kimball

Éditions Eyrolles

ISBN : 2-212-09165-6

2000

11

Infrastructure et métadonnées

L’infrastructure et les métadonnées sont les fondations des composantes architecturales quenous avons décrites dans les chapitres 8, 9 et 10. L’infrastructure d’un entrepôt de donnéesinclut le matériel, les réseaux et les fonctions de bas niveau, telles que la sécurité, que lescomposants de haut niveau considèrent comme acquises. Les métadonnées sont un peu moinsconcrètes que l’infrastructure, mais constituent tout de même la couche de base des outilsd’arrière-plan (back room) et frontaux (front room). Ce chapitre identifie et définit les princi-paux 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 encompte en matière d’infrastructure des outils d’arrière-plan (back room). Ensuite, nous abor-derons quelques considérations relatives au matériel, aux systèmes d’exploitation et auxplates-formes de bases de données, en donnant au passage quelques définitions de base. Nousen 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èvepar un exemple d’utilisation des métadonnées et par quelques réflexions sur leur maintenance.

Gestion du projet

Planificationdu projet

Définitiondes

besoins del'entreprise

Spécification del'applicationutilisateur

DéploiementMaintenance

etcroissance

Développementde l'application

utilisateur

Définition del'architecture

technique

Installationet sélection des produits

Modélisationdimensionnelle

Conceptiondu modèlephysique

Conception etdéveloppementdes éléments de la zone de préparation

des données

ArchitecturePARTIE 3

2

Bien qu’assez technique, ce chapitre concerne tous les membres de l’équipe ; il est en effetimportant 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 sontpas des experts en infrastructure. Notre stratégie a toujours consisté à travailler en étroitecollaboration avec les experts en infrastructure de nos clients et à les aider à bien comprendreles besoins en infrastructure de l’entrepôt. Cette section identifie et définit les principauxcomposants 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 restentles éléments déterminants de la mise en œuvre. Au niveau de l’infrastructure, les besoins métiersont représentés par des mesures plus techniques. Par exemple, l’activité détermine le niveau dedé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. Lafréquence de chargement des données et la complexité des règles régissant les processus detransformation 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’infras-tructure. Dans certains cas, le processus d’extraction représente une charge trop lourde pourles systèmes opérationnels ; cette situation peut déboucher sur un investissement dans un envi-ronnement matériel miroir. Les compétences et l’expérience des équipes chargées de la miseen œuvre de l’entrepôt entrent aussi en ligne de compte. Les équipes responsables des outilsd’arrière-plan (back room) expérimentées en gros systèmes auront tendance à développer desentrepôts de données sur gros systèmes, et

vice versa

. Il en est de même pour les plates-formesde base de données. Si les administrateurs des bases de données ont investi beaucoup de tempset d’énergie dans l’apprentissage d’un SGBD bien précis, il ne sera pas aisé de les orientervers un autre produit.

Les problèmes politiques et organisationnels jouent également un rôle dans le choix del’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éati-vité. Par ailleurs, la stratégie informatique de l’entreprise guidera certaines décisions relativesau 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 applicationsdont 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 dechaque magasin de données, de chaque serveur d’applications et des postes de travail.

À propos des plates-formes matérielles, il convient de garder à l’esprit qu’un entrepôt de données connaîtsa croissance la plus significative au cours des dix-huit premiers mois de son existence, à la fois entermes de données et d’utilisation.

ASTUCE

Infrastructure et métadonnéesCHAPITRE 11

3

La première étape consiste à déterminer les plates-formes réellement nécessaires. Quelsmagasins de données allez-vous mettre en œuvre ? Parmi eux, combien devront disposer deleur propre plate-forme ? La figure 11.1 illustre quelques configurations matérielles typiquescorrespondant à des projets de tailles diverses.

Chaque boite de cette figure représente une machine ou un ensemble de composants physiquede l’entrepôt. Un environnement à deux niveaux (2 tiers) suffit pour un projet modeste ou pourun premier déploiement. Cependant, même les systèmes les plus petits doivent prévoir unserveur d’applications pour permettre l’accès aux données

via

le Web. Dans les entrepôts dedonnées plus ambitieux ou arrivés à maturité, la zone de préparation des données est généra-lement séparée de l’entrepôt ou du data mart. De nombreuses entreprises commencent direc-tement à ce niveau, car elles ont l’intention de faire croître leur data warehouse en évitantd’avoir à migrer vers une architecture à trois niveaux (3 tiers). Au bas de la figure, un entrepôtde données étendu à toute l’entreprise est implémenté sur plusieurs serveurs séparés. Bienentendu, 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 assimilerles besoins. Le simple fait de comprendre ce qu’une plate-forme doit faire et la façon dont elledoit le faire du point de vue technique ne suffit pas. Il est essentiel de prendre aussi en compteles besoins métier. Ce faisant, vous constaterez que le nombre de solutions à examiner seréduit considérablement et vous pourrez comparer leurs coûts respectifs, ainsi que d’autresfacteurs, en vue de déterminer la meilleure. Dans presque tous les projets de data warehouse,

Test/développement Plusieurs

data marts

Petit/début

Moyen/deuxième

phase

Grand/entreprise

Entrepôt etpréparation

Serveurd’applications

Outilsdu postede travail







Préparation etdéveloppement

Entrepôt dedonnées/data mart

Zone depréparation

des données

Data martde donnéesatomiques Plusieurs

data marts

Figure 11.1

Plates-formes matérielles correspondant à des entrepôts de données de tailles et de maturité variées.


4

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 quevous avez pour objectif de résoudre. Si la stratégie de l’entreprise est de développer desrelations client one-to-one, le niveau de détail des transactions devra être le client. Laplupart des projets d’entrepôt de données et de data marts se contentent de 200 gigaoctetsau 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 denouvelles 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 dedonné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 lafenêtre de chargement. Encore une fois, les besoins métier fournissent de bonnes indica-tions sur la volatilité. Bien évidemment, les données quotidiennes sont plus volatiles queles données hebdomadaires ou mensuelles. Les réponses à ces questions ont une incidencedirecte 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 selonlaquelle ils utilisent le data warehouse, le nombre de connexions simultanées et les picsd’activité (fin de mois, par exemple) sont autant de facteurs importants dans la sélectiond’une plate-forme. Pour une entreprise digne de figurer au palmarès des 1 000 premièresdans

Fortune

, l’effort initial de data mart/data warehouse devra commencer par 25 à 50 utili-sateurs actifs. Durant les dix-huit premiers mois, ce nombre passera à 100 ou 200 ; trois ansplus tard, on comptera des milliers d’utilisateurs, notamment si l’entrepôt est utilisé à la foispour des requêtes

ad hoc

et pour créer des états standard ou presse-bouton dans une grandeentreprise. La répartition géographique des utilisateurs est également importante. S’ils sontdisséminés sur toute la planète, le système devra bien évidemment être disponible 24 heuressur 24, ce qui a des conséquences sur le matériel. Dans un tel cas de figure, si les systèmesopé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 » pourpermettre une disponibilité constante. Si les systèmes opérationnels sont décentralisés, ilsemble 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ôtinflue énormément sur sa complexité. Vous pouvez envisager une plate-forme matériellepar 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 lesdonnées consolidées sont indispensables aux dirigeants de l’entreprise et si les méthodesmiddleware de consolidation virtuelle sont inadaptées à votre situation.

•

Type d’utilisation

. Le type d’utilisation et les outils frontaux sélectionnés ont égalementune 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’opti-miser un data warehouse pour ce type d’utilisation, car les bons analystes compulsent sanscesse les données à la recherche de niches. Au contraire, un système presse-bouton essen-tiellement destiné à produire des états standards peut être optimisé pour ce typed’utilisation ; toutefois, si vous avez l’intention d’en rester aux états standard, vous ne


5

tirerez pas le meilleur parti de votre investissement. La plupart des générateurs d’états dumarché permettent de planifier l’exécution d’états prédéfinis tôt le matin, après le charge-ment des données et avant l’arrivée du personnel. Cette démarche vise à mieux répartir lacharge de traitement en générant la plupart des états standard en dehors des heures depointe. Le data mining à grande échelle représente également une lourde charge pour lematériel, tant du point de vue du volume des données que de celui des entrées-sorties. Ilfaudra alors prévoir des « bêtes de course » capables d’absorber d’énormes volumes dedonnées, de les « ratisser » au moyen des outils de data mining les plus scrutateurs et deretourner des résultats à l’analyse et à la conduite de l’activité. Il est donc primordiald’étudier les différents types de requêtes, parce que l’utilisation

ad hoc

, la générationd’états et le data mining ont des profils différents et que leurs performances varient selonles plates-formes.

•

Compétences techniques

. Du point de vue de l’administration, l’environnement serveurest comparable à l’environnement gros système sur le plan conceptuel mais très différentsur le plan de l’implémentation. N’espérez pas pouvoir installer un serveur Unix, ni mêmeun système NT important, si l’équipe ne compte aucun expert en ressources système. Lagestion d’un serveur implique des tâches et des compétences nombreuses : administrationde base du matériel et des logiciels systèmes, connectivité (avec les postes de travail et lessystè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 questionde se contenter de mettre en route les serveurs et de ne plus s’en occuper. Du moins pasencore… Choisissez donc les plates-formes matérielles en fonction des compétencesinternes, à la fois en termes qualitatifs et quantitatifs.

•

Disponibilité logicielle

. Il arrive fréquemment que l’analyse des besoins mette en évidencedes fonctionnalités manquantes, par exemple un système d’information géographiquepermettant de situer les informations de l’entrepôt sur des cartes. Le processus de sélectiondes logiciels peut révéler que le logiciel de cartographie qui répond le mieux à vos besoinsne fonctionne que sur une plate-forme graphique haut de gamme ; dans un tel cas, la décisionsera vite prise !

•

Ressources financières

. Le budget alloué à un projet dépend généralement des bénéficesattendus. 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 lesmérites d’un entrepôt avant d’en avoir mis un en œuvre. En terme de matériel, la conclu-sion 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 etle système d’exploitation forment un tout. Dans les environnements gros système, vous n’avezpas le choix du système d’exploitation. En revanche, dans le monde des systèmes ouvertschaque constructeur de matériel implémente sa propre version d’Unix. Même NT existe enplusieurs versions, qui n’acceptent pas toutes les logiciels Intel/NT de base en natif. Voici lesprincipales 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 regagnaientl’environnement gros système après avoir subi un échec dans l’environnement client-serveur. Le data warehouse est certainement

le

domaine auquel cette observation nes’applique pas. En règle générale, le gros système n’est pas la plate-forme idéale pour un


6

entrepôt de données et les quelques réussites en la matière sont des exceptions : il s’agit soitd’entrepôts de données implémentés sur gros système depuis longtemps et dont la migra-tion 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, ledata warehousing sur gros système est en général peu rentable. Les coûts relatifs à l’admi-nistration, au matériel et à la programmation sont plus élevés que ceux des systèmesouverts, en partie parce que le gros système dispose d’une infrastructure de traitement destransactions 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 transac-tions, il manque de souplesse sur le plan de la programmation. Les outils et les techniquessont fiables, mais difficiles à exploiter. L’ajout de nouvelles sources de données, ou mêmela 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 limi-tées et n’envisagent aucune extension en vue d’applications nouvelles. Alors si vous avezde la place, occupez-la ; si vous devez envisager un nouvel investissement, optez pour unenvironnement serveur.

•

Serveurs de systèmes ouverts

. Les serveurs de systèmes ouverts, ou Unix, sontaujourd’hui les plates-formes les plus courantes pour les entrepôts de données de moyenneet de grande dimension. Unix est généralement assez robuste pour gérer correctement lesapplications de production et pratique le traitement parallèle depuis plus de dix ans. Lemarché des serveurs Unix est relativement accessible. D’un point de vue fonctionnel, Unixpeut 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 doncpossé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érerl’entrepôt ; prévoyez des formations le cas échéant. Gardez surtout à l’esprit qu’Unix n'estpas un environnement standard et que chaque constructeur propose sa propre version dusystè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 fortecroissance 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 ontlongtemps été limitées à des architectures mono-processeurs et les clusters sous serveur NTsont opérationnels depuis peu. Étant donné les antécédents de Microsoft, on peut penserque NT va devenir une plate-forme d’exploitation puissante ; à l’heure actuelle, ce systèmen’est toutefois pas le mieux adapté aux entrepôts de données de moyenne et de grandedimension. Il est en revanche rentable dans le cadre de data warehouses modestes ou dedata 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 à eninventer 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 Multiproces-sing), 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


7

durs, avec la mémoire et entre eux. Les frontières entre ces architectures s’estompent à mesureque les constructeurs optimisent leurs offres. Les sections qui suivent évoquent l’applicationde ces configurations au data warehouse.

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 demé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éeconviennent parfaitement à un entrepôt de données de taille moyenne. Pour tirer parti deprocesseurs multiples, la base de données doit être capable d’exécuter ses opérations en paral-lèle et les processus de l’entrepôt doivent être conçus pour exploiter les fonctionnalités du trai-tement en parallèle.

L’architecture en « partage intégral » rend les machines SMP bien adaptées aux requêtes ad hoc. Dans unenvironnement ad hoc, les chemins d’accès ne sont pas connus par avance. La nature à la fois centrali-sé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.

Processeur Processeur Processeur Processeur

SMP

MPP

NUMA



Figure 11.2

Principales architectures matérielles.

ASTUCE


8

Le « partage intégral » représente à la fois la force et la faiblesse de l’architecture SMP. Lesprocesseurs 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 casde forte sollicitation. Étant donné que la machine SMP est une entité unique, plus rien ne fonc-tionnera en cas de panne. Pour remédier à cet inconvénient, les constructeurs mettent au pointdes techniques permettant à plusieurs ordinateurs SMP d’être reliés entre eux ou de formerdes clusters. Dans un cluster, chaque nœud est une machine SMP possédant son propresystème d’exploitation, mais le cluster inclut des logiciels de connexion et de contrôle quipermettent aux machines de se partager les disques et de pourvoir à la réparation desdéfaillances. Ainsi, si une machine cesse de fonctionner, les autres se répartiront temporaire-ment sa charge de travail. Bien entendu, cet avantage a un coût car les clusters sont complexeset difficiles à gérer. Enfin, la technologie de base de données nécessaire à la prise en comptedes clusters évolue sans cesse.

MPP (traitement massivement parallèle)

Les configurations MPP sont fondées sur des chaînes d’ordinateurs relativement indépendantsles uns des autres, équipés chacun de son propre système d’exploitation, de sa mémoire et deson disque dur, le tout étant coordonné par des échanges de messages. La force de MPP résidedans sa capacité à connecter des centaines de nœuds (c’est-à-dire de machines) en vue de leursoumettre un problèmes selon l’approche par la force. Par exemple, pour sonder une grossetable de fond en comble, vous obtiendrez rapidement un résultat en recourant à un systèmeMPP de 100 nœuds, chaque nœud étant chargé de traiter un centième de la table. C’est lanotion de « petite main » appliquée à l’informatique. Les difficultés surgissent lorsque le frac-tionnement du problème à traiter est malaisé. Par exemple, une jointure entre deux grossestables peut poser problème si elles doivent toutes deux être traitées par les cent nœuds. Eneffet, chaque enregistrement d’une des tables peut être lié à des enregistrements de l’autretable, qui peuvent se trouver sur n’importe lequel des 99 autres nœuds ! La tâche de coordina-tion des nœuds peut alors subir une surcharge. Bien entendu, les développeurs de systèmesutilisant la technologie MPP ont mis au point des moyens de contourner ce problème et deré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à duté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 enmiroir sur plusieurs nœuds. Les machines MPP fonctionnent mieux lorsque les cheminsd’accès aux données sont prédéfinis et que les données peuvent être distribuées sur les nœudset sur les disques en fonction de ces chemins.

Les systèmes MPP sont fréquemment employés pour gérer les environnements de requêtes prédéfiniesou 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 êtreconçue pour tirer parti de cette structure matérielle (la conception physique adaptée à un système MPPpeut ê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 dupartage des disques du premier aux performances de traitement en parallèle du second. Il s’agitd’une innovation relativement récente, qui a des chances d’être viable à long terme sur le

ASTUCE


9

marché du data warehouse. Du point de vue conceptuel, l’architecture NUMA reprend l’idéedes clusters de machines du SMP, mais avec des connexions plus « serrées » de la bandepassante supplémentaire et une meilleure coordination des nœuds. S’il vous est possible desegmenter votre entrepôt de données en groupes d’utilisation relativement autonomes et de placerchaque 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 logicielset 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 notam-ment qu’Unix n’est pas un standard.

• Quelles sont les applications disponibles compatibles avec cette version du systèmed’exploitation ? Si l’éditeur du logiciel que vous voulez acheter n’a pas porté son produitsur 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 utilitairesde 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 lesrequêtes peuvent solliciter fortement les données. En règle générale, une requête adressée à unsystème transactionnel retourne un enregistrement unique issu d’une table optimisée demaniè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 provenantde 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 legigaoctet. Dans les systèmes haut de gamme, les lecteurs sont installés sur un ordinateur auto-nome 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’autressystèmes d’exploitation). On peut les configurer conformément aux standards de sécurisationdu stockage des données RAID (

Redundant Array of Inexpensive Disks

) 1 ou 5, afin d’opti-miser la disponibilité de l’entrepôt de données. Sachez que les bases de données ont besoin degros volumes de mémoire temporaire pour effectuer les tris, les jointures et les agrégats. Cevolume doit résider sur des lecteurs et des contrôleurs performants mais n’a pas besoin d’êtreplacé 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 etl’échange à chaud sont importants dans la mesure où les lecteurs sont les composants les plussujets aux pannes. Les sous-systèmes de lecteurs de disques coûtent plus cher mais sont renta-bles à long terme. Prévoyez au départ assez d’espace disque pour un ou deux ans et gérezvotre 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émen-taire entre l’aide à la décision et le traitement transactionnel. Les requêtes sur les transactions


10

sont généralement peu gourmandes en mémoire. Les requêtes d’aide à la décision sont plusexigeantes et impliquent souvent plusieurs passes dans des tables volumineuses. Si lamé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 desplates-formes 64 bits. Les systèmes 32-bits sont limités à 2 gigaoctets (parfois 4), tandis queles processeurs 64-bits sont capables d’adresser un espace mémoire plus important. Remar-quez au passage que pour que le 64-bits soit effectif, l’ordinateur, son système d’exploitationet la base de données doivent également être en 64-bits.

La tentation de favoriser la mémoire au détriment des disques revient régulièrement à l’ordre du jour, enraison de la différence des temps d’accès. Un accès disque prend environ 10 millisecondes, tandis qu’unaccès mémoire est 100 fois plus rapide (0,1 milliseconde). Cependant, le traitement des données d’unebase en mémoire ne sera pas pour autant 100 fois plus rapide, car de nombreux autres facteurs entrent enligne de compte : antélecture de disque et mémoire cache sur le contrôleur ou dans le système d’exploita-tion. Néanmoins, vous pouvez multiplier les performances d’un entrepôt de données par un facteur comprisentre 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 devezoffrir. Si les données doivent être accessibles au monde entier, des machines en parallèle etune forte redondance des composants seront nécessaires (le problème consistera à trouver desheures creuses pour effectuer les chargements et la maintenance). La disponibilité du datamart des données atomiques est décisive dans la mesure où ce data mart contient les donnéesdu niveau de détail le plus fin et sera probablement relié à tous les autres data marts sur lemode du forage. La puissance de traitement est également essentielle, car le data mart desdonnées atomiques est le point central du processus de chargement et doit être capable detransfé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. Sipossible, optez pour un système de sauvegarde assez rapide pour effectuer son travail pendant ladurée impartie au chargement. Bien qu’il soit possible de sauvegarder le contenu d’un entrepôtde données à un moment où les utilisateurs s’en servent, une telle opération risque d’engendrerune 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 auxentrepôts de données, Unix représentant la meilleure option pour les systèmes de moyenne oude 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 ware-house 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 cons-tructeurs 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 leproduit fonctionne le mieux. Après son développement, le produit initial est porté sur d’autres

ASTUCE


11

systèmes d’exploitation et sur d’autres versions d’Unix. Bien entendu, il peut être judicieuxd’attendre une nouvelle version ; les premiers acquéreurs font office de cobayes…

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 produitsd’accès aux données sont livrés avec un composant serveur d’applications qui doit obliga-toirement 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 quivous évite d’engager des investissements supplémentaires. L’idée n’est peut-être pas excel-lente à long terme, mais elle simplifie le démarrage. Nous évoquons également les serveursd’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éderdirectement à l’entrepôt de données pour tester de nouveaux scénarios, construire denouvelles 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 ultra-sensible. Il existe plus d’une dizaine de possibilités ; chacune d’elles offre des exemplesd’implémentations de data warehouses réussies et est défendue par ses supporteurs. En dehorsdes produits les plus connus, la plupart des entreprises du secteur des langages de quatrièmegé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 multidimensionnellesspé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 auchoix de la plate-forme de la base de données. Notre expérience nous dit que votre décisiondépend des spécificités de votre situation. Commencez par faire votre choix entre les bases dedonné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 basesde données dimensionnelles, les premières menant la danse. Depuis quelques années, lemarché de l’aide à la décision est le théâtre de discussions visant à déterminer l’approcheconvenant le mieux au traitement analytique. Le débat est passionné mais apporte malheureu-sement peu de réponses.

Le problème devient plus facile à appréhender sous l’angle des besoins métier. Les bases dedonnées multidimensionnelles, également baptisées moteurs MOLAP, sont apparues pourrépondre à trois besoins essentiels des utilisateurs : simplicité de l’accès aux données, états detype tableau croisé et temps de réponse faibles. Certains ont développé des bases de donnéesspécialisées parce que les bases de données relationnelles standard et leurs « ancêtres » étaientincapables de satisfaire ces trois exigences. La majeure partie des produits MOLAP existentdepuis une dizaine d’années. Les sections suivantes mettent en lumière les avantages et lesinconvénients des deux solutions.

ASTUCE


12

Caractéristiques des moteurs relationnels

La plupart des constructeurs de bases de données relationnelles ont investi dans le développe-ment d’adaptations spécifiques au data warehouse et offrent aujourd’hui des performancesacceptables. Les principaux constructeurs de SGBDR ont introduit plusieurs nouveautés :prise en charge du modèle dimensionnel, jointures en étoile, indexation bitmap et optimiseursde requêtes plus efficaces. Ces progrès, accompagnés d’avancées technologiques telles que lasensibilité aux agrégats, ont réduit de manière considérable les différences de performancesentre les produits. Les bases de données relationnelles présentent l’avantage de pouvoirstocker plus de données au niveau de détail le plus fin. Il est entendu que les systèmes spécia-lisés dans la résolution de certains problèmes sont avantagés par rapport aux produits plusgénéralistes ; il en va de leur survie sur le marché.

Si vous avez décidé de fonder votre entrepôt de données sur une plate-forme relationnelle et si votreprojet est de faible ou de moyenne envergure, il serait absurde d’envisager des solutions n’appartenantpas à 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émentationsexistantes et de vous livrer à quelques tests. Identifiez quelques états un peu délicats, compor-tant notamment des jointures multiples entre plusieurs tables, et voyez ce qu’ils donnent. Enrègle générale, les constructeurs mettent à votre disposition des ressources pour vous aiderdans ce processus de test. Profitez des éventuelles expériences internes de sélection deproduits acquises dans le cadre de projets informatiques antérieurs.

Certaines bases de données relationnelles sont spécialement conçues pour gérer les configurations debases de données et les requêtes de type data warehouse. Elles sont plus rapides que les principauxSGBDR et sont intéressantes (presque obligatoires, en fait) pour les entrepôts de données de grandeenvergure.

Caractéristiques des moteurs MOLAP

Les moteurs MOLAP, également nommés systèmes de gestion de bases données multidimen-sionnelles, 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 lesbesoins auxquels il est possible de répondre par un schéma en étoile. Le nombre des dimen-sions et des lignes doit être relativement restreint. Le moteur MOLAP introduit une couchesupplémentaire dans les processus de chargement et d’administration.

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 etque 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 faitscorrespondant à toutes les combinaisons de dimensions valides sont préstockés. Les temps deréponse sont étonnants. En contrepartie, le stockage de tous ces agrégats accroît le volume desdonnées. Or, le volume de données qu’il est possible de stocker dans une base de donnéesmultidimensionnelle est, pour des raisons historiques, limité à 10 gigaoctets ; les construc-teurs font leur possible pour résoudre ces restrictions portant sur le stockage physique. Unelimitation subsiste néanmoins, imposée par la durée nécessaire au chargement de nouvelles

ASTUCE

ASTUCE

ASTUCE


13

données ou à l’actualisation de la base de données. Aujourd’hui, la plupart des utilisateurs ontautant 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 desproduits de cette gamme. Leurs aptitudes à gérer les modifications, les calculs complexes etles sous-totaux, autres avantages non négligeables des moteurs MOLAP, en font des candidatsidéaux pour les systèmes budgétaires et prévisionnels.

L’évaluation des moteurs multidimensionnels ne peut pas être dissociée de celle des outilsd’accès aux données, que nous décrivons en détail au chapitre 13. Certains produits MOLAPoffrent 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 procurerauprès d’un fournisseur extérieur.

Au moment où nous écrivons ces lignes, les fonctionnalités de forage des SGBDR de type SQL via desmoteurs MOLAP peuvent tout au plus être qualifiées de rudimentaires. Ce problème de liaison entre lesmoteurs MOLAP et l’environnement relationnel est la raison pour laquelle nous préconisons le stockagedes données détaillées au sein d’un modèle dimensionnel. Si ces deux niveaux représentent des concep-tions 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 utili-sateurs en procédant à des tests d’utilisation. Les solutions postes de travail, légères, peuventsembler intéressantes à court terme mais risquent de générer, au fil du temps, plus de travailque de valeur ajoutée. L’équipe chargée du data warehouse doit évaluer avec soin les limita-tions et les fonctionnalités des produits. L’évolutivité doit être privilégiée.

Sur le plan de l’évolutivité, l’inconvénient majeur des produits MOLAP réside actuellement dans la limita-tion du volume des données en entrée pour la table des faits principale et du nombre de lignes dans lesdimensions. Début 1998, ces limitations tournaient autour de 5 gigaoctets de données en entrée et de300 000 lignes dans la dimension la plus importante.

Le problème de la multiplicité des constructeurs et des produits tend à s’estomper à mesureque 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ématique-ment une baisse des prix ; le budget disponible reste donc un facteur à part entière du choixentre SGBDR et MOLAP.

Infrastructure des outils frontaux (front room)

L’infrastructure des outils frontaux (front room) dépend plus fortement de l’activité et desoutils 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 desinformations intéressantes et des conseils en ce domaine n’est pas simple, car les produits sont

ASTUCE

ASTUCE


14

très nombreux et très différents. La meilleure tactique consiste à interroger très tôt les cons-tructeurs 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 plate-forme matérielle ? Dans ce cas, comment se comportent les performances ? Quels sont lescompromis à 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 avantagesde l’installation de plusieurs processeurs ? Combien d’utilisateurs simultanés le produitpeut-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 deson navigateur favori sera satisfait si on lui fournit assez de puissance pour lancer son naviga-teur Web. À l’autre extrême, l’utilisateur aguerri qui construit des requêtes complexes et lancedes analyses personnalisées devra être équipé d’un ordinateur beaucoup plus puissant. Voustrouvez 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 duMacintosh ; d’autres sociétés utilisent des stations de travail Unix pour les études et pour laproduction. Le support de plates-formes multiples entraîne une lourde tâche pour l’équipechargée des outils frontaux. Les problèmes d’installation et de support varient d’une plate-forme à l’autre et l’équipe doit être compétente dans tous les domaines. D’autre part, lesproblèmes ne prennent pas fin une fois que les logiciels sont installés. Il est souvent nécessairede créer les états sur chaque plate-forme, ce qui peut multiplier par deux le travail de dévelop-pement et de maintenance. Les concepteurs d’outils frontaux sont peu nombreux à supporterd’autres plates-formes que le duo Windows/Intel. Si vous êtes obligé de supporter plusieursplates-formes poste de travail, le processus de sélection des outils d’accès aux données s’entrouvera 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 tousseront compatibles avec les logiciels client car la version du système d’exploitation peut êtreinadapté. Renseignez-vous sur la version du système d’exploitation requise par vos outils etvérifiez qu’elle correspond bien à la réalité.

Dans le monde Windows, si vos utilisateurs ne disposent pas de Windows 95 et versions ultérieures ou deNT 4 et versions ultérieures, vous pouvez vous attendre à des problèmes.

ASTUCE


15

Distribution des logiciels

Ce problème est insidieux : il s’installe lentement et sans faire de bruit puis, un beau jour, voussaute 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 sontimpatients de commencer à travailler sur les nouveaux produits. Puis d’autres personnesdemandent à accéder au data warehouse, bientôt rejoints par des utilisateurs géographiquementdistants, et vous finissez par vous retrouver en train de gérer plusieurs centaines de copies deslogiciels destinés aux poste de travail, réparties aux quatre coins de l’entreprise. C’est bienentendu ce moment-là que votre fournisseur choisit pour commercialiser la nouvelle version deson produit, qui fait absolument tout mais dont la compatibilité avec la précédente version n’estpas 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 Webet 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 adhoc. Il est pourtant possible de faire de l’analyse ad hoc au moyen d’une grosse applet ; chezMetaphor, nous avons même développé des applications complexes sur un réseau d’ordina-teurs 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 dedéveloppement n’est pas encore assez robuste). Les nouveaux venus qui proposent une offred’outils Web ne sont entravés par aucun passif, mais ils n’ont pas encore eu le temps de déve-lopper 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 perfor-mances des postes de travail. Nous avons eu l’occasion de travailler pour une entreprise quiavait consacré beaucoup de temps et d’énergie à rechercher la cause d’un problème du côté duréseau alors que le goulet d’étranglement était dû à une capacité mémoire insuffisante sur lespostes de travail. Ceux-ci passaient le plus clair de leur temps à paginer les données et lesprogrammes 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 effi-cace. 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 arti-ficiellement leur usage du data warehouse (et, ce faisant, l’utilité de ce dernier) en vued’é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 lepermet. Les stations partagées ne sont pas très fonctionnelles car elles font augmenter le coûtperç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 lesrésultats un peu plus tard, il aura probablement du mal à s’y mettre.


16

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. Étantdonné qu’elle constitue un prérequis à la mise en œuvre de n’importe quel application client-serveur, le travail préparatoire est généralement déjà terminé. La plupart des entreprisespossè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 urgentde mettre en place un groupe de travail afin d’évaluer les besoins. Plusieurs autres problèmesde 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éseaulocal à haut débit dédié (Ethernet ou FDDI à 100 Mo/s). Cette configuration procure la bandepassante 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 pouvoiraccéder à l’entrepôt de la même manière que les utilisateurs locaux. Prévoyez à cet effet uneconnexion à large bande passante, fiable, entre le réseau local des utilisateurs distants et celuiqui 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. Denombreux outils permettent à présent de définir un sous-ensemble de données particulièrementintéressant, de le récupérer et de l’analyser en local. Une telle opération représente un flux dedonnées descendant assez considérable. Après avoir évalué les besoins, contactez l’équiperé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 placeun accès par les lignes téléphoniques. Effectuez des tests de performances poussés et lisezattentivement le chapitre 12, qui traite de la sécurité.

Passerelles

La plupart des constructeurs de bases de données proposent des passerelles, qui permettentd’établir des liens avec les bases de données concurrentes et avec les sources de données deproduction. La mise en œuvre d’une passerelle sera par exemple très utile pour accéder auxdonné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 enprovenance de plusieurs sources au moyen de jointures hétérogènes. Ces passerelles onttendance à être assez lentes ; elles rendent particulièrement service dans le cadre des importa-tions batch et de recherches dans les petites tables. Faites des tests grandeur nature pour vérifierqu’elles ne s’effondrent pas.

Transfert de fichiers

Il existe un large éventail de protocoles de transfert de fichiers et de programmes chargés deles implémenter. Le principal est le protocole FTP (File Transfer Protocol), qui est un utili-taire de transfert de données universel. FTP remonte aux débuts de l’Internet ; il offre desservices de transfert de fichiers entre les ordinateurs reliés à l’Internet, quel que soit leur type.


17

Ses fonctionnalités de base sont l’établissement des connexions entre ordinateurs et le trans-fert 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 decryptage des données transmises, qui permet de sécuriser les informations sensibles. SSL esttrès largement implanté dans le monde Unix, dans lequel il sécurise les transactions entre lesnavigateurs 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 presquetoutes les bases de données, le mode natif. Il existe toutefois quelques standards en matière deconnectivité de base de données, notamment ODBC (Open Database Connectivity), originel-lement développé par Microsoft, et JDBC (Java Database Connectivity), initialement conçupar JavaSoft. ODBC est une méthode standard d’accès aux bases de données qui permetd’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 encommandes compréhensibles par la base de données. Historiquement, ODBC est devenu unpilote de connectivité de second ordre parce que beaucoup d’implémentations spécifiquesn’ont pas donné d’aussi bons résultats que l’utilisation du mode natif. Toutefois, des pilotesplus puissants existent aujourd’hui et la popularité d’ODBC augmente. JDBC a profité del’é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 connecti-vité sous le sigle OLE DB, qui promettent d’améliorer encore la connectivité des bases dedonnées.

Service d’annuaire

Votre infrastructure de réseau doit prévoir des fonctionnalités destinées à attribuer des nomsaux hôtes et à assurer l’indépendance des adresses. Au départ, l’Internet et/ou les intranetsdépendent d’un DNS (Domain Name Service), qui recherche un nom dans une liste etretourne 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 demanière qu’ils se servent de ce nom. Le nom du serveur est ensuite dynamiquement convertien adresse IP, celle de l’ordinateur où réside la base de données. Si vous déplacez la base surun autre ordinateur, il suffit de modifier l’entrée correspondante dans la liste du DNS. Cetteconversion se produit chaque fois que vous utilisez un navigateur Web pour vous rendre surun site quelconque. Lorsque vous tapez www.nomdusite.com, ce nom est converti en adresse IPpar 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 (LightweightDirectory Access Protocol). Ils hébergent des informations bien plus riches que les simplesadresses IP. Ils peuvent concerner plusieurs types de données : noms et adresses, adresses e-mail, listes téléphoniques et annuaires de matériel (imprimante, ordinateur, etc.). Cesannuaires peuvent servir de liste d’inventaire pour le recensement des serveurs, d’annuaire desutilisateurs pour la mise à disposition des données, de listes de diffusion pour les états stan-dard, etc. Dans le chapitre 12, nous vous incitons à centraliser l’administration de votre confi-guration (« logons », etc.) au moyen d’un serveur d’annuaire LDAP.


18

Conclusion sur l’infrastructureComme 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 troisdomaines, 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 dedonnées. Les nouveaux systèmes opérationnels client-serveur ont des besoins en infrastructuresimilaires à ceux des data warehouses ; en conséquence, dans la plupart des cas l’entrepôt dedonnées peut s’appuyer sur l’infrastructure existante. Cela dit, les questions d’infrastructure sonttrès sensibles ; vos décisions se retourneront contre vous si vous avez fait le mauvais choix.

Métadonnées et catalogue des métadonnéesLes métadonnées sont un vaste champ de bataille terminologique. Dans cette section, nousallons 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’unentrepôt de données. Enfin, nous décrirons le concept de catalogue de métadonnées et feronsquelques 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 nousne savons pas exactement en quoi elles consistent ni où elles se trouvent, nous passons beau-coup de temps à en parler, à nous en inquiéter et à nous sentir coupable de ne pas nous enoccuper suffisamment. Il y a quelques années, on a décrété que les métadonnées désignaientles 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 outilsfrontaux (front room) ». Les métadonnées des outils d’arrière-plan (back room) sontprocédurales ; elles guident les processus d’extraction, de nettoyage et de chargement. Lesmétadonnées des outils frontaux (front room) sont plus descriptives et aident les outils derequête et les générateurs d’états à fonctionner du mieux possible. Bien entendu, les métadon-nées procédurales et les métadonnées descriptives se recoupent, mais le fait de les distinguerainsi peut aider à mieux les comprendre.

Les métadonnées de la zone de construction (back room) sont censées aider l’administrateurde la base de données à alimenter l’entrepôt ; elles sont également susceptibles d’intéresser lesutilisateurs qui souhaitent connaître la provenance des informations. Les métadonnées desoutils frontaux (front room) bénéficient essentiellement à l’utilisateur final ; elles ne secontentent pas de mettre de l’huile dans les rouages des outils : elles constituent aussi unesorte de dictionnaire de l’activité.

Cependant, ces deux définitions, aussi intéressantes soient-elles, ne donnent pas à l’adminis-trateur de l’entrepôt de données une idée précise de l’intérêt des métadonnées. Essayons doncde 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 ;


19

• 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éta-donnée… Remarquez que le dernier point de la liste ci-dessus n’est pas une métadonnée, maisune information relative aux métadonnées. Serons-nous amenés à faire appel à des méta-métadonnées ? Pour y voir plus clair, élaborons une liste de tous les types de métadonnéespossibles. Celle-ci ne sera peut-être pas exhaustive du premier coup mais nous en apprendracertainement beaucoup.

Métadonnées des systèmes sourceRevenons tout d’abord aux systèmes source : gros systèmes, serveurs autonomes, postes detravail, fournisseurs de données externes et même Internet. Nous supposerons ici que nousnous contentons de lire les données source et de les déposer dans la zone de préparation desdonné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.


20

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 zonede préparation et pour préparer leur chargement dans un ou plusieurs data marts. L’opérationpeut être accomplie sur le site central au moyen d’un programme Cobol développé à cet effetou à l’aide d’un outil d’extraction automatisée. Il est également possible de stocker les fichiersséquentiels extraits sans y toucher dans une zone de préparation des données autonome, surun ordinateur distinct. En tout cas, nous devons nous préoccuper des métadonnées, notam-ment 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é etresponsable.

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 derecherche d’attributs ;

• règles à appliquer aux nouveaux attributs descriptif dans les dimensions changeantes (écra-sement, 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 unetable 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 DIFFCOMPARE.

Transformation et agrégation

• Spécification du nettoyage des données ;

• optimisation des données et transformations par rapprochement (par exemple, développe-ment des abréviations et ajout de détails) ;

• transformations nécessaires au data mining (par exemple, interprétation des valeurs nulleset 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égatspossibles ;


21

• 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 enregis-trement et de quand date-t-il ?) ;

• journaux d’exécution des transformations des données, synthèse des résultats et heures desexé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 auxmé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 autregroupe 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 cons-tructeur et le service informatique) ;

• profils des privilèges utilisateur dans la sécurité réseau ;

• certificats d’authentification de la sécurité réseau ;


22

• statistiques d’utilisation relatives à la sécurité réseau : tentatives de connexions, tentativesd’accès et état des ID utilisateur par localisation ;

• profils utilisateur individuels reliés aux ressources humaines pour le suivi des événementsqui 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ésentaientles métadonnées ! Elles englobent tout, sauf les données elles-mêmes, et les données semblentsoudain être la composante la plus simple de l’ensemble. Les métadonnées sont en quelquesorte 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 dynamiquesLa tâche qui consiste à collecter et à maintenir les métadonnées n’est pas une fin en soi. Lesmétadonnées sont au data warehouse ce que la documentation est aux systèmes traditionnels ; ducoup, on a facilement tendance à les délaisser au profit de projets plus urgents. Les métadonnéesdynamiques tentent de résoudre ce problème. Ces métadonnées pilotent les processus ; cefaisant, 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éta-donné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. Laplupart de ces outils sont fonctionnels en amont et en aval ; vous pouvez donc les utiliser pourextraire les métadonnées des bases de données existantes. Créez des modèles logiques etphysiques incluant les noms logiques (métier) des colonnes, leur nom physique, leur descrip-tion métier, des exemples de valeurs et des astuces de requêtes. Une fois votre modèle cons-truit, enregistrez-le dans la base de données relationnelle prévue dans l’outil pour le stockagedes 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. Lesmodèles de data warehouse élaborés à l’étape 1 apportent les informations nécessaires à l’iden-tification des cibles du processus de préparation. L’outil de préparation des données doit égale-ment 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équentielsque de bases de données sur gros système. Généralement, l’outil de préparation des donnéesdispose d’un moyen intégré de capturer ces informations, dont il a impérativement besoin. Lorsde 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 lacapture des informations relatives aux transformations susceptibles de se produire au cours duprocessus de préparation. Si vous disposez d’un bon outil de préparation, celui-ci potentialiserales 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 ouvertrelationnel de l’outil de préparation des données. La figure 11.4 illustre cette opération.


23

Figure 11.3

Capture des modèles de données de l’entrepôt.

Modèlelogique

Outil demodélisation

(1) Modèle de l’entrepôt

Catalogue des métadonnées

Modèlephysique

Figure 11.4

Capture de la définition des sources et rapproche-ment avec les cibles.

Modèlelogique

Définitionsdes sources

Rapprochementssource/cible


Systèmessource

Outil depréparation

desdonnées



Modèlephysique

(2) Définitionsdes sources

(3) Définitionsdes tables

(4) Rapprochements source/cible


24

Notez que le processus de création de ces rapprochements, à l’étape 3, consiste essentielle-ment à 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 autantde 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 lesdonnées, comme le montre la figure 11.5. Au cours de l’étape 5, l’outil de préparation desdonnées interroge les métadonnées afin de récupérer les informations requises : type etlocalisation des données source, type et localisation des données cible, rapprochementsentre les deux.

Figure 11.5

Étapes 5 à 8 : extraction, transforma-tion et chargement.

Modèlelogique




Systèmessource


desdonnées

Datawarehouse



Modèlephysique


(3) Définitions des tables (4) Rapprochements source/cible

(7) Données transformées (5a) Informations physiques (tablespaces, etc.)

(5) Informations derapprochement etde transformation

(6) Données extraites

(8) Statistiques de chargement


25

Nous pouvons également interroger la base de données cible au cours de l’étape 5a pour récu-pérer des informations sur l’état physique du système, notamment sur l’espace disque dispo-nible. Au cours de l’étape 6, nous procédons à l’extraction proprement dite des sources dedonné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 etles enregistre dans le catalogue des métadonnées.

Nous avons donc réussi à charger des données ; les utilisateurs brûlent d’impatience de lesexploiter, 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’ouvrirgrand les portes, il convient de donner à l’entrepôt un abord plus « métier ». Une liste destables et des colonnes classées par ordre alphabétique ne suffira pas, car l’utilisateur raisonneen types d’activités et non par ordre alphabétique… Les regroupements à opérer découlent dela table des faits. Les outils frontaux et les serveurs d’applications permettent habituellementde 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 Webdestiné à exploiter les métadonnées. L’utilisateur peut consulter les types d’activités, identifierles tables qui appartiennent à tel ou tel type d’activité et même consulter leur contenu. Enoutre, à l’aide d’un simple outil de recherche, l’utilisateur peut rechercher les noms ou lesdescriptions 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 unerequête et la soumettre à la base de données (étape 10). Remarquez au passage que la requêtes’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 estprise en charge par un bon outil de requête capable de générer un certain nombre d’informa-tions relatives à l’utilisation.

Cette progression illustre le rôle central du catalogue des métadonnées dans le contexte d’unentrepô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. Remar-quez également que, dans certains cas, des composants d’une seule et même métadonnéeapparaissent en différents endroits. Par exemple, le modèle que nous avons créé dans l’étape 1contient les définitions des tables physiques. L’outil d’accès aux données s’en sert lors durapprochement 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 tablesphysiques pour formuler de bonnes requêtes.

La liste des métadonnées et l’exemple de flux ont finalement réussi à vous donner une vued’ensemble de ces fameuses métadonnées. Mais est-il vraiment nécessaire de suivre un telcheminement ? Nous pensons que oui. Cette liste de métadonnées est la charpente de votreentrepô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ésidersur des ordinateurs situés près des lieux où les tâches se déroulent. Les programmes, les para-mètres et les spécifications qui pilotent les processus doivent connaître des destinationscertaines et des formats certains, et cela ne va pas changer dans les prochains temps.


26

Maintenance du catalogue des métadonnées

Les termes bibliothèque d’information, référentiel, dictionnaire de métadonnées et métabasede données sont, parmi d’autres, utilisés pour décrire le catalogue des métadonnées. Nousavons choisi le terme catalogue des métadonnées pour décrire l’ensemble des métadonnéesprésentes dans l’entrepôt. Idéalement, ce catalogue devrait être le lieu de stockage unique desinformations qui pilotent des processus dans l’entrepôt. Toutes les procédures internes de

Figure 11.6

Rôle des métadonnées dans le pilotage des outils frontaux.

Modèlelogique




Systèmessource


desdonnées

Outilsfrontaux

Datawarehouse



Modèlephysique


(3) Définitions des tables (4) Rapprochements source/cible

(7) Données transformées (5a) Informations physiques (tablespaces, etc.)

(5) Informations derapprochement etde transformation

(6) Données extraites

(8) Statistiques de chargement

(12) Statistiques d’utilisation des requêtes

Descriptionsmétier (nomset contenudes tables etdes colonnes,exemples de valeurs, etc.)

(9)

(10) États, requêtes (11) Données


27

l’entrepôt, du modèle initial à la navigation et à l’accès aux données en passant par les extrac-tions récurrentes et les processus de chargement, devraient faire appel au catalogue des méta-données. Malheureusement, une mise en œuvre aussi parfaite est impossible à l’heureactuelle ; nous considérerons donc le catalogue des métadonnées comme un concept logiqueréparti dans plusieurs emplacements physiques.

Procurez-vous un outil pour cataloguer et suivre toutes ces métadonnées. Il ne sera probablement pascapable de lire et d’écrire toutes les métadonnées directement mais, étant donné leur éparpillement, ilvous aidera au moins à gérer.

Il existe heureusement une catégorie d’outils, judicieusement nommés outils pour cataloguesde métadonnées, qui se consacrent à cette tâche. Le site Web de Larry Greenfield en fournitune 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 vued’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 lesspécifications qui accompagnent les data marts personnels peuvent ne pas être pris en chargepar 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 êtremise en œuvre afin de créer des RPC (Remote Procedure Calls), qui procureront aux systèmessource 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’exploiterles métadonnées relatives à la sécurité. Celles-ci doivent être développées et maintenues aumoyen d’un outil ou d’une fonction quelconque. Il s’agit d’ajouter et de supprimer des utili-sateurs et des groupes d’utilisateurs, d’assigner des droits d’accès à ces utilisateurs et à cesgroupes, etc. Ces métadonnées doivent également être intégrées aux tables de sécurité de laplate-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 deservices :

• intégration et fusion des informations du catalogue (depuis le modèle de données vers labase 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 desmé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, pouvons-nous espérer nous tourner vers des outils encore plus puissants qui rassembleront les métadon-nées en un lieu unique et qui seront capables de les lire et de les écrire ? Ce type d’outil nousapporterait une interface utilisateur uniformisée, appréciable dans un cadre aussi disparate, etnous permettrait en outre de prendre des instantanés cohérents de toutes les métadonnées d’unseul coup (puis de les sauvegarder, de les sécuriser et de les restaurer en cas de besoin).

ASTUCE


28

À notre avis, ce type d’outil n’est pas près d’inonder le marché. Le problème est trèscomplexe ; la prise en compte de toutes les formes de métadonnées requiert un type d’intégra-tion entre les systèmes qui n’existe pas encore. Nous sommes convaincus que la MetadataCoalition (un groupe de constructeurs qui s’est attelé à la résolution du problème des méta-données) réalisera des progrès intéressants dans la définition d’une syntaxe et d’une sémanti-ques communes pour les métadonnées. Signalons toutefois que ce groupe a vu le jour en1995… 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 standardsde métadonnées propriétaires. Si les avantages de ces standards sont assez importants pourattirer d’autres fournisseurs, nous pouvons espérer que le problème des métadonnées serarésolu une bonne fois pour toutes.

Conclusion sur les métadonnéesLes métadonnées sont le nœud gordien du data warehouse, mais Alexandre et son épée ne sontpas encore en vue. Comment faire face en attendant ? Voici quelques mesures qui vouspermettront au moins de desserrer un peu le nœud :

• Insistez lourdement pour que les fournisseurs choisis proposent des fonctionnalitésd’échange ouvert des métadonnées.

• Prenez en charge les points faibles à l’aide d’utilitaires simples qui vous aideront à copierles 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 depouvoir les maintenir correctement. Vous opérerez une migration vers le catalogue desmétadonnées intégré lorsque celui-ci fera son apparition. Rappelez régulièrement à vosfournisseurs 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 infrastructureinsuffisante 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 acheminerjusqu’au poste de travail de l’utilisateur sous une forme fiable, compréhensible et prévisible.

concevoir et déployer un data warehouse - eyrolles.com · 11 infrastructure et métadonnées...

Documents