Partie 2 · MLD et normalisation
Contraintes : PK, FK, UNIQUE, NOT NULL et MPD
Le TP2 liste les contraintes minimales attendues : unicité (email client, email vendeur, SKU produit, code promo), anti-doublons (offre vendeur-produit, inscriptions équivalentes), historique (prix payé, paiements, expéditions, retours/remboursements, adresse de commande) et cohérence temporelle (validité des codes promo, dates de suivi).
| Contrainte | Rôle | Exemple TP2 |
|---|---|---|
| PK | Identifie chaque ligne, jamais NULL | id_commande |
| FK | Impose qu'une référence existe | ligne_commande.id_commande |
| UNIQUE | Interdit un doublon métier | client.email, produit.sku, code_promo.code |
| NOT NULL | Valeur obligatoire | commande.id_client |
| CHECK (hors cours) | Règle sur une valeur | date_fin >= date_debut ; quantité > 0 |
Vérifie que tu as compris
PK composée ou id technique ?
Le TP2 cite ce choix à justifier. PK composée (ex. offre = (id_vendeur, id_produit)) : l'anti-doublon est automatique, mais les clés étrangères qui la référencent deviennent composées. Id technique : simple à référencer, mais il faut ajouter UNIQUE (id_vendeur, id_produit) sinon le doublon revient. Dans les deux cas, l'unicité métier doit exister.
Suppression logique
« Un vendeur peut être désactivé sans suppression de l'historique » : une colonne d'état (actif) plutôt qu'un DELETE, qui serait refusé ou casserait les FK des commandes et colis.
MPD (hors cours)
Le physique choisit les types du SGBD et les index. Pour l'argent, un type décimal exact, pas un flottant. Exemple :
CREATE TABLE offre ( id_vendeur INTEGER NOT NULL REFERENCES vendeur(id_vendeur), id_produit INTEGER NOT NULL REFERENCES produit(id_produit), prix DECIMAL(10,2) NOT NULL CHECK (prix >= 0), stock INTEGER NOT NULL DEFAULT 0, PRIMARY KEY (id_vendeur, id_produit) );
Vérifie que tu as compris