Discussion :

[platypus69]

Bonjour à tous,

mon boulangerie, après avoir discuter de nos métiers, m'a demandé si je pouvais lui développer une petite application pour gérer sa boutique.

Il souhaite pouvoir dans un premier temps suivre sa production avec la création de recette, création d'ingrédients, lancement de production.
Par la suite, il voudrait pourvoir gérer les achats (fournisseurs) ainsi que les ventes de son magasin en relation avec sa caisse.

Travaillant pour ma part essentiellement dans le DEV pour le milieu financier, j'ai peur d'oublier des paramètres importants dans la conception de la BDD.
Ci-dessous la BDD telle que je l'imagine pour le moment (avec les éléments que m'a donné le boulanger).



merci pour vos suggestions

N@ss

[escartefigue]

Bonsoir Platypus,

Avant de vous lancer bille en tête dans la modélisation, il faut d'abord collecter les règles de gestion.
Consultez les autres sujets publiés dans ce forum, ceux qui ont trouvé réponse sont passés par là.

Par exemple, dans une boulangerie, on peut supposer des règles de gestion comme suit :
R001a : un produit est d'un et un seul type (pains, viennoiserie, pâtisserie, chocolaterie...)
R001b : un type se rapporte à zéro ou plusieurs produits

R002a : pour un produit, il existe au moins une recette
R002b : une recette n'existe que pour un et un seul produit
etc.

Cette étape est indispensable

Quand ces règles de gestion auront été rédigées et validées par le boulanger (le métier, c'est lui qui le connait le mieux), vous pourrez commencer à dessiner un MCD

À propos de votre ébauche très prématurée de modèle

• premier point : il ne s'agit pas d'un MCD mais d'un MLD, nous sommes au niveau tabulaire et non conceptuel. Au niveau conceptuel (le MCD), on modélise des types d'entités (sous forme de rectangles) et des associations (sous forme d'ovales) avec des cardinalités sur chaque lien
• pourquoi avoir modélisé une table des sociétés ? Il me semble que vous ne vous intéressez qu'à la boulangerie pour laquelle vous intervenez, à moins que vos clients soient des entreprises ?
• quelle que soit la table, une PK doit être stable dans le temps. Ni le SIRET ni le SIREN ne sont des données stables (il existe des SIREN provisoires et des changements de SIREN en cas d’absorption d'entreprise)
  remplacez cette PK sémantique par un identifiant technique stable, le mieux est un identifiant technique attribué par le SGBD car il sera à la fois stable et concis, donc performant (contrairement à un SIRET coûteux en comparaison)
  Les identifiants sémantiques tels que SIRET, SIREN, N° de sécurité sociale, N° de téléphone... seront conservés comme identifiants alternatifs, éventuellement unique, mais jamais en tant que PK !
• la notion de trigger est très prématurée à ce stade, concentrez vous sur les règles de gestion

De nombreuses autres notions seront à revoir, par exemple l'externalisation et la normalisation des adresses et le typage des données mais c'est très prématuré à ce stade
Un point positif : avoir choisi un mnémonique pour chaque table que l'on retrouve dans chaque attribut, c'est une pratique que j'approuve car elle simplifie les recherches (études d'impact entre autres), mais vous n'avez pas été au bout de la démarche. Par exemple, dans la table TJ_composition_CPN, la FK CPN_id_recette devrait s'appeler RCT_id_recette puisqu'elle est issue de la table dont le mnémonique est RCT. C'est bien plus simple d'avoir le même nom pour une même colonne quelle que soit la table où cette colonne est présente. Si vous renommez CPN_id_recette en RCT_id_recette vous savez d'emblée que cette colonne est une FK issue de la table recette .