Discussion :

[BLJ.CHAUVIN]

Bonjour à tous,

Je voudrais vous présenter un MCD et que vous n'hésitiez pas à donner votre avis, quelques conseils ou critiques, ce qui vous parait aller de travers et quelles modifications vous y apporteriez (si besoin est ).

C'est le MCD de la base de données d'un site web de restaurant.

Voici ce que je peux vous en dire:

- l'entité PRODUCT regroupe les informations générales des produits proposés par l'entreprise comme le nom du produit (PRODUCT_LABEL), le fait qu'il soit ou non en vente (ON_SALE), etc... Les champs PRICE_x et UNIT_PRICE_x font référence au prix de vente lié à l'unité x.

exemple:
PRICE_1 | UNIT_PRICE_1 | PRICE_2 | UNIT_PRICE_2 | PRICE_3 | UNIT_PRICE_3 |
2.80 | 'verre' | 12.00 | '1/2 bouteille' | 22.00 | 'bouteille' |

- l'entité CHARAC_WINE créée une identité spécifique pour le vin. ID_CHARAC_WINE doit permettre de réunir les informations spécifiques telles que la région de production (entité REGION), le pays de production (entité COUNTRY), l'appellation du vin (entité MARK) et le type de l'appellation (entité MARK_TYPE).

exemple:
COUNTRY | REGION | MARK | MARK_TYPE |
France | Loire | Saumur | AOC

- l'entité MENU regroupe les différents menus proposé à la carte du restaurant.

- l'entité PRODUCT_CATEGORY indique la catégorie de produit c'est à dire par exemple : 'Entrée' ou 'Boisson chaude'. L'association IS_AFFILIATED qui lui est attribuée est réflexive puisque une catégorie de produit peut elle-même être une sous-catégorie.

exemple:

ID_CATEGORY | CATEGORY_LABEL |
1 | 'Entrée' |
2 | 'Entrée chaude' | ('Entrée chaude' est une sous-catégorie de 'Entrée')
3 | 'Entrée végétarienne' |('Entrée végétarienne' est yune sous-catégorie de 'Entrée')

- l'entité GENDER est la civilité des clients (GENDER_SMALL = Mr, Mme, Mlle) (GENDER_LONG = Monsieur, Madame, Mademoiselle)

- l'entité UNIT est la liste des unités de vente des produits (exemple : verre, bouteille, assiette, flute, etc...)

- l'entité RESERVATION regroupe toutes les informations nécessaires pour effectuer une réservation en ligne. (nom du client, numéro de mobile ou mail pour la confirmation, Nombre de place réservées, Date et heure de réservation, etc...).

Voici un schéma du MCD:


Que pensez vous de ce modèle conceptuel de données?

Remarques:
- Je n'ai pas relié les entités GENDER, UNIT et RESERVATION parce que je n'en voyais pas l'utilité. Aucun lien particulier n'aurait de fonction pour ces 3 entités ci. Puisque les réservations se limitent à la table et non aux produits il me parait inutile de relier les réservations à quoi que se soit. (mais peut-être que je me trompe?)

- J'ai conscience qu'il y a de petites redondances d'informations (exemple dans l'entité PRODUCT les champs UNIT_PRICE_x reprennent le contenu de l'entité UNIT. C'est vrai que cela risque de poser un problème si je dois effectuer une modification sur les noms des unités dans l'entité UNIT, il me sera alors plus complexe de modifier les UNIT_PRICE_x de l'entité PRODUCT

Merci du temps que vous m'avez consacré.

[ok.Idriss]

Bonsoir.

- Je n'ai pas relié les entités GENDER, UNIT et RESERVATION parce que je n'en voyais pas l'utilité. Aucun lien particulier n'aurait de fonction pour ces 3 entités ci. Puisque les réservations se limitent à la table et non aux produits il me parait inutile de relier les réservations à quoi que se soit. (mais peut-être que je me trompe?)

Dans un MCD correcte, les entités sont toujours reliés par au moins une association.
Je regarderais ton MCD dans le détails une autre fois par contre ...

Cordialement,
Idriss

[BLJ.CHAUVIN]

Dans un MCD correcte, les entités sont toujours reliés par au moins une association.

Merci pour ta réponse Idriss. En effet on m'avait déjà dit que les entités devaient être reliée... à part pour certaines exceptions comme pour une entité USER par exemple.

Mais c'est vrai que dans ce cas c'est plutôt parce que je ne savais pas à quoi les relier. Je suppose que je devrais revoir cette partie mais je ne sais pas trop comment m'y prendre.

[CinePhil]

- l'entité PRODUCT regroupe les informations générales des produits proposés par l'entreprise comme le nom du produit (PRODUCT_LABEL), le fait qu'il soit ou non en vente (ON_SALE), etc... Les champs PRICE_x et UNIT_PRICE_x font référence au prix de vente lié à l'unité x.

exemple:
PRICE_1 | UNIT_PRICE_1 | PRICE_2 | UNIT_PRICE_2 | PRICE_3 | UNIT_PRICE_3 |
2.80 | 'verre' | 12.00 | '1/2 bouteille' | 22.00 | 'bouteille' |

Ça commence mal !
Es-tu sûr que tu n'auras jamais plus de 3 catégories de prix différents pour un produit ?
Es-tu sûr que tu en auras toujours 3 ?

- J'ai conscience qu'il y a de petites redondances d'informations (exemple dans l'entité PRODUCT les champs UNIT_PRICE_x reprennent le contenu de l'entité UNIT. C'est vrai que cela risque de poser un problème si je dois effectuer une modification sur les noms des unités dans l'entité UNIT, il me sera alors plus complexe de modifier les UNIT_PRICE_x de l'entité PRODUCT

Effectivement, tu perçois le problème.

Règle de gestion :
Un produit peut être présenté en plusieurs unités de vente et une unité de vente peut présenter plusieurs produits.

MCD :
PRODUCT -1,n----Present----0,n- SALE_UNITY

Tables :
UNIT (u_id, u_label)
PRODUCT (product_id...)
PRODUCT_PRESENTATION (pp_product_id, pp_unit_id, pp_price)

- l'entité CHARAC_WINE créée une identité spécifique pour le vin. ID_CHARAC_WINE doit permettre de réunir les informations spécifiques telles que la région de production (entité REGION), le pays de production (entité COUNTRY), l'appellation du vin (entité MARK) et le type de l'appellation (entité MARK_TYPE).

exemple:
COUNTRY | REGION | MARK | MARK_TYPE |
France | Loire | Saumur | AOC

Si je comprends bien, CHARAC_WINE est une entité fille qui hérite de PRODUCT ?
Dans ce cas, les cardinalités et le nom de l'association sont faux !
CHARAC_WINE -(1,1)----Is----0,1- PRODUCT

Ce qui fait que CHARAC_WINE hérite de l'identifiant du PRODUCT.

Tables :
PRODUCT (ID_PRODUCT, PRODUCT_LABEL...)
CHARAC_WINE (ID_PRODUCT...)

Attention à la boucle entre CHARAC_WINE, COUNTRY et PRODUCT !
Un vin pourrait venir d'un autre pays que celui du produit qui l'identifie.
Tu devrais supprimer l'association entre CHARAC_WINE et COUNTRY.

- l'entité MENU regroupe les différents menus proposé à la carte du restaurant.

Dans cette entité, l'attribut MENU_TEXT ne peut pas être de type Variable characters(350) parce que ce type est normalement codé sur 2 octets (type standard SQL 'character_varying') et a donc une longueur maxi de 255 caractères.

Ton SGBD a peut-être le type non standard SQL TEXT ?

- l'entité GENDER est la civilité des clients (GENDER_SMALL = Mr, Mme, Mlle) (GENDER_LONG = Monsieur, Madame, Mademoiselle)

- l'entité RESERVATION regroupe toutes les informations nécessaires pour effectuer une réservation en ligne. (nom du client, numéro de mobile ou mail pour la confirmation, Nombre de place réservées, Date et heure de réservation, etc...).

- Je n'ai pas relié les entités GENDER, UNIT et RESERVATION parce que je n'en voyais pas l'utilité.

Pour UNIT, c'est fait plus haut.
GENDER se retrouve dans l'entité RESERVATION. Il faut donc associer GENDER et RESERVATION

Parlons de cette entité RESERVATION...
S'il y a un TYPE_RESERVATION, il devrait y avoir une entité TYPE_RESERVATION pour éviter de saisir des types de réservation avec des orthographes différentes.

Est-il nécessaire de séparer la date et l'heure de la réservation ? Il existe le type DATETIME !

GUEST_NAME à 25 caractères, c'est peut-être un peu juste.

RESERVATION_NOTE ne peut pas être de type variable characters (450). Cf. plus haut.

Puisque les réservations se limitent à la table et non aux produits il me parait inutile de relier les réservations à quoi que se soit. (mais peut-être que je me trompe?)

On a déjà vu qu'il fallait l'associer à GENDER.
Ne faudrait-il pas modéliser complètement le système de réservation avec les tables du restaurant ?

RESERVATION -1,n----Reserves----0,1- RESTAURANT_TABLE

À noter qu'avec ces cardinalités, il y aura une table associative.

En effet on m'avait déjà dit que les entités devaient être reliée... à part pour certaines exceptions comme pour une entité USER par exemple.

Mais c'est vrai que dans ce cas c'est plutôt parce que je ne savais pas à quoi les relier. Je suppose que je devrais revoir cette partie mais je ne sais pas trop comment m'y prendre.

En fait tu modélises deux domaines dans le même MCD :
- Les menus
- Les réservations

Comme tu n'as pas modélisé complètement les réservations, tu ne vois pas le lien entre les deux.

Le vois-tu maintenant ?

[ok.Idriss]

Salut.

l'entité GENDER est la civilité des clients (GENDER_SMALL = Mr, Mme, Mlle) (GENDER_LONG = Monsieur, Madame, Mademoiselle)

Une autre remarque : Il est inutile de mettre deux champs qui signifient la même chose (GENDER_SMALL et GENDER_LONG) ...

Pourquoi ne pas créer une entité CLIENT directement avec comme attribut le sexe et un champ permettant de savoir s'il est marié ou non par exemple (en plus du nom, prénom, l'adresse, etc) à la place de cette entité GENDER qui ne comporte que la civilité du client (avec redondance en plus) ?

C'est dans la couche logicielle (avec un langage de programmation) qu'il faut faire une interprétation de ces données. Par exemple, si tu sait qu'un client est de sexe féminin et qu'il est marié, tu saura automatiquement qu'il faut l'appeler Madame ou Mme ...

Un exemple en PHP pour illustrer :

Code php :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
// Résultats des requêtes SQL affectés dans des variables
$sexe = $resultat_requete['sexe_client'];
$marie = $resultat_requete['marie_client'];
 
if ($sexe == 'F' || $sexe == 'f') // F ou f : féminin
{
        if ($marie == 1) // 1 si marié et 0 dans le cas contraire
        {
               $GENDER_SMALL = "Mme";
               $GENDER_LONG = "Madame";
        }
        else
        {
               $GENDER_SMALL = "Mlle";
               $GENDER_LONG = "Ma demoiselle";
        }
}
else
{
        $GENDER_SMALL = "Mr";
        $GENDER_LONG = "Monsieur";
}

Ce client pourra ensuite effectuer une réservation (on peut donc relier les entités CLIENT et RESERVATION par une association EFFECTUER).

Cordialement,
Idriss

[CinePhil]

Je ne suis pas du tout d'accord avec ce que tu suggères ok.Idriss !

La bonne modélisation est l'entité GENDER séparée avec une clé étrangère sur l'identifiant du GENDER dans la table de réservation, ou éventuellement comme tu le suggères dans une table CLIENT qui serait associée à RESERVATION.

Et le fait d'avoir le libellé complet du GENDER et son abréviation permettent par exemple de faire des cartons d'invitation ou d'emplacement à table (avec seulement l'abréviation) et de souhaiter la bienvenue avec la bonne formulation complète à son client quand il arrive au restaurant.

BLJ.CHAUVIN a parlé de réservation "en ligne". La cliente ne voudra peut-être pas dire au restaurant si elle est mariée mais seulement le GENDER qu'elle souhaite qu'on lui attribue.

Au passage, l'abréviation française pour Monsieur est M. et non pas Mr qui est pour Mister en anglais..
Voir quelques civilités sur Wikipédia
Ou chez SQLPro.

[ok.Idriss]

Re

Et le fait d'avoir le libellé complet du GENDER et son abréviation permettent par exemple de faire des cartons d'invitation ou d'emplacement à table (avec seulement l'abréviation) et de souhaiter la bienvenue avec la bonne formulation complète à son client quand il arrive au restaurant.

Dans ce cas remplir un seul champs ne suffit-il pas ? Par exemple, pourquoi garder en mémoire un champs remplis de la mention "Mme" et un autre de la mention "Madame" ?

BLJ.CHAUVIN a parlé de réservation "en ligne". La cliente ne voudra peut-être pas dire au restaurant si elle est mariée mais seulement le GENDER qu'elle souhaite qu'on lui attribue.

Le champs "marié" est une solution (qui n'est peut être pas acceptable) mais on peut aussi bien mettre un seul champs GENDER dans une table CLIENT.

Une autre solution (encore mieux AMHA), c'est d'avoir une table GENDER (id_gender, libelle_gender) associé à une table CLIENT par une association CORRESPONDRE par exemple :

GENDER --- (0,n) - CORRESPONDRE - (1,1) --- CLIENT --- (1,n) - EFFECTUER - (1,1) --- RESERVATION

On aurait trois occurrence pour l'attribut libelle_gender : M, Mme ou Mlle. Après on sait tout de suite comment appeler le client et comment présenter les cartes d'invitations.

Au passage, l'abréviation française pour Monsieur est M. et non pas Mr qui est pour Mister en anglais.

Merci du renseignement

Cordialement,
Idriss

[CinePhil]

Une autre solution (encore mieux AMHA), c'est d'avoir une table GENDER (id_gender, libelle_gender) associé à une table CLIENT par une association CORRESPONDRE par exemple :

GENDER --- (0,n) - CORRESPONDRE - (1,1) --- CLIENT --- (1,n) - EFFECTUER - (1,1) --- RESERVATION

C'est bien comme ça que je l'entendais.

Si on veut générer un carton d'invitation, on utilisera de préférence la civilité complète :
"Monsieur Octave Du Pont a l'honneur d'inviter Mademoiselle Gertrude Du Moulin..."

Si on veut mettre un petit carton à chaque place à table, on utilisera plutôt l'abréviation :
"M. Octave Du Pont" ou "Mlle Gertrude Du Moulin"

Si on veut écrire à ses clients pour leur faire part de la nouvelle carte de menus et spécialités pour l'été, on utilisera la civilité complète :
"Cher Monsieur Du Pont..."

Et sur l'enveloppe peut-être l'abréviation : "M. Octave Du Pont..."

Ce n'est pas de la redondance de mettre l'abréviation et le libellé complet mais simplement la totalité de l'information souhaitée et utilisable.

Mais bon tout ça est du détail par rapport à la critique général du MCD.

[fsmrel]

Bonjour,

Un exemple en PHP pour illustrer :

Code PHP :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
 
// Résultats des requêtes SQL affectés dans des variables
$sexe = $resultat_requete['sexe_client'];
$marie = $resultat_requete['marie_client'];
 
if ($sexe == 'F' || $sexe == 'f') // F ou f : féminin
{
        if ($marie == 1) // 1 si marié et 0 dans le cas contraire
        {
               $GENDER_SMALL = "Mme";
               $GENDER_LONG = "Madame";
        }
        else
        {
               $GENDER_SMALL = "Mlle";
               $GENDER_LONG = "Ma demoiselle";
        }
}
else
{
        $GENDER_SMALL = "Mr";
        $GENDER_LONG = "Monsieur";
}

Je fais partie de ceux qui ne connaissent pas PHP, aussi seriez-vous aimable de fournir la traduction en SQL (normé tant qu’à faire) du code que vous proposez.

pourquoi garder en mémoire un champs remplis de la mention "Mme" et un autre de la mention "Madame" ?

On est au niveau conceptuel, donc parler de « garder en mémoire » n’est pas de mise, ceci relève du niveau physique. De même, utiliser le terme « champs » n’est pas non plus de mise en dehors du niveau physique.

Maintenant, définir un attribut GENDER_SMALL prenant les valeurs « Mme », etc. et un attribut GENDER_LONG prenant les valeurs « Madame », etc. est on ne peut plus valide, tant du point de vue conceptuel (Merise et Cie) que du point de vue de la théorie relationnelle, puisque la variable relationnelle dérivée de l’entité-type GENDER respecte la cinquième forme normale. Et qui plus est, on reste dans l’esprit du Modèle Relationnel de Données tel que l’a conçu Ted Codd, lequel aurait donné un satisfecit à CinePhil.

[ok.Idriss]

Ce n'est pas de la redondance de mettre l'abréviation et le libellé complet mais simplement la totalité de l'information souhaitée et utilisable.

Si on n'a que trois occurrences cela peut être en effet plus avantageux. J'avais mal compris au départ, je pensait (sûrement à tort) que l'entité GENDER posséderait une occurrence par client .

On est au niveau conceptuel, donc parler de « garder en mémoire » n’est pas de mise, ceci relève du niveau physique. De même, utiliser le terme « champs » n’est pas non plus de mise en dehors du niveau physique.

On est certes au niveau conceptuel donc oui on ne parle pas de champs mais d'attributs ou de propriété d'une entité et de donnée portée pour une association, je suis au courant . C'est un manque d'attention de ma part d'avoir parlé de champs pour une entité ...

Mais le niveau conceptuel n'est la que pour mettre en oeuvre le niveau physique : il faut donc songer dès maintenant à l'optimisation (en l'occurrence prendre le moins de place possible) tout en restant cohérent et valide au niveau conceptuel.

Je fais partie de ceux qui ne connaissent pas PHP, aussi seriez-vous aimable de fournir la traduction en SQL (normé tant qu’à faire) du code que vous proposez.

Il s'agit juste d'un simple algo qui montre comment interpréter des données sans avoir à écrire dans la base à propos d'une suggestion que j'avais émise (mais qui n'est pas la meilleur solution, voir les messages précédents). En gros :

$sexe est une variable ayant pour valeur la donnée contenu dans le champs sexe d'une occurrence de la table CLIENT. La variable $marie à pour valeur la donnée contenu dans le champs marie de cette même occurrence de la table CLIENT (je parle ici au niveau physique et non conceptuel bien entendu).

$GENDER_SMALL et $GENDER_LONG sont des variables qui contiendront en fonction de tests la mention M, Mme et Mlle pour $GENDER_SMALL et Monsieur, Madame et Ma demoiselle pour $GENDER_LONG.

Et voici l'algo de manière compréhensible :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
SI $sexe à pour valeur 'F' ou 'f' (féminin) ALORS
    SI $marie à pour valeur 1 (marié) ALORS
        $GENDER_SMALL aura pour valeur "Mme"
        $GENDER_LONG aura pour valeur "Madame"
     SINON
        $GENDER_SMALL aura pour valeur "Mlle"
        $GENDER_LONG aura pour valeur "Ma demoiselle"
     FIN SI
SINON
    $GENDER_SMALL aura pour valeur "M"
     $GENDER_LONG aura pour valeur "Monsieur"
FIN SI

Je sais que le test IF existe sous MySQL mais je ne suis pas sûr qu'il soit normalisé (je ne connais pas la norme assez bien pour m'avancer sur ce sujet).

Mais bon là n'est plus la question ...

Cordialement,
Idriss

[BLJ.CHAUVIN]

Milles mercis pour vos nombreuses et pertinentes réponses!

J'ai mis du temps à poster une réponse parce que j'ai voulu tester un peu et réfléchir dessus avant de dire n'importe quoi.

Je vais tenter de vous répondre point par point et ensuite de vous présenter la nouvelle version du MCD.

@ CinePhil :

"Es-tu sûr que tu n'auras jamais plus de 3 catégories de prix différents pour un produit ?
Es-tu sûr que tu en auras toujours 3 ?"

Tel Pyrrhon je ne suis sûr de rien. Après réflexion j'ai opté pour la solution d'une entité PROD_PRICE comme tu me le conseillais (enfin un peu modifié quand même tu me diras ce que tu en penses).

"Attention à la boucle entre CHARAC_WINE, COUNTRY et PRODUCT !
Un vin pourrait venir d'un autre pays que celui du produit qui l'identifie.
Tu devrais supprimer l'association entre CHARAC_WINE et COUNTRY."

En fait j'ai choisi de supprimer l'association MADE_IN entre PRODUCT et COUNTRY qui ne sera pas utilisée pour les produits autres que le vin.

J'ajoute que pour la cardinalité : "CHARAC_WINE -(1,1)----Is----0,1- PRODUCT" que tu proposes je ne suis pas d'accord. Plusieurs vins peuvent avoir les mêmes caractéristiques (les vins d'appellation Saumur, fabriqués en Loire et provenant de France sont nombreux, je dois donc partager ces caractéristiques avec plusieurs domaines viticoles)

"S'il y a un TYPE_RESERVATION, il devrait y avoir une entité TYPE_RESERVATION pour éviter de saisir des types de réservation avec des orthographes différentes."

C'est exacte, mais TYPE_RESERVATION était un déchet d'une précédente version que je n'avais pas pris soin d'effacer. C'est maintenant chose faite.

"GENDER se retrouve dans l'entité RESERVATION. Il faut donc associer GENDER et RESERVATION"

Tout à fait d'accord, j'ai supprimé GUEST_GENDER_SMALL et GUEST_GENDER_LONG de l'entité RESERVATION. Et j'ai créé une association IS_SEXED entre GENDER et RESERVATION.

@ ok.Idriss :

Je ne souhaite pas créer d'entité CLIENT. De plus la réservation se fait par un simple formulaire j'éviterai donc de poser des questions personnelles comme la date de naissance ou le statut (marié, célibataire, veuf) qui me semble t-il seraient perçues comme indiscrètes pour une simples réservation.

C'est pour cette raison que j'ai choisi de créer l'entité GENDER.


Voici maintenant la nouvelle version de mon modèle conceptuel de données:


Cela vous semble t-il correct maintenant?

Si vous voulez j'ai généré le Modèle physique de données, si ça peut vous aider à vous faire une meilleur idée du résultat final avec ce MCD.

Et encore merci pour vos réponses éclairées!

Cordialement

[ok.Idriss]

Bonsoir.

Je ne souhaite pas créer d'entité CLIENT. De plus la réservation se fait par un simple formulaire j'éviterai donc de poser des questions personnelles comme la date de naissance ou le statut (marié, célibataire, veuf) qui me semble t-il seraient perçues comme indiscrètes pour une simples réservation.

Tu peut choisir les infos que tu veut pour composer l'entité client : Un nom, Email et un numéros de téléphone par exemple. Tu n'es pas obligé de mettre des informations personnelles comme la date de naissance ou le statut comme tu dis. Le truc là c'est que tu fusionnes les informations d'un client avec celles d'une réservation dans une même entité et ça c'est discutable : d'un côté il s'agit bien d'informations qui concernent l'auteur de la réservation (donc de la réservation indirectement), de l'autre un client et une réservation sont deux choses bien distinctes et à partir du moment ou tu as plusieurs attributs (et là c'est le cas) et on se retrouve donc dans un cas de "multi-attribut" comme les appelles CinePhil.

Sauf que dans le cas présent, tu ne veut faire qu'un seul formulaire de réservation et le plus simple est peut être de laisser comme tu as fait dans ton MCD. Si tu crée une entité client avec un formulaire d'inscription en plus d'un formulaire de réservation, tu évitera la duplication de certaines informations (dans le cas ou une même personne effectue plusieurs réservations) mais tu perdra en simplicité d'utilisation (car il te faudra un formulaire d'inscription, d'authentification et de réservation). Un autre avantage c'est qu'une inscription avec authentification peut limiter le nombre de fausses réservations volontaire. Bref c'est à toi de voir .

Sinon ton MCD est dissocié en deux parties, il faudrait essayer de trouver au moins une association qui fait le raccord pour qu'il soit valide.

Cordialement,
Idriss

[f-leb]

bonsoir, je m'immisce

je me demandais comment on allait retrouver le prix du verre de champagne avec l'entité PROD_PRICE dans le bout de schéma:

PRODUCT---0,n---sold---1,1---PROD_PRICE---1,n---normalized---0,n---UNIT

Erreur de cardinalités ?

La solution proposée par CinePhil avec la propriété Price_Product portée par l'association Present semble plus pertinente, non ?

Règle de gestion :
Un produit peut être présenté en plusieurs unités de vente et une unité de vente peut présenter plusieurs produits.

MCD :
PRODUCT -1,n----Present----0,n- SALE_UNITY

Tables :
UNIT (u_id, u_label)
PRODUCT (product_id...)
PRODUCT_PRESENTATION (pp_product_id, pp_unit_id, pp_price)

[BLJ.CHAUVIN]

Bonsoir,

Merci d'avoir attiré mon attention sur cette boulette, en effet il y avait bien une erreur de cardinalité entre PROD_PRICE et UNIT.

Pour être sûr d'avoir bien corrigé je vais détaillé mon raisonnement, vous me direz si cela vous parait plus juste.



PRODUCT---0,n---sold---1,1---PROD_PRICE---1,1---normalized---0,n---UNIT

Donc un 'produit' (PRODUCT) peut avoir 0 ou n 'prix de vente' (PROD_PRICE) comme le champagne qu'on peut vendre à la bouteille ou au verre. Un 'prix de vente' ne se réfère qu'à un et un seul 'produit' (mais dans ce cas le(s) 'prix de vente' d'un produit supprimé devrait être effacé(s) en même temps que le 'produit').

Un 'prix de vente' ne peut être relié qu'à une et une seule 'unité' (UNIT). Par contre une 'unité' peut avoir 0 ou n 'prix'. (l'unité "bouteille" sera surement utilisée par plusieurs produits).

Cela vous semble t-il correcte de cette façon? Je poste un bout du modèle physique de données pour vous montrer ce que cela donne par la suite :



J'espère que le problème est réglé de cette façon.

Ps: Ce n'est pas que je ne veuille pas utilisé la solution proposée par CinePhil, c'est juste que par un étrange blocage cognitif je ne parviens pas à appréhender cette solution. Je bloque dessus et je ne vois pas la différence. Si quelqu'un se sent l'âme d'un professeur je tâcherai d'être un élève attentif.

[f-leb]

bonjour,

Il serait encore plus juste de transformer cette entité PROD_PRICE en association SOLD. L'association SOLD portera l'attribut Price_Product.

(voir Attributs d'associations, pour aller plus loin )

[BLJ.CHAUVIN]

Merci pour le conseil, c'est une très bonne idée en effet.

Du coup j'en ai profité pour déplacer 'ON_SALE' qui était dans l'entité 'PRODUCT' pour le mettre dans l'association 'SOLD' ce qui me permettra de stopper la vente d'un produit sous certaines unités mais de continuer avec d'autres (exemple: je peux arrêter momentanément la vente de la 1/2 bouteille de vin "Cuvée du père Glouglou" tout en continuant de vendre au verre et à la bouteille entière).

Je crois que maintenant mon mcd est complet et efficace. Si personne n'y trouve à redire d'ici ce soir 20:00 je commencerais à travailler avec cette forme de modèle.

Merci à tous pour le coup de main!