[MCD] Multiples catégories de produits

Bonjour à tous,

Dans le cadre d'un stage je dois créer une base données pour un traiteur en ligne, malheureusement mon expérience sur les bases de données est plus que réduite :(

J'ai eu des cours assez simples sur le MCD et le MPD, pas de notions d'héritage ni de trucs compliqués, bref le minimum. Alors maintenant je galère un peu...

Donc pour ce MCD j'ai une table 'PRODUITS' qui contient le stock actuel du dit produit et son libellé (juste le nom, la description du produit se fait ailleurs). Mais ce produit peut être de nature différente (et donc traité de façon différente par la suite). Pour renseigner son état j'ai donc sous-divisé ma table 'PRODUITS' vers des tables de catégories qui sont : 'BOISSONS', 'INGREDIENTS', 'PLATS', 'MATERIELS', 'VINS' (je sais que 'vins' devrait être dans 'boissons', mais il y a trop de références, on ne pourrait pas s'y retrouver ensuite).



Même si ça fait beaucoup de tables j'étais plutôt content de moi, malheureusement quand je passe au MPD ça ne fonctionne pas du tout comme je l'aurais souhaité. Je me retrouve avec une FK par sous-catégorie dans ma table 'PRODUITS' ce qui ne peut pas fonctionner correctement.



Je voulais donc savoir si quelqu'un avait une idée (à part bidouiller les cardinalités pour que enlever les FK de ma table 'produits' :mrgreen: ) ? Quitte a remodeler entièrement mon MCD, je préfère le refaire pour qu'il soit conforme par la suite.

Si vous voulez jeter un coup d'oeil au MCD complet pour avoir une vue d'ensemble, voici un lien pour télécharger le zip :
MCD Complet (Line 1 de la partie "Le MCD complet" )

Je pourrais très bien regrouper toutes mes catégories dans ma table 'PRODUITS' grâce au système des 'id_parent' et 'id_fils' (voir explication ci-dessous) mais si c'était possible j'aimerais bien bien garder un table par catégorie.

Le système des 'id_parent' et des 'id_fils' est simple et pratique mais je ne suis pas sur qu'il soit très conforme à l'esprit BDD. Je m'explique:

'id_parent' est une référence à la catégorie supérieure du produit en question, et 'id_fils' est la référence est la sous-catégorie inférieure. Par exemple pour la table 'INGREDIENTS' cela donne:



C'est pratique pour le classement, pour les requêtes c'est assez simple d'avoir l'arborescence pour un produit donné. Seulement avec cette technique dans une table sensée ne contenir que des produits je me retrouve avec de catégories et des sous-catégories, bref des choses immatérielles que mon patron serait bien en peine de servir à la table d'un client.

Est-ce que pour vous cette technique est choquante? Si oui j'ai un soucis, vu que je pensais en cas de non-résolution de mon problème de MPD fusionner toutes les tables de catégories avec la table 'PRODUITS' qui du coup ne poserait plus de problème de cardinalités mais qui contiendrait un nom impressionnant de catégories, de sous-catégories, de sous-sous-catégories, etc...

Bref elle deviendrait illisible pour l'oeil humain.

Quand pensez vous? Quelle solution adopteriez-vous?

Donc après modification... je me retrouve avec le même soucis. Je n'ai fait que déplacer le problème en fait, cela n'a servi à rien. Je dois avoir un défaut de conception, une chose que je n'ai pas compris.

Voilà le résultat après modification de mon MCD :


et le résultat identique sur mon MPD:


Si vous voyez ce qui cloche dans la conception de ma modélisation je serais heureux de vous entendre, parce que là je craque. :fou:

Salut,

ça fait un paquet de temps que j'ai pas modélisé, mais je vais essayer d'apporter ma contribution!!

Première remarque: je vois que dans tes héritages, tu références un parent et un enfant => Erreur! Tu dois avoir un parent unique, mais tu ne peux pas référencer d'enfant parce qu'il peut y en avoir plusieurs. Ex: dans ta table Ingrédients (qui à mon avis doit sauter, je vais y venir..), tu as un Id_Ingrédient, un Nom_Ingrédient, et un Id_Parent.

2)Dans la conception, ne t'occupe pas trop de la lisibilité des tables, l'important est que ton modèle soit pérenne. Au fil du temps, les tables vont se remplir et ce sera de toute façon le bordel pour s'y retrouver, d'où l'importance d'avoir un système stable pour éviter qu'il ne s'effondre dans 2 ans! Ta base de données est là pour structurer tes données; pour ce qui est de la présentation, ce seront les requêtes et procédures stockées qui feront le boulot!

3)Donc en ce qui concerne les produits, je le verrais plutôt comme ça... Merde, je sais pas comment insérer une image..tant pis, je vais essayer de te l'expliquer:

- 1 table Produit contient tous tes produits (toutes les dérivées sautent). Elle est liée à une table Catégorie par une relation 'Appartient à' de cardinalité 1.* (1 prod appartient à une seule catégorie, 1 catégorie peut concerner n prod) => tu retrouves donc IdCategorie ds la table produits.
- La table Catégorie est liée à elle-même ds une relation 'Est enfant de' (1.*): 1 Cat -> 1 seul parent. Dans cette table tu as donc un IdCat et un IdParent.
- Pour ce qui est du type matériel/immatériel, 2 possibilités: le + propre (ce qu'on apprend en formation!), c'est de créer 1 table typeProd, liée à Produits... mais dans la pratique, cette table ne contiendra que 2 enregistrements (matériel, immatériel), donc (solution n°2): tu intègres directement un champ 'type' (ou même un champ booléen 'matériel') dans la table qui va bien: Catégories si tous les prod d'une catégorie sont de même type, Produits dans le cas contraire.

Voilà, je pense que c'est un bon début... Affaire à suivre!


Si l'envie te prend de travailler, assied-toi et attend qu'elle te passe! (vieux -et faux!- dicton corse)

Pour faire plus général sur les héritages, voici 2 principes (parmi d'autres) qui t'aideront à comprendre certaines erreurs que tu as faites:
1)Un objet (classe) ne peut hériter que d'un seul objet.

2) Tu ne dérives une classe que si l'enfant possède des attributs spécifiques. Exemple: une classe Véhicule possède des attributs (couleur, type de carburant etc...). Si tu veux gérer des camions, tu crée une classe Camion héritée de Véhicule, parce qu'un camion possède par exemple un attribut 'tonnage' qu'un autre véhicule n'a pas.

Si l'envie te prend de travailler, assied-toi et attend qu'elle te passe! (vieux -et faux!- dicton corse)