Cas TP3 : diagnostiquer et corriger un MLD

Le TP3 donne deux contextes : location de véhicules (problèmes : incohérences sur les véhicules, tarifs difficiles à mettre à jour, anomalies d'historique) et vente B2B de matériel informatique (incohérences de chiffre d'affaires, ventes historiques difficiles à reconstituer, erreurs de mise à jour produit). Les MLD eux-mêmes sont des images absentes du texte source : les schémas ci-dessous sont donc des exemples ajoutés, dans l'esprit de ces contextes.

Méthode en 4 étapes

1. Pour chaque table, note la PK et liste les dépendances fonctionnelles.
2. Test 1NF : toutes les valeurs sont-elles atomiques ?
3. Test 2NF : un attribut dépend-il d'une partie de la clé ?
4. Test 3NF : un non-clé détermine-t-il un autre non-clé ? Puis décompose.

Exemple A : location (exemple ajouté)

RESERVATION (id_resa PK, client_nom, client_email, immat, modele,
             categorie, tarif_jour, date_debut, date_fin)

Dépendances : immat → modele, categorie ; categorie → tarif_jour. Clé simple, donc 2NF ok ; mais immat → modele (non-clé → non-clé) et categorie → tarif_jour : violations de 3NF. Correction : CLIENT, VEHICULE (immat PK, modele, id_categorie FK), CATEGORIE (id_categorie PK, tarif_jour), RESERVATION (id_resa PK, id_client FK, immat FK, dates).

Exemple B : B2B (exemple ajouté)

LIGNE (id_commande, id_produit, quantite, nom_produit, categorie,
       prix_catalogue, PK (id_commande, id_produit))

nom_produit, categorie, prix_catalogue dépendent d'id_produit seul : 2NF violée. Correction : PRODUIT(id_produit, nom, id_categorie) et LIGNE(id_commande, id_produit, quantite, prix_unitaire_applique).

Les contextes du TP3 insistent : « garantir la cohérence des données dans le temps ». La normalisation ne doit pas écraser l'historique : si le prix ou la catégorie évolue, les ventes passées doivent garder la valeur d'alors (prix figé, ou table d'historique datée).