Bonsoir Nino,
Vous avez bossé ! 
Le MCD est effectivement plus orienté gérant du magasin (exeunt les ventes et naissent les commandes et les livraisons).
Quelques remarques concernant la partie Clients.
Entité-type ARTICLE
Vous n’avez toujours pas défini d’attribut pour la référence de l’article. Je vous engage vivement à le faire.
Les attributs prix_vente_htva et prix_vente_htva_depuis sont redondants : n’en conserver qu’un. Même remarque concernant les attributs taux_tva et taux_tva_depuis.
Attribut marque_article : Les marques devraient faire l’objet d’une entité-type :
[MARQUE_ARTICLE]---0,N---(X)---1,1---[ARTICLE]
Historique des prix de vente des articles et des taux tva :
D’accord. Je vois que vous avez de saines lectures ! 
Si vous utilisez PostgreSQL comme SGBD, vous pouvez avantageusement utiliser le type daterange, et remplacer par exemple les attributs date_debut_prix_vente_htva et date_fin_prix_vente_htva par l’attribut periode_prix_vente_htva de type daterange, phagocytant la date de début et la date de fin. Voyez par exemple ici.
(Q8) Quel est votre SGBD cible ?
Entité-type CLIENT
Même remarque que pour ARTICLE : mettez en oeuvre le référencement des clients (attribut clientRef).
Entité-type REGLEMENT_CLIENT
(Q9) Cette entité-type ne fait référence à aucun client. Est-ce bien normal ?
L’attribut date_reglement ne devrait pas faire partie de l’identifiant de l’entité-type.
(Q9) Quel rôle joue l’attribut montant_paiement_fournisseur ?
Entité-type FACTURE_VENTE
Il devrait y avoir un attribut pour le numéro de facture. Une facture sans numéro ça n’est pas possible.
(Q10) Ce numéro est-il calculé à partir d’autres attributs ?
Il devrait y avoir un attribut pour la date de facture. Une facture sans date ça n’est pas possible.
(Q11) Cette date est-elle celle de la date de livraison, ou autre ?
Les lignes de facture ne sont pas modélisées.
(Q12) Comment les obtenez-vous ? A partir des lignes de livraison ? Tout ça paraît suspect et mérite des explications.
Entité-type LIVRAISON_CLIENT
(Q13) Pour une paire (commande, facture), peut-on avoir plus d’une livraison ?
Il manque la contrainte d’inclusion signifiant qu’il ne faut pas mélanger les factures du client C1 avec les livraisons du client C2 (mais ne perdez pas trop de temps avec ça, au stade SQL, ça ne se règle guère que manuellement).
Pour éviter les mélanges, il suffit d’identifier COMMANDE_CLIENT relativement à CLIENT, même chose pour FACTURE_VENTE, et au stade SQL ne conserver qu’un unique attribut id_client dans l’instruction CREATE TABLE LIVRAISON_CLIENT :
CREATE TABLE COMMANDE_CLIENT
(
clientId INTEGER NOT NULL
, commandeClientId INTEGER NOT NULL IDENTITY(1,1)
, commandeClientDate DATE NOT NULL
, commandeLivraisonDate DATE NOT NULL
, CONSTRAINT COMMANDE_CLIENT_PK PRIMARY KEY (clientId, commandeClientId)
, CONSTRAINT COMMANDE_CLIENT_CLIENT_FK FOREIGN KEY (clientId)
REFERENCES CLIENT (clientId)
) ;
CREATE TABLE FACTURE_VENTE
(
clientId INTEGER NOT NULL
, factureVenteId INTEGER NOT NULL IDENTITY(1,1)
, factureNo INTEGER NOT NULL
, factureDate DATE NOT NULL
, factureMtHt DECIMAL(7,2) NOT NULL
, factureMtTva DECIMAL(7,2) NOT NULL
, factureMtTtc DECIMAL(7,2) NOT NULL
, CONSTRAINT FACTURE_VENTE_PK PRIMARY KEY (clientId, factureVenteId)
, CONSTRAINT FACTURE_VENTE_AK UNIQUE (factureNo)
, CONSTRAINT FACTURE_VENTE_CLIENT_FK FOREIGN KEY (clientId)
REFERENCES CLIENT (clientId)
) ;
CREATE TABLE LIVRAISON_CLIENT
(
livraisonClientId INTEGER NOT NULL
, clientId INTEGER NOT NULL
, commandeClientId INTEGER NOT NULL
, factureVenteId INTEGER NOT NULL
, client_bl_date DATE NOT NULL
, client_bl_total DECIMAL(7,2) NOT NULL
, CONSTRAINT LIVRAISON_CLIENT_PK PRIMARY KEY (livraisonClientId)
, CONSTRAINT LIVRAISON_CLIENT_COMMANDE_FK FOREIGN KEY (clientId, commandeClientId)
REFERENCES COMMANDE_CLIENT (clientId, commandeClientId)
, CONSTRAINT LIVRAISON_CLIENT_FACTURE_FK FOREIGN KEY (clientId, factureVenteId)
REFERENCES FACTURE_VENTE (clientId, factureVenteId)
) ;
Association LIGNE_LIVRAISON_CLIENT
(Q14) Pourquoi les deux attributs quantite_livree_client et nombre_piece_livree_client ? N’y a-t-il pas redondance ?
Attribut Total_prix_quantite_livree : la valeur est calculable puisqu’on a la date de livraison et de là on sait retrouver le prix de vente d’un article dans ARTICLE (ou HISTORIQUE_PRIX_VENTE et HISTORIQUE_TAUX_TVA_VENTE).
Entité-type CARTE_FIDELITE
Supprimer l’attribut id_carte puisque, du fait de l’identification relative, l’identifiant est hérité de celui de CLIENT.
Si vous utilisez PostgreSQL, alors vous pouvez remplacer la date de début et la date de fin par la période (type daterange).
Dans les noms des objets SQL (tables, attributs, ...) évitez les lettres avec accent (é, è, ê, etc.)
Ne pas écrire Quantité_Commandée_Client , mais Quantite_Commandee_Client.
MCD Gestion d'un magasin de vente de détails
Répondre avec citation
Envoyé par nino04
, mais avec cette option vous ne pouvez pas faire l'économie de la définition de clés alternatives (futurs index) en déclarant "UNIQUE" les rubriques concernées (num_facture, num_ticket, num_carte, ...). Dans la même veine, il faut prévoir une référence article, car dans la logique que vous avez choisie, id_article ne correspondra pas à une information du SI.
: d'une façon générale les associations n-aires sont délicates à manipuler et nécessitent souvent la mise en œuvre de CIF.
Partager