Aller au contenu
Apprendre.
  • M1 · toutes les matières15 matières : Préparation de données, API & sécurité, CI/CD, Docker, Merise, Dataviz, KNIME, ML appliqué : projet LoL, SQL & UML, SQL avancé, Machine Learning, Git, IA frugale & responsable, Qualité des données, MathématiquesAnnée
  • M2 · toutes les matières4 matières : Deep Learning, AI Act, Comex & Fundraising, Gouvernance & DataMeshAnnée
  • Deep LearningM2 · 4 modules · Réseaux de neurones, CNN, texte, modèles génératifs.Matière
  • Préparation de donnéesM1 · 3 modules · Nettoyer, transformer et fusionner des données avec Python.Matière
  • API & sécuritéM1 · 2 modules · Consommer, concevoir et sécuriser des API.Matière
  • CI/CDM1 · 1 module · Intégration et livraison continues.Matière
  • DockerM1 · 3 modules · Conteneurs, images, volumes, réseaux, Compose.Matière
  • MeriseM1 · 2 modules · Modéliser une base : MCD, MLD, MPD.Matière
  • DatavizM1 · 2 modules · Visualiser pour comprendre et décider.Matière
  • KNIMEM1 · 1 module · Explorer et nettoyer des données en workflow.Matière
  • ML appliqué : projet LoLM1 · 2 modules · Du besoin métier au POC de vision par ordinateur.Matière
  • SQL & UMLM1 · 3 modules · Modèles UML et requêtes SQL.Matière
  • SQL avancéM1 · 3 modules · Jointures, fenêtres, CTE, optimisation.Matière
  • Machine LearningM1 · 3 modules · Régression, classification, segmentation, projet.Matière

↑↓ naviguer↵ ouvre le résultat en surbrillanceesc fermer

Partie 2 · MLD et normalisation

Cas TP2 : le MLD de la marketplace

Le TP2 exige que le MLD permette : le figement du prix payé, le paiement multiple/tentatives, la livraison en plusieurs colis avec contenu, les retours/remboursements partiels et la conservation de l'adresse de commande. Une solution possible (exemple ajouté) :

PRODUIT (id_produit PK, sku UNIQUE NOT NULL, titre, description, categorie)
VENDEUR (id_vendeur PK, raison_sociale, email UNIQUE NOT NULL, actif)
OFFRE (id_offre PK, id_vendeur FK, id_produit FK, prix, stock, delai,
       UNIQUE (id_vendeur, id_produit))
CLIENT (id_client PK, nom, email UNIQUE NOT NULL)
ADRESSE (id_adresse PK, id_client FK, type, rue, cp, ville)
CODE_PROMO (id_code PK, code UNIQUE NOT NULL, type, valeur, debut, fin)
COMMANDE (id_commande PK, id_client FK NOT NULL, date, statut,
          adr_livraison_rue, adr_livraison_cp, adr_livraison_ville,
          id_code FK NULL, remise_appliquee)
LIGNE_COMMANDE (id_commande FK, num_ligne, id_offre FK NOT NULL,
          quantite, prix_unitaire, PK (id_commande, num_ligne))
PAIEMENT (id_paiement PK, id_commande FK NOT NULL, date, montant, moyen,
          statut, ref_transaction)
COLIS (id_colis PK, id_commande FK NOT NULL, transporteur, suivi, statut)
COLIS_LIGNE (id_colis FK, id_commande, num_ligne, quantite,
          PK (id_colis, id_commande, num_ligne))
RETOUR (id_retour PK, date_demande, motif, statut)
RETOUR_LIGNE (id_retour FK, id_commande, num_ligne, quantite_retournee)
REMBOURSEMENT (id_remb PK, id_retour FK NOT NULL, date, montant, statut)

Vérifie que tu as compris

Comment ce MLD fige-t-il le prix payé ?

Choix à expliquer

  • Adresse figée : l'adresse est copiée dans la commande ; ADRESSE peut être modifiée sans toucher aux commandes passées.
  • Colis ↔ lignes : COLIS_LIGNE porte la quantité, pour un colis partiel d'une ligne.
  • Retours partiels : RETOUR_LIGNE désigne la ligne et la quantité retournée.
  • Ligne → offre : on sait quel vendeur doit expédier quoi.
  • Historique des statuts : « l'historique des statuts (ou au minimum l'état actuel + date de mise à jour) ». Ici, état actuel ; pour l'historique complet : table de journal (colis, statut, date).
  • Promo : remise_appliquee sur la commande garde la remise réelle même si le code change.

Attention (hors cours) : COLIS_LIGNE référence la ligne via sa PK composée (id_commande, num_ligne) : la FK est composée. Un id technique sur LIGNE_COMMANDE la simplifierait, avec un UNIQUE (id_commande, num_ligne).

Vérifie que tu as compris

Que protège la colonne remise_appliquee dans COMMANDE ?