Business Intelligence Avec SQL Server 2005 PDF

INFOPRO
B. BURQUIER
BUSINESS
APPLICATIONS & MÉTIERS

TYPE D’OUVRAGE
RETOURS
L'ESSENTIEL SE FORMER
D'EXPÉRIENCE
Bertrand Burquier
MANAGEMENT DES SYSTÈMES
D'INFORMATION
APPLICATIONS
MÉTIERS
INTELLIGENCE
AVEC
ÉTUDES, DÉVELOPPEMENT,
INTÉGRATION
BUSINESS INTELLIGENCE
EXPLOITATION
BUSINESS INTELLIGENCE ET ADMINISTRATION
RÉSEAUX
SQL SERVER 2005

& TÉLÉCOMS
AVEC SQL SERVER 2005
Mise en œuvre d'un projet décisionnel
Ce livre s’adresse aux directeurs informatiques, administratifs, BERTRAND BURQUIER

est consultant et ingénieur
financiers et opérationnels, ainsi qu’à tout responsable informatique
ayant à mettre en œuvre des systèmes décisionnels. Il intéressera
en systèmes d’information,
spécialisé dans la Business Mise en œuvre
Intelligence. Il dirige depuis
aussi les consultants et les architectes en systèmes d’information.
On assiste aujourd'hui à une démocratisation de l'informatique
1985 le cabinet de conseil
BuroFormatic. Il est
d'un projet décisionnel
également formateur en
décisionnelle. Chaque décideur qui le souhaite peut désormais entreprise et enseigne la
Business Intelligence à
disposer de puissants outils d'analyse, de reporting ou de data l’Institut de management de
mining. l’université de Savoie.
Cet ouvrage donne un cadre méthodologique à la mise en œuvre

d’un projet décisionnel complet, en s’appuyant sur les nouvelles
fonctions de Business Intelligence offertes par SQL Server 2005.
Après avoir passé en revue les principes fondamentaux qui président
à la réalisation d’un projet décisionnel, il identifie les pièges à
éviter et les facteurs clés de succès. Il montre ensuite comment
une solution de Business Intelligence peut analyser les
renseignements stratégiques de l'entreprise, quels sont les différents
indicateurs disponibles, et comment les interpréter pour définir
des cibles, des prévisions ou des tendances.
Des cas concrets expliquent comment mettre en œuvre la Business
Intelligence dans l’entreprise avec SQL Server 2005.
De nombreuses ressources complémentaires sont disponibles sur
le site www.buroformatic.com. Bertrand Burquier
6639389
ISBN 978-2-10-050536-4 www.dunod.com
burquier_prelims.fm Page I Vendredi, 8. décembre 2006 2:01 14
BUSINESS
INTELLIGENCE
AVEC
SQL SERVER 2005
Mise en œuvre
d’un projet décisionnel
Bertrand Burquier
Consultant et ingénieur en systèmes d’information
burquier_prelims.fm Page II Vendredi, 8. décembre 2006 2:01 14
Toutes les marques citées dans cet ouvrage sont des

marques déposées par leurs propriétaires respectifs.
Photographie de couverture : Bertrand Burquier

Lac d’Annecy
© Dunod, Paris, 2007

ISBN 978-2-10-050536-4
Table des matières
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Chapitre 1 – La business intelligence . . . . . . . . . . . . . . . . . . . . . . 5

1.1 La business intelligence pour qui, pour quoi ? . . . . . . . . . . . . . . . 5
1.2 Objectifs et enjeux du décisionnel . . . . . . . . . . . . . . . . . . . . . 7
1.3 Le processus de décision ou le facteur humain dans la prise de décision . 7
1.3.1 Comprendre les besoins d’aide à la décision . . . . . . . . . . . . . . . 8
1.3.2 Agir, analyser, décider, agir… . . . . . . . . . . . . . . . . . . . . . 9
1.3.3 Tableau de bord et business intelligence . . . . . . . . . . . . . . . . . 11
1.3.4 En quoi la BI est-elle utile à l’entreprise ? . . . . . . . . . . . . . . . . 14
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é . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.1.4 Le cycle de vie du projet BI selon Ralph Kimball . . . . . . . . . . . . 33
IV —————————————————————————————————————————————————— Business Intelligence avec SQL Server 2005
2.2 Pourquoi un tableau de bord ? . . . . . . . . . . . . . . . . . . . . . . . . 34

2.3 Les différents types d’indicateurs . . . . . . . . . . . . . . . . . . . . . . . 35
2.3.1 Fonction Commerciale . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.3.2 Fonction Direction générale . . . . . . . . . . . . . . . . . . . . . . . 37
2.3.3 Fonction Ressources humaines . . . . . . . . . . . . . . . . . . . . . . 38
2.3.4 Fonction Production et recherche – développement . . . . . . . . . . . . 39
2.3.5 Fonction Logistique et approvisionnements . . . . . . . . . . . . . . . . 41
2.3.6 Fonction Achats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.3.7 Fonction Informatique – Études – Exploitation . . . . . . . . . . . . . 43
2.4 Deux mondes différents : OLTP et DW . . . . . . . . . . . . . . . . . . . 45
2.4.1 Qu’est-ce qu’une transaction ? . . . . . . . . . . . . . . . . . . . . . . 46
2.4.2 Les utilisateurs et les gestionnaires . . . . . . . . . . . . . . . . . . . . 46
2.4.3 La dimension temporelle . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.4.4 Le modèle de données entité-relation pour les développeurs . . . . . . . . 49
2.4.5 Le modèle dimensionnel pour les analystes . . . . . . . . . . . . . . . . 49
2.5 Comparatif des deux modèles de stockage des données . . . . . . . . . . . 53
2.5.1 Le modèle transactionnel (OLTP) . . . . . . . . . . . . . . . . . . . . 53
2.5.2 Le modèle multidimensionnel (OLAP) . . . . . . . . . . . . . . . . . . 55
2.5.3 Synthèse OLTP et OLAP . . . . . . . . . . . . . . . . . . . . . . . . 56
2.5.4 Modèle simplifié FASMI . . . . . . . . . . . . . . . . . . . . . . . . . 56
2.6 OLAP ou reporting ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
2.7 Le processus décisionnel
avec SQL server 2005 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
2.8 Les erreurs à éviter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
2.8.1 Le facteur Humain . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
2.8.2 Le facteur Technique . . . . . . . . . . . . . . . . . . . . . . . . . . 65
2.9 Les règles du succès . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
2.9.1 Règle 1 – Comprendre les utilisateurs . . . . . . . . . . . . . . . . . . 67
2.9.2 Règle 2 – Distinguer les décisions stratégiques ou tactiques . . . . . . . . 68
2.10 Construire le tableau matriciel des besoins . . . . . . . . . . . . . . . . . 69
Chapitre 3 – Comment représenter les données ? . . . . . . . . . . . . . . . . 73
3.1 Concepts généraux et pratiques . . . . . . . . . . . . . . . . . . . . . . . 74
3.1.1 Tableaux ou graphiques ? . . . . . . . . . . . . . . . . . . . . . . . . 74
3.1.2 Données quantitatives ou catégorielles ? . . . . . . . . . . . . . . . . . 75
Table des matières ——————————————————————————————————————————————————————————————————————— V
3.2 Les nouveaux outils offerts par le complément Proclarity . . . . . . . . . 84

3.2.1 L’arbre de décomposition . . . . . . . . . . . . . . . . . . . . . . . . 84
3.2.2 La carte de performance . . . . . . . . . . . . . . . . . . . . . . . . 85
3.2.3 La vue en perspective . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Chapitre 4 – Entrepôt de données et analyse décisionnelle . . . . . . . . . . 89
4.1 Architecture de la plate-forme décisionnelle . . . . . . . . . . . . . . . . 92
4.2 Les améliorations de SQL Server 2005 par rapport à la version 2000 . . . 94
4.2.1 Actuellement, comment développons-nous un projet BI ? . . . . . . . . 94
4.2.2 Quels sont les défis à relever ? . . . . . . . . . . . . . . . . . . . . . 94
4.3 Les nouveaux composants dans SQL Server 2005 . . . . . . . . . . . . . 96
4.3.1 Les vues des sources de données (Data Source Views, DSV) . . . . . . 96
4.3.2 Les cubes et UDM . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
4.3.3 Les perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
4.3.4 Le cache proactif . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
4.4 Les améliorations apportées avec SQL Server 2005 SP1 . . . . . . . . . 98
4.4.1 La mise en miroir des bases de données . . . . . . . . . . . . . . . . . 98
4.4.2 Une création facilitée de rapports
sous SAP NetWeaver business intelligence . . . . . . . . . . . . . . . 99
4.5 Les services de notification . . . . . . . . . . . . . . . . . . . . . . . . . 99
Chapitre 5 – Introduction à Integration Services . . . . . . . . . . . . . . . . 101
5.1 Présentation de SQL Server Integration Services (SSIS) . . . . . . . . . 101
5.2 Migrer un package DTS 2000 . . . . . . . . . . . . . . . . . . . . . . . . 112
5.3 Migrer une base SQL Server 2000 vers SQL Server 2005 . . . . . . . . . 113
5.4 Tâches d’intégration services . . . . . . . . . . . . . . . . . . . . . . . . 114
5.5 Composants des flux de données . . . . . . . . . . . . . . . . . . . . . . 129
Chapitre 6 – Règles d’ETL et assistants . . . . . . . . . . . . . . . . . . . . 145
6.1 Utiliser l’assistant pour générer un lot import . . . . . . . . . . . . . . . 146
6.1.1 Créer le projet d’importation . . . . . . . . . . . . . . . . . . . . . . 146
6.1.2 Exécuter le lot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
6.1.3 Modifier le lot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
6.1.4 Migration de lots DTS de la version 2000 vers 2005 . . . . . . . . . . 163
6.1.5 Déploiement de packages SSIS . . . . . . . . . . . . . . . . . . . . . 167
6.1.6 Automatisation de l’exécution des packages . . . . . . . . . . . . . . . 169
VI —————————————————————————————————————————————————— Business Intelligence avec SQL Server 2005
6.2 Concept de packages dynamiques . . . . . . . . . . . . . . . . . . . . . . 171

6.2.1 Les expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
6.2.2 Les variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
6.2.3 Les configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
6.2.4 La gestion des événements . . . . . . . . . . . . . . . . . . . . . . . . 176
6.3 Planification du projet ETL . . . . . . . . . . . . . . . . . . . . . . . . . 176
6.3.1 La carte de haut niveau . . . . . . . . . . . . . . . . . . . . . . . . . 176
6.4 Les 38 règles qui régissent l’ETL . . . . . . . . . . . . . . . . . . . . . . . 177
Chapitre 7 – Analysis Services . . . . . . . . . . . . . . . . . . . . . . . . . . 179

7.1 OLAP et le data mining . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
7.2 Points d’amélioration entre Analysis 2000 et SSAS 2005 . . . . . . . . . 183
7.3 Méthodologie de création d’une base de données
depuis une source existante . . . . . . . . . . . . . . . . . . . . . . . . . 192
7.4 Création de notre premier cube . . . . . . . . . . . . . . . . . . . . . . . 194
7.4.1 Mesures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
7.4.2 Dimensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
7.4.3 Le schéma en flocons . . . . . . . . . . . . . . . . . . . . . . . . . . 198
7.4.4 Créer le projet « Mon Premier Cube » à l’aide
de l’environnement UDM d’Analysis Services . . . . . . . . . . . . . . 199
7.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Chapitre 8 – Méthode de conception des cubes avec SSAS . . . . . . . . . . . 229

8.1 Organisation logique des cubes . . . . . . . . . . . . . . . . . . . . . . . 230
8.1.1 Définition de la structure OLAP . . . . . . . . . . . . . . . . . . . . . 230
8.1.2 Définir les dimensions . . . . . . . . . . . . . . . . . . . . . . . . . . 232
8.1.3 Modification du cube . . . . . . . . . . . . . . . . . . . . . . . . . . 239
8.1.4 L’utilisation des dimensions . . . . . . . . . . . . . . . . . . . . . . . 242
8.1.5 Les calculs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
8.1.6 Ajouter de la business intelligence . . . . . . . . . . . . . . . . . . . . 245
8.1.7 Les indicateurs clé de performance (KPI) . . . . . . . . . . . . . . . . 246
8.1.8 Les actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
8.1.9 Les perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
8.1.10 Les traductions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
8.1.11 Le navigateur de données . . . . . . . . . . . . . . . . . . . . . . . . 250
Table des matières ——————————————————————————————————————————————————————————————————————— VII
8.2 L’organisation physique du cube . . . . . . . . . . . . . . . . . . . . . . 250

8.2.1 Les groupes de mesures et les partitions . . . . . . . . . . . . . . . . . 250
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.3 Recommandations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
Chapitre 9 – Le data mining . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
9.1 Méthodologie de création du modèle de data mining . . . . . . . . . . . 260
9.1.1 Définition du problème à résoudre . . . . . . . . . . . . . . . . . . . 260
9.1.2 Préparation des données . . . . . . . . . . . . . . . . . . . . . . . . 261
9.1.3 Construction du schéma de données . . . . . . . . . . . . . . . . . . 261
9.1.4 Création du modèle . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
9.1.5 Exploration du modèle . . . . . . . . . . . . . . . . . . . . . . . . . 261
9.1.6 Validation du modèle . . . . . . . . . . . . . . . . . . . . . . . . . . 262
9.1.7 Déploiement du modèle . . . . . . . . . . . . . . . . . . . . . . . . . 262
9.2 Quelles sont les tâches du data mining ? . . . . . . . . . . . . . . . . . . 262
9.3 Créer le modèle d’une campagne ciblée . . . . . . . . . . . . . . . . . . 264
9.3.1 Créer la source des données . . . . . . . . . . . . . . . . . . . . . . . 265
9.3.2 Créer la vue de source des données . . . . . . . . . . . . . . . . . . . 265
9.3.3 Créer le modèle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
9.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
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 La création de rapport . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
10.3 La gestion des rapports . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
10.3.1 La sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
10.3.2 Les rapports liés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
10.3.3 L’exécution de rapports . . . . . . . . . . . . . . . . . . . . . . . . . 318
10.3.4 L’historisation des rapports . . . . . . . . . . . . . . . . . . . . . . . 321
10.3.5 Abonnements aux rapports . . . . . . . . . . . . . . . . . . . . . . . 323
10.4 Reporting à la demande avec Report Builder . . . . . . . . . . . . . . . 324
VIII —————————————————————————————————————————————————— Business Intelligence avec SQL Server 2005
10.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329

Chapitre 11 – L’analyse de données avec Excel . . . . . . . . . . . . . . . . . 331
11.1 L’analyse ad hoc grâce aux tableaux croisés dynamiques . . . . . . . . . . 332
11.2 Complément Microsoft Office Excel
pour SQL Server Analysis Services . . . . . . . . . . . . . . . . . . . . . 340
11.3 Reporting interactif sur le web avec OWC . . . . . . . . . . . . . . . . . 344
11.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
Chapitre 12 – L’analyse de données sur le Web . . . . . . . . . . . . . . . . . 347
12.1 Proclarity for Business Scorecard Manager . . . . . . . . . . . . . . . . . . 348
12.1.1 L’arbre de décomposition . . . . . . . . . . . . . . . . . . . . . . . . 348
12.1.2 La carte de performance . . . . . . . . . . . . . . . . . . . . . . . . . 350
12.1.3 La vue en perspective . . . . . . . . . . . . . . . . . . . . . . . . . . 351
12.2 Proclarity Analytics Server (PAS) . . . . . . . . . . . . . . . . . . . . . . . 351
12.3 Dashboard Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
12.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
Chapitre 13 – Passez à l’action ! . . . . . . . . . . . . . . . . . . . . . . . . . 361
13.1 Les caractéristiques du chef de projet décisionnel . . . . . . . . . . . . . 362
13.2 Quel est le retour sur investissement ? . . . . . . . . . . . . . . . . . . . . 365
13.3 Faire une offre de solution décisionnelle . . . . . . . . . . . . . . . . . . 368
13.3.1 Un ETL d’entreprise, Integration Services . . . . . . . . . . . . . . . . 369
13.3.2 Un SGBD pour la gestion des gros volumes de données . . . . . . . . . 370
13.3.3 Une architecture qui garantit la disponibilité des données . . . . . . . . . 371
13.3.4 Compatibilité, ouverture . . . . . . . . . . . . . . . . . . . . . . . . . 371
13.3.5 Productivité dans le développement d’applications
liées à SQL Server 2005 . . . . . . . . . . . . . . . . . . . . . . . . . 371
13.3.6 Administration renforcée . . . . . . . . . . . . . . . . . . . . . . . . . 372
13.3.7 Sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
13.3.8 Analysis Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
13.3.9 Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
13.3.10 Donner un véritable cockpit de pilotage de l’activité
adapté aux différents niveaux de l’organisation . . . . . . . . . . . . . 373
13.4 Comment mettre en place un projet décisionnel ? . . . . . . . . . . . . . 374
13.4.1 Objectifs de la preuve de faisabilité . . . . . . . . . . . . . . . . . . . . 375
13.4.2 Faisabilité sur site . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
Table des matières ——————————————————————————————————————————————————————————————————————— IX
13.4.3 Livrables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375

13.4.4 Planning pour le déploiement de la solution . . . . . . . . . . . . . . . 375
13.4.5 Prototype/pilote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
13.4.6 Opérations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
13.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
A – Petit historique de la BI . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
B – Le marché mondial de la BI aujourd’hui . . . . . . . . . . . . . . . . . . 386
C – Les différentes versions de SQL Server 2005 . . . . . . . . . . . . . . . 391
D – Les profils d’apprentissage des différents acteurs de la BI . . . . . . . . 395
E – Glossaire de la BI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
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’acti-

vité 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
programmes 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.
2 ————————————————————————————————————————————————————————————————————————————— Introduction
Cependant, la complexité de mise en œuvre du datawarehouse et la création des

cubes multidimensionnels 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 Ser-
ver 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.
L’organe d’observation indépendant OlapReport a mesuré la progression ful-
gurante 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, disponible depuis le 8 novembre 2005, a eu
un grand retentissement. Cette nouvelle version intègre les développements les
plus récents en matière de business intelligence. Les développeurs et adminis-
trateurs de bases de données ont été entendus et disposent désormais d’outils
complets à tous les niveaux de la fabrication de la chaîne de valeur de l’infor-
mation.
Malgré ces avancées technologiques, le constat est affligeant. Aujourd’hui, la
plupart des entreprises, y compris les PME/PMI, disposent d´une masse d´infor-
mations de plus en plus importante sur leurs clients, leurs ventes, leurs produits,
leurs fournisseurs leurs concurrents… dont elles ne font rien ! Croisées, analy-
sées, filtrées, ces informations pourraient pourtant devenir un formidable trem-
plin pour se différencier de la concurrence, améliorer les résultats de l’entreprise,
suivre avec précision ses activités ou fidéliser les clients. Les entrepreneurs avisés
sont pourtant demandeurs de synthèses rapides, de tableaux de bord clairs pour
ne plus piloter leur entreprise à l’intuition.
Il est pourtant évident que les informations stockées dans les nombreux silos
de données répartis dans l’entreprise ne peuvent plus être traitées de manière
artisanale. Il n’est pas rare de constater que certains cadres passent leur temps à
ressaisir dans Excel des données puisées dans des documents fournis par les sys-
tèmes opérationnels (ERP, comptabilité, stocks, production, ventes, RH, etc.).
L’objectif est cependant louable : il s’agit de créer son tableau de bord personnel.
Naturellement chaque division procède de la même manière pour élaborer
son propre tableau de synthèse. Par conséquence, lorsque les cadres se réunissent en
comité interdépartementaux, il n’est pas rare d’observer des synthèses incohérentes
Introduction ————————————————————————————————————————————————————————————————————————————— 3
ou contradictoires. Au-delà du fait que l’informatique est une fois de plus mon-
trée du doigt et discréditée, les décisions qui devraient naturellement découler
de ces réunions sont reportées sine die.
En revanche, les entreprises concurrentes qui ont déployé des outils de busi-
ness intelligence perdent moins de temps en réunion et en discussion stériles, car
les indicateurs sont en permanence connus de tous, chaque cadre opérationnel dis-
posant des leviers permettant d’agir avec intelligence dans des délais très courts.
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. »
Cet ouvrage a pour ambition d’offrir une vision méthodologique de la fabri-
cation 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 direc-
tions 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 intel-
ligence à leurs tâches quotidiennes.
Les directeurs informatiques, responsables informatiques et bureautiques, dis-
poseront d’une méthode de mise en œuvre de la chaîne décisionnelle au service
des acteurs opérationnels de l’entreprise.
4 ————————————————————————————————————————————————————————————————————————————— Introduction
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
organismes 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.
Il a également pour objectif d’aider à définir les étapes clés d’un projet déci-
sionnel, 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émocratisa-
tion 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 éloi-
gné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 ?
Aide à la décision, datawarehouses, entrepôts de données, ETL, EIS, SIAD, struc-

tures multidimensionnelles OLAP, business intelligence, extranets, portails décision-
nels, datamarts… les acronymes et termes relatifs à la business intelligence sont
particulièrement riches. Mais ces termes abondants, parfois abscons, qui revien-
nent 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 dans le chapitre suivant le large éventail des domaines dans les-
quels 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 dis-
cours est dans ce cas très technique et s’attache à mettre en avant les performan-
ces, 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 satis-
faire des besoins d’analyse de l’activité immédiate de l’entreprise. Dans le
6 ————————————————————————————————————————————————————————————————— 1. La business intelligence
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 par-
ticuliè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.
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éli-
cate 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éces-
saire à la création de l’entrepôt de données, centre névralgique des applications
décisionnelles.
1.2 Objectifs et enjeux du décisionnel ——————————————————————————————————————————————————————— 7
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 Analytic Processing)
qui pendant quelques années a servi de niche technologique à certains éditeurs
bien connus, vient de faire une avancée 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 intelli-
gence depuis la découverte des bases de données relationnelles, dont les fonde-
ments 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 exis-
tent 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 cen-
traux, 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 expri-
ment é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é. »
1.3 Le processus de décision ou le facteur humain dans la prise de décision ————————————————————— 9
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.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 confronter leur stra-
té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 trans-
forme 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 pro-
priété intellectuelle et de son avantage compétitif. La compréhension et l’inter-
pré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 exem-
ple, une tendance à la baisse du taux de pénétration peut conduire à un change-
ment 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éterminant
pour leur productivité. En effet, dans l’entreprise, le référentiel métier est-il faci-
lement accessible ? Est-il centralisé sur un serveur partagé ou bien stocké loca-
lement 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 comman-
des, 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 compren-
dre. 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ésenta-
tion, 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, repro-
duisant 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 don-
né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é 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écou-
vrez la signification des différentes jauges et autres voyants lumineux.
Progressivement, vous vous familiarisez avec les indicateurs tels que position
(latitude, 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 nou-

velle orientation de l’avion. La trace est immédiatement 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 stoc-
ké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, Transfor-
ming, 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
visualisation des indicateurs de performance sous forme de reporting, d’analyse
multidimensionnelle et de data mining (découverte des causes et des effets) syn-
thé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, for-
tes 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 chan-
gements de comportements pour atteindre les objectifs.
Voici synthétisé le modèle du processus de prise de décision transposé à l’entre-
prise.
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 nou-
velles 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 particu-
lièrement délicat, aussi nous observerons dans ce chapitre la différence fonda-
mentale 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 aborderons 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’orga-
nisation, 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 nom-
bre 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 exem-
ple 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 infor-
mation 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 rapide-
ment.
L’information en tant que ressource partageable

Contrairement à toute autre ressource matérielle utilisée dans le processus de
fabrication, 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 nom-
bre de services dans lesquels ces utilisateurs travaillent ». (e-business intelligence,
Éditions Maxima).
Valeur de l’information =
(Nombre d’utilisateurs)² × (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 pro-
duit, 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 trans-
mise 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 com-
ment 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 devien-
nent 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éces-
sité 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 informa-
tion 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 con-
cerne 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éces-
sairement plus de valeur par l’accroissement d’information. La quantité phéno-
mé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 don-
né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 (ges-
tion 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 inte-
ragit 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 pren-
nent 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écou-
verte 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 affi-
ché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 recom-
mandations 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 col-
lecter 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 pro-
ductivité.
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,
production 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 promul-
gué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 finan-
ciers qui ont défrayé récemment la chronique. Indépendamment de leur carac-
tè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 rapide-
ment 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 Spon-
soring 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énements 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 exem-
ple 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égo-
ciation 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 conver-
gence 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 agis-
sent 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 fournis-
seurs 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’approvisionnement 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 arrive-
ront à 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 uti-
lisées en analyse technique boursière. L’analyse d’une action sur une durée signi-
ficative 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 pro-
duit. 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écol-
lage 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 prati-
ciens 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’acti-
vité de l’entreprise. Il synthétise les différentes activités et mesures de cette der-
niè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 ana-
lyses sous forme d’indicateurs, dans une représentation synthétique et compré-
hensible. Des 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.
1.4 Les modèles d’accès à l’information ————————————————————————————————————————————————————— 25
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’entre-
prise. 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, sont 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 complai-
sance de la situation des trois modèles qui gouvernent l’accès à l’information
dans l’entreprise. 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-infor-
matique, silos de données et applicatifs personnels vont progressivement se met-
tre 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 bureau-
tiques 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énomè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 cen-
tralisation des données. Chaque département tend à garder jalousement les infor-
mations 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 com-
plexité 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, comp-
tabilité, GPAO, CRM, ventes, etc.
Les approches traditionnelles ont très vite montré leurs limites. Le dévelop-
pement 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 capa-
cité 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 rapide-
ment s’imposer.
1.4.3 La démocratie de l’information

De par sa démarche structurante, la business intelligence offre un nouveau para-
digme :
• Partager le métier de l’entreprise et la transparence de l’information à tous
les échelons de la hiérarchie.
1.4 Les modèles d’accès à l’information ————————————————————————————————————————————————————— 27
• Disposer d’outils d’analyse conviviaux et accessibles en tous lieux (y com-

pris sur Internet) sans l’aide d’un spécialiste.
• Réduire les coûts de mise à disposition des informations stratégiques de
l’entreprise.
• Libérer les ressources humaines des contraintes fortes des systèmes infor-
matiques au profit du métier de l’entreprise.
• 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 dis-

poser 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
projet BI nécessite une demande d’autorisation d’investissement (DAI).
Cet engagement de dépense fait suite à une estimation fine des éléments
économiques du projet (nombre de jours/homme d’étude, de développe-
ment, 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 permet-

tant 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;
30 ————————————————————————————————————————————————————————————— 2. L’approche méthodologique
• 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.
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î-
nement 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.
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 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.
2.1 Les étapes d’un projet informatique ————————————————————————————————————————————————————— 31
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
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 documen-
tation 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éveloppe-
ment. 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 cher-
chant à 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écifica-
tions 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 ras-
surer les deux parties (fournisseur et client) en apportant au fournisseur une connais-
sance 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 don-
né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 fonc-
tionnelles (découverte d’un domaine parmi finances, achats, commercial, com-
munication, 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 permet-
tant de chiffrer avec plus de précision le développement et le déploiement de la
solution globale.
2.1 Les étapes d’un projet informatique ————————————————————————————————————————————————————— 33
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 par-
ticipant 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.
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écuri-
taires, 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).
On distingue clairement les quatre axes ou perspectives stratégiques :
• la perspective financière;
• la satisfaction des clients;
• les processus internes;
• l’apprentissage organisationnel.
2.3 Les différents types d’indicateurs ———————————————————————————————————————————————————————— 35
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
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 inci-
dence forte sur le résultat. Ils ont démontré à quel point la satisfaction de l’action-
naire (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).
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 composan-
tes 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 sco-
recard, sujet sur lequel il existe une littérature abondante (se référer à la biblio-
graphie en fin d’ouvrage). En revanche, nous donnerons à titre d’exemple
quelques indicateurs qui nous paraissent essentiels au bon pilotage de l’entre-
prise. 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
Quantités vendues par secteur, par produit, Par secteur, par produit,
par client par client
Nouveaux clients
Nombre de commandes
Activité
Clients n’ayant pas commandé depuis x temps
Nombre de prospects visités
Nombre de devis émis
Taux de transformation sur devis
Nombre de réclamations reçues et traitées
Délai de livraison client

Qualité
Taux de renouvellement des contrats
d’entretien
Taux de rupture
Frais commerciaux Par nature, par secteur

Coût
Contribution/coût Par agence
Promotions
Engagements publicitaires Par famille de produit

Coût
Frais de voyage et déplacement Par secteur
Coût des stocks obsolètes
Indices d’évolution d’achat de vente
Observation Suivi de la compétitivité
Concurrence
Effectifs
Embauches
Humains Démissions
Primes versées
Nouveaux projets
2.3.2 Fonction Direction générale
CA net, Quantités nettes Par secteur, par produit,

par client
Marge brute
Part de marché
Croissance du marché
Activité
Rentabilité des capitaux investis
Fonds de roulement
Taux de rotation des clients, fournisseurs, stocks
Carnet de commandes
Indice de qualité selon métier de l’entreprise
Qualité Délai de livraison
Nombre de réclamations
Main d’œuvre de production
Coût de revient des produits
Coût Frais généraux Par nature
Frais commerciaux Par secteur
Sous-traitance
Indices d’évolution d’achat de vente
Suivi de la compétitivité
Observation Concurrence
Grands projets d’investissements
Nouveaux projets
Effectifs (internes/externes), embauches,

démissions
Taux d’absentéisme
Humains
Moral des troupes
Fréquence des accidents du travail
2.3.3 Fonction Ressources humaines
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
Activité Nombre de candidatures pour pourvoir

un poste
Nombre de candidatures spontanées
Effectif Par catégorie, par sexe,

par âge
Effectif interne/externe
Activité Productifs/Improductifs
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

Qualité
% de postes en binôme
Nombre d’annonces nécessaires

pour pourvoir un poste
Nombre de licenciements
Turnover
Coût moyen d’un recrutement

Coût
Salaires Par département,
catégorie
Prévisions des départs en retraite
Observation Prévision de création de postes
Nouvelles formations
Heures supplémentaires
Taux d’absentéisme
Humains
M3oral des troupes
Mobilité du personnel
2.3.4 Fonction Production et recherche – développement
Capacité de production
Coût de revient des produits Standard/réel
Activité 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

Activité
Maintenance préventive
Niveau des stocks/activité par nature matières premières,

produits semi-finis,
produits finis
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

Qualité
Respect du délai clients,
suivi du délai fournisseurs
Délai de fabrication
Retard moyen des projets et études
Consommation d’heures Par atelier et par produit
Coût de main d’œuvre de R&D

Coût
Sous-traitance
Énergie
Planning de production
Observation Carnet de commandes
Évolution du prix des matières premières
Embauches démissions
Humains Absentéisme/turnover
Qualification du personnel
Taux d’improductifs
2.3.5 Fonction Logistique et approvisionnements
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
Activité Écarts sur inventaire
% de stock mort
Surface de stockage utilisée
Nombre de transporteurs
Nombre de références gérées en stock
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

Qualité
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 total du transport
Coût transport Par transposteur/

m3 transporté
Coût
Coût moyen d’acheminement Par fournisseur
Coût des stocks Par m3, total
Observation Carnet de commandes

Humains
Absentéisme/turnover
2.3.6 Fonction Achats
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

Activité
Nombre d’appels d’offre
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
Délai moyen de traitement d’une commande

fournisseur
Qualité
Nombre de relances
Nombre d’avoirs, de litiges
Performance des fournisseurs

Qualité
Qualité des négociations
Taux de couverture des besoins
Salaires
Dépenses de fonctionnement
Coût
Coût moyen de traitement d’une commande Total/par fournisseur
Coût moyen de recherche de fournisseur
Études de marché fournisseurs
Observation Évolution du marché
Carnets de demandes d’achats
Humains
Absentéisme/turnover
2.3.7 Fonction Informatique – Études – Exploitation
Rentabilité des investissements
Marge de contribution d’une nouvelle

application
Analyse des temps d’étude

Activité
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 heures

Activité
Nombre de programmes en exploitation
Nombre d’heures machines
Nombre de pages éditées
Respect du budget
Retard moyen
% heures de tests/heures d’études
% maintenance/études nouvelles
Délai de réponse aux demandes

Qualité
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
Dépenses globales
Ventilation des dépenses Par logiciel/personnel,

études/exploitation
Salaires Ingénieurs, techniciens,

Coût développeurs
Heures machines de tests/Production
Heures ingénieur
Coût moyen par transaction

2.4 Deux mondes différents : OLTP et DW ——————————————————————————————————————————————————— 45
Carnet de commandes
Nouvelles applications
Planning prévisionnel de charge
Observation 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é
Embauches/démissions
Humains
% 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 uti-
lisateurs différents. Le processus transactionnel (OLTP, Online Transaction Pro-
cessing) 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’entreprise, saisie dans des tableaux Excel, etc.). Le second joue le rôle de concen-
trateur 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 particu-
lière de stockage, OLAP, qui n’est qu’une représentation optimisée du dataware-
house. 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 centai-
nes 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 exis-
tantes. L’historique des mouvements est donc intégralement conservé. Ce méca-
nisme participe à la sacro-sainte traçabilité de l’information en entreprise
(loi SOX). Ce processus porte le nom d’ETL : extraction, transformation, char-
gement (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 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 perma-
nence 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 res-
ponsabilité. 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 sys-
tè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’inter-
rogent 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 les-
quels bien souvent une seule ligne (en général la dernière) est utile pour l’ana-
lyse. 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.
Figure 2.4 — Voici un tableau qui doit pouvoir être fourni

par un système basé sur un datawarehouse
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 dis-
position de l’utilisateur final (l’analyste métier).
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, Editions Wiley, parle alors de base de données scintillante. On com-
prend 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 suc-
cession 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 dataware-
house 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 évolu-
tions 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ées 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ées 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
datawarehouse règle deux problèmes connus dans les bases transactionnelles :
• À la différence de l’OLTP, le datawarehouse est au repos lorsque les uti-

lisateurs 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 2005) permet de mettre en œuvre le processus de stockage des ins-
tantané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 dataware-
houses réside dans le modèle relationnel. La modélisation d’un système OLTP
vise essentiellement à réduire la redondance des données de telle sorte que les
transactions modifient les données à un endroit unique. Le modèle entité-rela-
tion 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 sta-
tiques, 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 organisa-

tion, 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
envisagées dans une journée.
• Compte tenu de la complexité du schéma des tables, le département infor-
matique 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 lan-
gage 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 cer-
tain nombre de tables. À la différence d’un modèle entité-relation, la table cen-
trale 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 Inter-
netSales. 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
Indicateurs
Quand ? Qui ? Quoi ? Où ?
(Combien ?)
Année (historique Équipes Éditeur Enseigne CA & Qté vendues
sur 10 ans)
Repré- Catég. Prod. Libraire CA & Qté retournées
Mois sentants
Collection Remise en % et valeur
Jour
Titre de l’ouvrage Retours en % et valeur
Cumul à ce jour
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’ouvre
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
…
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 ——————————————————————————————————— 53
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
En guise de synthèse, nous proposons un comparatif entre les modèles de stoc-

kage 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 lan-
gage (SQL) afin d’accéder aux données utilisateurs ou aux métadonnées (struc-
ture 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 logi-
quement 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 rela-
tionnelle 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 correspon-
dante 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).
2.5 Comparatif des deux modèles de stockage des données ——————————————————————————————————— 55
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 cas-
cade (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ù provien-
nent 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’utili-
sateur.
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 pro-
duits 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écu-
rité 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 (bases
OLAP (cubes
transactionnelles
analytiques)
de production)
Collaborateur, cadre Cadre fonctionnel, décideur

Utilisateur
opérationnel
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)
Lecture/écriture Lecture seule (écriture

Accès
de simulation possible)
Transaction (insertion/ Requête complexe

Unité de travail suppression, mise à jour). hiérarchique.
Langage SQL Langage MDX
Nb enregistre- Quelques enregistrements Millions d’enregistrements

ments 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’acro-
nyme 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.
2.6 OLAP ou reporting ? —————————————————————————————————————————————————————————————————— 57
• 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’uti-
lisateur.
• 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 Ana-
lysis 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 multidimen-
sionnelle 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 com-
posants.
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épon-
dre à 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 don-
né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éra-
tionnelle, 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.
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 pro-

jets 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 perfor-
mance 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 sou-
cier 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é fonction-

nelle 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éces-
siteraient des jours de programmation dans des environnements de déve-
loppement traditionnels.
Voici deux exemples de requêtes qu’il est aisé de traiter au travers d’un sys-
tè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 ?
2.6 OLAP ou reporting ? —————————————————————————————————————————————————————————————————— 59
• 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ésen-
tations 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 » permettant de réaliser des simulations sur les données opérationnel-
les). Ces technologies permettent des restitutions dynamiques au travers de navi-
gateurs 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éfini-
tion 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 combi-
naisons 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 exem-
ple, 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 techno-
logies OLAP récentes ont considérablement repoussé les limites de taille. Il n’est
pas rare de rencontrer des cubes de quelques giga-octets avec des performances
tout à fait acceptables.
Si les données sont volumineuses et utilisées à leur niveau le plus bas, le stoc-
kage 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 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 nom-
bre 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 directe-
ment sur le serveur de DW.
La centralisation du référentiel métier, utilisé par les décisionnaires pour l’éla-
boration 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 restitu-
tion 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 multidi-
mensionnelle de données. De nouvelles possibilités sont alors apparues en par-
ticulier 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
2.7 Le processus décisionnel avec SQL server 2005 ——————————————————————————————————————————— 61
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 tempo-
rairement 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éa-
lisé à 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 techno-
logies 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

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 multi-
dimensionnel (schéma en étoile relationnel). Cette fonction est remplie
par Integration Services.
• Transformation du modèle multidimensionnel relationnel en modèle hyper-

cube 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, parti-
cipent à 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.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, Crys-
tal…). 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é-
2.8 Les erreurs à éviter ———————————————————————————————————————————————————————————————————— 63
Processus décisionnel avec SQL server 2005

données multiples
Sources de
SGBD (Oracle/ ERP

DB2, SQL, Ole Prog. Gestion
DB) intégrée Comptabilité,
RH,
Production
Transformer,
Nettoyer,
rafraichir
Extraire,
Integration Services
de données
Entrepôts
Datamart
Datamart Datamart Datamart
Processus
Finance Clients Apprentissage
internes
Modeliser
Structures de données
Multidimensionnelles
Analysis Services
CUBE OLAP
à perspectives
multiples
Restituer
Restitution et analyses
Excel, Proclarity
100 %
90 80
70 60 70
% % 50 40 50 60
% % 30 40 % %
% % % %
%
Piloter
Analyses, Reporting, Data Mining

Tableau de bord
BSM
Figure 2.8 — Les différentes composantes du processus décisionnel avec SQL Server 2005
pendance à l’égard des informaticiens qui jusque-là étaient les seuls concepteurs
de leurs requêtes.
Nous le verrons plus loin, SQL Server 2005 apporte des réponses à cette caté-
gorie d’utilisateurs grâce à Report Builder. (outil de création de requêtes et rap-
ports à 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’infor-
mation 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 2005 propose la mise en place d’UDM permettant
de s’affranchir de la complexité du modèle de données sous-jacent. L’UDM, sou-
vent créé par l’administrateur des bases (DBA) est une interface visant à per-
mettre à 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.
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’informa-
tion 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 effi-
cacité 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 indi-
cateurs 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’indi-
cateur 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 Les erreurs à éviter ———————————————————————————————————————————————————————————————————— 65
2.8.2 Le facteur Technique

Les facteurs humains, sont naturellement fondamentaux dans la réussite du pro-
jet 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 atten-
tion 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ées 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 pro-
duire lors du déclenchement du processus sur la présence d’un fichier séma-
phore 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 plu-
sieurs 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épen-
ses 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 cor-
respondance 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 char-
gement devront être étudiés avec attention. Des procédures d’alertes en cas de
« plantage » devront ê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 ——————————————————————————————————————————————————————————————————— 67
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 repor-
ting services. 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 infor-
mations au travers de scorecard (Business Scorecard Management 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 particu-
lier 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, 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. 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 utili-
sateurs métiers. Ils communiquent avec les techniciens de l’information et peu-
vent 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 cor-
rélations, 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 associés à des outils tels que Desktop Professionnal
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éso-
lution de problème (Solver). 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’infor-
mation. 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 rapi-
dement les décisions nécessaires à l’action. Les 20 % restant représentent les ana-
lystes. 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 sont prises à 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 ven-
dus 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’orga-
nisation, 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 ?
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 —————————————————————————————————————————————— 69
2.10 CONSTRUIRE LE TABLEAU MATRICIEL

DES BESOINS
Dans un souci d’amélioration du dialogue avec les utilisateurs et afin de permet-

tre 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 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
Axes d’observation ou Dimensions
Organisation
Revendeur
Processus Métier
Comptes
Produits
Ateliers
Temps
Clients
Analyse des ventes X X X X X
Profitabilité
X X X X
par clients/produits
Finance.
X X X
Balance
Production
X X X X
Gestion de la capacité
L’étape suivante consiste à sélectionner un processus métier puis à décompo-

ser 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 recom-
mandé de présenter une ébauche du résultat final. Excel ou ACCESS permet-
tront de maquetter l’application finale et de simuler rapidement le résultat
attendu.
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.
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
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
Indica-
teurs
Temps Produits Revendeur Clients Organisation
– Année – Ligne Grossiste Enseigne Équipe de vente Qtés

de produit cdées
– Trimestre Distributeur Groupement Vendeur
– Marques Qté
– Mois VAR Magasins
vendues
– Catégorie Point de vente
– Jour
de produits Marge
– YTD
– Collection Remises
(cumul)
– Produit % remise
– Croissance
par période Prix
moyen
On peut également définir un jeu de test et présenter une ébauche au travers

d’un tableau croisé dynamique.
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. Rappe-
lons 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 —————————————————————————————————————————————— 71
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 intui-

tive. 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
information 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ésen-
tation 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 com-
muniquer 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.
74 ——————————————————————————————————————————————————————— 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 Graphique
Les données sont représentées sous Les données sont traduites en images.
forme de nombres.
Les données sont disposées en lignes Les données sont affichées en relation
et colonnes. sur un 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 ————————————————————————————————————————————————————————— 75
Figure 3.1 — Tableau de valeurs
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).
Figure 3.2 — Représentation graphique de données
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-dessous (figure 3.3) met en évidence la distinction entre les don-
né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. Typique-
ment nous retrouvons des notions de régions (Amérique, Asie, Europe, etc.) ou
départements (ventes, marketing, finance, production).
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
Figure 3.4 — Les trois types d’échelles catégorielles

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 cer-
tain 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 n’est pas très révélateur. 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 à inter-
valles 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 que 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
ité
Nombre de membres
tiv
c
Vi
40
'ac
t
in
eu
jo
ct
ad
107 Déposer
re
.
Di
eu D.G
champs
sit
Type de fonction
de
190 de séries
r
ici
n
io
ct
ct
re
350
n
Di
fo
tre
nt
ra
Au
643
G
n
io
ct
708
re
di
al
tre
ér
Au
én
1279
rg
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 rap-
port 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.
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).
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
tiv ité
G éra nt
ir ecti on
on
s ident
ur de s
ur géné
ncti
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 »
4. Relations d’écart ou de déviation

Lorsque des valeurs affichent des écarts entre des objectifs prévisibles et des réa-
lisations 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.
É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
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 perfor-
mance) 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.
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.
Figure 3.10 — Représentation d’un KPI. Avec représentation de la tendance
5. Relation de distribution
Un graphe de distribution permet de représenter comment un ensemble de don-
nées se répartit au sein d’un spectre unique. Il permet de représenter des phéno-
mè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 profes-
sionnel entre 44 et 55 ans, puis un départ brutal à 60 ans.
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

6. Relation de corrélation
Un graphe de corrélation mesure le rapport qui existe ou non entre deux varia-
bles. 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).
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 varia-
bles portées sur l’axe des X. Dans la figure 3.13, les quatre régions géographiques
Figure 3.13 — Graphe présentant la relation de comparaison nominale

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écrois-
sant afin d’établir un classement.
Exemple de cheminement d’une 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étails 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 chemi-
nement à priori imprévisible.
Figure 3.14 — Graphe d’analyse des ventes
Déterminer le meilleur moyen pour représenter les valeurs
Tableau 3.1 — 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
Type de relation Méthodes privilégiées pour la représentation
Tout ou partie Barres

Barres empilées
Secteurs dont les parties sont matérialisées par un %
Déviation/Écart/ Histogrammes double 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 KPI (feux tricolores, flèches)

et tendances
3.2 LES NOUVEAUX OUTILS OFFERTS

PAR LE COMPLÉMENT PROCLARITY1
3.2.1 L’arbre de décomposition

L’arbre de décomposition permet d’analyser des données selon des chemine-
ments 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.
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.
3.2 Les nouveaux outils offerts par le complément Proclarity ——————————————————————————————————— 85
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).
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

3.2 Les nouveaux outils offerts par le complément Proclarity ——————————————————————————————————— 87
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 (Cle-
veland).
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 informa-
tions 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’indi-
cateurs et d’axes d’analyse de leur métier. Les responsables opérationnels s’inter-
rogent 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 per-
mettant 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éa-
lisé 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
90 —————————————————————————————————————————————— 4. Entrepôt de données et analyse décisionnelle
d’un système d’information vis-à-vis duquel ils mesurent leur incapacité à le faire
évoluer.
D’un autre côté, les responsables des systèmes d’information passent une
grande partie de leur acticité à maintenir en état de fonctionnement des orga-
nisations techniques complexes. Les nombreuses fusions et acquisitions consta-
té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 quel-
ques 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 couteux.
Tableau 4.1 — Répartition des modules SQL Server 2005 par composants
Module SQL Destination

Composant
Server 2005 dans l’entreprise
Extract, Transform, Integration services Administrateur de bases

Load (ETL) de données
Entrepôt de données Base de données Administrateur

relationnel et relationnelle SQL Server et développeur
multidimensionnel 2005
Base de données Analysis services Développeur et utilisateur

multidimensionnelle ayant des connaissances
analytique métier (Key User)
Exploration de données Data Mining intégré Statisticien et/

à Analysis services ou (Key User)
Création de rapports Reporting Services Développeur et Key User

et modèles de base
Requêtes et analyses Report Builder, Excel 200X, Analystes métier

spécifiques Proclarity, Office web
component. (Excel 2007
pour la lecture des KPI)
Développement SQL Server business Développeur

d’application BI intelligence Development
Studio
Outils de gestion de base SQL Server Management Administrateurs/

de données Studio développeurs
Services de notification SQL Server Notification Alertes envoyées aux

Services managers sur des
événements métier
(rupture de stock, etc.)
Entrepôt de données et analyse décisionnelle ———————————————————————————————————————————————— 91
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 maitriser leur métier que les techniciens
garants de l’intégrité des systèmes d’information de l’entreprise.
La première tentative de Microsoft dans le domaine de la BI fut réussie grâce
à l’introduction de DTS et Analysis Services dans la version de SQL Server 7
puis 2000. Fort de cette expérience mais conscient également de certaines lacu-
nes de cette première version, Microsoft vient de mettre sur le marché sa toute
dernière version : SQL Server 2005, fruit d’une longue réflexion alimentée par
les pratiques des meilleurs consultants de la planète en matière de SGBD et
d’analyse décisionnelle.
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).
Tableau 4.2 — Répartition des modules par tâche fonctionnelle
Fonction Outil disponible Particularité

Conception BIDS (business intelligence Le développement de script permet
Development Studio) construit un débogage dans tous les
sur Visual Studio 2005 composants BI
Synthèse DTS entièrement réécrit porte le nom Présente une vision transparente
d’Integration Services dans la version des données de sources hétérogènes.
SQL Server 2005 Le partitionnement simplifie la gestion
des données historiques
Stockage UDM (Unified Data Model) permet La mise en cache proactive permet un
d’unifier le monde relationnel stockage en temps réel des données
et multidimensionnel transactionnelles
Analyse Les cubes multidimensionnels, Les KPI (indicateurs clés
les perspectives, les algorithmes de performance) participent à
de data mining ont été enrichis 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 auprès
Les formats de restitution sont divers des utilisateurs
(Excel, PDF, XML, CSV, etc.)
Gestion SQL Server Management studio Administration centralisée et intuitive
intègre la gestion de tous permettant une mise en œuvre aisée
les composants de SQL Server 2005 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 2005, les modules
suivants sont installés :
• Moteur de la base de données relationnelle;
• Integration services;
• Analysis Services;
• Reporting Services (nécessite le gestionnaire des services Internet IIS ins-
tallé et configuré sur le serveur);
• SQL Server Management Studio pour la gestion des bases de données;
• BIDS (business intelligence Development Studio) pour le développement
d’applications BI.
Les informations de métadonnées d’Analysis Services sont stockées sous

forme de fichiers XML et totalement gérées par Analysis Services. Cette inno-
vation peut cependant dérouter lorsque l’on est habitué au mode de fonction-
nement de la console d’Analysis Services 2000. 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.
Cette pratique est pour le moins surprenante de la part de Microsoft qui a misé
sur une interface très conviviale par ailleurs. Gageons que ces quelques lacunes
seront comblées par les prochaines versions.
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 commu-
nication 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 à la nouvelle architecture de SQL Server 2005.
Les améliorations en termes d’analyse décisionnelle incluent :
• Plate-forme intégrée. SQL Server 2005 constitue une plate-forme d’ana-

lyse décisionnelle et analytique de bout en bout qui intègre OLAP (On
4.1 Architecture de la plate-forme décisionnelle —————————————————————————————————————————————— 93
Line Analytical Processing), l’exploration de données, les outils ETL

(Extract, Transform and Load) d’extraction, de transformation et de char-
gement de données, les entrepôts de données et des fonctionnalités de rap-
ports.
• Prise de décision améliorée. Les améliorations des fonctions décisionnel-
les existantes, comme OLAP et l’exploration de données, et l’introduction
d’un nouveau serveur de rapports 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é à mon-

ter 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. Un outil ETL amé-
lioré 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, les organisa-
tions pourront obtenir un avantage sur leurs concurrents grâce à une
meilleure compréhension de leurs activités.
4.2 LES AMÉLIORATIONS DE SQL SERVER 2005

PAR RAPPORT À LA VERSION 2000
SQL Server 2005, en plus d’offrir des innovations nombreuses en matière de

SGBD, répond à plusieurs défis propres à la business intelligence. De nouveaux
composants intégrés dans l’interface graphique de Visual Studio permettent un
développement et un déploiement aisés de la BI. Au risque d’apparaître moins
académique que ses concurrents, Microsoft veut démocratiser la business intel-
ligence 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 don-
né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 uti-
lisateurs. 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 adminis-
trateurs 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 nou-
veau modèle UDM (Unified Dimensional Model) d’Analysis Services 2005. Ce
nouveau 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 dimension-
nels 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.
4.2 Les améliorations de SQL Server 2005 par rapport à la version 2000 ———————————————————————— 95
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ésen-
ter 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 sen-
sibles 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.
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 seu-
lement 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 dimen-
sions 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 développé avec Analysis Services de SQL
Server 2000 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é-
rarchiques. 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 appar-
tiennent bien au même client mais ne présentent pas de caractère hiérarchique
entre eux. Dans Analysis Services 2000, ces attributs généraient des dimensions
différentes.
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éci-
sions. 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).
4.3 LES NOUVEAUX COMPOSANTS

DANS SQL SERVER 2005
SQL Server 2005 répond à tous ces défis en offrant plusieurs composants nou-
veaux. Les plus largement commentés sont UDM (Unified Dimensional Model)
et le cache Proactif. Voici quelques-unes des innovations.
4.3.1 Les vues des sources de données (Data Source Views, DSV)
Les systèmes BI extraient leurs données d’un grand nombre de sources différentes.
La nouvelle technologie du DSV permet à l’administrateur du cube de concevoir
un accès aux données des ERP ou d’autres systèmes opérationnels. Les adminis-
4.3 Les nouveaux composants dans SQL Server 2005 ————————————————————————————————————————— 97
trateurs d’ERP, très soucieux de conserver l’intégrité et la sécurité des données

dont ils ont la responsabilité, apprécient particulièrement cette technologie qui
sécurise les accès aux tables tout en offrant aux développeurs de cube une vue
sélective des données de base. Les DSV permettent d’accéder à toutes sortes de
sources différentes tels que fichiers XML, fichiers textes, fichiers Excel, tout en
les considérant comme des tables. De plus, les DSV permettent de renommer des
champs de manière plus conviviale, ou de créer des relations virtuelles entre les
tables sans jamais toucher à la structure des tables sous-jacentes.
4.3.2 Les cubes et UDM

UDM est un outil de modélisation multidimensionnelle. De ce fait, il ressemble
à l’outil Analysis Services 2000. Cependant, l’outil de modélisation a été pro-
fondément remanié dans SQL Server 2005. Alors qu’avec Analysis Services 2000
il était nécessaire de créer autant de cubes que de types d’analyses (table de fait
unique), UDM peut créer un modèle dimensionnel unique applicable à l’ensem-
ble de l’entreprise en regroupant dans un schéma synthétique toutes les tables
de faits et de dimensions.
En regard des commentaires que nous faisions plus haut, cette technique
apporte une sérieuse réponse dans le cadre de la non-redondance d’information
et donc satisfait notre recherche de centralisation de la « vérité ».
On le voit, UDM répond à notre défi n° 1, « les différentes versions de la
vérité », tout en offrant une richesse supplémentaire à la construction du modèle.
De plus le nouveau modèle permet de construire des dimensions non hiérarchi-
ques basées sur les attributs de dimensions et cela sans perte de performance.
Cette amélioration répond à notre défi n° 4 « le schéma en étoile ne permet pas
de modéliser la complexité des données ».
Alors que les outils du marché privilégient encore la multiplication des data-
marts, l’UDM consolide la plate-forme centrale tout en la rendant plus cohérente.
Il n’existe plus qu’une seule vue analytique de l’information de l’entreprise. Le
terme « unifié » du modèle UDM (Unified Dimensional Model) prend tout son sens.
4.3.3 Les perspectives

La conséquence de ce qui précède entraîne une plus grande complexité du modèle
multidimensionnel. Si tous les indicateurs de l’entreprise se retrouvent mainte-
nant dans un unique modèle, il va falloir offrir aux utilisateurs un moyen de
clarifier leurs recherches. D’où la notion de « perspectives » permettant des obser-
vations dans le cube en fonction du métier et du département de l’utilisateur.
L’enjeu consiste donc à cacher des mesures qui ne sont pas pertinentes à l’analyse.
4.3.4 Le cache proactif

Maintenant que nous avons maîtrisé le modèle d’analyse, le rendant adapté aux
différents groupes de travail, il s’agit de maîtriser le processus d’alimentation du
cube et en particulier de définir la cadence de rafraîchissement des données en
provenance des sources opérationnelles. Le cache proactif permet de définir la
fréquence de mise à jour des données, soit en fonction du temps (plusieurs fois
par heure) soit en fonction d’événements notifiés par la base opérationnelle.
(exemple : la mise à jour du contrat d’un client entraîne une répercussion immé-
diate dans le cube et donc sa mise à jour). Cela répond au défi n° 5 : « les sys-
tèmes BI actuels ne permettent pas le rafraîchissement de données OLAP en
temps réel ». Dans la pratique les données intermédiaires sont stockées dans un
espace mémoire temporaire (cache proactif) grâce à Notification Services puis
appliquées définitivement lors du traitement complet du cube.
4.4 LES AMÉLIORATIONS APPORTÉES

AVEC SQL SERVER 2005 SP1
Le Service Pack 1 (SP1) de Microsoft SQL Server 2005 intègre de nouvelles

fonctionnalités comme la mise en miroir des bases de données (database mirro-
ring) ou encore SQL Server Reporting Services (SSRS) ainsi qu’un nouvel outil
d’administration pour SQL Server Management Studio Express. Le SP1 offre
également des mises à jour de SQL Server 2005 Express Édition à destination
des éditeurs de logiciels indépendants qui désirent tirer parti de fonctionnalités
innovantes.
4.4.1 La mise en miroir des bases de données

Cette nouvelle fonctionnalité complète les fonctions existantes de SQL Server
2005 afin d’assurer une disponibilité totale des données, comme le cluster de
basculement, les clichés instantanés de bases de données, l’isolation de ces der-
niers ou l’envoi de journaux de transactions.
De nouvelles fonctionnalités intégrées à SQL Server 2005 Express Édition

Le SP1 étend les possibilités des petites entreprises et des éditeurs de logiciels
indépendants qui utilisent la version gratuite SQL Server 2005 Express Edition.
Cette dernière intègre désormais la fonction SQL Server Reporting Services
(SSRS), la recherche de texte intégral, et également le nouvel outil, SQL Server
Management Studio Express.
4.5 Les services de notification ————————————————————————————————————————————————————————————— 99
4.4.2 Une création facilitée de rapports

sous SAP NetWeaver business intelligence
Afin d’offrir une vision complète de l’activité de l’entreprise via la génération
de rapports sur SAP NetWeaver business intelligence, le SP1 apporte des com-
pléments à l’outil SSRS. Il s’appuie sur deux nouveaux composants : un fournis-
seur de données Microsoft.NET pour SAP NetWeaver business intelligence et
un nouveau concepteur de requêtes MDX. Cette nouvelle fonctionnalité étend
les bénéfices de la génération de rapports d’entreprise sous SQL Server, en per-
mettant aux clients SAP de créer et gérer des rapports à partir d’informations
résidant dans un entrepôt de données SAP BW.
4.5 LES SERVICES DE NOTIFICATION
SQL Server 2005 a introduit le concept de notification d’événements program-

més. Le service de notification offre au développeur une plate-forme permettant
d’avertir l’utilisateur lorsque des événements particuliers sont repérés dans le
SGBD. L’alerte peut être donnée au moyen de dispositifs variés tels que plate-
formes mobiles, organiseurs personnels (PDA), téléphones cellulaires ou tout
autre dispositif.
Voici quelques exemples qui entrent dans le champ d’action de Notification
Services. :
• alerter lorsque l’ouvrage Harry Potter atteint le seuil de rupture de stock
et déclencher une nouvelle commande;
• prévenir lorsque le tableau Excel que je partage avec des collègues a fait
l’objet de modification;
• être informé lorsque mon compte bancaire est à découvert;
• être informé lorsqu’une valeur boursière a atteint telle limite;
• avertir le chef de production lorsqu’une pièce fabriquée est défectueuse;
• avertir le client sans délai lorsque tel article est à nouveau disponible en
stock.
Notification Services est utile chaque fois qu’un utilisateur désire s’abonner
à un service de réception automatique de documents ou lorsque des événements
se produisent sur tel ou tel critère. On parlera de souscription d’abonnements
pilotés par les données.
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 repor-
ting et d’analyse. Nous pensons que la phase d’ETL doit être menée avec une vigi-
lance 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’Integra-
tion Services associé à business intelligence Development Studio. Nous intro-
duirons 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éve-
loppeur un ensemble d’outils permettant de résoudre, quasiment sans program-
mation, des tâches qui rentrent naturellement dans le développement d’applications
102 ———————————————————————————————————————————————————————— 5. Introduction à Integration Services
décisionnelles 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 apprentis-
sage, 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
Integration Services (SSIS) est le successeur de DTS (Data Transformation

Services) inclus dans la version SQL Server 2000. Integration services a été entiè-
rement réécrit. Il reprend bien sûr les fonctionnalités de DTS et apporte un cor-
tège de nouveautés fort appréciables des professionnels de la BI. SSIS offre une
nouvelle interface graphique dont le but est d’alléger grandement le travail de
programmation.
En annexe, nous présentons les différents profils IT gravitant autour de SSIS.
Rappelons-les brièvement :
• administrateur de base de données;

• administrateur de serveur de rapports (informatique d’entreprise);
• expert en sécurité;
• administrateur d’entrepôts de données.
Bien que la fonction principale d’un ETL réside dans l’alimentation du data-
warehouse, SSIS fournit de nombreux outils visant à automatiser un grand nom-
5.1 Présentation de SQL Server Integration Services (SSIS) ————————————————————————————————————— 103
Figure 5.2 — Le cycle Integration Services (source Microsoft)
bre de tâches qui participent de près ou de loin à la construction de l’entrepôt

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 com-
plexes 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.
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, transfor-
mation 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 consi-
gnées dans un enchaînement de tâches élémentaires. Chacune de ces tâches est
destiné à 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.
Figure 5.3 — Un package enchaîne

différents types de tâches dans le flux de contrôle
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.
Les tâches de SSIS peuvent également exécuter des sauvegardes de bases

complètes ou traiter des cubes et des dimensions Analysis Services. 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 d’un ETL est de procéder à la dénormalisation des
tables lors du passage du modèle opérationnel (OLTP) au modèle multidimen-
sionnel (DW). 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 don-
nées (DW).
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 quel-
ques 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 com-
patibles 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’algo-
rithmes de recherche exacte ou floue à des fins de substitution et de standardisa-
tion. 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 frac-
tionner 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 ins-
tances ou d’autres bases.
Un package SSIS peut exécuter d’autres packages. Cela permet au déve-
loppeur 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 Mana-
gement 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).
Le concepteur graphique de SSIS est scindé en quatre modules distincts maté-
rialisé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 fonctionnement, 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.
Figure 5.4 — Schéma global des composants de SSIS
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 stoc-
ké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 transforma-
tion, 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

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.
Figure 5.5 — L’onglet Flux de contrôle et le gestionnaire de connexions

La figure 5.9 présente les éléments du flux de contrôle.
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 excep-
tions.
Figure 5.6 — L’onglet flux de données
L’onglet Gestionnaire d’événements

Il permet :
• 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ève-
ment 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.
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;
Figure 5.8 — L’onglet présentant l’explorateur des objets contenus dans un package
Figure 5.9 — Liste des outils mis à disposition

de l’administrateur pour le flux de contrôle
Figure 5.10 — Liste

des tâches disponibles
dans DTS 2000
• 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.10.
Figure 5.11 — Liste des connecteurs standard disponibles dans DTS 2000
5.2 MIGRER UN PACKAGE DTS 2000
Les packages définis dans SQL Server 2000 peuvent être récupérés dans SSIS
selon trois stratégies :
• Migrer les packages DTS au format SQL Server 2005. Cette migration
n’est possible que si les lots DTS 2000 n’utilisent que des fonctionnalités
ayant un équivalent dans SSIS 2005. Si lors de la migration l’assistant
détecte des erreurs, il convient alors d’utiliser une des deux stratégies sui-
vantes.
5.3 Migrer une base SQL Server 2000 vers SQL Server 2005 ——————————————————————————————————— 113
• Exécuter les lots DTS en utilisant le runtime DTS de SQL Server 2000.
• Intégrer ou encapsuler les lots DTS dans une solution SSIS 2005.
Ces assistants sont disponibles dans les versions SQL Server 2005 Standard,
Enterprise ou Developer.
L’assistant de migration est intégré à SSIS. Projet puis Migrer un package
DTS 2000.
Le site msdn de Microsoft recense les problèmes connus liés à la migration des
packages 2000 vers 2005 (http://msdn2.microsoft.com/fr-fr/library/ms143462.aspx).
5.3 MIGRER UNE BASE SQL SERVER 2000

VERS SQL SERVER 2005
Le processus de migration d’une base de données SQL Server 2000 vers 2005 peut
être réalisé grâce à une sauvegarde de la version 2000 (exemple Northwind.bak).
Dans Management Studio 2005, procéder à la création de la base NorthWind.
La restauration de la base SQL 2000 vers SQL Server 2005 nécessite d’établir
la compatibilité descendante vers SQL Server 2000 lors de la création de la base
dans SQL Server Management Studio 2005.
Figure 5.12 — Assurer un niveau de compatibilité SQL Server 2000

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 2005
afin de bénéficier des fonctionnalités avancées.
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 2005.
5.4 TÂCHES D’INTÉGRATION SERVICES
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.
Dans la figure 5.13, 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 liste des fichiers dans le conteneur de type répertoire est donnée figure 5.14.
5.4 Tâches d’intégration services ——————————————————————————————————————————————————————————— 115
Figure 5.13 — Boucle exécutant des commandes SQL de création de table
Figure 5.14 — Liste de fichiers dans un conteneur de type répertoire
Pour information voici le contenu du fichier portant le nom CreateProspect-

TableTerr1.SQL.
/* Creates the Territory table*/
IF NOT EXISTS (SELECT * FROM AdventureWorks.sys.tables WHERE
type = ‘U’and name = ‘Territory1’)
CREATE TABLE AdventureWorks.dbo.Territory1 (
[CustomerKey] [int] IDENTITY (1, 1) NOT NULL,
FirstName nvarchar (15),
MiddleInitial nchar (1),
LastName nvarchar (20),
BirthDate datetime,
MaritalStatus nchar (5),
Gender nchar (1),
Salutation nvarchar (10),
EmailAddress nvarchar (100),
YearlyIncome int,
TotalChildren tinyint,
NumberOfChildrenAtHome tinyint,
Education nvarchar(40),
Occupation nvarchar(30),
HomeOwner nchar (3),

NumberCars tinyint,
AddressLine1 nvarchar (50),
City nvarchar (30),
State nchar (3),
PostalCode nvarchar (10),
Phone nvarchar (20),
Territory int
)
ELSE TRUNCATE TABLE AdventureWorks.dbo.Territory1
La figure 5.15 montre une collection d’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.15 — L’éditeur de boucle Foreach
À chaque boucle, le nom de fichier est transmis à la variable utilisateur vFile-

Name.
Le gestionnaire de connexion CreateTableSQL transmet le nom de fichier à la
tâche « Create Tables ».
À 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.16 —
Variable utilisateur
dans l’éditeur
de boucle
Figure 5.17 — Propriété de la connexion CreateTableSQL

Figure 5.18 — L’éditeur de tâche d’exécution d’une commande SQL
Conteneur de 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 conte-
neur de boucles For évalue une expression et répète son flux de travail jusqu’à
ce que l’expression renvoie la valeur False.
Figure 5.19 — boucle For
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 fonction-
nalité est particulièrement intéressante en phase de débogage. Il est possible éga-
lement 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 peu-
vent créer, modifier ou supprimer des cubes multidimensionnels et des dimen-
sions. La tâche DDL utilise un gestionnaire de connexion Analysis Services.
Tâche de flux de données

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 des tâches 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 don-

nées. Le moteur de flux de données exécute le plan.
Source
Transformation
Transformation
Destination
Figure 5.20 – La tâche de flux de données alimente une destination (table SQL Server,
fichier plat, etc.) à partir des données sourcesTâche de requête d’exploration de données
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
Cette tâche permet au programmeur de réaliser des fonctions non disponibles
dans les tâches intégrées de SSIS.
Figure 5.21 — La tâche de script ActiveX envoie un message

en cas d’erreur (incohérence entre les deux tables)
Le code ci-dessous permet de vérifier la cohérence des données entre une

table de faits (FactFinance) et une table de dimension (DimActivity) sur un ser-
veur SQL 2000 (Provider=SQLOLEDB.1).
Const DB_CONNECT_STRING = "Provider=SQLOLEDB.1;Data

Source=Monserveur\sql2000; Initial Catalog=Pubs;user
id = ‘sa’;password=‘sa’"
Dim OK_or_KO
‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘
‘Name : Function ExecuteSQL

‘Auteur B. Burquier
‘Objectif : Executes a SQL statement
‘Retour ADO Recordset
Function Main()
Call Process_Control()
If OK_or_KO = "OK" then
Main = DTSTaskExecResult_Success
Else ‘erreur
Main = DTSTaskExecResult_FAilure
End if
End Function
Sub Process_Control()
Dim rstResult
‘Requete de non correspondance
StrQuery = "SELECT FactFinance.CompanyId, FactFinance.AccountId,
FactFinance.ActivityId, FactFinance.CurrencyId, FactFinance.Projec-
tId, FactFinance.TimeId, FactFinance.AppealId, FactFinance.Scena-
rioId, FactFinance.DataCHF, FactFinance.DataLocalCurr,
FactFinance.LineDescription FROM FactFinance LEFT JOIN DimActivity ON
FactFinance.ActivityId = DimActivity.ActivityId WHERE DimActi-
vity.ActivityId Is Null"
‘Get the ADO Recordset
Set rstResult = ExecuteSQL(strQuery)
‘If the Recordset is not empty then proceed
If Not (rstResult.Eof and rstResult.Bof) Then ‘non vide
Msgbox "Non vide = failure"
OK_or_KO = "KO"
Else ‘vide
MsgBox "vide = Success"
OK_or_KO = "OK"
End If
‘Clean up variables
Set rstResult = Nothing
End Sub
‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘
‘Name : Function ExecuteSQL
‘Author : B Burquier
‘Purpose : Executes a SQL statement
‘Return ADO Recordset
‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘
Function ExecuteSQL(mySQLCmdText)
‘ instantiate the ADO objects
Dim myConn
Dim myRecordset
set myConn = CreateObject("ADODB.Connection")
set myRecordset = CreateObject("ADODB.Recordset")
‘ set the connection properties to point to the database using
the constant
myConn.Open = DB_CONNECT_STRING
myRecordset.Open mySQLCmdText, myConn
Set ExecuteSQL = myRecordset
End Function
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).
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. 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 (figure 5.22).
Tâche de transfert de messages d’erreur

Elle 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.
Figure 5.22 — Formulaire de sélection des connexions

à transférer entre deux instances de SQL Server
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 2000 et 2005.
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 2005 (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 pac-
kages exécutés par un flux de travail parent sont appelés « packages enfants ».
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 2005.
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 VisualBasic ou une macro Access chargée de générer
quotidiennement un rapport sur les ventes.
Figure 5.23 —
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 : code SQL de création de clé primaire.
IF NOT EXISTS (SELECT * FROM AdventureWorks.sys.tables WHERE
type = ‘U’and name = ‘Lineage_Fact_Table’)
CREATE TABLE dbo.Lineage_Fact_Table
(
[Column 0] NVARCHAR(50),
[File Name] NVARCHAR(260),
[User Name] NVARCHAR(70),
[Execution Start Time] DATETIME
)
ELSE
TRUNCATE TABLE AdventureWorks.dbo.Lineage_Fact_Table
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 exis-
tante. 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.24 — Formulaire permettant de configurer

les propriétés pour l’envoi d’un message électronique
Figure 5.25 — 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éne-
ment 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 exem-
ple, elle peut récupérer quotidiennement tous les fichiers des ventes des succur-
sales 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 com-
posants 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 WMI. Il est possible d’interroger les journaux des événements Win-
dows 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 messa-
ges à 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 por-
tables 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 Instrumen-
tation 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 trans-
fert 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.
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

La tâche de nettoyage d’historique supprime des entrées dans les tables d’histo-
rique 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.
Figure 5.26 — Formulaire de tâche de nettoyage d’historique
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 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.
Figure 5.27 — Formulaire permettant

de définir la tâche de mise à jour des statistiques
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.28 — Flux des processus dans SQLiMail

5.5 Composants des flux de données ———————————————————————————————————————————————————————— 129
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 possible d’automatiser des sauvegardes totales ou diffé-
rentielles. 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 :
BACKUP DATABASE [AdventureWorksDW] TO DISK = N’C :\Program
Files\Microsoft SQL Server\MSSQL.1\MSSQL\Bac-
kup\AdventureWorksDW_backup_200609201344.bak’WITH NOFORMAT, NOINIT,
NAME = N’AdventureWorksDW_backup_20060920134425’, SKIP, REWIND,
NOUNLOAD, STATS = 10
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 don-
nées et de contrôler les index des bases.
5.5 COMPOSANTS DES FLUX DE DONNÉES
SSIS offre trois types de composants de flux de données. Les sources, les trans-
formations 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élec-
tion de sortie normale.
La sortie d’erreur d’une source contient les mêmes colonnes que la sortie nor-
male plus deux colonnes supplémentaires : ErrorCode indique le code erreur et
ErrorColumn indique la colonne contenant l’erreur. Les colonnes de sortie devien-
nent à leur tour les colonnes d’entrée du composant de transformation.
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 direc-
tement 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.
Figure 5.29 — Un flux de données est composé

d’une source, d’une transformation et d’une destination
Sources des flux de données

Source DataReader
La source DataReader accède à des données d’un fournisseur.NET à l’aide du
gestionnaire de connexion ADO.NET. 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 automatiquement, voir figure 5.30.
Figure 5.30 —
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
Figure 5.31 — Formulaire

permettant d’établir
une connexion
avec un fichier plat
Un fichier plat peut être de format texte, avec des champs délimités par des carac-
tères spéciaux, de largeur fixe, ou les deux.
Dans le formulaire de la figure 5.31, 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.31, on observe une source de données au for-
mat anglais (États-unis).
L’affichage des colonnes après définition des types de colonne est montré
figure 5.32.
Figure 5.32 — Affichage des colonnes du fichier plat
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
à 2005.
Source OLE DB
La source OLE DB pointe sur des tables relationnelles. La figure 5.33 présente
les différents fournisseurs OLE DB fournis par le gestionnaire de connexion.
Figure 5.33 Liste des fournisseurs OLE DB

pour les sources et destinations de données
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écu-
tion. 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 com-
mencé, 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 Nom-
Complet 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.
Figure 5.34 — Sélectionner un des trois types de composant de script
La figure 5.35 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 exis-
tantes. 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.35 — Visual Studio for Application s’ouvre pour créer le script
Dimension à variation lente

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. Vouloir analyser le chiffre
d’affaires réalisé dans tel pays ou tel autre peut avoir un sens. Si c’est le cas, on
parlera de variation de dimension de type 2. A contrario, la distinction relative
au changement d’adresse peut ne pas être pertinente. Dans ce cas, la nouvelle
adresse du client remplacera purement et simplement l’ancienne et nous per-
drons toute capacité à suivre l’évolution du client dans le temps. Il s’agit de varia-
tion dimensionnelle de type 1.
Chacun de ces types de transformation de dimension à variation lente néces-
site de prendre en charge quatre types de modifications :
• modification d’attribut;
• modification d’attribut d’historique;
• modification d’attribut fixe;
• modification de membre inféré.
Les modifications modification d’attribut remplacent les enregistrements exis-

tants. 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 auto-
risée dans un enregistrement existant est une mise à jour d’une colonne qui indi-
que si l’enregistrement est actif ou expiré. 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.
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.
Membre inféré indique que la ligne est un enregistrement de membre déduit
dans la table de dimension. Un enregistrement de membre inféré est un membre
de dimension inconnu. Un enregistrement de membre inféré minimal est créé
en prévision des données de dimension pertinentes, qui sont fournies dans un
chargement ultérieur des données de dimension. La transformation de dimension
à variation lente dirige ces lignes vers une sortie nommée Sortie de mises à jour
de membre déduit.
Comment fonctionne l’assistant de création de dimension à variation lente
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.
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 map-
pages non-clés.
Sélectionnez le type de modification pour chaque colonne :
• Modification d’attribut remplace les valeurs existantes dans les enregis-

trements.
Figure 5.36 — La Clé d’entreprise présente la clé invariante

de la table dimensionnelle
• 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.37 — 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’indica-
teurs 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 et True pour les lignes actives et Expired et False
pour les lignes expirées. Vous pouvez également entrer des valeurs personnali-
sé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.38 — L’assistant permet de paramétrer les options d’attribut d’historique
Dans l’exemple ci-dessus les enregistrements expirés continent 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 pouvez 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 enregis-
trements 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 modi-
fication sont nulles;
• un enregistrement dans lequel une colonne booléenne indique que l’enre-
gistrement est un membre inféré.
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.
Figure 5.39 — Un enregistrement de membre inféré

est un membre de dimension inconnu
La figure 5.40 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.40 — 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 la 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_Per-
son_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éa-
tion 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_Ori-
ginal_ID de la date de début Sales_Person_SCD_Start_Date et enfin du
nom du représentant Sales_Person_Name.
Échantillonnage de ligne
Il permet de sélectionner un sous-ensemble des données sources de manière aléa-
toire. 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éa-
toire. 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 établis-
sent 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.
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 recher-
che floue permet également de fournir des données manquantes. Cette transfor-
mation 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 dis-
tance 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 exem-
ple 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
normalisé.
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.41 — Exemple de flux dénormalisé
Voici le data set après transformation.
Client ID Type de tel N° 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
Figure 5.42 — Flux normalisé
Tableau croisé dynamique (transformation Pivot)

Une fonction Pivot (à l’inverse de Unpivot) transforme un flux de données nor-
malisé en un flux dénormalisé (exemple inverse du précédent).
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 des-
cendant.
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.
Destinations du flux de données
Figure 5.43 — 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 disponi-
bles pour le stockage des données (figure 5.43) :
• 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 don-
né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
Règles d’ETL
et assistants
Nous l’avons vu dans le chapitre précédent, la grande force de business intelli-

gence 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 fonc-
tions 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 trou-
ver 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 2005 et son outil de développement intégré busi-
ness 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’envi-
ronnement SQL Server 2005 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.
146 ———————————————————————————————————————————————————————————————— 6. Règles d’ETL et assistants
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 :
Démarrer le programme : Programmes/SQL server 2005/SQL Server business
intelligence Developpement Studio.
Appeler le menu.
Fichier/Nouveau/Projet/Projet Integration Services.
Figure 6.1 — Nommer le projet
SSIS détermine un emplacement par défaut pour le projet. Cet emplacement

est naturellement modifiable.
La validation du projet entraine la création du projet.
6.1 Utiliser l’assistant pour générer un lot import ————————————————————————————————————————————— 147
Figure 6.2 — Assistant Projet d’Importation/Exportation SQL Server
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
Figure 6.3 — La table source Produits stockée dans Microsoft Access

dimensionnelles seront stockées dans l’entrepôt de données grâce à notre pro-

cé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).
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.

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 plu-
sieurs tables ou vues plutôt que d’écrire une requête.
Figure 6.6 — Fichier Customers stocké dans une feuille Excel
Parmi la liste des sources disponibles dans Access, sélectionnons la table Pro-
duits (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

destination. 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.
CREATE TABLE [AdventureWorksDW].[dbo].[Produits] (
[Réf produit] int NOT NULL,
[Nom du produit] nvarchar(40) NOT NULL,
[N° fournisseur] int,
[Code catégorie] int,
[Quantité par unité] nvarchar(30),
[Prix unitaire] money,
[Unités en stock] smallint,
[Unités commandées] smallint,
[Niveau de réapprovisionnement] smallint,
[Indisponible] bit NOT NULL
)
À ce stade, il est possible d’afficher le contenu de la table source grâce au bou-

ton 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 2005\Pro-
jects\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.
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 :
drop table [AdventureWorksDW].[dbo].[Produits]

GO
Figure 6.10 — Un package est automatiquement créé
– tâche de création de table Produits (nommée Tâche SQL de prépara-

tion dans la figure 6.10) :
CREATE TABLE [AdventureWorksDW].[dbo].[Produits] (
[Réf produit] int NOT NULL,
[Nom du produit] nvarchar(40) NOT NULL,
[N° fournisseur] int,
[Code catégorie] int,
[Quantité par unité] nvarchar(30),
[Prix unitaire] money,
[Unités en stock] smallint,
[Unités commandées] smallint,
[Niveau de réapprovisionnement] smallint,
[Indisponible] bit NOT NULL
)
GO
– 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).
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.
Figure 6.11 — L’onglet Flux

de données est composé
d’une source de données
et d’une destination
Figure 6.12 — L’éditeur de source OLE présente les colonnes sources

Figure 6.13 — Éditeur de destination OLE DB
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.
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 des-
tination 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 cou-
leurs différentes que prend successivement chaque tâche. La couleur jaune indi-
que 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 connaitre le déroulement du lot, le temps
passé pour chacune des tâches et le résultat de leur exécution.
Figure 6.14 — 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 sup-
pression 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).
Figure 6.15 — Management studio permet de générer des scripts SQL
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
[Gender] [nvarchar](255) COLLATE SQL_Latin1_General_CP1_CI_AS
NULL,
[EmailAddress] [nvarchar](255) COLLATE
[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
[AddressLine2] [nvarchar](255) COLLATE
[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.
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.16 — Ajouter la connexion

puis le code qui permet de supprimer la table Clients
Figure 6.17 — 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.18.
Figure 6.18 — 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.19 — 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
Figure 6.20 —
Le gestionnaire
de connexion Excel
permet d’établir
un lien avec le fichier
Customers.xls
Dans le gestionnaire de connexion OLE DB, choisir Gestionnaire de con-

nexions 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 destina-
tion 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 map-
page 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.21.
Figure 6.21 — 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 Pro-
duits à 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’enregistre-
ments 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.22).
Figure 6.22 — Éditeur

du gestionnaire de connexion FTP
Configurez les propriétés pour le message électronique (figure 6.23).
Figure 6.23 — Éditeur de tâche d’envoi de mail
L’éditeur de tâche d’envoi de message électronique permet de préciser le ser-

veur 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.24 — 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.25 — 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 2005

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 doi-
vent ê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 2005. 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 Stu-
dio. 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/
Figure 6.26 — Assistant migration de package

Préciser le nom du Serveur SQL 2000 renfermant le lot DTS.
Figure 6.27 — Selectionner le serveur qui renferme le lot DTS
Choisir la destination.
Figure 6.28 — Sélectionner le serveur qui renferme la base de destination

Figure 6.29 — Choisir le lots DTS 2000 à migrer vers 2005
Figure 6.30 — L’assistant demande de préciser un fichier journal

dans lequel il va stocker le déroulement des étapes de migration
Cliquez sur Terminer pour mettre fin aux opérations suivantes :

• Migrer le package vers SQL Server Integration Services.
Figure 6.31 — Formulaire de synthèse des actions menées par l’assistant
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\Administra-
teur\DTSlogBB.log.
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 2005.
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 bou-
ton droit sur le nom du projet, puis cliquez sur Propriétés.
Passer à True la variable CreateDeploymentUtility.
Puis OK.
Figure 6.32 — L’attribut CreateDeployementUtility doit être à True
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 confi-

gurations 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 Inte-
gration services.
L’Assistant Installation de package vous accompagne dans le processus d’ins-
tallation des packages sur le système de fichiers et sur SQL Server.
Clic droit sur <nom de projet>.SSISDeploymentManifest. puis deploy.
Figure 6.33 — Ouvrir

l’assistant de déploiement
de package
Figure 6.34 — L’assistant

permet de déployer
des packages SSIS
soit sous forme de systèmes
de fichiers XML
ou dans SQL Server
Figure 6.35 L’assistant permet

de sélectionner un dossier d’installation
Conserver le dossier par défaut puis Suivant deux fois.

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 ser-
ver 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.36 — 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 pac-
kage 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’empla-
cement 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 envi-
ronnement de production (Clic droit puis exécuter le package).
Ci-dessus nous avons programmé une exécution du package leçon 1.dtsx tou-
tes les nuits du lundi au vendredi à 0 h 00.
Le moniteur d’activité des travaux de SQL server Agent permet de suivre
l’exécution des travaux et leur traçabilité.
Vous pouvez également consulter la visionneuse du fichier journal.
6.2 Concept de packages dynamiques —————————————————————————————————————————————————————— 171
Figure 6.37 — Interface du planificateur de tâches intégré à SQL Agent
6.2 CONCEPT DE PACKAGES DYNAMIQUES
Il existe un grand nombre d’outils visant à modifier les tâches qu’un package
(lot) peut exécuter. Pour ce faire, SSIS dispose d’un jeu de variables et d’expres-
sions 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 condi-
tionnel 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 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ésultat 234
ROUND(12.3456) fournit le résultat 12.35
On retrouve également des fonctions sur les chaînes de caractères : TRIM(),
UPPER(), SUBSTRING(), etc.
Des fonctions portant sur les dates existent également : DATEDIFF(), DATEPART(),
GETDATE(), MONTH (), YEAR(), etc.
6.2.2 Les variables
Figure 6.38 — 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 par-
ties 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.39 — Tableau des variables utilisateur. Les noms de variables

sont sensibles à la casse (majuscules et minuscules doivent être respectées)
Figure 6.40 — Tâche de requête SQL

Figure 6.41 — Mappage des paramètres

entre les variables système et les paramètres
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 pos-
sible é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.
La tâche d’exécution SQL de la figure 6.40 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.41 les variables système et utilisateurs sont transférées
aux paramètres. A leur tour, ces paramètres (dont le nom commençe par le signe @)
sont transmis dans la requête SQL (voir requête ci-dessous).
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 trai-
tements 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, @PkgVersion-
Minor, @ExecStartDT, @ParentPkgExecKey)
6.2.3 Les configurations

La technique des configurations répond à un besoin d’adaptation à divers envi-
ronnements d’exploitation. Les valeurs prises par défaut peuvent être modifiées
dynamiquement 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 Server, un fichier XML, une variable d’un package parent, une variable
d’environnement de Windows ou une entrée du registre.
Le lancement du gestionnaire de configuration s’effectue à partir du menu
disponible; choisir Gestionnaire de configurations comme indiqué dans la
figure 6.37.
Figure 6.42 — SSIS permet de créer un fichier

de paramètres grâce au gestionnaire de configurations
L’exécution d’un package SSIS s’effectue généralement grâce aux commandes

DTExecUI ou DTExec. Dans la ligne de commande, il est possible de fournir le nom
du fichier de configuration à exécuter.
Figure 6.43 — Fichier de configuration au format XML
Dans le fichier XML de la figure 6.43 le nom du répertoire a été passé en para-
mètres entre les balises ConfiguredValue.
6.2.4 La gestion des événements

Le gestionnaire d’événement permet entre autres de contrôler l’état de fonction-
nement 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
6.3.1 La carte de haut niveau

La connaissance des outils de base, exposés dans les précédents paragraphes, per-
met 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 char-
gement.
• 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 ———————————————————————————————————————————————————————— 177
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?arti-
cleID=54200319.
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 natu-
rellement incluse dans SQL Server 2005 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, 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 uti-
lisateurs.
Le composant central de l’infrastructure OLAP est le cube multidimension-
nel. 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 Inte-
gration services et Reporting Services. Par exemple, une entreprise utilisera Ana-
lysis 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 com-
patibles 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).
180 ——————————————————————————————————————————————————————————————————————— 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

Comparée à la version 2000, Analysis Services 2005 offre aux développeurs en
entreprise et intégrateurs plus de 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, inter-
roger 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
7.1 OLAP et le data mining ———————————————————————————————————————————————————————————————— 181
à la question : « Quels 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 sim-
plement 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 fins de prédiction dans le cadre de processus d’affaires telles que
prévisions des ventes, segmentation de populations d’individus aux comporte-
ments 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é illus-
tré 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 gra-
phiques.
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 per-
mettent 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 tempo-
relle 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 automa-
tiquement. 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
2005). 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.
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, dimen-
sion Temps. La mesure analysée au croisement des trois axes est l’indicateur de
volume en valeur.
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)
Dans cet exemple, l’outil de restitution du cube est le tableau croisé dyna-
mique 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 quel-
ques secondes au manager opérationnel ou au contrôleur de gestion doté de son
outil favori : Excel.
7.2 Points d’amélioration entre Analysis 2000 et SSAS 2005 ——————————————————————————————————— 183
7.2 POINTS D’AMÉLIORATION ENTRE ANALYSIS 2000

ET SSAS 2005
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) combine en un seul référentiel les carac-
téristiques des modèles multidimensionnels (DW) et relationnels (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 clés de performance) 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 resti-
tution des données.
Les translations 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.
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) ont été améliorées puisqu’il
est désormais possible d’écrire dans des cellules agrégées (et non pas uniquement
au niveau de granularité le plus bas).
De nouveaux outils et assistants 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 nouveau langage de définition des données (DDL dans SSAS 2000) est
maintenant au format XML. XML/A (XML for Analysis) est le nouveau pro-
tocole 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 sup-
primant ainsi le cache client et l’amélioration des calculs complexes.
Le nouvel environnement de développement d’applications est maintenant
unifié dans business intelligence Development Studio. Le nouvel environnement
d’administration est SQL Server Management Studio (Enterprise Manager dans
la version SQL Server 2000).
Un nouveau modèle d’autorisations d’accès a été redéfini. Les nouveaux rôles
sont :
• administrateur de serveur;
• droits sur les objets de processus et de structure.
Le modèle de sécurisation des objets SSAS a été redéfini :
• sécurisation par objets de la base de données;

• cryptage des cubes;
• SSAS s’exécute avec le niveau le plus bas 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 maintenant 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 resti-
tution 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.
SQL Server Management Studio administre aussi bien les bases de données
SQL Server que les bases Analysis.
Figure 7.3 — Interface présentant SSMS (SQL Server Management Studio)
Dans la figure 7.3, le volet de gauche fait apparaître les composants de SQL.
On observe également le serveur Analysis Services avec ses composants UDM.
La nouvelle console d’administration remplace en les regroupant Enterprise
Manager et Analysis Manager de SQL Server 2000.
Les requêtes SQL et MDX sont analysées dans le même outil.
Le nouveau modèle objet AMO (Analysis Management Objects) remplace DSO.
Pour des raisons de compatibilité, DSO est supporté.
Les dimensions et leurs attributs

SSAS 2005 définit les dimensions des cubes grâce aux attributs des champs des
tables dimensionnelles et également sur les hiérarchies comme cela était le cas
dans AS 2000. En effet, dans AS 2000, une dimension était définie grâce à des
structures hiérarchiques fortes comme année/mois/jour ou pays/région/ville. Il
était possible de définir des dimensions virtuelles à partir des propriétés des mem-
bres. Cependant, les performances sur ce type de dimensions n’étaient pas au
rendez-vous. Les développeurs ne déployaient que rarement ces dimensions et
toujours sur des volumétries réduites.
SSAS 2005 définit une dimension à partir de nombreux attributs, chacun
d’entre eux servant à effectuer du slice (tranche de cube) et du filtrage des don-
nées. Chaque attribut peut participer à la définition de hiérarchies selon les rela-
tions entre les données.
Les notions de hiérarchie naturelle continuent d’exister et devront être défi-
nies avec soin. Les performances qui résultent de ces hiérarchies sont améliorées.
Dans l’exemple suivant considérons la dimension Client. La table qui ren-
ferme 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’aucune 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 « repro-
cesser » la dimension. Le cube reste donc disponible aux utilisateurs pen-
dant la réindexation de la dimension.
• Les dimensions dupliquées sont éliminées. Les dimensions sont plus com-
pactes.
• 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 2000 comporte deux types de dimensions : hiérarchique régulière
et parent-enfant.
Analysis Services 2005 offre de nouvelles structures de dimensions :
• 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 2005, la dimension est
stockée une seule fois mais aura une signification différente en fonction du
contexte.
• Dimension de fait. En réalité ce type de dimension est peu utilisé par Ana-
lysis puisqu’elle identifie un objet au niveau le plus fin. Elle prend toute
son importance lors de l’identification des lignes détail qui participent au
contenu d’une cellule agrégée.
• 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.
• 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’asso-
ciation, 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. 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.
Groupes de mesures et Perspectives

SSAS 2005 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. Avec
SSAS 2000, un cube était fondé sur une et une seule table de faits. Plusieurs
cubes étaient nécessaires lorsque des analyses portaient sur plusieurs tables de
faits. Le moyen pour rapprocher deux cubes était de constituer un cube virtuel.
Ce dernier était en quelque sorte une vue synthétique basée sur une jointure de
plusieurs cubes.
Dans SSAS 2005, 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.
Du fait de la complexité croissante de la navigation dans le cube liée au nom-
bre 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. Des niveaux d’accès sécurisés peuvent être
attribués à chaque perspective.
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’obser-
vation (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 dimen-
sions 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’inventaire 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
total du stock.
L’assistant de calcul des dimensions temporelles apporte une aide non négligea-
ble dans le cas de calcul d’agrégation à comparer sur des périodes de temps dif-
férentes (calcul du cumul des ventes depuis le début de l’année comparé sur les
trois dernières années). Cette fonction est native alors qu’auparavant il était
nécessaire de développer une fonction MDX de type ytd().
MDX Scripts
Le langage multidimensionnel MDX (Multidimensional Expressions) est un lan-
gage d’interrogation des cubes, aussi complexe que puissant. SSAS 2005 propose
un nouveau 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 utili-
sent une technique intuitive de glisser-déposer. Derrière cette apparente simpli-
cité, 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 2005 introduit la notion 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 simpli-
fient 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

Une innovation de taille dans SSAS 2005 réside dans la mise à disposition de
la technologie des KPI. Il s’agit de suivre des indicateurs métier pour lesquels des
objectifs ont été fournis préalablement. Typiquement, ces indicateurs se retrou-
vent dans des rapports, des portails décisionnels et des tableaux de bord. L’outil
de restitution est le portail Business Scorecard Management non inclus dans
SQL Server 2005. Des outils tiers qui exploitent cette technologie sont déjà dis-
ponibles sur le marché (Panorama software, Proclarity, etc.). Les KPI sont dès à
présent pris en charge par les tableaux croisés dynamiques de Excel 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.
Voici une illustration de trois KPI affichés dans une page web (figure 7.4):
• 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).
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.4 — Tableau de bord rassemblant trois KPI
Business intelligence en temps réel

Les entrepôts de donnée et les applications de business intelligence reposent tra-
ditionnellement sur des données historiques rafraîchies mensuellement, ou quo-
tidiennement. 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 seu-
lement 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 publi-
citaires diffusées dans le magasin. Dans ce cas, le temps d’attente entre la réali-
sation d’un fait et sa mesure est quasi instantané.
Alors que AS 2000 offrait un mode de rafraîchissement des cubes basé sur le
modèle pull (DTS déclenche une tâche à heure fixe), SSAS 2005 fournit un
nouveau 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édiatement 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 don-
né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 secon-
des. Cette période d’attente protège le système de reconstructions fréquen-
tes 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 data-
mart. 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 multidimen-
sionnel (OLAP) via UDM.
Système
Opérationnel Cube
UDM Analysis
OLTP
(Oracle, Services
Db2, SQL Server) OLAP
Figure 7.5 — 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.
• 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.6 — 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 don-
né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 don-
né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 tran-
sactionnelle (OLTP) sans mettre en œuvre dès le départ un entrepôt de données.
7.3 Méthodologie de création d’une base de données depuis une source existante ———————————————— 193
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 seule-
ment 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’utili-
sateur. Parfois, on sera amené à créer des champs calculés dérivés des champs
existants.
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 seu-

lement 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’administra-
tion 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éve-
loppement).
Cette phase de normalisation sera payante tout au long du processus de déve-

loppement 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 la
tables de dimensions. L’assistant tente de créer des structures hiérarchiques parmi

les attributs des dimensions. En général, il est conseillé de laisser l’assistant réa-
liser ce travail préliminaire quitte à revenir ultérieurement sur des choix qui ne
seraient pas conformes à la définition du cahier des charges.
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évelop-
pement 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 par-
ticulier 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 suf-
fisamment significatives afin de détecter rapidement toute anomalie éventuelle.
L’étape suivante consiste à créer des composants BI tels que les KPI (Key Per-
formance Indicators), les actions, les calculs dérivés. Selon que les utilisateurs cou-
vrent 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. Ces profils disposent également de droits
de consultation différents sur les données du cube. Si vous déployez des cubes
pour une consultation internationale ou multilingue, vous serez amenés à
déployer les fonctions de « traduction » (Translations). 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 2005 Database Engine.
• Microsoft SQL Server 2005 Analysis Services.
7.4 Création de notre premier cube ————————————————————————————————————————————————————————— 195
• 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 2005.
Le scénario suivant s’inspire d’une société fictive Cycles et Aventure qui fabri-
que 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 pro-
blèmes suivants :
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 données dans le tableur Excel. Ils peuvent ensuite élaborer
des graphes. Les données de synthèse saisies manuellement dans Excel ne per-
mettent 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 consti-
tuent les données de synthèse.
Les utilisateurs n’ayant pas connaissance des technologies OLAP se conten-
tent 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 rap-
ports 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 per-
formances 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 objec-
tifs 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 don-
né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éa-
lisé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 Ventes-
Internet. 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éter-
miner assez facilement les tables dimensionnelles devant intervenir dans l’éla-
boration 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.1 Mesures
Dans l’exemple présenté ci-après, les mesures sont définies par la table Ventes-
Internet 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.2 Dimensions
Notre manager veut effectuer des analyses selon divers axes d’observation.
L’axe clients se décompose de la façon suivante :
• région;
• province;
• ville;
• nom;
• l’axe produits;
• catégorie de produit;
• sous-catégorie;
• ligne produit;
• produit;
• l’axe du temps;
• année;
• trimestre;
• mois;
• jour.
7.4.3 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 FaitVentes-
Internet. La dimension Client est composée de deux tables liées (DimClients et
DimGeographie). De ce fait nous parlerons d’un schéma en flocons.
Figure 7.7 — 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.4 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 2005 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.8 — Formulaire de création d’un projet SSAS

Dans le champ Nom, nommer le projet : Projet Mon Premier Cube.

Dans le champ Emplacement, définir un chemin d’accès aux projets ou conserver
celui proposé par VS. Dans le champ Solution, saisir Solution Mon Premier Cube.
Figure 7.9 — 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 OLE DB natif\SQL Native Client.
Figure 7.10 — Choix des types de connexion
Choisir le fournisseur d’accès à la base Entrepot.

Figure 7.11 —
Le gestionnaire
de connexion
Le bouton Tester la connexion permet de vérifier la connexion au serveur.
Figure 7.12 —
Le Gestionnaire
de connexion vérifie
le lien avec la base
de données source
Puis OK deux fois.

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.14 — Information sur l’identité

de l’utilisateur accédant à la source de données
Figure 7.15 — 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 : Base_Entrepot.ds.
Figure 7.16 — La source

de données dans l’explorateur
de solutions
L’étape suivante consiste à créer une nouvelle vue de source de données.

Clic droit sur Vues de sources de données.
Figure 7.17 — 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.18 — 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 Base Entrepot.
Bouton Suivant.
Dans le formulaire suivant vous allez sélectionner les tables de Base entrepot
qui sont à inclure dans la vue de source de données.
Grâce au bouton > sélectionnez la table de faits FaitVentesInternet.

Cliquez sur le bouton Suivant.
Puis validez la fin de la création de source de données en cliquant sur le bou-

ton Terminer.
Dans l’explorateur de solution vous observez la création de la vue Base Entre-

pot.dsv.
Vous obtenez le schéma suivant (figure 7.19).
Figure 7.19 — Source de données selon un schéma en flocon
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.
Dans l’explorateur de solutions, effectuez un clic droit sur Cubes puis validez
Nouveau Cube…
L’assistant de création de cube est sollicité.
Puis cliquez sur le bouton Suivant.

Figure 7.20 — Création d’un cube

à l’aide de l’assistant UDM
Sélectionnez la Vue de source de données Base Entrepot puis cliquez sur le

bouton Suivant.
L’assistant tente de détecter automatiquement les tables de faits et de dimension.
Vous vérifiez que la table de faits est bien FaitsVentesInternet. Toutes les
autres tables sont des tables de dimension.
Précisez à l’assistant quelle est la table de dimension temporelle. Pour cela,
sélectionnez la table de dimension temps DimTemps.
Dans l’écran présenté dans la figure 7.21, vous devez préciser la table qui joue
le rôle de dimension de temps.
Figure 7.21 — L’assistant détecte les tables de dimension et tables de faits

Figure 7.22 —
Identifier les tables
de faits et de dimension
Figure 7.23 — Créer une hiérarchie dans la dimension temporelle

Sur la figure 7.22, le diagramme fait apparaître le schéma en étoile ou flocon en

distinguant les tables de dimension et les tables de faits (au centre du diagramme).
Sur la figure 7.23, l’assistant définit une hiérarchie pour la dimension Temps.
À la différence de AS 2000 qui déduit automatiquement la hiérarchie temporelle
à partir d’une date, SSAS 2005 doit recevoir un « mappage » manuel entre les
propriétés de la hiérarchie et les champs sélectionnés dans la table de dimen-
sions. On remarquera que les valeurs année, trimestre, mois, etc. doivent exister
dans la table dimensionnelle.
Lorsque la table dimensionnelle n’existe pas dans le modèle (cas fréquent) il
est nécessaire d’en générer une grâce à l’assistant de création de dimension tem-
porelle sans source de données.
Figure 7.24 — Lorsque

la table temps n’existe
pas, il est impératif de la
créer grâce à l’assistant
dimension temps.
Cette tâche a pour but
de créer une nouvelle
table dans l’entrepôt
de données
Figure 7.25 — Fournir les bornes pour la construction de la table temporelle

Il est nécessaire de fournir les bornes pour la construction de la table.

L’assistant détermine les mesures en fonction des champs numériques détec-
tés dans la base de faits. Conservez uniquement les mesures qui ont un sens à
être agrégées (mesures additives) comme ci-dessous.
Figure 7.26 — Sélectionnez les mesures ou indicateurs pertinents
Par défaut, l’assistant repère les champs au format numérique et tente d’en
créer des mesures. Décochez les clés qui ne constituent pas des mesures dans la
base de faits.
L’assistant détecte automatiquement les hiérarchies.
Déployez les nouvelles dimensions détectées afin de contrôler les choix effec-
tués par l’assistant.
Vérifiez la pertinence des hiérarchies et des attributs.
Figure 7.27 — Décochez les attributs de dimensions

qui ne définissent pas des axes d’analyse (le champ Photo n’est pas un axe d’analyse)

de création de cube
affiche la structure
des nouvelles dimensions
Figure 7.29 — L’assistant affiche les groupes de mesures

et les dimensions qu’il vient d’attribuer au cube MonPremierCube
Puis cliquez sur le bouton Terminer.
Figure 7.30 — Le concepteur de cube présente l’explorateur

de solutions, les groupes de mesures, les dimensions incluses
dans le cube et la vue de source de données
Dans la vue de la source de données, vous observez la table de faits au centre

du schéma en flocon (figure 7.30).
Le concepteur de cube contient les onglets suivants, qui affichent différentes
vues du cube.
Structure de cube
Cet onglet permet de modifier l’architecture d’un cube et d’en modifier les com-
posants.
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 nou-
veaux 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 rapi-
dement les informations utiles relatives à une valeur et par exemple, de déter-
miner 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 empla-
cements 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 com-
plexité 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.31).
Figure 7.31 — 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 Enre-
gister 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 apparais-
sent 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éve-

loppez Dim Clients, puis cliquez sur le
lien Modifier Dim Clients.
Le concepteur de dimension appa-
raît. Vous observez trois onglets :
Structure de dimension, Traductions
et Navigateur.
L’onglet Concepteur de dimension Figure 7.32 —
Groupe
contient à son tour trois onglets :
de mesures
Attributs, Hiérarchies et niveaux et et dimensions
vue source de données. du cube
Les choix effectués par l’assistant
ne nous conviennent pas. Par consé-
quent, vous allez procéder à la modifi-
cation de la hiérarchie de la dimension.
Commencez par renommer la hié-
rarchie en Clients.
Figure 7.33 — L’onglet structure de dimension se décompose en Attributs,

Hiérarchies et vue source de données propre à la dimension
Clic droit sur l’en-tête de la hiérarchie, puis

Renommer, puis saisissez Clients.
Vous allez reconstruire les niveaux hiérarchi-
ques 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 recons-
tituez 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 Figure 7.34 — Supprimer
Province puis Ville et enfin Nom. ou renommer un niveau
dans la hiérarchie
Vous obtenez ainsi la nouvelle hiérarchie
Clients.
Figure 7.35 — 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 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.36 — Pour créer une hiérarchie,

faites glisser une colonne ou un attribut sur la partie centrale
Vous allez créer de toute pièce 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 Dim-
Produit 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.37 — 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édiatement en dessous, NomProduitFrançais.
Revenez sur l’onglet DimProduit puis glissez le champ LigneProduit de la
Vue source de données vers Hiérarchie et Niveaux.
Figure 7.38 —
Glisser déplacer
un champ de la vue
source de données
dans la hiérarchie
Une nouvelle hiérarchie vient d’être créée avec un

seul élément LigneProduit.
Vous obtenez une nouvelle hiérarchie.
Hiérarchie temporelle
Dans l’explorateur de solutions, cliquez sur la dimen- Figure 7.39 — Hiérarchie
sion Dim Temps. Dans l’onglet Hiérarchie et niveaux, après introduction
renommez la hiérarchie en Dates. d’un nouveau champ
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 de
Analysis Services. Le traitement des objets dans une
Figure 7.40 — Renommer instance de Analysis Services, entraîne la copie des
une hiérarchie données à partir des sources de données sous-jacentes
dans les objets du cube.
Déployez le cube
Faites un clic droit sur MonPremierCube puis sélectionnez Déployer.
Figure 7.41 — 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.42 — Récapitulatif du déploiement du cube sur le serveur
Dans le répertoire Cubes de l’explorateur de solutions, double-cliquez sur

MonPremierCube.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.
Tout d’abord, glissez-déplacez la mesure Quantité commandée dans la partie
centrale du rapport.
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.43 — Onglet de navigation dans le cube
Figure 7.44 — La mesure Quantité

commandée a été glissée
sur la partie détail du navigateur
Figure 7.45 — 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’empla-

cement des champs de filtre. Dans la liste déroulante désélectionnez toutes les
années sauf 2003.
Figure 7.46 — 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.47 — 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 dynami-
ques d’Excel.
Rappelons que l’outil de navigation n’est pas mis à la disposition de l’utilisa-
teur 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.48 — Formulaire permettant de d’afficher des éléments

afin de rendre le navigateur proche du tableau croisé dynamique
Figure 7.49 — 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élec-
tionnant 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 Pro-
duit). 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égorie-
Produit et en jointure avec la clé principale CléCatégorieProduit de la table Dim-
CatégorieProduit.
Figure 7.50 — 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
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.
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…
Dans la partie droite de l’écran (figure 7.51), cliquez sur la table dbo.Dim-
Produit puis actionnez le bouton Ajouter des tables associées.
Figure 7.51 — Ajouter des tables à une vue des sources

de données grâce aux tables associées
Figure 7.52 — 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 Ajou-
ter des tables associées.
L’assistant détecte automatiquement les jointures entre les tables puis les
intègre automatiquement à la vue.
Figure 7.53 — 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érar-
chie 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égorieProduit (figure 7.54).
Figure 7.54 — Ajouter les tables

DimSousCatégorieProduit
et DimCatégorieProduit au schéma en flocon
Figure 7.55 — Glisser-déplacer

un champ d’une table vers la hiérarchie
Grâce au glisser-déplacer, vous allez insérer le champ NomFrançaisSous-

Caté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.
Renommez également le titre de la hiérarchie en Produit et Catégories.
Figure 7.56 — 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 glo-
bale Produit et catégories puis déroulez l’arborescence des catégories de produit.
Figure 7.57 — Navigateur

de dimension
Figure 7.58 — Il est possible de naviguer dans tous les attributs de la dimension
7.5 Conclusion ——————————————————————————————————————————————————————————————————————————— 227
Vous pouvez changer de niveau hiérarchique et observer les membres selon

le nouvel axe dimensionnel.
La navigation dans le cube fait clairement apparaître la nouvelle hiérarchie
Produit et Catégorie.
Figure 7.59 — 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 apparaitre 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 diffi-
culté 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 fabri-
cation du cube, mais de par sa structure tabulaire et linéaire, elle reste difficile-
ment exploitable pour l’analyse. Le langage SQL, seul outil de requêtage, permet
de réaliser des rapports simples basé sur des notions de listes dont la valeur ajou-
tée consiste à effectuer des regroupements matérialisés par des sous-totaux inter-
mé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 affi-
chage instantané. Cette technique de regroupement de données sous forme préa-
grégée est de loin plus efficace que la méthode ancienne qui consistait à indexer
230 —————————————————————————————————————————————— 8. Méthode de conception des cubes avec SSAS
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 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 varia-
tion 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 Ser-
vices.
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 2005 afin d’accéder au datawarehouse. Il doit également
être connecté au serveur d’analyse de SQL Server 2005. De nombreux déve-
loppeurs 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ée dans BI Studio puis déployée sur le serveur. Plutôt que d’accéder
8.1 Organisation logique des cubes ————————————————————————————————————————————————————————— 231
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 main-
tenance. 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’utilisa-
teur final.
Bien qu’il faille attendre que la phase de définition du datawarehouse soit ter-
minée avant d’entamer celle de la construction des cubes OLAP, il n’est cepen-
dant 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 don-
nées de test, que l’on pourra modifier manuellement afin de créer différentes situa-
tions. 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’ensem-
ble de la solution. Les sources de données parta-
gées sont plus aisées à maintenir parce qu’elles sont
définies à un endroit unique (figure 8.1).
L’assistant des sources de données peut en créer Figure 8.1 — Trois projets
dans la même solution
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édiatement 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’effec-
tuer 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).
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 il seraient alors remplacés
à chaque retraitement du cube.
Il est possible d’ajouter dans la vue des tables en provenance de serveur tiers (Ora-
cle, DB2, etc.). D’une manière générale, on préfèrera effectuer des jointures sur des
tables de bases de données tiers dans l’environnement propre du datawarehouse.
Figure 8.3 — Les jointures sont reconstituées lors de l’ajout de tables
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épen-
dantes de tout cube.
Les dimensions sont par nature

partageables entre plusieurs
cubes. Lors de la construction du
cube les dimensions sont sélec-
tionné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 Figure 8.4 — Dans le projet Analysis Services
attributs, et une ou plusieurs hié- Tutorial, huit dimensions ont été préparées
Figure 8.5 — Le cube est composé

de dix dimensions (trois dimensions
temporelles, Due date, Order date, Ship
date, sont 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
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.6 — 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’histo-
rique) 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 dimen-
sionnelle. 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é-

rarchie 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 vio-
lations 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.
• Processing Mode : indique si l’indexation et l’agrégation doivent se produire

durant le traitement (Regular) ou après le traitement (Lazy).
Figure 8.7 — Options disponibles

en cas de personnalisation de la configuration des erreurs
• 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 don-
né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.
• Visible : détermine si le cube est visible ou non.
Figure 8.8 — Paramètres de stockage pour la dimension Customer
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 dimension parent-enfant présentera un usage Parent.
• Keycolumns : représente la colonne source de la table de dimension rela-
tionnelle. 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é.
Figure 8.9 — Les attributs sont organisés en trois ensembles homogènes

(Contacts, Demographic, Location)
• 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.
• AttributeHierarchyVisible : permet de cacher des attributs que l’on ne sou-
haite 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.
Figure 8.10 — Attribut parent-enfant de la dimension 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 exem-
ple, 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.
Modifier les attributs liés des dimensions

Figure 8.11 — L’attribut date est relié à l’attribut
Month name, lui-même relié à l’attribut Calendar
Quarter, lui-même relié à Calendar Semester lui-même
relié à Calendar Year dans une cardinalité de type
plusieurs et un type de relation flexible
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’inter-
rogation 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
navigation.
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.
Figure 8.12 — 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
Les niveaux des hiérarchies sont construits à partir des attributs des hiérar-
chies. Les propriétés de chaque niveau sont également empruntées aux attributs
correspondants et ne peuvent être modifiés 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.
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’uti-
lisateur.
Navigateur
L’onglet Navigateur permet d’explorer les attributs ou les hierarchies de dimen-
sion. La figure 8.13 montre une navigation dans la hierarchie Product Categories.
Après toute modification d’un attribut ou hiérarchie il est nécessaire de se recon-
necter 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 don-
nées du cube.
Dans la figure 8.13, si une traduction avait été développée, la liste déroulante
ferait apparaître les membres dans la langue adéquate.
Figure 8.13 — 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 cal-
culs 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 count.
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
comportent comme les cubes virtuels de la version MSAS 2000, les cubes vir-
tuels étant le résultat de jointure de cubes physiques distincts.
Figure 8.14 — Cellules feuilles

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
terminales 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.
Dans la figure 8.14, une seule cellule est ombrée. Cette cellule est l’intersec-
tion des membres suivants :
• le membre avion de la dimension Itinéraire;
Figure 8.15 — Cellules non-feuilles

• 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.15, les deux cellules en grisé représen-
tent 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.
La dimension Mesures fait l’objet d’un traitement particulier. Cette dimen-
sion 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
dimensions participent à quels groupes de mesures.
La structure du cube fait apparaître le groupe de mesures ainsi que les dimen-
sions 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).
Figure 8.16 — La structure du cube présente

les groupes de mesures et le dimensions du cube
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.
Figure 8.17 — L’onglet utilisation de la dimension
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.
À chaque intersection d’une mesure et d’une dimension, on peut trouver dif-
fé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 à un 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 dimen-
sion 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.18 — 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 Moyenne-
DesVentes 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’assis-
tant qui propose un certain nombre d’améliorations telle que :
• Assistant Time Intelligence : permet d’ajouter des vues supplémentaires
paramé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ério-
des 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
standard, 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 addition-
nelles 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
manuellement 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 mesu-
res 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 dispo-

sitifs 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 2005. 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 : [Measu-
res].[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]. Figure 8.19 — Liste
des indicateurs d’état
• L’état avec son indicateur d’état très visuel.
Tapez l’expression MDX qui renvoie la valeur d’état de l’indicateur de per-

formance 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.
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 gra-
phiquement 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)
)
/
(
)
)
>=.02
Then 1
When (
KpiValue("Reseller Revenue") –
(
)
/
(
)
)
<=.02
Then – 1
Else 0
End
Le résultat affiché dans le navigateur de l’onglet KPI est montré figure 8.20.
Microsoft dispose d’ores et déjà d’un outil très élaboré de définition et de
restitution des KPI. Business Scorecard Manager permet de définir ses propres
KPI puis de les intégrer grâce à des webpart dans le portail « maison » SharePoint
Portal.
Les KPI sont maintenant interprétés par les tableaux croisés dynamiques
d’Excel version 2007.
Figure 8.20 — Le navigateur dans SSAS

permet d’afficher la valeur, l’objectif, l’état et la tendance
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’un 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 para-
mè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 cer-
taines perspectives à certains utilisateurs autorisés. Il est possible également de
cacher le cube
Les perspectives ne sont disponibles que dans la version SQL Server 2005
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
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.21 — L’onglet Partitions montre les partitions liées aux groupes de mesures
8.2 L’organisation physique du cube ———————————————————————————————————————————————————————— 251
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.
Figure 8.22 — Chaque partition

correspond à un groupe de mesure du cube
La colonne agrégations précise le mode de stockage des agrégations de don-

né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 don-
nées qui peut se traduire par une vue filtrée. Les partitions sont associées dans
le groupe de mesure.
Figure 8.23 — 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 dimen-
sionnel. 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éfinie, 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 mul-
tidimensionnelle 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 2005 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 rem-
plissent 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éces-
sitent 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. Les performances sont inter-
mé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 2005 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.24 — Paramétrer les options de stockage
Figure 8.25 — 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 stoc-
ké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.
Après le déploiement du cube, SQL Server Management Studio permet d’obser-
ver le cube et ses dimensions attachées à chaque groupe de mesures.
Figure 8.26 — Management studio

présente les partitions associées aux groupes de mesures
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 par-
titionnement 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 der-
nières années ou les 90 derniers jours). Dans ce cas, il suffit de supprimer la parti-
tion plutôt que de supprimer des lignes dans une énorme partition. Enfin, le
partitionnement améliore les performances lors du processus de traitement com-
plet 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 pro-
duits. Cette fonctionnalité est réservée à SQL Server Enterprise Edition.
Figure 8.27 — Les propriétés de la partition sont modifiables

dans Management Studio telles que le mode
de stockage et la mise en cache proactif
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 don-
né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 ser-
veur 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.28 — 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.29 — 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 par-
tition, 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. Depuis SQL Server 2005,
une méthode réside dans la technique du cache proactif. L’alimentation s’effec-
tue à partir des tables opérationnelles 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 pas-
ser 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’ali-
mentation. Le risque naturel est de traiter deux fois les mêmes données ou tout
simplement d’omettre de les traiter. Malheureusement, SQL Server 2005 ne dis-
pose 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 retrai-
ter la partition incriminée.
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. Lors de la mise au
point initiale, testez, contrôlez autant que vous le pourrez. Après la mise en pro-
duction 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 effi-
cace 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. Testez avec les utilisateurs,
observez leur façon d’interpréter et de contrôler les données. Mettez en produc-
tion 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 plu-
tôt que d’apprendre par un utilisateur que votre cube est faux.
9
Le data mining
Un diffuseur d’ouvrages distribue plusieurs sortes de magazines : sciences humai-

nes, 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 égale-
ment 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’extrac-
tion 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
260 ———————————————————————————————————————————————————————————————————————— 9. Le data mining
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 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 plu-
sieurs algorithmes répondant à cette problématique.
La question 5 est également exploratoire et nécessite de conserver un histo-
rique 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
partagent 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 com-
munication (exemple : cibler les clients potentiels en n’envoyant des pros-
pectus qu’aux clients susceptibles de répondre).
9.1 Méthodologie de création du modèle de data mining —————————————————————————————————————— 261
• 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.
À 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 parais-
sent 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 choi-
sis 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.
262 ———————————————————————————————————————————————————————————————————————— 9. Le data mining
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 modi-
fiant 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 pro-
duction. 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 pro-
cessus 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 vien-
nent 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 don-
9.2 Quelles sont les tâches du data mining ? ————————————————————————————————————————————————— 263
né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’ajuste-
ment 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.
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éter-
miner 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;

264 ———————————————————————————————————————————————————————————————————————— 9. Le data mining
• 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 rassu-
rer, 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 commen-
cerons 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
2005 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.
9.3 Créer le modèle d’une campagne ciblée ————————————————————————————————————————————————— 265
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.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 sour-
ces de données, puis sélectionnez la source de données opérationnelle Adven-
tureWorks créée à l’étape précédente.
266 ———————————————————————————————————————————————————————————————————————— 9. Le data mining
Sélectionnez la vue dbo.vTargetMail dans laquelle se trouvent les données

nécessaires à l’analyse (voir figure 9.3).
Cette requête détermine quel client 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.
Voici la structure de la vue :
CREATE VIEW [dbo].[vTargetMail]

AS
SELECT
c.[CustomerKey],
c.[GeographyKey],
c.[CustomerAlternateKey],
c.[Title],
c.[FirstName],
c.[MiddleName],
c.[LastName],
c.[NameStyle],
c.[BirthDate],
c.[MaritalStatus],
c.[Suffix],
c.[Gender],
c.[EmailAddress],
c.[YearlyIncome],
c.[TotalChildren],
c.[NumberChildrenAtHome],
c.[EnglishEducation],
c.[SpanishEducation],
c.[FrenchEducation],
c.[EnglishOccupation],
c.[SpanishOccupation],
c.[FrenchOccupation],
c.[HouseOwnerFlag],
c.[NumberCarsOwned],
c.[AddressLine1],
c.[AddressLine2],
c.[Phone],
c.[DateFirstPurchase],
c.[CommuteDistance],
x.[Region],
x.[Age],
CASE x.[Bikes]
WHEN 0 THEN 0
ELSE 1
END AS [BikeBuyer]
FROM
[dbo].[DimCustomer] c INNER JOIN (
SELECT
[CustomerKey]
,[Region]
,[Age]
,Sum(
CASE [EnglishProductCategoryName]
WHEN ‘Bikes’THEN 1
ELSE 0
END) AS [Bikes]
FROM
[dbo].[vDMPrep]
GROUP BY
[CustomerKey]
,[Region]
,[Age]
) AS [x]
ON c.[CustomerKey] = x.[CustomerKey]
La vue vDMPrep qui participe elle-même à la vue vTargetMail est basée sur
le schéma en flocon dont la table de fait centrale est FactInternetSales et les
tables dimensionnelles : Customers, DimProduct, DimProductSubcategory, Dim-
ProductCategory, DimCustomer, DimGeography, DimSalesTerritory.
Figure 9.3 — Voici la vue vTargetMail
Cette vue permet de déterminer l’âge du client au moment de l’extration

grâce à la fonction DateDiff(yy, c.[BirthDate], 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.
Les noms longs sont réduits afin d’offrir plus de lisibilité dans le modèle.
268 ———————————————————————————————————————————————————————————————————————— 9. Le data mining
CREATE VIEW [dbo].[vDMPrep]

AS
SELECT
pc.[EnglishProductCategoryName]
,Coalesce(p.[ModelName], p.[EnglishProductName]) AS [Model]
,c.[CustomerKey]
,s.[SalesTerritoryGroup] AS [Region]
,CASE
WHEN Month(GetDate()) < Month(c.[BirthDate])
THEN DateDiff(yy, c.[BirthDate], GetDate()) – 1
WHEN Month(GetDate()) = Month(c.[BirthDate])
AND Day(GetDate()) < Day(c.[BirthDate])
THEN DateDiff(yy, c.[BirthDate], GetDate()) – 1
ELSE DateDiff(yy, c.[BirthDate], GetDate())
END AS [Age]
,CASE
WHEN c.[YearlyIncome] < 40000 THEN ‘Low’
WHEN c.[YearlyIncome] > 60000 THEN ‘High’
ELSE ‘Moderate’
END AS [IncomeGroup]
, t.[CalendarYear]
, t.[FiscalYear]
, t.[MonthNumberOfYear] AS [Month]
, f.[SalesOrderNumber] AS [OrderNumber]
, f.SalesOrderLineNumber AS LineNumber
, f.OrderQuantity AS Quantity
, f.ExtendedAmount AS Amount
FROM
[dbo].[FactInternetSales] f
INNER JOIN [dbo].[DimTime] t
ON f.[OrderDateKey] = t.[TimeKey]
INNER JOIN [dbo].[DimProduct] p
ON f.[ProductKey] = p.[ProductKey]
INNER JOIN [dbo].[DimProductSubcategory] psc
ON p.[ProductSubcategoryKey] = psc.[ProductSubcategoryKey]
INNER JOIN [dbo].[DimProductCategory] pc
ON psc.[ProductCategoryKey] = pc.[ProductCategoryKey]
INNER JOIN [dbo].[DimCustomer] c
ON f.[CustomerKey] = c.[CustomerKey]
INNER JOIN [dbo].[DimGeography] g
ON c.[GeographyKey] = g.[GeographyKey]
INNER JOIN [dbo].[DimSalesTerritory] s
ON g.[SalesTerritoryKey] = s.[SalesTerritoryKey]
;
Voici le résultat de la vue vDMPrep (tableau 9.1).

Tableau 9.1 — Résultat de la vue vDMPrep
English- Customer- Income- Calendar- Fiscal Order- Line- Quan-
Model Region Age Month 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
North
Bikes Road-650 14501 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
9.3 Créer le modèle d’une campagne ciblée
Mountain-
Bikes 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
Mountain-
Bikes 11011 Pacific 42 Moderate 2001 2002 7 SO43705 1 1 3 399,9900
100
Bikes Road-150 16624 Pacific 33 High 2001 2002 7 SO43703 1 1 3 578,2700
North
Bikes Road-150 27645 44 High 2001 2002 7 SO43702 1 1 3 578,2700
America
Bikes Road-150 13513 Europe 64 Low 2001 2002 7 SO43712 1 1 3 578,2700
North
Bikes Road-150 27606 49 High 2001 2002 7 SO43711 1 1 3 578,2700
America
Bikes Road-150 13591 Europe 53 High 2001 2002 7 SO43714 1 1 3 578,2700
Bikes Road-150 16483 Pacific 55 Moderate 2001 2002 7 SO43715 1 1 3 578,2700
Bikes Road-150 16529 Pacific 28 Low 2001 2002 7 SO43716 1 1 3 578,2700
—————————————————————————————————————————————————
Bikes Road-650 25249 Pacific 48 High 2001 2002 7 SO43717 1 1 699,0982

269
270 ———————————————————————————————————————————————————————————————————————— 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’aug-
menter ses ventes souhaite communiquer au moyen d’une campagne de publi-
postage. 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
Figure 9.7 — Option Customer Key

272 ———————————————————————————————————————————————————————————————————————— 9. Le data mining
Le formulaire des données d’apprentissage définit les clés et les colonnes à

prévoir.
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élec-
tion des colonnes pertinentes en cochant les entrées désirées.
Donnons le nom Publipostage Ciblé à la structure d’exploration puis Deci-
sion_Tree au modèle d’exploration.
Avant de traiter le modèle d’exploration, nous ajouterons deux modèles com-
plé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
Le modèle Naïve Bayses 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.
274 ———————————————————————————————————————————————————————————————————————— 9. Le data mining
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é »
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 Deci-
sion_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
importants 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.
276 ———————————————————————————————————————————————————————————————————————— 9. Le data mining
Figure 9.13 — La visionneuse de modèle.

Ici, modèle d’exploration Decision_Tree
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ésen-
tant 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.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 ache-
teurs). 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 ache-
teurs 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
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
278 ———————————————————————————————————————————————————————————————————————— 9. Le data mining
verticale sur le côté droit permet de faire apparaître progressivement ces liens
(du poids le plus fort au poids le plus faible).
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.

L’onglet Caractéristique d’attribut se présente comme suit dans la figure 9.19.
Cet onglet permet de sélectionner un attribut (acheteur de vélo) et d’établir des
liens décroissants avec d’autres attributs.
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 n’ont pas d’enfants)
Figure 9.19 — Onglet Caractéristiques d’attribut
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.
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.
280 ———————————————————————————————————————————————————————————————————————— 9. Le data mining
Figure 9.20 — L’onglet Discrimination d’attribut permet une comparaison deux à deux
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).
Dans le diagramme ci-après, le cluster 6 (en bas) contient la plus grande quan-
tité 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.21 — Le diagramme de cluster

permet de réaliser des groupes homogènes
Figure 9.22 — Graphique d’analyse

de précision pour la valeur 1 = acheteurs
282 ———————————————————————————————————————————————————————————————————————— 9. Le data mining
• 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 Predict ou 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 diagonale. Les algorithmes matérialisés par les trois courbes peu-
vent ainsi être comparés entre eux :
• L’algorithme Decision Tree permet un remplissage correct de 52 sur 65;

• L’algorithme Naïve Bayes permet un remplissage correct de 46 sur 68;
• L’algorithme Cluster permet un remplissage correct de 39 sur 63.
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.
Prenons comme hypothèse les éléments sui-
vants :
• cible de clients : 5 000;
• coût fixe de la campagne (frais de con-
ception et d’impression) : 10 000 €;
• coût variable de 5 € par client (expédi- Figure 9.24 — Formulaire
tion); permettant de recueillir
les caractéristiques financières
• le service marketing estime à 50 € par et d’estimation
personne par vente réussie.
Figure 9.25 — Graphique

des bénéfices prévisibles en fonction du modèle
284 ———————————————————————————————————————————————————————————————————————— 9. Le data mining
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 pro-
babilité lié au fait de contacter un client.
Figure 9.26 — Bénéfices maximaux avec un remplissage de 88 euros
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.
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 ProspectAlternate-
Key.
La troisième source PredictProbability fournit le degré de probabilité.
Figure 9.27 — Mappage des données du modèle

de prévisions avec les champs de la table d’entrée
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
286 ———————————————————————————————————————————————————————————————————————— 9. Le data mining
Figure 9.28 — Copier dans Excel la liste extraite
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élec-
tionnant que les acheteurs potentiels c’est-à-dire Bike Buyer = 1.
9.4 Conclusion ——————————————————————————————————————————————————————————————————————————— 287
Le code ProspectAlternate identifie précisément le client. L’expression per-

met de donner la précision de la prédiction.
Dans Excel, nous trions la colonne Expression (Probabilité) en mode décrois-
sant. Trions également la colonne Bike Buyer. Nous en déduisons les 1 041 ache-
teurs potentiels sur une population de 2 059.
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 nou-
velles possibilités. Les entreprises qui se donneront la peine d’exploiter les nom-
breuses 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 ?
En janvier 2004, Microsoft introduisait pour la première fois un nouveau com-

posant à SQL Server 2000 : Reporting Services. Ce nouvel outil avait pour but
de combler un vide dans la chaîne décisionnelle de Microsoft. En effet, SQL
Server 2000 disposait d’un outil OLAP puissant : Analysis Services. Excel per-
Figure 10.1 — Positionnement de Reporting Services dans la chaîne décisionnelle

290 ————————————————————————————————————————————————————————————————————— 10. Reporting Services
mettait d’accéder aux cubes et d’effectuer des analyses grâce au tableau croisé
dynamique. Or, nous l’avons déjà dit, l’essentiel des données de l’entreprise est
consulté au moyen de rapports prédéfinis. À cette époque, Cognos et Business
Objects disposaient déjà d’outils de reporting tels que ReportNet et Crystal
Report. Microsoft n’a donc pas attendu la version 2005 de SQL pour offrir son
module de reporting.
Reporting Services regroupe un ensemble d’outils, d’interfaces de program-
mation, de services run-time et d’outils visant à définir, générer, déployer, et gérer
des rapports. Reporting Services comprend un moteur pour héberger et traiter
les rapports. Une interface de programmation permet également d’incorporer des
rapports dans différents environnements informatiques.
10.1.1 À quoi sert Reporting Services ?

SSRS permet de créer des rapports pour une diffusion interne ou externe à l’entre-
prise. Reporting Services offre la possibilité d’accéder aussi bien aux bases de don-
nées opérationnelles qu’aux magasins de données ou cubes OLAP. Les rapports
peuvent être diffusés largement par messagerie électronique ou sur un portail web.
Lorsqu’un éditeur de logiciel offre des solutions d’ERP basées sur SQL Server,
il peut intégrer Reporting Services dans sa solution afin de proposer des rapports
interactifs prédéfinis.
Cette solution permet au client final de disposer d’un outil lui permettant de
créer lui-même ses propres rapports dynamiques. Ce nouvel outil, Report Builder,
isole la complexité de la base de données en exposant la couche métier à l’uti-
lisateur.
SSRS permet aux entreprises de mettre des rapports à disposition sur le Web.
Elles peuvent en effet concevoir des extranets sécurisés à destination de leurs
clients et fournisseurs.
Voici quelques scénarios d’utilisation de Reporting Services.
Rapports internes
• Rapports « Maison » (vente, finance, DRH).
• Administrables, accessibles via un portail ou intégrés aux solutions d’entre-
prise.
Rapports embarqués
• Afficher des rapports dans n’importe quelle application d’entreprise (ERP,
CRM) ou analytique.
• Architecture extensible et flexible.
10.1 Qu’est-ce que Reporting Services ? ————————————————————————————————————————————————————— 291
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
MS SQL Server (2000 et 2005) MS Analysis Services

Base de données (la version 2005 remplace la version 2000 sur un même
et sources serveur).
de données Toutes sources de données conformes au standard OLE
DB, ODBC.
Générateur de rapports grâce à Visual Studio

pour Business. Intelligence.
Outils de création
Langage de définition de rapports basé sur le langage XML.
de rapports
De nombreux outils tiers permettent de développer
des rapports au format RDL.
Format libre.
Format tabulaire.
Format matriciel (tableau croisé).
Graphique de données.
Les formats
Filtrage dynamique lors de l’exécution.
de rapports
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.
Plusieurs formats de restitution (PDF, TIFF, CSV, Excel,

Exécution XML, Archive web).
de rapports Planification de l’envoi des rapports à la demande
de l’utilisateur ou de l’administrateur.
La gestion des rapports

Reporting Services dispose d’une interface web permettant d’effectuer des tâches
de gestion de rapports. Le tableau ci-dessous recense les différentes tâches.
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)

10. Reporting Services
10.1 Qu’est-ce que Reporting Services ? ————————————————————————————————————————————————————— 293
Tableau 10.2 — Tâches de gestion de rapports
Gestion Connexions aux serveurs

des sources de données avec authentification.
Gestion des paramètres des rapports Valeurs par défaut proposées
Invites avec listes déroulantes.
Planification de l’exécution des rapports SQL Server Agent doit être installé
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.
Groupes.
Rôles.
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, 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.
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 exter-
nes 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’uti-
lisateur 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.
Le concepteur de rapport est hébergé dans l’interface commune de Visual Stu-
dio BI. Celle-ci permet grâce à de nombreux assistants de développer et déployer
des rapports sans connaissance approfondie de SQL Server.
Figure 10.3 — Le gestionnaire de rapports
Report Builder est un outil client qui permet aux utilisateurs non-programmeurs
de définir et déployer des rapports sans aucune connaissance de SQL Server.
Report Builder se base sur des modèles conçus à l’aide du concepteur de modèles
de rapports (Report Model Designer). Cet outil stocke les définitions de rapports
dans la base de données Report Server. Ces rapports peuvent ensuite être modi-
fiés, complétés et publiés par l’utilisateur lui-même via l’interface web.
10.2 LA CRÉATION DE RAPPORT
Afin d’illustrer les différents concepts abordés dans le paragraphe précédent,

nous allons créer un rapport de ventes de la société AdventureWorks, puis nous
le publierons sur le serveur de rapports. Enfin, nous le consulterons via le Web.
Avant de créer un nouveau rapport il est nécessaire d’introduire la notion de
région de données. Celle-ci peut être liée à de nombreuses sources de données.
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 quatre 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
10.2 La création de rapport ———————————————————————————————————————————————————————————————— 295
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é d’Access. Les lignes et
colonnes ne peuvent être interverties lors de l’exploration. Un pseudo drill
down permet d’afficher les totaux de ligne puis de déplier les lignes qui com-
posent ce total afin d’en connaître le détail.
• La liste permet de créer une section sur voire 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.
La création de rapport débute dans BI Visual Studio. À l’instar des autres

modules de Visual Studio, 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.4 — Choisir la source de données (ici la base opérationnelle

AdventureWorks) Nous utilisons le générateur de requête afin de concevoir le dataset
Figure 10.5 — Le générateur de requête aide

le concepteur au travers d’une interface graphique
La requête générée est la suivante :

SELECT PC.Name AS ProdCat,
PS.Name AS SubCat,
DATEPART(yy, SOH.OrderDate) AS OrderYear,
‘Q’ + DATENAME(qq, SOH.OrderDate) AS OrderQtr,
SUM(SOD.UnitPrice * SOD.OrderQty) AS Sales
FROM Production.ProductSubcategory AS PS INNER JOIN
Sales.SalesOrderHeader AS SOH INNER JOIN
Sales.SalesOrderDetail AS SOD ON
SOH.SalesOrderID = SOD.SalesOrderID INNER JOIN
Production.Product AS P ON SOD.ProductID = P.ProductID ON
PS.ProductSubcategoryID = P.ProductSubcategoryID INNER JOIN
Production.ProductCategory AS PC ON
PS.ProductCategoryID = PC.ProductCategoryID
WHERE (SOH.OrderDate BETWEEN ‘1/1/2002’ AND ‘31/12/2003’)
GROUP BY DATEPART(yy, SOH.OrderDate), PC.Name, PS.Name, ‘Q’+ DATE-
NAME(qq, SOH.OrderDate), PS.ProductSubcategoryID
L’exécution de la requête fournit la liste suivante :
Components Forks 2002 Q4 23543,1060
Bikes Road Bikes 2002 Q1 3171787,6112
Components Wheels 2002 Q4 163921,8870
Clothing Socks 2003 Q3 6968,6884
Bikes Road Bikes 2003 Q4 3734891,6389
Components Mountain Frames 2002 Q3 608352,8754
Components Handlebars 2002 Q4 18309,4452
Accessories Tires and Tubes 2003 Q3 41940,3364
Components Road Frames 2003 Q2 457688,8401
Clothing Vests 2003 Q4 66882,6450
Figure 10.6 — Le générateur de requêtes permet de consulter immédiatement

le résultat. La figure 10.6 montre un extrait de la requête précédente
La requête ci-dessus fait l’objet d’une rapport de type tabulaire ou matriciel.

Figure 10.7 — Choisir le type de rapport : tabulaire ou matriciel
L’assistant propose de disposer les champs disponibles en lignes et colonnes.

La case à cocher Activer l’exploration vers le bas permet de regrouper/déplier
les lignes du rapport.
Figure 10.8 — Formulaire de conception de la matrice du rapport.

Disposer les champs en lignes ou colonnes
L’assistant propose six styles d’affichage du rapport.

L’assistant termine en proposant un récapitulatif des choix effectués. Le nom
du rapport est fourni à cette étape.
Figure 10.9 — Choix

du style de rapport
Figure 10.10 —
L’assistant propose
un résumé
des actions effectuées
lors de la création
du rapport
Après activation du bouton Terminer, l’aperçu du rapport s’effectue dans BI

Studio.
L’étape suivante consiste à déployer le nouveau rapport sur le serveur de
rapport.
Au préalable, nos devons nous assurer que le serveur de rapport est correcte-
ment paramétré, comme dans la figure 10.12.
Figure 10.11 — Le mode aperçu permet une visualisation immédiate du rapport
Figure 10.12 — Formulaire de configuration précisant l’URL du serveur de rapports
Un clic droit sur la solution AdventureWorks Sample Reports permet de véri-

fier le paramètre de déploiement. TargetServeurURL doit fournir une adresse
telle que http://localhost/reportserver.
Requête MDX sur cube OLAP
Figure 10.13 — Source de données Analysis Services
Grâce au générateur de requête MDX, on utilise la technique du glisser-déplacer

afin de préparer les dimensions (date et produit) puis les mesures à analyser.
Figure 10.14 — Le générateur de requête MDX
La requête MDX générée est la suivante :

SELECT NON EMPTY {[Measures].[Internet Sales Amount]} ON COLUMNS,
NON EMPTY {([Product].[Category].[Category].ALLMEMBERS *
Product].[Subcategory].[Subcategory].ALLMEMBERS * [Date].[Calen-
dar].[Month].ALLMEMBERS)}
DIMENSION PROPERTIES MEMBER_CAPTION, MEMBER_UNIQUE_NAME ON ROWS
FROM [Adventure Works]
CELL PROPERTIES VALUE, BACK_COLOR, FORE_COLOR, FORMATTED_VALUE,
FORMAT_STRING, FONT_NAME, FONT_SIZE, FONT_FLAGS
La représentation visuelle de la requête précédente est illustrée dans le tableau

suivant aux lignes imbriquées.
Figure 10.15 —
Le résultat de la requête MDX
dans Proclarity
L’assistant propose alors de mettre en forme la matrice.

Ne pas oublier d’activer l’exploration vers le bas permettant le regroupement
des données et le dépliement des lignes (drill down).
Figure 10.16 —
Le concepteur
de matrice dispose
les axes Produits
et Date en lignes
et colonnes
Figure 10.17 —
Rapport
des ventes
élaboré à partir
d’une source
OLAP Analysis
Services
L’étape suivante consiste à déployer ce rapport dans Reporting Services.

Avant d’exécuter le rapport dans Reporting Services, veillez à établir une
source de données partagée et sécurisée selon les paramètres donnés figure 10.18.
Figure 10.18 —
Créer
une source
de donnée
personnalisée
de type Analysis
Services
La source de données doit préciser la chaîne de connexion. Celle-ci est four-

nie dans le formulaire des propriétés de la source de données partagée comme
dans l’exemple de la figure 10.19.
Figure 10.19 — Source de données partagée dans BI Studio
Il convient de préciser également le type de sécurité intégrée de Windows.

La barre d’outil permet d’ajouter un graphique au rapport.
Figure 10.20 — Outil d’ajout de graphique
La figure 10.20 montre l’outil graphique et la manière de l’utiliser. Un simple

glisser/déposer des champs de la source de données sur les axes du graphe permet
de construire un graphe lié au données de la source.
L’exemple de la figure 10.21 montre le rendu du rapport après ajout d’un
graphe.
Figure 10.21 — Le même rapport qu’en 10.17 avec introduction d’un graphe
L’interface de Reporting Services permet un affichage du rapport qui offre la

possibilité de l’exporter selon plusieurs formats :
• Fichier au format HTML/XML. Format à privilégier pour des transferts

entre plateformes. Ce format n’est pas le plus fidèle et n’est pas à retenir
lorsque la disposition du texte nécessite une grande précision.
• Fichier au format CSV (ASCII). Texte séparé par des virgules. Ce format
est très commun. De plus, il est directement interprété par Excel.
• Fichier TIFF (image).
• Fichier Acrobat (PDF) fournit un rendu plus fidèle que le format TIFF.
PDF est devenu le format standard de lecture grâce au logiciel Adobe
Acrobat Reader. Le format TIFF est lu par des logiciels de traitement
d’image tels que Windows Picture, Paint ou Fax Viewer. Il est ainsi pos-
sible d’envoyer des documents en pièces jointes grâce à un logiciel de mes-

sagerie.
• Archive Web.
• Excel (versions 97 à 2007).
Figure 10.22 — Le rapport exporté dans Excel (ici version 2007)
Lors de l’exportation, les données sont converties en valeurs permettant ainsi

d’être déconnectées de la source des données. Les groupes sont dynamiques et
peuvent faire l’objet d’un drill down/drill up.
La sortie papier reste cependant un choix très fréquent. Reporting Services
offre la possibilité d’imprimer directement côté client. Lors de la première
impression, l’utilisateur est averti de l’installation d’un composant ActiveX (bien
vérifier que le composant est signé Microsoft). Ce composant permet d’activer
l’interface d’impression telle que la gestion des marges, la taille de la page et
même l’orientation.
Ajouter des paramètres de sélection à un rapport OLAP

Lorsque l’on observe la première fois les rapports fournis en standard par SQL
Server 2005, la notion de filtrage sur rapports OLAP paraît pertinente, mais en
même temps semble complexe. En réalité, Visual Studio offre un assistant pour
les paramètres de filtrage d’une grande simplicité. Fort heureusement, nous
n’aurons pas à modifier manuellement le code MDX généré par l’assistant.
Dans notre exemple, nous ajouterons successivement un filtre sur l’année puis
un second sur la catégorie de produit.
Depuis l’onglet Données, nous glissons l’attribut CalendarYear dans la zone
réservée au filtrage matérialisée par le texte <Sélectionnez une dimension>. Aus-
sitôt une ligne nouvelle apparaît permettant d’effectuer une sélection sur les
années. Il est impératif de cliquer dans la case Paramètres afin de générer un
nouveau dataset au format MDX permettant ainsi de proposer une liste dérou-
lante à l’utilisateur. Cette fonction permet également d’imbriquer le fitrage dans
le dataset initial (AdventureWorksAS).
Figure 10.23 — Ajout d’un paramètre de filtrage
Voici le nouveau code MDX généré :

SELECT NON EMPTY {[Measures].[Internet Sales Amount]} ON COLUMNS,
NON EMPTY {([Product].[Category].[Category].ALLMEMBERS *
[Product].[Subcategory].[Subcategory].ALLMEMBERS *
[Date].[Calendar].[Month].ALLMEMBERS)} DIMENSION PROPERTIES
MEMBER_CAPTION, MEMBER_UNIQUE_NAME ON ROWS
FROM (SELECT (STRTOSET(@DateCalendarYear, CONSTRAINED)) ON COLUMNS
FROM [Adventure Works]) WHERE (IIF(STRTOSET(@DateCalendarYear,
CONSTRAINED).Count = 1, STRTOSET(@DateCalendarYear, CONSTRAINED),
[Date].[Calendar Year].currentmember))
CELL PROPERTIES VALUE, BACK_COLOR, FORE_COLOR, FORMATTED_VALUE,
FORMAT_STRING, FONT_NAME, FONT_SIZE, FONT_FLAGS
Un nouveau dataset DateCalendarYear a été créé automatiquement.
Figure 10.24 —
Le dataset de
filtrage est généré
automatiquement
Le dataset DateCalendarYear dispose de quatre champs :

• Calendar Year;
• ParameterCaption;
• ParameterValue;
• ParameterLevel.
Le formulaire présentant les paramètres du rapport est défini comme dans la

figure 10.24.
Figure 10.25 —
Formulaire
des paramètres
du rapport
L’exécution du rapport fait immédiatement apparaître le choix des données.
Figure 10.26 — Aperçu du rapport avec choix de la sélection des années
La même procédure permet d’ajouter un second filtrage sur la catégorie. Le

résultat est donné figure 10.26.
Figure 10.27 — Rapport filtré sur deux paramètres : année et catégorie
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.
10.3 La gestion des rapports ——————————————————————————————————————————————————————————————— 309
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

totalement sur les utilisateurs et rôles créés dans le système de sécurité de Win-
dows. 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 Repor-
ting Services.
Les rôles de Reporting Services

Reporting Services fournit cinq rôles standards pour lesquels il est nécessaire
d’attribuer un compte utilisateur ou groupe Windows.
Tableau 10.3 — Les rôles 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.
Par exemple, un utilisateur auquel il a été attribué un rôle de serveur de publi-

cation sera autorisé à publier, créer, voir et supprimer des rapports. En revanche,
il ne sera pas autorisé à créer de nouveaux rôles.
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.
Figure 10.28 — Page de sécurité pour le dossier racine
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. Voici
les droits des rôles.
Tableau 10.4 — Tâches des rôles dans Reporting Services
Afficher Permet d’afficher les éléments dans l’arborescence

les dossiers des dossiers, ainsi que les propriétés des dossiers.
Afficher des modèles de l’arborescence des dossiers,

Afficher utiliser des modèles comme sources de données
les modèles pour un rapport et exécuter des requêtes
sur le modèle pour extraire des données.
Permet d’afficher les rapports et les rapports liés

Afficher dans l’arborescence des dossiers, ainsi que les captures
les rapports instantanées d’historique de rapport et les propriétés
de rapport.
Afficher Permet d’afficher les ressources dans l’arborescence

les ressources des dossiers, ainsi que les propriétés des ressources.
Permet d’afficher les éléments de source de données

Afficher les sources
dans l’arborescence des dossiers, ainsi que les propriétés
de données
de la source de données.
Créer Permet de créer des rapports liés et de les publier

des rapports liés dans un dossier du serveur de rapports.
Définir la sécurité Permet d’afficher et de modifier les paramètres

pour des éléments de sécurité des rapports, des dossiers, des ressources
individuels et des sources de données partagées.
Gérer Chaque utilisateur peut créer, afficher, modifier

les abonnements et supprimer des abonnements dont il est propriétaire.
individuels
Permet de créer, d’afficher et de supprimer des dossiers,

Gérer les dossiers ainsi que d’afficher et de modifier des propriétés
des dossiers.
Créer, afficher et supprimer des modèles, et afficher

Gérer les modèles
et modifier des propriétés de modèle.
Permet de créer, d’afficher et de supprimer des rapports,

Gérer les rapports
ainsi que de modifier des propriétés des rapports.
Permet de créer, de modifier et de supprimer

Gérer les ressources des ressources, ainsi que d’afficher et de modifier
des propriétés des ressources.
Permet de créer et de supprimer des éléments de source

Gérer les sources
de données partagée, ainsi que de modifier
de données
des propriétés de source de données.
Permet de créer, d’afficher et de supprimer des captures

Gérer l’historique
instantanées d’historique de rapport, ainsi que
de rapport
de modifier des propriétés d’historique de rapport.
Gérer tous Permet d’afficher, de modifier et de supprimer

les abonnements un abonnement 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.5 — 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.
Fournit une application qui permet de générer

Générer
des événements dans l’espace de noms du serveur
des événements
de rapports.
Gérer la sécurité Permet d’afficher et de modifier les attributions

du serveur de rôles au niveau du système.
de rapports

Gérer les planifications
des planifications partagées qui sont utilisées
partagées
pour exécuter des rapports ou les actualiser.
Permet d’afficher et de modifier les propriétés

Gérer les propriétés
qui s’appliquent au serveur de rapports
du serveur de rapports
et aux éléments gérés par celui-ci.
Permet de créer, d’afficher et de modifier

Gérer les rôles
des définitions de rôles.
Permet d’afficher et d’annuler les travaux

Gérer 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.6 — Rôles standards créés lors de l’installation de Reporting Services
Générateur Permet de visualiser les définitions de rapports.

de rapports
Gestionnaire Peut gérer un contenu sur Report Server, notamment

de contenu des dossiers, des rapports et des ressources.
Peut afficher des dossiers et des rapports, et s’abonner

Lecteur
à des rapports.
Peut publier des rapports et des rapports liés, gérer

Mes rapports des dossiers, des rapports et des ressources
dans le dossier « Mes rapports d’un utilisateur ».
Peut publier des rapports et des rapports liés sur Report

Serveur de publication
Server.
Chaque rôle prédéfini comporte un certain nombre de tâches.

Tableau 10.7 — Attribution des tâches par rôle
Générateur Gestionnaire Mes

Rôles Lecteur 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
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énérateur Gestionnaire Mes

Rôles Lecteur Publication
de rapports de contenu rapports
Gérer tous les
NON OUI NON NON NON
abonnements
Lire les rapports OUI OUI NON NON NON
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 rap-
ports, mais pas nécessairement de son contenu.
Tableau 10.8 — Attribution des tâches par rôle
Afficher Permet d’afficher une planification prédéfinie

les planifications qui est disponible à des fins d’utilisation générale.
partagées
Fournit une application qui permet de générer
Générer
des événements dans l’espace de noms du serveur
des événements
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
des planifications partagées qui sont utilisées
partagées
pour exécuter des rapports ou les actualiser.
Permet d’afficher et de modifier les propriétés
Gérer les propriétés
qui s’appliquent au serveur de rapports
du serveur de rapports
et aux éléments gérés par celui-ci.
Permet de créer, d’afficher et de modifier
Gérer les rôles
des définitions de rôles.
Permet d’afficher et d’annuler les travaux en cours
Gérer les travaux
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 per-
mettant aux utilisateurs d’afficher des informations de base sur le serveur de rap-
ports. Il prend également en charge le chargement d’un rapport dans le Générateur
de rapports.
Tableau 10.9 — Liste des tâches du rôle Utilisateur Système
Afficher Permet d’afficher une planification prédéfinie

les planifications qui est disponible à des fins d’utilisation générale.
partagées


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.
Figure 10.29 —
Nouvelle attribution
de rôle système
Figure 10.30 —
Formulaire de nouvelle
attribution de rôle système
Dans le champ Nom d’utilisateur ou de groupe, vous devez entrer un nom

d’utilisateur ou groupe Windows. Il est possible également de préfixer le nom
d’utilisateur par le nom de domaine tel que DOMAIN\Utilisateur.
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
Cliquez sur Modifiez la sécurité de l’élément Une confirmation de modifica-

tion de l’héritage des paramètres de sécurité du dossier parent est demandée à
l’opérateur. Il est ainsi possible d’effectuer une nouvelle attribution de rôle.
Figure 10.32 — Propriétés de sécurité

Ajoutez un utilisateur Windows.
Figure 10.33 —
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é.
Figure 10.34 — Attribution du rôle Lecteur à l’utilisateur Bertrand

À l’issue de ce traitement, voici les rôles attribués au répertoire Adventure-

Works Sample Reports (figure 10.34).
Figure 10.35 — 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
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 dos-
sier 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.
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 main-
tenance 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.36).
10.3.3 L’exécution de rapports

L’onglet Propriétés de l’exécution d’un rapport permet de définir le processus
d’optimisation lors de l’affichage. Ces options déterminent à quel moment se
produit le traitement du rapport. Vous pouvez ainsi définir ces options pour pro-
grammer l’exécution d’un rapport la nuit ou lorsque le serveur est le moins sol-
licité. Si un rapport est consulté fréquemment, vous pouvez également mettre en
Figure 10.36 — Le menu General de l’onglet Propriétés

du rapport permet de créer un rapport lié avec une sécurité différente
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 dis-
ponible 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.
Figure 10.37 — Formulaire de définition des propriétés

lors de l’exécution du rapport
• 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 der-
nier 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.
Figure 10.38 — Formulaire permettant de préciser les détails

de la planification d’envoi de rapports
• 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. Les clichés d’historique de rapport
sont accessibles à partir de la page Historique du rapport, qui stocke de
nombreuses instances d’un rapport à différents moments dans le temps.
Les utilisateurs ont accès aux clichés d’exécution de rapport à partir des
dossiers (comme pour les rapports actifs).
• 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é dispo-
nible 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 rap-
port 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 à dif-
férentes périodes et ainsi d’analyser les tendances. Précisons que ces analyses res-
tent 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.39 — 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.40 — 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’abonne-
ment 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 (exem-
ple : smtp.wanadoo.fr).
Figure 10.41 — 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 @Exe-
cutionTime).
Figure 10.42 — La réception du rapport dans Outlook
Un lien dynamique vers le serveur permet de rafraîchir le rapport et de retrou-

ver 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 per-
met 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éces-
site 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
10.4 Reporting à la demande avec Report Builder ———————————————————————————————————————————— 325
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 utili-
sateur 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 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.10 donne la liste des options disponibles
lors de la génération du modèle de rapport.
Tableau 10.10 — 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,

pour toutes les tables qu’elle contienne ou non des données.
Créer des agrégations Crée un champ d’agrégation qui contient

de comptage le nombre d’instances uniques d’une entité.
Créer des attributs Crée un attribut pour chaque colonne

de chaque table.
Créer des attributs pour les Crée un champ masqué qui contient les données
colonnes à incrémentation de la base de données incrémentées
automatique automatiquement.
Créer des variations de date Crée des variations sur les champs de date
en fonction 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.
Options Description de l’option
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
d’identification entité. Le générateur de rapports identifie
les attributs d’identification potentiels.
Définir les attributs de détail Indique les champs qui sont affichés par défaut
par défaut lorsqu’un 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 des nombres Tire les champs numériques et de date dans l’ordre
et de la date décroissant.
Mise en forme des nombres Met en forme les nombres entiers et décimaux.
entiers/décimaux
Mise en forme des nombres Définit la mise en forme des champs à virgule
à virgule flottante 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

le regroupement uniques. Cette option prend la valeur True
par défaut pour les attributs d’identification.
Sélection des valeurs de liste Définit la propriété de sélection des valeurs aux
déroulante listes déroulantes pour les champs contenant moins
de 200 valeurs uniques.
10.4 Reporting à la demande avec Report Builder ———————————————————————————————————————————— 327
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.
Figure 10.43 —
Le formulaire liste les champs source
repris dans le modèle
Figure 10.44 —
L’entité Sales Person
montre les colonnes
dérivées
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 conce-
voir 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.
Lorsque le rapport est défini, il peut être enregistré sur le serveur de rapports.
Il devient donc disponible aux utilisateurs autorisés.
Le filtrage offre des conditions simples à utiliser et intuitives.
Figure 10.45 — Grâce à un glisser-déplacer,

la construction du rapport s’effectue
Figure 10.46 — Filtrage sur l’année de commande

10.5 Conclusion —————————————————————————————————————————————————————————————————————————— 329
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.
Figure 10.47 — Le rapport filtré affiché dans Reporting Services
10.5 CONCLUSION
Les managers opérationnels disposent de peu de temps pour se former aux tech-
niques de la création de rapports. Les informaticiens joueront pleinement leur
rôle en préparant des rapports utiles aux personnels de l’entreprise. La facilité
de compréhension des rapports et leur mise à disposition rapide permettra 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é dyna-
mique. 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 fonc-
tionnalités à Excel permettant ainsi d’accéder à des cubes OLAP. Cette techno-
logie 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
332 ———————————————————————————————————————————————————————— 11. L’analyse de données avec Excel
un lieu de ressaisie manuel mais un outil d’analyse accédant aux données stra-
tégiques.
Dans ce chapitre nous présenterons les tableaux croisés dynamiques d’Excel
accédant aux cubes OLAP 2000 ou 2005. 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)
ne déroge pas à la règle. Elle apporte cependant une fonctionnalité liée à SSAS
2005 : 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 fonctionna-
lité est très prisée des utilisateurs nomades qui peuvent ainsi accéder à leurs analyses
sur Excel via un navigateur web.
Avec Office Business Scorecard Manager 2005, Microsoft offre une ouverture
nouvelle aux managers 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 restitu-
tion 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.
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 rafraichissement 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.
11.1 L’analyse ad hoc grâce aux tableaux croisés dynamiques ————————————————————————————————— 333
Figure 11.1 —
Connexion
au serveur Analysis
Services 2005
Sélectionnez la base de données (ou cube ou perspective) désirée. Il est néces-

saire 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 Ser-

vices. La version 8 correspond à AS 2000, la version 9.0 à MSAS 2005.
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 nou-
velle 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 dimen-
sions. Voir figure 11.5.
Les champs de page permettent d’effectuer un filtrage de la source de données
sur plusieurs critères.
Figure 11.5 — L’assistant propose trois axes dimensionnels

et une zone réservée aux mesures
L’espace nommé Déposer Données ici reçoit

les donnée 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.
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 Figure 11.6 — Sélectionner
la figure 11.7 le pays France sur la zone champs un ou plusieurs éléments
en filtre de page
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)
Figure 11.8 —
Options avancées
de champ
dynamique
Figure 11.9 — Liste des dix meilleures ventes de vélos (Road Bikes) de 2001 à 2004
Figure 11.10 — Le tableau croisé et le graphique croisé

sont synchronisés dynamiquement
La figure ci-dessus montre une sélection des 10 meilleures ventes (Total sales
amount) triées en ordre décroissant.
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 une graphique
croisé dynamique.
Le graphique croisé dynamique est directement lié au tableau croisé. Le gra-
phique est mis à jour dynamiquement en fonction des choix effectués dans le
tableau. Un drill down dans le tableau entraine la même opération dans le gra-
phique et réciproquement.
Excel 2007 présente des améliorations visuelles et de nouvelles fonctionnalités.
Figure 11.11 — La nouvelle interface des tableaux croisés dynamiques d’Excel 2007
Excel 2007 permet également une restitution des KPI (Indicateurs clés de
performances) inclus dans Analysis services 2005.
Créer un cube local

Pour des collaborateurs nomades qui par définition se déplacent et qui ne dis-
posent 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
fonctionnalité 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 ver-
sions Excel 2002 (XP) et 2003.
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 direc-
tement 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 don-
né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’enregis-
trement 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/2005);

• 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;
11.2 Complément Microsoft Office Excel pour SQL Server Analysis Services —————————————————————— 341
• 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 :
Figure 11.19 — Outil de disposition des rapports
Figure 11.20 — La sélection du choix Ligne, colonne et filtre de page

crée un rapport composé de quatre sections
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.
11.2 Complément Microsoft Office Excel pour SQL Server Analysis Services —————————————————————— 343
Figure 11.21 — Rapport défini avec l’outil Analyse de données
À 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 Custo-
mers].children})}})} on 0, {Hierarchize({{[Product].[Subcate-
gory].[All Products],
AddCalculatedMembers({[Product].[Subcategory].[All Products].chil-
dren})}})} 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
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 2005 aient été
ajoutées (groupes de mesures, dimensions hiérarchiques) à l’heure où nous tes-
tons le complément d’analyse sur les cubes UDM (AS 2005) certaines fonctions
ne sont pas encore opérationnelles. Cela est probablement lié à la différence de
structure entre les cubes AS 2000 et 2005.
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 2005.
11.3 REPORTING INTERACTIF SUR LE WEB AVEC OWC
Les managers nomades qui désirent accéder régulièrement à leurs tableaux trou-
veront 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’interroga-
tion 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é dyna-
mique) 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

11.4 Conclusion —————————————————————————————————————————————————————————————————————————— 345
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.
Les limitations de tels outils ont été évoquées plus haut. Grâce à SQL server
2005 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 satis-
faisante. 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 don-
né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/2005 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.
348 ———————————————————————————————————————————————————————— 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 cha-
que 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 per-

met 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 ? »
12.1 Proclarity for Business Scorecard Manager —————————————————————————————————————————————— 349
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
graphiques de Pareto illustrent la répartition des valeurs afin de permettre d’iden-
tifier 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 tri-
mestre 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 pourcen-
tage 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 obser-
vé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 cou-
leur, 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 : « Pour-
quoi, 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éa-
lise-t-il des ventes inférieures aux autres produits doublées d’une faible pro-
gression (petite taille et couleur noire) à celles des autres produits durant la
même période ? »
Figure 12.3 —
Carte
de performances
12.2 Proclarity Analytics Server (PAS) ——————————————————————————————————————————————————————— 351
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. 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’affai-
res 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 concen-
trer sur un pourcentage donné de la valeur totale. Vous pouvez, par exemple, dépla-
cer 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’uti-
lisateurs 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 Ser-
vices 2005.
Figure 12.5 — Plate-forme de business intelligence de Proclarity
Analytics Server est le composant central de la plate-forme de business intel-

ligence (figure 12.5). Les utilisateurs peuvent manipuler leurs données, les ana-
lyser 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.
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’effec-
tuer 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),
L’onglet Data Layout permet de disposer les mesures et les dimensions sur la
surface du dessin.
L’onglet View permet de choisi 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.6 — Rapport stocké sur la plate-forme analytique permettant

une navigation dans un cube OLAP sur le Web
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 apparaitre le serveur composé de librairies, de roles et d’utilisateurs. Chaque
librairie et chaque livre qui la compose fait l’objet d’une autorisation d’accès expli-
cite. Dans la partie de droite on observe les rapports appartenant à chaque librairie.
Figure 12.8 — Détail de la console d’administration de Proclarity
Les Librairies sont créées sur le serveur analytique par les utilisateurs autorisés
à l’aide de Proclarity Professionnal. 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 utili-
sateurs sur le Web. Par exemple, le composant Web Professional peut être auto-
risé 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.
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 inter-
face 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.9 — Reporting Services encapsulé

dans le portail Proclarity
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 instal-
lé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 navi-
gation (figure 12.11) tels que Drill down, Drill Up, Expand (développer), Show
only (sélectionner 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.
L’onglet Sort permet de trier toute colonne en ordre ascendant ou descendant
tout en préservant les groupes hiérarchiques.
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.
L’utilisateur dispose d’un choix de fonctions (figure 12.13) permettant de sau-
vegarder ses vues personnelles afin d’organiser son propre environnement d’ana-
lyse. Il peut également imprimer sur l’imprimante disponible ou exporter les
Figure 12.12 — L’onglet View
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.
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 électroni-
que, serveur PAS etc.)
Figure 12.13 —
Les utilisateurs qui disposent d’une version Procla- Différentes options
rity Professional installée sur le poste peuvent aussi d’envoi de documents
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 envi-
ronnement 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 Conclusion —————————————————————————————————————————————————————————————————————————— 359
12.4 CONCLUSION
Ce chapitre a montré l’innovation apportée par le logiciel Proclarity et ses dif-

férentes déclinaisons. L’accès aux tableaux via le web est une demande croissante
en particulier pour les opérateurs qui offrent des solutions d’hébergement d’appli-
cations (ASP : Applications Services Providers).
Selon les informations en notre possession, Microsoft projette d’inclure l logiciel
Proclarity dans son futur produit PerformancePoint. Une version de Performance-
Point integrera également BSM. Le lecteur intéressé par PerformancePoint pourra
consulter le site http://office.microsoft.com/fr-fr/assistance/CH101649551033.aspx.
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éthodolo-
gie 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égra-

tion de données, la modélisation ou l’analyse d’entreprise est indispensable.
362 ————————————————————————————————————————————————————————————————————— 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 techni-
cien 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éfi-
nir les caractéristiques essentielles du chef de projet décisionnel.
Ê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 avan-
cé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.
Ê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
13.1 Les caractéristiques du chef de projet décisionnel ———————————————————————————————————————— 363
de projet BI aura assumé par le passé plusieurs rôles différents dans des projets
antérieurs.
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.
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 sou-
vent 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.
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 chro-
nologie 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.
364 ————————————————————————————————————————————————————————————————————— 13. Passez à l’action !
Compétences en communication
Pour être un chef efficace, un individu doit également être un grand communi-
cateur. Un chef de projet efficace transmet ses messages de manière compréhen-
sible 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 indispen-
sable 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.
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 rap-
ports entre individus. L’honnêteté stimule la confiance et le respect entre les mem-
bres 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 arri-
vera 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.
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éden-
tes. 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 ? —————————————————————————————————————————————————— 365
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’entre-
prise n’a de valeur que si l’on en fait quelque chose.
Dans le monde de la BI, il convient d’observer que des investissements sont
nécessaires à 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’effi-
cacité 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
relativement à l’avantage d’entreprendre un projet de business intelligence. Plu-
sieurs 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 avanta-
ges. Cependant, une mesure généralement admise est le ROI.
Les composants de cette stratégie comportent une analyse des coûts, un
accroissement 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 dataware-
house et des licences de base);
• les coûts variables associé à l’activité. (achat des licences des outils de
restitution);
• 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 claire-
ment identifier. Ils incluent le prix d’achat du logiciel, des honoraires de main-
366 ————————————————————————————————————————————————————————————————————— 13. Passez à l’action !
tenance, des dépenses de développement générant des coûts de main d’oeuvre

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
produisent 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. Cepen-
dant, 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écision-
nel afin d’offrir à son personnel des outils d’interrogation et de reporting. Cepen-
dant, 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’éta-
blir 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 suivant.
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.

13.2 Quel est le retour sur investissement ? —————————————————————————————————————————————————— 367
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.
Le salaire horaire moyen est estimé à 75 €.
Voici un 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
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 ou la société
Adventure Works Cycles commercialisant un grand nombre de marques décide
de fournir l’accès aux données à chacun des ses fournisseurs. Créant un portail
368 ————————————————————————————————————————————————————————————————————— 13. Passez à l’action !
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 bud-

get conséquent et une maintenance très lourde. Toutefois, depuis que la démo-
cratisation 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 faci-
litent 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 progres-
sive 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 2005 côté serveur;
• Office 2003 côté client.
Le serveur SQL Server comporte de manière intégrée tous les éléments néces-
saires à une solution décisionnelle :
• un ETL d’entreprise, Integration Services, pour l’extraction, la transfor-
mation 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’informations 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;
13.3 Faire une offre de solution décisionnelle ———————————————————————————————————————————————— 369
• SharePoint Portal Server, pour le partage des graphiques et tableaux croi-

sés dynamiques sur l’intranet ou le portail d’entreprise;
• optionnellement, MapPoint peut être intégré au dispositif pour une repré-
sentation 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 Mana-
gement) permettant une mise en place et un suivi de tous types d’indica-
teurs 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’informa-
tion des entreprises, selon de multiples sources – nécessite la mise en place de
370 ————————————————————————————————————————————————————————————————————— 13. Passez à l’action !
protocoles. Simplifier cette étape est indispensable pour pouvoir ensuite mani-
puler les données, les confier aux utilisateurs et améliorer la diffusion d’informa-
tion dans l’entreprise.
Un ETL extrait les données de sources hétérogènes, les transforme et les réin-
jecte dans une nouvelle base, le datawarehouse. Cela permet de nettoyer et trans-
former 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 Integra-
tion 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 2005 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écu-
pé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 2005 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 2005) permet un bascule-
ment automatique pour les applications clientes en cas de défaillance d’un ser-
veur, 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 2005 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 docu-
ments 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 2005 offre aussi une meilleure compatibilité avec les environne-
ments Oracle, et des interfaces sont disponibles pour SAP.
13.3.5 Productivité dans le développement d’applications

liées à SQL Server 2005
SQL Server 2005 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 program-
mation classique (C#, VB.Net, J#).
La création de projets et solutions autour de SQL Server 2005 (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 productivité pour les développeurs (débogage plus aisé, choix du lan-
372 ————————————————————————————————————————————————————————————————————— 13. Passez à l’action !
gage 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 ser-
vices 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 2005 introduit
la console d’administration SQL Server Management Console qui permet
l’administration centralisée de l’ensemble des services SQL Server (moteur rela-
tionnel, moteur OLPA, moteur ETL, serveur de reporting, mobilité) à travers
un unique outil.
13.3.7 Sécurité
SQL Server 2005 introduit de nouvelles fonctionnalités qui renforcent la sécu-
rité 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 2005 est Analy-
sis Services 2005. Elle apporte des fonctions d’analyse en temps réel, un fra-
mework 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 2005 améliore également son
moteur de data mining, permettant d’effectuer des découvertes au sein des
datawarehouses.
13.3.9 Reporting
SQL Server 2005 comporte une plate-forme complète de reporting. De la créa-
tion 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 2005. Les outils de reporting, une
fois déployés par les informaticiens, donnent aux managers une réelle indépen-
dance 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 techni-
que 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 utilisa-
teurs sur le portail intégré.
Les rapports sont directement sauvegardés sur le serveur de rapports. Les rap-
ports 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 grou-
pes aux États-Unis, la salle de Management Cockpit permet de réagir rapide-
ment 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éfi-
nis 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
374 ————————————————————————————————————————————————————————————————————— 13. Passez à l’action !
figure 13.2 montre les différentes couches qui composent cette plate-forme (cou-
che physique d’alimentation, couche applicative, couche de restitution).
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 res-
ponsables informatiques confrontés aux discours marketing des éditeurs de solu-
tions de business intelligence ont forcé les organisations à la prudence. Avant
de s’engager définitivement 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 Comment mettre en place un projet décisionnel ? ———————————————————————————————————————— 375
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
(architectes, DSI) et les utilisateurs (responsables des directions fonction-
nelles ou opérationnelles (finance, achat, marketing, commercial, commu-
nication, 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 com-

plè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.
376 ————————————————————————————————————————————————————————————————————— 13. Passez à l’action !
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.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 2005 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 pro-
cessus 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’opti-
misation 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éci-
sionnelles à mettre en place sont prioritairement le reporting ad hoc (61 %), le
tableau de bord pour 59 %, le portail décisionnel (54 %), et l’analyse multidi-
mensionnelle (51 %).
Comme nous l’avons vu dans cet ouvrage, des outils sont largement disponi-
bles. 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écia-
listes 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 Micro-
soft. 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 pren-
dre en compte de plus en plus de besoins et ainsi de suivre la progression de
l’activité de toute entreprise.
378 —————————————————————————————————————————————————————————————————————————————— Conclusion
Cependant, peu nombreux sont les décideurs qui exploitent ces outils en tota-
lité. Qui peut se vanter de connaître (et encore moins d’appliquer) toutes les
fonctionnalité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 comman-
dement dans les organisations passe du mode simulation au mode opératoire et réci-
proquement 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 expli-
quée par ses promoteurs. Nous pensons qu’elle s’intègre elle-même dans une appro-
che 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émo-
cratisation de la business intelligence. Il forme et encadre en entreprise des étu-
diants 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é !
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, Edi-
tions 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’Organisa-
tion, 2004.
380 ———————————————————————————————————————————————————————————————————————————— Bibliographie
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’Organisa-
tion, 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.
Applied Microsoft Analysis Services 2005, TEO Lachev, Éditions Prologika, 2005
et 2006.
Delivering business intelligence with Microsoft SQL Server 2005, Brian Larson,
Osborne Mc Graw Hill, 2006.
Diriger un projet Informatique – Les secrets des consultants, Jacques Claviez, Édi-
tions JCI inc., 1993.
Scénarios pour la NET Economie, Karim Mokhnachi, Sandra Spinek Éditions
d’Organisation, 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 Knoc-
kaert., Éditions d’Organisation, 2005.
Découvrir Microsoft SQL SERVER 2005, Peter DeBetta, Éditions Microsoft Press,
2004.
Quel sytstème décisionnel pour les entreprises agiles ?, Philippe Nieuwbourg Edi-
tions Microsoft, mai 2004.
Le guide Decideo, Philippe Nieuwbourg, Luc Mornat, Véronique Blanc, Marcom
Generation, 2004.
Liens vers des sites Internet

Site de l’auteur : http://www.buroformatic.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/
Témoignages de mise en œuvre de SQL Server et la business intelligence :
www.microsoft.com/france/sql/sql2005/evaluez/temoignages.mspx
Bibliographie ———————————————————————————————————————————————————————————————————————————— 381
Guides comparatifs des fonctionnalités de business intelligence :

http://www.guidescomparatifs.com/guide-bi-olap-decisionnel.html
Site de présentation de Office PerformancePoint :
http://www.microsoft.com/performancepoint
Le site de référence Microsoft pour la business intelligence :
http://www.microsoft.com/france/sql/sql2005/default.mspx
Microsoft et Proclarity :
http://www.proclarity.com/fr/
À la découverte de SQL server 2005 :
http://www.microsoft.com/france/sql/sql2005/solution/edito/decouverte.mspx
Les 30 fonctionnalités majeures de SQL Server 2005 :
http://www. microsoft.com/france/sql/sql2005/decouvrez/fonctionnalites.mspx
Comparaison des fonctionnalités de SQL Server 2005 :
http://www. microsoft.com/france/sql/sql2005/achetez/versions.mspx
Formation à SQL Server 2005 e-learning :
http://www.microsoft.com/france/sql/sql2005/utilisez/e-learning.mspx
Le décisionnel avec SQL Server 2005 :
http://www.microsoft.com/france/technet/produits/sql/decisionnel.mspx
Site des utilisateurs de SQL Server :
http://www.guss.fr/
Business intelligence en Open Source :
http://www.palo.net/
http://www.pentaho.com/
La Synthèse 2007 de l’offre Microsoft pour les entreprises :
http://www.calipia.com/lasynthese.asp
Vous pouvez télécharger la version française et gratuite de SQL Server 2005
Enterprise, valable 180 jours, à l’adresse suivante : http://www.microsoft.com/
downloads/details.aspx?familyid=6931FA7F-C094-49A2-A050-
2D07993566EC&displaylang=fr
Site mondial d’observation du marché OLAP :
http://olapreport.com
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.
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 EIS en mode client/serveur.

Command Center
1990 Lancement de Cognos Premier client OLAP pour station de travail

Powerplay sous PC Windows. Indissociable de
Transformer (moteur de fabrication des cubes)
et Impromptu (requêteur du datawarehouse).
384 ————————————————————————————————————————————————————————————————— A. Petit historique de la BI
1992 Lancement de Essbase
1993 E. Codd dicte les règles qui À la demande de la société Arbor Software.
décrivent les moteurs OLAP 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 une architecture

par Microstrategy OLAP à 3 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 Création dynamique de cubes fondés

Objects 4.0 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 Livrable sous forme d’API (module interface).
OLE DB for OLAP
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 Initialement nommé DSS (Decision Support

OLAP services 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 Cette version d’Analsys Services est intégrée
Services en Analysis Services 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.
Petit historique de la BI ——————————————————————————————————————————————————————————————————— 385
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 BO, Cognos, Microsoft, Microsotrategy

add-ins pour Excel et Oracle mettent à disposition des add-ins
pour le tableur Excel.
2004 Hyperion livre Essbase 7X Orienté applications marketing et financières.
2005 Microsoft livre sa suite inté- La suite SQL Server 2005 intègre un SGBD,
grale de business intelligence le datawarehouse, l’ETL, OLAPet le data mining
dans SQL Server 2005 avec Analysis Services, le reporting avec
Reporting Services.
Si SQL Server 2005 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
Le marché mondial
de la BI aujourd’hui
L’observatoire indépendant de l’OLAP publie chaque année l’état du marché de

l’OLAP et les tendances. Il est possible de consulter les résultats de cette étude
sur le site www.olapreport.com.
Le graphe de la figure B.1 représente les parts de marché de l’OLAP ainsi que
les tendances des dix acteurs majeurs mondiaux.
Figure B.1 — Le marché mondial de l’OLAP a progressé de 15,7 % en 2005

Le marché mondial de la BI aujourd’hui ————————————————————————————————————————————————————— 387
On observe la percée de Microsoft depuis la sortie de SQL Server 2000

incluant la brique Analysis Services. De nombreuses sociétés ont fait l’acquisition
de SQL Server 2000 dans le but de déployer uniquement la partie décisionnelle
(Analysis Services). Le taux de progression de la plate-forme Microsoft est supé-
rieur à la moyenne du marché. On peut penser que la courbe de pénétration du
marché devrait repartir en 2006 du fait de l’arrivée de SQL Server 2005 (8 nov.
2005) incluant une plate-forme décisionnelle complète.
État du marché mondial de l’OLAP en 2005
Tableau B.1 — Les 10 leaders OLAP en 2005
Évolution
Rang % de parts
Éditeur sur année
sur le marché de marché
précédente
Microsoft ecosystem 1 ➚ 28,0 %
Hyperion Solutions 2 ➘ 19,3 %

incluant Brio Tech
Cognos (incluant Adaytum) 3 ➘ 14,0 %
Business Objects (incluant Crystal 4 ➚ 7,4 %

Décisions)
Microstrategy 5 ➚ 7,3 %
SAP (BW) 6 ➘ 5,9 %
Cartesis 7 ➚ 3,8 %
Systems Union 8 ➚ 3,4 %
Oracle 9 ➘ 3,4 %
Applix 10 ➚ 3,2 %
Le tableau ci-dessus montre la répartition des parts du marché mondial de

l’OLAP avec l’évolution entre 2004 et 2005.
La dynamique du marché français des solutions décisionnelles

Aujourd’hui les éditeurs d’ERP ont l’ambition affirmée d’étendre les fonction-
nalités de leurs applications transactionnelles disposant déjà d’un embryon de repor-
ting vers les applications analytiques décisionnelles (tableaux de bord, balanced
scorecard, KPI, etc.).
388 ——————————————————————————————————————————————————— B. Le marché mondial de la BI aujourd’hui
• ETL
CRM
• Data Mining
40%
• Reporting
Décisionnel • Applications analytiques
Décisionnel 30% ERP 670 M€
ERP 20% ERP

452 M€
Décisionnel
CRM 10%
Logiciel global
Logiciel global 0% 392 M€
Sécurité
-10%
2000 2001 2002 2003
197 M€
Décisionnel 32,0% 27,6% 7,2% 8,4% CRM
ERP 15,8% 9,9% 3,5% 2,0%
CRM 117,7% 6,8% -4,6% -4,1%
Logiciel global 11,6% 8% -1,1% 0,6% 0 200 400 600
Figure B.2 — Le décisionnel représente

le marché le plus dynamique
de l’informatique (source : IDC)
Microsoft (Excel, Proclarity, SSRS)

BO (Crystal), Cognos, Panorama, Hyperion (Brio),
Temtec
Analyse multidimensionnelle
Microsoft, Hyperion,
SAS, SPSS, KXEN, Microsoft
Microstrategy
Oracle, IBM Data Mining
OLAP Informatique
Décisionnelle
Ascential, Informatica, Sunopsis Office 2007, BSM, Panorama
Oracle, Microsoft, IBM, Cognos, BO
Hummingbird, SAS KPI
ETL
IBM, Oracle, Microsoft
SGBD/R
Figure B.3 — Panorama des éditeurs

de solutions décisionnelles
Le marché mondial de la BI aujourd’hui ————————————————————————————————————————————————————— 389
Tableau B.2 — Liste des éditeurs qui offrent des solutions décisionnelles
Éditeur SGBD/R Moteur OLAP ETL Restitution
Actuate Nimble Actuate 7

Technology e-Analysis
Actuate Query
Ascential (IBM) DB2 DB2 OLAP DataStage

Server (Moteur
OLAP
d’Hyperion)
Business Business Data Enterprise

Objects Integrator 6 Crystal
Decisions
Cognos PowerCube Decision Serie 8

Stream Impromptu
(requêtage)
Powerplay
(analyse ad hoc)
Reportnet
(rapports web)
Informatica PowerCenter Analytics

PowerExchange PowerAnalyser
Information Iway
Builders
Hummingbird Desktop OLAP Genio BI Suite
Hyperion Essbase Brio

Performance
suite 8
Microstrategy Moteur ROLAP Microstrategy 7

(reporting
masse, ad hoc,
analyses multi
dim)
Microsoft SQL Server OLAP Integration Excel, office

2005 (Analysis Services 2007, Reporting
Services services,
et UDM) Proclarity
Oracle Oracle Oracle 10 i R2 Oracle BI Applications

OLAP Warehouse analytiques
Datawarehouse (OFA, OSA)
builder
390 ——————————————————————————————————————————————————— B. Le marché mondial de la BI aujourd’hui
Éditeur SGBD/R Moteur OLAP ETL Restitution
SAS ETL SAS activity-

based
Management
Sybase IQ (moteur
SQL optimisé
pour le
décisionnel)
Sunopsis Sunopsis v3.2
Pourquoi Microsoft est-il entré sur le marché de l’OLAP ?

Microsoft observe constamment les nouveaux marchés à forte capacité de crois-
sance. Plusieurs facteurs ont guidé son choix avant d’entrer sur le marché OLAP.
• La taille : Les marchés inférieurs à 1 M$ ne sont pas de nature à attirer
l’attention de Microsoft.
• Le taux de croissance : Microsoft s’intéresse à des marchés présentant un
fort taux de croissance.
• Les volumes : Microsoft vend des produits standard dans de très grands
volumes, à des prix bas et faciles à déployer.
• La synergie avec ses produits existants : renforcer la domination de Windows
et Office est un objectif connu de Microsoft. Les technologies OLAP de
SQL Server 2005 trouveront un écho avec Excel et en particulier la ver-
sion 2007.
• Il n’existe pas de compétiteur dominant : Hyperion, Cognos et Business Objects
se partageaient le marché depuis le début des années quatre-vingt-dix.
Aucun d’entre eux n’avait la capacité à freiner les ardeurs de Microsoft.
En 1996, le marché de l’OLAP présentait toutes les conditions requises pour

une arrivée de Microsoft sur ce marché, aux côtés d’Oracle, Informix, Seagate
et IBM.
Le positionnement de Microsoft avec SQL Server 2005 (version Enterprise)
est de couvrir l’ensemble des domaines de l’informatique décisionnelle (SGBD,
ETL, reporting, analyse, data mining). Selon un principe qui lui a bien réussi
dans le domaine de la bureautique avec Word et Excel, Microsoft souhaite impo-
ser un standard des bases de données en incluant dès maintenant une offre déci-
sionnelle complète.
Parallèlement à cette percée de la BI, les grands éditeurs d’ERP ont la ferme
intention d’étendre les fonctionnalités de leurs applications transactionnelles
disposant déjà d’un embryon de reporting vers les applications analytiques déci-
sionnelles (tableaux de bord, analyses ad hoc, balanced scorecard, KPI, etc.).
C
Les différentes versions
de SQL Server 2005
Express Workgroup Standard Enterprise

Adaptée aux La base de données La plate-forme complète La plate-forme intégrée
pour les petites entités pour la gestion et pour la gestion et
développeurs pour
et les activités en l’analyse des données l’analyse de données
apprendre, construire
et déployer croissance destinée aux entités des applications critiques
moyennes à grandes de l’entreprise
1 Proc 2 Proc 4 Proc Pas de limitation +

1 Go mémoire 3 Go mémoire versions 32 & 64-bit Partitionnement
4 Go base
Outil d’administration Miroir de BD limité Miroir BD complet &
Outil d’administration Management Studio Cluster 8 nœuds
simplifié Cluster 2 noeuds
SQL Agent Opérations en ligne
Sécurité intégrée Integration Services
et redémarrage
Assistant (ETL) rapide
Support XML & d’optimisation
Améliorations T-SQL Analysis Services Clichés BD
Recherche en (Serveur OLAP)
Intégration .Net & CLR texte intégral Outils avancés
Data Mining (ETL, OLAP et Data
Serveur de rapports Serveur de Mining)
Réplication limité Réplication complète
Import/Export
Transfert journaux Serveurs de
Client Réplication Notification Services rapports multiples
(Log shipping)
Gratuit
Figure C.1 — Comparaison des versions de SQL Server 2005
La version Express Manager

Cette version remplace MSDE. Il s’agit d’une version allégée de la version
Workgroup. Cette version gratuite dispose maintenant d’un outil d’administra-
tion (Express Manager) :
• Pas de haute disponibilité.
392 ——————————————————————————————————————————————— C. Les différentes versions de SQL Server 2005
• Pas de décisionnel (ni KPI, ni Olap UDM).

• Pas d’ETL (Integration Services).
• Pas de recherche en texte ni d’agent SQL.
• Pas de Notification Services.
• Pas de réplication Oracle.
• Réplication SQL Server limitée.
• Reporting très limité.
Version SQL server Workgroup

Cette version est destinée aux applications départementales. Elle dispose de
recherche en texte intégral et de l’agent SQL. L’outil d’administration est Mana-
gement Studio doté d’un assistant de paramétrage de la base de données.
Limitations :
• reporting limité.
• limité à 2 processeurs.
• limité à 3 Go de mémoire.
Exclusions :
• pas de haute disponibilité.

• pas de décisionnel ni KPI, ni UDM.
• pas de réplication Oracle.
• pas de 64 bits.
Édition standard
Cette édition dispose des fonctionnalités de data mining :
• Réplication SQL Server.

• Décisionnel (KPI et UDM). Sauf Perspectives et mesures semi-additives.
• Outil d’administration complet (Management studio).
Limitations :
• la haute disponibilité est limitée à deux nœuds pour les clusters.

• ETL simplifié (import/export, et transformations de base).
• limité à 4 processeurs.
Les différentes versions de SQL Server 2005 ————————————————————————————————————————————————— 393
Exclusions :
• pas de réplication Oracle.
• pas de partitionnement des tables.
• pas de cache pro-actif.
• pas d’opérations on-line.
• pas de partitionnement des cubes OLAP.
Édition Enterprise
• Haute disponibilité illimitée.
• ETL complet.
• Data mining (dix algorithmes).
• Réplication Oracle.
• Replication SQL Server.
• Décisionnel illimité.
• Très haute performance (93 000 utilisateurs SAP concurrents).
D
Les profils d’apprentissage
des différents acteurs
de la BI
Le parcours d’apprentissage peut être suivi selon un axe métier IT (Information

Technology) ou selon un axe outils. Dans le parcours présenté ci-dessous, nous
parcourrons les compétences à acquérir par module outil puis dans chaque outil
nous présenterons les profils IT. Ces profils se décomposent en quatre catégories :
• utilisateur professionnel;
• administrateur;
• développeur;
• architecte.
Parcours d’apprentissage pour SQL Server Integration Services (SSIS)

Parcours d’auto-formation pour le profil Utilisateur professionnel SSIS
Un travailleur du savoir remplit le rôle traditionnel d’expert dans le domaine de
l’aide à la décision : c’est un acteur qui comprend les données métier et est capa-
ble de traduire ces données en informations utiles pour l’entreprise. Souvent, le
travailleur du savoir est celui qui analyse l’activité de l’entreprise pour identifier
les problèmes, les opportunités et les caractéristiques du projet.
Dans cette catégorie, on trouve des fonctions telles que :
• analyste d’entreprise;
396 ———————————————————————————————————— D. Les profils d’apprentissage des différents acteurs de la BI
• formateur technique;
• chargé de l’assistance technique et des opérations;
• administrateur réseau.
Tableau D.1 — Parcours de formation pour le profil Utilisateur professionnel SSIS
Thèmes abordés
pour l’utilisateur Parcours d’apprentissage
professionnel SSIS
Améliorations version 2005 Stocke, traite et sécurise les données
Présentation des packages Packages Integration Services

Éléments de flux de contrôle
Composants des flux de données
Objets et concepts d’Integration Services
Création de packages Création de solutions de projets IS

Création de packages dans le concepteur SSIS
Création de packages à l’aide de l’assistant
Import et Export
Ajout de fonctionnalités Journalisation dans les packages

aux packages SSIS Utilisation des expressions de propriétés
des packages
Utilisation des variables dans les packages
Création de configuration de base
Points d’arrêt dans les packages
Incorporation des transactions dans les packages
Dépannage des packages Débogage du flux de contrôle

Débogage d’un flux de données
Déploiement des packages Déploiement des packages SSIS
Parcours d’auto-formation pour le profil Administrateur d’Integration

Services
Un administrateur gère et optimise les solutions et les projets au niveau opéra-
tionnel. Il peut se voir attribuer différentes fonctions telles que :

• administrateur de serveur de rapports (informatique d’entreprise);
• administrateur d’entrepôts de données.
Les profils d’apprentissage des différents acteurs de la BI —————————————————————————————————————— 397
Tableau D.2 — Parcours de formation pour le profil Administrateur de SSIS
Thèmes abordés
pour l’administrateur Parcours d’apprentissage
professionnel SSIS
SSIS Améliorations apportées à SSIS
Notion de packages SSIS
Migration Compatibilité descendante de SSIS
des versions antérieures Migration des packages DTS
des packages DTS Utilisation de l’assistant Migration de package
Enregistrement Enregistrement des packages
et exécution de packages Sauvegarde et restauration des packages
Exécution des packages
Planification de l’exécution d’un package dans l’Agent
SQL Server
Utilisation des points d’arrêt dans les packages
Contrôle de l’exécution Service Integration Services
des packages Analyse des performances et de l’activité de SSIS
Déploiement des packages Création de configuration de package
Création d’un utilitaire de déploiement
Installation des packages
Redéploiement des packages
Parcours d’auto-formation pour le profil Développeur Integration Services

Un développeur conçoit et implémente des solutions suivant la technologie pré-
conisée par l’architecte SSIS, l’assistance opérationnelle de l’administrateur SSIS
et les commentaires de l’utilisateur final de SSIS. Le développeur SSIS peut revê-
tir les fonctions suivantes :
• développeur d’applications;
• développeur de rapports;
• développeur ETL;
• programmeur datawarehouse;
• programmeur de base de données;
• modélisateur de données.
Tableau D.3 — Parcours de formation pour le profil Développeur de SSIS
Thèmes abordés pour

Parcours d’apprentissage
le développeur SSIS
Programmation SSIS Integration Services Programming
Extension des packages grâce aux tâches de script

le développeur SSIS
Programmation des flux Construction de packages par programmation
de contrôle Survol du développement de tâches personnalisées
Programmation de flux Programmer les flux de données
de données Composants personnalisés
Propriétés des flux de données
Extension des packages Création et utilisation des variables de packages
avec des fonctionnalités Programmation de la gestion des événements dans SSIS
avancées Programmation du loging
Documentation Guide de référence de Transact-SQL
de référence sur le langage Information de référence des expressions SSIS
SQL Server Référence du langage MDX (accès OLAP)
Guide de référence du langage DMX (data mining)
XMLA (XML pour Analysis)
Exemples de Transformation d’agrégation et colonne dérivée
programmation Package d’exécution de processus
Utiliser le modèle SMO pour énumérer les tables
utilisateur
Exemple de source ADO
Composant de transformation
Composant de suppression de doublons
Parcours d’auto-formation pour le profil Architecte Integration Services

L’architecte choisit les technologies à utiliser pour l’implémentation d’une solu-
tion Integration Services. Il privilégie l’interaction et l’interopérabilité entre les
projets de l’entreprise. L’architecte assure une vision d’ensemble et une cohé-
rence des projets au sein d’une solution Integration Services. On retrouve des
fonctions telles que :
• architecte de datawarehouse;
• architecte des données d’entreprise.
Tableau D.4 — Parcours de formation pour le profil Architecte de SSIS
Thèmes abordés
pour l’Architecte SSIS
Composants SQL Server Moteur de base de données SQL Server
2005 SQL Server Analysis Services (SSAS)
SQL Server Reporting Services (SSRS)
SQL Server Notification Services
Service Broker
Thèmes abordés
pour l’Architecte SSIS
Utilisation d’Intégration Développement de solutions de business intelligence

services dans les solutions Conception et création de packages Integration
d’entreprise Services
Programmation de SSIS
Configuration système Éditions et composants de SQL Server 2005

requise SSIS et les ordinateurs 64 bits
Connaissance de la configuration matérielle
et logicielle requise pour l’installation
de SQL server 2005
Paramètre de l’outil d’analyse de configuration
système
Compatibilité descendante Compatibilité descendante de SSIS avec DTS 2000

Utilisation de plusieurs versions de SQL Server
(2000/2005)
Migration des packages DTS
Considération sur Manipulation de données multilingues

les implications d’un Paramètres régionaux Windows
déploiement international Incidence sur l’exploration de texte
et correspondance floue (fuzzy lookup)
dans un contexte multilingue
Parcours d’apprentissage pour SQL Server Analysis Services (SSAS)

Parcours d’auto-formation pour le profil Utilisateur professionnel SSAS
Tableau D.5 — Parcours de formation pour le profil Utilisateur Professionnel SSAS
Thèmes abordés
professionnel SSAS
Concepts Développement de solutions et projets Analysis

Services
Modèle dimensionnel unifié (UDM)
Concepts d’exploration de données (data mining)
Gestion Analysis Services Utilisation de OLAP

Utilisation de l’exploration de données
Traitement des objets Analysis Services (dimensions,
mesures, cubes, etc.)
Langages Référence au langage MDX (accès aux cubes OLAP)

Référence au langage DMX (data mining)
Thèmes abordés
professionnel SSAS
Outils Présentation de BIDS (business intelligence

Development Studio)
Présentation de SQL Server Management studio
Dépannage des packages Débogage du flux de contrôle

Débogage d’un flux de données
Déploiement des packages Déploiement packages SSIS
Parcours d’auto-formation pour le profil Administrateur SSAS
Tableau D.6 — Parcours de formation pour le profil Administrateur Professionnel SSAS

l’Administrateur SSAS
Concepts Les rôles SSAS (sécurité d’accès aux données)
Administration Mise à niveau ou migration d’Analysis Services

Traitement des objets Analysis Services via l’interface IHM
Traitement des objets Analysis Services à l’aide
de Integration Services
Analyse des performances de SSAS
Sauvegarde et restauration d’une base de données
Analysis Services
Sécurisation d’Analysis Services
Déploiement Utilisation de l’assistant de déploiement SSAS
Langages MDX
DMX
Outils Présentation de BIDS

Présentation de SQL Server Management Studio
Parcours d’auto-formation pour le profil Développeur SSAS
Tableau D.7 — Parcours de formation pour le profil Développeur SSAS

le Développeur SSAS
Concepts Architecture d’Analysis Services

Concept de SSAS
Assemblys SSAS afin d’étendre les fonctions
d’entreprise de MDX et DMX

le Développeur SSAS
Langages MDX
DMX
Programmation de l’accès Schema Rowsets

aux données XML for Analysis (XMLA) accès à toutes les sources
multidimensionnelles standard.
ADOMD.NET (accès à SSAS ou toutes bases
multidimensionnelles via TCP/IP ou HTTP)
Programmation Langage de script pour SSAS (ASSL)

de l’administration DSO pour gérer les objets Analysis services (serveurs,
sources de données, cubes, modèles de mining)
Parcours d’auto-formation pour le profil Architecte SSAS
Tableau D.8 — Parcours de formation pour le profil Architecte SSAS
Thèmes abordés
pour l’Architecte SSAS
Concepts Modèle dimensionnel unifié

Concept d’exploration de données
Planification Fonctionnalités prises en charge par les éditions SQL

Server 2005
Compatibilité descendante de SSAS
Mise à niveau ou migration d’Analysis Sevices
Considérations sur la localisation des applications
SSAS
Autres composants SSIS

SSRS
Moteur de base de données SQL Server
Parcours d’apprentissage pour SQL Server Reporting Services (SSRS)

Parcours d’auto-formation pour le profil utilisateur professionnel
de Reporting Services
Les utilisateurs de SSRS créent des rapports pour leurs propres besoins et, éven-
tuellement, pour d’autres personnes au sein de l’organisation. Un utilisateur pro-
fessionnel orienté reporting connaît les types de données gérés par l’organisation
et cherche à exploiter ces données pour réaliser d’autres tâches métier.
Souvent, l’utilisateur exécute des rapports pour analyser des données et iden-
tifier les opportunités métier. Il peut également collecter et distribuer des infor-
mations sur les processus et les ressources de l’organisation. Les tâches associées
au rôle d’utilisateur de reporting se retrouvent dans les fonctions suivantes :
• directeur commercial;
• assistant de direction;
• chef de projet.
Tableau D.9 — Parcours de formation pour le profil Utilisateur professionnel de SSRS
Thèmes abordés
pour l’utilisateur SSRS
Concepts de SSRS Présentation de Reporting services

Rapports et définitions de rapport
Recherche et affichage Démarrage du gestionnaire de rapports

des rapports Recherche de rapports sur le serveur de rapports
Affichage de rapports
Utilisation du dossier Mes Rapports
Exportation et Impression Exportation des rapports

des rapports Enregistrement des rapports
Impression d’un rapport
Création des rapports Création d’un rapport avec l’assistant

Lancer le générateur de rapports
Importation d’états à partir d’Access
Aperçu des rapports
Publication de rapports
Abonnements aux Vue d’ensemble des abonnements

rapports S’abonner à un rapport
Planification d’un abonnement
Parcours d’apprentissage pour le profil Analyste de Reporting Services

Les analystes d’entreprise créent des rapports et des modèles de données pour
leurs propres besoins ou pour d’autres personnes au sein de l’organisation. Un
analyste crée des rapports pour identifier les tendances, les opportunités, les pro-
blèmes d’un projet métier.
Les fonctions habituelles que l’on retrouve sont les suivantes :
• modélisateur de données;
• analyste de gestion;
• analyste financier;
• contrôleur de gestion;
• analyste commercial.
Tableau D.10 — Parcours de formation pour le profil Analyste de SSRS
Thèmes abordés
pour l’Analyste SSRS
Concepts de SSRS Présentation de Reporting Services

Rapports et définitions de rapport
Modèles de rapport
Méthodes de création de rapport
Utilisation des données dans SSRS
Région de données
Mise en page et rendu des rapports
Définition des données Connexion à une source de données

du rapport Récupération des données relationnelles à partir
d’une base SQL Server
Utilisation de paramètres dans un rapport
Filtrage de données
Expressions dans Reporting Services
Conception et publication Conception de la mise en page de rapport

des rapports Fonctionnalités interactives
Aperçu des rapports
Déploiement de rapports dans un environnement
de production
Conception de modèles Utilisation du générateur de modèles

de rapport Création d’un projet de modèle de rapport
Parcours d’apprentissage pour le profil Administrateur de SSRS

Un administrateur du serveur de rapports installe, configure, sécurise et gère le
déploiement d’un serveur de rapports. Un administrateur de SSRS doit avoir
une vision claire de la topologie du réseau et la configuration des ordinateurs
utilisés pour l’hébergement des composants SQL Server 2005 Reporting Services
et pour l’accès à ces derniers.
Les fonctions d’administration de SSRS sont les suivantes :

• administrateur du serveur de rapports (service informatique);
• administrateur principal de base de données.
Tableau D.11 — Parcours de formation pour le profil Administrateur de SSRS

l’Administrateur SSRS
Concepts de SSRS Serveur de rapports

Définition de rapports
Rapports liés
Captures instantanées de rapport
Espace de nom de dossier du serveur de rapports
Comptes dans un déploiement de SSRS
Configuration Liste de vérification pour le déploiement du serveur

Liste de vérification pour l déploiement de rapports
Configuration des composants de SSRS
Déploiement sur Internet
Sécurité Configuration de la sécurité du serveur de rapports

Utilisation de la sécurité basée sur les rôles
Administration du serveur Modification des mots de passe et des comptes

de services
Administration d’une base de données du serveur
de rapports
Gestion et utilisation des rapports publiés
E
Glossaire de la BI
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 cli-
quant sur une cellule du cube.
analyse de scénarios
Technique adoptée pour concevoir des scénarios à caractère commercial en met-
tant à 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 entre-
tenir 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.
406 —————————————————————————————————————————————————————————————————————— E. Glossaire de la BI
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 don-
né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 traitant 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 fonc-
tion 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éa-
lisé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 concer-
né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 mul-
tidimensionnelle (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).
Glossaire de la BI ———————————————————————————————————————————————————————————————————————— 407
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 don-
né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 performances 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.
cube
Ensemble de données organisées et synthétisées dans une structure multidimen-
sionnelle définie par un ensemble de dimensions et de mesures. Dans le cas de
nombreuses dimensions, on parle d’« hypercube »). Bien qu’un hypercube com-
porte 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 éga-
lement 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, mar-
keting, 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’entreprise. 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 concer-
nent. Les datamarts simplifient également le travail des services informatiques
en leur permettant de gérer pour chaque communauté d’utilisateurs des ensem-
bles 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éla-
tions 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 faci-
liter 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, quel
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 reporting et l’analyse
sont des outils décisionnels typiques. L’analyse décisionnelle aide la prise de déci-
sions 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 com-
posée des niveaux Année, Trimestre, Mois et Jour, Janvier est un descendant de
2005. 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 sou-
haitent fonder une analyse. Par exemple, une dimension géographique peut
inclure des niveaux Pays, Région, Département et Ville. Voir aussi table de faits,
mesure, niveau.
dimension de temps
Dimension divisant le temps en niveaux, tels que 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 multidimension-
nelle 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 rapportant à la zone cliquée. Cette fonctionna-
lité 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 donné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 dis-
ponibles 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’entre-
prise. Que ce soit des applications horizontales (comptabilité, paie, facturation, ges-
tion des ressources humaines) ou verticales (gestion de production, gestion de stocks
par secteur d’activité). Les ERP se dotent progressivement de fonctions décision-
nelles 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 mani-
puler des données multidimensionnelles.
extraction
Action d’extraire des données détaillées à partir desquelles les données d’une cel-
lule 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 simplifier 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 exem-
ple, dans une dimension de temps dotée des niveaux Année et Mois, les membres
Janvier 2005 et Février 2005 sont des frères. Voir aussi enfant, descendant, parent.
frère (membre)
Dans une structure arborescente, élément sans éléments subordonnés. Par exem-
ple, 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 dimen-
sion. 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 maga-
sin 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 restitution de données multidimension-
nelles.
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, 2004 et 2005 sont les mem-
bres 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 flocon 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épendantes.
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.
niveau hiérarchique
Au sein d’une hiérarchie, les positions sont en général organisé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 multidimensionnelles pour offrir un accès
rapide aux données en vue d’une analyse. Les données source OLAP sont sou-
vent 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 relation-
nelle. 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 acti-
vité 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 inversement.
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 pro-
pres à 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 exem-
ple, (Boston, [1995]) est un tuple composé de membres de deux dimensions : Géo-
graphie 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.
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 consom-
mation des clients, et en particulier sur du marketing one-to-one et des outils CRM.
Index
A B
Accès au détail (drillthrough) 249 Balanced scorecard 34, 64, 390
Action 13, 211, 249 Bâle 2 22
ActiveX 344 Base de données multidimensionnelle 181
Add-in Excel 368 BIDS 108
BO 62
Agent SQL Server 106
Briefing book 352
Agrégations 251 BSC 34
paramétrer les – 256 Business intelligence 3, 11, 33, 245
Alimentation 13 Business Objects 377
Analyse 188 Business Performance Management 369
ad hoc 181, 332, 390 Business Scorecard Management 67
de cube 341 Business Scorecard Manager 347
de données avec Excel 331 intégré 62
de séquence 264
C
Analysis Services 179
Approche itérative 361 Cache proactif 96, 98, 183, 190
Arbre de décomposition 84, 348 Calcul 188, 211, 244
ASCII 304 Capture instantanée 320
Assistant Carte de performance 85, 350
Cellule feuille 241
d’exportation 146
Checkpoint 46
d’importation 146
Classification 262
Association 263 Clé
Attribut 186 étrangère 222
lié 237 principale 222
Attrition 24 CLR (Common Langage Runtime) 183
418 —————————————————————————————————————————————————— Business Intelligence avec SQL Server 2005
Clusters 270, 283 Dimension 181, 182, 186, 193, 194, 196,
Cockpit 11 197, 211, 232
de pilotage 373 à multiples hiérarchies 96
Codd Edgar 8 à variation lente (Slowly changing dimen-
Cognos 377 sions) 48, 96, 135
Collecte de données 13 attributs 235
Comportement semi-additif 246 de data mining 187
Concepteur de rapport 293 de fait 187
Configuration 171, 174 de référence 187
Conteneur hiérarchie 221
de boucle intelligence 246
parent-enfant 96
For 118
plusieurs à plusieurs 187
Foreach 114
propriétés 234
de séquences 118
structure 238
Conversion monétaire 246
temporelle 47
Cookies 20
utilisation 242
CPM (Corporate Performance Management)
Dimensionnel 45
378
DMX (Data Mining Extensions) 119
CRM 19
Domaine
Cross-sell 20
analytique 9
Crystal 62
transactionnel 9
CSV 304
Donnée catégorielle 76
Cube 97, 211, 240
Drill down 48, 83, 181, 220, 301, 305, 324
déploiement 194
Drill up 181, 220, 305
local 337
DTS 2000 112
multidimensionnel 179
OLAP 181 E
Cycle en V 30
Échelle
D nominale 76
ordinale 76
Dashboard Server 358 Écriture différée 246
Data mining 180, 181, 259 EIS (Executive Information System) 25
Datamart 94, 104 Enjeux du décisionnel 7
Dataset 294, 307 Entrepôt de données 104
Datawarehouse 17, 45, 94 ERP 9, 46, 96
Date Chris 8 Espace d’analyse 13
Décision ETL (Extract, Transform, and Load) 46, 181
stratégique 68 d’entreprise 369
tactique 68 Étude de faisabilité 32
Decision tree 270, 283 Excel 377
Dénormalisation 105 2007 343
Destination 130 Explorateur de Package 110
Développement linéaire 361 Exploration vers le bas 301
Index ——————————————————————————————————————————————————————————————————————————————————— 419
F J
FASMI 56 Journal des audits 184
Fichier plat 132 Juste à temps 22
Filtre 219
Flux K
de contrôle 104, 108 Kaplan Robert 34, 373
de données 104, 109, 130 Key Users 62
Fonction lookup 105 Kimball Ralph 47, 94, 177, 380
Fouille de données 62 KPI (Key Performance Indicator) 24, 47, 62,
FrontPage 344 80, 183, 211, 246, 390
FTP 107
Fuzzy lookup 65 L
G Loi SOX 46
LOLF 21
Gestion Lot 104
des rapports 308
du risque 22 M
Gestionnaire
Mapping 134
d’événements 109
MapPoint 369
de rapports 293
MDX
Graphique croisé dynamique 337
requête 300
GRC 19
script 183, 188
Groupe de mesures 187, 240
Membre
calculé 245
H inféré 136
HOLAP (Hybride OLAP) 252 non-feuille 241
HTML 304 Mesure 50, 181, 193, 197
Hyperion 377 calculée 244
semi-additive 230
I Metadata 183
Microsoft Access 373
Indicateur Microsoft Clustering 272
clé de performance 24, 189 Microsoft Decision Trees 270
de performance 64 Microsoft Naïve Bayes 272
externe 13 Migration de lots DTS 163
Infocentres 25 Modèle
Informatique décisionnelle 3 Clusters 280
Inmon Bill 380 d’autorisations 184
Integration Services (SSIS) 101 de données entité-relation 49
Intellicube 193 de rapports 294
Intelligence comptable 245 Decision Tree 275
Intervalle dimensionnel 49
de latence 191 multidimensionnel 183
de reconstruction forcée 191 Naïve Bayes 278
IRR 365 relationnel 183
Modélisation 60 PDF 304

MOLAP (Multidimensional OLAP) 252 Performances 184
MS Access 345 Période
MS Excel 345 de latence 191
MS Query 339 silencieuse 191
Perspective 97, 187, 212, 249
N PGI 9, 46
PivotTable 332
Naïve Bayes 270, 283
Plan 127
Navigateur 212, 225, 239
Planification 320
de données 250
Planning 21
Navigation
POC (proof of concept) 374
en mode web 356
Powerplay 62, 377
Professional 355
Procédure stockée 183, 189
standard 355
Processus 196
Niveaux d’abstraction 10
d’apprentissage 11
Norton David 34, 373
de décision 7
Notification Services 98
Proclarity 67, 84, 347, 348
NPV 365
for Business Scorecard 348
Professional 357
O
Productivité 21
Office Profils d’apprentissage 395
2007 67 Projet décisionnel 374
Excel pour SSAS 332, 340 Prototype 375
PerformancePoint 369 Pull 190
Web Components 368 Push 190
OLAP (On line Analytical Processing) 8, 55,
56, 57, 180, 230 R
OLTP (On Line Transactional Processing) 45,
Rapport
46, 49, 53, 56, 181
abonnement 323
Opérateur unaire 246
clichés d’historique 321
OWC (Office Web Components) 332, 344,
exécution 318
347
historisation 321
lié 318
P
matriciel 297
Package 104 tabulaire 297
automatisation de l’exécution 169 RDL 373
déploiement 167 Recherche
dynamique 171 exacte 105
enfant 123 floue 105
parent 123 Référentiel 60
Panorama software 67 métier 10
Paramètres 306 Région de données 294
Partition 211 Régression 262
Partitionnement multiple 254 Relation
PAS (Proclarity Analytics Server) 351 d’écart ou de déviation 79
Index ——————————————————————————————————————————————————————————————————————————————————— 421
de comparaison nominale 82 Standard 391, 392

de corrélation 82 Workgroup 391, 392
de distribution 81 SQL Server Agent 169
Report Builder 64, 294, 324, 373 SQLiMail 128
Reporting 15, 26, 47, 57 SSAS 229
financier 21 SSIS 92
interactif 344 SSRB 324
Reporting Services 67, 289 SSRS 291
droits 310 Stratégie 13
rôles 312
tâches 310 T
Réseau de dépendance 277
Table
Retour sur investissement 365
de dimensions 50
ROI 365
de faits 50
ROLAP (Relational Olap) 252, 254
Tableau
Rôle 184, 187, 309
croisé dynamique 64, 182, 332
administrateur système 314
de bord 11, 13, 25, 64
utilisateur système 314
Tâche
Rollback 46
d’exécution
Roll-up 181
de Package 123
DTS 2000 123
S
de processus 124
SAP NetWeaver business intelligence 99 de requêtes SQL 124
Sarbane-Oxley 22 d’insertion en bloc 125
Scénario 68 DDL 119
Schéma de flux de données 119
en étoile 49 de script 120
en flocons 198 de service Web 122
Sécurité 309 de système de fichiers 122
Segmentation 263 de traitement Analysis Services 122
Serveur de rapports (Report server) 293 de transfert
Services de notification 99 d’objets SQL Server 123
SharePoint Portal 62, 67, 369 de base de données 122
SMDL (Semantic Model Definition Language) de connexions 122
325 de messages d’erreur 122
SMTP 323 de procédures stockées 123
Sniffing 184 de travaux 126
Solution décisionnelle 368 Envoyer un message 125
Solver 68 FTP 126
Source 129 Lecteur de données WMI 126
de données 193, 199 MSMQ 126
Spoofing 184 observateur d’événements WMI 126
SQL Server 2005 XML 127
Enterprise 391, 393 TIFF 304
Express 391 Time Intelligence 245
Express Manager 391 Traçabilité 184
Traduction 212, 238, 250 Vue

Traitement incrémentiel 257 des sources de données (Data Source
Transformation 129 Views, DSV) 96, 193
Translation 183 en perspective 86, 351
U W
UDM (Unified Dimensional Model) 64, 93, Webpart 248
94, 96, 97, 183, 191, 343 Workflow 107
Up-sell 20 Writeback 183
V X
Visual Studio 373 XML 92, 304
050536 – (I) – (1,5) – OSB 100° – SCM – API
Achevé d’imprimer sur les presses de

SNEL Grafics sa
Z.I. des Hauts-Sarts - Zone 3
Rue Fond des Fourches 21 – B-4041 Vottem (Herstal)
Tél +32(0)4 344 65 60 - Fax +32(0)4 289 99 61
décembre 2006 – 40711
Dépôt légal: janvier 2007

Imprimé en Belgique
INFOPRO
B. BURQUIER
BUSINESS
APPLICATIONS & MÉTIERS

TYPE D’OUVRAGE
RETOURS
L'ESSENTIEL SE FORMER
D'EXPÉRIENCE
Bertrand Burquier
MANAGEMENT DES SYSTÈMES
D'INFORMATION
APPLICATIONS
MÉTIERS
INTELLIGENCE
AVEC
ÉTUDES, DÉVELOPPEMENT,
INTÉGRATION
BUSINESS INTELLIGENCE
EXPLOITATION
BUSINESS INTELLIGENCE ET ADMINISTRATION
RÉSEAUX
SQL SERVER 2005

& TÉLÉCOMS
Mise en œuvre d'un projet décisionnel
Ce livre s’adresse aux directeurs informatiques, administratifs, BERTRAND BURQUIER

est consultant et ingénieur
financiers et opérationnels, ainsi qu’à tout responsable informatique
ayant à mettre en œuvre des systèmes décisionnels. Il intéressera
en systèmes d’information,
spécialisé dans la Business Mise en œuvre
Intelligence. Il dirige depuis
aussi les consultants et les architectes en systèmes d’information.
On assiste aujourd'hui à une démocratisation de l'informatique
1985 le cabinet de conseil
BuroFormatic. Il est
d'un projet décisionnel
également formateur en
décisionnelle. Chaque décideur qui le souhaite peut désormais entreprise et enseigne la
Business Intelligence à
disposer de puissants outils d'analyse, de reporting ou de data l’Institut de management de
mining. l’université de Savoie.
Cet ouvrage donne un cadre méthodologique à la mise en œuvre

d’un projet décisionnel complet, en s’appuyant sur les nouvelles
fonctions de Business Intelligence offertes par SQL Server 2005.
Après avoir passé en revue les principes fondamentaux qui président
à la réalisation d’un projet décisionnel, il identifie les pièges à
éviter et les facteurs clés de succès. Il montre ensuite comment
une solution de Business Intelligence peut analyser les
renseignements stratégiques de l'entreprise, quels sont les différents
indicateurs disponibles, et comment les interpréter pour définir
des cibles, des prévisions ou des tendances.
Des cas concrets expliquent comment mettre en œuvre la Business
Intelligence dans l’entreprise avec SQL Server 2005.
De nombreuses ressources complémentaires sont disponibles sur
le site www.buroformatic.com. Bertrand Burquier
6639389
ISBN 978-2-10-050536-4 www.dunod.com

Business Intelligence Avec SQL Server 2005 PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Business Intelligence Avec SQL Server 2005 PDF

Transféré par

Droits d'auteur :

Formats disponibles

INFOPRO

APPLICATIONS & MÉTIERS

BUSINESS INTELLIGENCE ET ADMINISTRATION

SQL SERVER 2005

Ce livre s’adresse aux directeurs informatiques, administratifs, BERTRAND BURQUIER

Cet ouvrage donne un cadre méthodologique à la mise en œuvre

Toutes les marques citées dans cet ouvrage sont des

Photographie de couverture : Bertrand Burquier

© Dunod, Paris, 2007

Chapitre 1 – La business intelligence . . . . . . . . . . . . . . . . . . . . . . 5

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

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

3.2 Les nouveaux outils offerts par le complément Proclarity . . . . . . . . . 84

6.2 Concept de packages dynamiques . . . . . . . . . . . . . . . . . . . . . . 171

Chapitre 7 – Analysis Services . . . . . . . . . . . . . . . . . . . . . . . . . . 179

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

8.2 L’organisation physique du cube . . . . . . . . . . . . . . . . . . . . . . 250

10.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329

13.4.3 Livrables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375

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

Bien longtemps, l’informatique décisionnelle a été réservée à des secteurs d’acti-

Cependant, la complexité de mise en œuvre du datawarehouse et la création des

Les consultants, architectes et urbanistes en systèmes d’information, assistants à

1.1 LA BUSINESS INTELLIGENCE

Aide à la décision, datawarehouses, entrepôts de données, ETL, EIS, SIAD, struc-

Toute interrogation métier, selon qu’elle est stratégique ou tactique, nécessite

1.2 OBJECTIFS ET ENJEUX DU DÉCISIONNEL

L’objectif d’un système décisionnel est de :

Les moyens pour y parvenir sont :

• une information riche, pertinente, détaillée, historisée, fiable;

Le cycle du projet comprend plusieurs étapes :

• Sélectionner les axes de progrès.

1.3 LE PROCESSUS DE DÉCISION OU LE FACTEUR

Dans un contexte d’inflation des données d’entreprises, plusieurs technologies

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

• « Nous apportons aux utilisateurs ce qu’ils demandent mais ces derniers ne

Ces commentaires suggèrent que les technologies actuelles sont inadéquates

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

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

Les niveaux d’abstraction

Le bon niveau d’abstraction de manipulation des données est fondamental

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

Quel parallèle avec la business intelligence ?

L’atterrissage est maintenant proche, le pilote s’apprête à agir sur la trajectoire

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 ?

Interrogeons-nous un instant : Une chaîne de supermarché a-t-elle pour objet

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

L’entreprise sera en mesure de montrer comment la valeur d’actif des données

La valeur « temps » des données

L’information en tant que ressource partageable

Cette formule est empruntée à une réflexion de Bob Metcalfe, l’inventeur de

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

L’analyse de la productivité du capital humain