Discussion :

[junux]

Bonjour, après de multiples migraines a essayé de modéliser mon projet, je vous montre ce que j'ai fait.

Je me pose bien trop de questions, et quand je regarde mon projet, je suis dubitatif.

En effet ça a l'air brouillon. Je sollicite votre aide pour me mettre dans le bon chemin car je m'y perd un peu.

Le but étant de gérer mes opérations en bourse. Sur cette partie n'apparait qu'une seule partie du projet.
Cette partie me permettra de dégager un certains nombres de paramètres et de faire des statistiques.

Merci de votre aide.

[fsmrel]

Bonsoir junux,


Il faudrait que vous précisiez le sens des mots : par exemple, TRADE a plus d’une traduction en français. Qu’entendez-vous par « sous-jacent » ? Nous ne sommes pas tous censés être au fait des affaires boursières...


Cela dit, d’un point de vue technique de modélisation, il est incongru de faire figurer des cardinalités 1,1 dans des relations à plus de deux pattes (l’éminent et indulgent Yves Tabourier usa d’un euphémisme : « Manque d’intérêt » (De l’autre côté de Merise, page 88). Ainsi, une occurrence T1 de l’entité-type TRANSACTION participe une et une seule fois à l’association PORTE_SUR, en conséquence de quoi T1 fait référence à une seule occurrence D1 de l’entité-type TRADE. De la même façon, cette occurrence D1 de l’entité-type TRADE participe une et une seule fois à l’association PORTE_SUR, elle fait donc référence à une seule occurrence T2 de l’entité-type TRANSACTION : si T1 = T2, y aurait- comme une bijection, sinon un cycle : T1 fait alors référence à T2 qui fait référence à Tn qui fait référence à Ti (1 ≤ i ≤ n) ... Et qui plus est, via l’association FAIT_L’OBJET, T1 fait référence à une et une seule occurrence de TRADE (laquelle ? )

Autrement dit, pour qu’on y voie clair, il faudrait que vous racontiez la vie d’une transaction, en suivant la recommandation de Nicolas Boileau : « Ce qui se conçoit bien... »

[junux]

Bonsoir fsmrel,

Effectivement en relisant mon message d'hier, il manque quelque peu d'informations. Lorsque l'on ai absorbé dans son projet et ses idées, tout est clair dans sa tête. Malheureusement vous n'êtes pas dans ma tête !! Je vais donc essayer d'être plus clair.

Sous jacent exemples : total, vivendi, eur/usd, cac40, or, argent,...... sont les entités unitaire sur lesquelles portent chaque trade. Font eux même partie d'une seule et unique catégorie Actions/Devises/Matières premières....
Sur un même sous jacent, on lui applique des frais commission à chaque transactions effective. Ces commissions peuvent évoluer dans le temps (ex commission de 1% sur la transaction de l'achat de 40 actions Total à la date x, si à une date ultérieure ces frais changent alors je doit pouvoir les mettre à jour sans affecter les résultats des calculs des transactions antérieure), de plus tout les sous jacent ne possèdent pas forcément de commissions.
Le taux de conversion sert à convertir les montants des transactions qui ne sont pas libellée en euro. De la même façon que pour les commissions, ce taux est variable dans le temps, différent selon la devise de référence de la transaction et doit être historisé pour ne pas affecter les calculs des dates antérieures.
Les frais de financements se comportent sensiblement de la même façon (nécessité là aussi d'historisé) que les deux précédents. Ils se calculent une fois par jour sur chacune des transactions ouverte, sont différentes selon le sens de la transaction initiale, et sont aussi différents (pour faire simple) du sous jacent traité.

Je commence à l'envers mais je trouve que c'est mieux pour expliquer la suite.

Pour moi un trade se défini par l'ensemble des transactions sur un sous jacent permettant de déboucler le trade. Je ne sais pas si c'est très clair !!
Un trade devra posséder un statut : en attente/en cours/clôturé/annulé.
Chaque trade initié (donc en cours et clôturé) fait l'objet d'au moins 2 transactions, mais peu faire l'objet de plus de 2 transactions (en effet j'entre en position en achetant 20 actions total (1 transaction) je sort de position en vendant ces même 20 actions total (seconde transaction) mais l'entrée en position peut se faire de manière fractionnée, tout comme la sortie).

Pour qu'une transaction se fasse il faut nécessairement un ticket d'ordre. Donc chaque transactions donnent lieu à un ordre, mais un ordre peut être associer à plusieurs transactions. Et un ordre peut avoir un ordre lié.

Un exemple pour essayer de synthétiser tout ça, car je conçoit que c'est loin d'être simple à comprendre. Toute cette gestion je peut la faire dans un tableur mais ça deviens vite infernal pour extraire de façon simple et rapide chaque les informations dont j'ai besoin pour assurer de manière efficiente la gestion de l'ensemble de mes positions et opérations.

exemple
Trade n°20140320xxxx12//Sens=Achat
20.03.2014 18:26:25 ACHAT//Ordre n°1234//Transaction n°abcd//Action Apple//Qté=200//Cours=90 $//Stop=85 $//Take Profit=100 $//Taux conversion=0.73//Valeur=(200*90*0.73) €//Commission=0.02$ par actions minimum 10$==7,3 €
20.03.2014 19:00:00 MODIF de l'ordre n°1234 : suppression du take profit//raison: ajustement de la stratégie
20.03.2014 19:00:51 VENTE 01 "en attente"//Ordre n°2345//Qté=67//Cours=95 $
20.03.2014 19:02:10 VENTE*02 "en attente"//Ordre n°3456//Qté=67//Cours=100 $
20.03.2014 19:02:46 VENTE*03 "en attente"//Ordre n°4567//Qté=66//Cours=110 $
20.03.2014 19:44:09 VENTE*01//Ordre n°2345//Ordre lié n°1234//Transaction n°bcde//Qté=67//Cours=95 $//Taux conversion=0.74//Valeur=(67*95*0.74) €//Montant=+308.2 €+247,90 €//Solde=(précédent solde + 308.2247,90) €//Commission (même principe ci-dessus)==7,4 €
20.03.2014 20:06:15 VENTE*02//Ordre n°3456//Ordre lié n°1234//Transaction n°cdef//Qté=67//Cours=100 $//Taux conversion=0.735//Valeur=(67*100*0.735) €//Montant=+522.6 €+492,45 €//Solde=(précédent solde + 522.6492,45) €//(même principe ci-dessus)==7,35 €
20.03.2014 22:07:47 Frais de financement//Ordre n°1234//Qté=200-67-67=66//Taux financement=2.34%//Taux conversion=0.727//Montant financement=0.28 €
21.03.2014 07:17:33 VENTE Stop touché//Ordre n°1234//Transaction n°defg//Qté=66//Cours=85 $//Taux conversion=0.728//Valeur=(66*85*0.728) €//Montant=-252.12 €-240,24//Solde=(précédent solde - 252.12240,24) €//(même principe ci-dessus)==7,28 €
21.03.2014 07:51:44 Ordre n°4567 Annulé

Trade cloturé
Total frais financement = 0,28 €
Total commissions = 29,33 €
Gain/Perte = 578,68 € 500,11
Gain/Perte nette = 549,07 € 470,50

Exemple totalement fictif, j'ai essayer d'y représenter un peu tous les cas de figures, j'espère avoir été un peu plus clair.

Pour ce qui est des cardinalités je vais regarder ce qui cloche. Je relis le livre Parlez vous Merise également afin de mieux structurer mon projet.

Cordialement.

[fsmrel]

Bonsoir junux,


Merci pour l’exemple, mais je n’interprète pas tout avec certitude...

Avant qu’on refasse le MCD, pourriez-vous déjà remplacer les « ? » ci-dessous par les noms d’entités-types / attributs de votre MCD ?







Pour les ordres liés, on passera par une association réflexive (dépourvue d'attributs identifiants) :

La mise entre parenthèses de la cardinalité 1,1 signifie que l’entité-type LIAISON hérite de l’identifiant de l’entité-type ORDRE. Au niveau table, on trouvera la paire d’attributs {OrdreId, OrdreLiéId} :

Code :

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

1
2
3
4
OrdreId    OrdreLiéId

2345       1234
3456       1234

[junux]

Bonjour,

En premier lieu merci pour votre aide, vos corrections et le temps passé à mon projet. J'ai apporter des modifications et des précisions à votre tableau.

Finalement ça m'a aidé pour me rendre compte qu'il manquais des informations, par contre cela m'a mené à me poser d'autres questions !

tableau mcd.ods

Pensez vous que la modélisation résultante pourra être «gérer» via la base de libreoffice, avec des récupérations de données dans le module calc afin de les traité, les triturer en graphes, camembert et j'en passe...

Bonne lecture de votre tableau annoté, je continu dans mon coin également.

ajout de précisions :

une transaction est la résultante d'un ordre exécuté, soit mais un ordre exécuté une fois peut l'être une seconde fois. En effet l'ordre est posé, soit il est exécuté immédiatement soit il est en attente, puis en lui renseignant le stop loss ou le take profit (soit au départ ou modifié ultérieurement) il peut donc être exécuté une seconde fois (donnant donc lieu a se moment là à une nouvelle transaction). Admettons également qu'un ordre soit exécuté sans ses stop et objectif, il peut être clôturé.

Cordialement

[fsmrel]

Bonsoir junux,



Pour les exemples, je conserve ID TRADE = "20140320xxxx12", mais ensuite on utilisera des valeurs non significatives.

Je complète le tableau, en reprenant le plus systématiquement possible le nom de chaque colonne de chaque table (comme en SQL).



J’observe que pour une paire {REF_ORDRE, DATE_HEURE_ORDRE} de l’entité-type ORDRE, il y a au plus une valeur pour l’attribut REF_TRANSACTION de l’entité-type TRANSACTION (l’ordre 1234 fait l’objet des transactions "abcd" (achat) et "defg" (vente) à des moments évidemment différents...) Confirmez-vous ?

Votre association PORTE_SUR semble signifier qu’un trade porte sur un seul sous-jacent, qu’une transaction porte sur un seul sous-jacent et qu’un ordre porte sur un seul sous-jacent (comme semble en témoigner votre exemple). Confirmez-vous ?

Sur un même sous-jacent, on lui applique des frais commission à chaque transactions effective. Ces commissions peuvent évoluer dans le temps (ex commission de 1% sur la transaction de l'achat de 40 actions Total à la date x

Vous prenez comme exemple un taux de 1%. Où se situe le taux dans votre MCD ? S’agit-il de l’attribut MONTANT COMMISSION de l’entité-type COMMISSION (ce que semble signifier votre exemple à propos de cet attribut : 200*0.02).

Les frais de financements [...] se calculent une fois par jour sur chacune des transactions ouvertes, sont différentes selon le sens de la transaction initiale

Vous utilisez le féminin « sont différentes », mais je suppose que ce sont les frais de financement qui « sont différents ». Quand vous parlez du sens de la transaction initiale, peut-on supposer que vous parlez du sens de l’ordre (achat ou vente) ? Qu’on utilise —selon le sens de l'ordre— des taux différents pour l’ordre concerné (ordre 1234 lié à l’ordre (vente) 3456 dans l’exemple) ?

et sont aussi différents (pour faire simple) du sous jacent traité.

C'est-à-dire ?


Vous posez la question : « ajouter un statut de l'ordre ? » Ça pourrait s’avérer utile. Disons que, pour le moment, « pourquoi pas ? »


Vous posez la question : « Faut-il une table SOLDE ? »

Il s’agit d’une donnée calculée, donc pas de redondance, donc normalement pas de table SOLDE.


Concernant l’historisation, il est préférable qu’on s’y plonge quand le reste sera stabilisé...

[junux]

Bonjour François,

Avant de répondre le plus précisément possible, je m'en occupe dans la journée, serait il possible de travailler sur le même fichier de tableur ?

Merci.

Julien

[fsmrel]

Bonjour Julien,


Je fais un essai à la sauce DVP, je n'ai pas fait ça depuis des années...


junux_transactions.xls


Si ça ne marche pas, je ferai autrement...

[junux]

tableau mcdV2.ods

Je viens de finir les modifications sur mon fichier précédent !!

DVP c'est quoi ?

Je poursuit, pour répondre à vos questions.

[junux]

J’observe que pour une paire {REF_ORDRE, DATE_HEURE_ORDRE} de l’entité-type ORDRE, il y a au plus une valeur pour l’attribut REF_TRANSACTION de l’entité-type TRANSACTION (l’ordre 1234 fait l’objet des transactions "abcd" (achat) et "defg" (vente) à des moments évidemment différents...) Confirmez-vous ?

Oui c'est bien cela 1 TRANSACTION = 1 ORDRE*mini et maxi
alors que 1 ORDRE = 0, 1 ou 2 TRANSACTION

Votre association PORTE_SUR semble signifier qu’un trade porte sur un seul sous-jacent, qu’une transaction porte sur un seul sous-jacent et qu’un ordre porte sur un seul sous-jacent (comme semble en témoigner votre exemple). Confirmez-vous ?

Oui également

Vous prenez comme exemple un taux de 1%. Où se situe le taux dans votre MCD ? S’agit-il de l’attribut MONTANT COMMISSION de l’entité-type COMMISSION (ce que semble signifier votre exemple à propos de cet attribut : 200*0.02).

L'exemple du taux de 1% est mal choisi au vu du montant 0,02 pour 200 unités. Ce que j'ai voulu dire, c'est que MONTANT*COMMISSION*de l'entité COMMISSION*peut être un % du montant de la transaction ou bien peut être comme le 0,02 $ choisi un montant de commission par nombre de quantité de la transaction. En l'occurrence "coute" 0,02 $ (quotité) * 200 (unités, quantité) soit 4 $.

Vous utilisez le féminin « sont différentes », mais je suppose que ce sont les frais de financement qui « sont différents ». Quand vous parlez du sens de la transaction initiale, peut-on supposer que vous parlez du sens de l’ordre (achat ou vente) ? Qu’on utilise —selon le sens de l'ordre— des taux différents pour l’ordre concerné (ordre 1234 lié à l’ordre (vente) 3456 dans l’exemple) ?

Oui mauvaise relecture du post désolé.
Oui encore une fois. L'ordre 1234 exécuté au tout début possède un taux 1 car l'ordre est passé à l'achat, il possèderai un taux 2 s'il avait été passé à la vente.
De plus ces mêmes taux diffèrent selon la CATEGORIE*PRODUIT*du SOUS JACENT.

Julien

[fsmrel]

DVP est l'acronyme de Developpez.net le site qui héberge nos discussions...

[fsmrel]

Bonjour Julien,


En passant :

J’observe que pour une paire {REF_ORDRE, DATE_HEURE_ORDRE} de l’entité-type ORDRE, il y a au plus une valeur pour l’attribut REF_TRANSACTION de
l’entité-type TRANSACTION (l’ordre 1234 fait l’objet des transactions "abcd" (achat) et "defg" (vente) à des moments évidemment différents...) Confirmez-vous ?

Oui c'est bien cela 1 TRANSACTION = 1 ORDRE*mini et maxi
alors que 1 ORDRE = 0, 1 ou 2 TRANSACTION

Le sens de ma question est plutôt celui-ci : pour un ordre O1 horodaté (aaaa_mm-jj hh:mm:ss) à T1, peut-on passer deux transactions distinctes ? (je ne le pense pas, mais je préfère avoir confirmation).


Selon votre MCD, à une date donnée (donc compte non tenu de l’historisation), un sous-jacent fait l’objet d’au plus une seule commission. Confirmez-vous ?


Une commission est-elle la propriété d’un sous-jacent (autrement dit, une commission fait-elle référence à un seul sous-jacent), ou bien l’entité-type COMMISSION représente-t-elle un référentiel de valeurs, utilisé pour l’ensemble des sous-jacents ?

Vous prenez comme exemple un taux de 1%. Où se situe le taux dans votre MCD ? S’agit-il de l’attribut MONTANT COMMISSION de l’entité-type COMMISSION (ce que semble signifier votre exemple à propos de cet attribut : 200*0.02).

Ce que j'ai voulu dire, c'est que MONTANT*COMMISSION*de l'entité COMMISSION*peut être un % du montant de la transaction ou bien peut être comme le 0,02 $ choisi un montant de commission par nombre de quantité de la transaction. En l'occurrence "coûte" 0,02 $ (quotité) * 200 (unités, quantité) soit 4 $.

Etant donné qu’une commission est représentée sous forme de pourcentage ou de montant, on pourrait spécialiser l’entité-type COMMISSION (Le montant de la commission et le montant mini s’expriment selon une devise) :



Version tabulaire

Code :

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

1
2
3
4
5
6
DEVISE 
DeviseId    DeviseNom
       1    Roupie
       2    Livre libanaise
       3    Dollar US
     ...    ...

Code :

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

1
2
3
4
5
COMMISSION
CommissionId    CommissionMini    DeviseId    
           1                10           3
           2                15           1
         ...               ...

Code :

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

1
2
3
4
COMMISSION_QUOTITE
CommissionId    CommissionMontant
           1                 0,02
         ...                  ...

Code :

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

1
2
3
4
COMMISSION_TAUX 
CommissionId    CommissionTaux
           2               0,1
         ...               ...

(Dans le cas de la commission CommissionId = 1, le montant de la commission (CommissionMontant) et celui de la commission mini (CommissionMini) s’expriment dans la même devise.)

[junux]

Le sens de ma question est plutôt celui-ci : pour un ordre O1 horodaté (aaaa_mm-jj hh:mm:ss) à T1, peut-on passer deux transactions distinctes ? (je ne le pense pas, mais je préfère avoir confirmation).

Non vous avez raison.
Précisions, je m'en suis aperçu tout à l'heure :
une transaction + un ordre lié donne lieu à un calcul de PV/MV et un calcul du solde
un ordre modifié ne donne lieu à aucun calcul
un ordre touché par une de ses branches active (le stoploss ou le takeprofit) n'a par définition pas d'ordre lié, mais donne lieu aux deux calculs précités.
du reste cela me fait penser pourquoi ne pas spécialiser avec une condition comme pour l'entité COMMISSION ?

Selon votre MCD, à une date donnée (donc compte non tenu de l’historisation), un sous-jacent fait l’objet d’au plus une seule commission. Confirmez-vous ?

oui c'est cela.

Une commission est-elle la propriété d’un sous-jacent (autrement dit, une commission fait-elle référence à un seul sous-jacent), ou bien l’entité-type COMMISSION représente-t-elle un référentiel de valeurs, utilisé pour l’ensemble des sous-jacents ?

Pour la spécialisation de l'entité COMMISSION*c'est une bonne idée. C'est une sorte de condition OU exclusif ?

[fsmrel]

Pour la spécialisation de l'entité COMMISSION*c'est une bonne idée. C'est une sorte de condition OU exclusif ?

De fait, dans la partie de MCD que j’ai présentée, l’exclusion est symbolisée par la lettre « X » inscrite dans la demi-lune symbolisant elle-même l’héritage. L’AGL utilisé ici est PowerAMC. Outre l’exclusion, la totalité (une commission appartient forcément à une des deux catégories) est symbolisée par le soulignement de la demi-lune (il aurait été préférable que soit utilisée la lettre « T », mais on fera sans...)

Cela dit, je repose ma question :

« Une commission est-elle la propriété d’un sous-jacent (autrement dit, une commission fait-elle référence à un seul sous-jacent), ou bien l’entité-type COMMISSION représente-t-elle un référentiel de valeurs, utilisé pour l’ensemble des sous-jacents ? »

Sémantiquement parlant je pencherais de mon côté pour qu’une commission appartienne à un sous-jacent, et du point de vue de la performance de la base de données aussi, mais peut-être avez-vous des arguments à opposer ?

une transaction + un ordre lié donne lieu à un calcul de PV/MV et un calcul du solde
un ordre modifié ne donne lieu à aucun calcul
un ordre touché par une de ses branches active (le stoploss ou le takeprofit) n'a par définition pas d'ordre lié, mais donne lieu aux deux calculs précités.
du reste cela me fait penser pourquoi ne pas spécialiser avec une condition comme pour l'entité COMMISSION ?

Dans la mesure où seuls certains types d’ordre font l’objet des calculs, et que la spécialisation apporte vraiment quelque chose, on peut y réfléchir. Quels « plus » vous apporterait objectivement la spécialisation ?

[fsmrel]

J'ai oublié un point important : quelles valeurs peut prendre le type de la transaction (entité-type TRANSACTION) ? "achat" et "vente" (et pas autre chose)) ?

Comment détermine-t-on la devise du cours lors de l’achat des 200 actions Apple ? A partir du sous-jacent ? de la transaction d'achat ? Autrement ?

Je suppose que la devise du stop loss et celle du take profit sont celles du cours, qu’en est-il ?

Je suppose que la devise de la commission et celle du mini commission sont celles du cours, qu’en est-il ?

La valeur du frais de financement (2,34% dans l’exemple) est-il strictement dépendant de l’ordre ? du sous-jacent ? d’autre chose ?

[junux]

Bonjour François,

Vous parlez de PowerAMC, je ne sais pas s'il existe une version Mac de ce logiciel, j'utilise JMerise.
Après recherche dans le livre Parlez vous Merise, je n'ai pas vu mention de la contrainte T, mais j'ai peut être mal regardé, par contre dans JMerise elle existe.

De fait, dans la partie de MCD que j’ai présentée, l’exclusion est symbolisée par la lettre « X » inscrite dans la demi-lune symbolisant elle-même l’héritage. L’AGL utilisé ici est PowerAMC. Outre l’exclusion, la totalité (une commission appartient forcément à une des deux catégories) est symbolisée par le soulignement de la demi-lune (il aurait été préférable que soit utilisée la lettre « T », mais on fera sans...)

« Une commission est-elle la propriété d’un sous-jacent (autrement dit, une commission fait-elle référence à un seul sous-jacent), ou bien l’entité-type COMMISSION représente-t-elle un référentiel de valeurs, utilisé pour l’ensemble des sous-jacents ? »

Effectivement la commission est une propriété d'un sous jacent, dans le détail la commission est propriété des sous jacent (chacune différentes) mais que sur les Catégorie Produit "actions".

Dans la mesure où seuls certains types d’ordre font l’objet des calculs, et que la spécialisation apporte vraiment quelque chose, on peut y réfléchir. Quels « plus » vous apporterait objectivement la spécialisation ?

Disons que je ne sais pas vraiment ce que la spécialisation apporterai dans ce cas précis. Je me suis imaginé que ce serai une contrainte supplémentaire, elle existe vraiment puisque sur un ordre exécuté/non clôturé avec le StopLoss et le TakeProfit renseigné, l'ordre court toujours jusqu'à l'exécution de l'un ou de l'autre.

[junux]

J'ai oublié un point important : quelles valeurs peut prendre le type de la transaction (entité-type TRANSACTION) ? "achat" et "vente" (et pas autre chose)) ?

Alors là je me perd, je ne sais plus trop vraiment ce que je voulais mettre dans cet attribut de l'entité TRANSACTION.
Je retourne à mes schémas et tableau pour y voir plus clair.
Je m'aperçoit aussi que j'ai oublier des éléments essentiels comme la notion de COMPTE, de LIGNEDECOMPTE, de POINTAGE d'opérations mais aussi de marge qui est un ensemble propriétés du sous jacent. J'en oublie certainement d'autres et du coup ça sème la confusion et dans ma réflexion et dans mes réponses à vos questions.

Comment détermine-t-on la devise du cours lors de l’achat des 200 actions Apple ? A partir du sous-jacent ? de la transaction d'achat ? Autrement ?

La devise est une propriété du sous jacent. Ici action apple dollar us, tout est ramené à la fin de chaque ligne de compte à la devise de référence du compte, ici l'euro. D'où la nécessité d'avoir le "taux" de conversion qui est plutôt un coefficient plus q'un taux.

Je suppose que la devise du stop loss et celle du take profit sont celles du cours, qu’en est-il ?

Oui encore, vous supposez bien, c'est en référence de la devise du cours de l'ordre elle même découlant de la propriété du sous jacent.

Je suppose que la devise de la commission et celle du mini commission sont celles du cours, qu’en est-il ?

Également, avec la même remarque que ci dessus.

La valeur du frais de financement (2,34% dans l’exemple) est-il strictement dépendant de l’ordre ? du sous-jacent ? d’autre chose ?

Alors là cela se complique un peu, pour ma petite tête. C'est une "propriété" changeante du sous jacent. Changeante car le taux évolue chaque jour. Mais finalement es ce vraiment une propriété du sous jacent. Je m'explique. Dépendent en fait plutôt de la devise du sous jacent et de la catégorie du produit. Un exemple pour illustrer.

Une action exprimée en euro possède le même taux qu'un indice exprimé en euro.
Une action exprimé en roupi possède le même taux qu'un indice exprimé en roupi.....

Ceci dit il n'y a pas qu'un seul taux de financement par couple catégorie produit, devise sous jacent mais deux taux. Un taux à la vente, et un taux à l'achat. C'est donc pour ça que cela dépend également du sens de l'ordre encore ouvert chaque fin de journée. Et qui permet donc son calcul.



Plus j'avance et plus j'ai le sentiment de reculer et je m'y perd un peu (beaucoup).
Je m'étais imaginé que ce serai plus ou moins facile à mettre en oeuvre au même titre qu'un tableau dans un tableur mais il n'en ai rien.

Merci pour toutes vos réflexions et le temps passé pour m'aider à y voir plus clair. Je ne lâche pas l'affaire...

Julien

[junux]

Es ce la bonne représentation pour la question de la spécialisation des commissions ?

Pour ce qui es des ordres liés, pas encore tout saisi surtout au niveau de la cardinalité relative (1,1).

Mais je me soigne et cherche encore.

En passant la lecture, relecture et re relecture du tuto initiation Merise de ce site m'apporte finalement plus que la lecture du livre !!

[fsmrel]

Bonsoir Julien,

Vous parlez de PowerAMC, je ne sais pas s'il existe une version Mac de ce logiciel, j'utilise JMerise.

Je ne sais pas s’il existe une version MAC d’AMC, mais vous pouvez toujours consulter les tarifs . Pour faire des MCD il faut au moins PowerAMC Données Basic avec référentiel, sinon avec PowerAMC Données Basic, on en reste au niveau MLD (autant utiliser MySQL Workbench (gratuit) ^^

Après recherche dans le livre Parlez-vous Merise, je n'ai pas vu mention de la contrainte T, mais j'ai peut être mal regardé, par contre dans JMerise elle existe.

Michel Diviné a écrit son ouvrage il y a 25 ans, et à l’époque il utilisait de façon équivalente le « ou inclusif », symbolisé par la lettre « V », voyez le cas de Madame Fourmi) (page 64).

Effectivement la commission est une propriété d'un sous-jacent, dans le détail la commission est propriété des sous-jacent (chacune différentes) mais que sur les Catégorie Produit "actions".

Si les commissions ne s’appliquent qu’aux actions, on peut représenter cela ainsi :

Je me suis imaginé que ce serai une contrainte supplémentaire, elle existe vraiment puisque sur un ordre exécuté/non clôturé avec le StopLoss et le TakeProfit renseigné, l'ordre court toujours jusqu'à l'exécution de l'un ou de l'autre.

Il faudra qu’on on reparle et qu’on creuse, mais pour le moment je ne suis pas convaincu. N'oublions pas que la spécialisation concerne des objets qui ne mutent pas, à l'image des actions qui ne sont pas des monnaies ou des pourcentages qui ne sont pas des montants.

[fsmrel]

Suite du feuilleton

Une action exprimée en euro possède le même taux qu'un indice exprimé en euro.
Une action exprimée en roupi possède le même taux qu'un indice exprimé en roupi.....

Voilà un concept, l’indice, qui prend naissance : appartient-il au modèle ? Comment le décrire ?

Pour ce qui est des ordres liés, pas encore tout saisi surtout au niveau de la cardinalité relative (1,1).

Illustrons par l’exemple. Reprenons les données Excel :

Code :

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

1
2
3
4
5
6
7
8
9
ORDRE
OrdreId    OrdreDateHeure          OrdreRef    OrdreQuantite
      1    20/03/2014  18:26:25    1234                  200
      2    20/03/2014  19:00:00    1234                     
      3    20/03/2014  19:00:51    2345                   67
      4    20/03/2014  19:02:10    3456                   67
      5    20/03/2014  19:02:46    4567                   66
      6    20/03/2014  19:44:09    2345                   67
      7    20/03/2014  20:06:15    3456                   67

Du fait de l’identification relative, au stade MLD, la clé primaire {OrdreId} de la table LIAISON hérite automatiquement de la clé primaire {OrdreId} de la table ORDRE (elle est aussi clé étrangère pour des raisons d’intégrité référentielle, avec en plus une clé étrangère {OrdreLié} faisant référence à l’ordre lié) :

Code :

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

1
2
3
4
LIAISON 
OrdreId    OrdreLié
      6           1
      7           1

Pour aller un peu plus loin :

Vous noterez en passant que les ordres d’OrdreId 3 et 5, ont la même valeur (67) pour l’attribut OrdreQantite (même remarque pour les ordres 4 et 6) : en fait il y a redondance, donc sus à l’ennemi : si on veut éviter les incohérences sur les quantités lors des mises à jour, on supprimera l’attribut OrdreQantite de la tale ORDRE, et en échange on mettra en œuvre une table ORDRE_QUANTITE, d’où la représentation tabulaire :

Table ORDRE_QUANTITE

Code :

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

1
2
3
4
5
6
OrdreId    OrdreQuantite
      1              200
      3               67
      4               67
      5               66

L’ordre 3 est absent de la table ORDRE_QUANTITE : normal, il n’apporte pas d’information sur la quantité. Dans le cas des ordres 6 et 7, on retrouve la quantité en faisant référence aux ordres qui sont à l’origine de l’information, à savoir les ordres 3 et 4. La mise en œuvre d’une table ORDRE_REF_QTE permet de créer le lien :

Table ORDRE_REF_QTE

Code :

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

1
2
3
4
 
OrdreId    OrdreParent
      6              3
      7              4

Eventuellement, cette table peut être absorbée par la table LIAISON, mais il faut voir s’il n’y a pas des contre-indications à procéder ainsi :

Table LIAISON

Code :

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

1
2
3
4
 
OrdreId    OrdreParent    OrdreLié     
      6              3           1
      7              4           1

Par ailleurs, les ordres ne font pas tous l’objet d’un stop loss ou d’un take profit, on peut donc sortir les attributs correspondants de la table ORDRE et les héberger dans des tables ad-hoc :

Table STOP_LOSS

Code :

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

1
2
3
4
OrdreId    StopLossValeur    StopLossStatut
      1                85    OK
      3                 0    fini

Table TAKE_PROFIT

Code :

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

1
2
3
4
OrdreId    TakeProfitValeur    TakeProfitStatut
      1                 100    OK
      2                   0    fini

Je ne préjuge pas ici des contraintes en relation avec le statut de l’ordre et autres, on verra ça par la suite, je ne cherche pour le moment qu’à évacuer la redondance, à normaliser comme je l’écris ici...



[QUOTE=junux;7759593 Est-ce la bonne représentation pour la question de la spécialisation des commissions ? [/Quote]
Oui, mais compte-tenu de vos réponses (posts #16 et #17), l’entité-type COMMISSION n’est pas directement en relation avec l’entité-type DEVISE, puisqu’une commission fait référence à un et un seul sous-jacent, lequel fait référence à une et une seule devise.

Par ailleurs, on étoffera ça quand on traitera de l’historisation, dans la mesure où dans le temps les montants et les taux des commissions peuvent évoluer.

Je ne lâche pas l'affaire...

Il ne manquerait plus que ça ! On y arrivera, le tout est de bien mettre les concepts à plat, et ne pas se précipiter et mal placer les pièces du puzzle...


N.B. Vous pouvez constater que l’entité-type ORDRE est disloquée, ventilée façon puzzle... Pas de panique, grâce à une vue (table virtuelle), on reconstitue sans problème le tableau EXCEL.