Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Gestion vente informatique
Bonsoir,
Je suis actuellement en train de concevoir un site web concernant la mise en vente de produits informatique. J'ai fait mon MCD mais je souhaiterais l'éprouver aux critiques afin qu'il soit le plus réussi possible. Il ne doit pas être parfait là. De plus pour la vente de produits informatique avec gestion d'un panier, faut-il le créer dans le MCD ? Si oui comment svp ?
"Vous qui entrez ici, abandonnez toute espérance." Dante
Je ne comprends pas ton Modèle, je crois que ce serait mieux que tu nous mettes les règles de gestion.
A mon avis , le panier doit être géré au niveau Traitement, en créant un objet par exemple.Il ne doit pas être parfait là. De plus pour la vente de produits informatique avec gestion d'un panier, faut-il le créer dans le MCD ?
Scuse me while I kiss the sky ! Jimi Hendrix
Vi j'ai fait des erreurs, j'avais pas fait gaffe mais je me suis planté, ce serait plutot ça:
Des critiques ?
"Vous qui entrez ici, abandonnez toute espérance." Dante
Salut,
+1 pour les règles de gestion.Envoyé par Le Pharaon
Mais à ce que je comprends :
- je ne vois pas l'utilité de ta table calendrier autant mettre un champ date pour l'anniversaire de l'adhérent.
- pour la table produit et calendrier ca veux dire qu'a chaque fois qu'un produit arrive (est livré) tu dois changer la clé qui référence la date...
- pour la relation entre adhérent est produit d'après ta définition un produit ne peut être acheté que par 1 et 1 seul adhérent. Autant rattacher le produit à ton adhérant...
En gros pour une gestion de vente informatique classique ton modèle n'est pas adapté, à moins que tu ais des règles de gestion particulières.
Ben non j'ai pas de règle de gestion particulière, c'est un MCD tout ce qui a de plus classique. De plus pour l'entité calendrier, pendant toutes mes études d'info on m'a expliqué que les dates doivent etre en général rassenblées dans une meme table. Oui je suis d'accord pour la cardinalité 1,1 à vrai dire j'ai hésité car un produit ne peut etre acheté qu'une fois c'est logique mais le libellé peut etre appelé plusieurs fois effectivement.
Ensuite j'ai pensé à un truc, j'ai pas géré la marque du produit, j'avais pensé faire une table MARQUE à part non ?
"Vous qui entrez ici, abandonnez toute espérance." Dante
Si c'était un MCD classique on te demanderai pas tes règles de gestion parce que ton MCD est plutôt atypique.c'est un MCD tout ce qui a de plus classique
C'est une entité produit par exemple si tu as un stock de 30 cartes mères ASUS XP3435 tu vas pas t'amuser à mettre les réf constructeur pour différencier chacune de cartes dans ta base, de toute facon t'as mis stockprod qui doit surement servir à y mettre pour l'exemple le 30 avec comme nom ASUS XP3435 etc...à vrai dire j'ai hésité car un produit ne peut etre acheté qu'une fois c'est logique mais le libellé peut etre appelé plusieurs fois effectivement.
Donc ton adhérent peux acheter 0 ou N carte mère ASUS XP...
Perso j'aurai fait un truc comme ca :
Après tu gère pas vraiment le stock ni le fait de commander parce que une commande doit etre unique et à une date donnée.
Faut aussi gérer le stock et les commandes fournisseurs bref c'est pas avec 2 tables que tu vas pouvoir faire un système pour une "gestion de vente informatique".
C'est pour ca que en premier lieu tu DOIS créer tes règles de gestion, si tu pars directement tête baissé à faire un MCD autant aller directement au code...
[EDIT]
pendant toutes mes études d'info on m'a expliqué que les dates doivent etre en général rassenblées dans une meme table
Je me souviens d'un truc comme ça aussi mais depuis le temps j'ai oublié et je ne sais pas dans quel cas faut appliquer cette règle...
Par contre on m'a dit qu'il fallait appeler les identifiant idxxx et non pas num parce que num c'est numéro et un numéro c'est des chiffres alors que identifiant c'est un identifiant donc ca peut être "Agent007" "XP4544" etc.. des chiffres et des lettres.[/EDIT]
Oui c'est sur je suis ptet un peu bourrin dans mon projet, je passe probablement trop vite sur mon analyse. Je vais ralentir un peu. J'ai rédigé mes règles de gestion mais il est difficile de ne rien oublier:Si c'était un MCD classique on te demanderai pas tes règles de gestion parce que ton MCD est plutôt atypique.
C'est une entité produit par exemple si tu as un stock de 30 cartes mères ASUS XP3435 tu vas pas t'amuser à mettre les réf constructeur pour différencier chacune de cartes dans ta base, de toute facon t'as mis stockprod qui doit surement servir à y mettre pour l'exemple le 30 avec comme nom ASUS XP3435 etc...
Donc ton adhérent peux acheter 0 ou N carte mère ASUS XP...
Perso j'aurai fait un truc comme ca :
Après tu gère pas vraiment le stock ni le fait de commander parce que une commande doit etre unique et à une date donnée.
Faut aussi gérer le stock et les commandes fournisseurs bref c'est pas avec 2 tables que tu vas pouvoir faire un système pour une "gestion de vente informatique".
C'est pour ca que en premier lieu tu DOIS créer tes règles de gestion, si tu pars directement tête baissé à faire un MCD autant aller directement au code...
[EDIT]
pendant toutes mes études d'info on m'a expliqué que les dates doivent etre en général rassenblées dans une meme table
Je me souviens d'un truc comme ça aussi mais depuis le temps j'ai oublié et je ne sais pas dans quel cas faut appliquer cette règle...
Par contre on m'a dit qu'il fallait appeler les identifiant idxxx et non pas num parce que num c'est numéro et un numéro c'est des chiffres alors que identifiant c'est un identifiant donc ca peut être "Agent007" "XP4544" etc.. des chiffres et des lettres.[/EDIT]
- Un adhérent est identifié par un pseudo unique
- Un adhérent peut passer plusieurs commandes
- Une commande peut-être composée de plusieurs produits
- Un produit n'appartient qu'à une marque
- Un adhérent nait à une date unique (logique !)
- Une commande est passée à une date unique
- Une commande arrive à une date unique
Mais ya un soucis aussi faut gérer la livraison...
Tu dis que mon MCD n'est pas atypique, aurais tu un exemple de MCD "typique" afin que j'ai une première vue stp ?
Merci d'avance...
"Vous qui entrez ici, abandonnez toute espérance." Dante
Voici où j'en suis:
"Vous qui entrez ici, abandonnez toute espérance." Dante
Pour te faire une idée tu peux regarder dans le forum les autres posts..
Sinon y'a celui-la :
http://developpez.net/forums/showthread.php?t=300302
Forcément ils ont été fait pour gérer un problème spécifique à leur concepteur qui n'est certainement pas le tien.. mais bon c'est toujours utile pour t'inspirer. Pour tes contraintes ca me parait un peu léger, mais après la consultation d'autres MCD je pense que tu trouveras plus de matière...
Si je peux te conseiller http://analysesi.free.fr/ y'a un programme qui sert à créer des MCD avec les différentes étapes i.e.
1 Définition du dictionnaire des données
2 MCD
3 MLD
et SQL
Je l'utilise que pour griffonner des MCD donc dans l'ensemble je ne sais pas ce qu'il vaux mais à vue de nez il me semble pas mal!!
Merci pour ta réponse que je peux qualifier de très complèteJe vais jeter un oeil aux MCD, j'en ai déjà étudier quelques uns c'est clair que j'ai négliger pas mal d'aspects donc va falloir y remédier. Pour ton logiciel moi j'ai l'habitude d'utiliser PowerAMC mais il ne permet pas, à ma connaissance, de partir de 0 avec le dictionnaire des données
"Vous qui entrez ici, abandonnez toute espérance." Dante
Voilà j'ai un peu avancé mais j'ai encore quelques soucis:
Quelqu'un peut me donner son avis svp ? Voire critiquer ? De plus je ne sais pas trop où placer les propriétés suivantes:
- stock_prod qui représente le stock d'un certain produit
- stock_mini_prod qui représente le stock minimum
- prix_tot qui représente le prix total de la commande
Le problème est que j'hésite à créer une table stock...
Quelqu'un peut m'aider svp ?
"Vous qui entrez ici, abandonnez toute espérance." Dante
Salut,
ça fait 6 mois que j'apprends merise. Mais je pense que :
Si stock_mini_prod represente le stock minimum que le produit doit avoir avant que le vendeur n'en rachete d'autre alors il doit se trouver dans l'entité Produit.- stock_mini_prod qui représente le stock minimum
prix_tot est une donnée calcuée à partir d'autres données. Elle est obtenue en additionnant les prix des produits commandés. Donc je pense que la propriété prix_tot ne doit pas figurer dans votre MCD.- prix_tot qui représente le prix total de la commande
Si le produit peut se trouver dans plusieurs stock à des endroits différents alors il faut créer l'entité Stock et la proprieté stock_prod sera une proprieté de l'association entre Produit et Stock.- stock_prod qui représente le stock d'un certain produit
Merci pour ta réponse
Je suis d'accord sur tes 2 premières idées mais pour la 3ème je suis un peu "contrarié". Si le stock_mini_prod doit etre dans l'entité produit, le stock_prod ne devrait il pas se trouver dans la meme entité ? De plus si je crée une table stock, que stock_mini_prod va dans produit et que stock_prod devient une donnée portée de l'association entre produit et stock que me reste il à mettre dans STOCK ? C'est là qu'est mon pf, les données devant se trouvées là sont réparties ailleurs
"Vous qui entrez ici, abandonnez toute espérance." Dante
Salut,
Y' a deux trois trucs qui me dérange mais j'ai déjà un peu trop donnée mon avis en début de post et dans ton intéret il vaux mieux que tu ais plusieurs avis...
1 date_naissance je l'aurai mis directement dans adhérent meme si tu peux dire qu'un adhérent est adhérent une fois qu'il a fait une commande mais alors la ta cardinalité 0,n audessus de calendrier est fausse. En plus l'adhérent peut faire plusieurs commande et à chaque commande il devra ressaisir sa date de naissance.... donc ca va pas.
2 pour date arriv produi c'est pareil en plus si j'ai bien compris à quoi elle sert elle depends de la livraison du produit par le fournisseur donc je l'aurai mis dans CIM fournit par ce que pour ta cardinalité 1,1 de produit à fournisseur 1 produit peut etre livré par plusieurs fournisseur enfin j'espère sinon t'as pas de concurrence. Si tu achètes des cartes réseaux Dlink d+4554 en france il existe plusieurs grossistes donc ton matériel peux provenir de plusieurs fournisseurs suivant le prix et leurs stocks.
3 pour photo correspond produit je pense que 1,N / 1,N serait mieux que 1,1 / 1,N tu peux avoir une photo par défaut pour les cartes mère par exemple pour un produit générique tu va pas t'amuser à prendre des photos de chaque modèle, sans compter ceux dont tu auras pas forcément de photo si le produit n'est pas disponible, tu mettras une photo par défaut et celle ci sera sur plusieurs produit.
4 les cardinalités entre transport et commande sont fausses tu ne peux pas avoir 1,1 / 1,1 si c'est réellement le cas la tables transport et commande doivent etre dans la meme table et de toute facon à tu pensé à un envoi différé si tu es en rupture de stock pour un produit tu vas pas différer la livraison en attendant qu'elle soit complète tu va envoyer une partie et une fois que le reste t'es livré tu envoie au client donc tu peux avoir deux transports si par exemple tu envoie par UPS le deuxième paquet pour faire classe et pour pas que la grève de la poste retarde le deuxième colis.
Salut, je suis encore de retour:
J'aimerais savoir ce que tu entends par Stock_mini_prod.Jiraiya42 a dit :
Si le stock_mini_prod doit etre dans l'entité produit, le stock_prod ne devrait il pas se trouver dans la meme entité ? De plus si je crée une table stock, que stock_mini_prod va dans produit et que stock_prod devient une donnée portée de l'association entre produit et stock que me reste il à mettre dans STOCK ? C'est là qu'est mon pf, les données devant se trouvées là sont réparties ailleurs
- Comme dans ma reponse précedente si cette proprieté depend du produit ie si c'est le stock que doit avoir le produit avant qu'on en rachete d'autre , alors cette proprieté doit se trouver dans l'entité Produit : ce n'est qu'un regle de dependance fonctionnelle élémentaire Id_Prod -> stock _mini_prod. Quand on connait l'id. du produit on saura le stock minimum de ce produit.
- Si stock_mini_prod est la quantité du produit la plus petite se trouvant dans un des stock alors elle ne doit etre dans aucune des entités (Produit, Stock). le stock_mini_prod est obtenu en comparant les stock du produits dans les différents stock. Alors dans ce cas stock_prod sera une proprieté de l'association entre Produit et Stock.
- l'entité Stock doit contenir un id. pour différencier les stocks et les proprietés suivantes : adrese, tel, etc...
Peut-etre que plusieurs avis sont préférables mais en tout cas des remarques sont vivement prises en compte
Très juste. La date de naissance est juste à titre d'information.
1 date_naissance je l'aurai mis directement dans adhérent meme si tu peux dire qu'un adhérent est adhérent une fois qu'il a fait une commande mais alors la ta cardinalité 0,n audessus de calendrier est fausse. En plus l'adhérent peut faire plusieurs commande et à chaque commande il devra ressaisir sa date de naissance.... donc ca va pas.
Encore très juste. Le date_arriv_prod sert à savoir quand le fournisseur va livrer le produit par contre "dans CIM" c'est quoi stp ?
2 pour date arriv produi c'est pareil en plus si j'ai bien compris à quoi elle sert elle depends de la livraison du produit par le fournisseur donc je l'aurai mis dans CIM fournit par ce que pour ta cardinalité 1,1 de produit à fournisseur 1 produit peut etre livré par plusieurs fournisseur enfin j'espère sinon t'as pas de concurrence. Si tu achètes des cartes réseaux Dlink d+4554 en france il existe plusieurs grossistes donc ton matériel peux provenir de plusieurs fournisseurs suivant le prix et leurs stocks.
Juste aussi. J'avais pas pensé à une photo par défaut, dans ma tete j'imaginais une photo par produit
3 pour photo correspond produit je pense que 1,N / 1,N serait mieux que 1,1 / 1,N tu peux avoir une photo par défaut pour les cartes mère par exemple pour un produit générique tu va pas t'amuser à prendre des photos de chaque modèle, sans compter ceux dont tu auras pas forcément de photo si le produit n'est pas disponible, tu mettras une photo par défaut et celle ci sera sur plusieurs produit.
Très juste, j'avais pas pensé aux envois différés
4 les cardinalités entre transport et commande sont fausses tu ne peux pas avoir 1,1 / 1,1 si c'est réellement le cas la tables transport et commande doivent etre dans la meme table et de toute facon à tu pensé à un envoi différé si tu es en rupture de stock pour un produit tu vas pas différer la livraison en attendant qu'elle soit complète tu va envoyer une partie et une fois que le reste t'es livré tu envoie au client donc tu peux avoir deux transports si par exemple tu envoie par UPS le deuxième paquet pour faire classe et pour pas que la grève de la poste retarde le deuxième colis.
"Vous qui entrez ici, abandonnez toute espérance." Dante
C'est le stock minimum avant lequel on doit recommander au fournisseur
- Si stock_mini_prod est la quantité du produit la plus petite se trouvant dans un des stock alors elle ne doit etre dans aucune des entités (Produit, Stock). le stock_mini_prod est obtenu en comparant les stock du produits dans les différents stock. Alors dans ce cas stock_prod sera une proprieté de l'association entre Produit et Stock.
Euh dans STOCK, l'id ok je comprends mais l'adresse, tel et tout je comprends pas... Adresse de qui ? Tel de qui ? Etant donné que le stock n'est pas une personne ?
- l'entité Stock doit contenir un id. pour différencier les stocks et les proprietés suivantes : adrese, tel, etc...
"Vous qui entrez ici, abandonnez toute espérance." Dante
salut ,
je suis encore de reour avec ceci :
Datenaiss_adh doit se trouver dans l’entité ADHERENT,
Date_cmde doit se trouver dans l’entité COMMNDE,
Nom_pays dans ADHERENT et l’entité PAYS n’a pas sa raison d’etre dans le MCD (comment un adherent ne peut pas habiter dans plusieurs pays),
Date_livraison_prod et date_arriv_prod sont des synonymes. On doit donc supprimer l’une de ces proprietés. Mais je préfére date-livraison_cmd au lieu de ces deux proprietés. On livre une commande et non des produits,
Si l’adhérent doit payer sa commande au moment de la livraison alors date_livraison_cmd et date_paiement_cmd sont des synonymes sinon la proprieté date_paiement _cmd doit se trouver dans l’entité COMMANDE si l’adhérent paie au moment de la commande.
Prix_ttc_prod est un donnée calculée donc ne doit pas figurer dans ton MCD.
L’association entre FOURNISSEUR et PRODUIT ne doit pas exister. Un fournisseur fournit une commande et non un produit.
L’entité stock doit être créer et il y aura une association entre l’entité PRODUIT et STOCK qui contiendra la propriété stock_prod.
Si la propriété stock_mini est :
--La qté qu’un produit doit avoir dans un stock donné pour que le fournisseur recharger ce stock. Dans ce cas stock_mini_prod doit se trouver dans l’association entre PRODUIT et STOCK.
--est qté la plus petite parmi les stock alors elle ne doit pas figurer dans le MCD (donnée calculée)
Dernière modification par Invité ; 25/04/2008 à 13h24.
Ca je crois qu'on est tous d'accord maintenant
Oui je suis d'accord, j'hésitais entre la mettre dans l'entité CALENDRIER et là
Date_cmde doit se trouver dans l’entité COMMNDE,
C'est pas faux mais j'ai vu sur plusieurs MCD cette fameuse table
Nom_pays dans ADHERENT et l’entité PAYS n’a pas sa raison d’etre dans le MCD (comment un adherent ne peut pas habiter dans plusieurs pays),
Non là c'est pas pareil date_livraison_prod c'est la date de livraison au client qui a acheté le produit sur le site et l'autre c'est l'arrivée à l'entrepotDate_livraison_prod et date_arriv_prod sont des synonymes. On doit donc supprimer l’une de ces proprietés. Mais je préfére date-livraison_cmd au lieu de ces deux proprietés. On livre une commande et non des produits,
Il paye la commande avant la livraison comme les magasins d'ecommerce, c'est plutot avant
Si l’adhérent doit payer sa commande au moment de la livraison alors date_livraison_cmd et date_paiement_cmd sont des synonymes sinon la proprieté date_paiement _cmd doit se trouver dans l’entité COMMANDE si l’adhérent paie au moment de la commande.
Je suis d'accord
Prix_ttc_prod est un donnée calculée donc ne doit pas figurer dans ton MCD.
Très justeL’association entre FOURNISSEUR et PRODUIT ne doit pas exister. Un fournisseur fournit une commande et non un produit.
Ca je suis un peu mitigé, je vois pas trop l'interet à vrai dire
L’entité stock doit être créer et il y aura une association entre l’entité PRODUIT et STOCK qui contiendra la propriété stock_prod.
En tout cas merci pour tes réponses à toi aussi qui sont très complètes
"Vous qui entrez ici, abandonnez toute espérance." Dante
CIM c'est pour Contrainte d'intégrité multiple. Pour faire simple c'est les boules entre deux tables dedans tu dois avoir les deux clés primaires de tes tables en clés étrangères et tu peux avoir d'autres données (on dit qu'elle est porteuse de données) une CIM c'est quand tes cardinalités ne sont pas à 1,1 ou 1,0 mais avec N, donc celles avec 1,1 ou 1,0 c'est des CIF et celles-ci n'ont pas de données de dedans. Si t'as rien capté à mes explications chope un cours la-dessus si t'as pas compris ce principe tu passes à coté de quelque chose d'important.par contre "dans CIM" c'est quoi stp ?
Tu penseras pas à tout et peut etre que certains cas ne se présenteront jamais donc ca sert à rien de trop te prendre la tete avec ton MCD une fois que tu le sens bien que t'as compris tous les gros points passe à l'étape suivante sinon dans 3 semaines t'aura toujours des remarques à propose de ceci ou cela!!!Très juste, j'avais pas pensé aux envois différés
Ton raisonnement est mauvais c'est pas parce que plein de personnes le font que c'est forcément bien ou adapté à ce que veux en faire. Si tu prends le cas que tes adhérents peuvent commander de n'importe quel pays de la terre alors meme si une personne peut habiter que dans un pays et d'ailleurs t'as mis la bonne cardinalité pour ca 1,1 vers pays par contre 0,N de pays vers adhérent, il peut etre utile d'avoir une table avec la liste de tous les pays. Si tu veux faire une recherche c'est plus simple de rechercher l'id 89 pour France que de t'arracher les cheveux parce que 15 personnes ont saisis Franse d'autres Frrens ou Fransse... Mais après si tu ne veux livrer qu'en France l'utilité de ta table est moindre.Citation:
Nom_pays dans ADHERENT et l’entité PAYS n’a pas sa raison d’etre dans le MCD (comment un adherent ne peut pas habiter dans plusieurs pays),
C'est pas faux mais j'ai vu sur plusieurs MCD cette fameuse table
Faudrait revoir la législation tu ne peux pas imposer qu'un seul mode de paiement meme si beaucoup le font je crois que c'est interdit. Normalement sur les sites d'ecommerce tu peux payer à réception par chèque (ou en natureIl paye la commande avant la livraison comme les magasins d'ecommerce, c'est plutot avant).
Bon courage!!
PS : c'est juste un projet ou tu as vraiment l'intention de monter un système de vente de matériel informatique en ligne?
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.
Répondre avec citation
Partager