Conception du Data Warehouse

publicité
& Microsoft OLAP Services (Plato)
La stratégie Data Warehouse de Microsoft
Une plate-forme pour améliorer la prise de décisions grâce à un accès aux
données et des analyses plus faciles.
http://www.microsoft.com/industry/bi
Les informations contenues dans ce document représentent le point de vue
actuel de Microsoft Corporation sur les sujets traités à la date de publication.
Etant donné que Microsoft doit s’adapter aux conditions changeantes du
marché, ces informations ne doivent pas être interprétées comme un
engagement de la part de Microsoft, et Microsoft n’est pas en mesure de
garantir l’exactitude de toute information présentée après la date de
publication.
Ce document n’est fourni qu’à titre d’information. MICROSOFT NE DONNE
AUCUNE GARANTIE EXPRESSE OU IMPLICITE DANS CE DOCUMENT.
© 1998 Microsoft Corporation. Tous droits réservés.
Microsoft, ActiveX, BackOffice, le logo BackOffice, FrontPage, Visual Basic,
Visual C++, Visual J++, Win32, Windows, Windows NT et Visual Studio 97
sont des marques, déposées ou non, de Microsoft Corporation aux EtatsUnis et/ou dans d’autres pays.
Les autres noms ou marques cités dans ce document sont des marques
leurs propriétaires respectifs.
Sauf indication contraire, les noms de sociétés, de produits, de personnes ou
de personnages et/ou les données mentionnées dans ce document sont
fictifs et ne représentent en aucune manière des individus, des sociétés, des
produits ou des événements réels.
Référence Microsoft n° 098-80704
Table des matières
Introduction ............................................................................................................................................. 1
Processus de Data Warehousing ............................................................................................................ 2
Architectures de Data Warehouse ...................................................................................................... 3
Composants du Data Warehousing .................................................................................................... 4
Microsoft Data Warehousing Framework ............................................................................................ 5
Composants du Data Warehouse Framework ............................................................................. 6
Une norme d’échange d’informations – OLE DB................................................................................. 7
Un modèle unifié d’accès aux données basé sur COM ...................................................................... 7
Définition d’OLE DB ......................................................................................................................... 8
Définition d’ActiveX Data Objects .................................................................................................... 8
Métadonnées : Le ciment de la cohésion du Data Warehouse ........................................................... 10
Conception du Data Warehouse .......................................................................................................... 11
Le « magasin de données » du Data Warehouse ................................................................................. 12
Un SGBD relationnel évolutif et robuste ......................................................................................... 12
Fonctions analytiques OLAP intégrées ............................................................................................ 13
Réplication ....................................................................................................................................... 14
Importation/exportation et transformation des données ................................................................... 15
Objectifs de Data Transformation Services ...................................................................................... 15
Architecture de DTS ........................................................................................................................ 15
Composant DTS ........................................................................................................................ 17
Création de composants DTS ........................................................................................................... 18
Analyse et présentation des données .................................................................................................... 20
Microsoft Office ............................................................................................................................... 20
English Query................................................................................................................................... 20
Produits tierces parties ..................................................................................................................... 22
Administration système......................................................................................................................... 23
Microsoft Management Console ...................................................................................................... 23
Assistants ......................................................................................................................................... 23
Diagrammes visuels de bases de données ........................................................................................ 24
SQL Server Profiler ......................................................................................................................... 25
Analyseur de requête SQL Server .................................................................................................... 25
Assistant d’optimisation des requêtes............................................................................................... 26
Administration automatisée .............................................................................................................. 27
Conclusion.............................................................................................................................................. 28
i
Introduction
La capacité à prendre rapidement de meilleures décisions revêt une importance cruciale sur
les marchés actuels dominés par une forte concurrence. Les entreprises qui cherchent à
améliorer leurs processus de prise de décision peuvent être submergées par le volume et la
complexité démesurés des données fournies par leurs différents systèmes de production, et
cela est tout à fait compréhensible. La possibilité de mettre ces données à la disposition
d’un nombre élevé d’utilisateurs est l’un des défis les plus importants auxquels les
informaticiens sont à l’heure actuelle confrontés.
C’est la raison pour laquelle de nombreuses entreprises ont choisi de construire un Data
Warehouse, afin d’exploiter la richesse des informations de leurs systèmes de production et
de comprendre les problèmes pratiques de leur activité. Le Data Warehouse est un entrepôt
intégré d’informations collectées à partir d’autres systèmes, et représente la base sousjacente de l’aide à la décision et de l’analyse de données. Bien qu’il existe de nombreux
types de Data Warehouses, basés sur différentes méthodologies de conception, ils ont tous
en commun les caractéristiques suivantes :
 Les informations contenues dans un Data Warehouse sont organisées autour des
principaux sujets de l’entreprise (par exemple, clients, produits, ventes ou fournisseurs),
reflétant une approche orientée données.
 Les données brutes sont collectées à partir d’applications de production et
d’applications propriétaires non intégrées. Elles sont ensuite nettoyées, puis agrégées et
présentées sous une forme exploitable par les utilisateurs.
 L’architecture du Data Warehouse évolue au cours du temps en fonction des réactions
des utilisateurs et des découvertes effectuées – ce qui reflète la nature itérative du
processus.
Le Data Warehousing est intrinsèquement un processus complexe et a donc, d’un point de
vue historique, été long et coûteux. Au cours de ces dernières années, Microsoft a travaillé
avec les acteurs du marché à la création d’une plate-forme de Data Warehousing faisant
appel à une technologie de composants et à des produits de premier plan, qui puisse être
utilisée pour abaisser les coûts et améliorer l’efficacité de la création, de l’administration et
de l’utilisation d’un Data Warehouse. Microsoft a également développé plusieurs produits
et fonctions qui sont bien adaptés au Data Warehousing, tels que Microsoft ® SQL Server™
version 7.0. En les combinant avec des produits tierces parties qu’il est possible d’intégrer
à l’aide du Microsoft Data Warehousing Framework, les clients disposent d’un large
éventail de produits interopérables de qualité, qui pourront répondre à leurs besoins en
matière de Data Warehousing.
Microsoft SQL Server 7.0 propose de nombreuses fonctionnalités pour prendre en charge
le Data Warehousing. Conjointement avec le Data Warehousing Framework, Microsoft
fournit une plate-forme pour le Data Warehousing qui réduit les coûts et la complexité,
tout en améliorant l’efficacité des opérations de Data Warehousing.
Le Data Warehousing est par nature itératif et nécessite des modifications constantes
pendant la durée de vie de l’application.
1
Processus de Data Warehousing
Conception
Design
Populate
Alimentation
AAnalyse
nalyze
Du point de vue des technologies de l’information, le Data Warehousing a pour objectif de
fournir aux acteurs de l’entreprise les informations dont ils ont besoin au moment
opportun. Il s’agit dans tous les cas d’un processus continu et non d’une solution figée, et il
nécessite une approche différente de celle mise en œuvre pour le développement de
systèmes transactionnels.
Un Data Warehouse est un ensemble de données destinées à venir en appui du processus
de prise de décision du personnel de direction ; il est orienté sujet, intégré, variable au
cours du temps et non volatile1. En termes simples, cela signifie que le Data Warehouse est
focalisé sur un concept métier (par exemple, les ventes) plutôt que sur un processus métier
(par exemple, l’émission des factures) et qu’il contient toutes les informations appropriées
sur ce concept rassemblées à partir de plusieurs systèmes informatiques. Ces informations
sont collectées et représentées à certaines périodes déterminées et n’évoluent pas
rapidement.
Le Data Warehouse intègre des données de production en utilisant des conventions de
dénomination, des mesures, des attributs physiques et une sémantique caractérisés par leur
cohérence. La première étape dans la construction du Data Warehouse est un processus de
gestion : elle consiste à déterminer les sujets à inclure et à développer un ensemble de
définitions acceptées pas tous. Elle nécessite des entretiens avec les utilisateurs finals, les
analystes métier et l’encadrement, pour appréhender et documenter l’étendue des besoins
en informations. Ce n’est qu’après une compréhension approfondie des problèmes de
l’activité que le processus logique pourra être converti en Data Warehouse physique.
Après la conception physique, des systèmes sont mis en place pour remplir le Data
Warehouse en continu à partir de systèmes de production. Dans la mesure où ces derniers
et le Data Warehouse représentent différemment les données, l’alimentation du Data
Warehouse nécessite des opérations de transformation des données : agrégation,
conversion, décodage, élimination des données incorrectes, etc. Les opérations suivantes
doivent être automatisées afin d’être réalisées de manière incessante : extraction,
transformation et déplacement des données source aussi fréquents que nécessaire pour
satisfaire les exigences métier du Data Warehouse.
1
W.H. Inmon. Building the Data Warehouse 1992
2
Dans l’environnement de production, les données sont toujours actualisées et pertinentes
au moment où l’on y accède. Par exemple, une application de saisie de commandes
présente systématiquement la quantité disponible en stock pour chaque produit au moment
de la consultation. Si l’on souhaite connaître la quantité en stock d’un produit donné à
deux moments différents, même relativement proches, les résultats obtenus peuvent
différer. En revanche, les données d’un Data Warehouse représentent les informations sur
une longue période de temps et sont censées être exactes à un moment donné. En effet, un
Data Warehouse contient une longue série d’instantanés sur les zones clé de l’activité.
Enfin, les informations sont mises à la disposition des analystes métier et des cadres aux
fins de consultation, d’analyse et de génération d’états. La phase d’analyse peut être
facilitée par de nombreux outils, allant des générateurs d’états simples jusqu’aux outils de
Data Mining évolués. Toutefois, c’est le travail d’analyse qui guide les itérations finales du
processus de Data Warehousing, à savoir les révisions de la conception, pour prendre en
compte de nouvelles informations, améliorer les performances du système ou introduire de
nouveaux types d’analyse. Une fois ces modifications effectuées, le processus redémarre et
continue pendant toute la durée de vie du Data Warehouse.
De nombreuses méthodologies ont été proposées pour la conception de Data Warehouses
afin de simplifier les opérations informatiques nécessaires à une prise en charge
permanente du processus. Cela a conduit à de multiples débats sur la meilleure architecture
pour la mise en œuvre de Data Warehouses dans les entreprises.
Architectures de Data Warehouse
Même si les approches pour la mise en œuvre pratique de systèmes d’aide à la décision
sont nombreuses, il existe deux principaux types de Data Warehouses : les Data
Warehouses d’entreprise et les Data Marts. Chacune des deux solutions a ses partisans, et
présente un certain nombre d’atouts et d’inconvénients.
Le Data Warehouse d’entreprise contient des informations globales à l’entreprise, qui sont
intégrées à partir de plusieurs sources de production pour une analyse de données
consolidées. Il comporte généralement plusieurs domaines d’informations (sujets) tels que
les clients, les produits et les ventes, et il est utilisé pour la prise de décisions tant tactiques
que stratégiques. Un Data Warehouse d’entreprise contient des données instantanées
détaillées et des informations agrégées, et sa capacité totale de stockage des données peut
aller de 50 Go jusqu’à plus d’un téra-octet. La construction et la gestion des Data
Warehouses d’entreprise peut être longue et coûteuse. Leur création est généralement
menée à bien par des départements informatiques centralisés, dans une approche
descendante.
Les Data Marts contiennent un sous-ensemble des données de l’entreprise destiné à être
utilisé par un département ou une division. A la différence des Data Warehouses
d’entreprise, les Data Marts sont souvent construits suivant une approche ascendante par
des ressources départementales, pour une application d’aide à la décision spécifique ou un
groupe d’utilisateurs particulier. Le contenu d’un Data Mart peut être un sous-ensemble du
contenu d’un Data Warehouse d’entreprise (Data Mart dépendant), mais il est
généralement directement issu des sources de données de production (Data Mart
indépendant).
Quelle que soit l’architecture, les Data Warehouses et les Data Marts sont construits et
actualisés par le processus itératif décrit plus haut. En outre, les deux approches ont des
besoins technologiques similaires.
3
Composants du Data Warehousing
Un Data Warehouse se compose toujours de plusieurs composants, pouvant inclure :
 des sources de données de production ;
 des outils de conception/développement ;
 des outils d’extraction et de transformation des données ;
 un système de gestion de bases de données ;
 des outils d’accès et d’analyse de données ;
 des outils de gestion système.
Il est évident que, dans les mises en œuvre client, tous ces composants ne seront pas
forcément des produits Microsoft. En fait, un Data Warehouse sera souvent construit à
l’aide d’une gamme étendue d’outils provenant de plusieurs fournisseurs et associés à une
programmation personnalisée.
Il y a plusieurs années, Microsoft reconnaissait la nécessité vitale d’un ensemble de
technologies d’intégration permettant à ces produits de nombreux fournisseurs de
fonctionner facilement ensemble. Cela a conduit à la création du Microsoft Data
Warehousing Framework, qui a non seulement servi au développement de produits
Microsoft tels que SQL Server 7.0, mais également au développement des technologies
nécessaires à l’intégration de produits de nombreux autres fournisseurs, partenaires ou
concurrents de Microsoft.
4
Microsoft Data Warehousing Framework
Le Data Warehouse Framework a pour but de simplifier la conception, la mise en œuvre et
l’administration des solutions de Data Warehousing. Il a été conçu pour fournir :
 une architecture ouverte facile à intégrer, qui pourra être étendue par des fournisseurs
tierces parties ;
 des services d’importation, d’exportation, de validation et de nettoyage de données
hétérogènes avec un suivi facultatif de leur historique ;
 des métadonnées intégrées pour des outils de conception de Data Warehouse,
d’extraction/transformation de données, de gestion de serveurs et d’analyse d’utilisateur
final ;
 des services de gestion de base pour la planification, la gestion du stockage, l’analyse
des performances, les alertes/événements et la notification.
Le Microsoft Data Warehousing Framework propose un canevas pour le développement et
l’intégration de produits sur la plate-forme Microsoft.
Utilisation
Conception
Sources
opérationnelles
Transformation
/nettoyage des
données
Schéma Transformation Planification
Annuaire info
Gestion
Conception Data Warehouse/Data Mart
Data Marts
ou Data
Warehouse
Répl
Outils
utilisateur
final
Publication
d’infos
OLAP
Référentiel (métadonnées persistantes partagées)
Gestion du Data Warehouse
Flux des
données
Flux des
métadonnées
Le Data Warehousing Framework a été entièrement conçu en vue de fournir une
architecture ouverte qui puisse être facilement étendue par les clients et les partenaires de
Microsoft à l’aide de technologies standard. Les entreprises peuvent ainsi choisir les
meilleurs composants en étant assurées qu’elles parviendront à les intégrer.
La facilité d’utilisation est une raison primordiale qui pousse les clients et les développeurs
indépendants à choisir le Microsoft Data Warehousing Framework. Microsoft fournit un
ensemble orienté objet de composants permettant de gérer des informations dans
l’environnement distribué. Microsoft fournit aussi des produits d’entrée de gamme et de
haut de gamme pour les nombreuses étapes du processus de Data Warehousing.
5
Composants du Data Warehouse Framework
Le Data Warehousing Framework décrit les relations entre les différents composants
utilisés pour la construction, l’utilisation et la gestion d’un Data Warehouse. Au cœur du
Microsoft Data Warehousing Framework, on trouve l’ensemble des technologies de prise
en charge composées de la couche de transport des données (OLE DB) et du référentiel de
métadonnées intégré. Ces deux technologies autorisent l’interopérabilité des nombreux
produits et outils impliqués dans le processus de Data Warehousing.
La construction du Data Warehouse requiert un ensemble d’outils pour la description de la
conception logique et physique des sources de données et de leurs destinations dans le
Data Warehouse ou les Data Marts. Les données de production doivent passer par une
étape de nettoyage et de transformation avant d’être placées dans le Data Warehouse ou les
Data Marts, pour se conformer aux définitions établies lors de la phase de conception. Ce
processus de traitement des données comporte souvent plusieurs niveaux, particulièrement
avec les architectures de Data Warehouse d’entreprise, mais elle a été volontairement
simplifiée dans le diagramme précédent.
L’accès aux informations du Data Warehouse s’effectue à l’aide d’outils d’utilisateur final
tels que des produits de productivité de bureau, des produits d’analyse spécialisés et des
programmes personnalisés. Dans l’idéal, les accès utilisateur s’effectuent par
l’intermédiaire d’une fonction d’annuaire qui permet de rechercher les données
appropriées, afin de résoudre les problèmes métier, et fournit une couche de sécurité entre
les utilisateurs et les systèmes centraux.
Enfin, un large éventail d’outils peuvent entrer en jeu pour la gestion de l’environnement
de Data Warehouse, comme la planification des tâches répétitives et la gestion des réseaux
comportant plusieurs serveurs.
Microsoft Repository fournit le point d’intégration pour les métadonnées (par exemple, les
données décrivant les données) partagées par les différents outils utilisés dans le processus
de Data Warehousing. Les métadonnées partagées autorisent l’intégration transparente de
plusieurs outils de différents fournisseurs, sans la nécessité d’interfaces spécialisées entre
chacun des produits. L’architecture Microsoft Repository est décrite en détail plus loin
dans ce document.
De même, OLE DB fournit un accès normalisé très performant à un large éventail de
données et autorise l’intégration de plusieurs types de données. OLE DB est décrit en
détail dans la section suivante.
6
Une norme d’échange d’informations – OLE DB
L’accès à toutes les sources de données possibles nécessite une connectivité et une
interopérabilité simples avec des bases de données hétérogènes et constitue l’un des
problèmes techniques les plus importants dans la mise en œuvre d’un Data Warehouse. Le
Data Warehousing Framework se base sur la norme de transport de données définie par
Microsoft, Universal Data Access, ainsi que sur les interfaces OLE DB. Universal Data
Access est une initiative en matière de plate-forme, d’application et d’outils qui définit et
met en œuvre des normes et des technologies ; elle constitue un élément clé du système de
référence de Microsoft pour le développement d’applications, l’architecture Microsoft
DNA (Windows® Distributed interNet Applications).
Universal Data Access fournit un accès extrêmement performant à de nombreuses sources
de données et d’informations sur plusieurs plates-formes, ainsi qu’une interface de
programmation facile à utiliser qui fonctionne avec pratiquement tous les outils ou
langages et permet ainsi d’exploiter les compétences techniques des développeurs. Les
technologies qui prennent en charge Universal Data Access permettent aux entreprises de
créer des solutions faciles à maintenir et d’utiliser les outils, applications et sources de
données hauts de gamme de leur choix sur le client, le niveau intermédiaire ou le serveur.
Un modèle unifié d’accès aux données basé sur COM
L’une des forces de la stratégie Universal Data Access de Microsoft est sa mise en œuvre
par l’intermédiaire d’un ensemble commun d’interfaces orientées objet. Celles-ci sont
basées sur le modèle d’objet composant (COM, Component Object Model) de Microsoft,
la technologie objet la plus largement mise en œuvre à travers le monde. COM est devenu
le choix des développeurs dans le monde entier car il fournit :
 les services intégrés les plus riches, tels que les transactions, la sécurité, la mise en file
d’attente de messages et l’accès aux données, pour prendre en charge la gamme de
scénarios applicatifs la plus étendue ;
 le choix le plus large d’outils de plusieurs fournisseurs utilisant différents langages de
développement ;
 la base de clients installés la plus large pour la personnalisation d’applications et la
réutilisation de composants ;
 une interopérabilité éprouvée avec les investissements existants des utilisateurs et des
développeurs.
Grâce à la cohérence et à l’interopérabilité procurées par COM, l’architecture Universal
Data Access de Microsoft est ouverte et fonctionne avec virtuellement n’importe quel outil
ou langage de programmation. En outre, cette architecture peut également fournir un
modèle d’accès aux données cohérent à tous les niveaux de l’architecture d’application
moderne.
Microsoft Universal Data Access expose des interfaces basées sur COM, qui sont
optimisées pour le développement d’applications de bas niveau et de haut niveau :
OLE DB et ADO.
7
Définition d’OLE DB
OLE DB est l’interface de programmation stratégique de niveau système de Microsoft
permettant de gérer des données dans toute l’entreprise. OLE DB est une spécification
ouverte qui repose sur la réussite d’ODBC et a été conçu pour fournir une norme ouverte
d’accès à tous les types de données. Alors qu’ODBC a été créé pour accéder à des bases de
données relationnelles, OLE DB est conçu pour accéder à des sources d’informations
relationnelles et non relationnelles incluant :
 données ISAM/VSAM et bases de données hiérarchiques de grands systèmes ;
 banques de messages électroniques et de systèmes de fichiers ;
 données textes, graphiques et géographiques ;
 objets métier personnalisés ;
 autres sources de données.
OLE DB définit une collection d’interfaces COM qui encapsule différents services de
système de gestion de bases de données. Ces interfaces permettent de créer des composants
logiciels mettant en œuvre ces services. Les composants OLE DB sont constitués de
fournisseurs de données (qui contiennent et exposent les données), de composants
d’utilisation des données et de composants de services (qui traitent et transportent les
données, comme des processeurs de requêtes ou des moteurs de curseurs).
Les interfaces OLE DB sont conçues pour aider à intégrer des composants de manière
transparente afin que les fournisseurs de composants OLE DB puissent commercialiser
rapidement des composants OLE DB de haute qualité. En outre, OLE DB inclut une
passerelle vers ODBC pour autoriser une prise en charge continue des nombreux pilotes de
bases de données relationnelles ODBC actuellement disponibles.
Définition d’ActiveX Data Objects
ActiveX™ Data Objects (ADO) est l’interface stratégique de Microsoft pour la
programmation de niveau application permettant d’accéder à des données et des
informations. ADO offre un accès cohérent, extrêmement performant aux données et prend
en charge un grand nombre de besoins en développement, tels que la création de clients
frontaux de bases de données et d’objets métier de niveau intermédiaire en utilisant des
applications, des outils, des langages ou des navigateurs Internet. ADO est conçu pour être
une interface de données destinée au développement de solutions client-serveur et Web à
un ou plusieurs niveaux.
8
Interface utilisateur et navigation
Processus métier
Sources de
données
Figure 1. Architecture Universal Data Access
ADO fournit une interface de niveau application facile à utiliser avec OLE DB, et qui
fournit l’accès sous-jacent aux données. ADO est mis en œuvre de manière compacte, avec
un trafic réseau minimal dans des scénarios clé et un nombre minimal de couches entre le
frontal et la source de données, ce qui permet d’aboutir à une interface légère,
extrêmement performante. ADO est facile à utiliser car il est appelé à l’aide de l’interface
d’automation COM : une métaphore familière disponible à partir de tous les outils et
langages de bases de données RAD du marché. Et comme ADO a été conçu pour associer
les meilleures fonctionnalités de RDO et DAO et en fin de compte les remplacer, il utilise
des conventions similaires avec une sémantique simplifiée, afin de constituer l’étape
suivante naturelle pour les développeurs d’aujourd’hui.
9
Métadonnées : Le ciment de la cohésion du Data Warehouse
A l’heure actuelle, l’un des défis les plus importants en matière de mise en œuvre consiste
à intégrer tous les outils nécessaires pour concevoir, transformer, stocker et gérer un Data
Warehouse. La capacité à partager et à réutiliser des métadonnées, c’est-à-dire des données
sur les données, réduit considérablement le coût et la complexité de la construction, de
l’utilisation et de la gestion de Data Warehouses. De nombreux produits de Data
Warehousing incluent un référentiel de métadonnées propriétaire qui ne peut pas être
utilisé par d’autres composants du Data Warehouse. Chaque outil doit pouvoir accéder
facilement aux métadonnées créées par un autre outil ou encore les créer ou les améliorer
tout aussi facilement, tout en étendant le modèle de métadonnées pour répondre aux
besoins particuliers de l’outil en question.
Considérons l’exemple d’un Data Warehouse comportant des métadonnées partagées. Les
métadonnées des systèmes de production sont stockées dans le référentiel par des outils de
conception et de transformation de données. Ce modèle logique et physique est utilisé par
des produits de transformation pour extraire, valider et nettoyer les données avant de les
charger dans la base de données. Le système de gestion de bases de données utilisé peut
être relationnel et/ou multidimensionnel. Les outils d’accès et d’analyse des données
permettent d’accéder aux informations du Data Warehouse. L’annuaire d’informations
intègre les métadonnées techniques et métier afin de permettre de retrouver et de lancer
facilement des requêtes, des états et des applications existants pour le Data Warehouse.
Le Data Warehouse Framework se base sur les métadonnées partagées de
Microsoft Repository, qui est fourni comme composant de Microsoft SQL Server 7.0.
Microsoft Repository est une base de données qui stocke des informations descriptives sur
des composants logiciels et leurs relations ; il se compose d’un modèle d’informations
ouvert (OIM, Open Information Model) et d’un ensemble d’interfaces COM publiées. Les
modèles OIM sont des modèles d’objet pour des types particuliers d’informations ; ils sont
suffisamment souples pour prendre en charge de nouveaux types d’informations et
suffisamment extensibles pour répondre aux besoins d’utilisateurs ou de fournisseurs
particuliers. Microsoft a déjà développé des OIM en collaboration avec d’autres sociétés,
pour Database Schema, Data Transformations et OLAP. Les modèles futurs incluront la
réplication, la planification des tâches, des modèles sémantiques et un annuaire
d’informations combinant métadonnées métier et techniques.
Le Metadata Coalition, un consortium industriel regroupant 53 fournisseurs, qui se
consacre à la mise au point d’une norme standard d’échange de métadonnées entre
fournisseurs, a annoncé la prise en charge de Microsoft Repository, et les OIM Repository
ont fait l’objet d’une prise en charge étendue de la part des développeurs indépendants
tierces parties.
10
Conception du Data Warehouse
La phase de développement du processus de Data Warehousing commence souvent par la
création d’un modèle métier dimensionnel décrivant les mesures et les dimensions
importantes du domaine (sujet) sélectionné, en fonction des besoins des utilisateurs. A la
différence des systèmes de traitement transactionnel en ligne (OLTP) dans lesquels les
données sont organisées de manière normalisée, les données du Data Warehouse sont
organisées d’une manière fortement dénormalisée pour accroître les performances
d’interrogation lors du stockage dans un système de gestion de bases de donnés
relationnelles.
Figure 4. Un exemple de schéma en étoile. Dans ce type de schéma de base de données,
une table de « faits » centrale est liée à des tables d’attributs ou de dimensions.
Les bases de données relationnelles utilisent souvent des schémas en étoile et en flocon
afin de fournir les meilleurs temps de réponse possibles pour des requêtes complexes. Les
schémas en étoile contiennent une table de faits centrale dénormalisée pour le sujet
concerné et plusieurs tables de dimensions contenant des informations descriptives sur les
dimensions du sujet2. La table de faits centrale peut contenir plusieurs millions de lignes.
Les informations faisant l’objet d’accès fréquents sont souvent pré-agrégées et résumées,
afin d’améliorer encore les performances.
Même si le schéma en étoile est avant tout considéré comme un outil permettant à
l’administrateur de bases de données d’accroître les performances et de simplifier la
conception du Data Warehouse, il constitue également une convention utile pour
représenter les informations d’un Data Warehouse sous une forme plus exploitable pour les
utilisateurs.
2
The Data Warehousing Institute, « Star and Snowflake Schema », 1996
11
Le « magasin de données » du Data Warehouse
Le cœur du Data Warehouse est constitué par une base de données, et il est vital de faire
reposer ces systèmes sur un moteur extrêmement performant, qui répondra aux besoins tant
actuels que futurs de l’entreprise. Les systèmes de gestion de bases de données
relationnelles sont les réservoirs les plus courants pour les volumes d’informations
importants conservés dans des Data Warehouses. Ces systèmes relationnels sont de plus en
plus souvent complétés par des serveurs OLAP multidimensionnels offrant des capacités
de navigation améliorées et de meilleures performances pour les requêtes complexes. Les
fonctions permettant de répliquer des bases de données de manière fiable à partir de Data
Warehouses centraux vers des Data Marts dépendants sont également importantes, de
même que celles qui permettent de garantir la cohérence entre des Data Marts en miroir
disséminés géographiquement.
Un SGBD relationnel évolutif et robuste
Microsoft SQL Server 7.0 offre plusieurs fonctionnalités qui en font une excellente plateforme de base de données pour les Data Warehouses et les Data Marts. Il s’agit notamment
des fonctionnalités suivantes :
 prise en charge de bases de données de plusieurs téra-octets permettant de gérer les
Data Warehouses les plus volumineux ;
 évolutivité pour les bases de données très volumineuses, mais également dans toute
l’entreprise vers les serveurs départementaux et même les ordinateurs portables avec
l’édition Desktop compatible à 100 % au niveau du code, qui offre une souplesse
extrême et des possibilités importantes d’accès à des sources de données centrales ;
 traitement évolué des requêtes prenant en charge l’optimisation et l’exécution des
requêtes complexes typiques des applications de Data Warehouses, comme les
jointures en étoile ;
 parallélisme intra-requête qui offre de meilleures performances en scindant une
requête complexe en ses éléments constitutifs et en répartissant la charge de travail
sur plusieurs processeurs, y compris des serveurs distants ;
 utilitaires extrêmement performants pour l’optimisation des performances, le
chargement des données et la construction des index ;
 fonctions de jointures hétérogènes autorisant l’extraction et la consolidation
d’informations à partir de n’importe quelle source OLE DB.
Le moteur de base de données relationnelle de Microsoft SQL Server 7.0 convient à
pratiquement toutes les tailles et toutes les complexités de Data Warehouses. Toutefois, la
mise en œuvre d’un Data Warehouse nécessite généralement plus qu’une simple base de
données centrale. En pratique, les entreprises mettront en œuvre des systèmes d’aide à la
décision avec des outils analytiques supplémentaires et des architectures informatiques
distribuées. Microsoft SQL Server 7.0 inclut des fonctions essentielles pour la gestion de
ces tâches supplémentaires.
12
Fonctions analytiques OLAP intégrées
OLAP (Online Analytical Processing) est une technologie qui est de plus en plus utilisée et
peut optimiser considérablement l’analyse d’une activité. Historiquement, OLAP a été
caractérisée par le coût élevé de ses outils, la difficulté de sa mise en œuvre et le manque
de souplesse de son déploiement. SQL Server OLAP Services est une nouvelle fonction
OLAP complète fournie en tant que composant de Microsoft SQL Server 7.0. Elle inclut
un serveur de niveau intermédiaire qui permet aux utilisateurs d’effectuer des analyses
sophistiquées sur des volumes de données importants avec des résultats très performants.
Parmi les autres composants de SQL Server OLAP Services figurent une mémoire cache
côté client et un moteur de calcul appelé PivotTable® Service, qui aide à améliorer les
performances et à réduire le trafic réseau. PivotTable Service permet également aux
utilisateurs d’effectuer des analyses lorsqu’ils sont déconnectés du réseau de l’entreprise.
Figure 2. SQL Server OLAP Services est un serveur OLAP de niveau intermédiaire qui
simplifie la navigation des utilisateurs et améliore les performances des requêtes d’accès
aux informations du Data Warehouse.
Base de
données
transactionnelle
Agrégats
Détails
Serveur
OLAP Serv
Cache MD
OLE DB
Excel 9.0
pour
OLAP et autres
clients
Analyse BD
OLAP est un composant clé du Data Warehousing et SQL Server OLAP Services fournit
une fonctionnalité essentielle pour une large gamme d’applications, depuis la génération
d’états d’entreprise jusqu’à l’aide à la décision évoluée. La prise en charge de la
fonctionnalité OLAP dans SQL Server rend l’analyse multidimensionnelle beaucoup plus
abordable et permet à une audience plus large de bénéficier des avantages d’OLAP. Cela
inclut non seulement les organisations plus petites, mais également les groupes et les
personnes au sein d’entreprises de plus grande taille qui étaient auparavant exclus du
monde OLAP en raison du coût et de la complexité des produits actuels.
Avec la grande diversité d’outils et d’applications prenant en charge des applications
OLAP par l’intermédiaire de l’interface Microsoft OLE DB pour OLAP, SQL Server
OLAP Services aidera à augmenter le nombre d’organisations ayant accès à des outils
d’analyse sophistiqués et réduira les coûts du Data Warehousing.
Pour plus d’informations sur les fonctions de SQL Server OLAP Services, reportez-vous
au document intitulé « Microsoft Decision Support Services » (réf. n° 098-80705).
13
Réplication
La création de Data Marts dépendants distribués à partir d’un Data Warehouse central, ou
même la duplication fiable du contenu d’un Data Mart indépendant, requiert la capacité à
répliquer les informations de manière fiable. Microsoft SQL Server 7.0 inclut des fonctions
permettant de distribuer des informations à partir d’un Data Warehouse de publication
central vers plusieurs Data Marts abonnés. Les informations peuvent être partitionnées en
fonction de l’heure, de l’emplacement géographique, etc. dans le cadre du processus de
réplication.
SQL Server offre de nombreuses technologies de réplication qui peuvent être adaptées aux
besoins particuliers de votre application. Chaque technologie présente différents avantages
et restrictions dans les trois domaines importants suivants :
 cohérence transactionnelle ;
 autonomie de site ;
 partitionnement des données pour éviter les conflits.
Les besoins dans ces trois domaines varient d’une application distribuée à l’autre.
Dans la plupart des applications d’aide à la décision, les données ne sont pas mises à jour
sur les sites individuels ; elles sont préparées en un lieu central et transmises par
mécanisme « push » vers les serveurs de bases de données distribuées pour les accès à
distance. C’est la raison pour laquelle on utilise souvent la réplication instantanée pour
distribuer les données.
Comme son nom l’indique, la réplication instantanée prend une photo, ou instantané, des
données publiées dans la base de données à un moment donné. Au lieu d’exécuter des
commandes INSERT, UPDATE et DELETE (comme la réplication transactionnelle) ou les
modifications de données (comme la réplication par fusion), les abonnés sont mis à jour
par un rafraîchissement total de l’ensemble des données. Par conséquent, la réplication
instantanée envoie toutes les données à l’abonné au lieu d’envoyer seulement les
modifications. Si le volume d’informations à transmettre est très important, cela peut
nécessiter beaucoup de ressources réseau. Pour décider si la réplication instantanée est
appropriée, il faut évaluer le volume total des données par rapport à leur fréquence de
modification.
La réplication instantanée est le type de réplication le plus simple, qui garantit une
cohérence automatique entre le publieur et l’abonné. Il procure aussi une autonomie
importante si les abonnés ne mettent pas à jour les données. Ce type de réplication est une
bonne solution pour les abonnés en lecture seule qui n’ont pas besoin des données les plus
récentes et peuvent être totalement déconnectés du réseau en l’absence de mises à jour.
Toutefois, SQL Server propose un large éventail de choix en matière de réplication pour
répondre aux besoins des applications. Pour plus d’informations sur les fonctions de
réplication proposées par SQL Server 7.0, reportez-vous au livre blanc « SQL Server 7.0
Replication ».
14
Importation/exportation et transformation des données
Avant de pouvoir charger les données dans le Data Warehouse, il faut d’abord les
transformer en leur attribuant un format intégré et cohérent. Une transformation est la suite
des opérations procédurales qui sont appliquées aux informations d’une source de données
pour que celles-ci puissent être stockées dans la destination spécifiée. Data Transformation
Services (DTS) est une nouvelle fonction de Microsoft SQL Server 7.0, qui prend en
charge de nombreux types de transformations tels que les correspondances de colonnes
simples, le calcul de nouvelles valeurs à partir d’un ou de plusieurs champs source, la
décomposition d’un champ en plusieurs colonnes de destination, etc.
Objectifs de Data Transformation Services
Data Transformation Services a été créé pour remplir les fonctions suivantes :
1. Augmenter la qualité des importations, des exportations et des transformations de
données hétérogènes en utilisant OLE DB.
2. Fournir une architecture extensible qui soit accessible aux développeurs indépendants,
aux clients et aux consultants.
3. Partager des métadonnées riches concernant les sources, les destinations, les
transformations et les historiques grâce à l’intégration avec les modèles OIM de
Microsoft Repository.
Data Transformation Services permet à l’utilisateur d’importer, d’exporter et de
transformer des données à destination et à partir de plusieurs sources de données en
utilisant une architecture basée à 100 % sur OLE DB. Les sources de données OLE DB
incluent non seulement des systèmes de bases de données mais également des applications
de bureau telles que Microsoft Excel. Microsoft fournit des interfaces OLE DB natives
pour SQL Server et Oracle. En outre, Microsoft a développé une enveloppe OLE DB qui
fonctionne en association avec les pilotes ODBC existants pour autoriser l’accès à d’autres
sources relationnelles. Les fichiers texte délimités ou à champs fixes sont également pris en
charge de manière native.
Architecture de DTS
Les définitions des transformations DTS sont stockées dans Microsoft Repository, SQL
Server ou des composants COM structurés. L’accès aux sources de données de production
s’effectue par l’intermédiaire d’OLE DB, ce qui permet d’accéder aux sources de données
tant relationnelles que non relationnelles. L’outil de chargement données lit un ensemble
de lignes à partir de la source et extrait chaque ligne de la source. Cet outil exécute des
scripts (VBScript, JScript et PerlScript) pour copier, valider ou transformer des données de
la source vers la destination. Il est possible de créer des objets de transformation
personnalisés pour un nettoyage évolué des données. Les nouvelles valeurs de la
destination sont renvoyées vers l’outil de chargement de données et transmises à la
destination au moyen de transferts de données à grande vitesse. Les destinations peuvent
être OLE DB, ODBC, des fichiers ASCII à champs fixes, des fichiers ASCII délimités et
HTML.
15
Figure 3. Architecture de DTS. Les données sont extraites des systèmes source à l’aide
d’un outil de chargement de données OLE DB et peuvent être transformées avant d’être
envoyées vers des destinations OLE DB.
Outil de chargement DTS
ENTREE
SORTIE
Les transformations et les logiques de validation complexes peuvent être mises en œuvre
au moyen d’un moteur de script. Ces scripts peuvent appeler des méthodes de n’importe
quel objet COM pour modifier ou valider la valeur d’une colonne. Les développeurs
expérimentés peuvent créer des objets de transformation COM réutilisables, offrant des
fonctions de nettoyage évoluées. Il est possible de créer des tâches personnalisées
transférant des fichiers via FTP ou lançant des processus externes.
Les développeurs indépendants et les consultants peuvent créer de nouvelles sources de
données et de nouvelles destinations en fournissant des interfaces OLE DB. L’outil de
chargement de données interrogera l’interface OLE DB pour n’importe quel fournisseur,
afin de déterminer si un chargement de données à grande vitesse est pris en charge ; si ce
n’est pas le cas, les mécanismes de chargement standard seront utilisés.
Même si les normes telles qu’ANSI SQL-92 ont amélioré l’interopérabilité entre les
moteurs de bases de données relationnelles, les fournisseurs se différencient toujours sur le
marché en ajoutant des extensions certes utiles mais propriétaires à ANSI SQL. SQL
Server offre un langage de programmation simple connu sous le nom de Transact-SQL, qui
fournit un traitement conditionnel de base et un contrôle simple des répétitions. Oracle,
Informix et les autres fournisseurs proposent tous des extensions SQL similaires mais
incompatibles. L’architecture SQL pass-through du moteur de transformation de DTS
garantit que 100 % des fonctionnalités de la source et de la destination sont à la disposition
des clients utilisant le moteur de transformation. Cela permettra aux clients d’exploiter les
scripts et les procédures stockées qu’ils ont déjà développés et testés en les appelant
simplement à partir du moteur de transformation. L’architecture pass-through simplifie
considérablement le développement et le test, car DTS ne modifie pas ou n’interprète pas
l’instruction SQL exécutée. Toute instruction qui fonctionne à travers l’interface native du
SGBD fonctionnera exactement de la même façon lors d’une transformation.
Data Transformation Services enregistrera et documentera l’historique de chaque
transformation dans le référentiel, afin que les clients puissent savoir d’où venaient leurs
données. L’historique des données peut être suivi au niveau table et au niveau ligne dans
une table. On bénéficie ainsi d’une piste d’audit complète pour les informations du Data
Warehouse. L’historique des données est partagé par les produits de plusieurs fournisseurs.
16
Les composants Data Transformation Services et l’historique des données peuvent être
stockés au niveau central dans Microsoft Repository. Cela inclut les définitions des
transformations, les scripts VB, les scripts Java et l’historique d’exécution des composants.
L’intégration avec le référentiel permettra aux tiers de se baser sur l’infrastructure fournie
par le moteur de transformation. L’exécution des composants DTS peut être planifiée à
l’aide d’un calendrier intégré ou bien s’effectuer de manière interactive ou en réponse à
des événements système.
Composant DTS
Le composant Data Transformation Services est une description complète de l’ensemble
du travail à effectuer dans le cadre du processus de transformation. Chaque composant
définit une ou plusieurs tâches à exécuter selon une séquence coordonnée. Un composant
DTS peut être créé interactivement en utilisant l’interface utilisateur graphique ou bien par
n’importe quel langage prenant en charge l’Automation OLE. Le composant DTS peut être
stocké dans Microsoft Repository, dans SQL Server ou en tant que fichier COM de
stockage structuré. Une fois récupéré à partir du référentiel ou du fichier de stockage
structuré, le composant peut être exécuté de la même manière qu’un composant DTS qui
avait été créé de manière interactive.
Figure 4. Les composants DTS peuvent contenir plusieurs tâches, aussi simples qu’une
correspondance de tables élémentaire ou aussi complexes que l’appel à un processus de
nettoyage de données externe.
Tâche
Task
Task 11
Source
Source
OLE DB
DB
OLE
Tâche
Task
Task 22
Source
Query
Requête
Destination
Destination
Destination
Destination
Java
Script
VB
VB
Script
Java
COM
Objet
Object
COM
Tâche
Task
Task 33
External
EXE
Tâche
3 EXE
externe
Tâche
Task
Task N
N
Une tâche définit une partie du travail à effectuer dans le cadre du processus de
transformation, et un composant DTS se compose d’une ou de plusieurs tâches. Une tâche
peut déplacer et transformer des données hétérogènes à partir d’une source OLE DB vers
une destination OLE DB en utilisant l’outil de chargement de données DTS, exécuter un
script ou lancer un programme externe. Les tâches sont ensuite exécutées étape par étape.
17
Les étapes coordonnent le déroulement et l’exécution des tâches dans le composant DTS.
Certaines tâches doivent être exécutées selon une séquence particulière. Par exemple, il
faut avoir créé une base de données (tâche A) avant de pouvoir créer une table (tâche B).
C’est un exemple de relation fin-début entre la tâche A et la tâche B ; la tâche B doit, par
conséquent, avoir une contrainte de priorité par rapport à la tâche A. Chaque tâche est
exécutée lorsque toutes les contraintes de priorité ont été satisfaites. Les tâches peuvent
être exécutées de façon conditionnelle en fonction de conditions d’exécution. Plusieurs
tâches peuvent être exécutées en parallèle pour améliorer les performances. Par exemple,
un composant peut charger simultanément des données à partir d’Oracle et de DB2 dans
des tables séparées. Le step object commande aussi la priorité de la tâche. La priorité
d’une étape détermine la priorité de la thread Win32 exécutant la tâche.
L’outil de chargement de données DTS est un fournisseur de services OLE DB qui fournit
l’infrastructure pour assurer l’importation, l’exportation et la transformation des données
entre magasins de données hétérogènes. OLE DB est l’interface stratégique de Microsoft
pour l’accès à la gamme la plus large possible de magasins de données relationnels et non
relationnels. L’outil de chargement de données DTS est un serveur COM in-process à
grande vitesse qui déplace et transforme les ensembles de lignes OLE DB.
Une transformation est l’ensemble des opérations procédurales qui doivent être appliquées
à l’ensemble de lignes source avant que celui-ci puisse être stocké dans la destination
voulue. L’outil de chargement de données DTS fournit une architecture COM extensible
qui autorise les validations et les transformations complexes lorsque les données sont
transférées de la source vers la destination. L’outil de chargement de données met toute la
puissance des langages de script à la disposition du composant DTS. Cela permet
d’exprimer une logique procédurale complexe sous la forme de scripts simples et
réutilisables. Ces scripts peuvent valider, convertir ou transformer les valeurs de colonnes
en utilisant le langage de leur choix lors du transfert de la source vers la destination, via
l’outil de chargement de données. Il est possible de calculer facilement de nouvelles
valeurs à partir d’une ou de plusieurs colonnes dans l’ensemble de lignes source. Les
colonnes source décomposent aussi un champ unique en plusieurs colonnes de destination.
Les scripts peuvent également appeler et utiliser les services d’un objet COM quelconque
prenant en charge l’automation.
Création de composants DTS
Les composants DTS peuvent être créés en utilisant les assistants
d’importation/exportation ou l’outil de conception de composant DTS, ou encore par
programmation. Les assistants d’importation/exportation offrent le mécanisme le plus
simple pour transférer des données vers ou à partir d’un Data Warehouse, mais la
complexité de la transformation est limitée par l’étendue de l’assistant. Par exemple, seules
les sources et les destinations uniques sont autorisées dans l’assistant. Toutefois, l’outil de
conception de composant DTS expose toutes les fonctions de DTS par l’intermédiaire
d’une interface visuelle, facile à utiliser. Dans l’outil de conception de composant, les
utilisateurs peuvent définir des relations de priorité, des requêtes complexes, un contrôle
de flux et l’accès à des sources hétérogènes multiples.
Enfin, les applications peuvent définir et exécuter des composants DTS par programmation
au travers d’une interface COM. Cette approche est principalement utilisée par les
développeurs indépendants qui souhaitent pouvoir utiliser les fonctionnalités de DTS sans
obliger un utilisateur à définir les composants séparément.
Figure 5. L’outil de conception de composant DTS fournit un environnement graphique
pour la description du flux des données et de l’exécution des composants.
18
19
Analyse et présentation des données
Microsoft fournit un certain nombre de mécanismes pour effectuer des requêtes sur les
données présentes dans le Data Warehouse. Dans la suite d’outils de productivité
Microsoft Office, les produits Microsoft Access et Microsoft Excel offrent tous deux des
fonctions d’interrogation et d’analyse des informations d’un Data Warehouse. Le
composant English Query intégré à SQL Server 7.0 permet aux utilisateurs d’interroger la
base de données en utilisant des phrases en langue anglaise. En outre, par l’intermédiaire
du Data Warehousing Framework, de nombreux produits compatibles sont disponibles
pour une visualisation et une analyse sophistiquées des données.
Microsoft Office
Deux des outils utilisés le plus couramment pour accéder et manipuler des données dans le
cadre de l’aide à la décision sont Microsoft Access et Microsoft Excel. Avec l’introduction
de la version suivante de Microsoft Office, qui portera le nom de Microsoft Office 2000,
les utilisateurs disposeront de nombreuses fonctions supplémentaires pour analyser et
présenter les informations contenues dans leurs Data Warehouses. Microsoft Excel sera
amélioré pour autoriser des représentations sous forme de tableaux et de graphiques de
sources de données OLAP par l’intermédiaire des interfaces OLE DB pour OLAP. Dans le
même temps, la fonction de tableau croisé dynamique existante sera remplacée par une
fonction OLAP plus évoluée basée sur le composant PivotTable Service de SQL Server
OLAP Services. Microsoft Access est en cours d’amélioration pour offrir une prise en
charge transparente des bases de données SQL Server en plus des fonctions de bases de
données Access existantes. Pour les clients, ces nouvelles fonctions leur permettront
d’utiliser leurs outils de bureau familiers pour une analyse plus sophistiquée des données.
Microsoft Office 2000 inclura aussi plusieurs composants destinés à simplifier la
construction d’applications Web à l’aide de contrôles prédéfinis. Ces contrôles permettront
d’accéder à des bases de données relationnelles et des bases de données OLAP, pour une
visualisation généralisée des informations du Data Warehouse.
English Query
English Query est une fonctionnalité de Microsoft SQL Server 7.0 qui permet de créer une
application d’accès au Data Warehouse, et avec laquelle les utilisateurs interrogeront une
base de données SQL Server en utilisant la langue anglaise au lieu d’un langage
d’interrogation formel tel que SQL. Par exemple, vous pourrez demander « How many
widgets were sold in Washington last year? » (combien de gadgets ont été vendus à
Washington l’année dernière) au lieu d’utiliser l’instruction SQL :
SELECT sum(Orders.Quantity) from Orders, Parts
WHERE Orders.State=’WA’
and Datepart(Orders.Purchase_Date,’Year’)=’1996’
and Parts.PartName=’widget’
and Orders.Part_ID=Parts.Part_ID
Une application English Query accepte en entrée des commandes, instructions et questions
en langue anglaise et détermine leur signification. Elle écrit puis exécute ensuite une
requête d’interrogation de la base de données en langage SQL et formate la réponse.
English Query peut aussi demander des informations supplémentaires à un utilisateur si
une question ne peut pas être interprétée.
20
English Query intègre une connaissance approfondie de la syntaxe et de l’utilisation de la
langue, mais le développeur d’applications doit créer un domaine d’informations sur les
données mises à la disposition de l’utilisateur. Dans Microsoft English Query, un domaine
est la collection de toutes les informations qui sont connues à propos des objets de
l’application English Query. Ces informations incluent les objets de la base de données qui
sont spécifiés (tables, champs, jointures, etc.), les objets sémantiques (entités, relations
entre entités, entrées de dictionnaire supplémentaires, etc.) et les options par défaut du
domaine global.
La première étape pour la construction d’une application English Query consiste à
modéliser la sémantique du Data Warehouse. Le développeur établit la correspondance
entre les entités (noms) et les relations (verbes, adjectifs, traits et sous-ensembles) de la
langue anglaise avec les tables, champs et jointures dans la base de données. Cela
s’effectue à l’aide d’un outil de création qui permet de tester le domaine en dehors de
l’application.
Figure 6. Flux des informations entre une application English Query basée sur le Web et
une base de données SQL Server.
Navigateur
Web
Question
Page de
résultats
Question
SQL
Moteur
d’exécution
d’English
Query
Application
English
Query
(*.eqd)
Données
SQL
Une fois le domaine suffisamment modélisé pour les tests et les accès utilisateur, le
développeur rend l’application English Query accessible par l’intermédiaire d’une
application Visual Basic ou d’une mise en œuvre basée sur le Web utilisant des pages ASP
(Active Server Pages). Avec l’augmentation de volume d’informations sur Intranet
disponibles dans des Data Warehouses, English Query est un excellent outil pour permettre
aux utilisateurs d’accéder à ces informations sans réaliser des investissements importants
en outils d’interrogation ou en formation.
Lors de l’exécution, un utilisateur final d’une application English Query se connecte à une
page Web par l’intermédiaire de Microsoft Internet Explorer (ou d’un autre navigateur
Web) et tape une question. Microsoft Internet Explorer transmet la question à Internet
Information Server (IIS), avec l’URL de la page ASP qui exécute VBScript.
Le script transmet la question à English Query pour qu’il la traduise en instruction SQL. English
Query utilise sa connaissance des domaines de la base de données cible (sous la forme d’une
application English Query) pour effectuer l’analyse syntaxique de la question et la traduire en SQL.
Le script lit ensuite ce code SQL, l’exécute (en utilisant un contrôle de base de données ASP),
applique le format HTML au résultat et renvoie la page à l’utilisateur.
English Query inclut des exemples de pages ASP qui peuvent être utilisées telles quelles
pour effectuer un prototypage rapide, ou être personnalisées pour s’adapter à la
présentation d’une application Web existante.
21
Produits tierces parties
L’un des concepts de base du Microsoft Data Warehousing Framework est l’ouverture de
la solution à des composants tierces parties. Par l’intermédiaire des normes d’interface de
bases de données ODBC et OLE DB, des dizaines de produits peuvent lire et manipuler les
informations stockées dans SQL Server ou une autre base de données relationnelle. De la
même façon, l’interface OLE DB pour base de données multidimensionnelle OLAP permet
d’accéder aux informations stockées dans SQL Server OLAP Services ou d’autres
magasins de données OLAP. Grâce à ces deux normes d’accès, les entreprises peuvent
sélectionner les outils analytiques les mieux adaptés à leurs besoins. La réduction des coûts
résultant de la normalisation pour les fournisseurs conduira aussi progressivement à une
réduction des coûts d’acquisition de produits de haute qualité.
22
Administration système
L’un des coûts cachés les plus importants liés à la mise en œuvre d’un Data Warehouse
concerne la maintenance et l’administration continues du système. Avec une technologie
conventionnelle, des compétences spécialisées sont généralement nécessaires pour gérer la
base de données relationnelle, le serveur OLAP, ainsi que la technologie de conception et
de transformation. Cela signifie qu’il faut souvent faire appel à plusieurs personnes ayant
des compétences spécifiques pour exécuter des tâches complètes liées. Le Microsoft Data
Warehousing Framework offre une couche de gestion et d’administration intégrée
partageable par tous les composants du processus de Data Warehousing. Microsoft fournit
une console pour les gammes de produits Microsoft, qui simplifie la transition entre les
tâches, voire entre des produits distincts. Microsoft Management Console peut être étendue
par les clients, les consultants et les développeurs indépendants afin de fournir une
interface hautement personnalisée pour des environnements particuliers. Les applications
sont fournies sous forme de snap-ins de la console, et il peut s’agir d’une interface
utilisateur prête à l’emploi développée par un éditeur de logiciels ou bien d’une interface
personnalisée développée séparément, mais accédant aux fonctions d’un produit sousjacent tel que SQL Server. Comme la plus grande partie de la suite Microsoft
BackOffice®, SQL Server 7.0 est fourni sous forme de snap-in de Microsoft Management
Console.
Microsoft Management Console
Microsoft Management Console (MMC) fournit une interface familière et cohérente pour
l’accès aux fonctions des produits serveur de Microsoft. L’interface utilisateur de MMC
est similaire à l’environnement de l’Explorateur Windows, avec une zone de travail
partagée verticalement en deux volets, qui contiennent dans la partie gauche l’arborescence
des catégories et des objets correspondant à un serveur particulier, et dans la partie droite
des informations supplémentaires sur un élément sélectionné. Les informations détaillées
du volet de droite peuvent être affichées de plusieurs manières, y compris sous forme de
documents HTML. Grâce à cette nouvelle console, l’administrateur de base de données
débutant ou occasionnel peut bénéficier de l’assistance d’outils plus sophistiqués. L’un des
ajouts importants concerne les « écrans d’affichage des tâches » (taskpads), qui regroupent
des activités à plusieurs facettes telles que la construction d’une base de données, la
définition de la sécurité utilisateur et la surveillance de la base de données SQL Server. Les
« taskpads » combinent des informations de didacticiel, des activités guidées et des liens
vers les nombreux assistants décrits ci-dessous.
Assistants
Microsoft SQL Server 7.0 contient plus de 25 assistants conçus pour simplifier l’exécution
des tâches fréquentes telles que :
 la création de bases de données, de vues, d’index et de procédures stockées ;
 la sauvegarde ou la restauration d’une base de données ;
 la configuration d’un serveur de publication et d’un serveur de distribution pour la
réplication et la création d’une publication pour la réplication ;
23
 la gestion de la sécurité des bases de données SQL Server ;
 la création d’un scénario de maintenance pouvant être exécuté à intervalles
réguliers ;
 la définition d’une indexation en texte intégral sur les colonnes SQL Server de type
caractère ;
 la création d’une tâche Web qui crée une page HTML, importe des données à partir
d’une page HTML ou exécute une tâche Web existante.
L’utilisation d’assistants réduit considérablement la courbe d’apprentissage nécessaire
pour qu’un administrateur de base de données soit productif avec Microsoft SQL Server.
Dans l’environnement de Data Warehousing, dans lequel des administrateurs de bases de
données prennent souvent en charge de nombreuses étapes du processus avec plusieurs
produits, cela se traduit par des économies de temps et d’argent.
Diagrammes visuels de bases de données
Comme les applications de Data Warehouse sont plus itératives que les systèmes OLTP,
les structures et les schémas de bases de données ont tendance à changer plus souvent. Les
diagrammes visuels de bases de données fournissent des outils de modélisation de données
physiques destinés aux administrateurs de bases de données Microsoft SQL Server, en vue
de simplifier les cycles de définition et de modification. Les diagrammes sont stockés sur
le serveur de bases de données à l’aide de SQL Server 7.0 Enterprise Manager. Les
modifications apportées à la base de données sont répercutées dans le diagramme, et
inversement. Un assistant est disponible pour automatiser la sélection et la disposition des
tables dans une base de données existante. Toutefois, il est possible de définir des entités
de bases de données (tables et leurs relations) entièrement dans l’outil diagramme.
Figure 7. Le diagramme de base de données montre les tables et leurs relations, et autorise
des modifications de la structure des différentes tables et des contraintes qui les relient.
Lors de l’enregistrement du diagramme, les modifications sont appliquées à la base de
données.
24
SQL Server Profiler
Pour optimiser correctement une base de données relationnelle, il est nécessaire de
connaître le mode d’utilisation régulière de cette base de données. SQL Server Profiler est
un outil graphique qui permet aux administrateurs système de surveiller des événements du
moteur Microsoft SQL Server en capturant un enregistrement continu de l’activité serveur
en temps réel. SQL Server Profiler surveille les événements se produisant dans SQL
Server, il les filtre en fonction de critères spécifiés par l’utilisateur et dirige la sortie de la
trace vers l’écran, vers un fichier ou vers une table. SQL Server Profiler permet ensuite à
l’administrateur de la base de données de relire des traces préalablement capturées pour
tester des modifications de structure de la base de données, identifier des requêtes lentes,
résoudre des problèmes ou recréer des conditions antérieures.
Les événements suivants du moteur peuvent entre autres être surveillés :
 des connexions, échecs de connexion et déconnexions ;
 des instructions SELECT, INSERT, UPDATE et DELETE ;
 une erreur écrite dans le journal des erreurs de SQL Server ;
 un verrou placé ou libéré sur un objet de base de données.
Les données de chaque événement peuvent être capturées et enregistrées dans un fichier ou
une table SQL Server, en vue d’une analyse ultérieure. Les données des événements du
moteur peuvent être collectées en créant des traces, lesquelles peuvent contenir des
informations sur les instructions SQL et leurs résultats, l’utilisateur et l’ordinateur
exécutant les instructions, ainsi que les heures de début et de fin de l’événement.
Les données d’événements peuvent être filtrées afin que la collecte ne porte que sur un
sous-ensemble de ces données. Cela permet à l’administrateur de base de données de ne
collecter que les événements qui l’intéressent, par exemple ceux qui affectent une base
particulière ou concernent utilisateur particulier, et d’ignorer tous les autres. De même, il
est possible de ne collecter que les données des requêtes dont le temps d’exécution dépasse
une valeur particulière.
SQL Server Profiler fournit une interface utilisateur graphique pour un ensemble de
procédures stockées étendues, que vous pouvez utiliser directement. Vous pouvez, par
conséquent, créer votre propre application utilisant les procédures stockées étendues de
SQL Server Profiler pour surveiller SQL Server.
Analyseur de requête SQL Server
L’Analyseur de requête SQL Server est un excellent outil pour l’exécution interactive ad
hoc d’instructions et de scripts Transact-SQL (le langage d’interrogation de SQL Server).
Comme les utilisateurs doivent comprendre Transact-SQL pour utiliser l’Analyseur de
requête SQL Server, cette fonction est principalement destinée aux administrateurs de
bases de données et aux utilisateurs expérimentés. Elle s’utilise en entrant des instructions
Transact-SQL dans une fenêtre de texte, en les exécutant et en visualisant les résultats dans
une fenêtre de texte ou un tableau. Il est également possible d’ouvrir un fichier texte
contenant des instructions Transact-SQL, d’exécuter ces instructions et de visualiser les
résultats dans la fenêtre de résultats.
25
L’Analyseur de requête SQL Server propose aussi d’excellents outils pour déterminer
comment Microsoft SQL Server interprète et travaille avec une instruction Transact-SQL.
Un utilisateur peut :
 afficher une représentation graphique du plan d’exécution généré pour l’instruction ;
 lancer l’Assistant d’optimisation des requêtes afin de déterminer quels index peuvent
être définis sur les tables sous-jacentes pour optimiser les performances de
l’instruction ;
 afficher des statistiques sur les performances de l’instruction.
Figure 8. L’Analyseur de requête de SQL Server 7.0 montre graphiquement comment les
requêtes complexes sont résolues. Dans cet exemple, certaines parties d’une requête
peuvent être exécutées en parallèle pour améliorer les performances.
Assistant d’optimisation des requêtes
L’un des processus les plus longs et les plus approximatifs de la gestion d’une base de
données relationnelle est la création d’index destinés à optimiser l’exécution de requêtes
utilisateur. Microsoft Research a collaboré avec l’équipe de développement de SQL Server
pour mettre au point une fonction simplifiant cette tâche. L’Assistant d’optimisation des
requêtes est un nouvel outil qui permet à l’administrateur d’une base de données SQL
Server de créer et de mettre en œuvre des index sans une compréhension expert de la
structure de la base de données, des plates-formes et des composants matériels ou de la
manière dont les applications utilisateur interagissent avec le moteur relationnel.
L’Assistant d’optimisation des requêtes analyse la charge de la base de données SQL
Server et recommande la configuration d’index optimale correspondante.
L’Assistant d’optimisation des requêtes de SQL Server est capable de :
 comparer, différencier et sélectionner la meilleure combinaison d’index en utilisant la
formule de coût du plan de requête ;
 recommander la meilleure combinaison d’index pour une charge de travail (fichier trace
ou script SQL) sur une base de données ;
 fournir une analyse des index, de la charge de travail, de l’utilisation des tables et du
coût des requêtes ;
 permettre à l’administrateur système d’optimiser la base de données pour un ensemble
limité de requêtes problématiques sans changer la configuration d’index ;
 permettre à l’administrateur système de prototyper des recommandations de
configuration d’index pour différentes contraintes d’espace disque.
L’Assistant d’optimisation des requêtes peut être utilisé pour analyser un script SQL ou le
résultat d’une trace SQL Server Profiler et émettre des recommandations sur l’efficacité
26
des index référencés dans la trace ou le script SQL. Ces recommandations consistent en
instructions SQL qui peuvent être exécutées pour supprimer des index existants et créer de
nouveaux index plus efficaces. Les recommandations suggérées par l’assistant peuvent être
ensuite enregistrées dans un script SQL qui sera exécuté manuellement par l’utilisateur
ultérieurement, qui sera immédiatement mis en œuvre ou encore, qui sera planifié pour une
exécution ultérieure grâce à l’exécution d’une tâche SQL Server exécutant le script SQL.
Si aucun script SQL ou aucune trace n’est disponible pour une analyse de la part de
l’Assistant d’optimisation des requêtes, celui-ci peut en créer un ou une immédiatement ou
le ou la planifier à l’aide de SQL Server Profiler. Lorsque l’administrateur de la base de
données a déterminé que la trace créée a capturé un échantillon représentatif de la charge
de travail normale de la base de données en cours de surveillance, l’assistant peut analyser
les données capturées et recommander une configuration d’index qui améliore les
performances de la base de données.
Administration automatisée
Les administrateurs de Data Warehouses peuvent trouver beaucoup d’avantages à
automatiser des tâches récurrentes telles que l’exécution de sauvegardes des bases de
données. Les tâches d’administration de SQL Server peuvent être automatisées en
établissant quelles opérations seront exécutées de manière régulière et pourront être
administrées par programmation, puis en définissant un ensemble de tâches et d’alertes
pour le service Agent SQL Server. L’administration automatisée peut inclure des
environnements comportant un seul ou plusieurs serveurs.
Les composants clé de l’administration automatisée sont les tâches, les opérateurs et les
alertes. Les tâches définissent une tâche administrative une seule fois afin qu’elle puisse
être exécutée une ou plusieurs fois et que l’on puisse savoir si chacune de ses exécutions
s’est déroulée correctement. Les tâches peuvent être exécutées sur un serveur local ou sur
plusieurs serveurs distants, en fonction d’un ou de plusieurs plannings, par une ou
plusieurs alertes, et elles peuvent être composées d’une ou de plusieurs étapes. Les étapes
de tâches peuvent être des programmes exécutables, des commandes Windows NT, des
instructions Transact-SQL, du code ActiveScript ou des agents de réplication.
Un opérateur est une personne responsable de la maintenance d’un ou de plusieurs
serveurs exécutant SQL Server. Dans certaines entreprises, la fonction d’opérateur est
dévolue à un individu. Dans les entreprises de plus grande taille disposant de plusieurs
serveurs, elles sont partagées par plusieurs personnes. Les opérateurs restent constamment
informés par messagerie électronique, par récepteur de poche ou par messagerie réseau.
Une alerte est une définition qui fait correspondre à un ou plusieurs événements SQL
Server une réponse appropriée au cas où ces événements se produisent. En général, un
administrateur ne peut pas contrôler les événements qui surviennent, mais il peut contrôler
la réponse à ces événements avec des alertes. Il est possible de définir des alertes pour
répondre à des événements SQL Server en avertissant un ou plusieurs opérateurs, en
réacheminant l’événement vers un autre serveur ou en déclenchant une condition d’erreur
visible par d’autres outils logiciels.
En combinant les notifications et les actions susceptibles d’être automatisées grâce au
service Agent SQL Server, les administrateurs peuvent construire un environnement
robuste qui gérera automatiquement la plupart de leurs tâches opérationnelles
quotidiennes. Les administrateurs ont ainsi plus de liberté pour s’occuper des tâches plus
importantes requérant leur intervention en personne.
27
Conclusion
Avec les technologies qui sous-tendent le Microsoft Data Warehousing Framework et les
avancées importantes de Microsoft SQL Server 7.0, Microsoft travaille à réduire la
complexité, à améliorer l’intégration et à réduire les coûts associés au Data Warehousing.
Les clients investissant dans une technologie de Data Warehouses basée sur la plate-forme
Microsoft ont ainsi l’assurance de pouvoir créer leurs applications sous le meilleur angle
économique possible, sans nuire à l’évolutivité ni à la fiabilité de leurs systèmes.
28
Téléchargement