Science de données

Pr TSOPZE N.
Programme
 Informatique Décisionnelle
 Introduction
 Entrepôts de données
 Processus ETL
 Modélisation
 Fouille de données
 Régression Linéaire et logistique
 Classification supervisée
 Classification non supervisée
 Classification sémi-supervisée
 Big data
 Biais + Ethique
 Bibliographie
 D. Ploix - Conception EDD support de cours pour M2 MIAGE
à l’université d’Evry
 R KIMBALL. The Data Warehouse Toolkit: The Complete
Guide to Dimensional Modeling. Wiley Publishing, second
edition, 2008
 BILL INMON , Michael H. Brackett. (1996). The Data
Warehouse Challenge: Taming Data Chaos. Wiley, 1er
édition.
 Han, Kamber, datamining concepts and techniques,
Morgan Kaufmann, 2001.
 E. Ferragu, Modélisation des systemes d’information
décisionnels – techniques de modélisation conceptuelle et
relationnelle des entrepôts de données, Vuibert, 2013,
Evaluation
1. Exposés (éventuellement)
2. Contrôle continu
3. Examen de fin de semestre
4. Évaluation pratique (éventuelle)

5. Modalité: A définir
Systèmes d’information
décisionnels

Merci tous les contributeurs !

Introduction
Motivations des entreprises
 Besoin des entreprises
 accéder à toutes les données de l’entreprise
 regrouper les informations disséminées
 analyser et prendre des décisions rapidement (OLAP)
 Exemples d'applications concernées
 Grande distribution : marketing, maintenance, ...
 produits à succès, modes, habitudes d’achat
 préférences par secteurs géographiques
 Bancaire : suivi des clients, gestion de portefeuilles
 mailing ciblés pour le marketing
 Télécommunications : pannes, fraudes, mobiles, ...
 classification des clients, détection fraudes, fuites de
clients
Décisionnel
 Les entreprises veulent exploiter
l’information.
 Défi : Transformer leur système
d’information
 qui avait une vocation de production en un
SI décisionnel dont la vocation de pilotage
devient majeure;
 Connaître l’environnement dans lequel on
évolue
 Pilotage de l’entreprise
Définitions
 Système d’information décisionnel:
 ensemble d’outils et de données organisé de
façon spécifique, approprié à la prise de
décision
 le bon pilotage de l’entreprise.
 Les données du SID proviennent d’horizons
multiples et divers.
 en grande majorité tirées des bases de production
(légales, juridiques, fiscales, politiques,
techniques, marketing…).
 en vu de la construction des indicateurs
indispensables au pilotage de l’entreprise, se fait
par entreposage de données
Définitions
 Entrepôt de données:
 base de données orientée sujet, intégrée et contenant des
informations historisées, non volatiles et exclusivement
destinées aux processus d’aide à la décision (Bill Inmon)
 system that retrieves and consolidates data periodically
from the source systems into a dimensional or normalized
data store (V. Rainardi)
 structure informatique dans laquelle est centralisé un
volume important de données consolidées à partir des
différentes sources de renseignements d'une entreprise
(notamment les bases de données internes) et qui est
conçue de telle sorte que les personnes intéressées aient
accès rapidement à l'information stratégique dont elles
ont besoin
SID

 Adéquation des données aux

mécanismes de la décision
 Avec une complexité, des coûts et des
risques
 Implique un modèle de données
spécifique et évolutif
 Implique une infrastructure
d’alimentation
 œuvre de génie logiciel et d’intégration
 SID
 à la fois séparé dans sa conception et
dépendant pour son alimentation du SIO;
 conditionnée d’une manière intégrée et
indépendante de ses sources d’alimentation.
 dans son contenu et dans sa forme,
indépendante des structures et des procédures
courantes de la production. Elle porte sur le
métier de l’utilisateur,
 Beaucoup de traitements pas déterminés par
des algorithmes
 SID (deux composants)

 modèle de données de diffusion, conçu selon

une approche multidimensionnelle ;
 information décisionnelle chronologique,
analyse de phénomènes évoluant dans le
temps.
 spécifications hautement instables
 objectifs stratégiques sont des cibles mouvantes,
 déploiement du système a pour effet de modifier
l’expression des besoins.
 SID

 établissement de ponts
 entre opérations et stratégie,
 entre automatisation et conduite,
 entre détail et synthèse,
 entre situation et évolution.
 Permet alors la détection avancée et de
l’adaptation rapide
Limites des systèmes
d’informations opérationnels
Systèmes opérationnels
 Opérations quotidiennes:
 Insertion
 Recherche
 Mise à jour
 Données détaillées pour décider
 Validité de la donnée mais pas pertinence de
l’information.
 Beaucoup de transactions
 Utilisateurs: tout le monde sauf les décideurs
(pilotage)
Systèmes opérationnels
 systèmes d’information qui n’informent pas
 Il serait donc tout à fait vain de rechercher, sur
ce point, des solutions qui ne s’exprimeraient
qu’en termes de puissance de calcul, de
vitesse de transmission et de capacité de
mémorisation, et qui relèveraient de la seule
compétence des informaticiens
 Carence d’information regrettable, présent
ressentie comme insupportable, compte tenu
des mutations de l’environnement économique
Limites
 surabondance de données et d’un déficit
d’information  crise de l’information
 dispositif technique conçu pour automatiser
est structurellement incapable d’informer,
systèmes d’information qui n’informent pas
 incapacité à produire l’information de
pilotage;
 conçue et réalisée application par
application, sans cohérence globale
 Critiques
 canaux logiques et physiques de communication sont conçus
« point à point », sans planification d’ensemble, ce qui
produit, à l’échelle de l’entreprise, un réseau compliqué
d’interdépendances et un foisonnement de formats de fichiers
temporaires ;
 Chaque interface nécessite un développement logiciel
spécifique et une technique de transmission particulière ;
 copies physiques entre applications génèrent une forte
redondance de données ;
 cohérence entre deux applications liées aux mêmes données
n’est rétablie que périodiquement incohérence
momentanée.
 Généralement calquées sur la structure de l’organisation
ilot informationnel
 Critiques
 SI dans sa conception ne refléte que la structure organique
du SO. Sa définition descendante (top-down) a toujours été
calquée sur la décomposition du SO (domaines, activités,
fonctions) sans tenir compte des processus fondamentaux.
 Dispersé auprès des organes, le SI ne voit pas les missions,
et encore moins l’environnement ;
 Vision restée presque toujours focalisée, pour l’utilisateur,
sur la fonction applicative, et, pour l’informaticien, sur la
technique.
 Cohérence informationnelle à l’échelle de l’entreprise, dans
l’immense majorité des cas, n’a pas été intégrée dans les
projets en tant que véritable objectif contractuel.
Information de contrôle
 Problème: évolution des dépenses scolaires
 Chambre (mois)
 Moto (jour)
 Petit déjeuner (jour)
 Téléphone (jour)

l’information produite en ordre dispersé dans le

cadre de transactions élémentaires à des fins
de contrôle opérationnel n’est pas directement
utilisable à des fins d’analyse et d’observation.
Comparaison SIO vs SID
Transactionnel vs décisionnel
 Informatique de production
 Modifier et interroger les données par les utilisateurs
 OLTP (On-Line Transaction Processing)
 Conserver la cohérence
 Pas conserver l’évolution
 Faible de temps de réponse
 Éviter la redondance
 Informatique décisionnelle
 Pas de modification de données
 OLAP (On-line Analytical Processing)
 Temps de réponse peut être élevé
 Redondance possible
SIO
 Stocke les données courantes de
l’entreprise
 Surabondant en données
 Automatise simplement l’entreprise
 Carence d’information, n’informe pas

la validité de la donnée ne fait pas la

pertinence de l’information.
 SIO
l’information produite en ordre dispersé dans le
cadre de transactions élémentaires à des fins
de contrôle opérationnel n’est pas directement
utilisable à des fins d’analyse et d’observation.
SIO produisent de l’information de contrôle à
partir de dispositifs hétérogènes indépendants;
SIO sont incapables de produire l’information
de pilotage
SIO
Transactionnel vs décisionnel
Transactionnel vs décisionnel
OLTP et OLAP

Reports
Appli.
Appli. OLAP &
Appli.
Analysis

ETL DW
OLTP

Aides à
DM
la décision
Processus ETL
Architecture type
Entrepôt de données
 Système qui recherche et consolide périodiquement
les données provenant de diverses sources en
données dimensionnées et normalisées. Il garde une
historique de ces données et permet de les interroger
pour les activités d’analyse et de BI.
 Un système de ETL (extract, transform, and load)
permet de fusionner les données de diverses sources
en une seule:
 Capacité à connecter plusieurs sources;
 Lire les données
 Transformer les données
 Charger les données à destination.
un ETL est un système qui intègre, transforme et charge
les données dans un DDS (dimensional data store)
Entrepôt de données
ETL = Intégration des données  3 activités
majeures:
 Extraction—Acquérir les données
provenant d’une ou plusieurs systèmes
 Transformation—Changer le format et/ou
le contenu des données afin de les mettre
dans les structures cibles de l’entrepôt
 Loading—Enregistrer les données dans
l’entrepôt.
ETL ==Extraction, Transformation, and
Loading
Entrepôt de données
 Transformation
 Validation des données—vérifier si les données sources sont
correctes.
 Nettoyage des données—corriger les données invalides.
 Décodage et renommage- uniformiser les noms et les
représentations.
 Agrégation—agréger les données.
 Génération et gestion des clefs —nouvelles lignes des
dimensions doivent être identifiées de manière unique
 Loading
 Chargement des tables de faits—
 Chargement et maintenance des tables de dimension—
Alimenter le DW
 Extraction
 Depuis les bases sources ou les journaux
 Différentes techniques
 Push = règles (triggers)
 Pull = requêtes (queries)
 Périodique et répétée
 Dater ou marquer les données envoyées
 Difficulté
 Ne pas perturber les applications OLTP
Transformation
 Accès unifiés aux données
 Unification des modèles
 Traduction de fichiers, BD réseaux, annuaires en tables
 Evolution vers XML (modèle d'échange) plus riche
 Unification des accès
 Rowset, SQL limité, SQL complet, …
 Mapping plus ou moins sophistiqué
 Unification des noms
 Appeler pareil les mêmes choses et différemment les choses
différentes
 Application des "business rules"
 Elimination des doubles
 Jointure, projection, agrégation (SUM, AVG)
 Cleaning des données
Data Cleaning
 Valeurs manquantes (nulles)
 Ignorer le tuple
 Remplacer par une valeur fixe ou par la moyenne
 Valeurs erronées ou inconsistantes
 Générées en présence de bruits
 Détecter par une analyse de voisinage
 Écart par rapport à la moyenne
 Factorisation en groupes
 Remplacer par une valeur fixe ou par la moyenne
 Inspection manuelle de certaines données
possible
Chargement
 Pas de mise à jour
 Insertion de nouvelles données
 Archivage de données anciennes
 De gros volumes
 Périodicité parfois longue
 Chargement en blocs (bulk load)
 Mise à jour des index et résumés
 Problèmes
 Cohabitation avec l'OLAP ?
 Procédures de reprises ?
Chargement
 Master data
Entités dans les systèmes
opérationnelles, expliquent les
évenements
 clients, produits, magasins, date...
 Transaction data
Données de transaction: achat, ticket
de caisse,..
Entrepôt de données
Entrepôt de données
 OLTP (Online Transaction Processing) : système qui a
pour but principal de capturer et de stocker les
transactions. La source de données est examinée
avec un profiler pour comprendre les caractéristiques
des données.
 BD multidimensionnelle : BD où les données sont
stockées dans les cellules et chaque cellule est définie
par un certain nombre de variables (dimensions), un
cellule peut représentée un évènement, ou une valeur
de la dimension lorsque cet évènement est arrivé.
Information de contrôle
Données synthétisées
Vision globale
Données intégrées
indicateurs clés : permettent de
connaître l’écart entre l’activité
opérationnelle et l’objectif
Pilotage et opérations
Pilotage et opérations
 Système Opérant représente l’organisation en
tant que processeur physique échangeant des
flux de matière et d’énergie avec le monde
extérieur et régulé par le SP par l’intermédiaire
du SI;
 Le pilotage est identifié comme une fonction de
contrôle opérationnel en relation avec des
objectifs prédéterminés.
 le système d’information est l’interface par
laquelle le Système de Pilotage régule et
contrôle le Système Opérant
Pilotage et opérations
 Les données reflètent directement les flux et
les stocks opérationnels de l’organisation 
traitement élémentaire
 Impossible définition et calcul d’indicateurs
d’efficacité pour un processus impliquant
plusieurs fonctions
 Aucune information consistante tiréee sur le
contexte extérieur dans lequel s’exerce le
métier de l’organisation.
Pilotage et opérations
 Dans le contexte concurrentiel, la logique de la
décision, et donc de l’information décisionnelle,
ne peut être que celle de l’autorité, de la
régulation et du contrôle. Les organisations
concurrentes étant toutes pilotées, à quelques
variantes idéologiques près, selon des
principes semblables, l’adaptation rapide au
changement n’était pas imposée par la
compétition extérieure.
 Evoluer signifirait mieux faire la même chose et
non pas faire autre chose.
Pilotage et opérations
 La peur de prendre une mauvaise décision est
souvent plus dissuasive que les conséquences
possibles de l’absence de décision
 Dans cette culture de la non-décision, le
gaspillage informationnel peut entraîner de
sanctions immédiates
 décision réactive et défensive ; prise sous la
pression de contraintes directes et immédiates
Pilotage et opérations
 Le pilotage nécessite à présent une
signalisation rapide et précise basée sur des
faits ;
 Les variables essentielles sont concernent les
forces et les faiblesses de l’organisation, les
menaces qui pèsent sur elle et les opportunités
qui sont à sa portée, et non celles qui mesurent
les performances opérationnelles ;
 L’information stratégique concerne un nombre
croissant d’utilisateurs n’appartenant pas
nécessairement au management central.
Pilotage et opérations
 développement d’un Système d’Information
Décisionnel (SID) distinct du Système
d’Information Opérationnel (SIO) de
l’organisation.
 deux objectifs parallèles :
 L’intégration du système d’information, qui est un
objectif à long terme englobant tous les traitements
et données opérationnels de l’organisation ;
 La construction du Système d’Information Décisionnel
qui, avec l’entrepôt de données, est un objectif
beaucoup plus rapproché d’intégration des données
sous une forme appropriée à un usage décisionnel
Entrepôt de données
 centraliser les données
 converger l'ensemble des données
d'une organisation
 But:
 Historiser les données
 faciliter l'accès à l'information, l'analyse
et la prise de décision.
 automatiser et standardiser les
indicateurs
Entrepôt de données
 Centré sur la modélisation et l’analyse de données pour les
décideurs, non pour des opérations quotidiennes
 Fournit une vue simple, concise sur des sujets particuliers
en excluant des données inutiles dans le processus d’aide à
la décision
 Construit par intégration de sources de données multiples et
hétérogènes
 Organisé autour des sujets majeurs, tels que personne,
client,…
 Sujet = Faits + Dimensions
Architecture des entrepôts de
données
Modèles classiques
 les données sources ne sont ni
sémantiquement cohérentes, ni synchrones, ni
liées entre elles d’une manière adaptée à la
perspective décisionnelle ;
 les environnements – généralement
hétérogènes – d’où proviennent ces
données sont conçus et organisés autour de
technologies (anciennes ou récentes) qui se
prêtent mal à l’implémentation directe
d’applications décisionnelles avancée
Modèles classiques
 les données sources ne sont ni sémantiquement
cohérentes, ni synchrones, ni liées entre elles d’une
manière adaptée à la perspective décisionnelle ;
 les environnements d’où proviennent ces
données sont conçus et organisés autour de
technologies qui se prêtent mal à
l’implémentation directe d’applications
décisionnelles avancées
 Ne pas imposer l’ED comme une source de
contraintes techniques immédiates pour les
applications existante ou imposer aux utilisateurs
de l’ED les contraintes des SIO
Modèles classiques
 L’architecture du système doit donc assurer à
la fois le conditionnement informationnel des
données en provenance de la production et le
cloisonnement entre l’environnement
opérationnel et l’environnement décisionnel.
 Fonctions fondamentales :
 collecte ;
 Intégration
 diffusion ;
 présentation.
Modèles classiques
 collecte : assure l’approvisionnement du SID en données
primaires puisées dans le SIO et subsidiairement à l’extérieur ;
 Intégration :assure la cohérence globale, au moins à l’échelle
d’un domaine, des données capturées, et leur mise à
disposition en un point unique, conformément à un modèle
unifié et normalisé ;
 diffusion : puise les données dans l’entrepôt central produit
et maintenu par la fonction d’intégration, et les met à la
disposition des applications, sous une forme dimensionnelle,
contexte par contexte ;
 présentation : gère, au moyen de services logiciels plus ou
moins élaborés et plus ou moins déterministes, l’accès de
l’utilisateur final aux données organisées par la fonction de
diffusion.
Architectures de référence
 Architecture datamart en silo
 Architecture corporate information
factory ou entreprise data warehouse
(B. Inmon)
 Architecture dimensional data
warehouse ou bus architecture (R.
Kimball)
Architecture datamart en silo
 Couche d’acquisition: ETL (SIO vers
datamarts (stockage))
 Couche de stockage: ensemble de
BD, une BD par fonction
 Couche de restitution: reporting,
tableau de bord, avec possible cube
 Architecture datamart en silo
 Avantages:
 Rapide à mettre en œuvre
 Faible coût
 Inconvénients:
 Redondance des traitements d’extraction (impact
sur la maintenance)
 Absence du langage commun  risque
d’incohérence)
 Difficulté à produire la synthèse des données
provenant des différents datamarts
Corporate info. factory
 Couche d’acquisition: un seul ETL (SIO vers
Datawarehouse centralisé)
 Couche data warehouse: BD unique de
stockage avec les données détaillées
 Couche de distribution: alimenter les
différentes applications utilisateurs
 Couche datamarts: données agrégées par
fonction
 Couche de restitution: reporting
Corporate info. factory
 Mutualisation des traitements (une
seule acquisition)
 Garantie de la cohérence avec le data
warehouse centralisé
 Alimentation facile des applications
Dimensional data warehouse
 Couche d’acquisition: un seul ETL (SIO
vers Datawarehouse centralisé)
 Couche de stockage: data warehouse
modélisé multidimensionnel,
ensemble de datamarts
(fait+dimension)
 Couche de restitution: reporting
CIF vs DDW
 Dans DDW le data warehouse est basé
sur un modèle multidimensionnel alors
que dans CIF il est en 3FN
 Dans DDW, le DWH est accessible
directement par les utilisateurs alors
dans CIF, seuls les datamarts
 Dans CIF, les datamarts contiennent les
données agrégées alors dans DDW ils
contiennent les données détaillées.
 Integrateur Serveur OLAP
Metadonnées
autres
source
s
Extraction Analyse
Bdd Transform. Data Service Requêtes
opérationnelles Chargement Rapports
Rafraich.
Warehouse
Data mining

Data Marts

Données sources Stock. de données Moteur OLAP Outil interface

Analyse des besoins
Délimitation de l’entreprise
 Identifier l’entreprise qui a
besoin de l’entrepôt
 Regrouper les besoins par
corps de métier
Comprendre les opérations
 Événement: activité qui arrive de
manière répétitive à des unités de
temps
 Statut: condition à vérifier par un objet à
un instant donné
 Niveau: mesure quantitative d’un objet à
un temps donné
 Rôle: celui qui déclenche un événement
Besoins fonctionnels
 Discuter avec les décideurs
 Identifier ce que le système est sensé
faire
 Classer les fonctions par priorité
Besoins fonctionnels
 À partir de l’entrepôt de données intégrant l’ensemble des faits et
dimensions constitutif des processus métier, une analyse doit être
réalisée pour identifier les éléments nécessaires aux analystes (pour
construire les datamarts, agrégats et autres cubes)
 Que voulez vous analyser ?  Faits
 Quels sont vos critères d'analyse ?  Dimensions
 Jusqu'à quel niveau de détail voulez vous aller ?
 Mesures dans les faits
 Attributs des dimensions
Besoins non fonctionnels
 Besoins utilisateurs
 Dépendent des systèmes sources
 Gestion et déroulement du projet
 Standard des technologies
 Architecture
faisabilité
 Explorer les sources
 Comprendre les structures de données
 Comprendre les données en listant les
risques de données principales et en les
analysant
 Où sont stockées les données et comment y
accéder
 Déterminer la possibilité de livrer le
projets suivant les besoins
Modélisation

« Un modèle est la représentation d’un objet, d’un système ou d’une

idée sous une forme quelconque autre que celle de l’entité
représentée elle-même. Sa fonction est de nous aider à expliquer, à
comprendre, ou à améliorer un système. Le modèle d’un objet peut
être une réplique exacte de cet objet (bien qu’exécutée dans un
matériau différent et à une échelle différente), ou une abstraction
des propriétés saillantes de l’objet. »
But
L’activité de l’utilisateur décisionnel est la recherche de mesures
déterminées par des corrélations et des consolidations sur
des ensembles de données définis indépendamment des
modalités actuelles du fonctionnement de l’entreprise.
 Définir les dimensions, niveaux, faits,…
 élaborée sur des données secondaires, ou dérivées, résultant
d’opérations de consolidation effectuées sur les données
primaires
 les bases de données décisionnelles contiennent
généralement des données calculées et ne conservent pas
toujours trace de chaque opération élémentaire
 il résulte généralement d’un compromis entre les besoins et
les coûts de stockage
Modélisation des SID
 Influences :
 les structures opérationnelles dans lesquelles le SID
puise ses données ;
 les modalités de fonctionnement des outils de gestion
et de présentation.
Les seules bases sur lesquelles il convient de
s’appuyer pour spécifier les objectifs du SID
sont les vues externes des utilisateurs. Ces
vues doivent donc être collectées et intégrées
dans le modèle
Conception d’un entrepôt
Entrepôt de données
 Construction de la base de données décisionnelle :
 Modélisation conceptuelle des données multiformes et
multisources
 Alimentation de l!entrepôt (extraire, nettoyer, transformer,
charger)
 Stockage physique des données
 Sélection des données à analyser :
 Besoins d!analyse de l!utilisateur
 Data mart
 Cubes multidimensionnels
 Tableaux ou tables bidimensionnels
 Analyse des données :
 Stastiques et reporting, OLAP, Data Mining
Entrepôt de données
Dimension
 Regroupement de données faisant
partie d’un domaine sémantique et
d’un même domaine d’analyse
 Peut être soit un niveau, soit une
hiérarchie
 Permet de répondre aux questions:
quand?, quoi?, où?, qui?, sous quelles
conditions?
Niveau
 Ensemble d’objets partageant les
mêmes caractéristiques
 Classe, entité
 Notion ayant un sens métier et digne
d’intérêt pour le reporting et l’analyse
 Caractérisé par un ensemble d’attributs
 Possède un identifiant
 Possède des membres
Hiérarchies
 Ensemble de niveaux reliés par les
relations hiérarchiques
 Une dimension peut être constitué
d’une ou plusieurs hiérarchies
 Une relation hiérarchique relie un
niveau parent (1) à un niveau enfant (N)
 Navigation (drill up, drill down) permet
de parcourir la hiérarchie
Gestion du temps
 aucune information ne peut être tirée d’un entrepôt
de données sans avoir recours à une association
sémantique avec le temps, et qui n’aurait pas de
sens dans un environnement purement
opérationnel.
 Intégrer le temps sous forme d’entités spécialisées,
et non pas sous forme de dates distribuées comme
des propriétés ordinaires dans diverses entités
 l’instant doit être désigné explicitement, ce qui a
pour effet de « sortir » des entités toutes les
caractéristiques sujettes à des variations dans le
temps
Gestion du temps
 Modification des associations au fil du
temps
 Modification des valeurs des attributs
d’un niveau
 Prendre en compte les modifications
temporelles de relation entre membres
de hiérarchies
Gestion du temps de type 0
Attribut n’est jamais modifé
Aucune gestion temporelle
Souvent appliquée aux
dates
Gestion du temps de type 1
 Lorsqu’un membre parent ou un attribut
d’un niveau changent de valeur, on
analyse la relation factuelle avec la
nouvelle valeur
 L’ancienne valeur est tout simplement
remplacée par la nouvelle; modification de
l’historique
 Reproduction des résultats potentiellement
différents à des dates différentes
Gestion du temps de type 2
 Conserver les anciens enregistrements
avec l’ancienne valeur
 Créer un nouvel enregistrement avec la
nouvelle valeur
 Pas de modification de l’historique
Gestion du temps de type 3
 Laisser la possibilité d’analyser suivant l’
ancienne valeur et suivant la nouvelle
valeur
 souvent utilisée pour gérer les
changements basés des dimensions
basées sur l’organisation de l’entreprise
Fait – relation factuelle
 Ensemble d’évènements ou de
situations
 Caractérisé par des indicateurs qui
mesurent les évènements représentés
par la relation factuelle
 Associé à des dimensions et Propre à un
processus métier
 Nommé en fonction du processus métier
référencé
Fait –relation factuelle (grain)
 Niveau de détail d’une relation
 Constitué d’un ensemble de niveaux
auxquels la relation est associée
 Équivalent à la notion d’identifiant
 N’inclure que les niveaux nécessaires
dans la définition du grain
Fait –relation factuelle (Niveau)
 Peut être associé plusieurs fois au
même niveau (préciser les rôles)
 Ne peut être associé à des niveaux
différents d’une même hiérarchie
 En général, la cardinalité entre niveau
et fait est 1..1
 Quelques cas rares de 0..N ou 1..N
relation factuelle (indicateurs)
 Représentent les mesures associés au
fait
 Valeur numérique servant à
quantifier, mesurer les faits
 Valeurs pouvant être agrégées
suivant les dimensions (somme,
moyenne, max, min)
relation factuelle (indicateurs)
 Additif: lorsque les valeurs peuvent
être agrégées sur l’ensemble des
dimensions suivant la somme
 Semi-additif: lorsque les valeurs
peuvent être agrégées sur l’ensemble
des dimensions sauf le temps (stock,
niveau)
 Non additif: ni additif, ni semi additif
(PU)
Conseils
 Toujours avoir une dimension
temporelle dans une relation factuelle
 Assurer la conformité des dimensions
de l’ensemble
 Assurer la conformité des indicateurs
 Définir un modèle unique pour
l’ensemble des activités de l’entreprise
 Définir le grain le plus fin possible
Conseils
 Définir un grain unique pour
l’ensemble des faits d’une relation
factuelle
 Utiliser les dimensions correspondant
à un réel concept métier
 Faire de sorte que chaque indicateur
soit pertinent pour l’ensemble des
dimensions associés
Entrepôt de données
 Fait
 table qui contient des informations
opérationnelles et qui relatent la vie de
l'entreprise (CA, stock,…)
 ce qu'on voudra analyser.
 Dimension
 Axe sur lequel on veut faire l’analyse
(produits, clients, magasins,…)
 ce qu'on utilisera pour faire nos
analyses
 Faits et dimensions
 Une méthode de modélisation
faits/dimensions part du processus
métier analysé vers l’analyse :

 Identification du processus métier analysé

 Établissement du niveau de granularité de l’analyse
 Établissement des dimensions qui s’appliquent à chaque ligne de
fait
 Identification des caractéristiques numériques qui s’appliquent à
chaque ligne de fait
Faits et dimensions
méthode demande une vision complète et décrite du
processus métier et de son implémentation
de construire le tableau qui croise les processus métier (et
les différentes étapes des processus métier) et les
dimensions :

Processus\ Dimension Date Entrepôt Produit Magasin Promotion

Vente au détail X X X X
Stock entrepôt X X X
Commande X X X

3
Concevoir le DW
 Export de données des sources
 Hétérogènes et variées
 Fichiers, BD patrimoniales, Web, …
 Définition des vues exportées
 Définition d'un schéma global
 Intègre les données utiles
 S'appuie sur le modèle relationnel
 Nécessité d'une gestion de méta-données
 Description des sources
 Description des vues exportées
 Description du schéma global
Concevoir le DW
 Pour faciliter l’exploitation des données au
niveau de l’ED, le concepteur doit réaliser une
classification par sujets fonctionnels
plutôt que par applications (BD
opérationnelles)
 Une modélisation relationnelle est souvent
utilisée : chaque sujet correspondant à une
table gérée par l’ED
Concevoir le DW
 La définition des tables de l’ED nécessite :
 D’isoler les données stratégiques,
 de déterminer les informations de détail nécessaires,
 les résumés à conserver (généralement calculés par
des requêtes avec fonction d’agrégats)
Exemple : plutôt que de stocker chaque vente
élémentaire de produit à un client, on préfèrera
grouper les ventes par produit ou par couple
client-produit sur une semaine
Modélisation - analyse
 déceler les axes d'analyses (les dimensions)
avec leurs attributs ainsi que les éléments à
analyser (les faits).
 Étudier profondément ce qui se passe dans
l'entreprise : documents échangés, rapports
périodiques, interviews des personnes clés, étude
des besoins.
 Faire un processus métier, savoir comment les
analystes organisent leurs raisonnements, savoir
ce que voient les décideurs avant de décider,
connaître les indicateurs de bonne santé de
l'entreprise et de la concurrence.
Modélisation - analyse
 A se poser:
 Que voulez vous analyser ?
 Quels sont vos critères d'analyse?
 quel niveau de détail?
 Savoir :
 D'où provient chaque champ ?
 Comment transite l'information ?
 Où trouver l'information voulue?
 Établir les liens entre ce qu’on veut analyser
et les données
Datamart (Magasin de données)
 sous-ensemble de données [extrait du DW]
et ciblé sur un sujet unique Bases
multidimensionnelles
Data Warehouse

Bases de
production

Data Marts
SGBD
relationnel

Outils
Bases externes d’alimentation Bases
relationnelles
 Organisation par sujet
 Les données sont organisées par sujets majeurs:
 Clients, produits, ventes, …
 Sujet = faits + dimensions
 Collecte les données utiles sur un sujet
 Exemple: ventes
 Synthétise une vue simple des événements à analyser
 Exemple: Ventes (N°, produit, période, magasin, )
 Détaille la vue selon les dimensions
 Exemple: Produits(IDprod, description, couleur, taille,
…)
 Magasins (IDmag, nom, ville, dept, pays)
 Périodes (IDper, année, trimestre, mois, jour)
Modélisation
 Etoile
 Fait relié à des dimensions
 Flocon
 Hiérarchie des dimensions reliées aux
faits
 Datamart
 entrepôt réduit à une seule activité
 Représenté par une étoile ou un flocon
Modélisation - étoile
 La table des faits est centrale
 Chaque dimension est reliée à la table
des faits par son identifiant;
 La table de faits est reliée aux
dimensions par des relations (1, n).
 Les tables de dimension contiennent
les éléments qu'utiliseront les
décideurs pour voir la table de faits.
Modélisation - étoile
 On n'utilise JAMAIS la clé d'un système de
production comme clé de dimension : pour
préserver l'historique des modifications
dans l'entrepôt de données;
 La granularité des tables de dimensions et
de faits doit être la même;
 Chaque ligne de la table de faits doit avoir
une relation avec chacune des tables de
dimensions;
 Il n'existe de relations qu'entre les
dimensions et les tables de faits.
 Le schéma en étoile

 Une table de faits encadrées par N tables de

dimensions
Produits
 Exemple IDprod
Table de faits “ventes” description
Périodes couleur
IDper période
taille
année produit fournisseur
trimestre magasin
mois Magasins
jour unités_vendues IDmag
montant_ventes nom
ville
taxes_ventes département
pays
Modélisation - Flocon
 Même démarche que le modèle en étoile
avec les particularités:
 créer des hiérarchies de dimensions,
 avoir moins de lignes par dimensions
 décomposition des dimensions du modèle en
étoile en sous hiérarchies.
 conserver le fait et éclater les dimensions
conformément à sa hiérarchie des paramètres
 normalisation des tables de dimensions :
structure hiérarchique des dimensions et un
niveau inférieur identifie un niveau supérieur
Modélisation - Flocon
 avantages
 formaliser une hiérarchie au sein d'une
dimension.
 maintenance des tables de dimensions simplifiée
 réduction de la redondance
 Inconvénients :
 induit une normalisation des dimensions
générant une plus grande complexité en
 termes de lisibilité et de gestion.
 navigation coûteuse
Schémas en flocons
 Raffinement du schéma étoile avec des tables
normalisées par dimensions

Produits Fournisseurs
IDprod IDfour
description description
couleur type
taille Adresse
Ventes IDfour
 Avantages
 Évite les redondances
 Conduit aux constellations (plusieurs tables de
faits à dimensions partagées)
Conception du schéma intégré
 Isoler les faits à étudier
 Schéma des tables de faits
 Définir les dimensions
 Axes d'analyse
 Normaliser les dimensions
 Éclater en plusieurs tables liés par contraintes
référentielles
 Intégrer l'ensemble
 Plusieurs tables de faits partagent quelques tables de
dimension (constellation d’étoiles)
 Data Warehouse: Conception
 Une étoile (ou un flocon) ne représente qu’un fait
de l’entreprise
 Une fonction de l’entreprise peut comporter
plusieurs étoiles.
 un entrepôt de données est l'ensemble de ces
étoiles et/ou flocons.
Il se pose alors la question d’organisation de ces
étoiles et flocons pour constituer un bon entrepôt
ayant une vue globale de l’entreprise
Data Warehouse: Conception
 constellation
 série d'étoiles (de flocons) reliées entre
eux par des dimensions
 étoiles avec des dimensions en commun.
 possibilité de naviguer d'étoile en étoile,
de constellation en constellation et de
Data Mart en DataMart à la recherche de
l'information si précieuse.
 Data Warehouse: Conception
 Définir la finalité du DW :
 Quelle activité de l’entreprise faut-il piloter?
 Quel est le processus de l’entreprise à modéliser?
 Qui sont les décideurs?
 Quels sont les faits numériques?
 Qu’est ce qui va être mesurer?
 Quelles sont les dimensions ?
 Comment les gestionnaires décrivent-ils des données
qui résultent du processus concerné?
 Définir le modèle de données :
 Modèle en étoile / flocon ?
 et/ou Cube?
 et/ou Vues matérialisées?
Le data cube et les
dimensions
Le data cube et les dimensions
Axe d'analyse: La géographie
(Pays - région - ville)

Variables analysées:
Nb unités, CA, marge...

Axe d'analyse: Les produits

(classe, produit)

Axes d'analyse: dimensions

Axe d'analyse: Le temps Variables analysées: indicateurs
(Année, trimestre, mois, semaine)
 Cube de données
Localisation

i t
d u
P ro

Date
La granularité des dimensions

Temps Jours Mois Trimestres Années

Géographie Villes Régions Pays

Produits Numéros Types Gammes Marques

L'algèbre des cubes
 Roll up :
 Agréger selon une dimension
 Semaine  Mois
 Drill down :
 Détailler selon une dimension
 Mois  Semaine
 Slice et Dice:
 Sélection et projection selon 1 axe
 Mois = 04-2003 ; Projeter(Région, Produit)
 Pivot :
 Tourne le cube pour visualiser une face
 (Région,Produit)(Région, Mois)
Exemple
Exemple
 Opération Slice: sélection sur une
dimension du cube
Exemple
 Opération Dice :
Définition d’un sous-
cube par sélection sur
deux (ou plus)
dimensions
 – Ex : critère
(Localisation = Paris v
Rome) et (Date = 1er
trimestre v
2èmetrimestre) et
(Produit =
Informatique v
Téléphonie)
 Exemple
 Opération Pivot :
 présentation
alternative du cube
 Transformation en
une série de plans
2D
 Renversement du
cube sur un ou plus
axes pour une
vision alternative
 renversement sur
l’axe Date
 Exemple
 Opération Roll-up :
généralisation du cube ;
 Supprimer une
dimension
 Remonter dans une
hiérarchie de concepts
d’une dimension
 Ex : remonter du
niveau
 Trimestre au niveau
 Semestre pour Date
Exemple
 Opération Drill-
down : spécialisation
du cube.
 Ajouter une
dimension
 Ex : dimension
TypeClient
ou
 Descendre dans une
hiérarchie de
concepts
 Ex : descendre du
niveau Catégorie au
niveau Type pour
Produit
Stockage physique
 ROLAP: Relationnal OLAP
 MOLAP: Multidimensionnal OLAP
 HOLAP: Hybride OLAP
 ROLAP (SQL server)
 stockées sous la forme de tables
relationnelles.
 modélisées sous la forme d’étoile ou de
flocon.
 Traduction des requêtes multidimensionnelles
en requêtes relationnelles (SQL).
 Bonne capacité de stockage,
 requêtes sont difficiles à définir, à mettre en
œuvre et coûteuses.
 MOLAP (Oracle)
 Technologie de stockage
multidimensionnelle.
 Définition des index multidimensionnels
 Compression des données de faible
 écriture des requêtes de manière
intuitive et efficace.
 Redéfinition d’un langage de
manipulation des données