Discussion :

[Alexr]

Bonjour à tous,

j'ai un point épineux à résoudre concernant la modélisation d'un fonctionnement : j'ai un produit qui va contenir divers champs et clé étrangères qui va servir de base pour être présenté à des clients.
Ensuite les clients prennent comme base ce produit et le modifie à leur façon.
Mon problème est je ne veux pas toucher au produit de base qui peut servir de référence à d'autres clients mais toute la vente du produit, etc... se fait à partir de la version du produit pour le client.
Comment puis je représenter ces 2 états Produit de base et Produit adapté au client qui ont les même "fonctionnalités" sauf que le 2ème est destiné à un client et va suivre un cycle de commande ?

Pour préciser les choses :
[ Produit ]--0,1----( possède )----0,n--[ Licence ]
[ Produit ]--1,n----( possède )----1,1--[ Specification_Dev ]
etc ...
seulement à ce stade le produit est "générique", des changements vont intervenir quand un client intéressé va demander des modifications propre à lui.
C'est là où je ne sais pas quoi faire car mon [ Produit ] est désormais lié à mon [client] la licence va peut être changer, les Specification_Dev aussi, etc ...
dois je créer une autre table Produit_Client (cette table aura les même relations que [Produit] mais avec des valeurs différentes) ?
Suis je totalement à l'ouest dans ma modélisation ?

Je vais faire ça :
[ Produit ]--1,1----( possède )----0,n--[ Produit ]
qui décrit le fait qu'un produit de base possède plusieurs versions de produit.
Une version de produit possède un seul produit de base


voici une vue du mcd gérant les contraintes suivantes :
Un produit peut être crée sans être affecté à un client - "Produit Racine"
Un "Produit Racine" peut avoir des "versions de produit"
Une "version de produit" peut avoir un "Produit Racine"
Un produit peut être directement affecté à un client
Un produit peut avoir plusieurs versions en fonction du nombre de clients
Une version de produit est propre à un client
Un produit ne peut pas être lancé en commande sans affectation client

est ce que cela vous semble correct ?

[JPhi33]

Bonjour Alexr,

Je vais faire ça :
[ Produit ]--1,1----( possède )----0,n--[ Produit ]
qui décrit le fait qu'un produit de base possède plusieurs versions de produit.
Une version de produit possède un seul produit de base

Ceci n'est pas représenté dans le schéma.

Un "Produit Racine" peut avoir des "versions de produit"
Un produit peut avoir plusieurs versions en fonction du nombre de clients

Non modélisé.

Une "version de produit" peut avoir un "Produit Racine"

Normalement, une version devrait avoir obligatoirement un produit racine, non ?

Un produit peut être directement affecté à un client

Est-ce l'association "version client" ? Dans ce cas, cette association n'est pas nommée correctement.

Une version de produit est propre à un client

Non modélisé.


En résumé, il semble que la notion de version de produit ait été oubliée dans le schéma.

[Alexr]

Bonjour JPhi33,

merci pour les réponses.
Je vais essayer d'éclaircir les choses.
J'ai tenté de représenter la notion de produit et version de produit par ce lien (en bas du mcd) : [ Produit ]--0,1----( produit de base)----0,n--[ Produit ]
- 1 produit a 0 ou 1 produit de base (Un client peut venir avec un produit défini, il n'y alors pas de produit de base)
- 1 produit de base à 0 ou n version produit (0 si pas de client intéressé)

Le fait est qu'à la table produit (qu'il soit de base ou version) vont se greffer tout un tas d'autres associations liées aux phases de développement, specs, etc ... et je ne vois pas l’intérêt de créer 2 entités différentes Produit et Version produit car de ce fait je doublerai toutes les associations du genre :
[ Produit ]--1,n----( a)----1,1--[ Design]
[ Produit ]--1,n----( a)----1,1--[ Specs]
[ Produit ]--1,n----( a)----1,1--[ Packaging]
etc ...

[JPhi33]

et je ne vois pas l’intérêt de créer 2 entités différentes Produit et Version produit car de ce fait je doublerai toutes les associations

Non, effectivement, il n'y a aucun intérêt à doubler toutes les associations communes entre un produit et une version.

Cependant, il y a bien des différences entre un produit et une version. Si elles ne se situent pas au niveau des propriétés, elles se situent très probablement au niveau des associations (à confirmer, SVP).

Pour résoudre ce problème, on peut utiliser la généralisation / spécialisation. On considère 3 entités :
- le produit qui porte toutes les caractéristiques (propriétés et associations) communes à tous les produits
- le produit de base qui ne porte que les caractéristiques spécifiques aux produits racines
- la version de produit qui ne porte que les caractéristiques spécifiques aux versions

On peut affirmer qu'un PRODUIT_BASE et qu'une VERSION_PRODUIT (entités spécialisées) sont chacun un (genre de) PRODUIT (entité généralisée). Les entités spécialisées héritent des caractéristiques de l'entité généralisée. On peut maintenant facilement modéliser les règles :

- 1 produit a 0 ou 1 produit de base (Un client peut venir avec un produit défini, il n'y alors pas de produit de base)
- 1 produit de base à 0 ou n version produit (0 si pas de client intéressé)

Lorsqu'un produit a 0 produit de base, il n'y a aucune occurrence dans PRODUIT_BASE correspondant à PRODUIT.
La 2e règle est modélisée par l'association "a_pour_base".

[Alexr]

Bonjour JPhi33,

merci pour la modélisation que tu proposes.

La différence entre un PRODUIT_BASE et un VERSION_PRODUIT est que le PRODUIT_BASE n'entrera jamais dans un cycle de commande car pour cela il faut qu'il soit adapté aux besoins du client et donc devienne un VERSION_PRODUIT.

De ce fait, l'association avec CLIENT ne peut se faire que pour un VERSION_PRODUIT
[ VERSION_PRODUIT]--1,1----( affecté a)----1,n--[ CLIENT]
[ VERSION_PRODUIT]--1,1----( distribué dans)----0,n--[ PAYS]

Dans le schéma de généralisation / spécialisation, je peux affecter à PRODUIT les associations communes à PRODUIT_BASE et VERSION_PRODUIT et n'affecter à VERSION_PRODUIT que les associations qui correspondent à la relation CLIENT, COMMANDE, etc ... ?

[JPhi33]

Dans le schéma de généralisation / spécialisation, je peux affecter à PRODUIT les associations communes à PRODUIT_BASE et VERSION_PRODUIT et n'affecter à VERSION_PRODUIT que les associations qui correspondent à la relation CLIENT, COMMANDE, etc ... ?

Oui, c'est exactement le but recherché avec cette modélisation.
De même pour les propriétés ; celles qui sont communes aux trois entités appartiennent à PRODUIT, seules les propriétés spécifiques à chacune des entités spécialisées sont rattachées à PRODUIT_BASE et VERSION_PRODUIT (il est possible qu'il n'y en ait pas).

[Alexr]

Merci beaucoup pour ton aide