Devoir Surveillé - Système d’Information Décisionnel

Questions de réflexion

Question 1 - Architecture de Kimball vs Inmon

La différence fondamentale entre l'architecture de Ralph Kimball et celle de Bill Inmon réside dans leur approche de construction et leur philosophie de structuration de la donnée :

• L'approche de Kimball (Bottom-Up / Ascendante) : Elle est centrée sur les processus métiers. On commence par construire des magasins de données (Data Marts) modélisés de manière dimensionnelle (en étoile ou en flocon) pour répondre aux besoins spécifiques des différents départements. L'entrepôt de données (Data Warehouse) n'est autre que l'union de ces Data Marts intégrés grâce à des dimensions communes appelées "dimensions conformes" (Architecture en bus).
• L'approche d'Inmon (Top-Down / Descendante) : Elle est centrée sur les données de l'entreprise. On construit d'abord un entrepôt de données d'entreprise (Enterprise Data Warehouse - EDW) centralisé, global et modélisé de manière relationnelle normalisée (généralement en 3ème forme normale, 3NF). Les Data Marts départementaux sont ensuite extraits et alimentés à partir de cet EDW central pour servir l'analyse décisionnelle.

Question 2 - Exemples de systèmes où l'entrepôt de données n'est pas conseillé

Un entrepôt de données est un système OLAP (Online Analytical Processing) optimisé pour l'historisation, l'agrégation et l'analyse de gros volumes de données. Sa mise en place n'est pas conseillée dans les cas suivants :

1. Les systèmes transactionnels temps réel critiques (OLTP pures) : Par exemple, un système de réservation de billets d'avion ou un système de gestion des urgences médicales.
   • Justification : Ces systèmes nécessitent un traitement immédiat à la seconde près, un accès en écriture massive, et des propriétés ACID strictes sur des transactions unitaires. Le Data Warehouse fonctionne par mises à jour par lots (batchs) et subit un temps de latence de rafraîchissement des données (souvent quotidien ou horaire), ce qui le rend incapable de piloter des opérations nécessitant un état des lieux instantané.
2. Les petites applications locales ou d'appoint à très faible volume de données : Par exemple, l'application de gestion de stock d'une petite boulangerie de quartier.
   • Justification : Le coût, la complexité architecturale (serveurs, flux ETL, modélisation) et la maintenance d'un entrepôt de données seraient disproportionnés par rapport au besoin. Une simple base relationnelle avec des requêtes SQL directes ou un tableur connecté suffisent pour générer les indicateurs nécessaires.

Question 3 - Dimension à évolution lente vs rapide

• Dimension à évolution lente (SCD - Slowly Changing Dimension) : C'est une dimension dont les attributs se modifient rarement ou de façon très occasionnelle dans le temps.
  • Exemple : La zone d'habitation d'un client. Un client déménage rarement. Ce changement peut être géré en écrasant l'ancienne valeur (SCD Type 1) ou en créant une nouvelle ligne pour conserver l'historique (SCD Type 2).
• Dimension à évolution rapide (Rapidly Changing Dimension) : C'est une dimension (ou un sous-ensemble d'attributs) qui subit des modifications très fréquentes. Les traiter comme des SCD classiques provoquerait une explosion du volume de la table dimensionnelle (inflation combinatoire).
  • Exemple : Le profil démographique et comportemental variable d'un client, comme sa tranche d'âge exacte couplée à sa tranche de revenus et son "score d'appétence" du mois en cours. Pour gérer cela, on sépare souvent les données statiques (nom, date de naissance) dans la dimension principale, et les attributs volatils dans une "mini-dimension" séparée.

Etude de CAS - Modélisation de l'entrepôt de données

Choix de la modélisation

Pour répondre aux besoins du DSI de la Poste Tunisienne, il faut suivre les événements générant des données. On identifie clairement deux processus métiers distincts (avec des métriques et des contextes différents) :

1. Les paiements (qu'ils soient par TPE ou par Internet, ils partagent la même logique de dépense auprès d'un tiers).
2. Les retraits d'espèces au DAB.

Le format le plus adéquat est donc un schéma en constellation (ou modèle en galaxie), composé de deux tables de faits partageant des dimensions conformes.

Définition des Dimensions

On applique le principe de dénormalisation propre aux modèles décisionnels pour optimiser les requêtes (schéma en étoile pour chaque fait).

• Dim_Temps
  • ID_Temps (Clé primaire)
  • Date_Complete
  • Jour
  • Semaine
  • Mois
  • Annee
• Dim_Client
  • ID_Client (Clé primaire)
  • Nom_Prenom
  • Zone_Habitation
  • Categorie_Socioprofessionnelle (ex: haut cadre, profession libérale...)
  • Employeur
  • Num_Telephone
  • Email
  • Succursale_Domiciliataire
  • Localisation_Succursale
• Dim_Carte (Séparée du client pour faciliter la gestion des remplacements de cartes)
  • ID_Carte (Clé primaire)
  • Numero_Carte
  • Type_Carte (Golden, Silver)
• Dim_Beneficiaire (Unifie les commerçants physiques et les prestataires internet)
  • ID_Beneficiaire (Clé primaire)
  • Identite_Beneficiaire (ex: Carrefour, Tunisie Telecom, STEG)
  • Secteur_Activite (ex: Prêt-à-porter, Télécommunications, Pharmaceutique)
  • Localisation_Geographique (pour les TPE, ou zone du prestataire)
  • Banque_Commercant
• Dim_Canal_Paiement
  • ID_Canal (Clé primaire)
  • Type_Canal (TPE, Internet)
  • Nature_Prestation (Achat physique, Paiement de factures, Réservation hôtels, etc.)
• Dim_DAB
  • ID_DAB (Clé primaire)
  • Localisation_DAB
  • Etablissement_Proprietaire (Poste, Banque X, etc.)

Définition des Tables de Faits

Fait_Paiement (Grain : un paiement unitaire effectué par un client)

• Clés étrangères : ID_Temps, ID_Client, ID_Carte, ID_Beneficiaire, ID_Canal
• Mesures : Montant_Paye

Fait_Retrait (Grain : un retrait unitaire effectué au DAB)

• Clés étrangères : ID_Temps, ID_Client, ID_Carte, ID_DAB
• Mesures : Montant_Encaisse

Validation du modèle face aux indicateurs demandés

Le tableau suivant démontre que le modèle répond à toutes les requêtes formulées par la direction :

Indicateur demandé	Résolution à partir du modèle proposé
CA par prestataires télécoms par mois et par zone	Fait_Paiement croisé avec Dim_Beneficiaire (Secteur='Télécommunications', Localisation), regroupé par Dim_Temps (Mois). Somme(Montant_Paye).
CA chaine Carrefour / Carrefour Express par région et par semaine	Fait_Paiement croisé avec Dim_Beneficiaire (Identite contient 'Carrefour', Localisation), regroupé par Dim_Temps (Semaine). Somme(Montant_Paye).
Répartition achats prêt à porter, région de la Soukra	Fait_Paiement croisé avec Dim_Beneficiaire (Secteur='Prêt à porter'). Filtre sur Dim_Client ou Dim_Beneficiaire (Localisation='Soukra'). Somme ou Compte des paiements.
Retraits en espèces banques proches de la succursale (cartes Gold)	Fait_Retrait croisé avec Dim_Carte (Type='Golden'), Dim_DAB (Etablissement != Poste), comparé avec la Localisation_Succursale de Dim_Client. Compte(Lignes).
Consommation moyenne mensuelle prof. libérales / hauts cadres (Mourouj) en pharmacie	Fait_Paiement croisé avec Dim_Client (Catégorie='Haut cadre' ou 'Profession libérale', Zone='El Mourouj'), Dim_Beneficiaire (Secteur='Produits pharmaceutiques'). Moyenne(Montant_Paye) par Mois (Dim_Temps).
Structure budget dépensé par professions libérales (El Manazeh)	Consolidation de Fait_Paiement (ventilé par secteurs via Dim_Beneficiaire) et Fait_Retrait pour la zone 'El Manazeh' et la catégorie 'Profession libérale' dans Dim_Client.
Proportion dépenses en espèces région du Bardo par catégorie	Fait_Retrait (proxy pour espèces) croisé avec Dim_Client (Zone='Le Bardo'). Somme(Montant_Encaisse) regroupée par Categorie_Socioprofessionnelle.

Méthode

Pour réussir l'épreuve de modélisation décisionnelle (Data Warehouse) :

1. Lire la cible avant les sources : Commencez toujours par lire les indicateurs métier finaux que le décideur (ici le DSI ou le responsable Marketing) souhaite obtenir. Les axes d'analyse de ces indicateurs (par mois, par région, par catégorie, par secteur) vous dictent précisément quelles dimensions créer et quels attributs y inclure. Les valeurs à agréger (chiffre d'affaires, moyenne de consommation, nombre) vous donnent vos mesures.
2. Identifier la granularité : Pour chaque table de faits, demandez-vous "Que représente exactement une ligne de cette table ?". Ici, le grain est la transaction individuelle (le paiement TPE à la seconde T, le retrait au DAB au temps T). C'est le niveau le plus fin possible, qui permet de répondre à n'importe quelle requête d'agrégation.
3. Séparer les processus métiers : Ne forcez pas des événements de nature différente dans une seule table de faits avec des colonnes vides (valeurs nulles). Un retrait DAB et un paiement Internet n'ont pas les mêmes attributs (un DAB n'a pas de secteur d'activité, un prestataire internet n'a pas d'agence physique). Optez systématiquement pour un schéma en constellation (plusieurs faits partageant des dimensions) lorsque le sujet comporte plusieurs verbes d'action distincts (acheter, retirer).
4. Dénormaliser sans scrupule : Contrairement aux bases de données transactionnelles (où on éviterait de répéter la ville pour une succursale), le modèle en étoile encourage l'aplatissement des hiérarchies. L'adresse de la succursale va directement dans la dimension Client ou dans une dimension Succursale plate pour éviter les jointures coûteuses lors de l'interrogation par le système OLAP.