Discussion :

[satory]

Oyé Oyé brave gens ,

Et oui, encore un newbie débarquant la larme a l'oeil sur les forums de developpez.net ^^ …
Oui enfin newbie, newbie pas tant que ca mais j'ai quand même quelques difficultés concernant merise et la modélisation d'un de mes projets.
Pour la petite histoire, je décidé de finir ma carrière d'étudiant par un master 2 en projet informatique et je me colle à mon premier projet : Access.

Hein quoi ? Vous êtes impatient de connaitre mon beau projet ?
Ok ok, je vous explique en quelques lignes de quoi qu'ça cause !!!


———————————————————————————————————————
LE PROJET :
———————————————————————————————————————

Pour l'intérêt, j'ai décidé de prendre un projet de gestion d'une boutique en ligne. Pour le fun, j'ai décidé de prendre le concept d'un LoveStore ^^ Oui oui, y'a des gods, des vibro, des coins coins et plein d'autres débilités érotiques du meme genre.

NAN NAN, ce n'est pas un sex-shop rroohhhh, fermer vos braguettes les gars… Un peu de sérieux quand même… On est des pro.

Mon modèle (sans vouloir faire de pub, ni le copier) est le site du passage du désir.


———————————————————————————————————————
MON MCD
———————————————————————————————————————

Bref ! Donc je vous explique un minimum ce que comprend aujourd'hui mon MCD bien qu'il soit suffisamment "standard" car ca reste une gestion de boutique en ligne :

J'ai des clients avec :
- Les coordonnées complète (Nom, Prénom, Date de naissance, Sexe, Situation familiale (facultatif), Orientation sexuelle (facultatif), Adresse, Email, Téléphone (facultatif), mot de passe
- code parrainage
- une connexion en ligne
- un service client prenant en compte les attentes, les besoins, répondant aux email


Gestion commande
=> Les commandes sont enregistrées, accessible pour le client, il peut regarder les commandes déjà réalisées.
- l’approvisionnement
- les ventes
- une facture
- Une adresse de livraison
- Un statut


Des produits (Je propose une gamme de produit large et profonde (avec mauvais jeux de mots)) avec
- Nom
- Marques
- Genres
- Modèles
- Catégories
- des prix
- des réductions/promos


Gestion des stocks
- Stock de sécurité
- Stock d'alerte


Des fournisseurs
- Nom
- Siret
- Bon de commande
- adresse
- statut livraison


Gestion des vente :
=> Des promotions saisonnière (Ex: soldes, événement tel que la Saint Valentin, Noël etc.) sont réalisées sur un certains nombre de produits:
- 20% première démarque (soldes: 2 premières semaines)
- 40/50% deuxième démarque (soldes: deux dernières semaines)
- code promo: NOËL donne droit à la livraison gratuite+3euros de “chèque cadeau”
- code promo: STVAL donne droit à la livraison gratuite
=> La TVA est à 19.6%
=> L’entreprise propose un système de points (1euro = 1point)
-30 points: 3 euros de réduction
-50 points: 5 euros de réduction
-100 points: 10 euros de réduction etc...
=> j'offre les frais d'envoie à partir de 35 euros d'achat
=> Les acheminement sont fait par colissimo.


Outre le plaisir que j'ai pu prendre à trouver des noms de catégories tel que "L'effet Kiss Cool", "Tomber en sainte", "Par Douze", "l'éppé Nice", "Cap’Hot", "Queue tard", "Ma’Boule", "Cunégonde", etc… j'ai néanmoins le devoir, en plus de faire plaisir à mon examinateur, de lui fournir quelque chose de fonctionnel.

Si si, c'est vrai…

J'ai regardé un peu partout sur le net et j'ai regroupé les meilleurs idées grâce au logiciel Jmerise (au début j'étais sur analyseSI).

Ma demande aujourd'hui concerne l'optimisation de ce MCD. Je le soumets à vos yeux experts et à vos doigts agiles.

Quoi ? En plus faut travailler !!!! Il manque pas d'aire ce newbie…
C'est vrai, c'est vrai… Mais c'est pour la bonne cause. Un jour le petit deviendra grand à son tour. life cycle isn't it ?


Dans l'arborescence, il est prévu :
Familles > Catégories > Genres > Modèles > Articles


Voila voila ! J'ai cru comprendre que vous aimiez les descriptions assez complètes alors J'espere avoir été assez bon dans cet exercice.


———————————————————————————————————————
Mes questions
———————————————————————————————————————

=> Mes cardinalités sont elles correctes ? J'ai encore un peu de mal avec ca :/
=> La table connexion est-elle nécessaire. Ne peut elle pas se mettre dans client ?
=> J'ai 2 commandes dont une concerne le client et l'autre mon réapprovisionnement. Est-ce une bonne idée de les regrouper dans une seule table ?
=> Meme réflexion concernant les adresses… Est-ce mieux de tout regrouper (adresse client, fournisseurs, livraison) dans une table "adresse" ou vaut mieux les séparer.
=> Est-ce que l'orientation sexuelle est bien foutu ? J'ai bien peur de mélanger des infos qui sont cohérentes ensemble mais qui ne sont pas forcément a mettre dans une seule table : la situation maritale et l'orientation sexuelle. Le sexe ne serait il pas mieux placé dans client ?
=> Puis-je regrouper la table statut pour a la fois suivre le statut d'une commande client et fournisseur mais aussi le statut de mon stock ?
=> Sinon avez-vous des idées pour améliorer ce MCD ?

[CinePhil]

Rapidement parce que pas trop le temps, je commence à examiner le MCD par en haut à gauche...

1) client -1,n----avoir----1,1- orientation sexuelle
Ce qui signifie en français :
Un client a de une à plusieurs orientations sexuelles et une orientation sexuelle est possédée par un seul client.

Autrement dit, tu ne pourra avoir qu'un seul client hétéro, un seul homo, un seul bi.
Limité comme ambition non ?

=> Tes cardinalités sont à l'envers !

2) Entité type "orientation sexuelle".
2. A) D'une manière générale, comme le MCD générera un MLD puis le SQL pour créer physiquement la BDD, évite les noms d'entités types avec des espaces, des lettres accentuées et tout autre caractère pouvant poser problème au SGBD.
D'autres entités types sont également concernées par cette remarque.
=> Les 26 lettres de l'alphabet et les 10 chiffres + le caractère de soulignement suffisent.

2. B) Évite les types "SET et "ENUM" qui sont des pièges.

2. C) Je ne comprends pas la structure de ton entité type !
Une orientation sexuelle pour moi, c'est grosso modo les trois possibilités que j'ai données dans la remarque 1. Tu ne devrais donc avoir ici qu'un identifiant (que je préfère au mot "code") et un libellé.
Sexe et situation maritale sont deux autres entités types à modéliser et à associer au client.

3) Nomme tes entités types au singulier.
Tu as vu dans la règle de gestion que j'ai donnée à la remarque 1 que celle-ci définit ce qu'il se passe pour une instance de l'entité ("Un client a..., une orientation sexuelle est possédée...).

4) Adresse
4. A) Pourquoi avoir mis l'adresse dans l'entité type "client" alors qu'il y a une entité type pour les adresses ?

4. B) Qu'est censé contenir la propriété "Nom_Adresse" ?

4. C) Externaliser la ville.
Pour éviter d'avoir enregistré des milliers de fois la même ville, potentiellement avec des orthographes différentes, il faut créer une entité type de référence des villes et l'associer à l'adresse.

4. D) Pourquoi deux adresses pour une instance de l'entité type adresse ?
Pourquoi avoir mis l'adresse de livraison dans cette entité type ?
Une adresse de livraison est une adresse associée à la commande.

J'arrête là. Il y a beaucoup de choses à revoir dans ce schéma !

Écris tes règles de gestion et donne-les nous, ce sera plus facile d'analyser ton schéma et tu trouveras toi-même sans doute pas mal d'erreurs.

Bon courage !