Un modèle de données pour le trading d'actions, de fonds et de crypto-monnaies

Le trading de crypto-monnaies, l'achat d'actions, etc. est extrêmement populaire de nos jours - c'est perçu comme un profit facile. Les prix augmentent actuellement, mais nous ne pouvons pas savoir quand cela va changer. D'un autre côté, nous savons que ce sera le cas à un moment donné. Mais nous ne sommes pas là pour faire des prévisions financières. Au lieu de cela, nous parlerons d'un modèle de données qui peut être utilisé pour soutenir le commerce de crypto-monnaies et d'instruments financiers comme des actions ou des parts de fonds.

Ce que vous devez savoir sur le trading des devises et des actions

Les améliorations technologiques des dernières décennies ont eu un impact significatif sur le commerce. Il existe maintenant de nombreuses plateformes de trading en ligne que vous pouvez utiliser. La plupart des transactions d'aujourd'hui se font virtuellement - vous pouvez voir des stocks de papier dans les musées, mais vous ne verrez probablement pas les stocks que vous achetez sous forme papier. Et vous n'avez pas besoin de faire vos valises et de vous rendre à Wall Street ou à toute autre bourse pour effectuer une transaction. Depuis le confort de votre ordinateur ou de votre appareil mobile, vous pouvez acheter ou vendre des dérivés financiers (tels que des obligations, des actions ou des matières premières).

La plupart des transactions (ventes de dérivés financiers) suivent les mêmes règles. Il y a des vendeurs et des acheteurs. S'ils s'entendent sur un prix, l'échange a lieu. Après la transaction, le prix de ce dérivé financier sera recalculé et le processus se poursuivra avec de nouveaux traders. Les actions et autres dérivés fonctionnent de la même manière.

Qu'est-ce qu'une crypto-monnaie ? Vous avez probablement entendu parler du Bitcoin et d'autres crypto-monnaies. Mais quels sont-ils ? Les crypto-monnaies sont comme des monnaies virtuelles, mais elles ne sont pas liées aux monnaies du monde réel (comme les euros ou les dollars). Au lieu de cela, les utilisateurs peuvent échanger des crypto-monnaies entre eux comme des jetons. Ils peuvent ensuite négocier une vente qui transforme leurs jetons en argent réel. Ces ventes fonctionnent exactement comme les échanges d'actions et d'actions décrits ci-dessus.

Ce sujet est complexe et nous pourrions avoir beaucoup de détails dans notre modèle (par exemple, des enregistrements de documents et de transactions). je vais faire simple; Je n'implémenterai aucun type de trading automatique ni aucune formule pour générer de nouveaux prix après un événement commercial.

Alors, jetons un coup d'œil à ce modèle de trading simple.

Le modèle de données

Le modèle de données se compose de trois domaines :

Currencies
Items
Traders

Nous présenterons chaque domaine dans l'ordre dans lequel il est répertorié.

Devises

Les Currencies domaine est simple. Il contient quatre tables qui stockent toutes les devises que nous utilisons et leurs taux de change. Les devises sont importantes car :

Nous utiliserons une devise, appelée devise de base , pour le commerce. Une plateforme de négociation d'actions en ligne utilisera probablement le dollar américain (USD) comme devise de base, quelles que soient les régions réelles des commerçants. Toutes les transactions seront converties dans la devise de base.
Nous pouvons également avoir des devises non de base ou locales pour tous les pays où notre plateforme de trading est disponible. Cela nous permettrait d'afficher les prix dans la devise locale tout en effectuant des transactions dans la devise de base.

Les deux tableaux restants concernent les devises et les pays.

Le tableau le plus important dans ce domaine est la currency table. C'est là que nous stockerons toutes les devises que nous avons utilisées pour le trading, y compris les crypto-monnaies. Si une devise est incluse dans ce tableau dépend si cette devise sera utilisée pour payer les articles échangés. Pour chaque devise, nous stockerons :

code – Un code utilisé pour désigner UNIQUEMENT cette devise. Pour les devises nationales, il s'agira du code ISO 4217 (par exemple, USD pour le dollar américain) ou d'un autre code officiel. Nous pourrions également utiliser ISO 4217 pour les crypto-monnaies ; XBT est le code ISO de Bitcoin. Cependant, Bitcoin utilise également le code BTC de manière informelle.
name – Le nom UNIQUE de cette devise (par exemple, le dollar des États-Unis).
is_active – Si la devise est actuellement active dans notre système.
is_base – Si cette devise est la devise de base de notre système. Habituellement, nous n'aurons qu'une seule devise de base à la fois. Il est possible que nous en ayons plus d'un, par exemple en utilisant des euros pour les États de l'UE et des dollars américains pour d'autres régions. Dans ce cas, nous avons la possibilité d'attribuer une devise de base à chaque pays avec cet attribut.

Le tableau suivant stocke les taux actuels et historiques entre les paires de devises. Dans le currency_rate table, nous stockerons le currency_id nous voulons comparer à un base_currency_id ainsi que le rate quand cette paire a été stockée (ts ). Étant donné que nous stockerons les taux tels qu'ils étaient à différents moments, ce tableau stockera à la fois les données historiques et actuelles.

Une liste de tous les pays concernés est stockée dans le country dictionnaire. Outre la clé primaire (id ), il contient un attribut contenant un name de pays UNIQUE .

Le dernier tableau de ce domaine est le currency_used table. Dans la plupart des cas, un pays utilisera toujours la même devise. Pourtant, des changements peuvent se produire, comme lorsque de nombreux pays de l'UE ont remplacé leur monnaie nationale par l'euro. Pour couvrir une telle éventualité, nous stockerons un historique de toutes les devises que nous avons utilisées. Pour chaque enregistrement de ce tableau, nous stockerons les références au country tableau (country_id ), la currency tableau (currency_id ), et quand cette devise a été utilisée (date_from et date_to ). Si date_to est NULL, alors cette devise est actuellement utilisée. Bien entendu, une seule devise doit être utilisée par pays. Nous n'implémenterons pas cette vérification dans le modèle ; à la place, nous effectuerons une vérification lorsqu'un enregistrement est ajouté ou mis à jour dans ce tableau.

Articles

Tableaux dans les Items le domaine définit tous les articles disponibles pour le commerce et leur statut actuel. Il enregistre également toutes les modifications apportées à ces éléments au fil du temps.

Le item Le tableau répertorie tous les articles que les commerçants peuvent acheter ou vendre (ou qu'ils ont achetés ou vendus). Il peut s'agir d'actions, de fonds ou de crypto-monnaies. Toute transaction impliquant ces instruments financiers utilise presque exactement le même processus, nous pouvons donc utiliser la même structure pour chacun d'eux. Pour chaque article, nous stockerons :

code – Un code texte UNIQUE pour cet élément, similaire à celui que nous utilisons pour les actions (par exemple, le NASDAQ utilise le code "AAPL" pour Apple Inc).
name – Le nom complet de la société (pour les actions), du fonds ou de la crypto-monnaie.
is_active – Si cet objet est disponible à l'échange ou non.
currency_id – Fait référence à la currency utilisée comme devise de base pour cet article.
details – Tous les détails supplémentaires (tels que le nombre d'actions émises) sous forme textuelle.

Le price table suit tous les changements de prix dans le temps. Une fois qu'un changement s'est produit, nous enregistrerons l'heure (ts ), et le buy et sell prix de l'article (item_id ) impliqué. Nous stockerons également une référence à la currency tableau, qui nous indique la devise utilisée pour définir la valeur de cet élément à ce moment-là. Notez que la devise préférée pour n'importe quel article peut changer.

Le tableau final dans ce domaine est le report table. L'idée est de stocker des rapports réguliers (c'est-à-dire quotidiens) pour chaque élément. Ce rapport sera basé sur les transactions effectuées au cours de cette période et conservera les détails financiers au même endroit. Ce sont des données redondantes, mais elles peuvent s'avérer très utiles lors de l'interrogation des prix historiques (ce qui arrive souvent, car les commerçants sont extrêmement intéressés par les tendances). Pour chaque enregistrement de cette table, nous stockerons :

trading_date – La date de ce rapport. Si nous devons compiler des rapports plus d'une fois par jour, nous devrons apporter des modifications au modèle - par ex. ajouter des horodatages qui indiquent quand une période de trading a commencé et s'est terminée.
item_id et currency_id – Fait référence à l'item et la currency utilisé.
first_price , last_price , min_price , max_price et avg_price – Le premier, le dernier, le maximum, le minimum et le prix moyen de cet article pendant cette période.
total_amount – Le montant total payé pour cet article au cours de la période de rapport.
quantity – Le nombre (quantité) d'articles échangés au cours de cette période de déclaration. Veuillez noter qu'un prix moyen peut être calculé à partir de total_amount et quantity , mais je préfère garder "total_amount" séparé. Cela simplifie la situation lorsque nous créons un rapport pour une période plus longue, comme hebdomadaire. Dans ce cas, nous pourrions ajouter tous les total_amount attributs et divisez-les par la somme de toutes les quantity attributs pour obtenir un prix moyen hebdomadaire.

Tous les attributs de cette table (autres que la clé primaire et les clés étrangères) peuvent être NULL. Ce sera le cas lorsque nous insérons un enregistrement pour une nouvelle période de négociation - il n'y a pas encore de transactions. Au début de chaque date, nous pouvons nous attendre à insérer un enregistrement pour chaque élément et à mettre à jour ces valeurs au fil de la journée. La valeur finale mise à jour sera également le rapport final pour ce jour.

Commerçants

Les Traders Le domaine est le dernier dont nous parlerons, mais c'est le domaine le plus important du modèle. Ses quatre tables (sans le country et item tables que nous avons déjà couvertes) stockent des informations sur les commerçants, leurs inventaires et leurs actions. Notez que la currency le tableau utilisé ici n'est qu'une copie. Il est utilisé pour simplifier le modèle et éviter les chevauchements de relations.

La table centrale est le trader table. Pour chaque commerçant, nous stockerons :

first_name et last_name – Nom et prénom du commerçant.
user_name et password – Le nom d'utilisateur et le mot de passe (hash) choisis par le commerçant. Le user_name L'attribut ne peut stocker que des valeurs UNIQUES.
email – L'adresse e-mail du commerçant. Celui-ci sera utilisé pour compléter le processus d'inscription et pour tous les contacts ultérieurs avec le commerçant. Il ne peut également contenir que des valeurs UNIQUES.
confirmation_code – Le code envoyé à l'utilisateur pour terminer le processus d'inscription.
time_registered et time_confirmed – Horodatages du moment où le commerçant s'est enregistré et quand il a terminé le processus d'inscription.
country_id – Le country où habite le commerçant.
preferred_currency_id – La currency dans lequel le commerçant souhaite afficher les prix.

La liste de tous les objets qu'un commerçant possède actuellement est stockée dans le current_inventory table. Pour chaque trader_id UNIQUE – item_id paire, nous stockerons la quantity le commerçant possède actuellement.

Les deux tableaux restants sont directement liés aux offres et aux échanges. Nous supposerons que chaque commerçant peut placer une offre d'achat ou de vente d'articles à un certain prix. Lorsqu'une offre correspondante apparaît, l'événement commercial se produit. (Nous n'entrerons pas dans les détails spécifiques aux bourses, où un courtier sert de médiateur.)

Nous conserverons une trace de toutes les offres dans l'offer table. Tout commerçant peut placer une offre d'achat ou de vente d'articles. Pour ce faire, nous devons stocker les détails suivants :

trader_id et item_id – Référence le trader qui a placé cette offre et le item ils veulent acheter ou vendre.
quantity – La quantité qu'ils veulent acheter ou vendre.
buy et sell – Si cette offre est d'achat ou de vente. Un seul attribut peut être défini à la fois.
price – Le prix d'achat ou de vente souhaité. Ce n'est pas obligatoire, car un commerçant peut vouloir acheter ou vendre, quel que soit le prix.
ts – L'horodatage auquel cet enregistrement a été inséré.
is_active – Si cette offre est toujours active. Il peut devenir inactif a) si le commerçant le définit sur inactif, ou b) si l'échange a eu lieu.

Le tableau final de notre modèle contient des données relatives à l'événement commercial. L'échange a lieu entre deux utilisateurs après qu'ils aient tous les deux fait une offre. Le prix utilisé peut être le premier prix proposé ou le prix actuel, selon ce que nous voulons mettre en œuvre dans notre application. Pour chaque trade événement, nous stockerons :

item_id – Fait référence à l'item échangé.
seller_id et buyer_id – Les deux font référence au trader tableau et indiquez les utilisateurs impliqués dans le commerce.
quantity – Quelle quantité de cet article a été échangée dans cette transaction.
unit_price – Le prix unitaire utilisé pour cet article dans cet échange.
description – Tous les détails supplémentaires, sous forme textuelle.
offer_id – L'identifiant de l'offer qui a initié ce commerce. Remarque :La première offre initie un échange, c'est donc l'ID que nous allons stocker ici.
ts – L'horodatage auquel cet échange a eu lieu.

Qu'en pensez-vous ?

Nous venons d'envisager un modèle de données pour faciliter le commerce en ligne de crypto-monnaies, d'actions et d'autres dérivés financiers. Ce n'est que l'os nu du modèle; il y a un tas d'autres détails que nous pourrions ajouter. Je pense aux documents liés aux commerçants et à un moyen de stocker les informations de paiement. Qu'ajouteriez-vous ? Ou peut-être supprimer? Veuillez nous le dire dans les commentaires.