Systèmes d'information d'aide à la décision (SIAD)

Introduction aux Systèmes d'Information et au Décisionnel

Ce document explore les systèmes d'information (SI) et plus particulièrement les Systèmes d'Information d'Aide à la Décision (SIAD), leur classification, leur construction et les technologies associées, dans le cadre de l'année académique 2025-2026 sous la direction de M. WOAMEY.

1. Définitions Fondamentales

Un système est un ensemble d'éléments matériels ou immatériels en interaction dynamique, unis par des relations. Ces relations transforment des entrées en sorties dans le but d'atteindre un objectif. Il peut être subdivisé en sous-systèmes.

• Dans une organisation, on distingue :
  • Le système opérant (ou opérationnel/de production) : exécute les décisions et effectue la transformation.
  • Le système de pilotage (ou de décision) : guide l'organisation vers ses objectifs, planifie, gère et contrôle.

L'accroissement des informations échangées entre ces deux systèmes a donné naissance au besoin d'un système d'information.

1.1. Information

Une information est un élément qui enrichit la connaissance sur une personne, un objet, ou un événement. C'est un fait perçu qui possède une signification. Elle est essentielle au processus de décision et doit être pertinente, cohérente et rentable. Une donnée ne devient information que lorsqu'elle est contextualisée.

• Exemples : Nom d'une personne, couleur d'une voiture, date d'un événement.

1.2. Système d'Information (SI)

Selon Robert REIX, un système d'information est un ensemble de ressources (humaines, matérielles, logicielles, procédures) organisées pour acquérir, traiter, stocker et diffuser l'information au sein d'une organisation.

• Types de SI selon leur finalité :
  • Supports d'opérations : traitement de transactions, contrôle de processus industriels, support de bureau et communication.
  • Supports de gestion : aide à la production de rapports, aide à la décision (SIAD).

2. Classification des Systèmes d'Information

Les SI sont classés selon les utilisateurs cibles ou les fonctions de l'entreprise.

2.1. L'Informatique Transactionnelle

Elle soutient l'exploitation de l'entreprise en enregistrant et traitant les données créées par les transactions.

• Applications spécifiques : systèmes de paie, gestion des commandes.
• Progiciels :
  • CRM (Customer Relationship Management) : Gestion de la relation client.
  • SCM (Supply Chain Management) : Gestion de la chaîne logistique.
  • HRM (Human Resource Management) : Gestion des ressources humaines.
• Échange de Données Informatisé (EDI) : Solution permettant l'échange de données entre organisations, accélérant les transactions inter-entreprises.
• Workflow : Automatisation des flux d'information et des circuits de traitement.
• Gestion Électronique des Documents (GED) : Système d'organisation et d'archivage numérique des documents (accès, stockage, gestion).

2.2. L'Informatique de Pilotage

Elle fournit des outils de synthèse et d'analyse pour le pilotage et le contrôle des activités.

• Business Intelligence (BI) ou Informatique Décisionnelle : Processus de collecte, d'analyse et d'utilisation de données pour améliorer les performances. Regroupe divers outils, applications et méthodologies pour l'analyse des données, la création de rapports et tableaux de bord.
• Systèmes d'Information Stratégique (SIS) : Soutiennent la stratégie d'entreprise, destinés à la direction. Conçus pour créer des tableaux de bord et graphiques comparant des données sur le temps et l'espace.

2.3. La Transversalité : ERP (Enterprise Resource Planning)

Un ERP (ou PGI) intègre tous les systèmes informatisés pour soutenir le fonctionnement de l'entreprise, couvrant l'ensemble des services (production, gestion commerciale, GRH, comptabilité, décisionnel). L'intérêt principal est l'uniformisation et la dématérialisation des informations.

3. Du Transactionnel au Décisionnel

3.1. Naissance de l'Informatique Décisionnelle

Introduite par E.F. Codd en 1970 avec les SGBDR pour les systèmes transactionnels (OLTP - OnLine Transaction Processing). En 1993, Codd formalise l'OLAP (OnLine Analytical Processing), base de l'informatique décisionnelle. Un SIAD vise à exploiter les données opérationnelles pour faciliter la prise de décision.

3.2. Activités des Systèmes Transactionnels (OLTP)

• Orientés vers la saisie, le stockage, la mise à jour, la sécurité et l'intégrité des données.
• Gèrent les transactions quotidiennes (ex : inventaires, réservations).
• Contiennent des données actuelles très détaillées, sans archives.
• Mises à jour par de nouvelles transactions.
• Opérations courantes : ajout, suppression, mise à jour, requêtes simples, interrogations fréquentes.

3.3. Activités des Systèmes Décisionnels (SID)

Capables d'agréger données internes/externes et de les transformer en informations pour une prise de décision rapide.

• Répondent à des questions complexes (ex : catégorie socioprofessionnelle des meilleurs clients, évolution des parts de marché).
• Les questions sont formulées dans le langage de l'utilisateur métier et sont souvent imprévisibles.
• Nécessitent des méthodes d'extraction d'informations adéquates.

3.4. Incompatibilités OLTP et OLAP

Les objectifs de performance OLTP et OLAP sont opposés et ne peuvent coexister sur les mêmes données.

• Les requêtes OLAP dégradent les performances des systèmes transactionnels.
• Les données temporelles sont difficiles à visualiser historiquement dans un système transactionnel.
• L'activité OLAP nécessite une base de données propre : l'entrepôt de données (Data Warehouse).

4. Notion de Système d'Information d'Aide à la Décision (SIAD)

4.1. Définitions du SIAD

Selon Bernard ROY, l'aide à la décision est une activité s'appuyant sur des modèles pour fournir des éléments de réponse aux questions d'un intervenant dans un processus décisionnel, afin d'éclairer la décision et de recommander un comportement. Un SIAD est la partie d'un SI qui accompagne les décideurs.

• Fonctions d'un SIAD :
  • Collecter, intégrer, synthétiser et transformer les données opérationnelles.
  • Mémoriser de manière adaptée les données décisionnelles.
  • Traiter ces données (alimentation, rafraîchissement, pré-calculs).
  • Restituer ces données de manière appropriée pour faciliter la prise de décision.
• Actuellement, l'ensemble des outils informatiques supportant un SIAD est appelé Business Intelligence (BI) ou Système d'Aide à la Décision (SAD).

4.2. Classifications des SIAD

Les SIAD peuvent être classés en trois catégories selon l'échelle de temps et l'envergure de la décision :

• SIAD opérationnel : Évite la surcharge mentale de l'opérateur en proposant des solutions rapides pour des situations complexes.
• SIAD de gestion : Présente aux responsables opérationnels des indicateurs et alarmes quotidiens pour le pilotage (qualité, charge de travail). S'intègre aux processus métier.
• SIAD stratégique : Présente aux dirigeants des séries chronologiques mensuelles pour éclairer l'efficacité et le positionnement de l'entreprise (résultats, part de marché, tendances). C'est le type de SIAD principalement abordé dans ce cours.

Le SIAD est un point d'aboutissement du SI, qu'il soutient et alimente, mais qui n'a d'interface que pour la consultation par l'utilisateur.

4.3. Dimension Technique du SIAD Stratégique

Un SIAD est un outil d'observation qui permet aux managers d'identifier les alertes de gestion, de suivre l'évolution de l'activité et d'investiguer des phénomènes particuliers, à partir de données de gestion et/ou statistiques. Il fournit une présentation synthétique des données d'entreprise et doit résoudre les problèmes de comparabilité et de redressement des données issues de diverses sources.

• Objectifs du SIAD :
  • Présenter des informations utiles, construites selon des critères de sélectivité pour différentes catégories d'utilisateurs.
  • Offrir un outil de consultation commode et ergonomique, minimisant la recherche d'information.
  • Protéger les bases de données opérationnelles en s'intercalant comme tampon.

4.4. Outils fournis par le SIAD

• Tableaux de bord avec alertes.
• Tableaux préformatés de statistiques d'activité et d'environnement.
• Tableaux et graphiques restituant des résultats synthétiques via la technologie "hypercubes".
• Analyses sophistiquées à la demande (corrélation, simulation) utilisant des outils de "datamining".

La technologie hypercubes permet de construire des séries chronologiques ou tableaux croisés à partir de tableaux multidimensionnels intermédiaires. Le contenu des hypercubes est défini a priori.

4.5. Architecture du SIAD

Un SIAD peut être structuré en trois couches :

• Alimentation de la base multidimensionnelle.
• Stockage historisé, agrégation et constitution des hypercubes.
• Publication sous forme d'alertes, tableaux préformatés, tableaux croisés et graphiques.

La constitution de la base de données du SIAD implique :

• Une procédure d'extraction périodique des données des applications vers un "silo d'échange".
• Un traitement par le SIAD pour vérifier et redresser les données avant intégration.

La modélisation de l'entrepôt de données précise les "axes" (variables qualitatives pour les tableaux) et les "mesures" (variables ventilées dans les tableaux).

4.6. Base de Données du SIAD

La base de données du SIAD est détaillée, souvent une copie individuelle des enregistrements individuels des applications source. Contrairement aux bases opérationnelles "vivantes", la base SIAD est une base "morte" enregistrant des situations passées, permettant de reconstituer l'enchaînement chronologique. Elle est à la fois exhaustive (pour la population étudiée) et sélective (pour les variables observées).

• Méthodes de constitution :
  • Suite périodique de "photographies" instantanées de la base vivante.
  • Considération des événements qui modifient la base (modifications datées d'enregistrements individuels).

4.7. Apports et Limites du SIAD

Le SIAD fournit des observations qui, après recoupement avec d'autres sources (économiques, marketing), alimentent la compréhension du marché, suivent l'activité et optimisent les moyens pour faciliter l'orientation de l'action. Il ne fournit pas d'indicateurs pour le pilotage opérationnel quotidien ni le suivi de dossiers individuels. Il peut cependant conforter la gestion en permettant aux responsables d'évaluer l'efficacité par des séries chronologiques confrontées aux données de gestion.

5. Data Warehouse

5.1. Présentation et Motivation

Les entreprises font face à une concurrence accrue et des clients exigeants. L'anticipation repose sur des informations pertinentes. Malgré la surabondance de données éparpillées et non organisées, ces dernières représentent une "mine d'informations". Le Data Warehouse (DW) est une architecture informatique visant à rassembler et homogénéiser ces données pour l'analyse décisionnelle. Il permet d'améliorer la performance et la connaissance des clients et de l'environnement.

5.2. Systèmes Opérationnels et Décisionnels

Les systèmes opérationnels (transactionnels) contiennent des données importantes mais sont orientés vers les fonctions quotidiennes. Elles sont éparpillées, peu structurées pour l'analyse, et utilisées pour des fonctions critiques avec des temps de réponse corrects. Il est nécessaire de construire une structure dédiée (le DW) pour héberger, organiser et restituer ces informations à des fins d'analyse.

Le tableau suivant met en évidence les différences entre données opérationnelles et décisionnelles :

Données opérationnelles	Données décisionnelles
Orientées application, détaillées, précises au moment de l'accès	Orientées activité (thème, sujet), condensées, historiques
Mise à jour interactive possible	Pas de mise à jour interactive
Accès unitaire, par une personne à la fois	Utilisation par l'ensemble des analystes, par sous-ensemble
Cohérence atomique	Cohérence globale
Haute disponibilité en continu	Haute disponibilité ponctuelle
Uniques (peu de redondance)	Peuvent être redondantes
Structure statique, contenu variable	Structure flexible
Petite quantité de données par traitement	Grande quantité de données par traitement
Opérations au jour le jour	Cycle de vie différent
Forte probabilité d'accès	Faible probabilité d'accès
Utilisées de façon répétitive	Utilisées de façon aléatoire

5.3. Définition et Caractéristiques du Data Warehouse

La définition la plus appropriée est celle de William (Bill) Inmon : un Data Warehouse est une collection de données orientées sujet, intégrées, non volatiles et historisées, organisées pour le support d'un processus d'aide à la décision. C'est une base de données multidimensionnelle alimentée par des données nettoyées et homogénéisées provenant des systèmes de production (OLTP).

5.3.1. Caractéristiques des données

• Orientées sujet : Organisé autour des sujets majeurs de l'entreprise (ex: clients, produits), permettant une vue transversale.
• Intégrées : Les données de différentes sources sont unifiées et mises en forme pour une vue cohérente. Cette phase d'intégration est complexe et représente 60 à 90% de la charge du projet DW.
• Non volatiles : Les données ne sont jamais mises à jour. Chaque valeur est associée à un référentiel temps, permettant de retrouver des valeurs passées. Conséquence de l'historisation.
• Historisées : Conserve en ligne les données historisées. Chaque nouvelle insertion ne détruit pas les anciennes valeurs mais crée une nouvelle occurrence.

Comparaison entre système de production et Data Warehouse :

Critère	Système de production	Data Warehouse
Niveau de détail	Très détaillé	Synthétique, parfois détaillé
Utilisateurs	Une ou quelques fonctions	Plusieurs fonctions
Données figées	Non (évolution en temps réel)	Oui (archivage)
Historique	Non	Oui
Opérations sur données	Ajout/mise à jour/consultation	Consultation uniquement

5.4. Concepts de Base du Data Warehouse

5.4.1. Structure

Un Data Warehouse se structure en quatre classes de données :

• Données détaillées courantes : Reflètent les événements récents, volumes importants. Le niveau de détail n'est pas forcément identique aux systèmes opérationnels (peut être agrégé).
• Données agrégées : Éléments d'analyse représentatifs des besoins utilisateurs, facilement accessibles et compréhensibles via des structures multidimensionnelles.
• Données archivées/anciennes : Stockées en ligne, chaque nouvelle insertion de données ne détruit pas les anciennes valeurs, mais crée une nouvelle occurrence.
• Métadonnées : Informations sur le DW et ses processus. Utilisées par les utilisateurs (sémantique, localisation), les équipes de transformation (règles), les équipes de création d'agrégats et les administrateurs de base de données.

5.4.2. Architectures

Trois types d'architectures sont possibles pour implémenter un Data Warehouse :

• Architecture réelle : Les données sont stockées dans un SGBD séparé, alimenté par des extractions périodques. Le SGBD contient des données préparées pour la décision, mais implique un coût de stockage supplémentaire et un manque d'accès en temps réel.
• Architecture virtuelle : Les données restent dans le système de production et sont accessibles via des middlewares. Avantages : pas de coût de stockage, accès en temps réel. Inconvénient : données non préparées.
• Architecture remote : Combinaison des deux précédentes, rarement utilisée. Agrégats stockés physiquement, données de détail dans le système de production accessibles via middleware.

Synthèse des architectures de Data Warehouse :

	Architecture réelle	Architecture virtuelle	Architecture remote
Utilisation	Retenue pour les systèmes décisionnels	rarement utilisée	rarement utilisée
Stockage	SGBD séparé du système de production, alimenté par extractions périodiques	Données résidant dans le système de production	Combinaison des architectures réelle et virtuelle
Avantages	Données préparées pour la décision	Pas de coût de stockage supplémentaire, accès en temps réel
Inconvénients	Coût de stockage supplémentaire, manque d'accès temps réel	Données non préparées

5.4.3. Infocentre et Data Warehouse

Bien que similaires, l'infocentre et le Data Warehouse diffèrent sur plusieurs points, notamment la volatilité des données et leur finalité.

	Infocentre	Data Warehouse
Type	Collection de données	Collection de données
Orientation	Orientées sujet	Orientées sujet
Intégration	Intégrées	Intégrées
Volatilité	Volatiles	Non volatiles
Historisation	Actuelles	Historisées
Finalité	Support de décision ponctuelle	Support d'aide à la décision
Nature	Outil	Architecture

Dans un infocentre, chaque nouvelle valeur remplace l'ancienne, rendant impossible de retrouver des valeurs antérieures. Le DW conserve l'historique pour des décisions à long terme. L'infocentre est un outil, le DW est une architecture.

6. Datamart

6.1. Définition du Datamart

Un Datamart (DM) est une base de données moins coûteuse, plus légère qu'un Data Warehouse, destinée à un nombre restreint d'utilisateurs au sein d'un département. Il vise une problématique précise avec moins de sources de données. Il peut évoluer vers un Data Warehouse si des précautions sont prises.

Comparaison entre Data Warehouse et Data Mart :

	Data Warehouse	Data Mart
Cible utilisateur	Toute l'entreprise	Département
Implication du service informatique	Élevée	Faible ou moyenne
Base de données	SQL type serveur	SQL milieu de gamme, bases multidimensionnelles
Modèles de données	À l'échelle de l'entreprise	Département
Champ applicatif	Multi-sujets, neutre	Quelques sujets, spécifique
Sources de données	Multiples	Quelques-unes
Stockage	Base de données	Plusieurs bases distribuées
Taille	Centaines de Go et plus	Une à deux dizaines de Go
Temps de mise en place	9 à 18 mois pour 3 étapes	6 à 12 mois (installation en plusieurs étapes)
Coût	> 6 millions de francs	500 000 à 3 millions de francs

7. Construction du Data Warehouse

L'objectif est de recomposer les données pour obtenir une vision intégrée, transversale, métier et agrégée/détaillée.

7.1. Approches de Construction

Deux grandes théories s'opposent en BI :

• Approche Top-Down (Bill Inmon) :
  • Le DW consolide les données détaillées de toute l'entreprise.
  • Les DM sont construits à partir de cette source complète.
  • Avantages : Architecture intégrée, déduction facile des DM, réutilisation des données, pas de redondances, vision claire des données.
  • Inconvénients : Méthode lourde, contraignante, nécessite du temps.
• Approche Bottom-Up (Ralph Kimball) :
  • Le DW est l'ensemble des DM ; chaque nouveau DM enrichit le DW.
  • Avantages : Simple à réaliser, résultats rapides, efficace à court terme, diminution des coûts et délais.
  • Inconvénients : Pas efficace à long terme, risque de redondances, volume de travail d'intégration important.
• Approche Middle-Out (approche hybride) :
  • Prend le meilleur des deux approches.
  • Développement d'un modèle de données d'entreprise itératif.
  • Développement d'une infrastructure lourde uniquement en cas de nécessité.
  • Inconvénient : Peut impliquer des compromis de découpage.

7.2. Constituants du Système Décisionnel

Un système décisionnel est composé de deux pans :

• Préparation et stockage des données (Back-End) :
  • Construction et alimentation d'un Data Warehouse.
  • Utilisation d'outils ETL (Extract, Transform, Load) pour le nettoyage et l'intégration.
  • Objectifs : Archiver données métier, nettoyer incohérences, lier référentiels, fournir un socle d'analyse.
• Distribution des données aux utilisateurs (Front-End) :
  • Applications de BI.
  • Création d'axes métier (dimensions), traitement de données pour valeur ajoutée.
  • Objectifs : Fournir information compréhensible, orientée métier, exploitable ; source unique et sécurisée ; analyses disponibles et accessibles.

7.3. Composants Fonctionnels du Data Warehouse

Trois composants caractérisent un Data Warehouse :

• Acquisition (ETL) :
  • Extraction : Collecte les données utiles des systèmes de production. Peut utiliser passerelles, outils de réplication, outils propriétaires ou développés spécifiques.
  • Préparation : Mise en correspondance des formats, nettoyage, transformation et agrégation des données.
  • Chargement : Dernière phase d'alimentation. Nécessite la maîtrise de la structure du SGBD (tables, index) pour optimiser le processus.
• Stockage :
  • Composant de base : le SGBD, adapté aux caractéristiques de l'accès décisionnel.
  • Transparence à l'évolution matérielle et des systèmes d'exploitation.
• Accès décisionnel (Front-End) :
  • Définir une architecture globale pour les accès décisionnels, tout en offrant aux utilisateurs des solutions d'accès adaptées (requêteurs, tableurs, outils OLAP, EIS, Data Mining, SIG).

8. Conduite de Projets Décisionnels

8.1. Conduite du Projet

Pour construire un Data Warehouse, il faut :

• Bien connaître les métiers utilisateurs : Impliquer, faire participer à la définition des métadonnées, former, avoir un chef de projet orienté utilisateur.
• Assurer une véritable conduite de projet : Le chef de projet fédère les besoins, organise et planifie les phases. (L'échec principal est souvent humain).
• Commencer petit et voir grand : Démarrer avec un prototype ou un Data Mart.
• Gérer l'évolutivité : Maîtriser l'alimentation et l'administration.

La construction d'un DW stratégique est un projet colossal, souvent découpé en itérations par domaine fonctionnel (Data Marts) pour satisfaire les utilisateurs plus tôt et permettre une montée en charge progressive.

8.2. Étapes de Conception

La conception d'un Data Warehouse est influencée par :

• Les évolutions technologiques : Choix des composants selon le contexte d'utilisation.
• La stratégie de l'entreprise : Le DW est aligné sur la stratégie, objectifs définis en termes métier.
• L'amélioration continue : Le DW doit évoluer avec les demandes utilisateurs et les objectifs.
• La maturité de l'entreprise : Adapte le projet au contexte existant.

Trois phases pour la conception :

• Définir le "pourquoi" et les objectifs (impliquer les utilisateurs).
• Définir l'infrastructure technique et organisationnelle.
• Mettre en œuvre les applications.

Ces phases s'inscrivent dans une démarche informatique en cinq étapes : spécification, conception, mise en œuvre et intégration, déploiement, et mesures.

8.3. Conduite d'une Itération

Chaque itération débute par la modélisation du Data Mart :

• Choisir le processus métier à analyser : Définir le périmètre fonctionnel du DM (ex: commandes clients).
• Définir le grain du DM : Niveau de détail des données archivées dans la table de faits (ex: lignes de commande).
• Définir les dimensions : Axes d'analyse (ex: calendrier, clients, produits, fournisseurs) avec attributs et hiérarchies.
• Définir les mesures des faits : Informations quantitatives dans la table des faits (ex: quantité, montant, nombre distinct de commandes).
• Définir la fréquence et le mode d'alimentation : Fraîcheur des données, solutions pour alimenter le schéma en étoile.
• Définir la profondeur d'historique en ligne : Nombre d'unités de temps (années, mois...) pour estimer le volume de données.

8.4. Implémentation du Data Mart

L'implémentation physique s'effectue comme suit :

• Création du DM relationnel SQL (tables de faits et dimensions) avec partitionnement et indexation.
• Création de la couche sémantique (modèle multidimensionnel ou tabulaire) pour l'interface utilisateur.
• Création des applications de Business Intelligence (rapports, classeurs Excel).
• Validation du modèle et des données avec les utilisateurs métier.
• Création de l'alimentation du DM (ETL) : la partie la plus coûteuse.
• Validation finale (recette) par les utilisateurs.

La phase d'alimentation du Data Warehouse est une des difficultés techniques majeures et la plus coûteuse.

9. Alimentation du Data Warehouse (ETL)

L'acquisition des données se déroule en trois phases : extraction, transformation et chargement.

9.1. Découverte des Données

Consiste à localiser les données pertinentes dans le système opérationnel. Un mauvais choix peut complexifier les phases suivantes.

9.2. Extraction des Données

Collecter les données utiles du système de production. Pour rafraîchir la base, identifier les données modifiées pour extraire le minimum et planifier les extractions pour éviter la saturation du système de production. Le processus doit être automatique et ne rafraîchir que les données modifiées.

9.3. Transformation des Données

Comprend le nettoyage des données, la suppression des doublons, l'application de filtres pour assurer la cohérence (ex: harmonisation des formats de date), et la décomposition/agrégation/calcul des données. Les liens entre champs sources et cibles peuvent être complexes (1-1, 1-N, N-1, N-N). Des analyses lexicales peuvent reconnaître des termes similaires (ex: "Boulvd", "Bd", "Boulevard").

9.4. Chargement des Données

Dernière phase de l'alimentation, délicate en cas de gros volumes. Nécessite la maîtrise des structures du SGBD (tables, index) pour optimiser les performances. Les techniques de parallélisation peuvent optimiser les chargements lourds.

• Méthodes de transfert :
  • Transfert de fichiers : Création de fichiers lors de l'extraction, transfert vers le système cible, transformation avant ou après.
  • Transfert de base à base : Extraction de la source, nettoyage, transfert vers la cible.

10. Concept OLAP (OnLine Analytical Processing)

10.1. Présentation

Les outils OLAP reposent sur une base de données multidimensionnelle pour exploiter rapidement les dimensions d'une population de données. Ils restructurent et stockent les données (fichiers plats, bases relationnelles) dans un format multidimensionnel appelé hypercube, organisant les données le long de dimensions. Cela permet des analyses multidimensionnelles avec de grands volumes de données.

10.2. Règles OLAP (selon E.F. Codd, 1993)

Codd a défini 12 règles que tout système de pilotage multidimensionnel devrait respecter :

1. Vue multidimensionnelle : L'utilisateur doit pouvoir raisonner et manipuler les données en vues multidimensionnelles (rotation, pivot, slice and dice, drill anywhere).
2. Transparence du serveur OLAP : Intégration transparente avec les outils habituels de l'utilisateur, architecture ouverte, ne pas affecter les fonctionnalités du système central. L'utilisateur ne doit pas se soucier de l'intégration des données.
3. Accessibilité à de nombreuses sources de données : Accès aux données nécessaires aux analyses, capacité à gérer des schémas logiques de stockage pour des données physiques hétérogènes.
4. Performances du système de Reporting : L'augmentation du nombre de dimensions ou du volume de données ne doit pas dégrader visiblement les performances.
5. Architecture Client-Serveur : Prise en charge des environnements Client-Serveur.
6. Dimensions Génériques : Toutes les dimensions doivent être équivalentes en structure et en calcul.
7. Gestion dynamique des matrices creuses : Optimisation de la gestion des données pour les matrices creuses (où toutes les cellules n'ont pas de valeur).
8. Supports multi-utilisateurs : Gestion des accès concurrents, intégrité et sécurité des données.
9. Calculs à travers les dimensions : Opérations possibles sur toutes les dimensions, sans intervention de l'utilisateur pour les calculs hiérarchiques.
10. Manipulation intuitive des données : Manipulation via action directe sur les cellules, sans menus complexes.
11. Souplesse et facilité de constitution des rapports : Création de rapports flexibles pour présenter les données de manière synthétique ou détaillée.
12. Nombre illimité de niveaux d'agrégation et de dimensions : Le système doit gérer au moins 15 à 20 dimensions.

Codd a souligné que les SGBD relationnels n'étaient pas conçus pour les fonctions de synthèse, d'analyse et de consolidation de l'analyse multidimensionnelle. Les données doivent être transformées en un hypercube.

10.3. Analyse Multidimensionnelle

Les serveurs OLAP intègrent un environnement client/serveur avec des hypercubes prédéfinis pour analyser la répartition d'indicateurs (ex: chiffre d'affaires) selon des axes/dimensions (clients, produits, temps) et leurs hiérarchies.

10.3.1. Modèle dimensionnel

• Dimensions : Un tableau à n dimensions (hypercube). Chaque dimension a une hiérarchie associée de niveaux de consolidation (ex: Année, Saison, Mois, Semaine pour le temps). Chaque intersection de dimensions est une cellule.
• Variables (métriques) : Colonnes dans une table relationnelle. Peuvent être de flux (cumulables sur une période) ou d'état (valeur à un instant t, non cumulable). Les métriques de base sont l'association d'une colonne de fait et d'une fonction d'agrégation.

10.3.2. Navigation dans les données

• Drill-down / Drill-up : Passage du niveau global au niveau détaillé et inversement, basé sur les hiérarchies (ex: d'une marque vers un article). Une dimension peut avoir plusieurs hiérarchies.
• Slice and dice (pivot) : Rotation dynamique des axes d'un tableau d'analyse croisée.
• Rotate : Rotation de l'hypercube pour présenter une face différente, modifiant la dimension de lecture.
• Data surfing : Possibilité de circuler librement et de manière intuitive dans le modèle dimensionnel, au-delà du drill-down ou slice and dice, en modifiant dynamiquement les axes ou appliquant de nouveaux filtres.

Ces mécanismes s'appliquent sur un modèle défini par l'administrateur ou l'utilisateur.

10.3.3. Problème des matrices creuses

Dans un hypercube, toutes les cellules n'ont pas toujours de valeur (cube creux ou sparcity). Cela se produit lorsque des enregistrements n'appartiennent qu'à une seule dimension, des dimensions sans valeur pour chaque occurrence, ou des dimensions comportant des valeurs exclusives. L'ajout de colonnes précalculées augmente significativement la taille de la base de données. Pour MOLAP, il est crucial de bien choisir les dimensions et de restreindre leur nombre. Le stockage relationnel permet d'éluder ces problèmes de place.

11. Modélisation d'un Data Warehouse

La modélisation est délicate et doit aboutir à un modèle global et cohérent, orienté sujet et compréhensible pour l'utilisateur. Elle doit s'adapter à la démarche de recherche et d'analyse.

Les cinq axes de qualification d'un modèle décisionnel sont : la lisibilité, les performances de chargement, les performances d'exécution, l'administration et l'évolutivité. Le choix du modèle dépend des besoins.

11.1. Modélisation relationnelle

• Modèle de données normalisé : Très classique et détaillé (ex: MERISE). Offre beaucoup d'autonomie mais peu d'informations directement utiles pour le décisionnel. Les requêtes peuvent être complexes et peu performantes sur de grandes tables.
• Modèle de données dénormalisé : Simplifie le modèle normalisé pour mieux répondre aux exigences décisionnelles. Crée des redondances et informations agrégées pour améliorer les temps de réponse et faciliter l'accès, réduisant le nombre de tables.

11.2. Modélisation dimensionnelle

Dérive des concepts OLAP et vise l'analyse de la performance via des indicateurs regroupés dans une table des faits.

• Modéliser en étoile (Star Schema) :
  • Tous les faits sont dans une seule table de faits, reliée par clés primaires à des tables de dimensions (ex: PRODUITS, MAGASIN, CLIENT, REGION, TEMPS pour les achats).
  • Simplifie le modèle logique normalisé pour l'analyse.
  • Avantages : Facilité de navigation, nombre limité de jointures, gestion des agrégats.
  • Inconvénients : Toutes les dimensions ne concernent pas les mesures, redondances dans les dimensions, alimentation complexe.
• Modéliser en flocon (Snowflake Schema) :
  • Modélisation en étoile semi-dénormalisée où les tables de dimensions sont éclatées en sous-tables selon leur hiérarchie (ex: PRODUITS éclatée en Catégorie, Sous-catégorie).
  • Avantages : Normalisation des dimensions, économie d'espace disque.
  • Inconvénients : Modèle plus complexe (nombreuses jointures), requêtes moins performantes, navigation difficile.
• Modèle en constellation de faits (Fact Constellation Schema) :
  • Plusieurs tables de faits partagent certaines dimensions. Utilisé pour un DW global d'entreprise.
  • Constitué d'un ensemble de schémas en étoile et/ou en flocon.

11.2.1. Dimensions et granularité

• Attributs : Composent une dimension (ex: nom, adresse, ville pour CLIENT). Les hiérarchies lient les attributs (ex: Département > Ville). Certains attributs servent à l'analyse, d'autres sont purement informatifs.
• Granularité : Niveau de détail des données d'une dimension.
• Clés : Une clé fonctionnelle (du système OLTP) identifie de manière unique chaque ligne de la dimension. Une clé de substitution (surrogate key), propre à l'environnement décisionnel, est souvent générée (nombres entiers).
  • Avantages des clés de substitution : Petite taille (optimisation des jointures), permet de suivre l'évolution des attributs (ex: client qui déménage), indépendante de la source (utile avec multi-sources).
  • Inconvénients : Index supplémentaire, modèle et requêtes plus complexes.
• Variation des dimensions : Les attributs peuvent évoluer dans le temps.
  • Type 1 (écrasement) : L'ancienne valeur est écrasée. Les faits antérieurs sont rattachés à la nouvelle valeur. Adapté aux modifications courantes.
  • Type 2 (historisation) : Un nouvel enregistrement est créé dans la dimension pour chaque modification, mémorisant l'évolution des attributs (ex: avec dates de validité). Les nouveaux faits sont rattachés au nouvel enregistrement. Adapté aux modifications rares (Slow Changing Dimension).

11.2.2. Faits, agrégations et cubes

• Le niveau des faits dans le système opérationnel est le niveau atomique. Une table de faits peut être au niveau atomique ou déjà agrégée.
• Un agrégat est une valeur combinant plusieurs valeurs via un opérateur mathématique (ex: somme du CA). Le pré-calcul d'agrégats (ex: CA mensuel) améliore fortement les performances.
• Un cube est un schéma en étoile où un nombre d'agrégats ont été précalculés. Il offre une couche métier au-dessus des données du schéma en étoile. Il est performant pour les résultats agrégés, non pour les faits atomiques. Un cube peut avoir plus de trois dimensions (base de données multidimensionnelles).

12. Différentes Technologies OLAP

Le choix de l'outil dépend des besoins. Les outils OLAP se déclinent en plusieurs versions :

• MOLAP (Multidimensional OLAP) :
  • Excluivement pour l'analyse multidimensionnelle, avec stockage optimisé (hypercube ou format tabulaire propriétaire).
  • Agrège tout par défaut, donc bonnes performances pour l'analyse.
  • Limité en volume (quelques giga-octets).
  • Incompatible avec d'autres modes d'accès (nécessite un moteur spécialisé et une API dédiée plutôt que SQL standard).
  • Excellent pour des fonctionnalités avancées (prévision, simulation).
• ROLAP (Relational OLAP) :
  • Superpose un modèle multidimensionnel au-dessus des SGBD/R bidimensionnels.
  • Diminue le coût d'un serveur de base de données multidimensionnelle supplémentaire.
  • Traduit les analyses multidimensionnelles en requêtes SQL.
  • Ne stocke pas les agrégats par défaut, mais en tire parti s'ils existent (il faut les gérer explicitement).
  • Mieux adapté aux gros volumes de données.
  • Accès direct aux bases de production pour l'analyse est déconseillé.
• HOLAP (Hybrid OLAP) :
  • Combine MOLAP et ROLAP. Stocke les données détaillées dans des tables relationnelles et les données agrégées dans des cubes.
  • Mixe les avantages des deux systèmes, répartissant les requêtes pour une meilleure performance.
• OOLAP (Object OLAP) :
  • Technologie la plus récente, basée sur le paradigme objet.
  • Chaque fait et chaque dimension correspond à une classe.
  • Augmente le niveau d'abstraction.

13. L'Exemple de BI Microsoft (SQL Server)

13.1. Suite Microsoft SQL Server

SQL Server contient principalement les quatre composants suivants pour la BI :

• MSSQL (SQL Server Database Engine) : Serveur de bases de données relationnelles, optimisé pour les applications transactionnelles et les schémas en étoile.
• SSAS (SQL Server Analysis Services) : Serveur de modèles sémantiques de données.
  • Peut être installé en mode multidimensionnel (OLAP, Data Mining) ou tabulaire.
  • Le mode multidimensionnel stocke les données (fines et agrégats) aux formats MOLAP, ROLAP ou HOLAP.
• SSRS (SQL Server Reporting Services) : Serveur de rapports.
  • Conçu pour travailler sur des bases relationnelles, peut aussi lire SSAS.
  • Produit des rapports statiques (tableaux, graphiques, jauges, indicateurs visuels, cartographie).
  • Intègre Power View (pour SharePoint et Excel) pour des rapports dynamiques.
• SSIS (SQL Server Integration Services) : ETL pour alimenter les entrepôts de données et automatiser les tâches d'administration.
  • Se connecte à de nombreux types de sources de données.
  • Construit des flux ETL en paquets, avec des flux de contrôle et de données.
  • Propose des modèles de déploiement par paquets ou par projet pour gérer la paramétrisation et l'exploitation.

L'utilisation d'une base relationnelle est recommandée pour construire une solution BI, avec des éditions comme le Parallel Data Warehouse pour les gros volumes.

13.2. Office et BI

La gamme Office, notamment Excel et SharePoint, joue un rôle direct dans les solutions BI de Microsoft.

• Excel : Outil très puissant pour la consommation des données décisionnelles.
  • Connexion aux sources de données relationnelles et décisionnelles.
  • Création de tableaux croisés dynamiques, graphiques, et formules de cube.
  • À partir d'Excel 2013, le classeur contient un modèle de données (tables et relations) permettant de manipuler des millions de lignes.
  • Conversion de tableaux dynamiques en formules de cube pour des tableaux de bord statiques.
• Power BI pour Excel : Suite d'outils de BI en libre-service.
  • Power Pivot : Module complémentaire au modèle de données d'Excel, ajoute une couche sémantique métier (colonnes calculées, mesures agrégées, hiérarchies, KPI).
  • Power Query : ETL personnel, connecte à de nombreuses sources, nettoie et fusionne les données.
  • Power View : Solution de reporting dynamique, consomme les données du modèle Excel ou des bases SSAS tabulaires.

13.3. Premiers Pas avec SQL Server

• SSDT (SQL Server Data Tools) : Interface de développement dédiée à la BI.
  • Édition de Microsoft Visual Studio.
  • Permet de développer des projets pour SQL Server (bases relationnelles), Analysis Services (multidimensionnel/tabulaire), Integration Services et Reporting Services.
  • Facilite le développement collaboratif avec TFS (Team Foundation Server).
  • L'Explorateur de solutions permet de regrouper et gérer les composants des projets.
• SSMS (SQL Server Management Studio) : Interface de gestion des services SQL Server (instances de bases de données, SSAS, SSIS, SSRS).
  • Permet toutes sortes d'opérations : exécution de requêtes, sauvegardes, gestion des partitions, scripts DDL.
  • L'Explorateur d'objets est le cœur de SSMS pour naviguer et effectuer des opérations contextuelles.
• Exemple Adventure Works : Microsoft fournit un système BI d'exemple (société imaginaire Adventure Works Cycle) pour illustrer les fonctionnalités de SQL Server. Une ressource complète et communautaire pour l'étude et la reproduction de comportements.

Conclusion

Ce cours a couvert les concepts fondamentaux des systèmes d'information, du transactionnel au décisionnel, avec une attention particulière aux SIAD, aux Data Warehouses, aux Data Marts, à la modélisation dimensionnelle (étoile, flocon, constellation), aux technologies OLAP (MOLAP, ROLAP, HOLAP, OOLAP) et aux outils BI de Microsoft SQL Server. La compréhension de ces éléments est cruciale pour la mise en place de solutions d'aide à la décision efficaces en entreprise.