Business Intelligence Avec SQL Server 2008 R2 PDF

Business Intelligence
avec SQL Server 2008 R2
Sébastien FANTINI
Résumé
Ce livre sur la Business Intelligence (BI) avec SQL Server 2008 R2, s'adresse à tous les membres d'une équipe décisionnelle : chef de projet,
architecte, développeur ETL, développeur de rapports, service Aide à la Maîtrise d'Ouvrage (AMO). Du débutant au technicien expérimenté, le
lecteur bénéficiera d'une approche métier du décisionnel.
Tout au long du livre, et très progressivement, l’auteur détaille les concepts clés du décisionnel puis les met concrètement en application. Ainsi,
au cours des différents chapitres, le lecteur va utiliser les différents outils de la suite SQL Server pour bâtir progressivement un système
décisionnel complet et professionnel. A chaque chapitre, le livre regorge de solutions concrètes et professionnelles et de bonnes pratiques. Le
lecteur bénéficie des retours d’expérience de l’auteur pour finalement gagner en expertise sur les différentes étapes d’un projet décisionnel.
Plus précisément, l’auteur propose de créer le système décisionnel d’une société virtuelle, Distrisys. Ce sera l'occasion pour le lecteur
d'aborder les sujets suivants :
- L'architecture des serveurs et le choix des licences
- La modélisation de l'entrepôt de données
- La conception du cube Analysis Services
- La réalisation des différents types de flux d'alimentation ETL avec Integration Services
- L'utilisation d'Excel et de PowerPivot pour exploiter les données décisionnelles
- La réalisation de rapports opérationnels et décisionnels avec Reporting Services
Les différentes solutions réalisées au cours du livre sont en téléchargement sur le site www.editions-eni.fr et sont directement exploitables dans
des projets.
Les chapitres du livre :
Avant-propos – Introduction – Installation et découverte des outils SQL Server – Réaliser son premier système décisionnel – La modélisation
dimensionnelle – Alimenter l’entrepôt de données avec SSIS – Restituer les données décisionnelles – Conclusion et perspectives
L'auteur
Sébastien FANTINI est Consultant décisionnel - Expert Microsoft depuis plus de 8 ans. Ses missions d'expert décisionnel auprès de grandes
entreprises tant nationales qu'internationales le conduisent à réaliser l'étude de cadrage, l'élaboration d'un plan directeur, la modélisation
dimensionnelle, l'audit des SIAD, la conception de tableaux de bord, la conception de systèmes d'audit de flux ETL... Il est certifié sur tous les
derniers outils Microsoft liés à la BI.
Ce livre numérique a été conçu et est diffusé dans le respect des droits d’auteur. Toutes les marques citées ont été déposées par leur éditeur respectif. La loi du 11 Mars
1957 n’autorisant aux termes des alinéas 2 et 3 de l’article 41, d’une part, que les “copies ou reproductions strictement réservées à l’usage privé du copiste et non destinées
à une utilisation collective”, et, d’autre part, que les analyses et les courtes citations dans un but d’exemple et d’illustration, “toute représentation ou reproduction intégrale,
ou partielle, faite sans le consentement de l’auteur ou de ses ayants droit ou ayant cause, est illicite” (alinéa 1er de l’article 40). Cette représentation ou reproduction, par
quelque procédé que ce soit, constituerait donc une contrefaçon sanctionnée par les articles 425 et suivants du Code Pénal. Copyright Editions ENI
Ce livre numérique intègre plusieurs mesures de protection dont un marquage lié à votre identifiant visible sur les principales images.
© ENI Editions - All rigths reserved - educ algeria - 1-

À qui s’adresse ce livre ?
Ce livre s’adresse en premier lieu à tous les membres d’une équipe, ayant pour objectif la mise en œ uvre d’un système
décisionnel avec SQL Server.
Par membre de l’équipe décisionnel, nous entendons :
● Le chef de projet, qui trouvera dans ce livre une approche méthodologique, pour aborder la conception du
système décisionnel, ainsi qu’une vision d’ensemble sur les bonnes pratiques d’implémentation des différents
outils SQL Server.
● L’architecte, qui trouvera des réponses très concrètes concernant l’architecture serveur, l’architecture
logicielle, le choix des outils de restitution, l’organisation des bases de données, les bonnes pratiques de
modélisation des bases décisionnelles…
● Le développeur ETL, qui quant à lui, trouvera dans ce livre, un chapitre détaillant comment utiliser l’outil d’ETL
de Microsoft et rappelant tous les concepts du métier, mais aussi une partie importante qui sera consacrée à
l’audit du système ETL : un sujet à grande valeur ajoutée dans le cadre de la mise en place d’un projet
d’alimentation de données.
● Le développeur de rapports trouvera un chapitre consacré à la restitution de données ainsi que tous les
éléments pour choisir le bon outil de restitution. Il trouvera aussi des exemples concrets mettant en œ uvre
tous les cas d’emplois offerts par les outils à disposition.
● Le membre d’un service AMO, ne connaissant pas particulièrement le décisionnel et désirant réaliser un cahier
des charges ou un appel à projet pour sélectionner un prestataire, y trouvera tous les éléments pour
comprendre le décisionnel, ses enjeux et comment aborder cette problématique.
Enfin ce livre s’adresse à toute personne connaissant la base de données SQL Server, désirant comprendre ce qu’est
le décisionnel et apprendre à utiliser les outils SQL Server qui y sont associés.
Les débutants y trouveront des explications très détaillées, des actions et des manipulations à réaliser. Les
techniciens expérimentés, quant à eux y trouveront une approche métier du décisionnel, très complémentaire avec
l’utilisation des outils, ainsi que des solutions pratiques pour implémenter ces concepts.
Les étudiants enfin, y trouveront une approche et des mises en œ uvre très concrètes, proches du monde de
l’entreprise. Ce livre est un bon moyen d’aborder l’état de l’art du décisionnel et pour apprendre à utiliser des outils
qu’ils rencontreront sûrement dans l’exercice de leur futur métier.

Les prérequis
Le seul prérequis nécessaire est d’être familier avec la base de données SQL Server, sans toutefois en être un
expert. Le livre est fait de telle manière que les bases et concepts liés au décisionnel sont repris et expliqués.
Pour réaliser les manipulations et suivre le déroulement du livre, vous aurez besoin d’une installation de SQL Server
2008 R2 ainsi que d’Office 2010 (Excel 2010 notamment).
Si besoin, vous pouvez télécharger ces solutions en version d’évaluation sur le site de Microsoft :
http://technet.microsoft.com/frfr/evalcenter/

Les objectifs du livre
Cet ouvrage n’a pas pour objectif de faire de vous des experts techniques sur chacun des outils de la suite SQL Server,
mais plutôt de vous apprendre à les comprendre et à bien les employer dans le cadre de la mise en œ uvre d’un
système décisionnel.
Cet ouvrage se veut avant tout un support et un outil pour toute personne désirant réaliser un système décisionnel
avec Microsoft, en bénéficiant des meilleures pratiques. Les pratiques expliquées dans l’ouvrage sont issues des
théories du décisionnel mais aussi de leur application concrète sur le terrain.
Le livre suit la mise en œ uvre concrète d’un système décisionnel au sein d’une société virtuelle, sous tous ses aspects.
● Les premiers chapitres vont vous permettre de vous familiariser avec le projet décisionnel :
● Le chapitre Installation et découverte des outils SQL Server permettra de faire le point sur
l’architecture serveur et logicielle. Des propositions concrètes d’architecture vous seront proposées.
● Le chapitre Réaliser son premier système décisionnel vous permettra de créer en quelques
manipulations un entrepôt de données avec son cube associé. Ce chapitre vous permettra ainsi de
vous familiariser avec les grands concepts du décisionnel et de les démystifier. Il vise à vous donner les
moyens de réaliser des maquettes ou de mener à bien des ateliers de modélisation.
● Les chapitres suivants entreront dans les détails de chacune des phases clés d’un lot projet :
● Le chapitre La modélisation dimensionnelle abordera les concepts ainsi que les bonnes pratiques de
modélisation. Nous vous fournirons très concrètement des modélisations standards dont vous pourrez
vous inspirer pour vos projets.
● Le chapitre Alimenter l’entrepôt de données avec SSIS vous permettra d’aborder dans le détail l’ETL :
l’architecture d’alimentation des données, les différents types de flux et le système d’audit. Ce chapitre
regorge d’exemples illustrant chaque type de flux et chaque situation. Autant d’exemples que vous
pourrez réutiliser également directement sur vos projets.
● Le chapitre Restituer les données décisionnelles abordera le bon usage des outils Excel et Reporting
Services. Vous apprendrez notamment à utiliser le PowerPivot et à réaliser la publication de masse d’un
rapport décisionnel.
L’ensemble de ces chapitres est organisé logiquement afin de suivre le déroulement chronologique du projet.
Vous découvrirez dans le chapitre qui va suivre qu’un lot projet débute toujours par la réalisation puis la validation d’un
modèle de données et du cube qui lui est associé.
Les étapes d’un projet décisionnel sur un périmètre fonctionnel (lot)
L’ouvrage ne traite pas spécifiquement des nouveautés de la version SQL Server 2008 R2 par rapport aux versions
précédentes. Néanmoins, les lecteurs trouveront ici et là des éléments abordant ces nouveautés.

- 2- © ENI Editions - All rigths reserved - educ algeria
Présentation du décisionnel
Cet ouvrage a pour but de montrer la manière dont il faut se servir des outils Microsoft SQL Server afin d’aborder au
mieux la problématique décisionnelle.
Avant de rentrer dans des considérations techniques, il est bon de faire un point sur ce qu’est le décisionnel et ce que
ce terme sousentend.
Pour faire très simple, l’informatique décisionnelle recouvre tous les moyens informatiques destinés à améliorer la prise
de décision des décideurs d’une organisation.
Cette définition pose trois nouvelles questions :
● Qu’estce qu’un décideur ?
● Qu’estce qui peut permettre d’améliorer la prise de décision ?
● Quels sont les moyens informatiques disponibles ?
L’informatique décisionnelle est souvent appelée BI pour Business Intelligence. Attention, le décisionnel n’a
strictement rien à voir avec une mauvaise traduction littérale de Business Intelligence, qui serait Intelligence
Economique. Ne confondons pas tout !
1. La notion de décideur
Sous le modèle du taylorisme et jusque dans les années 8090, les organisations étaient organisées de manière
pyramidale. Les décisions étaient prises au sommet de la pyramide et les ordres étaient transmis de manière
descendante et unilatérale à tous les niveaux opérationnels. Dans ce type d’organisation, les décideurs étaient
seulement les dirigeants de l’organisation.
Ce type d’organisation était efficace tant que le marché était localisé et qu’il suffisait de produire pour vendre.
Depuis nous sommes confrontés à une complexité grandissante du marché liée :
● À la mondialisation : les concurrents sont plus nombreux, plus innovants, mieux armés.
● À une modification des comportements d’achats : l’organisation se doit d’être centrée client. En effet, les
produits sont de plus en plus personnalisés (on parle de onetoone).
● Au fait que le monde va de plus en plus vite : le critère de délai de livraison ou de disponibilité de l’information
7 jours du 7, 24h sur 24 associé à la mondialisation et la personnalisation du besoin client, démultiplie la
complexité de l’écosystème de l’organisation.
Afin de pouvoir répondre à cette complexité grandissante du marché, l’entreprise dans les années 90, puis avec le
web dans les années 2000 a amorcé une mutation de son organisation. Une des conséquences de cette modification
latente des organisations est que les cadres opérationnels sont devenus autant de décideurs de terrain.
Dans une entreprise internationale, les responsables du marché français, japonais et indien sont forcément des personnes
distinctes. Les marchés sont trop différents. De même, dans cette même entreprise, le responsable de l’unité parisienne est
différent du responsable de l’activité à Nice sur le littoral ou à Limoges dans le Limousin : les clients sont trop différents,
leurs attentes, leurs disponibilités diffèrent trop pour qu’une politique unique soit menée unilatéralement sans prise en
compte de cette différence.
Cette logique, facile à comprendre dans un cadre commercial, s’applique dans tous les domaines de l’entreprise. La
prise de décision ne peut plus être centrale, celleci doit être déléguée.
De fait, dans une entreprise moderne, tout cadre devient un décideur de terrain et dispose d’une autonomie relative.
C’est cette explosion du nombre de décideurs qui pose un gros problème à :
● L’informatique, qui se voit démultiplier le nombre de demandes de rapports et d’extraction de données.
● La direction, qui a besoin d’outils pour manager ses décideurs : de la cohérence est nécessaire afin que les
décisions prises à tous les niveaux de l’entreprise, le soient en accord avec la stratégie d’entreprise.

Cette problématique, liée à une démocratisation des outils décisionnels, a fait exploser la demande et mis en avant au
début des années 2000, ce besoin de décisionnel.
Face à ce constat, qui sont les décideurs dans une entreprise ?
On les classe en trois catégories :
Les décideurs stratégiques
Exemple : la direction générale dans une entreprise.
● Horizon de travail : Long terme.
● Périmètre de travail : Tous les services, tous les territoires.
● Leur rôle : ces décideurs impulsent une politique, définissent les valeurs de l’organisation et donnent les
moyens aux ambitions de l’organisation.
Les décideurs tactiques
Exemple : sur un axe horizontal, on va retrouver la direction financière, la direction des achats, la direction des ventes… Sur
un axe vertical, pour chaque direction, on aura le responsable des ventes France, le responsable des ventes Japon… Mais
aussi, potentiellement, suivant la taille de l’entreprise, le responsable Paris, Nice et Limoges…
● Horizon de travail : Moyen terme.
● Périmètre de travail : un service ou un territoire.
● Leur rôle : les décideurs tactiques sont les relais des caps stratégiques, fixés par les décideurs stratégiques.
Ce sont eux qui fixent les objectifs de leur direction ou de leur territoire, qui élaborent et choisissent la
meilleure tactique pour atteindre ces objectifs.
Les décideurs opérationnels
Exemple : un commercial, un acheteur, un responsable de magasin, l’agent de maîtrise d’une ligne de production ou d’un
atelier... Ce sont toutes ces personnes qui prennent des décisions à chaud sur le terrain.
● Horizon de travail : court terme.
● Périmètre de travail : un service sur un territoire.
● Leur rôle : faire face à la réalité du terrain, gérer le quotidien.
À ces trois profils de décideurs s’ajoute celui des analystes. Le rôle des analystes est de récolter et de travailler
l’information, fiabiliser les données, expliquer les résultats. Leur rôle est d’aider à la prise de décision des décideurs.
Les analystes varient suivant le type d’organisation (industrie, négoce, service public…) et le service auquel ils
appartiennent.
Par exemple, les analystes de la direction financière sont des contrôleurs de gestion, ceux du service marketing peuvent être
statisticiens, dans une société industrielle l’analyste peut être aussi un qualiticien ou un gestionnaire des stocks… Dans
beaucoup d’entreprises, ce sont les secrétariats de direction qui récoltent les chiffres et les consolident pour leur directeur de
rattachement.
Il est important d’identifier les analystes dans l’organisation dans laquelle vous intervenez, car ce sont de très
loin, les utilisateurs les plus demandeurs d’informations.

Cette classification a de l’importance, car elle va révéler de grosses différences dans le type d’outils dont chacun a
besoin. Bien entendu, les choses ne sont pas aussi binaires : certaines personnes relèveront du stratégique/tactique,
d’autres du tactique/opérationnel… Toutes les nuances sont permises. Ce qu’il faut bien comprendre, c’est que la
notion de prise de décision pour chacun de ces décideurs n’a pas la même teinte et que chaque profil n’a pas les
mêmes attentes visàvis du décisionnel.
2. Les facteurs d’amélioration de la prise de décision
Généralement, on présente les trois facteurs de prise de décision comme étant :
● La connaissance et l’analyse du passé.
● La représentation du présent.
● L’anticipation du futur.
Les informations permettant d’appréhender ces facteurs peuvent être de deux natures différentes :
● Les informations quantitatives : ce sont toutes les données chiffrées telles que les montants, quantités,
pourcentages, délais…
● Les informations qualitatives : ce sont toutes les informations non quantifiables telles qu’un commentaire
accompagnant un rapport, des mécontentements, un sentiment, une directive, une nouvelle procédure…
Ces facteurs n’ont pas le même sens suivant le type de décideur. Leurs horizons fonctionnels et temporels sont trop
différents pour être traités de manière uniforme.
Les décideurs stratégiques ont besoin d’une vision à 360° de leur organisation. S’ils ont besoin d’une évaluation
régulière de leur politique, ils travaillent surtout sur l’anticipation de l’avenir. Ils ont besoin de projections chiffrées
internes et externes à l’organisation (données quantitatives), mais aussi de beaucoup de données qualitatives
remontant du terrain : commentaires, comptesrendus. La conviction repose sur des chiffres, mais aussi sur
l’appréhension et la compréhension d’un contexte et d’un climat interne ou externe à l’organisation.
Les décideurs tactiques sont souvent les plus grands demandeurs d’outils décisionnels, car ils sont comprimés entre
des décideurs stratégiques, qui leur demandent des évaluations de leur politique, et des décideurs de terrain, parfois
très nombreux, qu’il faut cadrer et suivre. Ces décideurs tactiques ont besoin d’une parfaite compréhension du passé,
travaillent peu avec le présent, mais se doivent de travailler avec des prévisions pour recadrer leur politique. Les
données chiffrées sont bien évidemment essentielles, encore fautil que les différents systèmes s’accordent entre eux.
Les décideurs opérationnels travaillent surtout avec le présent : il leur faut des données opérationnelles brutes
instantanées. L’analyse du passé relève surtout d’un suivi opérationnel pour vérifier l’adéquation avec les objectifs.
L’anticipation de l’avenir relève de la fourniture de données opérationnelles en amont du service.
Par exemple, s’il y a beaucoup de prises de commandes lors d’une journée, le responsable d’un centre logistique sait que le
lendemain ou la semaine suivante la charge de son service va augmenter.
Pour les décideurs tactiques et opérationnels, les informations qualitatives quant à elles ne sont pas dans les
systèmes informatiques traditionnels : elles sont dans les mails et circulent de vive voix.
Pour être concret, la plupart des cadres d’entreprise arrivent le matin à leurs bureaux. Ils déposent leurs affaires, puis
allument leur ordinateur pour consulter leurs mails.
Ils vont ensuite à la machine à café pour discuter du dernier mail ou de l’information de la veille. Ils règlent certaines

de leurs affaires à cette occasion, mais découvrent aussi d’autres problèmes. Enfin, ils reviennent à leurs bureaux pour
traiter les problèmes qu’on leur a soumis. Ils font le nécessaire pour obtenir et consulter des données chiffrées. Ils
analysent puis retravaillent ces informations chiffrées. Enfin, après réflexion, ils prennent leur décision sur la base de
ces données.
Le problème, c’est que ces cadres ne connaissent pas la fiabilité des données à leur disposition. De plus, chaque
fichier contient une information dense mais qui pourtant, ne révèle qu’une information partielle. Il faut alors croiser des
données de différents fichiers, émis par des services distincts, pour en avoir une vue complète. Cela n’est pas toujours
très facile à faire. L’autre problème consiste à obtenir les données. Dans certaines organisations, la recette de la
conception des chiffres et plus encore la possession de ces mêmes chiffres est un enjeu de pouvoir important. Enfin
dans de nombreuses organisations, les chiffres émis par un service sont systématiquement contestés par les autres.
Les réunions de comité de direction se transforment dans certaines entreprises en dialogue de sourds car chacun
reste sur sa position et estime être celui qui possède le bon chiffre.
Dans ce contexte, prendre des décisions sur des données fiables et en toute sérénité relève du parcours du
combattant.
Sachez que vous pouvez avoir confiance en chacune des décisions que vous prenez, dès l’instant que vous avez :
● La certitude que vos données sont fiables, à jour et complètes.
● Les capacités de comprendre l’origine d’un succès ou d’une défaillance.
● Les moyens d’évaluer les plans d’action et les politiques mises en œ uvre suite à une décision.
Dès lors, la mise en place d’outils décisionnels doit permettre de répondre progressivement à ces trois attentes :
● Améliorer l’accès et la qualité des données.
● Gagner en finesse d’analyse et de compréhension de données.
● Gérer les performances de l’organisation et de ses politiques.
3. L’informatique décisionnelle
L’informatique décisionnelle couvre toutes les solutions informatisées pour améliorer la prise de décision des décideurs
dans l’organisation.
Dans ses débuts, l’informatique décisionnelle s’est contentée tout d’abord de dupliquer les bases de données des
systèmes de gestion, afin d’isoler les requêtes d’analyse de données des requêtes opérationnelles. Les requêtes
d’analyse étant souvent très lourdes, l’objectif était surtout de préserver les performances des systèmes
opérationnels. Ensuite cette base de données dédiée aux requêtes et à l’analyse a progressivement muté et s’est
organisée.
Partant du constat qu’il est difficile de croiser des données contenues dans des bases de données distinctes, le plus
simple a été de regrouper ces données éparses. Le concept de la base unique pour centraliser les données de
l’entreprise est plus que jamais d’actualité. Il s’agit du concept d’entrepôt de données (ou Data Warehouse).
S’il est plus simple d’analyser ces données une fois qu’elles sont dans l’entrepôt de données, il n’en reste pas moins
qu’il faut tout de même remplir l’entrepôt de données. L’extraction et le croisement des données des différents
systèmes opérationnels puis le chargement dans l’entrepôt de données, ont fait émerger des outils dédiés à cette
tâche, avec des concepts métiers qui leur sont propres : les outils d’ETL (Extract Transform Load).
Si au début, les requêtes d’analyses portaient sur une base relationnelle (dites OLTP pour OnLine Transaction
Processing), le concept de base multidimensionnelle (dites OLAP pour OnLine Analytical Processing) s’est démocratisé fin
des années 90. Ce concept de bases de données offrait des performances très largement supérieures aux bases
OLTP pour répondre à des requêtes d’analyse. Ces bases OLAP se sont alors couplées avantageusement avec
l’utilisation de l’entrepôt de données. En effet, elles offraient à la fois un environnement plus performant, mais
permettaient également aux utilisateurs finaux de bénéficier d’une interface simplifiée d’accès aux données, beaucoup
plus intuitive qu’une base de données OLTP. On parle alors de métamodèle.
Attention, suivant les éditeurs, les métamodèles ne reposent pas forcément sur des bases
multidimensionnelles. On constate toutefois sur ces dernières années que ce schéma s’impose peu à peu.
L’ensemble des moyens informatiques et techniques destiné à améliorer la prise de décision est appelé système
décisionnel ou encore Système Informatique d’Aide à la Décision (SIAD).

Architecture technique d’un système décisionnel
Si l’informatique décisionnelle s’est contentée dans ses débuts d’une approche technicienne, elle progresse et
converge de plus en plus rapidement vers le poste utilisateur et s’adapte aux métiers des utilisateurs. Nous sommes
encore aujourd’hui dans cette phase de convergence.
Vous le comprendrez, dans le contexte actuel, les décideurs étant de natures très différentes, les outils de restitution
sont multiples afin de convenir et répondre à toutes les attentes des différents acteurs de la prise de décision.
On dénombre sur le poste de travail des outils de natures très variées :
● Les outils de reporting pour délivrer une information opérationnelle ou une information décisionnelle de suivi
d’activité. Dans le cadre du reporting décisionnel, il s’agit notamment de reporting de masse destiné à la
publication d’un rapport personnalisé vers de nombreux utilisateurs avec un profil de décideur opérationnel.
● Les outils d’analyses pour comprendre et appréhender une situation passée. Les outils d’analyse reposant sur
une base multidimensionnelle (OLAP) pour des performances optimales. Ces outils doivent permettre aux
analystes de naviguer et d’explorer les données disponibles facilement, rapidement et en toute autonomie.
La base OLAP favorise l’utilisation d’outils d’analyse. Attention la base OLAP n’est pas un outil d’analyse en
soi. Que serait un système de gestion (type ERP ou CRM), si on ne livrait aux utilisateurs que la base de
données sans les interfaces…
● Les outils de statistiques pour modéliser des situations ou des comportements, pour tenter de les anticiper.
● Les outils de tableaux de bord et de pilotage pour assurer l’alignement des objectifs stratégiques, tactiques et
opérationnels de l’organisation et permettre le suivi des politiques.
● Les outils d’intranet pour partager l’information dans l’entreprise, favoriser la production d’informations
qualitatives (Wiki, Blog, forum, enquêtes…) et associer informations qualitatives et quantitatives. L’objectif de
l’intranet, dans une optique décisionnelle, est de favoriser l’émergence de véritables espaces de prises de
décision, personnalisés à un service et/ou à un utilisateur. L’intranet est aussi le relais idéal du décisionnel
lorsqu’il s’agit de mettre en œ uvre les actions correctrices et bien entendu de les suivre.

Les outils de restitution suivant les profils d’utilisateurs
Dans la section suivante nous allons voir comment Microsoft articule sa solution pour répondre aux exigences, tant
techniques que fonctionnelles.

La solution Microsoft BI
1. L’offre Microsoft BI
Contrairement à ce que l’on pourrait penser, Microsoft n’est pas un nouveau venu dans le monde de la BI. Depuis le
tout début des années 2000, il en est même un acteur majeur et ce, grâce à sa base OLAP Analysis Services et au
tableau croisé dynamique Excel.
Bien entendu, son offre s’est largement étendue et structurée depuis, avec le développement de ce nouveau marché.
Il est à noter tout de même que Microsoft a largement contribué à démocratiser le recours à l’informatique
décisionnelle dans les sociétés de taille moyenne, ainsi que dans les PME.
Sur le fond, l’offre Microsoft BI est structurée autour des trois promesses du décisionnel :
● Améliorer l’accès et la qualité des données : on y retrouve tous les outils destinés à concevoir un entrepôt de
données bien modélisé, performant et contenant des données fiabilisées.
● Gagner en finesse d’analyse et de compréhension de données : on y retrouve tous les outils qui permettent
aux utilisateurs finaux d’analyser et de naviguer dans leurs données en toute autonomie, sans avoir à recourir
au service informatique.
● Gérer les performances de l’organisation et de ses politiques : on y retrouve tous les outils destinés à
partager, à communiquer et à organiser les performances de l’organisation tels que les outils de tableaux de
bord et les outils d’intranet.
Sur la forme, l’offre Microsoft BI est structurée au sein de trois licences. Chacune de ces licences contient de nombreux
outils à usage décisionnel correspondant aux tâches énoncées plus haut :
● SQL Server 2008 R2 : Integration Services, Master Data Services, Analysis Services, Reporting Services.
● Office 2010 : Excel 2010, PowerPivot
● SharePoint Server 2010 : Excel Services, PerformancePoint Services.
Si les outils de la gamme SQL Server 2008 R2 sont plutôt des produits techniques destinés, à l’usage, au service
informatique, les outils des gammes Office 2010 et SharePoint 2010 sont plus spécifiquement destinés aux utilisateurs
finaux.
Dans la suite de cette partie, nous allons étudier le contenu, l’utilisation et le positionnement de chacune de ces
solutions.
Néanmoins, dans cet ouvrage nous n’étudierons pas en détail les outils de la gamme SharePoint Server 2010. Les
chapitres qui suivent se concentreront sur le bon usage des produits de la gamme SQL Server 2008 R2, ainsi que
d’Excel 2010. Pourtant nécessaire et très complémentaire, l’étude de l’utilisation de Sharepoint est un sujet en soi,
qu’il faudra étudier et travailler par ailleurs.

L’utilisation des licences Microsoft suivant les profils utilisateurs
2. SQL Server 2008 R2
Si à l’origine, la licence SQL Server correspond uniquement à une base de données relationnelle (OLTP), assez
rapidement la licence s’étoffe pour couvrir l’ensemble des outils dédiés au stockage et au traitement de données.
Dans le langage courant, SQL Server évoque la base de données relationnelle. Il existe néanmoins d’autres outils ou
services couverts par cette même licence, dont la plupart trouve un usage dans le cadre de la mise en œ uvre d’un
Nous ne nous attarderons donc pas sur le service de base de données relationnelle, qui a maintenant fait ses preuves
face à la concurrence. La base de données est fiable, performante et hautement disponible. Le service de base de
données est parfaitement indiqué pour accueillir un entrepôt de données. On retrouve d’ailleurs des entrepôts de
données sous SQL Server Database Services dans de grandes banques nationales, dans de grands consortiums
hospitaliers, dans la grande distribution, dans des sociétés de télécom et de téléphonie… SQL Server se retrouve dans
les sociétés et organisations de toutes les tailles et dans tous les domaines d’activité.
Nous avons vu précédemment que la construction d’un système décisionnel ne se limite pas à l’utilisation d’une base
de données relationnelle. Avec la licence SQL Server, Microsoft nous livre toute la panoplie d’outils dont un service
informatique a besoin pour bâtir un système décisionnel dans les règles de l’art.
Pour bâtir notre système d’aide à la décision, nous aurons besoin de :
● SQL Server Integration Services : l’ETL.
● SQL Server Master Data Services : le gestionnaire de données de référence.
● SQL Server Analysis Services : la base de données multidimensionnelle (OLAP) et le méta modèle.
● SQL Server Reporting Services : l’outil de reporting opérationnel et de reporting de masse.
Dans les parties qui suivent, nous allons présenter plus en détail chacun de ces outils.
a. SQL Server Integration Services
Nous avons expliqué précédemment que les concepts du décisionnel prennent racine dans le fait de bénéficier
d’entrepôt de données contenant et croisant des données provenant de systèmes sources très hétérogènes.
Si la grande valeur ajoutée du décisionnel est d’accéder confortablement aux données contenues dans l’entrepôt de
données, il n’en reste pas moins que la majeure partie d’un projet décisionnel se situe dans l’alimentation de
l’entrepôt de données.
En effet, l’alimentation d’un entrepôt de données représente généralement près de 80 % de la charge du projet. De
prime à bord, beaucoup de services informatiques qui découvrent le décisionnel ont largement tendance à sous

estimer le temps nécessaire à récupérer l’information, mais aussi à la croiser.
Pour nous aider dans cette tâche, Microsoft met à notre disposition, dans la licence SQL Server 2008 R2, un outil
d’ETL (Extract Transform Load) : SQL Server Integration Services (SSIS).
Déroulement d’un flux ETL sous SSIS
Même s’il n’est pas considéré comme le meilleur ETL du marché, il n’en reste pas moins que SSIS est un véritable outil
d’ETL, fiable, performant, et qu’il remplit parfaitement le rôle pour lequel il est destiné. SSIS est d’ailleurs maintenant
largement déployé et employé dans de très nombreuses entreprises françaises et étrangères.
Je ne vous conseille pas d’acheter la licence SQL Server 2008 R2 pour bénéficier spécifiquement de SSIS,
surtout, si vous travaillez sur un décisionnel en environnement Linux avec des technologies Open Source...
En revanche, si vous avez pour projet de bâtir un système décisionnel en environnement Microsoft, le rapport
qualitéprix de l’outil est véritablement imbattable.
Le point fort de SSIS est que c’est d’une part un bon ETL et qu’il est d’autre part disponible sans surcoût
avec la licence SQL Server. Une licence que la plupart des entreprises disposent déjà afin de bénéficier de la
base de données relationnelle.
Plus que l’outil, c’est la manière dont il est employé qui est très importante. À ce propos, le chapitre Alimenter
l’entrepôt de données avec SSIS, reviendra assez largement sur le sujet afin de vous donner les bonnes pratiques
d’usage. Je vous invite donc à consulter ce chapitre, à la fois pour découvrir les bonnes pratiques de l’ETL et pour
apprendre à vous familiariser avec SSIS.
Généralement on attend d’un outil d’ETL :
● Qu’il accélère le travail de développement des flux de données : SSIS est un ETL assez simple d’utilisation.
Sa prise en main est rapide. SSIS, comme les grands ETL, permet de découper un flux d’alimentation en une
multitude de petites tâches de transformation de données distinctes et ordonnancées. L’amélioration de la
productivité vient du fait qu’il est plus facile de traiter une multitude de problèmes très simples, plutôt que de
traiter un grand problème très compliqué. SSIS permet aussi de suivre très précisément le déroulement du
flux de données. Entre chaque tâche de transformation de données, il est possible de visualiser les valeurs,
ainsi que les transformations qui leur ont été appliquées.
● Qu’il offre une vision claire et maintenable des flux réalisés : SSIS, comme tout bon ETL, permet d’obtenir une
visualisation graphique, logique et simple des flux réalisés. Les règles de transformation pouvant être parfois
très compliquées, il est important qu’elles puissent être représentées simplement afin que n’importe quel
informaticien, disposant d’une formation ETL, puisse lire et comprendre le déroulement d’un flux de données.
Chaque tâche de transformation est représentée par une boîte que le développeur a la liberté de nommer

ou plutôt de décrire. Développer un flux ETL avec SSIS ne nécessite pas de notions de développement objet
ni même d’un grand savoirfaire SQL. Un flux SSIS correctement développé et respectant la logique ETL est
un flux vraiment très lisible et facilement maintenable.
● Qu’il puisse se connecter et travailler avec de nombreuses sources hétérogènes : le propre d’un ETL est
d’être ouvert et de pouvoir disposer d’une certaine universalité de connexion. SSIS ne déroge pas à cette
règle, il permet entre autres de se connecter nativement à :
● de nombreuses bases relationnelles par OLEDB : SQL Server, Oracle, DB2…
● des fichiers : fichier plat csv, fichier xml, fichier Excel
● des sources en ligne : services web, service ftp,
● etc.
La liste est bien entendu loin d’être exhaustive. Les connecteurs sont cependant de qualité très inégale, mais
comme tous les produits Microsoft, le produit est ouvert et la communauté de développeurs est assez efficace. Vous
trouverez sur le marché de nombreux autres composants, connecteurs ou tâches, et vous disposerez de la
possibilité de créer le vôtre en .net si vraiment cela s’avère nécessaire. Ce qui est en définitive assez rare toutefois.
Au cours de mes projets, nous avons eu par exemple à développer une tâche récupérant les fichiers en
pièces jointes des mails d’une boîte aux lettres électronique. Le besoin est peu banal mais la réalisation a
été simple.
● Qu’il soit performant : un ETL dispose souvent de fenêtres de traitement très courtes pour se connecter à un
système source et pour charger l’entrepôt de données. Il faut alors que l’outil traite de très gros volumes,
très rapidement. Le secret de la performance des outils d’ETL réside généralement dans leur capacité à
travailler et faire les transformations sur les données en mémoire vive. C’est le cas de SSIS, qui dispose
d’ailleurs de nombreuses possibilités de gestion et d’optimisation du cache.
● Qu’il dispose de nombreuses fonctionnalités de transformation de données : en ce qui concerne la lettre T de
ETL, SSIS est plutôt bien fourni et propose de nombreuses tâches de transformation : calcul, contrôle, mise
en cohérence des données, conversion, pivotement, union, jointure, nettoyage, regroupement,
échantillonnage… SSIS intègre de plus en plus de tâches de transformation avancées issues de la
statistique, pour vous permettre de mieux nettoyer vos données ou contrôler leurs contenus.
● Qu’il puisse se déployer facilement : SSIS gère parfaitement les problématiques de multienvironnements et
de déploiement sur un environnement de production. Tout se passe au sein de fichiers de configuration qui
peuvent être de natures diverses (XML, base de données…). Les flux se lancent et se planifient, soit par le
biais de l’agent SQL fourni et intégré à SQL Server, soit par le biais d’une ligne de commande exécutable, si
vous disposez de votre propre ordonnanceur d’entreprise.
Enfin SSIS permet de mettre en œ uvre pleinement les concepts du métier : audit de données, historisation des
dimensions (SCD), traitement des erreurs et des rejets... En ce qui concerne la gestion d’erreur, SSIS gère l’erreur au
niveau de chacune de ses tâches et potentiellement au niveau de chacune des lignes chargées. SSIS vous permet
ainsi de mettre en place des systèmes d’audit de flux et de données performants et entièrement personnalisés à
votre activité et à votre problématique. Cependant, ce genre de système n’est pas quelque chose de standard inclus
magiquement dans un outil, il vous faudra le mettre en place. Je vous incite à consulter sur ce sujet le chapitre
Alimenter l’entrepôt de données avec SSIS Audit des flux ETL.
b. SQL Server Master Data Services
SQL Server Master Data Services (MDS) est une nouveauté de SQL Server 2008 R2. Ce nouveau service est une
solution de MDM (Master Data Management) ou Management des données de référence.
La gestion des données de référence n’est pas exclusive au système décisionnel. Il s’agit plutôt d’une pratique
d’urbanisation des systèmes d’information qui contribue sensiblement à la qualité de l’information dans l’entreprise.
Les données de référence sont les données transversales de l’entreprise. Ce sont les éléments clés qui décrivent et
définissent un domaine de l’entreprise : clients, produits, fournisseurs, sites, organisations, services, employés…
Gérer ces données de référence devient primordial pour la plupart des organisations qui ont une organisation
cloisonnée des données.
Une société multinationale qui dispose d’un ERP, d’une GPAO ou d’un CRM pour chacune de ses filiales, est forcément

confrontée à un moment ou un autre à des problèmes de redondance ou d’incohérence de données. Le risque est le
même, chaque fois qu’une organisation fait le choix de déployer une solution spécialisée pour gérer une activité
spécifique de son activité : déployer un CRM pour les commerciaux, une GPAO pour la production, une GMAO pour les
services maintenance… Lors de chaque déploiement, les données de référence sont alors dupliquées. Si l’on n’y fait
pas attention, il devient après plusieurs années extrêmement complexe de rapprocher les données de ces différents
systèmes.
Le MDM regroupe les pratiques et les outils permettant de rassembler, gérer et partager les données pour lesquelles
il est primordial qu’il ne subsiste aucune erreur. Le rôle du MDM est de fournir aux différents systèmes des données
de référence exactes, complètes et actualisées.
Le MDM crée une ressource centralisée, indépendante des applications et des processus métier, qui gère le cycle de
vie des données de référence.
Avec la mise en place d’une telle pratique impliquant les services fonctionnels et le service informatique, la cohérence
des données dans les divers systèmes de transactions et d’analyses est ainsi garantie. Ainsi, les problèmes de
qualité des données peuvent être résolus de manière proactive, plutôt qu’après coup, dans l’entrepôt de données.
Microsoft fournit donc à travers MDS, une solution informatique appuyant et permettant la mise en œ uvre d’une
démarche de MDM dans votre organisation. Le MDM n’est pas l’objet de l’ouvrage, mais comprenez l’intérêt d’une
telle solution lors du déploiement de votre système décisionnel. Le rapprochement des données entre les différents
systèmes est l’un des principaux enjeux de l’ETL, mais aussi l’une des raisons majeures des délais de
développement ETL.
Interface d’administration de MDS
c. SQL Server Analysis Services
SQL Server Analysis Services (SSAS) est la base multidimensionnelle (OLAP) de la licence SQL Server. On présente
souvent SSAS comme étant la solution de cubes de Microsoft. SSAS est une solution parfaitement fiable et très
robuste, leader de son marché.

Interface de conception Analysis Services
Avec l’augmentation des volumes de données, les bases de données OLAP s’imposent progressivement comme des
solutions incontournables pour représenter les données contenues dans l’entrepôt de données. À l’opposé des
bases OLTP, plus les requêtes utilisateurs portent sur des données globales et agrégées, plus la réponse est rapide.
À l’inverse, plus la requête porte sur les données de détail, moins la requête est performante. Il ne faut donc pas
considérer Analysis Services comme une base de données permettant des extractions de données. Les modèles
Analysis Services doivent être conçus pour fournir la finalité de l’analyse attendue par l’utilisateur.
Exemple d’interface d’exploration de cube
Les données détaillées de l’entrepôt de données sont contenues dans la base relationnelle, mais c’est Analysis
Services qui les agrège et les présente aux utilisateurs finaux. Étant la partie émergée de l’entrepôt de données, il
offre ainsi la possibilité de gérer véritablement de très grands volumes de données avec des temps de réponse de
l’ordre de la seconde. Les résultats sont souvent assez bluffants pour des utilisateurs habitués à travailler avec des
bases de données OLTP. SSAS ne craint pas les gros volumes de données, il est taillé pour cela. Attention toutefois à
conserver une modélisation appropriée, car la performance de son moteur OLAP est directement liée à la
modélisation de la base de données sousjacente.
Je ne saurais que trop insister tout au long de l’ouvrage sur l’importance de la modélisation de l’entrepôt de
données. Je vous suggère à ce sujet les chapitres Réaliser son premier système décisionnel, puis La modélisation
dimensionnelle, pour vous apprendre à concevoir des modèles d’analyse cohérents et performants.
Les données de l’entrepôt de données étant manipulées directement et exclusivement par le biais d’Analysis
Services, celuici offre aux utilisateurs une interface simplifiée et intuitive d’accès aux données. Dans les faits, les

utilisateurs n’accèdent pas directement à Analysis Services. Ce sont les outils de restitution qui proposent et
consomment les données du cube. Il est donc indispensable lorsque vous mettez en place SSAS de proposer
parallèlement aux utilisateurs des outils de restitution adaptés (par exemple Excel).
Analysis Services est l’interface entre l’entrepôt de données et les outils de restitution
d. SQL Server Reporting Services
Enfin, la suite SQL Server dispose d’un serveur de rapports permettant d’afficher et de diffuser des informations.
Reporting Services est avant tout un produit destiné à un public d’informaticiens. Sa parfaite intégration avec
l’environnement .net, sa capacité de mise en page, ses possibilités de diffusion en font un excellent outil de reporting
opérationnel. Reporting Services est l’outil parfait pour mettre en page une facture, un bon de livraison, un suivi de
commande, un inventaire, un catalogue produit, la liste des clients à relancer… Tous les états, dont une application
de gestion a besoin, sont parfaitement réalisables avec Reporting Services.
En ce qui concerne le besoin décisionnel, Reporting Services a été survendu par Microsoft depuis la sortie de SQL
Server 2005. Reporting Services n’est pas un outil d’analyse destiné à des utilisateurs finaux. En revanche, il a
totalement sa place dans la diffusion de rapports de masse, c’estàdire dans les rapports décisionnels destinés à de
nombreux décideurs opérationnels.
Par exemple, la diffusion par mail au format PDF, du rapport mensuel de suivi des ventes à tous les commerciaux de
l’entreprise.
Nous reviendrons largement sur ce sujet dans le chapitre Restituer les données décisionnelles Reporting Services.
Nous aborderons alors plus en détail la différence entre rapport opérationnel et rapport décisionnel, puis nous
apprendrons à faire bon usage de Reporting Services.

Exemple de rapport réalisé avec Reporting Services
3. Office 2010
Microsoft Excel est sûrement et de loin, le premier outil décisionnel dans le monde et ce, depuis de nombreuses
années. Il répond aux besoins d’analyse de tous les services, de toutes les organisations et sert à toutes les tâches :
stockage de données, traitement de l’information et restitution.
Si Microsoft Excel seul répond assez bien à des problématiques sectorielles (pour le service Marketing ou pour le
service contrôle de gestion uniquement), il atteint toutefois ses limites lorsque :
● Il s’agit de croiser les données de référence de plusieurs applications : les fichiers Excel deviennent alors de
véritables usines à gaz très difficiles à maintenir.
● Il s’agit de réduire les délais de production des tableaux de bord : il est difficile d’automatiser le traitement de
données dans Excel. On peut toujours y arriver par le biais de macro, mais on augmente alors sensiblement la
difficulté de maintenance des rapports.
● Les données à traiter deviennent trop importantes : Excel 2003 gère quelque 65000 lignes, Excel 2007 jusqu’à
un peu plus de 1 million. Mais les systèmes produisent toujours plus de données et les demandes des
décideurs ont aussi tendance à se complexifier.
● Il s’agit de sécurité : un fichier Excel diffusé par mail contient l’intégralité des données détaillées qu’il affiche et
ses données sont potentiellement modifiables.
● Il s’agit d’automatiser la diffusion des rapports : les fichiers sont de plus en plus volumineux. La limite admise
par le serveur de messagerie est parfois atteinte.
Pour toutes ces raisons et bien d’autres encore, Excel a besoin de s’adosser à un système décisionnel. Les utilisateurs
continuent toutefois de plébisciter l’utilisation d’Excel dans leur quotidien. Microsoft a compris l’avantage substantiel
qu’il peut tirer de cette position privilégiée.
Au sein de la solution BI Microsoft, Excel est l’outil d’analyse des utilisateurs finaux. Toutefois, Excel n’est utilisé que
pour accéder, manipuler et naviguer dans les données d’Analysis Services. Les données ne sont plus contenues
directement dans le fichier, mais sur un serveur. Et ces données ne sont plus traitées directement par les utilisateurs
fonctionnels mais par le service informatique par le biais de l’ETL. Excel conserve toutefois toutes ses capacités de
représentation graphique, de mise en page et de personnalisation à l’aide de formules.

Le tableau croisé dynamique d’Excel
Dans sa version 2010, Excel dispose d’un nouvel outil : le PowerPivot. Un outil puissant mais qu’il faut bien
comprendre et repositionner dans la solution Microsoft BI.
Nous étudierons en détail, dans le chapitre Restituer les données décisionnelles Excel, l’utilisation d’Excel adossée à
la solution décisionnelle Microsoft, mais aussi l’utilisation du PowerPivot. Vous apprendrez ainsi à mieux comprendre et
à cerner l’utilisation de ces outils.
4. SharePoint 2010
SharePoint 2010 est une plateforme de services de portail. SharePoint est notamment utilisé pour réaliser des
portails Intranet/Extranet et des platesformes d’espaces collaboratifs et documentaires.
SharePoint est une solution très vaste regroupant de très nombreux services, tels que :
● le moteur de recherche de l’entreprise ;
● la gestion documentaire ;
● la gestion des processus métier par le biais des flux de travail (workflows) ;
● la gestion de contenus (Content Management Services ou CMS) ;
● l’affichage des données applicatives.
SharePoint, comme son nom l’indique, se veut être le point de convergence de tous les contenus de l’entreprise. Les
informations décisionnelles font bien évidemment partie de ces contenus.
Comme nous l’avons vu plus haut dans ce chapitre, le décisionnel a pour objectif de mettre à disposition des
décideurs, tous les éléments nécessaires à la prise de décision. Les contenus nécessaires à la prise de décision sont
très vastes et ne se limitent pas uniquement aux informations quantitatives mises à disposition par l’entrepôt de
données. L’intranet, c’estàdire SharePoint dans la solution Microsoft, est le relais idéal du système décisionnel pour
toucher les décideurs et concevoir des espaces de décision complets, contenant :
● rapports et analyses chiffrées ;

● commentaires et analyses des analystes métier ;
● remarques des confrères ;
● bibliothèques de documents Word et Excel ;
● lien direct pour contacter un collaborateur et engager une action ;
● lien direct vers le moteur de recherche pour une ouverture sur des informations internes ou externes à
l’organisation, etc.
Sharepoint est véritablement l’outil idéal pour s’adresser aux décideurs de l’entreprise.
Pour aller plus loin dans les données de l’entrepôt de données et réaliser de véritables tableaux de bord, Sharepoint
dispose de deux solutions :
● Excel Services
● PerformancePoint Services

Ces services nécessitent la version et la licence Enterprise de SharePoint.
Ces solutions et leurs mises en place nécessitent une attention et une perception qui dépassent l’objectif de cet
ouvrage. Bien qu’essentielles, elles ne seront donc pas abordées.
a. Excel Services
Le service Excel est un serveur offrant la possibilité de transformer tout ou partie du contenu d’une feuille Excel en
une page web au format HTML. La grande force des services Excel est de rendre dynamique ce contenu. Cela signifie
que l’utilisateur qui publie sur SharePoint un tableau croisé dynamique basé sur Analysis Services verra le contenu
de celuici, sur son portail Sharepoint, actualisé pour afficher dynamiquement les toutes dernières données. Le
tableau croisé dynamique publié conserve aussi ses capacités de navigation et de filtre comme le tableau croisé
dynamique du fichier Excel originel.
Avec les Services Excel, les contenus et analyses d’Excel conçus par les utilisateurs finaux deviennent alors très
facilement diffusables et partageables à l’ensemble de l’organisation.
Le fonctionnement est assez simple : l’utilisateur conçoit ses analyses sous Excel 2010. Puis, il publie le fichier sur
une liste SharePoint (un répertoire virtuel en quelque sorte). Le contenu de ce fichier publié est alors calculé par le
serveur Excel pour être restitué à l’aide d’une webpart Sharepoint.
Dans le chapitre Restituer les données décisionnelles Excel nous évoquerons un peu le sujet sans toutefois entrer
dans les détails spécifiquement propres à SharePoint.
- 10 - © ENI Editions - All rigths reserved - educ algeria

Tableau croisé dynamique Excel Service dans SharePoint 2010
b. PerformancePoint Services
Le dernier service dont dispose SharePoint 2010, est PerformancePoint. Ce dernier service, destiné à des utilisateurs
métier (type contrôleurs de gestion), est un outil destiné à élaborer et à gérer la performance de l’entreprise. Ce
service s’inscrit totalement dans une approche de Management de la performance, appelée aussi Business
Performance Management (BPM) ou Corporate Performance Management (CPM).
Le service PerformancePoint permet, à la solution BI de Microsoft, de répondre à la dernière attente de l’informatique
décisionnelle :
● Gérer les performances de l’organisation et de ses politiques.
Le service PerformancePoint est une des toutes meilleures solutions sur ce sujet et il est aussi le seul outil de la
suite Microsoft à s’ouvrir sur cette démarche.
Le management de la Performance a pour objectif l’alignement et la mise en cohérence des objectifs des décideurs
tactiques et opérationnels sur les objectifs stratégiques de l’organisation. Cette démarche favorise l’émergence de
tableaux de bord pensés et construits autour d’indicateurs clés (ou KPI pour Key Performance Indicator).
Nous n’irons pas plus loin dans l’explication et la compréhension du Management de la Performance. Sans être citée,
cette démarche est de plus en plus présente dans les organisations tant privées que publiques (la LOLF menée par
le gouvernement français en est un bon exemple). De plus en plus, vous entendrez parler de tableaux de bord,
d’indicateurs, d’objectifs… Tous ces termes relèvent d’une démarche de Management de la Performance.
Le service PerformancePoint est alors un complément pour accompagner cette démarche, pour répondre aux
exigences des décideurs de votre organisation et pour maîtriser la communication officielle sur la performance de
l’organisation.
Le service PerformancePoint offre aux utilisateurs métier noninformaticiens la possibilité de :
● Créer et gérer des espaces de décision complets.
● Créer et gérer de tableaux de bord dynamiques constitués d’indicateurs clés.
● Créer et gérer des indicateurs clés, modifier les seuils d’atteinte ainsi que les visuels de météo (feux vert en
cas d’atteinte d’un objectif par exemple, flèche rouge vers le bas lors de tendance à la baisse, etc.).
● Créer des analyses de données plus dynamiques que ne le permettent les services d’Excel. C’est en ce sens
© ENI Editions - All rigths reserved - educ algeria - 11 -

un bon complément au service Excel.
● Référencer et gérer les ressources officielles complémentaires aux tableaux de bord : tableau croisé
dynamique Excel Services, graphique d’analyse en mode web, commentaires, ressources documentaires…
La finalité de ce service est de délivrer aux décideurs des espaces de décision en mode web, complets, riches et
dynamiques, comme le montrent les copies d’écran cidessous :
Tableau de bord intégré à l’espace portail

Espace de décision avec tableau de bord et analyse

Notre étude de cas : Distrisys
La société Distrisys est une société virtuelle européenne que nous prendrons en exemple dans notre ouvrage.
Distrisys est un grossiste de grands et petits appareils d’électroménager. La société est distributeur officiel et exclusif
d’appareils qu’elle fait fabriquer, importe puis vend sous ses propres marques : Lagon, Cuccina et PierreMichel. La
société ne fabrique donc pas ellemême, elle a une activité importante d’importation.
Distrisys ne vend pas ses produits en direct aux consommateurs. La société dispose d’un réseau de revendeurs et
distributeurs agréés. Son réseau est de plusieurs types : réseau de distribution généraliste, réseau de magasins
spécialisés et enfin réseau de sites marchands.
Distrisys est issue historiquement de plusieurs sociétés acquises par croissance externe. La société dispose de cinq
sites géographiques :
● Trois en France : le siège à Paris, AixEnProvence et Bordeaux.
● Deux à l’étranger : Barcelone et Munich.
Chaque site dispose de son propre PGI (Progiciel de Gestion Intégrée ou ERP en anglais), qui a été toutefois
homogénéisé pour en faciliter la gestion et la maintenance.
La direction de Distrisys est depuis très longtemps confrontée à des problèmes de qualité de données et souhaite se
doter d’outils permettant d’appréhender leurs données de manière globale. Si la direction n’engage pas encore de
démarches de Management de la Performance, elle y pense très sérieusement.
C’est dans ce contexte que le service informatique, en liaison avec la direction financière, amorce un projet de mise en
œ uvre d’un système décisionnel.
L’équipe informatique a mené une étude de choix d’outils et a porté son dévolu sur la solution BI Microsoft. Disposant
déjà des licences SQL Server 2008 R2 et d’un portail intranet SharePoint 2010. La solution en plus d’être cohérente,
très complète et compétitive techniquement, dispose d’un formidable rapport qualitéprix.
Tout au long de l’ouvrage, nous allons étudier et traiter le cas de la société Distrisys. Nous allons suivre toutes les
étapes de mise en œ uvre de la solution décisionnelle au sein de la société. Afin de suivre le déroulement du projet et
faire les manipulations pour bâtir en parallèle le système décisionnel, vous n’aurez besoin que d’une installation de
SQL Server. La version 2008 R2 développer ou Enterprise ferait idéalement l’affaire, mais si vous disposez de la version
2005 ou 2008 vous pourrez aussi parfaitement suivre de votre côté le déroulement du projet.
Les versions SQL Server 2005, 2008 et 2008 R2 sont assez proches les unes des autres. De plus, vous
comprendrez assez vite qu’audelà des outils et des versions, ce sont les concepts qui sont vraiment
importants.
L’exploitation de la solution décisionnelle nécessitera, quant à elle, une version d’Excel, idéalement Excel 2010. Mais je
vous engage à faire des tests avec toutes les versions d’Excel disponibles et déployées dans votre entreprise afin d’en
apprécier les différences.
Des versions d’évaluation de ces produits sont disponibles en téléchargement sur le site Technet Evaluation

Center à l’adresse http://technet.microsoft.com/frfr/evalcenter/

Le choix des licences
La réalisation d’un système décisionnel avec la suite Microsoft BI (Business Intelligence) demande généralement moins
d’investissement que les solutions concurrentes, mais demande toutefois de disposer des bonnes éditions et si
possible de la totalité de la suite. La mise en place d’un système décisionnel avec Microsoft n’est pas gratuite.
Nous avons vu au chapitre précédent, que la mise en place globale de la solution décisionnelle Microsoft nécessite trois
licences distinctes. Dans leurs versions les plus récentes, ces licences sont :
● SQL Server 2008 R2
● Office 2010
● SharePoint 2010
Voyons dans le détail quelles sont les éditions nécessaires.
Nous n’entrerons pas dans les considérations de tarifs. Sur ce sujet, prenez contact directement avec votre
revendeur ou avec votre commercial Microsoft pour une estimation précise.
1. SQL Server 2008 R2
Le discours et les plaquettes commerciales de Microsoft vantent la disponibilité des outils décisionnels de la suite SQL
Server dès l’édition Standard.
Dans la réalité, mettre en place une solution décisionnelle avec SQL Server réclame obligatoirement de disposer de
l’édition Enterprise, et la différence de coût entre l’édition Standard et Enterprise est vraiment substantielle.
L’édition Enterprise est impérative, car audelà des considérations de haute disponibilité ou montée en charges, cette
édition dispose de fonctionnalités décrites de manière assez obscure dans les plaquettes commerciales ou de
comparaison de version, mais qui se révèlent essentielles.
Nous verrons notamment au chapitre La modélisation dimensionnelle, que pour modéliser correctement notre
entrepôt de données, nous aurons besoin de deux fonctionnalités incontournables :
● La semiadditivité : entre autres raisons, sans cette fonctionnalité, votre entrepôt de données sera amputé
de toutes les tables de faits de type photo. Il existe trois types de tables de faits et ce dernier type est celui
qui apporte la plus grande valeur ajoutée par rapport à des systèmes opérationnels classiques. La semi
additivité vous permet aussi de gérer des faits de type température ou pression, qui sont des faits qui ne
s’additionnent pas.
● Les perspectives : il s’agit de la fonctionnalité permettant de réaliser un entrepôt de données conforme en

toute sérénité. La perspective décrit des contextes cohérents d’analyse de données. Sans cette
fonctionnalité, le principe de l’entrepôt de données, exposé au travers d’Analysis Services, est mis à mal.
Une dernière fonctionnalité est essentielle pour assurer la pérennité de votre système décisionnel :
● L’intelligence financière : nous ne l’aborderons pas dans cet ouvrage, mais l’intelligence financière est la
fonctionnalité ouvrant Analysis Services au Management de la Performance et à toutes les problématiques
des services financiers et de contrôle de gestion. L’ultime finalité du décisionnel est tout de même de donner
les moyens de gérer la performance. Il serait dommage de se priver des moyens techniques.
En fait, la différence entre l’édition Standard et Enterprise se fait sur ces nombreux petits détails. Les quelques
éléments donnés en exemple cidessus ne concernent que Analysis Services. La différence de fonctionnalités entre
les versions touche bien évidemment aussi Integration Services et Reporting Services.
En conclusion, sauf après étude et contexte spécifique, la mise en œ uvre de la solution BI Microsoft nécessite
toujours SQL Server édition Enterprise.
2. Office 2010

Par la licence Office 2010, le décisionnel s’intéresse surtout à Excel. Dans toutes les éditions d’Excel, vous aurez la
possibilité de faire des tableaux croisés dynamiques nativement et d’exploiter le contenu des cubes Analysis Services.
Néanmoins, si vous souhaitez lier votre décisionnel à SharePoint, préférez alors l’édition Professional Plus aux autres
éditions. Pour vous faire une idée de cette fonctionnalité, le chapitre Restituer les données décisionnelles Excel
aborde succinctement la publication de contenu Excel dans Sharepoint (les services Excel).
3. SharePoint 2010
L’étude de SharePoint n’est pas abordée dans cet ouvrage. Il n’en reste pas moins que la solution est nécessaire
pour bénéficier de la suite décisionnelle complète. Même si vous pensez vous passer de SharePoint dans un premier
temps, je vous conseille vivement de l’intégrer dans vos estimations de coûts prévisionnels.
SharePoint est livré gratuitement avec Windows Server sous le nom de SharePoint Fundation 2010 (anciennement
Windows SharePoint Services WSS). Cette édition vous permettra de commencer à travailler avec un portail et
d’exposer vos rapports Reporting Services.
Toutefois, pour bénéficier des fonctionnalités décisionnelles de SharePoint, il vous faudra acquérir la version
payante : SharePoint Server 2010 (anciennement Microsoft Office Sharepoint Server MOSS en version 2007) en
édition Enterprise. L’édition Standard de SharePoint Server 2010 étant dépourvue des fonctionnalités décisionnelles
que sont Excel Services et PerformancePoint Services.

Architecture serveur
Le choix de l’architecture serveur est un préalable nécessaire au projet pour plusieurs raisons :
● Estimer le coût des machines et du matériel nécessaire.
● Estimer le coût des licences.
● Laisser le temps à l’équipe exploitation de s’organiser, de se former et d’installer les environnements.
La mise en place d’un projet décisionnel nécessite, en fait, plusieurs environnements de travail. On dénombre
généralement :
● Un environnement de développement : c’est sur cet environnement que seront réalisés notamment les
développements ETL. Ce type de développement est assez gourmand en ressources machine, il s’agit alors de
le désolidariser de l’environnement de travail des utilisateurs.
● Un environnement de recette : l’environnement de recette et d’intégration est souvent le même.
L’environnement de recette ou de préproduction, est l’environnement de travail sur lequel on évalue la qualité
du travail réalisé en développement. La recette est très importante et peut parfois prendre du temps, il est donc
important que cet environnement soit distinct du développement et de la production afin de ne perturber ni les
développeurs, ni les utilisateurs.
● Un environnement d’intégration : l’environnement d’intégration est quant à lui un laboratoire sur lequel l’équipe
exploitation peut tester, s’entrainer et préparer les travaux de maintenance ou de mises à jour applicatives.
Par exemple, si vous partez tout d’abord sur SharePoint Fundation 2010, puis que vous souhaitez passer sous SharePoint
Server 2010, l’environnement d’intégration permettra à l’équipe exploitation de réaliser une étude d’impact et d’écrire les
procédures permettant d’éviter les écueils et de réduire les perturbations sur l’environnement de production.
● Un environnement de production : c’est l’environnement de travail des utilisateurs. De fait, cet environnement
doit avoir le moins possible d’interruptions de services tout en offrant avec constance les meilleures
performances.
Généralement, nous constatons trois environnements : l’environnement de recette et d’intégration étant le même. En
début de projet décisionnel, deux environnements peuvent suffire : l’environnement de production, jouant dans un
premier temps aussi le rôle d’environnement de recette. Toutefois, une fois que le projet est lancé et que le premier lot
projet est en production, il est vraiment important de se doter au moins d’un environnement recette/intégration.
1. L’environnement de production
La performance d’un environnement de production est évaluée suivant deux axes :
● Sa capacité à monter en charge pour répondre efficacement à toutes les demandes utilisateurs. Rappelons
que le système décisionnel doit présenter des chiffres dans des délais de l’ordre de la seconde. Un décideur
n’attendra certainement pas plusieurs minutes que son tableau veuille bien s’afficher.
● Sa haute disponibilité. Par haute disponibilité, on entend sa capacité à offrir un service chaque fois qu’un
utilisateur en a besoin. Un service qui est régulièrement indisponible fera fuir les utilisateurs. De plus, si le
décisionnel devient l’outil de pilotage de l’entreprise, cela peut devenir catastrophique si celuici ne fonctionne
pas lorsqu’on a besoin de lui pour prendre une décision importante.
Les critères entrant en jeu lors de la définition de l’environnement de production sont :
● La volumétrie : le volume de données influe bien évidemment sur la taille des machines et des disques.
Lorsque l’on parle d’estimation du volume de données, il faut sousentendre l’ordre de grandeur de l’entrepôt
de données : parleton de Mo, de Go, de centaine de GO ou de To ? Il ne faut pas chercher à faire une
estimation exacte. Généralement, pour estimer l’ordre de grandeur d’un entrepôt de données, on se base sur
l’estimation de la volumétrie des tables de faits qui seront susceptibles d’être les plus volumineuses. Cette

estimation devra être réalisée à partir d’hypothèses précises, chiffrées et validées.
Par volumétrie, il est aussi vraiment très important de prendre en considération le volume des données de
référence. Si vous disposez d’une donnée de référence de plusieurs millions de membres (les abonnés d’une
société de télécom ou les produits d’un grand supermarché par exemple), ce volume de données aura forcément un
impact un jour ou l’autre sur le cache nécessaire au niveau de l’ETL (mémoire RAM) ou sur la probable émergence
d’une table de type photo gigantesque.
● Le nombre d’utilisateurs au total et le nombre d’analystes : vous comprendrez aisément l’importance de ce
critère si vous réalisez un suivi commercial de votre réseau de plusieurs milliers d’agents… Le nombre
d’analystes est quant à lui important, car ces utilisateurs ont un mode de consommation du système
décisionnel qui pèsera beaucoup plus sur ses performances qu’un utilisateur lambda qui va recevoir une fois
par mois un rapport dans sa boîte mails.
● Les prévisions d’évolution et de montée en charge du système : l’architecture devra bien évidemment prendre
en compte la croissance prévisionnelle du périmètre fonctionnel de l’entrepôt de données. Une augmentation
du périmètre fonctionnel ayant forcément un impact sur le nombre d’utilisateurs et sur la volumétrie du
système.
● La haute disponibilité : parmi tous les critères, l’exigence en haute disponibilité est surement le critère le plus
contraignant et celui qui a le plus d’impact dans l’élaboration de l’environnement de production. On mesure la
disponibilité avec des taux de disponibilité composés de 9 :
● Un taux de disponibilité de 99% correspondant à un arrêt de service de 3.65 jours dans l’année.
● Un taux de 99,9% à un arrêt de 8,75 heures par an.
● Un taux de 99,99% à un arrêt de 52 minutes par an... et ainsi de suite.
La contrainte de haute disponibilité étant généralement présente, de ce fait, la typologie de l’environnement de
production est bien souvent celle présentée cidessous :
Typologie de l’architecture de production en haute disponibilité
Cette architecture nécessite :
● 2 serveurs BackEnd en cluster : qui devront être deux grosses machines physiques.
● 2 serveurs Front End en load balancing (ou équilibrage de charges) : qui peuvent être deux petites machines

virtuelles.
● 1 serveur Active Directory : il s’agira vraisemblablement d’un serveur existant. Sachez cependant que le
service Active Directory sera nécessaire pour installer et configurer correctement la solution BI Microsoft.
● Une baie SAN : l’optimisation d’une architecture serveur passe nécessairement par un plan de découpage et
d’isolement des bases et des partitions sur des disques physiques distincts :
● Il s’agit tout d’abord de séparer les fichiers Data, Logs et Temp du service SQL Server Database
Services sur des disques distincts.
● Il s’agit ensuite qu’au sein d’un même flux, le disque contenant la base ou la table source soit distinct
de celui contenant la base ou la table de destination. Et ce, afin d’éviter qu’un disque physique
travaille à la fois en lecture et en écriture au cours de l’exécution d’un flux.
Si vous ne disposez pas de SAN et que vous ne souhaitez pas investir, prévoyez un maximum de disques durs.
Cet ouvrage n’a pas vocation à être un livre blanc sur l’installation de la solution BI. Toutefois, voilà quelques
remarques ou points d’attention :
● Tous les services applicatifs seront installés sur les serveurs FrontEnd mais auront leur base de données de
référence installée sur le cluster des serveurs de BackEnd.
● Installez au moins deux instances SQL Server Database Services : l’une pour accueillir les bases décisionnelles
(DW et SA cf chapitre suivant) et l’autre pour accueillir les bases de données de référence des applicatifs,
telles que Reporting Services ou SharePoint.
● Tous les services seront installés sans exception avec des comptes de service qui seront exclusivement des
comptes de domaines. Avoir deux comptes est vivement conseillé : un pour l’installation de tous les services
de BackEnd, un autre pour tous les services de FrontEnd. D’autres comptes pourront être indispensables
notamment en ce qui concerne la configuration de SharePoint.
● Enfin, cette architecture étant distribuée, elle requerra forcément la configuration de la délégation de sécurité
Kerberos. Il s’agit en fait de la difficulté de l’installation. Je vous engage alors à contacter d’une part votre
équipe exploitation et d’autre part l’éditeur ou un prestataire spécialisé pour vous faire accompagner dans la
mise en place de Kerberos.
Enfin, pour être concret, je vous propose cidessous deux configurations types :
● La configuration de production intégrant la haute disponibilité :
Exemple de configuration pour un environnement de production en haute disponibilité

● La configuration de production sans haute disponibilité :
Exemple de configuration de production sans haute disponibilité
Attention toutefois de bien comprendre qu’une interruption de service de plus de 24 heures est envisageable
avec une configuration n’intégrant pas la haute disponibilité.
La taille des machines devra bien évidemment être adaptée à votre contexte (volumétrie, utilisateurs, budget…) et aux
prix pratiqués par le marché. Discutez et échangez autour de de la configuration avec votre équipe informatique
chargée de l’exploitation.
Si vous disposez d’une licence SharePoint 2007, les serveurs Front End doivent être installés en 32 bits afin
de pouvoir installer la totalité de la suite Microsoft BI et notamment la solution Proclarity Analytics Server.
Cette dernière solution n’est plus obligatoire avec la licence SharePoint Server 2010.
2. L’environnement de développement
L’environnement de développement n’est pas soumis aux contraintes de haute disponibilité. Il s’agit toutefois de
réaliser un environnement robuste et performant afin que l’équipe de développement puisse travailler avec tout le
confort nécessaire.
Afin d’améliorer la productivité de vos équipes, je vous engage à investir dans un outil de contrôle de code source. Cet
outil vous permettra de partager vos projets, historiser les changements, tracer les modifications et permettre de
réaliser une sauvegarde régulière et quotidienne de l’ensemble.
Dans la solution Microsoft, le serveur et l’outil de contrôle de code source est Team Fundation Server et Visual
Studio Team System.
En terme d’architecture serveur, une architecture toutenun, comprenant l’ensemble des serveurs présents en
production est suffisante. Prévoyez tout simplement une bonne machine.
À titre d’exemple, je vous propose cette configuration, qui devra elle aussi être adaptée à votre contexte (au nombre
de développeurs, au nombre de projets…) :

Exemple de configuration pour un environnement de développement
3. L’environnement de recette et d’intégration
En terme de configuration, l’environnement de recette n’a pas de contrainte particulière et peut ressembler par
exemple à l’environnement de développement.
L’environnement d’intégration quant à lui devra si possible ressembler autant que possible à l’environnement de
production pour y intégrer les mêmes contraintes.
En terme de budget, cela peut revenir bien évidemment très cher. Un compromis moyen peut être trouvé en
considérant au moins un environnement de recette/intégration avec une architecture de production sans la haute
disponibilité.
Tout est affaire de budget et de négociation avec l’équipe chargée de l’exploitation de vos machines.

Découverte des outils SQL Server
Avant de vous lancer dans les chapitres pratiques qui vont suivre, je vous propose une petite découverte des outils
SQL Server que vous allez avoir à utiliser.
Pour l’ensemble des outils, SQL Server dispose de deux consoles de gestion principales :
● La console SQL Server Management Studio (ou SSMS) est la console destinée aux administrateurs. Vous
pourrez y créer des bases de données relationnelles, programmer vos sauvegardes, y faire vos restaurations…
● La console Business Intelligence Developpement Studio (ou BIDS) est la console destinée aux développeurs.
Vous pourrez y développer des flux ETL, des rapports ou des cubes.
1. SQL Server Management Studio
a. Connexion à des serveurs SQL Server
Ouvrons SQL Server Management Studio (SSMS) afin de prendre connaissance de la console d’administration et
aborder quelques sujets dont vous aurez sûrement besoin dans les chapitres suivants.
■ Dans le menu Démarrer, ouvrez le répertoire Microsoft SQL Server 2008 R2, puis cliquez sur SQL Server
Management Studio.
Une fenêtre de connexion s’ouvre :
Cette fenêtre vous permet de vous connecter à un serveur, quel que soit son type :
● Moteur de base de données
● Analysis Services
● Reporting Services
● Integration Services
L’administration de tous les outils décisionnels SQL Server a été centralisée pour plus de facilité dans un seul et
unique environnement.
■ Pour vous connecter à votre serveur de base de données, saisissez le nom de votre serveur puis cliquez sur Se

conn.
Le nom de votre serveur est généralement de la forme NomMachine\Instance. Vous verrez d’ailleurs sur la
copie d’écran, que dans mon cas, mon serveur de base de données est accessible sur le serveur Server1
\r2. Server1 étant le nom de la machine et r2 le nom de l’instance SQL Server.
Une fois la connexion établie, la fenêtre Explorateur de solutions affiche les objets d’administration du serveur de
bases de données sur lequel vous êtes connecté :
L’explorateur d’objets de SSMS
SQL Server Management Studio vous offre la possibilité de vous connecter, soit à un autre serveur de base de
données relationnelle, soit à d’autres types de serveur.
Nous allons par exemple nous connecter au serveur Analysis Services. Pour cela :
■ Dans l’Explorateur d’objets, cliquez sur Se connecter, puis sur Analysis Services.
■ Dans la fenêtre de connexion, saisissez le nom de votre serveur Analysis Services.
Le nom d’un serveur Analysis Services se compose de la même manière que le serveur de base
relationnelle : NomMachine\Instance.
Une fois la connexion établie les objets d’administration de votre serveur Analysis Services s’affichent en dessous
de votre connexion précédente :
b. Modification des options de l’interface graphique
Pour la suite des manipulations, nous avons besoin de modifier une option de configuration de l’interface de SSMS.
■ Pour modifier les options de l’interface, cliquez dans la barre de menu sur Outils, puis sur Options.
Nous allons désactiver une option, qui est activée par défaut après l’installation de SQL Server. Cette option
empêche de modifier une table ou tout autre objet de base de données à l’aide de l’interface graphique. Cette
protection n’étant pas très pratique pour la suite des manipulations, nous allons la désactiver. Pour cela :

■ Cliquez sur l’onglet Designers.
■ Puis décochez l’option Empêcher l’enregistrement de modifications qui nécessitent une recréation de table.
■ Cliquez enfin sur OK pour valider la modification.
c. Restauration d’une base de données
En suivant l’ordre chronologique des chapitres, vous allez être amené à créer ex nihilo une base de données.
Toutefois, il vous sera nécessaire de restaurer une base de données pour les besoins du chapitre Alimenter
l’entrepôt de données avec SSIS. Vous aurez aussi besoin de restaurer une base de données, si vous souhaitez lire
les chapitres par ordre d’intérêt, plutôt que par ordre chronologique.
Pour restaurer une base de données, procédez ainsi :
■ Au niveau de la connexion de votre moteur de base de données, faites un clic droit sur Base de données, puis

dans le menu contextuel, sélectionnez Restaurer.
La fenêtre Restaurer une base de données s’affiche. Pour restaurer par exemple la base de données DistrisysSA,
dont vous aurez besoin au chapitre Alimenter l’entrepôt de données avec SSIS, procédez ainsi :
■ Téléchargez sur le site des Éditions ENI, dans le répertoire 5 Alimenter votre entrepôt de données avec SSIS, le
fichier DistrisysSA.bak.
■ Saisissez dans le champ Vers la base de données le nom de la base de données à restaurer. Dans notre cas
DistrisysSA.
■ Cochez l’option À partir de l’unité.
■ Parcourez votre disque à la recherche du fichier DistrisysSA.bak préalablement téléchargé.
■ Un fichier de sauvegarde peut contenir plusieurs jeux de sauvegarde, cochez le jeu le plus récent.

Interface de restauration d’une base de données
■ Enfin cliquez sur OK pour lancer la restauration.
2. Business Intelligence Developpement Studio
Enfin, ouvrons l’interface de développement : Business Intelligence Developpement Studio (BIDS).
■ Dans le menu Démarrer, ouvrez le répertoire Microsoft SQL Server 2008 R2, puis cliquez sur Business
Intelligence Developpement Studio.
L’interface de développement BIDS n’est autre en fait que Visual Studio 2008. L’interface de développement
décisionnel bénéficie donc de la richesse de tous les compléments et outils de productivité complémentaires existants
sur le marché pour Visual Studio 2008.

L’interface Business Intelligence Developpement Studio
Pour voir les projets décisionnels que vous pouvez créer :
■ Dans la barre de menu, cliquez sur Fichier, puis sélectionnez Nouveau et enfin cliquez sur Projet.
Tous les projets de développement décisionnel seront gérés par BIDS
BIDS étant une version allégée de Visual Studio 2008, vous ne bénéficiez pas de la possibilité de créer des projets de
développement .Net. En revanche, il vous est offert la possibilité de créer des projets :
● Analysis Services, pour créer des bases multidimensionnelles : nous aborderons ce sujet dès le prochain

chapitre : Réaliser son premier système décisionnel.
● Integration Services, pour réaliser les flux d’alimentation ETL : nous aborderons ce sujet dans le chapitre
Alimenter l’entrepôt de données avec SSIS.
● Reporting Services, pour créer des rapports : nous aborderons ce sujet dans le chapitre Restituer les
données décisionnelles.
Maintenant que vous savez comment accéder à SSMS et à BIDS, nous allons commencer dès le prochain chapitre à
entrer dans le vif du sujet. Nous allons créer un entrepôt de données et faire connaissance avec les premiers
concepts décisionnels.

Introduction
Lors de ce chapitre, nous utiliserons les outils SQL Server pour réaliser la première brique de notre système
décisionnel.
Nous commencerons par mettre en œ uvre le système d’analyse des factures qui permettra à la société Distrisys,
d’analyser son chiffre d’affaires (CA), ses marges et ses coûts.
Dans une entreprise commerciale, commencer par mettre en œ uvre l’analyse des factures est généralement un bon
choix, pour deux raisons :
● Raison technique : généralement le système de facturation est assez bien maitrisé par le service informatique
et les données sont structurées, présentes et accessibles dans le système d’informations de l’entreprise.
● Raison métier : les données de facturation intéressent la plupart des services tels que la direction générale, la
direction des ventes, la finance, le marketing... et la mise à disposition d’un système d’analyse des factures est
souvent assez riche en informations et donc en valeur ajoutée.
Les données de facturation seront analysables par les utilisateurs suivant quatre axes principaux :
● L’axe produit
● L’axe client
● L’axe site, qui permettra de connaître le site à l’origine de la vente
● L’axe temps
Lors de ce chapitre nous emploierons la méthode de travail suivante :
● Nous modéliserons la solution finale en construisant l’entrepôt de données, puis le cube.
● Nous générerons des données de test afin de nous assurer que le modèle répond à nos attentes.
● Puis dans une étape ultérieure, nous nous intéresserons à remonter les données de vos systèmes sources
dans l’entrepôt de données, que nous aurons précédemment modélisé.
Il est important de commencer à modéliser la solution avant de l’alimenter. Toute autre démarche consistant à partir de
vos données sources pour construire un entrepôt de données serait vouée, à terme, à l’échec.
Mettonsnous dès à présent au travail !

Création des tables de faits et de dimension
1. Création de l’entrepôt de données
Nous allons commencer par créer l’entrepôt de données. Nous appellerons cette base de données : DistrisysDW.
Pour information les deux lettres DW sont le sigle de Data Warehouse, traduction anglaise d’Entrepôt de données.
Pour créer cette base de données il nous faut utiliser l’outil SQL Server Management Studio (SSMS).
■ Ouvrez la console SQL Server Management Studio.
■ Créez une nouvelle base de données DistrisysDW avec le modèle de recouvrement Simple. En effet, une base de
données décisionnelle ne doit pas enregistrer les logs de transaction. D’une part parce que les logs seraient trop
volumineux, d’autre part parce que le système de recouvrement au quotidien sera géré par le système d’audit. Pour
plus de détails sur ce sujet, reportez vous au chapitre Alimenter l’entrepôt de données avec SSIS L’audit des flux
ETL.
■ Assurezvous que le compte de service de votre serveur SQL Server a les droits en lecture sur DistrisysDW. Si vous
ne savez pas comment vous y prendre, vous avez à votre disposition un complément téléchargeable sur le site des
Éditions ENI.
Vous venez de créer un entrepôt de données et de vous assurer que le compte de service a bien les droits d’accès sur
cette nouvelle base de données. Dans les prochaines étapes, nous allons nous atteler à la création de la table de faits
et des dimensions.
2. Création d’une table de faits
D’abord quelques explications sur la construction d’une table de faits. Chaque table de faits sera construite en trois
blocs.
Le premier bloc détaille les liaisons avec les tables de dimension :
Les quatre axes pour analyser les factures sont les suivants :
● DateFacturation_FK permettra d’identifier la date de facturation et fera la liaison avec la dimension Temps.
● Site_FK permettra d’identifier le site de facturation et fera la liaison avec la dimension Site.
● Produit_FK permettra d’identifier le produit facturé et fera la liaison avec la dimension Produit.
● Client_FK permettra d’identifier le client facturé et fera la liaison avec la dimension Client.
Ces champs définissent la granularité de notre table de faits.
Dans notre cas, la granularité de la table de faits FactFacture correspond à une ligne : par jour (date de facturation),
par site de facturation, par produit et par client. Cela signifie que, potentiellement, nous pourrons regrouper et
sommer en une seule ligne, les lignes de facture ayant les mêmes critères.
Ce regroupement est appelé un agrégat.

Veuillez noter que chaque champ de liaison ne tolère pas de champ null.

Ces champs de liaison seront des clés étrangères. Une table de faits n’a pas de clé primaire, c’est une de ses
caractéristiques.
Le second bloc détaille les mesures de la table de faits :
Ces mesures sont issues d’un travail conjoint avec le service contrôle de gestion de Distrisys. La facture est l’occasion
de redéfinir les termes et le découpage des différents montants. Suite à l’atelier nous avons posé les relations
suivantes entre ces différentes mesures :
● Prix Catalogue = CA TTC + Remise
● CA TTC = CA HT + TVA
● CA HT = Coût Indirect + Coût Direct Main d’œ uvre + Coût Direct Matière + Marge
Les mesures de la table des faits sont tous de type numeric(9,2) afin de gérer les nombres réels compris entre
1 000 000,00 et 1 000 000,00.
La précision de 9, représentant le nombre de chiffres total et 2, le nombre de chiffres après la virgule. Pour mieux
comprendre le fonctionnement du type numérique, veuillezvous reporter au tableau cidessous :
Mini Maxi Coût en octets
Numeric(9,1) 10 000 000,0 10 000 000,0 5
Numeric(9,2) 1 000 000,00 1 000 000,00 5
Numeric(9,3) 100 000,000 100 000,000 5
Le type numeric (9,x) coute donc 5 octets. Ce type de données représente le stockage de la valeur réelle, le moins
couteux en octets.
Les mesures de la table de faits ne doivent pas accepter de valeur null
Le troisième bloc liste des champs dits de dimensions dégénérées :
Ces champs n’ont pas d’utilité dans l’analyse. Ils représentent généralement une référence au grain de la table de
faits. Ces champs permettront de faire le lien entre le système décisionnel et le système source.
En effet, nous n’analyserons jamais nos factures par le numéro de facture. En revanche, nos utilisateurs souhaiteront
peut être connaître la liste des numéros de factures qui compose les ventes du mois d’un produit, pour un client et
pour un site en particulier. Nous verrons l’usage concret des dimensions dégénérées au chapitre La modélisation
dimensionnelle Facturation et commande client.
Attention, ces champs sont assez coûteux en espace, car ils sont généralement en type varchar : 1 octet par
caractère. Un varchar(6) coûte donc jusqu’à 6 octets par ligne dans la table de faits. Il ne faut donc pas
tomber dans l’excès. La création d’un tel champ doit être pesée.
Nous allons maintenant nous atteler à la création d’une table de faits : FactFacture.
■ Créez la table de faits des factures de la manière suivante :

■ Enregistrez la table et nommezla : FactFacture.
Toutes les tables de faits de l’entrepôt de données seront préfixées par Fact afin de les identifier comme
telles.
La table doit apparaître comme cidessous :
3. Création des tables de type dimension
Maintenant que nous avons créé la table de faits des factures, nous allons nous atteler à construire les tables de type
dimension utilisées dans l’analyse des factures. De même que les tables de faits sont préfixées par Fact, les tables de
type dimension seront préfixées par Dim.
Nous allons donc créer les tables de type dimension suivantes :
● DimProduit, pour la dimension produit
● DimSite, pour la dimension site
● DimClient, pour la dimension client

Commençons par la création de la table dimension Produit.
Comme pour la table de faits, quelques explications s’imposent quant à la construction d’une table de type dimension.
La table de dimension Produit est construite en deux blocs. Ces deux blocs devront se retrouver dans chacune de nos
tables de type dimension.
Le premier bloc, identifie le champ de clé technique de la table de dimension Produit.
Cette clé technique ne doit pas être issue de votre système source. Elle ne doit pas non plus être une codification
métier. Il est important que votre entrepôt de données utilise et gère ses propres identifiants de table de dimension.
Nous aurons donc pour chacune de nos tables de dimension, une clé technique de type int, en incrémentation
automatique.
Le deuxième bloc de colonnes liste les attributs de la dimension Produit
Nous remarquons que les attributs sont tous de type varchar, pour supporter une valeur sous forme de chaînes de
caractères. Le nombre spécifié entre parenthèses correspondant au nombre de caractères maximum du champ.
La dimension Produit se décomposera en trois niveaux :
● le niveau Famille ;
● le niveau Sous Famille ;
● le niveau Produit.
Chacun des attributs Famille, Sous Famille et Produit est décomposé en deux champs au sein de la table de dimension
de l’entrepôt de données.
Le champ suffixé Code (ProduitCode par exemple) servira de clé d’identification unique de l’attribut, tandis que l’autre
champ (Produit par exemple) correspondra à sa désignation : la valeur affichée pour l’utilisateur.
Par exemple, pour le champ ProduitCode LL1100, le champ Produit correspondant est LAGON LL 1100.
Cette façon de procéder est nécessaire dans le cas des attributs disposant déjà d’une codification ou des
attributs générant de nombreuses valeurs comme les produits, les clients, les fournisseurs, les actions
commerciales…
Créez la table de dimension Produit :
■ Créez les colonnes de table comme cidessous :

■ Enregistrez la table en la nommant DimProduit.
La table DimProduit est créée :
■ Positionnez une clé primaire sur la première colonne Produit_PK et enregistrez les modifications :

Pensez à enregistrer chacune de vos modifications.
■ Éditez le contenu de la table DimProduit :
La table est actuellement vide.
■ Saisissez directement dans l’interface les 10 nouvelles lignes comme cidessous :

Vous trouverez en téléchargement sur le site des Éditions ENI, un script SQL permettant de générer ces lignes.
Pour les besoins de notre cas, nous venons de saisir manuellement la valeur des données de Produit_PK.
Néanmoins, il est préférable de laisser SQL Server gérer et générer la valeur de ce champ. Pour ce faire, il faut
activer la propriété d’incrémentation automatique. Une fois en incrémentation automatique, vous ne pourrez plus
saisir manuellement la valeur de ce champ. Pour les besoins de notre cas, nous activerons l’incrémentation
automatique seulement après la saisie des données, pour nous assurer que les clés techniques aient bien les
valeurs figurant dans les exemples proposés.
■ Créez une identité avec incrémentation automatique. Pour cela, changez la propriété (Est d’identité) à Oui en
utilisant la liste déroulante.
Un peu de vocabulaire :
La valeur unique que prend chaque attribut est appelée un membre. Ainsi dans notre exemple, l’attribut Produit
dispose de dix membres. De même l’attribut Famille dispose de deux membres : Gros Ménager et Petit Ménager. Le
nombre de lignes de la dimension est appelé la cardinalité de la dimension. Dans notre exemple, la dimension Produit a
une cardinalité de 10.
Vous savez maintenant créer une table et vous comprenez la composition d’une dimension.
■ Créez la table de dimension DimSite :

Vous devrez alors avoir :
Vous pouvez constater que la dimension DimSite est composée de trois blocs de colonnes distincts. Nous retrouvons
les deux blocs obligatoires :
Le premier référence la clé technique :
Le second bloc référence les attributs de dimension :
Mais il existe un troisième bloc, qui liste les liaisons avec d’autres dimensions :
Un peu à la manière de la table des faits, GeographieSite_FK est une clé étrangère qui fera la liaison avec une
dimension Geographie et permettra de localiser le site sur un axe géographique : pays, département, ville…
Pourquoi faire la liaison avec une table de dimension distincte ? Pourquoi ne pas créer les attributs Pays,
Département et Ville directement dans cette dimension Site ? Tout simplement, parce que la dimension
géographie est un axe qui sera partagé par d’autres dimensions autres que Site. L’axe Geographie au sein de la
dimension Client nous permettra de localiser les clients de Distrisys. Nous créerons donc une table DimGeographie
qui centralisera toutes les informations concernant la localisation géographique.
■ Créez la table de dimension DimGeographie :
Notre dimension Geographie dispose donc des attributs nécessaires pour réaliser des analyses par pays, département
et ville.
Dans la réalité, je vous conseillerais vivement d’apporter une attention particulière à cette dimension, en y intégrant la

région et de descendre jusqu’au code INSEE. Cette dimension est importante car c’est la clé qui vous permettra
d’analyser vos données à l’aide d’outils de cartographie.
■ Éditez le contenu de la table DimGeographie (11 lignes) :
■ Éditez le contenu de la table DimSite (5 lignes) :
Pour faciliter la saisie, vous trouverez le script de création des données en exemple, en le téléchargeant sur le site du
livre.
Au vue de ces exemples, il faut donc lire que l’agence Sud se situe à AixenProvence. En effet, l’agence Sud fait référence à
GeographieSite_FK qui est égal à 8. Et la table DimGeographie nous apprend que l’identifiant 8 fait référence à la ville d’Aix
enProvence.
Finissons enfin par la création de la dimension client.
■ Créez la table de dimension DimClient :
Les attributs TypeClient et SegmentationClient ne comprendront que très peu de valeurs et ne disposeront
pas de codification métier. C’est pour cela que l’attribut avec le suffixe Code n’est pas nécessaire.
■ Éditez le contenu de la table DimClient (10 lignes) :

Au final, au sein de Management Studio, vous devriez avoir :
N’oubliez pas de spécifier l’incrémentation automatique des tables DimSite, DimClient et DimGeographie.
Notre entrepôt de données se dessine lentement. Malgré tout, il nous reste une dernière dimension essentielle à
créer. Il s’agit de la dimension Temps. L’importance est telle que nous y consacrerons la partie suivante.

La dimension temps
Dans un système décisionnel, la dimension Temps revêt une importance particulière et doit faire l’objet de la plus
grande attention. La table Temps est unique et sa présence est obligatoire dans toute table de faits, quelle qu’elle
soit. La présence de la dimension Temps dans une table de faits est une des caractéristiques d’un système décisionnel
par rapport à un système transactionnel.
La table de dimension Temps a une granularité au jour.
● Dans certains cas, vous aurez besoin de faire des analyses à l’heure : il s’agira alors de créer une dimension

Heure. Nous n’intégrerons jamais les heures au sein de la dimension Temps.
● Dans d’autres cas, vous aurez une table de faits à la granularité mois : il s’agira alors de considérer le premier
jour du mois, comme étant représentatif du mois. Nous aborderons ce caslà ultérieurement, dans le chapitre
La modélisation dimensionnelle Facturation et commande client.
Le premier réflexe est de construire une table de dimension Temps assez simple, comme cidessous :
Ne créez pas cette table car cette construction se révèlera vite très insuffisante. Il faudrait la compléter par
bon nombre d’attributs supplémentaires.
L’expérience vous apprendra qu’une table de dimension bien construite permettra d’anticiper bon nombre de
complications ultérieures.
Au cours des pages suivantes, nous allons créer la table Temps, saisir son contenu, puis la peaufiner pour qu’elle
corresponde à nos attentes. Néanmoins, la table DimTemps finale est disponible en téléchargement au format csv sur
l’espace de téléchargement du livre.
L’intérêt de la procédure qui suit est de vous permettre de vous constituer votre propre DimTemps qui reflétera les
spécificités de votre organisation.
Pour commencer, nous allons nous servir d’un assistant de projet SSAS, afin de générer une première version de la
table DimTemps. La création de la table de dimension Temps va nous permettre d’avoir un premier contact avec l’outil
de création de cubes de Microsoft : BIDS (SQL Server Business Intelligence Developpement Studio). Nous reviendrons,
plus tard dans le chapitre et plus en détails, sur l’environnement de création de cube.
■ Ouvrez l’outil BIDS et créez un nouveau projet.
■ Sélectionnez un projet de type Projet Analysis Services :

■ Créez une nouvelle source de données :
Nous allons suivre l’assistant de création d’une nouvelle source de données :
■ L’assistant s’ouvre sur un écran d’accueil, cliquez sur le bouton Suivant.
■ Aucune référence à une source de données n’étant encore définie, cliquez sur le bouton Nouveau pour en créer une
nouvelle.

■ Saisissez le nom de votre instance SQL Server, ainsi que le nom de l’entrepôt de données, puis cliquez sur Tester la
connexion pour vérifier que les paramètres sont corrects.

■ Cliquez sur Suivant pour continuer la configuration de la source de données.

■ Sélectionnez Utiliser le compte de service pour vous connecter à la base de données.
■ Cliquez sur Terminer.

Maintenant que la source de données est créée, nous allons créer une dimension Temps dans le projet Analysis
Services.
■ Créez une nouvelle dimension. Pour cela, dans l’Explorateur de solutions, faites un clic droit sur Dimension puis,
dans le menu contextuel, cliquez sur Nouvelle dimension.
■ Un nouvel assistant s’ouvre. Dans la fenêtre Sélectionner la méthode de création, sélectionnez l’option Générer
une table de temps dans la source de données.

■ Sélectionnez la période qui vous intéresse : dans notre cas, nous souhaitons une plage allant du 1 e r janvier 2006 au

31 décembre 2013.
■ Sélectionnez le ou les types de calendrier qui sont supportés par votre axe temps.

Dans notre cas, nous n’aurons besoin que du calendrier régulier. Dans la réalité, il est très probable que des
services tels que le service financier, les ventes ou les services production et logistique aient chacun leur
propre calendrier qui diffère du calendrier standard. Le calendrier standard commence le 1e r janvier et finit le 31
décembre. Le calendrier fiscal d’une entreprise peut par exemple commencer le 1e r septembre et terminer le 31 août
de l’année suivante.
■ Cochez l’option Créer le schéma maintenant afin que l’assistant crée non seulement la structure, mais génère
également les données et changez le nom de la nouvelle dimension en DimTemps. Enfin cliquez sur le bouton
Terminer.

■ À l’affichage de l’assistant de génération de schéma, cliquez sur Suivant.
■ Sélectionnez l’option Créer une nouvelle vue de source de données nommée arbitrairement SSAStemps.
Nous reviendrons plus en détail sur ces aspects du projet Analysis Services. Notre projet n’a pas d’autre vocation
que de générer la dimension temps.

■ Sélectionnez l’option Remplir afin de générer les données de la table DimTemps :
■ L’assistant affiche un écran de paramétrage des conventions de nommage. À l’option Séparateur, spécifiez la valeur
Aucun :

■ Achevez l’assistant en cliquant sur le bouton Terminer.
■ À la fin du processus de génération du schéma, cliquez sur Fermer.

L’assistant est terminé, la dimension est créée. Vous pouvez quitter le projet.
Dans l’outil SQL Server Management Studio, vous pouvez constater que la table DimTemps vient d’être ajoutée :
La structure de la table DimTemps générée est la suivante :

Et vous pouvez vérifier que les lignes de la table DimTemps ont bien été saisies :
Nous disposons maintenant d’une table de dimension temps, beaucoup plus conforme à nos attentes. Néanmoins,
nous allons continuer d’apporter manuellement quelques améliorations qui nous seront profitables par la suite.
Par expérience, je vous recommanderais d’utiliser une clé Temps_PK de type int au format aaaammjj. Cette

clé vous évitera de nombreux écueils lors du chargement de vos données. Les champs de type Date étant
souvent sources de problème d’alimentation. D’autre part, ce type de clé vous permettra d’obtenir de meilleures
performances.
Cette codification au format aaaammjj devra être généralisée à tous les niveaux de notre axe temps : année,
semestre, trimestre, mois, semaine…
Je vous suggère donc que chaque niveau (année, semestre, trimestre, mois, semaine, jour) soit composé de trois
attributs distincts :
● Code
● Date
● Nom
Par exemple, le mois devra être composé des attributs suivants :

Attribut Type Valeur exemple Commentaire
MoisCode Int 20091101 Format aaaammjj, par défaut doit toujours

se référer à la 1 ère date de la période
MoisDate SmallDateTime 20091101 00:00:00 Format date
MoisNom Varchar(50) Novembre 2009 Valeur au format affichée
Les valeurs des attributs Code devront être déduites à partir des valeurs attributs Date, à l’aide d’un script SQL de mise
à jour (requête UPDATE).
Afin de finaliser l’axe temps, nous vous conseillons d’exécuter le script FinalisationDimTemps.sql, téléchargeable sur le
site du livre.
Ce script réalise les opérations suivantes :
● Il renomme un certain nombre de colonnes.
● Il modifie des types de données DateTime en SmallDateTime.
● Il modifie des types de données nvarchar en varchar.
● Il crée la clé Temps_PK ainsi que les colonnes AnneeCode, SemestreCode, TrimestreCode, MoisCode et
SemaineCode.
● Il remplit les valeurs pour les champs créés précédemment.
● Il modifie les colonnes pour interdire la valeur null.
● Il repositionne la clé primaire sur Temps_PK.
Au final, après exécution du script, la table DimTemps devra avoir ce formalisme :
Le champ Temps_PK devra bien entendu être une clé primaire. En revanche, exceptionnellement, n’activez pas
l’incrémentation automatique pour cette table.
■ Vérifiez que la table DimTemps est bien remplie :

Conservez précieusement la table DimTemps ainsi que ses données. En effet, la table DimTemps, que vous
venez de créer, est parfaitement standard et réutilisable, quels que soient vos futurs projets d’entrepôt de
données.

Création des étoiles
Dans les chapitres précédents, nous avons créé une table de faits et les tables de dimensions associées. Au cours de
ce chapitre, nous allons achever la modélisation de notre entrepôt de données en assemblant ces tables en étoile.
Pourquoi en étoile ? Tout simplement parce que la table de faits est au centre d’un réseau de tables de dimension, le
tout faisant penser à une étoile.
Représentation schématique d’une étoile
Vous entendrez aussi parler de schéma en flocon. Tout simplement parce que les tables de dimension, peuvent être
liées à d’autres dimensions. Le schéma global faisant penser alors à un flocon de neige.
Représentation schématique d’un flocon
La manière de nommer ces schémas étoile ou flocon n’a que peu d’importance. Il est surtout important de noter que
les liaisons du centre vers l’extérieur se matérialisent uniquement par des relations de clé étrangère à clé primaire. De
ce fait, dans une modélisation correcte :

● Une table de faits ne devra jamais contenir de clé primaire.
● Une table de dimension contient toujours une clé primaire unique et parfois des clés étrangères (pour obtenir
un flocon).
Dans notre cas, voyons à quoi devrait ressembler notre étoile :
Schéma en étoile FactFacture
La table de dimension DimGeographie est partagée par deux autres tables de dimension DimSite et DimClient. Mais cela
ne gêne en rien la conformité de notre modèle. Notre schéma reste conforme, car le sens des flèches va bien du centre
vers l’extérieur.
Utilisons maintenant SQL Server Management Studio pour intégrer cette étoile à notre entrepôt de données.
■ Faites un clic droit sur Schéma de base de données, puis cliquez sur Nouveau schéma de base de données :
■ Cliquez sur Oui :
■ Ajoutez toutes les tables au schéma de base de données, puis fermez.

■ Arrangez les tables afin de toutes les faire apparaître à l’écran :
■ Par contrôle visuel, assurezvous que tous les champs en _PK soient bien des clés primaires. Les clés primaires étant
identifiées par le symbole .
■ Enregistrez le schéma et nommezle Facture Etoile, du nom de la table de faits concernée :
Vérifiez que le schéma est créé :

Maintenant revenons à notre schéma, afin de créer les relations entre les tables.
■ Sélectionnez le symbole du champ Produit_PK de la table DimProduit, puis maintenez la sélection enfoncée. Un
lien en pointillés apparaît et votre curseur change d’apparence. Nous allons faire un glisséposé sur le champ
Produit_FK de la table FactFacture.
Une fois audessus du champ Produit_FK, relâchez la souris : deux nouvelles fenêtres apparaissent, vous proposant de
confirmer la relation entre Produit_PK de DimProduit avec Produit_FK de FactFacture.
■ Pour la première fenêtre, cliquez sur OK :

■ À la seconde fenêtre, cliquez également sur OK :
La liaison a été créée :

En revanche, les modifications n’ont pas encore été appliquées, les petites étoiles sont là pour vous le
rappeler :
■ Enregistrez de nouveau votre schéma. Je vous conseille de l’enregistrer après chaque manipulation.
■ Maintenant que vous savez créer une relation entre deux tables, je vous suggère de créer les relations suivantes :
● Temps_PK (DimTemps) avec DateFacturation_FK (FactFacture)
● Site_PK (DimSite) avec Site_FK (FactFacture)
● Client_PK (DimClient) avec Client_FK (FactFacture)
● Geographie_PK (DimGeographie) avec GeographieSite_FK (DimSite)
● Geographie_PK (DimGeographie) avec GeographieClient_FK (DimClient)
Vous devriez maintenant avoir le diagramme suivant :

■ Vérifions par un contrôle visuel la conformité de notre étoile : les clés étrangères sont au centre de l’étoile et toutes
les dimensions ont une clé primaire.
Nous venons ainsi de construire notre premier schéma en étoile Facture Etoile.

Génération du jeu de test
Dans le chapitre précédent, nous avons achevé la modélisation de notre entrepôt de données. Néanmoins pour tester
et appréhender le modèle, il nous faut des données concrètes.
Lors de la phase de conception, même si je vous engage à vérifier la disponibilité des informations sources, je vous
incite vivement à ne pas chercher à travailler avec les données réelles mais avec un jeu de test. Et ce, jusqu’à une
validation de la modélisation.
Nous allons voir dans ce chapitre comment générer et travailler avec un jeu de test. Cette phase peut sembler lointaine
des préoccupations du concepteur, elle reste cependant capitale pour la validation et la réussite de cette phase de
modélisation. En effet, lors des phases de conception, il est important de faire des itérations très rapides avec les
utilisateurs métier, et surtout d’être capable de leur faire voir et leur faire manipuler le fruit des décisions des dernières
délibérations.
À l’issue de ce chapitre, c’estàdire après la création du cube, dans notre étude de cas Distrisys, nous devrions réaliser
une démonstration et un atelier. Cela permettra aux utilisateurs, qui ont participé à sa conception, de manipuler le
modèle, ce afin de le leur faire valider. L’objectif étant qu’une fois le modèle validé à l’aide de données de test nous le
mettrons de côté. Nous pourrons alors nous intéresser exclusivement au chargement des données réelles : une phase
qui peut se révéler très longue.
C’est justement parce que le chargement des données réelles est souvent long et fastidieux, qu’il faut :
● S’assurer que le modèle final est validé et stable.
● Générer et travailler avec des données de test, pour permettre aux utilisateurs clés de visualiser le
comportement de leur cube, et ce jusqu’à validation.
Revenons à notre étude de cas. Pour générer nos données de test, nous procéderons ainsi :
● Nous allons tout d’abord saisir des données manuellement dans toutes les dimensions.
● Nous utiliserons Excel pour générer le jeu de données des faits.
● Nous intègrerons les données Excel précédemment créées dans la table de faits SQL Server. Cette intégration
se fera à l’aide de l’outil en ligne de commande BCP.
Ce processus, une fois acquis, est assez simple et rapidement reproductible à chaque modification du modèle.
Pour rappel, précédemment, nous avons saisi le contenu des tables suivantes :
● DimProduit : 10 lignes.
● DimSite : 5 lignes.
● DimClient : 10 lignes.
Maintenant, nous allons nous atteler à générer les données de la table de faits FactFacture.
Pour cela, nous allons :
● Saisir une ligne de la table FactFacture.
● Exporter sous Excel le contenu et la structure de la table par l’outil BCP.
● Générer les données avec Excel.
● Importer le contenu du fichier Excel dans la table FactFacture avec l’outil BCP.
■ Commençons donc par saisir au moins une ligne dans la table de faits FactFacture :

■ Ouvrez l’Invite de commande :
■ Positionnezvous à la racine de votre disque C. Pour cela, tapez dans l’invite de commande l’instruction suivante :
cd\
■ Tapez la ligne de commande suivante, puis appuyez sur la touche [Entrée] :
bcp DistrisysDW.dbo.FactFacture out "FactFacture.csv" -T -c -t";"

-S"Serveur\Instance"

L’option S encadre le nom de votre serveur et instance SQL Server.

L’exportation s’est déroulée avec succès.
■ Explorez le disque C :
Le fichier FactFacture.csv a été généré.
■ Ouvrez ce fichier avec Excel :

Vous pouvez constater que l’on retrouve la ligne préalablement insérée manuellement dans la table FactFacture.
Nous allons maintenant utiliser les fonctions tirer et aléatoire de Excel afin de créer un jeu de test, que nous
réintégrerons dans la table FactFacture.
● Après modification manuelle de la colonne A de mon fichier Excel j’obtiens ceci :
● La colonne A représentant la table de dimension Temps, nous saisissons les mois que nous souhaitons voir
apparaitre dans notre cube.
Dans cet exemple, je saisis 24 mois, du 1er janvier 2009 à décembre 2010. Les mois étant tous représentés par le 1er jour

du mois. Dans mon exemple, je considère que détailler les ventes par jour n’a que peu d’intérêt. Ça ne sera pas toujours le
cas. Dans certains cas, par exemple, afin de démontrer que vous savez calculer une moyenne des 30 derniers jours, il vous
faudra forcément générer des données détaillées au jour.
● La colonne B représente le site de la ligne de fait. La dimension Site dispose de 5 membres avec un identifiant
allant de 1 à 5. Nous utilisons alors une fonction d’Excel générant une valeur aléatoire entre 1 et 5 :
=ALEA.ENTRE.BORNES(1;5)
● La colonne C représente le produit de la ligne de fait. La dimension Produit dispose de 10 membres avec un
identifiant allant de 1 à 10. Nous utilisons alors la même astuce que précédemment mais avec une valeur
aléatoire entre 1 et 10 :
● La colonne D représente le client de la ligne de fait. La dimension Client dispose de 10 membres avec un
identifiant de 1 à 10.
■ Nous générerons donc un nombre aléatoire entre 1 et 10 :

● Les colonnes E à L représentent les mesures. Nous pouvons utiliser la même fonction aléatoire et bien
évidemment, toutes les fonctions dont dispose Excel, afin de générer des valeurs les plus cohérentes possibles
pour le cas à traiter.
■ Nous commençons donc par générer la quantité de produits vendus : un nombre aléatoire entre 1 et 100 (valeurs
totalement arbitraires) :
■ Puis nous définissons la valeur prix de vente de la ligne de fait : on considère ici que nos produits sont vendus en prix
catalogue entre 1 et 150 euros. Nous multiplions cette valeur par la quantité de produit vendus.
■ Ensuite, nous définissons la remise de la ligne de fait : on considère ici que la remise se situe entre 2 % et 30 %.
Pour éviter toute erreur lors de l’utilisation avec le BCP, on arrondit la valeur afin qu’il n’y ait pas de valeurs après la
virgule.

■ La colonne G est le CA, il est donc égal au prix de vente auquel on retranche la remise :
Et nous procédons ainsi de suite pour l’ensemble des autres mesures. Ce travail est plus ou moins détaillé. L’objectif
étant surtout que les chiffres affichés n’entravent pas la compréhension de votre modèle
Par exemple, une marge supérieure au CA, serait incomprise par les utilisateurs qui rejetteraient alors aussitôt le modèle que
vous leur proposerez.
■ Une fois les règles de calcul aléatoires fixées pour chaque colonne, il vous suffit alors de tirer ces formules sur
l’ensemble des mois :

■ Afin de rendre le plus réaliste possible notre document, vous devez obtenir un nombre de lignes suffisamment
important. Démultipliez alors ces 24 lignes par copiercoller jusqu’à obtenir le nombre de lignes souhaitées.
■ Pour finir, enregistrez le document sous format Excel afin de conserver vos formules. Puis, enregistrez ce fichier
également au format CSV (séparateur pointvirgule) à son emplacement originel (remplacez le fichier précédent).
Enfin, fermez Excel.
Le fichier Excel de démonstration et le fichier CSV en résultant sont téléchargeables sur le site des Éditions ENI.
■ À l’Invite de commande, tapez la commande qui permet d’intégrer les données du fichier CSV dans la table
FactFacture :
bcp DistrisysDW.dbo.FactFacture in "FactFacture.csv" -T -c -t";"

-S"Serveur\Instance"
La commande s’est exécutée avec succès. Nous venons de réintégrer 1908 lignes à notre table de faits FactFacture :

La réexécution de la commande BCP n’écrase pas le contenu de la table, mais ajoute d’autres lignes aux lignes déjà
existantes. Cela vous permet ainsi de créer des jeux de tests de plusieurs millions de lignes, si nécessaire.
Suite à ce chapitre vous devrez donc être en mesure de créer vos propres jeux de test parfaitement personnalisés à
votre problématique et vous permettant ainsi de vous assurer la validité de votre modélisation.
Dans le prochain chapitre nous allons apprendre à construire un cube. Le cube va nous permettre d’explorer facilement
les données que nous venons de charger.

Créer et utiliser simplement un cube brut
Dans les chapitres précédents, nous avons construit l’entrepôt de données sous SQL Server, puis nous avons chargé
un jeu de test cohérent.
À présent, nous allons nous atteler à rendre l’information contenue dans l’entrepôt de données de manière simple,
présentable et rapide.
Simple et présentable : cela signifie que l’utilisateur qui accède à l’information ne doit pas voir la complexité du
traitement de l’information. Le fait que l’information provienne de multiples sources doit être totalement transparent.
Le fait que la restitution de l’information suggère de nombreuses règles de gestion métier doit lui aussi être
transparent. Un modèle réussi est un modèle que l’on peut donner à l’utilisateur sans avoir crainte qu’il ne se trompe,
qu’il interprète mal les résultats ou qu’il se perde dans l’étendue de l’information.
Rapide signifie qu’un utilisateur, qui accède à des informations mises à disposition, doit avoir un temps d’attente de
l’ordre de la seconde. Attendre 10 secondes peut déjà être considéré comme long.
La base de données Analysis Services et sa technologie multidimensionnelle peut nous aider à répondre à ces
trois critères. Néanmoins la solution n’est pas magique. Ce n’est pas le fait d’employer la technologie qui va
faire que l’information va être simple, rapide et présentable. L’outil va simplement nous donner les moyens de nos
ambitions.
La modélisation que nous venons de mettre en œ uvre dans les chapitres précédents en est l’illustration. La bonne
modélisation est la clé de l’utilisation optimale d’Analysis Services.
Nous allons voir dans ce chapitre, qu’un entrepôt de données bien modélisé, c’est 80 % du travail accompli. Les 20 %
restants relèvent de la finition.
SQL Services Analysis Services (SSAS) est le service de bases de données multidimensionnelles. Attention,
Analysis Services n’est pas un outil de restitution de données mais une base de données orientée vers
l’utilisateur.
Dans les chapitres qui vont suivre, quand nous évoquerons SSAS, la base OLAP, la base multidimensionnelle, le cube
ou le modèle, nous sousentendrons toujours la base de données Analysis Services.
La construction du cube Analysis Services se réalise avec l’outil SQL Server Business Intelligence Developpement Studio
(ou BIDS) alors que la gestion et l’administration des modèles se réalisent avec l’outil SQL Server Management Studio
(ou SSMS)
Pour commencer, nous allons créer un nouveau projet Analysis Services sous SQL Server Business Intelligence
Developpement Studio.
■ Ouvrez BIDS.
■ Créez un nouveau projet Analysis Services :

Un projet Analysis Services se présente ainsi :
Lorsque l’entrepôt de données est créé et bien modélisé, créer un cube d’entreprise est assez simple. Cela se fait en
trois étapes :
1. Création de la source de données
2. Création de la vue de source de données (DSV)
3. Création du cube
Dans des conceptions avec BIDS nous réaliserons surtout des cubes d’entreprise et dans ce cas précis nous
retrouverons surtout un seul et grand cube. Les cubes d’entreprise sont des modèles reposant sur un
entrepôt de données modélisé avec une approche définie par Ralph Kimball. Les cubes financiers ou de pilotage sont
des cas particuliers nécéssitant une approche et des outils de conception différents et complémentaires à l’approche
évoquée par ce livre.
Dans un environnement sain, les choses sont simples :
● Il n’y a qu’une seule source de données, il s’agit de l’entrepôt de données.
● Il n’y a qu’une seule vue de source de données et celleci est, autant que possible, le reflet de l’entrepôt de
données.
Nous rappelons que le modèle de l’entrepôt de données doit être pensé, réfléchi et doit avoir une modélisation
conforme. Toutes les transformations et manipulations de données devront être réalisées en amont lors de la phase
d’ETL. La vue de sources de données ne doit pas être basée sur des vues ou basée sur des requêtes SQL, même si
l’outil en donne la possibilité. Toutes vues ou requêtes SQL, présentes dans un DSV, sont des symptômes d’une
modélisation non conforme. Le DSV a une utilité dans des cas très précis qui relèvent de l’exception. Un de ces usages
très particulier est illustré dans le chapitre La modélisation dimensionnelle Facturation et commande client.

■ Créez la source de données :
■ Sélectionnez l’entrepôt de données DistrisysDW, créé précédemment, puis cliquez sur Suivant :
■ À la fenêtre de l’Assistant Sources de données, sélectionnez Utiliser le compte de service :
La source de données est créée :

Maintenant créons la vue de sources de données :
■ Sélectionnez la source de données précédemment créée :
■ Sélectionnez toutes les tables préfixées Dim et Fact :

■ En fin d’assistant, cliquez sur Terminer.
La vue de sources de données est créée :
Les tables et leurs relations sont conservées :

Le diagramme présenté est assez simple car nous n’avons qu’une seule table de faits et donc qu’une étoile. Pour
prendre de bonnes habitudes, nous allons alors créer un nouveau diagramme Facture Etoile.
■ Effectuez un clic droit sur le diagramme par défaut pour créer un Nouveau diagramme :

■ Renommez le nouveau diagramme Facture Etoile.
■ Glissez la table de fait FactFacture dans l’espace de travail au centre, puis avec un clic droit sur la table, sélectionnez
Afficher les tables associées :
■ Pour compléter l’étoile, glissez DimGeographie dans l’espace de travail et recréez l’étoile en vous assurant bien des
liaisons entre les tables :

Pour rappel, les diagrammes n’ont pas d’autre utilité, que de vous permettre de bien vous assurer de la
conformité de la modélisation.
■ Enregistrez le projet.
■ Créez le cube :
■ Un assistant de création de cube s’ouvre. Dans la fenêtre Sélectionner la méthode de création, sélectionnez
l’option Utiliser des tables existantes, puis cliquez sur le bouton Suivant.

■ Cliquez sur Suggérer.
L’assistant doit pouvoir trouver tout seul les tables de faits. Dans le cas contraire, je ne saurais que vous conseiller de
reprendre votre étoile et de vous assurer la cohérence du modèle :
Dans l’écran suivant, l’assistant sélectionne, de luimême, uniquement les mesures :

■ Renommez le groupe de mesure Fact Facture en Facture et désélectionnez le compteur Fact Facture Nombre. En effet,
compter le nombre de lignes de la facture n’est pas une mesure pertinente dans notre cas.
Les dimensions sont automatiquement détectées :

Veuillez noter que la table de dimension Geographie n’est pas une dimension en tant que telle. Les
informations de la tables seront disponibles au travers de la dimension Client et Site.
■ Renommez les dimensions pour les rendre plus compréhensibles à un noninformaticien :

■ Renommez le cube si nécessaire :
■ En cliquant sur Terminer, l’assistant va donc créer un cube Distrisys, comportant :
● Un groupe de mesures : Facture disposant des mesures CA, Prix Catalogue, remise, marge...
● Quatre dimensions : Temps, Site, Client et Produit
L’assistant est terminé, le cube est créé :

Dans cette interface concepteur, le contenu central, émanant de la vue de source de données, n’a que très peu
d’intérêt.
Dans cette première interface, nous avons accès aux mesures regroupées par groupe de mesures (table de faits) :
Ainsi qu’à la gestion des dimensions :
Avant de déployer le cube, nous allons nous assurer de le déployer sur le bon serveur Analysis Services.
■ Dans la fenêtre Explorateur de solutions, faites un clic droit sur DistrisysOLAP puis cliquez sur Propriétés.
■ Dans l’onglet Déploiement, au niveau du champ Serveur, entrez le nom et l’instance du serveur Analysis Services.
Puis validez en cliquant sur OK.

■ Visualisons sans plus tarder notre cube. Pour cela traitez le cube en cliquant sur l’icône .
■ Au premier déploiement du cube ou à chaque modification de structure, le message cidessous apparaîtra, choisissez
Oui :
Concrètement, le déploiement crée la structure de données.
■ Après le déploiement du cube, la fenêtre de traitement apparaît, cliquez sur Exécuter :

Concrètement, traiter le cube revient à alimenter et à calculer les agrégats dans la structure déployée à
l’étape précédente. Plus vous aurez de données, plus le temps de traitement va s’allonger. Ce n’est pas une
tâche anodine, son optimisation relève du travail de l’administrateur Analysis Services. Étant donné que dans notre
cas, nous travaillons sur des données de test, le problème ne se pose pas et le traitement devrait se réaliser dans
des délais assez courts.

Le traitement s’est terminé avec succès nous allons donc pouvoir manipuler le contenu du cube.
■ Fermez toutes les fenêtres de traitement du cube.
■ Cliquez sur l’onglet Navigateur du projet Analysis Services :
Le projet Analysis Services embarque un explorateur de cube afin de visualiser les modifications que vous effectuez.
L’explorateur de cube le plus couramment employé est le tableau croisé dynamique. C’est l’interface qui vous est
proposée ici.
■ Glissez une mesure du cube dans l’espace central :

Les mesures se glissent uniquement dans l’espace central d’un tableau croisé dynamique. En effet, les mesures
correspondent aux chiffres analysés. Elles se retrouveront donc toujours au centre du tableau croisé dynamique,
contrairement aux attributs de dimension qui se retrouvent toujours soit en ligne, soit en colonne ou soit en filtre.
■ Puis glissez une dimension ou un de ses attributs en ligne, en colonne ou en filtre du tableau croisé dynamique :
Votre cube est bien créé et vous avez la possibilité de l’explorer. Néanmoins, les dimensions ne sont accessibles que
par leurs clés primaires.
Le même navigateur est disponible avec l’outil SQL Server Management Studio :
■ Ouvrez SSMS et connectezvous à un serveur Analysis Services :
■ Ouvrez la base de données, puis le cube. À l’aide d’un clic droit sur Parcourir, vous avez accès à l’explorateur de

cube :
Vous pouvez là encore accéder aux informations contenues dans votre cube :
Maintenant que vous savez créer un cube, au cours de la prochaine étape, nous allons apprendre à le peaufiner. Nous
allons notamment travailler la présentation des dimensions et apprendre à créer des mesures complémentaires à
celles présentes dans les tables de faits.

Peaufiner le cube
1. Dimensions : hiérarchies et attributs
Nous avons créé dans la section précédente un cube basé sur l’entrepôt de données DistrisysDW. La création et la

génération du cube a été rapide. Mais il est apparu clairement que quelques finitions étaient nécessaires pour le
rendre accessible aux utilisateurs. Une des finitions les plus évidentes est la nécessité de retravailler les dimensions.
Dans notre travail de finition, pour chaque dimension, nous allons devoir identifier les atttributs à afficher et quand
c’est possible chercher à les organiser en hiérarchie.
Voyons un peu comment procéder. Dans le premier onglet cube du projet Analysis Services, identifiez la zone de
gestion des dimensions, en bas à gauche. Dépliez la dimension Temps et cliquez sur Modifier Temps :
Un nouvel onglet spécifique à la gestion de la dimension Temps s’ouvre. Vous pouvez revenir si nécessaire à la
gestion générale du cube en cliquant sur l’onglet Distrisys.cube [design] :
La zone Attributs la plus à gauche, vous permet de visualiser la liste des attributs de la dimension Temps.

Vous noterez que le seul attribut disponible est, par défaut, la clé technique.

La zone Hiérarchie centrale vous permettra de construire les hiérarchies.
La zone Vue de sources de données, la plus à droite, vous permet de visualiser les tables concernées par la
dimension.
Pour commencer, nous allons modifier l’attribut de clé Temps PK, afin que ce soit un attribut qui affiche le jour de
l’année à l’utilisateur, plutôt qu’une clé technique.
■ Affichez les Propriétés de Temps PK :
La barre de propriétés de l’attribut Temps PK s’affiche :

■ Sélectionnez la propriété NameColumn et cliquez sur
■ Sélectionnez le champ Jour de la table DimTemps :
Vous devriez avoir :

■ Renommez l’attribut Temps_PK en Jour :
Nous venons de créer l’attribut Jour. Cet attribut est l’attribut de clé car il s’agit de l’attribut le plus fin de la
dimension. Cet attribut a pour clé Temps_PK, mais l’affichage présentera à l’utilisateur la valeur correspondant au
champ Jour.

■ Observons le résultat. Traitez la dimension en cliquant sur l’icône .
■ Puis cliquez sur l’onglet Navigateur :
Vous pouvez constater que le nom des membres affichés de l’attribut Jour est une date comprise par l’utilisateur. De
plus, vous pouvez noter que ces membres sont triés dans le bon ordre, celui de la clé Temps_PK.
Nous procéderons ainsi pour créer les attributs d’une dimension. Quand cela est possible, le champ technique servira
de clé du membre et le champ, compréhensible par l’utilisateur, servira de nom du membre.
Créons ainsi un nouvel attribut Année :
■ Glissez à partir de la vue de sources de données le champ AnneeCode dans la zone Attribut :
■ Renommez AnneeCode en Année.
■ Dans les propriétés de l’attribut Année, sélectionnez comme nom de membre le champ AnneeNom :

■ Dans les propriétés de l’attribut Année, spécifiez bien le tri par la clé à l’aide de la propriété OrderBy :
■ Après traitement de la dimension, allez sur l’onglet Navigateur, cliquez sur Reconnectezvous :
■ En sélectionnant l’attribut Année, vous devriez obtenir ceci :
■ Faites de même pour les attributs suivants :
● Mois
● Trimestre

● Semestre
● Semaine
La procédure à suivre est la suivante :
■ Vous glissez d’abord le champ _code dans la zone attribut et vous modifiez le nom de l’attribut.
■ Puis vous changez la propriété de nom de membre de l’attribut en sélectionnant le champ présentable _nom.
■ Enfin, vous vous assurez que le tri des membres s’effectue bien par la clé.
Vous devriez avoir les attributs suivants :
Après traitement de la dimension, vous devriez avoir le résultat suivant pour la liste des membres Semaine :
■ Vérifiez bien que les membres de chacun de vos attributs s’affichent correctement.
Vous venez de créer les attributs de la dimension Temps.
Nous allons maintenant créer les hiérarchies de la dimension Temps.
Il y a plusieurs façons d’accéder aux attributs de la dimension Temps, par exemple :
● Année Semestre Trimestre Mois Jour
● Année Mois Jour
● Année Semaine Jour
● Année Trimestre Mois Jour

● Année Semestre Mois Jour
● Année Mois
● Année Semaine
● Etc.
La manière dont vous allez proposer l’accès aux attributs, est une hiérarchie. L’idée n’est pas de créer toutes les
hiérarchies possibles, mais seulement les hiérarchies pertinentes dans votre organisation.
Pour créer la hiérarchie Année Mois Jour, procédez de la manière suivante :
■ Glissez l’attribut Année dans la zone Hiérarchies :
■ Glissez ensuite les attributs Mois et Jour sous l’attribut Année :
■ Renommez la hiérarchie en Année Mois Jour :
■ Faites de même en créant les hiérarchies suivantes :
● Année Semestre Trimestre Mois Jour
● Année Semaine Jour
Vous devriez obtenir :

Vous allez constater qu’un avertissement entache la création de vos hiérarchies. En fait, SQL Server 2008 inclut des
outils d’audit permettant d’alerter le concepteur sur des défauts d’optimisation ou de conception.
■ Pour corriger le problème, cliquez sur l’onglet Relations d’attributs :
Cette interface va nous permettre de contrôler la manière dont va être réalisée l’agrégation de la dimension
Temps, et ainsi optimiser la performance du cube durant le traitement et à l’affichage.

■ Créez une Nouvelle relation d’attribut en faisant un clic droit sur l’attribut Semaine :
■ Spécifiez les paramètres de la relation d’attribut entre Semaine et Annee, comme cidessous :
■ Visualisez la relation d’attribut nouvellement créée.

Nous devons créer cette relation, car l’attribut Semaine s’agrège uniquement par l’attribut Année.
■ Faites de même pour obtenir les relations suivantes :
L’agrégation de l’attribut Jour peut se faire soit par Semaine, soit par Mois. L’attribut Mois peut s’agréger par
Trimestre, qui luimême peut s’agréger par Semestre, qui luimême peut aussi s’agréger par Année.
Après traitement, vous devriez obtenir dans le Navigateur :

Généralement, une fois un attribut disponible dans une hiérarchie, on masque cet attribut à l’utilisateur, pour rendre
la dimension plus simple et donc plus présentable.
■ Pour masquer les attributs, sélectionnezles et affichez les Propriétés :
■ Modifiez la propriété AttributeHierarchyVisible à False pour rendre ces attributs invisibles à l’utilisateur :
Vous venez de terminer le travail de finition sur la dimension Temps.

■ Traitez de nouveau le cube complet, puis accédez à l’onglet Navigateur du cube.
■ Au besoin, cliquez sur le bouton Reconnexion pour reconnecter le tableau croisé dynamique au cube
nouvellement traité.
■ Réalisez le tableau dynamique cidessous :
Les hiérarchies de la dimension Temps sont maintenant accessibles. Au niveau du tableau croisé dynamique, vous
accédez aux données de vos mesures, en naviguant suivant les hiérarchies que vous venez de prédéfinir.
■ Vous pouvez maintenant modifier la dimension Produit pour obtenir au final l’interface suivante :
La clé Produit_PK a été renommée Produit. Le nom de membre à l’affichage correspond au champ Produit :
■ Définissez la propriété de tri (OrderBy) des attributs par Name (nom de membre), permettant ainsi d’avoir un
classement des membres par ordre alphabétique :

■ Définissez les relations d’attributs de la manière suivante :
Vous devriez alors pouvoir naviguer dans la Hiérarchie Famille SousFamille Produit :
■ Rendez invisibles les attributs Famille, SousFamille et Produit.
■ Faites de même avec la dimension Site.
Au final, l’interface devra ressembler à la copie d’écran cidessous :

Attribut Site :
■ Supprimez l’attribut Geographie_PK (visible par défaut dans la colonne des attributs). Puis, glissez ce même
attribut de la vue de source de données dans la colonne attribut. Enfin, renommez l’attribut Geographie_PK en
Attribut Ville.
Le nom de membre à l’affichage correspond au champ Ville.
■ Masquez tous les attributs et définissez les relations d’attribut comme cidessous :

La hiérarchie Pays Site devrait apparaître ainsi :
■ Pour finir, faites de même pour la dimension Client. L’interface finale devrait ressembler à la copie écran ci
dessous :
Les attributs Segmentation Client et Type Client ne disposant pas de _code, c’est le champ unique qui
définit alors la clé du membre. Lorsque le nom du membre n’est pas spécifié, le nom du membre correspond à
sa clé.
■ Définissez les relations d’attributs comme cidessous :

■ Lorsque les finitions sur les dimensions sont terminées, traitez le cube et regardez le résultat dans le navigateur :
Vous disposez maintenant d’un modèle propre et parfaitement manipulable par les utilisateurs. Vous pouvez explorer
vos données suivant tous les axes et vous disposez de la capacité de croiser ces axes entre eux.
2. Mise en forme des mesures
Dans la section précédente nous avons réalisé des finitions au niveau des dimensions. Nous allons nous consacrer
dans cette section à apporter quelques finitions au niveau des mesures.
Découvrons plus en détail la zone de gestion des mesures.

■ Sélectionnez la mesure CA et affichez ses propriétés. Pour chacune des mesures nous disposons de la possibilité
de contrôler son format d’affichage par le biais de la propriété FormatString.
Dans la majorité des cas, nous aurons à utiliser les formats standards suivants :
● Currency : pour afficher les mesures de type monétaire (ex : CA, Remise, Marge…)
● Percent : pour afficher les mesures exprimant un pourcentage (ex : % Marge, % Remise…)
● Standard : pour afficher les mesures quantitatives (ex : quantité).
Ces formats standards s’affichent de différentes manières suivant le contexte de langue. Ainsi si vous aviez
une version américaine de SQL Server installée, les valeurs monétaires s’afficheraient alors en $, alors
qu’une version française afficherait les valeurs en €. Si vous avez une version US de SQL Server installée, mais que
vous souhaitez bénéficiez d’un contexte de langue français, l’astuce consiste à utiliser la commande suivante
placée sous l’onglet calcul de votre projet SSAS : Language(This) = 1036;.

Si ces mises en forme par défaut ne vous conviennent toujours pas, il vous est toujours possible de recourir à des
mises en forme personnalisées. Vous trouverez cidessous des exemples récurrents :
Format personnalisé Exemple de valeur Remarque
Quantité ### ### ##0;### 1 234 567

### ##0
Quantité (avec chiffre ### ### ##0.00;### 1 234 567,00 Identique à Standard

après la virgule) ### ##0.00 dans un contexte français
Monétaire ### ### ##0.00 €; 1 234 567,00 € Identique à Currency

### ### ##0.00 € dans un contexte français
Durée en jours ### ### ##0 " j";### 1 234 567 j

### ##0 "j"
Je vous engage donc, dès à présent, à effectuer les modifications de la propriété FormatString pour chacune des
mesures du cube.
3. Organisation des mesures
Dans le cube actuel, nous disposons d’un nombre limité de mesures. Mais lorsque vous mettrez en œ uvre votre
solution, vous éprouverez surement le besoin d’organiser la présentation de vos mesures. En effet, pour un
utilisateur final, la qualité de la présentation de l’information est tout aussi importante que la qualité de l’information.
La propriété DisplayFolder nous offre la possibilité de ranger les mesures dans des sousrépertoires.
Je vous propose donc de ranger les mesures Cout Direct Matière, Cout Direct Main d’œuvre et Cout Indirect dans
un sousrépertoire Cout.
■ Pour cela, définissez Cout comme valeur de la propriété DisplayFolder de chacune de ces mesures.

■ Après traitement du cube, vous devriez obtenir la présentation suivante :
Ce que nous venons d’apprendre, à propos de la mise en forme et l’organisation des mesures, s’applique aussi aux
mesures calculées.
4. Mesures calculées
Au niveau de notre entrepôt de données et de notre table de faits, nous avons défini des mesures. J’aime alors les
identifier comme étant les mesures agrégées.
En effet, ces mesures et leurs valeurs sont définies au niveau de la base de données et agrégées lors du traitement
du cube. Néanmoins certaines mesures relatives, comme un calcul de poids (pourcentage) ou de rang, ne peuvent
être stockées en base de données au sein de la table de faits. Ces mesures devront être déduites (ou calculées) en
fonction du contexte de présentation. On parle alors de mesures calculées.
Les mesures calculées vont nous permettre d’effectuer toutes sortes de calculs arithmétiques entre mesures
(addition, soustraction, division, multiplication…) ou d’utiliser des fonctions proposées en standard par Analysis
Services. On parle alors de fonction MDX. Nous reviendrons plus en détails sur ces mesures calculées et plus évoluées
au chapitre La modélisation dimensionnelle Facturation et commande client. Nous ferons alors une introduction
pratique au langage MDX.
Pour l’heure, nous avons besoin dans le cadre de Distrisys, de créer les mesures calculées suivantes :
Mesures calculées Règles de calcul
% Marge Marge / CA
% Remise Remise / Prix Catalogue
Cout total Cout Direct Matière + Cout Direct Main d’œ uvre + Cout Indirect
Prix de vente moyen CA / Quantité

■ Afin d’afficher l’interface de gestion des mesures calculées, cliquez sur l’onglet Calculs de l’interface BIDS.

■ Pour créer une nouvelle mesure calculée, cliquez sur l’icône .
■ Modifiez le nom de la mesure calculée en [% Marge]. Conservez bien les crochets [ ].
■ Dans la zone Expression, vous allez définir la règle de calcul de cette mesure calculée. Le [% Marge] étant
CA/Marge, il vous faut faire appel à deux mesures existantes CA et Marge. Pour faire appel à une mesure existante
(agrégée ou calculée) l’astuce consiste à sélectionner la mesure CA dans la zone de navigation du cube en bas à
gauche, puis de la glisser dans la zone expression. Faites de même pour la mesure Marge.
■ Définissez la propriété Chaine de format (FormatString) à Percent pour un affichage en pourcentage et associez

cette nouvelle mesure calculée au groupe de mesures Facture, afin que le % Marge apparaisse dans ce groupe.
Vous devriez alors avoir l’interface suivante :
■ Afin de valider votre nouvelle mesure, vous avez juste besoin de déployer vos modifications en cliquant sur le

bouton . Vous n’avez pas besoin de traiter le cube pour autant.
■ Pour visualiser la nouvelle mesure dans la zone de navigation du cube en bas à gauche, il vous suffit alors de

cliquer sur le bouton . La mesure % Marge devrait alors s’afficher :

■ Pour achever la construction de notre cube, créez les trois autres mesures calculées comme indiquées cidessous :
Mesures calculées Expression
[% Marge] [Measures].[Marge]/[Measures].[CA]
[% Remise] [Measures].[Remise]/[Measures].[Prix Catalogue]
[Cout Total] [Measures].[Cout Direct Main Oeuvre] + [Measures].[Cout Direct Matiere] +
[Measures].[Cout Indirect]
[Prix de vente moyen] [Measures].[CA]/[Measures].[Quantite]
L’organisation des mesures calculées au sein des groupes de mesures se gère à partir d’une interface disponible en
cliquant sur le bouton .
■ Organisez les mesures comme indiquées sur l’écran cidessous :
Au final, vous devriez avoir :

Une fois dans le navigateur vous devriez être capable d’afficher le tableau croisé dynamique suivant :
Vous êtes ainsi capable d’afficher le taux de Marge, le taux de remise ou le prix moyen de vente suivant les axes
produit, client ou site géographique.
Les formats d’affichage sont clairs et l’accès au cube pour un débutant est facilité par la clarté de l’organisation des
attributs dans les dimensions et des mesures.

Le cube et la matrice dimensionnelle
Nous venons d’achever la construction de notre cube reposant sur un entrepôt de données.
Pour finir le chapitre et préparer le suivant, nous allons découvrir le concept de matrice dimensionnelle.
■ Dans le projet du cube, sélectionnez l’onglet Utilisation de la dimension :
La matrice qui est proposée est le véritable cœ ur du cube. Nous appellerons cette représentation : matrice
dimensionnelle.
La matrice dimensionnelle est la manière la plus efficace de modéliser et de représenter un entrepôt de données. Dans
la matrice, les lignes sont les dimensions et les colonnes les Tables de faits. L’intersection d’une dimension avec la table
de faits spécifie si les mesures de la table de faits sont analysables par cette dimension.
La matrice dimensionnelle de l’entrepôt de données définie dans ce chapitre peut être représentée de la façon
suivante :
Dans ce tableau, les croix (x) indiquent que les mesures de la table de Faits Facture sont analysables par les attributs
des dimensions Temps, Produit, Site et Client.
Une autre représentation possible de la matrice dimensionnelle, plus complète, est de représenter les intersections
(remplaçant ainsi les croix) par le grain définissant l’intersection. Dans notre cas, la représentation complète de la
matrice dimensionnelle est la suivante :

Cela signifie par exemple que :
● Le croisement entre la table de faits des factures et la dimension Temps se fait au jour.
● Le croisement entre la table de faits des factures et la dimension produit se fait au détail produit.
● Etc.
Le grain n’est pas toujours forcément au niveau le plus élémentaire :
Un budget peut être défini au mois et par famille de produit.
De même, une dimension ne croise pas toujours toutes les tables de faits. Par exemple, la table de faits des factures
fournisseurs s’analyse par la dimension Fournisseur, mais ne s’analyse pas par la dimension Client. Dans les faits, seule la
dimension Temps aura au moins une intersection avec toutes les tables de faits, parfois même plusieurs.
La matrice dimensionnelle a de très nombreux intérêts, l’un étant d’être le meilleur outil pour déterminer la
modélisation physique des tables de l’entrepôt de données.
Un autre intérêt, peutêtre moins conceptuel mais plus pragmatique, est que BIDS est un concepteur de cube,
intégrant parfaitement la théorie de la matrice dimensionnelle : plus vous vous y conformerez, plus l’utilisation
de l’interface et des assistants vous rendront la tâche facile.
Je ne saurais que trop insister sur la nécessité de disposer d’une modélisation dimensionnelle conforme. Ainsi, afin de
vous aider à bien modéliser, nous allons utiliser dans le prochain chapitre l’outil n°1 du concepteur décisionnel : la
matrice dimensionnelle.
Le cube et la base DistrisysDW finaux de cette fin de chapitre sont téléchargeables sous le chapitre Réaliser son premier

La matrice dimensionnelle de Distrisys
Au chapitre Réaliser son premier système décisionnel, vous avez découvert les rudiments pour commencer à créer
l’entrepôt de données de Distrisys. Ce dernier chapitre est un préalable nécessaire au chapitre que nous allons à
présent aborder, notamment si vous n’êtes pas un utilisateur aguerri d’Analysis Services ou un concepteur décisionnel
averti.
Lors de ce chapitre, nous verrons la mise en place de l’entrepôt de données Distrisys par rapport aux domaines
fonctionnels : vente, stock et achat.
Nous porterons notre attention en particulier sur ces trois domaines car il s’agit de domaines fonctionnels classiques et
assez standards pour la plupart des entreprises. Nous profiterons de ces domaines fonctionnels pour aborder des
concepts décisionnels et des fonctions avancées d’Analysis Services.
Même si le périmètre fonctionnel proposé dans cette étude de cas est assez éloigné d’un organisme public,
d’une banque ou d’une association, les concepts qui seront mis en œ uvre vous permettront tout de même de
relever le défi de création de votre propre entrepôt de données.
Pour commencer à modéliser un entrepôt de données, il faut d’abord s’attacher à établir la matrice dimensionnelle de
l’organisation.
La matrice dimensionnelle décrit les processus stratégiques ou du moins les plus importants de l’organisation. Ces
descriptions de processus apparaissent en colonnes dans la matrice dimensionnelle sous forme de groupes de mesures
(ou tables de faits).
Nous verrons au cours du chapitre qu’il existe trois types de tables de faits :
● Les tables de faits de type transaction : il s’agit de décrire en détail l’étape d’un processus (l’évènement).
● Les tables de faits de type bilan : il s’agit de faire le récapitulatif de certaines étapes du déroulement d’un
processus.
● Les tables de faits de type photo : il s’agit de faire l’état des lieux d’un processus en un instant T (l’inventaire).
Prenons l’exemple d’une situation de la vie quotidienne, comme l’acte d’achat d’un article sur Internet. Le client navigue sur
un site Internet, il détecte le produit qui lui plairait, il commande cet article. Trois jours plus tard, n’ayant toujours pas reçu le
colis, il contacte le support qui le rassure. Le lendemain, en effet, le client reçoit son colis, il signe un bon de réception. Son
colis est accompagné de la facture et d’un bon de livraison.
Voyons maintenant du côté de l’entrepôt de données de l’entreprise comment serait traduite cette situation :
Tout d’abord, chacune des pages vues du site Internet pourrait faire l’objet d’une ligne (de faits) dans la table de faits de
Navigation du Site Internet (transaction).
En fin de session Internet, une ligne de faits, dans la table de faits Session Site Internet, pourrait faire le bilan du temps
passé par l’internaute. Elle pourrait également comptabiliser le nombre de pages totales vues, le nombre d’articles consultés
et pourrait noter si le client potentiel a acheté… Il s’agit alors d’une table de faits de type Bilan.
La commande de l’article par le client ajouterait une ligne de faits à la table de faits Commande (transaction).
Au sein de l’entreprise, la commande serait préparée, la facture éditée (transaction), l’article serait sorti du stock (transaction)
et, au moment du départ vers le livreur, le bon de livraison serait édité (transaction).
Pendant ce temps, le client appelle le support de l’entreprise : ajout d’une ligne de faits dans la table des appels entrants du
support (transaction).
Puis, le livreur fait signer au client un bon de réception électronique, acte qui permet d’ajouter une ligne de faits dans la table
de faits des réceptions (transaction).
À la réception du colis, une nouvelle ligne de faits est ajoutée à la table de faits de bilan de commande, permettant de savoir
comment s’est déroulé le processus de vente : délai écoulé, retard, nombre d’incidents, temps passé avec le support, coûts
additionnels… (Bilan).
En fin de mois, un inventaire des stocks est réalisé tant en quantité qu’en valeur (Photo). Une photo des clients est
également faite afin de comptabiliser leur nombre sous différents aspects : segmentation, comportement d’achat, localisation
géographique… Il s’agit là aussi d’une table de faits de type photo.

Tout élément d’un processus peut être sujet à mesure, et dans une entreprise, les processus peuvent être très
nombreux.
C’est pour cela que chez Distrisys, nous avons entrepris d’interviewer les membres du comité de direction. En effet,
nous souhaitons une vision globale du projet mais également obtenir les grandes orientations de l’entreprise afin de
nous concentrer sur les processus les plus stratégiques. Des documents complémentaires tels que le plan stratégique
ou la cartographie des processus de l’entreprise sont des documents majeurs pour nous aider lors de cette étape.
Cette vision globale est très importante car elle permet :
● De se concentrer sur les processus les plus importants et donc d’aider à prioriser la réalisation du projet. En
effet, si la modélisation doit être globale, la réalisation de l’entrepôt de données doit se faire étape par étape.
● D’établir la matrice dimensionnelle et ainsi d’avoir une vision exhaustive des dimensions qui doivent croiser un
processus.
Un processus n’est pas la propriété d’une activité. L’évaluation des stocks intéresse autant le service de
gestion des stocks, que le service financier, de vente, d’achat, de production... même s’il est presque certain
que ces différents services n’analyseront pas les stocks avec le même angle de vue. Néanmoins, pour la bonne
marche de l’entreprise, aucun de ces services ne peut avoir une vision prépondérante sur ces voisins.
Par exemple, il n’est pas rare de voir des responsables marketing, production, achat ou de service financier parler d’un axe
produit qui n’a de commun, au premier abord, que le nom… Une des grandes tâches du projet sera alors de travailler de
concert, afin que la remontée d’un même processus puisse permettre à tous les services de faire les analyses spécifiques de
leur activité, tout en retrouvant et comprenant les analyses de l’activité voisine.
● D’établir la matrice dimensionnelle et ainsi de mettre en exergue les difficultés à venir au niveau des dimensions.
Contrairement à ce que l’on peut croire, la difficulté de réalisation d’un bon entrepôt de données vient de la
volonté de vouloir croiser un axe d’analyse avec deux processus parfaitement distincts et pris en charge par
deux services à la vision et à la culture opposée. Il est là, le vrai challenge de l’entrepôt de données.
Le fait de s’assurer un appui de la direction générale vous aidera assurément à relever ces challenges.
Certains lecteurs s’étonneront sûrement sur le fait que je n’ai pas abordé l’étude des systèmes sources. Cela
est normal, car le système source qu’il soit grand ERP, ERP modeste, système propriétaire ou réseau de fichier
Excel, n’impacte pas la modélisation de votre entrepôt de données. Le seul intérêt de l’étude des systèmes sources,
à ce stade, serait d’appréhender la disponibilité de l’information.
Après ce travail de synthèse, dressons la matrice dimensionnelle de Distrisys, disponible cidessous :
Matrice dimensionnelle de Distrisys
La matrice dimensionnelle cidessus couvre les domaines fonctionnels suivants :
● Activité commerciale : Facture Entête, Facture, Budget Vente, Bilan Commande Client.

● Les stocks : Stock photo et Stock Mouvement.
● Le service achat : Facture fournisseur, Bilan Commande Achat, Commande Achat en transit et Retour
Fournisseur.
L’intérêt d’une telle démarche est d’ores et déjà d’annoncer que les principaux axes Temps, Produit, Site, Client et
Fournisseur, permettront une analyse commune de processus parfois très éloignés ou difficiles à rapprocher.
Au cours de ce chapitre nous allons mettre en œ uvre, ensemble et progressivement, cette matrice dimensionnelle afin
qu’elle devienne un entrepôt de données, puis un cube.

Facturation et commande client
1. Modélisation et schéma en étoile
Pour commencer, nous allons nous intéresser aux tables de faits et aux dimensions relevant de l’activité commerciale.
Ce domaine fonctionnel peut s’illustrer par la matrice dimensionnelle cidessous :
Matrice dimensionnelle du périmètre des ventes
Quelques explications s’imposent quant aux nouvelles tables de faits :
● Facture, que l’on aurait pu nommer FactureLigne pour la distinguer de Facture Entête, est la table de faits que
nous avons mise en œ uvre au chapitre Réaliser son premier système décisionnel. Cette table, qui enregistre
une ligne de facture par fait, nous a permis de mesurer le CA, la marge, la remise et de détailler les différents
coûts au niveau produit.
● Facture Entete est la table de faits identifiant une facture par fait. Étant donné qu’une facture peut comporter
plusieurs produits, nous sommes dans l’incapacité, avec la seule table de faits FactFacture, de pouvoir compter
le nombre de factures émises. Utilisée pour ellemême, la mesure Nombre de factures n’est pas une mesure
très intéressante. En revanche, elle le devient si elle permet la création de mesures calculées, telles que Prix
moyen facturé ou Nombre d’articles moyen par facture.
● Budget Vente est la table de faits qui va porter les mesures : CA Budget et Marge Budget. Attention, le budget
est seulement saisi par mois, par produit et par site. Cette table de faits permet une projection de l’activité à
moyen et long terme.
● Bilan Commande Client est une table de faits de bilan. Dans notre cas, la table de faits Bilan Commande
Client couvre les processus de la demande initiale du client à sa livraison. Les mesures de la table de faits vont
surtout être temporelles : Délai prévisionnel (entre la date de demande et la date prévisionnelle de livraison)
et Délai réel (entre la date de demande et la date réelle de livraison). Deux autres mesures viendront
compléter la table de faits pour compter le nombre de commandes en retard et pour évaluer le délai de retard.
2. Les factures
Pour commencer, nous allons ajouter à l’entrepôt de données DistrisysDW, puis au cube, la table de faits
FactureEntete afin d’illustrer le processus de mise à jour.
La table de faits FactFactureEntete comprend une seule et unique mesure : Nombre Article facture. La mesure Nombre
Facture sera déduite au niveau du cube. Nous le verrons plus loin.
■ Ouvrez SQL Server Management Studio (SSMS), afin de créer la table FactFactureEntete suivant ces
caractéristiques :

Les colonnes DateFacturation_FK, Site_FK et Client_FK correspondent aux liaisons avec les tables de dimension
DimTemps, DimSite et DimClient aux grains spécifiés par la matrice dimensionnelle. Son schéma en étoile est le
suivant :
■ Vous allez donc créer dans SSMS, le schéma Facture Entete Etoile correspondant, en prenant bien soin de créer les
relations entre la table de faits et ses dimensions.
Rappelezvous : pour créer un schéma, glissez la table de fait que vous venez de créer, ainsi que les
dimensions relatives à cette table. Par exemple, pour le schéma Facture Entete Etoile, les dimensions à glisser
sont DimTemps, DimClient et DimSite (DimGeographie étant intimement liée aux deux dernières dimensions), car sur
FactFactureEntete, on peut lire DateFacturation_FK, Site_FK et Client_FK.
Vous devriez obtenir le schéma cidessous :

■ Maintenant, ouvrez dans BIDS le projet Analysis Services, créé au chapitre précédent. Puis double cliquez sur la vue
de source de données Distrisys DW.dsv.
■ Une fois dans la vue de sources de données, créez un nouveau schéma Facture Entete Etoile.
■ Puis cliquez sur le bouton Ajouter/supprimer des objets, afin d’ajouter au schéma la table FactFactureEntete.
■ Au final, après avoir glissé les tables de dimensions DimSite, DimClient, DimTemps et DimGeographie, vous devriez
avoir le schéma suivant :
En cas de difficulté, n’hésitez pas à reprendre le chapitre Réaliser son premier système décisionnel Créer et utiliser
simplement un cube brut.
Maintenant, nous allons déclarer cette table de faits comme un nouveau groupe de mesures du cube.

■ Pour cela, dans le projet de cube, cliquez sur le bouton Nouveau groupe de mesures.
■ Puis sélectionnez la table FactFactureEntete. Un nouveau groupe de mesures devrait se créer.
■ Pour finir, renommez le groupe de mesures Fact Facture Entete en Facture Entete, et la mesure Fact Facture
Entete Nombre en Nb Facture.

À ce sujet, vous avez pu remarquer que la mesure de comptage du nombre de lignes de faits s’ajoute par défaut à
toute création de groupe de mesures.
■ Au final, après traitement du cube et en allant sur l’onglet Navigateur, vous pouvez constater que les mesures de la
table de faits sont disponibles au niveau du cube.
Si vous souhaitez y adjoindre des données de test, vous pouvez soit reprendre le chapitre Réaliser son premier
système décisionnel Générer un jeu de test, soit partir du jeu de test téléchargeable sur le site du livre.
Au final, l’intérêt est de pouvoir analyser des mesures de deux tables de faits différentes au travers des mêmes
dimensions.
La modélisation dimensionnelle des factures se fait généralement toujours comme ceci avec la création de deux tables
de faits. La première table de faits sert à enregistrer les factures (FactFactureEntete), la seconde permet d’enregistrer
les faits au niveau de la ligne de produit (FactFacture).
■ Vous pouvez achever votre cube au niveau de la facturation, en créant deux nouvelles mesures calculées : Panier
Moyen et le Nombre Moyen Article Facture.
Expression
[Panier Moyen] [Measures].[CA]/[Measures].[Nb Facture]
[Nombre Moyen Article Facture] [Measures].[Nb Article Facture]/[Measures].[Nb Facture]
Ainsi, vous pouvez constater avec la mesure calculée Panier Moyen, que les mesures calculées peuvent être issues de
deux mesures provenant chacune, de deux tables de faits distinctes.
3. Le bilan de commande client
Maintenant que vous savez ajouter une table de faits au cube existant, nous allons nous intéresser à la table de faits
suivante : Bilan Commande Client.
Jusqu’à présent, nous avons travaillé avec deux tables de faits de type Transaction, c’estàdire que chaque nouvelle
facture dans le système source de Distrisys ajoute le lendemain une ou plusieurs lignes dans les tables de faits
FactFactureEntete et FactFacture.
C’est ce même type de tables de faits qui permet la modélisation de processus à la transaction comme un bon de
livraison, un bon de réception, une signature contrat, une opportunité commerciale, une édition de devis… Les tables
de faits de type Transaction permettent une étude détaillée d’un processus.
La table de faits Bilan Commande Client est une table de faits de type Bilan. Ce type de tables de faits couvre
normalement un certain nombre de transactions pour en faire un bilan, à l’achèvement de la dernière transaction.
Concrètement, une ligne de fait de notre table FactBilanCommandeClient s’ajoutera à chaque fois qu’une commande
sera actée comme livrée à son destinataire. Cette table fera alors un récapitulatif du processus, entre le moment de la
demande du client et sa réception réelle. Dans notre cas Distrisys, nous avons souhaité nous concentrer uniquement
sur un bilan en termes de délai. Nous aurions aussi pu faire un bilan financier de la commande, en incluant les frais de
support (temps passé des opérateurs à traiter cette commande…) et autres frais qui surviennent parfois lors de
l’exécution d’une commande.

La table de faits FactBilanCommandeClient comprendra donc les mesures suivantes :
● Délai prévu : différence entre la date de demande du client et la date prévisionnelle de livraison de la
commande
● Délai réel : différence entre la date de demande et la date réelle de livraison de la commande
● Nb Retard : identifiera par un 1, chaque commande dont le délai réel est supérieur au Délai prévu. Sinon 0.
● Délai retard : Différence entre Délai réel et Délai prévu si la commande est en retard, sinon 0.
Cette table de faits nous permettra ainsi de mesurer les engagements de délai que nous prenons visàvis de nos
clients.
En reprenant la matrice dimensionnelle, nous pouvons en déduire les relations que FactBilanCommandeClient aura avec
les tables de dimension :
● DateDemande_FK : permet d’identifier la date de la demande client et fera la liaison avec Temps_PK de la table
DimTemps.
● DateLivraisonPrevue_FK : permet d’identifier la date de livraison annoncée au client et fera la liaison avec la
dimension Temps.
● DateLivraisonReelle_FK : permet d’identifier la date effective de livraison au client et fera la liaison avec la
dimension Temps.
● Site_FK : permet d’identifier le site de facturation et fera la liaison avec la dimension Site.
● Client_FK : permet d’identifier le client et fera la liaison avec la dimension Client.
Vous constaterez que FactBilanCommandeClient dispose de trois relations distinctes avec la table DimTemps. C’est une
caractéristique des tables de faits de type Bilan. On dit alors que la dimension Temps joue plusieurs rôles. Voyons un
peu comment mettre en œ uvre cette spécificité au niveau de l’entrepôt de données et du cube Analysis Services.
■ Tout d’abord, commencez par créer avec SSMS, la table FactBilanCommandeClient :
Pour rappel du chapitre Réaliser son premier système décisionnel Création des tables de faits et de dimension, le
champ NumCommande est un attribut de dimension dégénérée. Ce champ facultatif n’entre pas en compte lors de
l’analyse, mais permettra d’identifier la ligne en cas d’audit. Dans notre cas, on y fera figurer le numéro de commande.
La représentation schématique de l’étoile de cette table de faits est la suivante :

Date demande, Date Livraison prévue et Date Livraison réelle ne sont que des rôles de la dimension Temps. Ce ne sont
pas de nouvelles entités.
■ Toujours dans SSMS, créez le schéma Bilan Commande Client Etoile comme cidessous en liant Temps_PK à
DateDemande_FK, à DateLivraisonPrevue_FK et à DateLivraisonReelle_FK :
■ Générez un jeu de test pour cette nouvelle table de faits FactBilanCommandeClient. Vous pouvez utiliser le jeu de
test en téléchargement sur le site du livre.
■ Dans le projet Analysis Services de BIDS, créez un nouveau schéma :
■ Puis ajoutez un nouveau groupe de mesures Bilan Commande Client.

■ Renommez la mesure de comptage Fact Bilan Commande Client Nombre en Nb Commande livree.
■ Modifiez la propriété Visible à False des mesures Delai Prevu En Jour, Delai Reel En Jour et Délai Retard En Jour.
En effet, afficher la somme des délais prévus, réels ou de retard n’a que peu d’intérêt pour l’utilisateur. En revanche,
nous allons créer trois nouvelles mesures calculées Délai Prevu Moyen, Délai Reel Moyen et Délai Retard Moyen qui
seront des mesures bien plus pertinentes :
Expression
[Délai Prévu Moyen] [Measures].[Delai Prevu En Jour]/[Measures].[Nb Commande livree]
[Délai Réel Moyen] [Measures].[Delai Reel En Jour]/[Measures].[Nb Commande livree]
[Délai Retard Moyen] [Measures].[Delai Retard En Jour]/[Measures].[Nb Commande livree]
[% Commande en retard] [Measures].[Nb Commande en Retard]/[Measures].[Nb Commande livree]
■ Modifiez les propriétés FormatString des nouvelles mesures si vous le souhaitez. Pour rappel, reportezvous au
chapitre Réaliser son premier système décisionnel Peaufiner le cube.
■ Puis, après traitement, allez sur le Navigateur :
Première constatation
La modélisation a permis à BIDS de générer les rôles de la dimension Temps. BIDS a créé trois nouvelles dimensions
ayant les mêmes propriétés (membres, attributs et hiérarchies) que la dimension Temps originale.
Deuxième constatation

Lorsqu’on glisse la dimension Temps en ligne dans le tableau croisé dynamique, on remarque que la mesure Nb
Commande livree affiche uniquement la valeur de total : cela signifie que le groupe de mesures Bilan Commande Client
n’est pas analysable par l’axe Temps.
■ Jetons un coup d’œ il à l’onglet Utilisation de la dimension :
On constate que dans la matrice actuelle, le groupe de mesures Bilan Commande Client n’est pas analysable par la
dimension Temps. Nous pouvons constater qu’à l’écran, aucune donnée (rectangle grisé) n’apparait à l’intersection du
groupe de mesures et de la dimension cités cidessus.
Pour avoir une conformité avec la matrice dimensionnelle souhaitée, en début de chapitre, il nous faut déclarer à BIDS
que le groupe de mesure Bilan Commande Client s’analyse par la dimension Temps au travers de la Date de
livraison réelle. C’estàdire que lorsque nous afficherons la dimension Temps avec une mesure de Bilan Commande
Client, nous analyserons cette mesure suivant l’axe Date Livraison Relle.
■ Pour réaliser cette manipulation, cliquez sur le bouton à l’intersection de Temps et Bilan Commande Client.
Puis saisissez les informations comme cidessous :

■ Identifiez et validez la relation entre la dimension Temps et la table de faits Bilan Commande Client, par la relation
régulière entre Temps_PK et DateLivraisonReelle_FK.
Analysis Services gère plusieurs types de relations, dont les plus communes sont les relations : Normale, Plusieurs à
plusieurs et Référencé. Ces relations sont définies par les relations physiques entre les tables. Le schéma
synthétique en étoile vous aide à identifier la relation à mettre en œ uvre. Néanmoins, dans ce livre nous n’aborderons
que les relations normales.
Après votre manipulation, vous devriez alors obtenir la matrice dimensionnelle suivante :
Cette matrice dimensionnelle est en conformité avec celle que nous souhaitions mettre en œ uvre en début de
chapitre.
■ En allant sur l’onglet Navigateur, vous constaterez que maintenant la dimension Temps permet l’analyse des
mesures de Bilan Commande Client :

4. Le budget des ventes
Traitons maintenant la dernière table de faits du périmètre des ventes : Budget Vente.
À noter que l’entrepôt de données n’est pas le meilleur endroit pour stocker et traiter les budgets. En effet, les
budgets, prévisions ou autres objectifs par essence sont assez changeants et fluctuants : ils se révisent, ils ne sont
pas toujours reportés à l’identique d’une année sur l’autre. Certains objectifs sont parfois même créés lors
d’apparition d’évènements modifiant le contexte et l’environnement immédiat de l’organisation. Pour être plus réactif
et plus souple, il est nécessaire d’employer des outils et une modélisation plus proche d’une vision métier, rendant
autonome les services fonctionnels concernés. Ces solutions logicielles sont communément connues sous le nom
d’outils de planification et d’élaboration budgétaire. Pour être mises en œ uvre efficacement et sereinement, ces
solutions nécessitent néanmoins de reposer sur un entrepôt de données solidement constitué.
Toutefois, les organisations qui sont en cours de construction ou de refonte de leur entrepôt de données, ou n’ayant
pas amorcé de démarche d’entreprise de management de la performance, n’ont généralement pas la maturité pour
investir sur de telles solutions.
C’est parce que ce dernier cas est assez fréquent, voire majoritaire dans les entreprises de taille moyenne, que je
vous propose par réalisme d’intégrer le budget des ventes au sein de l’entrepôt de données.
À noter néanmoins qu’Analysis Services supporte la modélisation dimensionnelle métier (ou modélisation financière)
préalable à ce type d’approche. La base multidimensionnelle de Microsoft est aussi le pivot de nombreuses solutions
de planification budgétaire du marché. Ce pan du décisionnel ne sera pas abordé dans ce livre. Il devra être abordé
dans une phase ultérieure de progression de votre système décisionnel que je qualifie de Management de la
Performance. Pour plus de détail reportezvous à la conclusion de l’ouvrage.
Dans cette partie, nous allons apprendre à traiter chaque budget comme une table de faits. Nous verrons alors
comment dans ce contexte, les objectifs s’intègrent et se traitent au sein de l’entrepôt de données et du cube qui y
est associé.
Les objectifs des ventes de Distrisys portent uniquement sur le CA et sur la marge, et sont déterminés par mois, par
produit et par site de vente.
■ Créez la table FactBudgetVente avec la structure suivante :
■ Dans SSMS, créez le schéma Budget Vente Etoile, comme vous avez appris à le faire :

Le budget des ventes sera saisi par mois, néanmoins au niveau des données, le grain reste au jour.
Les saisies mensuelles seront affectées au premier jour du mois correspondant. Par exemple, cela signifie que les
lignes budgétaires du mois de mai 2010 seront en réalité affectées au 1er mai 2010. Les niveaux Jour et Semaine ne
doivent pas être, de ce fait, accessibles à l’utilisateur, car le budget est défini au mois, au niveau le plus bas. Vous
verrez plus tard, avec les perspectives, comment bien présenter les données à l’utilisateur, afin de l’empêcher
d’afficher les données au jour.
■ Vous allez maintenant, à partir de BIDS, créer le schéma Budget Vente Etoile correspondant.
■ Toujours dans BIDS, dans le projet de cube, au niveau de l’onglet Structure de cube, ajoutez le nouveau groupe de
mesures Fact Budget Vente, que vous renommerez Budget Vente.
■ Supprimez ensuite la mesure qui se crée par défaut : Fact Budget Vente Nombre.
■ Renommez les mesures CA Fact Budget Vente en CA Budget Vente et Marge Fact Budget Vente en Marge
Budget Vente. Modifiez leur propriété FormatString.
■ Créez enfin les mesures calculées suivantes :
Mesures calculées Expression Description
[% Marge Budget Vente] [Measures].[Marge Budget Vente]/ Affiche le taux de marge

[Measures].[CA Budget Vente] budgétée.
[% CA vs Budget Vente] [Measures].[CA]/ [Measures].[CA Budget Affiche le taux d’atteinte de

Vente] l’objectif en CA.
[Ecart Marge vs Budget Vente] [Measures].[% Marge][Measures].[% Affiche l’écart entre le taux de

Marge Budget Vente] marge réel et le taux de
marge budgété.
Vous pouvez, si vous le souhaitez, charger des données à partir d’un jeu de test (cf. chapitre Réaliser son premier
système décisionnel Génération du jeu de test) ou télécharger le jeu de test proposé en téléchargement sur le site
du livre.
■ Après traitement, allez sur l’onglet Navigateur. Vous devrez pouvoir visualiser le tableau croisé dynamique ci
dessous :

■ Pour finir, éditez la dimension Temps et créez une nouvelle hiérarchie Année Mois. Si besoin, reportezvous au
chapitre Réaliser son premier système décisionnel Peaufiner le cube.
L’utilisation de cette hiérarchie ne permettra pas à l’utilisateur de descendre au niveau de la journée. En revanche, en
l’état actuel du cube, l’utilisateur a la possibilité de faire une erreur et de sélectionner une hiérarchie descendant au
jour.
Pour remédier à ce problème, nous allons créer une perspective.
5. Les perspectives
La perspective est simplement une vue simplifiée de la matrice dimensionnelle : une vue cohérente pour un sujet
d’analyse donné.
Dans le cas de la mise en œ uvre du budget, nous pourrions réaliser deux perspectives :
● Suivi des ventes par site : la première perspective serait alors celleci :

Matrice dimensionnelle de la perspective Suivi Vente par site
● Suivi des ventes par produit : la seconde perspective serait alors cellelà :
Matrice dimensionnelle de la perspective Suivi Vente par produit
L’idée d’une perspective est de donner aux utilisateurs finaux une vue cohérente entre groupes de mesures et
dimensions, et donc entre mesures et attributs.
Toutes les tables de faits et de dimensions ne se croisent pas. De nombreuses intersections se retrouvent vides.
L’idée d’une perspective est de montrer une vue orientée métier.
■ Pour mettre en œ uvre ces deux perspectives, allez dans le projet de cube de BIDS et cliquez sur l’onglet
Perspective.

■ Cliquez ensuite sur le bouton Nouvelle perspective :

■ Créez deux nouvelles perspectives : Suivi Vente par Site et Suivi Vente par produit, comme indiqué cidessous :
En fait, il s’agit de cocher uniquement les éléments que nous souhaitons conserver dans la perspective. Au besoin,
conférezvous aux matrices dimensionnelles des perspectives correspondantes.
■ Dépliez la dimension Temps, et conservez cochée uniquement la hiérarchie Année Mois :

■ Dépliez l’élément Calculs et gardez sélectionnées uniquement les mesures calculées qui ont une cohérence et un
sens avec la perspective considérée :
Les mesures calculées Panier Moyen et Nb Moyen Article Facturé sont en lien direct avec le groupe de mesures
Facture Entete qui ne fait pas partie de la perspective Suivi Vente par produit. C’est pour cela qu’elles sont
décochées. C’est le même raisonnement qui nous a conduits à désélectionner les mesures calculées en relation avec
le groupe de mesures Bilan Commande Client.
■ Après traitement, allez dans l’onglet Navigateur, puis sélectionnez avec la liste déroulante Perspective, Suivi
Vente par Site :

Le navigateur de cube se rafraichit alors pour mettre à disposition uniquement les éléments de groupes de mesures et
de dimensions disponibles dans la perspective.
Vous constaterez aussi que la seule hiérarchie disponible dans la dimension Temps est la hiérarchie Année Mois.
Les perspectives se travaillent et s’affinent en contact des utilisateurs de votre cube. Attention, il ne s’agit pas d’un
élément de sécurité permettant de restreindre l’accès à des informations cruciales à certains utilisateurs. Il s’agit
seulement d’un élément de confort d’utilisation fort utile. L’importance de la perspective va croissant avec le
développement du périmètre fonctionnel de l’entrepôt de données.
6. Les actions
Toujours dans un esprit de finalisation du périmètre des ventes, nous allons maintenant mettre en œ uvre une
fonctionnalité vraiment très appréciée des utilisateurs : la fonctionnalité d’audit.
Au sein de SSAS, l’audit de données se traduit par la possibilité donnée à l’utilisateur, à tout moment, d’obtenir un
extrait des lignes qui compose une cellule d’un tableau croisé dynamique. Nous allons le mettre en œ uvre rapidement
et simplement afin que vous compreniez l’utilisation de la fonction, puis dans un second temps nous la compléterons.
■ Dans BIDS, dans le projet de cube, cliquez sur l’onglet Actions.

■ Cliquez sur le bouton Nouvelle action d’extraction.
■ Nommez l’action Extraction Facture et configurezla comme cidessous :

■ Enregistrez vos modifications, traitez le cube, puis allez dans l’onglet Navigateur.
■ Réalisez un tableau croisé dynamique avec CA en colonne et la hiérarchie Pays Site en ligne.
■ Sélectionnez la cellule du tableau croisé dynamique correspondant au CA réalisé en Espagne, puis faites un clic droit
pour afficher le menu contextuel.
■ Cliquez dans le menu contextuel sur Extraction Facture :

La visionneuse de données s’affiche pour vous donner un extrait des 1000 premières lignes correspondant à l’agrégat
sélectionné.
Ici, il s’agit des 2 706 744 € réalisés auprès des clients espagnols en 2010.
Attention, il ne s’agit pas de transformer le cube en extracteur de données, mais juste d’auditer les lignes et
de donner la possibilité aux utilisateurs de faire la passerelle entre les données du système décisionnel et
celles du système opérationnel (source).
Afin d’aller au bout de cette idée, nous allons maintenant offrir la possibilité aux utilisateurs de visualiser le numéro de
facture des lignes remontées par l’extraction.
Rappelezvous, à la création de certaines tables de faits, nous avons ajouté une ligne dite de dimension
dégénérée. C’est cette donnée que nous allons offrir en visualisation par le biais de l’action d’extraction.
Maintenant que vous êtes familiarisé avec l’interface, suivez la procédure cidessous :
■ Par le biais de l’Explorateur de solution, allez dans la vue de source de données Distrisys DW.dsv.
■ Sélectionnez le diagramme Facture Etoile.
■ Cliquez sur le bouton Nouvelle requête nommée.
■ Nommez la requête Audit Facture et tapez la requête SQL suivante :
SELECT DISTINCT(NumFacture) FROM FactFacture
■ Liez le champ NumFacture de la table FactFacture au champ NumFacture de la requête nommée AuditFacture.
■ Un message doit vous demander de définir le champ NumFacture comme clé primaire logique. Cliquez sur Oui. Puis
enregistrez.
■ Dans l’Explorateur de solution, faites un clic droit sur Dimension pour afficher le menu contextuel. Sélectionnez et
cliquez sur Nouvelle Dimension.

■ L’Assistant Dimension démarre. À l’écran Sélectionner la méthode de création, choisissez Utiliser une table
existante.
■ À l’écran Spécifier des informations sur la source, sélectionnez comme table principale AuditFacture.
■ Cliquez sur Suivant à l’écran suivant, puis cliquez sur Terminer pour créer la dimension.
■ Dans le projet de cube, sur le premier onglet Structure de cube, cliquez sur le bouton Ajouter une dimension de

cube.
■ Sélectionnez AuditFacture. Cliquez sur OK.
■ La dimension Auditfacture doit s’afficher dans le panneau Dimensions en bas à gauche de l’onglet Structure de
cube. Sélectionnez la nouvelle dimension AuditFacture, Allez dans ses propriétés pour spécifier la propriété Visible
à False. AuditFacture n’est pas véritablement une dimension d’analyse. Il ne faut pas que les dimensions d’audit
soient disponibles aux utilisateurs.
■ Dans le projet de cube, cliquez sur l’onglet Actions.
■ Ajoutez dans les colonnes d’extraction AuditFacture et en colonne de retour NumFacture.
■ Enregistrez et traitez le cube. Dans l’onglet Navigateur, à l’affichage de l’action Extraction Facture vous devriez
maintenant voir s’afficher le numéro de facture de chaque ligne constituant l’extrait, comme le montre la copie
d’écran cidessous :
Cette procédure n’est pas à généraliser systématiquement pour toutes les tables de faits. C’est une procédure à
réaliser sur demande d’un service ou d’un utilisateur, notamment au moment de la recette des données. Il reste
nécessaire, au moment de la modélisation de la table de faits, de réfléchir à la mise à disposition d’une dimension
dégénérée.
7. Introduction au MDX

a. La requête MDX
Avant d’en terminer avec le périmètre des ventes, nous allons aborder quelques notions de MDX.
Au même titre que le SQL est le langage de requêtes d’une base de données relationnelle, le MDX est le langage
permettant de faire des requêtes sur un cube,
Pour rappel, ce que nous appelons communément un cube, n’est autre qu’une base de données
multidimensionnelle.
Le langage MDX est, par certains côtés, proche du SQL. Il n’est ni plus simple, ni plus compliqué : il est simplement
différent, moins connu et moins usité que le SQL. Rappelons aussi que vos requêtes MDX seront d’autant plus faciles
à réaliser si votre base est bien modélisée et bien préparée.
Cette préparation, vous l’avez faite tout au long du chapitre Réaliser son premier système décisionnel, notamment
avec un vrai travail de fond sur la dimension Temps.
Au cours de ce chapitre, nous allons essayer d’acquérir quelques bases :
● Où trouver un requêteur MDX et comment faire une requête MDX classique.
Puis nous verrons quelques exemples concrets et basiques que vous retrouverez sur tous vos projets :
● Comment créer en MDX des mesures calculées de type cumul annuel, moyenne mobile et valeur d’une
période précédente.
Commençons par écrire une requête simple.

■ Dans SSMS, cliquez sur le bouton Requête MDX Analysis Services :
Le requêteur MDX de SSMS est composé de deux zones :
● La première zone, la plus à droite, est la zone de travail.
● La seconde zone, la plus à gauche, est le navigateur de cube.
Les éléments de mesures, de dimension, d’attributs, de hiérarchie et même de membres se glissent par glisser
déposer directement dans la zone de travail. Faites quelques essais pour comprendre comment s’utilise l’interface.
■ Maintenant, écrivez dans la zone de travail, la requête suivante en vous aidant bien entendu du navigateur du
cube :
SELECT
[Measures].[CA] ON COLUMNS
FROM [Distrisys]
■ Puis cliquez sur le bouton Exécuter pour lancer la requête :

Dans la fenêtre Résultats, nous pouvons visualiser le résultat de la requête. Cette requête demande tout
simplement d’afficher en colonne la mesure CA du cube Distrisys.
■ Modifions maintenant la requête pour afficher le CA en 2010 : l’année 2010 devant apparaître en ligne. Pour cela,
tapez la requête suivante :
SELECT
[Measures].[CA] ON COLUMNS,
[Temps].[Année - Mois - Jour].[Année].&[20100101] ON ROWS
FROM [Distrisys]
■ Exécutez la requête. Vous devriez avoir le résultat suivant :

La syntaxe [Measures].[CA] ou [Temps].[Année Mois Jour].[Année].&[20100101] est appelée

UniqueName. C’est en quelque sorte la référence unique à un membre d’une dimension. Notez que le
UniqueName fait appel à la clé du membre.
■ Modifions encore une fois la requête pour obtenir le CA en 2010 des sites français. Tapez la requête suivante :
SELECT
[Measures].[CA] ON COLUMNS,
[Temps].[Année - Mois - Jour].[Année].&[20100101] ON ROWS
FROM [Distrisys]
WHERE
(
[Site].[Pays - Site].[Pays].&[Fr]
)
■ Exécutez la requête, vous devriez avoir le résultat suivant :
Tous les composants de la requête MDX sont présents dans cette requête. À la manière d’un tableau croisé
dynamique, la requête MDX est constituée d’éléments en colonne, en ligne et en filtre.

À l’usage, on prend l’habitude de simplifier l’écriture en substituant le mot clé COLUMNS par 0, et le mot clé ROWS
par 1. La requête suivante donne exactement le même résultat que précédemment :
SELECT
[Measures].[CA] ON 0,
[Temps].[Année - Mois - Jour].[Année].&[20100101] ON 1
FROM [Distrisys]
WHERE
(
[Site].[Pays - Site].[Pays].&[Fr]
)
Maintenant, si l’on souhaite afficher plusieurs membres d’une même hiérarchie, sur un même axe, on utilise les
accolades { }. On dit alors qu’il s’agit d’un jeu de membres.
■ Ajoutons par exemple en colonne la mesure % Marge, tapez la requête suivante :
SELECT
{[Measures].[CA], [Measures].[% Marge]} ON 0,
[Temps].[Année - Mois - Jour].[Année].&[20100101] ON 1
FROM [Distrisys]
WHERE ( [Site].[Pays - Site].[Pays].&[Fr] )
Le jeu de membres fonctionne autant en colonne, qu’en ligne ou qu’en filtre. Il fonctionne autant pour les mesures
que pour les membres de dimensions.
Maintenant, nous souhaitons afficher le CA et le % Marge des sites français, pour tous les mois de l’année 2010.
Deux solutions s’offrent à nous :
● Soit nous pouvons faire appel aux accolades et à un jeu de membre comprenant les douze mois de l’année.
● Soit nous faisons appel à une fonction de navigation dans la hiérarchie, qui va nous faire l’économie de
beaucoup de script.
Utilisons par exemple la fonction .Children. Cette fonction affiche tous les enfants d’un membre d’une hiérarchie.
Comprenez parlà que les enfants de Année 2010, dans la hierarchie [Année Mois Jour], seront les mois de 2010. Mais
que par contre, les enfants de Année 2010 dans la hiérarchie [Année Semestre Trimestre Mois Jour] seront les deux
semestres de 2010.
■ Tapez la requête suivante :
SELECT
{[Measures].[CA], [Measures].[% Marge]} ON 0,
[Temps].[Année - Mois - Jour].[Année].&[20100101].children ON 1
FROM [Distrisys]
WHERE ( [Site].[Pays - Site].[Pays].&[Fr] )

Il existe de nombreuses fonctions de navigation, de mathématiques, de statistiques... Pour les découvrir, cliquez sur
l’onglet Fonctions dans la zone de navigation du cube :
Cet ouvrage n’ayant pas pour but d’être un guide de référence du MDX, veuillez vous référer à la
documentation technique de Microsoft pour les découvrir plus en détail.
Nous souhaitons maintenant créer une nouvelle mesure, CA Espagne qui, quelle que soit la dimension Site, affiche
toujours le CA réalisé par les sites espagnols. Cette nouvelle mesure devra s’afficher en colonne au côté de la
mesure CA.
Tapez la requête cidessous :
WITH
MEMBER [CA Espagne] AS
(
([Measures].[CA], [Site].[Pays - Site].[Pays].&[ES])
)
SELECT
{[Measures].[CA], [CA Espagne]} ON 0,
[Temps].[Année - Mois - Jour].[Année].&[20100101].children ON 1
FROM [Distrisys]
Pour information, si vous souhaitez mettre des bouts de code en commentaire, vous pouvez : soit utiliser les

doubles tirets pour mettre en commentaire une ligne, soit encadrer le code à mettre en commentaire par /*
et */ s’il s’agit de plusieurs lignes.
Cette syntaxe entre parenthèses, couplant plusieurs membres de dimensions différentes, est appelée un
tuple.
La clause WITH MEMBER reproduit le comportement d’une mesure calculée.
■ Pour rendre disponible cette mesure CA Espagne, comme mesure calculée au niveau du cube, copiez la syntaxe
du tuple (il s’agit du contenu pris entre les parenthèses du mot clé AS).
([Measures].[CA], [Site].[Pays - Site].[Pays].&[ES])
■ Allez dans BIDS, dans le projet de cube, cliquez sur l’onglet Calculs, puis sur le bouton Nouveau membre calculé.
■ Nommez la nouvelle mesure calculée CA Espagne, et collez le contenu du pressepapier dans la zone Expression.
■ Déployez le cube, puis retournez soit dans SSMS, soit dans l’onglet Navigateur pour tester votre nouvelle mesure
calculée.
Maintenant que vous êtes un peu familiarisé avec les requêtes MDX et que vous savez comment tester la syntaxe
d’une future mesure calculée, nous allons créer des mesures calculées couramment utilisées et les mettre en œ uvre
dans le cube Distrisys.
b. Comparaison de valeurs à date
Une des premières demandes que vous aurez en mettant en place un cube, est de pouvoir comparer les valeurs
mensuelles par exemple, avec le mois précédent ou avec le même mois de l’année précédente.
Pour réaliser cette comparaison, nous allons créer une mesure calculée utilisant la fonction ParallelPeriod.
■ Dans le requêteur MDX de SSMS, tapez la requête suivante :
WITH
MEMBER [CA Mois-1] AS
(
[Measures].[CA],
ParallelPeriod(
[Temps].[Année - Mois - Jour].[Mois],
1,
[Temps].[Année - Mois - Jour].CurrentMember
)
),FORMAT_STRING="Currency"
MEMBER [CA Mois Année-1] AS
(
[Measures].[CA],
ParallelPeriod(
[Temps].[Année - Mois - Jour].[Annee],
1,

[Temps].[Année - Mois - Jour].CurrentMember
)
),FORMAT_STRING="Currency"
SELECT
{[Measures].[CA], [CA Mois-1], [CA Mois Année-1]} ON 0,
[Temps].[Année - Mois - Jour].[Annee].&[20100101].children ON 1
FROM [Distrisys]
Les deux nouvelles mesures sont en fait un tuple formé du couple entre le CA et une fonction ParallelPeriod. La
fonction ParallelPeriod permet de retourner un membre de la dimension Temps. Le membre retourné est fonction du
niveau spécifié, d’un nombre d’occurrences et d’un membre de référence.
Dans le cas de la mesure CA Mois1, le niveau spécifié est le niveau Mois. Le Nombre d’occurrences est 1 et le
membre de référence est le membre courant. Dans les faits cela se traduit par ramener pour le membre actuel de la
dimension Temps, l’occurrence précédente (1) du niveau mois : soit obtenir le mois précédent de chaque mois affiché.
Dans le cas de la mesure CA Année Mois1, le niveau spécifié est le niveau Année. Le nombre d’occurrences est 1 et
le membre de référence est le membre courant. Dans les faits cela se traduit par ramener pour le membre actuel de
la dimension Temps, l’occurrence précédente (1) au niveau annuel : soit obtenir le même mois de l’année précédente
de chaque mois affiché.
Par exemple, nous sommes au mois d’avril 2010 et nous souhaitons comparer le CA actuel avec celui du mois précédent
(c’estàdire le mois de mars 2010) ou bien encore, nous souhaitons toujours comparer ce fameux chiffre d’affaires mais
d’une année sur l’autre, c’estàdire comparer avril 2009 par rapport à avril 2010 : c’est grâce à cette fonction
ParallelPeriod que nous serons en mesure de le faire.
Nous sommes donc en mesure de créer quatre nouvelles mesures calculées :
Mesures calculées Expression
CA Mois1 (
[Measures].[CA],
ParallelPeriod(
[Temps].[Année Mois Jour].[Mois],
1,
[Temps].[Année Mois Jour].CurrentMember
)
)
CA Mois Année1 (

Langue

Business Intelligence Avec SQL Server 2008 R2 PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Business Intelligence Avec SQL Server 2008 R2 PDF

Transféré par

Droits d'auteur :

Formats disponibles

Business Intelligence

avec SQL Server 2008 R2

© ENI Editions - All rigths reserved - educ algeria - 1-

© ENI Editions - All rigths reserved - educ algeria - 1-

© ENI Editions - All rigths reserved - educ algeria - 1-

© ENI Editions - All rigths reserved - educ algeria - 1-

© ENI Editions - All rigths reserved - educ algeria - 1-

- 2- © ENI Editions - All rigths reserved - educ algeria

© ENI Editions - All rigths reserved - educ algeria - 3-

- 4- © ENI Editions - All rigths reserved - educ algeria

© ENI Editions - All rigths reserved - educ algeria - 5-

- 6- © ENI Editions - All rigths reserved - educ algeria

© ENI Editions - All rigths reserved - educ algeria - 1-

- 2- © ENI Editions - All rigths reserved - educ algeria

© ENI Editions - All rigths reserved - educ algeria - 3-

- 4- © ENI Editions - All rigths reserved - educ algeria

© ENI Editions - All rigths reserved - educ algeria - 5-

- 6- © ENI Editions - All rigths reserved - educ algeria

© ENI Editions - All rigths reserved - educ algeria - 7-

- 8- © ENI Editions - All rigths reserved - educ algeria

© ENI Editions - All rigths reserved - educ algeria - 9-

- 10 - © ENI Editions - All rigths reserved - educ algeria

© ENI Editions - All rigths reserved - educ algeria - 11 -

- 12 - © ENI Editions - All rigths reserved - educ algeria

© ENI Editions - All rigths reserved - educ algeria - 13 -

Des versions d’évaluation de ces produits sont disponibles en téléchargement sur le site Technet Evaluation

© ENI Editions - All rigths reserved - educ algeria - 1-

● Les perspectives : il s’agit de la fonctionnalité permettant de réaliser un entrepôt de données conforme en

© ENI Editions - All rigths reserved - educ algeria - 1-

- 2- © ENI Editions - All rigths reserved - educ algeria

© ENI Editions - All rigths reserved - educ algeria - 1-

- 2- © ENI Editions - All rigths reserved - educ algeria

© ENI Editions - All rigths reserved - educ algeria - 3-

- 4- © ENI Editions - All rigths reserved - educ algeria

© ENI Editions - All rigths reserved - educ algeria - 5-

© ENI Editions - All rigths reserved - educ algeria - 1-

- 2- © ENI Editions - All rigths reserved - educ algeria

■ Au niveau de la connexion de votre moteur de base de données, faites un clic droit sur Base de données, puis

© ENI Editions - All rigths reserved - educ algeria - 3-

- 4- © ENI Editions - All rigths reserved - educ algeria

© ENI Editions - All rigths reserved - educ algeria - 5-

- 6- © ENI Editions - All rigths reserved - educ algeria

© ENI Editions - All rigths reserved - educ algeria - 1-

© ENI Editions - All rigths reserved - educ algeria - 1-

Mini Maxi Coût en octets

Numeric(9,1) ­10 000 000,0 10 000 000,0 5

Numeric(9,2) ­1 000 000,00 1 000 000,00 5

Numeric(9,3) ­100 000,000 100 000,000 5

- 2- © ENI Editions - All rigths reserved - educ algeria

© ENI Editions - All rigths reserved - educ algeria - 3-

- 4- © ENI Editions - All rigths reserved - educ algeria

© ENI Editions - All rigths reserved - educ algeria - 5-

- 6- © ENI Editions - All rigths reserved - educ algeria

© ENI Editions - All rigths reserved - educ algeria - 7-

- 8- © ENI Editions - All rigths reserved - educ algeria

© ENI Editions - All rigths reserved - educ algeria - 9-

● Dans certains cas, vous aurez besoin de faire des analyses à l’heure : il s’agira alors de créer une dimension

© ENI Editions - All rigths reserved - educ algeria - 1-

- 2- © ENI Editions - All rigths reserved - educ algeria

© ENI Editions - All rigths reserved - educ algeria - 3-

- 4- © ENI Editions - All rigths reserved - educ algeria

© ENI Editions - All rigths reserved - educ algeria - 5-

Numeric(9,1) 10 000 000,0 10 000 000,0 5

Numeric(9,2) 1 000 000,00 1 000 000,00 5

Numeric(9,3) 100 000,000 100 000,000 5

MoisDate SmallDateTime 20091101 00:00:00 Format date