Concevoir et déployer un data warehouse

Transcription

1 Concevoir et déployer un data warehouse Ralph Kimball Éditions Eyrolles ISBN :

2 Définition de l'architecture technique Installation et sélection des produits 11 Planification du projet Définition des besoins de l'entreprise Modélisation dimensionnelle Conception du modèle physique Conception et développement des éléments de la zone de préparation des données Déploiement Maintenance et croissance Spécification de l'application utilisateur 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.

3 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.

4 Infrastructure et métadonnées CHAPITRE 11 3 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. Petit/début Entrepôt et préparation Serveur d applications Outils du poste de travail Moyen/ deuxième phase Préparation et développement Entrepôt de données/ data mart Serveur d applications Outils du poste de travail Grand/ entreprise 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 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,

5 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 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

6 Infrastructure et métadonnées CHAPITRE 11 5 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

7 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

8 Infrastructure et métadonnées CHAPITRE 11 7 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.

9 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

10 Infrastructure et métadonnées CHAPITRE 11 9 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

11 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

12 Infrastructure et métadonnées CHAPITRE 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.

13 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

14 Infrastructure et métadonnées CHAPITRE 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 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

15 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.

16 Infrastructure et métadonnées CHAPITRE 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 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.

17 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.

18 Infrastructure et métadonnées CHAPITRE 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 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 e- mail, 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.

19 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 ;

20 Infrastructure et métadonnées CHAPITRE 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.