Business Intellig

Business
applications & métiers
Intelligence
avec
SQL Server 2008
Mise en œuvre d’un projet décisionnel
Bertrand Burquier
BUSINESS
INTELLIGENCE
AVEC
SQL SERVER 2008
Mise en œuvre
d'un projet décisionnel
Business Intelligence
avec SQL Server 2008
Mise en œuvre d'un projet décisionnel
Bertrand Burquier
432 pages
Dunod, 2007
Microsoft® SQL Server® 2008

Étape par étape
Mike Hotek
400 pages
Microsoft Press, 2009
BUSINESS
INTELLIGENCE
AVEC
SQL SERVER 2008
Mise en œuvre
d'un projet décisionnel
Bertrand Burquier
Consultant et ingénieur en systèmes d'information
Toutes les marques citées dans cet ouvrage sont des
marques déposées par leurs propriétaires respectifs.
Illustration de couverture : arbres d automne © Jean-Michel POUGET-Fotolia.com
© Dunod, Paris, 2009

ISBN 978-2-10-054197-3
Table des matières
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Chapitre 1 – La Business Intelligence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.1 La Business Intelligence pour qui, pour quoi ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2 Objectifs et enjeux du décisionnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3 Le processus de décision ou le facteur humain dans la prise de décision . . . . . . . 9
1.3.1 Comprendre les besoins d’aide à la décision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3.2 Agir, analyser, décider, agir... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.3.3 Tableau de bord et business intelligence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.3.4 En quoi la BI est-elle utile à l’entreprise ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.4 Les modèles d’accès à l’information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.4.1 La dictature de l’information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.4.2 L’anarchie de l’information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.4.3 La démocratie de l’information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Chapitre 2 – L’approche méthodologique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.1 Les étapes d’un projet informatique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.1.1 Le cycle en V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.1.2 La méthode agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.1.3 L’étude de faisabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.1.4 Le cycle de vie du projet BI selon Ralph Kimball . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
VI Business Intelligence avec SQL Server 2008
2.2 Pourquoi un tableau de bord ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.3 Les différents types d’indicateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.3.1 Fonction Commerciale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.3.2 Fonction Direction générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.3.3 Fonction Ressources humaines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.3.4 Fonction Production et recherche – développement . . . . . . . . . . . . . . . . . . . . . . . . 38
2.3.5 Fonction Logistique et approvisionnements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.3.6 Fonction Achats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.3.7 Fonction Informatique – Études – Exploitation . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.4 Deux mondes différents : OLTP et DW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.4.1 Qu’est-ce qu’une transaction ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.4.2 Les utilisateurs et les gestionnaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.4.3 La dimension temporelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.4.4 Le modèle de données entité-relation pour les développeurs . . . . . . . . . . . . . . . . . . 45
2.4.5 Le modèle dimensionnel pour les analystes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.5 Comparatif des deux modèles de stockage des données . . . . . . . . . . . . . . . . . . . . . . 49
2.5.1 Le modèle transactionnel (OLTP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.5.2 Le modèle multidimensionnel (OLAP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
2.5.3 Synthèse OLTP et OLAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
2.5.4 Modèle simplifié FASMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.6 OLAP ou reporting ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.7 Le processus décisionnel avec SQL server 2008. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
2.8 Les erreurs à éviter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
2.8.1 Le facteur Humain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
2.8.2 Le facteur Technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
2.9 Les règles du succès . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
2.9.1 Règle 1 – Comprendre les utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
2.9.2 Règle 2 – Distinguer les décisions stratégiques ou tactiques . . . . . . . . . . . . . . . . . . 62
2.10 Construire le tableau matriciel des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Chapitre 3 – Comment représenter les données ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

3.1 Concepts généraux et pratiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.1.1 Tableaux ou graphiques ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Table des matières VII
3.1.2 Données quantitatives ou catégorielles ?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

3.2 Les nouveaux outils offerts par le complément proclarity . . . . . . . . . . . . . . . . . . . . 77
3.2.1 L’ arbre de décomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
3.2.2 La carte de performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
3.2.3 La vue en perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Chapitre 4 – Entrepôt de données et analyse décisionnelle . . . . . . . . . . . . . . . . . . . . . . 81

4.1 Architecture de la plate-forme décisionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.2 Comment simplifier le monde réel ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.2.1 Actuellement, comment développons-nous un projet BI ? . . . . . . . . . . . . . . . . . . . 86
4.2.2 Quels sont les défis à relever ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Chapitre 5 – Introduction à Integration Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

5.1 Présentation de SQL Server Integration Services (SSIS) . . . . . . . . . . . . . . . . . . . . 89
5.2 Migrer une base SQL Server 2000 vers SQL Server 2008 . . . . . . . . . . . . . . . . . . . . 97
5.3 Tâches d’intégration services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.3.1 Tâches des éléments de flux de contrôle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.3.2 Tâches du plan de maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
5.4 Composants flux de données (ETL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
5.4.1 Sources des flux de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
5.4.2 Transformations du flux de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
5.4.3 Destinations du flux de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Chapitre 6 – Les assistants de l’ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

6.1 Utiliser l’assistant pour générer un lot import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
6.1.1 Créer le projet d’importation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
6.1.2 Exécuter le lot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
6.1.3 Modifier le lot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
6.1.4 Migration de lots DTS de la version 2000 vers 2008 . . . . . . . . . . . . . . . . . . . . . . . 150
6.1.5 Déploiement de packages SSIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
6.1.6 Automatisation de l’exécution des packages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
6.1.7 Assistant de mise à niveau des packages SSIS 2005 vers 2008 . . . . . . . . . . . . . . . 156
6.2 Concept de packages dynamiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
6.2.1 Les expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
VIII Business Intelligence avec SQL Server 2008
6.2.2 Les variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

6.2.3 Les configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
6.2.4 La gestion des événements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
6.3 Planification du projet ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
6.4 Les 38 règles qui régissent l’ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Chapitre 7 – Analysis Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

7.1 OLAP et le data mining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
7.2 Composants d’Analysis Services 2008 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
7.3 Méthodologie de création d’une base de données depuis une source existante . 178
7.4 Création de notre premier cube . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
7.4.1 Constat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
7.4.2 Mesures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
7.4.3 Dimensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
7.4.4 Le schéma en flocons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
7.4.5 Créer le projet « Mon Premier Cube » à l’aide de l’environnement UDM
d’Analysis Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
7.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Chapitre 8 – Méthode de conception des cubes avec SSAS . . . . . . . . . . . . . . . . . . . . . 231

8.1 Organisation logique des cubes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
8.1.1 Définition de la structure OLAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
8.1.2 Définir les dimensions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
8.1.3 Modification du cube . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
8.1.4 L’utilisation des dimensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
8.1.5 Les calculs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
8.1.6 Ajouter de la Business Intelligence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
8.1.7 Les indicateurs clé de performance (KPI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
8.1.8 Les actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
8.1.9 Les perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
8.1.10 Les traductions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
8.1.11 Le navigateur de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
8.2 L’organisation physique du cube . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
8.2.1 Les groupes de mesures et les partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Table des matières IX
8.2.2 Les différents modes de stockage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

8.2.3 Comment SSAS rafraîchit-il les données du cube ? . . . . . . . . . . . . . . . . . . . . . . . . 253
8.2.4 Paramétrer les agrégations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
8.2.5 Processus de mise à jour des cubes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
8.2.6 Où sont stockées les données du cube et comment optimiser le stockage ? . . . . . . 257
8.3 Recommandations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
Chapitre 9 – Le data mining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263

9.1 Méthodologie de création du modèle de data mining . . . . . . . . . . . . . . . . . . . . . . . 264
9.1.1 Définition du problème à résoudre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
9.1.2 Préparation des données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
9.1.3 Construction du schéma de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
9.1.4 Création du modèle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
9.1.5 Exploration du modèle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
9.1.6 Validation du modèle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
9.1.7 Déploiement du modèle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
9.2 Quelles sont les tâches du data mining ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
9.3 Créer le modèle d’une campagne ciblée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
9.3.1 Créer la source des données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
9.3.2 Créer la vue de source des données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
9.3.3 Créer le modèle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
9.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
Chapitre 10 – Reporting Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289

10.1 Qu’est-ce que Reporting Services ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
10.1.1 À quoi sert Reporting Services ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
10.1.2 Fonctionnalités de Reporting Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
10.2 Anatomie d’un rapport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
10.3 La gestion des rapports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
10.3.1 La sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
10.3.2 Les rapports liés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
10.3.3 L’exécution de rapports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
10.3.4 L’historisation des rapports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
10.3.5 Abonnements aux rapports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
X Business Intelligence avec SQL Server 2008
10.4 Reporting à la demande avec Report Builder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326

10.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Chapitre 11 – L’ analyse de données avec Excel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333

11.1 L’ analyse ad hoc grâce aux tableaux croisés dynamiques . . . . . . . . . . . . . . . . . . . . . 334
11.2 Complément Microsoft Office Excel pour SQL Server Analysis Services . . . . . . 342
11.3 Reporting interactif sur le web avec OWC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
11.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
Chapitre 12 – L’analyse de données sur le Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351

12.1 Proclarity for Business Scorecard Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
12.1.1 L’arbre de décomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
12.1.2 La carte de performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
12.1.3 La vue en perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
12.2 Proclarity Analytics Server (PAS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
12.3 Dashboard Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
12.4 SharePoint portal server et performancepoint server 2007 . . . . . . . . . . . . . . . . . . . 362
12.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
Chapitre 13 – Passez à l’action ! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371

13.1 Les caractéristiques du chef de projet décisionnel . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
13.1.1 Être bien informé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
13.1.2 Être expérimenté . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
13.1.3 Leadership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
13.1.4 Compétences en organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
13.1.5 Compétences en communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
13.1.6 Qualités personnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
13.1.7 Apprendre des expériences passées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
13.2 Quel est le retour sur investissement ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
13.3 Faire une offre de solution décisionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
13.3.1 Un ETL d’entreprise, Integration Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
13.3.2 Un SGBD pour la gestion des gros volumes de données . . . . . . . . . . . . . . . . . . . . 380
13.3.3 Une architecture qui garantit la disponibilité des données . . . . . . . . . . . . . . . . . . . 380
Table des matières XI
13.3.4 Compatibilité, ouverture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380

13.3.5 Productivité dans le développement d’applications liées à SQL Server 2008 . . . . 381
13.3.6 Administration renforcée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
13.3.7 Sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
13.3.8 Analysis Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
13.3.9 Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
13.3.10Donner un véritable cockpit de pilotage de l’activité adapté aux différents niveaux
de l’organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
13.4 Comment mettre en place un projet décisionnel ? . . . . . . . . . . . . . . . . . . . . . . . . . . 383
13.4.1 Objectifs de la preuve de faisabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
13.4.2 Faisabilité sur site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
13.4.3 Livrables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
13.4.4 Planning pour le déploiement de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
13.4.5 Prototype/pilote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
13.4.6 Opérations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
13.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
A NNEXES
Annexe A – Petit historique de la BI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
Annexe B – Nouveautés de SQL Server 2008 par rapport a la version 2005. . . . . 395
Glossaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
Introduction
« Voudriez-vous me dire, s’il vous plaît,

quel chemin je dois prendre pour m’en aller d’ici ?
– Cela dépend beaucoup de l’endroit où tu veux aller, répondit le chat.
– Peu m’importe l’endroit... dit Alice.
– En ce cas, peu importe la route que tu prendras, répliqua-t-il.
– ...pourvu que j’arrive quelque part, ajouta Alice en guise d’explication.
Oh, tu ne manqueras pas d’arriver quelque part,
si tu marches assez longtemps. »
Alice au Pays des Merveilles – Lewis Carroll
Bien longtemps, l’informatique décisionnelle a été réservée à des secteurs d’activité
friands de reporting financiers et d’analyse marketing, tels que les banques, les
assurances et plus généralement les grands comptes. Ces organisations étaient les
seules à tirer parti d’investissements lourds aussi bien en termes d’équipes projet qu’en
termes d’infrastructures matérielles et logicielles. Le coût d’un projet décisionnel
n’était jamais inférieur à 0,5 m€ et dépassait fréquemment 1,5 m€.
Dès le début des années quatre-vingt-dix, partant du constat que les ERP (ou
progiciels de gestion intégrés, PGI) étaient dans l’incapacité de fournir des éditions et
rapports synthétiques personnalisés, de nouveaux acteurs tels que Hyperion, Business
Objects et Cognos, ont apporté une réponse en matière de restitution de l’information.
Un nouveau type d’organisation des données appelées hypercubes OLAP, et de
nouvelles interfaces ont permis aux managers d’accéder à leurs données. Cependant,
la complexité de mise en œuvre du datawarehouse et la création des cubes multidimen-
sionnels demeurait forte. Si bien qu’un certain nombre de grands éditeurs ont tenté de
développer des applications analytiques « métier ». Celles-ci ont eu tendance, comme
les ERP quelques années plus tôt, à faire entrer l’entreprise dans un schéma analytique
standard tout en faisant de nouveau exploser la facture finale.
Le véritable lifting de l’informatique décisionnelle a eu lieu en 2000, lorsque
Microsoft, qui n’était alors que challenger, rendit disponible la version SQL Server
2000. Outre le fait que l’éditeur cherchait à s’imposer sur le marché des SGBD face
à Oracle et IBM, le leader mondial des logiciels introduisait le germe de la Business
Intelligence par l’ajout d’un composant décisionnel appelé Analysis Services.
2 Business Intelligence avec SQL Server 2008
L’organe d’observation indépendant OlapReport a mesuré la progression fulgurante

de Microsoft en termes de parts de marché OLAP. Dès 2002, l’éditeur de Redmond a
pris la place de leader mondial pour ne jamais plus la quitter.
L’arrivée de SQL Server 2005, mise à disposition le 8 novembre 2005, a fait
l’effet d’un coup de tonnerre dans le monde la Business Intelligence. Cette nouvelle
version intégrait déjà les développements les plus récents en matière de Business
Intelligence. Les développeurs et administrateurs de bases de données ont été entendus
et disposaient déjà d’outils complets à tous les niveaux de la fabrication de la chaîne
de valeur de l’information.
Le 3 octobre 2008, Microsoft mettait à disposition une nouvelle version de son
SGBD phare. SQL Server 2008 apportait son lot d’innovations aussi bien dans le
moteur SQL que dans les outils BI.
Les nombreuses formations que nous avons assurées depuis 2005 ainsi que les
missions de consulting ont montré la forte pénétration des nouveaux outils de Business
Intelligence non seulement auprès de Grands Comptes mais également auprès des
PME. Pendant cette période nous avons observé un mouvement qui visait à effectuer
de nombreuses migrations d’applications BI vers les outils Microsoft.
L’éditeur de Redmond était-il à l’origine de ces nombreuses acquisitions observées
dans le domaine des concepteurs de solutions de Gestions de la Performance ?
En mars 2007, Oracle annonce le rachat d’Hypérion pour 3,3 milliards de dollars.
En mai 2007, SAP rachète Outlooksoft pour 200 millions de dollars puis lance
une OPA amicale sur Business Object pour une valeur de 6,7 milliards de dollars. BO
venait à peine de terminer son acquisition de Cartesis.
En novembre 2007, c’est au tour d’IBM de procéder à l’acquisition du Canadien
Cognos pour 5 M$. Ce dernier venait de fusionner avec Applix le leader de l’analyse
financière.
Malgré tous ces rachats, et selon le Gartner, Microsoft conserve sa position de
référence. La plate-forme de Business Intelligence compte parmi les « leaders » aux
côtés de Cognos et BO, Oracle, SAS et Microstrategy. (Figure 1)
Microsoft avait développé son propre outil de performance par le rachat de sociétés
diverses telles que Proclarity. Performance Point Server 2007 Monitoring, Analytics
et Planning) devait s’imposer comme l’outil de gestion de la performance.
Bill Baker, directeur général BI annonçait qu’à partir d’avril 2009 Performan-
cePoint server 2007 serait dorénavant intégré à Sharepoint server Enterprise (14)
annoncé pour le premier semestre 2010.
Selon Lionel Billon (chef de produit SQL Server chez Microsoft France) Microsoft
prépare de « nouvelles technologies d’analyse décisionnelle « en libre-service » » et « des
capacités améliorées en référentiels de données pour les grandes entreprises » permettant de
« généraliser l’usage de l’analyse décisionnelle à tous les employés ».
Ces nouvelles fonctions d’« analyse en libre-service », connues sous le nom de
code « Projet Gemini », constituent l’un des points importants du futur SQL Server
dit « Kilimanjaro ». Il sera largement dédié à l’analyse décisionnelle.
Introduction 3
Figure 1 — Magic Quadrant for Business Intelligence Platforms (Source Gartner)
En parallèle, Microsoft proposera aussi un référentiel de données présentant des

fonctionnalités évoluées, sous le nom de code « Madison ».
« Ces nouveaux outils permettront aux entreprises d’étendre les avantages de l’analyse
décisionnelle à un large panel d’employés, sans nécessiter une intervention lourde des services
informatiques ».
Il s’agit de « transformer la façon d’utiliser l’analyse décisionnelle dans les entreprises,
grâce à la mise en place d’outils familiers et intuitifs ; chacun pourra ainsi accéder à la
puissance et aux avantages de l’analyse décisionnelle (...) Si vous savez utiliser Word
et Excel, vous serez capable d’utiliser notre solution d’analyse décisionnelle. C’est notre
engagement envers les clients. »
Après une "version préliminaire", via une version CTP (Community Technology
Preview), prévue fin 2009, le géant de Redmond devrait présenter une version
définitive au cours du premier semestre de 2010.
Après que l’informatique ait engendré inutilement de la complexité et son cortège
d’Experts assurés de missions longues et rémunératrices, Microsoft semble vouloir
fournir une technologie au service de l’utilisateur.
Par temps de crise, les entreprises sont devenues moins dispendieuses et l’expé-
rience acquise depuis des années a apporté aux dirigeants son lot de réalisme. À
qualité égale, le coût est devenu un critère majeur. La simplicité de mise en œuvre et
d’intégration des couches technologiques a aujourd’hui toute son importance.
Gageons que Microsoft, avec sa solution SQL Server 2008 intégrant nativement la
Business Intelligence trouvera une nouvelle fois un écho favorable auprès d’un public
exigeant.
Cet ouvrage a pour ambition d’offrir une vision méthodologique de la fabrication
de la chaîne décisionnelle, un état de l’art des outils disponibles, ainsi qu’un mode
opératoire permettant de réaliser vous-même le déploiement de fonctions de Business
Intelligence au service du métier de votre entreprise.
Public concerné
La Business Intelligence en tant qu’outil de pilotage s’adresse essentiellement aux
décideurs confrontés chaque jour à des choix stratégiques et tactiques dans leur
entreprise. Il est donc bien naturel que les dirigeants (direction générale et directions
opérationnelles) disposent d’un langage commun partagé avec les techniciens de
l’information. Cet ouvrage leur est particulièrement destiné car il présente une
méthodologie de valorisation de l’information à des fins stratégiques.
Les contrôleurs de gestion, directions financières, commerciales, marketing, res-
sources humaines, production verront les aides que peut apporter la Business Intelli-
gence à leurs tâches quotidiennes.
Les directeurs informatiques, responsables informatiques et bureautiques, disposeront
d’une méthode de mise en œuvre de la chaîne décisionnelle au service des acteurs
opérationnels de l’entreprise.
Les consultants, architectes et urbanistes en systèmes d’information, assistants à
maîtrise d’ouvrage, chef de projet informatique, étudiants en informatique de gestion
disposeront d’un outil méthodologique basé sur des cas concrets d’entreprise. Ils
disposeront d’une panoplie d’outils leur permettant de réaliser rapidement des projets
décisionnels.
Les SSII soucieuses d’apporter des prestations nouvelles à leurs clients, les orga-
nismes de formation, les sociétés de VPC, les hébergeurs d’applications sur Internet,
les banques et assurances, les sociétés de service, les sociétés fiduciaires, les sociétés
industrielles quelle que soit leur taille découvriront avec intérêt le potentiel de la
Business Intelligence.
Objectifs à atteindre
L’objectif de cet ouvrage est de fournir aux dirigeants la culture nécessaire à la
compréhension des méthodes et outils nécessaires à la mise en œuvre du tableau de
bord de l’entreprise. Il permet également de comprendre les mécanismes sous-jacents
qui participent à la fabrication de la chaîne décisionnelle. L’informatique décisionnelle
se fonde sur des concepts spécifiques et un vocabulaire approprié détaillés en annexe.
Introduction 5
Il a également pour objectif d’aider à définir les étapes clés d’un projet décisionnel,
identifier les processus métier, modéliser les données métier, identifier les outils qui
participent à la conception du datawarehouse, comprendre les outils d’analyse et de
restitution. Communiquer avec ses partenaires grâce à un portail décisionnel.
Quelles sont les qualités et compétences requises pour être un bon chef de projet
décisionnel ? Calculer le retour sur investissement et faire une offre concrète sont
souvent évoqués dans la littérature décisionnelle mais rarement explicités.
L’auteur de cet ouvrage espère participer au mouvement de la démocratisation du
décisionnel dans les petites et moyennes entreprises. Les séminaires de formation
qu’il anime sur le sujet montrent bien l’intérêt croissant que tous les acteurs de
l’entreprise portent à ce domaine. L’auteur espère qu’à travers cet ouvrage, un dialogue
constructif s’établira entre les deux mondes, parfois éloignés, qu’il rencontre dans ses
consultations : les informaticiens et les managers d’entreprise.
1
La Business Intelligence
1.1 LA BUSINESS INTELLIGENCE POUR QUI,

POUR QUOI ?
Que signifie le terme « intelligence » ?

Le Petit Larousse donne la définition suivante : « faculté de connaître, de com-
prendre ».
Et l’expression « Business Intelligence » ?

Wikipedia (encyclopédie libre sur le net) donne la définition suivante de la Business
Intelligence (ou informatique décisionnelle) :
« L’ informatique décisionnelle (DSS, Decision Support System ou encore BI,
Business Intelligence) désigne les moyens, les outils et les méthodes qui permettent
de collecter, consolider, modéliser et restituer les données d’une entreprise en vue
d’offrir une aide à la décision et de permettre aux responsables de la stratégie d’une
entreprise d’avoir une vue d’ensemble de l’activité traitée. »
Aide à la décision, Datawarehouses, entrepôts de données, ETL, EIS, SIAD,
structures multidimensionnelles OLAP, Business Intelligence, extranets, portails déci-
sionnels, datamarts... les acronymes et termes relatifs à la Business Intelligence sont
particulièrement riches. Mais ces termes abondants, parfois abscons, qui reviennent
de manière récurrente dans la bouche des spécialistes, ne permettent pas d’offrir aux
acteurs de l’entreprise une vision claire sur le sujet.
D’un côté, les discours marketing centrés sur la BI s’adressent à la population
parfaitement identifiée des dirigeants opérationnels des entreprises. Il s’agit d’offrir
des solutions particulièrement innovantes autour du métier du dirigeant. Nous verrons
8 Chapitre 1. La Business Intelligence
dans le chapitre suivant le large éventail des domaines dans lesquels la BI offre des
réponses concrètes.
De l’autre côté les éditeurs de logiciels de BI s’adressent aux informaticiens dans le
but bien naturel de réaliser des volumes importants de licences. Le discours est dans
ce cas très technique et s’attache à mettre en avant les performances, la simplification
et la richesse des fonctionnalités des produits.
Entre ces deux mondes, il réside un fossé d’incompréhension. Pourquoi ? Les
dirigeants opérationnels (finance, marketing, commercial, RH...) ont un besoin crucial
d’informations concernant le déroulement de leur activité. Ils réclament régulièrement
des rapports nouveaux auprès des informaticiens dans le but de satisfaire des besoins
d’analyse de l’activité immédiate de l’entreprise. Dans le meilleur des cas, un délai
de quelques jours sera nécessaire aux programmeurs pour délivrer lesdits rapports.
Dans le pire des cas ces développements ne verront jamais le jour soit de par la
« complexité apparente » de la demande, soit tout simplement par la non-disponibilité
des développeurs, très chargés par ailleurs.
En réalité, on s’aperçoit que les métiers de l’informatique évoluent vers des tâches
d’administration de systèmes d’information de plus en plus complexes, qui nécessitent
tous les jours davantage de soins et d’attention, sans parler de la sécurité omniprésente.
Paradoxalement, l’informaticien est de plus en plus au service de la machine et de
moins en moins au service du métier de l’entreprise.
Malgré des réussites évidentes, le déploiement des ERP (progiciels de gestion
intégrée) a nécessité des ressources importantes dans les entreprises qui les ont
mis en place. Des équipes de projet se sont bien souvent épuisées à faire entrer le
métier de l’entreprise dans des standards. Tout naturellement, les entreprises ont donc
« standardisé » leur métier. Elles cherchent aujourd’hui, à juste titre, des facteurs de
différenciation.
La Business Intelligence est un système permettant aux dirigeants d’analyser et
d’interpréter, à l’aide d’outils simples, les données complexes de l’entreprise et de son
environnement économique.
Les données brutes sont transformées et restituées dans des entrepôts structurés,
afin de permettre d’analyser et de suivre les indicateurs stratégiques de l’entreprise.
Ces outils doivent permettre de découvrir et de partager la stratégie à tous les niveaux
de l’entreprise. Grâce à ses outils « multidimensionnels » la BI est particulièrement
adaptée à l’analyse immédiate. Elle offre la capacité de suivre au quotidien les
indicateurs métiers et de les comparer aux objectifs opérationnels définis par la
direction.
Bien sûr, le discours marketing ambiant tente de démontrer qu’il suffit d’acquérir
tel ou tel produit décisionnel pour que la magie opère. Comme on dit communément,
« si c’était aussi simple ça se saurait ». À quoi serviraient alors les SSII, les intégrateurs
et les consultants spécialisés en systèmes décisionnels ? Seraient-ils devenus inutiles
parce que les éditeurs ont mis en place des assistants visant à simplifier le processus de
création de la chaîne décisionnelle ? Rien n’est moins sûr.
1.2 Objectifs et enjeux du décisionnel 9
Nous verrons au fil de cet ouvrage les pièges qu’il est nécessaire de connaître avant
d’entreprendre un projet BI. Nous découvrirons que la phase la plus délicate de la
chaîne décisionnelle ne réside ni dans la conception du cube, ni dans la restitution.
Nous verrons également qu’un cadre méthodologique est nécessaire à la création de
l’entrepôt de données, centre névralgique des applications décisionnelles.
Toute interrogation métier, selon qu’elle est stratégique ou tactique, nécessite des
outils appropriés qu’il faut identifier dans la panoplie offerte par les éditeurs de logiciels.
Nous verrons quels processus se mettent en place lors de la prise de décision. Nous
montrerons comment, grâce à des outils appropriés, être tantôt l’architecte du projet,
tantôt le « consommateur » de l’information. Chaque rôle, très complémentaire, revêt
une importance capitale dans la mise en œuvre de la BI en entreprise.
1.2 OBJECTIFS ET ENJEUX DU DÉCISIONNEL

L’objectif d’un système décisionnel est de :
• connaître ;
• mesurer ;
• prévoir ;
• agir.
Les moyens pour y parvenir sont :

• une information riche, pertinente, détaillée, historisée, fiable ;
• des outils d’analyse et de restitution puissants et adaptés ;
• des indicateurs qui favorisent le pilotage et favorisent l’action.
Le cycle du projet comprend plusieurs étapes :

• Sélectionner les axes de progrès.
• Sélectionner le ou les processus à analyser.
• Définir les objectifs.
• Définir les indicateurs.
• Bâtir le portail décisionnel.
1.3 LE PROCESSUS DE DÉCISION OU LE FACTEUR

HUMAIN DANS LA PRISE DE DÉCISION
Dans un contexte d’inflation des données d’entreprises, plusieurs technologies récentes
arrivent à point nommé pour répondre concrètement à l’augmentation des besoins
d’analyse et de prise de décisions émis par les dirigeants opérationnels.
Parmi ces innovations, il en est une qui offre la plus grande avancée en matière
d’aide à la décision. La technologie OLAP (On Line Analytical Processing) qui pendant
quelques années a servi de niche technologique à certains éditeurs bien connus,

vient de faire un progrès remarquable du fait de l’amélioration des performances des
ordinateurs et de la découverte de nouveaux algorithmes. OLAP représente l’avancée
la plus spectaculaire en matière de Business Intelligence depuis la découverte des bases
de données relationnelles, dont les fondements ont été établis par Chris Date et Edgar
Codd en 1993.
Bien que de nombreux articles aient été publiés décrivant le fonctionnement des
technologies OLAP, très peu ont mis en avant « quand » et « comment » utiliser ces
technologies dans le cadre de l’aide à la décision.
Dans ce chapitre, nous mettrons en évidence les deux volets de la prise de décision :
le volet quelque peu mécaniste de la création d’information à partir des données de
base et le volet humain, qui permettra de découvrir LA bonne information.
Divers outils de reporting basés sur les bases de données relationnelles existent
et sont largement utilisés dans les entreprises. Les tableurs sont également des outils
désormais banalisés. Bien que demeurant déconnectés des systèmes centraux, ils sont
devenus indispensables aux financiers et contrôleurs de gestion dans des tâches
quotidiennes de collecte d’informations et de consolidation.
Mais quel que soit le soin apporté à la gestion de ces données, leur restitution
ne représente qu’une partie de la prise de décision. L’autre partie, à nos yeux
la plus importante, est de savoir comment les décisionnaires « consomment » les
informations, les comprennent et agissent enfin.
1.3.1 Comprendre les besoins d’aide à la décision

Une étude récente du Forester Research montre que 66 % des utilisateurs de rapports
sont insatisfaits. Les programmeurs qui développent ces rapports expriment également
leurs frustrations en ces termes :
• « Nous apportons aux utilisateurs ce qu’ils demandent mais ces derniers ne sont
toujours pas satisfaits. »
• « Les utilisateurs ne savent pas ce qu’ils veulent. Ils changent souvent d’avis. »
• « Nos données posent problème mais nous n’y pouvons rien. »
• « Nous avons construit l’entrepôt de données, mais il ne semble pas que les
utilisateurs s’en servent. »
• « Nous avons beaucoup investi dans le stockage des données, cependant chacun
semble encore disposer de ses propres chiffres et de sa propre vérité. »
Ces commentaires suggèrent que les technologies actuelles sont inadéquates dans
le cadre de l’aide à la décision. Cependant, ces réflexions nous aident à comprendre la
complexité et la nature des attentes des utilisateurs.
1.3 Le processus de décision ou le facteur humain dans la prise de décision 11
1.3.2 Agir, analyser, décider, agir...

Utiliser des données dans le but de prendre des décisions pertinentes représente la part
humaine du processus de décision. Ce processus débute lors de la mise à disposition
des données auprès du décisionnaire jusqu’à la décision finale.
Toute action dans l’entreprise implique d’en conserver la trace. Les systèmes ERP
(PGI) enregistrent chaque seconde les opérations élémentaires (factures, achats,
commandes, clients...). Une action dont la trace est conservée dans des journaux
(log) ressort du domaine transactionnel.
Les décideurs observent comment vont les choses afin de confronter leur stratégie à
la réalité. Ils cherchent à découvrir les faits qui expliquent la marche de l’entreprise. Ils
élaborent une modélisation de causes à effets. Ils en déduisent les décisions à prendre.
Le domaine analytique permet de passer de l’analyse à la décision.
Figure 1.1 — Le cycle décisionnel dans l’entreprise
La compréhension du mode de consommation des informations et de la façon dont

les acteurs de l’entreprise prennent leur décision est la clé nécessaire à la mise en place
de solutions d’aide à la décision.
Généralement, le processus de prise de décision requiert les compétences d’une
personne ayant une vision claire des données afin d’en tirer pleinement du sens, d’en
comprendre les causes, et de prendre les décisions et les actions qui s’imposent. Par
ailleurs, on peut identifier trois concepts fondamentaux qui influent sur la prise de
décision : le référentiel métier, le niveau d’abstraction et le processus d’apprentissage.
La mise en place du référentiel métier

Le référentiel métier apporte la signification et la pertinence des données. Il transforme
des données brutes en informations utiles aux décisionnaires, par l’ajout de calculs, de
sélections complémentaires, de regroupements et de présentation. Un fichier rempli
de nombres est sans intérêt tant qu’il n’a pas été transformé en tendances, ratios
financiers ou taux de pénétration de marché.
Le référentiel d’une organisation représente le composant essentiel de sa propriété
intellectuelle et de son avantage compétitif. La compréhension et l’interprétation
sont basées non seulement sur les données mais aussi sur la manière dont les données
sont transformées en une information porteuse de sens. Par exemple, une tendance à
la baisse du taux de pénétration peut conduire à un changement dans la distribution
des produits ou de nouvelles campagnes promotionnelles dans les différents canaux de
vente.
La manière dont le référentiel métier est géré dans un système d’aide à la décision
détermine sa mise en valeur auprès des décisionnaires et est déterminante pour
leur productivité. En effet, dans l’entreprise, le référentiel métier est-il facilement
accessible ? Est-il centralisé sur un serveur partagé ou bien stocké localement dans des
tableaux Excel ? Est-il correctement géré et maintenu à jour ? Un puissant référentiel
métier largement accessible et facile à utiliser offre une forte valeur ajoutée aux
décisionnaires.
Les niveaux d’abstraction

Le niveau d’abstraction permet aux utilisateurs de résoudre des problèmes dans un
contexte propre au métier pratiqué. Par exemple, un administrateur de bases de
données manipule des objets à fort niveau d’abstraction que sont les tables, les
colonnes les jointures et les index. Parallèlement, dans la même organisation, les
dirigeant traitent des allocations de ressources, de productivité, de satisfaction clients,
de lignes de produits ou de périodes fiscales. Bien que la matière brute représentée
par les données soit naturellement la même pour ces deux acteurs, celles-ci sont
manipulées et interprétées de façon différente.
Le bon niveau d’abstraction de manipulation des données est fondamental pour la
prise de décision. La réflexion des cadres dans le domaine des ventes se concentrera
autour des régions, des quotas, des commissions et de la productivité de l’équipe.
Les cadres financiers vont manipuler des notions telles que commandes, chiffre
d’affaire, marge et retour sur investissement. Aucun de ces acteurs ne s’attend à devoir
manipuler des requêtes, des colonnes ou des agrégats.
Le processus d’apprentissage
Lorsque les données sont organisées en référentiel métier et présentés au niveau
d’abstraction adéquat, les décisionnaires peuvent alors les utiliser et les comprendre. Le
processus d’apprentissage implique des réflexions itératives de la part du décisionnaire.
Celles-ci se matérialisent par des requêtes successives dont les réponses engendrent
naturellement de nouvelles questions.
De manière similaire, nous pouvons attribuer le succès sans précédent du Web par
l’application de ces trois principes : organisation, navigation et visualisation. Pour trouver
une information sur un DVD, nous tapons ces deux mots « DVD NomDuChanteur »
dans un moteur de recherche. Ce dernier propose plusieurs sites commerciaux. Nous
pouvons facilement comparer, naviguer, approfondir notre recherche en cliquant sur
des hyperliens.
Le second point repose sur le fait que le processus d’apprentissage est rarement
linéaire. Le Web est particulièrement adapté à ce mode de fonctionnement. Les
hyperliens nous permettent de passer d’un sujet à un autre. Les boutons de retour en
arrière du navigateur permettent de revoir toutes les étapes du cheminement. Cette
approche est particulièrement efficace lors d’une découverte non structurée.
Enfin, la visualisation enrichie du Web présente une information dans sa forme la
plus compréhensible. Des images animées, des graphiques pour exprimer des tendances,
des tableaux pour comparer, etc. Tous ces modes de représentation, exprimés selon
une organisation intuitive et flexible, font du Web une des inventions les plus efficaces
qui soit dans le domaine de l’information.
1.3.3 Tableau de bord et business intelligence

Le cockpit
Si vous vous êtes déjà trouvé sur un vol long courrier, vous n’avez pas pu échapper à
ces écrans qui vous permettent de suivre en temps réel votre parcours, reproduisant de
manière fidèle la position de votre avion et du chemin déjà parcouru.
De quoi s’agit-il ? L’écran qui servira plus tard à divertir le voyageur, affiche à
chaque instant la position de l’avion par rapport aux villes survolées, laissant une
trace du chemin déjà réalisé. Au fur et à mesure de la progression du vol, des vues
différentes permettent d’observer le chemin parcouru, le chemin qui reste à parcourir
et l’orientation que prend l’avion.
Lorsque nous observons ces images, nous n’avons pas idée de la masse de données
qu’il est nécessaire de collecter dans le but de restituer sur l’écran une vue compré-
hensible par le voyageur. Et lorsque l’écran s’éteint, nous nous trouvons subitement
plongés dans l’inconnu. On ne peut alors que faire des suppositions sur l’identification
de la région survolée.
Maintenant, le commandant de bord vous invite à pénétrer dans le cockpit
de l’avion afin de vous faire découvrir le tableau de bord de pilotage mis à sa
disposition. Après quelques explications simples des écrans d’affichage, vous découvrez
la signification des différentes jauges et autres voyants lumineux.
Progressivement, vous vous familiarisez avec les indicateurs tels que position (lati-
tude, longitude), altitude, vitesse, consommation de kérosène, température extérieure,
etc. Les cadrans donnent un ensemble d’informations qui situent précisément l’aéronef
dans son environnement géographique en trois dimensions.
Concentré sur son tableau de bord, le copilote actionne un levier qui permet à
l’avion de corriger imperceptiblement sa trajectoire puis de se stabiliser à nouveau.
Figure 1.2 — Dans le cockpit : suivre le plan de vol
Les voyants affichent immédiatement de nouvelles données reflétant la nouvelle

orientation de l’avion. La trace est aussitôt perceptible dans la cabine pour l’ensemble
des passagers.
Quel parallèle avec la Business Intelligence ?

Le plan de vol (départ Roissy, arrivée Los Angeles 11 heures plus tard) représente le
plan de vol à suivre afin de mener l’avion à bon port dans le délai convenu d’avance.
En Business Intelligence, nous parlerons de la stratégie de l’entreprise.
La trace que laisse l’avion sur l’écran matérialise la collecte de données de
positionnement et de progression de l’avion. Ces données sont naturellement stockées
dans la boîte noire de l’appareil. La mémoire du vol est ainsi historisée dans ce dispositif
ultra-sécurisé, pouvant résister aux chocs les plus violents. L’ensemble des voyageurs
visualise en cabine ces informations de positionnement grâce à l’écran GPS.
En Business Intelligence, nous parlerons de processus ETL (Extract, Transforming,
Loading) qui représente le mécanisme d’alimentation et de stockage des données de
l’entreprise dans un entrepôt centralisé (datawarehouse). L’entreprise structure ses
données éparses, les rend homogènes, les stocke et les délivre.
Les indicateurs de vol fournis au copilote grâce aux différents cadrans mis à sa
disposition forment son espace d’analyse, qui vise à suivre la progression de l’avion.
En Business Intelligence, nous disposerons de manière similaire d’outils de visuali-
sation des indicateurs de performance sous forme de reporting, d’analyse multidimen-
sionnelle et de data mining (découverte des causes et des effets) synthétisé dans un
tableau de bord. Il s’agit de focaliser les collaborateurs sur ce qui est important et
d’attirer leur attention en permanence.
Tour écart de trajectoire est corrigé par le pilote.
En Business Intelligence, nous parlerons d’écarts sur objectifs prévisionnels,
d’optimisation, de planning, de prévu/réalisé.
Toute décision de correction de trajectoire entraîne une action dans le poste de
pilotage.
En Business Intelligence d’entreprise, les écarts entre le prévu et le réalisé vont
engendrer des actions correctives.
Des indicateurs externes à l’avion (radar détectant la présence d’un autre avion à
proximité, perturbations atmosphériques prévisibles sur carte météo, fortes turbulences
en vue), vont amener le pilote à changer de trajectoire...
L’atterrissage est maintenant proche, le pilote s’apprête à agir sur la trajectoire et
l’altitude.
En Business Intelligence, la direction générale s’apprêtera à agir par la mise en
place d’actions opérationnelles. Dans l’entreprise, cela peut entraîner des changements
de comportements pour atteindre les objectifs.
Voici synthétisé le modèle du processus de prise de décision transposé à l’entreprise.
Figure 1.3 — Les étapes de la prise de décision dans l’entreprise
1.3.4 En quoi la BI est-elle utile à l’entreprise ?

De la donnée brute à l’information
Selon l’enquête de PricewaterhouseCoopers réalisée en 2001, « les sociétés qui
utilisent leurs données en tant que ressource stratégique et investissent dans leur
qualité, en tirent déjà un avantage en terme de réputation et de profitabilité ». Selon

une vision traditionnelle, les données sont le « carburant » qui pilote les processus,
étant entendu que l’entreprise utilise l’ordinateur pour l’aider à réaliser son business.
La connaissance stratégique est déduite de la vision prospective, elle-même basée sur
les données de l’entreprise.
Interrogeons-nous un instant : Une chaîne de supermarché a-t-elle pour objet
de vendre de la nourriture ou bien son activité ne consiste-t-elle pas à exploiter
la connaissance des préférences du client, de son positionnement géographique, de
la logistique et des coûts d’approvisionnement ? Le cycle de vie des produits, des
informations sur la concurrence, le niveau d’inventaire, le prix proposé et la disposition
du produit en rayon ne doivent-ils pas être considérés comme autant d’informations
pour accroître la marge réalisée sur chaque article vendu ?
À l’ère de l’Information, la réponse que vous ferez à ces questions déterminera la
viabilité à long terme de votre entreprise.
Très bien me direz-vous ! Mais comment transformer les données en ressource
stratégique ? Une partie de la réponse réside dans l’application adéquate des nouvelles
technologies sur vos données. Mais la plus grande part de la réponse consiste à
comprendre et de manière subséquente à construire son business autour de la valeur de
l’information. On le voit bien, cet exercice d’abstraction est particulièrement délicat,
aussi nous observerons dans ce chapitre la différence fondamentale qui réside entre
une approche traditionnelle basée sur une technologie transactionnelle à des fins
de reporting et une vision moderne de l’utilisation des données à des fins d’analyse
prospective.
Nous introduirons la notion du dirigeant « sachant ». En effet, celui-ci base son
observation sur les faits, c’est-à-dire les données stockées dans l’entreprise. Nous abor-
derons les aspects de l’information qui révèlent de la valeur et quels sont les processus à
mettre en place afin d’extraire cette valeur des données. Nous présenterons également
quelques applications de Business Intelligence afin d’illustrer la méthodologie proposée
dans cet ouvrage.
Les atouts de l’information et l’évaluation des données

Les données peuvent-elles être considérées comme un actif ?
Bien que personne n’ait jamais observé dans un bilan de société la moindre ligne
concernant les données de l’entreprise, ni du côté de l’actif, ni du passif, il convient
de considérer cependant que certains coûts associés à la gestion des données – le coût
de stockage, la maintenance, la surface utilisée, l’équipe, etc. – apparaissent bien au
compte d’exploitation comme des charges réelles.
En contrepartie, les données doivent être considérées comme de l’actif, parce que
celles-ci sont employées à générer des bénéfices, sont contrôlées par l’organisation, et
sont le résultat de transactions liées à l’activité de l’entreprise (soit parce qu’elles sont
générées en interne, soit parce qu’elles ont été acquises à l’extérieur).
Traiter des données comme un actif représente un intérêt pour l’entreprise car cela
peut être de nature à justifier un investissement en Business Intelligence. L’entreprise
sera en mesure de montrer comment la valeur d’actif des données s’est enrichie.
Cela implique naturellement de pouvoir mesurer la valeur des données, et c’est bien
là que nous bloquons dans notre réflexion.
Il existe cependant des cas concrets où nous pouvons attribuer précisément
une valeur à l’information. Prenons par exemple le cas d’une demande au service
des renseignements téléphoniques dont le coût est, par exemple, de 1 euro alors
que l’information demandée peut être obtenue gratuitement grâce à un annuaire
téléphonique sur internet. Le coût de la transaction accepté par le client est cependant
justifié par un service immédiat. Quel que soit l’endroit où il se trouve, et le moment
de son choix, le demandeur obtient l’information capitale.
D’une manière générale, la valeur de l’information dépend d’un certain nombre de
facteurs que nous évoquerons. Il est intéressant de constater que plus nous pouvons
préciser ces facteurs et plus nous sommes en mesure d’élaborer le modèle d’évaluation
de l’information.
La valeur « temps » des données

Afin d’illustrer la contrepartie monétaire de la valeur « temps », prenons un exemple
simple. Nous sommes le 1er mars et je rencontre un « gourou » de la finance qui
m’informe que suite à un accord entre la société Alcatel et un Consortium chinois,
l’action de l’équipementier clôturera demain 2 mars, en hausse probable de 5 euros. Je
m’empresse de passer mes ordres d’achat auprès de mon broker en ligne. L’exécution de
l’ordre est immédiate. Le 2 mars peu avant la clôture, je revends mes actions et prends
mon bénéfice. Si au lieu de recevoir cette information le 1er j’en prends connaissance
le 3 mars, inutile de dire que l’action à mener serait tout autre.
Cet exemple montre bien que la valeur de l’information se dégrade dans le temps.
Parce que les données stockées représentent un instantané de la situation, il paraît
évident qu’en l’absence de toute réactualisation, et parce que le monde change à tout
instant, notre « photographie » tend à devenir obsolète très rapidement.
L’information en tant que ressource partageable

Contrairement à toute autre ressource matérielle utilisée dans le processus de fabrica-
tion, les données sont des ressources qui non seulement ne s’altèrent pas mais dont la
valeur informationnelle s’accroît par l’usage d’un plus grand nombre d’utilisateurs. La
connaissance d’un tel processus s’illustre par exemple dans le cas d’un vendeur, alerté
du moment le plus opportun pour contacter un prospect. Cette connaissance peut
rationaliser le travail des vendeurs. Et même si plusieurs vendeurs partagent la même
connaissance avec d’autres membres de l’équipe, cette connaissance transmise aux
autres ne subit aucune dégradation. Cela veut dire que grâce à son partage, la valeur
de l’information est proportionnelle au nombre de personnes qui la possèdent.
Dans le contexte de la Business Intelligence, cela se traduit par le stockage des
données dans le datawarehouse. Cet entrepôt centralisé offre de nombreux accès aux
utilisateurs qui observent tous la même information. Et puisqu’elle est utilisée par
des observateurs distincts, sa valeur est multipliée par le nombre de personnes qui
l’utilisent.
Bernard Liautaud, président et PDG de Business Objects a écrit dans un ouvrage

remarquable, que « la valeur d’une information augmente avec le carré du nombre
d’utilisateurs pouvant accéder à l’information, multiplié par le nombre de services
dans lesquels ces utilisateurs travaillent ». (e-Business Intelligence, Éditions Maxima).
Valeur de l’information =
(Nombre d’utilisateurs)2 × (Nombre de départements de l’entreprise)
Cette formule est empruntée à une réflexion de Bob Metcalfe, l’inventeur de
l’Internet, qui avait formulé la loi qui porte son nom comme suit : « la valeur d’un
réseau varie en fonction du carré du nombre d’unités interconnectées ».
Il ne fait pas de doute que plus le nombre de personnes disposant de la même
information augmente, mieux elles communiquent et plus elles prennent des décisions
collectives et pertinentes.
La transversalité de l’information peut s’illustrer de la manière suivante : si je
fournis à une équipe commerciale les outils pour analyser ses ventes par produit,
par clients, par mois, par vendeur, cela constitue une arme qui sera utilisée dans
la démarche commerciale face aux clients. Cette même information transmise au
contrôleur de gestion, qui ajoutera l’indicateur du plan prévisionnel, lui fournira
immédiatement une vue complémentaire utile au pilotage.
L’accroissement de la valeur proportionnellement à son usage

Pour la plupart des actifs immobilisés, plus leur usage est fréquent, plus leur valeur
diminue. Par exemple, chaque kilomètre parcouru par une automobile diminue sa
valeur. A contrario, la valeur des données ne décroît pas lors de leur usage, car elles ne
subissent aucune dégradation lorsqu’elles sont utilisées.
Si dans l’organisation, chacun sait comment accéder à l’information et comment
l’exploiter, la valeur de cette information croît rapidement. Si les données stockées ne
sont jamais utilisées, elles n’apportent aucune valeur ajoutée et deviennent rapidement
une charge.
L’accroissement de la valeur au travers de la qualité

Si l’on reprend l’exemple de notre gourou qui, au lieu de nous prédire une hausse
de l’action, envisage au contraire une baisse probable du cours Alcatel de 5 euros, la
probabilité de réaliser une perte plutôt qu’un bénéfice devient forte.
Ceci met en évidence la valeur liée à l’exactitude de l’information et la nécessité
d’obtenir une information de haute qualité mais aussi de mettre en place les moyens
de la mesurer. Ainsi, grâce à l’interprétation de cette mesure de qualité, il sera plus
aisé de déterminer le risque associé à la prise de décision.
L’accroissement de la valeur grâce à la fusion

La combinaison des éléments de la connaissance fournit un levier puissant au fur et
mesure de l’accroissement de la valeur. Si je dispose d’informations sur mes canaux de
vente, je possède une certaine valeur. Si je possède une information sur le processus
d’approvisionnement, je dispose également d’une valeur informationnelle. Mais si je
combine ces deux informations entre elles, j’obtiens une connaissance précise sur le
mouvement des produits depuis le fournisseur jusqu’au consommateur.
Il est aisé de comprendre que la valeur de l’information s’accroît lorsqu’elle peut
être combinée avec d’autres sources d’information. Le processus de BI concerne
la capacité à collecter, agréger, et plus important encore de rapprocher plusieurs
sources entre elles. En d’autres termes, si nous pouvons rapprocher deux informations,
les lier entre elles, et en déduire quelque chose de nouveau qui n’aurait pu être
découvert autrement, nous pouvons exploiter cette découverte pour en tirer un
avantage concurrentiel.
La valeur face au volume

Contrairement au comportement de certains actifs, nous n’obtenons pas nécessai-
rement plus de valeur par l’accroissement d’information. La quantité phénoménale
d’information produite chaque année est stupéfiante. La complexité de l’intégration
des données croît proportionnellement au nombre de sources de données.
Toute la difficulté réside dans le fait de mesurer l’apport d’une source nouvelle
de données eu égard à la complexité à être intégrée dans le référentiel existant. Il
faut comprendre que chaque ajout d’une nouvelle source de données induit un mode
d’accès nouveau (connecteur). Tout nouveau connecteur implique un soin particulier
pour la mise à jour des données dans le référentiel centralisateur.
Il faut également considérer une différence importante en matière de qualité entre
l’acquisition de données provenant de sources disparates de celles qui sont puisées à la
même source. Par exemple, conserver une grande quantité de données sur les ventes
réalisées depuis plusieurs années peut apporter plus de valeur s’il s’agit d’analyser des
tendances.
La mesure de la valeur de l’information

Le coût historique : cette méthode consiste à évaluer la valeur basée sur le coût
d’acquisition de l’information ou le coût de remplacement.
La valeur marché : cette méthode évalue la valeur en fonction de ce qu’un opérateur
est susceptible de payer pour l’acquérir.
La valeur utile : cette méthode consiste à estimer la valeur en fonction du bénéfice
attendu.
Les applications de la Business Intelligence

L’analyse Client
Les termes CRM (Customer Relationship Management) et en français GRC (gestion de
la relation clients) ont été utilisés abondamment. Ils sont devenus en quelque sorte
des mots « tarte à la crème » souvent vidés de leur sens initial par des vendeurs plus
prompts à vendre des licences en grand nombre plutôt que d’écouter le besoin du
client et d’apporter une réponse adaptée.
Pour améliorer la relation client, point n’est besoin de monter une « usine à gaz ».
Le challenge consiste à mieux comprendre le client afin de lui apporter le produit ou
le service qu’il désire. On le comprend bien, il s’agit de satisfaire un client grâce à son
profil parfaitement identifié.
Les rubriques énumérées ci-dessous ont pour but d’augmenter la visibilité des
services ventes, marketing et d’une manière générale tout département qui interagit
avec le client final.
Profil Client
La plus grande partie des actions marketing consiste à « ratisser large » et à espérer
capturer le plus grand nombre de clients possibles. Après les études très détaillées
de Martha Rodgers consacrées au « marketing one to one », les entreprises prennent
de plus en plus conscience que les prospects sont différents les uns des autres et que
leur approche doit être adaptée en fonction du profil du prospect. Des informations
comportementales, préférentielles, géographiques et sociologiques concernant le
prospect permettent d’adapter individuellement le discours.
Le ciblage marketing
La connaissance des ressemblances et dissemblances permet de constituer des
ensembles de prospects ayant des comportements similaires afin d’élaborer une
communication adéquate.
La personnalisation
L’analyse fine du caddie, que ce soit au supermarché ou sur un site marchand en ligne,
permet en temps réel de connaître les produits achetés en magasin ou sur le site et d’en
déduire immédiatement des analyses fines et d’effectuer les actions qui s’imposent. À
cet égard, le navigateur web est un formidable outil de découverte de l’internaute, tant
les traces numériques laissées lors de ses recherches et hésitations sont révélatrices du
comportement de ce dernier. Le serveur web a la capacité d’interagir avec l’internaute
afin de l’aider dans sa recherche ou même de suggérer des achats complémentaires.
Les « cookies » permettent l’identification d’un individu sur un site. Lors d’un
accès ultérieur il devient possible de dialoguer intelligemment avec l’internaute et
d’agir en tant que conseil auprès de celui-ci.
Le filtrage collaboratif
Si vous êtes déjà allé sur des sites de ventes en ligne tels qu’Amazon.com ou Fnac.com,
cette notion de filtrage collaboratif ne vous a sans doute pas échappé. Lors du choix
d’un CD ou d’un livre, le site vous suggère des achats alternatifs ou complémentaires
basés sur les préférences d’autres clients. L’information affichée sur la page web est très
suggestive : « Les gens qui ont acheté le produit X ont également acheté le produit Y. »
Les processus de filtrage collaboratif évaluent la similitude des préférences entre des
groupes de consommateurs. Ces recommandations créent en général des opportunités
de cross-sell (ventes croisées) et de up-sell (ventes additionnelles).
La satisfaction du client
Un des avantages induits par le profilage est de connaître la satisfaction d’un client
par rapport à des produits ou services. Un rapide sondage permet de collecter le
niveau de satisfaction d’un client, de comparer par rapport à l’ensemble des clients.
L’historisation des données permet de connaître la tendance de la satisfaction générale
de la cible et naturellement de réagir avant qu’il ne soit trop tard.
La durée de vie d’un client

Comment les entreprises déterminent quels sont leurs meilleurs clients ? Quand on
connaît le coût induit par la recherche et l’acquisition d’un nouveau client, la durée
de vie d’un client devient naturellement une mesure de profitabilité. L’analyse Client
permet de mettre en place des indicateurs afin de mesurer la durée de vie d’un client.
La fidélité du client
On a coutume de dire que les meilleurs nouveaux clients d’une entreprise sont les
clients actuels. Cela veut dire que les plus belles opportunités de réaliser de nouvelles
ventes se font auprès des clients de l’entreprise qui sont heureux de travailler avec
vous et satisfaits de vos produits et services.
L’analyse des clients en portefeuille est une aide efficace.
L’analyse de la productivité du capital humain

L’utilisation et l’optimisation du centre d’appels
Si vous avez déjà fait l’expérience des longues minutes d’attente passées au téléphone
avant d’obtenir le service souhaité et l’irritation naturelle qui en découle, vous
comprendrez sans difficulté la valeur qui résulte de l’analyse du temps d’attente du
client au sein de votre entreprise. Lorsqu’on sait par ailleurs que les appels entrants
proviennent en grande partie de clients non satisfaits, la durée d’attente aura un effet
déplorable sur la qualité du dialogue qui suivra.
La rentabilité effective
Cette notion regroupe la performance, le coût du travail et le rendement de la
production ; autant de facteurs qui montrent comment les membres du personnel
travaillent. Cette information peut être intégrée dans le référentiel et apporter une
valeur supplémentaire à l’analyse globale.
L’analyse de la productivité
Ce domaine d’analyse très répandu génère un grand nombre d’indicateurs et d’analyses.
L’analyse des produits défectueux

Alors que les entreprises se battent quotidiennement afin d’améliorer la qualité des
produits qu’elles fabriquent, des facteurs affectent le nombre de produits défectueux,
dont les causes sont les matières premières utilisées ou les personnels qui les fabriquent.
Il est aisé de suivre ces facteurs grâce aux indicateurs de productivité.
Le suivi du planning et l’optimisation des ressources

La compréhension de l’utilisation des ressources qui composent l’actif d’une usine
(machines, personnel, rendements attendus, matières premières, entrepôts, produc-
tion en flux tendus, etc.) peut être grandement facilitée par l’usage de la Business
Intelligence.
Le reporting financier
Les contraintes sévères liées à l’industrie obligent les entreprises et maintenant les
administrations (LOLF, loi organique relative aux lois de finances promulguée le
1er août 2001) à fournir de nombreux rapports financiers afin de présenter leurs
résultats. Ces contraintes se sont encore alourdies suite aux scandales financiers qui
ont défrayé récemment la chronique. Indépendamment de leur caractère obligatoire,
les analyses qui en résultent sont un excellent moyen de prendre le pouls de l’entreprise
et de repérer des secteurs nécessitant une surveillance particulière.
Dans cet esprit, le Congrès américain a fait adopter en juillet 2002 la loi Sarbane-
Oxley contraignant ainsi les entreprises cotées à communiquer rapidement leurs
résultats financiers.
L’article 404 de la loi vise à renforcer la fiabilité de l’information financière
délivrée et rend obligatoire l’utilisation d’un cadre d’analyse reconnu en matière de
contrôle interne et cite en substance le référentiel COSO (Committee of Sponsoring
Organizations, association américaine ayant pour objectif d’établir des règles de
contrôle financier interne et d’améliorer la qualité des reporting financiers).
La gestion du risque
C’est la capacité à trouver des solutions pour minimiser les conséquences des événe-
ments associés à une situation.
La précision de l’observation dans le suivi de l’activité et de la productivité offre
aux gestionnaires la capacité de prendre de meilleures décisions, par exemple sur
l’allocation de ressources dans le but de réduire le risque de l’organisation. De plus
l’analyse du risque peut apporter des réponses dans le cadre de la négociation de
contrats avec les fournisseurs et les partenaires en général.
La mise en place du nouveau règlement Bâle 2 vise à améliorer la qualité du
système bancaire grâce à la transparence dans la gestion des risques opérationnels.
Le juste à temps
Le concept de production en juste à temps doit aboutir à une diminution des risques
liés à la volatilité des prix des produits. Il est fortement recommandé de pouvoir
corréler les informations reçues au travers du canal de ventes afin de réagir le plus
rapidement en termes d’approvisionnement et de production.
L’analyse des canaux de vente

Le marketing
La capacité de régler finement un programme de marketing ainsi que la mesure de
l’efficacité dudit programme découlent en partie de l’analyse du canal de ventes. Le
processus itératif classique consiste à identifier des profils de groupes de clients et
de régler sa stratégie sur ces observations. L’efficacité de la stratégie sera fortement
dépendante des données recueillies par le canal de vente. Les résultats seront
naturellement comparés avec les objectifs attendus. La convergence ou la divergence
des résultats par rapport aux objectifs précisera de manière itérative de nouvelles
stratégies.
L’analyse de la performance des ventes

Les résultats de l’équipe de vente permettent d’identifier des variables qui agissent sur
le cycle des ventes, tels que les vendeurs, les régions, le type d’industrie, la qualité des
contacts, la récurrence et la fréquence des contacts.
L’analyse de la chaîne d’approvisionnement

L’analyse de la chaîne d’approvisionnement permet de caractériser les fournisseurs afin
de mieux les comparer.
La gestion des vendeurs des fournisseurs

Un grand nombre d’organisations sont dans l’incapacité d’identifier précisément qui
sont les vendeurs qui leur fournissent biens et services. L’analyse de la chaîne d’ap-
provisionnement permet aux gestionnaires de tracer la performance et la fiabilité des
fournisseurs, d’évaluer et de classer la qualité des produits fournis et ainsi d’optimiser
la relation avec le fournisseur en ce qui concerne les dépenses, les délais de livraison
et les risques.
L’expédition
Il existe différentes méthodes pour livrer des marchandises auprès des clients, chacune
générant des coûts différents. Par exemple, il sera plus coûteux de livrer des produits
par avion plutôt que par transport routier, mais les produits arriveront à destination
plus rapidement. Ce délai plus court peut être exploité pour répondre à une demande
dont il faut mesurer la justification.
L’analyse du comportement
Il est utile de repérer des modèles de comportement qui sont le présage d’événements
significatifs. Ce type d’analyse fait un usage abondant des données afin de repérer des
modèles susceptibles de générer tel ou tel événement. Le but de l’analyse consistera
donc à repérer la mise en place de tels modèles dans le but de prédire l’apparition
des phénomènes attendus. Ces études sont fortement utilisées en analyse technique
boursière. L’analyse d’une action sur une durée significative permet de mettre en
évidence des modèles susceptibles de prédire des changements de tendance. L’analyse
chartiste est basée sur ces phénomènes.
Les tendances d’achats

Bien qu’il soit possible de connaître avec précision le cycle de vie des produits, il existe
des tendances qui échappent à ce schéma. Les cas les plus parlants sont les produits
à effet de mode. L’approche des fêtes de Noël rend parfois difficile toute prévision,
faisant flamber tel article de jouet ou s’effondrer tel autre produit. Dans le domaine de
la mode, il est fréquent d’observer une corrélation entre la tenue vestimentaire d’une
star invitée à une émission grand public et le décollage soudain des ventes du même
article en magasins.
L’activité du Web
Nous l’avons déjà signalé précédemment, l’analyse du comportement d’achat sur un
site de commerce électronique est relativement aisée. Elle donne de surcroît des
indications d’achat et de tendance en temps réel. Cette détection des modèles de
comportement d’achat peut être à l’origine d’un modelage du site afin de mieux
prendre en compte les attentes des internautes.
La détection des fraudes

Les comportements abusifs ou frauduleux sont fréquemment modélisables. Par exemple
dans le domaine de la santé, il est aisé de constater que certains praticiens ont tendance
à prescrire des médicaments onéreux ou en surnombre. Une fois ces comportements
modélisés, zoomer sur les auteurs de tels actes devient un jeu d’enfant.
L’attrition du client
Un problème récurrent pour un grand nombre d’organisations est l’attrition du client
ou la capacité de ce dernier à quitter son fournisseur habituel. Dans les industries
à caractère compétitif, il est bien plus profitable de convaincre un client de rester
fidèle à un fournisseur avant qu’il n’ait pris la décision de le quitter plutôt qu’après.
On constate cela fréquemment dans la lutte effrénée que se livrent les opérateurs
téléphoniques pour conquérir de nouveaux clients. Les coûts de séduction de ces
nouveaux clients sont proprement exorbitants. Le repérage des clients susceptibles
de quitter l’entreprise par une observation fine des modèles de comportements
(historiques des appels et des plaintes) permettrait de proposer des offres personnalisées
susceptibles de retarder le départ voire même de l’éviter.
Le tableau de bord de l’intelligence

Un indicateur clé de performance (KPI, Key Performance Indicator) est une mesure
objective d’un aspect de l’activité qui est critique pour le succès de l’entreprise. De
tels indicateurs sont les composants du tableau de bord représentatif de l’activité de
l’entreprise. Il synthétise les différentes activités et mesures de cette dernière telles que
la satisfaction du client, la productivité, la performance du canal d’approvisionnement
et la profitabilité. Il synthétise également la qualité des hommes et des femmes de
l’entreprise, la qualité des outils qui leur sont mis à disposition.
Le tableau de bord de l’intelligence d’entreprise reflète les résultats des analyses
sous forme d’indicateurs, dans une représentation synthétique et compréhensible. Des
1.4 Les modèles d’accès à l’information 25
alerteurs visuels, de différentes couleurs, attirent le regard pour une compréhension

plus rapide. Ce tableau de bord dynamique permet en outre de zoomer sur tel ou
tel indicateur et d’approfondir l’analyse jusqu’à remonter à la cause première des
phénomènes.
Voici quelques-uns de ces indicateurs :
• graphe des ventes régionales par ville ;
• statistiques du personnel ;
• rapport d’approvisionnement par fournisseur ;
• mesure de la satisfaction client ;
• mesure de la productivité de l’usine, d’un département, d’un atelier, etc. ;
• moyenne de la profitabilité client.
La valeur ajoutée de la Business Intelligence

Au cours de nos réalisations, et au vu des avantages instantanés que nos clients
ont obtenus, nous avons acquis la ferme conviction que la Business Intelligence
permet d’insuffler un niveau de connaissance jusqu’alors inégalé dans l’entreprise. La
qualité du dialogue des dirigeants par le partage de la connaissance objective s’en
trouve améliorée. La connaissance transversale, par la suppression des cloisonnements
départementaux dans l’entreprise, est autant de facteurs générateurs d’observations
nouvelles.
1.4 LES MODÈLES D’ACCÈS À L’INFORMATION

Bernard Liautaud, dans l’ouvrage déjà mentionné, fait une analyse sans complaisance
de la situation des trois modèles qui gouvernent l’accès à l’information dans l’entre-
prise. Il cite :
• La dictature de l’information, où seuls quelques initiés ont accès aux données.
• L’anarchie de l’information, où chacun recrée son propre système d’information
provoquant un véritable chaos de données.
• La démocratie de l’information, où l’information bien gérée circule librement.
1.4.1 La dictature de l’information

Le premier cas met en évidence une attitude dictatoriale vis-à-vis du partage et
de la diffusion de l’information dans l’entreprise. Dans les années quatre-vingt, les
données étaient stockées sur des serveurs centraux hautement protégés. La diffusion
de l’information se faisait au travers de listings volumineux, dupliqués, et regorgeant
souvent de données inexploitables. Les analyses étaient confiées à des équipes d’experts
qui grâce à des logiciels spécifiques, parvenaient à extraire des analyses qu’ils diffusaient
ensuite auprès des personnels concernés. C’était le règne des infocentres dotés parfois
de tableaux de bord centralisés appelés EIS (Executive Information System).
1.4.2 L’anarchie de l’information

Dans les années quatre-vingt-dix, grâce à la diffusion massive de la micro-informatique,
silos de données et applicatifs personnels vont progressivement se mettre en place,
faisant apparaître un nouveau comportement anarchique. En effet, pour se libérer
du carcan imposé par les structures centralisées, les directeurs des départements
opérationnels vont rapidement comprendre que les outils bureautiques peuvent
répondre à de nombreux besoins restés jusque-là sans réponse. Les managers vont
se doter massivement d’outils tels qu’Excel et Access dans le but de répondre quasi
instantanément à leur demande de tableaux de bord et de reporting. C’est le début
de la multiplication des organismes de formation en bureautique. Les personnels
opérationnels rapidement formés vont s’approprier des données qui jusque-là leur
étaient inaccessibles.
De la généralisation des bases de données et tableurs va naître un autre phéno-
mène : la multiplication des silos de données. De nouvelles plates-formes matérielles et
logicielles hétérogènes fleurissent alors dans les entreprises. La communication entre
ces matériels parfois incompatibles rend difficile la centralisation des données. Chaque
département tend à garder jalousement les informations qui lui sont propres, rendant
difficile une consolidation de l’ensemble des données stratégiques et opérationnelles de
l’entreprise. L’incohérence des informations se manifeste lors de réunions regroupant
plusieurs départements où les managers finissent par s’interroger sur la validité des
tableaux d’indicateurs souvent montés à la hâte peu de temps avant la réunion.
On comprend aisément que la diversité des applicatifs entraîne une complexité
croissante des structures de données. De plus, ces données sont stockées dans des
fichiers de types différents tels que tableur, base de données, ERP, comptabilité, GPAO,
CRM, ventes, etc.
Les approches traditionnelles ont très vite montré leurs limites. Le développement
de l’Internet et la mondialisation ont ouvert les frontières de l’entreprise à l’ensemble
de ses partenaires. Le partage de l’information stratégique et la capacité d’effectuer
tous types d’analyse sont devenus une demande pressante des acteurs de l’entreprise.
Dans ce contexte anarchique, l’informatique décisionnelle va donc rapidement
s’imposer.
1.4.3 La démocratie de l’information

De par sa démarche structurante, la Business Intelligence offre un nouveau paradigme :
• Partager le métier de l’entreprise et la transparence de l’information à tous les
échelons de la hiérarchie.
• Disposer d’outils d’analyse conviviaux et accessibles en tous lieux (y compris
sur Internet) sans l’aide d’un spécialiste.
• Réduire les coûts de mise à disposition des informations stratégiques de l’entre-
prise.
• Libérer les ressources humaines des contraintes fortes des systèmes informatiques
au profit du métier de l’entreprise.
1.4 Les modèles d’accès à l’information 27
• Sécuriser l’information selon le profil des utilisateurs.

• Assurer la qualité et la pertinence de l’information.
• Augmenter la réactivité des personnels et la souplesse de l’entreprise grâce à la
connaissance.
• Permettre de découvrir des informations enfouies dans les données, que l’être
humain ne pourrait extraire seul.
• Faciliter la prise de décision grâce à la cohérence des données.
• Partager la vérité de l’information.
• Accéder sans délai à l’information.
2
L’approche méthodologique
Lorsqu’un projet décisionnel est décidé dans l’entreprise plusieurs composantes vont
interagir :
• La composante humaine est le moteur du projet et il est important de disposer
d’un sponsor de poids dans l’entreprise (la direction générale dans une PME ou
une direction fonctionnelle dans un grand compte).
• La composante technique est l’arbre de transmission qui garantira aux rouages
un fonctionnement harmonieux.
• La composante financière résulte des deux composantes précédentes. Tout pro-
jet BI nécessite une demande d’autorisation d’investissement (DAI). Cet enga-
gement de dépense fait suite à une estimation fine des éléments économiques
du projet (nombre de jours/homme d’étude, de développement, d’intégration,
d’exploitation, coûts des licences, coûts des plates-formes matérielles, etc.).
En général il faut assortir cette démarche d’une analyse de la valeur permettant de

calculer le retour sur investissement (ROI). Cette étude est présentée en détail dans
le chapitre 13. Dès maintenant nous pouvons mettre en avant des avantages tels que :
• l’augmentation de la productivité grâce à une information disponible plus
rapidement ;
• une information plus fiable ;
• un gain de temps mesurable pour rassembler les informations utiles ;
• un travail plus facile pour les collaborateurs itinérants ;
• une diffusion automatisée et économique des informations opérationnelles.
Autant que faire se peut, on cherchera à identifier les facteurs de différentiation par
rapport aux concurrents et à mettre en place des indicateurs permettant de mesurer
les gains réels.
30 Chapitre 2. L’approche méthodologique
2.1 LES ÉTAPES D’UN PROJET INFORMATIQUE

2.1.1 Le cycle en V
Les projets informatiques traditionnels avaient coutume de présenter un enchaîne-
ment linéaire des sept étapes. Les voici résumées :
• Expression des besoins et faisabilité.
• Analyse et spécifications.
• Conception.
• Programmation.
• Tests.
• Intégration.
• Recette et mise en production.
Expression des Recette et Mise

besoins en production
Et faisabilité
Analyse et Intégration
spécifications
Conception Tests
Développements
Et
programmation
Figure 2.1 — Les sept étapes d’un projet informatique
Lorsque l’on constate un problème technique ou fonctionnel dans une étape de

la partie montante du cycle dit en V, le retour ne s’effectue pas à l’étape précédente
mais au niveau de l’étape conceptuelle correspondante (identifiée par les flèches
horizontales de la figure 2.1).
2.1.2 La méthode agile

L’équipe
La méthode du cycle en V a pour but de présenter les processus et les outils mais ne fait
pas suffisamment apparaître les interactions entre les acteurs du projet. La composante
2.1 Les étapes d’un projet informatique 31
humaine est primordiale pour la réussite d’un projet BI. Il est de loin préférable qu’une
équipe soit soudée et animée par la volonté partagée de réussir plutôt que composée
d’individualités brillantes ayant peu le sens de la communication.
Priorité à l’application
Il est vital que l’application fonctionne selon les spécifications demandées. Il ne sert à
rien de documenter à l’excès des procédures techniques. On le sait, les programmes ont
tendance à être modifiés régulièrement mais pas la documentation associée rendant
cette dernière suspecte. Il est préférable de commenter abondamment les programmes
et de mettre à jour les lignes de commentaires lors de l’apport de modifications.
Il est infiniment plus utile d’obtenir en ligne un commentaire sur l’origine d’une
information (clic droit ou aide) plutôt que d’en chercher le sens dans un cahier
généralement introuvable au moment opportun. La documentation fonctionnelle doit
être accessible en ligne.
Il est également important de définir un binôme technique (deux personnes ayant
une bonne compréhension des processus informatiques, une forte complémentarité et
pouvant assurer un dépannage en cas d’absence de l’autre).
La collaboration avec l’utilisateur

Le client ou utilisateur final doit être impliqué à chaque étape du développement.
Le périmètre du projet doit être défini avec soin lors du contrat initial (cahier des
charges). Mais le client doit pouvoir intervenir très tôt et collaborer avec l’équipe
réalisatrice afin d’apporter un feed-back continu. Il s’agit d’éviter l’effet tunnel trop
souvent observé dans les projets d’envergure. Le client cherchant à se rassurer doit
pouvoir se projeter dans son application future aussi bien sur le fond, en termes
de contenu, que sur la forme (ergonomie de l’outil). La communication lors d’une
conversation en face à face est le meilleur vecteur de compréhension.
L’acceptation du changement
Il n’est jamais agréable au cours du développement de revenir sur des spécifications ou
des procédures codées. Cependant, afin d’éviter la frustration du client, il est impératif
d’accepter des modificatifs mineurs. La planification du projet doit rester flexible afin
d’en tenir compte. Le choix de l’outil de développement est à cet égard très important.
2.1.3 L’étude de faisabilité

Lorsqu’un projet décisionnel n’est pas totalement formalisé, il peut être judicieux
de mettre en œuvre une étude de faisabilité. Cette démarche a pour but de rassurer
les deux parties (fournisseur et client) en apportant au fournisseur une connaissance
suffisante sur le métier du client et au client une bonne perception sur la capacité
d’écoute et de compréhension du prestataire. Cette étude de faisabilité a pour objectifs
de permettre, dans un délai très court (5 à 10 jours) :
• de formaliser les attentes du client ;
• de les matérialiser au travers d’un prototype personnalisé à l’aide de données
réelles ;
• de cerner les capacités de la solution ;

• d’acquérir les connaissances de base ;
• d’être une base de travail et de discussion avec les utilisateurs.
Cette étude permet d’effectuer une sorte de « carottage » dans les strates fonction-
nelles (découverte d’un domaine parmi finances, achats, commercial, communication,
RH) et techniques (découverte des systèmes utilisés : système d’information, SGBD,
système d’exploitation, etc.).
Les livrables sont :
• un document de synthèse ;
• un prototype de l’application cible ;
• une licence à durée limitée du produit utilisé.
La démarche projet présentée plus haut est naturellement appliquée lors de cette
étude de faisabilité.
À l’issue de cette étude, le prestataire dispose d’éléments concrets lui permettant
de chiffrer avec plus de précision le développement et le déploiement de la solution
globale.
Après un temps de réflexion, le client dispose de la faculté de stopper son
expérience ou au contraire de mettre en œuvre tout ou partie du projet.
Le chapitre 13 présente les composants de l’étude de faisabilité.
2.1.4 Le cycle de vie du projet BI selon Ralph Kimball

Ralph Kimball, qui est considéré par beaucoup comme l’expert mondial de la Business
Intelligence, a défini très précisément les modules méthodologiques participant au
cycle de vie d’un projet BI :
• L’analyse des besoins.
• Les données :
– Modélisation dimensionnelle des données.
– Modèle physique des données.
– Définition des étapes de chargement du datawarehouse.
• La technologie :
– Définir l’architecture technique.
– Choix et installation des outils.
• L’application :
– Spécification de l’application.
– Développement de l’application utilisateur.
• Le déploiement.
• La maintenance.
• L’évolution.
2.2 Pourquoi un tableau de bord ? 33
En voici un schéma synthétique (figure 2.2).
Définir Sélection et
l’architecture installation Croissance
technique des outils et
évolution
Technologie
Planification Analyse Modélisation Modélisation Étapes du

des dimensionnelle physique chargement du Déploiement
du projet
besoins des données des données datawarhouse
métiers
Données
Maintenance
Spécification Développement
de de l’application
l’application
Application
Figure 2.2 — Gestion du cycle de vie dimensionnel (selon Ralph Kimball)
2.2 POURQUOI UN TABLEAU DE BORD ?

Lorsque l’on aborde un projet BI, il faut résister à la tentation de mettre en avant
l’outil plutôt que la démarche qui consiste à découvrir le métier du client et la nature
de ses besoins. Pourquoi me mettrais-je au volant de mon véhicule si je ne sais où
aller ? Nous avons vu au paragraphe précédent que le projet BI consistait à bien
appréhender le métier du client et de délimiter le périmètre fonctionnel avant de
procéder à toute étape de développement. Les éditeurs de logiciels ont une tendance
naturelle à mettre en avant la palette des fonctionnalités de leur produit. Ils offrent
rarement une réponse à l’attente métier du client.
Lors de nos consultations en entreprise nous rencontrons généralement deux
profils : le chef d’entreprise qui intuitivement souhaite disposer du meilleur tableau de
bord de pilotage et le DSI qui a tendance à mettre l’accent sur les aspects techniques
de l’offre BI. Pour des raisons historiques voire culturelles ou sécuritaires, le DSI sera
attiré par les solutions proposées par un éditeur déjà installé dans les lieux. Cependant,
un comparatif réalisé auprès de plusieurs éditeurs peut parfois aboutir à des conclusions
inattendues. Vous trouverez dans les références bibliographiques disponibles à la fin
de cet ouvrage un lien proposant des critères de comparaison des fonctionnalités et de
l’ergonomie des outils de BI.
Nous déconseillons toujours de mettre en œuvre un projet BI s’il n’est pas
« sponsorisé » par une direction fonctionnelle ou opérationnelle. En matière de BI, il
existe un facteur déterminant de succès : la recherche de l’amélioration de la valeur.
Ce facteur servira de fil conducteur tout au long de la réalisation du projet.
En 1992, Robert Kaplan et David Norton ont avancé pour la première fois
l’expression balanced scorecard (BSC) dans un article de la Harvard Business Review.
En 1996, les mêmes auteurs publient un livre sur ce sujet, traduit en français sous le
titre Le tableau de bord prospectif, pilotage stratégique : les quatre axes du succès (Éditions
d’Organisation, 1998). Les auteurs proposent de sortir du traditionnel tableau de bord
financier tout en faisant apparaître une vision multidimensionnelle de la performance.
Ils définissent quatre axes privilégiés de la performance, chaque axe étant motivé par
le même moteur : la stratégie de l’entreprise (figure 2.3).
Mon personnel est-il heureux ?

Comment améliorer
la compétence des hommes et
développer les outils performants ?
Quelle est
ma stratégie
de développement ?
Mes Quels processus améliorer

actionnaires, pour satisfaire et conserver
qu’attendent- mes clients ?
ils de moi ?
Que dois-je
apporter à mes clients ?
Que font mes concurrents ?
Figure 2.3 — Le balanced scorecard et les axes privilégiés d’analyse de la performance
On distingue clairement les quatre axes ou perspectives stratégiques :

• la perspective financière ;
• la satisfaction des clients ;
• les processus internes ;
• l’apprentissage organisationnel.
Dans les années quatre-vingt, les entreprises privilégiaient la mesure de leur

entreprise aux résultats financiers. Aujourd’hui les organisations ne se contentent plus
de mesurer leur efficacité par une approche comptable. Norton et Kaplan ont montré
comment des activités immatérielles dans l’entreprise ont une incidence forte sur le
résultat. Ils ont démontré à quel point la satisfaction de l’actionnaire (axe finance)
résulte fortement de la satisfaction du client (axe clients), elle-même très liée aux
processus de l’entreprise (axe processus internes). Les processus de l’entreprise sont
eux-mêmes servis par des hommes dont il est indispensable de connaître le niveau
d’implication (axe apprentissage organisationnel).
2.3 Les différents types d’indicateurs 35
La grande force du BSC fut de montrer qu’il existait d’autres composantes qui
participent à la valeur ajoutée. Norton et Kaplan ont nommé ces composantes
intangible value drivers et ont tenté de définir des indicateurs de performance derrière
chacun des axes.
2.3 LES DIFFÉRENTS TYPES D’INDICATEURS

Les étapes à suivre lors de la construction du tableau de bord sont les suivantes :
• Définir les objectifs.
• Identifier les variables d’action.
• Choisir les indicateurs.
• Mettre en place les clignotants.
Il ne rentre pas dans la mission de cet ouvrage de développer dans le détail la

méthodologie participant à l’élaboration des tableaux de bord ou balanced scorecard,
sujet sur lequel il existe une littérature abondante (se référer à la bibliographie en fin
d’ouvrage). En revanche, nous donnerons à titre d’exemple quelques indicateurs qui
nous paraissent essentiels au bon pilotage de l’entreprise. Nous distinguerons plusieurs
fonctions dans l’entreprise et pour chacune d’elles nous répartirons les indicateurs
selon quatre orientations :
• indicateur d’activité ;
• indicateur qualité ;
• indicateur de coût ;
• indicateur d’éclairage.
2.3.1 Fonction Commerciale
Activité Quantités vendues par secteur, par produit, par Par secteur, par produit,
client par client
Nouveaux clients
Nombre de commandes
Clients n’ayant pas commandé depuis x temps
Nombre de prospects visités
Nombre de devis émis
Taux de transformation sur devis
Qualité Nombre de réclamations reçues et traitées
Délai de livraison client
Taux de renouvellement des contrats d’entretien
Taux de rupture
(suite)
Coût Frais commerciaux Par nature, par secteur
Contribution/coût Par agence
Promotions
Engagements publicitaires Par famille de produit
Frais de voyage et déplacement Par secteur
Coût des stocks obsolètes
Observation Indices d’évolution d’achat de vente
Suivi de la compétitivité
Concurrence
Humains Effectifs
Embauches
Démissions
Primes versées
Nouveaux projets
2.3.2 Fonction Direction générale
Activité CA net, Quantités nettes Par secteur, par produit,

par client
Marge brute
Part de marché
Croissance du marché
Rentabilité des capitaux investis
Fonds de roulement
Taux de rotation des clients, fournisseurs, stocks
Carnet de commandes
Qualité Indice de qualité selon métier de l’entreprise
Délai de livraison
Nombre de réclamations
Coût Main-d’œuvre de production
Coût de revient des produits
Frais généraux Par nature
Frais commerciaux Par secteur
Sous-traitance
Observation Indices d’évolution d’achat de vente
Suivi de la compétitivité
Concurrence
Grands projets d’investissements
Nouveaux projets
(suite)
Humains Effectifs (internes/externes), embauches,
démissions
Taux d’absentéisme
Moral des troupes
Fréquence des accidents du travail
2.3.3 Fonction Ressources humaines
Activité Niveau de salaire en % du CA, en % des coûts Par département

Nombre d’augmentations de salaires Par catégorie
Nombre de personnes recrutées
Budget formation
Nombre de candidatures pour pourvoir un poste
Nombre de candidatures spontanées
Effectif Par catégorie, par sexe,
par âge
Effectif interne/externe
Productifs/Improductifs
Qualité Nombre de départs en période d’essai
Délai moyen d’un recrutement
Âge moyen Par catégorie
% de postes pourvus en interne
% de postes en binôme
Nombre d’annonces nécessaires pour pourvoir
un poste
Nombre de licenciements
Turnover
Coût Coût moyen d’un recrutement
Salaires Par département,
par catégorie
Observation Prévisions des départs en retraite
Prévision de création de postes
Nouvelles formations
Humains Heures supplémentaires
Taux d’absentéisme
Moral des troupes
Mobilité du personnel
2.3.4 Fonction Production et recherche – développement
Activité Capacité de production

Coût de revient des produits Standard/réel
Valeur ajoutée Par atelier
Quantités produites/heures productives
Quantités produites/effectif total
Quantités produites/heures machines
Consommation de matières premières/quantités
produites
Quantités produites Tonnes, unités
Maintenance préventive
Niveau des stocks/activité par nature Matières premières,
produits semi-finis,
produits finis
Qualité Taux de retouches, taux de déchets, taux d’arrêts
techniques
Nombre de réclamations, retours clients, retours
fournisseurs
Nombre de ruptures de stock
Respect du délai clients, suivi du délai fournisseurs
Délai de fabrication
Retard moyen des projets et études
Coût Consommation d’heures Par atelier et par produit
Coût de main-d’œuvre de R&D
Sous-traitance
Énergie
Observation Planning de production
Carnet de commandes
Évolution du prix des matières premières
Humains Effectif interne/externe
Embauches démissions
Absentéisme/turnover
Qualification du personnel
Taux d’improductifs
2.3.5 Fonction Logistique et approvisionnements
Activité Produits expédiés (tonnes, unités et valeur)

Valeur totale des stocks Standard/réel
Analyse ABC des stocks
Taux de rotation des stocks
Écarts sur inventaire
% de stock mort
Surface de stockage utilisée
Nombre de transporteurs
Nombre de références gérées en stock
Qualité Taux de retouches, taux de déchets, taux
d’arrêts techniques
Délai moyen de livraison au client
Délai moyen d’approvisionnement/fournisseur
Temps moyen et changement de véhicules
Retards de livraison En jours et en valeur
Nombre de ruptures de stock Matières premières
et produits semi-finis
Nombre de litiges transport, de livraison
Nombre d’avoirs
Taux de remplissage
Coût Coût total du transport
Coût transport Par
transposteur/m3 transporté
Coût moyen d’acheminement Par fournisseur
Coût des stocks Par m3 , total
Observation Carnet de commandes
2.3.6 Fonction Achats
Activité Montant annuel des achats

Montant moyen d’achat Par commande, par personne
Nombre de commandes traitées par personne
Taux de remise obtenu par personne
Conditions de paiement négociées
Nombre de références
Nombre de demandes d’achat
Nombre d’appels d’offres
Nombre de négociations
Nombre de commandes Par tranches de valeur
Nombre de comptes fournisseurs
Nombre de fournisseurs en activité
Nouveaux fournisseurs
Turnover fournisseurs
Part des importations
Qualité Délai moyen de traitement d’une commande
fournisseur
Nombre de relances
Nombre d’avoirs, de litiges
Performance des fournisseurs
Qualité des négociations
Taux de couverture des besoins
Coût Salaires
Dépenses de fonctionnement
Coût moyen de traitement d’une commande Total/par fournisseur
Coût moyen de recherche de fournisseur
Observation Études de marché fournisseurs
Évolution du marché
Carnets de demandes d’achats
2.3.7 Fonction Informatique – Études – Exploitation
Activité Rentabilité des investissements

Marge de contribution d’une nouvelle
application
Analyse des temps d’étude
Développement Planifié non planifié
Nombre d’heures de test
Nombre d’heures sous-traitées
Nombre d’heures ingénieur Par projet
Heures d’études
Lignes produites Par programmeur/période
Nombre de transactions Par heure
Nombre de programmes en exploitation
Nombre d’heures machines
Nombre de pages éditées
Qualité Respect du budget
Retard moyen
% heures de tests/heures d’études
% maintenance/études nouvelles
Délai de réponse aux demandes
Délai moyen d’une demande
Nombre d’incidents par période
Nombre d’erreurs de manipulation
Nombre d’incidents matériels
Nombre d’heures indisponibles
Coût Dépenses globales
Ventilation des dépenses Par logiciel/personnel,
études/exploitation
Salaires Ingénieurs, techniciens,
développeurs
Heures machines de tests/Production
Heures ingénieur
Coût moyen par transaction
Observation Carnet de commandes
Nouvelles applications
Planning prévisionnel de charge
Hausse des volumes traités Par rapport aux années
précédentes
Hausse des heures-machine Idem
Remplacement de matériel/amortissement
Nouvelles versions des logiciels/utilité
(suite)
Embauches/démissions
% de sous-traitance
2.4 DEUX MONDES DIFFÉRENTS : OLTP ET DW

Avant de développer les techniques nécessaires à la définition de l’entrepôt de données,
nous devons avoir conscience des différents niveaux de stockage des données, chacun
d’entre eux étant destiné à des tâches différentes pour des utilisateurs différents. Le
processus transactionnel (OLTP, Online Transactional Processing) est totalement orienté
vers l’utilisateur qui alimente au quotidien les bases de production. En revanche, le
modèle dimensionnel du datawarehouse (DW) est destiné aux analystes métier.
Le premier joue le rôle de récepteur des données originelles quels qu’en soient les
supports et les outils (saisie sur Internet, alimentation de l’ERP, comptabilité d’entre-
prise, saisie dans des tableaux Excel, etc.). Le second joue le rôle de concentrateur des
données afin de leur conférer une cohérence globale et partagée par l’ensemble des
acteurs de l’entreprise. Le DW peut prendre une forme particulière de stockage, OLAP,
qui n’est qu’une représentation optimisée du datawarehouse. OLAP présente en effet
l’avantage de fournir une information « prédigérée » selon les différents points de vue
des gestionnaires de l’entreprise.
Les utilisateurs de chaque niveau ne sont pas les mêmes, les structures de données
sont différentes, l’administration est différente ainsi que la gestion quotidienne.
2.4.1 Qu’est-ce qu’une transaction ?

Un système OLTP tel qu’un ERP ou un PGI traite des centaines voire des milliers
de transactions par jour. Chaque transaction est le reflet soit d’une mise à jour,
soit d’une suppression ou encore d’un ajout de données nouvelles. A contrario le
datawarehouse ne fera l’objet que d’une seule transaction dont la fréquence est
généralement quotidienne. En revanche cette transaction représente des centaines de
milliers d’enregistrements. De plus, elle s’effectue exclusivement en mode d’ajout de
données sans aucune modification ni suppression des données existantes. L’historique
des mouvements est donc intégralement conservé. Ce mécanisme participe à la
sacro-sainte traçabilité de l’information en entreprise (loi SOX). Ce processus porte
le nom d’ETL : extraction, transformation, chargement (load).
Un soin particulier sera apporté lors du processus d’ETL à la consistance des bases
avant et après le chargement. En effet, le processus de chargement peut faire l’objet
d’une interruption intempestive laissant le système dans un état d’inconsistance. Bien
qu’un processus de rollback puisse être mis en place, il sera souvent préférable de
procéder à une restauration de la base DW dans l’état où elle était avant le début du
2.4 Deux mondes différents : OLTP et DW 43
chargement. On verra que les ETL proposent des solutions de reprise intermédiaire
basées sur des points de contrôle ( checkpoint) à certaines étapes du processus.
2.4.2 Les utilisateurs et les gestionnaires

Les utilisateurs des systèmes OLTP sont des acteurs qui alimentent en permanence
les bases de données opérationnelles des organisations. Ils prennent des commandes,
enregistrent des paiements, procèdent à des règlements, saisissent de nouveaux clients,
enregistrent des réclamations, font des réservations, entrent de nouvelles données et
en corrigent d’anciennes. L’organisation des systèmes OLTP doit permettre la mise à
jour instantanée de toutes ces données.
Les gestionnaires (DBA, DataBase Administrator) de systèmes OLTP sont obsédés
par la performance, la fiabilité et la sécurité des SGBD dont ils ont la responsabilité.
Si le système OLTP s’arrête, c’est toute l’entreprise qui est bloquée. Il n’est donc pas
question d’effondrer les performances des systèmes par des requêtes ou des rapports de
synthèse qui seraient exécutées par les analystes métier dans l’entreprise.
Ces analystes sont les observateurs de l’organisation. Ils sont naturellement de gros
consommateurs des datawarehouses. Leur métier consiste à comptabiliser les nouvelles
commandes, chercher à comprendre les motifs qui poussent les clients à partir, analyser
les réclamations, comparer l’activité d’une année sur l’autre, observer des tendances.
Ils détectent parfois des anomalies dans les systèmes sous-jacents.
Ces gestionnaires observent les données à un niveau élevé de synthèse. Ils
éprouvent rarement le besoin d’accéder à des informations détaillées. Ils s’interrogent
sans cesse sur la manière dont les affaires se déroulent, passent rapidement de rapports
en analyse, de requêtes en nouvelles interrogations dans le but de déceler du sens dans
la marche de l’entreprise. Les réponses à leurs interrogations doivent être immédiates,
quelques secondes tout au plus et ceci quelle que soit la complexité de la requête.
Le reporting est souvent l’objet principal du datawarehouse (80 % des cas).
Aujourd’hui il n’est plus question d’imprimer des listings volumineux dans lesquels
bien souvent une seule ligne (en général la dernière) est utile pour l’analyse. Il s’agit
au contraire de mettre en place un reporting utile et personnalisé en fonction du
besoin du lecteur. Dans les chapitres qui suivent, nous verrons comment un utilisateur
peut souscrire un abonnement à tel ou tel rapport, le recevoir dans sa messagerie
quotidiennement ou mettre en place des alertes afin d’être prévenu lors de telle ou
telle transaction ou franchissement de seuil.
L’exemple de la figure 2.4 montre les nouvelles fonctionnalités du traitement des
indicateurs clés (KPI) proposés par le logiciel de requêtage de cubes OLAP Proclarity
6. Ce tableau synthétique, relativement complexe à développer en programmation
pure, est un jeu d’enfant à créer avec les assistants mis à la disposition de l’utilisateur
final (l’analyste métier).
Figure 2.4 — Voici un tableau qui doit pouvoir être fourni par un système basé sur un
datawarehouse
2.4.3 La dimension temporelle

Les systèmes OLTP et les datawarehouses traitent le temps de façon très différente. Le
meilleur des systèmes OLTP est en perpétuel changement, du fait des traitements de
mise à jour constants. Ralph Kimball, dans son ouvrage de référence The data warehouse
toolkit, Practical techniques for building dimensional data warehouses, Éditions Wiley, parle
alors de base de données scintillante. On comprend bien que des changements constants
dans la base ou des réécritures sur des données anciennes sont de nature à perturber les
analyses. Un système OLTP en perpétuel mouvement ne produira pas deux analyses
identiques à des moments différents dans une même journée.
Ces problèmes de changements permanents sont définitivement résolus par la
mise en œuvre de l’entrepôt de données dont l’objet est de stocker une succession
d’instantanés en provenance du système opérationnel et selon une fréquence régulière.
Un peu comme des géologues capables d’expliquer la formation des montagnes
en observant les couches successives de sédiments, le datawarehouse permet de
reconstituer l’évolution de l’activité d’une organisation grâce à des photographies
instantanées prises à des périodes régulières. De la même façon que les géologues
creusent les couches sédimentaires afin d’analyser les évolutions dans le temps, le
manager utilise la technique de forage ( drill down) afin de mesurer et de comprendre
les actions qui se sont succédé dans la réalisation des affaires.
Nous introduirons également la notion de « dimensions à variation lente » (slowly
changing dimensions). Cette technique est fondamentale pour représenter correctement
les variations qui se sont succédé dans le passé. En effet, il est fréquent que des
modifications surviennent dans les gammes de produits, chez les clients et fournisseurs.
Bien souvent, le manager souhaitera conserver la trace de ces variations.
La technique des instantanés statiques qui alimentent régulièrement le dataware-
house règle deux problèmes connus dans les bases transactionnelles :
• À la différence de l’OLTP, le datawarehouse est au repos lorsque les utilisateurs
lancent leurs requêtes car le « scintillement » n’est pas permis.
• Le soin apporté lors du stockage des informations dans le datawarehouse
autorise une représentation temporelle des données qui n’est pas native dans les
systèmes OLTP. Avec le datawarehouse, il est en effet possible de rapprocher des
informations de ventes ou de production sur des périodes de temps comparables.

Il est naturel d’analyser les données sur plusieurs années en year to date (cumul
depuis le début de l’année). Il est également aisé de connaître les nouveaux clients
depuis telle date ou au contraire ceux qui ont quitté l’entreprise.
Nous verrons dans le chapitre 5 comment l’ETL (Integration Services dans SQL
Server 2008) permet de mettre en œuvre le processus de stockage des instantanés dans
le datawarehouse.
2.4.4 Le modèle de données entité-relation pour les développeurs

Une autre différence majeure entre les systèmes transactionnels et les datawarehouses
réside dans le modèle relationnel. La modélisation d’un système OLTP vise essen-
tiellement à réduire la redondance des données de telle sorte que les transactions
modifient les données à un endroit unique. Le modèle entité-relation sur lequel
sont basés les systèmes OLTP met en œuvre une organisation très complexe avec
de nombreuses tables reliées entre elles selon des jointures précises garantissant par
ailleurs l’intégrité de la base. Il en résulte une grande difficulté de compréhension du
schéma relationnel. Il n’est pas facile de comprendre au premier coup d’œil quelles
sont les tables importantes et celles qui le sont moins, quelles tables contiennent des
données dynamiques et celles qui sont plutôt statiques, quelles tables présentent des
mesures de performance, quelles tables sont plutôt descriptives.
Voici quelques conséquences liées à cette organisation :
• Le modèle entité-relation, compte tenu de la complexité de son organisation,
présente des temps de réponse excellents lors d’ajout ou de mise à jour mais
catastrophiques lorsqu’il s’agit d’effectuer des requêtes à des fins d’analyse.
• Il résulte du point précédent que seules quelques requêtes peuvent être envisa-
gées dans une journée.
• Compte tenu de la complexité du schéma des tables, le département informa-
tique est contraint d’écrire des requêtes pour les utilisateurs métier.
• Dans les bases de données relationnelles normalisées, les requêtes qui sont de
simples questions en termes métier, sont très complexes à écrire en langage SQL
et ne peuvent donc être élaborées que par des spécialistes.
• Les utilisateurs sont frustrés de ne pouvoir eux-mêmes effectuer leurs requêtes
et analyses.
2.4.5 Le modèle dimensionnel pour les analystes

Le modèle qui est le plus proche des utilisateurs et qui décrit le mieux l’activité de
l’entreprise est le modèle dimensionnel appelé également « schéma en étoile ».
Ce schéma a été initialement mis en évidence par des fournisseurs de données tels
que A.C. Nielsen, IRI, IMS et Walsh America. Ce schéma résulte d’une demande
légitime d’amélioration des temps de réponse lors de l’accès à de très grosses bases de
données et également d’une volonté de simplification de la vision qu’un utilisateur

peut avoir lors de l’analyse des données métier.
Le modèle dimensionnel est composé d’une table centrale entourée d’un certain
nombre de tables. À la différence d’un modèle entité-relation, la table centrale est la
seule qui présente des jointures avec les autres tables. La table centrale est appelée
table de faits, et les autres tables, tables de dimensions.
Dans le schéma en étoile de la figure 2.5, la table de faits centrale est Internet-
Sales. Cette table historise l’ensemble des ventes effectuées sur Internet. Les tables
dimensionnelles caractérisent les clients, les produits et le temps.
Figure 2.5 — Un modèle dimensionnel type. Le schéma en étoile
Le schéma en flocon présente les mêmes caractéristiques que le schéma en

étoile avec cependant des branches dimensionnelles normalisées (plusieurs tables
en cascade). Dans la figure 2.6, les branches Customer et Geography sont normalisées.
La table de faits renferme les données qui mesurent la performance ou l’activité de
l’entreprise ; par exemple les ventes quotidiennes, les quantités fabriquées, les heures
travaillées. Les mesures stockées dans ces tables sont exclusivement numériques et
additives, c’est-à-dire qu’elles pourront être agrégées dans le temps. Exemple : le cumul
des ventes quotidiennes, mensuelles, annuelles. Ces mesures répondent à la question
« Combien ? ».
Figure 2.6 — Schéma en flocon
Les tables de dimensions présentent souvent des descriptions textuelles. Par exemple,
on effectuera des requêtes par produit ou par client. Dans ce cas, les produits ou les
clients sont des axes d’observation métier. Ces axes d’analyse répondent souvent aux
questions « Quoi ? » (quel produit), « Où ? » (chez quel client), « Comment ? » (quel
canal de vente), « Qui ? » (quel vendeur).
Tableau 2.1 — Le croisement des dimensions permet d’analyser les indicateurs selon de
nombreuses perspectives
Quand ? Qui ? Quoi ? Où ? Indicateurs

(Combien ?)
Année (historique Équipes Éditeur Enseigne CA & Qtés vendues
sur 10 ans)
Mois Représentants Catég. Prod. Libraire CA & Qtés
retournées
Jour Collection Remise en % et
valeur
Cumul à ce jour Titre de l’ouvrage Retours en % et
valeur
Tableau 2.2 — L’analyse dimensionnelle offre des combinaisons multiples et quasi illimitées.
Chaque dimension peut comporter des niveaux hiérarchiques permettant d’affiner les analyses
Dimensions Indicateurs
Temps De résultat
Géographie Nombre d’unités vendues
Part de marché
Usine Nombre de clients traités
Commandes prises
Canaux de ventes Taux de produit défectueux
Pièces produites
Organisation Pièces en rebut
Coût
Temps (calendaire/fiscal) Budget/réalisé
Contribution/marges
Ratios
...
De moyens
Matière consommée/unité produite
Heures de main-d’œuvre
D’avancement et plan d’action
% personnel formé
Nombre de cercles de qualité
D’environnement
Cours des matières premières
Taux de change
Taux financier
...
Axe d’analyse : La géographie

(Pays - région - ville)
Indicateurs :
Nb unités, CA, marge...
Axe d’analyse : Les produits

(Éditeur, Collect, titre)
Axe d’analyse : Le temps

(Année, trimestre, mois, jour)
Figure 2.7 — Représentation habituelle du modèle multidimensionnel sous forme de cube

2.5 Comparatif des deux modèles de stockage des données 49
Dans la figure 2.7, les flèches représentant les arêtes du cube symbolisent les axes
d’observation (Géographie, Produits et Temps). Les cellules du cube matérialisent les
mesures ou indicateurs (nombre d’unités, CA, marge, etc.).
2.5 COMPARATIF DES DEUX MODÈLES

DE STOCKAGE DES DONNÉES
En guise de synthèse, nous proposons un comparatif entre les modèles de stockage dit
transactionnels et multidimensionnels. Ces règles ont été définies par deux théoriciens
américains, E.F. Codd et C.J. Date.
2.5.1 Le modèle transactionnel (OLTP)

Les douze règles du relationnel (définies par Codd et Date)
Règle 1 : Toute information d’une base de données relationnelle est représentée par
des valeurs insérées dans des tables composées de lignes et de colonnes.
Règle 2 : Toute donnée ou toute valeur atomique dans une base de données
relationnelle doit être accessible grâce à la connaissance d’un nom de table, de la
valeur d’une clé primaire et d’un nom d’attribut (colonne).
Règle 3 : Les valeurs nulles (distinctes d’une chaîne de caractères vide ou d’une
chaîne de caractères « blancs » ou de zéro ou tout autre nombre) sont supportées par
un SGBD relationnel en tant que représentation d’information manquante.
Règle 4 : La description de la base de données est représentée au niveau logique de
la même manière que des données ordinaires, de sorte que des utilisateurs privilégiés
(bénéficiant des bonnes autorisations) peuvent utiliser le même langage (SQL) afin
d’accéder aux données utilisateurs ou aux métadonnées (structure des tables).
Règle 5 : Un système de gestion de données relationnel peut accepter plusieurs
langages et plusieurs interfaces utilisateurs. Cependant, il doit y avoir au moins un
langage dont les commandes sont exprimables grâce à une syntaxe bien spécifiée
exprimée sous forme de chaînes de caractères. Ces commandes sont :
• la définition des données ;
• la définition des vues ;
• la manipulation des données (interactive et à l’aide de programmes) ;
• les contraintes d’intégrité ;
• les autorisations ;
• les limites de transaction (début, fin, commit).
Règle 6 : Toutes les vues que l’on peut théoriquement mettre à jour peuvent aussi
être mises à jour par le système (ce qui inclut insertion, modification, suppression).
Règle 7 : La possibilité de manipuler une relation de la base ou relation dérivée

comme un opérande unique s’applique non seulement à la recherche de données mais
aussi à l’insertion, à la modification et à la destruction.
Règle 8 : Les programmes d’application et les interfaces écran demeurent logique-
ment inchangés si on modifie les méthodes de stockage ou les méthodes d’accès.
Règle 9 : Les programmes d’application et les interfaces écran demeurent logique-
ment inchangés si des modifications sont effectuées dans les tables.
Règle 10 : Les contraintes d’intégrité spécifiques pour une base de données
relationnelle doivent être définissables dans le langage de manipulation de la base et
stockables dans le catalogue, et non dans les programmes d’application :
• Intégrité de l’entité : aucun composant de la clé primaire n’est autorisé à être nul.
• Intégrité référentielle : pour chaque clé étrangère distincte non nulle d’une base
de données relationnelle, il doit exister une clé primaire correspondante du
même domaine (dans une autre table).
Règle 11 : Une base de données relationnelles est indépendante vis-à-vis de

la répartition. Autrement dit, les programmes d’application et les interfaces écran
demeurent logiquement inchangés :
• si on introduit un nouveau modèle de répartition des données,
• si les données sont distribuées sur plusieurs serveurs (dans le cas où le SGBD
gère la répartition).
Règle 12 : Si un système relationnel est interfacé avec un langage de bas niveau,

ce langage ne peut pas enfreindre ou contourner les règles d’intégrité exprimées par le
langage de haut niveau (de type ensembliste).
Ces règles ont été définies par C.J. Codd en 1985. Depuis, elles ont fait l’objet
d’amélioration.
2.5.2 Le modèle multidimensionnel (OLAP)

Voici les douze règles caractérisant le modèle multidimensionnel (C.J. Codd).
Règle 1 : Offre une vue permettant des manipulations simples sur les données :
rotation, pivot ou vue par tranche, permutation d’axes (slice and dice) ou en cascade
(drill anywhere).
Règle 2 : Offre une transparence du serveur OLAP à différents types de logiciels.
Permet d’implanter le système OLAP sans affecter les fonctionnalités du système
central.
Règle 3 : Doit être accessible à de nombreuses sources de données. Les outils
OLAP ont leur propre schéma logique de stockage de données physiques mais doivent
accéder aux données et réaliser n’importe quelle conversion pour présenter une vue
simple et cohérente des données. Ils doivent savoir d’où proviennent les données.
Règle 4 : L’augmentation du nombre de dimensions ou du volume de la base de
données ne doit pas entraîner de dégradation de performance visible par l’utilisateur.
2.5 Comparatif des deux modèles de stockage des données 51
Règle 5 : La plupart des données OLAP sont stockées sur des systèmes puissants
et sont accessibles via des postes individuels. Il est donc nécessaire que les produits
OLAP travaillent en environnement client/serveur.
Règle 6 : Toutes les dimensions doivent être équivalentes en structures et en calcul.
Il ne doit exister qu’une seule structure logique pour toutes les dimensions.
Règle 7 : L’optimisation des matrices creuses est nécessaire afin de tenir compte
des combinaisons vides (dans une analyse à la fois sur les produits et les clients, tous
les produits ne sont pas vendus chez tous les clients).
Règle 8 : Le système doit offrir des accès concurrents, garantir l’intégrité et la
sécurité afin que plusieurs utilisateurs puissent accéder au même modèle d’analyse.
Règle 9 : Tout outil OLAP doit gérer au moins 15 à 20 dimensions.
Règle 10 : Les opérations doivent s’effectuer sur toutes les dimensions (agrégats)
et ne pas demander à l’utilisateur d’intervenir pour définir un calcul hiérarchique.
Règle 11 : Toute manipulation de données doit être intuitive. Elle doit être
accomplie via une action directe sur les cellules du modèle sans utiliser de menus
ou des chemins multiples à travers l’interface utilisateur.
Règle 12 : Doit offrir une souplesse et une grande facilité de constitution des
rapports. Doit permettre de présenter les résultats sous forme de données synthétiques
ou en fonction de l’orientation du modèle.
2.5.3 Synthèse OLTP et OLAP
Tableau 2.3 — Comparaison des deux modèles de stockages des données
OLTP OLAP
(bases transactionnelles (cubes analytiques)
de production)
Utilisateur Collaborateur, cadre opérationnel Cadre fonctionnel, décideur
Fonction Saisie journalière Aide à la décision
Base de données Orientée application (ERP) Orientée métier
Données Dynamique Historique
Usage Répété À la demande (ad hoc)
Accès Lecture/écriture Lecture seule (écriture de
simulation possible)
Unité de travail Transaction (insertion/suppression, Requête complexe hiérarchique.
mise à jour). Langage SQL Langage MDX
Nb enregistrements Quelques enregistrements Millions d’enregistrements
utilisés
Nb utilisateurs Centaines Dizaines
Volume de la Base GB TB
2.5.4 Modèle simplifié FASMI

Les douze règles de Codd ont été simplifiées, complétées et synthétisées par l’acronyme
FASMI (Fast Analysis Shared Multidimensional Information) :
• Fast. Le système est conçu afin de délivrer aux utilisateurs la plupart des réponses
en moins de 5 secondes.
• Analysis. Le système doit pouvoir répondre à toute problématique métier,
tout type d’analyse et toute statistique appropriée à l’application. L’accès à
l’information doit être aisé et répondre rapidement aux besoins de l’utilisateur.
• Shared. Les données sont centralisées et partagées avec tous les niveaux de
sécurité et confidentialité nécessaires. Le système doit être capable de tenir
compte des accès multiples en écriture des cubes OLAP. (Microsoft Analysis
Services est un exemple d’outil sécurisé de mise à jour de cubes à des fins de
simulation.)
• Multidimensional. Cette notion est la clé de la définition de l’OLAP. Le système
doit être en mesure de fournir à l’utilisateur une vue multidimensionnelle et
hiérarchique, offrant une vision proche de celle de la structure de l’organisation
de l’entreprise.
• Information. Toute l’information pertinente de l’entreprise doit pouvoir être
stockée sans considération de limitation de taille ou du nombre de composants.
2.6 OLAP OU REPORTING ?
Le propos est de mettre en avant les avantages et les inconvénients des deux systèmes
(OLAP et reporting) afin de choisir l’outil le mieux adapté pour répondre à un besoin
« utilisateur » spécifique.
Approche du problème
Les techniques d’aide à la décision font appel à deux approches complémentaires.
L’une est centrée sur les données à produire, l’autre sur l’utilisateur. Dans le cas de
l’approche centrée sur les données, on examine les caractéristiques des données à
produire et on choisit la technologie la mieux adaptée pour cela.
Dans le cas de l’approche centrée sur l’utilisateur, la réflexion est menée autour
des besoins exprimés par le demandeur. En effet, vous cherchez à connaître qui sont
les consommateurs d’information et quelles sont leurs attentes : s’agit-il de prendre
des décisions, de suivre la performance d’une unité opérationnelle, ou de partager
l’information avec d’autres collaborateurs. Lorsque le besoin sera défini, il s’agira de
déterminer la meilleure technologie susceptible d’aider les utilisateurs à accomplir
leurs tâches.
2.6 OLAP ou reporting ? 53
Les critères de décision

L’information doit-elle être délivrée telle quelle ou doit-elle faire l’objet d’une
interprétation ? Un grand nombre de projets BI a seulement pour but de délivrer
un ensemble de rapports à une population d’individus déterminée. Certains projets
ont pour but de comprendre le sens des données sous-jacentes et de produire des
informations utiles à destination des décisionnaires soucieux de la performance de
leur organisation.
Par exemple, dans le cas d’une relation de partenariat entre deux acteurs, la
fourniture d’information sur un état de compte ou des factures en cours est un schéma
de type centré sur les données. Le but étant de fournir aux utilisateurs un accès aisé et
rapide à des enregistrements spécifiques pour un compte donné. Dans un tel projet, on
ne recherche pas à connaître l’usage qui sera fait de telles données par l’utilisateur. Le
seul objectif est de fournir des données sans se soucier de leur interprétation.
D’un autre côté, la mise à disposition d’information dans le but de permettre à un
décisionnaire de mieux contrôler le niveau d’inventaire ou de suivre les ventes au
quotidien d’un produit afin d’optimiser le circuit de livraison et le niveau de stock,
est un projet BI orienté compréhension. Parce qu’une réponse à une question induit
naturellement toute une série d’autres questions/réponses, dont le cheminement n’est
pas connu par avance, l’outil qui permettra d’apporter une aide à ce schéma sera basé
sur un modèle Multidimensionnel.
Quel est le pourcentage de données pour lesquelles la lecture est connue d’avance,
et quel est le pourcentage des informations connues dynamiquement ? Dans le premier
cas les rapports traditionnels sont bien adaptés. Les données et calculs associés, vues
et filtres divers sont prédéfinis. Ces rapports statiques dans leur forme, sont disposés
sur des serveurs de rapports et délivrés tels quels auprès des managers opérationnels.
Si au contraire, votre projet nécessite de réaliser des requêtes dynamiques et non
prédéfinies, les outils analytiques OLAP sont les plus judicieux. Ils le sont à double
titre.
• Les utilisateurs peuvent naviguer verticalement dans une unité fonctionnelle et
transversalement à travers les départements de l’entreprise.
• Les informaticiens disposent d’outils très sophistiqués permettant de laisser à la
machine le soin de répondre à des interrogations complexes qui nécessiteraient
des jours de programmation dans des environnements de développement
traditionnels.
Voici deux exemples de requêtes qu’il est aisé de traiter au travers d’un système
OLAP et très complexe avec le langage SQL de base :
• Quels sont les clients dont la part cumulée progresse le plus vite depuis le début
de l’année ?
• Quelle est la variation des ventes cumulées et comparées sur trois ans pour mes
cinquante plus gros clients ?
Comment les données sont-elles fournies ?

Les outils de reporting ont tendance à produire des rapports avec des présentations
formatées. Les technologies OLAP sont optimisées pour des analyses temps réel
(navigation non prévisible, calculs à la volée, et scénarios de type « what if » per-
mettant de réaliser des simulations sur les données opérationnelles). Ces technologies
permettent des restitutions dynamiques au travers de navigateurs Internet ou peuvent
être « encapsulés » dans des tableurs.
Quels sont les types d’interrogation et de temps de réponse

attendus par les utilisateurs ?
D’un côté, les rapports prédéfinis sont envoyés à l’imprimante qui par définition est
un périphérique lent. Cette tâche est le plus souvent planifiée et peut durer des heures.
D’un autre côté, un utilisateur « analyste » navigue sur des Giga octets de données
réalisant des requêtes complexes avec des temps de réponse inférieurs à la seconde.
L’état de l’art en matière de technologie OLAP, utilise des algorithmes d’agrégation
et de compression de données dans le but de garantir toutes les combinaisons utiles
au sein du cube. Cette organisation permet de disposer de requêtes dont les temps de
réponse sont quasi immédiats. Pour offrir des temps d’accès aussi rapides, il est impératif
d’agréger les données et de ne pas conserver le niveau « atomique » généralement
stocké dans les bases de production. Par exemple, si des centaines de transactions
sont stockées pour le même client dans la même journée, il suffira de stocker dans
le cube une seule ligne représentant le cumul journalier pour le client. Le niveau de
granularité du cube est souvent un agrégat des données de production.
En effet si cette condition n’est pas respectée, on constate une « hypertrophie » du
cube pouvant amener à une « explosion » de la structure.
On l’a compris, si l’on doit analyser les données au niveau de la transaction, la
structure relationnelle est naturellement mieux adaptée.
Quelles sont les tailles acceptables ?

Historiquement, les technologies OLAP ont montré certaines limitations réduisant
le champ des problèmes qu’elles étaient censées résoudre. Les technologies OLAP
récentes ont considérablement repoussé les limites de taille. Il n’est pas rare de ren-
contrer des cubes de quelques gigaoctets avec des performances tout à fait acceptables.
Si les données sont volumineuses et utilisées à leur niveau le plus bas, le stockage
relationnel est probablement le meilleur choix. En revanche, si les données sont
volumineuses, mais que l’analyse s’effectue à un niveau agrégé des données, la structure
OLAP est le meilleur choix.
Pourquoi un référentiel métier unique ?

SQL, le langage des bases de données relationnelles, n’a pas été défini pour des
calculs et filtrages complexes. Pour détourner ces limitations, les utilisateurs s’orientent
souvent vers le tableur afin de réaliser des calculs complexes. Au mieux, l’utilisation de
ces outils représente un risque à cause de la technique du « copier-coller ». Au pire ces
2.6 OLAP ou reporting ? 55
techniques à base de tableurs mènent à l’anarchie des rapports où chaque collaborateur

dispose de « sa » propre version de la vérité. On observe trop fréquemment dans les
organisations des cadres passant une bonne partie de leur temps à consolider des
tableaux répartis dans un grand nombre de stations de travail. Nous verrons au chapitre
11 que le tableur Excel est particulièrement adapté à l’analyse pour autant qu’il puise
des données directement sur le serveur de DW.
La centralisation du référentiel métier, utilisé par les décisionnaires pour l’élabo-
ration des indicateurs clés de performance (KPI), apporte une compréhension des
affaires grâce à une standardisation des concepts et au partage collaboratif. La vue
synthétique des objets métiers répertoriés dans le dictionnaire global de l’entreprise,
améliore la compréhension, et la productivité lors de l’extraction des données et de la
construction des tableaux.
Les données ont-elles besoin d’être agrégées ou bien traitées

au niveau le plus bas ?
Nous l’avons vu, le but des bases multidimensionnelles est d’analyser et de manipuler
de grandes quantités de données. Le type même de structure « cubique » permet la
création de nouveaux algorithmes d’agrégation et de synthèse. L’intérêt d’une telle
structure est que les calculs d’agrégation et de totalisation des indicateurs sont stockés
dans un référentiel unique, partagé par tous. La restitution de l’information est ainsi
considérablement fiabilisée réduisant le risque d’erreur d’interprétation.
Par ailleurs le type de structure résultant de l’organisation des cubes induit
naturellement une vision commune et un partage naturel et complémentaire des
observations de chacun dans l’entreprise.
Quel est le besoin de la modélisation de la décision ?

De nouvelles recherches se sont développées autour de la structure multidimension-
nelle de données. De nouvelles possibilités sont alors apparues en particulier dans le
domaine de l’analyse prédictive et de la segmentation.
Un type d’analyse assez fréquent est basé sur la question suivante « que se passerait-
il si ? ». En effet il peut être intéressant dans un modèle économique de faire varier tel
ou tel facteur sur les données réelles de l’entreprise et d’en mesurer l’impact. Une autre
démarche consiste à ajouter ou retirer une variable dans un contexte prévisionnel
et d’en mesurer l’impact immédiatement. Les structures multidimensionnelles dites
en écriture permettent de stocker temporairement ces données de simulation et d’en
mesurer les conséquences sur l’ensemble du modèle.
Un autre volet consiste à réaliser des analyses prédictives. Certains algorithmes
statistiques permettent de se projeter dans le futur et ainsi de prévoir des résultats
avant même que la réalité ne se produise. Cette analyse est particulièrement utile aux
gestionnaires qui basent leurs projections sur les données historiques de l’entreprise.
Aujourd’hui malheureusement, ce type d’analyse est souvent réalisé à partir d’outils
disparates dans l’entreprise, visant à consolider manuellement les informations puisées
dans les divers silos de données. On le comprend bien, ces méthodes « artisanales »
même si elles résultent d’un travail commun non négligeable, ne permettent pas de
profiter des bénéfices liés à la centralisation et au partage de quantités importantes de

données de l’entreprise. Les technologies OLAP apportent naturellement des réponses
à cette problématique.
En conclusion
Les techniques basées sur des structures de données relationnelles sont efficientes
lorsqu’elles visent à distribuer des données détaillées aux utilisateurs au travers de
rapports préformatés.
Les technologies OLAP sont plus appropriées lorsque les utilisateurs désirent
explorer et comprendre les données agrégées afin de répondre rapidement à des
besoins stratégiques de l’entreprise. L’utilisation partagée d’un référentiel « métier »
de l’entreprise favorise le dialogue et le partage naturel de la stratégie entre les acteurs
des différents départements de l’entreprise.
2.7 LE PROCESSUS DÉCISIONNEL

AVEC SQL SERVER 2008
Les différentes étapes du processus décisionnel sont maintenant clairement définies et
synthétisées dans la figure 2.8.
• Collecte des données depuis les différentes sources opérationnelles (Oracle,
DB2, SQL, Sybase, ODBC, OLE DB...).
• Intégration dans un ou plusieurs datamart métier selon un modèle multidi-
mensionnel (schéma en étoile relationnel). Cette fonction est remplie par
Integration Services.
• Transformation du modèle multidimensionnel relationnel en modèle hypercube
OLAP. Élaboration de KPI (indicateurs clé de performance). Fouille de données
visant à découvrir du sens dans les entrepôts. Cette recherche est confiée à des
algorithmes spécialisés de data mining grâce à Analysis Services.
• Restitution de l’information sous forme de rapports ou d’analyses croisées à la
demande. Reporting Services, Report Builder, Proclarity, Excel, participent à la
restitution.
• Présentation synthétique des résultats d’analyse dans un tableau de bord
(Business scorecard Manager intégré dans SharePoint Portal).
Nous développerons chacune des composantes à partir du chapitre 5.
2.8 LES ERREURS À ÉVITER

Plusieurs facteurs sont à prendre en compte dans la création d’un projet BI afin
d’anticiper les risques d’échec.
2.8 Les erreurs à éviter 57
Figure 2.8 — Les différentes composantes du processus décisionnel avec SQL Server 2008
2.8.1 Le facteur Humain

La compétence et les motivations des utilisateurs sont mal interprétées
Dans l’entreprise, il existe quatre catégories d’utilisateurs de l’information :
• Les utilisateurs non techniques ayant une forte implication métier.
• Les Analystes métier.
• Les Analystes avancés (Key Users) qui ont une connaissance forte du métier et
une bonne compétence des techniques de requêtage.
• Les Développeurs ou Administrateurs de base de données (DBA) dont la
vocation est de mettre à disposition des utilisateurs métier, les données de
l’entreprise. Ces techniciens de l’information (voir en annexe les différents
profils) ont une forte compétence en matière d’infrastructure des systèmes
d’information mais peuvent faire montre d’une connaissance relative du métier
de l’entreprise.
Dans la plupart des entreprises, les utilisateurs non techniques représentent en

moyenne 80 pourcent des utilisateurs de l’information, alors que les analystes avancés
et les analystes métier se partagent les 20 % restant. Cette population d’analystes,
souvent proche des directions opérationnelles, a très vite compris l’intérêt présenté par
les outils de restitution sophistiqués (Powerplay, BO, Crystal...). Ils ont souvent joué le
rôle de facilitateurs lors de l’acquisition d’outils d’aide à la décision. En arrière-pensée
ils visaient à recouvrer une certaine indépendance à l’égard des informaticiens qui
jusque-là étaient les seuls concepteurs de leurs requêtes.
Nous le verrons plus loin, SQL Server 2008 apporte des réponses à cette catégorie
d’utilisateurs grâce à Report Builder. (outil de création de requêtes et rapports à usage
des non-techniciens). Excel offre une réponse grâce aux tableaux croisés dynamiques
connectés directement sur les Cubes OLAP.
Le partage de l’information reste encore tabou dans les entreprises

Un piège classique dans le cycle de la BI est de penser que seuls les développeurs et
Administrateurs des bases de données peuvent accéder et manipuler l’information
des bases de données. Cette croyance est directement liée au fait qu’il n’est pas
concevable de fournir à un utilisateur l’accès direct au SGBD sur lequel est basé l’ERP.
De nombreuses raisons, souvent justifiées, sont mises en avant. La sacro-sainte sécurité
dans les entreprises a contribué à éloigner les utilisateurs des sources de données.
Les risques de dégradation des performances et la non-compréhension du modèle de
données ont longtemps été un frein à la mise à disposition d’outils de requêtage à
destination des utilisateurs finals.
Une réponse est la mise à disposition d’un datawarehouse déconnecté de l’ERP.
Microsoft SQL Server 2008 propose la mise en place d’UDM permettant de s’affranchir
de la complexité du modèle de données sous-jacent. L’UDM, souvent créé par
l’administrateur des bases (DBA) est une interface visant à permettre à l’analyste
d’accéder aux données de l’entreprise en toute sécurité. De plus l’UDM offre une
vision claire des données au travers du référentiel métier.
2.8 Les erreurs à éviter 59
La culture de la mesure n’est pas intégrée par le personnel

Si les dirigeants sont les seuls à prendre le plus grand soin à mesurer l’activité et
les revenus qui en découlent, on observe que parmi les utilisateurs de l’information
susceptibles d’apporter du changement dans l’entreprise, peu nombreux sont ceux qui
en tirent un avantage au quotidien.
Cependant lorsque l’on offre à chacun la possibilité d’observer sa propre effica-
cité en la comparant à d’autres employés de l’entreprise, le comportement change
radicalement. La mise en œuvre de tableaux de bord présentant des indicateurs de
performance des Business Units, sous forme très visuelle telle que « feux tricolores »
vert/jaune/rouge, représente un aiguillon redoutable. Pour autant il convient de fournir
à l’employé la règle qui permet d’influer sur l’indicateur et les moyens d’action pour
parvenir au résultat attendu.
La difficulté dans un grand nombre de sociétés réside dans le fait que les employés
sont peu informés de la stratégie menée par la direction générale. Dans ces conditions
comment l’employé s’améliorer ? L’apport du Balanced Scorecard est de ce point de vue
fondamental.
2.8.2 Le facteur Technique

Les facteurs humains, sont naturellement fondamentaux dans la réussite du projet
BI mais il ne faut pas négliger les aspects techniques qui, s’ils ne sont pas maîtrisés,
peuvent être à l’origine de naufrages (Le Titanic a sombré à cause d’une erreur de
positionnement).
Vous ne devrez jamais perdre de vue que la plus grande partie de votre attention
doit être focalisée sur l’alimentation de l’entrepôt de données, sorte de boîte noire de
l’activité de l’entreprise sur laquelle sont basés toutes les hypothèses des analystes et
le reporting d’entreprise.
Voici une liste des erreurs et des pièges les plus communément observés dans le
déploiement de projet BI.
Les données sources sont :
• Incomplètes
– Enregistrements manquants.
– Champs manquants conduisant à des cellules vides.
– Description d’enregistrements erronés.
• Incorrectes
– Mauvaise codification (altération des codes dans le temps).
– Agrégations déjà réalisées dans les sources de données.
– Calculs erronés. (champs numériques résultant de calculs imprécis ou
erronés).
– Enregistrements doublonnés impactant les tables de faits.
– Double exécution du processus de chargement. Cette erreur peut se produire

lors du déclenchement du processus sur la présence d’un fichier sémaphore
mal maîtrisé.
– Mauvaise information entrée dans le système source telle qu’une inversion
de date 12/01/2006 ou 01/12/2006.
• Incompréhensibles
– Données en provenance d’un champ unique devant être « éclaté en plusieurs
champs dans le datawarehouse. Ex. : « John F. Kennedy » ».
– Codifications inconnues du système. (Fuzzy lookup).
– Données non structurées en provenance de traitement de texte (nombres
formatés avec des espaces en tant que séparateurs de milliers).
– Jointures de tables avec des relations plusieurs à plusieurs non identifiées.
• Incohérentes
– Codifications versatiles (« M » et « F » ou 1 et 2).
– Codifications changeantes liées à des réorganisations dans l’entreprise.
(Dimensions à variation lente). Risque de perdre l’antériorité de l’historique.
– Multiplication de codes différents pour une même entité (ex. : client ou
produit ayant changé plusieurs fois de codification dans le temps).
– Plusieurs codes distincts représentant la même entité.
– Noms et adresses légèrement différentes mais identifiant la même entité.
– Calculs d’agrégations erronés dans les sources de données (la somme des %
de deux nombres n’est pas égale au % de la somme de ces deux nombres).
– Le niveau de granularité des données doit être comparable (ex. : les dépenses
sont connues au niveau poste de charge, les budgets sont établis au niveau
du regroupement de charges).
– Les données agrégées concernent des périodes différentes (ex. : fourniture
de données en provenance d’organismes extérieurs sur la base de la semaine,
alors que le traitement d’alimentation est quotidien).
– Les champs Null, espace ou vides ne possèdent pas la même codification
interne.
– Manque d’intégrité référentielle dans les données sources (chiffre d’affaire
réalisé sur le produit A alors que le client n’est pas référencé).
– La mise à jour de la table de faits dans le datawarehouse est quotidienne
alors que la table de dimension associée est mensuelle (risque de non-
correspondance des données).
– Des lignes de données peuvent intégrer les lignes détail ainsi que les totaux
(risque de doubler les valeurs).
La phase de préparation du chargement des données dans le datawarehouse (ETL)

est longue, fastidieuse, et coûteuse en temps. Elle nécessite de multiples contrôles
afin d’assurer une totale cohérence des données. Les journaux de chargement devront
être étudiés avec attention. Des procédures d’alertes en cas de « plantage » devront
2.9 Les règles du succès 61
être mises en œuvre (envoi de mail ou SMS). Des procédures de reprises doivent être
définies.
Il est aisé de comprendre que la complexité d’un entrepôt de données croît de
manière exponentielle avec le nombre de sources de données en entrée.
Il ne faut pas non plus négliger le fait que la connaissance des pièges et de leur
identification peut disparaître avec les personnes.
Le poste d’ETL devra faire l’objet d’une documentation extrêmement précise et
complète.
2.9 LES RÈGLES DU SUCCÈS

2.9.1 Règle 1 – Comprendre les utilisateurs
Les utilisateurs métiers non techniques
Cette population nous l’avons vu représente 80 % des utilisateurs. Leur tâche au
quotidien est de servir les processus de l’entreprise et ils n’ont par conséquent ni le
temps ni le loisir d’analyser sans cesse les données. Ils demandent un accès sans effort
aux données. Ils s’abonnent une fois pour toutes afin de recevoir par mail chaque jour
le compte rendu de l’activité, les objectifs définis et les écarts.
En regard de cette population nous mettrons en action un outil tel que reporting
services. Le développeur réalisera la maquette du rapport, l’administrateur (DBA)
effectuera pour eux un abonnement. Ils recevront les documents au format qu’ils
jugeront utile (mail, ou support papier). Ils définiront également la fréquence de
réception.
Les dirigeants qui ont besoin d’une vision synthétique, consulteront les informa-
tions au travers de scorecard (PerformancePoint 2007 ou Office 2007) ou des tableaux
de bord via une interface Web (SharePoint Portal, Panorama software, Proclarity).
Les Analystes métier

Ils ont une connaissance plus approfondie de l’outil informatique et en particulier
maîtrisent bien Excel. Ils sont tout à fait capables de trier, filtrer les données. Ils
utilisent les tableaux croisés dynamiques en accès direct sur les cubes Olap. Les
données sont naturellement extraites du datawarehouse et ne souffrent d’aucune saisie
manuelle par l’utilisateur.
Les Analystes qui recherchent l’origine des causes et l’analyse de croissance ont
besoin d’outils puissants (Report Builder 1.0, Excel for Olap, ou Proclarity).
Les Analystes métier, techniciens de l’information (Key Users)

Ces utilisateurs ont la capacité de créer eux-mêmes leurs requêtes et rapports. Ils
maîtrisent Reporting services et Report Builder 2.0. Ils peuvent élaborer des tableaux
de bord sophistiqués et sont en général de véritables référents pour l’ensemble des
utilisateurs métiers. Ils communiquent avec les techniciens de l’information et peuvent

apporter leur contribution dans l’élaboration du datawarehouse et de l’UDM.
Les statisticiens
Les statisticiens disposeront d’outils puissants leur permettant d’analyser les corréla-
tions, ou d’effectuer des analyses prédictives. Ils se spécialiseront dans l’usage des outils
de data mining (fournis dans la version SQL Server S005 standard et Enterprise). Ils
pourront également se livrer à des scénarios afin d’en mesurer les impacts (Les cubes
en écriture (writeback) associés à des outils tels que Desktop Professional de Proclarity,
permettront aisément de répondre à ce type d’analyse). Rappelons qu’Excel dispose
en standard de fonctions de simulations (Scénario) ou de résolution de problème
(Solver). La version 2007 d’Excel permet grâce au menu d’exploration de données,
d’accéder aux outils de Data Mining de SQL Server 2008. Ces outils nécessitant une
petite formation sont malheureusement peu utilisés.
En conclusion nous pouvons affirmer que plus de 80 % des utilisateurs métier ne
désirent pas passer leur temps à créer des rapports, ou manipuler de l’information. En
revanche ils désirent des rapports ciblés, concis, avec des graphiques clairs. Ils veulent
passer le moins de temps possible à déchiffrer et prendre rapidement les décisions
nécessaires à l’action. Les 20 % restant représentent les analystes. Ils font le plus grand
usage d’outils dynamiques et interactifs.
2.9.2 Règle 2 – Distinguer les décisions stratégiques ou tactiques

Chaque jour des centaines voire des milliers de décisions tactiques sont prises dans les
organisations. Ces décisions émanent de tous les niveaux de la hiérarchie.
Exemples de décisions tactiques :
• Y a-t-il suffisamment de produits en stock pour honorer cette commande ?
• Quelles sont nos meilleures offres de services ou nos produits les plus vendus ce
trimestre ?
• Quelle est notre meilleure offre en termes de mix-produit, de coût, et de pricing
qui préserve nos marges et accroît notre résultat ?
Les décisions stratégiques sont la plupart du temps prises au sommet de la hiérarchie

dans l’organisation. Du fait qu’elles impactent en profondeur l’organisation, elles sont
moins fréquentes que les décisions tactiques.
Exemple de décisions stratégiques :
• devons-nous entrer sur le marché avec une nouvelle ligne de produits ?
• Quels canaux de distribution devons-nous privilégier ?
• Devons-nous augmenter nos parts de marché ou plutôt accroître nos marges ?
• Devons-nous augmenter notre budget marketing, ou être plus efficient en
matière de production ou développer un nouveau produit ?
2.10 Construire le tableau matriciel des besoins 63
Selon que l’utilisateur manipulera des informations tactiques, stratégiques ou les

deux, les outils mis à sa disposition ne seront pas les mêmes.
2.10 CONSTRUIRE LE TABLEAU MATRICIEL

DES BESOINS
Dans un souci d’amélioration du dialogue avec les utilisateurs et afin de permettre aux
chefs de projets de disposer d’un outil de réflexion on sera bien inspiré de mettre en
place quelques tableaux synthétiques définissant les besoins des utilisateurs.
Un tableau général élaboré par le chef de projet BI en présence de tous les acteurs
décisionnels de l’entreprise, permettra de définir le périmètre du projet en recensant
les différents thèmes analytiques à développer ainsi que les axes d’observation.
Les projets d’entreprise recensent les besoins suivants :
Tableau 2.4 — Définir la matrice des besoins métiers

Processus Métier Axes d’observation ou Dimensions
Organisation
Revendeur
Comptes
Produits
Ateliers
Clients
Temps
Analyse des ventes X X X X X

Profitabilité par clients/produits X X X X
Finance. Balance X X X
Production. Gestion de la capacité X X X X
Dans le tableau ci-dessus on observe en colonnes les axes d’observation et en lignes

les processus métiers (en provenance des datamarts). Seules les intersections qui ont
du sens entre les processus métier et les axes d’observation sont matérialisées par
une croix. On parlera de dimensions « conformes » ou partageables entre processus.
L’UDM (cube OLAP) que nous présentons dans les chapitres suivants, permet de
croiser des processus entre plusieurs axes ou dimensions offrant ainsi une capacité
d’analyse démultipliée. Les intersections qui n’ont pas de sens (cellules vides dans
le tableau ci-dessus) seront exclues naturellement du champ d’analyse évitant ainsi
l’affichage de données incohérentes.
L’étape suivante consiste à sélectionner un processus métier puis à décomposer les
axes dimensionnels et introduire les indicateurs.
Prenons le processus métier « Analyse des ventes ». Celui-ci se décompose selon
le tableau 2.5.
Afin de communiquer de façon très visuelle avec l’utilisateur il est recommandé de
présenter une ébauche du résultat final. Excel ou ACCESS permettront de maquetter
l’application finale et de simuler rapidement le résultat attendu.
Analyse des ventes année 2005
150 000
100 000 Qtés cdées
50 000 Qtées
vendues
0 Retours
Roman Sciences Informatique
humaines
Figure 2.9 — Une représentation visuelle est toujours plus parlante pour l’utilisateur
Dans l’exemple présenté à la figure 2.9, Excel permet à l’utilisateur de se déterminer

rapidement sur le résultat attendu par l’utilisateur.
Le tableau 2.5 est un outil incontournable favorisant la représentation des besoins
exprimés par l’utilisateur.
Tableau 2.5 — Tableau des dimensions et indicateurs de la fonction « Analyse des ventes »
Dimensions Indicateurs
Temps Produits Revendeur Clients Organisation
– Année – Ligne Grossiste Enseigne Équipe de vente Qtés
– Trimestre de produit Distributeur Groupement Vendeur cdées
– Mois – Marques VAR Magasins Qtés
– Jour – Catégorie Point de vente vendues
– YTD de produits Marge
(cumul) – Collection
– Croissance – Produit Remises
par période % remise
Prix
moyen
On peut également définir un jeu de test et présenter une ébauche au travers d’un
tableau croisé dynamique (figure 2.10).
Toutes les versions d’Excel (depuis 97) permettent de présenter des résultats sous
forme de tableaux croisés dynamiques. Voici à titre d’exemple l’interface d’Excel 2007
permettant de construire des tableaux croisés dynamiques. Rappelons que les sources
des tableaux croisés peuvent être indifféremment des tables, des listes ou des cubes
OLAP.
2.10 Construire le tableau matriciel des besoins 65
Figure 2.10 — Tableau croisé dynamique avec Excel (Ici version 2007)
3
Comment représenter
les données ?
L’aptitude à représenter graphiquement des données numériques n’est pas intuitive.

Elle requiert certaines compétences qui doivent être acquises. Ce chapitre introduit
les meilleures pratiques en matière de conception graphique.
Dans le monde des affaires, aucune information n’est plus importante qu’une infor-
mation quantitative. Les nombres mesurent la performance, repèrent les opportunités
et prévoient le futur. L’information quantitative est souvent présentée sous forme de
graphique. Malheureusement, la plupart des graphes utilisés dans le monde des affaires
sont mal conçus. Pourquoi ? Tout simplement parce que la plupart des auteurs qui
les produisent, y compris des spécialistes tels que les financiers et les développeurs de
rapports, n’ont pas été formés à la représentation graphique efficace.
Ce chapitre est une introduction à la représentation pratique des données, dans
le but d’établir une meilleure communication entre le créateur d’un tableau et son
lecteur. Heureusement, les compétences nécessaires pour traduire et communiquer
efficacement la plupart des données d’affaires ne requièrent pas un diplôme spécialisé
en statistiques. En fait, ces compétences sont aisées à acquérir mais un apprentissage
est néanmoins nécessaire.
Le processus tient dans les six étapes suivantes :
• Préciser le message à communiquer et identifier les données nécessaires à sa
communication.
• Déterminer si un tableau de chiffres, un graphe ou une combinaison des deux
est nécessaire à la communication.
68 Chapitre 3. Comment représenter les données ?
Si un graphe est nécessaire, on observe alors les quatre étapes suivantes :

• Déterminer le meilleur moyen pour représenter visuellement les valeurs numé-
riques.
• Déterminer comment afficher chaque variable.
• Déterminer le meilleur rendu graphique.
• Déterminer si des données particulières doivent être mises en évidence. Si oui,
comment ?
3.1 CONCEPTS GÉNÉRAUX ET PRATIQUES
Avant d’approfondir le processus de conception des graphes, il y a quelques concepts

généraux que le lecteur doit connaître et qui s’appliquent en toutes circonstances.
3.1.1 Tableaux ou graphiques ?

En général, lorsque l’on compare les modes de représentation dans le but de présenter
des données quantitatives, il n’y a pas à préférer a priori entre une représentation sous
forme de tableaux de chiffres ou de graphes. Les deux modes de représentation sont
simplement différents.
Définissons quelques termes.
Tableau 3.1
Tableau Graphique
Les données sont représentées sous forme Les données sont traduites en images.
de nombres.
Les données sont disposées en lignes Les données sont affichées en relation sur un
et colonnes. ou plusieurs axes matérialisés par une échelle
qui donne du sens aux valeurs.
Les tableaux sont particulièrement utiles lorsqu’il s’agit de montrer des valeurs
précises.
En revanche les graphiques sont préférés lorsque le message à communiquer réside
d’avantage dans la forme que la précision des valeurs (c’est-à-dire des modèles, des
tendances ou des exceptions).
Dans le tableau suivant, on observe des taux de change présentés par année et par
mois.
3.1 Concepts généraux et pratiques 69
Figure 3.1 — Tableau de valeurs
Figure 3.2 — Représentation graphique de données
Si vous désirez connaître une valeur précise telle que le taux de mai 1996, le
tableau permet d’y répondre de la meilleure façon possible. En revanche, si vous
désirez connaître l’évolution du taux sur l’année 1996 ou de la comparer avec l’année
1997, le graphique sera une bien meilleure représentation (figure 3.2).
3.1.2 Données quantitatives ou catégorielles ?

Les données quantitatives ne renferment pas seulement des nombres, mais aussi des
données qui identifient le sens des données.
Dans un graphique on distingue les données quantitatives – les nombres – des
données catégorielles – les étiquettes qui précisent ce que les nombres mesurent.
Le graphe ci-après (figure 3.3) met en évidence la distinction entre les données
catégorielles représentées par l’étiquette de chaque série de données et les données
quantitatives sur l’axe vertical des ordonnées.
Figure 3.3 — Graphe présentant des données catégorielles et quantitatives
Les trois types d’échelles catégorielles

Les échelles catégorielles se subdivisent en trois types fondamentaux : nominal, ordinal
et intervalle (figure 3.4).
L’échelle nominale consiste en des données discrètes qui appartiennent à une caté-
gorie commune, sans présenter de rapport avec d’autres données. Typiquement nous
retrouvons des notions de régions (Amérique, Asie, Europe, etc.) ou départements
(ventes, marketing, finance, production).
Figure 3.4 — Les trois types d’échelles catégorielles
Les données qui relèvent d’une échelle ordinale ont un ordre intrinsèque mais ne
représentent pas de données numériques. Il s’agit par exemple de classements tels que
petit, moyen, grand, ou mauvais, médiocre, moyen, bon, excellent ou rouge vert, bleu,
jaune.
Les données qui qualifient des intervalles non seulement définissent un certain
ordre mais représentent également des valeurs. Il s’agit par exemple de séries de plages
de valeurs de taille égale. Exemple : tranche 1 de 0 à 99, tranche 2 de 100 à 199, tranche
3 de 200 à 299, tranche 4 de 300 à 399, etc.
Les sept relations en données quantitatives

Un nombre en tant que tel ne présente pas d’intérêt. En revanche, lorsqu’il est comparé
à d’autres nombres il prend tout son sens. 7 500 € de consommation électrique dans
mon immeuble cette année ne sont pas très révélateurs. En revanche lorsque j’observe
que cette valeur est 40 % supérieure à celle de l’année dernière à pareille époque, cela
devient une alerte qui sera probablement suivie d’une action (recherche de la cause et
mise en place du remède).
La plupart des données quantitatives peuvent être classifiées selon leur mode de
relation entre elles. Voici les types de relation les plus fréquemment rencontrés.
1. Relations de séries temporelles

Lorsque des valeurs quantitatives représentent une série de mesures prises à intervalles
réguliers, ce type de relation est appelé série temporelle (figure 3.5). Il s’agit du type
de graphe le plus répandu. En effet, 75 % des graphiques d’entreprises concernent
des séries temporelles. Le temps peut être divisé en périodes de durées variables telles
qu’années, trimestres, mois, semaines, jours, heures et secondes.
Figure 3.5 — Graphique représentant une série temporelle
Ce type de graphique montre bien les mouvements à la hausse ou à la baisse au

fil du temps. Les séries temporelles, révèlent des tendances ou des modèles qu’il est
nécessaire de décrypter afin de prendre les décisions qui s’imposent.
2. Relations de classement avec tri par ordre croissant

Lorsque des données quantitatives sont présentées selon un ordre croissant ou
décroissant ce type de relation porte le nom de classement.
Adhérent actif 1 REGION (Tous)
Répartition par fonction
Nb Adhérents
10
nt
de
18
si
ré
r d e- p
té
Nombre de membres
ivi
c
ct
Vi 40
'a
t
in
eu
o
dj
ct
107 Déposer
re
.a
Di
eu D.G
e champs
sit
Type de fonction
e
190 de séries
rd
ici
n
io
ct
t
re
nc
350
Di
fo
tre
t
an
Au
ér
643
G
n
t io
c
708
g é dire
al
tre
ér
Au
1279
r
eu
t
en
ct
id
re
0 200 400 600 800 1000 1200 1400

és
Di
Pr
u
.o
.G
D
P.
Fonction
Figure 3.6 — Relation de classement décroissant
On utilise souvent ce mode de représentation pour classer les performances des

vendeurs ou les dépenses effectives des départements de l’entreprise. Ce type de graphe
révèle non seulement l’ordre de classement mais permet également de rapprocher et
de comparer certains groupes entre eux.
3. Relations de partie d’un tout

Dans ce contexte, les valeurs affichées révèlent le poids de chaque part en rapport avec
la globalité. Ce type de représentation est utile pour représenter la façon dont une
entité est divisée en parties. Dans l’exemple de la figure 3.7, on observe la répartition
en pourcentage des membres d’une association par type de fonction.
Répartition des membres en %
40,0% 38,2%
35,0%
30,0%
25,0%
21,2%
19,2%
20,0%
15,0%
10,5%
10,0%
5,7%
5,0% 3,2%
1,2% 0,5% 0,3%
0,0%
sid ent
djo int
ral
ite
ité
G éra nt
ir ection
nction
s ident
ur de s
tiv
ur géné
ur d'ac
D.G . a
ou P ré
Vice-pré
Autre fo
Autre d
Dir ec te
Dir ec te
Dir ec te
P.D.G .
Type de m em bres
Figure 3.7 — Graphe de relation de type « partie d’un tout »

Pour montrer la part des différents éléments par rapport à l’ensemble, le meilleur
moyen est d’utiliser un arbre de décomposition (voir la section 3.2.1).
4. Relations d’écart ou de déviation

Lorsque des valeurs affichent des écarts entre des objectifs prévisibles et des réalisations
effectives, on utilise une relation de type écart (figure 3.8).
Production Prévu/Réalisé
30
25
25
20 20
18
20 17
en M €
14 13 Prévu
15
10 Réalisé
10
5
0
Janvier février mars Avril
Année 2006
Figure 3.8 — Graphe de type écart
Un exemple courant de ce type de graphe est celui qui rapproche des données
actuelles, par exemple des dépenses, par rapport à des données prévues – celles d’un
budget.
L’exemple de la figure 3.9 présente une variante du graphe d’écart. Seul l’écart
constaté est représenté. Il apparaît soit en positif (au-dessus de l’axe des abscisses) soit
en négatif (en dessous de l’axe des abscisses).
Dans le cas présent on créera une mesure calculée écart telle que :
écart = Réalisé – Prévu.
Ce type de rapport ne permet cependant pas de mesurer si l’écart est maîtrisé
ou considéré comme normal. La technique du KPI (indicateur clé de performance)
permet de pallier cela par l’ajout d’une composante telle que la tendance.
Exemple des ventes

Supposons que vous désiriez un état et une tendance des ventes et rapprocher la cible
de la mesure de prévision.
La figure 3.10 montre le nouvel indicateur clé de performance (KPI) pour les
catégories de produit. La couleur des drapeaux (Vert, rouge ou blanc) permet
d’identifier immédiatement le statut de l’indicateur (Bon, Mauvais, Moyen...). La
figure 3.10 permet d’observer que les ventes des « Business PCs » ont enregistré une
meilleure performance que les prévisions. Nous observons également que les ventes
de serveurs ont été bonnes jusqu’au dernier trimestre où elles ont chuté de manière
significative par rapport aux prévisions.
Écarts de production
20
15
15
10
en M €
5 3
–2 –1
0
Janvier février mars Avril
–5
Année 2006
Figure 3.9 — Variante du graphe d’écart
Figure 3.10 — Représentation d’un KPI. Avec représentation de la tendance
Les flèches quant à elles, montrent les évolutions de croissance. Les flèches sont
orientées vers le haut lorsque la croissance est supérieure à la période précédente, vers
le bas lorsque la croissance est négative.
5. Relation de distribution
Un graphe de distribution permet de représenter comment un ensemble de données
se répartit au sein d’un spectre unique. Il permet de représenter des phénomènes de
concentration ou d’absence de données. On peut parfois observer des phénomènes de
symétrie (courbe normale, ou courbe en cloche).
L’exemple de la figure 3.11 montre un pic de participation à un club professionnel
entre 44 et 55 ans, puis un départ brutal à 60 ans.
6. Relation de corrélation
Un graphe de corrélation mesure le rapport qui existe ou non entre deux variables.
Dans l’exemple ci-dessous il ne semble pas exister de rapport entre la taille d’un
employé et son salaire (la répartition des points est disparate).
Lorsqu’une corrélation est observée, les points ont tendance à se superposer à une
droite souvent matérialisée par la diagonale du graphe (figure 3.12).
120
100
80
60
40
20
0
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
72
73
79
Figure 3.11 — Répartition des membres par âge
Figure 3.12 — Relation de corrélation
7. Relation de comparaison nominale

Dans un graphe de comparaison nominale, il n’existe pas de lien entre les variables
portées sur l’axe des X. Dans la figure 3.13, les quatre régions géographiques n’ont
aucun lien entre elles et leur ordre ne présente pas d’importance. Tout au plus, est-il
possible de présenter les variables selon un ordre croissant ou décroissant afin d’établir
un classement.
Figure 3.13 — Graphe présentant la relation de comparaison nominale
Exemple de cheminement d’une analyse des ventes
Figure 3.14 — Graphe d’analyse des ventes
La figure 3.14 montre que les performances des ventes au troisième trimestre ont
été particulièrement élevées pour la Californie. Le lecteur peut souhaiter étudier plus
en détail ces chiffres. Il peut être amené à se poser des questions complémentaires,
par exemple : dans quelles villes ces ventes ont-elles été réalisées ? Quels produits ont
contribué à ce résultat et dans quelles proportions ? Nous verrons plus loin que la
technique du forage progressif ( drill down) permet de répondre quasi instantanément
à de nombreuses questions selon un cheminement a priori imprévisible.
3.2 Les nouveaux outils offerts par le complément proclarity 77
Déterminer le meilleur moyen pour représenter les valeurs
Tableau 3.2 — Type de relation et méthode de représentation
Type de relation Méthodes privilégiées

pour la représentation
Séries temporelles Lignes mettant en exergue l’évolution des données
dans le temps
Classement Barres horizontales ou verticales
Points
Tout ou partie Barres
Barres empilées
Secteurs dont les parties sont matérialisées par un %
Déviation/Écart/ Histogrammes doubles par mesure
Budget/Réalisé Histogramme représentant l’écart
Fréquence de distribution Barres verticales (histogrammes)
Lignes (polygone de fréquence)
Corrélation Nuage de points avec ligne de tendance
Comparaison nominale Barres horizontales ou verticales
Points
Écart sur objectifs et tendances KPI (feux tricolores, flèches)
3.2 LES NOUVEAUX OUTILS OFFERTS

PAR LE COMPLÉMENT PROCLARITY
3.2.1 L’ arbre de décomposition1
State
California
3M 100 %
City
San Jose Los Angeles San Francisco

2 304 K 74 % 773 K 25 % 46 K 1%
Product
Alpha IIp750 Alpha IIp1K Omega J – 500 Ml-562 Omega J – 750 Mx Mark Xl/136 10 derniers
837 K 36 % 435 K 19 % 404 K 18 % 158 K 7% 141 K 6% 65 K 3% 262 K 11 %
Figure 3.15 — La représentation en arbre

de décomposition permet une analyse non déterministe
1. Proclarity : société éditrice de logiciels basés sur les technologies OLAP de Microsoft. Cette société
a été acquise par Microsoft en avril 2006.
L’arbre de décomposition permet d’analyser des données selon des cheminements

non déterminés à l’avance. Dans l’exemple ci-dessous, nous désirons approfondir
l’activité de ventes par produits et par ville dans l’État de Californie.
3.2.2 La carte de performance

Vous souhaitez analyser les ventes du troisième trimestre et leur augmentation ville
par ville en Californie. Les cartes de performances sont un outil idéal pour analyser les
performances et évolutions relatives. Nous commençons avec une grille représentant
les ventes et leur augmentation par rapport à la période précédente pour les villes de
Los Angeles, San Francisco et San Jose pour le troisième trimestre 2002.
Figure 3.16 — La carte de performance
Les villes sont maintenant regroupées par ligne de produits (PC et périphériques).
Les ventes sont en hausse dans toutes les villes, à l’exception des ventes de PC à Los
Angeles. (Los Angeles a subi une baisse de 77,6 % de ses ventes). La croissance la plus
élevée a été enregistrée pour les ventes de périphériques à San Jose, comme l’indique
la couleur claire en bas à droite.
Supposons maintenant que vous souhaitiez connaître le profil des clients à l’origine
de cette hausse des ventes de périphériques à San Jose. Il faut afficher uniquement
les données relatives aux périphériques et décomposer les ventes de périphériques
réalisées à San Jose par type de client (figure 3.17).
3.2 Les nouveaux outils offerts par le complément proclarity 79
Figure 3.17 — Autre représentation de la carte de performance
3.2.3 La vue en perspective

Supposons maintenant que vous souhaitiez modifier votre analyse pour connaître le
rapport entre le volume des ventes et celui de la facturation pour chaque ville. Pour
comparer un vaste volume de données entre deux mesures, vous utiliserez une vue en
perspective.
Figure 3.18 — Vue en perspective
Les vues en perspective sont un outil très utile pour détecter les écarts et identifier
ainsi les représentations de données qui sortent nettement de la norme. Par exemple, la
ville de New York (représentation de données en haut à droite) se distingue clairement

puisqu’elle présente à la fois le volume de ventes et le volume de factures le plus élevé.
Cette vue en perspective fait ressortir d’autres informations :
• par rapport à New York, Chicago (représentation de données comprise entre 6
et 8 millions de dollars de ventes) a enregistré pratiquement autant de factures,
mais nettement moins de ventes ;
• aucune ville ne présente un ratio très déséquilibré Volume de factures
faible/Volume de ventes élevé ;
• dans la zone représentant moins de 2 millions de dollars de ventes, une ville
présente un volume de factures élevé pour des ventes médiocres (Cleveland).
4
Entrepôt de données
et analyse décisionnelle
Ce chapitre présente succinctement les outils ainsi que les nouvelles méthodes de
développement de processus décisionnels qui en découlent.
Lors des consultations de Business Intelligence et de tableaux de bord que nous
donnons en entreprise, nous sommes souvent confrontés à deux types de réaction de
la part des managers et responsables informatiques.
D’un côté, les managers qui réfléchissent en termes de métier comprennent
aisément le concept d’entrepôt de données centralisateur de toutes les informations
de l’entreprise et de leur historisation. Ils adhèrent volontiers à la notion de tableau
de bord de pilotage et comprennent spontanément le concept d’indicateurs et d’axes
d’analyse de leur métier. Les responsables opérationnels s’interrogent même sur le
fait que de telles solutions n’ont pas déjà été mises en place dans leur organisation.
Intuitivement, ils conçoivent que l’informatique devrait les aider dans ce domaine.
Et pourtant la technique de collecte des données de l’entreprise ressemble souvent
au parcours du combattant avec ses innombrables ressaisies manuelles, ses tableaux
mensuels déconnectés les uns des autres ne permettant aucune consolidation annuelle.
L’analyse sur deux années n’est souvent pas à l’ordre du jour. La synthèse s’effectue
dans un document final souvent réalisé grâce à un logiciel de PAO. Les cadres, dont la
vocation est de réfléchir à la stratégie de l’entreprise, passent une grande partie de leur
temps à collecter l’information. Privés de leur capacité d’analyse, ils s’interrogent sur
leur valeur ajoutée dans l’organisation. Par manque de temps et surtout d’outils d’aide
à la décision, ils ne peuvent prendre suffisamment de hauteur. Ils restent dépendants
d’un système d’information vis-à-vis duquel ils mesurent leur incapacité à le faire
évoluer.
82 Chapitre 4. Entrepôt de données et analyse décisionnelle
D’un autre côté, les responsables des systèmes d’information passent une grande
partie de leur activité à maintenir en état de fonctionnement des organisations
techniques complexes. Les nombreuses fusions et acquisitions constatées ces dernières
années ont contraint les responsables IT à faire communiquer des systèmes qui a priori
n’avaient rien de commun tant sur le plan technique que fonctionnel. Par ailleurs, les
systèmes décisionnels disponibles depuis quelques années sur le marché nécessitaient
des équipes ultra-spécialisées à tous les niveaux de la conception, les rendant de ce
fait très coûteux.
Tableau 4.1 — Répartition des modules SQL Server 2008 par composants
Composant Module SQL Server 2008 Destination dans l’entreprise

WorkFlow + Flux Integration services Administrateur de bases
de données (ETL) de données
Entrepôt de données Base de données relationnelle Administrateur et développeur
relationnel SQL Server 2008
et multidimensionnel
Base de données Analysis services Développeur et utilisateur
multidimensionnelle ayant des connaissances métier
analytique (Key User)
Exploration de données Data Mining intégré à Analysis Statisticien et/ou (Key User)
services
Création de rapports et de Reporting Services Designer Développeur et Key User
modèles sémantiques métier
Requêtes et analyses Report Builder 1.0 et 2.0, Excel Analystes métier
spécifiques 200X, Proclarity (cubes Olap),
Office web component. (Excel
2007 pour la lecture des KPI).
PerformancePoint Monitor
et Analytics.
Développement SQL Server Business Développeur
d’application BI Intelligence Development
Studio (BIDS) = Visual Studio
pour BI
Outils de gestion de base SQL Server Management Administrateurs/développeurs
de données Studio
Services de notification SQL Server Notification Alertes envoyées aux managers
Services sur des événements métier
(rupture de stock, etc.)
Conscient de ces faiblesses et profitant d’une expérience de plus de quinze années,

Microsoft a tenté de mettre en place une solution susceptible de satisfaire aussi bien les
managers soucieux de maîtriser leur métier que les techniciens garants de l’intégrité
des systèmes d’information de l’entreprise.
Le tableau 4.1 présente une vue d’ensemble des composants d’un système de
Business Intelligence et de leur destination dans l’entreprise.
On peut également répartir les outils selon un axe fonctionnel (tableau 4.2).
4.1 Architecture de la plate-forme décisionnelle 83
Tableau 4.2 — Répartition des modules par tâche fonctionnelle
Fonction Outil disponible Particularité

Conception BIDS (Business Intelligence Development Le développement de script permet
Studio) construit sur le modèle de Visual un débogage dans tous
Studio les composants BI
Synthèse Integration Services (SSIS) Présente une vision transparente
des données de sources hétérogènes.
Le partitionnement simplifie
et optimise la gestion des données
historiques
Stockage UDM (Unified Data Model) permet La mise en cache proactive permet
d’unifier le monde relationnel un stockage en temps réel
et multidimensionnel (SSAS) des données transactionnelles
Analyse Les cubes multidimensionnels, Les KPI (indicateurs clés de
les perspectives, les algorithmes de data performance) participent
mining (SSAS) à l’élaboration du tableau de bord
Restitution Reporting Services et Report Builder La diffusion est automatisée
sont administrés via des services Web. sous forme d’abonnement
Les formats de restitution sont divers auprès des utilisateurs
(Excel, PDF, XML, CSV, Rtf (Word) etc.)
Gestion SQL Server Management studio intègre Administration centralisée et intuitive
la gestion de tous les composants de SQL permettant une mise en œuvre aisée
Server dans les petites et moyennes
structures
Alertes SQL Notification Services Transmission de messages
de notifications sur la base
d’événements programmés
4.1 ARCHITECTURE DE LA PLATE-FORME

DÉCISIONNELLE
Lorsque les administrateurs mettent en œuvre SQL Server 2008, les modules suivants
sont installés :
• Moteur de la base de données relationnelle ;
• Integration services ;
• Analysis Services ;
• •Reporting Services (Introduit la nouvelle architecture de serveur de rapports
qui inclut la prise en charge native des fonctionnalités précédemment fournies
par les Services Internet (IIS) ;
• Report Builder 1.0 est intégré nativement à Reporting Services (Générateur de
rapports observable dans le Portail Reporting Services)
• SQL Server Management Studio pour la gestion des bases de données ;
• BIDS (Business Intelligence Development Studio) pour le développement d’appli-
cations BI.
Les modules suivants peuvent être installés séparément par l’Administrateur :

• Le site Open Source de Microsoft www.codeplex.com, rubrique SQL Server,
offre toute une panoplie d’outils complémentaires.
• BIDS Helper : Complément très utile à l’outil de développement fourni en
standard (BIDS). Cet add-in qui existe aussi pour la version SQL Server 2005
offre des outils d’aide au développement des packages SSIS ainsi que des cubes
SSAS (gestion fine des agrégats et optimisation des hiérarchies utilisateur).
• Les exemples fournis avec la version SQL Server 2008 (Bases de données
AdventureWorks 2008, Reports, cubes etc.).
• Le site de Microsoft (http://www.microsoft.com/downloads) permet le téléchar-
gement du module Report Builder 2.0, outil de création de rapports ad hoc.
• Il s’agit de la version « utilisateur » du Report Designer de SQL Server 2008.
Les utilisateurs avertis pourront utiliser cet outil qui s’installe sur le poste client
comme un ActiveX. L’interface de cet add-in intègre le ruban d’Office 2007 et
offre une grande convivialité. Il est un complément, sans le remplacer, de la
version Report Builder 1.0. Il permettra en effet de créer des rapports faisant
appel simultanément aux tableaux, matrices et graphes, ce que ne permet pas de
réaliser Report Builder 1.0
Les informations de métadonnées d’Analysis Services sont stockées sous forme

de fichiers XML et totalement gérées dans un projet de type Analysis Services. Les
fichiers XML, dont les formats sont documentés par Microsoft, sont observables via
un éditeur XML ou un simple bloc-notes.
Dans le module SSIS (SQL Server Integration Services), certains paramétrages
nécessitent d’intervenir manuellement dans des fichiers de configuration XML (fichier
portant l’extension .dtsconfig). À la différence d’un éditeur de texte (notepad) BIDS
permet une présentation structurée ces fichiers. L’éditeur intégré à BIDS permet
également d’apporter des modifications dans les fichiers XML de configuration. BIDS
est conçu pour développer et déboguer les applications BI tandis que Management
Studio permet d’utiliser et de gérer les objets de bases de données.
Le modèle dimensionnel unifié intègre définitivement les bases de données
relationnelles et la modélisation multidimensionnelle OLAP.
Les défis et les promesses de l’analyse décisionnelle reposent sur la communication
aux employés d’informations correctes, au moment opportun. La mise en œuvre de cet
objectif requiert une analyse décisionnelle exhaustive, sécurisée, intégrée aux systèmes
opérationnels et disponible 24 heures sur 24, 7 jours sur 7. Cet objectif est atteint
grâce à l’architecture de SQL Server.
• Plate-forme intégrée. SQL Server 2008 constitue une plate-forme d’analyse
décisionnelle et analytique de bout en bout qui intègre OLAP (On Line
Analytical Processing), la fouille de données (data mining), les outils ETL
(Extract, Transform and Load) d’extraction, de transformation et de chargement
de données, les entrepôts de données et des fonctionnalités de rapports.
4.2 Comment simplifier le monde réel ? 85
• Prise de décision améliorée. Les améliorations des fonctions décisionnelles

existantes, comme OLAP la fouille de données, et la mise en place d’un nouveau
serveur de rapports intégrant nativement les fonctionnalités de IIS, fournissent
aux entreprises les moyens d’exploiter les informations pour de meilleures prises
de décision, à tous les niveaux.
Figure 4.1 — Le modèle dimensionnel unifié (Unified Dimensional Model)

se substitue à Analysis Services
• Sécurité et disponibilité. Des améliorations en termes de capacité à monter

en charge, de disponibilité et de sécurité offrent aux utilisateurs un accès
ininterrompu aux rapports et aux applications décisionnelles.
• Fonctionnalités d’analyse au niveau de l’entreprise. L’outil ETL incorporé dans
un workflow permet aux organisations d’intégrer et d’analyser plus facilement
les données en provenance de diverses sources d’informations. En analysant les
données sur une large gamme de systèmes opérationnels (ERP basés sur tous
types de plate-forme), les organisations pourront obtenir un avantage sur leurs
concurrents grâce à une meilleure compréhension de leurs activités.
4.2 COMMENT SIMPLIFIER LE MONDE RÉEL ?
SQL Server 2008, en plus d’offrir des innovations nombreuses en matière de SGBD,
répond à plusieurs défis propres à la Business Intelligence. Les composants intégrés dans
l’interface graphique de Visual Studio permettent un développement et un déploie-
ment aisés de la BI. Au risque d’apparaître moins académique que ses concurrents,
Microsoft veut démocratiser la Business Intelligence en la rendant accessible au plus
grand nombre.
4.2.1 Actuellement, comment développons-nous un projet BI ?

Avec Ralph Kimball, nous avons appris au chapitre précédent quelles sont les règles
fondamentales à observer dans le cadre d’un projet BI. Rappelons-les brièvement :
les données sont extraites des systèmes opérationnels (ERP, comptabilité, paie, etc.)
en général chaque jour. L’étape suivante consiste à transformer les données brutes
avant de les charger dans un datawarehouse relationnel/multidimensionnel. Une fois
le datawarehouse mis à jour, les données sont à nouveau extraites dans un ou plusieurs
cubes OLAP hiérarchiques/multidimensionnels afin d’être présentées sous une forme
plus « lisible » aux utilisateurs. Pendant la journée, les décisionnaires effectuent toutes
sortes de requêtes sur les cubes. La nuit suivante, le cycle est à nouveau répété, et
les datamarts sont rafraîchis grâce aux nouvelles données de la veille. En général,
les administrateurs de systèmes BI préfèrent définir plusieurs datamarts métier plutôt
qu’un unique datawarehouse. Nous verrons dans les chapitres suivants que les notions
de datamart et datawarehouse peuvent être désormais confondues dans le modèle
UDM (Unified Dimensional Model). Ce modèle tente de relever plusieurs défis.
4.2.2 Quels sont les défis à relever ?

Le processus décrit ci-dessus est le plus couramment suivi par les entreprises. Il a le
mérite d’être compréhensible et donne souvent satisfaction. Cela ne veut pas dire
qu’il est parfait. Loin s’en faut !
Défi n◦ 1 : Différentes versions de la vérité

Un problème majeur, engendré par l’utilisation de multiples modèles dimensionnels
réside dans le rapprochement de plusieurs cubes. Un peu comme une requête ou vue
composée de plusieurs tables jointes entre elles par des clés, il est possible de créer un
cube « virtuel » en fusionnant plusieurs cubes, cela si les cubes élémentaires partagent
les mêmes dimensions.
Par exemple si nous disposons de trois cubes différents, chacun présente une
dimension « Client » propre. Dans le premier cube, la notion de client se définit
comme : « toute personne qui a commandé un article depuis 2 ans ». Dans le deuxième,
un client représente « toute personne qui présente un chiffre d’affaires de plus de 10
k€ ». Dans le troisième cube, le client est « toute personne qui dispose d’une adresse
complète et valide ». Nous le voyons, ces trois cubes ont été développés pour des
départements différents et présentent un sens différent. Maintenant, imaginez que le
directeur de chaque département décide de présenter dans un tableau de synthèse les
dépenses annuelles de publicité réalisées par client. Les résultats, bien que différents,
paraîtront à chacun cohérents. Si les trois dirigeants tentent maintenant de confronter
leurs résultats, des écarts sensibles apparaîtront. La raison en est que la dimension
Client est interne à chaque cube et non partagée par l’ensemble des trois cubes. Nous
montrerons comment UDM fournit une réponse élégante à ce problème.
4.2 Comment simplifier le monde réel ? 87
Défi n◦ 2 : Recopie multiple des données

Les modèles classiques de BI maintiennent au moins deux copies des données en plus
de la donnée originale ; une dans le datawarehouse global, une autre dans le datamart
métier. Comme les cubes sont indépendants, il n’est pas rare non plus de constater
que les données sont dupliquées entre les datamarts. Non seulement cette technique
est très coûteuse en espace disque, mais elle met encore une fois en évidence la notion
de « versions différentes de la vérité ».
Défi n◦ 3 : La localisation des données est difficile

La localisation est le procédé qui permet de présenter l’information aux différents
utilisateurs dans leur propre langue et dans la monnaie de leur pays. Les systèmes
actuels ne permettent pas de disposer de traductions des hiérarchies de dimensions
ainsi que des contenus des membres de dimensions.
Lors d’une interrogation de la base articles, si votre langue naturelle est celle de
Molière, laquelle de ces deux réponses préférez-vous recevoir du système ?
Item : Road-550-W Yellow, 40 Same technology as all of our Road series bikes, but
the frame is sized for a woman. Perfect all-around bike for road or racing.
Ou
Article Vélo de route 550 – W – jaune, 40 Équipé de la même technologie que tous
nos vélos de route, avec un cadre femme. Idéal pour la promenade ou la course sur
route.
Défi n◦ 4 : Le schéma en étoile ne permet pas de modéliser la complexité des données

Un modèle dimensionnel traditionnel est un schéma en étoile constitué d’une table
de fait centrale et d’un certain nombre de dimensions. Il existe des options pour la
création de schéma en flocon, de dimensions de type « parent-enfant » ou la mise
à jour de « dimensions à variation lente ». Mais, dans la vie courante, il n’est pas
exclu de rencontrer des relations plusieurs à plusieurs au niveau des tables de faits
(exemple : un compte bancaire est ouvert au nom de plusieurs propriétaires et chaque
propriétaire dispose d’un ou plusieurs comptes bancaires. Une commande peut faire
état de plusieurs adresses d’expédition, une adresse peut à son tour faire l’objet de
plusieurs commandes).
Un autre exemple concerne les dimensions à multiples hiérarchies. En effet, la
dimension temporelle est-elle basée sur le calendrier classique ou le calendrier fiscal ?
Que penser encore des dimensions composées uniquement d’attributs non hiérar-
chiques. Par exemple, les clients ont des attributs tels que le genre, l’âge, le nombre
d’enfants, la tranche de revenus etc. À l’évidence, ces attributs appartiennent bien au
même client mais ne présentent pas de caractère hiérarchique entre eux.
Défi n◦ 5 : Les systèmes BI actuels ne permettent pas le rafraîchissement

de données OLAP en temps réel
Les décisionnaires réclament des informations à jour avant de prendre leurs décisions.
Il existe de plus en plus de situations dans lesquelles l’analyse des données en temps
réel est nécessaire (exemple : dans un hypermarché, l’analyse d’un rayon quart d’heure
par quart d’heure permet de suivre l’efficacité des messages sonores diffusés dans le
magasin. L’analyse du ticket de caisse en quasi temps réel permet de détecter des
corrélations entre la vente de certains produits et la présence d’un commercial sur le
terrain).
Dans notre ouvrage précédent nous avons largement présenté les améliorations
apportées à la version SQL Server 2005. Ces nouveaux apports permettaient de
répondre aux défis énoncés ci-dessus.
En annexe de cet ouvrage, le lecteur pourra prendre connaissance des nouveautés
apportées dans les trois modules principaux SQL Server 2008.
5
Introduction
à Integration Services
Quel que soit le projet de Business Intelligence, le processus d’ETL a pour seul but de
fournir de solides fondations au référentiel de données et aux fonctions de reporting
et d’analyse. Nous pensons que la phase d’ETL doit être menée avec une vigilance
toute particulière car elle conditionne la qualité de la chaîne décisionnelle.
Ce chapitre a pour objectif de présenter les différents composants d’Integration
Services associé à Business Intelligence Development Studio. Nous introduirons
différents concepts tels que les flux de contrôle et les flux de données. Nous présenterons
les nombreux outils et assistants dont la vocation est de simplifier le travail de
programmation ou d’administration des techniciens de la Business Intelligence. Afin
d’illustrer SSIS, nous procéderons à la génération automatique d’un lot visant à
alimenter une table de dimension dans l’entrepôt de données. Nous présenterons les
différentes tâches qui ont été créées automatiquement et découvrirons leur contenu
avant de créer un lot de toutes pièces.
Nous donnerons également un aperçu de l’ensemble des tâches inclus dans les flux
de contrôle et les flux de données.
5.1 PRÉSENTATION DE SQL SERVER INTEGRATION

SERVICES (SSIS)
SSIS met à la disposition de l’administrateur de base de données et du développeur
un ensemble d’outils permettant de résoudre, quasiment sans programmation, des
tâches qui rentrent naturellement dans le développement d’applications décisionnelles
90 Chapitre 5. Introduction à Integration Services
mais également dans tout processus de manipulation de données (figure 5.1). Les
administrateurs de base de données et les développeurs avaient l’habitude de coder les
tâches d’administration. Au prix d’un nouvel apprentissage, ils trouveront dorénavant
des outils d’amélioration de leur productivité.
Figure 5.1 — Positionnement de Integration Services dans la chaîne décisionnelle
Il est assez fréquent de comparer Integration Services à un ETL (Extract, Trans-

formation, Loading). SSIS englobe naturellement un outil d’ETL que nous allons
développer dans les paragraphes suivants. Mais il convient de noter que la tâche ETL
n’est qu’un composant parmi les nombreux qui constituent un véritable workFlow.
Rappelons qu’un workflow décrit le circuit de validation de tâches qui participent à un
processus métier. En effet la partie de SSIS appelée Flux de Contrôle permet d’effectuer
un enchaînement de tâches de haut niveau telles que des tâches administratives sur
les SGBD ou les serveurs. Il permet par ailleurs d’effectuer des transferts de données
entre plusieurs sites, d’en garder la traçabilité, de communiquer sous différentes
formes (envoi de mails, messages, alertes) avec l’ensemble des acteurs participants à la
valorisation de la chaîne informationnelle.
Nous verrons plus loin que l’une des tâches du Flux de contrôle consiste à traiter
la phase d’ETL. Cette tâche porte le nom de Flux de données.
La figure 5.2 montre le regroupement d’un grand nombre de tâches dans un même
et unique module. Cette démarche permet la modularité de tâches complexes et en
même temps leur centralisation dans un même processus. On peut synthétiser les
améliorations de SSIS par rapport à DTS comme suit :
• l’intégration des données et la création de l’entrepôt sont réalisées au moyen
d’une seule opération ;
• la récupération, la préparation et le chargement des données s’effectuent dans
un seul processus auditable ;
• la gestion de très gros volumes de données est possible.
5.1 Présentation de SQL Server Integration Services (SSIS) 91
Figure 5.2 — Le cycle Integration Services (source Microsoft)
Afin d’illustrer concrètement le domaine d’application de SSIS, nous allons passer

en revue quelques-unes des fonctionnalités.
Fusion de données à partir de bases hétérogènes

Nous l’avons déjà dit, les données d’entreprises sont généralement stockées au sein de
différents silos répartis sur des plates-formes géographiquement éloignées et dans des
formats disparates (Excel, Access, Oracle, DB2, ERP propriétaire, etc.). SSIS permet
d’accéder à un grand nombre de sources de données (.NET, OLE DB, ODBC, XML,
fichiers plats) afin de les rendre compatibles entre elles dans leur format physique et
homogènes dans leur contenu.
Ce processus est pris en charge par le mécanisme des flux de données. Ce dernier
utilise trois types de composants : sources des flux de données, transformation des flux
de données, destination des flux de données.
Alimentation des entrepôts de données et Datamart

Par nature, un ETL est chargé d’extraire des données, de les transformer et de les
charger dans un entrepôt métier également appelé datamart. SSIS n’échappe pas à
cette règle. Ces tâches répétitives et parfois complexes, doivent être consignées dans
un enchaînement de tâches élémentaires. Chacune de ces tâches est destinée à la
manipulation des données. Quel que soit le degré de simplicité ou de complexité du
traitement de la donnée, celui-ci est pris en charge grâce à de multiples assistants.
Ceux-ci sont regroupés au sein d’une interface graphique et relèguent au rang des
oubliettes les antiques lignes de code en C# ou Visual Basic. Rassurons immédiatement
les développeurs : ils continueront à manipuler du code SQL, des procédures stockées
et pourquoi pas du code VB ou C# lorsque les assistants auront atteint leurs limites
fonctionnelles.
Les tâches d’intégration sont rassemblées dans un package ou lot. Le flux de

contrôle établit l’enchaînement des tâches du package. Certaines tâches ont pour
vocation d’assurer la transformation de données. On les appelle tâches de flux de
données.
Les flux de données traitent essentiellement des fonctions de transformation
de données. Elles sont au minimum composées d’une source de données, d’une
transformation et d’une destination.
Figure 5.3 — Un package enchaîne différents types de tâches dans le flux de contrôle
Le traitement automatisé de bout en bout permet de maintenir une parfaite

synchronisation entre les données de l’ERP, du datawarehouse et des cubes OLAP
associés.
Une des grandes tâches préparatoires à la mise en place d’un processus ETL est
de procéder à la dénormalisation des tables lors du passage du modèle opérationnel
(OLTP) au modèle multidimensionnel (DW). Un entrepôt de données hautement
dé normalisé fait apparaître un « schéma en étoile ». La table de faits au centre de
l’étoile est reliée directement aux tables de dimensions. La table de faits renferme
l’ensemble des indicateurs. Les tables de dimensions ont pour but de qualifier les faits
grâce aux attributs qui les constituent. L’ETL profite également de ces transformations
pour introduire des fonctions d’agrégation telles que SUM, COUNT et AVERAGE dans
l’entrepôt de données (DW). Nous expliquerons plus loin le mécanisme qui consiste
à alimenter les faits dans le DW par ajout de couches de données successives alors
que les dimensions évoluent lentement par le biais de mises à jour. Nous présenterons
également le mécanisme ETL de dimension à variation lente. Ces deux mécanismes
constituent le fondement de l’alimentation des entrepôts de données.
Nettoyage et standardisation des données

Quelle que soit l’origine des données (OLTP, OLAP, Excel, Access, fichiers plats,
etc.), elles doivent être préalablement nettoyées et standardisées. En voici quelques
illustrations :
• Les succursales d’une même organisation utilisent des conventions et des
standards qui leur sont propres.
• Les données peuvent être acquises auprès de loueurs professionnels. Avant d’être
exploitées, il est nécessaire de les standardiser et de les rendre compatibles avec
les données déjà existantes dans l’entreprise.
• Certaines données peuvent être spécifiques à des critères régionaux (formats
numériques, date et heure). Avant de les charger, il est nécessaire de les convertir
en un même référentiel.
Un lot SSIS peut également substituer des valeurs de champs par recherche de
valeurs issues d’une table de référence (fonction lookup). SSIS dispose d’algorithmes
de recherche exacte ou floue à des fins de substitution et de standardisation. Par
exemple, dans les cas d’une récupération d’adresses de prospects, la ville peut être
mal orthographiée (Pari au lieu de Paris). L’algorithme de recherche floue permet de
conserver la bonne orthographe et ainsi de standardiser les valeurs dans le référentiel
de l’entreprise. Ce même type d’algorithme permet également de détecter des doublons
lors de l’introduction de nouvelles adresses et ainsi d’effectuer un traitement spécifique.
La transformation de données intelligentes

SSIS présente des fonctions de transformation dynamique afin de s’adapter aux
données auxquelles il accède. En fonction du contenu de données en entrée, SSIS
permet de fusionner plusieurs lignes source en une seule ou au contraire de fractionner
des lignes en plusieurs destinations. Il est possible également d’appliquer différentes
fonctions d’agrégation selon les données source.
Les conteneurs permettent de grouper certaines tâches participant à un même
objectif. On attribuera à ces conteneurs des variables partagées par toutes les tâches le
constituant. Les conteneurs répétitifs permettent également d’effectuer des itérations
pour chaque élément constitutif du conteneur. Par exemple, une tâche FTP transfère
quotidiennement des fichiers en provenance des succursales dans un répertoire de
destination. Lorsque tous les fichiers ont été transférés et sans en connaître le nombre
exact, SSIS balaie séquentiellement le contenu du répertoire, traitant les uns après les
autres tous les fichiers du répertoire.
Automatisation des fonctions d’administration

SSIS permet d’automatiser des tâches d’administration telles que sauvegardes et
restaurations de bases de données. Il est également possible de copier des bases de
données SQL Server ou certains objets qu’elles contiennent vers d’autres instances ou
d’autres bases.
Un package SSIS peut exécuter d’autres packages. Cela permet au développeur ou
à l’administrateur de morceler son travail en sous-ensembles cohérents, et d’en assurer
plus facilement la maintenance ou la réutilisation.
Un package peut utiliser une tâche de bouclage afin de scanner un certain nombre
de serveurs et ainsi réaliser des fonctions similaires sur plusieurs serveurs. SSIS dispose
d’un énumérateur qui passe en revue les objets SMO (SQL Management Object).
Les packages SSIS peuvent être planifiés à l’aide de l’agent SQL Server.
Synthèse de l’architecture de SSIS

Nous l’avons vu, SSIS est composé de packages ou lots. Chaque package comprend
un ou plusieurs flux de contrôle. Certains flux de contrôles englobent à leur tour des
tâches de flux de données (tâche de transformation).
Figure 5.4 — Schéma global des composants de SSIS
Le concepteur graphique de SSIS est scindé en quatre modules distincts matériali-

sés par des onglets différents visant à :
• construire le flux de contrôle qui séquence l’ensemble des tâches du package ;
• construire le flux de données et les transformations élémentaires entre une
source et une destination ;
• mettre en œuvre un gestionnaire d’événements permettant de réagir à certains
événements lors du traitement tels que en cas d’erreur, en cas de bon fonctionne-
ment, en cas d’arrêt du lot, etc. ;
• afficher le contenu et la progression de l’exécution du package, ce qui facilite
le débogage.
Les enchaînements de tâches ou workflow intègrent des fonctions comme des

transferts de fichiers (FTP), l’exécution d’instructions SQL, de procédures stockées,
l’envoi de messages par courriel. La prise en compte d’un grand nombre de sources
de données permet des connexions en provenance de multiples bases de données.
Integration Services permet d’automatiser des tâches de transformation, de nettoyage,
d’agrégation, de fusion et de copie de données. Des interfaces de programmation sont
fournies permettant aux développeurs d’intégrer ces API dans leurs développements.
Dans ce chapitre, vous apprendrez à utiliser SSIS pour créer un lot dont la finalité
sera de récupérer des données en provenance de Access et Excel, puis d’insérer ces
données dans une table de dimension de l’entrepôt de données.
Structure d’un package SSIS

Business Intelligence Development Studio (BIDS) est une interface conviviale visant
à construire des packages Integration Services.
Lorsque nous utilisons BIDS, plusieurs onglets sont à notre disposition.
L’onglet Flux de contrôle (workflow)
Figure 5.5 — L’onglet Flux de contrôle et le gestionnaire de connexions
Il permet :
• de créer des conteneurs qui définissent des flux de travail répétitifs ;
• de subdiviser des tâches en sous-ensembles cohérents ;
• de créer des tâches de flux de données ;

• de préparer les données ;
• de créer des scripts ;
• d’ordonner les flux en appliquant des contraintes de précédence.
La figure 5.8 présente les éléments du flux de contrôle.
L’onglet Flux de données (ETL)
Figure 5.6 — L’onglet flux de données
Il permet :
• d’ajouter une ou plusieurs sources de données ;
• d’ajouter des gestionnaires de connexion ;
• de créer des transformations afin de répondre aux besoins métier ;
• d’ajouter une ou plusieurs destinations telles que des tables ou bases de données ;
• de détecter des erreurs lors des transformations et de traiter les exceptions.
L’onglet Gestionnaire d’événements

Il permet de :
• traiter les événements qui se déclenchent lors du traitement du package
(exemple : envoyer un message électronique lors de l’échec ou à l’achèvement
d’un package) ;
• traiter les événements pour tous les types de tâches du package.
La figure 5.7 montre l’interception de l’erreur lors de l’exécution du package, et

l’envoi d’un courriel d’information.
5.2 Migrer une base SQL Server 2000 vers SQL Server 2008 97
Figure 5.7 — Le gestionnaire d’événements permet de déclencher

des tâches en cas d’erreur (ou autres événements)
L’onglet Explorateur de Package

Il permet :
• de fournir un aperçu du package ;
• de lister les exécutables ;
• de lister les contraintes de précédence qui relient les tâches ;
• de lister le gestionnaire d’événements ;
• de lister le gestionnaire de connexions.
À titre de comparaison, l’interface DTS de SQL Server 2000 présentant les tâches
est donnée figure 5.9.
5.2 MIGRER UNE BASE SQL SERVER 2000

VERS SQL SERVER 2008
Le processus de migration d’une base de données SQL Server 2000 vers 2008 peut être
réalisé grâce à une sauvegarde de la version 2000 (exemple Northwind.bak).
Dans Management Studio 2008, procéder à la création de la base NorthWind.
La restauration de la base SQL 2000 vers SQL Server 2008 nécessite d’établir la
compatibilité descendante vers SQL Server 2000 lors de la création de la base dans
SQL Server Management Studio 2008.
Le processus de restauration se déroule selon les étapes suivantes :
• Spécifier l’emplacement de la sauvegarde.
• Dans les options, cocher la case Remplacer la base existante.
• La restauration s’effectue normalement.
• Après la restauration, passer le niveau de compatibilité à SQL Server 2008 afin
de bénéficier des fonctionnalités avancées.
Figure 5.8 — Liste des outils mis à disposition

de l’administrateur pour le flux de contrôle
Figure 5.9 — Liste des tâches disponibles dans DTS 2000

5.3 Tâches d’intégration services 99
Figure 5.10 — Assurer un niveau de compatibilité SQL Server 2000
Nous verrons dans le paragraphe suivant que SSIS dispose également d’une
fonction permettant d’effectuer le transfert de base du format SQL 2000 vers SQL
2008.
5.3 TÂCHES D’INTÉGRATION SERVICES

5.3.1 Tâches des éléments de flux de contrôle
La boîte à outils de flux de contrôle recense l’ensemble des tâches du plan de
maintenance et de flux permettant d’enchaîner des processus de traitement de
données.
Conteneur de boucle Foreach

Le conteneur de boucle Foreach exécute un ensemble de tâches autant de fois qu’il y a
d’éléments dans la collection qui les contient. Plusieurs types de collections peuvent
être utilisés :
• fichiers présents dans un répertoire et répondant à un critère particulier ;
• chaque ligne d’un recordset ADO ou ADO.NET dataset ;
• chaque ligne de toutes les tables d’un dataset ADO.Net ;
• chaque table d’un dataset ADO.Net ;
• chaque élément d’une variable qui comporte une collection d’objets ;
• chaque nœud d’une liste XML ;
• chaque objet d’une collection SMO.
Figure 5.11 — Boucle exécutant des commandes SQL de création de table
Dans la figure 5.11, la tâche « Create tables » est incluse dans la boucle qui porte
le nom « Run SQL Statements ». Cette tâche sera donc répétée.
La figure 5.12 montre une collection d’objets constitués des fichiers contenus dans
un répertoire donné. La boucle ForEach balaie le répertoire à la recherche de fichiers
dont l’extension est .SQL.
Figure 5.12 — L’éditeur de boucle Foreach
À chaque boucle, le nom de fichier est transmis à la variable utilisateur vFileName.

Figure 5.13 — Variable utilisateur dans l’éditeur de boucle
Le gestionnaire de connexion CreateTableSQL transmet le nom de fichier à la

tâche « Create Tables ».
Figure 5.14 — Propriété de la connexion CreateTableSQL
À chaque boucle, la variable @[User : :vFileName] reçoit le nom du fichier et

modifie dynamiquement la connexion.
La tâche d’exécution SQL puise sa requête dans le fichier source grâce au
gestionnaire de connexion CreateTableSQL.
Figure 5.15 — L’éditeur de tâche d’exécution d’une commande SQL
Conteneur de boucle For
Figure 5.16 — Boucle For
Le conteneur de boucles For définit un flux de contrôle répétitif dans un package.

La mise en œuvre de la boucle est similaire à la structure de bouclage For... Next
des langages de programmation. Lors de chaque répétition de la boucle, le conteneur
de boucles For évalue une expression et répète son flux de travail jusqu’à ce que
l’expression renvoie la valeur False.
Conteneur de séquences
Le conteneur de séquences regroupe un sous-ensemble de tâches pour mieux structurer
le package. Il offre l’avantage de pouvoir être désactivé, ce qui a pour conséquence
de désactiver toutes les tâches qui le composent. Cette fonctionnalité est particuliè-
rement intéressante en phase de débogage. Il est possible également de définir des
propriétés sur le conteneur plutôt que sur chacune des tâches qui le composent.
Tâche DDL d’exécution SQL Server Analysis

La tâche DDL d’exécution de Analysis Services exécute des instructions qui peuvent
créer, modifier ou supprimer des cubes multidimensionnels et des dimensions. Une
tâche DDL peut également renfermer l’exécution d’une sauvegarde d’une base de
données OLAP.
Supposons que nous souhaitions créer une tâche SSIS de sauvegarde d’une base
de données Analysis services, il suffit d’ouvrir Management studio 2008 puis de
sélectionner le serveur Analysis Services. Un clic droit sur la base permet de choisir le
menu de sauvegarde.
Figure 5.17
Le bouton Script permet de récupérer le code XML/A correspondant à la tâche de

sauvegarde.
Revenons dans SSIS puis double-clic sur la tâche DDL.
Figure 5.18
Créez une connexion de type Analysis Services vers le serveur SSAS.

Dans la propriété SourceDirect il suffit de coller le code récupéré dans Management
Studio.
Voici le code XML/A :
<Backup xmlns="http://schemas.microsoft.com/analysisservices/2003/engine">
<Object>
<DatabaseID>Analysis Services Tutorial 10</DatabaseID>
</Object>
<File>Analysis Services Tutorial 10.abf</File>
<AllowOverwrite>true</AllowOverwrite>
</Backup>
On observe le nom du fichier de sauvegarde avec son extension .abf (Analysis

Backup File)
On observe également que la balise <AllowOverwrite> positionnée à True signifie
que ce fichier peut être écrasé à chaque sauvegarde.
Tâche de flux de données (Tâche ETL)
Source
Transformation
Transformation
Destination
Figure 5.19 — La tâche de flux de données alimente une destination (table SQL Server, fichier
plat, etc.) à partir des données sources
Cette tâche permet de copier des données entre des sources et des destinations tout
en offrant la possibilité de transformer, nettoyer et modifier les données. La tâche de
flux de données représente le conteneur dont le détail est fourni dans l’onglet « Flux
de données ».
• les sources précisent les connecteurs vers les sources de données (fichiers plats,
tables ou vues SQL) ;
• les transformations modifient les données ;
• les destinations chargent les données.
Lors de l’exécution, la tâche crée un plan d’exécution à partir du flux de données.

Le moteur de flux de données exécute le plan.
Tâche de profilage des données

Cette tâche a pour but d’analyser la qualité des données qui entrent dans le processus
d’alimentation de l’entrepôt de données. La fiabilité des indicateurs de performance
clés (IPC ou KPI) dépend de la validité des données sur lesquels ils sont basés.
Les statistiques fournies par cette tâche donnent les informations nécessaires
pour minimiser de manière efficace les problèmes de qualité qui peuvent résulter
de l’utilisation des données sources.
Un profil de données se présente sous la forme d’une collection de statistiques
agrégées sur les données par exemple l’analyse de la table Clients permettra d’élaborer
les statistiques suivantes :
• le nombre de lignes dans la table Clients ;
• le nombre de valeurs distinctes dans la colonne Départements ;
• le nombre de valeurs Null ou manquantes dans la colonne Code Postal ;
• la distribution des valeurs dans la colonne Ville ;
• la puissance de la dépendance fonctionnelle de la colonne Code Postal et Ville
(en effet le code postal d’une ville doit toujours être le même pour une même
ville).
Tâche de requête d’exploration de données (data mining)

Cette tâche exécute des requêtes basées sur des modèles prédictifs intégrés à Analysis
Services. Par exemple, lors du chargement de données dans une base, une telle requête
peut prédire si un nouveau prospect est susceptible d’acheter ou non tel ou tel article
et d’isoler les cas dans des tables intermédiaires. La requête est une instruction DMX
(Data Mining Extensions).
Tâche de script Active X

La tâche de script ActiveX prend en charge les langages VBScript et JScript ainsi que
d’autres langages de script installés sur l’ordinateur local. La tâche de script ActiveX
est fournie exclusivement à des fins de compatibilité descendante avec le composant
abandonné DTS (Data Transformation Services).
Figure 5.20 — La tâche de script ActiveX envoie un message

en cas d’erreur (incohérence entre les deux tables)
Tâche de script
Cette tâche permet au programmeur de réaliser des fonctions non disponibles dans les
tâches intégrées de SSIS.
La tâche de script utilise Microsoft Visual Studio Tools for Applications (VSTA)
en tant qu’environnement d’écriture des scripts et que moteur d’exécution.
VSTA fournit l’ensemble des fonctionnalités standard de l’environnement
Visual Studio, telles que l’éditeur Visual Studio à code de couleur, IntelliSense et
l’Explorateur d’objets. VSTA utilise également le même débogueur que les autres
outils de développement Microsoft. Les points d’arrêt dans le script fonctionnent de
façon transparente avec ceux des tâches et des conteneurs Integration Services.
VSTA prend en charge les langages de programmation Microsoft Visual Basic 2008 et
Microsoft Visual C# 2008.
La tâche de Script est utile pour :
• Accéder aux données à l’aide d’autres technologies non prises en charge par les
types de connexion intégrés. Par exemple, un script peut utiliser des interfaces
ADSI (Active Directory Service Interfaces) pour accéder aux noms d’utilisateur
et les extraire d’Active Directory.
• Créer un compteur de performances spécifique au package. Par exemple, un
script peut créer un compteur de performances mis à jour pendant l’exécution
d’une tâche complexe ou peu performante.
• Déterminer si les fichiers spécifiés sont vides ou combien de lignes ils
contiennent, puis en fonction de ces informations, affectez le flux de contrôle
dans un package. Par exemple, si un fichier ne contient aucune ligne, la
valeur 0 d’une variable et une contrainte de précédence qui évalue la valeur
empêchent une tâche de système de fichiers de copier le fichier.
• Compter combien de fichiers sont présents dans un répertoire FTP afin de
décider si un traitement peut être démarré ou reporté.
Pour l’écriture des programmes, le développeur dispose d’un grand nombre de

snippets ou extraits de code standard (VB ou C#) qu’il lui suffit d’adapter afin de
répondre au besoin métier.
Figure 5.21 — Des extraits de code sont fournis pour un grand nombre d’applications.
Figure 5.22 — Flux de contrôle intégrant trois tâches de script.
Dans le flux de contrôle ci-dessus on observe trois tâches de script. Il s’agit de

compter combien de fichiers ont été trouvés dans un répertoire donné puis d’afficher
le résultat en fin d’exécution.
La première tâche de script a pour but d’incrémenter un compteur. On observe
que cette tâche est englobée dans la boucle For Each File.
Voici le code :
Public Sub Main()

Dts.Variables("Compteur").Value = Dts.Variables("Compteur ").Value + 1
Dts.TaskResult = ScriptResults.Success
End Sub
La variable Compteur est déclarée en Integer (int32) dans le package puis passée
en paramètre (lecture/écriture) dans la tâche de script.
A l’issue de la boucle for each file, lorsque le compteur est supérieur à 0 on affiche
un message à l’opérateur afin de préciser combien de fichiers ont été traités.
Voici le code :
MsgBox("Il existe " & Dts.Variables("Compteur ").Value & " fichiers dans " &
Dts.Variables("VarFolderName").Value, MsgBoxStyle.Information, "Résultat du
test sur le nb de fichier(s)")
Bien entendu ce message peut être remplacé par un envoi de mail à l’adminis-
trateur suivi d’une exécution d’un traitement particulier en fonction de la valeur du
Compteur.
Figure 5.23 — Affichage du résultat du test sur le compteur.
Les extraits de code proposés sont nombreux. Il est utile de les découvrir, ils vous
feront gagner beaucoup de temps dans la phase de développement.
Exemple 1 : Afficher Vrai ou Faux en fonction de la présence ou non d’un

fichier dans un répertoire donné
’MsgBox(My.Computer.FileSystem.FileExists("C:\Formation
BI\SolutionBI\CoursSSIS\Sample Data\SampleCurrencyData.txt"))
Exemple 2 : Afficher l’espace disponible sur le disque C du serveur.
Dim drive As System.IO.DriveInfo
drive = My.Computer.FileSystem.GetDriveInfo("C:\")
’Dim space As Long = drive.AvailableFreeSpace
’MsgBox("Espace disponible sur c: " & space, MsgBoxStyle.Information,
"Titre de la fenêtre")
Tâche de service Web

Cette tâche permet d’exécuter une méthode de service web. Elle récupère
dans une variable ou un fichier, des valeurs renvoyées par la méthode de
service Web. Le gestionnaire de connexions HTTP permet de pointer vers un
site web ou un fichier WSDL (Web Service Description Langage). Exemple :
http://MyServer/MyWebService/MyPage.asmx ?WSDL
Tâche de système de fichiers

Cette tâche effectue des opérations sur les fichiers et les répertoires. Il est possible de
copier un répertoire et son contenu, de déplacer des fichiers, d’en modifier les attributs,
etc. Le gestionnaire de connexion permet de choisir le serveur sur lequel effectuer les
opérations. Les tâches de système sur les fichiers et répertoires sont les suivantes :
• copier un répertoire ;
• copier un fichier ;
• créer un répertoire ;
• supprimer un répertoire ;
• supprimer le contenu d’un répertoire ;
• supprimer un fichier ;
• déplacer un répertoire ;
• déplacer un fichier ;
• renommer un fichier ;
• définir des attributs des fichiers ou des répertoires.
Tâche de traitement Analysis Services

Cette tâche permet de traiter les objets Analysis Services (cubes, dimensions, modèles
de data mining).
Figure 5.24 — La tâche de traitement Analysis services permet de traiter tout ou partie d’un cube.
Ci-dessus les groupes de mesures Internet Sales et Reseller Sales font l’objet d’un
traitement ainsi que les dimensions Product, Customer, Reseller et Internet Sales Order
Details.
Tâche de transfert de base de données

Cette tâche permet de copier des bases SQL entre des instances SQL Server 2000
et/ou SQL Server 2005 ou 2008. Toutes les combinaisons sont possibles.
Tâche de transfert de connexions

Cette tâche permet de transférer une ou plusieurs connexions entre différentes
instances de SQL Server.
Tâche de transfert de messages d’erreur

Cette tâche transfère des messages d’erreur entre plusieurs instances de SQL Server et
permet de gérer les cas de doublons de messages d’erreur.
Tâche de transfert de procédures stockées

La tâche de transfert de procédures stockées de master transfère une ou plusieurs
procédures stockées définies par l’utilisateur entre les bases de données master sur des
instances de SQL Server. Pour transférer une procédure stockée à partir de la base de
données master, le propriétaire de la procédure doit être dbo.
Tâche de transfert d’objets SQL Server

La tâche de transfert d’objets SQL Server transfère un ou plusieurs types d’objets d’une
base de données SQL Server entre des instances de SQL Server. Il est possible de
transférer des tables, des procédures stockées, des fonctions et types de données définis
par les utilisateurs entre des versions différentes de SQL Server.
Les rôles de serveur, les rôles et les utilisateurs de la base de données spécifiée
peuvent être copiés, ainsi que les autorisations pour les objets transférés.
Certaines fonctions sont réservées à SQL Server 2008 (partitions, schémas,
assemblies, agrégations, schéma XML).
Tâche d’exécution de package

Cette tâche étend les fonctionnalités d’entreprise de SSIS en permettant à des
packages d’en exécuter d’autres au sein d’un flux de travail. Un package qui en exécute
d’autres est généralement appelé « package parent », tandis que les packages exécutés
par un flux de travail parent sont appelés « packages enfants ». D’une manière générale
les packages sont étanches entre eux. Ainsi les variables ont une portée qui ne peut
excéder celle du package. Il existe cependant une possibilité de passer une variable
depuis un package parent vers un package enfant. L’inverse n’étant pas possible.
Tâche d’exécution de package DTS 2000

La tâche d’exécution de package DTS 2000 exécute les lots développés à l’aide de
DTS 2000. Cette tâche permet d’exécuter des packages DTS SQL Server 2000 dans
les solutions de transformation de données SQL Server 2008.
Tâche d’exécution de processus

Cette tâche exécute une application (Word, Access, Excel, etc.) ou un fichier de
commandes dans le cadre d’un flux de travail. Elle permet par exemple de démarrer une
application Visual BASIC ou une macro Access chargée de générer quotidiennement
un rapport sur les ventes.
Figure 5.25 — Exécution d’un processus de décompression d’un fichier zippé (expand.exe)
Tâche d’exécution de requêtes SQL

Cette tâche exécute des instructions ou des procédures stockées. La tâche peut
contenir une seule ou plusieurs instructions SQL s’exécutant de façon séquentielle.
Exemple de tâche d’exécution SQL avec une source de données

de type ADO .NET
Grâce au connecteur ADO.NET, l’onglet mappage peut recevoir des paramètres au
nom significatif. Ces paramètres recevront le contenu de variables choisies dans le
package (Système ou utilisateur).
La requête SQL suivante illustre l’utilisation des paramètres dans le but d’insérer
une ligne dans une table d’audit.
INSERT INTO AuditPkgExecution (PkgName, PkgGUID, PkgVersionGUID,

PkgVersionMajor, PkgVersionMinor, ExecStartDT, ParentPkgExecKey)
Values (@PkgName, @PkgGUID, @PkgVersionGUID, @PkgVersionMajor,
@PkgVersionMinor, @ExecStartDT,NULL)
Figure 5.26 — Tâche d’exécution de requête SQL avec type de connecteur ADO.NET
Figure 5.27 — Onglet de mappage de paramètres
Tâche d’insertion en bloc

Il s’agit d’un moyen très rapide de copier de gros volumes de données dans une table
ou une vue SQL Server. Pour des raisons de performance, cette tâche ne permet pas
d’effectuer des transformations de données lors du chargement. La tâche d’insertion
en bloc ne peut transférer des données que depuis un fichier texte vers une table ou
une vue SQL Server. Si la table ou la vue de destination contient déjà des données,
les nouvelles données sont ajoutées à la table existante. Si vous souhaitez remplacer
les données, utilisez une tâche d’exécution SQL DELETE ou TRUNCATE avant de
lancer la tâche d’insertion en bloc.
Tâche Envoyer un message
Figure 5.28 — Formulaire permettant de configurer

les propriétés pour l’envoi d’un message électronique
Figure 5.29 — Formulaire de préparation de connexion SMTP
Elle permet à un package d’envoyer des messages en cas de réussite ou d’échec

des tâches du flux de travail, ou d’envoyer des messages en réponse à un événement
déclenché par le package au moment de l’exécution. Par exemple, la tâche peut
notifier à un administrateur de base de données la réussite ou l’échec de la tâche de
sauvegarde de base de données ou de l’import de données.
Tâche FTP
Cette tâche permet de télécharger des fichiers de données entre serveurs. Par exemple,
elle peut récupérer quotidiennement tous les fichiers des ventes des succursales sur un
serveur central exécutant la consolidation dans le datawarehouse.
Tâche Lecteur de données WMI

WMI (Windows Management Instrumentation) permet d’occulter la complexité liée à
l’environnement du système. Le schéma CIM (Common Information Model) résulte de
la norme DMTF. Il présente une vue cohérente et unifiée des différents types d’objets
logiques et physiques contenus dans l’environnement tels des composants de logiciel,
des services, des imprimantes. Les utilisateurs des services WMI souscrivent à des
événements choisis et reçoivent des alertes lorsque des événements se réalisent.
La tâche Lecteur de données WMI exécute des requêtes au moyen du langage de
requête WQL. Il est possible d’interroger les journaux des événements Windows sur
un serveur distant puis d’écrire les informations dans un fichier à des fins d’analyse.
Tâche MSMQ
La tâche MSMQ (Microsoft Message Queuing) permet d’envoyer et recevoir des
messages entre différents packages Integration Services ou d’envoyer des messages à
une file d’attente traitée par une application personnalisée. Par exemple, la tâche peut
mettre en file d’attente les messages destinés aux ordinateurs portables hors connexion
des représentants commerciaux.
Tâche de Transfert de travaux

Elle transfère un ou plusieurs travaux d’agent SQL Server entre des instances de SQL
Server.
Tâche observateur d’événements WMI

Cette tâche permet d’observer les événements WMI (Windows Management Ins-
trumentation) à l’aide d’une requête d’événement WQL (Management Instrumentation
Query Language) pour spécifier les événements dignes d’intérêt.
Il est ainsi possible d’utiliser l’observateur d’événements WMI afin d’attendre la
notification signalant que des fichiers sont ajoutés à un dossier lors d’un transfert FTP,
puis de démarrer le traitement au signal de fin de transfert.
Tâche XML
La tâche XML est utilisée pour travailler avec des données XML. Il est possible de
remettre en forme un document XML et de lui appliquer une feuille de style XSLT.
5.3.2 Tâches du plan de maintenance

Exécuter la tâche de l’instruction T-SQL
Cette tâche est similaire à la tâche d’exécution SQL. Toutefois, elle ne permet pas
d’exécuter des requêtes paramétrées, d’enregistrer les résultats des requêtes dans des
variables ou d’utiliser des expressions de propriété. Pour cela, vous devez utiliser la
tâche d’exécution SQL et non pas la tâche Exécuter l’instruction T-SQL.
Tâche de nettoyage de maintenance

La tâche de nettoyage de maintenance supprime les fichiers résiduels résultant de
l’exécution du plan de maintenance.
Tâche de nettoyage d’historique
Figure 5.30 — Formulaire de tâche de nettoyage d’historique
La tâche de nettoyage d’historique supprime des entrées dans les tables d’historique
Backup et Restore de la base de données SQL Server msdb, dans l’historique des
travaux de SQL Server Agent et du plan de maintenance.
Tâche Exécuter le travail de l’agent SQL Server

Cette tâche exécute des travaux d’agent SQL Server. Il est possible d’exécuter des
travaux qui exécutent des instructions T-SQL, XML/A et des scripts ActiveX, des
tâches de maintenance, de réplication ou d’exécution de lots SSIS.
Tâche Mettre à jour les statistiques

La tâche Mettre à jour les statistiques permet à un package de mettre à jour les
statistiques d’une ou plusieurs bases de données.
Tâche Notifier l’opérateur

Un opérateur d’agent SQL Server est un alias d’une personne ou d’un groupe qui
peut recevoir des notifications électroniques. La tâche Notifier l’opérateur envoie des
messages de notification aux opérateurs d’Agent SQL Server. Elle utilise le service
SQLiMail. Préalablement à la mise en place d’une telle tâche, un opérateur doit être
défini avec une adresse courriel valide.
SQL script
EXECUTE sendmail_sp Service Broker SMTP Server
queue
sqlimail90.exe
msdb
SQLiMail Configuration
sendmail_sp Stored Procedure Service Broker
mailhost
Email messages
Logs
Figure 5.31 — Flux des processus dans SQLiMail
Tâche Reconstruire l’index

La tâche Reconstruire l’index reconstruit les index dans les vues et les tables de base
de données SQL Server.
Tâche Sauvegarder la base de données

Grâce à cette tâche, il est possible d’automatiser des sauvegardes totales ou différen-
tielles. Une ou plusieurs bases de données peuvent être sauvegardées dans des fichiers
ou groupes de fichiers.
Le formulaire écran fourni par SSIS permet de générer la commande SQL qui sera
exécutée.
Tâche Vérifier l’intégrité de la base de données

Cette tâche contrôle l’allocation et l’intégrité de la structure de tous les objets de la
base de données spécifiée. Il est possible de vérifier plusieurs bases de données et de
contrôler les index des bases.
Tâches complémentaires à installer

Sur le site www.SQLIS.com vous pouvez trouver un grand nombre de composants
supplémentaires. En général ces composants de qualité sont développés par la société
Konesans. Vous pourrez y télécharger des composants de type Flux de contrôle comme
des composants de type Transformation de données.
Vous devez ensuite intégrer ces composants dans votre boîte à outils.
Voici quelques-uns des composants utiles :
• Trace File Source Adapter : Permet de lire des fichiers de trace (Profiler) stockés
au format .trc. Ces fichiers peuvent être lus dans le Flux de données.
5.4 Composants flux de données (ETL) 117
• Checksum Transformation : Calcule le checksum à travers une ou plusieurs

colonnes.
• File Watcher Task : Cette tâche détecte les modifications apportées à des
fichiers existants ou l’arrivée de nouveaux fichiers dans un répertoire. Utile
lorsque les fichiers sont volumineux.
• Row Count Plus Transformation.
• Row Number Transformation : Donne la valeur du N◦ de ligne pour chaque
ligne lue dans un Flux de données. Utile pour repérer une ligne en erreur dans
un flux de données.
• Regular Expression Transformation et RegexClean Transformation : Utilisent
la puissance du formatage des « expressions régulières » au sein d’un flux de
données.
• Data Generator Source Adapter : Génère de manière aléatoire des données de
type Integer et string en entrée d’un flux de données.
• Trash Destination Adapter : Il s’agit d’une destination de Flux de données qui
peut remplacer un chargement d’une table SQL. En effet ce composant simule
une destination mais n’effectue aucune action.
5.4 COMPOSANTS FLUX DE DONNÉES (ETL)
SSIS offre trois types de composants de flux de données. Les sources, les transformations
et les destinations. Dans le schéma de la figure 5.29, nous observons que les sources
puisent leurs données dans les colonnes externes en provenance d’une base de données
ou d’un fichier plat en s’appuyant pour cela sur une connexion pointant vers la source
de données. Le mode d’accès précise le type de source (vue, table, fichier, etc.).
Les sources comportent des colonnes externes en entrée et des colonnes de sortie.
Il est possible de sélectionner les colonnes externes qui participent à la sélection
de sortie normale.
La sortie d’erreur d’une source contient les mêmes colonnes que la sortie normale
plus deux colonnes supplémentaires : ErrorCode indique le code erreur et ErrorColumn
indique la colonne contenant l’erreur. Les colonnes de sortie deviennent à leur tour
les colonnes d’entrée du composant de transformation suivant.
Les transformations comportent des colonnes d’entrée et des colonnes de sortie.
Certaines transformations permettent de fusionner plusieurs entrées en une seule
colonne de sortie ou d’éclater une entrée en plusieurs colonnes de sortie.
Les destinations comportent des colonnes d’entrée. Une destination écrit directe-
ment dans une table de la base de données ou dans un dataset en mémoire. Des
colonnes de sortie d’erreur peuvent intercepter des traitements ne pouvant aboutir, par
exemple la mise à jour d’un champ de la table avec une valeur null alors que ce champ
n’autorise pas les valeurs nulles.
5.4.1 Sources des flux de données
Figure 5.32 — Un flux de données est composé

d’une source, d’une transformation et d’une destination
Source ADO .NET

La source ADO NET exploite des données issues d’un fournisseur .NET et les met à
la disposition du flux de données.
Vous devez saisir une commande SQL telle que SELECT * FROM sales.customer.
Le mappage entre les colonnes externes et les colonnes de sortie se réalise automati-
quement, voir figure 5.38.
Figure 5.33 — Mappage des colonnes dans le cas d’une source DataReader
Source de fichier brut

La source de fichier brut lit des données directement dans un fichier lui-même généré
par SSIS. Cette source n’utilise pas de gestionnaire de connexion.
Source de fichier plat

Un fichier plat peut être de format texte, avec des champs délimités par des caractères
spéciaux, de largeur fixe, ou les deux.
Dans le formulaire de la figure 5.34, on précisera le type de séparateur de ligne et
de colonnes (tabulateur, guillemet, virgule).
Le choix des paramètres régionaux permet de définir le format des données selon la
localisation de la source (format date anglo-saxon ou français, format numérique, etc.).
Dans la figure 5.34, on observe une source de données au format anglais (États-Unis).
L’affichage des colonnes après définition des types de colonne est montré
figure 5.35.
Source Excel
La source Excel extrait des données de feuilles de calcul Excel entières ou de plages
nommées. Les formats pris en compte sont Excel 3, 4, 5 et les versions 97 à 2007.
Figure 5.34 — Formulaire permettant d’établir une connexion

avec un fichier plat
Figure 5.35 — Affichage des colonnes du fichier plat

Source OLE DB
Figure 5.36 — Liste des fournisseurs OLE DB

pour les sources et destinations de données
La source OLE DB pointe sur des tables relationnelles. La figure 5.36 présente les
différents fournisseurs OLE DB fournis par le gestionnaire de connexion.
Voici un récapitulatif des sources et leur incidence.
Tableau 5.1
Type Marqueur Nom Exemple Exemple
de gestionnaire de du de requête de nom
de connexion paramètre paramètre de paramètre
OLEDB ? 0,1,2... SELECT Nom FROM 0
Clients WHERE Nom
=?
ADO.Net @Varnom @Varnom SELECT Nom FROM @Nom
Clients WHERE Nom
= @Nom
ADO ? @Param1, SELECT Nom FROM @Param1
@Param2... Clients WHERE Nom
=?
ODBC ? 1,2... SELECT Nom FROM 1
Clients WHERE Nom
=?
5.4.2 Transformations du flux de données

Agrégation
La transformation d’agrégation permet de regrouper un certain nombre de lignes du
flux de données. La fonction d’agrégation effectue un regroupement grâce à la clause
GROUP BY sur une ou plusieurs colonnes, puis applique une fonction d’agrégation telle
que Moyenne, Comptage, Comptage distinct, Somme, Max, Min.
Audit
La transformation d’audit permet d’ajouter des colonnes au flux de données, afin
d’obtenir des informations relatives à l’environnement au moment de l’exécution.
Les colonnes d’audit concernent l’identifiant GUID, l’identificateur du package, le
nom ou la version du package, l’heure à laquelle le package a commencé, le nom de
l’ordinateur et de la tâche exécutée.
Colonne dérivée
Une colonne dérivée résulte de l’application d’une fonction qui s’applique sur d’autres
colonnes ou variables du package. Par exemple, la colonne dérivée NomComplet résulte
de l’expression Prénom + " " + Nom. L’expression DATEPART ("year", GETDATE()) renvoie
l’année en cours.
Commande OLE DB
La transformation de commande OLE DB exécute une instruction SQL pour chaque
ligne d’un flux de données. Il est ainsi possible d’exécuter une instruction SQL qui
insère, met à jour ou supprime des lignes d’une table de base de données.
DELETE FROM Dimcustomer WHERE CustomerKey = ?
Dans notre exemple, le « ? » remplace la colonne externe Param_0 mappée à la

colonne d’entrée CustomerKey.
Composant script
Ce composant permet d’écrire du code de script personnalisé. Le composant script peut
être utilisé en tant que source, transformation ou destination. On utilise le composant
script lorsqu’il s’agit de lire un fichier dont le format n’est pas pris en charge par le
gestionnaire de connexion de SSIS. Un script peut appliquer plusieurs transformations
simultanées. Un script peut naturellement exécuter des fonctions personnalisées qui
n’existent pas dans la bibliothèque des fonctions fournies nativement par SSIS.
La figure 5.37 montre l’environnement de développement en visual basic.net.
Conversion de données
Ce composant permet de convertir les données d’une colonne d’entrée en un type de
données différent. La donnée convertie peut soit remplacer la colonne existante, soit
être ajoutée dans une nouvelle colonne.
Copie de colonnes
Cela permet de créer de nouvelles colonnes qui sont la copie de colonnes existantes.
Les nouvelles colonnes permettent de fournir une plus grande flexibilité dans le
cadre de nouveaux calculs, de transformation ou de mapping avec des colonnes de
destination.
Figure 5.37 — Visual Studio for Application s’ouvre pour créer le script
Dimension à variation lente (slowly changing dimension)

SSIS présente un mécanisme qui permet de traiter les trois types de variation
dimensionnelle. En effet, les axes dimensionnels ont tendance à évoluer dans le
temps. Il s’agira par conséquent de se déterminer sur la traçabilité de la variation des
dimensions dans le temps ou bien de ne pas en tenir compte. Un client qui change de
pays est toujours client de l’entreprise. Dans ce cas, vouloir analyser le chiffre d’affaires
réalisé dans tel pays ou tel autre peut avoir un sens. Si donc l’on désire conserver la
trace des différents états du client, on parlera de variation de dimension de type 2
(SCD 2). A contrario, la distinction relative au changement de contact peut ne pas
être pertinente. Dans ce cas, le nouveau contact du client remplacera purement et
simplement l’ancien et nous perdrons toute capacité à suivre l’évolution des contacts
du client dans le temps. Il s’agit de variation dimensionnelle de type 1 (SCD 1).
Chacun de ces types de transformation de dimension à variation lente nécessite
de prendre en charge quatre types de modifications :
• modification d’attribut (SCD 1) ;
• modification d’attribut d’historique (SCD 2) ;
• modification d’attribut fixe (SCD 0) ;
• modification de membre inféré.
Le type modification d’attribut remplace les champs des enregistrements existants.

Ce type de modification est équivalent à une modification de type 1. La transformation
de dimension à variation lente dirige ces lignes vers une sortie nommée Sortie de
mises à jour d’attribut de validation.
Les modifications d’attribut d’historique créent de nouveaux enregistrements au

lieu de mettre à jour les enregistrements existants. La seule modification autorisée
dans un enregistrement existant est une mise à jour d’une colonne qui indique si
l’enregistrement est actif ou expiré En général deux champs de type Date permettent de
préciser la période de validité d’un enregistrement de la dimension (Date de début de validité
et Date de fin de validité). Ce type de modification qui préserve l’historique équivaut
à une variation de type 2. La transformation de dimension à variation lente dirige
ces lignes vers deux sorties : Sortie d’insertions d’attribut d’historique et Nouvelle
sortie. Ce type de variation a un fort impact sur les tables de faits puisque celles-ci
devront être reliées à la dimension non plus par la clé d’entreprise (ex : code client)
mais par une clé de substitution (surrogate key).
Les modifications d’attribut fixe indiquent que la valeur de colonne ne doit pas
changer. La transformation de dimension à variation lente détecte les modifications
et peut diriger les lignes modifiées vers une sortie nommée Sortie d’attribut fixe.
En général les dimensions sont traitées avant les faits qui leur sont rattachés. Parfois
les faits sont connus avant les dimensions qui les qualifient. Que faire dans ce cas ?
Faut-il rejeter purement et simplement le fait ou faut-il créer une ligne d’attente dans
la dimension afin que le fait ne reste pas « orphelin ». C’est tout l’intérêt de créer un
membre inféré ou membre déduit du fait.
Le mécanisme est alors le suivant. Lors du traitement de la table de fait, la ligne
ne permettant pas de trouver correspondance avec la clé de dimension déclenche un
processus qui permet de créer artificiellement une ligne de dimension dont la seule
valeur est la clé d’entreprise elle-même déduite du fait. C’est pour cela que l’on parle
de membre déduit (membre inféré). Lors d’un traitement ultérieur de la dimension, et
lorsque l’information attendue nous sera parvenue, la dimension sera alors complétée.
La branche parcourue dans la tâche de dimension à variation lente sera la troisième,
celle qui traite les membres inférés (sortie de mises à jour de membre déduit).
Il est à noter que lors du traitement d’une même ligne d’une dimension il est
possible d’observer des modifications de type 1 ET de type 2.
Comment fonctionne l’assistant de création de dimension à variation lente

(type 2)
Sélectionnez le gestionnaire de connexions pour accéder à la source de données qui
contient la table de dimension à mettre à jour.
Vous pouvez effectuer une sélection dans une liste de gestionnaires de connexions
inclus dans le package.
Sélectionnez la table ou vue de dimension à mettre à jour.
Après avoir choisi le gestionnaire de connexion, vous pouvez sélectionner la table
ou la vue à partir de la source de données.
Sélectionnez les attributs clés sur les colonnes et mappez les colonnes d’entrée aux
colonnes de la table de dimension.
Figure 5.38 — La Clé d’entreprise représente la clé invariante

de la table dimensionnelle
Vous devez sélectionner au moins une colonne de clé d’entreprise dans la table de
dimension et la mapper à une colonne d’entrée. D’autres colonnes d’entrée peuvent
être mappées à des colonnes de la table de dimension en tant que mappages non-clés.
Sélectionnez le type de modification pour chaque colonne :
• Modification d’attribut remplace les valeurs existantes dans les enregistrements.
• Attribut d’historique crée des enregistrements au lieu de mettre à jour des
enregistrements existants.
• Attribut fixe indique que la valeur de colonne ne doit pas changer.
Figure 5.39 — L’assistant présente les trois types d’attribut de dimension

Si vous configurez des colonnes de façon à utiliser le type de modification

Attribut d’historique, vous devez choisir comment effectuer la distinction entre les
enregistrements actifs et expirés. Vous pouvez utiliser une colonne d’indicateurs de
lignes actives ou deux colonnes de date pour identifier les lignes actives et expirées.
Si vous utilisez la colonne d’indicateurs de lignes actives, vous pouvez lui affecter les
valeurs Current ou True pour les lignes actives et Expired ou False pour les lignes
expirées. Vous pouvez également entrer des valeurs personnalisées. Si vous utilisez
deux colonnes de date, une de début et une de fin, vous pouvez spécifier la date à
utiliser lors de la définition des valeurs de colonnes de date en tapant une date ou en
sélectionnant une variable système et en utilisant sa valeur.
Figure 5.40 — L’assistant permet de paramétrer les options d’attribut d’historique
Dans l’exemple ci-dessus les enregistrements expirés contiennent une date de

début et une date de fin. Les enregistrements actifs contiennent uniquement une date
de début. Ci-dessus, la variable système Creationdate sert à alimenter les dates de début
et fin.
Spécifiez si nécessaire la prise en charge des membres inférés et sélectionnez les
colonnes que l’enregistrement de membre inféré contient.
Lors du chargement de mesures dans une table de faits, vous pourrez créer des
enregistrements minimaux pour les membres inférés qui n’existent pas encore. Lorsque,
par la suite, des données significatives seront disponibles, les enregistrements de
dimension pourront être mis à jour. Il est possible de créer les types d’enregistrements
minimaux suivants :
• un enregistrement dans lequel toutes les colonnes avec des types de modification
sont nulles ;
• un enregistrement dans lequel une colonne booléenne indique que l’enregistre-
ment est un membre inféré.
Figure 5.41 — Un enregistrement de membre inféré

est un membre de dimension inconnu (généré grâce à la ligne de faits)
Examinez les configurations créées par l’assistant Dimension à variation lente. En

fonction des types de modifications pris en charge, différents ensembles de composants
de flux de données sont ajoutés au package.
La figure 5.42 illustre un exemple de flux de données qui prend en charge les
modifications d’attributs fixes, d’attributs variables et d’attributs d’historique, et les
modifications d’enregistrements correspondants.
Figure 5.42 — SSIS génère automatiquement les tâches nécessaires

à la création de dimensions à variation lente par insertion
d’attribut d’historique, par nouvelle sortie
1. Dans le cas de la conservation des attributs historiques (branche de droite) :

• la colonne dérivée Sales_Person_SCD_End_Date prend la valeur de la date de
création @[System : :CreationDate].
• La Transformation OLE DB permet de mettre à jour la date de
fin Sales_Person_SCD End_Date en fonction de la clé invariante
[Sales_Person_SCD_Original_ID] selon la commande SQL :
UPDATE [MaxMinSalesDM].[Sales_Person] SET [Sales_Person_SCD_End_Date] = ? WHERE

[Sales_Person_SCD_Original_ID] = ? AND [Sales_Person_SCD_End_Date] IS NULL
2. Dans tous les cas :

• La transformation unir tout permet de fusionner les deux sources (source de
lignes en ajout pur et simple et lignes en modification + ajout).
• La transformation colonne dérivée 1 permet d’attribuer la date de création
au champ date de début : Sales_Person_SCD_Start_Date. Ce champ prend la
valeur de la date de création : @[System : :CreationDate].
• La transformation finale permet d’insérer dans la table de destination un nouvel
enregistrement composé de la clé invariante Sales_Person_SCD_Original_ID
de la date de début Sales_Person_SCD_Start_Date et enfin du nom du repré-
sentant Sales_Person_Name.
Voici un extrait de notre support de formation.

Il s’agit de présenter le fonctionnement synthétique de l’alimentation d’une table
de dimension.
Figure 5.43 — Mécanisme d’alimentation d’une table de dimension Employé

Figure 5.44 — La variation de type 1 met à jour les colonnes concernées
Figure 5.45 — La variation de type 2 crée une nouvelle ligne avec incrément de la clé
de substitution EmployeeKey puis met à jour la colonne EndDate de l’enregistrement obsolète
du même employé
Figure 5.46 — Composants du flux de données générés automatiquement par l’assistant

de dimension à variation lente
Figure 5.47 — Lorsque la ligne de fait ne trouve pas de correspondance avec la dimension,
on peut mettre en place le mécanisme d’insertion d’un membre déduit dans la dimension
Échantillonnage de ligne
Il permet de sélectionner un sous-ensemble des données sources de manière aléatoire.
L’échantillonnage est basé sur un nombre de ligne à extraire.
Échantillonnage du pourcentage
Il permet de sélectionner un sous-ensemble des données sources de manière aléatoire.
L’échantillonnage est basé sur un nombre de ligne correspondant à un pourcentage du
flux d’origine.
Importation de colonne
Importe les données de fichiers vers les lignes d’un dataset. Il est possible de spécifier
les colonnes de données à extraire puis de sélectionner ligne à ligne le fichier de
destination.
Jointure de fusion
Elle établit une fusion entre des données en provenance de deux flux de données.
Cela équivaut à effectuer une jointure entre deux tables. Ainsi, par exemple, une
table Produits peut être jointe à une table Catégorie de produit par une clé étrangère
(CatProd) permettant d’établir la jointure entre les deux tables. Il est possible d’établir
des jointures FULL, LEFT, INNER. Les colonnes qui établissent la jointure doivent
être de type compatible. Les deux tables doivent être triées préalablement sur le champ
permettant la jointure.
Multidiffusion
La transformation de multidiffusion dirige sa sortie vers une ou plusieurs sorties.
Chaque ligne d’entrée dirige ses données vers chaque sortie.
Nombre de lignes
Cette transformation détermine le nombre de lignes dans le flux de données. Le
compteur est ensuite stocké dans une variable du package. La variable peut ensuite
être récupérée afin de modifier le flux de contrôle ou le flux de données.
Recherche
Cette transformation exécute une requête dans un ensemble de référence (table, vue).
Le paramètre d’extraction est fourni par une colonne du flux d’entrée. La table de
référence renvoie un ou plusieurs champs en retour.
Il existe trois sorties de recherche :
• Sortie de recherche avec correspondance (clé trouvée)
• Sortie de recherche sans correspondance (clé non trouvée)
• Sortie d’erreur de recherche (recherche impossible).
Recherche de terme
On recherche les occurrences d’un ensemble de mots ou de phrases dans un flux
de données comportant du texte libre. Le résultat de cette transformation est un
ensemble de lignes précisant le comptage d’occurrences trouvées et le terme de la
table de référence.
Recherche floue
La transformation de recherche floue permet d’effectuer des tâches de nettoyage dans
le but de corriger, puis de standardiser les données. L’algorithme de recherche floue
permet également de fournir des données manquantes. Cette transformation présente
un fort intérêt lorsque les données en entrée ont fait l’objet d’une saisie libre et n’ont
pas été contrôlées à la source.
Regroupement probable
La transformation de regroupement probable identifie des lignes de données sus-
ceptibles d’être des doublons. Une correspondance exacte garantit que seules les
colonnes possédant des valeurs identiques dans cette colonne seront regroupées. Une
correspondance approximative regroupe des lignes ayant des données approchantes.
C’est l’utilisateur qui définit le score de similarité basé sur une notion de distance entre
deux chaînes de caractères. Paris et Pari ont une distance de 1 car un seul caractère
sépare les deux mots. Idem pour Cathy et Kathy. En revanche Kathy et Kathryn ont
une distance de 2.
Requête d’exploration de données

Une requête d’exploration de données utilise un modèle de data mining afin de réaliser
des prédictions sur chaque ligne du flux de données. C’est ainsi par exemple qu’il
est possible de prédire si un client sera un bon candidat pour l’achat de tel produit.
L’algorithme de prédiction se base sur des requêtes DMX (Data Mining Extension).
Supprimer le tableau croisé dynamique (transformation Unpivot)

Une fonction Unpivot transforme un flux de données dénormalisé, en un flux norma-
lisé.
ClientID Tél. Domicile Tél. Travail Tél. Mobile Fax

1234 04 50 60 01 02 01 69 30 03 04 06 80 47 13 15
2345 05 06 07 08 09 05 07 08 09 10 05 07 08 09 11
Figure 5.48 — Exemple de flux dénormalisé

Voici le data set après transformation.
Tableau 5.2 — Flux normalisé

Client ID Type de tel No de ligne
1234 Domicile 04 50 60 01 02
1234 Travail 01 69 30 03 04
1234 Mobile 06 80 47 13 15
2345 Domicile 05 06 07 08 09
2345 Travail 05 07 08 09 10
2345 Fax 05 07 08 09 11
Tableau croisé dynamique (transformation Pivot)

Une fonction Pivot (à l’inverse de Unpivot) transforme un flux de données normalisé
en un flux dénormalisé (exemple inverse du précédent).
Transformation du cache
La transformation du cache écrit des données provenant d’une source de données
connectée dans le flux de données directement dans un gestionnaire de connexions
du cache. La transformation de recherche (lookup) peut ainsi effectuer des recherches
dans un cache dont le contenu peut être modifié dynamiquement lors du traitement.
Table de caractères
La transformation de table de caractères permet d’effectuer des conversions sur des
colonnes de type chaîne de caractères. Il est possible de convertir des chaînes en
minuscules ou majuscules, d’inverser l’ordre des caractères.
Tri
Cette fonction trie les données d’entrée dans l’ordre croissant ou décroissant et copie
les données triées dans la sortie. Plusieurs imbrications de tri sont possibles et pour
chaque colonne triée, il est possible de préciser l’ordre ascendant ou descendant.
Unir tout
La transformation d’union totale permet de combiner plusieurs entrées en une seule
sortie. On reparle de concaténation des sources de données. La première entrée fournit
le format qui servira à mapper les colonnes avec le flux de sortie.
5.4.3 Destinations du flux de données
Figure 5.49 — Destination du flux de données
Les données ont maintenant été transformées dans le format attendu, nous devons
maintenant les stocker dans une destination. Voici les options disponibles pour le
stockage des données (figure 5.49) :
• Apprentissage du modèle d’exploration de données : les données reçues par
la destination sont transmises au modèle d’exploration (algorithme de data
mining) afin d’être exercées. Plusieurs modèles peuvent faire l’objet d’un
apprentissage.
• Destination DataReader permet d’utiliser ADO.NET pour le stockage des
données de destination.
• Destination de fichier brut permet d’écrire un flux de données dans un fichier au
format natif de SSIS. Ce type de fichier est utilisé afin d’obtenir des performances
maximales.
• Destination de fichier plat ou fichier au format TXT.
• Destination de l’ensemble d’enregistrements insère un Recordset dans une
variable dont le contenu peut être affiché en dehors du flux de données.
• Destination Excel envoie un flux de données dans une feuille Excel.
• Destination OLE DB transfert le flux de données vers toute table d’une base
de données compatible OLE DB.
• Destination pour SQL Server envoie le flux de données directement dans une
table ou vue SQL Server. Cette fonction est équivalente à la tâche de Bulk
Insert. Cette tâche offre de grandes performances.
• Destination de SQL Server Mobile envoie un flux de données vers la version
mobile de SQL Server.
• Traitement de dimension envoie un flux de données visant à ajouter des
données nouvelles dans une dimension de Analysis Services.
• Traitement de Partition permet d’alimenter une partition d’un cube dans
Analysis Services.
6
Les assistants de l’ETL
Nous l’avons vu dans le chapitre précédent, la grande force de Business Intelligence

Visual Studio est de simplifier en profondeur la tâche des programmeurs, en offrant une
large panoplie d’outils d’utilisation simple. L’essentiel des fonctions de manipulation
des données se retrouve dans les flux de contrôle et les flux de données. Ces outils
de base peuvent cependant dérouter le développeur habitué à réaliser des tâches
identiques en codant des lignes en C++, C# ou VB. En effet, le choc culturel n’est pas
neutre, car le développeur habitué à gérer la complexité va être fortement concurrencé
par la mise à disposition de nouveau outils simplificateurs. L’entreprise et son personnel
devraient cependant y trouver un avantage de taille. En effet, la finalité de toute
organisation est de rester centrée sur son propre métier et non de gérer la complexité
des outils susceptibles de l’aider dans son activité.
La réponse de SQL Server 2008 et son outil de développement intégré Business
Intelligence Development Studio consiste à occulter une grande partie de cette
complexité et d’amener progressivement l’utilisateur à réfléchir sur son métier.
Microsoft a envisagé d’accompagner le DBA dans son évolution vers l’environne-
ment SQL Server 2008 et SSIS dispose d’un grand nombre d’assistants permettant
d’effectuer ces migrations. Outre le fait qu’ils présentent une réelle utilité, ils ont le
mérite d’être formateurs. Voyons dans le détail quelques-uns des assistants de haut
niveau.
136 Chapitre 6. Les assistants de l’ETL
6.1 UTILISER L’ASSISTANT POUR GÉNÉRER

UN LOT IMPORT
6.1.1 Créer le projet d’importation
L’ assistant d’importation et d’exportation permet d’effectuer des transferts d’objets
entre plusieurs bases de données elles-mêmes réparties sur des serveurs différents.
L’assistant permet également de créer un package SSIS qui pourra être exécuté
ultérieurement. Afin de lancer l’assistant, dans BI Studio vous pouvez exécuter la
séquence suivante :
Figure 6.1 — Nommer le projet
Démarrer le programme : Programmes/SQL server 2008/SQL Server Business

Intelligence Development Studio.
Appeler le menu.
Fichier/Nouveau/Projet/Projet Integration Services.
SSIS détermine un emplacement par défaut pour le projet. Cet emplacement est
naturellement modifiable.
6.1 Utiliser l’assistant pour générer un lot import 137
Figure 6.2 — Assistant Projet d’Importation/Exportation SQL Server
La validation du projet entraîne la création du projet.

Pour notre exemple, choisissons deux sources de données au format différent.
La source de données Produits sera puisée dans une base Comptoir d’Access.
La source de données Clients sera puisée dans un tableau Excel. Ces deux tables
dimensionnelles seront stockées dans l’entrepôt de données grâce à notre procédure
d’import. Afin de simplifier, nous faisons l’hypothèse que les tables Clients et Produits
sont recréées à chaque transfert.
Voici l’affichage de la table Produits dans Access (figure 6.3).
Figure 6.3 — La table source Produits stockée dans Microsoft Access

Choisissons la source de données Access et la base Comptoir.mbd (figure 6.4).
Figure 6.4 — Définition de la source de données
Choisissons la destination SQL Native Client sur le serveur local (figure 6.5).
Figure 6.5 — Définition de la base de données destination

Voici l’affichage de la table Customers dans Excel.
Figure 6.6 — Fichier Customers stocké dans une feuille Excel
Choisissons la source de données Excel et le fichier Customers.xls. L’assistant

demande de spécifier les données sources à transférer (tables ou vues/requêtes). Faisons
le choix de Copier les données à partir d’une ou plusieurs tables ou vues plutôt que
d’écrire une requête.
Parmi la liste des sources disponibles dans Access, sélectionnons la table Produits
(figure 6.7).
Figure 6.7 — Cet écran permet de sélectionner les tables

ou requêtes en provenance de la source de données
Par défaut, la table de destination porte le nom de la table en entrée. Celui-ci est
naturellement modifiable.
Figure 6.8 — Cet écran montre la phase

de création de la table Produits dans la base de destination
La figure 6.8 montre la mise en correspondance des colonnes source et de destina-

tion. Le nommage des champs de destination et leur type sont déduits des attributs
des colonnes source.
Le bouton Modifier SQL... permet de contrôler l’action effectuée par l’assistant.
À ce stade, il est possible d’afficher le contenu de la table source grâce au bouton
Aperçu.
L’assistant récapitule l’action qu’il va entreprendre.
Cliquez sur Terminer pour effectuer les actions suivantes :
• Copier les lignes de Produits vers [AdventureWorksDW].[dbo].[Produits]. La
table cible sera supprimée puis recréée.
• Le package sera enregistré dans le fichier de package « C :\Documents and
Settings\Administrateur\Mes documents\Visual Studio 2008\Projects\Projet
Import de données\Projet Import de données\Package1.dtsx ».
Le package ne sera pas exécuté immédiatement. L’assistant termine sa tâche en

créant les tâches nécessaires à l’exécution du lot.
Figure 6.9 — Le rapport d’exécution de l’assistant Importation et Exportation
Après cette exécution, l’assistant crée le nouvel environnement du projet dans

Visual Studio.
Figure 6.10 — Un package est automatiquement créé
Quelles tâches ont été créées par l’assistant ?

• deux connexions (une connexion pour la source des données et une pour leur
destination) ;
• trois tâches de flux de contrôle :
– tâche de suppression de la table Produits :
– tâche de création de table Produits (nommée Tâche SQL de préparation

dans la figure 6.10) :
– tâche de flux de données, elle-même composée d’un ensemble de sous-tâches
développées dans l’onglet Flux de données (figure 6.11).
Figure 6.11 — L’onglet Flux de données est composé d’une source de données
et d’une destination
La figure 6.12 détaille la source de données Produits et montre les colonnes

externes constitutives de la source OLE DB (Access). L’opérateur a la capacité de
ne sélectionner que certaines d’entre elles et ou de renommer les champs en sortie.
La fonction mappage de l’éditeur de destination OLE DB permet de relier les
champs sources avec les champs de la table de destination. Dans la figure 6.13 on
observe un mappage des champs de la table Produits d’Access avec les champs de la
table Produits de AdventureWorksDW.
Figure 6.12 — Éditeur de destination OLE DB
Les champs qui portent des noms identiques sont mappés automatiquement. Il
conviendra au développeur de s’assurer que les types des champs source et destination
sont compatibles entre eux.
6.1.2 Exécuter le lot

L’exécution du package est lancée à l’aide de la touche F5 ou Déboguer/Démarrer le
débogage.
L’exécution du package est lancée. La progression est vérifiée à l’aide de couleurs
différentes que prend successivement chaque tâche. La couleur jaune indique que la
tâche est active. La couleur verte indique que la tâche a été réalisée avec succès. La
couleur rouge indique que la tâche a été mise en échec.
Dans notre exemple, lors de la première exécution, la première tâche (tâche de
suppression de table) est mise en échec puisque la table n’existe pas dans la base de
destination. Les autres tâches sont exécutées avec succès.
L’onglet Résultat d’exécution permet de connaître le déroulement du lot, le temps
passé pour chacune des tâches et le résultat de leur exécution.
Figure 6.13 — Onglet résultat d’exécution
À l’issue du traitement, ne pas oublier de stopper le mode débogage.
6.1.3 Modifier le lot

Nous allons apporter une modification à notre lot en y ajoutant le transfert de données
en provenance d’une table Excel. Il s’agit de la table Clients.
La table Clients doit exister dans la base AdventureWorks avant de procéder au
transfert depuis Excel.
À ce stade, nous avons la possibilité de coder à la main la procédure de suppression
de la table Clients suivie de sa création.
Une façon simple de générer un code parfait est de procéder à l’import du fichier
Excel dans la base AdventureWorksDW puis d’utiliser l’assistant de génération de
scripts de table.
À l’aide de SQL server Management studio, nous allons effectuer un import du
fichier Excel afin de créer la table dans la base AdventureWorks. À l’aide d’un clic droit
sur la base AdventureWorks Tâches/Importer les données. Puis on utilise l’assistant
pour importer les données Excel.
Ensuite nous utilisons l’utilitaire qui permet de générer le code T-SQL de création
de table.
Dans Management Studio, on déplie la liste des tables (clic droit sur la table
Clients).
Dans la figure ci-dessus l’assistant de management studio (CREATE to) crée un
script SQL de création de la table Clients.
Clic droit sur la table Clients puis Générer un script de la table en tant
que/CREATE To/nouvelle fenêtre de l’éditeur de requête.
USE [AdventureWorksDW]
GO
/****** Objet : Table [dbo].[Clients]
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [dbo].[Clients](
[FirstName] [nvarchar](255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
[MiddleInitial] [nvarchar](255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
[LastName] [nvarchar](255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
[BirthDate] [datetime] NULL,
[MaritalStatus] [nvarchar](255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
[Gender] [nvarchar](255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
[EmailAddress] [nvarchar](255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
[YearlyIncome] [float] NULL,
[TotalChildren] [float] NULL,
[NumberChildrenAtHome] [float] NULL,
[Education] [nvarchar](255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
[Occupation] [nvarchar](255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
[HouseOwnerFlag] [float] NULL,
[NumberCarsOwned] [float] NULL,
[AddressLine1] [nvarchar](255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
[AddressLine2] [nvarchar](255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
[City] [nvarchar](255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
[State] [nvarchar](255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
[ZIP] [float] NULL,
[Phone] [nvarchar](255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
) ON [PRIMARY]
Nous avons également besoin de supprimer la table avant sa création. Voici le

code généré par l’assistant :
USE [AdventureWorksDW]
GO
/****** Objet : Table [dbo].[Clients]Date de génération du script : 05/27/2006
20 :59 :59 ******/
IF EXISTS (SELECT * FROM sys.objects WHERE
object_id = OBJECT_ID(N’[dbo].[Clients]’) AND type in (N’U’))
DROP TABLE [dbo].[Clients]
Revenons dans notre projet d’import des données dans Visual Studio.
Figure 6.14 — Ajouter la connexion

puis le code qui permet de supprimer la table Clients
Dans l’onglet Flux de données, glissons à deux reprises une tâche d’exécution de
requête SQL. La première consiste à effectuer un DROP de la table Clients.
Figure 6.15 — Ajouter la connexion puis la requête SQL

générée dans SQL Server Management Studio
Compléter la connexion puis le code SQL par un copier-coller en provenance du

résultat du query de SQL Server Management Studio.
Reliez les tâches entre elles à l’aide des flèches comme précisé dans la figure 6.16.
Figure 6.16 — Se positionner dans l’onglet Flux de données

et faire apparaître la boîte d’outils à gauche (Affichage/Boîte d’outils)
Depuis les sources de flux de données, faire glisser la source Excel sur l’onglet Flux
de données, puis double-cliquez sur la tâche Source Excel.
Figure 6.17 — La source Excel est créée. Le signe « stop » à droite indique que le fichier source
n’est pas précisé. Le gestionnaire de connexion Excel s’ouvre. Une nouvelle connexion doit être
créée vers le fichier source Excel
Dans le gestionnaire de connexion OLE DB, choisir Gestionnaire de connexions

Excel.
Dans le champ mode d’accès aux données, choisir Table ou Vue.
Dans le champ nom de la feuille Excel, choisir Customers$.
Le gestionnaire de connexion fait immédiatement apparaître la nouvelle
connexion Excel.
Par un glisser-déplacer depuis la barre d’outils, créons maintenant la destination
OLE DB. Compléter le gestionnaire de connexion OLE DB puis indiquer le nom de
la table réceptrice [dbo].[Clients].
Nous relions maintenant les deux tâches à l’aide de la flèche verte. Le mappage
des champs se réalise automatiquement.
Renommez les tâches afin de les rendre plus compréhensibles.
L’onglet Flux de données doit ressembler à l’écran de la figure 6.18.
Figure 6.18 — Onglet Flux de données
Sauvegardez tous les fichiers puis exécutez le lot par la touche F5.
Les tâches se déroulent en parallèle.
Stoppez le débogage après exécution.
Prenez la précaution de contrôler le contenu des deux tables Clients et Produits à
l’aide de Management Studio. Faire un clic droit sur le nom de la table puis ouvrir la
table. Observez le contenu de la table et le nombre d’enregistrements situé en bas de
page.
Ajoutons à présent une tâche d’envoi de courriel à l’administrateur afin d’être
prévenu en cas d’achèvement sans échec ou en cas d’échec.
Dans l’onglet Flux de contrôle, ajoutons deux tâches « Envoyer un message ».
Créez une connexion SMTP pour l’envoi de courriel (figure 6.19).
Figure 6.19 — Éditeur du gestionnaire de connexion FTP

Configurez les propriétés pour le message électronique (figure 6.20).
Figure 6.20 — Éditeur de tâche d’envoi de mail
L’éditeur de tâche d’envoi de message électronique permet de préciser le serveur

SMTP d’envoi de mail. Il permet de préciser le ou les destinataires du mail. Les pièces
jointes peuvent être des fichiers d’anomalies générés lors de l’exécution du package ou
tout autre fichier. Les variables systèmes ou utilisateurs peuvent être introduites dans
le corps du texte rendant ainsi les messages dynamiques.
Relier les tâches entre elles à l’aide des flèches vertes.
Double-cliquez sur la flèche afin de paramétrer des contraintes en cas d’échec de
l’opération ou en cas de succès.
Figure 6.21 — L’envoi de message est fonction de l’exécution

avec ou sans échec de la tâche de flux de données
Il est possible de traiter le lot complet.

Figure 6.22 — L’onglet gestionnaire d’événements

permet d’effectuer des tâches en fonction d’événements lors de l’exécution du lot
6.1.4 Migration de lots DTS de la version 2000 vers 2008

Nous l’avons vu, SSIS comprend toutes les fonctionnalités de DTS 2000 et bien plus.
Cependant, la migration de certaines fonctionnalités en provenance de DTS 2000
ne se fait pas. C’est les cas notamment des paramètres gérés par DTS et de façon
totalement différente avec SSIS.
C’est pour cette raison que SSIS permet d’exécuter des lots DTS 2000 sans aucune
migration. Lorsque SSIS doit exécuter DTS 2000, il est nécessaire qu’une instance
de SQL Server 2000 soit disponible sur un serveur ou que SQL server 2000 DTS
Run-time soit installé sur la machine exécutant SSIS. Si les lots doivent être modifiés,
il est nécessaire que SQL Server 2000 Enterprise Manager soit installé. SSIS permet
d’instancier DTS 2000 comme une tâche exécutable.
SSIS dispose d’un assistant de migration pour la conversion des lots DTS en lots
SSIS 2008. Les éléments de DTS sont convertis en tâches SSIS. Chaque élément qui
ne peut être converti est placé dans un nouveau package DTS puis appelé par SSIS.
La migration des lots DTS se fait grâce à un assistant de SQL Server BI Studio.
Ouvrez ou créez un projet de type Integration services. L’assistant va vous permettre
de migrer un package DTS 2000 au travers des étapes qui suivent.
Projet/Migrer un package DTS 2000

Préciser le nom du Serveur SQL 2000 renfermant le lot DTS.
Choisir la destination.
Figure 6.23 — Sélectionner le serveur qui renferme la base de destination
Cliquez sur Terminer pour mettre fin aux opérations suivantes :

• Migrer le package vers SQL Server Integration Services.
Figure 6.24 — Choisir les lots DTS 2000 à migrer vers 2008
Les options suivantes ont été sélectionnées :

• Source à partir de laquelle les packages sont migrés :
– Type de source = Microsoft SQL Server.

– Nom de la source = SERVEURDELL.
• Destination où doivent être stockés les packages migrés :
– Type de la destination = Microsoft SQL Server.

– Nom de la destination = (local).
• Le nom du fichier journal est C :\Documents and
Settings\Administrateur\DTSlogBB.log.
• L’assistant demande de préciser un fichier journal dans lequel il va stocker le
déroulement des étapes de migration.
Les packages suivants seront migrés :

EssaiDTS À EssaiDTS.
• Nombre total de packages à l’emplacement source = 1.
• Nombre de packages qui seront à migrer = 1.
• Nombre de packages qui ne seront pas migrés = 0.
• Les paramètres attachés aux lots DTS 2000 ne sont pas récupérés par SQL
Server 2008.
Figure 6.25 — Formulaire de synthèse des actions menées par l’assistant

6.1.5 Déploiement de packages SSIS

Le processus de déploiement de package se déroule en deux étapes :
• 1. La première étape consiste à créer le projet Integration Services afin de créer
un utilitaire de déploiement de package.
• 2. La seconde étape consiste à copier le dossier de déploiement créé en même
temps que le projet Integration Services sur l’ordinateur cible, puis à exécuter
l’Assistant Installation de package pour installer les packages.
Créer l’utilitaire de déploiement

Pour accéder aux propriétés d’un projet Integration Services, cliquez avec le bouton
droit sur le nom du projet, puis cliquez sur Propriétés.
Figure 6.26 — L’attribut CreateDeployementUtility doit être à True
Passer à True la variable CreateDeploymentUtility.

Puis OK.
Lorsque vous générez un projet Integration Services, un fichier manifeste, <nom
de projet>.SSISDeploymentManifest.xml et des copies des packages du projet et des
dépendances de package sont créés et ajoutés dans le dossier bin\Deployment dans
le projet ou à l’emplacement spécifié dans la propriété DeploymentOutputPath. Le
fichier manifeste répertorie les packages, les configurations de package et tous les
divers autres fichiers du projet.
Installation du déploiement
L’installation du déploiement permet de stocker le package sur le serveur Integration
services.
L’Assistant Installation de package vous accompagne dans le processus d’installa-
tion des packages sur le système de fichiers et sur SQL Server.
Clic droit sur <nom de projet>.SSISDeploymentManifest. puis deploy.
Figure 6.27 — L’assistant permet de déployer des packages SSIS

soit sous forme de systèmes de fichiers système (XML)
ou dans SQL Server
Conserver le dossier par défaut puis Suivant deux fois.

L’assistant permet de sélectionner un répertoire de destination.
Vous pouvez vérifier la bonne installation du package en vous connectant au
serveur Integration services. Dans File System retrouvez votre projet puis exécutez le
package.
Lorsque le package est opérationnel dans le serveur Integration Services vous
pouvez en planifier l’exécution.
6.1.6 Automatisation de l’exécution des packages

L’automatisation de l’exécution de packages permet de planifier tous types de tâches
et en particulier des tâches quotidiennes d’alimentation de l’entrepôt de données. Les
administrateurs pourront utiliser cette facilité pour exécuter des tâches de sauvegardes,
ou de ré indexation des bases opérationnelles.
Dans Management studio Démarrer le service SQL Server Agent. Ce service peut
être démarré automatiquement lors du démarrage de SQL server. SQL server Agent
peut être démarré manuellement lors de la connexion au moteur de base de données
SQL server.
• Clic droit sur SQL server Agent puis démarrer.
• Ouvrir SQL server Agent.
• Clic droit sur Travaux.
Figure 6.28 — L’assistant permet de créer un nouveau travail
Lors de l’exécution d’un travail de l’agent SQL préciser qu’il s’agit d’un package
SQL Server Integration services et que la source de fichiers est Système de fichiers
(pour les packages au format XML). Vous devez également fournir l’emplacement du
package déployé précédemment sur le serveur SSIS.
Avant de planifier l’exécution du package vous pouvez le tester dans son environ-
nement de production (clic droit puis exécuter le package).
Figure 6.29 — Interface du planificateur de tâches intégré à SQL Agent
Ci-dessus nous avons programmé une exécution du package leçon 1.dtsx toutes les
nuits du lundi au vendredi à 0 h 00.
Le moniteur d’activité des travaux de SQL server Agent permet de suivre l’exécu-
tion des travaux et leur traçabilité.
Vous pouvez également consulter la visionneuse du fichier journal.
6.1.7 Assistant de mise à niveau des packages SSIS 2005 vers 2008
SQL Server 2008 fournit un Assistant Mise à niveau de packages SSIS afin de migrer
les packages créés dans la version BIDS 2005. à cet effet. Il est possible de configurer
l’Assistant pour qu’il sauvegarde les packages d’origine. Cet assistant est disponible
dans les éditions Standard Enterprise et Developer de SQL Server.
L’Assistant Mise à niveau de packages SSIS est accessible dans le menu d’Integra-
tion Services. Menu SSIS puis Projet -> Mettre à niveau tous les packages.
• Dans BIDS, créez ou ouvrez un projet Integration Services.
• Dans l’Explorateur de solutions, cliquez avec le bouton droit sur le nœud
Packages SSIS, puis cliquez sur Mettre à niveau tous les packages pour mettre
à niveau tous les packages sous ce nœud.
6.2 Concept de packages dynamiques 157
Pour exécuter l’Assistant à partir de SQL Server Management Studio :

• Dans SQL Server Management Studio, connectez-vous à Integration Services,
développez le nœud Packages stockés, cliquez avec le bouton droit sur le nœud
Système de fichiers ou MSDB, puis cliquez sur Mettre à niveau les packages.
Pour exécuter l’Assistant à l’invite de commandes :

• À l’invite de commandes, exécutez le fichier SSISUpgrade.exe à partir du dossier
C:\Program Files\Microsoft SQL Server\100\DTS\Binn.
Lorsqu’il sauvegarde les packages d’origine, l’Assistant stocke une copie des
packages d’origine dans un dossier SSISBackupFolder. Il crée le dossier SSISBa-
ckupFolder en tant que sous-dossier du dossier qui contient les packages d’origine et
les packages mis à niveau.
6.2 CONCEPT DE PACKAGES DYNAMIQUES

Il existe un grand nombre d’outils visant à modifier les tâches qu’un package peut
exécuter. Pour ce faire, SSIS dispose d’un jeu de variables et d’expressions utilisées dans
le flux de contrôle et les transformations des flux de données. Les configurations ont
pour but de modifier l’environnement de travail d’un package SSIS (par exemple,
changement de serveur et des sources de données lors de la mise en production).
6.2.1 Les expressions

SSIS intègre un langage permettant de spécifier les transformations dans les flux de
données. La plupart des expressions ont une syntaxe relativement simple telle que A
+ B ou A >= B, ou une fonction de type GetDate(). On trouve de telles expressions dans
des transformations du flux de données de type éclatement conditionnel des tables ou
colonnes dérivées.
Les expressions permettent de modifier le comportement d’un package en évaluant
des expressions afin de modifier les propriétés d’une tâche ou un composant lors de
l’exécution.
Les identificateurs sont utilisés dans des expressions qui sont inconnues jusqu’à
l’exécution du package. Les identifiants peuvent représenter des variables :
• @Filename
• @LoopCounter
• @PakageName
Les identificateurs qui représentent des variables sont toujours précédés par le
caractère @.
Les fonctions mathématiques sont supportées par les expressions.
Exemple
ABS(-1234)fournit le résultat234
ROUND(12.3456)fournit le résultat 12.35
On retrouve également des fonctions sur les chaînes de caractères : TRIM(),

UPPStyle caratère : CodeDansTexte non pris en charge
ER(), SUBSTRING(), etc.
Des fonctions portant sur les dates existent également : DATEDIFF(), DATEPART(),
GETDATE(), MONTH (), YEAR(), etc.
6.2.2 Les variables
Figure 6.30 — L’onglet Variables liste toutes les variables

(système et utilisateur) connues dans le package DimEmployee
Les variables sont utilisées pour passer des informations entre les différentes parties
d’un package. Elles peuvent être passées d’une tâche de transformation de données à
un autre ou d’une tâche de contrôle vers le gestionnaire de connexion. C’est le cas par
exemple lorsqu’une tâche a pour but de balayer tout un répertoire afin de traiter tour
à tour chacun des fichiers qui le compose. La tâche recueille donc chaque fichier puis
passe dans une variable, au gestionnaire de connexion, le nom du fichier en cours de
traitement.
Figure 6.31 — Tableau des variables utilisateur. Les noms de variables

sont sensibles à la casse (majuscules et minuscules doivent être respectées)
Les variables peuvent être créées grâce au bouton d’ajout de variable. Les noms de
variables et leur type doivent être fournis lors de la création. Il est possible également
d’allouer une valeur initiale. Afin de préserver les performances de SSIS lors de
l’exécution, les variables sont fortement typées. L’étendue de la variable définit la
visibilité de celle-ci dans le package.
Figure 6.32 — Tâche de requête SQL
La tâche d’exécution SQL de la figure 6.32 est développée ci-dessous. Cette requête
permet d’insérer des lignes dans la table AuditPkgExecution tout en recueillant les
valeurs à partir de variables alimentées au cours de l’exécution du package. Dans la

figure 6.33 les variables système et utilisateurs sont transférées aux paramètres. À leur
tour, ces paramètres (dont le nom commence par le signe @) sont transmis dans la
requête SQL (voir requête ci-dessous).
Figure 6.33 — Mappage des paramètres

entre les variables système et les paramètres
Cet exemple montre comment il est possible d’auditer les tâches qui s’exécutent
dans un package. Dans l’exemple ci-dessus on conserve la trace des traitements
dans une table de l’entrepôt de données (AuditPkgExecution) recevant les variables
système ou utilisateur, en particulier le nom du package lancé et la date de début de
l’exécution. Voici la requête correspondant à la tâche Get PkgExecKey.
INSERT INTO AuditPkgExecution

(PkgName, PkgGUID, PkgVersionGUID, PkgVersionMajor, PkgVersionMinor,
ExecStartDT, ParentPkgExecKey)
Values
(@PkgName, @PkgGUID, @PkgVersionGUID, @PkgVersionMajor, @PkgVersionMinor,
@ExecStartDT, @ParentPkgExecKey)
6.2.3 Les configurations

La technique des configurations répond à un besoin d’adaptation à divers environne-
ments d’exploitation. Les valeurs prises par défaut peuvent être modifiées dynamique-
ment lors de l’exécution du package. L’application d’un fichier de configuration permet
d’initialiser des variables. Un des points majeurs du système de configuration consiste
à modifier dynamiquement les connexions aux serveurs sans modifier le contenu du
package. Plusieurs packages peuvent utiliser le même fichier de configuration. Il est
également possible de définir l’ordre dans lequel les fichiers de configuration doivent
s’appliquer.
SSIS peut charger les configurations à partir de plusieurs types de source : SQL Ser-
ver, un fichier XML, une variable d’un package parent, une variable d’environnement
de Windows ou une entrée du registre.
Figure 6.34 — SSIS permet de créer un fichier

de paramètres grâce au gestionnaire de configurations
Le lancement du gestionnaire de configuration s’effectue à partir du menu dispo-

nible ; choisir Gestionnaire de configurations comme indiqué dans la figure 6.29.
L’exécution d’un package SSIS s’effectue généralement grâce aux commandes
DTExecUI ou DTExec ou grâce à l’Agent SQL qui exécute un package stocké dans le
serveur Integration Services. Lors de la publication d’un projet SSIS sur le serveur
de production le ou les fichiers de configuration attachés à ce projet sont également
transférés sur le serveur. Lors de la procédure de déploiement, l’opérateur peut modifier
le contenu du fichier de configuration afin de tenir compte de l’environnement de
production.
Figure 6.35 — Ci-dessus contenu du fichier de configuration au format XML. Ce fichier peut être
modifié par l’administrateur afin de correspondre à l’environnement de production
</Configuration>
<Configuration ConfiguredType="Property"
Path="\Package.Variables[User::DeployFolderName].Properties[Value]"
ValueType="String">
<ConfiguredValue>C:\Formation BI\SolutionBI\CoursSSIS\</ConfiguredValue>
</Configuration>
L’extrait ci-dessus montre la configuration de la variable du package Deploy-

FolderName de type String. Au moment de l’exécution du package la variable
DeployFolderName recevra la valeur située entre les balises <ConfiguredValue> et
</ConfiguredValue>
6.2.4 La gestion des événements

Le gestionnaire d’événement permet entre autres de contrôler l’état de fonctionne-
ment d’un serveur ou d’envoyer un e-mail à l’administrateur lorsqu’une erreur survient
dans l’exécution d’un package.
On trouve des événements de type OnError, OnPreExecute, OnPostExecute, etc.
Par exemple un événement OnError permet de déclencher la restauration d’une
base en cas d’anomalie lors du déroulement.
6.3 PLANIFICATION DU PROJET ETL

La carte de haut niveau
La connaissance des outils de base, exposés dans les précédents paragraphes, permet
de mieux comprendre les mécanismes de SSIS et ainsi de définir un schéma de haut
niveau permettant le dialogue entre utilisateurs métier et développeurs.
• Définir une carte des tâches à un niveau élevé.
• Déployer une copie du système et travailler sur la copie.
• Découvrir des données grâce à des outils simples de requêtage (Access en lien
ODBC vers SQL Server). Cette démarche permet de découvrir les différents
domaines à traiter, les relations entre les données et la qualité des données.
• Détailler sous forme synthétique (tableau Excel) les tables source et les tables de
destination en effectuant un « mappage » des données et leur transformation.
• Déterminer la fréquence de chargement de chaque table (dimensions et faits).
• Déterminer les données historiques de chaque table pour le premier chargement.
• Déterminer une stratégie de partitionnement des tables de faits aussi bien dans
le modèle relationnel du datawarehouse que dans le modèle OLAP.
• Définir une stratégie d’extraction des données pour chaque source système.
• Supprimer les doublons par des algorithmes adaptés.
Sur le site de l’auteur – www.buroformatic.com – vous pourrez télécharger des

modèles permettant de représenter les grandes tâches qui participent à la construction
du schéma ETL.
6.4 LES 38 RÈGLES QUI RÉGISSENT L’ETL

Afin de créer et de réussir la mise en œuvre d’un entrepôt de données, Ralph Kimball a
énoncé trente-huit règles qui participent au processus d’extraction, de transformation
et de chargement. Le processus d’ETL consomme environ 70 % du temps et de l’effort
de construction d’un datawarehouse. On peut retrouver ces règles sur le site :
http://www.intelligententerprise.com/showArticle.jhtml ?articleID=54200319.
6.4 Les 38 règles qui régissent l’ETL 163
Par chance, SQL Server Integration Services et Analysis Services fournissent un

certain nombre d’assistants qui participent naturellement à la mise en place d’un grand
nombre de ces règles.
7
Analysis Services
SQL Server Analysis Services (SSAS) est une plate-forme de développement et

d’administration permettant de créer des applications OLAP (On Line Analytical
Processing) et de data mining (fouille de données). Cette plate-forme est naturellement
incluse dans SQL Server 2008 et a pour but d’aider les utilisateurs à analyser les
données historiques et à découvrir des corrélations ou des modèles de comportement
entre les données.
Côté client, un outil de requêtage et de filtrage doit être installé (Excel ou tout
autre outil tiers : Proclarity, Panorama, Powerplay, Crystal, Report Builder, etc.).
Côté serveur, Analysis Services doit être installé et correctement paramétré au
niveau de la sécurité afin d’autoriser l’accès aux données selon le profil des utilisateurs.
Le composant central de l’infrastructure OLAP est le cube multidimensionnel. Il
s’agit d’une base de données spécialement conçue pour permettre un accès immédiat
aux données d’entreprise stockées dans les entrepôts de données.
Analysis Services est indépendant des sources de données de même que Integration
services et Reporting Services. Par exemple, une entreprise utilisera Analysis Services
dans le but de créer des cubes à partir de données stockées dans des bases telles
qu’Oracle, DB2 d’IBM, SQL Server, Access ou autres bases compatibles ODBC et
OLE DB.
Enchaînement des données en Business Intelligence

Dans la figure 7.1, on observe le positionnement de la brique Analysis Services dans
le cheminement habituel des données, depuis les sources opérationnelles (à gauche)
jusqu’à la restitution via Excel (à droite).
166 Chapitre 7. Analysis Services
Figure 7.1 — Analysis Services dans la chaîne décisionnelle
Bien que non obligatoire pour la création des cubes OLAP, l’étape de création du
datawarehouse est fortement conseillée.
Une plate-forme de développement flexible

Analysis Services 2008 offre aux développeurs en entreprise et intégrateurs une grande
flexibilité dans la modélisation des cubes et les sources de données. Cette plate-forme
propose en effet de nouveaux outils de création de cubes ainsi que huit nouveaux
algorithmes de data mining. Ces améliorations aident les développeurs à délivrer des
solutions plus complètes tout en réduisant le temps nécessaire au développement et
au déploiement.
7.1 OLAP ET LE DATA MINING

OLAP (On Line Analytical Processing) et le data mining (fouille de données) font
partie des technologies que les managers utilisent pour rassembler, stocker, interroger
et analyser des données historiques. Ces technologies font partie des outils d’aide à la
décision. Les applications OLAP sont généralement utilisées pour fournir des réponses
aux questions relatives aux performances de l’entreprise. Par exemple, une chaîne de
distribution utilisera un cube décisionnel afin d’élaborer des graphiques des ventes pour
un grand nombre de lignes de produits croisés avec des régions et des périodes de temps
afin de pouvoir par exemple répondre à la question : « Quelles sont les ventes réalisées
en quantité et valeur par point de vente pour chaque collection d’ouvrages ? ». S’il le
désire, l’analyste peut simplement ajouter un critère supplémentaire afin d’obtenir le
même tableau en comparant 2004 avec 2005 en cumul depuis le début de l’année.
Le data mining en revanche, utilise des algorithmes de reconnaissance de modèles
afin de détecter des comportements particuliers, des corrélations ou des tendances
dans les données. Une fois détectés, ces modèles et tendances sont utilisés à des
7.1 OLAP et le data mining 167
fins de prédiction dans le cadre de processus d’affaires telles que prévisions des
ventes, segmentation de populations d’individus aux comportements similaires. Ces
techniques sont également utilisées afin de mettre en place des systèmes de ventes
additionnelles (up-sell) ou ventes croisées (cross-sell).
Les cubes OLAP et les techniques de data mining sont basées sur des données
collectées et agrégées au sein des entrepôts de données.
Rappelons que la finalité d’un entrepôt de données (datawarehouse) est de stocker
et historiser des volumes importants de données. Ce processus a été illustré au chapitre
précédent grâce à SSIS. Nous l’avons vu, les entrepôts de données sont alimentés grâce
à des outils ETL (Extract, Transform, and Load). Ces outils ont pour vocation d’extraire
et de structurer les données en provenance des bases de données opérationnelles
dites OLTP (On Line Transactional Processing). La phase d’ETL réalise également
un nettoyage des données suivi généralement d’une phase d’agrégation au sein des
entrepôts.
À leur tour, ces données agrégées font l’objet d’une alimentation dans des bases de
données multidimensionnelles appelées cubes OLAP.
Un cube est défini par un certain nombre de dimensions ou axes d’observation. Au
croisement de ces dimensions se trouvent des mesures ou indicateurs. En général, le
cube permet des analyses ad hoc et des requêtes dynamiques ayant un caractère naturel
et intuitif.
Les utilisateurs accèdent aux cubes OLAP grâce à des outils d’analyse offrant ainsi
la capacité de réaliser à la volée des tableaux de synthèse et rapports graphiques.
La structure hiérarchisée des dimensions permet une analyse en profondeur des
données grâce à la technique du drill down et du roll-up. Ces techniques permettent un
forage progressif des données en passant du niveau le plus élevé au niveau de détail
le plus fin (drill down) ou selon un cheminement inversé ( drill up). Par exemple, un
utilisateur peut effectuer un drill down sur la dimension temporelle afin de visualiser
des indicateurs de ventes ou de revenus par année, puis par trimestre, par mois et enfin
par jour. Il sera alors aisé de déceler des variations saisonnières ou des tendances à
partir des graphes dynamiques générés automatiquement. De la même manière, un
chef de ventes sera capable d’analyser, pour un produit donné, les ventes effectuées
la veille par point de vente puis d’agréger rapidement les données au niveau semaine,
mois, trimestre ou année (drill up).
Les technologies OLAP, par leur aspect dynamique, et synthétique complètent
les outils de reporting tels que Reporting Services (inclus dans SQL Server 2008).
Les outils de reporting sont généralement utilisés afin de fournir des vues statiques au
travers de rapports instantanés à partir des données de l’entrepôt. À la différence des
outils de requêtage OLAP, les fonctions de forage dynamique et de changement d’axes
à la demande y sont absentes.
Le cube et sa représentation multidimensionnelle
9 000 €
Quel a été le volume de commande
■ Pour le Produit veste Mars
Fevr.
■ Dans la région ouest…
Janvier
■ Pour le mois de mars…
Est
Régions
Ouest
Nord
Sud
Chaussure
Bonnet
Veste
Produit
Figure 7.2 — Le cube et sa représentation multidimensionnelle (source : Microsoft)
L’exemple de la figure 7.2 montre la structure du cube faisant apparaître les trois
dimensions ou axes d’analyse : dimension Produits, dimension Région, dimension
Temps. La mesure analysée au croisement des trois axes est l’indicateur de volume en
valeur.
Dans cet exemple, l’outil de restitution du cube est le tableau croisé dynamique
d’Excel. On observe l’indicateur de volume du chiffre d’affaires (9 000 €) réalisé sur
les ventes des vestes pour la région Ouest et pour le mois de mars. On verra lors de
l’étude des outils de restitution que cette analyse ne prend que quelques secondes au
manager opérationnel ou au contrôleur de gestion doté de son outil favori : Excel.
7.2 COMPOSANTS D’ANALYSIS SERVICES 2008

Passons rapidement en revue les fonctionnalités de SSAS aussi bien dans le domaine
du développement d’application que de l’administration du référentiel.
UDM (Unified Dimensional Model) Modèle sémantique qui combine en un seul
référentiel les caractéristiques des organisations de données multidimensionnelles
(Cubes) et relationnelles (DW et ERP).
Le cache proactif permet une alimentation des cubes en quasi temps réel à chaque
modification des données dans le système de données opérationnelles.
Les KPI (indicateurs de performances clés) sont un nouveau mécanisme qui permet
de définir des indicateurs métiers basés sur des valeurs d’objectif, d’écart et de tendance.
La notion de feu tricolore est une illustration assez courante de ces KPI. Nous aurons
l’occasion de traiter ce sujet dans le chapitre sur la restitution des données.
7.2 Composants d’Analysis Services 2008 169
Les traductions présentent un mécanisme de traduction multilingue du référentiel

de données (metadata). Cette fonctionnalité permet aux développeurs de créer un
unique référentiel et aux utilisateurs de créer des analyses dans leur propre langue. En
plus des métadonnées (noms des champs) converties dans la langue de l’utilisateur au
moment de la consultation, les contenus des attributs de dimension peuvent également
faire l’objet de traduction afin d’afficher des rapports adaptés à la langue du lecteur.
Les scripts MDX sont des nouveaux mécanismes utilisés pour la définition des
membres calculés, des ensembles nommés et des cellules calculées. La syntaxe est
simplifiée et améliorée. Les scripts peuvent être débogués ligne à ligne.
Les procédures stockées de SSAS permettent de créer des routines en langage de
programmation CLR (Common Langage Runtime) tels que C ou VB.
Les fonctions de writeback (écriture dans le cube) permettent d’écrire dans des
cellules agrégées (et non pas uniquement au niveau de granularité le plus bas). Ce
mécanisme est utile dans le cadre de création de scénarios.
De outils et assistants de Business Intelligence permettent se simplifier la création
de :
• mesures semi-additives ;
• dimensions temporelles intelligentes ;
• de compte ;
• d’agrégations financières ;
• de conversions monétaires.
Les vues des sources de données permettent de s’affranchir de la complexité des

sources de données du SGBD source.
Le langage de définition des données (DDL dans SSAS 2000) est désormais au
format XML. XML/A (XML for Analysis) est le nouveau protocole qui assure la
communication avec le serveur Analysis. Ainsi, de nouvelles sortes d’applications sont
rendues plus faciles à développer et permettent aux postes client d’accéder directement
à des services web sans installation locale.
Les calculs sont centralisés sur le serveur et non plus sur le poste client supprimant
ainsi le cache client et l’amélioration des calculs complexes.
L’environnement de développement d’applications est unifié dans Business Intel-
ligence Development Studio. L’environnement d’administration est SQL Server
Management Studio.
Le modèle d’autorisations d’accès comprend les rôles suivants :
• administrateur de serveur ;
• administrateur de base de données ;
• droits sur les objets de processus et de structure.
Le modèle de sécurisation des objets SSAS définit :

• la sécurisation par objets de la base de données ;
• le cryptage des cubes ;
• SSAS s’exécute avec le niveau le plus fin d’autorisation ;
• les communications entre le client et le serveur sont cryptées assurant un

renforcement de la sécurité face à des techniques comme le sniffing ou le spoofing.
La traçabilité des événements est possible grâce au gestionnaire de profil de SQL

Server. Il existe un journal des audits d’accès aux données et aux applications. Un
journal des erreurs est également disponible.
L’amélioration des performances porte essentiellement sur le mode de restitution
des cellules calculées.
• les calculs effectués sur le serveur sont mis en cache ;
• l’optimiseur de requêtes redéfinit les requêtes clientes dans le but d’améliorer
les performances ;
• les performances sur les réseaux étendus permettent des accès simultanés de
plusieurs centaines d’utilisateurs.
Figure 7.3 — Interface présentant SSMS (SQL Server Management Studio)
SQL Server Management Studio administre aussi bien les bases de données SQL
Server que les bases Analysis. Management Studio permet également d’accéder et
manager le Serveur SSIS et les rôles de Reporting Services.
Les requêtes SQL, MDX DMX, et XML/A sont analysées ou exécutées dans le
même outil.
Le modèle objet AMO (Analysis Management Objects) remplace DSO. Pour des
raisons de compatibilité, DSO est supporté.
Les dimensions et leurs attributs

SSAS 2008 définit une dimension à partir de nombreux attributs, chacun d’entre
eux servant à effectuer du slice (tranche de cube) et du filtrage des données. Chaque
attribut peut participer à la définition de hiérarchies utilisateur selon les relations
entre les données. (exemple : hiérarchie utilisateur Produits Categ prod / Sous-Categ /
Produit
Dans l’exemple suivant considérons la dimension Client. La table qui renferme
la source de données contient huit colonnes : Clé client, nom du client, âge, genre
(masculin/féminin), e-mail, ville, région, pays.
On observe une hiérarchie naturelle telle que (pays, région, ville, nom du client).
Bien que moins naturel, on peut définir un second axe d’observation (âge, genre).
Les avantages liés à cette nouvelle structure de dimensions sont les suivants :
• Il n’est pas nécessaire de charger en mémoire les dimensions. Il en résulte qu’au-
cune limitation de taille n’est imposée pour une dimension donnée (certaines
dimensions peuvent comporter des centaines de millions de membres).
• Les attributs des hiérarchies peuvent être ajoutés ou supprimés sans « re
processer » la dimension. Le cube reste donc disponible aux utilisateurs pendant
la ré indexation de la dimension.
• Les dimensions dupliquées sont éliminées. Les dimensions sont plus compactes.
• La performance du processus de construction des dimensions est améliorée et
exploite naturellement le mécanisme de processus parallèle.
Types de dimensions
Analysis Services 2008 offre les structures de dimensions suivantes :
• Dimension régulière (schéma en étoile).
Une relation de dimension régulière entre une dimension de cube et un groupe de

mesures existe quand la colonne de clé de la dimension est directement jointe avec
la table de faits. Cette relation directe est basée sur une relation clé primaire - clé
étrangère dans la base de données relationnelle sous-jacente, mais elle peut aussi être
basée sur une relation logique définie dans la vue de source de données. Une relation
de dimension régulière représente la relation entre des tables de dimension et une
table de faits dans une conception de schéma en étoile traditionnelle.
• Rôles. Une dimension peut jouer plusieurs rôles en fonction du contexte. Par
exemple la dimension Temps peut être utilisée indifféremment pour la date de
commande et la date de livraison. Dans SSAS 2008, la dimension est stockée une
seule fois mais aura une signification différente en fonction du contexte.
• Dimension de fait. Une dimension de fait, fréquemment appelée aussi dimen-
sion dégénérée, est une dimension standard construite à partir de colonnes
d’attributs de tables de faits, et non de tables de dimension.
• Dimension de référence. Ce type de dimension n’est pas en rapport direct
avec la table de faits. Par exemple une dimension géographie peut aussi bien
s’appliquer à la dimension Client et à la dimension Équipe de vente. Les données

de la dimension sont acquises à partir de tables externes et sont indépendantes
de la table de faits.
Figure 7.4
• Dimension de data mining. Les dimensions de type data mining résultent de

modèles mathématiques tels que les arbres de décision, les règles d’association,
les réseaux de neurones, les clusters, etc. Nous donnerons une liste exhaustive
des différents algorithmes dans le chapitre consacré au data mining.
• Dimension de type plusieurs à plusieurs (figure 7.5). Dans la plupart des
dimensions, chaque fait joint un et un seul membre de dimension, un seul
membre de dimension peut être associé à plusieurs faits. Dans la terminologie des
bases de données relationnelles, on parle de relation un-à-plusieurs. Cependant,
il est fréquemment utile de joindre un seul fait à plusieurs membres de dimension.
Ce type de dimension étend le schéma en étoile dans lequel il est habituel de
constater qu’un champ de la table de faits est en relation avec un et un seul
enregistrement de la table de dimension liée. Dans le type plusieurs à plusieurs,
une dimension est reliée à une première table de faits (dite sans fait) elle-même
reliée à une autre table de faits. Ex l’achat d’un produit sur internet (table de
fait avec indicateur : Internet Sales) peut être conditionné par une ou plusieurs
raisons de l’achat (table de fait sans fait : Internet Sales Reason) elle-même en
liaison avec la dimension des raisons d’achat (Sales Reason).
Lire à ce sujet l’excellent article de Marco Russo :

http://www.sqlbi.eu/Portals/0/Downloads/M2M%20Revolution%201.0.93.pdf
Groupes de mesures et Perspectives

SSAS 2008 introduit la notion de groupe de mesures et de perspectives afin de
simplifier la création et le déploiement de base de données analytiques.
Dans SSAS 2008, le développeur construit un seul cube. Le cube contient un ou
plusieurs groupes de mesures. Un groupe de mesures est attaché à une et une seule
table de faits. Le niveau de granularité de chaque groupe de mesures dépend de son
intersection avec le niveau hiérarchique de chaque dimension.
Figure 7.5 — Représentation d’une relation plusieurs à plusieurs
Figure 7.6 — Utilisation des dimensions dans le cube
La figure 7.6 montre les intersections possibles entre les groupes de mesures (faits)
et dimensions. Lorsque les faits ne partagent pas tous les axes dimensionnels, le
développeur sera avisé de modifier la propriété IgnoreUnrelatedDimension à False dans
les groupes de mesures afin d’éviter la répétition d’informations non pertinentes lors
de l’affichage du cube.
Du fait de la complexité croissante de la navigation dans le cube liée au nombre

potentiellement important de mesures et dimensions, il a été mis en place la technique
des perspectives qui consiste à créer une vue représentant un sous-ensemble de mesures
et dimensions. Les perspectives ne doivent pas être utilisées à des fins de sécurité. Seuls
les rôles définis dans le cube ont vocation à accorder des droits aux utilisateurs.
Il résulte de cette nouvelle organisation de meilleures performances. Des mesures
peuvent renfermer des cellules ayant des valeurs nulles (et non zéro).
Calculs et analyses
Une mesure est dite additive lorsqu’elle s’agrège quel que soit le niveau d’observation
(exemple : le total des ventes pour tous les produits, tous les clients et tous les temps).
Au contraire, une mesure semi-additive peut être additive pour certaines dimensions
et pas pour d’autres. Prenons l’exemple d’un état des stocks d’un entrepôt ; le nombre
d’articles en stock aujourd’hui n’est bien évidemment pas la somme de la situation
constatée hier augmentée de celle d’aujourd’hui. Dans SSAS, on dispose nativement
d’agrégations semi-additives qui permettent de résoudre des problématiques d’inven-
taire telles que :
• La moyenne des quantités et des valeurs en stock sur une période donnée.
• La balance d’ouverture et de clôture sur une période.
• La variation d’inventaire entre des périodes consécutives ou parallèles.
• Le niveau d’inventaire minimum et maximum sur une période donnée.
• La contribution relative d’un article en stock par rapport à la valorisation totale
du stock.
L’assistant de calcul des dimensions temporelles apporte une aide non négligeable
dans le cas de calcul d’agrégation à comparer sur des périodes de temps différentes
(calcul du cumul des ventes depuis le début de l’année comparé sur les trois dernières
années).
Il est possible de générer automatiquement le code MDX permettant d’effectuer
les calculs suivants :
• Cumul annuel/semestriel/trimestriel/mensuel jusqu’à ce jour (year to date).
• Moyennes mobiles sur différentes périodes.
• Croissance et % de croissance entre périodes.
MDX Scripts
Le langage multidimensionnel MDX (Multidimensional Expressions) inventé par Mosha
Pasumanski au sein des équipes de Microsoft en 1997 est un langage d’interrogation
des cubes, aussi complexe que puissant.
Un grand nombre d’éditeurs ont maintenant adopté ce langage. Citons par exemple
ALG Software (acquis par Business Objects), Applix, Descisys, INEA/Cartesis (acquis
par Business Objects), Microstrategy, SAS, SAP.
Citons également quelques produits utilisant ce langage Panorama Software,

Proclarity AppSource, Cognos, Business Objects, Voyager (B.O), Brio Technology,
Crystal Reports, Microsoft Excel, Microsoft Reporting Services.
SSAS 2008 propose un modèle de calcul qui simplifie la construction et la syntaxe
des requêtes.
Des outils tels que les tableaux croisés dynamiques accédant aux cubes utilisent
une technique intuitive de glisser-déposer. Derrière cette apparente simplicité, la
technologie « pivot table » génère des requêtes en langage MDX occultant ainsi la
complexité de la syntaxe.
MDX est aussi le langage naturel utilisé par SSAS pour construire les cubes.
Lorsqu’un cube est traité, les données sont mises à jour seulement au niveau
de détail le plus fin (le niveau feuille). C’est lorsque la demande sera formulée par
l’utilisateur que les niveaux d’agrégation intermédiaires seront calculés « à la volée ».
On imagine le gain d’espace procuré par cette technologie.
Procédures stockées
Analysis Services 2008 dispose de procédures stockées afin d’étendre les capacités
de traitement (UDF). Une procédure stockée peut être écrite dans n’importe quel
langage tel que C++, VB ou C#. Les procédures stockées simplifient le développement
et l’implémentation par la création unique de scripts codés réutilisables par d’autres
procédures stockées ou requêtes des utilisateurs. Les procédures stockées fournissent
des mécanismes afin d’étendre les fonctions de base du langage MDX. Ces procédures
permettent également de réaliser des tâches spécifiques comme le rafraîchissement
d’un cube ou la mise à jour partielle d’une portion du cube.
Indicateurs clés de performance

Un KPI (Key Performance Indicator, ou IPC) permet de suivre des indicateurs métier
pour lesquels des objectifs ont été fournis préalablement. Typiquement, ces indicateurs
se retrouvent dans des rapports, des portails décisionnels et des tableaux de bord.
L’outil de restitution est le portail SharePoint Server. On citera également les outils
Performance Point Monitor et Analytics qui ont pour vocation de mettre en œuvre
les Indicateurs de Performance Clé. Des outils tiers qui exploitent cette technologie
sont disponibles sur le marché (Panorama software, Voyager, etc.). Les KPI sont pris
en charge par les tableaux croisés dynamiques d’Excel à partir de la version 2007.
D’une manière générale, un KPI est composé des éléments suivants :
• la valeur à mesurer (ventes, profit, etc.) ;
• l’objectif de la valeur à atteindre (valeur ou pourcentage) ;
• l’état de la mesure permettant de juger de l’écart par rapport à l’objectif. Une
expression MDX évalue une valeur courante de la mesure dans une plage allant
de – 1 (très mauvais) à + 1 (très bon) ;
• la tendance : valeur précisant si la valeur de la mesure se rapproche de l’objectif
ou s’en éloigne.
Chiffre d’affaires trimestriel Satisfaction client

Le chiffre d’affaire Les clients ont été
trimestriel dépassera extrêmement satisfaits
les prévisions en décembre 2001.
de 12,87 %.
Voir le rapport complet…
Taux d’adoption du marché

Le taux d’adoption
de XYZ a été inférieur
de 17,2 % aux prévisions.
Voir le rapport complet… Voir le rapport complet…
Figure 7.7 — Tableau de bord rassemblant trois KPI
Voici une illustration de trois KPI affichés dans une page web (figure 7.7) :
• KPI du chiffre d’affaires trimestriel (feu vert car le revenu dépasse le but de
12,87 %) ;
• KPI de la satisfaction client (feu vert) ;
• KPI du taux d’adoption du marché (feu rouge car inférieur aux prévisions).
Business Intelligence en temps réel

Les entrepôts de donnée et les applications de Business Intelligence reposent tradition-
nellement sur des données historiques rafraîchies mensuellement, ou quotidiennement.
Il est admis que les applications décisionnelles stratégiques ne nécessitent pas de
fréquence de rafraîchissement inférieure au jour. Nous pensons que la Business
Intelligence doit être omniprésente dans l’entreprise et non seulement réservée à
quelques décideurs tactiques ou stratégiques. On le constate par exemple lorsqu’un
directeur de supermarché souhaite connaître en quasi temps réel les produits qui se
vendent le mieux en fonction des annonces publicitaires diffusées dans le magasin.
Dans ce cas, le temps d’attente entre la réalisation d’un fait et sa mesure est quasi
instantané.
SSAS 2008 fournit un modèle qui offre un temps de latence très réduit entre le
stockage de la donnée dans l’ERP et sa constatation dans le cube.
Le modèle push déclenché par le pipeline DTS permet aux données d’être immédia-
tement transférées dans une partition d’Analysis Service sans stockage intermédiaire.
Le modèle de cache proactif permet de définir très précisément la durée d’attente
avant la prise en compte des nouvelles données. La fréquence des mises à jour des
bases dimensionnelles peut être programmée.
Grâce à ces mécanismes optimisés, il n’est pas rare de constater que les données
rafraîchies et agrégées sont accessibles plus rapidement dans la base OLAP que dans
la base relationnelle source.
Les paramètres ajustables du cache proactif sont :

• La période silencieuse qui définit la durée pendant laquelle la source de donnée
n’a pas reçu de nouvelle transaction avant de lancer le processus de traitement.
Ce paramètre est généralement défini à moins de 10 secondes. Cette période
d’attente protège le système de reconstructions fréquentes du cache dans le
cas où il y aurait de nombreuses transactions de mises à jour sur la source
relationnelle.
• La période de latence : durée qui garantit une période maximale au-delà de
laquelle un rafraîchissement des données s’effectue.
• L’intervalle de latence : il s’agit de la durée maximum entre la notification
de changement et le démarrage du processus de cache proactif. Si la base
de données est rafraîchie constamment, ce paramètre annule le paramètre de
période de silence.
• L’intervalle de reconstruction forcée : ce paramètre est utilisé dans le but de
fournir un simple cache sur des systèmes dont les bases de données source ne
disposent pas des fonctionnalités de notifications de mise à jour.
L’UDM remplace-t-il définitivement la construction du datamart ?

Le modèle UDM permet dans certains cas de s’affranchir de construire le datamart.
En considérant les fonctionnalités citées précédemment, il peut être tentant de passer
directement du système opérationnel (OLTP) au mode multidimensionnel (OLAP)
via UDM.
Système
Opérationnel Cube
UDM Analysis
OLTP
(Oracle, Services
Db2, SQL Server) OLAP
Figure 7.8 — Le processus UDM
Il existe cependant des situations qui ne permettent pas de créer ou mettre à jour
un cube via UDM.
1. UDM nécessite une connexion OLE DB. Si la source de données se trouve
dans un format différent (texte, XML) ou dans un format propriétaire, il sera
nécessaire de passer par le datamart ou au moins une phase de staging (étape
intermédiaire entre l’OLTP et le datamart).
2. UDM nécessite une connexion permanente avec la source des données. En
particulier, si des fichiers doivent être reçus de différentes plates-formes via FTP
ou cédérom avant d’être traités, il sera nécessaire de passer par un datamart.
3. UDM alimente le cube à partir de données propres, ne nécessitant pas de
transformations préalables. Si le système opérationnel contient des erreurs ou
des informations nécessitant d’être nettoyées, il sera indispensable de passer
par la phase d’alimentation du datamart via Integration Services.
Système Data Mart Cube

Intégration UDM
Opérationnel Métier Analysis
Services
OLTP (Oracle, (Oracle, Services
DB2, SQL DB2, SQL OLAP
Server) Server)
Figure 7.9 — Dans la plupart des cas, la création du datamart est la solution la plus judicieuse
7.3 MÉTHODOLOGIE DE CRÉATION D’UNE BASE

DE DONNÉES DEPUIS UNE SOURCE EXISTANTE
La méthode la plus simple consiste à concevoir une base de données Analysis Services
en partant d’une base de données relationnelle quelle qu’en soit la source (ERP, PGI,
ODS, Oracle, DB2, SQL Server, Access, etc.).
D’une manière générale, il est fortement conseillé de créer une base de données
relationnelle servant d’entrepôt de données. En effet, le datawarehouse qui sert
de source à la création des hypercubes joue le rôle d’interface entre les bases
opérationnelles multiples et les cubes. On comprend aisément que cette interface
est nécessaire pour des contraintes de performances, de nettoyage des données source,
et d’historisation de celles-ci. Les bases de données opérationnelles sont volatiles
et pour des raisons de performance sont vidées régulièrement des données les plus
anciennes (données indispensables aux cubes).
Cependant, il peut être astucieux et peu onéreux de commencer à développer une
application décisionnelle en partant directement de la base de données transaction-
nelle (OLTP) sans mettre en œuvre dès le départ un entrepôt de données. C’est le cas
lorsque les données nécessitent peu de transformations, de nettoyage et d’agrégation.
Dans ce cas, SSAS sera vu comme un environnement complémentaire au système de
reporting existant. On gagnera dans ce cas l’avantage de l’interactivité et on fera une
économie non négligeable sur l’ETL.
Sources de données et vues sur les sources de données

Le point de départ pour la création d’une application décisionnelle consiste à créer
un nouveau projet dans l’interface Business Intelligence Development Studio. Une
fois que le squelette du projet est créé par l’assistant, vous pouvez créer vos sources de
données pour vous connecter à n’importe quelle source relationnelle.
Les vues sur les sources de données contiennent des informations sur des tables
constitutives des différentes sources de données. Il est possible non seulement
d’accéder aux tables et leurs champs mais également d’établir des jointures entre les
différentes tables source. Il est parfois judicieux de renommer les tables et les champs
par des appellations plus proches du référentiel métier de l’utilisateur. Parfois, on sera
amené à créer des champs calculés dérivés des champs existants.
7.3 Méthodologie de création d’une base de données depuis une source existante 179
L’avantage de ces vues pour le développeur réside dans le fait qu’elles sont partagées
entre les projets SSAS et SSIS au sein d’un même projet, ce qui est particulièrement
appréciable dans les cas suivants :
• La base de données d’origine comporte des centaines de tables dont seulement
quelques-unes sont utiles au projet BI.
• Les sources de données sont multiples (serveurs distincts, SGBD distincts,
plateformes différentes, fichiers plats, etc.).
• Le développeur BI n’a pas besoin de disposer des privilèges d’administration sur
les sources de données opérationnelles des ERP ou DW.
• Le développeur BI peut procéder au développement d’application en mode
déconnecté (les sources de données ne sont pas nécessaires pour le développe-
ment).
Cette phase de normalisation sera payante tout au long du processus de développe-

ment des applications BI jusqu’à leur restitution.
Création des dimensions des mesures et des cubes

Après que les vues sur les sources de données ont été créées, vous allez procéder à
la création des cubes OLAP. Une batterie d’assistants est disponible afin de créer les
mesures (métriques) et les dimensions du cube (axes d’observation). La technologie
Intellicube examine la base de données et les cardinalités dans les jointures des tables
et, tout naturellement, va déterminer les tables de faits et les tables de dimensions.
L’assistant tente de créer les dimensions sans y inclure les attributs. À la différence de
2005, les hiérarchies ne sont plus traitées avec l’assistant. Malgré cela, il est conseillé
de laisser l’assistant réaliser ce travail préliminaire quitte à revenir ultérieurement sur
des choix qui ne seraient pas conformes à la définition du cahier des charges. Chaque
dimension devra recevoir manuellement les attributs la constituant. Les hiérarchies
utilisateur seront également créées ultérieurement.
Maintenant que les dimensions et les mesures ont été définies avec soin, l’étape
suivante consiste à construire et déployer le cube sur le serveur.
Création et déploiement du cube

Jusqu’ici les étapes précédentes de création de dimension et de définition de cubes
ont généré sur la machine de développement des fichiers intermédiaires au format
XML. Les processus de création et de déploiement vont maintenant fournir toutes ces
données sur le serveur cible. Par défaut, le serveur de développement réside sur votre
machine locale. Il est naturellement possible au moment du déploiement de choisir le
serveur qui hébergera l’application BI.
Après cette étape de création, il convient de contrôler le prototype et en parti-
culier le comportement des mesures au travers des dimensions. Il est préférable de
démarrer avec une base de données disposant de peu d’informations mais suffisamment
significatives afin de détecter rapidement toute anomalie éventuelle. Il existe plusieurs
méthodes de déploiement du cube sur le serveur de production. Un assistant génère
le code XML/A représentant la structure du cube. Ce fichier (lisible, et modifiable)

peut être fourni à l’administrateur qui effectuera une exécution du code sur le serveur
de production en adaptant les connexions. Restera l’étape d’alimentation du cube
(traitement).
À l’issue de la phase de création du cube, des étapes d’amélioration optionnelles
consistent à créer des composants BI tels que les KPI (Key Performance Indicators), les
actions, les calculs dérivés. Selon que les utilisateurs couvrent des métiers différents,
vous créerez des perspectives différentes. Ces perspectives sont en réalité des vues
différentes des données à l’intérieur d’un même cube selon des profils différents. Si
vous déployez des cubes pour une consultation internationale ou multilingue, vous
serez amenés à développer les fonctions de « traduction ». Lors de la création du cube
vous, vous poserez la question de son mode d’alimentation et de la fréquence de son
rafraîchissement. Cela fera intervenir des notions de Partition et de cache proactif.
Une fois que la base Analysis Services a été réalisée, les objets sont déployés pour
des tests d’alimentation et de performance sur le serveur de production.
7.4 CRÉATION DE NOTRE PREMIER CUBE

Afin de réaliser cet exemple, les composants suivants doivent être installés sur le poste
de travail :
• Microsoft SQL Server 2008 Database Engine.
• Microsoft SQL Server 2008 Analysis Services.
• Business Intelligence Studio.
• AdventureWorks DW sample Database (option à sélectionner).
• Vous devez être membre du groupe local administrateurs sur le serveur et disposer
des autorisations en lecture sur la base AdventureWorks DW.
Bien vérifier la sélection des options ci-dessus lors de l’installation de SQL Server
2008.
Le scénario suivant s’inspire d’une société fictive Cycles et Aventure qui fabrique et
distribue des bicyclettes en matériaux métalliques et composites. La société emploie
plusieurs équipes commerciales dans le but de couvrir un marché qui s’étend sur trois
continents : Amérique du Nord, Europe et Asie.
Pour répondre aux besoins en analyse des données des équipes commerciales et
marketing, ainsi que de la direction, l’entreprise récupère actuellement les données
transactionnelles dans la base de données Base_Opérationnelle et les données non
transactionnelles comme les quotas des ventes dans des feuilles de calcul, et consolide
ces données dans l’entrepôt de données relationnelles Base_Entrepot. Cependant,
l’entrepôt de données relationnelles présente les problèmes suivants.
7.4.1 Constat
Actuellement, les rapports prédéfinis fournis par le système opérationnel sont statiques.
Lorsque les utilisateurs désirent établir des tableaux de synthèse, ils doivent ressaisir les
7.4 Création de notre premier cube 181
données dans le tableur Excel. Ils peuvent ensuite élaborer des graphes. Les données
de synthèse saisies manuellement dans Excel ne permettent pas d’explorer des niveaux
de détail plus fins. Dans ce contexte, il n’existe pas de lien permettant de retrouver les
données détaillées qui constituent les données de synthèse.
Les utilisateurs n’ayant pas connaissance des technologies OLAP se contentent
bien souvent des rapports qu’ils impriment selon leurs besoins. Parmi ces utilisateurs,
certains souhaiteraient accéder directement aux données de la base opérationnelle.
Ils disposent parfois d’outils de requêtage. Cependant, du fait de la complexité du
schéma de la base, ils renoncent à élaborer eux-mêmes les rapports dont ils ont besoin
et finissent par solliciter les services informatiques.
Dans les environnements où l’entrepôt de données n’a pas été mis en place, les
utilisateurs constatent avec stupeur que les données des années antérieures ne sont
plus accessibles. Les processus de « nettoyage » visant à améliorer les performances du
système transactionnel ont eu raison de l’historique des données.
Les temps de réponse sont aléatoires (plusieurs minutes voire plusieurs heures
lorsque les volumétries sont importantes).
La solution passe naturellement par l’entrepôt de données visant à organiser les
données en tables dimensionnelles et la technologie OLAP dont un des objectifs est
de permettre des analyses croisées dynamiques.
Dans l’exemple qui suit, nous allons montrer comment la technologie UDM va
nous permettre d’élaborer rapidement un cube OLAP.
Un peu de méthode avant de commencer. La création d’un cube passe par quatre
étapes indispensables.
Étape 1 : Définir le processus à analyser

Cette première étape est souvent attachée à un besoin « métier ». Ce besoin est
généralement exprimé par un manager opérationnel de l’organisation sous forme
d’interrogation : quelles sont les ventes réalisées sur Internet comparées sur les trois
dernières années par régions et par lignes de produit ?
Étape 2 : Déterminer le niveau de granularité des données

Les données proviennent des tables de faits pour les métriques et des tables de
dimension pour les axes d’observation. La granularité représente le niveau de détail
auquel le manager souhaite parvenir. Bien souvent, les analyses se font sur des
données agrégées apportant ainsi une vision globale de l’activité, mais il est également
nécessaire de connaître les données détaillées qui composent la donnée synthétique.
Le niveau de granularité le plus fin est conditionné par la ligne de détail stockée
dans la table de faits. Ainsi, pour une analyse des ventes réalisées sur Internet, il sera
nécessaire d’identifier la table de faits susceptible de renfermer cette donnée. Une
table candidate est naturellement la table VentesInternet. Le niveau de granularité le
plus bas sera donc représenté par la ligne de facture des ventes internet. En général,
cette ligne de facture représente un niveau de détail suffisamment fin pour connaître
l’article vendu, par qui et quand, puis de connaître la quantité vendue et le montant.
Ralph Kimball et Margy Gross recommandent que la table de faits stocke la donnée à
un niveau « atomique » c’est-à-dire au niveau le plus fin. Cependant, si vous décidez
d’agréger les données dans la table de faits de l’entrepôt de données et que vous désirez
accéder au niveau de détail le plus fin, vous devrez envisager que UDM puisse accéder
à la source représentée par la base transactionnelle OLTP.
Étape 3 : Choisir les dimensions

L’analyse sémantique de la question posée par notre manager permet de déterminer
assez facilement les tables dimensionnelles devant intervenir dans l’élaboration du
cube. En effet, lorsque le responsable demande une analyse par Régions et par ligne
de produit, il identifie clairement les axes d’observation, donc les dimensions du cube
OLAP. La région étant déterminée par le client, la table dimensionnelle Clients sera
introduite par l’UDM dans le référentiel. La notion de ligne de produit et produit est
déterminée par deux champs de la table Produit. Nous devrons donc intégrer la table
dimensionnelle Produit.
Notre manager précise également qu’il désire effectuer la même analyse sur les
trois dernières années. Cette requête implique par conséquent une notion temporelle.
Il sera donc nécessaire d’introduire la dimension Temps. Il est à noter que cette table
Temps n’existe nullement dans la base opérationnelle. Elle est un artifice introduit
uniquement dans la base entrepôt de données. Son but est de partager plusieurs
datamarts selon le même axe temporel. La table Temps est jointe à la table de faits
centrale grâce à une clé temporelle ajoutée à la table de faits et alimentée au moment
de la phase d’ETL (fonction lookup).
Le niveau de granularité du cube sera déterminé par le niveau hiérarchique le plus
bas de chacune des dimensions qui composent le cube.
Étape 4 : Identifier les métriques

La dernière étape consiste à identifier les données numériques qui répondent à la
question de notre manager.
7.4.2 Mesures
Dans l’exemple présenté ci-après, les mesures sont définies par la table VentesInternet
et sont les suivantes :
• quantité commandée ;
• prix unitaire ;
• quantité étendue ;
• remise unitaire ;
• montant de la remise ;
• coût standard du produit ;
• coût total du produit ;
• montant des ventes ;
• montant de la taxe.
7.4.3 Dimensions
Notre manager veut effectuer des analyses selon divers axes d’observation.
• Axe Géographie
– région ;
– province ;
– ville ;
– nom.
• Axe Produits
– catégorie de produit ;
– sous-catégorie ;
– ligne produit ;
– produit.
• Axe Temps
– année ;
– trimestre ;
– mois.
– jour.
7.4.4 Le schéma en flocons

Les datamarts sont constitués d’une table de faits centrale autour de laquelle gravitent
des tables de dimensions. Selon que l’axe dimensionnel est composé d’une seule table
ou de plusieurs, le schéma sera appelé en étoile ou en flocon.
Dans l’exemple ci-dessous, la table de fait centrale est la table FaitVentesInternet.
La dimension Client est composée de deux tables liées (DimClients et DimGeogra-
phie). De ce fait nous parlerons d’un schéma en flocons.
Figure 7.10 — Schéma en flocon composé d’une table de faits et de trois axes dimensionnels
La dimension Produits est constituée à partir de trois tables liées DimProduit,

DimSousCatégorieProduit et DimCatégorieProduit).
Dans la figure ci-dessus, l’axe Produits est lui-même composé de trois tables. On
parle donc d’un schéma en flocons.
7.4.5 Créer le projet « Mon Premier Cube » à l’aide de l’environnement

UDM d’Analysis Services
Un projet Analysis Services se décompose en deux phases. La première consiste à
définir l’environnement des sources qui alimentent le cube. La seconde permet de
créer le cube en introduisant la notion de mesures et dimensions.
Définir l’environnement des sources de données

Sélectionner Démarrer, cliquer sur Microsoft SQL Server 2008 ensuite cliquez sur
SQL Server Business Intelligence Development Studio.
L’environnement Business Intelligence de Visual Studio s’ouvre : Nouveau projet.
Dans la fenêtre Project types sélectionner Business Intelligence Projects.
Dans la fenêtre Visual studio Modèles Visual Studio effectuez un double-clic sur :
Projet Analysis Services.
Figure 7.11 — Formulaire de création d’un projet SSAS
Dans le champ Nom, nommer le projet : MonPremierCube.

Dans le champ Emplacement, définir un chemin d’accès aux projets ou conserver
celui proposé par VS. Dans le champ Solution, saisir Créer une nouvelle solution.
Figure 7.12 — Composants créés en standard lors de la création d’un projet SSAS
Créer la source de données :

• Clic droit sur Source de données.
• Assistant Source de données.
• Cliquer sur Suivant.
• Sélectionner la méthode de définition de la connexion.
• Cliquer sur le bouton Nouveau.
Dans la liste proposée choisissez SQL Server Native Client 10.0.
Figure 7.13 — Choix des types de connexion
Choisir le fournisseur d’accès à la base AdventureWorksDW.
Figure 7.14 — Le gestionnaire de connexion permettant d’accéder à la base AdventureWorksDW
Le bouton Tester la connexion permet de vérifier la connexion au serveur. Puis

OK.
L’assistant montre les paramètres de la connexion de données. Puis dans l’écran
suivant, sélectionnez le choix Utiliser le compte de service.
Figure 7.15 — Information sur l’identité de l’utilisateur accédant à la source de données
Figure 7.16 — Chaîne de connexion fournie par l’assistant
Puis cliquez sur Terminer. Dans l’explorateur de solutions, nous constatons la

présence de la nouvelle source de données : Adventure Works DW.ds.
Figure 7.17 — La source de données dans l’explorateur de solutions
L’étape suivante consiste à créer une nouvelle vue de source de données.

La vue des sources de données a pour but de :
• Spécifier la source de données sous-jacente (.ds) ;
• Définir des conventions d’affectation de noms pour identifier les relations ;
• Sélectionner des tables et des vues pour la vue de source de données ;

• Attribuer un nom à la vue de source de données afin d’être utilisée ultérieure-
ment dans la création d’un ou plusieurs cubes.
La Vue des sources de données comporte une clé primaire par table ou vue. Cette
clé est très importante et doit être définie avec soin car elle détermine l’unicité des
membres de dimensions ainsi que les jointures entre dimension et table de faits.
Clic droit sur Vues de sources de données.
Figure 7.18 — Création d’une nouvelle vue de source de données
Validez Nouvelle vue de source de données... L’assistant de source de données

démarre. Bouton Suivant.
Figure 7.19 — Formulaire de sélection des tables qui entrent dans le référentiel
du modèle en étoile ou en flocon
Sélectionnez la source de données qui vient d’être créée Adventure Works DW.
Bouton Suivant. Dans le formulaire suivant vous allez sélectionner les tables de
AdventureWorksDW qui sont à inclure dans la vue de source de données.
Grâce au bouton > sélectionnez la table de faits FactInternetSales. Cliquez sur le
bouton Suivant. Puis validez la fin de la création de source de données en cliquant sur
le bouton Terminer.
Dans l’explorateur de solution vous observez la création de la vue Adventure
Works DW.dsv. Vous obtenez le schéma suivant (figure 7.20).
Figure 7.20 — Source de données selon un schéma en flocon (représentation en mode diagonale)
À ce stade il est possible d’ajouter une ou plusieurs tables à la vue des sources de
données. Il est cependant utile de noter que si vous effectuez vous-mêmes des jointures
entre des tables celles-ci ne sont pas vérifiées dans le concepteur. Si des jointures
s’avèrent erronées, vous n’en aurez connaissance qu’au moment du traitement du
cube.
Vous pouvez également créer des requêtes nommées visant par exemple à filtrer
des données. Ces requêtes nommées sont en quelque sorte des vues et peuvent être
traitées comme de nouvelles tables physiques. Pour ces vues nommées vous devrez
créer une clé primaire logique. Aussi soyez attentif à la compréhension du modèle
relationnel sous-jacent avant de créer des jointures et/ou des clés primaires sur des
vues ou requêtes nommées.
Au fur et à mesure que les besoins évoluent, vous pouvez remplacer la table
nommée par une table physique ou une autre table nommée.
Créer le cube à l’aide de l’assistant

La phase de création du cube permet de déterminer les dimensions et les mesures
qui participent à son élaboration. À ce stade il est très important que le schéma de
modélisation de la base de données soit préalablement validé selon les règles déjà
évoquées dans les chapitres précédents (Kimball). L’assistant de création de cube ne
valide en aucun cas le schéma relationnel sous-jacent.
Dans l’explorateur de solutions, effectuez un clic droit sur Cubes puis validez
Nouveau Cube...
Figure 7.21 — Création d’un cube à l’aide de l’assistant UDM
L’assistant de création de cube est sollicité. Puis cliquez sur le bouton Suivant.
Sélectionnez la méthode de création
Figure 7.22
L’assistant fournit trois options pour la création du cube :

• Utiliser des tables existantes. Cas le plus fréquent, car le cube s’appuie sur un
schéma relationnel sous-jacent (généralement le datawarehouse).
• Créer un cube vide. Cette option crée un cube vide et ne génère aucune
dimension. En conséquence vous devrez créer le modèle dimensionnel « from
scratch ».
• Générer des tables dans la source de données. Cette option est utile lorsque
vous désirez créer un cube (UDM) en l’absence de base relationnelle sous-
jacente. Avec cette option il est donc possible de générer une base relationnelle
déduite de la structure du cube. Il existe des modèles de schéma prédéfinis. Vous
pouvez ajouter vos propres modèles de cubes. Les tables pourront être remplies
automatiquement.
Cette méthode est retenue lorsque vous désirez créer une table dimensionnelle
temporelle dans un entrepôt de données. Il suffit de préciser les attributs et dates
extrêmes du calendrier pour créer et alimenter une telle table.
L’assistant vous invite à définir la ou les tables de faits. Cliquez sur le bouton
Suggérer afin d’obtenir une détection automatique.
Figure 7.23 — Le bouton Suggérer permet de sélectionner automatiquement la table de Faits
Cliquez sur le bouton Suivant puis sélectionnez les mesures à inclure dans le groupe
de mesures. Les clés (données numériques) servant aux jointures doivent être exclues
des mesures. Observez la création d’une mesure créée par l’assistant. Il s’agit de Fact
Internet Sales Nombre. Cet indicateur (représente une fonction Count) permettra
par la suite de dénombrer les lignes qui répondent à tel ou tel critère ex : Compter
combien de clients ont commandé dans l’année 2009.
Figure 7.24 — Sélectionnez les mesures à inclure dans le cube

Puis cliquez sur Suivant.
Figure 7.25 — Sélectionner les dimensions (décochez la table de faits Fact Internet Sales.
Une table de faits peut également être considérée comme une dimension dégénérée)
Cliquez sur Suivant.
Figure 7.26
Cliquez sur Terminer.

Figure 7.27 — Le concepteur de cube présente l’explorateur de solutions, la source de données,

la vue des sources de données, les trois dimensions partagées, le groupe de mesures basé
sur la table de faits, les cinq dimensions incluses dans le cube
L’assistant de BIDS 2008 est différent de 2005 puisqu’à ce stade, BIDS 2005 avait
créé des attributs de dimensions et hiérarchies utilisateurs. L’assistant de BIDS 2008
doit être complété par des manipulations de la part du concepteur.
Il est donc nécessaire d’ajouter manuellement des attributs aux dimensions Dim
Product, Dim Time et Dim Customer.
Pour ajouter des attributs à la dimension Customer :
• Ouvrez le Concepteur de dimensions pour la dimension Customer. Pour cela,
double-cliquez sur la dimension Customer du nœud Dimensions de l’Explorateur
de solutions.
• Dans le volet Attributs, remarquez les attributs Customer Key et Geography
Key créés par l’Assistant Cube.
Figure 7.28 — Vous devez sélectionner manuellement les attributs de dimensions

qui seront intégrés au cube
• Dans la barre d’outils de l’onglet Structure de dimension, utilisez l’icône Zoom

pour afficher les tables du volet Vue de source de données avec un zoom de
100 %.
• Faites glisser les colonnes suivantes de la table Customer du volet Vue de source
de données vers le volet Attributs : Vous pouvez sélectionner plusieurs champs
simultanément et les déplacer en une seule opération.
– BirthDate
– MaritalStatus
– Gender
– EmailAddress
– YearlyIncome
– TotalChildren
– NumberChildrenAtHome
– EnglishEducation
– EnglishOccupation
– HouseOwnerFlag
– NumberCarsOwned
– Phone
– DateFirstPurchase
– CommuteDistance
• Faites glisser les colonnes suivantes de la table Geography du volet Vue de
source de données vers le volet Attributs :
– City
– StateProvinceName
– EnglishCountryRegionName
– FrenchCountryRegionName
– PostalCode
Figure 7.29 — L’onglet Structure de dimension permet de vérifier la sélection des attributs
• Dans le menu Fichier, cliquez sur Enregistrer tout.
Une nouvelle fonctionnalité apparue avec SSAS 2008 consiste à afficher des règles
de suggestion. Si le concepteur détecte des conflits dans les dimensions il souligne
l’objet avec une ligne ondulée bleue. Lorsque vous pointez la souris sur la ligne bleue,
une description de la règle apparaît dans une info-bulle. Il est possible de désactiver la
liste des règles en cliquant droit sur le projet Analysis services puis Modifier la base de
données.
Figure 7.30 — Onglet présentant les cinq types d’avertissement
Vous pouvez déplier une ou plusieurs descriptions de règles puis désactiver une ou
plusieurs options.
Figure 7.31 — Vous pouvez choisir les Règles d’avertissement de conception
La figure 7.31 montre un extrait des règles de conception.

Définition des Hiérarchies utilisateur et des relations d’attributs dans les dimen-
sions.
Dans l’UDM, une dimension est un container logique composé d’attributs. Les
attributs représentent les caractéristiques de la dimension (ville, région, code postal...).
Les attributs sont reliés entre eux grâce à des relations d’attributs. Toute dimension
comporte une clé primaire. Par défaut tous les attributs de la dimension sont reliés
à la clé primaire. À la différence d’une base de données relationnelle qui stocke les
données dans une structure à deux dimensions (lignes/colonnes), l’UDM offre une
représentation multidimensionnelle qui supporte les hiérarchies telles que Catégorie
de produit/Sous-catégorie de produit/Produit. De plus, des relations existent entre ces
niveaux hiérarchiques.
Les attributs d’une dimension sont directement ou indirectement reliés à la clé de
dimension selon des relations logiques (cardinalités) de type un à un ou Plusieurs à un.
Par exemple la dimension Produits évoquée ci-dessus implique que chaque produit fait
l’objet d’une description unique ; il s’agit d’une relation 1 :1. En revanche la couleur
du produit fait apparaître une relation de type Plusieurs : 1 parce que plusieurs produits
peuvent avoir la même couleur. De la même manière la sous-catégorie de produit fait
état d’une relation de type Plusieurs à un avec la catégorie de produit.
D’une manière générale, l’UDM n’a pas connaissance des relations entre les
attributs. Par défaut, il définit des relations de type Plusieurs à 1 entre tous les attributs
de la dimension et la clé de la dimension.
Les relations d’attributs ont pour but de :
• Optimiser le stockage des hiérarchies.
• Retrouver rapidement les données agrégées.
Vous pourrez approfondir ce sujet en consultant l’article « Microsoft SQL Server

2008 Analysis Services Performance Guide ». Vous trouverez le lien sur le site de
l’auteur.
Une nouvelle hiérarchie se crée par un simple glisser-déposer depuis le volet

Attributs vers le volet hiérarchie. Nous créons la hiérarchie sur l’axe région en
précisant les niveaux State Province Name puis French Country Region Name et
enfin City. Voici l’onglet Structure de dimension.
Figure 7.32 — Onglet Structure de dimension faisant apparaître les attributs de la dimension
et la hiérarchie utilisateur sur l’axe Région
La version 2008 de BIDS fait apparaître un nouvel onglet « Relations d’attributs »

dans les propriétés de la dimension.
Figure 7.33 — Nouvel onglet Relations d’attributs
La figure ci-dessus montre les trois volets. Le volet attributs en bas à gauche, le
volet des relations d’attribut avec la clé Customer Key, puis le volet concernant la
hiérarchie et les relations de la clé principale avec chaque niveau.
Les propriétés de chaque relation d’attribut précisent en particulier la cardinalité

(Un ou Plusieurs) et le type de relation (Flexible ou rigide). Un client peut changer
de code postal (la relation sera flexible). Un trimestre appartient à un semestre donné
et ne peut faire l’objet de modification (la relation sera rigide).
Dans l’exemple ci-dessus on observe à proximité du titre de la hiérarchie une icône
représentant un panneau avec un point d’exclamation. Le survol de ce panneau avec
la souris permet d’afficher le message suivant :
Les relations d’attributs n’existent pas sur un ou plusieurs niveaux de cette
hiérarchie. Il peut s’ensuivre une diminution des performances de la requête. Ce
message nous incite à établir des relations directes entre chaque niveau de la hiérarchie
afin d’optimiser la navigation.
Figure 7.34
Modifions donc les relations.
Figure 7.35 — Nouvelle relation d’attributs entre les différents niveaux de la hiérarchie
Figure 7.36 — Volet Structure de dimension
On observe que l’avertisseur a disparu. À l’exécution du traitement de la dimension

un échec apparaît.
Figure 7.37 — Un message apparaît à l’issue du traitement
Si BIDS Helper est installé (voir ressources en fin d’ouvrage) vous pourrez
connaître les raisons de cet échec en effectuant le contrôle de la dimension Dim
Customer.
Figure 7.38 — Menu complémentaire fourni par BIDS Helper
Voici le résultat de la vérification fourni par BIDS Helper.
Figure 7.39 — Résultat du contrôle effectué par BIDS Helper
On observe que la même ville peut être trouvée dans plusieurs régions occasionnant
des doublons (ex. Berlin dans Hamburg, Hessen Brandburg...) Nous devons donc lever
l’ambiguïté en attribuant à chaque ville une clé composite constituée de la ville et du

nom de la province associée.
Figure 7.40 — Formulaire permettant d’associer plusieurs clés pour l’attribut City
Figure 7.41 — Propriétés de l’attribut City après création de la clé composite
Dorénavant, le traitement de la dimension s’exécutera avec succès.

Figure 7.42 — La navigation dans la hiérarchie utilisateur est maintenant optimisée
Déployer les bases de données SSAS sur le serveur de production

Il existe plusieurs méthodes pour déployer des bases de données SSAS sur un serveur
de production.
Tableau 7.1 — Rappel des différentes méthodes de déploiement et recommandations
Méthode de déploiement Recommandations

BIDS (clic droit sur projet, puis déployer) Déploie les dernières modifications sur votre
serveur local
Assistant de déploiement (menu windows Permet de déployer les cubes vers un serveur
Analysis services, puis Deployment wizard) de test ou de production avec un niveau fin
de paramétrage
Script XMLA Permet de planifier une tâche de déploiement
Assistant de synchronisation de Bases Synchronise deux cubes, (Cube intermédiaire à
de données OLAP Cube de production)
Backup et Restore Copie une base OLAP d’un serveur vers un
autre. Les données sont également transférées.
Analysis Management Objects (AMO) Déploiement par programmation.
Déploiement avec BIDS

Cette méthode est utilisée lorsque :
• Vous travaillez en mode projet BIDS.
• Vous voulez tester vos modifications pendant le cycle de vie du projet.
• Vous souhaitez déployer votre cube SSAS sur un serveur de test ou de produc-
tion.
Deux options de déploiement peuvent être utilisées :

• Le mode connecté : Dans ce mode vous êtes directement connecté sur la base
de données SSAS située sur le serveur Analysis services. Les modifications de
structure apportées sont immédiatement répercutées sur le serveur. Ce mode est
accédé dans BIDS grâce à la commande Ouvrir/Base de données Analysis.
• Le mode projet : Ce mode est celui utilisé par défaut dans BIDS et s’appuie
sur des fichiers XML générés lors de la génération du projet SSAS L’avantage
de cette méthode est le partage du développement de projet par une équipe de
développeurs. En mode projet vous êtes déconnecté du serveur. Pour tester vos
modifications vous devez procéder au déploiement sur un serveur SSAS (local
ou test).
Paramétrage du déploiement
Vous pouvez modifier les paramètres de déploiement en cliquant droit sur le nœud du
projet dans BIDS.
Figure 7.43 — Page de propriétés de déploiement du cube

Les options de déploiement sont les suivantes :
Tableau 7.2
Choix de l’option Paramètres Commentaire
Serveur Précise le nom du serveur susceptible de revoir le
déploiement. Nom du serveur suivi de l’instance
SSAS.
Base de données Précise le nom de la base de données OLAP cible.
Option de traitement Par défaut Permet de déployer tout en maintenant le cube
en état de fonctionnement.
Complet Traitement complet de la base OLAP
Ne pas traiter Déploie les changements uniquement
Déploiement False Exécute chaque commande de déploiement
transactionnel de manière indépendante
True Remet la base OLAP à l’état initial s’il y a échec
(Rollback)
Mode de déploiement Déployer tout Écrase la cible
Déployer Compare avec la cible et déploie uniquement
uniquement ce qui a changé
ce qui a changé
Serveur Précise le nom du serveur susceptible de revoir
le déploiement
Base de données Précise le nom de la base de données OLAP cible.
Lorsque vous déployez un projet SSAS, BIDS met à jour un fichier au format xml
qui porte le nom <nomdu projet>.asdatabase dans le répertoire \bin du projet
ATTENTION : Bien que le mode de déploiement permette de déployer unique-
ment ce qui a changé, la fonction de déploiement de BIDS écrase les paramètres de
gestion de la base OLAP tels que le partitionnement et les rôles. Pour un meilleur
contrôle du déploiement, utilisez plutôt l’assistant de déploiement.
Assistant de déploiement
L’assistant de déploiement est conçu pour vous donner un contrôle plus fin et
incrémental. Lorsque vous créez un projet SSAS à l’aide de BIDS celui-ci génère
un script de déploiement (asdatbase) et plusieurs fichiers xml.
Tableau 7.3 — Fichiers générés lors du déploiement du projet
Fichiers dans le sous-répertoire \bin du projet Description

<NomDuProjet>.asdatabase Fichier de script au format XMLA
<NomDuProjet>.configSettings Définit les sources de données
et les connexions
<NomDuProjet>.deploymentOptions Contient les options de déploiement tels
que l’écrasement des partitions
et les paramétrages des rôles
<NomDuProjet>.deploymentTarget Contient les noms des serveurs et base
de données de déploiement
À ce stade, deux modes de déploiement peuvent être envisagés :

• Mode interactif (l’assistant lit les fichiers de configuration ci-dessus puis vous
permet de les modifier de manière interactive lors de la procédure de déploie-
ment. Il en résulte un fichier au format XMLA que vous pouvez sauvegarder
pour une exécution ultérieure ou immédiate.
• Mode de commande permet une exécution différée ou planifiée. Vous pouvez
obtenir les paramètres de cette commande en exécutant la commande suivante :
microsoft.analysisservices.deployment.exe /?
Voici la syntaxe de la commande :
Microsoft.AnalysisServices.Deployment [ASdatabasefile]
{[/s[:logfile]] | [/a] | [[/o[:output_script_file]] [/d]]}
Arguments :
• ASdatabasefile – Chemin complet du dossier dans lequel le fichier de script de
déploiement Analysis Services (.asdatabase) se trouve. Le fichier de script de
déploiement contient les définitions d’objets à déployer. En l’absence de toute
spécification, le dossier en cours est utilisé.
• /s – Exécute l’utilitaire en mode silencieux et n’affiche pas de boîte de dialogue.
• logfile – Chemin d’accès complet et nom de fichier du fichier journal. Les
événements de trace sont consignés dans le fichier journal spécifié. Si le fichier
journal existe déjà, le contenu du fichier est remplacé.
• /a – Exécute l’utilitaire en mode réponse. Toutes les réponses effectuées pendant
la partie Assistant de l’utilitaire sont réécrites dans les fichiers d’entrée, mais
aucune modification n’est apportée aux cibles de déploiement.
• /o – Exécute l’utilitaire en mode de sortie. Aucun déploiement n’est effectué,
mais le script XML for Analysis (XMLA) qui serait normalement envoyé
aux cibles de déploiement est plutôt enregistré dans le fichier de script de
sortie spécifié. Si output_script_file n’est pas spécifié, l’utilitaire tente d’utiliser
le fichier de script de sortie spécifié dans le fichier d’entrée des options de
déploiement (.deploymentoptions). Si un fichier de script de sortie n’est pas
spécifié dans le fichier d’entrée des options de déploiement, une erreur se
produit.
• output_script_file – Chemin d’accès complet et nom de fichier du fichier de script
de sortie.
• /d – Si l’argument /o est utilisé, il spécifie que l’utilitaire ne doit pas se connecter
à l’instance cible. Aucune connexion n’étant établie aux cibles de déploiement,
le script de sortie est généré uniquement sur la base des informations récupérées
à partir des fichiers d’entrée.
Utilisation de l’assistant de déploiement
Démarrer / SQL Server 2008 / Analysis Services / Deployment wizard

Spécifiez des options pour les partitions et les rôles.

Précisez si vous désirez conserver ou non les partitions existantes et/ou conserver
les rôles et les membres. Cette option est très utile lorsque les cubes sont en fonction
et que vous désirez modifier quelques éléments mineurs (ajout d’attribut, mesures ou
dimensions) sans toucher à l’organisation existante.
Vous pouvez ensuite préciser le choix des paramètres de configuration, d’optimisa-
tion et d’identité, de stockage des fichiers journaux d’erreur.
Figure 7.44 — Vous devez définir les propriétés de configuration
Créez ensuite un script de déploiement.
Figure 7.45
Si vous exécutez le fichier script XMLA par un double clic, Management studio
s’ouvre automatiquement en présentant le code XMLA. Voici en mode réduit le script
généré.
Figure 7.46
Le code XMLA est modifiable puis exécutable (clic droit dans le code puis
exécuter).
Assistant de Synchronisation
Si vous disposez d’une ferme de serveurs de production et vous désirez déployer les
dernières modifications sur chaque serveur. Vous allez éviter de processer chaque
serveur pour des raisons de durée de traitement. Vous déciderez donc de processer
les cubes sur des serveurs de type staging (intermédiaires) et ensuite de synchroniser
chaque cube de production avec chaque cube de staging.
L’assistant de synchronisation est obtenu dans Management Studio par un clic
droit sur le nœud Base de données puis synchroniser...
Les serveurs source de synchronisation et destination ne peuvent être identiques.
Configurez le serveur destination de telle sorte qu’il s’exécute avec un compte de
domaine ayant les droits administrateur.
Effectuer un backup de la base OLAP
Figure 7.47 — Formulaire de sauvegarde de cube

L’extension d’un fichier de sauvegarde OLAP est .abf (Analysis Backup File).
Vous pouvez récupérer le script XMLA d’une procédure de sauvegarde de cube en
activant l’icône Script.
Figure 7.48 — Le bouton Script permet de récupérer le script XML/A généré

pour le backup de cube
Voici le code généré par l’assistant Script :
<Backup xmlns="http://schemas.microsoft.com/analysisservices/2003/engine">
<Object>
<DatabaseID>MonPremierCube</DatabaseID>
</Object>
<File>MonPremierCube.abf</File>
<AllowOverwrite>true</AllowOverwrite>
</Backup>
Il est naturellement possible de récupérer ce code et l’exécuter dans une tâche

DDL de Integration Services ou de l’agent SQL afin d’effectuer régulièrement des
backup de cubes. Toutes ces tâches acceptent d’exécuter du code XMLA (traitement
de cube, Backup etc.).
Figure 7.49 — Planification de tâche à l’aide de l’Agent SQL Server
Ci-dessus l’agent SQL exécute une commande XMLA. Vérifiez le type d’exécution
« commande SQL Server Analysis Services ».
Structure de cube
Cet onglet permet de modifier l’architecture d’un cube et d’en modifier les composants.
Utilisation de la dimension
Cet onglet permet de définir les relations entre des dimensions et des groupes de
mesures, ainsi que la granularité de chaque dimension au sein de chaque groupe
de mesures. Si vous utilisez plusieurs tables de faits, il se peut que vous deviez
identifier si les mesures s’appliquant ou non à une ou plusieurs dimensions. Chaque
cellule représente une relation potentielle entre le groupe de mesures et la dimension
intersectée.
Calculs
Cet onglet permet d’étudier les calculs définis pour le cube, de définir de nouveaux
calculs pour le cube dans sa totalité ou pour un sous-cube, de réorganiser les calculs
existants et de déboguer les calculs, pas à pas, en s’aidant des points d’arrêt. Les calculs
permettent de définir de nouveaux membres et mesures basés sur des valeurs existantes,
tels que des calculs de profit, et de définir des jeux nommés.
KPI
Cet onglet permet de créer, éditer et modifier les indicateurs de performance clés
(KPI) dans un cube. Ceux-ci permettent au concepteur de déterminer rapidement les
informations utiles relatives à une valeur et par exemple, de déterminer si la valeur
définie est supérieure ou inférieure à un objectif ou si la tendance que suit la valeur
définie augmente ou diminue.
Actions
Cet onglet permet de créer ou de modifier des extractions, des rapports et d’autres
actions pour le cube sélectionné. Il contient des informations contextuelles sur les
applications clientes, les commandes et les rapports auxquels les utilisateurs finaux
peuvent accéder.
Partitions
Les partitions permettent de stocker les sections d’un cube dans différents emplace-
ments avec des propriétés différentes, telles que des définitions d’agrégations.
Perspectives
Une perspective est un sous-ensemble défini d’un cube et sert à réduire la complexité
d’un cube du point de vue de l’utilisateur.
Traductions
Cet onglet permet de créer et gérer les noms traduits des objets de cube, tels que les
noms de mois ou de produits.
Navigateur
Cet onglet permet d’afficher les données du cube selon une présentation proche du
tableau croisé dynamique.
L’explorateur de solutions présente les nouvelles dimensions (figure 7.50).
Figure 7.50 — L’explorateur de solution présente trois dimensions partagées alors que le cube
lui-même en contient cinq (la dimension temps est triplée dans le cube car il existe trois dates
différentes liées à la table temps)
Dans le menu de Visual studio sélectionnez Fichiers puis cliquez sur Enregistrer
tout.
Modification des mesures et dimensions créées par défaut

Sélectionnez l’onglet Structure du cube puis dépliez les mesures de Fait Ventes
Internet.
Le volet Dimensions de l’onglet Structure de cube affiche les dimensions qui
ont été créées à l’étape précédente. Les dimensions Produit et Clients apparaissent
clairement. En revanche, la table de dimension Dim Temps a généré trois dimensions
de cube temporelles. Ces dimensions temporelles correspondent aux champs de type
date observés dans la table de faits : date de livraison, date de commande et date
expédition.
Dans le volet Dimensions, développez Dim Clients, puis cliquez sur le lien Modifier
Dim Clients.
Figure 7.51 — Groupe de mesures et dimensions du cube
Le concepteur de dimension apparaît. Vous observez trois onglets : Structure de

dimension, Traductions et Navigateur.
L’onglet Concepteur de dimension contient à son tour trois onglets : Attributs,
Hiérarchies et niveaux et vue source de données.
Les choix effectués par l’assistant ne nous conviennent pas. Par conséquent, vous
allez procéder à la modification de la hiérarchie de la dimension.
Figure 7.52 — L’onglet structure de dimension se décompose en Attributs, Hiérarchies

et vue source de données propre à la dimension
Commencez par renommer la hiérarchie en Clients.

Clic droit sur l’en-tête de la hiérarchie, puis Renommer, puis saisissez Clients.
Figure 7.53 — Supprimer ou renommer un niveau dans la hiérarchie
Vous allez reconstruire les niveaux hiérarchiques de la dimension clients.

Vous allez supprimer les niveaux actuels par un clic droit sur chaque niveau puis
Supprimer.
Grâce à la fonction glisser déplacer, vous reconstituez la hiérarchie de la dimension
Clients.
Dans l’ordre, glissez tout d’abord Nom Région Français puis immédiatement en
dessous Nom Province puis Ville et enfin Nom.
Figure 7.54 — Grâce à un glisser-déplacer depuis la source de données vers la hiérarchie,

il est possible de construire une ou plusieurs hiérarchies de dimension
Vous obtenez ainsi la nouvelle hiérarchie Clients.

Vous allez effectuer le traitement de réorganisation sur la dimension Produit.
Dans l’explorateur de solution sélectionnez la dimension Dim Produit.
Les trois onglets Structure de dimension, Traductions et Navigateur s’ouvrent de
nouveau. L’onglet Hiérarchie est vide.
Figure 7.55 — Pour créer une hiérarchie, faites glisser une colonne
ou un attribut sur la partie centrale
Vous allez créer de toutes pièces une nouvelle hiérarchie Produit en incluant la
hiérarchie LigneProduit et Produit.
Avant de créer cette nouvelle hiérarchie et afin de mieux sélectionner les champs,
vous allez observer le contenu de la table DimProduit à partir de laquelle vous allez
reconstituer la hiérarchie.
Dans l’onglet Vue Source de données, faites un clic droit sur la table DimProduit
puis Explorer les données.
En cliquant sur l’en-tête de colonne, vous pouvez trier en ordre croissant ou
décroissant les données (ici NomProduitFrançais).
Figure 7.56 — Un clic droit sur une table dans la source de données permet d’explorer
le contenu de la table
Dans la hiérarchie Produit, vous allez sélectionner Ligne de produit puis immédia-
tement en dessous, NomProduitFrançais.
Figure 7.57 — Glisser-déplacer un champ de la vue source de données dans la hiérarchie
Revenez sur l’onglet DimProduit puis glissez le champ LigneProduit de la Vue

source de données vers Hiérarchie et Niveaux.
Une nouvelle hiérarchie vient d’être créée avec un seul élément LigneProduit.
Figure 7.58 — Hiérarchie après introduction d’un nouveau champ
Vous obtenez une nouvelle hiérarchie.
Hiérarchie temporelle
Dans l’explorateur de solutions, cliquez sur la dimension Dim Temps. Dans l’onglet
Hiérarchie et niveaux, renommez la hiérarchie en Dates.
Dans le menu Fichiers, choisissez alors Enregistrer tout.
Pour afficher les données du cube dans le projet, il est nécessaire de déployer le projet
sur une instance spécifiée de Analysis Services, puis traiter le cube et ses dimensions.
Le déploiement d’un projet Analysis Services entraîne la création des objets définis
dans une instance d’Analysis Services. Le traitement des objets dans une instance
d’Analysis Services, entraîne la copie des données à partir des sources de données
sous-jacentes dans les objets du cube.
Figure 7.59 — Renommer une hiérarchie
Déployez le cube
Faites un clic droit sur MonPremierCube puis sélectionnez Déployer.
Figure 7.60 — Déployer le cube permet de créer la structure du cube

sur le serveur Analysis Services
À l’issue du déploiement, l’assistant récapitule l’ensemble des actions qu’il a

réalisées.
Après que le cube est déployé puis traité sur le serveur, il est possible de naviguer
dans le cube grâce à l’onglet Navigateur.
Figure 7.61 — Récapitulatif du déploiement du cube sur le serveur
Dans le répertoire Cubes de l’explorateur de solutions, double-cliquez sur MonPre-

mierCube.cube puis dans la fenêtre de gauche, sélectionnez l’onglet Navigateur.
Vous observez un affichage proche du tableau croisé dynamique d’Excel. Vous allez
progressivement déplacer les champs de mesures et dimension vers ce tableau vierge.
Figure 7.62 — Onglet de navigation dans le cube
Tout d’abord, glissez-déplacez la mesure Quantité commandée dans la partie

centrale du rapport.
Figure 7.63 — La mesure Quantité commandée a été glissée sur la partie détail du navigateur
Les champs de dimension vont être dirigés vers les en-têtes de lignes et de colonnes.
Glissez-déplacez la dimension Dim Clients vers les en-têtes de lignes puis Dim
Produit dans en-têtes de colonnes.
Figure 7.64 — Le champ Ligne Produit définit les colonnes et Région définit les lignes
Glissez-déplacez la dimension temporelle Clé Date Commande vers l’emplacement

des champs de filtre. Dans la liste déroulante désélectionnez toutes les années sauf
2003.
Figure 7.65 — La date de commande remplit le rôle de filtre
En cliquant sur le signe + associé aux champs, vous allez pouvoir « forer » dans la
hiérarchie des dimensions. Cette technique est également appelée drill down. Le signe
– permet d’effectuer un drill up.
Figure 7.66 — Les signes + et — permettent d’effectuer drill down et drill up
Faites un clic droit sur l’espace du tableau puis sélectionnez Commandes et Option
puis comportement puis cochez les cases Barre de titre et Barre d’outils. Vous pouvez
obtenir un contexte proche de celui des tableaux croisés dynamiques d’Excel.
Figure 7.67 — Formulaire permettant d’afficher des éléments afin de rendre le navigateur
proche du tableau croisé dynamique
Rappelons que l’outil de navigation n’est pas mis à la disposition de l’utilisateur

final. Dans la phase de développement, il est utile au développeur et à l’administrateur
(au travers de la console de management) à des fins de contrôle.
Figure 7.68 — L’interface est maintenant celle du tableau croisé dynamique d’Excel
Vous pouvez continuer de déposer des champs mesures et/ou dimensions à partir
de la liste des champs disponibles.
Vous pouvez également retirer des champs (mesures ou dimensions) en sélection-
nant l’en-tête du champ et en glissant celle-ci hors du tableau.
Créer une nouvelle hiérarchie de dimension

La dimension Produit contient actuellement deux niveaux (Ligne produit et Produit).
L’analyste souhaite établir une subdivision par catégorie de produit et sous-catégorie
de produit.
L’observation du diagramme de la base Base_Entrepot dans SQL Management
Studio fait clairement apparaître les liens d’intégrité qui existent entre les tables
DimProduit, DimSousCatégorieProduit et DimCatégorieProduit.
La clé étrangère CléSousCatégorie de la table DimProduit et en jointure avec la clé
principale CléSousCatégorieProduit de la table DimSousCatégorieProduit.
De même la clé étrangère CléCatégorieProduit de la table DimSousCatégoriePro-
duit et en jointure avec la clé principale CléCatégorieProduit de la table DimCatégo-
rieProduit.
Afin d’ajouter les niveaux hiérarchiques Sous-catégorie de produit et Catégorie de
produit, il est nécessaire d’ajouter les deux tables correspondantes dans la vue Base
Entreprot.dsv.
Figure 7.69 — De nouvelles tables (catégories et sous-catégories) doivent être ajoutées

au modèle en flocon. Ci-dessus, représentation des tables dans Management Studio
Dans l’explorateur de solutions, cliquez avec le bouton droit sur la vue Base
entrepot.dsv.
Puis sélectionnez concepteur de cube.
Dans l’onglet de définition de vue, vous allez ajouter deux tables supplémentaires.
Dans le menu BI studio, choisissez Vue des sources de données puis Ajouter/Supprimer
des tables...
Figure 7.70 — Ajouter des tables à une vue des sources de données grâce aux tables associées
Dans la partie droite de l’écran (figure 7.70), cliquez sur la table dbo.DimProduit
puis actionnez le bouton Ajouter des tables associées.
Figure 7.71 — Ajouter des tables associées
Retirez la table FaitVentesRevendeur qui n’est pas utile pour le moment, puis
cliquez sur DimSousCatégorieProduit et actionnez de nouveau le bouton Ajouter des
tables associées.
L’assistant détecte automatiquement les jointures entre les tables puis les intègre
automatiquement à la vue.
Figure 7.72 — Objets inclus dans la vue finale
Cliquez sur OK.

Les deux nouvelles tables font maintenant partie de la vue Base Entrepot.dsv.
Sauvegardez tout.
Vous allez maintenant ajouter deux niveaux supplémentaires dans la hiérarchie
Produit.
Dans l’explorateur de solution, double-cliquez sur la dimension DimProduit.dim.
Dans la vue Source de données, utilisez le clic droit et l’option ajouter les tables...
Vous ajoutez les deux tables suivantes DimSousCatégorieProduit et DimCatégoriePro-
duit (figure 7.73).
Figure 7.73 — Ajouter les tables DimSousCatégorieProduit et DimCatégorieProduit

au schéma en flocon
Grâce au glisser-déplacer, vous allez insérer le champ NomFrançaisSousCatégorie

au-dessus de ligne Produit. Vous allez faire de même en amenant le champ NomFran-
çaisCatégorieProduit au-dessus du champ précédent.
Figure 7.74 — Glisser-déplacer un champ d’une table vers la hiérarchie
Renommez également le titre de la hiérarchie en Produit et Catégories.
Figure 7.75 — La nouvelle hiérarchie après introduction des champs de catégorie
Puis déployez le cube : clic droit dans l’explorateur de dimension puis Déployer.
Dans l’explorateur de solution, effectuez un clic droit sur la dimension Dim
Produit.dim, puis dans l’onglet central Navigateur, choisissez la hiérarchie globale
Produit et catégories puis déroulez l’arborescence des catégories de produit.
Figure 7.76 — Navigateur de dimension
Vous pouvez changer de niveau hiérarchique et observer les membres selon le

nouvel axe dimensionnel.
Figure 7.77 — Il est possible de naviguer dans tous les attributs de la dimension
La navigation dans le cube fait clairement apparaître la nouvelle hiérarchie Produit

et Catégorie.
7.5 Conclusion 229
Figure 7.78 — Les attributs catégories et sous catégories sont maintenant intégrés au cube
7.5 CONCLUSION
Ce chapitre nous a permis de comprendre les différentes étapes qui participent à la
création d’un cube. Nous avons successivement défini les sources de données. Nous
avons défini un schéma en flocon faisant apparaître clairement la table de faits centrale
et les tables descriptives appelées dimensions. Lors de la création du cube l’assistant
a détecté le rôle des tables en présence. Il a déterminé la table de faits comportant
les mesures (métriques), puis les tables dimensionnelles. Il a déterminé le niveau de
granularité et les liaisons entre tables de faits et tables de dimension.
Le déploiement du cube sur le serveur Analysis Services a ensuite permis de
naviguer dans le cube grâce à l’outil intégré à BI studio.
Dans le chapitre suivant nous apporterons un éclairage complémentaire en
présentant de façon plus détaillée les composants essentiels du cube afin de répondre
plus précisément à des problématiques métier.
8
Méthode
de conception
des cubes avec SSAS
Nous l’avons vu, créer un cube OLAP avec l’assistant ne présente pas de difficulté
majeure, en particulier si l’on respecte les paramètres standard fournis par l’outil. La
base de données relationnelle sous-jacente est indispensable à la fabrication du cube,
mais de par sa structure tabulaire et linéaire, elle reste difficilement exploitable pour
l’analyse. Le langage SQL, seul outil de requêtage, permet de réaliser des rapports
simples basés sur des notions de listes dont la valeur ajoutée consiste à effectuer
des regroupements matérialisés par des sous-totaux intermédiaires de colonnes et
totaux généraux. Un véritable serveur analytique dispose de la couche OLAP offrant
des performances constantes quelle que soit la volumétrie. À la vision purement
séquentielle de l’information, OLAP en apporte une transverse permettant ainsi de
mettre en relation des données non contiguës dans l’entrepôt. Cette capacité à définir
des rapprochements structurés dans l’espace est rendue possible grâce au langage MDX.
De telles performances sont rendues possibles grâce à une gestion simplifiée des
agrégations. Celles-ci résultent de calculs visant à regrouper des données numériques
puisées dans les tables de faits. Ces calculs sont préstockés dans le cube OLAP à des
niveaux variables de regroupement, rendant possible un affichage instantané. Cette
technique de regroupement de données sous forme pré agrégée est de loin plus efficace
que la méthode ancienne qui consistait à indexer des vues SQL. Cette technique
d’indexation était également accompagnée d’une mise à niveau coûteuse des matériels
afin de répondre à toujours plus d’exigence.
L’objectif principal est de déterminer les agrégations qui répondent le mieux aux
besoins métier et d’identifier la fréquence de mise à jour des agrégats. Un autre enjeu
232 Chapitre 8. Méthode de conception des cubes avec SSAS
consiste à décider de la façon de conserver l’historique et particulièrement s’il est

nécessaire de tracer les changements d’états successifs au niveau des axes d’observation
(produits, clients, fournisseurs, etc.).
La mise en place d’agrégations permet de prévenir des risques de mauvaise
interprétation des données. En effet, dans un modèle relationnel, comment s’assurer
que l’utilisateur qui désire suivre son stock semaine par semaine ne va pas par erreur
additionner des stocks successifs au lieu de ne considérer que la variation constatée
d’une semaine sur l’autre. Nous l’avons déjà vu, il s’agit là d’une notion de mesure
semi-additive, totalement prise en compte par OLAP. Un autre aspect naturellement
pris en compte par OLAP est le rapprochement de données à des niveaux de
granularité différents (budget défini à un niveau trimestriel, comparé à des données
journalières).
Une fois que les membres de l’organisation ont décidé des besoins métiers, ils vont
alors préciser comment ils souhaitent y accéder (Internet, intranet, via Excel ou autre
outil tiers) et la manière dont ils veulent naviguer au sein de leurs données (forage
progressif selon différents niveaux d’agrégation).
8.1 ORGANISATION LOGIQUE DES CUBES

8.1.1 Définition de la structure OLAP
Plusieurs étapes sont à respecter lors du développement d’un projet Analysis Services.
Démarrer le projet OLAP

Vous devez disposer de l’outil client BI Development Studio sur votre machine
de développement. Votre ordinateur doit pouvoir être connecté au serveur de
données de SQL Server 2008 afin d’accéder au datawarehouse. Il doit également être
connecté au serveur d’analyse de SQL Server 2008. De nombreux développeurs qui
travaillent en mode déconnecté installent les composants serveur sur leur machine de
développement. BI Studio sert à concevoir et à développer la base Analysis Services.
Management Studio a pour vocation de maintenir la base de données d’analyse (ajout
et exécution de partitions, sauvegarde, etc.). La règle est que tout développement
ou toute modification de définition des cubes doit être réalisé dans BI Studio puis
déployée sur le serveur. Plutôt que d’accéder directement aux tables des bases sources,
Analysis Services accède à celles-ci au moyen d’une couche d’exposition qui simplifie
grandement le processus de maintenance. C’est également grâce à ces vues que le
développeur exposera les champs de données selon des règles de nommage métier
compréhensible par l’utilisateur final.
Bien qu’il faille attendre que la phase de définition du datawarehouse soit terminée
avant d’entamer celle de la construction des cubes OLAP, il n’est cependant pas
nécessaire que la phase d’ETL soit terminée. Il est tout à fait possible et même
recommandé de ne pas attendre la fin du processus Integration Services pour démarrer
le projet SSAS. Bien souvent on se contentera de quelques données de test, que l’on
8.1 Organisation logique des cubes 233
pourra modifier manuellement afin de créer différentes situations. Les résultats seront
d’autant plus faciles à contrôler que les données sont peu nombreuses (contrôle des
moyennes, et des mesures semi-additives). Le temps de rafraîchissement des cubes sera
réduit d’autant.
Créer le projet et la vue des sources de données

Afin de contrôler une solution globale faisant intervenir des projets divers tels que
SSIS, SSAS, SSRS, il est fortement conseillé de créer une seule solution intégrant
elle-même les trois projets différents.
Cette stratégie permet de créer une vue des sources de données qui sera partagée
dans l’ensemble de la solution. Les sources de données partagées sont plus aisées à
maintenir parce qu’elles sont définies à un endroit unique (figure 8.1).
Figure 8.1 — Trois projets dans la même solution
L’assistant des sources de données peut en créer une nouvelle basée sur une
existante dans la même solution ou créer une source de données basée sur un projet
Analysis Services existant.
Figure 8.2 — Le menu ci-contre permet d’effectuer toutes les modifications

sur une vue de données
Lors de l’ajout de tables dans la vue (choix Ajouter/Supprimer des tables...

figure 8.2), les jointures existantes dans la base de données sous-jacente sont immédia-
tement reconstituées. On peut vouloir créer de nouvelles jointures entre des champs
de tables. Un simple glisser-déplacer suffit. Il est important d’effectuer le glisser depuis
le champ représentant la clé étrangère de la table côté n, vers le champ représentant

la clé unique dans la table côté 1 (figure 8.3).
Figure 8.3 — Les jointures sont reconstituées lors de l’ajout de tables
Les attributs de description des tables et des champs seront remplis avec soin car
Analysis Services utilise ces données lors de la création du cube. On évitera de stocker
les commentaires dans le cube lui-même car ils seraient alors remplacés à chaque
retraitement du cube.
Il est possible d’ajouter dans la vue des tables en provenance de serveur tiers
(Oracle, DB2, etc.). D’une manière générale, on préférera effectuer des jointures sur
des tables de bases de données tierce dans l’environnement propre du datawarehouse.
8.1.2 Définir les dimensions

D’une manière générale, les dimensions sont construites à partir du schéma en étoile
ou en flocon et sont a priori indépendantes de tout cube.
Figure 8.4 — Dans le projet Analysis Services Tutorial, huit dimensions ont été préparées
Les dimensions sont par nature partageables entre plusieurs cubes. Lors de la
construction du cube les dimensions sont sélectionnées. La figure 8.4 montre des
dimensions qui peuvent être partagées entre plusieurs cubes.
Une dimension standard contient une clé (Product Name dans la figure 8.6) un
ou plusieurs attributs, et une ou plusieurs hiérarchies. Analysis Services crée des
dimensions à partir de tables dénormalisées. Le passage de la troisième forme normale
à une forme de table « plate » permet de répondre à des critères de performance.
Figure 8.5 — Le cube est composé de dix dimensions (trois dimensions temporelles, Due date,
Order date, Ship date, dérivées des trois champs de type Date dans la table de faits). La figure 8.5
montre les dimensions utilisées par le cube Analysis Services Tutorial
Figure 8.6 — Dans l’onglet structure de dimension, les dimensions sont caractérisées
par des attributs et des hiérarchies
Une dimension peut inclure des hiérarchies de type parent/enfant. Une dimension
peut être à variation lente de type 1 (ne tient pas compte de l’historique) ou de
type 2 (garde la trace des changements). Une dimension peut présenter les deux types
simultanément. En effet les types de réaffectation sont définis au niveau de chaque
attribut de dimension et non pas au niveau global.
Une dimension de type 2 est toujours préférée au type 1, car il n’y a pas de
réaffectation globale sur l’historique à chaque rechargement de la table dimensionnelle.
Les traitements de reconstruction des cubes sont allégés d’autant.
Modifier les propriétés des dimensions

Une dimension possède plusieurs propriétés modifiables. Les plus importantes sont :
• Le nom de la dimension est visible de l’utilisateur. Il convient de le définir de
façon très représentative du métier.
• La description est également exposée à l’utilisateur.
• Le type peut revêtir des usages différents : les plus importants sont Regular, Time,
Accounts. Le type, déduit par l’assistant lors de la création de la dimension, est
naturellement modifiable et permet à SSAS d’établir un certain nombre de
contrôles lors de la création des cubes.
Nous donnons la définition de quelques propriétés de dimension :

• AttributeAllMemberName : affiche le texte au niveau le plus élevé de la hiérar-
chie de dimension (exemple : All Customers).
• ErrorConfiguration : SSAS détecte de lui-même des incohérences au niveau des
données de dimensions comme des clés dupliquées ou des violations d’intégrité
référentielle. Il s’agit d’un paramètre de gestion des erreurs configurable pour
gérer les clés dupliquées, les clés inconnues, les limitations des erreurs, l’action
lors de la détection d’erreurs, le fichier journal des erreurs et les clés NULL.
La figure 8.7 montre les différentes options offertes par la gestion des erreurs lors de
l’alimentation d’une dimension. Les options par défaut sont affichées et sont explicites.
Il est possible de tracer dans un fichier journal la liste des erreurs rencontrées lors du
traitement. Le choix pour cette option est personnalisé ou par défaut. Il est souhaitable
de laisser l’option par défaut.
Figure 8.7 — Options disponibles en cas de personnalisation de la configuration des erreurs
• Processing Mode : indique si l’indexation et l’agrégation doivent se produire

durant le traitement (Regular) ou après le traitement (Lazy).
• Processing priority : détermine la priorité de traitement du cube durant les

opérations en arrière-plan, telles que les agrégations et l’indexation différées. La
valeur par défaut est 0.
• ProactiveCaching : paramètres de mise en cache proactive pour le cube.
• Source : précise la vue de source de données utilisée pour le cube.
• StorageLocation : emplacement de stockage du système de fichiers pour le cube.
Si aucun n’est spécifié, l’emplacement est hérité de la base de données qui
contient le cube.
• StorageMode : mode de stockage pour le cube ; les valeurs sont MOLAP, ROLAP ou
HOLAP comme illustré dans la figure 8.8.
Figure 8.8 — Paramètres de stockage pour la dimension Customer
• Visible : détermine si le cube est visible ou non.
Modifier les attributs des dimensions

La plupart des attributs de dimensions sont définis correctement par l’assistant de
création de dimension. Quelques propriétés utiles ne sont cependant pas gérées par
l’assistant.
• Usage : Key est l’usage réservé à la clé de substitution (ou clé unique). L’usage
Regular sera choisi pour l’ensemble des attributs à une exception : une dimen-
sion parent-enfant présentera un usage Parent.
• Keycolumns : représente la colonne source de la table de dimension relationnelle.
En général, il s’agit de la clé unique représentée par la clé de substitution.
• OrderBy et OrderByAttribute : permettent de trier un attribut par la valeur de
la clé ou par le nom de l’attribut. Il est possible également de trier un attribut
selon l’attribut relié.
• IsAggregatable : un attribut peut être ou non agrégé. La valeur par défaut est vrai.
• AttributeHierarchyDisplayFolder : il est possible de regrouper artificiellement
plusieurs attributs. Il suffit de saisir un libellé dans la zone réservée à cet effet.
Celui-ci enrichit une liste déroulante qui peut être réutilisée pour d’autres
attributs.
Figure 8.9 — Les attributs sont organisés en trois ensembles homogènes (Contacts,
Demographic, Location)
• AttributeHierarchyVisible : permet de cacher des attributs que l’on ne souhaite

pas exposer à l’utilisateur. Un attribut peut être caché mais participer à une
hiérarchie de dimension.
• AttributeAllMemberName : est composé de all plus le nom de la hiérarchie. Il est
cependant possible d’en modifier le contenu.
• Attribut parent-enfants Une hiérarchie parent-enfant est une hiérarchie dans
une dimension standard qui contient un attribut parent. Un attribut parent
décrit une relation d’auto-référencement, ou jointure réflexive, dans une table de
dimension principale. Les hiérarchies parent-enfant sont construites à partir
d’un seul attribut parent. La figure 8.10 montre une relation parent-enfant. La
jointure récursive permet de faire pointer le champ EmployeeKey vers le champ
ParentEmployeeKey dans la même table Employee.
• RootMemberIf : permet d’identifier le membre parent le plus élevé dans la
hiérarchie.
• NamingTemplate : le modèle de nom de niveau détermine les noms de niveaux
affichés pour les utilisateurs lorsqu’ils parcourent le cube. Par exemple, Employee
Level * permet d’afficher (Tout) ; Employee Level 02 ; Employee Level 03 ;
Employee Level 04 ; etc.) en fonction du niveau sélectionné. Il est possible de
préciser manuellement des noms de niveaux distincts.
Figure 8.10 — Attribut parent-enfant de la dimension Employee
Modifier les attributs liés des dimensions

La notion d’attributs liés est une caractéristique qu’il est important de connaître
car sa maîtrise conditionne grandement les performances d’interrogation du cube.
Les attributs reliés participent à un mécanisme qui permet d’établir une intégrité
référentielle entre plusieurs attributs d’une même dimension. Lors de la création de
la dimension, l’assistant affecte à la clé de la dimension un lien d’intégrité de type
« un à plusieurs » avec l’ensemble des autres attributs de la dimension. Le paramètre
RelationShipType indique si une relation change dans le temps. Les valeurs sont les
suivantes :
• Rigid : signifie que les relations entre les membres ne changent jamais dans le
temps.
• Flexible : indique un changement possible dans le temps.
Créer des hiérarchies ou modifier les attributs de hiérarchie de dimensions

La création d’une hiérarchie résulte d’un besoin métier ou de contraintes de naviga-
tion.
Structure de dimension
Certaines hiérarchies sont naturelles telles que année/mois/jour ou catégorie de
produit/sous-catégorie de produit/produit. D’autres sont moins naturelles telles que
fréquence de commande/nom du revendeur.
Les niveaux des hiérarchies sont construits à partir des attributs des hiérarchies. Les
propriétés de chaque niveau sont également empruntées aux attributs correspondants
et ne peuvent être modifiées au sein de chaque hiérarchie.
Pour une hiérarchie régulière, utilisez la propriété HideMemberIf d’un niveau d’une
hiérarchie pour masquer les membres manquants aux utilisateurs finaux.
Figure 8.11 — Créer des hiérarchies et des niveaux par un glisser-déplacer des attributs
des dimensions vers la fenêtre hiérarchies et niveaux
Traductions
Les traductions permettent au serveur de prendre en charge les applications clientes
en adaptant le langage de présentation selon la langue du client. Il est utile de pouvoir
traduire divers éléments d’un cube et de ses dimensions dans une langue différente,
de sorte que des personnes de divers pays puissent afficher et comprendre le cube. Au
moment de l’affichage de la requête, un dialogue s’établit entre la station du client
et le serveur. Le client renvoie la langue utilisée au serveur qui renvoie à son tour le
résultat de la requête dans la langue de l’utilisateur.
Navigateur
L’onglet Navigateur permet d’explorer les attributs ou les hiérarchies de dimension. La
figure 8.12 montre une navigation dans la hiérarchie Product Categories. Après toute
modification d’un attribut ou hiérarchie il est nécessaire de se reconnecter au cube
avant d’explorer à nouveau les données.
Avant de parcourir les données il est nécessaire de traiter la dimension. Il n’est
cependant pas nécessaire de déployer le cube ou de traiter la base de données du cube.
Dans la figure 8.12, si une traduction avait été développée, la liste déroulante ferait
apparaître les membres dans la langue adéquate.
Figure 8.12 — Choisir une hiérarchie ou un attribut et parcourez la liste des données
8.1.3 Modification du cube

Nous l’avons vu, l’assistant permet de créer rapidement un cube en précisant :
• la vue de la source de données ;
• les tables de dimensions ;
• les tables de faits ;
• les tables qui servent de passerelles dans des relations de dimensions de type
plusieurs à plusieurs.
Après que le cube a été créé grâce à l’assistant, il est possible de revenir sur tous
les composants du cube grâce au concepteur de cube. Il est possible de tester le cube,
d’ajouter de nouvelles dimensions à des groupes de mesures et d’ajouter des groupes de
mesure.
Les objets qui composent le cube sont présentés ci-après.
Les mesures sont des données en provenance des tables de faits. On distingue :
• les mesures physiques définies à partir des colonnes de la vue source ;
• les mesures calculées dérivées d’autres colonnes de la table de faits. Les calculs
sont élaborés grâce au langage MDX (Multidimensional Expressions) ;
• les fonctions d’agrégation permettent des fonctions de type sum, count, min, max,
distinct cStyle caratère : CodeDansTexte non pris en charge
ount.
Les groupes de mesures rassemblent des mesures extraites d’une même table de
fait et dont la granularité est définie par les dimensions.
Le cube rassemble dimensions, mesures et groupes de mesure. Ceux-ci se com-
portent comme les cubes virtuels de la version MSAS 2000, les cubes virtuels étant le
résultat de jointure de cubes physiques distincts.
La base de données Analysis Services peut héberger plusieurs cubes. Pour une
bonne organisation, il est préférable de ne traiter qu’un seul cube par base de données.
Lorsque de nombreuses mesures et dimensions sont disponibles dans le cube,

il est souhaitable de présenter les informations d’entreprise en fonction du métier
de l’utilisateur. C’est le rôle des perspectives. Cette fonctionnalité est disponible
uniquement dans la version SQL Server Enterprise.
Les cellules se distinguent en cellules feuilles (terminales) et cellules non termi-
nales non-feuilles. Dans SSAS, la cellule représente l’unique intersection logique d’un
membre de n’importe quelle dimension référencée dans un cube. Un cube se compose
essentiellement de cellules, rassemblées dans des groupes de mesures et classées par
dimension.
Un membre non-feuille est un membre qui possède un ou plusieurs membres
enfants. Dans ce cas, la valeur de la cellule dérive le plus souvent de l’agrégation de
membres enfants associés au membre non-feuille.
Figure 8.13 — Cellules feuilles
Dans la figure 8.13, une seule cellule est ombrée. Cette cellule est l’intersection
des membres suivants :
• le membre avion de la dimension Itinéraire ;
• le membre Afrique de la dimension Source ;
• le membre quatrième trimestre de la dimension Temps ;
• la mesure Packages.
La valeur de la mesure Packages (240 dans notre exemple) peut être extraite
directement de la colonne correspondante d’une ligne de la table de faits, car tous les
membres sont terminaux (feuilles).
Dans l’exemple fourni par la figure 8.14, les deux cellules en grisé représentent
un agrégat du 3e et 4e trimestre soit le 2e semestre. Le membre du 2e semestre est
non-feuille car tous les membres qui lui sont associés doivent être agrégés.
Figure 8.14 — Cellules non-feuilles
La dimension Mesures fait l’objet d’un traitement particulier. Cette dimension

regroupe les données numériques faisant l’objet de traitement d’agrégation.
8.1.4 L’utilisation des dimensions

L’onglet « utilisation de la dimension » permet rapidement d’observer quelles dimen-
sions participent à quels groupes de mesures.
La structure du cube fait apparaître le groupe de mesures ainsi que les dimensions
générées avec l’assistant. Chaque groupe de mesures rassemble des données en
provenance d’une même table de faits. On observe que les trois dates différentes
dans les tables de faits ont généré trois axes dimensionnels différents (Due Date, Order
Date, Ship Date).
L’onglet Utilisation de la dimension permet, pour chaque groupe de mesures, de
préciser si telle ou telle dimension participe à ce groupe et à quel niveau de granularité.
On trouve fréquemment des niveaux de granularité différents. C’est le cas lorsque l’on
désire comparer des prévisions (table de faits prévus) connues à un niveau trimestriel
alors que la table de faits réalisés fournit des données quotidiennes.
Chaque table de faits dans la vue des sources de données constitue un groupe de
mesures.
Chaque dimension peut participer ou non à une agrégation de mesure.
Figure 8.15 — La structure du cube présente les groupes de mesures et les dimensions du cube
À chaque intersection d’une mesure et d’une dimension, on peut trouver différents

types de relations entre les tables de faits et les dimensions :
• Aucune dimension : la table de faits et la table de dimension ne sont pas
associées.
• Normale : la table de dimension est directement jointe à la table de faits.
• Fait : la table de dimension est la table de fait.
• Référencé : la table de dimension est jointe à une table intermédiaire, elle-
même jointe à la table de faits.
• Plusieurs à plusieurs : la table de dimension est jointe à une table de faits
intermédiaire, elle-même jointe à une table de dimension qui à son tour est
jointe à une table de dimension intermédiaire, cette dernière étant jointe à la
table de faits. SSAS simplifie en proposant une jointure entre la dimension et
un groupe de mesures intermédiaire.
• Exploration des données : la dimension cible est basée sur un modèle d’explo-
ration de données (voir algorithmes dans le chapitre « Data mining »).
8.1.5 Les calculs

La création de calculs portant sur différents objets du cube (mesures, dimensions,
membres, etc.) nécessite l’utilisation du langage MDX. Parce qu’il est dans la nature
humaine de résister à tout nouvel apprentissage, SSAS fournit encore une fois un
point d’entrée relativement aisé grâce à un assistant dont le but est d’occulter une
grande part de complexité. Il s’agit de l’outil d’ajout de Business Intelligence qui
permet de créer plusieurs types de calculs.
Figure 8.16 — L’onglet utilisation de la dimension

Observez les relations de type plusieurs à plusieurs (n à n) et relation de fait (dimension dégénérée)
Figure 8.17 — Formulaire permettant de créer une mesure calculée
De nombreux calculs sont aisés à créer tels que des sommes de mesures ou des ratios.
Les mesures calculées s’ajoutent à la liste des mesures existantes. Pour l’utilisateur
final, il n’existe pas de différences entre une mesure physique et une mesure calculée.
Dans l’exemple ci-dessous, nous créons une mesure calculée nommée MoyenneDes-
Ventes dont l’expression de calcul est obtenue par glisser-déplacer des mesures du volet
de gauche vers le champ Expression. La fonction division a été fournie manuellement.
L’assistant génère la commande MDX suivante :
CALCULATE;
CREATE MEMBER CURRENTCUBE.[MEASURES].MoyenneDesVentes
AS [Measures].[Internet Sales-Sales Amount]/[Measures].[Internet Sales Count],
FORMAT_STRING = "Percent",
VISIBLE = 1;
Une liste de fonctions est fournie grâce à l’onglet Fonction. On y retrouve des
fonctions statistiques (arithmétiques), temporelles, de manipulation de chaîne de
caractères, conditionnelles, etc.
Il faudra rester vigilant sur la complexité des calculs car les mesures calculées font
l’objet de traitement d’agrégation à la volée, au moment de l’affichage. Les mesures
calculées ne sont pas stockées dans le cube.
Les membres calculés sont définis à l’intérieur des dimensions plutôt que dans les
mesures.
Les jeux nommés représentent un ensemble de membres de dimensions. Par
exemple, un jeu nommé peut représenter un groupe de produits, ou un sous-ensemble
de clients que l’on veut identifier rapidement.
8.1.6 Ajouter de la Business Intelligence

À moins que vous ne soyez un expert en langage MDX, la meilleure méthode pour vous
initier au langage MDX est d’utiliser l’assistant de Business Intelligence. Cet assistant
propose un ensemble de calculs que l’on rencontre fréquemment dans l’entreprise.
Le bouton Ajouter de la Business Intelligence vous permet de lancer l’assistant
qui propose un certain nombre d’améliorations telles que :
• Assistant Time Intelligence : permet d’ajouter des vues supplémentaires para-
métrées en fonction du temps et du niveau hiérarchie sélectionné. Il est ainsi
possible de calculer des mesures de type Year to Date (période-à-date), moyenne
mobile, moyenne sur douze mois et comparaison de périodes en valeur et en
pourcentage. Cet assistant ne fonctionne que si au moins une dimension date
existe dans le cube.
• Intelligence comptable : permet d’attribuer des classifications comptables stan-
dard, par exemple les bénéfices et les dépenses, aux membres d’un attribut
de compte. Le serveur utilise ces classifications pour agréger les comptes
(débit/crédit, positif ou négatif).
• Intelligence des dimensions : identifie une dimension et ses attributs comme
étant de types prédéfinis tels que produits, clients, taux, temps etc. Lorsque le
type de dimension a été défini, des valeurs calculées additionnelles peuvent être
créées en utilisant la définition de la dimension.
• Opérateur unaire pour remplacer l’agrégation par défaut qui est associée aux
membres dans une hiérarchie parent-enfant.
• Formule de membre personnalisée : pour remplacer l’agrégation par défaut
d’une hiérarchie par les résultats d’une expression MDX.
• Ordre de classement des attributs pour spécifier comment les membres d’un
attribut sont classés. Ils peuvent être classés d’après le nom ou la clé de l’attribut,
ou d’après le nom ou la clé d’un autre attribut. Par défaut, les membres sont
classés par le nom.
• Écriture différée de la dimension permet aux utilisateurs de modifier manuelle-
ment la structure de la dimension. Les mises à jour effectuées sur une dimension
activée en écriture sont enregistrées directement dans la table de la dimension.
• Comportement semi-additif définit la méthode d’agrégation pour les mesures
ou les membres individuels d’un attribut de type compte.
• Conversion monétaire définit les règles de conversion et d’analyse des données
multinationales du cube. Les règles de conversion s’appliquent au niveau du
cube dans le script de calcul.
8.1.7 Les indicateurs clé de performance (KPI)

Les indicateurs clé de performance mesurent la santé de l’entreprise. Ces dispositifs
sont généralement mis à disposition des managers afin de leur permettre de piloter leur
business. À l’instar d’un tableau de bord de voiture qui regroupe les cadrans essentiels
pour la conduite du véhicule, on retrouve ces indicateurs de pilotage de l’entreprise au
sein du « digital dashBoard » ou tableau de bord numérique de l’entreprise. Celui-ci
offre une vue synthétique de l’activité et grâce à des systèmes d’alerte permet en un
seul coup d’œil de contrôler toute dérive au sein de l’entreprise.
Afin d’interpréter ces indicateurs visuels, il est nécessaire de disposer d’outils
capables de lire et de restituer les KPI de SQL Server 2008. On dispose d’outils tels
qu’Excel (à partir de la version 2007) ou Panorama Software.
Un indicateur clé de performance reflète cinq niveaux d’observation : très bon,
bon, moyen, mauvais, très mauvais.
Un indicateur clé est conçu à partir de quatre composants :
• L’expression de valeur résulte d’une simple mesure ou d’un membre calculé.
Exemple : [Measures].[Reseller Sales-Sales Amount].
• L’expression de l’objectif à atteindre, en général une expression MDX, ou peut-
être un membre ou un attribut de dimension. Exemple : [Measures].[Sales
Amount Quota].
• L’état avec son indicateur d’état très visuel (figure 8.18).
Tapez l’expression MDX qui renvoie la valeur d’état de l’indicateur de performance

clé lorsque ce dernier est exécuté.
Faites glisser les éléments sélectionnés du volet Outils de calcul vers cette option
pour inclure la syntaxe MDX des éléments sélectionnés.
Figure 8.18 — Liste des indicateurs d’état
Il est recommandé que cette expression renvoie une valeur décimale comprise
entre – 1 et 1. Une valeur inférieure à zéro représente une situation négative alors
qu’une valeur supérieure à zéro représente une situation positive.
Exemple de code calculant l’état de l’indicateur :
Case
When KpiValue("Reseller Revenue")/KpiGoal ("Reseller Revenue")
>=.95
Then 1
When KpiValue("Reseller Revenue")/KpiGoal ("Reseller Revenue")
<.95
And
KpiValue("Reseller Revenue")/KpiGoal ("Reseller Revenue")
>=.85
Then 0
Else -- 1
End
• La tendance.
La tendance est représentée par des valeurs numériques qui se traduisent graphi-
quement par des flèches.
Case
When IsEmpty
(
ParallelPeriod
(
[Date].[Calendar Time].[Calendar Year],
1,
[Date].[Calendar Time].CurrentMember
)
)
Then 0
When (
KpiValue("Reseller Revenue") --
(
KpiValue ("Reseller Revenue"),
ParallelPeriod([Date].[Calendar Time].[Calendar Year],
1, [Date].[Calendar Time].CurrentMember)
)
/
(

)
)
>=.05
Then 1
When (
KpiValue("Reseller Revenue") --
(
)
/
(
)
)
<=.02
Then -- 1
Else 0
End
Dans l’exemple ci-dessus le calcul consiste à effectuer le ratio suivant (Reseller

Revenue Année A – Reseller Revenue Année A-1)/(Reseller Revenue Année A-1).
Si le ratio est > 5 % alors la tendance est positive (valeur 1 = flèche vers le haut). Si
le ratio est < à 2 % alors la tendance est négative (Valeur -1 = flèche vers le bas).
Le résultat affiché dans le navigateur de l’onglet KPI est montré figure 8.19.
Figure 8.19 — Le navigateur dans SSAS permet d’afficher la valeur, l’objectif, l’état et la tendance
PerformancePoint Monitor et Analytics (Proclarity) permettent de réaliser sans

programmation MDX de tels KPI.
Les KPI générés dans le cube sont récupérés par les tableaux croisés dynamiques
d’Excel version 2007 (Excel 2003 ne peut les exploiter).
8.1.8 Les actions

SSAS permet d’exécuter des commandes sur le serveur. Les actions sont définies grâce
au langage MDX. Une action peut être déclenchée par l’utilisateur en effectuant
un clic droit sur une cellule agrégée d’un tableau afin de connaître les lignes qui
participent à la valeur de la cellule.
Plusieurs types d’action peuvent être envisagés :
• l’accès au détail (drillthrough) ;
• l’exécution d’un rapport grâce à Reporting services (voir chapitre 10) ;
• l’exécution d’une action générique telle que l’appel d’une URL ou l’exécution
d’une commande. Une action est une instruction MDX et peut être exécutée
par l’utilisateur en cliquant (droit) sur la valeur contenue dans une cellule ou
sur le nom du membre de la cellule. L’action reçoit en paramètres des données
du cube qui sont transmises à l’application cliente.
Lors de la modification d’une action dans le cube il n’est pas nécessaire de retraiter
les données. Seules les métadonnées doivent être déployées.
8.1.9 Les perspectives

Une perspective s’apparente à une vue qui s’applique au sommet de la base de données
et qui permet de limiter l’accès à certaines dimensions et groupes de mesures. Dans
certaines organisations, on cherche même à ne présenter que certaines perspectives à
certains utilisateurs autorisés. Il est possible également de cacher le cube
Les perspectives ne sont disponibles que dans la version SQL Server 2008
Enterprise ou Developer. Si vous disposez de la version standard avec un modèle
de cube qui intègre des perspectives, vous devrez les supprimer avant de déployer le
cube.
8.1.10 Les traductions

L’onglet Traductions permet d’exposer les métadonnées du cube selon la langue de
l’utilisateur. Il est possible d’apporter des traductions aux groupes de mesure, aux
mesures, aux dimensions, aux KPI, aux actions, aux jeux nommés et aux membres
calculés.
Le choix de la langue est déterminé en fonction des paramètres régionaux stockés
sur le poste client.
8.1.11 Le navigateur de données

Le dernier onglet du concepteur de cube offre l’opportunité de tester le cube. Avant de
pouvoir naviguer dans les données du cube, vous devez traiter et déployer le cube. Le
navigateur qui s’apparente au tableau croisé dynamique d’Excel, permet de contrôler
rapidement l’effet de modifications apportées dans le cube. Il n’est donc pas nécessaire
de disposer d’un outil tiers tel qu’Excel ou Proclarity pour procéder aux tests de
validation.
8.2 L’organisation physique du cube 251
8.2 L’ORGANISATION PHYSIQUE DU CUBE

8.2.1 Les groupes de mesures et les partitions
Lors de la création du cube via l’assistant, celui-ci crée automatiquement une partition
par groupe de mesures.
Figure 8.20 — L’onglet Partitions montre les partitions liées aux groupes de mesures
L’assistant attribue un nom à chaque partition emprunté au groupe de mesure

auquel il est lié. La source précise la table ou la vue qui alimente la partition. La source
est identique à celle sur laquelle repose le groupe de mesures. Un groupe de mesure
repose sur une table de faits. Si vous avez installé BIDS Helper il vous est possible de
régler finement les agrégats.
Figure 8.21 — Chaque partition correspond à un groupe de mesure du cube
La colonne agrégations précise le mode de stockage des agrégations de données.

Dans certains cas, il sera nécessaire de créer plusieurs partitions pour un même groupe
de mesures. Chaque partition dispose de sa propre source de données qui peut se
traduire par une vue filtrée. Les partitions sont associées dans le groupe de mesure.
Figure 8.22 — Groupe de mesure avec plusieurs partitions temporelles en provenance

d’une même table de faits
8.2.2 Les différents modes de stockage

Par défaut, SSAS propose le mode de stockage MOLAP (Multidimensional OLAP) qui
est de loin le plus performant. Le mode MOLAP est adapté au modèle dimensionnel.
Il utilise un algorithme de compression des données et des techniques d’indexation
offrant d’excellentes performances. MOLAP sera préféré aux vues indexées aussi bien
en termes d’espace requis pour le stockage des index qu’en termes de performances.
Dans le mode MOLAP, toutes les données sont stockées dans le cube selon une
organisation dimensionnelle.
Il est cependant possible de stocker les dimensions dans deux autres modes appelés
ROLAP (Relational Olap) et HOLAP (Hybride OLAP).
Lorsque les données sont stockées dans l’ordinateur sur lequel la partition est défi-
nie, une partition locale est créée. Lorsque les données sont stockées sur un autre serveur
Analysis Services, une partition distante est créée. La structure multidimensionnelle
qui stocke les données de la partition se situe dans un sous-dossier du dossier Data des
fichiers programmes de Analysis Services.
Dans le mode ROLAP, les données de détail et les agrégats sont stockés dans des
tables relationnelles. Lorsque les résultats ne peuvent pas être dérivés des agrégations
ou du cache de requête, le système accède à la table de faits de la source de données
pour répondre aux requêtes. Ce mode offre des performances inférieures aux deux
autres modes. Le mode ROLAP permet d’économiser de l’espace de stockage pour les
grands datasets qui sont rarement interrogés, comme les données purement historiques.
Si une partition utilise le mode de stockage ROLAP et que ses données sources sont
stockées dans SQL Server 2008 Analysis Services, Analysis Services tente de créer des
vues indexées pour contenir les agrégations de la partition. La création et l’utilisation

de vues indexées pour les agrégations exigent que la partition ROLAP et les tables de
son schéma remplissent les conditions suivantes :
• la partition ne peut contenir de mesures qui utilisent la fonction Min() ou Max();
• chaque table de la partition ne peut être utilisée qu’une seule fois ;
• les colonnes source ne doivent pas contenir de données NULL.
Dans le mode HOLAP, les données de détail sont stockées dans des tables
relationnelles tandis que les agrégats le sont dans un format multidimensionnel. Le
mode de stockage HOLAP convient pour les partitions de cubes qui nécessitent des
réponses rapides aux requêtes sur des données de synthèse calculées à partir d’un
volume important de données source. Style caratère : Texte-Courant-Car non pris en
charge
Les performances sont intermédiaires entre MOLAP et ROLAP.
8.2.3 Comment SSAS rafraîchit-il les données du cube ?

Le service de notification de SQL Server 2008 informe Analysis Services lorsque des
changements surviennent dans les tables sources. Lorsqu’une partition est liée à une
vue, il est nécessaire de préciser la table de suivi.
Figure 8.23 — Paramétrer les options de stockage

Figure 8.24 — Préciser la table de suivi qui informe SSAS en cas de modification
L’interrogation planifiée interroge régulièrement la base afin de déterminer si des

données ont changé.
Dans le cas du mode ROLAP temps réel, les données sont directement stockées
dans la table relationnelle. Il n’y a pas besoin de notification ni de cache proactif. Les
données sont toujours à jour mais ce au détriment des performances.
Figure 8.25 — Management studio présente les partitions associées aux groupes de mesures
Après le déploiement du cube, SQL Server Management Studio permet d’observer

le cube et ses dimensions attachées à chaque groupe de mesures.
Figure 8.26 — Les propriétés de la partition sont modifiables dans Management Studio
telles que le mode de stockage et la mise en cache proactif
Du fait de sa capacité à optimiser les accès aux données, le partitionnement est

indispensable lorsque les groupes de mesures sont volumineux (millions ou milliards de
lignes). Il est également plus rapide d’ajouter des données dans une nouvelle partition
plutôt que dans une partition déjà très volumineuse. Le partitionnement est également
utile lorsque l’on désire conserver des données sur une période glissante (par exemple,
lorsque l’on souhaite conserver les trois dernières années ou les 90 derniers jours).
Dans ce cas, il suffit de supprimer la partition plutôt que de supprimer des lignes dans
une énorme partition. Enfin, le partitionnement améliore les performances lors du
processus de traitement complet d’un groupe de mesures.
Le partitionnement multiple peut être envisagé pour de très gros volumes. Il est
possible par exemple de créer des partitions par mois et par catégorie de produits.
Cette fonctionnalité est réservée à SQL Server Enterprise Edition.
Lorsque vous établirez des partitions, soyez vigilants aux bornes que vous devez
définir dans la clause WHERE. BI Studio ne permet pas de détecter si des données en
provenance des tables de faits sont doublées ou manquantes.
Lors du développement avec BI Studio, vous pouvez préciser l’édition du serveur
de déploiement (Enterprise ou Standard). Ce dispositif permet de fournir à BI Studio
les fonctionnalités autorisées ou non, et de signaler toute incohérence avant le
déploiement.
Figure 8.27 — Dans les propriétés du projet, précisez l’édition du serveur de déploiement
8.2.4 Paramétrer les agrégations

Le paramétrage des agrégations permet de définir les limites de stockage ou de
performance des agrégations générées.
Figure 8.28 — Le formulaire « Définir les options d’agrégations » permet de définir les limites de
stockage ou de performance des agrégations générées
• L’espace de stockage estimé atteint xxx Mo – Limite les agrégations en

indiquant l’espace disque autorisé pour générer les agrégations.
• Les gains de performance atteignent xx % – Limite la conception d’agrégation
en définissant le pourcentage maximal de gain de performance estimé que la
conception d’agrégation peut fournir.
• Je clique sur Arrêter – Arrête la conception d’agrégation en cliquant sur
Arrêter au cours du processus de conception.
• Ne pas créer d’agrégations (0 %) – On utilise cette option pour supprimer des
agrégations existantes pour une partition, un groupe de mesures ou un cube.
• Démarrer – Démarre le processus de conception d’agrégation.

• Arrêter – Arrête le processus de conception d’agrégation.
8.2.5 Processus de mise à jour des cubes

Il existe plusieurs méthodes d’alimentation du cube. Une méthode réside dans la
technique du cache proactif. L’alimentation s’effectue à partir des tables opération-
nelles lors de leurs mises à jour. Il est possible également d’alimenter directement
le cube à partir de SSIS à l’aide du flux de données multidiffusion afin d’alimenter
simultanément le datawarehouse et le cube multidimensionnel. Sauf cas exceptionnel,
nous conseillons toujours de passer par l’étape du datawarehouse qui, à son tour, sert à
alimenter le cube.
Plusieurs méthodes peuvent être mises en œuvre.
Retraitement complet
Cette méthode consiste à retraiter la totalité du cube à chaque ajout de données dans
un groupe de mesures. Il s’agit naturellement de la méthode la plus simple à mettre en
œuvre et probablement la plus sûre. Elle est choisie par la plupart des administrateurs.
Elle est naturelle et même conseillée si les cubes ont une faible volumétrie et, par
conséquent, un temps de retraitement court. Cette méthode est à proscrire si les mises
à jour des tables de faits sont quotidiennes avec des volumétries très élevées (centaines
de milliers d’enregistrements). Dans ce cas, nous aurons recours à la méthode de
traitement incrémentiel.
Traitement incrémentiel
Le traitement incrémentiel consiste à filtrer les données les plus récentes des tables de
faits afin de ne traiter qu’un nombre réduit de lignes. Cette technique est séduisante
mais elle nécessite une très grande rigueur lors de la phase d’alimentation. Le risque
naturel est de traiter deux fois les mêmes données ou tout simplement d’omettre de
les traiter. Malheureusement, SQL Server 2008 ne dispose pas de solution intégrée.
Le développeur doit mettre en place un mécanisme d’audit qui consiste à « marquer »
les lignes ayant fait l’objet d’un traitement afin de s’assurer de ne pas les traiter une
seconde fois. L’absence de traitement ou un traitement partiel sont plus délicats à
gérer puisqu’ils ne laissent aucune trace. Dans ce cas, on pourra développer un script
MDX qui établira un contrôle quotidien avec la base de production pour détecter des
écarts éventuels et retraiter la partition incriminée.
8.2.6 Où sont stockées les données du cube et comment optimiser

le stockage ?
SSAS fournit des propriétés du serveur qui s’appliquent à l’ensemble de l’instance
SSAS. Il est possible de modifier tout ou partie des paramètres du serveur.
Dans Management Studio ouvrez une instance d’Analysis services puis clic droit
sur le Serveur.
Management Studio effectue une lecture du fichier msmdsrv.ini

Il est intéressant de constater deux catégories de paramètres
• Emplacement des Répertoires (emplacements par défaut pour les données, les
backup et les journaux)
• Paramétrage des fichiers journaux (définit le paramétrage des query log à des
fins d’optimisation des agrégations)
Figure 8.29 — Fenêtre présentant les propriétés définies pour l’Instance Analysis Services
Sur la figure 8.29 on observe les répertoires par défaut réservés aux backup, aux
données et journaux etc.
Si vous désirez optimiser les performances des cubes, il est d’usage de suivre
l’activité du serveur afin de détecter les requêtes les plus fréquemment utilisées et
celles dont la durée d’exécution est la plus longue.
Vous devrez par conséquent passer à True la valeur de CreateQueryLogTable,
puis créer une connexion à un serveur de base de données grâce à la propriété
QueryLogConnectionString. La propriété QueryLogSampling permet d’attribuer
une fréquence de stockage des traces. La propriété QueryLogTableName fournit le
nom de la table SQL qui capture les statistiques d’interrogation. Par défaut cette table
se nomme OlapQueryLog.
Figure 8.30
Figure 8.31 — Paramètres permettant de tracer les requêtes effectuées sur le serveur OLAP
Figure 8.32
Chaque Requête effectuée sur le serveur permet d’alimenter la table OlapQueryLog.

Déterminez la période de suivi des requêtes.
Figure 8.33
Il convient ensuite de créer les optimisations dans le cube en fonction du résultat

des requêtes tracées.
Figure 8.34
Voici le résultat final.
Figure 8.35
BIDS Helper permet de vérifier les agrégats.
Figure 8.36 — Fenêtre des agrégats fournie par BIDS Helper
L’opérateur a la possibilité de créer lui-même ses propres agrégats en cochant les

attributs dans la fenêtre de droite.
BIDS Helper permet de recueillir automatiquement toutes les lignes d’agrégats
dont la durée de la requête dépasse x millisecondes.
Figure 8.37
Dans l’exemple ci-dessus, BIDS Helper va créer des agrégats pour les requêtes dont
la durée est supérieure ou égale à 10 millisecondes. La liste des requêtes fournie par
le Query Log peut faire l’objet d’une injection directe dans le cube (fonction BIDS
Helper)
8.3 RECOMMANDATIONS
Bien que les assistants soient nombreux dans Analysis Services, ce logiciel est
complexe et nécessite beaucoup de soin dans sa conception. Nous ne saurions trop
vous conseiller d’installer l’utilitaire gratuit BIDS Helper 2008. Cet utilitaire vous
permettra de mieux contrôler l’optimisation de vos cubes et les raisons éventuelles de
dysfonctionnement.
Lors de la mise au point initiale, testez, contrôlez autant que vous le pourrez. Après
la mise en production du cube, donnez-vous les moyens de croiser des données du
cube avec d’autres sources telles que le datawarehouse sous-jacent. Il n’y a rien de
plus efficace pour jeter le discrédit sur votre œuvre qu’un utilisateur qui lance en
pleine réunion que le cube donne des résultats incohérents. Ne soyez jamais seul à
concevoir vos cubes. Testez avec les utilisateurs avancés (Key Users), observez leur
façon d’interpréter et de contrôler les données. Mettez en production les automates
de contrôle et faites-vous alerter par SSIS au moindre écart. Soyez le premier à alerter
les utilisateurs qu’un dysfonctionnement a eu lieu plutôt que d’apprendre par eux que
votre cube est faux !
9
Le data mining
Un diffuseur d’ouvrages distribue plusieurs sortes de magazines : sciences humaines,

philosophie, roman, sport et beaux-arts. Il souhaite mieux étudier ses clients pour
découvrir de nouveaux marchés ou vendre plus de nouveautés à ses libraires. Les
questions qu’il se pose sont les suivantes :
• Combien de libraires ont acheté des ouvrages de sport cette année ?
• A-t-on vendu plus d’ouvrages de sport cette année que l’année dernière à la
même période ?
• Les libraires qui achètent des ouvrages de philosophie achètent-ils également
des ouvrages de « beaux-arts » ?
• Quels sont les critères qui caractérisent une librairie orientée sport ou sciences
humaines ?
• Comment puis-je prédire la perte des clients et les actions nécessaires pour la
réduire ?
Les réponses aux questions 1 et 2 peuvent être fournies par de simples outils de
requêtage de type SQL.
La question 1 trouvera une réponse en exécutant une requête SQL sur la base de
données opérationnelle ou mieux sur l’entrepôt de données. Les critères d’extraction
sont dans ce cas l’année de l’achat et le type d’ouvrage (sport).
La question 2 implique de conserver en ligne deux années de ventes, puis de
comparer l’agrégat des ventes réalisées en Year to date (cumul depuis le début de
l’année) et d’en déduire l’écart en valeur. La réponse sera fournie très facilement par
une requête MDX exécutée sur le cube OLAP. Excel fournira une réponse, grâce au
tableau croisé dynamique.
La question 3 permet de déterminer la probabilité que la règle d’association entre
plusieurs éléments est vérifiée. Il s’agit d’un type de recherche dirigée car l’objectif est
264 Chapitre 9. Le data mining
totalement identifié. Si la valeur de la probabilité est élevée, le diffuseur serait avisé

d’effectuer des offres promotionnelles en associant les deux produits. La réponse à
cette question sera fournie par un des algorithmes de data mining.
La question 4 est de nature exploratoire. Il s’agit de découvrir une règle plutôt
que de la vérifier. Cela est du ressort du data mining, technologie qui offre plusieurs
algorithmes répondant à cette problématique.
La question 5 est également exploratoire et nécessite de conserver un historique
afin de modéliser les comportements d’attrition (départ volontaire du client). Il y a lieu
de mettre en œuvre des indicateurs tels que quantités retournées, délais de paiements,
impayés. La notion temporelle est très importante car elle permet d’observer au fil du
temps des changements parfois imperceptibles.
9.1 MÉTHODOLOGIE DE CRÉATION DU MODÈLE

DE DATA MINING
9.1.1 Définition du problème à résoudre
Lorsque l’on entreprend un processus de data mining, on cherche à définir le problème
à résoudre.
• Un commercial désire prévoir si un client particulier achètera ses produits.
• Un diffuseur désire constituer des groupes homogènes de personnes qui par-
tagent des informations démographiques similaires et qui achètent des produits
similaires.
• Un webmaster d’un site de commerce électronique souhaite analyser des
similitudes de comportements successifs (exemple : des séquences de clics
similaires. Il désire connaître comment les utilisateurs se déplacent sur le site).
• Le directeur commercial veut mesurer l’attrition des clients et anticiper les
actions correctives.
• Le directeur marketing veut optimiser les coûts d’une campagne de communica-
tion (exemple : cibler les clients potentiels en n’envoyant des prospectus qu’aux
clients susceptibles de répondre).
• Le directeur commercial de Adventureworks désire savoir si la vente d’un
modèle de vélo peut-elle être utilisée pour prédire la vente d’un autre modèle ?
• Un grossiste en produits culturels souhaite identifier les articles qui ont tendance
à être achetés ensemble (analyse de panier, up sell, cross sell).
9.1.2 Préparation des données

Si les données proviennent de sources diverses, il est nécessaire de procéder à
l’alimentation du datawarehouse. C’est le rôle de l’ETL. Ensuite, le processus de data
mining puise ses données dans différentes sources comme les cubes OLAP ou les bases
de données relationnelles via le connecteur OLE DB.
9.1 Méthodologie de création du modèle de data mining 265
À ce stade, la connaissance des données et la signification des rubriques sont

déterminantes pour la construction du schéma de données. Par exemple si on désire
connaître les critères les plus importants dans l’achat d’un vélo tout terrain, on
s’oriente vers les caractéristiques du client et on sélectionne celles qui paraissent
pertinentes dans l’acte d’achat (âge, revenu, nombre d’enfants, sexe, etc.).
9.1.3 Construction du schéma de données

Cette étape consiste à sélectionner les sources de données. Les sources peuvent être
extraites des schémas relationnels ou des cubes OLAP. Avant de créer un modèle,
vous devez sélectionner les données qui serviront à l’apprentissage du modèle.
9.1.4 Création du modèle

Si vous désirez prédire quels prospects seront susceptibles d’acheter vos produits, il
vous faut analyser le comportement des acheteurs actuels. Il s’agit de créer un jeu
de données d’apprentissage qui servira à nourrir le modèle. Un modèle contient des
colonnes d’entrées (critères pertinents), une colonne d’identification (clé) et une ou
plusieurs colonnes prévisibles. Le modèle applique sur le jeu de données un ou plusieurs
algorithmes tels que classification, association ou régression choisis en fonction du but
recherché.
9.1.5 Exploration du modèle

Lorsque le modèle est construit, il convient de l’explorer afin de découvrir les analyses
prédictives effectuées par les algorithmes. Business Intelligence Studio dispose d’outils
d’exploration très visuels. Nous aurons l’occasion de les présenter plus loin dans ce
chapitre.
9.1.6 Validation du modèle

La validation du modèle consiste à lui appliquer un jeu de données de test dans lequel
les valeurs des variables prédictives sont connues et à les comparer aux prédictions
fournies par le modèle. Cette étape permet également de choisir entre plusieurs
algorithmes celui qui correspond le mieux à l’échantillon analysé. Si le modèle créé à
l’étape précédente ne fonctionne pas correctement, il faudra revenir sur la conception
du modèle en redéfinissant le problème, ou en modifiant les critères sélectionnés dans
le jeu d’origine.
9.1.7 Déploiement du modèle

Lorsque le modèle a été validé, il y a lieu de le déployer sur le serveur de production.
On attribuera des rôles autorisant tel ou tel utilisateur à accéder aux modèles déployés.
Lorsque les modèles sont déployés, il est possible de les utiliser lors du processus
ETL ou lors d’une validation de transaction dans la base opérationnelle. Cette dernière
fonctionnalité permet par exemple de savoir avec précision si le prospect récemment
introduit dans la base de données sera ou non un acheteur potentiel.
La mise à jour du modèle doit être réalisée lorsque de nouvelles données viennent
alimenter les bases.
9.2 QUELLES SONT LES TÂCHES DU DATA MINING ?

Classification
La classification consiste à examiner les caractéristiques d’un objet afin de lui attribuer
une classe. Les caractéristiques sont généralement basées sur des valeurs discrètes
(tranche d’âge, genre, marié/célibataire, etc.). La classification est utile dans les cas
suivants :
• attribuer ou non un prêt à un client ;
• établir un diagnostic ;
• accepter ou refuser un retrait dans un distributeur.
Régression
À la différence de la tâche de classification, la régression sert à déterminer une relation
entre deux colonnes continues. La relation se présente sous la forme d’une équation
correspondant à la droite représentant le mieux une série de données. Par exemple, la
droite dans le diagramme suivant est la meilleure représentation linéaire possible des
données. Cette notion est souvent utilisée dans la partie graphique d’Excel.
Figure 9.1 — Graphe présentant une droite de régression
L’équation qui correspond à la droite du diagramme est de type y = ax + b. On la

nomme équation de régression. La variable y représente la variable de sortie, x représente
la variable d’entrée, et a et b sont des coefficients ajustables. Pour chaque point de
données du diagramme, une erreur est associée à la distance entre le point et la droite
de régression. Les coefficients a et b de l’équation de régression ajustent l’angle et
l’emplacement de la droite de régression. L’ajustement des variables a et b peut être
renouvelé jusqu’à ce que la somme des erreurs associées aux points atteigne le plus
petit nombre possible.
9.2 Quelles sont les tâches du data mining ? 267
Segmentation
La segmentation consiste à former des groupes (clusters) homogènes à l’intérieur d’une
population afin de répondre à la question « Quels attributs trouve-t-on en commun
dans chaque groupe ? » La tâche de segmentation précède souvent les autres tâches
afin de construire des groupes sur lesquels on applique des tâches de classification.
Association
L’association examine les comportements de groupes d’individus afin de déterminer
quels liens existent entre eux. Les règles d’association sont souvent liées au secteur de
la distribution à travers ce qu’on appelle l’analyse du panier de la ménagère. Des sites
d’achats en ligne de produits culturels utilisent cette méthode afin de rechercher
les produits qui tendent à être achetés ensemble et proposer en ligne des offres
complémentaires (vente additionnelle).
Un des principaux attraits de la méthode est la clarté des résultats produits. En effet,
le résultat de la méthode est un ensemble de règles d’association dont voici quelques
exemples :
• si un client achète des plantes, alors il achète du terreau ;
• si un client achète du poisson et du citron, alors il achète du vin blanc ;
• si un client achète une télévision, il achètera un magnétoscope dans un an.
Bien souvent, les commerciaux ont déjà intuitivement déterminé des groupes qui
seront probablement confirmés par l’algorithme. Bien que cela puisse rassurer, il est
évident que les décideurs attendent des réponses non triviales et utiles, allant bien
au-delà d’une simple analyse.
Cette méthode est par définition non supervisée car il n’existe pas d’indice a priori
permettant d’effectuer une recherche prédéfinie.
Analyse de séquence
L’algorithme de séquence permet d’analyser un chemin réalisé par le passé afin d’en
déduire la route probable dans le futur.
On applique souvent ce type d’algorithmes à l’analyse des séquences de clics que
les internautes effectuent sur un site web.
L’analyse de séquence sert également à découvrir l’ordre dans lequel un client
ajoute des éléments dans son panier d’achat sur un site de vente en ligne.
Toute société qui offre un service d’achat en ligne est intéressée par cette démarche.
En effet, pour acheter, les clients doivent se connecter au site. La société collecte
des informations sur les pages que les internautes visitent et l’ordre dans lequel ils
consultent les pages. Il analyse également quelles sont les pages les plus consultées
avant l’acte d’achat d’un produit.
9.3 CRÉER LE MODÈLE D’UNE CAMPAGNE CIBLÉE
Afin d’offrir au lecteur une vue globale des outils de data mining, nous pensons utile
de lui présenter les étapes de la méthode et, pour chacune d’elles, les outils fournis par
Business Intelligence Studio.
Nous allons tour à tour construire trois types d’application. Nous commencerons
par un premier scénario de publipostage ciblé qui permettra de présenter les algorithmes
de classification. Nous présenterons également des scénarios de prévision, d’analyse
de panier et enfin de séquence clustering.
Ces exemples peuvent être réalisés par le lecteur s’il dispose de SQL Server
2008 version standard ou Enterprise avec Analysis Services, et les exemples modèles
AdventureWorks.
Le lecteur trouvera tous les outils nécessaires sur le site de l’auteur à l’adresse
www.buroformatic.com.
La création d’un modèle d’exploration de données commence par la création d’un
projet Analysis Services dans lequel nous créerons les sources de données en lien avec
les bases relationnelles ou OLAP.
Nous allons créer un nouveau projet Analysis Services que nous nommons
AdventureWorks DataMining.
Figure 9.2 — Création du projet data mining via Analysis Services

9.3 Créer le modèle d’une campagne ciblée 269
9.3.1 Créer la source des données

La source des données est une connexion qui identifie le serveur et la base de données
dans laquelle résident les données à analyser.
• Choisissez OLE DB natif\SQL Native Client comme fournisseur d’accès.
• Serveur Localhost et utilisez l’authentification Windows.
• Sélectionnez la base de données dimensionnelle (datawarehouse) Adventure-
WorksDW.
9.3.2 Créer la vue de source des données

Faites un clic droit sur Vue des sources de données puis Nouvelle vue des sources
de données, puis sélectionnez la source de données opérationnelle AdventureWorks
créée à l’étape précédente.
Sélectionnez la vue dbo.vTargetMail dans laquelle se trouvent les données
nécessaires à l’analyse (figure 9.3).
Cette requête détermine quel client/prospect est acheteur ou non de produits
« bikes ». On calcule la somme des occurrences des acheteurs de « bikes ». L’algorithme
attribue la valeur 1 si le nombre de ventes est >=1 et 0 dans le contraire.
Figure 9.3 — Voici la vue vTargetMail
Cette vue permet de déterminer l’âge du client au moment de l’extraction grâce à

la fonction Style caratère : CodeDansTexte non pris en charge
DateDiff(yy, Style caratère : CodeDansTexte non pris en charge
c.[BirthDate], Style caratère : CodeDansTexte non pris en charge
GetDate()) qui calcule l’écart en années entre la date du jour et la date de naissance.
La vue constitue également des tranches de revenu selon les gains annuels.
Yearly Income est déterminé comme Low, Moderate ou High selon que le revenu
annuel est inférieur à 40 000, compris entre 40 000 et 60 000 ou supérieur à 60 000.
Voici le résultat de la vue finale (tableau 9.1).
270
Tableau 9.1 — Extrait de la vue permettant de nourrir le modèle d’exploration des données
English- Model Customer- Region Age Income- Calendar- Fiscal Month Order- Line- Quan- Amount
Product Key Group Year Year Number Number tity
Bikes Mountain- 11003 Pacific 38 High 2001 2002 7 SO43701 1 1 3 399,9900
100
Bikes Road-650 14501 North 68 High 2001 2002 7 SO43700 1 1 699,0982
America
Bikes Road-150 21768 North 59 High 2001 2002 7 SO43697 1 1 3 578,2700
America
Bikes Mountain- 25863 North 59 Moderate 2001 2002 7 SO43699 1 1 3 399,9900
100 America
Bikes Mountain- 28389 Europe 41 Low 2001 2002 7 SO43698 1 1 3 399,9900
100
Bikes Mountain- 11005 Pacific 40 High 2001 2002 7 SO43704 1 1 3 374,9900
100
Bikes Mountain- 11011 Pacific 42 Moderate 2001 2002 7 SO43705 1 1 3 399,9900
100
Chapitre 9. Le data mining
Les données sources sont maintenant définies. Nous allons construire le modèle de
publipostage ciblé.
9.3.3 Créer le modèle

Le besoin métier s’exprime selon ces termes : l’équipe marketing désireuse d’augmenter
ses ventes souhaite communiquer au moyen d’une campagne de publipostage. Les coûts
d’une telle campagne étant lourds, le service marketing souhaite connaître les critères
qui caractérisent les acheteurs de vélos afin de déduire parmi un lot de prospects ceux
qui sont le plus susceptibles d’acheter.
Il s’agit d’un problème de classification pour lequel les algorithmes Naïve Bayes,
Decision tree et Clusters sont particulièrement adaptés.
Figure 9.4 — L’explorateur de solutions permet de créer un modèle d’exploration
Nous devons commencer par créer une nouvelle structure d’exploration de données
à partir de la base de données relationnelle. Un clic droit sur Structures d’exploration
de données permet de lancer l’assistant de création du modèle. Il serait également
possible d’établir un modèle basé sur un cube OLAP.
Nous choisissons tout d’abord l’algorithme MDT (Microsoft Decision Trees).
Figure 9.5 — Un choix de neuf algorithmes est proposé

La vue des sources de données est la requête vTargetMail.
Figure 9.6 — Spécifier les types de tables. Ici vTargetMail représente le fichier des cas à analyser
Le formulaire des données d’apprentissage définit les clés et les colonnes à prévoir.
Figure 9.7 — Option Customer Key
La clé est déterminée grâce au champ CustomerKey, lui-même défini en tant que
clé dans la source. Le champ à prévoir est BikeBuyer. En ce qui concerne les colonnes
en entrée, nous allons demander à l’assistant de nous suggérer les champs les plus
susceptibles d’entrer dans le processus prédictif.
Le bouton Suggérer permet de lister ces champs.
Figure 9.8 — Formulaire de suggestion des colonnes

susceptibles d’entrer dans le processus prédictif
L’assistant effectue un choix parmi les types de données et les types de contenus. Il
est conseillé de vérifier les choix effectués par l’assistant. Complétez la sélection des
colonnes pertinentes en cochant les entrées désirées.
Donnons le nom Publipostage Ciblé à la structure d’exploration puis Decision_Tree
au modèle d’exploration.
Avant de traiter le modèle d’exploration, nous ajouterons deux modèles complé-
mentaires respectivement basés sur les algorithmes Microsoft Clustering et Microsoft
Naïve Bayes.
L’ajout s’effectue sans difficulté puisque le modèle de base (Decision Tree) fournit
les éléments aux deux autres modèles.
Figure 9.9 — Formulaire présentant les types de contenu (Continu, Discret ou Clé) et les types
de données des colonnes sélectionnées
Figure 9.10 — Terminer en attribuant un nom à la structure d’exploration

Figure 9.11 — Ajout d’un nouveau modèle basé sur l’algorithme Naïve Bayes
Figure 9.12 — L’onglet Modèles d’exploration affiche les trois modèles qui participent à l’analyse
du cas « mailing ciblé »
Le modèle Naïve Bayes ne traite que des données discrètes. Il ignore ainsi les
données comme le revenu annuel ou l’âge du client qui sont considérés comme des
variables continues.
Nous procédons ensuite au déploiement des modèles et à leur traitement.
Naviguer dans le modèle Decision Tree

La navigation dans les modèles s’effectue grâce à l’onglet visionneuse de modèle
d’exploration.
La visionneuse offre le choix entre les trois modèles (Decision Tree, Naïve Bayes
ou Clusters). Dans la liste déroulante nous choisissons le modèle Decision_Tree.
L’arborescence propose une liste des variables à prévoir. Ici, une seule variable est à
rechercher : Bike Buyer. Cette variable prend la valeur 1 lorsque le client a acheté
au moins un vélo et 0 dans le cas contraire. Afin de suivre le mode de répartition des
acheteurs, nous sélectionnons la valeur 1. L’arrière-plan de chaque nœud se teinte en
fonction de la fréquence du cas.
Dans l’arborescence du modèle, on observe quels sont les facteurs les plus impor-
tants qui déterminent les acheteurs. On observe que l’âge de l’acheteur vient en
première position suivi du nombre d’enfant au foyer. Viennent ensuite des critères de
revenu puis de région.
Chaque nœud affiche une trame de couleur plus ou moins foncée. Plus le critère
recherché (ici les acheteurs de vélos) est important, plus foncée sera la couleur du
fond du nœud.
Le nœud racine est toujours le plus sombre.
Portons notre attention sur le nœud racine. La légende d’exploration nous indique
que 18 484 cas ont été recensés, se répartissant en 9 132 cas représentant 49,39 %
d’acheteurs et 9 352 cas de non-acheteurs représentant 50,58 %. La barre graphique
répartit les proportions entre les acheteurs et le non acheteurs matérialisée par des
couleurs différentes.
Figure 9.13 — La visionneuse de modèle. Ici, modèle d’exploration Decision_Tree
Figure 9.14 — Légende d’exploration du nœud sélectionné
En suivant l’arborescence selon les nœuds les plus sombres, on observe que la
population des 39-53 ans est celle qui achète le plus de vélos (3 934 acheteurs). Parmi
cette population, on observe que les acheteurs sont ceux qui n’ont pas d’enfant au
foyer, qui ont un revenu supérieur à 26 000 € et qui n’habitent pas en Amérique du
Nord. Il est possible d’extraire cette population puis de copier la liste dans Excel ou
Word afin d’effectuer un publipostage.
Figure 9.15 — Fenêtre d’extraction d’un nœud. On observe que la colonne Bike Buyer
comprend acheteurs et non-acheteurs
Effectuez un filtrage sur Bike Buyer = 1 pour obtenir uniquement les acheteurs de
vélos.
Comprendre le réseau de dépendance.

Lorsque les critères sont nombreux, il n’est pas toujours aisé de comprendre les facteurs
qui participent à la détermination de la variable à prévoir. L’onglet de réseau de
dépendance permet de sélectionner un nœud puis à l’aide des liens qui pointent vers
ce nœud d’en connaître les attributs qui le déterminent. La réglette verticale sur le
côté droit permet de faire apparaître progressivement ces liens (du poids le plus fort
au poids le plus faible).
Figure 9.16 — Le réseau de dépendance montre les liens qui ont un fort degré de dépendance
avec le critère Bike Buyer
Dans notre cas, il est aisé de constater que les liens les plus forts sont l’âge, le
nombre d’enfants au foyer, le revenu, le nombre de voitures possédées et la région. Ces
liens sont apparus dans l’ordre précité.
Naviguer dans le modèle Naïve Bayes

Le choix du navigateur Naïve Bayes permet d’observer le même cas d’une façon
différente. Dans ce modèle, les variables continues ont été exclues (âge et revenu).
Chaque attribut génère une ligne avec une colonne représentant les différents
états de l’attribut, puis autant de colonnes qu’il y a d’états possibles pour la valeur à
prévoir (Bike Buyers = 1 ou 0).
Figure 9.17 — Le modèle Naives Bayes présente uniquement les variables discrètes
À l’intersection d’une ligne et d’une colonne, on peut observer la distribution.
Figure 9.18 — Légende d’exploration des données. La figure 9.18 montre la distribution des
acheteurs en fonction du nombre d’enfants au foyer (62,7 % des acquéreurs de vélo n’ont pas
d’enfants)
L’onglet Caractéristique d’attribut se présente comme suit dans la figure 9.19.
Figure 9.19 — Onglet Caractéristiques d’attribut
Cet onglet permet de sélectionner un attribut (acheteur de vélo) et d’établir des

liens décroissants avec d’autres attributs.
Du tableau représenté dans la figure 9.19, il est possible de déduire que les acheteurs
de vélos ont une forte probabilité de ne pas avoir d’enfants, de ne pas être de la région
Amérique du Nord, de niveau bachelier, etc.
On observe que l’absence des critères d’âge et de revenu dans l’analyse Naïve
Bayses entraîne des résultats différents de ceux de l’algorithme d’arbre de décision.
Il peut être intéressant de comparer deux groupes côte à côte. Si l’on désire
comparer les acheteurs et les non-acheteurs, nous obtenons le graphe de la figure 9.20.
Figure 9.20 — L’onglet Discrimination d’attribut permet une comparaison deux à deux
On peut déduire du tableau qui précède que les acheteurs de vélos ne possèdent pas
d’auto alors que ceux qui n’achètent pas de vélos possèdent deux autos. Les acheteurs
de vélos ont un enfant et habitent la région Pacifique, etc. Plusieurs attributs peuvent
se retrouver avec des poids relatifs différents.
Naviguer dans le modèle clusters

Le diagramme cluster permet d’établir des relations entre des groupes homogènes. Les
lignes qui relient les clusters sont plus denses si les liens entre clusters sont étroits. Le
curseur à gauche du diagramme permet d’appliquer un filtre afin d’occulter les liens les
moins forts (figure 9.21).
Figure 9.21 — Le diagramme de cluster permet de réaliser des groupes homogènes
Dans le diagramme ci-après, le cluster 6 (en bas) contient la plus grande quantité
d’acheteurs de vélos. Un lien avec le cluster 1 apparaît comme très étroit.
Évaluer le modèle
Maintenant que nous avons mis en place nos trois modèles, nous devons les évaluer
afin de déterminer lequel est le meilleur pour prédire le profil d’acheteur. Pour cela,
nous allons appliquer successivement nos modèles sur une table de cas dont les résultats
sont déjà connus. Le but étant de comparer la capacité de prédiction de chaque
algorithme avec la réalité.
• Sélectionner une table de cas (différente de la table qui a servi à modéliser).
Figure 9.22 — Graphique d’analyse de précision pour la valeur 1 = acheteurs
• Effectuer le mappage des colonnes entre la structure d’exploration et les champs

de la table de cas. Le mappage s’effectue naturellement lorsque les noms de
colonnes sont identiques.
• Le filtrage des lignes d’entrée permet d’affiner la recherche dans la table de cas.
• Sélectionnez les modèles qui seront inclus dans le graphique.
• Sélectionnez la ou les colonnes prévisibles (ne sont proposées que les colonnes
dont le type est Style caratère : CodeDansTexte non pris en charge
Predict ou Style caratère : CodeDansTexte non pris en charge
Predict Only).
• Sélectionnez une valeur prévisible afin de montrer l’efficacité du modèle. Si
vous ne précisez pas de valeur prévisible, le graphique montre le degré de précision
du modèle.
Le graphique de courbe d’élévation permet de comparer la précision des trois

algorithmes.
Figure 9.23 — Graphique de courbes d’élévation comparant les trois algorithmes
La requête de prévision s’exécute sur le serveur. La courbe idéale est matérialisée

par la droite de gauche. Les algorithmes matérialisés par les trois courbes peuvent ainsi
être comparés entre eux :
• L’algorithme Decision Tree permet une probabilité de prévision de 67,88 %
• L’algorithme Naïve Bayes permet une probabilité de prévision de 65,48 %.
• L’algorithme Cluster permet une probabilité de prévision de 54,06 %.
Créer le graphique des bénéfices

Ajoutons une dimension financière à notre modèle en cherchant à connaître le profit
généré par chacun des algorithmes.
Figure 9.24 — Formulaire permettant de recueillir les caractéristiques financières et d’estimation

Prenons comme hypothèse les éléments suivants :

• cible de clients : 5 000 ;
• coût fixe de la campagne (frais de conception et d’impression) : 10 000 €;
• coût variable de 5 € par client (expédition) ;
• le service marketing estime à 50 € par personne par vente réussie.
Figure 9.25 — Graphique des bénéfices prévisibles en fonction du modèle
L’axe Y du graphique représente les bénéfices, tandis que l’axe X représente le

pourcentage de la population contactée. La meilleure performance financière est
donnée grâce à l’algorithme Decision Tree.
Un graphique des bénéfices montre une augmentation des bénéfices jusqu’à un
certain point. Ensuite, plus le nombre d’individus contactés augmente moins les
bénéfices augmentent.
Le graphique des bénéfices contient une ligne verticale grise et positionnée par
défaut à 50 %. Cette barre peut être ajustée en cliquant dans le graphique. Le calcul
des bénéfices est recalculé immédiatement.
Si vous sélectionnez le point des bénéfices maximaux dans le graphique en utilisant
la ligne grise, vous observez une valeur qui détermine un seuil de probabilité lié au fait
de contacter un client.
Figure 9.26 — Bénéfices maximaux avec un remplissage de 88 %
Dans l’exemple ci-dessus, le sommet de la courbe des bénéfices se trouve à 88 %

de remplissage pour une probabilité de prévision de 13,77 %. Cela indique que pour
réaliser des bénéfices maximaux, vous devez contacter uniquement les clients dont la
réponse est prévue avec une probabilité de 13,77 % ou plus.
Comment sélectionner la liste des clients potentiels dans un jeu de données ?

Lorsque nous avons choisi un modèle d’exploration, il convient de créer une requête
DMX (Data Mining Extensions). Cette requête de prévision permet de sélectionner
dans une table de cas une liste de clients potentiels.
Figure 9.27 — Mappage des données du modèle de prévisions avec les champs de la table
d’entrée
Dans l’exemple suivant, la table à examiner est ProspectiveBuyer.

La première source de la prévision repose sur le modèle Decision_Tree avec le

champ prévisible Bike Buyer.
La seconde source fournit l’identifiant unique du prospect ProspectAlternateKey.
La troisième source PredictProbability fournit le degré de probabilité.
Voici la requête DMX générée par l’assistant :
SELECT
[TM Decision Tree].[Bike Buyer],
t.[ProspectAlternateKey],
PredictProbability([bike buyer])
From
[TM Decision Tree]
PREDICTION JOIN
OPENQUERY([Adventure Works DW],
’SELECT
[ProspectAlternateKey],
[MaritalStatus],
[Gender],
[YearlyIncome],
[TotalChildren],
[NumberChildrenAtHome],
[Education],
[Occupation],
[HouseOwnerFlag],
[NumberCarsOwned]
FROM
[dbo].[ProspectiveBuyer]
’) AS t
ON
[TM Decision Tree].[Marital Status] = t.[MaritalStatus] AND
[TM Decision Tree].[Gender] = t.[Gender] AND
[TM Decision Tree].[Yearly Income] = t.[YearlyIncome] AND
[TM Decision Tree].[Total Children] = t.[TotalChildren] AND
[TM Decision Tree].[Number Children At Home] = t.[NumberChildrenAtHome] AND
[TM Decision Tree].[Education] = t.[Education] AND
[TM Decision Tree].[Occupation] = t.[Occupation] AND
[TM Decision Tree].[House Owner Flag] = t.[HouseOwnerFlag] AND
[TM Decision Tree].[Number Cars Owned] = t.[NumberCarsOwned]
Le résultat de la requête peut être envoyé dans Excel puis traité en ne sélectionnant
que les acheteurs potentiels c’est-à-dire Bike Buyer = 1.
Le code ProspectAlternate identifie précisément le client. L’expression permet de
donner la précision de la prédiction.
Dans Excel, nous trions la colonne Expression (Probabilité) en mode décroissant.
Trions également la colonne Bike Buyer. Nous en déduisons les 1 041 acheteurs
potentiels sur une population de 2 059.
Figure 9.28 — Copier dans Excel la liste extraite
Notre publipostage portera sur tout ou partie de cette population d’acheteurs (Bike
Buyers = 1).
9.4 CONCLUSION
Ce chapitre nous a montré les nombreux assistants fournis par Analysis Services. Nous
espérons avoir convaincu le lecteur que le data mining n’est pas réservé aux grandes
entreprises qui disposent d’un large volume de données.
Il n’est pas non plus indispensable d’être statisticien pour exploiter ces nouvelles
possibilités. Les entreprises qui se donneront la peine d’exploiter les nombreuses
facettes de cet outil découvriront de nouvelles pistes jusque-là encore inexplorées.
10
Reporting Services
10.1 QU’EST-CE QUE REPORTING SERVICES ?
Lors de nos formations, nous aimons présenter la phase de reporting comme la dernière
et la plus importante des étapes de ce long et difficile processus de collecte, stockage,
transformation et manipulation des données. Cette dernière étape représente celle
qui aux yeux des utilisateurs a le plus de valeur car elle permet de donner du sens
aux montagnes de données qui s’accumulent chaque jour. Les rapports jouent un rôle
essentiel dans la compréhension des clients, du marché et plus globalement de la
performance de l’entreprise.
Dans sa troisième version, Reporting Services 2008 fournit une plate-forme de
reporting sophistiquée offrant aux managers des outils d’analyse de volumes importants
de données avec une grande efficacité. La plate-forme native de Reporting Services
permet de partager des rapports avec le personnel, les clients et les partenaires de
l’entreprise.
Ce chapitre a pour ambition de présenter au lecteur un panorama assez large des
fonctionnalités de Reporting services 2008 en pointant les améliorations de la dernière
version par rapport à la version 2005. De tous les modules de la Business Intelligence,
SSRS 2008 est de loin celui qui a subi la plus forte évolution. L’intégration native de
la technologie Dundas (graphes, jauges et cartes) et une interface de développement
nouvelle avec l’introduction d’un nouveau concept (tableau matriciel) permet à
Reporting Services de rattraper son retard par rapport aux outils concurrents.
290 Chapitre 10. Reporting Services
Figure 10.1 — Positionnement de Reporting Services dans la chaîne décisionnelle
10.1.1 À quoi sert Reporting Services ?

Microsoft SQL Server 2008 Reporting Services (SSRS) fournit une gamme d’outils
et de services prêts à l’emploi permettant de créer, déployer et gérer des rapports
d’entreprise. Il offre au développeur des fonctions de programmation visant à étendre
et personnaliser les fonctionnalités de création de rapports.
SQL Server 2008 Reporting Services (SSRS) est une plate-forme serveur de
rapports qui fournit des fonctionnalités de création de rapports pour différentes sources
de données. Les outils Reporting Services fonctionnent au sein de l’environnement
Microsoft Visual Studio (BIDS) et sont totalement intégrés aux outils et composants
de SQL Server 2008.
Reporting Services, permet de créer des rapports de type interactif, tabulaire,
graphique ou libre à partir de sources de données XML, relationnelles (SQL) et
multidimensionnelles (OLAP). Il est possible de publier des rapports, de planifier le
traitement de rapports ou d’accéder à des rapports à la demande.
Grâce à Report Builder 1.0 et Report Builder 2.0 (nouvel outil fourni en complé-
ment de SQL Server 2008), Reporting Services permet de créer des rapports ad hoc
basés sur des modèles sémantiques prédéfinis, et d’explorer des données de manière
interactive dans le modèle.
Les personnes autorisées, pourront sélectionner divers formats d’affichage, exporter
des rapports vers d’autres applications et s’abonner à des rapports publiés.
Les rapports créés via SSRS 2008 peuvent être consultés par le biais d’une
connexion Internet ou en tant qu’application Microsoft Windows ou site SharePoint.
Les entreprises peuvent en effet concevoir des extranets sécurisés à destination de
leurs clients et fournisseurs.
Voici quelques scénarios d’utilisation de Reporting Services.
10.1 Qu’est-ce que Reporting Services ? 291
Rapports internes
• Rapports « Maison » (vente, finance, DRH).
• Administrables, accessibles via un portail ou intégrés aux solutions d’entreprise.
Rapports embarqués
• Afficher des rapports dans n’importe quelle application d’entreprise (ERP, CRM)
ou analytique.
• Architecture extensible et flexible.
Rapports collaboratifs
• B2B, B2C, échanges inter ou intra-entreprises, etc.
Rapports externes
• Publier des rapports via extranet, Internet.
• Isolation de données, sécurité extensible.
10.1.2 Fonctionnalités de Reporting Services

SSRS gère de manière centralisée le cycle de vie d’un rapport depuis sa création
jusqu’à sa diffusion. Il utilise une architecture multiniveau illustrée dans la figure 10.2.
Les principaux composants de SSRS sont donnés dans le tableau 10.1.
Tableau 10.1 — Composants de SSRS
Base de données MS SQL Server (2000 et 2005, 2008) MS

et sources de données Analysis Services (les versions 2008 et 2000
ne peuvent résider sur un même serveur).
Toutes sources de données conformes
au standard OLE DB, ODBC.
Outils de création de rapports Générateur de rapports grâce à Visual Studio
pour Business. Intelligence.
Langage de définition de rapports basé
sur le langage XML.
De nombreux outils tiers permettent
de développer des rapports au format RDL.
Les formats de rapports Format libre.
Format tabulaire.
Format matriciel (Ces trois formats sont regroupés
sous le nom de tableau matriciel (Tablix))).
Graphique de données.
Filtrage dynamique lors de l’exécution.
Regroupement en sous-totaux et totaux généraux.
Tris ascendant/descendant.
Rapports liés activés par lien hypertexte
avec passage de paramètres.
Exécution de rapports Plusieurs formats de restitution (PDF, TIFF, CSV,
Excel, XML, Archive web, Word).
Planification de l’envoi des rapports à la demande
de l’utilisateur ou de l’administrateur.
292
Navigateur Administration Application Report Builder
Sources de données Formats

(SQL, OLE DB, ODBC, URL WMI Web Service (HTML, Excel,
Oracle, clients) PDF, Autres)
Report Server
Report Processing
Interrogation
Formatage
des données
Sécurité Exportation
Services Sécurité SQL Server Catalog Cibles

(NT, Passeport, (Courrier, Fichier,
Autre) Autres)
Figure 10.2 — Architecture de Reporting Services (source : Microsoft)

Chapitre 10. Reporting Services
La gestion des rapports

Reporting Services dispose d’une interface web permettant d’effectuer des tâches de
gestion de rapports. Le tableau 10.2 recense les différentes tâches.
Tableau 10.2 — Tâches de gestion de rapports
Gestion des sources de données Connexions aux serveurs avec authentification.

Gestion des paramètres Valeurs par défaut proposées
des rapports Invites avec listes déroulantes.
Planification de l’exécution SQL Server Agent doit être installé
des rapports et en service.
Mode d’exécution des rapports Direct.
Mise en cache. Capture instantanée.
Historique des rapports exécutés conservé
pour consultation ultérieure.
Sécurité Utilisateurs et groupes d’utilisateurs.
Application des rôles niveau système et niveau
rapports.
Report Server Web Application Définir la sécurité.
Planifier l’exécution et la remise de rapports.
Effectuer le suivi des rapports.
API de service web.
Le rendu des rapports Format HTML et XML.
Format d’impression PDF et TIFF.
Format Excel, Word, CSV.
Autres formats via API ouvertes.
Options de remise Exécutions planifiées.
Exécutions pilotées par événements.
Abonnements.
Rapport reçu ou lien avec le serveur.
Abonnements pilotés par les données
(envoi de rapports personnalisés
à une liste de destinataires).
Le serveur de rapports (Report Server) contient un moteur qui interprète la

définition des rapports, exécute les requêtes et restitue les rapports. Il permet également
de planifier l’exécution et l’envoi de rapports en mode sécurisé. Le serveur de rapports
héberge un service web permettant à des applications externes de communiquer avec
le moteur de rapports.
Le gestionnaire de rapports se présente sous la forme d’un portail web fourni avec
Reporting Services. Le gestionnaire de rapport est destiné aussi bien à l’utilisateur qui
désire exécuter un rapport qu’à l’administrateur désireux de mettre en place la sécurité
ou la planification de distribution des rapports.
Figure 10.3 — Le gestionnaire de rapports
BIDS Report Designer (concepteur de rapport) est hébergé dans l’interface com-
mune de Visual Studio BI. Cet outil est destiné aux développeurs et utilisateurs
avancés. Il s’agit de la version la plus complète de Reporting services.
Report Builder 1.0 (Générateur de rapports ad hoc) est un outil client qui permet
aux utilisateurs non-programmeurs de définir et déployer des rapports « ad hoc » sans
aucune connaissance de SQL Server. L’utilisation de Report Builder est conditionnée
par la mise à disposition d’un modèle sémantique (proche de l’Univers de Business
Objects). Ce modèle sémantique est créé à l’aide de Visual Studio (BIDS).
Report Builder 1.0 stocke les définitions de rapports dans la base de données Report
Server. Ces rapports peuvent ensuite être modifiés, complétés et publiés dans le portail
Web par l’utilisateur lui-même. Cette version n’a pas été modifiée depuis SQL Server
2005.
Report Builder 2.0 (Générateur de rapports ad hoc). Cette version a pour
vocation de remplacer à terme Report Builder 1.0. Cet outil s’adresse à des utilisateurs
avancés. Visuellement cet outil se rapproche de l’interface Office 2007 avec la mise
à disposition du ruban. L’avantage de cette version réside dans le fait qu’elle est
totalement interchangeable avec Report Designer 2008. Un rapport développé avec
BIDS Report Designer 2008 peut être repris par Report Builder 2.0 et réciproquement.
Seules les interfaces diffèrent.
Figure 10.4 — L’interface du nouvel outil Report Builder 2.0
Le ruban de Report Builder 2.0 apporte des fonctionnalités nouvelles telles que les
Jauges et le tableau matriciel imbriqué (Tablix).
Figure 10.5 — La boite à outils sous forme de ruban
Visual Studio Report Designer. Cet outil est réservé aux développeurs .NET. Il
inclut les fonctionnalités de base de Report Designer. Cet outil est distribué au travers
du contrôle Report Viewer inclus dans Visual Studio 2005/2008.
10.2 ANATOMIE D’UN RAPPORT
Afin d’illustrer les différents concepts abordés dans le paragraphe précédent, nous
allons utiliser le rapport de ventes créé pour la société AdventureWorks, puis nous le
publierons sur le serveur de rapports. Enfin, nous le consulterons via le Web.
Le rapport final est le suivant :
Figure 10.6 — Rapport final
Chaque zone du tableau et des graphiques étant cliquable il est possible d’affiner
l’observation en effectuant un focus sur tel ou tel résultat.
Dans notre exemple, un simple clic sur le nom d’un employé permet d’effectuer un
appel à un rapport lié avec passage automatique de paramètres.
10.2 Anatomie d’un rapport 297
Figure 10.7 — Rapport lié auquel le contexte du rapport appelant a été fourni
(ici le nom du commercial)
Afin de comprendre le mode de fonctionnement d’un rapport il est nécessaire

d’introduire la notion de région de données. Une région de données identifie des
tables ou des graphes eux-mêmes s’appuyant sur des datasets.
Dans le principe, une région de données lit un enregistrement contenu dans un jeu
d’enregistrements ( dataset), remplit une portion du rapport en utilisant les données
de l’enregistrement, puis lit l’enregistrement suivant. Ce processus est répété autant
de fois qu’il y a d’enregistrements dans le dataset.
Un rapport peut être constitué de plusieurs types de régions :
• La table permet de lister le contenu des enregistrements selon un format
tabulaire. La table est composée d’un nombre de colonnes fixe et d’un nombre
d’enregistrements variable. Les lignes peuvent être regroupées afin de composer
des lignes de totalisation ou sous-totalisation.
• Le tableau croisé ou matriciel est composé d’un nombre variable de lignes et de
colonnes. Il s’apparente au tableau croisé dynamique. Les lignes et colonnes ne
peuvent être interverties lors de l’exploration. Un drill down permet d’afficher
les totaux de ligne puis de déplier les lignes qui composent ce total afin d’en
connaître le détail.
• La liste permet de créer une section sur une ou plusieurs pages pour chaque
enregistrement du jeu de données.
• Le graphe permet de représenter sous forme visuelle les données relatives à
chaque enregistrement.
Dans SSRS 2008 les types table, liste et matrice sont considérés comme un unique objet
de type tablix.
Figure 10.8 — La boîte à outil de SSRS 2008 fait apparaître les différents types de région.
Observez également le nouvel outil Jauge
Figure 10.9 — La fenêtre des données du rapport

La fenêtre Données du Rapport permet d’utiliser les objets suivants :

1. Les champs prédéfinis tels que l’heure d’exécution du rapport ou la numérota-
tion des pages.
2. Les paramètres communs à l’ensemble du rapport. Ces paramètres permettent
d’effectuer des filtrages sur les datasets sous-jacents. Ce mécanisme de partage
permet également de synchroniser les différentes régions du rapport.
3. Les images intégrées au rapport.
4. Les sources de données (adventureworks2008) avec les dataset associés :
– a. Microsoft SQL Server
– b. OLE DB
– c. MS Analysis Services (Cubes OLAP)
– d. Oracle
– e. ODBC (Access/Excel etc.)
– f. XML
– g. Report Server Model (Modèle sémantique créé par Report Designer)
– h. SAP NetWeaver BI
La création de rapport s’effectue dans BIDS. À l’instar des autres modules, un

assistant guide pas à pas le développeur de rapport. Il suffit ensuite de revenir sur la
conception libre du rapport afin d’apporter les modifications souhaitées.
La création d’un rapport débute toujours par la définition de la source de données.
Figure 10.10 — Fenêtre des propriétés du dataset
Le concepteur de requête permet une saisie assistée de la requête SQL.

Figure 10.11 — Le concepteur de requête offre une assistance à la construction des requêtes
Chaque paramètre de la requête fait à son tour l’objet de définition de propriétés :

1. Nom du paramètre
2. L’invite
3. Le type de données
4. Valeur simple ou à choix multiple
5. Visible ou masqué
Les valeurs disponibles et les valeurs par défaut des paramètres peuvent être :
1. spécifiées manuellement ou ;
2. obtenues à partir de requêtes.
Figure 10.12 — Les objets de la zone de conception
À l’aide de la boîte à outils le concepteur du rapport déplace ses objets dans la

surface de dessin.
Figure 10.13 — Fenêtre des propriétés du tableau matriciel (Tablix)
Les options de sauts de page, de présentation des en-têtes de lignes et en-têtes de

colonnes peuvent être complétées pour chaque région de données.
Figure 10.14 — Formulaire permettant d’attribuer des propriétés à chaque regroupement de

ligne du tableau
La notion de tri permet de définir l’ordre d’affichage des groupes.

La visibilité permet de mettre en place le mécanisme de drill down/drill up.
Les filtres s’appliquent au-dessus de la requête sous-jacente du dataset. Le méca-
nisme des filtres peut être pertinent lorsque des requêtes SQL s’appuient sur une
importante volumétrie. Les filtres permettent ainsi de sélectionner des données
précises alors que les données de la requête globale sont en cache.
Les variables fournissent un mécanisme permettant le calcul d’expression complexe
lors de l’exécution d’un rapport.
Exemple =Sum(Fields !SalesAmount.Value * Variables !Rate.Value)
Si le champ SalesAmount est additif la même expression peut être réécrite de la
façon suivante :
=Sum(Fields !SalesAmount.Value) * Variables !Rate.Value
L’innovation du contrôle Tablix réside dans la possibilité d’ajouter des groupes

adjacents en lignes ou en colonnes.
10.2 Anatomie d’un rapport
Figure 10.15 — Aperçu d’un rapport de type Matriciel (Tablix)

303
Dans la figure 10.15 on observe deux axes différents en colonnes. (Par année et
par Territoire).
Figure 10.16 — Onglet de conception de rapport matriciel
Dans la figure 10.16 on observe les deux groupes adjacents de colonnes

(Année/Trimestre et Région/Pays). Ces deux groupes partagent le même groupe
hiérarchique de lignes (Catégorie de produit/sous-catégorie/Produit).
Figure 10.17 — Les groupes de lignes partagent les groupes de colonnes
Il est possible d’ajouter autant de groupes adjacents que souhaité aussi bien en
lignes qu’en colonnes.
Le champ Growth en % permet de calculer un taux de croissance d’un trimestre
sur l’autre.
Voici la formule à saisir :
=Code.GetGrowth(Sum(Fields!InternetSalesAmount.Value),
Previous(Sum(Fields!InternetSalesAmount.Value), "CalendarQuarter"))
On utilise la fonction Previous basée sur l’étendue (scope) CalendarQuarter. Cela
permet de calculer une progression d’un trimestre à l’autre.
Le code appelé est stocké dans le rapport de la figure 10.18.
Figure 10.18
Voici le code :
Public Function GetGrowth(ByVal CurrentValue, ByVal PreviousValue) As Object

If IsNothing(PreviousValue) OR IsNothing(CurrentValue) Then
Return Nothing
Else if PreviousValue = 0 OR CurrentValue = 0 Then
Return Nothing
Else
Return (CurrentValue - PreviousValue) / CurrentValue
End If
End Function
Les nouveaux objets graphiques dans Reporting Services 2008

En mai 2007 Microsoft a fait l’acquisition de la technologie Dundas permettant
ainsi à Reporting Services 2008 de disposer de contrôles graphiques avancés. Cette
technologie permet de visualiser des graphiques sophistiqués agrémentés de formules
statistiques.
Dans SSRS 2008 sont nativement intégrés :

• Les graphiques avancés.
Figure 10.19 — Graphiques avancés
• Les jauges qui ajoutent un tableau de bord et des fonctionnalités associées aux
rapports.
Figure 10.20 — Palette des jauges Radiales et linéaires
• Le calendrier, qui intègre des éléments de visualisation liés aux dates

• La carte qui insère des fonctionnalités de visualisation de cartes.
10.3 La gestion des rapports 307
Figure 10.21 — La technologie Dundas est définitivement intégrée à SSRS 2008
10.3 LA GESTION DES RAPPORTS
Lorsque les rapports sont publiés sur le serveur de rapports, il est indispensable de
procéder à un certain nombre de réglages supplémentaires. Généralement, les rapports
font l’objet d’une mise en sécurité visant à permettre la consultation uniquement
par les personnes autorisées. Les utilisateurs, de plus en plus exigeants, souhaitent
obtenir sans délai les informations sur leur activité dans l’entreprise. Ils désirent
également recevoir périodiquement leurs informations métier sous forme électronique
ou exécuter eux-mêmes les traitements selon leurs besoins.
Les utilisateurs et administrateurs accèdent au gestionnaire de rapports à l’adresse
suivante : http://localhost/reports.
Le gestionnaire de rapports met à disposition de l’administrateur un certain nombre
d’outils permettant de répondre à ces contraintes. Passons-les en revue.
10.3.1 La sécurité
Reporting Services met en place plusieurs niveaux de sécurité.
• Le gestionnaire de rapports web requiert une authentification Windows.
• Les utilisateurs autorisés à accéder au gestionnaire de rapports doivent faire
partie du groupe des administrateurs (BUILTIN\Administrateurs).
Reporting Services ne gère pas de liste spécifique d’utilisateurs. Il s’appuie totale-

ment sur les utilisateurs et rôles créés dans le système de sécurité de Windows (Active
Directory). Si vous désirez autoriser d’autres utilisateurs à accéder aux rapports, vous
devrez ajouter de nouveaux utilisateurs ou groupes Windows dans des rôles de niveau
éléments propres à Reporting Services.
SQL Server Reporting Services utilise l’autorisation basée sur les rôles et l’au-
thentification Windows pour déterminer qui est habilité à effectuer des opérations
et à accéder aux éléments d’un serveur de rapports. L’autorisation basée sur les rôles
catégorise en rôles l’ensemble des actions qu’un utilisateur ou groupe peut effectuer.
Reporting Services est installé avec une attribution de rôle unique qui accorde
l’accès au serveur de rapports aux membres du groupe des administrateurs locaux. Un
administrateur local doit créer des attributions de rôles supplémentaires pour rendre
le serveur de rapports accessible aux autres comptes d’utilisateur et de groupe. Dans
SSRS 2008 les rôles sont créés grâce à Management studio. L’attribution de rôles
s’effectue via le Gestionnaire de rapports.
Figure 10.22
Les rôles de Reporting Services

Dans le cadre de la planification d’un déploiement, vous devez déterminer comment
les utilisateurs se connectent au serveur de rapports, comment le serveur de rapports
se connecte à sa base de données interne et comment le serveur se connecte aux
sources de données externes qui fournissent les données aux rapports. Vous devez
aussi connaître les services, les comptes et les connexions qui doivent être configurés
pendant ou après l’installation pour rendre un serveur de rapports disponible. Enfin,
vous devez savoir quand des autorisations d’administrateur sont requises pour exécuter
un outil ou effectuer une tâche.
Connexions utilisées dans un déploiement de Reporting Services

Au cours de la planification d’un déploiement de Reporting Services, vous devez
configurer et gérer trois types de connexions.
Voici les trois étapes de connexion dans Reporting Services
• Connexion des utilisateurs au serveur de rapports
• Connexion du serveur de rapport à la base de données
• Connexion aux sources de données externes qui fournissent les données aux
rapports.
Le diagramme suivant illustre les connexions intervenant dans une installation

en mode natif par défaut. Ce diagramme présente les types des connexions que vous
devez définir ou gérer.
Figure 10.23
Le tableau 10.3 fournit des informations détaillées sur chaque type de connexion.
Étapes de paramétrages
Figure 10.24 — Page Paramètres du site (général)
Le formulaire Paramètres du site permet de :

• modifier le titre de l’application ;
• définir des valeurs par défaut à l’échelle du serveur pour les limites de l’historique
de rapport et les valeurs du délai d’exécution du traitement du rapport ;
• gérer les attributions de rôle au niveau du système ;
• gérer les planifications partagées ;
• effectuer les attributions de rôles système prédéfinis, en s’appuyant sur des comptes
d’utilisateurs et de groupes ;
• de prédéfinir les planifications partagées que les utilisateurs peuvent sélectionner
pour leurs rapports et abonnements.
Tableau 10.3
Connexion Description
1 L’utilisateur se connecte Les utilisateurs et les applications se connectent à un
au serveur de rapports serveur de rapports par l’intermédiaire de requêtes
http.
Par défaut, les utilisateurs sont authentifiés au moyen
de leurs informations d’identification de domaine et de
la sécurité intégrée Windows.
D’autres modes d’authentification peuvent être
déployés.
Authentification par formulaire (Common logon)
Mode intégré SharePoint
Une fois l’utilisateur authentifié, le serveur de rapports
vérifie s’il existe des autorisations qui octroient l’accès
au contenu et aux opérations du serveur de rapports.
Les autorisations sont définies dans des attributions de
rôles qui décrivent les tâches qu’un utilisateur peut
accomplir. Chaque utilisateur qui se connecte à un
serveur de rapports doit posséder les attributions de
rôles définies sur le compte qu’il utilise pour se
connecter au serveur de rapports.
2 Le serveur de rapports Le serveur de rapports se connecte à la base de
se connecte à la base données système (en général la base SQL
de données du serveur ReportServer) en vue de stocker et d’extraire du
de rapports contenu, l’état du serveur et des métadonnées.
Le serveur de rapports peut se connecter à sa base de
données à l’aide de l’un des types de comptes
suivants :
– Utiliser le compte de service. Il s’agit de la valeur par
défaut.
– Utiliser un compte de domaine.
– Utiliser une connexion SQL Server.
3 Le serveur de rapports Pour récupérer des données utilisées dans un rapport,
se connecte à des sources un serveur de rapports doit se connecter à d’autres
de données externes serveurs qui abritent des sources de données externes
(Oracle, SQL, DB2...). Lorsque le rapport ou le modèle
s’exécute, le serveur de rapports ouvre une connexion
au serveur ou à l’ordinateur, fournit la requête, attend
que le dataset soit retourné, puis ferme la connexion
avant de passer à l’étape de traitement suivante.
Rôles au niveau élément

Une définition de rôle au niveau élément est une collection nommée de tâches
que les utilisateurs effectuent sur un élément spécifique (c’est-à-dire un dossier, un
rapport, une ressource ou une source de données partagée). Les définitions de rôles
sont attribuées à un utilisateur ou à un groupe pour créer une attribution de rôle.
Les tâches contenues dans la définition de rôle décrivent les opérations que peuvent
effectuer l’utilisateur ou le groupe.
Reporting Services contient plusieurs définitions prédéfinies de rôles au niveau
élément que vous pouvez utiliser. Vous pouvez les modifier en changeant la liste des
tâches de chacune d’elles ou vous pouvez créer une définition de rôle qui prend en
charge une autre combinaison de tâches.
Figure 10.25 — Les rôles de sécurité sont définis dans Management Studio
Figure 10.26 — Rôle utilisateur (niveau élément)
Rôles système
Une définition de rôle système contient une collection nommée de tâches effectuées
sur tout le site (c’est-à-dire, la racine virtuelle qui héberge l’environnement du serveur
de rapports) plutôt que sur un élément individuel. Les définitions de rôles sont
attribuées à un utilisateur ou à des groupes pour créer une attribution de rôle. Les
tâches contenues dans la définition de rôle spécifient les opérations que peuvent
effectuer l’utilisateur ou le groupe.
Reporting Services contient deux définitions de rôles système prédéfinies : Admi-

nistrateur système et Utilisateur système. Vous pouvez les modifier en changeant la
liste des tâches de chacune d’elles ou vous pouvez créer un rôle système qui prend en
charge une autre combinaison de tâches.
Figure 10.27 — Rôle système dans Management studio
Figure 10.28 — Rôle système
Reporting Services fournit cinq rôles utilisateur standards pour lesquels il est
nécessaire d’attribuer un compte utilisateur ou groupe Windows (tableau 10.4).
Par exemple, un utilisateur auquel il a été attribué un rôle de serveur de publication
sera autorisé à publier, créer, voir et supprimer des rapports. En revanche, il ne sera
pas autorisé à créer de nouveaux rôles.
Tableau 10.4 — Les rôles utilisateur par défaut de Reporting Services
Générateur de rapports Permet de visualiser les définitions de rapports.

Gestionnaire Peut gérer un contenu sur Report Server, notamment
de contenu des dossiers, des rapports et des ressources.
Lecteur Peut afficher des dossiers et des rapports, et s’abonner
à des rapports.
Mes rapports Peut publier des rapports et des rapports liés, gérer
des dossiers, des rapports et des ressources
dans le dossier « Mes rapports » d’un utilisateur.
Serveur de publication Peut publier des rapports et des rapports liés sur Report Server.
Dans la plupart des cas, les droits d’accès aux différents dossiers et objets devront
faire l’objet d’une attribution spécifique de la part de l’administrateur. Il existe une
exception à cette règle : l’administrateur local dispose de toutes les autorisations. Un
utilisateur qui appartient au groupe local Administrateurs sur le serveur qui héberge
Reporting Services disposera de tous les droits.
Si vous supprimez l’attribution de rôle pour BUILTIN\Administrateurs et les
membres du groupe administrateur local, vous continuerez à disposer des droits de
gestion de tous les dossiers et objets.
Les tâches et les droits dans Reporting Services

Chaque tâche de Reporting Services fait l’objet d’une attribution de droit. Le
tableau 10.5 dresse les droits des rôles.
Tableau 10.5 — Tâches des rôles dans Reporting Services
Afficher les dossiers Permet d’afficher les éléments dans l’arborescence

des dossiers, ainsi que les propriétés des dossiers.
Afficher les modèles Afficher des modèles de l’arborescence des dossiers, utiliser
des modèles comme sources de données pour un rapport
et exécuter des requêtes sur le modèle pour extraire
des données.
Afficher les rapports Permet d’afficher les rapports et les rapports liés
dans l’arborescence des dossiers, ainsi que les captures instantanées
d’historique de rapport et les propriétés
de rapport.
Afficher Permet d’afficher les ressources dans l’arborescence des dossiers,
les ressources ainsi que les propriétés des ressources.
Afficher les sources de Permet d’afficher les éléments de source de données
données dans l’arborescence des dossiers, ainsi que les propriétés
de la source de données.
Créer Permet d’afficher et de modifier les paramètres de sécurité
des rapports liés des rapports, des dossiers, des ressources et des sources
de données partagées.
Définir la sécurité pour Permet de créer des rapports liés et de les publier
des éléments dans un dossier du serveur de rapports.
individuels
Tableau 10.5 — (suite)

Gérer Chaque utilisateur peut créer, afficher, modifier
les abonnements et supprimer des abonnements dont il est propriétaire.
individuels
Gérer les dossiers Permet de créer, d’afficher et de supprimer des dossiers,
ainsi que d’afficher et de modifier des propriétés des dossiers.
Gérer les modèles Créer, afficher et supprimer des modèles, et afficher
et modifier des propriétés de modèle.
Gérer les rapports Permet de créer, d’afficher et de supprimer des rapports,
ainsi que de modifier des propriétés des rapports.
Gérer les ressources Permet de créer, de modifier et de supprimer des ressources,
ainsi que d’afficher et de modifier des propriétés
des ressources.
Gérer les sources Permet de créer et de supprimer des éléments de source
de données de données partagée, ainsi que de modifier des propriétés
de source de données.
Gérer l’historique Permet de créer, d’afficher et de supprimer des captures instantanées
de rapport d’historique de rapport, ainsi que de modifier
des propriétés d’historique de rapport.
Gérer tous Permet d’afficher, de modifier et de supprimer un abonnement
les abonnements quel que soit son propriétaire.
Lire les rapports Lit les définitions de rapport.
En complément des tâches d’accès aux rapports, des tâches complémentaires de

gestion du système font également l’objet de droits spécifiques (tableau 10.6).
Tableau 10.6 — Tâches de rôle système
Afficher les planifications Permet d’afficher une planification prédéfinie

partagées qui est disponible à des fins d’utilisation générale.
Afficher les propriétés Permet d’afficher les propriétés qui s’appliquent
du serveur de rapports au serveur de rapports.
Exécuter les définitions Démarrer l’exécution à partir de la définition de rapport
de rapport sans la publier sur Report Server.
Générer des événements Fournit une application qui permet de générer
des événements dans l’espace de noms du serveur
de rapports.
Gérer la sécurité Permet d’afficher et de modifier les attributions de rôles
du serveur de rapports au niveau du système.
Gérer les planifications Permet de créer, de modifier et de supprimer
partagées des planifications partagées qui sont utilisées pour exécuter des
rapports ou les actualiser.
Gérer les propriétés Permet d’afficher et de modifier les propriétés qui s’appliquent
du serveur de rapports au serveur de rapports et aux éléments gérés par celui-ci.
Gérer les rôles Permet de créer, d’afficher et de modifier des définitions
de rôles.
Gérer les travaux Permet d’afficher et d’annuler les travaux en cours d’exécution.
Les rôles dans Reporting Services

Les droits autorisent des tâches. Afin de simplifier la gestion des droits, il est possible
de regrouper des tâches en créant des rôles.
Reporting Services propose cinq rôles en standard.
Tableau 10.7 — Rôles standards créés lors de l’installation de Reporting Services
Générateur de rapports Permet de visualiser les définitions de rapports.

Gestionnaire de contenu Peut gérer un contenu sur Report Server, notamment
des dossiers, des rapports et des ressources.
Lecteur Peut afficher des dossiers et des rapports, et s’abonner
à des rapports.
Mes rapports Peut publier des rapports et des rapports liés, gérer
des dossiers, des rapports et des ressources
dans le dossier « Mes rapports d’un utilisateur ».
Serveur de publication Peut publier des rapports et des rapports liés sur Report Server.
Chaque rôle prédéfini comporte un certain nombre de tâches.
Tableau 10.8 — Attribution des tâches par rôle
Rôles Générateur Gestionnaire Lecteur Mes Publication

de rapports de contenu rapports
Afficher
OUI OUI OUI OUI NON
les dossiers
Afficher
OUI OUI OUI NON NON
les modèles
Afficher
OUI OUI OUI OUI NON
les rapports
Afficher
OUI OUI OUI OUI NON
les ressources
Afficher
les sources NON OUI NON OUI NON
de données
Créer
NON OUI NON OUI OUI
des rapports liés
Définir
la sécurité pour
NON OUI NON NON NON
des éléments
individuels
Gérer
les abonnements NON OUI OUI OUI NON
individuels
Gérer
NON OUI NON OUI OUI
les dossiers
Gérer
NON OUI NON NON OUI
les modèles
Gérer
NON OUI NON OUI OUI
les rapports

Rôles Générateur Gestionnaire Lecteur Mes Publication
de rapports de contenu rapports
Gérer
NON OUI NON OUI OUI
les ressources
Gérer
les sources NON OUI NON OUI OUI
de données
Gérer l’historique
NON OUI NON OUI NON
de rapport
Gérer tous les
NON OUI NON NON NON
abonnements
Lire
OUI OUI NON NON NON
les rapports
Les tâches spécifiques au rôle Administrateur système

Le rôle Administrateur système est un rôle prédéfini qui comprend des tâches utiles
pour un administrateur qui a la responsabilité générale du serveur de rapports, mais
pas nécessairement de son contenu.
Tableau 10.9 — Attribution des tâches par rôle
Afficher Permet d’afficher une planification prédéfinie

les planifications partagées qui est disponible à des fins d’utilisation générale.
Afficher les propriétés Permet d’afficher les propriétés qui s’appliquent
du serveur de rapports au serveur de rapports.
Exécuter les définitions Démarrer l’exécution à partir de la définition de rapport
Générer des événements Fournit une application qui permet de générer
des événements dans l’espace de noms du serveur
de rapports.
Gérer la sécurité du serveur Permet d’afficher et de modifier les attributions de rôles
de rapports au niveau du système.
Gérer les planifications Permet de créer, de modifier et de supprimer
partagées des planifications partagées qui sont utilisées
pour exécuter des rapports ou les actualiser.
Gérer les propriétés Permet d’afficher et de modifier les propriétés
du serveur de rapports qui s’appliquent au serveur de rapports
et aux éléments gérés par celui-ci.
Gérer les rôles Permet de créer, d’afficher et de modifier
des définitions de rôles.
Gérer les travaux Permet d’afficher et d’annuler les travaux en cours
d’exécution.
Les tâches spécifiques au rôle Utilisateur système

Le rôle Utilisateur système est un rôle prédéfini qui comprend des tâches permettant
aux utilisateurs d’afficher des informations de base sur le serveur de rapports. Il prend
également en charge le chargement d’un rapport dans le Générateur de rapports.
Tableau 10.10 — Liste des tâches du rôle Utilisateur Système
Afficher Permet d’afficher une planification prédéfinie

les planifications partagées qui est disponible à des fins d’utilisation générale.
Afficher les propriétés du serveur Permet d’afficher les propriétés qui s’appliquent
de rapports au serveur de rapports.
Exécuter les définitions de rapport Démarrer l’exécution à partir de la définition
Les tâches et les rôles ont été définis. Il convient maintenant d’attribuer des
utilisateurs ou groupes d’utilisateurs Windows dans chaque rôle.
Dans le champ Nom d’utilisateur ou de groupe, vous devez entrer un nom d’utilisa-
teur ou groupe Windows. Il est possible également de préfixer le nom d’utilisateur par
le nom de domaine tel que DOMAIN\Utilisateur.
Figure 10.29 — Le dossier Racine est autorisé aux utilisateurs Stagiaire avec le rôle Lecteur et
Administrateur avec le rôle Gestionnaire de contenu
Figure 10.30 — Formulaire de nouvelle attribution de rôle système
Sécuriser les objets de Reporting Services

Dans le but d’autoriser l’accès aux rapports ou répertoires de Reporting Services, vous
allez devoir ajouter la sécurité à chaque élément. Par exemple, pour donner accès au
répertoire AdventureWorks Sample Reports et tous les rapports qu’il contient, il est
nécessaire d’ouvrir le répertoire puis d’accéder à l’onglet Propriétés puis Sécurité.
Vous observez une page identique à celle donnée figure 10.30.
Figure 10.31 — L’onglet Propriété du rapport permet de modifier la sécurité d’accès au rapport
Ajoutez un utilisateur Windows.

Figure 10.32 — Créer un nouvel utilisateur Windows
Attribuer l’utilisateur Windows au rôle prédéfini Lecteur. Il est possible de créer

un nouveau rôle si aucun ne correspond au choix souhaité.
À l’issue de ce traitement, voici les rôles attribués au répertoire AdventureWorks
Sample Reports (figure 10.33).
Figure 10.33 — Attribution du rôle Lecteur à l’utilisateur Bertrand
La sécurité attribuée au dossier racine AdventureWorks Sample Reports sera

naturellement reportée sur l’ensemble des sous-répertoires contenus dans le dossier
Racine.
La procédure d’attribution de sécurité d’un répertoire peut être appliquée de façon

identique aux rapports et aux ressources.
Figure 10.34 — Le lien Sécurité de l’onglet Propriétés du dossier racine fait apparaître
les utilisateurs Windows et les rôles associés
10.3.2 Les rapports liés

Reporting Services offre une technique permettant de partager un rapport qui a été
déployé dans un répertoire afin de le partager dans d’autres dossiers. Cette technique
permet de n’avoir qu’une seule définition du rapport rendant la maintenance et le
déploiement plus aisés. Le rapport est cependant accessible à partir de différents
dossiers. Pour des raisons évidentes, le rapport lié n’hérite pas de la sécurité du rapport
sur lequel il pointe (figure 10.35).
Figure 10.35 — Le menu General de l’onglet Propriétés du rapport permet de créer un rapport
lié avec une sécurité différente
10.3.3 L’exécution de rapports
Figure 10.36 — Formulaire de définition des propriétés lors de l’exécution du rapport

L’onglet Propriétés de l’exécution d’un rapport permet de définir le processus d’op-

timisation lors de l’affichage. Ces options déterminent à quel moment se produit
le traitement du rapport. Vous pouvez ainsi définir ces options pour programmer
l’exécution d’un rapport la nuit ou lorsque le serveur est le moins sollicité. Si un
rapport est consulté fréquemment, vous pouvez également mettre en cache de façon
temporaire des copies de ce dernier pour éliminer les temps d’attente lorsque plusieurs
utilisateurs y accèdent à quelques minutes d’intervalle.
Pour ouvrir cette page, sélectionnez un rapport, cliquez sur l’onglet Propriétés
situé en haut de la page, puis sur le menu Exécution situé sur le côté gauche de la
page. Précisons les différents choix proposés :
• Toujours exécuter ce rapport avec les données les plus récentes. Utilisez cette option
lorsque vous souhaitez que le rapport soit exécuté à la demande ou lorsqu’un
utilisateur le sélectionne. Si une copie du rapport est encore disponible en
cache mémoire, l’extraction ne sera pas exécutée et l’affichage du rapport sera
instantané.
• Ne pas mettre en cache les copies temporaires de ce rapport. Le rapport sera toujours
exécuté avec les données les plus récentes. Chaque utilisateur qui ouvre le
rapport déclenche un accès à la source de données.
• Mettre en cache une copie temporaire du rapport place une copie temporaire
du rapport dans un cache lorsqu’un premier utilisateur ouvre le rapport. Les
performances sont meilleures pour les utilisateurs qui ouvrent le même rapport
avec les mêmes paramètres d’extraction, car il n’y aura pas d’accès à la source
de données.
• Faire expirer la copie du rapport après un certain nombre de minutes. Saisissez le
nombre de minutes après lequel la copie temporaire n’est plus valide. Une fois
cela, elle n’est plus renvoyée à partir du cache. La prochaine fois qu’un utilisateur
ouvrira le rapport, le serveur de rapports retraitera ce dernier et replacera une
copie du rapport actualisé dans le cache.
• Faire expirer la copie du rapport selon la planification suivante. Ce paramètre permet
de définir une date et heure d’expiration pour un rapport. Pour qu’un rapport
mis en cache expire en fin de journée, par exemple, vous pouvez sélectionner
une heure durant la nuit après laquelle la copie expire.
• Effectuer le rendu de ce rapport à partir d’une capture instantanée d’exécution du
rapport : cette option permet de traiter un rapport comme un cliché, à l’heure
planifiée. Choisissez cette option lorsque vous souhaitez exécuter un rapport
aux heures creuses. Contrairement aux copies mises en cache qui sont créées
lorsqu’un utilisateur ouvre le rapport, un cliché est créé, puis actualisé, suivant
une planification. Les clichés restent en service jusqu’à ce qu’ils soient remplacés
par de nouvelles versions.
• Les clichés générés par les paramètres d’exécution de rapport ont les mêmes
caractéristiques que les clichés d’historique de rapport. La seule différence réside
dans le fait qu’il n’existe qu’un seul cliché d’exécution de rapport et plusieurs clichés
d’historique de rapport. Ces derniers sont accessibles à partir de la page Historique
du rapport, qui stocke de nombreuses instances d’un rapport à différents instants.
Les utilisateurs ont accès aux clichés d’exécution de rapport à partir des dossiers
(comme pour les rapports actifs).
Figure 10.37 — Formulaire permettant de préciser les détails de la planification d’envoi

de rapports
• Créer une capture instantanée du rapport lorsque vous cliquez sur le bouton
Appliquer de cette page : cliquez sur ce bouton pour rendre le cliché disponible
avant l’heure de début planifiée.
• Délai d’expiration de l’exécution des rapports : spécifie si le traitement d’un rapport
doit être interrompu après un certain nombre de secondes. Si vous choisissez le
paramètre par défaut, le paramètre du délai d’expiration spécifié dans la page
Paramètres du site est utilisé pour le rapport.
10.3.4 L’historisation des rapports

Cette fonctionnalité permet de conserver une trace des rapports exécutés. Plutôt
que de conserver des copies des données à des instants différents, il sera plus simple
de conserver les instantanés des rapports. Il est ainsi possible de conserver des listes
d’inventaire, des ratios financiers ou des rapports de production à différentes périodes
et ainsi d’analyser les tendances. Précisons que ces analyses restent visuelles et que
les rapports ne peuvent à nouveau faire l’objet de réexécution. Pour les analyses de
tendance nous préférerons naturellement la richesse des KPI fournis avec Analysis
Services.
Figure 10.38 — Le menu Historique de l’onglet Propriétés permet de paramétrer la fréquence

d’historisation des instantanés
L’onglet Historique permet de consulter les instantanés.
Figure 10.39 — L’onglet Historique du rapport Company Sales fournit la liste des instantanés
10.3.5 Abonnements aux rapports

Plusieurs types de souscription aux rapports sont proposés par Reporting Services.
Lorsqu’un utilisateur qui affiche un rapport désire souscrire à un envoi régulier du
rapport, il crée un abonnement.
Il peut recevoir ses rapports soit par e-mail, soit dans un répertoire partagé. La
dernière option permet également de placer le rapport dans un entrepôt de documents
indexé par une application telle que SharePoint Portal.
Le formulaire ci-dessous présente les options liées à la procédure d’abonnement au

rapport Company Sales.
La gestion des abonnements nécessite que le service SQL Server Agent soit
actif. Le gestionnaire d’abonnements envoie les rapports via le compte SMTP. Ce
compte a été paramétré lors de la configuration de Reporting Services (exemple :
smtp.wanadoo.fr).
Figure 10.40 — Formulaire d’options d’abonnement de rapport
Les champs Objet et Commentaire permettent d’introduire du texte avec des

variables comme le nom du rapport et l’heure d’exécution (@ReportName et @ExeStyle
caratère : CodeDansTexte non pris en charge
cutionTime).
Figure 10.41 — La réception du rapport dans Outlook
Un lien dynamique vers le serveur permet de rafraîchir le rapport et de retrouver

une navigation dynamique ( drill down sur les années ou les catégories).
D’autres formats peuvent être joints en pièces attachées (PDF, CSV, Excel, etc.).
10.4 REPORTING À LA DEMANDE AVEC REPORT

BUILDER
Le générateur de rapports Report Builder est une application côté client qui permet de
créer et de concevoir des rapports à la demande. Cet outil est mis à la disposition des
managers. Il est en effet orienté métier et ne nécessite pas de connaissance technique.
Report Builder (SSRB) offre un service de données au niveau entité concep-
tuelle. Nous l’avons vu précédemment, l’écriture de rapports avec SSRS nécessite
de savoir élaborer des requêtes au niveau du schéma logique. Par exemple, la
création d’un rapport sur l’état des commandes nécessite d’écrire la jointure entre
les différentes tables qui constituent une commande (entête de commande/lignes de
commande/clients/produits).
Un grand nombre d’utilisateurs souhaite disposer d’un environnement utilisateur
de création de rapports n’imposant ni d’utiliser Visual Studio ni de créer des requêtes
SQL pour les rapports. Les utilisateurs et analystes souhaitent créer des rapports
10.4 Reporting à la demande avec Report Builder 327
directement sur les clients, les commandes, les ventes, etc. Certains raisonnent au
niveau concept métier, ou « domaine », et souhaitent exprimer leurs requêtes à ce
niveau plutôt qu’au niveau du schéma logique.
Report Builder permet de décrire et de mettre en correspondance les entités
« métier » avec la couche de schéma logique. Cette méthode porte le nom de SMDL
(Semantic Model Definition Language).
Report Builder permet de créer des rapports de type tabulaire, matriciel ou
graphique. La création d’un rapport nécessite au préalable la mise à disposition d’un
modèle de rapport. Ce modèle est conçu grâce à l’assistant de création d’un modèle de
rapport. Les modèles de rapport portent l’extension.smdl.
Lors de la publication du modèle sur le serveur, de nombreuses entités et champs
dérivés sont créés. Le tableau 10.11 donne la liste des options disponibles lors de la
génération du modèle de rapport.
Tableau 10.11 — Options disponibles lors de la génération du modèle de rapport
Options Description de l’option

Créer des entités Crée une entité pour chaque table, qu’elle contienne
pour toutes les tables ou non des données.
Créer des agrégations Crée un champ d’agrégation qui contient le nombre d’instances
de comptage uniques d’une entité.
Créer des attributs Crée un attribut pour chaque colonne
de chaque table.
Créer des attributs Crée un champ masqué qui contient les données
pour les colonnes de la base de données incrémentées automatiquement.
à incrémentation automatique
Créer des variations Crée des variations sur les champs de date en fonction
de date des différentes parties de la date, par exemple l’année,
les mois ou les jours.
Créer des agrégations Crée des champs somme, moyenne, minimum
numériques et maximum pour chaque champ numérique.
Créer des agrégations Crée un champ d’agrégation de la première date
de date et un champ d’agrégation de la dernière date
pour chaque champ de date.
Créer des rôles Crée deux rôles (un sortant et un entrant) pour chaque relation
découverte entre les entités.
Entités de recherche Considère les entités ne contenant qu’un champ en tant
qu’entités de recherche. Ces entités sont placées
dans un dossier nommé Lookup.
Petites listes Crée des listes déroulantes lorsqu’il existe dans l’entité moins
de 100 instances à partir desquelles choisir.
Grandes listes Impose aux utilisateurs de choisir dans une liste
où il existe dans l’entité plus de 500 instances parmi lesquelles
choisir.
Très grandes listes Impose aux utilisateurs de filtrer avant de choisir dans une liste
où il existe dans l’entité plus de 5 000 instances parmi lesquelles
choisir.
Définir des attributs Indiquent les champs qui sont uniques à cette entité.
d’identification Le générateur de rapports identifie les attributs d’identification
potentiels.

Options Description de l’option
Définir les attributs Indique les champs qui sont affichés par défaut lorsqu’un
de détail par défaut utilisateur clique sur un élément lié dans un rapport consultable
à l’aide de clics.
Nom du rôle uniquement Définit automatiquement la propriété de nom contextuel
de l’attribut Rôle.
Mise en forme Trie les champs numériques et de date dans l’ordre décroissant.
des nombres et de la date
Mise en forme Met en forme les nombres entiers et décimaux.
des nombres
entiers/décimaux
Mise en forme Définit la mise en forme des champs à virgule flottante.
des nombres à virgule
flottante
Mise en forme de la date Met en forme les champs de date et d’heure pour qu’ils affichent
uniquement la partie date et non la partie heure du champ.
Déconseiller Empêche les utilisateurs de regrouper les champs uniques.
le regroupement Cette option prend la valeur True par défaut
pour les attributs d’identification.
Sélection des valeurs Définit la propriété de sélection des valeurs aux listes déroulantes
de liste déroulante pour les champs contenant moins
de 200 valeurs uniques.
La table source SalesPerson est composée de neuf champs. Le générateur de modèle

crée des colonnes dérivées à partir des champs de la table source.
Les attributs de type texte sont préfixés par l’icône a tandis que les champs numériques
sont repérés par un # .
Lorsque le modèle de rapport est publié sur le serveur, le manager peut concevoir ses
rapports personnalisés. Il manipule les données métier en les filtrant, en les groupant,
en les triant ou en créant de nouvelles formules.
Figure 10.42 — Le formulaire liste les champs source repris dans le modèle
Lorsque le rapport est défini, il peut être enregistré sur le serveur de rapports. Il
devient donc disponible aux utilisateurs autorisés.
10.4 Reporting à la demande avec Report Builder 329
Figure 10.43 — L’entité Sales Person montre les colonnes dérivées
Le filtrage offre des conditions simples à utiliser et intuitives.
Figure 10.44 — Grâce à un glisser-déplacer, la construction du rapport s’effectue

Figure 10.45 — Filtrage sur l’année de commande
Lorsque le rapport est prêt, il est nécessaire de l’enregistrer sur le serveur de rapports
afin qu’il soit disponible dans Reporting Services.
10.5 Conclusion 331
Figure 10.46 — Le rapport filtré affiché dans Reporting Services
10.5 CONCLUSION
Les managers opérationnels disposent de peu de temps pour se former aux techniques
de la création de rapports. Les informaticiens joueront pleinement leur rôle en prépa-
rant des rapports utiles aux personnels de l’entreprise. La facilité de compréhension
des rapports et leur mise à disposition rapide permettront aux opérationnels de suivre
les indicateurs essentiels et ainsi de partager avec la direction, la vision de l’entreprise.
11
L’ analyse de données avec
Excel
Dans le chapitre précédent, nous avons montré comment Reporting Services permet
d’accéder à toutes les sources d’informations (relationnelles et OLAP) et d’en
découvrir le sens. SSRS offre de nombreuses formes de restitution de l’information :
listes, graphes, tendances, alertes.
Report Builder offre une certaine autonomie au manager pour accéder aux
informations dont il a besoin. Malgré de nombreux efforts déployés par l’éditeur,
Report Builder nécessite un minimum de formation. Or, les managers ont peu de
temps à consacrer à leur formation aux techniques de l’information.
Microsoft avait depuis longtemps introduit la notion de rapport de masse grâce à
une fonctionnalité que l’on trouve dans Excel : le tableau croisé dynamique. Excel
est depuis longtemps l’outil d’analyse le plus répandu et n’a pas besoin d’être présenté
aux managers.
Depuis le début des années 2000, Microsoft a introduit de nouvelles fonctionnalités
à Excel permettant ainsi d’accéder à des cubes OLAP. Cette technologie a offert de
nouvelles opportunités d’analyse. Excel peut également effectuer des requêtes sur
l’entrepôt de données.
Excel offre ainsi de nombreuses possibilités d’analyse : accès au datawarehouse via
MS Query, accès aux cubes OLAP via les tableaux croisés dynamiques.
Une conséquence bénéfique de l’existence du datawarehouse réside dans la
centralisation naturelle des données de l’entreprise. Excel ne doit donc plus être
un lieu de ressaisie manuel mais un outil d’analyse accédant aux données stratégiques.
Dans ce chapitre nous présenterons les tableaux croisés dynamiques d’Excel
accédant aux cubes OLAP 2000 ou 2008. Depuis la version d’Excel 2000 le mode
opératoire d’accès à un cube OLAP est le même. La version Excel 2007 (Office 12)
334 Chapitre 11. L’ analyse de données avec Excel
ne déroge pas à la règle. Elle apporte cependant une fonctionnalité liée à SSAS 2008 :
les indicateurs clés de performance (KPI).
Microsoft a également mis à disposition des utilisateurs d’Excel un complément
nommé Office Excel pour SQL server Analysis services. Cet outil apporte des
fonctionnalités qui n’existent pas dans les tableaux croisés dynamiques, en particulier
l’accès simultané à plusieurs cubes, et les fonctionnalités d’écriture dans un cube
OLAP. Nous présentons cet outil dans ce chapitre.
Grâce aux Office Web Components (OWC), Microsoft offre la possibilité d’encap-
suler des tableaux et graphes dynamiques dans des pages web. Cette fonctionnalité
est très prisée des utilisateurs nomades qui peuvent ainsi accéder à leurs analyses sur
Excel via un navigateur web.
Avec PerformancePoint 2007, Microsoft offre une ouverture nouvelle aux mana-
gers soucieux de gouvernance d’entreprise. Les indicateurs clés de l’entreprise sont
présentés sous forme de tableaux de bord synthétiques. BSM s’intègre naturellement
dans un portail maison, Sharepoint Portal.
Depuis avril 2006, la société Proclarity, spécialisée dans les outils de restitution sur
plateformes MS OLAP, a été rachetée par Microsoft. Nous montrons l’apport de cette
société dans la chaîne décisionnelle de Microsoft.
11.1 L’ ANALYSE AD HOC GRÂCE AUX TABLEAUX

CROISÉS DYNAMIQUES
L’utilisation des tableaux croisés dynamiques nécessite que le composant PivotTable

soit installé sur le poste client. Ce composant est téléchargeable sur le Web. Vous
pouvez également le télécharger sur le site de l’auteur www.buroformatic.com.
Figure 11.1 — Connexion au serveur Analysis Services 2008

11.1 L’ analyse ad hoc grâce aux tableaux croisés dynamiques 335
L’installation de ce composant nécessite la présence d’Excel sur le poste client.

Voici les étapes nécessaires à la création d’un tableau croisé dynamique. Il est à
noter que les paramètres de connexion sont à définir lors de la création du tableau.
Les accès ultérieurs permettront un rafraîchissement automatique des données.
Choisir Données/Rapport de tableau croisé dynamique/Source de données
externes.
Puis Obtenir les données/Choisir une source/OLAP/Nouvelle source de données.
Sélectionnez la base de données (ou cube ou perspective) désirée. Il est nécessaire
de créer une nouvelle source de données et de choisir un cube à analyser.
Figure 11.2 — Créer une nouvelle source de données OLAP
Le fournisseur OLAP varie en fonction de la version du serveur Analysis Services.

La version 8 correspond à AS 2000, la version 10 à MSAS 2008.
Figure 11.3 — Liste de sources OLAP
La nouvelle source OLAP est maintenant créée. Il convient de choisir cette source
en entrée du tableau croisé.
Figure 11.4 — Sélectionner l’emplacement du rapport
Le tableau croisé peut être créé dans la feuille Excel existante ou dans une nouvelle
feuille. Le positionnement du tableau dans la feuille doit également être précisé. Dans
la figure 11.4 le tableau croisé sera créé dans la feuille existante en cellule A3.
L’assistant fournit un modèle de rapport Vierge que l’utilisateur devra compléter.
L’espace de travail est composé de régions qui ont chacune un rôle spécifique.
Les champs de ligne et de colonnes reçoivent les attributs ou hiérarchies de
dimensions. Voir figure 11.5.
Figure 11.5 — L’assistant propose trois axes dimensionnels et une zone réservée aux mesures
Les champs de page permettent d’effectuer un filtrage de la source de données sur

plusieurs critères.
L’espace nommé Déposer Données ici reçoit les données numériques ou mesures du
cube.
Par un glisser-déposer, on introduit la catégorie de produit en tête de ligne, les

années calendaires en tête de colonnes et les territoires en filtre de page.
Figure 11.6 — Sélectionner un ou plusieurs éléments en filtre de page
Dans la figure 11.6 la sélection d’un seul pays France, aura pour conséquence de
filtrer la source de données sur ce critère. On observe sur la figure 11.7 le pays France
sur la zone champs de page.
Figure 11.7 — Le tableau croisé présente les ventes effectuées sur le territoire français,
par catégorie de produit (lignes) et par années calendaires (colonnes)
La figure ci-dessus montre une sélection des 10 meilleures ventes (Total sales
amount) triées en ordre décroissant.
Figure 11.8 — Options avancées de champ dynamique
Il est possible d’agrémenter la présentation du tableau en appliquant différents

types de formats. Dans la figure 11.9 le format standard a été appliqué.
Afin de rendre plus visuel le tableau il est possible d’ajouter un graphique croisé
dynamique.
Figure 11.9 — Liste des dix meilleures ventes de vélos (Road Bikes) de 2001 à 2004
Le graphique croisé dynamique est directement lié au tableau croisé. Le graphique

est mis à jour dynamiquement en fonction des choix effectués dans le tableau. Un drill
down dans le tableau entraîne la même opération dans le graphique et réciproquement.
Figure 11.10 — Le tableau croisé et le graphique croisé sont synchronisés dynamiquement
Excel 2007 présente des améliorations visuelles et de nouvelles fonctionnalités.

Excel 2007 permet également une restitution des KPI (Indicateurs clés de perfor-
mances) inclus dans Analysis services 2008.
Figure 11.11 — La nouvelle interface des tableaux croisés dynamiques d’Excel 2007
Créer un cube local

Pour des collaborateurs nomades qui par définition se déplacent et qui ne disposent
pas toujours d’une connexion Internet il est parfois souhaitable de leur fournir des
outils d’analyse. Les administrateurs pourront ainsi extraire des cubes et les stocker
sur des portables avec toutes les données nécessaires. Des aspects de sécurité doivent
également être pris en compte.
Excel dispose d’une fonction de création de cube local à partir d’un cube SSAS. Il
s’agit de la fonction OLAP hors connection du menu Tableau croisé dynamique.
Figure 11.12 — OLAP hors connexion permet de copier le cube sur le poste client
L’assistant de création de cube OLAP permet de stocker le cube localement.
Figure 11.13 — Permet de créer un fichier de données hors connexion
Les paramètres constitutifs du tableau croisé sont transférés dans le cube local.
Figure 11.14 — On choisit les dimensions et les mesures à exporter
Le fichier extrait porte le nom du cube source : Analysis Services Tutorial.cub.

Lors de l’analyse du cube local on accédera au fichier.cub et non au serveur de
cubes.
Figure 11.15 — Connexion OLAP à un cube OLAP

Il est à noter que Microsoft Query, inclus dans Excel, dispose d’un assistant
permettant de créer des cubes à partir d’une source relationnelle.
Depuis la version 2000, Excel permettait déjà de réaliser des cubes. Cette fonc-
tionnalité reste rudimentaire et ne s’applique qu’à des sources de données peu
volumineuses. Cette fonctionnalité ne doit pas occulter la recommandation majeure
de la Business Intelligence : partager un même et unique référentiel dans l’entreprise.
Ces recommandations étant faites, nous présentons succinctement les étapes qui
permettent de créer un cube avec Excel.
Dans MS Query aller dans Fichier puis Création de cube OLAP.
Figure 11.16 — L’assistant de création de cube OLAP à partir de MS Query
La requête porte une extension.oqy et est stockée par défaut dans le répertoire
requêtes d’Excel : C :\Documents and Settings\Administrateur\Application Data\
Microsoft\Requêtes\AdventureWorks.cub.
Le tableau croisé dynamique d’Excel est l’outil permettant de relire un cube stocké
selon ce format.
11.2 COMPLÉMENT MICROSOFT OFFICE EXCEL

POUR SQL SERVER ANALYSIS SERVICES
Le complément Microsoft Office Excel pour SQL Server Analysis Services est une
nouvelle offre d’analyse décisionnelle qui permet aux utilisateurs de créer rapidement
des rapports personnalisés dans Microsoft Excel. Ce complément est disponible
gratuitement sur le site de Microsoft. Il est compatible avec les versions Excel 2002
(XP) et 2003.
11.2 Complément Microsoft Office Excel pour SQL Server Analysis Services 343
Interactivité de l’analyse et de la génération des rapports

Conçu pour étendre les fonctionnalités de Microsoft Office Excel, le complément
Excel pour Analysis Services permet d’accéder aux données de différentes sources, de
les analyser, puis de créer des rapports riches et personnalisés directement dans Excel.
Grâce à ce complément, les utilisateurs individuels peuvent gérer le cycle des rapports
du début à la fin, et éliminer le copier-coller des données issues de différents systèmes.
Fonctionnalités techniques clés

Le complément Excel pour Analysis Services, étroitement intégré à Microsoft SQL
Server et Analysis Services, étend les fonctionnalités d’analyse et de génération
de rapports de Microsoft Office Excel. Il contient un ensemble complet d’outils
qui simplifient la liaison avec diverses sources de données, la gestion des requêtes,
la génération de rapports sophistiqués dans plusieurs formats, l’enregistrement des
données dans le cube, etc. Les composants clés du complément Excel pour Analysis
Services sont :
Les fonctionnalités principales sont les suivantes :
• récupère et partage les données des cubes OLAP (2000/2008) ;
• regroupe et exécute les requêtes ;
• met en forme les résultats des requêtes ;
• enregistre des données dans les cubes OLAP (write back) ;
• gère la mise en forme des rapports ;
• permet l’insertion ou la suppression de ligne ;
• offre des possibilités de drill down/drill up ;
• gère les formules et présente les résultats dans les cellules Excel ;
• permet de répondre à des simulations de type « what if » ;
• affiche les formules au format MDX.
Après installation du complément, un nouveau menu Analyse des cubes apparaît

dans la barre Excel.
Figure 11.17 — Le menu Analyse des cubes du complément Excel pour OLAP
Le menu gérer les connexions permet de connecter plusieurs cubes.
Figure 11.18 — Gestion des connexions
Lors de la création d’un nouveau rapport plusieurs dispositions sont fournies :

11.2 Complément Microsoft Office Excel pour SQL Server Analysis Services 345
Figure 11.19 — Outil de disposition des rapports
Plusieurs filtrages peuvent être associés. Les navigations drill down et drill up sont
disponibles. À la différence du tableau croisé dynamique, le tableau peut être scindé.
Des lignes et colonnes peuvent y être ajoutées.
Figure 11.20 — La sélection du choix Ligne, colonne et filtre de page crée un rapport composé
de quatre sections
À titre d’exemple, voici le code MDX généré par l’assistant :
SELECT {Hierarchize({{[Customer].[Customer Geography].[All Customers],

AddCalculatedMembers({[Customer].[Customer Geography].[All
Customers].children})}})} on 0, {Hierarchize({{[Product].[Subcategory].[All
Products],
AddCalculatedMembers({[Product].[Subcategory].[All Products].children})}})} on
1
from [Adventure Works]
where ([Date].[Calendar].[Calendar Year].&[2003])
CELL PROPERTIES VALUE, FORMATTED_VALUE, FONT_NAME, FONT_SIZE, FONT_FLAGS,
FORE_COLOR, BACK_COLOR, FORMAT_STRING
Figure 11.21 — Rapport défini avec l’outil Analyse de données
Les fonctionnalités de l’analyseur de cube permettent d’isoler ou d’éliminer des

membres de dimension.
Bien que de quelques fonctionnalités nouvelles liées à SSAS 2008 aient été
ajoutées (groupes de mesures, dimensions hiérarchiques) à l’heure où nous testons le
complément d’analyse sur les cubes UDM (AS 2008) certaines fonctions ne sont pas
encore opérationnelles. Cela est probablement lié à la différence de structure entre les
cubes AS 2000 et 2008.
Il s’agit en particulier de l’accès au détail par un clic droit sur les cellules agrégées.
Les actions et les fonctions de simulation ne sont pas opérationnelles.
La version Excel 2007 intègre définitivement l’analyse des cubes avec toutes les
fonctionnalités propres à SSAS 2008.
11.3 Reporting interactif sur le web avec OWC 347
11.3 REPORTING INTERACTIF SUR LE WEB AVEC OWC
Les managers nomades qui désirent accéder régulièrement à leurs tableaux trouveront
appréciable d’utiliser des tableaux croisés dynamiques sur le Web. Si le composant
OWC n’est pas installé sur le poste client, le téléchargement du contrôle ActiveX
s’effectue lors du premier accès au cube.
L’utilisateur accède au cube OLAP via une interface web. L’outil d’interrogation
des cubes via le Web est similaire au tableau croisé dynamique intégré à Excel.
En pratique, le concepteur intègre le composant OWC (tableau croisé dynamique)
dans une page web puis établit les connexions vers les sources de données.
Dans FrontPage il est possible de créer un tableau croisé dynamique (figure 11.22).
Figure 11.22 — Insertion d’un composant web avec FrontPage
Le composant ActiveX permet de disposer d’une interface proche du tableau croisé.
Figure 11.23 — Le composant web dans FrontPage

La liste des champs de tableau croisé apparaît dans la fenêtre de droite. Le

concepteur de la page web élabore un premier tableau qui servira de modèle de base à
l’utilisateur final.
Figure 11.24 — Avec le graphe associé
Par la suite, l’utilisateur définit lui-même les axes d’analyse, filtre et trie les données
selon ses propres analyses.
11.4 CONCLUSION
De nombreux outils étaient déjà intégrés dans Office 2000 permettant d’effectuer
toutes sortes de requêtes et d’analyses. MS Access et MS Excel sont largement
répandus dans les entreprises. De nombreuses PME/PMI ont mis en place des systèmes
décisionnels efficaces grâce à de tels outils.
11.4 Conclusion 349
Les limitations de tels outils ont été évoquées plus haut. Grâce à SQL server 2008
et Analysis services, Microsoft a su concilier la puissance et la robustesse d’un système
centralisé connectés à des outils fortement répandus auprès des managers d’entreprises.
Pour les utilisateurs nomades désireux d’effectuer tous types d’analyse tout en
restant connecté à leur entreprise, Microsoft ne disposait pas de solution satisfaisante.
Depuis l’acquisition de la société Proclarity ce vide est comblé. Nous verrons dans le
chapitre suivant les différentes solutions d’analyse offertes via le web.
12
L’analyse de données
sur le Web
Reporting Services, totalement orienté Web, offre une lecture statique des données
de l’entrepôt et des cubes OLAP. Excel, grâce aux OWC permet une lecture plus
dynamique des mesures et axes dimensionnels. Bien qu’Excel soit l’outil d’analyse le
plus répandu et le mieux maîtrisé par les managers, il n’en reste pas moins que certains
prérequis sont nécessaires : une licence Excel est nécessaire sur chaque poste utilisateur
et le composant OWC doit également être installé pour une lecture sur le Web.
Si l’on désire accéder à des informations d’analyse dans un contexte extranet, il
est indispensable de disposer d’outils qui ne nécessitent aucune installation côté poste
client.
Afin de répondre à cette attente, Microsoft a acquis cette technologie en avril 2006,
auprès de la société Proclarity. La vocation de Proclarity fut pendant des années de
développer des outils de restitution autour des outils SQL Server 2000/2008 et du
portail Sharepoint.
Microsoft annonce que les outils développés par Proclarity feront partie intégrante
de la suite décisionnelle aux côtés de Business Scorecard Manager. On y trouve les
fonctionnalités exposées dans les sections suivantes.
352 Chapitre 12. L’analyse de données sur le Web
12.1 PROCLARITY FOR BUSINESS SCORECARD

MANAGER
Sans installation côté client, Proclarity Business Scorecard permet d’obtenir un
tableau synthétique des objectifs avec une vision de haut niveau. Derrière chaque
indicateur, il est possible de découvrir les raisons qui mènent à ce résultat.
Figure 12.1 — Le logiciel Proclarity for Business Scorecard. Rassemble les indicateurs clés
de l’entreprise
Derrière chaque indicateur clé de performance, le client analytique léger permet de

répondre à la question « Pourquoi ? ». Proclarity propose des modes de représentation
inhabituels et complémentaires à ceux d’Excel, tels que l’arbre de décomposition, la
carte de performance et la vue en perspective.
12.1.1 L’arbre de décomposition

Un arbre de décomposition fractionne une valeur pour mettre en évidence les éléments
qui y contribuent et affiche leurs relations dans une arborescence hiérarchique avec,
éventuellement, un graphique de Pareto. Il permet également de répondre à des
questions telles que : « Quels sont les produits alimentaires qui se vendent le mieux ? »,
« Quel pourcentage des ventes globales du deuxième trimestre représente les aliments
en boîtes de conserve ? »
Les données sont affichées sous forme de chiffres bruts et de pourcentages. Vous
pouvez trier les nœuds du plus grand au plus petit ou inversement. En outre, les
12.1 Proclarity for Business Scorecard Manager 353
graphiques de Pareto illustrent la répartition des valeurs afin de permettre d’identifier

rapidement les groupes qui apportent la plus grande contribution à un total.
Figure 12.2 — L’arbre de décomposition s’affiche dans une page web
La figure 12.2 présente les informations suivantes :

• La quantité totale des ventes Internet représente 5 436 429 _ pour le 2e trimestre
de l’année calendaire 2004.
• Sur la même période, les accessoires représentent 4 % des ventes.
• Les Fenders et les Bikes Racks représentent respectivement 7 % et 6 % des
accessoires Ces deux catégories sont matérialisées par les deux barres plus claires
du graphique de Pareto.
• Dans le graphique de Pareto, la ligne des 76 % croise la ligne du pourcentage
du total au-dessus de la barre représentant les Fenders. Cela signifie qu’environ
76 % des ventes d’accessoires sur Internet sont représentées par les trois
premières catégories (Top 3) et représentées graphiquement par les barres situées
à gauche de la catégorie Fenders. Pour connaître le détail de ces accessoires,
il suffit de placer le curseur sur les barres ou de cliquer sur le nœud Top 3
(3 premiers) afin d’afficher son contenu.
• Une diminution significative de la quantité d’accessoires vendus est observée à
partir de la troisième barre. Cette situation pourrait éventuellement faire l’objet
d’une analyse plus approfondie.
12.1.2 La carte de performance

Une carte de performances (figure 12.3) utilise des ratios de tailles et de couleurs pour
comparer les valeurs de deux mesures pour chaque élément de la vue :
• la taille de case représente la première mesure ;
• la couleur de case représente la seconde mesure.
En un seul coup d’œil, il est possible d’évaluer l’importance de ces mesures

appliquées à la requête. Par exemple, si la taille correspond aux ventes et la couleur,
aux bénéfices, vous pouvez :
• Évaluez les performances en vous posant des questions telles que « Quel produit
a réalisé les plus fortes ventes au cours du quatrième trimestre 2002 ? » (plus
grande taille affichée dans l’angle supérieur gauche : SE200) et « Quel est le produit
qui a réalisé la meilleure progression ? » (couleur claire en bas à gauche : CA 635).
• Identifiez des opportunités d’amélioration en vous demandant : « Pourquoi,
malgré sa position en tête des ventes (case la plus grande), le produit MI-562
a-t-il réalisé une progression médiocre (couleur la plus foncée) ? »
• Identifiez les exceptions en vous demandant : « Pourquoi tel produit réalise-t-il
des ventes inférieures aux autres produits doublées d’une faible progression
(petite taille et couleur noire) à celles des autres produits durant la même
période ? »
Figure 12.3 — Carte de performances
12.1.3 La vue en perspective

Une vue en perspective ressemble à un nuage de points, à ceci près qu’elle offre
des informations plus détaillées et plus nombreuses. Elle affiche les performances de
grandes quantités de données en fonction de deux mesures.
12.2 Proclarity Analytics Server (PAS) 355
Elle permet de répondre à des questions telles que :

• Quels sont les clients avec lesquels je fais le plus de bénéfices ? (Quelle est la
part du bénéfice par rapport à la rentabilité ?)
• Quel est le rapport entre le chiffre d’affaires prévisionnel et le chiffre d’affaires
réel ?
• Quel est le rapport entre le budget et la situation réelle ?
La vue en perspective (figure 12.4) est utilisée pour mettre en évidence les
relations entre de nombreuses représentations de données. Elle permet d’effectuer
une analyse sectorielle, d’expliciter d’importants volumes de données et d’établir des
correspondances entre plusieurs mesures simultanément au sein d’une hiérarchie.
Lorsque vous déplacez les règles mobiles statistiques, vous pouvez vous concentrer
sur un pourcentage donné de la valeur totale. Vous pouvez, par exemple, déplacer la
règle pour afficher les quatre-vingts premiers pour cent du chiffre d’affaires et 80 %
des quantités.
Figure 12.4 — Vue en perspective permettant de comparer les quantités vendues sur Internet
avec le montant des ventes (chiffre d’affaires)
12.2 PROCLARITY ANALYTICS SERVER (PAS)

Analytics Server permet de fournir des analyses basées sur le Web auprès d’utilisateurs
disposant d’un simple navigateur (zero footprint).
PAS Intègre un serveur de cubes. Les tableaux sont accessibles grâce à des vues
stockées dans des livres. Chaque livre fait l’objet d’une sécurité particulière au moyen
du gestionnaire d’administration du serveur PAS. La sécurisation des cubes (accès aux
dimensions, aux mesures, etc.) est effectuée dans Analysis Services 2008.
Analytics Server est le composant central de la plate-forme de Business Intelli-
gence (figure 12.5). Les utilisateurs peuvent manipuler leurs données, les analyser et
communiquer des tableaux au moyen d’une grande variété d’interfaces.
Les administrateurs disposent d’un outil leur permettant de centraliser les droits
d’accès aux librairies en un endroit unique.
Figure 12.5 — Plate-forme de Business Intelligence de Proclarity
Le serveur analytique centralise la définition de rapports préétablis dans un livre

(briefing book).
La publication du livre sur le serveur PAS autorise son exploitation via un
navigateur Internet. La figure 12.6 montre les différents onglets permettant d’effectuer
tous types de traitements sur les rapports. L’onglet navigation rassemble des fonctions
de Drill down (forage vers le bas), de Drill Up (forage vers le haut).
Figure 12.6 — Rapport stocké sur la plate-forme analytique permettant une navigation
dans un cube OLAP sur le Web
L’onglet Data Layout permet de disposer les mesures et les dimensions sur la surface
du dessin.
L’onglet View permet de choisir le type de graphe. L’onglet Sort effectue des tris
sur les données. L’onglet Filter autorise des filtres sur les sources de données ;
Ces onglets sont détaillés dans les figures 12.11 et suivantes.
L’interface d’administration est composée de deux parties : la gauche présente les
composants tels que les librairies et les rôles, la droite fournit les détails des répertoires.
Le lecteur pourra découvrir par lui-même le mode de fonctionnement de cet outil
en se connectant sur le site de l’auteur www.buroformatic.com.
Figure 12.7 — Console d’administration du serveur analytique de Proclarity
Dans la figure 12.7 on observe la console de management de PAS. Celle-ci fait

apparaître le serveur composé de librairies, de rôles et d’utilisateurs. Chaque librairie
et chaque livre qui la compose font l’objet d’une autorisation d’accès explicite. Dans
la partie de droite on observe les rapports appartenant à chaque librairie.
Les Librairies sont créées sur le serveur analytique par les utilisateurs autorisés à
l’aide de Proclarity Professional. Lors de la création d’une librairie, le dossier Books
est créé. Il rassemble les rapports partagés sur le serveur.
Le répertoire Components contient les logiciels distribuables auprès des utilisateurs
sur le Web. Par exemple, le composant Web Professional peut être autorisé au
téléchargement afin de permettre la création de rapports sur le Web.
Le répertoire des Rôles contient des groupes d’utilisateurs.
Le répertoire des Users contient les comptes individuels ajoutés au serveur
analytique. Par défaut PAS (Proclarity Analytic Server) refuse les droits de publication
ou de fournir des liens vers les livres de rapports via e-mail.
Figure 12.8 — Détail de la console d’administration de Proclarity
Le serveur Proclarity agit comme une sorte de portail intégrant des rapports
d’origines différentes telles que Reporting Services. La figure 12.9 montre l’intégration
d’un Rapport des ventes élaboré avec Reporting Services dans une interface Proclarity.
Figure 12.9 — Reporting Services encapsulé dans le portail Proclarity

Les outils disponibles dans l’interface web sont nombreux. La figure 12.10 montre
une sélection de sets (ensemble de données). Les boutons ADD ou Remove permettent
d’ajouter ou de retirer les sélections.
Figure 12.10 — Le gestionnaire de hiérarchie
L’onglet Navigation
Sur le web il existe deux modes de navigation : standard et Professional. Le mode
standard ne nécessite aucun ajout ou téléchargement de contrôle activeX. Le mode
Professional n’est disponible que si l’application Proclarity Professional est installée sur
le poste client.
Figure 12.11 — Navigation en mode web

Dans la même interface web, il est possible de recourir à tous types de navigation
(figure 12.11) tels que Drill down, Drill Up, Expand (développer), Show only (sélection-
ner un membre seulement) ou Hide (cacher tel ou tel membre de dimension).
L’onglet View
L’onglet View permet de choisir les types de graphiques, d’ajouter des options de
totalisation par ligne et colonnes ou de supprimer les hiérarchies dimensionnelles
(figure 12.12).
L’onglet Sort permet de trier toute colonne en ordre ascendant ou descendant tout
en préservant les groupes hiérarchiques.
Figure 12.12 — L’onglet View
L’onglet Filter permet de sélectionner ou cacher des lignes selon les critères habituels :
les n meilleurs, les x valeurs les plus basses. Les valeurs au-dessus, au-dessous ou entre
des bornes. Il est possible de fournir les valeurs en pourcentages ou en sommes de
mesures.
12.3 Dashboard Server 361
L’utilisateur dispose d’un choix de fonctions (figure 12.13) permettant de sauve-

garder ses vues personnelles afin d’organiser son propre environnement d’analyse. Il
peut également imprimer sur l’imprimante disponible ou exporter les données dans
la version d’Excel installée sur le poste utilisateur. L’envoi par e-mail permet de faire
parvenir un lien au destinataire. Ce lien exécute un accès sécurisé au serveur afin de
fournir des données dynamiques et à jour.
Figure 12.13 — Différentes options d’envoi de documents
L’envoi par mail d’un rapport au format PDF est également possible grâce à
la fonction imprimer. La figure 12.13 montre les différentes options d’envoi de
documents (Imprimante, Excel, Messagerie électronique, serveur PAS etc.)
Les utilisateurs qui disposent d’une version Proclarity Professional installée sur le
poste peuvent aussi créer et publier de nouveaux rapports sécurisés.
PAS gère toutes les connexions et les droits d’accès aux cubes. Dans un environne-
ment de clusters, PAS permet un accès simultané de plusieurs milliers d’utilisateurs.
Les techniques de caching optimisent les performances.
12.3 DASHBOARD SERVER
Dashboard Server requiert une installation complémentaire. Le tableau de bord permet

de regrouper de façon très synthétique un grand nombre d’applications telles que
Reporting Services grâce à des liens ou des portlets embarqués dans le portail.
Figure 12.14 — L’interface de Proclarity Dashboard offre les fonctionnalités d’un portail
Il y a fort à parier que Proclarity Dashboard et Business Scorecard Manager

fusionneront en une nouvelle version.
12.4 SHAREPOINT PORTAL SERVER ET

PERFORMANCEPOINT SERVER 2007
Au sein de la Galaxie Microsoft, les outils de restitution de l’information sont
nombreux et parfois leurs fonctionnalités se chevauchent. De ce fait il est parfois
difficile de choisir l’outil permettant de répondre à telle ou telle question.
Nous avons évoqué Reporting Services pour les rapports prédéfinis.
Report Builder 1.0 pour la création de rapports ad hoc s’adressant à des utilisateurs
non spécialistes. Report Builder 1.0 nécessite la création et le déploiement préalable
d’un modèle de rapport (Report Model). Il s’agit de représenter le métier de l’utilisateur
sous forme d’entités et d’attributs. (accès aux cubes et bases relationnelles).
Nous avons parlé de Report Builder 2.0 associé à la version de Reporting Ser-
vices 2008. Cette version ne nécessite pas obligatoirement la création d’un Report
Model préalable. Cette nouvelle version, très puissante et complète, convient à des
utilisateurs avancés.
Excel 2003/2007 est un outil idéal pour la création de tableaux croisés dynamiques
en accès direct à des cubes Olap. Excel peut également être un outil de restitution de
bases relationnelles. Nous avons également présenté l’add in Excel pour les versions
12.4 SharePoint portal server et performancepoint server 2007 363
2003 et 2007. Nous avons également montré la facilité de création de tableaux et

graphes croisés dynamique sur le Web grâce au composant Office Web Component
(OWC).
Proclarity, totalement orienté cubes OLAP permet de créer côté utilisateur des
KPI (Indicateurs de performance clé). Des fonctions avancées permettent également
des filtrages et sélections élaborées sur des cubes. Le code MDX peut être récupéré et
intégré par le développeur dans le cube OLAP 2008.
En complément de SQL Server 2008, Microsoft a mis à disposition du manager un
outil de gestion de la performance. PerformancePoint Server comporte trois modules :
• PerformancePoint Monitor – Le module Monitor répond à la notion de pilotage
de la performance des organisations. Ce module répond essentiellement à des
questions telles que : « Que se produit-il l’entreprise » ou bien que s’est-il
produit ? PerformancePoint Monitor entre dans le cadre d’application de
sorecarding ou de tableau de bord ;
• PerformancePoint Analytics – A la différence de Monitor, le module Analytics
répond à la question pourquoi cela se produit-il ? Ce module intègre le produit
Proclarity dans sa version 6.3. Il s’appuie exclusivement sur les cubes OLAP,
organisation des données orientée analyse. On regrettera dans cette version 6.3
intégrée à PerformancePoint 2007 la disparition du module Business Reporter
encore présent dans la version 6.2 de Proclarity. Ce module permet une
intégration totale de Proclarity à Excel 2003/2007 sous forme d’un menu dans la
barre d’outils. Il permet également une mise en page libre des tableaux croisés.
Souvent, les observateurs utilisent ce module afin d’analyser finement les
indicateurs clés de performance (KPI) grâce à la technique du drill down
(forage), slicing (tranchage), dicing (cube) et filtrage.
• Performance Point Planning – Alors que Monitor répond à la question Quoi ?
Analytics à la question Pourquoi ? Planning répond à la question Comment ? Les
applications de Performance Point Planning ont pour but de planifier, budgétiser,
effectuer des prévisions et des consolidations financières.
SharePoint représente l’outil principal pour la création de tableaux de bord.

Depuis avril 2009, les modules PerformancePoint Monitor et PerformancePoint
Analytics sont fournis sans coût supplémentaire avec le portail SharePoint Server.
Microsoft a annoncé, pour la même date, l’arrêt du module PerformancePoint
Planning. Ce dernier module n’est donc pas livré dans SharePoint.
Figure 12.15 — Intégré dans Sharepoint Portal, tableau de bord faisant apparaître les indicateurs
clés de performance
PerformancePoint Server est composé de plusieurs éléments :

• Le gestionnaire de Web service.
• Le prévisualiseur de tableau de bord.
• Monitoring Server permet aux utilisateurs de travailler avec Dashboard Designer
et de disposer d’un site de prévisualisation.
• Gestionnaire de Base de données système.
Figure 12.16 — Gestionnaire de configuration du serveur
Concepts applicatifs
Les tableaux de bord sont généralement constitués de scorecards et de rapports
assemblés dans un site SharePoint. Ces tableaux fournissent aux organisations une
vue unifiée de la performance au travers d’espaces métier complémentaires. Nous
renvoyons le lecteur au chapitre 2.2 de cet ouvrage afin de revoir les perspectives
stratégiques de l’entreprise définies par MM Norton & Kaplan dans le modèle unifié :
le balanced scorecard ou tableau de bord équilibré.
Figure 12.17 — Tableau de bord de PerformancePoint permettant de mettre en avant

la perspective financière
Les scorecards sont des collections d’indicateurs stratégiques (KPI) représentant

l’activité passée et pour lesquels des objectifs ont été définis. Les écarts du réalisé par
rapport à l’objectif sont matérialisés par des icônes visuelles dont la signification ne
peut échapper au lecteur (vert = objectif atteint, jaune = performance moyenne, rouge
= performance médiocre). Le code couleur permet au lecteur de se focaliser rapidement
sur les zones à risques. Généralement les KPI sont complétés par un indicateur
de tendance matérialisé par une flèche dont l’orientation donne la performance
temporelle. En effet, bien que l’objectif n’ait pas été atteint (icône triangulaire ou
jaune), la tendance ou la progression d’une année sur l’autre peut être bonne (flèche
orientée vers le haut).
Plusieurs méthodologies peuvent participer à la mise en forme de tableau de bord.
Rappelons les principales :
• Balanced scorecard.
• Six Sigma.
• CMMI (Capability Maturity Model Integration).
• Agile.
• CRM.
Figure 12.18 — Le balanced scorecard est généralement composé des axes (Financier, Clients,
Processus, Ressources humaines) et complété de la carte stratégique
Figure 12.19 — La carte stratégique
La carte stratégique est représentée par un diagramme décrivant comment une

organisation peut créer de la valeur. Il s’agit de connecter les objectifs stratégiques sur
les quatre axes principaux de l’entreprise dans des relations de cause à effet. La carte
stratégique se lit de bas en haut : on observe que les choix judicieux lors du recrutement
des personnels permet d’optimiser les processus clés de l’entreprise (Marketing, R&D,
CRM). Ces processus contribuent à leur tour à fournir de la valeur aux clients (services
et produits de qualité mesurés par les questionnaires clients). Les clients génèrent à
leur tour de la valeur financière aux actionnaires (marges, profit).
Il s’agit d’un processus récursif car il est clair que la valeur financière apportée aux
actionnaires impacte fortement le personnel (participation, embauches, moral etc.).
12.5 Conclusion 369
12.5 CONCLUSION
• Des prises de décision collaboratives – On l’a vu, l’analyse collaborative
commence par l’organisation de l’information en un point d’accès unique
accessible à tous les utilisateurs.
Le portail collaboratif permet également d’imposer une vision unique des indi-
cateurs clés et des métriques, et de lier la stratégie à l’exécution opérationnelle.
Les échanges sont ainsi facilités autour de la compréhension de ces métriques et
de leur impact sur les performances de l’entreprise.
• Une information fidèle à la réalité – Au-delà de la vision chiffrée issue du
système d’information, il est important d’associer des informations de différentes
natures, qui peuvent être apportées par l’ensemble des employés concernés.
Il s’agit de présenter des éléments d’informations qualitatives qui donnent à
l’utilisateur une vision transversale de la situation. L’utilisateur peut apporter
son analyse personnelle. Les commentaires et documents renforcent l’efficacité
des jugements et des actions à engager.
• De l’analyse à l’action – Piloter et analyser en profondeur les leviers de la
performance est un des fondements des solutions décisionnelles. Toutefois, leur
efficacité devient relative lorsqu’il s’agit de prendre des actions pour corriger une
situation. C’est précisément l’objectif de la Business Intelligence collaborative
qui permet d’améliorer la qualité des actions engagées et d’accélérer leur mise
en œuvre. Initier des plans d’actions, créer des espaces collaboratifs autour
d’un objectif critique et gérer les processus autour de workflows donne enfin à
l’utilisateur de vrais leviers pour agir.
13
Passez à l’action !
Tous les projets ne se ressemblent pas et tous les chefs de projets sont différents.
Commençons par le premier constat. La gestion d’un projet décisionnel (BI)
est différente de celle d’un projet traditionnel car elle implique un grand nombre
de technologies différentes, tant sur le plan logiciel que matériel. En outre, les
projets traditionnels de développement de logiciels impliquent une méthodologie
de développement linéaire, alors que les projets de BI exigent une approche itérative.
L’approche itérative débute par l’étude des besoins, l’ébauche du modèle analytique, sa
mise à disposition auprès des utilisateurs et les corrections qui s’imposent en fonction
de l’adéquation des résultats obtenus par rapport à ceux attendus et des contraintes
d’évolution du métier.
Les projets BI exigent également de l’équipe projet d’avoir une plus grande
interaction avec un large périmètre fonctionnel, rassemblant des interlocuteurs
compétents en systèmes d’information ainsi que des analystes et managers.
Pour réussir dans le domaine de la BI, une équipe de projet doit être composée
de membres ayant une forte composante métier conjuguée à une bonne compétence
technique.
Ces contraintes exigent souvent une connaissance approfondie sur le sujet traité
(finance, marketing, achats, etc.).
Naturellement, la maîtrise des technologies essentielles telles que l’intégration de
données, la modélisation ou l’analyse d’entreprise est indispensable.
372 Chapitre 13. Passez à l’action !
13.1 LES CARACTÉRISTIQUES DU CHEF DE PROJET

DÉCISIONNEL
Les personnes qui se cachent derrière les projets sont les pilotes fondamentaux du
succès. Elles doivent posséder un large éventail de qualifications afin d’être efficaces.
Au cours de ces dernières années, nous avons travaillé sur de nombreux projets BI,
en revêtant tour à tour le rôle d’analyste, d’architecte ou de technicien des systèmes
d’information.
Nous avons travaillé avec des chefs de projets exceptionnels. Mais nous avons
aussi hérité de projets enlisés par manque de compétence des acteurs ou par absence
de volonté de la part de la direction.
Notre expérience dans le domaine des projets décisionnels nous a amené à définir
les caractéristiques essentielles du chef de projet décisionnel.
13.1.1 Être bien informé

Au-delà de la maîtrise d’une méthodologie de gestion de projet, un chef de projet BI
doit être bien informé des contraintes du métier traité ainsi que des aspects techniques
du projet.
Les chefs de projet qui réussissent se tiennent constamment informés des avancées
les plus récentes en matière de BI. Un chef de projet qui veut affirmer son leadership
sur son équipe doit imposer des méthodes éprouvées aussi bien face aux responsables
métier que face aux techniciens du datawarehouse.
Les bons chefs de projet en BI ont une grande connaissance des architectures
techniques ainsi que des liens existant entre les données opérationnelles et le modèle
dimensionnel de l’entrepôt de données.
Le chef de projet compétent a une conscience objective de son niveau de
connaissance. Il est capable de mesurer ses propres lacunes et de les combler par
une assistance complémentaire. Son seul but est la réussite globale du projet.
13.1.2 Être expérimenté

Ils sont peu nombreux, les chefs de projets disposant d’une expérience en tant que
chef de projet BI et ayant une connaissance des outils de mise en œuvre.
Une connaissance théorique de la gestion de projets BI est certes nécessaire.
Cependant, pouvoir anticiper les problèmes dès la phase conceptuelle est un atout
supplémentaire qui ne peut résulter que d’une expérience de terrain. Pouvoir déceler
dès le départ certaines carences dans la mise à disposition des données évite un
enlisement probable. Le processus itératif, dans la mesure où il ne remet pas en cause
le schéma initial, permet de réagir positivement aux demandes d’adaptation liées à
une meilleure appréciation des besoins. Idéalement, le chef de projet BI aura assumé
par le passé plusieurs rôles différents dans des projets antérieurs.
13.1 Les caractéristiques du chef de projet décisionnel 373
En plus de l’expérience pratique des projets BI, un chef de projet efficace doit
contrôler l’étendue du projet et de son budget. Ceci exige de sa part qu’il surveille
activement l’avancement des tâches, les livrables, le temps passé et les dépenses
occasionnées par chaque membre de l’équipe projet. En contrôlant activement tous
ces points, le chef de projet peut déterminer l’impact d’une demande de changement
et les risques de dépassement de budget.
13.1.3 Leadership
Tout le monde ne dispose pas des qualifications ou des qualités personnelles nécessaires
au contrôle d’un projet informatique. Un chef de projet doit pouvoir être source
d’inspiration et forcer le respect, vis-à-vis des membres de l’équipe projet mais
également vis-à-vis des commanditaires et des représentants de la communauté
d’utilisateur. Cela exige du chef de projet de pouvoir gérer les attentes de ceux à
qui il rapporte directement aussi bien que de ceux qui lui rapportent directement.
Le chef de projet doit construire une équipe formée d’individus qui possèdent
différentes qualifications et si possible complémentaires. Développer une équipe aux
compétences croisées représente un réel défi parce que les membres sont souvent issus
de disciplines et de milieux différents. Cela exige du leader une volonté d’unir des
membres pour le bien commun de l’équipe et le succès du projet.
Le chef de projet doit également maîtriser la gestion des conflits et l’art de la
négociation. On constate cependant que beaucoup de dirigeants manquent tout
simplement de compétences dans l’art de manager les hommes.
13.1.4 Compétences en organisation

Les meilleurs chefs de projet BI sont très organisés et adhèrent aux principes de base
de la gestion de projet. Cela exige d’eux de développer et soumettre pour approbation
un plan formel de projet intégrant les livrables, les charges, la chronologie des tâches
et le budget.
Une fois que le planning a été approuvé, le chef de projet surveille activement
l’avancement des travaux par rapport au plan. La seule manière de communiquer
l’état d’avancement du projet est de tenir des réunions hebdomadaires auxquelles sont
conviés tous les membres de l’équipe, les commanditaires du projet et le comité de
coordination de projet. En conduisant ces réunions régulièrement, tous les acteurs du
projet sont informés de l’avancement, des problèmes éventuels et des retards qui en
découlent.
13.1.5 Compétences en communication

Pour être un chef efficace, un individu doit également être un grand communicateur.
Un chef de projet efficace transmet ses messages de manière compréhensible afin
d’être entendu par l’ensemble des acteurs. Cela exige des capacités de communication
écrite et orale. La communication claire et concise est indispensable au soutien de la

solution par la communauté des utilisateurs.
Le succès d’un projet BI est intimement lié à la compréhension de l’utilité et à
l’efficacité de la solution développée. Si les utilisateurs ne parviennent pas à utiliser
simplement la solution ou ne comprennent pas les avantages qu’elle leur fournit,
pourquoi devraient-ils changer leur comportement ? La communication efficace est
essentielle aux attentes des gestionnaires. De plus elle instruit les utilisateurs et
encourage les individus à accepter plus facilement le changement.
13.1.6 Qualités personnelles

De notre point de vue, il y a quelques traits personnels qui distinguent de bons chefs
de projet de ceux qui sont exceptionnels. Tout d’abord, il y a l’honnêteté et le désir
de franchise dans les communications. Un excellent chef de projet sait nuancer son
attitude, qui peut être ferme et claire afin d’insister sur un point précis ou remplie de
tact pour ne pas détériorer des relations ou endommager des rapports entre individus.
L’honnêteté stimule la confiance et le respect entre les membres de l’équipe projet et
les sponsors.
En second lieu, les chefs de projet BI exceptionnels sont positifs, ce qui ne signifie
pas d’un optimisme béat. Un optimiste espère toujours que le meilleur arrivera en
dépit des difficultés, et ne parvient pas à anticiper les problèmes avant qu’il ne soit trop
tard. D’autre part, une attitude positive inclut une certaine quantité de scepticisme et
une bonne compréhension des réalités de la situation.
Troisièmement, les excellents chefs de projet BI sont clairvoyants et peuvent
identifier des sujets de préoccupation avant qu’ils ne deviennent de vrais problèmes.
Tandis que la perception est influencée par l’expérience, la capacité à identifier
ces difficultés réduit considérablement le risque et permet au projet de continuer
d’avancer.
13.1.7 Apprendre des expériences passées

Les excellents chefs de projet possèdent de nombreuses qualités acquises au fil de
leur parcours professionnel, et sont influencés par leurs expériences précédentes. Les
caractéristiques communes d’un tel chef de projet sont ces traits qui les distinguent de
leurs confrères. Le succès d’un projet BI repose sur le chef de projet et sa capacité à
composer avec les courants politiques de l’organisation tout en cherchant l’appui du
commanditaire de projet et du comité de coordination.
13.2 QUEL EST LE RETOUR SUR INVESTISSEMENT ?

Il est important de considérer que ce qui compte n’est pas ce que l’on sait mais bien
ce que l’on fait avec ce que l’on sait. De la même manière, tout actif d’entreprise n’a
de valeur que si l’on en fait quelque chose.
13.2 Quel est le retour sur investissement ? 375
Dans le monde de la BI, il convient d’observer que des investissements sont néces-
saires à la construction d’un environnement dans lequel les données se transforment
en connaissance. Mais le réel bénéfice provient de l’action générée par la connaissance.
Cela signifie simplement que chaque organisation ne fait pas simplement que produire
de l’information. Elle dispose de méthode pour extraire de la valeur de la connaissance,
agir en conséquence et mesurer l’efficacité de son action. Il s’agit là non pas d’un
problème technique mais bien d’organisation. Identifier une connaissance « active »
est une chose, mais réaliser l’action requise nécessite une organisation agile et
fortement réactive.
Les gestionnaires évaluent sans cesse les coûts comparés aux avantages de telle ou
telle option. La compréhension et la quantification des coûts comparés aux bénéfices
sont nécessaires afin de répondre à une telle question.
De plus en plus souvent, les chefs de projet sont invités à évaluer le coût relative-
ment à l’avantage d’entreprendre un projet de Business Intelligence. Plusieurs mesures
financières peuvent être retenues telles que le taux interne de rendement (IRR), la
valeur nette (NPV), la période de remboursement et le retour sur l’investissement
(ROI). Chacune de ces mesures présente des avantages. Cependant, une mesure
généralement admise est le ROI.
Les composants de cette stratégie comportent une analyse des coûts, un accrois-
sement des revenus liés à cette activité, et d’autres bénéfices. On peut distinguer les
points suivants :
• les coûts fixes liés à l’acquisition de l’infrastructure (achats du datawarehouse et
des licences de base) ;
• les coûts variables associés à l’activité. (achat des licences des outils de restitu-
tion) ;
• les coûts induits par la maintenance de l’activité ;
• la valeur des bénéfices dérivés des actions induites par la connaissance ;
• le modèle de valeur attendu de cette activité ;
• la détermination à rentrer dans ses frais tout en proposant un modèle de
profitabilité.
Les coûts directs sont des dépenses réelles qu’une organisation peut clairement
identifier. Ils incluent le prix d’achat du logiciel, des honoraires de maintenance, des
dépenses de développement générant des coûts de main-d’œuvre internes et externes.
S’ajoute à cela des coûts de logiciels et de formation des utilisateurs.
Les coûts indirects sont plus difficiles à identifier ou mesurer. Puisqu’ils se pro-
duisent habituellement après le démarrage de l’application, ils ne sont pas souvent
inclus dans le coût de mise en œuvre d’un projet décisionnel. Cependant, ces coûts
indirects sont une composante importante du coût global. Ils intègrent la mise à niveau
des postes client, des infrastructures de réseau, la mise à niveau des logiciels, le soutien
des utilisateurs et leur formation aux nouvelles applications. La compréhension du
coût total est impérative pour que le projet ne sorte pas du cadre du budget.
Le chiffrage des différents composants du projet tels que les coûts de logiciel et des
honoraires de maintenance et le coût moyen de configuration peuvent être obtenus
auprès de ressources externes. Les coûts estimatifs de déploiement de l’application
feront partie intégrante du calcul du ROI.
Si le modèle ne permet pas clairement de rentrer dans ses frais il convient d’être
circonspect sur la nécessité d’entreprendre ce chantier.
La formule communément admise pour le calcul du ROI est la suivante :
ROI = [(Économies réalisées – Investissement)/Investissement)] × 100
Exemple
La société Adventure Works Cycles souhaite mettre en place un projet décisionnel
afin d’offrir à son personnel des outils d’interrogation et de reporting. Cependant,
compte tenu de l’engagement financier important, le sponsor du projet et la direction
générale veulent connaître le ROI généré par le projet BI. Afin d’établir des éléments
de comparaison, on estime la charge de travail actuelle du reporting à 120 heures/mois.
On calcule les coûts de la mise en place d’un nouveau développement BI. Ils sont
synthétisés dans le tableau 13.1.
Tableau 13.1 — Coûts de la mise en place d’un nouveau développement BI
Dépenses Coût
Matériel 5 000 €
Logiciel (SQL Server Enterprise) 25 000 €
Main-d’œuvre (chef de projet + développeur) 35 000 €
Total 65 000 €
Durée estimée du projet : trois mois.

Tableau 13.2 — Maintenance et support
% du temps Coût en €
Fonction
de travail (2 000 h/an)
Administrateur de base de données 5% 7 500
Administrateur système 5% 7 500
Administrateur réseau 5% 7 500
Total 22 500
Le coût de maintenance des logiciels est de 10 % par an.

Le nombre d’heures de travail par individu est de 2000 par an.
13.3 Faire une offre de solution décisionnelle 377
Tableau 13.3 — Calcul du ROI sur un horizon de trois ans
Adventure Works Cycles ne déployant pas de projet BI
Année 0 Année 1 Année 2 Année 3
Main-d’œuvre (120 h/mois) 108 000 108 000 108 000 108 000
Adventure Works Cycles déployant un projet BI
Matériel 5 000
Logiciel 25 000 2 500 2 500 2 500
Main-d’œuvre 35 000 22 500 22 500 22 500
Total investissement 65 000 25 000 25 000 25 000
Résultats
Économie n/a 83 000 83 000 83 000
Le salaire horaire moyen est estimé à 75 €.

L’économie réalisée sur les trois premières années est de 249 000 €.
Total de l’investissement des quatre premières années = 140 000 €.
ROI = [(249 000 – 140 000)/140 000)] × 100
Soit un ROI de 78 % sur 3 ans.
Ce rendement peut être considérablement accru dans le cas où la société Adven-
ture Works Cycles commercialisant un grand nombre de marques décide de fournir
l’accès aux données à chacun de ses fournisseurs. Créant un portail décisionnel à haute
valeur ajoutée pour ses fournisseurs, elle peut en attendre un loyer mensuel basé par
exemple sur le chiffre d’affaires réalisé.
Dans l’exemple ci-dessus nous avons volontairement comparé un système manuel à
un système automatisé. Nous n’avons pas intégré des notions telles que l’amélioration
considérable de la qualité des données, de la rapidité de leur mise à disposition et de
leur diffusion, ainsi que la disponibilité d’analyses permettant d’effectuer des choix de
gestion pertinents grâce à des observations qu’il était impossible de réaliser dans un
système manuel.
13.3 FAIRE UNE OFFRE DE SOLUTION DÉCISIONNELLE

La mise en œuvre d’une solution décisionnelle nécessitait jusqu’à présent un budget
conséquent et une maintenance très lourde. Toutefois, depuis que la démocratisation
de l’informatique décisionnelle s’est mise en marche, la donne a considérablement
changé. Le développement d’offres de plus en plus packagées et complètes ainsi que la
naissance d’outils de reporting orientés utilisateurs facilitent grandement l’accès à une

version unique et vérifiée de l’information selon le format désiré.
En guise de synthèse de cet ouvrage, nous proposons une démarche progressive
et concrète de mise en place de solutions décisionnelles, quelle que soit la taille de
l’organisation considérée.
Dans sa plus simple expression, la solution est articulée autour de deux éléments :
• SQL Server 2008 côté serveur ;
• Office 2003 côté client.
Le serveur SQL Server comporte de manière intégrée tous les éléments nécessaires
à une solution décisionnelle :
• un ETL d’entreprise, Integration Services, pour l’extraction, la transformation
et le chargement des données à partir de n’importe quelle source ;
• une base de données relationnelle intégrée à un moteur multidimensionnel
OLAP ;
• un serveur de rapport, Reporting Services, qui permet des restitutions d’infor-
mations sous toutes formes. (reporting de masse, reporting ad hoc).
Côté client, notre solution comporte :

• Excel complété par un add-in Excel pour les besoins de simulation ;
• les Office Web Components pour un accès via le Web ;
• SharePoint Portal Server, pour le partage des graphiques et tableaux croisés
dynamiques sur l’intranet ou le portail d’entreprise ;
• optionnellement, MapPoint peut être intégré au dispositif pour une représenta-
tion cartographique ou à des fins de « géo-analyse » ;
• Proclarity, nouvel add-in de Microsoft, pour une meilleure visualisation des
données et un serveur de cubes sur le Web ;
• un serveur de Business Performance Management (Business Scorecard Manage-
ment) permettant une mise en place et un suivi de tous types d’indicateurs clés
de performance.
Il est conseillé d’avoir connaissance des évolutions de ces deux produits dans la
stratégie Microsoft. En effet, Microsoft annonce Office PerformancePoint pour le
premier semestre 2007. Il s’agit d’une application de planification, de budgétisation et
de prévisions. D’après les informations en notre possession lors de la rédaction de cet
ouvrage, il semblerait que cette appellation englobe Proclarity et Business Scorecard
Management au sein de SharePoint.
Sources DataMarts Reporting
Analyses
ERP détaillées
Outils familiers
(Excel,
Navigateur,…)
CRM
Applications tierces Rapports
interactifs
LOB SQL
Server Terminaux
Tableaux
de bord
Stockage Analyse Reporting
Intégration Analysis Reporting

Services Services Services
Figure 13.1 — Les composants d’une offre décisionnelle globale
13.3.1 Un ETL d’entreprise, Integration Services

L’accès aux données – dispersées dans différentes parties du système d’information
des entreprises, selon de multiples sources – nécessite la mise en place de protocoles.
Simplifier cette étape est indispensable pour pouvoir ensuite manipuler les données,
les confier aux utilisateurs et améliorer la diffusion d’information dans l’entreprise.
Un ETL extrait les données de sources hétérogènes, les transforme et les réinjecte
dans une nouvelle base, le datawarehouse. Cela permet de nettoyer et transformer les
données. Une seule source de données est ensuite interrogée par l’outil de restitution.
Le module d’ETL qui porte le nom d’Integration Services (SSIS) permet une
intégration des données en provenance de diverses sources hétérogènes vers les
environnements d’aide à la décision (moteur OLAP, datamart, datawarehouse) ou tout
autre type d’application. Les caractéristiques majeures de SQL Integration services
sont les suivantes :
• service de transfert de données (ETL) ;
• accès à tous types de sources de données (SGBD tiers, mainframe, fichiers,
ODBC, XML, ERP, CRM...) ;
• transfert et conversion des données à l’aide de scripts ;
• planification de l’exécution des tâches ;
• moteur d’agrégation ;
• support des environnements 64 bits ;
• intégration avec le reste des composants ;
• les fonctions de SSIS sont exposées au travers d’un modèle objet ;
• migration depuis DTS 2000 ;
• signature des packages à l’aide des certificats ;

• visualisation en temps réel des données traitées ;
• possibilité de créer des points de reprise ;
• débogage facilité par l’insertion de points d’arrêt ;
• environnement de développement intégré à Visual Studio.
13.3.2 Un SGBD pour la gestion des gros volumes de données

SQL Server 2008 gère à la fois des bases de données de taille modeste mais aussi de
très grandes bases de données (plusieurs dizaines de téra-octets).
Les fonctionnalités de partitionnement des données, de restauration (récupération
rapide et restauration en ligne), d’opérations de gestion (ré-indexation en ligne, etc.),
d’isolation des transactions, permettent de mieux répartir la charge et de travailler sur
une base en permanence disponible.
13.3.3 Une architecture qui garantit la disponibilité des données

SQL Server 2008 permet la mise en place de solutions de haute disponibilité, tout
en minimisant les charges d’administration et d’exploitation. Par exemple, la mise en
miroir (nouvelle fonction de SQL Server 2008) permet un basculement automatique
pour les applications clientes en cas de défaillance d’un serveur, sans perte de données
et dans un temps très réduit.
13.3.4 Compatibilité, ouverture

Intégration des données : des sources de données de tous types peuvent être intégrées
dans les flux de transformation : Oracle, sources XML, services web, fichiers plats, etc.
Mécanisme de réplication : SQL Server peut être utilisé comme répliquat d’une base
Oracle.
Chaîne décisionnelle : le mécanisme UDM (Unified Dimensional Model) permet
l’intégration dans la chaîne décisionnelle de n’importe quelle source de données (base
ERP, CRM, relationnelle, multidimensionnelle...).
Reporting : pour créer des rapports depuis des bases de données non Microsoft, de
produire des rapports avec des outils tiers dans des formats au standard du marché
(PDF, XML, HTML, CSV, etc.).
SQL Server 2008 ajoute un support natif des services web et de XML dans la base
de données. Cela permet une gestion complète et optimisée des documents XML
dans la base de données et la possibilité d’ouvrir les services du moteur relationnel en
utilisant des standards du marché (services web).
SQL Server 2008 offre aussi une meilleure compatibilité avec les environnements
Oracle, et des interfaces sont disponibles pour SAP.
13.3.5 Productivité dans le développement d’applications

liées à SQL Server 2008
SQL Server 2008 intègre le framework d’exécution .Net et le moteur relationnel. Cette
intégration permet d’optimiser des traitements (fonctions et procédures SQL, etc.)
stockés dans la base de données en utilisant un langage de programmation classique
(C#, VB.Net, J#).
La création de projets et solutions autour de SQL Server 2008 (création de projets
d’ETL, de projets décisionnels, de projets de reporting, etc.) s’effectue désormais au
travers d’une interface unique : Business Intelligence Development Studio (Visual
Studio). Cette utilisation de Visual Studio permet d’une part une plus grande produc-
tivité pour les développeurs (débogage plus aisé, choix du langage de développement
le plus adapté), et une industrialisation plus poussée des développements (gestion de
sources, isolation des serveurs de développement et des serveurs de production). De
plus, le développeur peut s’appuyer sur les services de notification, de reporting, sur
une infrastructure complète de service pour se concentrer sur les aspects métier de son
application.
13.3.6 Administration renforcée

L’administration se fait via des interfaces graphiques : SQL Server 2008 introduit la
console d’administration SQL Server Management Console qui permet l’administra-
tion centralisée de l’ensemble des services SQL Server (moteur relationnel, moteur
OLPA, moteur ETL, serveur de reporting, mobilité) à travers un unique outil.
13.3.7 Sécurité
SQL Server 2008 introduit de nouvelles fonctionnalités qui renforcent la sécurité des
données et des échanges avec SQL Server :
• chiffrement des données ;
• chiffrement des échanges sur le réseau ;
• gestion des certificats ;
• filtrage des adresses IP pouvant invoquer un service web.
13.3.8 Analysis Services

Il s’agit de mettre en place une vision multidimensionnelle des données de l’entreprise
de sorte à croiser des axes et perspectives à l’aide de nombreuses mesures.
La composante multidimensionnelle du moteur SQL Server 2008 est Analysis
Services 2008. Elle apporte des fonctions d’analyse en temps réel, un framework
de création d’indicateurs de performance (KPI), de modélisation libre (plus grande
flexibilité en termes de création des cubes) et des fonctions de haute disponibilité à
son moteur OLAP. SQL Server 2008 améliore également son moteur de data mining,
permettant d’effectuer des découvertes au sein des datawarehouses.
13.3.9 Reporting
SQL Server 2008 comporte une plate-forme complète de reporting. De la création
de rapports au travers de Visual Studio, à la mise à disposition de ces rapports à
l’utilisateur via une intégration possible au portail ou à des applications métier.
Report Builder permet aux analystes métier de créer des rapports et tableaux
avec des fonctions de navigation interactive au sein des rapports. Report Builder est
complètement intégré à Reporting Services 2008. Les outils de reporting, une fois
déployés par les informaticiens, donnent aux managers une réelle indépendance pour
l’accès à leurs données.
Les différentes façons de créer un rapport

Il existe différentes manières de créer un rapport :
• pour les développeurs : Visual Studio ;
• pour l’utilisateur final : Report Builder ;
• importation de rapports depuis Microsoft Access ;
• via des outils partenaires ;
• génération de description de rapports en RDL.
Client Report Builder

Report Builder est destiné aux utilisateurs finaux pour leur faciliter la création de
rapports. Les utilisateurs n’ont pas besoin de comprendre la structure technique des
données sous-jacentes.
Les rapports sont construits sur la base de modèles développés à partir de Reporting
Services (table, matrice, graphique) et mis à disposition des utilisateurs sur le portail
intégré.
Les rapports sont directement sauvegardés sur le serveur de rapports. Les rapports
conçus par les utilisateurs peuvent être publiés et partagés sur le serveur.
13.3.10 Donner un véritable cockpit de pilotage de l’activité adapté

aux différents niveaux de l’organisation
Les Anglo-saxons mettent en place des salles de type Management Cockpit. Sans aller
jusqu’aux war-room (salles de guerre) présentes dans les grands groupes aux États-Unis,
la salle de Management Cockpit permet de réagir rapidement aux événements et
aux crises. Les murs de telles salles sont recouverts d’indicateurs visant à faciliter le
pilotage de l’entreprise. On retrouve souvent les indicateurs répartis selon les quatre
perspectives du Balanced Scorecard définis par MM Norton et Kaplan (Financier,
Client, Processus et apprentissage organisationnel).
L’ensemble des techniques présentées au cours de cet ouvrage peuvent être
regroupées au sein d’un schéma global de la plate-forme décisionnelle. La figure 13.2
montre les différentes couches qui composent cette plate-forme (couche physique
d’alimentation, couche applicative, couche de restitution).
13.4 Comment mettre en place un projet décisionnel ? 383
Figure 13.2 — La plate-forme décisionnelle
13.4 COMMENT METTRE EN PLACE UN PROJET

DÉCISIONNEL ?
Un projet décisionnel met en œuvre des technologies diverses et des savoir-faire dans
des domaines complémentaires. L’expérience parfois douloureuse des responsables
informatiques confrontés aux discours marketing des éditeurs de solutions de Business
Intelligence ont forcé les organisations à la prudence. Avant de s’engager définitive-
ment dans le choix de telle ou telle solution, les décideurs ont besoin de savoir si
les outils répondront aux exigences formulées par les demandeurs, mais également le
degré d’implication des différents acteurs de l’entreprise.
Il est maintenant acquis qu’une première étape d’étude de faisabilité est nécessaire
au processus de décision. La terminologie anglo-saxonne est Proof Of Concept (POC).
13.4.1 Objectifs de la preuve de faisabilité

Les objectifs sont les suivants :
• permettre dans un délai très court de formaliser les attentes du client et de les
matérialiser au travers d’un prototype personnalisé ;
• cerner les capacités de la solution et acquérir les connaissances de base ;

• une base de travail et de discussion avec les responsables techniques (archi-
tectes, DSI) et les utilisateurs (responsables des directions fonctionnelles ou
opérationnelles (finance, achat, marketing, commercial, communication, RH,
etc.)).
13.4.2 Faisabilité sur site

La démarche de faisabilité sur site inclut les étapes suivantes :
• Analyse des besoins.
• Interviews et questionnaires.
• Implémentation d’un prototype se basant sur les données du client.
• Présentation/analyse de la valeur/transfert de compétences.
13.4.3 Livrables
Les livrables sont :
• document de synthèse ;
• prototype ;
• licence à durée limitée du produit utilisé ;
• prévoir une durée d’étude de 10 jours.
L’étude de faisabilité peut déboucher sur le déploiement de la solution complète.

Voici un planning type pour le déploiement.
13.4.4 Planning pour le déploiement de la solution

Les points qui seront abordés sont les suivants :
• l’architecture globale ;
• le planning de la montée en charge ;
• les recommandations pour les configurations clientes ;
• les recommandations pour les configurations serveur ;
• les configurations d’installation des produits.
13.4.5 Prototype/pilote
Ce pilote sera conçu en fonction du cahier des charges défini précédemment.
Il faudra procéder à :
• l’installation sur un des serveurs de l’organisation cliente ;
• l’intégration des sources de contenus ;
• la mise en place et la personnalisation de la solution décisionnelle ;
• l’installation sur les postes client.
13.5 Conclusion 385
13.4.6 Opérations
Il faut définir les procédures opérationnelles principales et toutes les procédures de
contrôle :
• définition des procédures opérationnelles ;
• contrôle des performances ;
• optimisation des performances.
13.5 CONCLUSION
Le lecteur aura pu s’en rendre compte, MS SQL 2008 offre une réponse plus que
satisfaisante à la mise en œuvre de tout projet décisionnel. L’apprentissage d’un tel
outil permet de découvrir non seulement de nouveaux concepts liés au processus
décisionnels mais de les mettre rapidement en œuvre grâce à une boîte à outils
immédiatement opérationnelle.
L’apparente facilité de déploiement d’un projet décisionnel ne doit cependant pas
occulter l’impérative nécessité de procéder avec méthode. Tout commence par la
vision claire des objectifs à atteindre. Les outils ne sont que le moyen de mettre la
stratégie au service de l’entreprise.
N’oublions jamais que la phase la plus importante du cycle décisionnel est l’action !
Conclusion
Sans action l’intelligence est vaine !

Une enquête récente publiée par le CIO (Le Monde Informatique) montre que
le moteur de la stratégie décisionnelle est alimenté à 69 % par le pilotage de
la performance, à 53 % par la réduction des coûts opérationnels et à 51 % par
l’optimisation de la productivité.
À la question « quels sont les facteurs clés de succès d’un projet décisionnel »,
86 % des décideurs pensent que l’adéquation aux objectifs métier est essentielle.
Viennent ensuite l’adhésion des utilisateurs (78 %), l’implication de la direction
générale (72 %), l’adéquation à la stratégie de l’entreprise (61 %) puis la rapidité de
mise en œuvre (51 %). Enfin, les managers pensent que les fonctions décisionnelles
à mettre en place sont prioritairement le reporting ad hoc (61 %), le tableau de bord
pour 59 %, le portail décisionnel (54 %), et l’analyse multidimensionnelle (51 %).
Comme nous l’avons vu dans cet ouvrage, des outils sont largement disponibles.
De nombreux assistants logiciels tentent de banaliser les fonctions qui, il y a peu
encore, semblaient réservées à des élites (statisticiens, prévisionnistes, spécialistes en
intelligence artificielle ou systèmes experts). La technologie d’aujourd’hui met à portée
de clic les analyses les plus complexes (data mining, simulations, analyses prédictives).
Rappelons que 80 % de la réussite d’un projet de Business Intelligence provient de la
qualité du datawarehouse. La méthodologie qui préside à la conception de l’entrepôt
(cf. chapitre 2) est à ce titre fondamentale.
Les logiciels sont largement compatibles avec les technologies OLAP de Microsoft.
Que vous utilisiez des outils d’analyse comme Excel, Powerplay de Cognos, Business
Objects, Hyperion, vous pouvez réaliser rapidement et à peu de frais un système
décisionnel. Le processus itératif d’un projet décisionnel permet de prendre en compte
de plus en plus de besoins et ainsi de suivre la progression de l’activité de toute
entreprise.
Cependant, peu nombreux sont les décideurs qui exploitent ces outils en totalité.
Qui peut se vanter de connaître (et encore moins d’appliquer) toutes les fonction-
nalités d’Excel ? Aujourd’hui les outils de BI sont extrêmement aboutis et vont
même bien au-delà des besoins des décideurs. Le véritable enjeu ne réside pas dans
le mode d’emploi des outils de BI, lesquels sont dotés de plus en plus d’assistants
(ils seront bientôt banalisés comme ce fut le cas de la bureautique dans les années
quatre-vingt-dix) mais bien d’avantage dans la capacité d’utiliser ces outils au service
de la stratégie de l’entreprise.
Appliquons l’adage de Socrate, « connais-toi toi-même », à notre sujet d’étude.
C’est parce que l’entreprise réalise un travail d’introspection sur elle-même qu’elle va
pouvoir se situer dans le monde qui l’entoure. Mais pour bien connaître le monde,
l’entreprise doit exercer une veille permanente.
Le Corporate Performance Management (CPM), qui se définit comme un ensemble
de méthodes et d’outils destinés au contrôle des performances de l’entreprise, s’appuie
d’ores et déjà sur les fondements de la Business Intelligence. La chaîne de com-
mandement dans les organisations passe du mode simulation au mode opératoire et
réciproquement selon un cycle vertueux mû par la stratégie globale de l’entreprise.
La Business Intelligence n’est ni un mirage, ni un miracle de la technologie. Si
elle n’a pas toujours été comprise, c’est qu’elle n’a pas été suffisamment expliquée
par ses promoteurs. Nous pensons qu’elle s’intègre elle-même dans une approche
multidimensionnelle où les trois axes sont pragmatisme, rigueur et pédagogie.
Pragmatisme parce que la Business Intelligence s’impose au-delà des modes en
mettant en concordance technologie et stratégie d’entreprise.
Rigueur dans le respect de règles de l’art et des méthodologies de gestion de projets.
Pédagogie afin de rapprocher ceux qui conçoivent les systèmes et les mettent en
œuvre de ceux qui les utilisent au quotidien.
L’auteur espère apporter sa modeste contribution au mouvement de démocrati-
sation de la Business Intelligence. Il forme et encadre en entreprise des étudiants
en informatique à l’Institut du management de l’université de Savoie. Ces jeunes,
compétents, ouverts à toutes les technologies, apportent des réponses concrètes aux
problématiques rencontrées dans les entreprises industrielles ou de services.
Mais ne l’oublions jamais, le but principal de l’éducation n’est pas le savoir, mais
l’action. La connaissance seule ne suffit pas. La connaissance n’a de valeur que si on
l’exploite. Sans action, l’intelligence est vaine. Ce n’est pas ce qu’on sait qui est le
plus important, mais plutôt ce qu’on fait avec ce qu’on sait.
Et un dernier conseil à ceux qui douteraient encore : il y a pire dans la vie que de
ne pas avoir réussi, c’est de ne pas avoir essayé !
ANNEXES
A
Petit historique
de la BI
Voici un bref historique des étapes essentielles qui ont jalonné la longue marche de ce
que l’on appelle aujourd’hui la Business Intelligence.
Tableau A.1
Année Événement Commentaire
1962 Ken Iverson publie Premier langage multidimensionnel.
le langage APL (A Programming
Langage)
1970 Express Premier outil multidimensionnel visant
les applications de type marketing.
La version modernisée de ce moteur
OLAP est intégrée aujourd’hui
dans Oracle 9i Release 2 Option
OLAP.
1982 Comshare System W Premier outil OLAP visant
les applications financières.
Ancêtre de Essbase.
1984 Lancement de Metaphor Premier moteur ROLAP (Relational
OLAP).
1985 Lancement de Pilot Command EIS en mode client/serveur.
Center
1990 Lancement de Cognos Powerplay Premier client OLAP pour station de
travail sous PC Windows. Indissociable
de Transformer (moteur de
fabrication des cubes) et Impromptu
(requêteur du datawarehouse).
1992 Lancement de Essbase
392 Annexe A. Petit historique de la BI
Tableau A.1 — (suite)

1993 E. Codd dicte les règles qui À la demande de la société Arbor
décrivent les moteurs OLAP Software. E. Codd avait
précédemment dicté les règles
universelles du modèle relationnel.
1994 Lancement de DSS Agent La version actuelle 7i présente
par Microstrategy une architecture OLAP
à trois niveaux.
1995 Lancement de Holos 4.0 Outil d’accès aux SGBD relationnels et
aux cubes OLAP multidimensionnels.
La technologie fut acquise par Crystal
Decisions en 1996.
1996 Oracle acquiert Express Événement d’importance qui
propulse l’analyse
multidimensionnelle au premier rang.
Moteur hybride d’accès aux sources
relationnelles et multidimensionnelles.
1996 Lancement de Business Objects 4.0 Création dynamique de cubes fondés
sur des données relationnelles.
La technologie client/serveur et Web
a été acquise par le rachat de Crystal
Enterprise.
1997 Microsoft lance la technologie OLE Livrable sous forme d’API (module
DB for OLAP interface).
1998 IBM lance Db2 pour OLAP Cette version d’Essbase stocke
les données selon le modèle en étoile.
1998 Hyperion fournit ses solutions L’entrée de Microsoft sur le marché
OLAP pousse Arbor et Hyperion à
fusionner.
1999 Lancement de Microsoft OLAP Initialement nommé DSS (Decision
services Support Services). La technologie
OLAP Services
a été achetée auprès de la société
israélienne Panorama Software en
1996.
2000 Microsoft renomme OLAP Services Cette version d’Analsys Services est
en Analysis Services intégrée gratuitement dans SQL
Server 2000.
2000 XML/A Hyperion, SAS Institute et Microsoft
définissent les règles d’accès aux
données OLAP via XML for Analysis.
2001 Oracle 9i OLAP Successeur d’Oracle Express.
2002 Oracle 9i Release 2 OLAP À mi-chemin entre une base
relationnelle et OLAP
multidimensionnel.
2003 Année de consolidation BO achète Crystal Decisions,
Hyperion achète Brio Software,
Cognos achète Adaytum et Geac
achete Comshare.
2004 Les éditeurs fournissent des add-ins BO, Cognos, Microsoft,
pour Excel Microsotrategy et Oracle mettent à
disposition des add-ins pour le tableur
Excel.
Petit historique de la BI 393
Tableau A.1 — (suite)

2004 Hyperion livre Essbase 7X Orienté applications marketing et
financières.
2005 Microsoft livre sa suite intégrale de La suite SQL Server 2005 intègre un
Business Intelligence dans SQL SGBD, le datawarehouse, l’ETL,
Server 2005 OLAPet le data mining avec Analysis
Services, le reporting avec Reporting
Services.
Mars 2007 Oracle annonce le rachat d’Hypérion
Mai 2007 SAP rachète Outlooksoft SAP lance un OPA amicale sur B.O.
Juin 2007 Microsoft acquiert la technologie de De nouveaux graphiques, les jauges,
Visualisation de données auprès de et les calendriers seront intégrés à
la société Dundas Reporting Services 2008.
Novembre 2007 IBM rachète Cognos
Juillet 2008 Microsoft annonce son souhait Objectif : préparer la future version
d’acquérir DatAllegro de SQL Server et concurrencer
Netezza, Terradata et HP.
3 octobre 2008 Microsoft livre la version SQL
Server 2008
Janvier 2009 Microsoft annonce l’arrêt des PerformancePoint Monitor et
développements de Analytics seront intégrés à Office 14
PerformancePoint Planning Sharepoint offrant ainsi la BI à 30 à
40 millions d’utilisateurs de
SharePoint Portal.
2010 ? Microsoft envisage de livrer la SQL Server 2010 comporterait des
version SQL Server 2010 (nom de fonctions d’analyse de données et de
code Kilimanjaro) reporting en ’libre service’. Ces
développements sont menés sous le
nom de code « Projet Gemini »
Si SQL Server 2008 intègre aujourd’hui les techniques les plus abouties en matière
de BI, c’est qu’il a hérité des nombreuses recherches qui se sont déroulées depuis une
quarantaine d’années.
B
Nouveautés de SQL Server
2008 par rapport a la version
2005
B.1 NOUVEAUTÉS DE L’ETL INTEGRATION SERVICES

(SSIS 2008)
Cette dernière version de Microsoft Integration Services présente de nouvelles
fonctionnalités et des améliorations pour l’installation, les composants, la gestion
de données, les performances et le dépannage.
B.1.1 Fonctionnalités d’installation

Nouvel emplacement des exemples
La documentation en ligne n’inclut plus d’exemples de base de données et d’ap-
plications SQL Server. Ces exemples de base de données et d’applications sont
désormais disponibles sur le site Web des Exemples pour Microsoft SQL Server
www.codeplex.com. Non seulement ce site Web rend ces exemples plus accessibles
aux utilisateurs, mais il simplifie également la recherche des exemples supplémentaires
concernant Microsoft SQL Server et Business Intelligence. Sur le site Web des
exemples SQL Server, vous pouvez effectuer les opérations suivantes :
• Parcourir les exemples fournis par les développeurs, les utilisateurs et la commu-
nauté Microsoft MVP (Most Valuable Professional).
• Télécharger des exemples de base de données et de projets de code.
• Voir ou participer à une zone de discussion où vous pouvez signaler des problèmes
et poser des questions sur les exemples dans chaque domaine technologique.
396 Annexe B. Nouveautés de SQL Server 2008 par rapport a la version 2005
Prise en charge de SQL Server 2000 DTS (Data Transformation Services)

Integration Services continue de prendre en charge SQL Server 2000 Data Transfor-
mation Services (DTS).
B.1.2 Améliorations des composants

Performances améliorées et mise en cache pour la transformation de recherche
Les améliorations en termes de performances apportées à la transformation de
recherche se traduisent par un chargement plus rapide du cache et des opérations
de recherche plus efficaces. Ces améliorations sont possibles grâce aux fonctionnalités
suivantes :
• la possibilité de prendre des lignes n’ayant pas d’entrées correspondantes dans
le dataset de référence et de les charger dans le cache ;
• la possibilité d’utiliser des flux de données distincts pour charger le dataset de
référence dans le cache et pour y effectuer des recherches ;
La transformation de recherche inclut maintenant les options de mise en cache suivantes

• Le dataset de référence est un fichier cache (.caw), accessible à l’aide d’un
gestionnaire de connexions du cache.
• Le dataset de référence est une source de données connectée dans le flux de
données, accessible à l’aide d’un gestionnaire de connexions du cache et une
transformation du cache.
• Le dataset de référence est une table, une vue ou une requête qui est totalement
ou partiellement mise en cache et accessible à l’aide d’un gestionnaire de
connexions OLE DB.
• Le cache peut être partagé entre plusieurs transformations de recherche d’un
même package et entre transformations de packages distincts.
Vous avez la possibilité de déployer un fichier cache avec un package.
Nouveaux composants ADO.NET

Integration Services 2008 inclut désormais les composants ADO.NET suivants :
• Un composant source ADO NET qui exploite les données issues d’un fournis-
seur .NET Framework et les met à la disposition du flux de données.
• Un composant de destination ADO NET qui charge des données dans diffé-
rentes bases de données compatibles ADO.NET qui utilisent une vue ou une
table de base de données.
Nouvelle tâche de profilage des données et la visionneuse du profil des données

La tâche de profilage des données est une nouvelle tâche de la boîte à outils Integration
Services. Vous pouvez utiliser cette tâche dans un package Integration Services pour
profiler des données qui sont stockées dans SQL Server. Les informations fournies
par le profil vous permettent d’identifier des problèmes potentiels liés à la qualité
B.1 Nouveautés de l’ETL Integration Services (SSIS 2008) 397
des données. La tâche de profilage des données fournit des profils qui permettent
d’identifier des problèmes de qualité des données dans des colonnes individuelles et
avec les relations de colonnes :
Profils qui permettent d’identifier les problèmes dans des colonnes individuelles
• la distribution de longueurs dans les valeurs de colonnes ;
• le pourcentage de valeurs Null ;
• la distribution de valeurs dans la colonne ;
• des statistiques de colonnes pour les colonnes numériques ;
• des expressions régulières font correspondre des colonnes de chaîne.
Profils qui permettent d’identifier les problèmes avec les relations de colonnes
• les colonnes des clés candidates ;
• les dépendances fonctionnelles entre les colonnes ;
• l’inclusion de l’ensemble de valeurs dans une colonne de l’ensemble de valeurs
d’une autre colonne.
Nouvel Assistant Projet de connexions Integration Services

L’Assistant Projet de connexions Integration Services permet de créer un package
qui contient les informations de connexion requises pour connecter des sources
de données et des destinations. L’Assistant vous guide lors des étapes de sélection
de fournisseurs de données, de configuration de gestionnaires de connexions et
d’attribution de gestionnaires de connexions aux sources et aux destinations.
Nouvel environnement de script

Business Intelligence Development Studio s’intègre maintenant de façon transparente
à l’environnement Microsoft Visual Studio VSTA (Visual Studio Tools for Applications).
VSTA est l’environnement de développement dans lequel un développeur écrit des
scripts pour la tâche de script et le composant Script.
VSTA prend en charge les langages de programmation Microsoft Visual Basic 2008
ou Microsoft Visual C# 2008. VSTA permet également d’ajouter des assemblys
managés à un script au moment de sa conception en naviguant jusqu’à l’emplacement
du dossier. Par ailleurs, VSTA vous permet d’ajouter à votre code une référence Web
qui permet à ce code d’utiliser des objets et des méthodes fournis par un service Web.
Pour les packages SQL Server 2005 Integration Services (SSIS) qui incluent des
scripts MicrosoftVisual Studio VSA (Visual Studio for Applications), VSTA convertit
ces scripts. Les Points d’arrêt ne sont pas pris en charge dans le composant Script
Mise à niveau de packages

Vous pouvez mettre à niveau vos packages Integration Services du format utilisé par
Integration Services dans SQL Server 2005 vers le format utilisé par SQL Server 2008.
Pour mettre à niveau vos packages SQL Server 2005, effectuez une ou plusieurs
des procédures suivantes :
• Utilisez l’utilitaire de ligne de commande dtexec (dtexec.exe) livré avec SQL
Server 2008 pour exécuter le package SQL Server 2005. Lorsque vous utilisez
cette méthode pour exécuter un package SQL Server 2005, la mise à niveau est
temporaire, et les modifications qui résultent de la mise à niveau ne peuvent
pas être enregistrées.
• Ajoutez le package SQL Server 2005 à un projet existant ou ouvrez ce package
dans SQL Server 2008 Integration Services. Integration Services mettra auto-
matiquement à niveau le package. Toutefois, la mise à niveau est temporaire.
Pour définitivement mettre à niveau le package, vous devez enregistrer les
modifications apportées à ce dernier. Pour ajouter un package existant, dans le
menu Projet, cliquez sur Ajoutez un package existant.
• Créez ou ouvrez un projet SQL Server 2005 Integration Services, puis utilisez
l’Assistant Mise à niveau de packages SSIS pour mettre à niveau tous les
packages du projet. Cette mise à niveau est permanente.
B.1.3 Améliorations de la gestion des données

Gestion des types de données améliorés dans l’Assistant Importation et Exportation SQL Server
L’Assistant Importation et Exportation SQL Server fournit maintenant des informa-
tions et des options supplémentaires liées aux conversions de types de dates requis par
l’opération d’importation ou d’exportation :
• Vous pouvez afficher des informations de mappage de types de données pour
chaque table ou vue que vous choisissez d’importer ou d’exporter. Ces informa-
tions incluent une indication visuelle de la probabilité de réussite sans erreur
des conversions.
• Vous pouvez afficher des informations détaillées supplémentaires pour toute
colonne de la table ou vue sélectionnée.
• Vous pouvez accepter ou rejeter les conversions de types de données que
l’Assistant effectuera colonne par colonne.
• Vous pouvez spécifier la gestion des erreurs et des troncations globalement ou
colonne par colonne.
Nouveaux types de données de date et d’heure

Les nouveaux types de données de date et d’heure suivants sont disponibles dans
Integration Services :
• DT_DBTIME2
• DT_DBTIMESTAMP2
• DT_DBTIMESTAMPOFFSET
B.1 Nouveautés de l’ETL Integration Services (SSIS 2008) 399
Les avantages de ces nouveaux types de données Integration Services sont les
suivants :
• Prise en charge d’une plus grande échelle pour les fractions de seconde.
• Prise en charge d’une précision définie par l’utilisateur.
• Prise en charge d’un décalage de fuseau horaire.
Vous pouvez convertir les nouveaux types de données en d’autres types de données
de date Integration Services à l’aide d’expressions, de la transformation de conversion
de données et de la transformation de colonne dérivée. Vous pouvez également utiliser
des expressions pour effectuer des comparaisons entre les nouveaux types de données.
Pour plus d’informations, consultez Types de données d’Integration Services et Cast
(SSIS).
Instructions SQL améliorées

Integration Services inclut les améliorations suivantes apportées aux instructions
Transact-SQL :
• Opérations DML (Data Manipulation Language) simultanées Transact-SQL
prend en charge l’utilisation d’une opération MERGE dans une instruction
SQL. L’opération MERGE vous permet d’exprimer plusieurs opérations INSERT,
UPDATE et DELETE dans une instruction unique sur une table cible spécifiée.
La table cible est basée sur les conditions de jointure avec une table source. Pour
plus d’informations, consultez Style caratère : Texte-Courant-Car non pris en
charge
Insertion, mise à jour, et suppression de données à l’aide de MERGE et
Utilisation de MERGE dans les packages Integration Services.
• Extraction de données sur les modifications apportées à une source de
données L’opération INSERT prend en charge l’insertion de lignes dans une
table cible qui sont renvoyées par la clause OUTPUT d’une opération INSERT,
UPDATE, DELETE ou MERGE.
• Amélioration des performances de l’opération de chargement en masse
lorsque les données sont triées d’après l’index cluster sur la table L’option
BULK de la fonction OPENROWSET prend en charge l’argument ORDER qui
indique comment les données du fichier de données sont déjà triées. L’argument
ORDER n’effectue pas d’opération de tri sur les données de texte. Cet argument
indique au Moteur de base de données SQL Server que les données sont déjà
pré-triées dans le fichier. Si les données ne sont pas triées, le Moteur de base de
données renvoie une erreur. La fonction OPENROWSET vous permet d’utiliser
OLE DB pour accéder aux données distantes.
B.1.4 Améliorations des performances et du dépannage

Capture des données modifiées
Integration Services inclut une nouvelle technologie appelée « capture de données
modifiées ». Cette nouvelle fonctionnalité Moteur de base de données capture les
activités d’insertion, de mise à jour et de suppression appliquées aux tables SQL

Server. La capture des données modifiées rend également disponibles les détails de ces
modifications dans un format relationnel simple à utiliser.
Nouveaux fichiers de vidage du débogage

Vous pouvez créer des fichiers de vidage du débogage (.mdmp et .tmp) qui fournissent
des informations sur ce qui se produit lors de l’exécution d’un package. Ces infor-
mations peuvent vous aider à résoudre les problèmes qui surviennent lors de cette
opération.
Pour créer les fichiers de vidage du débogage, vous utilisez certaines options d’invite
de commandes avec l’utilitaire dtexec et l’utilitaire d’invite de commandes dtutil
(dtutil.exe).
B.2 NOUVEAUTÉS D’ANALYSIS SERVICES BASE DE

DONNÉES MULTIDIMENSIONNELLE (SSAS 2008)
Cette nouvelle version de Microsoft SQL Server Analysis Services intègre de nou-
velles fonctionnalités et des améliorations.
B.2.1 Améliorations apportées à la conception d’agrégation

Analysis Services inclut les améliorations suivantes apportées à la conception des
agrégations :
• Nouveau concepteur d’agrégation. Un nouveau concepteur d’agrégation facilite
la navigation et la modification des conceptions d’agrégations. Les conceptions
d’agrégations sont maintenant regroupées par groupe de mesures. Une nouvelle
vue est désormais disponible pour les utilisateurs expérimentés souhaitant
concevoir manuellement des agrégations.
• Simplification et amélioration des Assistants Conception d’agrégation et Opti-
misation de l’utilisation. Ces Assistants mis à jour vous permettent de modifier
les paramètres de stockage des agrégations dans une ou plusieurs partitions simul-
tanément et facilitent la définition des paramètres d’utilisation des agrégations.
L’Assistant Optimisation de l’utilisation vous permet également maintenant
d’ajouter de nouvelles agrégations à une agrégation existante.
• Nouveaux avertissements AMO. Ces nouveaux messages d’avertissement pré-
viennent les utilisateurs lorsqu’ils s’écartent des méthodes conseillées en matière
de conception d’agrégation.
B.2 Nouveautés d’Analysis Services Base de données multidimensionnelle (SSAS 2008) 401
B.2.2 Améliorations apportées à la conception de cube

L’Assistant Cube a été simplifié et amélioré Ces améliorations vous permettent de
créer plus rapidement des cubes plus performants.
B.2.3 Améliorations de la conception de dimensions

Analysis Services intègre les améliorations suivantes à la conception de dimensions :
• Nouveau concepteur de relations d’attributs. L’éditeur de dimensions dispose
d’un nouveau concepteur de relations d’attributs qui facilite la navigation et la
modification des relations d’attributs.
• Nouveaux avertissements AMO. Ces nouveaux messages d’avertissement pré-
viennent les utilisateurs lorsqu’ils s’écartent des méthodes conseillées en matière
de conception ou qu’ils commettent des erreurs logiques lors de la conception
d’une base de données.
• Simplification et amélioration de l’Assistant Dimension. Cette dernière version
de l’Assistant détecte automatiquement les hiérarchies parent-enfant, fournit
une configuration d’erreur par défaut plus sûre et prend en charge la spécification
des propriétés de membre.
• Nouvelle boîte de dialogue Colonnes clés. Cette nouvelle boîte de dialogue
facilite la modification des colonnes clés.
• Prise en charge des colonnes clés dans le panneau des propriétés. Les colonnes
clés peuvent maintenant être modifiées dans le panneau des propriétés.
• Onglet Structure de dimension mis à jour. Cet onglet fonctionne maintenant
avec le nouveau concepteur de relations d’attributs et est plus simple d’utilisa-
tion, ce qui facilite la modification des attributs et des hiérarchies.
B.2.4 Améliorations de la sauvegarde et de la restauration

La fonctionnalité de sauvegarde et de restauration d’Analysis Services dispose d’une
nouvelle structure de stockage et de performances améliorées dans tous les scénarios
de sauvegarde et de restauration.
B.2.5 Structure de stockage améliorée

La nouvelle structure de stockage fournit une base de données de référentiel plus
solide pour les bases de données archivées. Avec la nouvelle structure de stockage, il
n’existe aucune limite pratique à la taille du fichier de base de données, ni au nombre
des fichiers qu’une base de données peut contenir.
B.2.6 Performances améliorées

La nouvelle fonctionnalité de sauvegarde et de restauration améliore les performances.
Les tests effectués sur des bases de données de tailles diverses contenant différents
nombres de fichiers ont montré de significatives améliorations des performances. Pour
obtenir les valeurs réelles basées sur vos besoins spécifiques, nous vous encourageons à
effectuer vos propres tests sur votre base de données.
B.2.7 Extensions de personnalisation Analysis Services

Les extensions de personnalisation Analysis Services permettent aux développeurs de
créer des objets et des fonctionnalités Analysis Services et de fournir dynamiquement
ces objets et fonctionnalités dans le contexte de la session utilisateur. Les développeurs
ne doivent pas nécessairement créer de spécifications détaillées décrivant où et
comment rechercher les fonctionnalités étendues. Au lieu de cela, ils peuvent partager
immédiatement ces nouveaux objets et fonctionnalités avec les utilisateurs finaux et
les autres développeurs.
B.3 NOUVEAUTÉS (REPORTING SERVICES)
Microsoft SQL Server 2008 Reporting Services (SSRS) introduit de nombreuses

nouvelles fonctionnalités et améliorations qui augmentent les capacités de création
de rapports des gens qui développent des solutions de création de rapports.
B.3.1 Nouveautés de la création de rapports

Introduit les régions de données Tablix, Chart et Gauge. Introduit également la
prise en charge du format RTF, de nouveaux types de sources de données et le
Générateur de rapports 2.0, qui offre de nombreuses nouvelles fonctionnalités telles
qu’une disposition de données et une visualisation améliorées, dans un environnement
de création semblable à Office. Pour finir, cette rubrique décrit les modifications
incrémentielles apportées aux outils de création et au langage RDL (Report Definition
Language) qui permettent à un créateur de rapport de tirer pleinement parti des
nouvelles fonctionnalités de traitement.
B.3.2 Nouveautés dans le traitement des rapports et le rendu

Présente de nouvelles extensions de rendu pour Microsoft Word et les améliorations
apportées aux extensions de rendu Excel et CSV. Cette rubrique décrit également
les modifications importantes apportées au processeur de rapports qui améliorent la
performance et l’évolutivité des grands rapports.
B.3 Nouveautés (Reporting Services) 403
B.3.3 Nouveautés dans l’architecture et les outils de serveur de rapports

Introduit la nouvelle architecture de serveur de rapports qui inclut la prise en charge
native des fonctionnalités précédemment fournies par les Services Internet (IIS).
B.3.4 Nouveautés dans le domaine de la programmabilité de Report Server

Introduit une nouvelle extension serveur qui fournit un prétraitement des définitions
de rapports, plus de nouvelles méthodes du point de terminaison ReportServer2006
qui éliminent l’écart de fonctionnalités qui existait précédemment entre les serveurs
de rapports en mode natif et en mode intégré SharePoint.
Glossaire
Action Lance une action prédéfinie sur un cube ou une partie d’un cube. Une action
permet par exemple de lancer un rapport ou d’effectuer un drill through en
cliquant sur une cellule du cube. Une action de rapport permet d’exécuter
un rapport Reporting services directement depuis un cube. Cette méthode
facilite la lecture de l’entrepôt de données relationnel depuis un cube.
Analyse de scénarios Technique adoptée pour concevoir des scénarios à caractère
commercial en mettant à jour des données, puis en analysant les effets des
modifications apportées aux données. Les analyses de scénarios font partie
intégrante d’Excel et de SQL Server OLAP grâce à la technique d’écriture
différée.
Analysis Server Composant serveur d’Analysis Services spécialement conçu pour
créer et entretenir des structures de données multidimensionnelles et
produire des données multidimensionnelles en réponse aux requêtes des
clients. Voir aussi données multidimensionnelles, OLAP.
Attribut Un fait décrivant chaque position d’une dimension.
Agrégation Action de calculer les valeurs associées aux positions parentes des
dimensions hiérarchiques. Cette agrégation peut être une somme, une
moyenne ou toute autre opération plus complexe.
Axe Ensemble de tuples où chaque tuple est un ensemble de membres issus de
différentes dimensions. Un ensemble d’axes définit les coordonnées d’un
jeu de données multidimensionnelles. Plus simplement, correspond à une
dimension du cube. Voir aussi tranche, tuple.
Balanced Scorecard Méthode consistant à décliner les objectifs d’une entreprise en
indicateurs de performance clés.
Base de données multidimensionnelle OLAP Modèle de base de données trai-
tant les données non comme des tables et des colonnes relationnelles,
mais en tant que cubes d’information dont les cellules comportent des
données de synthèse et de dimension. Chaque cellule est fonction d’un
ensemble de coordonnées qui précisent sa position dans les dimensions de
la structure. Par exemple, la cellule située aux coordonnées {SALES, 1997,
WASHINGTON, SOFTWARE} dévoile la synthèse des ventes de logiciels
réalisées dans l’État de Washington en 1997.
Base de données relationnelle Ensemble d’informations organisées sous forme de

lignes et de colonnes dans des tables. Chaque table détermine une classe
d’objets pour l’organisation concernée. Les requêtes peuvent exploiter les
données d’une table pour rechercher des données associées dans d’autres
tables. Les liens entre les tables (qui donnent la possibilité de traiter
simultanément les données de plusieurs tables) sont établis à l’aide de
jointures entre les champs clés.
BI (Business Intelligence) Concept désignant les moyens permettant de rassembler,
intégrer, analyser et partager des données de l’entreprise afin d’optimiser
la prise de décision. Par extension, BI désigne les solutions logicielles
combinant à des fins décisionnelles des fonctions d’interrogation de bases
de données, de reporting, d’analyse multidimensionnelle (ou OLAP), de
data mining et de visualisation des données.
Catégorie S’emploie pour décrire ou classifier les données détaillées d’une société,
par exemple la date d’une transaction, un produit donné, un client donné
ou une région commerciale. Les catégories peuvent être regroupées en
catégories plus larges, par exemple les dates sont regroupées en mois et
les mois en années.
Cellule Une donnée définie par une position de chaque dimension (comme dans le
cas d’un document Excel).
Champ Zone d’une fenêtre ou d’un enregistrement stockant une valeur de données
unique. Certaines bases de données interprètent le champ comme un
synonyme de la colonne.
Checkpoint Point de contrôle permettant une reprise des traitements de chargement
des données dans un ETL.
Clé de membre Propriété d’un niveau de dimension qui spécifie les identificateurs des
membres du niveau. La valeur de cette propriété peut désigner une colonne
dans laquelle figurent les identificateurs ou une expression correspondant
aux identificateurs.
Connexion Liaison établie entre le complément et un cube Analysis Services.
Cookies Certains sites web enregistrent sur votre disque dur des informations à votre
sujet (par exemple, la date de votre dernière connexion). On appelle ces
informations « cookies ». Internet Explorer enregistre les cookies dans le
dossier Cookies de Windows. Vous pouvez les supprimer sans aucun danger.
CPM (Corporate Performance Management) Outil de pilotage global des per-
formances de l’entreprise. Afin de répondre aux contraintes de la loi
Sarbanes-Oxley, le CPM permet d’obtenir une vue globale non seulement
sur les performances financières mais en outre de la conformité des résultats
par rapport aux prévisions.
CRM (Customer Relationship Management) Gestion de la relation client.
Cross-sell Technique de vente consistant à proposer au client un produit lié à celui
demandé, soit parce qu’il existe un lien technique, soit parce que l’étude des
comportements des consommateurs montre l’existence d’une corrélation
entre les ventes des deux produits.
Glossaire 407
Cube Ensemble de données organisées et synthétisées dans une structure multidi-

mensionnelle définie par un ensemble de dimensions et de mesures. Dans
le cas de nombreuses dimensions, on parle d’« hypercube »). Bien qu’un
hypercube comporte normalement plus de trois dimensions, on emploie
souvent le synonyme « cube multidimensionnel » pour le désigner. Voir
aussi dimension, mesure, base de données multidimensionnelle, OLAP.
Cube local Cube créé et stocké avec l’extension.cub sur un ordinateur local. On parle
également de cube hors connexion.
Cube virtuel Cube logique fondé sur un ou plusieurs cubes réguliers ou liés.
Datamart Sous-ensemble d’un datawarehouse lié à un métier de l’entreprise (finance,
marketing, RH, etc.) et conçu pour répondre aux besoins d’un groupe
spécifique d’utilisateurs en respectant les exigences de sécurité de l’entre-
prise. L’entreprise peut construire des datamarts « Ventes », « Finance » ou
« Ressources Humaines » en ayant l’assurance que les utilisateurs n’ont accès
qu’aux données qui les concernent. Les datamarts simplifient également le
travail des services informatiques en leur permettant de gérer pour chaque
communauté d’utilisateurs des ensembles de données moins volumineux.
Datamining Méthode d’exploitation automatique des données visant à révéler les
tendances, récurrences et corrélations entre les données. Basé sur des
méthodes d’analyse statistique et/ou d’intelligence artificielle, le data mining
permet de déceler des informations essentielles difficiles à repérer « à l’œil
nu » telles que les corrélations entre des événements, des relations de
causes à effets, des classifications, des regroupements, des projections et
des prévisions. On parle aussi de Web mining.
Datawarehouse Entrepôt de données, isolé des systèmes opérationnels, permettant
d’agréger des données thématiques, intégrées, non volatiles et historisées,
dans un but de faciliter la prise de décision.
Datastore Base de données intermédiaire avant spécialisation.
Dataweb Accès à une base de données via un serveur Internet et un navigateur web,
quelle que soit sa plate-forme d’hébergement, sa localisation ou le format
des données.
Décisionnel Processus d’utilisation des connaissances issues des informations et des
données générées par les processus métier de l’entreprise pour déterminer la
meilleure action à entreprendre, la meilleure décision à prendre. Le repor-
ting et l’analyse sont des outils décisionnels typiques. L’analyse décisionnelle
aide la prise de décisions stratégiques en permettant de visualiser les données
de l’entreprise à l’aide d’indicateurs métier.
Descendant Dans une hiérarchie de dimension, membre associé au membre d’un
niveau supérieur de la même dimension. Par exemple, dans une dimension
de temps composée des niveaux Année, Trimestre, Mois et Jour, Janvier est
un descendant de 2008. Voir aussi enfant, parent, frère.
Dimension Attribut structurel d’un cube constituant une hiérarchie organisée de
catégories (niveaux) qui décrivent les données d’une table de faits. Ces
catégories décrivent généralement un ensemble identique de membres sur
lesquels les utilisateurs souhaitent fonder une analyse. Par exemple, une
dimension géographique peut inclure des niveaux Pays, Région, Départe-
ment et Ville. Voir aussi table de faits, mesure, niveau.
Dimension de temps Dimension divisant le temps en niveaux, tels qu’Année,
Trimestre, Mois et Jour. Dans Analysis Services, type spécial de dimension
créée à partir de la colonne date/heure.
DOLAP (Desktop OLAP) Ce terme désigne un petit produit OLAP faisant de
l’analyse multidimensionnelle en local. Il peut impliquer l’utilisation d’une
minibase multidimensionnelle ou de l’extraction de cube.
Données source Lignes ou enregistrements sous-jacents d’une base de données
fournissant les données d’un rapport.
Drill down (zoom en profondeur) C’est la fonctionnalité d’analyse des données qui
permet, en cliquant sur une donnée ou sur une dimension, d’obtenir un
nouveau rapport avec un niveau d’information supplémentaire se rappor-
tant à la zone cliquée. Cette fonctionnalité permet d’approfondir un axe
d’analyse en descendant aux niveaux de détail de plus en plus fins d’un
système multidimensionnel.
drill through (zoom en travers) Fonctionnalité d’analyse des données qui permet,
comme le drill down, d’obtenir un niveau de détails supplémentaire, mais
ici, l’accès se fera à une base différente. Cette base peut être soit un cube
multidimensionnel, soit une base relationnelle.
drill up (forage arrière) Fonction de zoom arrière d’un outil décisionnel permettant,
en cours d’analyse, de passer d’un niveau de détail fin à un niveau de données
plus synthétique.
DSS (Decision Support System) Système d’interrogation et de présentation des don-
nées adapté à l’aide à la décision. Appelé aussi SIAD (système d’information
d’aide à la décision) ou encore EIS.
Écriture différée Données de scénarios enregistrées et écrites dans le cube. Ces
données sont disponibles pour une analyse ultérieure et peuvent être
consultées et partagées par d’autres personnes ayant accès au cube. Voir
aussi analyse de scénarios.
EIP (Enterprise Information Portal) Portail d’entreprise donnant un point d’accès
unique à l’ensemble des ressources : données, applications, services...
EIS (Executive Information System) Tableaux de bord et graphiques synthétiques
présentant une vision assez large de l’activité.
Enfant Membre du niveau inférieur suivant dans la hiérarchie directement associé au
membre actuel. Par exemple, dans une dimension de temps composée des
niveaux Trimestre, Mois et Jour, Janvier est un enfant du trimestre 1 (Q1).
ERP (Enterprise Resource Planning) ou PGI (progiciel de gestion intégré)
L’ERP regroupe tout ou partie des applications nécessaires à la gestion
de l’entreprise. Que ce soit des applications horizontales (comptabilité,
paie, facturation, gestion des ressources humaines) ou verticales (gestion
Glossaire 409
de production, gestion de stocks par secteur d’activité). Les ERP se dotent

progressivement de fonctions décisionnelles et front office.
ETL (Extract, Transform, Load) Outils destinés à l’extraction, à la transformation
et au chargement des données dans un datawarehouse.
Expression personnalisée Expression chargée de renvoyer des données à un rapport
selon une ou plusieurs conditions.
expressions multidimensionnelles (MDX) Syntaxe servant à définir des objets
multidimensionnels et à interroger et manipuler des données multidimen-
sionnelles.
Extraction Action d’extraire des données détaillées à partir desquelles les données
d’une cellule du cube ont été synthétisées. Voir drill through.
FASMI (Fast Analysis of Shared Multi-dimensional Information) « Analyse rapide
d’information multidimensionnel partagée ». Critères retenus pour simpli-
fier les règles de E. Codd et faciliter l’évaluation des outils OLAP.
Filtre de page Filtre dans un rapport affichant des sous-ensembles de données.
Frère Dans une hiérarchie de dimensions, membre spécifié du même parent. Par
exemple, dans une dimension de temps dotée des niveaux Année et Mois,
les membres Janvier 2008 et Février 2008 sont des frères. Voir aussi enfant,
descendant, parent.
Frère (membre) Dans une structure arborescente, élément sans éléments subordonnés.
Par exemple, dans Analysis Services, un frère est un membre de dimension
qui n’a pas de descendants.
Hiérarchie Les positions d’une dimension organisées selon une série de relations
(1 – n) en cascade. Cette organisation de données est comparable à
un arbre logique où chaque membre n’a pas plus d’un père mais un
nombre quelconque d’enfants. Exemple de hiérarchie temporelle :
Année/Trimestre/Mois/Jour.
Hiérarchie de dimension Une des hiérarchies d’une dimension. Voir aussi hiérarchie.
Historiser Stocker des données pour leur utilisation à long terme. Une fois historisées,
les données ne sont plus volatiles, elles entrent dans l’histoire (d’une
entreprise, par exemple). Voir datawarehouse.
HOLAP (Hybrid OLAP) La solution HOLAP combine les avantages des solutions
MOLAP et ROLAP.
Hypercube Voir cube.
Jeu de sélection Définit le niveau des données à insérer dans un rapport.
Jointure imbriquée Action de fusionner le contenu de deux ou plusieurs dimensions et
de produire un ensemble de résultats qui englobe les lignes et les colonnes
de chaque dimension. Par exemple, une jointure imbriquée fusionne les
données des villes de la dimension Magasins et les données des boissons de
la dimension Produits.
Magasin de données Base de données spécialement structurée pour les requêtes et

l’analyse. Un magasin de données contient généralement des données qui
illustrent l’historique commercial d’une organisation.
MDB (Multidimensional DataBase) Permet le stockage, le traitement et la restitu-
tion de données multidimensionnelles.
MDX Voir expressions multidimensionnelles.
Membre Élément d’une dimension représentant une ou plusieurs occurrences de
données. Un membre peut être unique ou non. Par exemple, 2007 et 2008
sont les membres uniques du niveau Année d’une dimension de temps
tandis que Janvier représente les membres non uniques du niveau Mois car
la dimension de temps peut révéler plusieurs fois le mois de janvier si elle
contient des données sur plusieurs années.
Membre calculé Membre d’une dimension dont la valeur est calculée à l’aide d’une
expression. Les valeurs des membres calculés peuvent provenir des valeurs
d’autres membres. Par exemple, vous pouvez définir un membre calculé
Profit en soustrayant la valeur du membre Coûts de celle du membre Ventes.
Membre frère Membre de dimension qui n’a pas de descendants.
Mesure Dans un cube, ensemble de valeurs, généralement numériques, basées sur une
colonne dans la table de faits du cube. Les mesures sont des valeurs centrales
qui sont agrégées et analysées. Voir aussi cube, table de faits.
Métadonnées Les métadonnées constituent l’ensemble des données qui décrivent des
règles ou processus attachés à d’autres données.
Modèle en étoile Arrangement de tables dans une base de données relationnelles. Au
centre, on trouve la table de faits ; les branches de l’étoile qui rayonnent à
partir de la table de faits correspondent aux dimensions.
Modèle en flocon Le modèle en flocon reprend les principes du modèle en étoile ; le flo-
con est une étoile dont les branches sont décomposées en sous-hiérarchies.
MOLAP (Multidimensional OLAP) Stocke les données basiques et leurs agrégations
sur un serveur spécialisé OLAP.
Monter dans la hiérarchie/descendre dans la hiérarchie Technique permettant de
parcourir les niveaux de données, du plus synthétisé (vers le haut) au plus
détaillé (vers le bas). Par exemple, lorsqu’il consulte les données détaillées
des ventes annuelles, un utilisateur peut descendre d’un niveau dans la
hiérarchie pour afficher les données par trimestre, puis encore d’un niveau
pour afficher les données par mois.
Multidimensionnel Structure de données ayant au moins trois dimensions indépen-
dantes.
Niveau Nom désignant un ensemble de membres dans une hiérarchie de dimension
où tous les membres sont placés à distance égale de la racine de la
hiérarchie. Par exemple, une hiérarchie de temps comprend les niveaux
Année, Mois et Jour. Voir aussi dimension, hiérarchie.
Glossaire 411
Niveau hiérarchique Au sein d’une hiérarchie, les positions sont en général orga-
nisées en niveaux. Les positions d’un même niveau correspondent à une
classification précise.
Nom de membre Propriété d’un niveau de dimension qui spécifie les noms des
membres du niveau. La valeur de cette propriété peut désigner une colonne
dans laquelle figurent les noms ou une expression correspondant aux noms.
OLAP (Online Analytical Processing) Technologie utilisant des structures mul-
tidimensionnelles pour offrir un accès rapide aux données en vue d’une
analyse. Les données source OLAP sont souvent stockées dans les magasins
de données d’une base de données relationnelle. Voir aussi magasin de
données, base de données relationnelle.
Parent Membre du niveau supérieur suivant dans la hiérarchie directement associé
au membre actuel. La valeur parente est généralement une consolidation
des valeurs de tous ses enfants. Par exemple, dans une dimension de temps
composée des niveaux Trimestre, Mois et Jour, le trimestre 1 (Q1) est le
parent de Janvier. Voir aussi enfant, descendant, frère.
Pivoter (table pivot) Possibilité de modifier l’aspect d’un rapport en déplaçant un
champ (ou un groupe de champs) de ligne en colonne ou inversement. On
peut également ajouter des champs en les sélectionnant dans une liste de
choix.
Position Une valeur d’une dimension.
Propriété de membre Information supplémentaire stockée dans un cube OLAP
Analysis Services et décrivant un membre de dimension.
Rapport au format libre Rapport offrant une granularité au niveau des cellules et ne
dépendant pas de la structure des données source sous-jacentes. Les rapports
au format libre peuvent combiner des données de plusieurs sources OLAP.
Le rapport au format libre fait l’objet d’un add-in dans Excel. Il est intégré à
Excel 2007. Voir aussi rapport structuré.
Rapport structuré Rapport dépendant de la structure des données source sous-jacentes
et offrant des fonctions d’analyse avancées. Le rapport au format structuré
fait l’objet d’un add-in dans Excel. Il est intégré à Excel 2007.
Reporting Outil de mesure de faits a posteriori.
Repository Référentiel permettant de stocker les métadonnées c’est-à-dire les données
qui décrivent les données.
ROLAP (Relational OLAP) Les données ne sont pas stockées dans le cube mais dans
une base de données relationnelles selon les principes OLAP.
rollback Permet d’annuler un processus de mise à jour dans une base de données
relationnelle. La phase de Commit permet d’appliquer définitivement les
modifications apportées dans la base.
SGBD (système de gestion de bases de données) Les bases de données relationnelles
(SGBDR) ont tendance à se banaliser. Domaines de prédilection d’Oracle,
IBM (DB2), SQL Server, MySql.
SIAD (système d’information d’aide à la décision) Équivalent de EIS.

Supply chain Gestion et optimisation de la chaîne logistique, de la fabrication d’un
produit à sa distribution finale.
Table de faits Table centrale dans un schéma de magasin de données composée
de mesures numériques et de clés associant des faits à des tables de
dimension. Les tables de faits renferment des données qui décrivent des
événements inhérents à une activité commerciale, tels que des transactions
bancaires ou des ventes de produits. Voir aussi magasin de données.
Tableau de bord Rapport dynamique composé d’indicateurs clés d’une activité,
permettant d’avoir une vision globale des performances ; il s’agit d’un outil
de mesure et de pilotage.
Tableau croisé dynamique Action de transformer les lignes en colonnes et inverse-
ment.
Tablix Nouveau module de type région de données dans Reporting Services permet-
tant de combiner des rapports tabulaires et des rapports matriciels.
Total visuel Valeur de cellule agrégée et affichée pour un membre de dimension et
cohérente avec les valeurs de cellules affichées pour ses enfants. Le total
visuel d’une cellule peut être différent du total réel si certains enfants de la
cellule sont masqués. Par exemple, si la fonction d’agrégation est SUM, la
valeur de cellule affichée pour Espagne est 1000, celle de Portugal est 2000
et le total visuel pour Péninsule ibérique est 3000.
Tranche Sous-ensemble de données dans un cube, spécifié en limitant une ou plusieurs
dimensions en fonction des membres de la dimension. Par exemple, des faits
propres à une année donnée forment une tranche d’un ensemble de données
portant sur plusieurs années. Voir aussi axe.
Tuple Ensemble ordonné de membres appartenant à différentes dimensions. Par
exemple, (Boston, [1995]) est un tuple composé de membres de deux
dimensions : Géographie et Temps. Un membre unique est un cas dégénéré
de tuple qui peut être utilisé comme expression sans parenthèses. Voir aussi
axe.
Six Sigma Méthode de gestion de la qualité se donnant pour objectif un nombre très
restreint de défaillance dans les processus
up-sell Technique de vente consistant à proposer au client un produit générant une
marge plus élevée que celui demandé, soit typiquement un produit plus cher.
Cette technique s’appuie sur l’identification des besoins et habitudes de
consommation des clients, et en particulier sur du marketing one-to-one et
des outils CRM.
Bibliographie
Ouvrages sur la Business Intelligence

e-Business Intelligence, Bernard Liautaud avec Mark Hammond, Éditions Maxima,
2001.
Tableaux de bord et Balanced scorecards, Carla Mendoza, Revue Fiduciaire (Guide de
gestion), 2002.
L’essentiel du tableau de bord, Alain Fernandez, Éditions d’organisation.
The Microsoft Data Warehouse Toolkit – With SQL Server 2005 and the Microsoft Business
Intelligence Toolset, Ralph Kimball, John Wiley & Sons, 2006.
Le data warehouse, Guide de conduite de projet, Ralph Kimball, Laura Reeves, Margy
Ross, Warren Thornthwaite, Éditions d’Organisation, Fev. 2005.
The Multidimensional Manager. 24 ways to impact your bottom line in 90 days, Richard
Connelly, Robin McNeill, Roland Mosimann Cognos, Juin 2001.
The Multidimensional Organization. How to deliver the 24 ways, Richard Connelly,
Roland Mosimann, Cognos, Avril 1999.
Microsoft OLAP Solutions, Erik Thomsen, George Spofford, Dick Chase, Editions
Wiley, 1999.
Mesurer et développer les performances, Jean-Pierre Mercier, Éditions Quebecor, 2003.
Indicateurs et tableaux de bord; 100 questions pour comprendre et agir, Roger Aïm, Éditions
AFNOR, 2004.
Le pilotage opérationnel de l’entreprise, Jean-Michel Treille, Éditions d’Organisation,
2004.
Analyse financière et reporting avec Excel, Joseph Rubin, Éditions d’Organisation, 2004.
Le tableau de bord facile, Daniel Boix – Bernard Féminier, Éditions d’Organisation,
2003.
Le Management Cockpit, Patrick M. Georges, Éditions d’Organisation, 2002.
Data Mining with SQL Server 2005, ZhaoHui Tang – Jamie MacLennan, John Wiley
& Sons, 2005.
Diriger un projet Informatique – Les secrets des consultants, Jacques Claviez, Éditions JCI
inc., 1993.
Scénarios pour la NET Économie, Karim Mokhnachi, Sandra Spinek Éditions d’Orga-
nisation, 2000.
Le tableau de bord prospectif, pilotage stratégique : les quatre axes du succès, Kaplan Robert
S. et Norton David P., Éditions d’Organisation, 1998.
Maîtriser les processus de l’entreprise, Michel Cattan Nathalie Idriss, Patrick Knockaert.,
Éditions d’Organisation, 2005.
Quel système décisionnel pour les entreprises agiles ?, Philippe Nieuwbourg Editions
Microsoft, mai 2004.
Le guide Decideo, Philippe Nieuwbourg, Luc Mornat, Véronique Blanc, Marcom
Generation, 2004.
Applied Microsoft SQL Server 2008 Replorting Services, Teo Lachev, Prologika, 2008.
Microsoft SQL Server 2008 – Business Intelligence Development and Maintenance (MCTS
Self-Paced Training Kit . EXAM 70-448), Microsoft Press, 2009.
Liens vers des sites Internet

• Site de l’auteur : Nombreux compléments, trucs et astuces, formations et
liens utiles : http://www.buroformatic.com
• Le site de référence Microsoft pour la Business Intelligence :
http://www.microsoft.com/france/decisionnel/
• Site des utilisateurs de SQL Server : http://www.guss.fr/
• Site français des développeurs :
http://business-intelligence.developpez.com/
• Site de Ralph Kimball : http://www.kimballgroup.com/
• Site de Bill Inmon : http://www.billinmon.com
• Site de l’Institut du Management de l’Université de Savoie :
http://www.imus.univ-savoie.fr/
• Site de présentation de Office Performance Point :
http://www.microsoft.com/france/decisionnel/applications/scorecard.aspx
• Business Intelligence en Open Source :
– http://www.palo.net/
– http://www.pentaho.com/
• Site mondial d’observation du marché OLAP : http://olapreport.com
Index
A base de données multidimensionnelle 167

BIDS 95
accès au détail (drillthrough) 250
BO 58
action 15, 211, 250
ActiveX 347 briefing book 356
add-in Excel 378 BSC 33
agent SQL Server 93 Business Intelligence 7, 13, 32, 246
agrégations 251 Business Objects 387
paramétrer les 256 Business Performance Management 378
alimentation 14 Business Scorecard Management 61
analyse 174 Business Scorecard Manager 351
ad hoc 167, 334 intégré 56
de cube 343
de données avec Excel 333 C
de séquence 267
cache proactif 168, 176
Analysis Services 165
calcul 174, 210, 244
approche itérative 371
capture instantanée 322
arbre de décomposition 77, 352
carte de performance 78, 354
assistant
cellule feuille 242
d’exportation 136
checkpoint 43
d’importation 136
association 267 classification 266
attribut 171 clé
lié 239 étrangère 223
attrition 24 principale 223
CLR (Common Langage Runtime) 169
Clusters 271, 284
B cockpit 13
balanced scorecard 33, 59 de pilotage 382
Bâle 2 22 Codd, Edgar 10
Cognos 387 attributs 237

collecte de données 14 de data mining 172
comportement semi-additif 247 de fait 171
concepteur de rapport 294 de référence 171
configuration 157, 160 hiérarchie 223
conteneur intelligence 246
de boucle For 102 parent-enfant 87
de boucle Foreach 99 plusieurs à plusieurs 172
de séquences 102 propriétés 236
conversion monétaire 247 structure 239
cookies 20 temporelle 44
CPM (Corporate Performance utilisation 243
Management) 388 DMX (Data Mining Extensions) 105
CRM 19 domaine
cross-sell 20 analytique 11
Crystal 58 transactionnel 11
cube 210, 241 donnée catégorielle 69
déploiement 179 drill down 44, 76, 167, 221, 326
local 340 drill up 167, 221
multidimensionnel 165
OLAP 167
E
cycle en V 30
échelle
nominale 70
D
ordinale 70
Dashboard Server 361, 362 écriture différée 247
data mining 166, 263 EIS (Executive Information System) 25
datamart 86, 91 enjeux du décisionnel 9
dataset 297 entrepôt de données 91
datawarehouse 17, 42, 86 ERP 11, 42
Date, Chris 10 espace d’analyse 14
décision ETL (Extract, Transform, and Load) 42,
stratégique 62 167
tactique 62 d’entreprise 379
Decision tree 271, 284 étude de faisabilité 31
dénormalisation 92 Excel 387
destination 117 2007 346
développement linéaire 371 explorateur de Package 97
dimension 167, 168, 171, 179, 182, 183,
210, 234
F
à multiples hiérarchies 87
à variation lente (slowly changing FASMI 52
dimensions) 44, 87, 123 fichier plat 119
Index 417
filtre 221 J
flux
journal des audits 170
de contrôle 92, 95
juste à temps 22
de données 92, 96, 118
fonction lookup 93
fouille de données 56
FrontPage 347 K
FTP 95
Kaplan, Robert 33, 382
Fuzzy lookup 60
Key Users 58
Kimball, Ralph 44, 86, 162, 414
G KPI (Key Performance Indicator) 24, 43,
gestion 56, 73, 168, 211, 247
des rapports 307
du risque 22
gestionnaire L
d’événements 96
de rapports 293 loi SOX 42
graphique croisé dynamique 338 LOLF 22
GRC 19 lot 92
groupe de mesures 172, 241
H M
HOLAP (Hybride OLAP) 252 mapping 122
Hyperion 387 MapPoint 378
MDX
I script 169, 174
indicateur membre
clé de performance 24, 175 calculé 246
de performance 59 inféré 124
externe 15 non-feuille 242
infocentres 25 mesure 46, 167, 179, 182
informatique décisionnelle 7 calculée 245
Inmon, Bill 414
semi-additive 232
Integration Services (SSIS) 89
metadata 169
Intellicube 179
Microsoft Access 382
intelligence comptable 246
intervalle Microsoft Clustering 273
de latence 177 Microsoft Decision Trees 271
de reconstruction forcée 177 Microsoft Naïve Bayes 273
IRR 375 migration de lots DTS 150
modèle P
Clusters 281
package 92
d’autorisations 169 automatisation de l’exécution 154
de données entité-relation 45 déploiement 153
Decision Tree 276 dynamique 157
dimensionnel 42, 45 enfant 110
multidimensionnel 168 parent 110
Naïve Bayes 279 Panorama software 61
relationnel 168 partition 211
modélisation 55 partitionnement multiple 255
MOLAP (Multidimensional OLAP) 252 PAS (Proclarity Analytics Server) 355
MS Access 348 performances 170
MS Excel 348 période
MS Query 342 de latence 177
silencieuse 177
N perspective 172, 211, 250
PGI 11, 42
Naïve Bayes 271, 284 PivotTable 334
navigateur 211, 227, 240 plan 114
de données 250 Planification 322
navigation planning 22
en mode web 359 POC (Proof Of Concept) 383
Professional 359 Powerplay 58, 387
standard 359 procédure stockée 169, 175
niveaux d’abstraction 12 processus 181
Norton, David 33, 382 d’apprentissage 12
NPV 375 de décision 9
Proclarity 61, 77, 351, 352
O for Business Scorecard 352
Professional 361
Office productivité 21
2007 61 projet décisionnel 383
Excel pour SSAS 334, 342 prototype 384
PerformancePoint 378 push 176
Web Components 378
OLAP (On Line Analytical Processing) 9,
50, 52, 166, 232 R
OLTP (On Line Transactional Processing) rapport
42, 45, 49, 167 abonnement 324
opérateur unaire 247 clichés d’historique 322
OWC (Office Web Component) 334, 347, exécution 321
351 historisation 323
Index 419
lié 320 SMDL (Semantic Model Definition

RDL 382 Language) 327
recherche SMTP 325
exacte 93 sniffing 170
floue 93 solution décisionnelle 377
référentiel 54 Solver 62
métier 12 source 117
région de données 297 de données 178, 184
régression 266 spoofing 170
relation SQL Server Agent 155
d’écart ou de déviation 73 SQLiMail 116
de comparaison nominale 75 SSAS 231
de corrélation 74 SSIS 84
de distribution 74 SSRB 326
Report Builder 58, 294, 326, 382 SSRS 291
reporting 16, 26, 43, 52 stratégie 14
financier 22
interactif 347 T
Reporting Services 61, 289
droits 313 table
rôles 315 de dimensions 46
tâches 313 de faits 46
réseau de dépendance 278 tableau
retour sur investissement 374 croisé dynamique 58, 168, 334
ROI 375 de bord 13, 15, 25, 59
ROLAP (Relational OLAP) 252, 254 tâche
rôle 169, 171, 308 d’exécution de Package 110
administrateur système 316 d’exécution de Package DTS 2000
utilisateur système 317 110
roll-up 167 d’exécution de processus 110
rollback 42 d’exécution de requêtes SQL 111
d’insertion en bloc 112
DDL 103
S
de flux de données 104
Sarbane-Oxley 22 de profilage des données 104
Scénario 62 de requête d’exploration de données
schéma 105
en étoile 45 de script 105, 106
en flocons 183 de service Web 108
sécurité 307 de système de fichiers 108
segmentation 267 de traitement Analysis Services 109
serveur de rapports (Report server) 293 de transfert d’objets SQL Server 110
SharePoint Portal 56, 61, 378 de transfert de base de données 109
de transfert de connexions 109 U

de transfert de messages d’erreur 109 UDM (Unified Dimensional Model) 58, 85,
de transfert de procédures stockées 86, 168, 177, 346
110 up-sell 20
de transfert de travaux 114
Envoyer un message 113 V
FTP 113 Visual Studio 382
Lecteur de données WMI 114 vue
des sources de données (Data Source
MSMQ 114
Views, DSV) 178
observateur d’événements WMI 114 en perspective 79, 354
XML 114
Time Intelligence 246 W
traçabilité 170 workflow 95
traduction 211, 240, 250 writeback 169
traitement incrémentiel 257
transformation 117 X
translation 169 XML 84
InfoPro l’essentiel
type d’ouvrage
se former
retours
d’expérience
Bertrand Burquier
Management des systèmes
d’information
applications
Business Intelligence
métiers
études, développement,
intégration
avec SQL Server 2008 exploitation

et administration
réseaux
Mise en œuvre d’un projet décisionnel & télécoms
Cet ouvrage s’adresse aux directeurs informatiques, administratifs,

financiers et opérationnels, ainsi qu’à tout responsable informatique
ayant à mettre en œuvre des systèmes décisionnels. Il intéressera
aussi les consultants et les architectes en systèmes d’information. Bertrand Burquier
Cet ouvrage permettra aux étudiants de faire le lien entre la théorie est consultant
et la réalisation concrète en entreprise. et ingénieur en systèmes
d’information, spécialisé
On assiste aujourd’hui à une démocratisation de l’informatique dans la Business
Intelligence. Il dirige
décisionnelle. Chaque décideur qui le souhaite peut désormais depuis 1985 le cabinet
disposer de puissants outils d’analyse, de reporting ou de data de conseil BuroFormatic.
Il est également
mining (analyse prédictive). formateur en entreprise
Cet ouvrage donne un cadre méthodologique à la mise en œuvre et encadre de nombreux
projets décisionnels.
d’un projet décisionnel complet, en s’appuyant sur les nouvelles Il enseigne la Business
fonctions de Business Intelligence offertes par SQL Server 2008. Intelligence à l’Institut
de management de
Après avoir passé en revue les principes fondamentaux qui président l’université de Savoie.
à la réalisation d’un projet décisionnel, il identifie les pièges à éviter,

les facteurs clés de succès et les meilleures pratiques. Il montre
ensuite comment une solution de Business Intelligence permet
de mettre en œuvre les indicateurs stratégiques de l’entreprise,
et comment les interpréter pour définir des prévisions et détecter
des cibles, ou des tendances.
Des cas concrets expliquent comment tirer profit de la Business
Intelligence dans l’entreprise avec SQL Server 2008.
De nombreuses ressources complémentaires sont

disponibles sur le site www.buroformatic.com
ISBN 978-2-10-054197-3 www.dunod.com

Business Intellig

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 Intellig

Transféré par

Droits d'auteur :

Formats disponibles

Business

applications & métiers

Microsoft® SQL Server® 2008

Illustration de couverture : arbres d automne © Jean-Michel POUGET-Fotolia.com

© Dunod, Paris, 2009

Chapitre 1 – La Business Intelligence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Chapitre 2 – L’approche méthodologique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.2 Pourquoi un tableau de bord ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Chapitre 3 – Comment représenter les données ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

3.1.2 Données quantitatives ou catégorielles ?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Chapitre 4 – Entrepôt de données et analyse décisionnelle . . . . . . . . . . . . . . . . . . . . . . 81

Chapitre 5 – Introduction à Integration Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Chapitre 6 – Les assistants de l’ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

6.2.2 Les variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

Chapitre 7 – Analysis Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

Chapitre 8 – Méthode de conception des cubes avec SSAS . . . . . . . . . . . . . . . . . . . . . 231

8.2.2 Les différents modes de stockage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

Chapitre 9 – Le data mining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263

Chapitre 10 – Reporting Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289

10.4 Reporting à la demande avec Report Builder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326

Chapitre 11 – L’ analyse de données avec Excel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333

Chapitre 12 – L’analyse de données sur le Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351

Chapitre 13 – Passez à l’action ! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371

13.3.4 Compatibilité, ouverture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380

Annexe A – Petit historique de la BI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391

« Voudriez-vous me dire, s’il vous plaît,

L’organe d’observation indépendant OlapReport a mesuré la progression fulgurante

Figure 1 — Magic Quadrant for Business Intelligence Platforms (Source Gartner)

En parallèle, Microsoft proposera aussi un référentiel de données présentant des

1.1 LA BUSINESS INTELLIGENCE POUR QUI,

Que signifie le terme « intelligence » ?

Et l’expression « Business Intelligence » ?

1.2 OBJECTIFS ET ENJEUX DU DÉCISIONNEL

Les moyens pour y parvenir sont :

Le cycle du projet comprend plusieurs étapes :

1.3 LE PROCESSUS DE DÉCISION OU LE FACTEUR

quelques années a servi de niche technologique à certains éditeurs bien connus,

1.3.1 Comprendre les besoins d’aide à la décision

1.3.2 Agir, analyser, décider, agir...

Figure 1.1 — Le cycle décisionnel dans l’entreprise

La compréhension du mode de consommation des informations et de la façon dont

La mise en place du référentiel métier

Les niveaux d’abstraction

1.3.3 Tableau de bord et business intelligence

Figure 1.2 — Dans le cockpit : suivre le plan de vol

Les voyants affichent immédiatement de nouvelles données reflétant la nouvelle

Quel parallèle avec la Business Intelligence ?

Figure 1.3 — Les étapes de la prise de décision dans l’entreprise

1.3.4 En quoi la BI est-elle utile à l’entreprise ?

qualité, en tirent déjà un avantage en terme de réputation et de profitabilité ». Selon

Les atouts de l’information et l’évaluation des données

La valeur « temps » des données

L’information en tant que ressource partageable

Bernard Liautaud, président et PDG de Business Objects a écrit dans un ouvrage

L’accroissement de la valeur proportionnellement à son usage

L’accroissement de la valeur au travers de la qualité

L’accroissement de la valeur grâce à la fusion

La valeur face au volume

La mesure de la valeur de l’information

Les applications de la Business Intelligence

La durée de vie d’un client

L’analyse de la productivité du capital humain

L’analyse des produits défectueux