Discussion :

[tavarlindar]

Bonjour

Voilà j’ai un gros souci de conception de MCD.
J’ai plusieurs options et je ne sais laquelle choisir.

Lorsque ce post sera clôturé, j'espère reproduire une partie de Microsoft Money pour ce qui est de la partie Compte bancaire. Toutes les bonnes volontés sont les bienvenues !

Contexte simplifié : Je suis un intermédiaire entre des loueurs de bateaux et des clients qui louent un bateau.
Des contacts font des demandes de location de bateaux.
Dès qu’une demande est signée, elle fait l’objet d’un ou plusieurs dossiers de réservation. Si la demande implique un seul loueur de bateau, alors la demande fait l’objet d’une réservation et une seule. Si plusieurs loueurs de bateau impliqués pour réaliser la demande alors il y a autant de réservations que de loueurs. Un loueur est un fournisseur parmi tant d’autres au même titre que peut l’être la poste, le trésor publique, etc.
Qui dit réservation dit facturation client, facturation fournisseur.
Une réservation se compose d’une ou plusieurs prestations.
Ces prestations seront facturés au client (contact dont le statut est client). Ces prestations sont achetés à des fournisseurs. J’ai donc une notion de facturation côté clients et côté fournisseurs.
Les clients peuvent payer en plusieurs fois comme je peux payer mes fournisseurs en plusieurs fois. J’ai donc une notion de paiement fournisseurs et paiement client. Les flux monétaires qui en découlent alimentent des comptes bancaires.

En pratique lorsque je crée une réservation, je renseigne un calendrier des paiements, côté client et côté fournisseurs. Pour une réservation donnée, j’ai donc au minimum 2 calendriers : un pour le client que je facture et un pour le loueur de bateau qui effectue la prestation.

Imaginons que pour une réservation donnée, le client devra payer 1000 euros (somme de plusieurs prestations). Il va le faire en 2 fois. Le 15 mars il paye un acompte de 500 et un solde de 500 le 15 avril 2008.
Cette réservation implique 2 fournisseurs : le loueur de bateau et un assureur. On admet qu’ils seront payés tous les 2 en 2 fois et pour tout simplifier dans la même monnaie (euro).
Le loueur me facture le bateau 700 (2 règlements de 350) et l’assureur me facture 50 (2 règlement de 25 euros).

Ces (lignes) de paiement viennent alimenter automatiquement un compte bancaire. Pour simplifier, on va dire qu’il s’agit du même compte.

Je bute sur le MCD ! Je ne vois pas comment relier une réservation donnée avec mes paiements planifiés. Je ne vois pas comment intégrer une notion paiement client et paiement fournisseur. C’est idiot, mais … je butte. L’évidence m’échappe-t-elle ?

Vous noterez que j'ai mis un montant_global_previsionnel dans mon entité "paiement planifié". Je pense que je commets une erreur. Ce montant global est en fait un champ calculé. Il correspond au total de mes lignes montant_prestation_vente dans le cas d'un client (paiement à recevoir) ou au total montant_prestation_achat dans le cas d'un fournisseur (paiement fournisseur à payer).

[JPhi33]

Bonjour,

Tes questions n'ont pas remporté un franc succès... C'est pourtant un problème sémantique très intéressant. A la lecture de ton MCD, il apparaît clairement que tu ne prends pas assez de recul par rapport à la modélisation pour te concentrer sur la sémantique. Mais c'est très souvent le cas quand on modélise un problème.

Je vais reprendre ton exemple pour expliquer ce que j'ai compris et comment je le modéliserais.

Pour la réservation, ton client doit te payer 1000. Et toi, tu dois payer tes 2 fournisseurs, chacun pour leur prestation : 700 au loueur et 50 à l'assureur. La différence entre 1000 et 750 étant ta marge commerciale.

Tu as correctement modélisé ton échéancier de paiement pour payer tes fournisseurs (entité Paiement_planifié) : chaque prestation fait l'objet d'une ou plusieurs occurrences de cette entité afin d'enregistrer les différentes échéances.

Par contre, n'espère pas pouvoir gérer l'échancier de paiement de ton client avec la même entité : ton client ne paie pas les prestations individuellement mais une facture globale correspondant à la somme de ces prestations (montant_prestation_vente). Il te faut donc une 2e entité pour l'échéancier de paiement de tes clients ; par exemple, Paiement_planifié_client. Celle-ci serait, en toute logique, liée à Réservation :

[ Paiement_planifié_client ]--1,1----( règle )----1,n--[ Réservation ]

Ceci n'empèche pas de retrouver la décomposition en montants de prestations du montant que doit payer le client. On l'obtient via Réservation et Prestation.

Il faudrait que la partie financière du MCD soit reliée au reste du MCD. Là, je ne suis pas très sûr, mais je propose que Opération soit liée à Paiement_planifié (et peut-être aussi à Paiement_planifié_client).

Enfin, selon les propriétés qui feront partie de Paiement_planifié_client, il est possible que tu puisse créer une entité généralisée à partir des deux entités Paiement_planifié. Dans ce cas, c'est l'entité généralisée qui pourrait être reliée à Opération.

Dis-moi ce que tu en penses.


JPhi33

[tavarlindar]

JPhi33,
Tout d'abord merci beaucoup pour ta réponse et le temps passé à sur mon problème.
Malheureusement, je crains ne pas tout comprendre.
J'ai lu et relu très attentivement ton post.
Fondamentalement, à mon sens, il n'y a pas de différence entre paiement client et paiement fournisseur au regard de ton analyse. En effet, pour une même réservation, je peux avoir plusieurs prestations. Ces prestations peuvent être réalisées par le même fournisseur. Exemple : si pour une résa donnée, j'ai 4 lignes de prestation, 3 peuvent être le fait d'un même fournisseur.

libelle Prestation.....| Px vente client....|.Px achat fournisseur.| Fournisseur|
location bateau......|..............3000....|...................2000....|....1......
skipper.................|................300....|....................200....|....1.....
assurance.............|................100....|....................100....| 2
traiteur.................|................200....|....................100....| .1

Comme tu le précises , le client paiera une facture globale de 3600 en 2 ou 3 fois par exemple. Côté fournisseur je paierai mon fournisseur 1 : 2300 euros en 2 ou plusieurs fois également.

Ceci étant dit, après réflexion, tu sembles avoir totalement raison. Mes paiement_planifie ne peuvent être reliés à l'entité prestation. C'est l'entité reservation qui doit être reliée l'entité paiement planifié.
Ce qui me dérange sans plus de réflexion, c'est que les paiement planifiés ne sont pas directement reliés aux fournisseurs.

Ce qui donnerait le mcd suivant.


Voilà où j'en suis.

[JPhi33]

Ce qui me dérange sans plus de réflexion, c'est que les paiement planifiés ne sont pas directement reliés aux fournisseurs.

Pour 1 Paiement, tu as 1 seule Réservation, puis 1 seule Demande, puis 1 seul Contact. Donc, par transitivité, 1 Paiement est lié à 1 seul Contact.
Relier directement Paiement à Contact dénormaliserait le MCD en contrevenant à la 3e forme normale.

Dans ton 2e modèle, tu as déplacé l'entité Paiement_planifié pour la relier à Réservation. C'est une erreur ; tu n'as plus d'échéancier pour payer tes fournisseurs. Je t'ai indiqué qu'il faut 2 entités Paiement_planifié : 1 pour les fournisseurs, 1 pour les clients (relis bien mon précédent message !)
S'il y a beaucoup de choses en commun entre les 2 entités Paiement_planifié, tu peux les généraliser :

[ Paiement_planifié_client ] ===> [ Paiement_planifié ]
[ Paiement_planifié_fourn ] ===> [ Paiement_planifié ]

(où "===>" représente le lien de généralisation - spécialisation orienté de l'entité spécialisée vers l'entité généralisée)

Rien ne ressemble plus à un échéancier qu'un autre échéancier ! La généralisation semble donc conceptuellement valide (à toi de le déterminer).

Tout ce qui est en commun va dans l'entité générale Paiement_planifié, les propriétés spécifiques à chaque type d'échéancier vont dans l'entité Paiement_planifié_xxx correspondante (j'espère que tu me suis).

Pour une explication sur la généralisation - spécialisation regarde ici


JPhi33

[tavarlindar]

JPhi33,

J’ai bien lu tes 2 posts. J’ai bien noté que tu me suggères de gérer séparément les paiements planifiés associés aux client s de ceux associés aux fournisseurs. Je n’ai rien contre, mais pour l’heure je n’en comprends pas l’utilité.

Suite à ton premier post, j’ai effectivement rattaché les paiement planifiés aux réservations. Je ne comprends pas pourquoi tu m’as dit : « C'est une erreur ; tu n'as plus d'échéancier pour payer tes fournisseurs. ».
Je ne comprends pas dans la mesure où c’est la solution que tu me préconises pour les paiements clients. Dans la mesure où, fondamentalement, j’arrive à la conclusion qu’il n’y a pas de différence entre paiement client et paiement fournisseur, pourquoi faire différemment.

Dans les deux cas, le montant total d’un paiement résulte d’un total de ligne de prestation. Voir mon précédent exemple.
Le client paiera un total de 3000+300+100+200. S’il y paie en 2 fois (50% + 50%), alors j’aurais 2 lignes dans la table paiement_planifie d’un montant_global_previsionnel de 3600/2 = 1800.
Côté fournisseur, si je prends le fournisseur 1 : 2000+200+100=2300. Si paiement en 2 fois aussi (30%-70%). J’aurai aussi 2 lignes d’un montant respectif de -690 et -1610.
Ce qui diffère entre les deux :
- le signe du nombre stocké dans la base. Un signe positif traduit un nombre qui apparaitra en crédit et un signe négatif traduit un nombre qui apparait en débit d’un compte bancaire donné.
- La devise utilisée et donc par voie de conséquence le compte bancaire utilisé.
Un client peut payer en euro et je paie mes fournisseurs en dollars.

Pour ce qui est des notions de couverture et disjonction, hum je veux bien, mais tes explications ne disent pas comment cela se traduit concrètement en terme de base de données. (comment sont in fine construite les tables, quels sont les clefs primaires utilisées, etc.)
Cela dit, je veux bien admettre que lorsqu’on maitrise ce sujet cela doit bien aider à ne pas commettre d’erreur.

Qu’en penses-tu ?

[TheLeadingEdge]

Bonjour,

Sur le fond, pour moi la partie ''réservation client'' et la partie ''compta fournisseur'' sont 2 domaines de responsabilité différents. Tu peux relier l'établissement des factures client avec les prestations commandées, mais ça me parait étrange que ce soit toi qui gère les factures fournisseur. C'est plutôt le fournisseur qui doit les emettre, et ça inclu aussi l'établissement de l'échéancier.
A moins que tu ne fasse office de presta. pour eux ? Il faudrait que tu sois plus précis.

Sur la forme la partie réservation devrait pouvoir être améliorée. Les tables qui vont résulter de ton modèle ne vont pas être en FN.

Et en ce qui concerne l'aspect généralisation je rejoins l'avis de JPhi33.

J'ai fait cette ébauche juste avec les entités. Elle pourra être revue en fonction des précisions que tu apportera. Les propriétés de tes entités ne semble pas bien fixées encore

[tavarlindar]

Pour commencer, je dois avouer que je ne connais pas la signification de la relation qui lie factureClient et factureAchat et Facture. Pas de cardinatilités … idem entre Bateau , Service et Prestation.

Pour le reste, j’avoue ne pas comprendre la philosophie.

Concernant la relation Réservation avec Prestations.
Une réservation est constituée d’une ou plusieurs prestations.
Côté prestation, une prestation donnée prises parmi toutes les prestations appartient obligatoirement à 1 et une seule réservation.
[ Reservation ]--1,n----( est_constituée )----1,1--[ prestation ]

Effectivement, je ne gère pas les factures fournisseurs.
Au moment où je crée une réservation, je connais néanmoins le coût des prestations. C’est pourquoi j’avais mis Montant_prestation_vente et Montant_prestaion_Achat dans l’entité Prestation.
Côté client , je vais émettre « une facture ». Il ne s’agit pas d’une facture au sens propre, mais d’un document qui dit combien devra payer le client en précisant l’échéancier des paiements. Pour simplifier, on va dire que le client reçoit donc une facture.

Par ailleurs, les relations qui lient Bateau à marque de bateau et reservation sont accessoires.

[tavarlindar]

bon, ce sujet n'intéresse personne ?
je suis déçu, car j'ai vraiment besoin d'aide.

si cette séparation compta fournisseur / compta client semble évidente, tant elle se traduit à de nombreux niveaux en pratique dans l'organisation des sociétés,
ici, pour un besoin simpliste, je ne comprends toujours pas.

[JPhi33]

Bonjour tavarlindar,

Je reprends ton exemple

Code :

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

1
2
3
4
5
6
7
libelle Prestation|Px vente client|Px achat fournisseur|Fournisseur|
--------------------------------------------------------------------
location bateau...|...........3000|................2000|....1......|
skipper...........|............300|.................200|....1......|
assurance.........|............100|.................100|....2......|
traiteur..........|............200|.................100|....1......|

Le client paiera une facture globale de 3600 en 2 ou 3 fois par exemple. Côté fournisseur je paierai mon fournisseur 1 : 2300 euros en 2 ou plusieurs fois également.

Ceci étant dit, après réflexion, tu sembles avoir totalement raison. Mes paiement_planifie ne peuvent être reliés à l'entité prestation. C'est l'entité reservation qui doit être reliée l'entité paiement planifié.

A cela, j'ajoute les besoins que tu as exprimés dans ton tout premier message :

Qui dit réservation dit facturation client, facturation fournisseur.
Une réservation se compose d’une ou plusieurs prestations.
Ces prestations seront facturés au client (contact dont le statut est client). Ces prestations sont achetés à des fournisseurs. J’ai donc une notion de facturation côté clients et côté fournisseurs.
Les clients peuvent payer en plusieurs fois comme je peux payer mes fournisseurs en plusieurs fois. J’ai donc une notion de paiement fournisseurs et paiement client.

Maintenant que les choses ont décanté suite aux différents échanges de points de vue, il faut refaire un point sur ces besoins.

Que veux-tu gérer exactement (oui/non) ?
- les échéanciers de paiement des clients
- tes propres échéanciers de paiement de tes fournisseurs

Dans le cas de l'exemple ci-dessus :
- l'échéancier de paiement du client correspond-il à un montant de 3600 ?
- si tu gères tes échéanciers pour payer tes fournisseurs, combien en auras-tu : 1 car 1 réservation (montant 2400), 2 car 2 fournisseurs dans cette réservation (montants 2300 et 100), 4 car 4 prestations dans cette réservation ?

J'ai peut-être oublié quelques questions, on verra par la suite.


JPhi33

[tavarlindar]

Re-Bonjour,

Je reprend ce sujet si capital pour moi.

Que veux-tu gérer exactement (oui/non) ?
- les échéanciers de paiement des clients
- tes propres échéanciers de paiement de tes fournisseurs

La réponse est OUI aux deux questions.
Côté client, c'est évident. Les clients payent en 2 ou plusieurs fois. Cet échéancier doit apparaître sur les documents que reçoit le client.
Côté fournisseur, je suis obligé de remplir un échéancier puisque les montants que je devrais payer vont se retrouver dans mes comptes bancaires.
Lors d'une création de réservation, tous ces montants (prévisionnels) vont venir alimenter mon compte bancaires.
Un échéancier étant constitué d'une ou plusieurs lignes de paiements planifiés.

Dans le cas de l'exemple ci-dessus :
- l'échéancier de paiement du client correspond-il à un montant de 3600 ?
- si tu gères tes échéanciers pour payer tes fournisseurs, combien en auras-tu : 1 car 1 réservation (montant 2400), 2 car 2 fournisseurs dans cette réservation (montants 2300 et 100), 4 car 4 prestations dans cette réservation ?

La montant que doit payer le client est de 3600. Cela se traduira souvent par
un échéancier composé de 2 échéances 1800 et 1800 par exemple.
(2 lignes de paiements planifiés)

Côté fournisseurs, c'est la même chose. J'ai autant d'échéancier que de fournisseurs différents.

Dans l'exemple, j'ai 2 fournisseurs.

Je devrais payer un montant total de 2300 au fournisseur 1 (2000+200+100).
Comme pour les clients je vais le payer en 2 fois. Donc 2 échéances de 1150.
Quant au fournisseur 2 : un total de 100 en 1, 2 ou trois fois.

[JPhi33]

Bonjour,

On va essayer de conclure cette question d'échéancier. En préambule, on peut dire que, d'après ton MCD, ce que tu nommes "paiement planifié" est 1 échéance de paiement.
Lors de la modélisation, il faut s'assurer de pouvoir toujours retrouver le montant total du paiement constitué par l'ensemble des échéances.

La montant que doit payer le client est de 3600. Cela se traduira souvent par un échéancier composé de 2 échéances 1800 et 1800 par exemple. (2 lignes de paiements planifiés)

Le client doit payer le montant total d'une réservation, ici 3600 (3000 + 300 + 100 + 200). S'il paye en 2 fois, on aura donc 2 lignes de paiement planifié. On voit bien que "paiement_planifié", pour le client, ne peut pas être lié à "prestation" (comme dans le MCD 1). En effet, non seulement on ferait une erreur sémantique en disant qu'un ensemble d'échéances permet de payer une prestation au lieu d'une réservation mais, en outre, on serait incapable de faire correspondre les montants des échéances et ceux des prestations, quelle que soit la manière de modéliser le lien entre ces entités :

[ paiement_planifié ]--1,1----( a-un )----1,n->[ prestation ]
[ paiement_planifié ]<-1,n----( a-un )----1,1--[ prestation ]
[ paiement_planifié ]--1,n----( xxxxx )----1,n--[ prestation ]

Il faut faire correspondre un ensemble d'échéances à un ensemble de prestations. Pour cela, il faut une entité intermediaire :

[ paiement_planifié ]--1,1----( a-un )----1,n->[ ??? ]<-1,n----( a-un )----1,1--[ prestation ]

Cette entité intermédiaire, c'est "réservation" (comme dans le MCD 2).
Le montant total de 3600 peut être retrouvé en faisant la somme les "montant_prestation_vente" (ou _achat ?) de l'ensemble des prestations liées à la réservation.

Exemple d'occurrences du MLD

Code :

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

1
2
3
4
5
6
7
8
9
10
-----------------------   -----------------------
paiement_planifié         prestation
-----------------------   -----------------------
id montant #réservation   id montant #réservation
-- ------- ------------   -- ------- ------------
1     1800 R1             1     3000 R1
2     1800 R1             2      300 R1
                          3      100 R1
                          4      200 R1

Côté fournisseurs, c'est la même chose. J'ai autant d'échéancier que de fournisseurs différents. Dans l'exemple, j'ai 2 fournisseurs. Je devrais payer un montant total de 2300 au fournisseur 1 (2000+200+100). Comme pour les clients je vais le payer en 2 fois. Donc 2 échéances de 1150. Quant au fournisseur 2 : un total de 100 en 1, 2 ou trois fois.

Pour les fournisseurs, c'est plus compliqué. En effet, l'ensemble des échéances doit permettre de payer un ensemble de prestations d'un fournisseur dans le cadre d'une réservation.
Oublions les contraintes du fournisseur et de la réservation pour l'instant. Il faut donc faire correspondre un ensemble d'échéances à un ensemble de prestations. Le problème est le même que dans le cas du client. On a vu qu'il ne peut être résolu qu'au moyen d'une entité intermédiaire. Nommons-la "fourniture" par exemple. Le modèle est :

[ paiement_planifié ]--1,1----( a-un )----1,n->[ fourniture ]<-1,n----( a-un )----1,1--[ prestation ]

Maintenant, réintroduisons les aspects nécessaires de réservation et fournisseur :

[ fourniture ]--1,1----( est fournie par )----1,n->[ fournisseur ]
[ fourniture ]--1,1----( est fournie pour )----1,n->[ réservation ]

A ce stade, on a (schéma simplifié) :

Code :

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

1
2
3
4
5
prestation -1---n-> fourniture -1---n-> réservation
    |                                        ^
    |                                        |
    +-------1-----------------------n--------+

Ce modèle contrevient à la 3FN. Pour le normaliser, il faut éliminer l'association (la DF) non directe "est constituée" entre "prestation" et "réservation".
Pour la même raison, on élimine l'association "réalise" entre "prestation" et "fournisseur".

En ce qui concerne les paiements planifiés, on a 2 approches.

1) Soit on considère dès le départ qu'il y a deux entités, par exemple "paiement_planifié_client" et "paiement_planifié_fournisseur". Dans ce cas, il faut impérativement nommer différemment les propriétés qui pourraient se trouver en double dans les deux entités. De plus, il faut changer les cardinalités (0,1) à la place de (1,1) car une occurrence de paiement planifié est liée soit à une occurrence de "réservation" soit à une occurrence de "fourniture" et modéliser un contrainte d'exclusion.

2) Soit on considère qu'il s'agit de la même entité. Dans ce cas, il est impératif que toutes les propriétés de l'entité "paiement_planifié" soient pertinentes pour les deux côtés.

La solution intermédiaire est une généralisation - spécialisation comme je l'ai déjà expliqué dans un message précédent :

[ Paiement_planifié_client ] ===> [ Paiement_planifié ]
[ Paiement_planifié_fourn ] ===> [ Paiement_planifié ]

"Paiement_planifié" contient les propriété communes, les propriétés spécifiques sont dans les entités spécialisées.


Pour conclure, voici le modèle (simplifié) prenant en compte mes développements ci-dessus :




JPhi33

[tavarlindar]

JPhi33, Bonjour

Tout d'abord, encore mille fois merci pour le temps que tu a consacré à ma problématique.

Je dois avoué que je ne comprends pas toute ton analyse.

Récapitulons.
1) Pour le moment, je fais abstraction du distinguo calendrier des paiements côté fournisseur et côté client.
Je suis d'accord avec toi, les paiements planifiés ne doivent pas être rattachés aux prestations. les paiements se rattachent à l'entité réservation. 100% d'accord.

Ton raisonnement concernant la partie paiement fournisseur me rend dubitatif.
Je ne comprends pas pourquoi tu introduit une nouvelle entité "fourniture". Ok, sur la notion d'entité intermédaire entre paiement_fournisseur et prestation. Mais pourquoi l'entité réservation ne ferait pas l'affaire ?

Code :

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

1
2
Pour les fournisseurs, c'est plus compliqué. En effet, l'ensemble des échéances doit permettre de payer un ensemble de prestations d'un fournisseur dans le cadre d'une réservation.

Oui ! Mais pourquoi plus compliqué ?

ne comprenant pas, je me suis dit. Ok admettons qu'il ait raison. Faisons un test.
J'ai répliqué ton mcd


ce qui correspond sauf erreur au mld suivant :


je me suis posé la question où mettre les montant dans "fourniture" ou "prestation" ... J'ai laissé ces attributs dans prestation.

Imaginons maintenant que Monsieur Jean Philippe Aimecédet souhaite partir en vacances du 1er mai au 10 mai. Il fait réserve.
voir sa réservation

Total du voyage 3650 euros. 4 fournisseurs impliqués.
le fournisseur 123 sera payé en 2 fois : 1050 +1050 = 2100
le fournisseur 511 sera payé en 2 fois : 70 +30 = 100
le fournisseur 503 sera payé en 1 fois : 50
le fournisseur 712 sera payé en 2 fois : 100 + 90 = 190


Je rentre les données dans la base :
note pour les noms : j'inverse pour les clé étrangère. Si id_fournisseur est une clé étrangère je nomme le champ fournisseur_id.

Table Reservation


Table Fournisseur


Table Prestation


Table Fourniture

Nous somme d'accord, id_fourniture est auto incrémenté. Je crée donc autant de ligne fourniture qu'il y a de ligne prestation. J'aurais bien vu un prestation_id dans cette table ....

Table Paiement planifie client

Ici, pas de problème.

Table Paiement planifie fournisseur
Maintenant comment je fais pour la table paiement planifié fournisseur ?

A quelle fourniture_id dois-je rattaché ma première échéance de 1050 concernant mon fournisseur 123 ?

J'ai du louper une étape. Non ?

Il va sans dire que pour le reste entité de spécialisation, j'en suis pas encore là.

[JPhi33]

Bonjour tavarlindar,

Je vois que tu as beaucoup cogité, en effet.

Je ne comprends pas pourquoi tu introduit une nouvelle entité "fourniture".

Comme je l'ai dit, c'est essentiellement une question de correspondance de montants. Celle-ci rend nécessaire la modélisation de Fourniture.
Fourniture est un concept existant dans la réalité ; il représente l'ensemble des Prestations fournies par un Fournisseur dans le cadre d'une Réservation. Mais un concept n'est modélisé que s'il présente un intérêt de gestion. Si l'échéancier de paiement fournisseur s'appuie sur 1 seule prestation, le concept de Fourniture ne présente pas d'intérêt de gestion et il n'est normalement pas modélisé.

Ok, sur la notion d'entité intermédaire entre paiement_fournisseur et prestation. Mais pourquoi l'entité réservation ne ferait pas l'affaire ?

Parce que pour une réservation tu as plusieurs fournisseurs à payer avec chacun leur échéancier et que l'entité Réservation n'est pas liée à un seul fournisseur mais à plusieurs. Tu ne saurais donc pas à quel fournisseur se rattache ton échéancier.

Pour les fournisseurs, c'est plus compliqué. En effet, l'ensemble des échéances doit permettre de payer un ensemble de prestations d'un fournisseur dans le cadre d'une réservation.

Oui ! Mais pourquoi plus compliqué ?

En fait ce n'est pas plus compliqué dans l'absolu, mais plus compliqué par rapport à ton MCD initial car il faut introduire un concept nouveau : Fourniture.

ne comprenant pas, je me suis dit. Ok admettons qu'il ait raison. Faisons un test. J'ai répliqué ton mcd
ce qui correspond sauf erreur au mld suivant :

Oui, le MLD est correct

je me suis posé la question où mettre les montant dans "fourniture" ou "prestation" ... J'ai laissé ces attributs dans prestation.

Le montant de la prestation est obligatoirement dans Prestation. On peut effectivement se demander si on peut créer un nouveau montant de fourniture dans Fourniture qui serait la somme des prestations (DU fournisseur pour LA réservation). Certains concepteurs interdisent les données calculées dans un MCD. Je ne suis pas aussi catégorique mais disons qu'en l'occurrence je pense que ce n'est pas indispensable.

Imaginons maintenant que Monsieur Jean Philippe Aimecédet souhaite partir en vacances du 1er mai au 10 mai. Il fait réserve.

Total du voyage 3650 euros. 4 fournisseurs impliqués.
le fournisseur 123 sera payé en 2 fois : 1050 +1050 = 2100
le fournisseur 511 sera payé en 2 fois : 70 +30 = 100
le fournisseur 503 sera payé en 1 fois : 50
le fournisseur 712 sera payé en 2 fois : 100 + 90 = 190

J'aurais préféré que tu continues avec le même exemple que précédemment. D'une part il est très représentatif et d'autre part on y était habitué.

Je rentre les données dans la base :
Nous somme d'accord, id_fourniture est auto incrémenté. Je crée donc autant de ligne fourniture qu'il y a de ligne prestation. J'aurais bien vu un prestation_id dans cette table ....

Effectivement, tu n'as pas saisi ce que représente l'entité Fourniture. Regarde bien le MCD : une Fourniture est composée de 1 à n Prestations. Dans ton exemple, tu crées autant de fournitures que de prestations. Ce n'est pas incompatible avec le MCD, mais ça ne sert à rien. C'est comme si on avait :

[ Prestation ]--1,1----( Compose )----1,1--[ Fourniture ]

De plus, je ne vois pas bien comment le fait que id_fourniture soit auto-incrémenté te conduit à en déduire qu'il faut créer 1 ligne Fourniture pour 1 ligne Prestation.

Voici comment ta table Fourniture doit être :

Code :

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

1
2
3
4
5
6
7
id_fourniture   reservation_id   fournisseur_id
-------------   --------------   --------------
1               100              123
2               100              712
3               100              511
4               100              503

et donc la table Prestation :

Code :

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

1
2
3
4
5
6
7
8
9
10
id_prest  libelle_prest     mt_vente   mt_achat   fourniture_id
--------  ---------------   --------   --------   -------------
2         location bateau       3000       2000   1
3         nattoyage                0        100   1
4         annexe                   0          0   1
5         skipper                100        100   2
6         traiteur               200        100   3
7         assurance              150         50   4
8         zodiac                 200         90   2

Table Paiement planifie client
Ici, pas de problème.

Je confirme.

Table Paiement planifie fournisseur
Maintenant comment je fais pour la table paiement planifié fournisseur ?
A quelle fourniture_id dois-je rattaché ma première échéance de 1050 concernant mon fournisseur 123 ?

A la fourniture 1

Table Paiement_planifié_fournisseur

Code :

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

1
2
3
4
5
6
7
8
9
10
id_ppf   mt_prev   fourniture_id
------   -------   --------------
1           1050   1
2           1050   1
3             70   3
4             30   3
5             50   4
6            100   2
7             90   2

On a bien (Mt paiement planifié = Mt prestations) :
1050 + 1050 = 2000 + 100 + 0 (fourniture 1)
70 + 30 = 100 (fourniture 3)
50 = 50 (fourniture 4)
100 + 90 = 100 + 90 (fourniture 2)


JPhi33

[tavarlindar]

Bonjour à tous,
Merci JPhi33 pour l'explication. J'ai compris.
Pour continuer et concernant les paiements planifiés, je vais reprendre les 3 approches de Jphi33.

En ce qui concerne les paiements planifiés, on a 2 approches.

1) Soit on considère dès le départ qu'il y a deux entités, par exemple "paiement_planifié_client" et "paiement_planifié_fournisseur". Dans ce cas, il faut impérativement nommer différemment les propriétés qui pourraient se trouver en double dans les deux entités. De plus, il faut changer les cardinalités (0,1) à la place de (1,1) car une occurrence de paiement planifié est liée soit à une occurrence de "réservation" soit à une occurrence de "fourniture" et modéliser un contrainte d'exclusion.

2) Soit on considère qu'il s'agit de la même entité. Dans ce cas, il est impératif que toutes les propriétés de l'entité "paiement_planifié" soient pertinentes pour les deux côtés.

Approche 2
Si on opte pour 1 seule entité paiement planifié considérant que fondamentalement les paiements planifiés client ne diffèrent en aucun point des paiements planifiés côté fournisseur (hormis le signe du montant : positif si client, négatif pour les fournisseurs).
On obtient le mcd suivant :

J’ai modélisé la contrainte d’exclusion avec un ovale et une croix.
Le mld devient alors :


Avec la définition de la table paiement planifie comme suit :

Ce qui donne en termes de contenu :


Ici, on retrouve des valleurs null. Est-ce si grave ?
Rien n’empêche à priori dans le cas des paiements fournisseurs de mettre dans reservation_id sa valeur : ici 100. Non ?


Approche 1 : on a deux entités paiement planifiés , une pour les clients et l’autre pour les fournisseurs.

Le mcd est alors :

et le mld :


Approche 3 :héritage
A l'heure actuelle, je n'ai pas d'attributs spécifiques côté fournisseur ou côté client. Les paiements planifiés servent avant tout à alimenter un compte bancaire qui lui se matérialise toujours par la même structure : date d'opération, libelle, tiers, montant en débit ou crédit suivant le signe.

ici j'ai mis la même clé primaire dans les 3 tables. les id_paiement_planifie des 2 tables filles devant si j'ai bien compris être définies comme étant en même temps clé étrangère par rapport à la table mère paiement planifie.

Alors laquelle choisir ?
je pense plus à l'approche 1 ou 2. La solution héritage ici me semble lourde pour pas grand chose.

NB : je n'ai pas encore pris de décision concernant la relation paiement planifié - compte bancaire et opération. Une relation directe paiement planifie (écheance) opération semble plus logique.

[JPhi33]

Ma réponse ne va étonner personne (elle est sous-entendue au message #2 et clairement annoncée au message #4 !)

Approche 2
Dans le MLD, la table Paiement_planifié comporte 2 clés étrangères id_reservation et id_fourniture. Dans chaque ligne de cette table, l'une des 2 aura obligatoirement la valeur Null.

Approche 1
C'est mieux : pas de problème de Null. On note quand même la redondance de concepts : date_paiement_prev, montant_prev, mais qui reste acceptable.

Généralisation
Pour moi, c'est l'idéal. Pas de problème de Null et pas de redondance de concept.


Voyons ce que donnent 2 requêtes "typiques" dans chaque cas. Je ne suis pas très sûr de moi (si un DBA passait par là j'aimerais avoir son avis).

1) Liste des paiements planifiés "de type client"
Approche 2

Code :

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

1
2
3
4
SELECT id_paiement_planifie
  FROM Paiement_planifie
 WHERE id_reservation <> Null (???)

J'ai de gros doutes. Je ne suis pas certain que ça marche bien.

Approche 1

Code :

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

1
2
3
SELECT id_paiement_planifie_client
  FROM Paiement_planifie_client

---> ok

Généralisation

Code :

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

1
2
3
SELECT id_paiement_planifie
  FROM Paiement_planifie_client

---> ok


2) Liste des paiement planifiés d'un compte bancaire ('0001' par exemple)
Approche 2

Code :

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

1
2
3
4
SELECT id_paiement_planifie
  FROM Paiement_planifie
 WHERE id_compte_bancaire = "0001"

---> ok

Approche 1

Code :

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

1
2
3
4
5
6
7
8
SELECT id_paiement_planifie_client
  FROM Paiement_planifie_client
 WHERE id_compte_bancaire = "0001"
UNION
SELECT id_paiement_planifie_fournisseur
  FROM Paiement_planifie_fournisseur
 WHERE id_compte_bancaire = "0001"

Pas très pratique l'union (et risque de problèmes de performances ?)

Généralisation

Code :

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

1
2
3
4
SELECT id_paiement_planifie
  FROM Paiement_planifie
 WHERE id_compte_bancaire = "0001"

---> ok

Seule la généralisation reçoit 2 ok (sous réserve de la validité des requêtes).


JPhi33

[tavarlindar]

Bonjour,

Voici la dernière mouture de mon mcd simplifié.
J'ai encadré en rouge la partie pour laquelle j'aimerais avoir vos commentaires.


contexte pour mieux comprendre le mcd.
Je loue des bateaux.
j'ai crée une entité "fournisseur_agence" qui représente en fait tous les fournisseurs. Par agence on peut aussi dire, bureau ou base de départ selon la catégorie de fournisseur. Ce n'est ici qu'une question de terminologie.
J'aurais à priori pu l'appeler tout simplement Fournisseur.

Lorsqu'un client fait une réservation, ceci implique obligatoirement une base de départ qui est un endroit physique où le client devra se rendre pour embarquer.
Le fournisseur principal dans le cadre de la location de bateau est dans le jagon appelé Provider (loueur de bateau).
Si la demande du client implique un seul loueur de bateau, alors la demande fait l’objet d’une réservation et une seule. Si plusieurs loueurs de bateau impliqués pour réaliser la demande alors il y a autant de réservations que de loueurs.
Par rapport à ce mcd, je me demande si je n'ai pas crée une relation redondante. A savoir :
Une réservation se traduit par la fourniture d'au moins une prestation qui est la location de bateau, prestation fournie par mon provider. Est-ce bien utile de créer une association " implique obligatoirment" entre reservation et fournisseur_agence ?
Pour le reste, peut-être que quelle que chose vous choque.

Par avance merci,

Bien à vous

Tavar

[JPhi33]

Bonjour Tavar,

Je pense moi aussi que cette CIF est conceptuellement redondante même si elle ne l'est pas techniquement (on ne pourrait pas l'éliminer au titre de la 3e forme normale).

Si la location du bateau est la seule Prestation de la réservation, on n'a donc qu'une seule FounitureServices impliquée dans la Réservation et donc un seul Fournisseur_agence.
Selon moi, Cette CIF traduit la volonté de contrôler que si une Réservation ne contient qu'une seule Prestation, alors celle-ci est de type location de bateau. Cette notion est très difficilement modélisable dans un MCD car il faudrait faire intervenir une occurrence dans une association (il aurait fallu aussi qu'une entité "Type de prestation" existe).

Puisque le MCD ne permet pas de modéliser ce contrôle, tout en permettant la gestion de ce cas particulier, le contrôle est à faire dans les traitements.


JPhi33

[Techys]

Le seul aspect dont je veux parler c'est la table Paiment Palnifié tu aurais du ecrire Selement Piaement. Une reservationdonne droit a 1 paiment
et ta les propriété de Paiement(IDpaiement, DatePrevue,Montant, DatePaiement,etc..)

je trouve que c plus simple