Discussion :

[nuriel2]

Hello,

Je souhaite avoir des avis/remarques/conseils afin d'optimiser une BDD que je monte. Elle se decoupe en 2 parties, ayant chacune les contraintes suivantes:

Gestion des clients
---------------------

Situee a gauche du modele, ces relations visent a enregistrer toutes les informations importantes sur des societes clientes (company) et les contacts qui y travaillent (Customer). Ces tables servent surtout aux utilisateurs, qui lisent et completent les informations. Les contraintes sont:
- Une compagnie appartient a 0 ou 1 Group (GlobalCompany), et a autant de compte qu'elle le desire (Account)
- Une compagnie a 0 ou 1 Customer, mais 1 customer ne travaille que pour une unique compagnie.

Calcul Commission
-------------------

Sur la partie droite du schema, il vise a calculer a posteriori les commissions generees sur les differents comptes. La plupart des tables ne font que recevoir des informations, mais la table commission servira a des calculs sur des champs provenant des tables TradeXXX. Elle sera videe plusieurs fois par jours/mois pour recalculer l'ensemble des Com. Les contraintes sont:
- Chaque ligne de TradeDetails n'aura qu'une seule ligne de com. Cette table contient 95% des infos necessaires pour faire les calculs.
- J'ai souvent besoin de convertir les sommes engagees (Tables Rate)
- Il devrait y avoir une liaison directe entre Cost et TradeDetails, mais cela alourdirait le schema.

Ceci est un exercice que je m'impose pour mieux comprendre les BDD (pour le coup, je decouvre MERISE) et est, dans son expression des besoins, une replique d'un systeme que j'ai aide a developper pendant un stage sous VBA-Access. Merci d'avance a ceux qui critiqueront ce modele.

[Mathusalem]

En jettant un oeil, 2 choses qui m'intriguent :
- pas d'historisation des currency (c'est pas souvent mais ça arrive : typiquement un passage à l'Euro)
- pas d'exécution d'ordres : tu ne t'intéresses qu'au Back / Middle Office (les cross, la facilitation, ...) ?
- pourquoi ne pas fusionner la table Trader et la table Trade_details ?
- je ne vois pas où sont les stocks (place de cotation, monnaie, codes reuters/isin/Bloom/... qui sont tous à historiser, etc.)



edit : je ne sais pas compter

[nuriel2]

En jettant un oeil, 2 choses qui m'intriguent :
- pas d'historisation des currency (c'est pas souvent mais ça arrive : typiquement un passage à l'Euro)
- pas d'exécution d'ordres : tu ne t'intéresses qu'au Back / Middle Office (les cross, la facilitation, ...) ?
- pourquoi ne pas fusionner la table Trader et la table Trade_details ?
- je ne vois pas où sont les stocks (place de cotation, monnaie, codes reuters/isin/Bloom/... qui sont tous à historiser, etc.)

Merci de cette reponse, je n'en esperais plus.

- Pas d'historisation des currency: en effet, le besoin ne s'est jamais fait sentir. Pour etre clair, tu proposes que je rentre la periode de validite dans la table Currency ?

- Pas d'execution d'ordres: du moins, pas encore. Mon objectif est pour l'instant de gerer les informations APRES que l'ordre ait ete donne et execute. Ces informations me reviennent sous la forme d'un fichier texte qui sert a alimenter les tables TradeXXX

- pourquoi ne pas fusionner la table Trader et la table Trade_details ?: un trade peut etre annule, puis remplace, ce qui correspond a 3 trades dans mon fichier (avec des flags actives pour signaler qu'ils annulent ou remplacent un trade precedent). Les trois trades auront alors le meme debut de reference, mais l'annulation et le remplacant auront des caracteres en plus. Ai je bien fait de separe les 2 tables du coup ?

- je ne vois pas où sont les stocks : j'y arrive tres bientot.

Merci pour ces quelques remarques

[Mathusalem]

- Pas d'historisation des currency: en effet, le besoin ne s'est jamais fait sentir. Pour etre clair, tu proposes que je rentre la periode de validite dans la table Currency ?

chez nous, il y a une date début et une date fin (à NULL si toujours valide)

- Pas d'execution d'ordres: du moins, pas encore. Mon objectif est pour l'instant de gerer les informations APRES que l'ordre ait ete donne et execute. Ces informations me reviennent sous la forme d'un fichier texte qui sert a alimenter les tables TradeXXX

Tu es du côté Broker ? Gaffe aux cross quand même : Si deux clients ont des ordres opposés, plutôt que de passer par le marché le broker va les crosser, les comm seront identiques mais lui ne payerait pas les frais d'exécution.

- pourquoi ne pas fusionner la table Trader et la table Trade_details ?: un trade peut etre annule, puis remplace, ce qui correspond a 3 trades dans mon fichier (avec des flags actives pour signaler qu'ils annulent ou remplacent un trade precedent). Les trois trades auront alors le meme debut de reference, mais l'annulation et le remplacant auront des caracteres en plus. Ai je bien fait de separe les 2 tables du coup ?

Si un trade est annulé, tu gardes tout et tu mets un flag annulé.
Une modif du premier trader donne un nouveau trade -> nouvel trade_id

On ne remplace pas une donnée annulée, on la garde au cas où (Les voies de l'AMF sont impénétrables...)

- je ne vois pas où sont les stocks : j'y arrive tres bientot.

Piège aussi, gère ton propre stock_id (on identifie un stock par le titre + la place de cotation) avec un dictionnaire de correspondance avec tous les autres identifiants externes. Typiquement les codes bloom changent sans raison, un jour ça marche plus, tu remontes l'erreur et tu vois que ça vient d'eux.
La semaine dernière, des Codes en "DE" pour l'Allemagne devenu "XE" sans raison chez un de nos providers ne m'a pas fait beaucoup rire non plus.

Merci pour ces quelques remarques

N'hésite pas, je suis à fond la dedans en ce moment

[nuriel2]

chez nous, il y a une date début et une date fin (à NULL si toujours valide)

Bien vu !!!

Tu es du côté Broker ?

OUI, comment as tu devine ? Ceci dit, je debute, et je ne suis pas du tout habitue a leur vocabulaire.

Gaffe aux cross quand même : Si deux clients ont des ordres opposés, plutôt que de passer par le marché le broker va les crosser, les comm seront identiques mais lui ne payerait pas les frais d'exécution.

Je me renseigne des Lundi pour savoir exactement ce que cela veut dire.

Si un trade est annulé, tu gardes tout et tu mets un flag annulé.
Une modif du premier trader donne un nouveau trade -> nouvel trade_id

On ne remplace pas une donnée annulée, on la garde au cas où (Les voies de l'AMF sont impénétrables...)

C'est bien ce que mon maitre de stage m'avait dit a l'epoque. J'ai donc rassemble dans une seule table les informations concernant les trades.

Piège aussi, gère ton propre stock_id (on identifie un stock par le titre + la place de cotation) avec un dictionnaire de correspondance avec tous les autres identifiants externes. Typiquement les codes bloom changent sans raison, un jour ça marche plus, tu remontes l'erreur et tu vois que ça vient d'eux.
La semaine dernière, des Codes en "DE" pour l'Allemagne devenu "XE" sans raison chez un de nos providers ne m'a pas fait beaucoup rire non plus.

Je ne comprend pas pourquoi il faudrait gerer les stocks comme tu le decris: le nom de la stock me revient dans le fichier que je traite. Ce meme fichier contient egalement le code bloom du pays ou la transaction a ete faite. Du coup, je fais une liaison entre le code bloom et le pays (liaison entre Cost et Country, en bas de mon schema). Lorsqu'un code change (cela m'est egalement arrive), j'ajoute une association code bloom - pays dans la table Cost, et le modele reste valide, null besoin d'associer le nom de la stock au pays. Pourrais tu preciser ton idee si tu penses que je fais fausse route.

N'hésite pas, je suis à fond la dedans en ce moment

Ah, en general, c'est exactement ce qu'il faut eviter de dire aux newbies. Mais je te remercie. Question annexe, sur quoi travailles tu , si ce n'est pas trop indiscret ? De mon cote, j'essaie de creer un systeme qui permettra aux brokers de:
- visualiser la liste des clients et des comptes qui leurs sont associes
- calculer les commissions generees a partir du fichier que je suis en train de traiter
- generer les rapports de management base
- envoyer des documents aux clients

[Mathusalem]

Je ne comprend pas pourquoi il faudrait gerer les stocks comme tu le decris: le nom de la stock me revient dans le fichier que je traite. Ce meme fichier contient egalement le code bloom du pays ou la transaction a ete faite. Du coup, je fais une liaison entre le code bloom et le pays (liaison entre Cost et Country, en bas de mon schema). Lorsqu'un code change (cela m'est egalement arrive), j'ajoute une association code bloom - pays dans la table Cost, et le modele reste valide, null besoin d'associer le nom de la stock au pays. Pourrais tu preciser ton idee si tu penses que je fais fausse route.

Attention le pays et la place cotation c'est pas pareil
Exemple : tu peux côter en Suisse sur 2 places (renseigne toi sur VIRTX)
De plus avec la MIFID en Novembre (2007 ) il y aura bientôt des tonnes des places "virtuelles" qui ouvriront, tout partout.
Et puis fixer tes identifiants sur ceux de bloom ou d'un tiers... ça ne me parait pas très prudent.

Ah, en general, c'est exactement ce qu'il faut eviter de dire aux newbies. Mais je te remercie. Question annexe, sur quoi travailles tu , si ce n'est pas trop indiscret ? De mon cote, j'essaie de creer un systeme qui permettra aux brokers de:
- visualiser la liste des clients et des comptes qui leurs sont associes
- calculer les commissions generees a partir du fichier que je suis en train de traiter
- generer les rapports de management base
- envoyer des documents aux clients

J'ai bossé à Exane et maintenant je suis à Cheuvreux (broker de Calyon).
Pour le moment je fais du reporting, du coup je tape dans toutes les bases de manière transverse.