Cas pratiques Data Modeling

Contexte : Une startup e-commerce lance sa première plateforme de vente en ligne. Le Problème : Les données clients, commandes et produits sont stockées dans un seul tableau Excel, rendant les analyses et évolutions difficiles. Contraintes : Séparer les entités principales (clients, produits, commandes). Définir des clés primaires simples. Éviter toute redondance inutile. Rester dans un modèle relationnel classique. Livrable attendu : Proposer un schéma relationnel simple avec tables, clés primaires et relations entre clients, produits et commandes.

Contexte : Une bibliothèque municipale souhaite suivre les livres et les emprunts. Le Problème : Les emprunts ne sont pas tracés correctement et il est difficile de savoir quel livre est emprunté. Contraintes : Définir les entités livres, membres et emprunts. Permettre le suivi des dates d’emprunt et de retour. Maintenir un modèle relationnel clair. Livrable attendu : Proposer un schéma relationnel simple incluant les tables nécessaires et leurs relations.

Contexte : Une PME souhaite structurer sa base pour gérer clients, factures et paiements. Le Problème : Les informations sont actuellement dispersées et peu structurées. Contraintes : Identifier les entités principales. Définir relations entre clients et factures. Permettre le suivi des paiements partiels. Livrable attendu : Proposer un schéma relationnel simple décrivant les tables nécessaires et leurs clés.

Contexte : Une base contient une table orders où chaque ligne répète toutes les informations du client. Le Problème : Les données clients sont dupliquées dans chaque commande, provoquant incohérences lors des mises à jour. Extrait logique actuelle : orders(order_id, client_name, client_email, product_id, amount) Contraintes : Supprimer la redondance. Introduire une table dédiée aux clients. Maintenir l’intégrité référentielle. Livrable attendu : Proposer un modèle corrigé avec séparation claire entre clients et commandes, incluant clés primaires et étrangères.

Contexte : Une table unique stocke informations employé et département. Le Problème : Les données département sont répétées pour chaque employé, rendant les mises à jour complexes. Extrait actuel : employees(emp_id, emp_name, dept_name, dept_location) Contraintes : Séparer les entités employé et département. Maintenir une relation via clé étrangère. Livrable attendu : Proposer un modèle normalisé supprimant la redondance et améliorant l’intégrité des données.

Contexte : Une table products a été créée sans clé primaire. Le Problème : Plusieurs lignes identiques existent, rendant difficile l’identification unique d’un produit. Extrait actuel : products(name, price, category) Aucune colonne id définie. Contraintes : Introduire une clé primaire unique. Garantir l’unicité des produits. Maintenir la compatibilité avec les relations existantes. Livrable attendu : Proposer une modification du modèle ajoutant une clé primaire et assurant l’intégrité des données.

Contexte : Une table contient les colonnes order_id, product_id, product_name. Le Problème : product_name dépend uniquement de product_id, pas de order_id, créant une dépendance partielle. Extrait actuel : orders(order_id, product_id, product_name) Contraintes : Appliquer une normalisation minimale (3NF). Séparer les données produits dans une table dédiée. Livrable attendu : Proposer un modèle normalisé supprimant la dépendance fonctionnelle partielle.

Contexte : Une base tente de modéliser la relation entre étudiants et cours. Le Problème : Les cours sont stockés sous forme de liste dans une colonne unique de la table étudiants. Extrait actuel : students(id, name, courses_list) Contraintes : Remplacer la liste par une table d’association. Maintenir la possibilité pour un étudiant de suivre plusieurs cours. Livrable attendu : Proposer un modèle relationnel corrigé utilisant une table intermédiaire pour gérer la relation plusieurs-à-plusieurs.

Contexte : Une application permet de réserver des créneaux pour des salles de réunion. Le Problème : Aucune structure formelle ne permet d’éviter les conflits de réservation. Contraintes : Définir entités utilisateurs, salles et réservations. Permettre la gestion des dates et heures. Éviter les conflits logiques. Livrable attendu : Proposer un modèle relationnel simple décrivant les tables et leurs relations principales.

Contexte : Une école souhaite digitaliser la gestion des élèves, enseignants et cours. Le Problème : Aucune structure de données formelle n’est encore définie. Contraintes : Identifier les entités principales. Définir les relations (un enseignant peut enseigner plusieurs cours, un élève peut suivre plusieurs cours). Rester simple et cohérent. Livrable attendu : Proposer un modèle entité-association décrivant clairement les entités, attributs clés et relations principales.

Contexte : Une plateforme SaaS souhaite suivre les abonnements clients et leurs évolutions (changement de plan, résiliation). Le Problème : Le modèle actuel écrase les informations historiques. Contraintes : Intégrer une gestion des dates de validité (date_debut, date_fin). Permettre la conservation de l’historique des changements. Maintenir la cohérence des relations clients-abonnements. Livrable attendu : Proposer un modèle relationnel permettant le suivi temporel des abonnements.

Contexte : Une entreprise gère plusieurs entrepôts avec des niveaux de stock distincts par produit. Le Problème : Le modèle actuel ne permet pas de distinguer correctement les stocks par localisation. Contraintes : Introduire une entité entrepôt. Gérer la relation produit-entrepôt avec quantité disponible. Garantir cohérence des mises à jour. Livrable attendu : Proposer un modèle relationnel permettant un suivi précis des stocks par entrepôt.

Contexte : Votre entreprise souhaite mettre en place un data warehouse pour analyser les ventes par produit, client et période. Le Problème : Les données opérationnelles sont normalisées et peu adaptées aux requêtes analytiques complexes. Contraintes : Concevoir un schéma en étoile avec une table de faits des ventes et des dimensions (produit, client, temps). Définir clairement les clés substitutives. Optimiser pour la lecture analytique. Livrable attendu : Proposer un modèle dimensionnel complet incluant table de faits, dimensions et relations adaptées au reporting.

Contexte : Une table utilise l’adresse email comme clé primaire pour identifier un client. Le Problème : Les clients peuvent changer d’adresse email, ce qui compromet la stabilité des relations. Extrait actuel : customers(email PRIMARY KEY, name, phone) Contraintes : Introduire une clé substitutive stable. Maintenir l’unicité de l’email via contrainte unique. Livrable attendu : Proposer une refonte du modèle garantissant stabilité et intégrité des relations.

Contexte : Une table contient des informations dépendant transitivement de la clé primaire. Le Problème : Certaines colonnes dépendent d’attributs non-clés, violant la troisième forme normale. Extrait actuel : employees(emp_id, emp_name, dept_id, dept_name) Contraintes : Séparer les entités pour respecter la 3NF. Maintenir les relations via clés étrangères. Livrable attendu : Proposer une normalisation correcte supprimant les dépendances transitives.

Contexte : Un schéma en étoile a été mis en place pour analyser les ventes. Le Problème : Certaines colonnes métier ont été intégrées directement dans la table de faits, rendant le modèle peu flexible. Extrait logique actuelle : fact_sales(order_id, product_name, product_category, customer_city, amount) Contraintes : Séparer clairement faits et dimensions. Introduire des clés étrangères vers des dimensions dédiées. Livrable attendu : Proposer une restructuration du schéma respectant les principes du modèle dimensionnel.

Contexte : Une base modélise commandes et lignes de commande. Le Problème : Les lignes de commande ne possèdent pas de clé composite cohérente et peuvent exister sans commande valide. Extrait actuel : order_lines(line_id, product_id, quantity) Aucune référence claire à order_id. Contraintes : Introduire une clé étrangère vers la table orders. Définir une clé primaire cohérente (composite si nécessaire). Assurer l’intégrité référentielle. Livrable attendu : Proposer un modèle corrigé garantissant cohérence entre commandes et lignes associées.

Contexte : L’entreprise analyse ses ventes par pays, région et ville. Le Problème : La dimension géographique actuelle contient toutes les informations dans une seule table, rendant certaines analyses lourdes. Contraintes : Concevoir un schéma flocon en séparant pays, région et ville. Maintenir des relations hiérarchiques cohérentes. Livrable attendu : Proposer un modèle dimensionnel en flocon adapté aux analyses géographiques hiérarchiques.

Contexte : Plusieurs rapports nécessitent des analyses par jour, semaine, mois et trimestre. Le Problème : La table de faits contient uniquement une date brute sans hiérarchie temporelle. Contraintes : Concevoir une dimension temps avec hiérarchie complète (jour, semaine, mois, trimestre, année). Prévoir des attributs calendaires utiles. Permettre la réutilisation dans plusieurs faits. Livrable attendu : Proposer une structure complète de dimension temps adaptée à un data warehouse analytique.

Contexte : Les requêtes analytiques sur le data warehouse deviennent lentes. Le Problème : Le modèle actuel mélange tables transactionnelles et analytiques sans séparation claire. Contraintes : Identifier les tables à transformer en tables de faits et dimensions. Simplifier les jointures analytiques. Maintenir cohérence avec les données sources. Livrable attendu : Proposer une refonte dimensionnelle permettant d’améliorer les performances analytiques.

Contexte : Une application collecte des données structurées ainsi que des attributs dynamiques variables selon les clients. Le Problème : Le modèle strictement relationnel devient rigide face aux nouveaux attributs. Contraintes : Concevoir une structure hybride combinant tables relationnelles principales et stockage flexible (par exemple attributs clés-valeurs). Maintenir cohérence et performance. Livrable attendu : Proposer un modèle hybride équilibrant flexibilité et intégrité des données pour un système évolutif.

Contexte : Une application SaaS héberge les données de plusieurs clients (tenants) dans une même base. Le Problème : Le modèle actuel ne garantit pas une isolation stricte entre tenants. Contraintes : Introduire une gestion explicite du tenant_id dans les entités concernées. Garantir l’isolation logique. Prévoir la scalabilité. Livrable attendu : Proposer un modèle multi-tenant robuste assurant séparation stricte des données et cohérence des relations.

Contexte : Votre organisation intègre des données provenant de multiples systèmes hétérogènes (CRM, ERP, e-commerce) dans un data warehouse central. Le Problème : Le modèle dimensionnel actuel est difficile à faire évoluer face aux changements fréquents des sources. Contraintes : Concevoir une architecture Data Vault avec Hubs, Links et Satellites. Garantir traçabilité des sources et historisation complète. Préserver la scalabilité et l’auditabilité. Livrable attendu : Proposer un modèle Data Vault détaillé incluant les entités principales, clés techniques et stratégie d’historisation.

Contexte : Une dimension client évolue dans le temps (changement d’adresse, segment marketing). Le Problème : Les mises à jour écrasent les anciennes valeurs, empêchant les analyses historiques correctes. Extrait logique actuelle : dim_customer(customer_id, name, address, segment) Contraintes : Implémenter une stratégie SCD Type 2 avec dates de validité et indicateur actif. Maintenir cohérence avec la table de faits. Livrable attendu : Proposer une refonte de la dimension permettant une gestion complète des changements historiques.

Contexte : Le système transactionnel et le reporting utilisent la même base relationnelle. Le Problème : Les requêtes analytiques lourdes impactent les performances opérationnelles. Contraintes : Séparer modèle transactionnel (OLTP) et analytique (OLAP). Introduire un modèle dimensionnel dédié au reporting. Maintenir synchronisation cohérente. Livrable attendu : Proposer une architecture distinguant clairement OLTP et OLAP avec flux d’alimentation adapté.

Contexte : Une table gère des contrats avec dates de validité. Le Problème : Plusieurs enregistrements pour le même contrat ont des périodes qui se chevauchent, créant des incohérences. Extrait logique actuelle : contracts(contract_id, valid_from, valid_to, status) Contraintes : Garantir absence de chevauchement pour un même contract_id. Définir des règles d’intégrité temporelle. Livrable attendu : Proposer une modélisation et des contraintes assurant la cohérence des périodes temporelles.

Contexte : Une plateforme gère produits, promotions et canaux de distribution avec de multiples relations croisées. Le Problème : Les tables d’association génèrent une explosion combinatoire difficile à maintenir. Contraintes : Identifier les relations réellement nécessaires. Introduire des entités intermédiaires pertinentes. Maintenir cohérence métier. Livrable attendu : Proposer une restructuration du modèle réduisant la complexité relationnelle tout en conservant la flexibilité fonctionnelle.

Contexte : L’entreprise souhaite analyser à la fois les ventes quotidiennes et les prévisions mensuelles. Le Problème : Les deux jeux de données ont des granularités différentes et sont mal combinés dans le modèle actuel. Contraintes : Définir clairement les grains de chaque table de faits. Partager les dimensions communes. Éviter toute confusion de granularité. Livrable attendu : Proposer une architecture dimensionnelle cohérente intégrant plusieurs tables de faits avec granularités distinctes.

Contexte : Une entreprise doit tracer toutes les actions utilisateurs pour conformité réglementaire. Le Problème : Le modèle actuel ne conserve pas l’historique complet des événements. Contraintes : Concevoir une table d’événements générique. Inclure métadonnées (timestamp, utilisateur, type d’action). Garantir extensibilité et performance. Livrable attendu : Proposer un modèle événementiel structuré permettant audit complet et analyses ultérieures.

Contexte : Le data warehouse contient plusieurs milliards de lignes et les requêtes deviennent coûteuses. Le Problème : Le modèle n’est pas optimisé pour les accès fréquents sur certaines dimensions. Contraintes : Identifier les index ou partitions logiques nécessaires. Ajuster la granularité des faits. Maintenir cohérence analytique. Livrable attendu : Proposer une stratégie de modélisation adaptée aux très grands volumes avec optimisation structurelle.