Bonjour,
Je développe actuellement une application PHP permettant de gérer et synchroniser ses ventes sur eBay. Pour le moment j'ai conçu mon MCD.
Je souhaiterais un avis sur ce schéma.
Merci d'avance.
Bonjour,
Je développe actuellement une application PHP permettant de gérer et synchroniser ses ventes sur eBay. Pour le moment j'ai conçu mon MCD.
Je souhaiterais un avis sur ce schéma.
Merci d'avance.
Bonsoir alainyvan,
Votre diagramme est plutôt un MCD qu’un MLD. Attention, l’association VENDRE est une ternaire, elle donnera lieu au stade SQL à l’instruction du genre de celle-ci :
C'est-à-dire que la référence du produit et son prix dépendent non seulement de l’entreprise (fournisseur ?), mais aussi de l’utilisateur (client ?). Est-ce bien ce que vous voulez ?CREATE TABLE VENDRE ( Id_entreprise INT NOT NULL , Id_produit INT NOT NULL , Id_utilisateur INT NOT NULL , Quantite INT NOT NULL , Prix DECIMAL(7,2) NOT NULL , Ref VARCHAR NOT NULL , CONSTRAINT VENDRE_PK PRIMARY KEY (Id_entreprise, Id_produit, Id_utilisateur) , ... ) ;
(a) Faites simple, mais pas plus simple ! (A. Einstein)
(b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
=> La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)
__________________________________
Bases de données relationnelles et normalisation : de la première à la sixième forme normale
Modéliser les données avec MySQL Workbench
Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.
Bonjour,
Ce qui parait étonnant c'est la liaison avec l'utilisateur sur l'association VENDRE. L'utilisateur achète, et a sûrement du passer une COMMANDE avant. Seul l'entreprise VEND (si j'ai bien compris le rôle de celle-ci)
Effectivement il s"agit d'un MCD (petite confusion de terminologie lors de la redaction du message).
L'association vendre représente les annonces en cours pour un utilisateur sur un site de vente.
Dans ce cas je te conseillerais de renommer l'association, car vendre correspond à un action bien précise concernant des informations différentes.
De même, essaye de faire des associations entre seulement deux entités si tu en as la possibilité.
PS: au niveau du MCD on parle d'entité et pas de tables. Nous en sommes encore au stade de la conception.
Si je ne fait pas d'erreur, l'association Vendre est ternaire si je l'utilise pour indiqué les produits vendus actuellement pour un utilisateur donnée sur un site de vente (comme eBay).
Quel nom pourrais-je utilisé à la place de Vendre ?
Dans ce cas on aurais quelque chose du genre:
[Vendeur]-----(vend)-----[Produit]------(achète)-----[Consommateur]
?
Bonsoir alainyvan et ZenZiTone,
Je répète, selon votre MCD, la référence du produit et son prix sont fixés par l’utilisateur...
Il faudrait que vous précisiez une bonne fois pour toutes le rôle des acteurs :
Un utilisateur représente-t-il un client ou un vendeur ? Participe-t-il à la détermination des prix et des références ?
Une entreprise représente-t-elle un client ou un vendeur ? Détermine-t-elle les quantités ?
L’association VENDRE est porteuse d’un attribut (propriété) Quantité : s’agit-il de la quantité disponible dans le stock ?
Bref, illustrez par l’exemple.
Pour être précis, on parle de type d'entité (ou entité-type). L’entité est à l’entité-type ce que la ligne est à la table et, en logique, la proposition au prédicat.
Exemple de prédicat conforme au MCD proposé, mais vraisemblablement pas à la réalité :
Pour un produit P, l’entreprise E et l’utilisateur U déterminent la référence de P, son prix et la quantité (en stock ?)
Exemple de propositions (vraies ou fausses) pour ce prédicat, mais conformes au modèle donc valides pour la base de données (disons SQL) :
Alainyvan : qu’en est-il ?Entreprise Utilisateur Produit Référence Prix Quantité Ets Naudin Fernand Calva r01 100 10 Ets Naudin Raoul Calva r01 200 10 Ets Naudin Paul Calva r01 150 5 Ets Naudin Fernand Pastis r01 150 5
(a) Faites simple, mais pas plus simple ! (A. Einstein)
(b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
=> La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)
__________________________________
Bases de données relationnelles et normalisation : de la première à la sixième forme normale
Modéliser les données avec MySQL Workbench
Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.
Une entreprise représente un site de vente (eBay, Priceminister, ...)
Un utilisateur est une personne pouvant acheter un produit sur Priceminister et le vendre sur eBay.
Le prix et la quantité sont ceux fixé par l'utilisateur sur son annonce eBay.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5 entreprise | utilisateur | produit | référence | prix | quantité ebay | utilisateur 1 | Samsung SSD 850 PRO 512 Go | 171708932385 | 295,95 | 1 ebay | utilisateur 1 | Crucial Ballistix Tactical LP 4 Go DDR3 1600 MHz CL8 | 181608685204 | 38,35 | 1 ebay | utilisateur 1 | Intel Core i5-3340 (3.1 GHz) | 181608791203 | 177,45 | 1
La référence correspond à la référence retourné par eBay via son API.
L'utilisateur participe à la détermination du prix et de la quantité (valeur qu'il fixe pour son annonce). Quand à la référence, elle correspond à l'identifiant de l'annonce après sa création.
Peux t-on considérer que l'utilisateur détermine la référence ?
Cette table est un copie des annonces en cours sur un site de vente.
Bonsoir alainyvan,
Vous traitez des sites eBay et PriceMinister, mais vu la cardinalité maximale N de la patte connectant ENTREPRISE et VENDRE dans votre MCD, je suppose que la liste des sites n’est pas limitée.
Les propositions suivantes sont-elles possibles à la fois :
Le 15/06/2015, l’utilisateur Fernand propose le produit Samsung SSD 850 PRO 512 Go sur eBay, en quantité 10 et au prix unitaire de 295,95 euros ;
A la même date, Fernand propose aussi le produit Samsung SSD 850 PRO 512 Go sur PriceMinister, là encore en quantité 10 et au prix unitaire de 295,95 euros ;
eBay affecte à cette proposition la référence 123. Effet du hasard, PriceMinister affecte aussi une référence 123.
Dans la base de données, la situation serait alors la suivante :
Entreprise Utilisateur Produit Réf Prix Qté Date ------------- ----------- -------------------------- --- ------ --- ---------- eBay Fernand Samsung SSD 850 PRO 512 Go 123 295,95 10 15/06/2015 PriceMinister Fernand Samsung SSD 850 PRO 512 Go 123 295,95 10 15/06/2015
Règles de gestion des données correspondantes :
(RG1) Pour une entreprise, un utilisateur, un produit et une date donnés, il y a exactement une référence, un prix unitaire et une quantité.
(RG2) Pour une entreprise et une référence données, il y a exactement un utilisateur, un prix unitaire, une quantité et une date.
Ce qui suit est-il possible :
(RG3) Si Fernand propose le lendemain à nouveau du Samsung SSD 850 PRO 512 Go, toujours en quantité 10 et au prix unitaire de 295,95 euros, chez eBay et chez PriceMinister, ces entreprises attribueront de nouvelles références.
Si c’est possible, les propositions seraient par exemple celles-ci :
Je ne connais rien au mode de fonctionnement de PriceMinister et d’eBay, à vous de valider ce que j’ai écrit.Entreprise Utilisateur Produit Réf Prix Qté Date ------------- ----------- -------------------------- --- ------ --- ---------- eBay Fernand Samsung SSD 850 PRO 512 Go 123 295,95 10 15/06/2015 PriceMinister Fernand Samsung SSD 850 PRO 512 Go 123 295,95 10 15/06/2015 eBay Fernand Samsung SSD 850 PRO 512 Go 345 295,95 10 16/06/2015 PriceMinister Fernand Samsung SSD 850 PRO 512 Go 234 295,95 10 16/06/2015
Dans ce qui précède, je n’ai évoqué que les ventes effectuées par Fernand, ses achats n’interviennent pas.
Je suppose que Fernand peut vendre sur un site sans jamais n’avoir rien acheté quoi que ce soit sur ce site.
Je suppose encore que Fernand peut avoir acheté un produit sur un site de vente et le revendre sur le même site.
Plausible ?
(a) Faites simple, mais pas plus simple ! (A. Einstein)
(b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
=> La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)
__________________________________
Bases de données relationnelles et normalisation : de la première à la sixième forme normale
Modéliser les données avec MySQL Workbench
Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.
Bonsoir alainyvan,
La date participe à l’identification, en conséquence de quoi la partie VENTE du MCD pourrait être la suivante :
MLD correspondant (notation PowerAMC) :
Vous noterez la présence dans la table VENTE d’une clé alternative {Id_entreprise, Reference}, qu’on ne sait pas exprimer dans un MCD (à moins de faire des acrobaties douteuses, et en définissant une entité-type REFERENCE). Cette clé signifie que pour une entreprise et une référence, on a un seul utilisateur, un seul produit, une seule date de création, un seul prix, une seule quantité. Êtes-vous d’accord avec cette clé alternative ?
Code SQL correspondant :
CREATE TABLE ENTREPRISE ( Id_entreprise INT NOT NULL, Nom_entreprise VARCHAR(64) NOT NULL, Url_entreprise VARCHAR(64) NOT NULL, CONSTRAINT ENTREPRISE_PK PRIMARY KEY (Id_entreprise), CONSTRAINT ENTREPRISE_AK UNIQUE (Url_entreprise) ) ; CREATE TABLE PRODUIT ( Id_produit INT NOT NULL, Titre_produit VARCHAR(64) NOT NULL, Description_produit VARCHAR(64) NOT NULL, CONSTRAINT PRODUIT_PK PRIMARY KEY (Id_produit) ) ; CREATE TABLE UTILISATEUR ( Id_utilisateur INT NOT NULL, Nom_utilisateur VARCHAR(64) NOT NULL, CONSTRAINT UTILISATEUR_PK PRIMARY KEY (Id_utilisateur) ) ; CREATE TABLE VENTE ( Id_utilisateur INT NOT NULL, Id_produit INT NOT NULL, Id_entreprise INT NOT NULL, DateCreation DATETIME NOT NULL, Reference INT NOT NULL, Prix DECIMAL(7,2) NOT NULL, Quantite INT NOT NULL, CONSTRAINT VENTE_PK PRIMARY KEY (DateCreation, Id_utilisateur, Id_entreprise, Id_produit), CONSTRAINT VENTE_AK UNIQUE (Reference, Id_entreprise), CONSTRAINT VENTE_UTILISATEUR_FK FOREIGN KEY (Id_utilisateur) REFERENCES UTILISATEUR (Id_utilisateur), CONSTRAINT VENTE_ENTREPRISE_FK FOREIGN KEY (Id_entreprise) REFERENCES ENTREPRISE (Id_entreprise), CONSTRAINT VENTE_PRODUIT_FK FOREIGN KEY (Id_produit) REFERENCES PRODUIT (Id_produit) ) ;
Quel est votre SGBD ?
(a) Faites simple, mais pas plus simple ! (A. Einstein)
(b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
=> La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)
__________________________________
Bases de données relationnelles et normalisation : de la première à la sixième forme normale
Modéliser les données avec MySQL Workbench
Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.
Bonsoir alainyvan,
Tout dépende de la façon dont vous voulez suivre les modifications :
— Annule et remplace bestial, peu importe de qui est modifié, auquel cas cette date peut figurer dans l’association VENTE ;
— Suivi par attribut (historique) : référence, prix, quantité : ça a un impact non négligeable sur la modélisation.
Quelle est votre option ?
(a) Faites simple, mais pas plus simple ! (A. Einstein)
(b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
=> La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)
__________________________________
Bases de données relationnelles et normalisation : de la première à la sixième forme normale
Modéliser les données avec MySQL Workbench
Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.
La date de modification est mise à jour à chaque synchronisation pour une vente donnée.
Qu'entendez-vous par « synchronisation pour une vente donnée » ?
(a) Faites simple, mais pas plus simple ! (A. Einstein)
(b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
=> La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)
__________________________________
Bases de données relationnelles et normalisation : de la première à la sixième forme normale
Modéliser les données avec MySQL Workbench
Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.
Chaque vente correspond à une annonce sur un site de vente.
La date de modification doit correspondre à celle que possède le site de vente.
Dans le cas contraire cela indique une modification de la vente (ou plutôt de l'annonce) non synchronisée avec le site.
Comment modélisez-vous la date de modification que possède le site de vente ? Est-ce la date de modification qui figure dans l’association VENDRE de votre MCD ? (Cf. votre 1er message).
Est-ce là aussi la date de modification qui figure dans l’association VENDRE de votre MCD ?
On nage dans l’ambiguïté. Le mieux serait que vous illustriez par des exemples tirés de la réalité : Un utilisateur souhaite que soit modifiée une quantité et/ou un prix, quelles sont les conséquences ?
(a) Faites simple, mais pas plus simple ! (A. Einstein)
(b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
=> La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)
__________________________________
Bases de données relationnelles et normalisation : de la première à la sixième forme normale
Modéliser les données avec MySQL Workbench
Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.
(a) Faites simple, mais pas plus simple ! (A. Einstein)
(b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
=> La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)
__________________________________
Bases de données relationnelles et normalisation : de la première à la sixième forme normale
Modéliser les données avec MySQL Workbench
Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager