Discussion :

[tavarlindar]

Bonjour à tous,

Qui dit épisode III, dit pour rappel Episode I et Episode II.

Il y a 2 sujets pour lesquels j'ai le plaisir de vous solliciter.

1) La gestion du paiement de commissions
2) La gestion des emails associés au paiement des échéances

Après avoir présenter une partie du MCD, je présenterai le contexte et ensuite (malheureusement) pourquoi je n'arrive pas à finaliser le MCD.

MCD actuel:


ce qui donne en gros le MLD suivant:


Rappel succinct du contexte général : domaine de la location de bateaux
Un client fait une demande sur Internet pour louer un bateau. Une fois que sa demande se concrétise commercialement, on fait une réservation. Cette réservation entraine l'établissement d'échéanciers qui viennent directement alimenter des comptes bancaires. (pour une meilleure compréhension voir début de l'
Episode I)

Point 1 - Gestion du paiement de commissions

Contexte et cahier des charges:

Marge Brute d’une réservation = (Somme des paiements du client – Somme des paiements fournisseurs) associées à la dite réservation.
Marge Brute d’un dossier commercial = Marge Brute d’une demande = somme des marges des réservations associées. Dans 90% des cas, une demande d'info (table demande) qui se concrétise commercialement fait d'objet d'une seule réservation (dossier de réservation). Il peut néanmoins arriver que soit rattachée à une demande plusieurs dossiers de réservations.

Marge Brute Finale:
La marge brute finale est la marge calculée lors de la clôture du dossier. C’est le service gestion qui définit la clôture: date et montant. En principe, la marge brute finale ne peut pas être calculée tant que le client n’a pas terminé sa location et/ou que tous les fournisseurs liés à cette réservation n’ont pas été payés.

Règle 1: La marge brute finale se calcule uniquement à partir de données comptables : encaissements et décaissements constatés. Par données comptables, il faut traduire données enregistrées dans les comptes bancaires. (= données issues de la table opération)

Règle 2: La marge brute associée à une réservation s’exprime toujours en euro, même si les encaissements et les décaissements se font en dollar ou autres monnaies.

Pratique 3: Dans le cadre de réservation faisant intervenir d’autres monnaies que l’euro, il est d'usage qu'un seul taux de change (par monnaie) soit pris en compte, indépendamment de toutes considérations (date d’encaissement réel, de décaissement, etc) . Ce taux est choisi par la personne en charge de la gestion.

Règles 4: Principe de précaution et afin de garantir la pérennité de la solution, l'application doit pouvoir s’affranchir de la pratique n°3! En d’autres termes, le système doit être capable de calculer la marge d’un dossier en considérant des taux de change différents.

Règle 5: Un taux de change se détermine en fonction de sa date de référence. Autrement dit, on ne saisit pas un taux de change, on saisit une date. En fonctionne de cette date, le système doit connaître le taux de change à appliquer.

Le commercial perçoit une commission. Cette commission se calcule à partir de la Marge brute selon la formule suivante :
commission = (marge brute) x (taux de commission).

Ce taux est jusqu'à présent toujours de 50%, mais rien ne dit qu'il en sera toujours à l'avenir pour tous les dossiers.

En début de mois (généralement), la gestion procède au paiement des commerciaux.Chaque commercial perçoit alors un montant global qui est la somme de ses commissions. Ce paiement est enregistré dans les comptes bancaires. Cela fait donc l'objet d'une opération bancaire.

La marge s'exprimant en euro, la commission s'exprime de facto en euro. Si le commercial est américain et doit être payé en dollar, la commission doit être valorisée en dollar. C'est la personne en charge de la gestion qui choisi la date du taux de change.

Un petit exemple pour bien comprendre :

Un client américain, mr OBAMA loue un bateau en Espagne. Le client paye sa réservation en dollar sur un compte (en dollar). Le client fait 3 paiements de 3000 $. Le ou les fournisseurs qui sont impliqués dans ce dossier seront eux payer en euro (ici un seul fournisseur pour simplifier).
Prenons le cas le plus «compliqué»:
Pour Y raisons, il est décidé de valoriser les paiements du client comme suit:

paiement du 1er janvier au taux du 2 janvier 2009. A cette date la parité euro_dollar était de 1.25, donc 1/1.25 euro (=0,8) pour 1 dollar

paiement du 1er août au taux du jour. A cette date, la parité euro_dollar était de 1.3456 soit 1 dollar pour 0,7432 euro

paiement du 29 octobre au taux du 1er décembre 2009. A cette date, la parité euro_dollar était de 1.1123 soit 1 dollar pour 0,899 euro



Sachant que pour cette réservation, le taux de commission est de 50%, la commission est de 1213,20 €. Le commercial étant américain, on valorise sa commission en dollar. Il est décidé de prendre la date du 1er décembre 2009 pour le taux de change.
Commission = 1213,20 x 1.1123 = 1349,44 $

Dans la pratique, si on reprend l'exemple ci-dessus, on valorise tous les paiements au même taux de change. Idem pour le taux de change retenu pour le calcul de la commission. C'est le taux de change en date du paiement des commissions qui est pris en compte. Ici la date du 1 décembre 2009.



Commission = (3131,33 x 0,5) x 1.1123 = 1774,85 $


Mon analyse pour le MCD.
Quelles sont les entités et relations associées à définir et qui ne sont pas encore représentées dans le MCD actuel ?

La notion de marge brute me pose problème. C'est un champ calculé. La marge prend en considération une ou plusieurs opérations bancaires, chaque opération bancaire pouvant être associée à un taux de change (date de taux de change). Initialement, je me suis dit, c'est simple, il suffit de rajouter l'attribut date_taux_change dans la table opération. Seulement voilà, cet attribut ne concerne que des opérations résultant d'une réservation, opérations appartenant en plus à un compte bancaire libellé dans une autre devise que l'euro. Je vais avoir beaucoup de NULL pour cet attribut.
J'ai donc pensé à la notion d'héritage/spécialisation.
Une opération bancaire servant au calcul de marge , n'est ni plus ni moins qu'une opération bancaire, elle en a tout les attributs, mais en plus elle a l'attribut date_taux_change.

Oui mais, cela sous entend qu'on utilise une date de taux de change pour chaque opération, or en pratique ce n'est pas vrai. En effet, généralement, on utilise le même taux de change (date) pour toutes les opérations.
Doit-on prendre on considération cet état de fait, sachant que dans le cas où l'on gère différents taux de change, il sera toujours possible de calculer la marge. Toutes les opérations bancaires auront la même date de taux de change.
N'y aurait-il pas là une notion d'exclusion à modéliser ? Le calcul de la marge fait intervenir une date de taux de change ou s'appuie sur plusieurs de taux de change. Nous avons donc une notion de modalité de calcul de Marge avec Taux_Change_Unique ou Taux_Change_Multiple.
Cependant, la notion de modalité de calcul n'a de sens que pour des comptes bancaires dont la devise n'est pas l'euro. Dois-t-on le modéliser ?
En faisant abstraction cette notion de marge, au mieux (à priori) , on peut dire qu'une commission se rattache à une réservation avec comme cardinalité (1,1) et (1,1). Cette entité «commission» ayant pour attribut le tx_de_commission. Il existerait aussi une relation entre Commission et Commercial.
[commission]----1,1-----(concerne)----0,n-------[commercial]. Tout ceci ne me convainc guère ...

J'ai beau «brouillonner» plusieurs nouvelles entités, relations, j'aboutis à rien .
J'ai même étudié la piste de mettre des attributs d'association comme présentée ici. Je verrai bien en effet une relation se_calcule entre une entité [Marge_brute] et l'entité [opération] avec comme attribut d'association date_taux_change. Ce serait mon premier attribut d'association! J'en ai pas encore dans mon MCD!

Bref, j'ai du mal à faire la différence entre ce qui relève purement du MCD voir MLD et des requêtes qui seront mises en œuvre.

Pour ce qui est du point 2 ( La gestion des emails associés au paiement des échéances), on verra cela après !

En espérant ne pas vous avoir perdu en cours de route,

Bien à vous
Tavar

[JPhi33]

Bonjour Tavar,

Le taux de change n'est pas une donnée "métier". On peut considérer qu'il s'agit d'un paramètre du système. Les paramètres, dont le taux de TVA est l'exemple typique, sont modélisés à part car :
- leur évolution ne dépend pas du métier de l'entreprise
- ils sont uniquement utilisés pour des calculs.

Dans le cas très général où l'on n'a pas besoin de savoir à quelle date le paramètre change, on enregistre simplement sa valeur dans une table dédiée et chaque nouvelle valeur vient écraser l'ancienne.

Exemple :

PARAMETRE(id_param, valeur_param)

certains font même plus simple s'il n'ont qu'un paramètre (ici, le taux de TVA) :

TVA(id, taux_tva)

Ton besoin, tel que je le comprends, est de disposer du taux de change pour plusieurs devises à chaque date d'opération et surtout a posteriori. C'est-à-dire que le jour du calcul de la marge brute, à la clôture du dossier, quantités d'opérations auront été enregistrées à des dates antérieures. Ce sont ces dates qu'il faudra prendre en considération lors du calcul de la marge brute. Pour éviter de devoir stocker dans chaque opération le taux de change à la date de l'opération, avec les inconvénients que tu as décrits, le mieux est de modéliser une table paramètre pour le taux de change.

La modélisation peut être :

TAUX_CHANGE(date, code_devise, parité_euro)

La gestion de la table peut se faire de deux façons.

Le taux de change change () tous les jours. Une première manière de gérer cette table consiste à stocker chaque jour le taux de change de toutes les devises dont tu as besoin. Lors du calcul, il suffit d'accéder à la table avec la date de l'opération et la devise pour récupérer le taux à cette date. C'est ce que j'appellerais la manière bestiale !

Pour éviter de stocker des lignes inutiles, il est préférable d'enregistrer le taux de change au moment de la création d'une opération qui nécessitera ce taux de change lors du calcul de la marge brute. Quand on crée l'opération, on a la devise et la date ; il faut récupérer (je ne sais trop comment) le taux de change du jour et insérer une ligne dans la table.

Exemple de M. OBAMA

Code :

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

1
2
3
4
5
6
Date       Devise Taux
---------- ------ ------
15/01/2009 USD    1,2500
01/08/2009 USD    1,3456
29/10/2009 USD    1,1123

Evidemment, les taux du 15 janvier et du 29 octobre sont faux puisque dans ton exemple ce sont les taux du 2 janvier et du 1er décembre, respectivement, mais c'est pour l'exemple.
J'ai choisi un code devise alphanumérique mais il existe aussi un code devise numérique. Les deux sont définis par la norme ISO 4217.

[tavarlindar]

Bonjour JPhi33,
Tu as bien compris le besoin. Merci pour l’iso des devises, je ne connaissais pas. L’idée de remplir la table taux_change lorsqu’on créer une opération me plait aussi.
Par contre, je suis surpris par ta proposition dans la mesure où :
1) J’ai déjà une table taux de change.
2) Comme tu le dis

Lors du calcul, il suffit d'accéder à la table avec la date de l'opération et la devise pour récupérer le taux à cette date. C'est ce que j'appellerais la manière bestiale !

.
Si en pratique, il n’y a pas raison de faire autrement, on peut très bien imaginer de que l’utilisateur souhaite faire différemment à savoir pour une date d’opération donnée, prendre une date de change différente. Dans ce cas, comment avoir l’information ?
Nulle part, on stocke en base la date de change souhaitée pour une ligne d’opération. Nulle part on stocke le taux de commission.

Pour l’heure, si ce forum n’existait pas, je partirai sur la solution suivante :
Rajout de 3 attributs à la table réservation :

- taux_change_global , champ de type enum (spécificité je crois de mYSQL) avec 2 valeurs possibles Y ou N. Si Taux_change_global = Y, alors on sait que pour toutes lignes d’opérations associées à cette réservation, on doit prendre en considération qu’une date de taux de change, date stockée dans le champ suivant.
- date_change_globale : date de taux de change à utiliser. NULL par défaut. date_change_globale n’a de sens que si Taux_change_global = Y. Dans le cas où Taux_change_global = N, date_change_globale n’a pas de signification.
- Taux de commission (puisque à 1 réservation donnée correspond un et un seul taux de commission)

Création d’une table enfant de la table opération : operation_change. -> Héritage :
operation_change : avec comme clé primaire id_operation et en même temps clé étrangère (table operation) et comme attribut date_change.
Maintenant, est-ce la bonne voir meilleure solution ?


de retour de vacances ...

Tavar

[JPhi33]

Bonjour Tavar,

1) J’ai déjà une table taux de change.

Désolé, je ne l'avais vue .
Cette table convient mais si un jour tu as besoin d'une nouvelle devise, il faut modifier la structure de la table. Avec celle que je te propose, il n'y a rien à faire, si ce n'est d'ajouter les données.

2) Comme tu le dis .

Lors du calcul, il suffit d'accéder à la table avec la date de l'opération et la devise pour récupérer le taux à cette date. C'est ce que j'appellerais la manière bestiale !

La manière bestiale concerne le nombre de lignes qu'il faut enregistrer dans la table, pas la manière de les récupérer. La table étant identique dans les deux modes de gestion, la méthode d'accès l'est aussi : avec la clé {date, devise}.

on peut très bien imaginer de que l’utilisateur souhaite faire différemment à savoir pour une date d’opération donnée, prendre une date de change différente.

Ceci est une nouveauté... que je n'ai, par conséquent, pas pu prendre en compte. Quoi qu'il en soit, l'application ne peut pas être basée sur des spéculations ; il faut vérifier la validité de cette hypothèse. L'utilisateur peut-il oui ou non choisir une date de taux de change pour chaque opération ? Est-ce seulement souhaitable ?

Dans ce cas, comment avoir l’information ?
Nulle part, on stocke en base la date de change souhaitée pour une ligne d’opération.

J'ai bêtement supposé que le taux de change à prendre en compte pour l'opération est celui de la date de valeur (date_valeur_op).

Nulle part on stocke le taux de commission.

Je ne me suis pas encore préoccupé du taux de commission... mais parlons-en.

Ce taux est jusqu'à présent toujours de 50%

Ce taux a toutes les caractéristiques d'un paramètre du S.I. :
- il s'applique à tous les dossiers et tous les commerciaux (il en est donc indépendant)
- il peut varier dans le temps (sinon ce serait une constante, donc inopportune dans le MCD)

TAUX_COMMISSION (id, taux_commission)

Si on veut garder une trace des différents taux de commission :

TAUX_COMMISSION (date, taux_commission)

mais rien ne dit qu'il en sera toujours à l'avenir pour tous les dossiers

Si le taux de commission dépend du dossier, alors c'est une propriété de l'entité Réservation (à supposer que dossier = réservation).



Pour ce qui est de la solution avec les 3 propriétés supplémentaires dans l'entité Réservation, elle va truffer de NULL la table Réservation correspondante, ce qui n'est pas bon.

[tavarlindar]

Bonjour JPhi33,

Effectivement, la structure de la table taux de change que tu proposes est, sans doute, plus pertinente. Elle est plus souple que celle que j’ai mise en place. Je n’ai pas encore pris de décision (il faut que je modifie l’application existante) , mais je pense (à 99,5%) adopter ta solution.
Tu as choisi comme identifiant monnaie (devise) le Code alphabétique. Je trouve cela plus pratique que le Code numérique. Cela permet une lecture directe.

Je suis surpris par ton commentaire :

Ceci est une nouveauté... que je n'ai, par conséquent, pas pu prendre en compte. Quoi qu'il en soit, l'application ne peut pas être basée sur des spéculations ; il faut vérifier la validité de cette hypothèse. L'utilisateur peut-il oui ou non choisir une date de taux de change pour chaque opération ? Est-ce seulement souhaitable ?

Ceci n’est pas une nouveauté ! Cela fait clairement partie du cahier des charges (règle 4) suivi d’un exemple. Afin de parer à toutes éventualités, je souhaite avoir la possibilité d’affecter le taux de change que je veux quelque soit la ligne d’opération. Donc OUI l’utilisateur doit pouvoir choisir une date de taux de change pour chaque opération.
En pratique, si tel est le cas (utilisation de différents taux de change) , la logique veut que l’on choisisse le taux de change à la même date que la date de valeur de l’opération. Tu as donc intelligemment supposé que le taux de change à prendre en compte pour l'opération est celui de la date de valeur (date_valeur_op). Maintenant, je préfère prévenir que guérir, je préfère que la structure de la base de données (et donc le mcd/mld sous-jaccent) soit capable de répondre à tous les cas de figure (ou presque). Si l’application permet de définir le taux que l’on souhaite pour une opération bancaire donnée, je suis (presque) assuré de ne pas avoir à redévelopper par la suite.

Dans la vie des sociétés, il est fréquent que les règles changent. Je n’ai pas fini de lire l’ensemble du sujet consacré aux règles pour concevoir un bon MCD, mais si je devais à mon humble niveau en édicter une, je dirai : un bon MCD doit anticiper les changements.
Pour cette même raison, il faut considérer le taux de commission comme dépendant du dossier, donc comme une propriété de l'entité Réservation.

Concernant les 3 propriétés supplémentaires dans l'entité Réservation, je suis d’accord, il y aura beaucoup de NULL, mais je ne vois pas comment faire autrement.

Voilà,

Au plaisir de lire tes conseils,

Tavar

[JPhi33]

Bonjour Tavar,

Je suis surpris par ton commentaire :

Ceci est une nouveauté... que je n'ai, par conséquent, pas pu prendre en compte. Quoi qu'il en soit, l'application ne peut pas être basée sur des spéculations ; il faut vérifier la validité de cette hypothèse. L'utilisateur peut-il oui ou non choisir une date de taux de change pour chaque opération ? Est-ce seulement souhaitable ?

Ceci n’est pas une nouveauté ! Cela fait clairement partie du cahier des charges (règle 4) suivi d’un exemple.

Non, la règle 4 dit seulement que l'application doit pouvoir prendre en compte différentes dates de taux de change (i.e. une par opération) dans une même réservation, contrairement à la pratique 3 qui ne prend en compte qu'un seul taux de change par réservation. La règle 4 ne dit pas que l'utilisateur peut choisir n'importe quelle date comme date de taux de change (d'où mon étonnement).



Bref, supposons que cette règle soit valide. Tu as déjà avancé la solution dans ton premier message (sans toutefois aller jusqu'au bout).


L'entité spécialisée "operation_non_euro" contient la date de taux de change pour les opérations la nécessitant (et seulement ces opérations-là).

Quelles sont les opérations nécessitant cette date ? Je serais tenté de dire (hypothèse 1) que ce sont les opérations liées à un compte en devise non Euro pour lesquelles l'utilisateur a choisi une date différente de "date_valeur_op". Dans cette hypothèse, une ligne de cette table ne serait donc créée que si les 2 conditions sont réunies :

C1. l'opération est liée à un compte non Euro
C2. date_taux_change est différente de date_valeur_op

Ce qui réduit le contenu de cette table aux lignes réellement nécessaires.

Pour éviter de se poser des questions, on peut systématiquement récupérer la date de taux de change par jointure externe. La date n'est pas valorisée si, dans la table "operation_non_euro", il n'existe pas de ligne correspondant à l'opération sur laquelle porte la requête.

On peut aussi décider (hypothèse 2) de créer une ligne de cette table dès lors que l'opération est liée à un compte en devise non Euro. Dans cette hypothèse, on ne tient compte que de C1. Pour savoir quelle est la date du taux de change, date_valeur_op ou date_taux_change, il faut préalablement vérifier la devise du compte.

Ce sont les règles fournies par les utilisateurs qui décideront du mode de gestion de cette table.

Pour cette même raison, il faut considérer le taux de commission comme dépendant du dossier, donc comme une propriété de l'entité Réservation.

C'est cohérent. Chaque réservation aura donc son propre taux de commission.

Concernant les 3 propriétés supplémentaires dans l'entité Réservation, je suis d’accord, il y aura beaucoup de NULL, mais je ne vois pas comment faire autrement.

J'ai répondu un peu à la va-vite sur ce point car le taux de commission est valorisé pour chaque réservation comme indiqué ci-dessus (il n'y aura donc pas de NULL).

Pour ce qui est des deux autres propriétés, je ne vois pas leur intérêt avec l'apport de l'entité "operation_non_euro" sauf s'il s'agit du taux de change à appliquer pour le calcul de la commission d'un commercial non payé en Euros. Mais, à ce que j'ai compris, cette commission fait l'objet d'une opération bancaire. Si cette opération est enregistrée dans la table "operation", on aura une date de taux de change...
Il faudrait éclaircir ce point.

[tavarlindar]

Bonjour JPhi33 !

Encore merci pour ta patience et ton aide.

Mea culpa pour la règle 4. Je n’ai pas été assez précis au départ. Il faut considérer la « date_valeur_op » comme étant le plus souvent indépendante de la date de taux de change.
J’ai lu attentivement (comme d’hab !) tes propositions.

Tu as mis le doigt sur un point « épineux » :

sauf s'il s'agit du taux de change à appliquer pour le calcul de la commission d'un commercial non payé en Euros.

Ah voilà qui est intéressant. Prenons le cas suivant : le client paye en euro, tous les fournisseurs sont payés aussi en euro. Bref, les opérations bancaires associées se font en euro (donc compte(s) en euro). Aucun problème, pour calculer la marge brute (ici pas de notion de taux de change). La commission, pas de problème non plus. On prend le taux de commission de la table réservation. On a donc notre commission en euro.
Super, sauf si le commercial est américain et on doit le payer en USD. Il y a du taux de change dans l’air. Je vais donc devoir faire un transfert d’un compte euro vers un compte dollar avant de débiter ce même compte pour payer le commercial. Il va falloir valoriser la commission en USD. Il faut donc que l’on stocke la date de taux de change quelque part.

Ce quelque part où peut-il être ? peut-il être la table "operation_non_euro" ?

Au premier regard, non. L’argent est sur un compte en euro. Compte en euro et operation_non_euro : aucune relation. Maintenant, il y a transfert. Donc l’argent arrive sur un compte non euro. Ah, là il y a une connexion possible. Cela voudrait dire que lors du calcul de la marge et de la commission, on enclenche tout de suite le paiement, histoire d’avoir une opération bancaire sur un compte non euro afin de stocker dans la table associée « operation_non_euro", la date de change. Or, en pratique, on ne va créer une opération bancaire (qui correspond au paiement du commercial US) que pour un ensemble de commissions. Le commercial va percevoir la somme de n commissions correspondant à plusieurs dossiers. On ne peut donc pas, à priori, s’appuyer sur la table operation_non_euro.
A moins de renommer cette table « operation_non_euro » en « operation_taux_change ». Cette table se verrait alimentée selon les cas de figure.

Qu’en penses-tu ?

PS : J’aimais bien mes attributs : taux_change_global et date_change_globale !

[JPhi33]

Il faut considérer la « date_valeur_op » comme étant le plus souvent indépendante de la date de taux de change.

Il y aura donc un peu plus de lignes dans la table "operation_non_euro" que ce que j'avais imaginé mais ceci n'invalide pas la solution.

Super, sauf si le commercial est américain et on doit le payer en USD. Il y a du taux de change dans l’air. [...] Il faut donc que l’on stocke la date de taux de change quelque part.
Ce quelque part où peut-il être ? peut-il être la table "operation_non_euro" ? Au premier regard, non.

Et au deuxième regard non plus. Cette date de taux de change concerne la commission que le commercial "non euro" va percevoir pour avoir traité la réservation. Sa place est donc dans l'entité Réservation mais comme elle ne concerne que les réservations traitées par des commerciaux "non euro", il faut spécialiser la réservation en "Réservation traitée par un commercial dont la commission doit être réglée dans une devise autre que l'euro". Evidemment, ça fait un peu long comme nom d'entité. A toi de trouver plus court.

A ce propos, il y a une lacune dans le MCD : on ne sait pas dans quelle devise il faut payer le commercial. Pour y remédier, il serait judicieux d'associer Commercial et Devise.

On ne peut donc pas, à priori, s’appuyer sur la table operation_non_euro.
A moins de renommer cette table « operation_non_euro » en « operation_taux_change ». Cette table se verrait alimentée selon les cas de figure.

Renommer l'entité ne change rien. L'opération bancaire concernant le commercial porte sur plusieurs dossiers dont chacun nécessite une date de taux de change (potentiellement) différente.

PS : J’aimais bien mes attributs : taux_change_global et date_change_globale !

Désolé mais parfois, il faut savoir faire des sacrifices .

[tavarlindar]

Bonjour JPhi33 !
En essayant de récapituler l’ensemble des modifications à apporter, voici mes premières remarques :

Concernant la table taux de change.
Je n’ai pas réagi tout de suite, mais, sauf erreur de compréhension, je ne peux pas adopter ta proposition qui consiste à avoir la structure suivante : TAUX_CHANGE(date, code_devise, parité_euro).
En effet, je dois gérer la parité USD/GBP. C’est une parité qui sert lors d’un transfert d’un compte en dollar vers un compte en pound britannique (ou l’inverse).
C’est vrai que si demain on me demande de gérer une autre devise, cela modifiera la structure de la table avec l’ajout d’un autre champ. Ce n’est pas, à priori, la mer à boire.

Je reviens sur mes 2 champs : taux_change_global et date_change_globale associé à la table « operation_non_euro ». Je suis têtu.

Quel intérêt j’y vois ?
Aujourd’hui, lorsqu’on calcule la marge et la commission, la comptabilité utilise qu’un seul taux de change(date où elle calcule la commission du commercial en fait). C’est vrai, que je souhaite m’affranchir de cette pratique. Dans le cas, où on adopterait uniquement la table enfant « operation_non_euro », que va-t-il se passer ?
On va se retrouver avec autant de nouvelles lignes dans la table operation_non_euro qu’il y a de lignes d’opération exprimée dans une devise autre que l’euro. Dans le cas, où on utilise un même taux de change, on va créer des lignes avec le même taux de change. On va gonfler artificiellement cette table. Cela me dérange pas outre mesure, mais est-ce une bonne chose ?
J’ai l’impression qu’en ayant un attribut : taux_change_global avec pour valeur Y ou N (Yes / No) cela va me faciliter la vie. Associé à un champ « date_change », cela parait plus simple à gérer.
En y réfléchissant, je ne puis m’empêcher de faire un certain parallèle avec l’épisode II concernant les opérations avec ou sans ventilation. Il y a une notion d’exclusivité. Cette notion d’exclusivité n’a pas été gérée par la création d’un champ : opération ventilée: Y/N, mais par la création de 2 tables enfants : operation_sans ventilation et detail_operation.
D’où l’idée de faire de même ici.
« operation_non_euro _tx_change_unique » et « operation_non_euro _tx_change_personnalises ». J’ai essayé de le modéliser mais lorsque je demande de générer le mld, l’AGL refuse pour une histoire de référence circulaire ….


L’idée est de créer la table « operation_non_euro _tx_change_unique » comme table enfant de la table réservation avec pour identifiant l’id_reservation et comme attribut la date de change. De l’autre côté on créer une table enfant de la table operation : « operation_non_euro _tx_change_personnalises ». C’est la même table « operation_non_euro » que tu proposes et qui est simplement renommée.
Pour ce qui est du paiement du commercial, ok pour créer une table enfant de la table reservation : « Réservation traitée par un commercial dont la commission doit être réglée dans une devise autre que l'euro » que l’on pourrait nommer comme « paiement_commission_commercial_non_euro » aec pour attribut la date de change.
Concernant le paiement des commerciaux, effectivement, il manque une relation. La règle c’est qu’un commercial est payé dans une seule devise. Toutefois, un commercial pouvant changer de continent (c’est déjà arrivé), pour garantir l’historique, je vais créer un nouvel attribut dans la table « commercial » mais aussi dans la table réservation : devise_commercial.
Si tu regardes bien cette table « reservation », j’ai de même devise_client, devise_provider. Dans le cas d’un client, un client paye sa location (reservation) dans une seule et même devise. La logique voudrait qu’on ne créé pas de champ devise client, puisqu’une réservation se rattache à un et un seul client. Donc si on connait le client, on connait sa devise et on sait comment dans quelle devise la réservation a été payée. Seulement, comme un client peut à travers le temps déménager et changer de devise, j’ai jugé bon de stoker la devise de paiement directement dans la table reservation.
Peut-être as-tu des remarques à faire aussi sur cette pratique qui vise à conserver et garantir l’historique.

Qu’en penses-tu ?

Par avance merci pour ton aide, et si d'autres personnes on avis sur la question, qu'il n'hésite pas !

Tavar

[JPhi33]

Bonjour Tavar,

je ne peux pas adopter ta proposition qui consiste à avoir la structure suivante : TAUX_CHANGE(date, code_devise, parité_euro).
En effet, je dois gérer la parité USD/GBP.

Dans ce cas, la structure à adopter est
TAUX_CHANGE(date_taux_change, devise_source, devise_cible, parité)

Code :

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

1
2
3
4
5
6
7
Date_taux_change Devise_source Devise_cible Parité
---------------- ------------- ------------ ------
15/01/2009       EUR           USD          1,2500
01/08/2009       EUR           USD          1,3456
29/10/2009       EUR           USD          1,1123
29/10/2009       USD           GBP          0,6324

C’est vrai que si demain on me demande de gérer une autre devise, cela modifiera la structure de la table avec l’ajout d’un autre champ. Ce n’est pas, à priori, la mer à boire.

Admettons qu'on enregistre une date de taux de change par semaine en moyenne et qu'au bout de 2 ans on te demande d'ajouter un nouveau taux de change. La table contiendra environ 100 lignes. Dès lors que tu ajouteras la colonne du nouveau taux de change, la table contiendra NULL dans cette colonne pour les 100 lignes existantes.

Il faut considérer un autre aspect de cette question. L'enregistrement d'une date de taux de change est probablement effectué pour un besoin précis : une parité pour une opération donnée ; pour deux taux de change, il faudrait que l'on ait deux opérations à traiter le même jour sur des parités différentes, ce qui semble être plutôt rare. Donc, en reprenant l'exemple ci-dessus, on a :

Code :

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

1
2
3
4
5
6
Date_change euro_usd euro_gbp euro_aud euro_zar usd_gbp
----------- -------- -------- -------- -------- -------
15/01/2009  1,2500   NULL     NULL     NULL     NULL
01/08/2009  1,3456   NULL     NULL     NULL     NULL
29/10/2009  1,1123   NULL     NULL     NULL     0,6324

La table va être truffée de NULL. Rien que sur cet exemple, on a 11 NULL pour 4 valeurs.

Je reviens sur mes 2 champs : taux_change_global et date_change_globale associé à la table « operation_non_euro ».
Aujourd’hui, lorsqu’on calcule la marge et la commission, la comptabilité utilise qu’un seul taux de change(date où elle calcule la commission du commercial en fait). C’est vrai, que je souhaite m’affranchir de cette pratique.

Ce débat a déjà eu lieu. Il faut choisir entre les deux règles.

Soit c'est la règle d'une seule date de taux de change pour toutes les opérations de la réservation, auquel cas il faut adopter la modélisation d'une entité spécialisée de la réservation, soit c'est la règle d'une date de taux de change spécifique à l'opération, laissant libre l'utilisateur de choisir cette date pour chaque opération tel qu'exprimé précédemment :

Donc OUI l’utilisateur doit pouvoir choisir une date de taux de change pour chaque opération.

Ceci dit, si tu veux quand même gérer les deux cas de figures, la solution est de spécialiser l'entité réservation. C'est ce que tu as fait avec l'entité "operation_non_euro_tx_change_unique". Sauf que cette entité ne touche pas les opérations mais la réservation. Je suggère "Réservation à taux de change unique". La propriété booléenne taux_change_global est inutile : l'information est apportée par l'existence ou non de l'occurrence de taux de change unique correspondant à la réservation.



Pour terminer, j'ai une question sur un aspect du modèle auquel je n'avais pas prêté attention jusqu'à présent : pourquoi une opération ne dépend-elle pas d'une seule réservation ?

[tavarlindar]

Bonjour JPhi33,
Encore merci pour ton aide,

Ok pour la structure de la table TAUX_CHANGE(date_taux_change, devise_source, devise_cible, parité).
Néanmoins, hormis le cas d’un ajout de parité (nouvelle devise à gérer), normalement, je n’ai pas de NULL . Lorsque le système met à jour les taux de change, je récupère pour une date donnée, tous les taux de change.

Code :

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

1
2
3
4
5
6
Date_change euro_usd euro_gbp euro_aud euro_zar usd_gbp
----------- -------- -------- -------- -------- -------
15/01/2009  1,2500   NULL     NULL     NULL     NULL
01/08/2009  1,3456   NULL     NULL     NULL     NULL
29/10/2009  1,1123   NULL     NULL     NULL     0,6324

Donc en adoptant ta proposition, en prenant l’exemple ci-dessus, au lieu de se retrouver avec une table de 3 lignes, la nouvelle table contiendra 3*5 = 15 lignes. En pratique donc, si en une année, on a besoin de 24 date de change (2 mise à jour par mois par ex), on va se retrouver avec 24 x 5 = 120 lignes au lieu de 24 lignes. J’espère que cela ne va pas allonger le temps des requêtes.
Quoi qu’il en soit, je vais adopter ta solution puisque dans le cas d’une nouvelle devise, évidemment, si je conserve ma structure actuelle, nous aurions des valeurs NULL pour la nouvelle parité à gérer.

Pour ce qui est des spécialisations, tu as raison, une table enfant "Reservation_TxChange_Unique" est plus parlant que "operation_non_euro_tx_change_unique"
Nous aurions ainsi 2 tables "Reservation_TxChange_Unique" et "operation_non_euro ".

Pourquoi une opération ne dépend-elle pas d'une seule réservation ?

Je ne pense ne pas comprendre la portée de ta question.

Une opération bancaire n’est pas forcément liée à une réservation. Les frais généraux par exemple font l’objet d’opération bancaire et ne sont absolument pas lié à une réservation.
Par contre si une opération découle d’une réservation (réservation -> échéance -> opération), alors cette opération se rattache à une et une seule réservation.

Par ailleurs as-tu quelques remarques à faire sur la manière dont est géré l’historique ?

Tavar

[JPhi33]

Bonjour Tavar,

Lorsque le système met à jour les taux de change, je récupère pour une date donnée, tous les taux de change.

C'est une bonne nouvelle au cas où il serait décidé de conserver la structure actuelle.

au lieu de se retrouver avec une table de 3 lignes, la nouvelle table contiendra 3*5 = 15 lignes. En pratique donc, si en une année, on a besoin de 24 date de change (2 mise à jour par mois par ex), on va se retrouver avec 24 x 5 = 120 lignes au lieu de 24 lignes. J’espère que cela ne va pas allonger le temps des requêtes.

Pour les requêtes de recherche de taux de change, a priori ça ne devrait rien changer (accès sur clé complète). Pour ce qui est des ajouts de taux de change, il est un fait que, pour une date, au lieu d'insérer une ligne, il faut en insérer 5.
Toutefois, ceci est à mettre en balance avec la souplesse procurée par la table. Un autre cas concret : imagine que la Grande-Bretagne entre dans la zone Euro, avec la structure actuelle, il faudra insérer NULL dans la colonne usd_gbp jusqu'à la fin de la vie de l'application (la suppression de la colonne n'est pas envisageable à cause de l'historique). Alors que la structure que je propose permet tout simplement d'arrêter d'insérer les lignes correspondant au taux de change USD/GBP tout en conservant celles qui ont été utiles dans l'historique.

Pour conclure sur cette table, voici pourquoi j'en ai proposé la structure (en fait j'aurais du commencer par là). Cette structure provient tout simplement de la modélisation naturelle des données. La table TAUX_CHANGE telle que je l'ai modélisée est en fait une association. Voici le MCD correspondant :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
  +--[ Devise  ]--+
  |               |
 0,n             0,n
  |               |
source          cible
  |               |
  +-(Taux_change)-+
          |
         0,n
          |
       [ Date ]

L'association "Taux_change" contient la propriété parité.

Par contre si une opération découle d’une réservation (réservation -> échéance -> opération), alors cette opération se rattache à une et une seule réservation.

Et bien ce n'est pas ce qui est modélisé.
Quelque chose m'a gêné dès lors que tu as parlé de taux de change global au niveau de la réservation en remplacement des taux de change spécifiques à chaque opération. La relation entre réservation et opération n'a pas été débattue dans l'épisode I.
Ce qui est modélisé est qu'une opération regroupe un ensemble de d'échéances client et d'échéances fournisseur. Rien n'interdit qu'elles puissent être associées à des réservations différentes.

Par ailleurs as-tu quelques remarques à faire sur la manière dont est géré l’historique ?

Les propriétés devise_xxx sont une manière de conserver l'historique des devises du client, du fournisseur et du commercial. Il existe une autre technique plus sémantique permettant de les gérer. Prenons l'exemple du commercial :

[Commercial]<-1,n----( )---(1,1)-[Histo_devise_com]--1,1----( )----0,n->[Devise]

"Histo_devise_com" est une entité faible (cardinalités 1,1 entre parenthèses) dépendant du commercial et identifiée par Date_début matérialisant la date à partir de laquelle le commercial est payé dans cette devise. La table issue de "Histo_devise_com" est donc :

HISTO_DEVISE_COMMERCIAL(id_commercial, date_debut, id_devise#)

De la même manière, on pourra avoir Histo_devise_client et Histo_devise_provider.

[fsmrel]

Bonsoir à vous deux,


Heureusement que JPhi33 est là, quel boulot !


@ Tavar, concernant le MCD (début du 3e épisode), j'ai au moins trois bateaux de retard, mais :

1. Pourquoi ne pas avoir mis en œuvre le MCD proposé par JPhi33 dans son message du 01/05/2008 alors que vous l’aviez fait dans votre message du 07/05/2008 ?
   
2. FOURNITURE_SERVICES est ce que Codd appelle une entité-type associative. Dans le contexte Merise, c’est une association-type que l’on a déguisée en entité-type, parce que PRESTATION en est une propriété multivaluée et parce qu’elle entretient des relations avec ECHEANCE (toujours ce problème des relations auxquelles participent des relations...) Par conséquent, le déguisement implique que FOURNITURE soit identifiée relativement à RESERVATION et FOURNISSEUR (cardinalités mises entre parenthèses dans la partie conceptuelle ci-dessous, convention Power AMC). L’attribut id_fourniture_services doit disparaître. Quant à l’attribut num_fournisseur, mais « c’est qu’est-ce que c’est » ?
   
   
   
   MLD correspondant :
   
   
   
3. L’entité-type RESERVATION est « pondéralement surchargée ». A quoi correspondent les nombreux attributs nf_ligne_xxx ? A des données calculées ? l’entité-type comporte 5 attributs etape1, etc. Que ferez-vous le jour où il faudra ajouter etape6, etape7, etc. ? Il serait opportun de dégraisser la bête et de « verticaliser » tout cela.
   
4. L’obésité risque de toucher aussi l’entité-type DEMANDE (pollution de commentaires en tous genres).

Je n’ai pas suivi le feuilleton monétaire qui me fait penser au Biglotron...

Je dirais quand même à propos de la table TAUX_CHANGE (date_taux_change, devise_source, devise_cible, parité) proposée par JPhi33 que c’est la solution qu’il faut évidemment mettre en oeuvre. Je suggère toutefois un aménagement, à cause de la complexité des requêtes SQL qui seront à écrire en relation avec la détermination d’une valeur de parité : par exemple, quelle est la parité de l’euro et de la livre anglaise au 01/09/2009 ? au 15/11/2009 ? Je sais qu’au niveau conceptuel on n’a pas à se préoccuper de contingences de cet ordre, mais la recommandation est au niveau du MLD de mettre en œuvre une table des derniers taux de change et une autre table dans laquelle sont historisés les taux n’ayant plus cours. Pour reprendre l’exemple de JPhi33, en l'aménageant :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
TAUX_Depuis (Devise_Source   Devise_Cible    Date_Taux   Parité
             -------------   ------------   ----------   ------
             EUR             USD            29/10/2009   1,1123  
             USD             GBP            29/10/2009   0,6324


TAUX_Histo (Devise_Source  Devise_Cible  Date_Taux_Deb  Date_Taux_Fin  Parité
            -------------  ------------  -------------  -------------  ------
            EUR            USD              15/01/2009     31/07/2009  1,2500  
            EUR            USD              01/08/2009     28/10/2009  1,3456

Ainsi, pour savoir quelle est la parité euro/dollar à une date donnée D, la requête SQL (simple et performante) sera celle-ci :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
SELECT    Parite
FROM      TAUX_DEPUIS
WHERE     Devise_Source = 'EUR' AND Devise_Cible = 'USD'
  AND     D >= Date_Taux
UNION ALL
SELECT    Parite
FROM      TAUX_HISTO
WHERE     Devise_Source = 'EUR' AND Devise_Cible = 'USD'
  AND     D >= Date_Taux_Deb AND D <= Date_Taux_Fin

Je vous laisse le soin de coder la requête (moins simple et moins performante) dans le cas de la table TAUX_CHANGE (date_taux_change, devise_source, devise_cible, parité).

Ce qui vaut pour les parités des taux vaut également pour tout ce qui a un caractère historique (cf. l’historisation des règlements des commerciaux et Cie) :

Une table XXX_DEPUIS (..., Date_depuis, ...)
Et une table XXX_HISTO ( ..., Date_début, Date_fin, ...)

Ceci est traité en long et en large dans l’ouvrage suivant (400 pages) exclusivement consacré aux données intervallaires (en fait temporelles) : Temporal Data and the Relational Model (A Detailed Investigation into the Application of Interval and Relation Theory to the Problem of Temporal Database Management) par C.J. Date, Hugh Darwen, Nikos A. Lorentzos.

[JPhi33]

Bonsoir,

Pourquoi ne pas avoir mis en œuvre le MCD proposé par JPhi33 dans son message du 01/05/2008 alors que vous l’aviez fait dans votre message du 07/05/2008 ?

tavarlindar a mis en oeuvre, les deux fois, le MCD que j'ai proposé.

FOURNITURE_SERVICES est ce que Codd appelle une entité-type associative. Dans le contexte Merise, c’est une association-type que l’on a déguisée en entité-type

Ce n'est pas ce que j'avais modélisé (regardez bien) mais je ne me souviens plus pourquoi je n'avais pas été jusque là. Probablement ne voulais-je pas introduire trop de nouveautés pour Tavar, le problème était déjà suffisamment compliqué sans en rajouter ; ou bien je savais pertinemment qu'AnalyseSi ne sait pas modéliser l'identification relative.

Je n'avais pas non plus proposé que PRESTATION soit une entité faible de FOURNITURE mais pourquoi pas.

Quant à l’attribut num_fournisseur, mais « c’est qu’est-ce que c’est » ?

Moi non plus je ne vois ce qu'il vient faire ici.

Je suggère toutefois un aménagement, à cause de la complexité des requêtes SQL qui seront à écrire en relation avec la détermination d’une valeur de parité : par exemple, quelle est la parité de l’euro et de la livre anglaise au 01/09/2009 ? au 15/11/2009 ?

Je ne comprends pas le problème de la complexité des requêtes. Peut-être ai-je mal perçu le problème...
Pour moi, une ligne de TAUX_CHANGE est créée pour chaque date de taux de change dont on a besoin. Il n'y aurait donc pas de durée ou d'intervalle de temps pendant lequel un taux de change est valable.
Lorsqu'on a besoin d'un taux de change, on dispose de la date D, et des devises source S et cible C.

Code SQL :

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

1
2
3
4
5
6
 
SELECT parite
  FROM TAUX_CHANGE
 WHERE date_taux_change = D
   AND devise_source = 'S'
   AND devise_cible = 'C'

Pour ce qui est des devises associées aux commerciaux, clients et provider, il y a là, effectivement, présence d'une durée. Par conséquent, la proposition de fsmrel peut être retenue. Ceci est à mettre en rapport avec le nombre de fois où un acteur change de devise et qui doit être très faible en moyenne. Donc créer 3 tables supplémentaires n'est-ce pas un peu du luxe dans ce cas précis ?

[fsmrel]

Bonjour,

tavarlindar a mis en oeuvre, les deux fois, le MCD que j'ai proposé.

Les MCD proposés par Tavar le 03/09/2010 et le 23/09/2010 ne traduisent pas la généralisation/spécialisation. Dans le style d’Open ModelSphere, le MCD devrait être celui-ci :



Et le MLD (à la notation des liens près) :

FOURNITURE_SERVICES est ce que Codd appelle une entité-type associative. Dans le contexte Merise, c’est une association-type que l’on a déguisée en entité-type

Ce n'est pas ce que j'avais modélisé (regardez bien) mais je ne me souviens plus pourquoi je n'avais pas été jusque là. Probablement ne voulais-je pas introduire trop de nouveautés pour Tavar, le problème était déjà suffisamment compliqué sans en rajouter ; ou bien je savais pertinemment qu'AnalyseSi ne sait pas modéliser l'identification relative.

Je n'avais pas non plus proposé que PRESTATION soit une entité faible de FOURNITURE mais pourquoi pas.

A la lettre ça n’est évidemment pas ce que vous avez modélisé, mais dans l’esprit il n’en demeure pas moins que FOURNITURE_SERVICES est une association-type à laquelle participent RESERVATION et FOURNISSEUR (un fournisseur propose tels services pour telle réservation). Elle a pour identifiant la « concaténation » (quel vilain mot) des identifiants des participants, d’où la clé primaire (quel vilain mot) {IdReservation, IdFournisseur} pour la table FOURNITURE_SERVICES correspondante.

Pour moi, une ligne de TAUX_CHANGE est créée pour chaque date de taux de change dont on a besoin. Il n'y aurait donc pas de durée ou d'intervalle de temps pendant lequel un taux de change est valable.
Lorsqu'on a besoin d'un taux de change, on dispose de la date D, et des devises source S et cible C.

Code SQL :

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

1
2
3
4
5
SELECT parite
  FROM TAUX_CHANGE
 WHERE date_taux_change = D
   AND devise_source = 'S'
   AND devise_cible = 'C'

Je suis d’accord que dans ces conditions la notion de période ne se justifie pas et donc que la table TAUX_CHANGE que vous proposez convient tout à fait. Au cas où cela peut intéresser Tavar, s’il fallait malgré tout chercher une parité dans un intervalle, vu que seul l’attribut Parite est historisé, il n’y a pas de complications du point de vue des requêtes.
Exemple : rechercher la parité euro/dollar au 15 septembre 2009 :

Code SQL :

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

1
2
3
4
5
6
7
8
9
 
SELECT  Date_Taux, Parite
FROM    TAUX 
WHERE   Devise_Source = 'EUR' AND Devise_Cible = 'USD'
  AND   Date_Taux = 
            (SELECT MAX(Date_Taux)
             FROM   TAUX
             WHERE  Devise_Source = 'EUR' AND Devise_Cible = 'USD'
               AND  Date_Taux <= '2009-09-15')

Pour ce qui est des devises associées aux commerciaux, clients et provider, il y a là, effectivement, présence d'une durée. Par conséquent, la proposition de fsmrel peut être retenue. Ceci est à mettre en rapport avec le nombre de fois où un acteur change de devise et qui doit être très faible en moyenne.

Quand il y a historisation, on met en œuvre une entité-type ad-hoc. Quelle est l’alternative ?

Donc créer 3 tables supplémentaires n'est-ce pas un peu du luxe dans ce cas précis ?

Dans un contexte relationnel ou SQL, trois tables supplémentaires ça n’est rien. Ceci dit, ne serait-il pas temps de procéder à une opération de généralisation des commerciaux, clients et providers ? (Incidemment, les trois tables ne feraient plus qu’une).

[tavarlindar]

Bonjour !

Concernant la table Taux_Change, JPhi33, tu m’as définitivement convaincu d’abandonner ma structure et d’adopter celle que tu proposes. L’argument mettant en avant le changement de devise d'un pays est un argument plus que pertinent.
Au passage, je viens de prendre conscience que lorsque je crée des tables, je ne me pose pas suffisamment la question : et demain, si cet attribut devient caduc, que se passe-t-il ?

Comme le précise fsmrel, il y a du boulot !

Pourquoi ne pas avoir mis en œuvre le MCD proposé par JPhi33 dans son message du 01/05/2008 alors que vous l’aviez fait dans votre message du 07/05/2008 ?

C’est une bonne question ! En fait, à cette époque, appelons un chat un chat, l’héritage me faisait peur. Les rapides analyses et tests que j’avais effectués m’avait refroidi. (souvenirs...

Techniquement, au-delà du MCD, c’est la partie mise en œuvre sql qui me posait psychologiquement problème. Aujourd’hui, c’est pareil, sauf que … ce n’est plus psychologique ! Si je ne l’ai pas encore mise en œuvre, je trouverai bien un moyen de le faire. Et de manière général, il n’y a pas de problème technique, il n’y a que des solutions.
Ceci étant dit, de là à tout refondre, je ne suis pas du tout chaud. J’ai 2 tables Echéances (echeance_client et echeance_fournisseur), je les garde. L’héritage n’a pas été mis en œuvre, c’est dommage, j’avoue, mais … Sinon, il faudrait que je recode toute la partie applicative (PHP + javascript). Cela fonctionne, donc tant pis, si ce n’est pas l’optimum optimorum.
Bon, si vous me prouvez par a+b qu’on va à la catastrophe avec le mld actuel, ok, mais franchement, je ne pense pas. Ceci ne vaut que pour l'épisode I. Si aujourd'hui, il faut spécialiser, je spécialise, sinon à quoi bon vous demander vos conseils ?

Quant à l’attribut num_fournisseur, mais « c’est qu’est-ce que c’est » ?

C’est un champ qui me sert au niveau applicatif.


Lorsque l’utilisateur établit une réservation, il précise les prestations qui sont facturées. Pour chaque presta, il précise quel est le fournisseur qui l’effectue et sont coût. Par défaut, toutes les services sont fournis par le fournisseur num=1 . Maintenant, on peut définir un 2ème fournisseur, un 3ème, etc. On peut ainsi dire que la prestation A, B, D et E sont fournit par le fournisseur 1 et que les presta C, F et J sont elles fournies par le fournisseur 2.

Si l’utilisateur décide d’appeler un fournisseur 99 (num = 99), il peut. Il suffit juste de préciser ensuite que 99 = nom d’un fournisseur. Ce num_fournisseur n’a donc rien à voir avec l’id_fournisseur stocké en base. C’est une numérotation qui est propre à l’utilisateur et qui n’est valable que pour une réservation.

L’entité-type RESERVATION est « pondéralement surchargée ». A quoi correspondent les nombreux attributs nf_ligne_xxx ?

Oui ! les nb_ligne_XXX sont des champs calculés qui servent pour générer les pages php. Lorsque l’utilisateur créer ou supprime des lignes (via javascript côté applicatif), je tiens à jour un (des) compteur de lignes. Ces compteurs « javascript » vont être stockés en base. Lorsqu’on revient sur une page, je me sers de ces champs pour générer les bons tableaux. Plutôt que faire des requêtes pour calculer le nombre de lignes de ceci ou cela, je lie directement la valeur dans une seule table, la table réservation… Cela me simplifie la vie. Ce n’est sans doute pas très académique, mais une chose est sûre, cela fonctionne à merveille et c’est très rapide.

Et si demain, etape6, etape7,….
Au passage, qu’est-ce que c’est ? J’ai découpé la réalisation d’une réservation en 5 étapes = 5 écrans applicatifs. Cela me permet de savoir à quelle étape est une réservation. Chaque étape a 2 statuts possibles C ou M pour Créer ou Modifier. Évidemment, en fonction du statut, chaque étape est gérée différemment. Si demain une 6ème étape et bien question historique, je mettrai en étape 6 la valeur M pour toutes les réservations passées.

Il serait opportun de dégraisser la bête :

oui ! Certainement ! et notamment au niveau des emails. Ce qui me donnera l’occasion de donner les règles de gestion pour finir le sujet. Je ne le fais pas maintenant, mais cela va vite venir.

Biglotron

... ? Ce n’est pas sympa … c’est plutôt un MégaSuperBiglotron !!
Pour ce qui est de la gestion de l’historique, je vais étudier vos propositions en détails … Je présens que vous avez encore raison, mais je n’ai pas encore analysé toutes les implications. C’est bien beau de créer des tables, mais après il faut les gérer !
Avant cela, encore merci .

Tavar

[JPhi33]

Bonsoir,

Lorsque l’utilisateur établit une réservation, il précise les prestations qui sont facturées. Pour chaque presta, il précise quel est le fournisseur qui l’effectue et sont coût.

Ce qui aboutit à la création d'une occurrence de FOURNITURE laquelle est un couple {RESERVATION, FOUNISSEUR}. Ce qui a pour conséquence d'identifier un et un seul fournisseur (Episode I).

Par défaut, toutes les services sont fournis par le fournisseur num=1 .
Maintenant, on peut définir un 2ème fournisseur, un 3ème, etc. On peut ainsi dire que la prestation A, B, D et E sont fournit par le fournisseur 1 et que les presta C, F et J sont elles fournies par le fournisseur 2.

Si l’utilisateur décide d’appeler un fournisseur 99 (num = 99), il peut.

D'après la copie d'écran, ce numéro de fournisseur est une donnée applicative permettant de faire un lien visuel entre les prestations et la désignation du fournisseur + total fournisseur en bas. Pourquoi la stocker dans la base de données ? Il y a d'autres moyens de faire ce lien visuel. Par exemple, remplacer la colonne "supplier num" par une colonne "supplier" contenant la liste déroulante des fournisseurs. Le lien se fait alors de facto.

Objectivement, c'est quand même plus confortable pour l'utilisateur de voir :

Code :

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
-------------------  ---------    ---------  -----------------------
Heading              Price        Costs      Supplier
-------------------  ---------    ---------  -----------------------
Location de bateau     5000.00      2000.00  123 Test Virginie
zodiac                       0       250.00  123 Test Virginie
bouée                        0        50.00  123 Test Virginie
Fusée de détresse            0       600.00  The Idea Travel Company
assurance               100.00        50.00  Ouest Assurance


---------------------------------
Suppliers
---------------------------------
123 Test Virginie         2300.00
The Idea Travel Company     50.00
Ouest Assurance            600.00

plutôt que d'être obligé de faire le lien par un numéro fictif, même si c'est lui qui l'attribue. Non ?

[fsmrel]

Bonsoir,

L’héritage n’a pas été mis en œuvre, c’est dommage, j’avoue, mais … Sinon, il faudrait que je recode toute la partie applicative (PHP + javascript). Cela fonctionne, donc tant pis, si ce n’est pas l’optimum optimorum

Don’t worry. Dans leur première version, Merise et plus généralement les méthodes Entité/Association ne proposèrent strictement rien concernant le thème de l’héritage : ce que vous avez modélisé est valide et n’aurait fait l’objet d’aucune remarque particulière il y a trente ans. Pour la petite histoire, les premiers à avoir proposé la généralisation dans le contexte de la modélisation des données furent John Miles Smith et Diane C.P. Smith en 1976, dans un article publié en 1977 : Database Abstractions: Aggregation and Generalization. Codd intégra le concept dans RM/T (cf. son article de 1979), renvoyant ainsi l’ascenseur à la famille Smith qui s’était appuyée sur le Modèle Relationnel de Données pour illustrer sa théorie.

Cela dit, vous devez désormais maîtriser le concept de généralisation/spécialisation...

C’est une numérotation qui est propre à l’utilisateur et qui n’est valable que pour une réservation.

Je partage totalement l’avis de JPhi33 quant à la pertinence de l’attribut NumFournisseur, mais comme vous êtes parfois un peu têtu (sorry...), je vais supposer que vous souhaitez le conserver.

Si j’ai bien compris, il s’agit d’un synonyme pour le nom du fournisseur, relativement à une réservation et dont la valeur est définie par l’utilisateur. Ainsi, dans le cas de la réservation <r1>, le fournisseur <123 Test Virginie> identifié par <f1> a pour synonyme <1>, tandis que dans le cas de la réservation <r2>, le fournisseur <123 Test Virginie> (toujours identifié par <f1>) aurait par exemple pour synonyme <5> :

Code :

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

1
2
3
4
5
6
7
8
 
IdReservation  IdFournisseur  NumFournisseur
-------------  -------------  --------------
           r1             f1               1
           r1             f2               2
           r1             f3              99
           r2             f1               5
           r2             f3               2

Mais, selon votre MLD actuel, la paire {IdReservation, IdFournisseur} n’est pas clé candidate, donc faites en sorte qu’il en soit ainsi.
A défaut, on pourrait très bien se retrouver avec les triplets <r1, f1, 1> et <r1, f1, 2>.

Symétrie oblige, la paire {IdReservation, NumFournisseur} doit aussi être clé candidate, sinon on pourrait avoir des triplets du genre :

<r1, f2, 2> et <r1, f4, 2>.

Le MLD devrait ressembler à ceci :



Avec Open ModelSphere, la clé alternative {IdReservation, NumFournisseur} est repérée par le mickey <1>.

Vous noterez par ailleurs que l'attribut NumFournisseur n’a rien à faire dans la table PRESTATION, sinon il y aurait viol de la deuxième forme normale (2NF), un truc à vous faire traîner devant les tribunaux relationnels.

=> Suivez l’avis de JPhi33.

C’est bien beau de créer des tables, mais après il faut les gérer !

Je vous ai fourni des exemples de requêtes SQL dans mon message précédent. Il est quand même préférable de gérer des tables correctement modélisées que de biglotronner dans des tables pondéralement surchargées, même s’il y a de la jointure à mettre en oeuvre. Cela vaut évidemment pour les attributs qui dans RESERVATION correspondent aux données calculées et aux étapes et y sont des corps étrangers.

[tavarlindar]

Bonjour à tous les deux,
Encore merci pour votre aide. Après quelques semaines de réflexions, voici mes interrogations :

Concernant l’historisation.

Concernant les taux de change, je rejoins JPhi33. Nous n’avons pas besoin de connaître une parité dans un intervalle de temps. La structure proposée par JPhi33 qui s’appuie sur une seule table convient.
J’ai néanmoins essayé de comprendre la requête suivante proposée par fsmrel.

Code :

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

1
2
3
4
5
6
7
8
9
SELECT    Parite
FROM      TAUX_DEPUIS
WHERE     Devise_Source = 'EUR' AND Devise_Cible = 'USD'
  AND     D >= Date_Taux
UNION ALL
SELECT    Parite
FROM      TAUX_HISTO
WHERE     Devise_Source = 'EUR' AND Devise_Cible = 'USD'
  AND     D >= Date_Taux_Deb AND D <= Date_Taux_Fin

En essayant de comprendre, je me rends compte que cela pose plusieurs questions !
Considérons la gestion de l’historisation des devises. Prenons le cas de la devise du client.
Quelles sont les conséquences ?

Cela veut dire créer 2 tables du type :

Devise_Client_Depuis : Devise, Date_devise, Devise, client_id
Devise_Client_Histo : Devise, Date_devise_deb, Date_devise_fin, client_id

Où client_id est une clé étrangère de la table Client (qui a pour identifiant et clé primaire id_client)

Que se passe-t-il lorsqu’on crée un client ? D’après ce que j’ai pu tester, on ne renseigne pas la table Devise_Client_Histo, vu que l’on ne connait pas la date_devise_fin.

Cela implique que lorsqu’on crée un client, on renseigne sa devise, on doit alors renseigner la table Devise_Client_Depuis. Exemple, le 1/02/2010 on crée Mr Dupont (id_client = 201), devise = EUR.

On modifie la fiche client (nom, adresse, etc) . Il faut alors faire un test.
Si la devise est la même que celle renseignée la première fois, alors on ne modifie pas la table Devise_Client_Histo. Dans le cas contraire, on renseigne la Date_devise_fin et on crée une nouvelle ligne dans la table Devise_Client_Depuis.

Est-ce bien cela ? Comment cela fonctionne ?

Je ne suis pas sût d’avoir tout compris. En particulier, sauf erreur de ma part, lorsqu’on renseigne la table histo, il faut faire aussi des calculs. Exemple : Le 15 mai, on modifie la devise du client. Dans ce cas là, il faudra calculer la date Jour de la modif – 1 donc ici 14 mai et la mettre comme date_fin dans la table Histo afin d’avoir
Client_id = 201, date_devise_debut = 01-02-2010, date_devise_fin = 14-05-2010 et devise = EUR.

Évidemment par rapport à ce qui est aujourd’hui cela complexifie un peu les choses. En effet, à ce jour, lorsqu’on modifie une fiche client, je ne me pose pas la question de savoir ce qui a été modifié ou pas, les infos sur le client viennent écraser les anciennes.

Au-delà de l’implémentation (le sujet est intéressant), la question est de savoir si on souhaite conserver un historique ou pas. Au-delà de dégraisser la table réservation, je ne vois pas trop l’intérêt de conserver une notion d’historique dans des tables à part pour le moment.
J’entends à l’avance fsmrel dire : « il est fatiguant ce Tavarlindar, qu’est-ce qu’il est têtu ! ». Euh, c’est un peu vrai, mais beaucoup faux aussi ! La preuve j’adopte très souvent les solutions qui me sont proposées dans la mesure où on m’explique pourquoi elles sont meilleures.

Donc, pour l'heure, je n'exclus donc pas d'utiliser des tables histo.

Concernant le num_fournisseur.

Ne pourrait-t-on pas « remplacer la colonne "supplier num" par une colonne "supplier" contenant la liste déroulante des fournisseurs » ? comme le suggère Jphi33.
Eh bien NON. J’ai retenu cette technique en m’inspirant d’une application qui tourne depuis de très nombreuses années chez le numéro 1 de la distribution d’électroménager (en autre). Technique qui a fait ses preuves avec quelques dizaines de millier d’utilisateurs de tous profils.
Plutôt que de sélectionner directement le nom du fournisseur (via un menu déroulant ou pas), c’est plus rapide de mettre un numéro devant chaque prestation et ensuite d’établir la correspondance. Je conserve donc cette façon de faire, non pas parce que je suis têtu, mais parce que c’est l’efficience même ! Cette façon de faire au niveau Interface Homme Machine est à priori la meilleure. Maintenant que derrière, elle soit mal implémentée au niveau base de données, c’est un autre sujet.
Je ne comprends pas les remarques de fsmrel au sujet de la table fourniture_services.

J’ai relevé les points suivants :

FOURNITURE_SERVICES est ce que Codd appelle une entité-type associative. Dans le contexte Merise, c’est une association-type que l’on a déguisée en entité-type, parce que PRESTATION en est une propriété multivaluée et parce qu’elle entretient des relations avec ECHEANCE (toujours ce problème des relations auxquelles participent des relations...) Par conséquent, le déguisement implique que FOURNITURE soit identifiée relativement à RESERVATION et FOURNISSEUR (cardinalités mises entre parenthèses dans la partie conceptuelle ci-dessous, convention Power AMC). L’attribut id_fourniture_services doit disparaître.

FOURNITURE_SERVICES est une association-type à laquelle participent RESERVATION et FOURNISSEUR (un fournisseur propose tels services pour telle réservation). Elle a pour identifiant la « concaténation » (quel vilain mot) des identifiants des participants, d’où la clé primaire (quel vilain mot) {IdReservation, IdFournisseur} pour la table FOURNITURE_SERVICES correspondante.

Si j’ai bien compris, il s’agit d’un synonyme pour le nom du fournisseur, relativement à une réservation et dont la valeur est définie par l’utilisateur. Ainsi, dans le cas de la réservation <r1>, le fournisseur <123 Test Virginie> identifié par <f1> a pour synonyme <1>, tandis que dans le cas de la réservation <r2>, le fournisseur <123 Test Virginie> (toujours identifié par <f1>) aurait par exemple pour synonyme <5> :

Vous avez bien compris !

Mais, selon votre MLD actuel, la paire {IdReservation, IdFournisseur} n’est pas clé candidate, donc faites en sorte qu’il en soit ainsi.
A défaut, on pourrait très bien se retrouver avec les triplets <r1, f1, 1> et <r1, f1, 2>.

Symétrie oblige, la paire {IdReservation, NumFournisseur} doit aussi être clé candidate, sinon on pourrait avoir des triplets du genre :
<r1, f2, 2> et <r1, f4, 2>.

J’avoue : j’ai du mal à suivre ….
Utilisant un id_fourniture_services, je suis à priori capable d’identifier chaque triplet. L’utilisation d’un id_fourniture_services remplace la paire {IdReservation, IdFournisseur}. Cet id_fourniture_services est utilisé dans la table Prestation comme clé étrangère.

C’est vrai, j’utilise aussi le numFournisseur dans la table Prestation. Cette notion de numFournisseur n’a de raison d’être que pour des raisons d’affichage. Derrière, toutes requêtes associées à l’application utilise l’id_fourniture_services. En regardant mon code pour me rappeler, j’ai fait cela il y a un an, finalement, j’ai mis en place un système qui jongle entre l’id_fourniture_services et le num_Fournisseur. Il y a équivalence. L’utilisateur raisonne et utilise les num_Fournisseur, l’application gère elle des id_fourniture_services.

Je stocke dans la table prestation le num_fournisseur parce que lorsque je génère le tableau, je ne fais que lire les données de cette table. Cela permet simplement de construire le tableau des prestations.
Oups ! Je allais poursuivre mon explication et souhaitais conclure fièrement par: le système fonctionne parfaitement, mais je viens de m’apercevoir d’un bug ….

En relisant pour la xième fois les commentaires de Mr Fsmrel, je me suis dit, ai-je de mauvais triplets ? Je viens de m’apercevoir en consultant la table fourniture_services d’une erreur. J’ai en trouvé au moins un.


Zut alors ! Je vais devoir me replonger dans le code … Le problème vient-il d’un oubli (type mauvaise gestion des mises à jour, oubli d’un cas) ou vient-il d’une erreur purement base de données (mauvaise conception) ?
Comme quoi, <r1, f1, 1> et <r1, f1, 2> m’a permis de m’apercevoir d’un bug.

Une chose est sûre, si je peux conserver cette id_fourniture_services, cela m’arrangerait. J’ai passé un nombre d’heure incalculable côté développement applicatif. Si je dois tout revoir ….

[JPhi33]

Bonjour Tavar,

J’ai retenu cette technique en m’inspirant d’une application qui tourne depuis de très nombreuses années chez le numéro 1 de la distribution d’électroménager (en autre). Technique qui a fait ses preuves avec quelques dizaines de millier d’utilisateurs de tous profils.

Ce n'est pas un critère ! J'ai déjà vu plusieurs progiciels "qui tournent depuis des années" ou "qui font référence dans tel domaine" ou "utilisés par le numéro 1 de ceci ou de cela" mettre en oeuvre des techniques qui relèvent plus de la bidouille que de la solution cohérente et réfléchie. Et comme "c'est utilisé par des milliers d'utilisateurs" et que "ça a toujours bien fonctionné comme ça", personne ne les remet en cause.

Concernant cette technique en particulier, le bon critère à prendre en compte est que cela convienne à tes utilisateurs. Apparemment, c'est le cas mais ont-ils eu le choix ? Pour aller au bout de démarche il faudrait leur proposer l'autre technique, qu'ils la testent pendant quelques temps puis qu'ils prennent leur décision.