Discussion :

[francois974]

bonjour,
j'essaye de modéliser une application destinée à des restaurants qui livrent de s repas le midi sur des secteurs géographiques prédéfinis.

l'application permet notamment
- aux restaurants de proposer une carte
- aux clients de passer une commande (pas de paiements gérés par l'application)

voici les principes de ma modélisation
- les restos possedent plusieurs cartes du jour (une seule publiée a un jour j)
- chaque carte est composée de plats (ex: poulet roti, gratin dauphinois..
- chaque plat est disponible dans un format(ex: portion, demi portion...) à un prix déterminé

voici un première partie de la modélisation qui concerne les restos (pas en core de clients et de commandes pris en compte) pourriez vous me dire si ma modélisation convient. merci

[Richard_35]

Bonjour Francois974,

En termes de conception, ton MCD est parfait !

En termes de fonctionnalité, juste une suggestion (en rouge l'association réflexive "Etre carte du jour" avec l'attribut "Date") :



Ce qui te permettrait de planifier, à l'avance, les cartes du jour. Contrairement au MCD d'origine qui, si j'ai bien compris, prévoit un champ booléen (oui/non) pour indiquer la carte du jour, sans indication de date donc, non historisée.

[francois974]

merci de ta réponse ca permet d'avancer plus tranquille. En plus pouvoir planifier les cartes du jour c'est trés bien.
j'ai complété mon mcd pour y intégrer des données relatives aux clients et aux commandes. et là aussi j'aimerais un avis et/ou des conseils ( en particulier sur les associations qui lient les entités plats, formats, lignesDecommande . Est-ce que cette modélisation fonctionne toujours ?

[CinePhil]

Pour commencer par quelque chose de simple, je dirais plutôt qu'une commande est composée d'au moins une ligne de commande.

Ensuite, tu es tombé dans le piège de la boucle, déjà maintes fois évoqué ici.

Une commande peut avoir une ligne de commande concernant un plat dans un certain format entrant dans la composition d'une carte possédée par un restaurant qui ne livre pas à au site de livraison souhaité par la commande !

J'ajoute, pour lancer la modification du MCD, qu'une association tertiaire avec une patte possédant des cardinalités 1,1 est le signe d'une erreur.

Commençons par transformer cette association "existeEn" en entité type associative car ce qui sera commandé sera effectivement un plat dans un certain format.

Plat -1,n----définir----(1,1)- Produit -(1,1)----préciser----0,n- Format

Nota : Cardinalités entre parenthèse => identification relative. Pas sûr que tu puisse le faire avec Analyse SI.

Au passage, remarque que j'ai nommé les entités types au singulier et les association avec des verbes à l'infinitif ; c'est mieux, surtout pour le singulier.

Nous pouvons maintenant effectivement commander ce produit dans une ligne de commande :

Commande -1,n----comprendre----(1,1)- LigneCommande -1,1----concerner----0,n- Produit

D'après ton schéma, la commande est passée à un site de livraison et non pas à un restaurant. Est-ce normal ?

Autre ambiguïté dans ton schéma : Si un plat P existe dans les formats F1 et F2, ces formats seront tous dans les cartes des restaurants qui proposent ce plat ?

[Richard_35]

Bonjour Francois974 et Philippe,

Outre les remarques de CinePhil , si tu es OK avec l'association réflexive, intègres-la dans un MCD à jour : nous verrons, ainsi, les évolutions de version.

[francois974]

merci pour ces remarques !

Une commande peut avoir une ligne de commande concernant un plat dans un certain format entrant dans la composition d'une carte possédée par un restaurant qui ne livre pas à au site de livraison souhaité par la commande !

oui tu as raison mais comment résoudre ce problème au niveau du MCD ? comment garantir que le lieu de livraison est desservi par resto ou je commande le plat. je ne vois pas de solutions pour l'instant
je veux que les restos puissent décider de leurs sites de livraison. et que les clients qui commandent choisissent parmis les site de livraisons proposés par le restaurant. ici une commande correspond à un lieu de livraison unique.

D'après ton schéma, la commande est passée à un site de livraison et non pas à un restaurant. Est-ce normal ?

voila comment je voyais la chose (corriges moi si c'est bancal):
on peut "retrouver" le resto en "passant" par commande ->ligne de commandes -> produits ->plat -> carte ->restos. donc la commande est rattachée au resto.
il fallait aussi la rattacher la commande à un lieu de livraison c'est pour cela que j'ai fait l'association. on en revient au problème précédent: effectivement rien au niveau du mcd ne contraint le choix du lie de livraison .quelle modélisation peut y remèdier ?

[francois974]

Voici une nouvelle version du mcd. je crois que je touche aux limites de analyseSI : je n'arrive pas à faire des liens identifiants ni des asso réflexives.

[CinePhil]

voila comment je voyais la chose (corriges moi si c'est bancal):
on peut "retrouver" le resto en "passant" par commande ->ligne de commandes -> produits ->plat -> carte ->restos. donc la commande est rattachée au resto.

Sauf que comme tu n'as pas que des cardinalités (1,1 - 0,n) dans cette chaîne, on ne peut pas retrouver quel restaurant propose tel plat.

J'ai l'impression que ta notion de "carte" n'est là que pour dire qu'un ensemble de plats est disponible tel jour et pas tel autre.

Ne pourrait-on pas la supprimer et dire qu'un produit, constitué d'un ensemble {plat, format}, est proposé par un à plusieurs restaurants pour une à plusieurs dates ?

restaurant -0,n----proposer----0,n- produit
date -0,n------------------|

Détail à préciser : un restaurant propose t-il ses produits dans tous ses points de livraison ou bien peut-il n'en proposer certains que dans certains points de livraison ?

S'il propose dans tous ses points de livraison, on laisse la ternaire. Sinon, on peut passer en quaternaire :

point_livraison -0,n----|
restaurant -0,n----proposer----0,n- produit
date -0,n------------------|

On pourra ensuite transformer de nouveau cette association en table associative pour pouvoir pointer une ligne de commande dessus.

restaurant -0,n----proposer----(1,1)- produit_disponible -(1,1)----concerner----0,n- produit
date -0,n----rendre_disponible----(1,1)------|

L'identifiant de la table issue de l'entité type "produit_disponible" sera constitué des identifiants du produit (donc du plat + du format), du restaurant et de la date.

il fallait aussi la rattacher la commande à un lieu de livraison c'est pour cela que j'ai fait l'association. on en revient au problème précédent: effectivement rien au niveau du mcd ne contraint le choix du lie de livraison .quelle modélisation peut y remèdier ?

Si un produit_disponible l'est dans tous les points de livraison du restaurant, le problème est directement résolu. Il suffit que le client choisisse le point de livraison qu'il souhaite parmi ceux délivrés par le restaurant qui propose le produit disponible qu'il commande.

Sinon, en associant le point de livraison en identification relative au produit_disponible, c'est alors la ligne de commande qui est associée automatiquement au point de livraison. Si le client commande plusieurs produits qui sont disponibles dans des points de vente différents, et bien il fera des kilomètres !

[francois974]

à cinephil

Sauf que comme tu n'as pas que des cardinalités (1,1 - 0,n) dans cette chaîne, on ne peut pas retrouver quel restaurant propose tel plat.

ok.Donc avec des cardinalités 1,1 et 1,N je peux retrouver mon resto ?

J'ai l'impression que ta notion de "carte" n'est là que pour dire qu'un ensemble de plats est disponible tel jour et pas tel autre.

c'est vrai l'entité carte m'a semblé "naturelle". ta façon de faire pour gérer la disponibilité des produits est meilleure. je pense que j'utiliserai le concept de carte pour géréer des aspects de présentation

Ne pourrait-on pas la supprimer et dire qu'un produit, constitué d'un ensemble {plat, format}, est proposé par un à plusieurs restaurants pour une à plusieurs dates ?

oui on peut supprimer la carte telle qu'elle est définie . Cependant dans mon modele chaque resto peut nommer son plat comme il l'entend même si des plats similaires portent des noms différents. Chaque resto définira ses propres plats et ne pourra pas utiliser les plats d'un autre. idem pour les formats.

Détail à préciser : un restaurant propose t-il ses produits dans tous ses points de livraison ou bien peut-il n'en proposer certains que dans certains points de livraison ?

Dans la modélisation que je veux réaliser tous les produits d'un restaurant sont disponibles dans tous ses points de livraison




J'ai une question: les lignes de commandes concernent elles "les produits" ou "les produits disponibles" . je dirais qu'avec "produit" ca marche à tous les coups . En revanche, pour "produit disponible" ne faudrait il pas lier la date de disponibilite du produit et la date de livraison de la commande ? comment faire cela ?

[CinePhil]

Dans ton dernier message, ceci est très important et aurait mérité d'être précisé plus tôt :

chaque resto peut nommer son plat comme il l'entend même si des plats similaires portent des noms différents. Chaque resto définira ses propres plats et ne pourra pas utiliser les plats d'un autre. idem pour les formats.

Si je traduis correctement :
Un plat est proposé par un seul restaurant et un restaurant peut proposer plusieurs plats.
Un plat existe dans un à plusieurs formats et un format peut exister pour plusieurs plats.
Un format appartient à un seul restaurant et un restaurant peut avoir plusieurs formats.

Ces règles de gestion sont exactes ?

J'ai une question: les lignes de commandes concernent elles "les produits" ou "les produits disponibles" . je dirais qu'avec "produit" ca marche à tous les coups . En revanche, pour "produit disponible" ne faudrait il pas lier la date de disponibilite du produit et la date de livraison de la commande ? comment faire cela ?

J'avais écrit ceci :

On pourra ensuite transformer de nouveau cette association en table associative pour pouvoir pointer une ligne de commande dessus.

restaurant -0,n----proposer----(1,1)- produit_disponible -(1,1)----concerner----0,n- produit
date -0,n----rendre_disponible----(1,1)------|

Il faut faire pointer la ligne de commande sur produit_disponible sinon on peut commander un produit le 23 octobre qui n'était disponible que le 12 juillet.

Dans son état actuel, en plus d'associer la ligne de commande à produit_disponible et non pas à produit, il faut aussi prévoir une contrainte d'inclusion entre la dateALivrer de la commande et la date de disponibilité du produit.

Mais en fonction de ta réponse sur les règles de gestion que j'ai émises ci-dessus, le MCD peut changer ou au moins nécessiter une autre contrainte.

[francois974]

à cinephil
merci de continuer à m'aider. Cela me fait beaucoup progresser.

Un plat est proposé par un seul restaurant et un restaurant peut proposer plusieurs plats.
Un plat existe dans un à plusieurs formats et un format peut exister pour plusieurs plats.
Un format appartient à un seul restaurant et un restaurant peut avoir plusieurs formats.

c 'est exact .

et aurait mérité d'être précisé plus tôt

C'est noté.mais c'est justement dans les interactions sur le forum que je me rends compte de ce qui est important...

On pourra ensuite transformer de nouveau cette association en table associative pour pouvoir pointer une ligne de commande dessus

ok.

prévoir une contrainte d'inclusion entre la dateALivrer de la commande et la date de disponibilité du produit

je comprends ce que cela signifie mais comment représente-t-on cela sur mon mcd ?

[CinePhil]

Pour les contraintes, il y a des exemples dans la FAQ. Tu trouveras aussi des réponses plus complètes dans les tutoriels. Il y en a un plus récent qui n'est pas référencé dans la liste des tutos Merise de DVP et qui développe le sujet des contraintes.

[francois974]

bonjour,
voici une version modifiée et actualisée du mcd
J'ai cependant un problème: je ne sais pas comment faire figurer les contraintes entre "date à livrer de la commande" et "dispo du produit".
pourtant j'ai bien consulter les références (tuto,cours...) conseillés mais la configuration de mon mcd ne semble pas "coller" aux exemples donnés.
cette contrainte releve-t -elle du mcd ou plutot des traitement ?

[CinePhil]

Ouh là ! Tu as ajouté trop de choses !

Comme un produitDisponible ne concerne qu'un seul produit qui est défini par un seul plat, si un restaurant propose ce produitDisponible, c'est donc qu'il cuisine ce plat.
=> L'association cuisiner est inutile. De plus, elle crée une nouvelle boucle pouvant créer une incohérence de données.

Idem pour l'association conditionner, tout aussi inutile car on peut retrouver les formats conditionnés par un restaurant à travers les produits disponibles qu'il propose.

Idem pour l'association "commander à". La commande est composé de lignes de commande qui concernent des produits disponibles qui sont proposés par un restaurant.

L'éventuelle contrainte à définir est si une commande ne peut comprendre que des produitsDisponibles proposés par un seul restaurant. Cette éventuelle contrainte, tu peux la formaliser simplement par une note écrite et pointant par un pointillé sur l'association "concerner" entre "LigneDeCommande" et "ProduitDisponible".

J'ai cependant un problème: je ne sais pas comment faire figurer les contraintes entre "date à livrer de la commande" et "dispo du produit".

Ne peux-tu relier cette contrainte à "Commande" d'une part et à "rendreDisponible" d'autre part ?

Il faudrait prévoir aussi une contrainte qui spécifie que le site de livraison qui livre la commande doit être desservi par le restaurant auquel les produits disponibles sont commandés.

J'avoue que ces contraintes ne me semblent pas faciles à représenter et introduisent chez moi un doute sur la justesse du MCD que nous avons établi. J'aimerais bien qu'un autre donne son avis.

[francois974]

une question sans doute naive
si dans mon application je souhaite que chaque resto puisse définir ses formats et ses plats (par exemple via un formulaire) ne faut il pas que dans le mcd resto soit associé a format et resto soit associé à plats. pour que chaque resto trouve directement ses plat ses formats...
idem pour commande ?

C'est pour cela que j'ai rajouté ces associations. légitime ou incohérent ?

[fsmrel]

J'aimerais bien qu'un autre donne son avis.

On va s'en occupationner !

[fsmrel]

Bonjour,


J’ai regardé l’introduction et la conclusion, en jetant un regard rapide sur les messages intermédiaires.

Ce que je comprends à peu de choses près :

Côté restaurants :

Des restaurants proposent une carte du jour.
Une carte du jour d’un restaurant donné propose un détail de plats.
Un plat d’une carte du jour et d’un restaurant donnés est proposé selon différents formats.

Côté Commandes

Un restaurant est en relation avec différents sites de commande/livraison.
Un client peut passer commande à un restaurant donné pour un site de livraison donné.
Une commande d’un client comporte autant de lignes que de types de plats commandés.

Je quitte le niveau conceptuel pour le niveau relationnel, peut-être moins bon pour exprimer la sémantique, mais plus approprié pour représenter les contraintes (chose pas toujours facile (euphémisme) avec les MCD).

Les restos :

Code :

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

1
2
RESTO {RestoId, ...}
       KEY {RestoId} ;

Les plats et les formats :

Si j’ai bien compris, chaque plat est propre à un restaurant, même s’il s’agit de quelque chose de lambda, du genre demi-poulet. Soit. Cela conditionne la composition de la clé. Même principe pour les formats. PlatId et FormatId sont des attributs permettant de mettre en oeuvre l’identification relative :

Code :

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

1
2
3
4
5
6
7
PLAT {RestoId, PlatId, ...}
       KEY {RestoId, PlatId}
       FOREIGN KEY {RestoId} REFERENCES RESTO ; 

FORMAT {RestoId, FormatId, ...}
       KEY {RestoId, FormatId}
       FOREIGN KEY {RestoId} REFERENCES RESTO ;

Pour que les clients choisissent des plats compatibles avec les formats, on définit un référentiel des paires {plat, format} par restaurant :

Code :

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

1
2
3
4
PLAT_FORMAT {RestoId, PlatId, FormatId, ...}
       KEY {RestoId, PlatId, FormatId}
       FOREIGN KEY {RestoId, PlatId} REFERENCES PLAT
       FOREIGN KEY {RestoId, FormatId} REFERENCES FORMAT ;

La carte du jour d’un restaurant et son contenu détaillé. CarteSeq sert à mettre en œuvre l’identification relative. Noter que {RestoId, CarteDate} est clé (alternative) :

Code :

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

1
2
3
4
CARTE {RestoId, CarteSeq, CarteDate, ...}
       KEY {RestoId, CarteSeq}
       KEY {RestoId, CarteDate}
       FOREIGN KEY {RestoId} REFERENCES RESTO ;

CarteDetailSeq sert à mettre en œuvre l’identification relative. J’ai fait figurer le prix à cet endroit dans la mesure où il peut changer d’un jour à l’autre pour un même triplet {resto, plat, format}.

Code :

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

1
2
3
4
CARTE_DETAIL {RestoId, CarteSeq, CarteDetailSeq, PlatId, FormatId, Prix, ...}
       KEY {RestoId, CarteSeq, CarteDetailSeq}
       FOREIGN KEY {RestoId, CarteSeq} REFERENCES CARTE
       FOREIGN KEY {RestoId, PlatId, FormatId} REFERENCES PLAT_FORMAT ;

Les sites et leurs relations avec les restos :

Code :

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

1
2
3
4
5
6
 SITE {SiteId, ...}
        KEY {SiteId} ;

RESTO_SITE {RestoId, SiteId, ...}
        KEY {RestoId, SiteId}
        FOREIGN KEY {RestoId} REFERENCES RESTO ;

Les commandes :

Un client passe commande à un resto et choisit aussi le site de livraison (lequel est compatible avec le resto). A noter que le séquenceur CarteDetailSeq de la table CARTE_DETAIL sert à l’identification relative de la table LIGNE_CDE des lignes de commande :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
CLIENT {ClientId, ...}
       KEY {ClientId} ; 

COMMANDE {ClientId, RestoId, CdeSeq, SiteId}
        KEY {ClientId, RestoId, CdeSeq}
        FOREIGN KEY {ClientId} REFERENCES CLIENT
        FOREIGN KEY {RestoId, SiteId} REFERENCES RESTO_SITE ; 

LIGNE_CDE {ClientId, RestoId, CdeSeq, CarteSeq, CarteDetailSeq, Quantite, ...}
        KEY {ClientId, RestoId, CdeSeq, CarteDetailSeq}
        FOREIGN KEY {ClientId, RestoId, CdeSeq} REFERENCES COMMANDE
        FOREIGN KEY {RestoId, CarteSeq, CarteDetailSeq} REFERENCES CARTE_DETAIL ;

Tout ceci correspond à une approche relationnelle d’un univers du discours que j’ai plus ou moins bien interprété. A vous de me dire ce qui ne va pas.

Vous noterez que l’attribut RestoId (entre autres) est propagé au maximum dans les « tables » : c’est le moyen permettant de résoudre les contraintes de chemin. Quant à faire de la rétro-conception en MCD, ça me paraît mission délicate...

[CinePhil]

Merci d'intervenir François, avec cette autre approche intéressante.

Un client passe commande à un resto et choisit aussi le site de livraison (lequel est compatible avec le resto).

Code :

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

1
2
3
4
COMMANDE {ClientId, RestoId, CdeSeq, SiteId}
        KEY {ClientId, RestoId, CdeSeq}
        FOREIGN KEY {ClientId} REFERENCES CLIENT
        FOREIGN KEY {RestoId, SiteId} REFERENCES RESTO_SITE ;

Ne manque t-il pas SiteId dans la clé puisque la clé étrangère référence RESTO_SITE ?

Code :

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

KEY {ClientId, RestoId, SiteId, CdeSeq}

Propagation dans LIGNE_COMMANDE :

Code :

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

KEY {ClientId, RestoId, SiteId, CdeSeq, CarteDetailSeq}

Quant à faire de la rétro-conception en MCD, ça me paraît mission délicate...

Je pense que ça donne ceci :


Il reste une contrainte à placer entre les associations "Livrer" et "Concerner" (cette dernière étant celle entre "Ligne_Cde" et "Carte_Detail") pour imposer que RestoId soit le même afin déviter de demander un site de livraison non desservi par le restaurant qui prépare le plat que l'on commande.

Chouette exercice !

[fsmrel]

MCD net et chouette, du cousu main.

Ne manque t-il pas SiteId dans la clé puisque la clé étrangère référence RESTO_SITE ?

Que nenni ! Ça n’est parce que la clé étrangère {RestoId, SiteId} référence RESTO_SITE que l’attribut SiteId aurait à être élément de quelque clé candidate que ce soit de la table COMMANDE, orthogonalité oblige. Les seules contraintes auxquelles sont soumises une clé candidate sont celles d’unicité et d’irréductibilité :

Unicité : Deux lignes de la table COMMANDE ne peuvent pas avoir la même valeur de clé.

Irréductibilité : Il n’existe pas de sous-ensemble strict de la clé garantissant l’unicité.

L’attribut CdeSeq est relatif. En l’occurrence il a pour seul objet d’éviter les doublons pour la paire {ClientId, RestoId} puisqu’un client peut passer plusieurs fois commande au même restaurant :

Code :

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

1
2
3
4
5
ClientId    RestoId    CdeSeq
--------    -------    ------
cli01       resto01         1
cli01       resto01         2
...         ...           ...

J’aurais pu identifier relativement au triplet {ClientId, RestoId, SiteId}, mais il n’y a aucune valeur ajoutée, au contraire. On n’a pas besoin du site pour établir un pont entre les lignes de commande et les menus proposés. En conséquence : rasoir d’Ockham...

Cela dit, si identifier relativement au triplet {ClientId, RestoId, SiteId} permet de faciliter la rétro-conception, va malgré tout pour tolérer l'intégration de SiteId dans la clé, qu'Ockham nous pardonne...

Il reste une contrainte à placer entre les associations "Livrer" et "Concerner" (cette dernière étant celle entre "Ligne_Cde" et "Carte_Detail") pour imposer que RestoId soit le même afin déviter de demander un site de livraison non desservi par le restaurant qui prépare le plat que l'on commande

Certes, il faut que le resto de Ligne_Cde soit le même que celui de Carte_Detail, mais lequel choisir parmi les trois restos dont hérite Carte_Detail si l'on se fie au MCD ?


Accessoirement, il y a une contrainte supplémentaire à prendre en compte :

les restos possèdent plusieurs cartes du jour (une seule publiée à un jour j)

Comment rétro-concevoir la clé {RestoId, CarteDate} de la table CARTE ?

[CinePhil]

COMMANDE {ClientId, RestoId, CdeSeq, SiteId}
KEY {ClientId, RestoId, CdeSeq}
FOREIGN KEY {ClientId} REFERENCES CLIENT
FOREIGN KEY {RestoId, SiteId} REFERENCES RESTO_SITE ;

Ne manque t-il pas SiteId dans la clé puisque la clé étrangère référence RESTO_SITE ?

Que nenni ! Ça n’est parce que la clé étrangère {RestoId, SiteId} référence RESTO_SITE que l’attribut SiteId aurait à être élément de quelque clé candidate que ce soit de la table COMMANDE, orthogonalité oblige.

COMMANDE comprend les attributs RestoId et SiteId et la clé étrangère référence le couple {RestoId, SiteId} qui est l'identifiant de RESTO_SITE. Ça me choque de voir cet identifiant coupé en deux pour n'en prendre qu'une moitié dans la clé (primaire) de COMMANDE !

Dans mon MCD, j'ai traduit cet ensemble, en ajoutant SiteId à la clé primaire, par une identification de COMMANDE relativement à RESTO_SITE. Si je retire SiteId de la clé primaire, il me semble que je doive cette fois identifier COMMANDE relativement à RESTO et non plus à RESTO_SITE. Ce qui ajoute mécaniquement une association entre COMMANDE et RESTO. N'y a t-il pas alors redondance avec l'association entre COMMANDE et RESTO_SITE ? Et même une incohérence potentielle qui fait qu'on peut passer commande à un RESTO et se faire livrer au site choisi par un autre RESTO ?

Dans le MCD ne figurent pas les clés étrangères mais pour rétro-concevoir le MCD, je me suis servi de celles-ci pour établir les identifications relatives. Cela m'a semblé la manière la plus rationnelle et logique de faire.

Si je génère le schéma ER à partir du MCD, avec les clés étrangères, comme je le pensais, Open Modelsphere prend l'intégralité de la clé référencée dans la table référante et on se retrouve avec plusieurs fois la même colonne :


Je manque de temps pour nettoyer ce schéma ER et voir ce qu'en pense Open Modelsphere.