Database
 sql >> Base de Dados >  >> RDS >> Database

Um modelo de dados para negociar ações, fundos e criptomoedas


Negociar criptomoedas, comprar ações e coisas do gênero é extremamente popular hoje em dia – é percebido como lucro fácil. Os preços estão subindo, mas não podemos saber quando isso vai mudar. Por outro lado, sabemos que em algum momento isso acontecerá. Mas não estamos aqui para fazer previsões financeiras. Em vez disso, falaremos sobre um modelo de dados que pode ser usado para apoiar o comércio de criptomoedas e instrumentos financeiros, como ações ou cotas de fundos.

O que você precisa saber sobre a negociação de moedas e ações


As melhorias tecnológicas nas últimas décadas tiveram um impacto significativo no comércio. Agora existem muitas plataformas de negociação online que você pode usar. A maior parte das negociações de hoje é feita virtualmente – você pode ver ações de papel em museus, mas provavelmente não verá as ações que compra em papel. E você não precisa fazer as malas e ir para Wall Street ou qualquer outra bolsa de valores para fazer uma negociação. A partir do conforto do seu próprio computador ou dispositivo móvel, você pode comprar ou vender derivativos financeiros (como títulos, ações ou commodities).

A maioria dos negócios (vendas de derivativos financeiros) seguem as mesmas regras. Existem vendedores e compradores. Se eles concordarem com um preço, a negociação acontece. Após a negociação, o preço desse derivativo financeiro será recalculado e o processo continuará com novos traders. As ações e outros derivativos funcionam da mesma maneira.

O que é criptomoeda? Você provavelmente já ouviu falar de Bitcoin e outras criptomoedas. Mas o que são eles? As criptomoedas são como moedas virtuais, mas não estão vinculadas a moedas do mundo real (como euros ou dólares). Em vez disso, os usuários podem negociar criptomoedas entre si como tokens. Eles podem então negociar uma venda que transforma seus tokens em dinheiro real. Essas vendas funcionam exatamente como os negócios de ações e ações descritos acima.

Este assunto é complexo e poderíamos ter muitos detalhes em nosso modelo (por exemplo, registros de documentos e transações). Vou simplificar; Não implementarei nenhum tipo de negociação automática ou fórmulas para gerar novos preços após um evento comercial.

Então, vamos dar uma olhada neste modelo de negociação simples.

O modelo de dados





O modelo de dados consiste em três áreas de assunto:
  1. Currencies
  2. Items
  3. Traders

Apresentaremos cada área de assunto na ordem em que está listada.

Moedas



As Currencies área de assunto é simples. Ele contém quatro tabelas que armazenam todas as moedas que usamos e suas taxas de câmbio. As moedas são importantes porque:

  • Usaremos uma moeda, chamada de moeda base , para negociação. Uma plataforma de negociação de ações online provavelmente usará o dólar americano (USD) como moeda base, independentemente das regiões reais dos traders. Todas as transações serão convertidas na moeda base.
  • Também podemos ter moedas não base ou locais para todos os países onde nossa plataforma de negociação está disponível. Isso nos permitiria exibir preços na moeda local, mas ainda realizar negócios na moeda base.

As duas tabelas restantes relacionam moedas e países.

A tabela mais importante nesta área de assunto é a currency tabela. É aqui que armazenaremos todas as moedas que já usamos para negociação, incluindo criptomoedas. A inclusão de uma moeda nesta tabela depende se essa moeda será usada para pagar os itens negociados. Para cada moeda, armazenaremos:
  • code – Um código usado para denotar EXCLUSIVAMENTE essa moeda. Para moedas nacionais, este será o código ISO 4217 (por exemplo, USD para dólar dos Estados Unidos) ou algum outro código oficial. Também poderíamos usar a ISO 4217 para criptomoedas; XBT é o código ISO do Bitcoin. No entanto, o Bitcoin também usa o código BTC informalmente.
  • name – O nome EXCLUSIVO dessa moeda (por exemplo, Dólar dos Estados Unidos).
  • is_active – Se a moeda estiver atualmente ativa em nosso sistema.
  • is_base – Se esta moeda for a moeda base do nosso sistema. Normalmente, teremos apenas uma moeda base por vez. É possível que tenhamos mais de um, como usar euros para estados da UE e dólares americanos para outras áreas. Nesse caso, temos a capacidade de atribuir uma moeda base a cada país com esse atributo.

A tabela a seguir armazena as taxas atuais e históricas entre pares de moedas. Na currency_rate tabela, armazenaremos o currency_id queremos comparar com um base_currency_id bem como a rate quando este par foi armazenado (ts ). Como armazenaremos as taxas como estavam em vários momentos, esta tabela armazenará dados históricos e atuais.

Uma lista de todos os países relevantes é armazenada no country dicionário. Além da chave primária (id ), ele contém um atributo que contém um name de país ÚNICO .

A última tabela nesta área de assunto é a currency_used tabela. Na maioria dos casos, um país sempre usará a mesma moeda. Ainda assim, mudanças podem acontecer, como quando muitos países da UE substituíram suas moedas nacionais pelo euro. Para cobrir tal eventualidade, armazenaremos um histórico de todas as moedas que usamos. Para cada registro nesta tabela, armazenaremos referências ao country tabela (country_id ), a currency tabela (currency_id ), e quando esta moeda foi usada (date_from e date_to ). Se date_to for NULL, essa moeda está atualmente em uso. Obviamente, apenas uma moeda deve estar em uso por país. Não implementaremos essa verificação no modelo; em vez disso, realizaremos uma verificação quando um registro for adicionado ou atualizado nesta tabela.

Itens



Tabelas nos Items área de assunto define todos os itens disponíveis para negociação e seu status atual. Ele também registra todas as mudanças que ocorreram nesses itens ao longo do tempo.

O item tabela lista todos os itens que os comerciantes podem comprar ou vender (ou que eles compraram ou venderam). Podem ser ações, fundos ou criptomoedas. Qualquer negociação envolvendo esses instrumentos financeiros usa quase exatamente o mesmo processo, então podemos usar a mesma estrutura para todos eles. Para cada item, armazenaremos:

  • code – Um código de texto EXCLUSIVO para esse item, semelhante ao que usamos para compartilhamentos (por exemplo, NASDAQ usa o código “AAPL” para Apple Inc).
  • name – O nome completo da empresa (para ações), fundo ou criptomoeda.
  • is_active – Se este item está disponível para troca ou não.
  • currency_id – Faz referência à currency usado como moeda base para este item.
  • details – Todos os detalhes adicionais (como o número de ações emitidas) em formato textual.

O price tabela rastreia todas as mudanças de preço ao longo do tempo. Assim que ocorrer uma alteração, armazenaremos a hora (ts ), e o buy e sell preço do item (item_id ) envolvidos. Também armazenaremos uma referência à currency table, que nos informa a moeda usada para definir o valor desse item naquele momento. Observe que a moeda preferencial para qualquer item pode mudar.

A tabela final nesta área de assunto é o report tabela. A ideia é armazenar relatórios regulares (ou seja, diários) para cada item. Este relatório será baseado nas negociações durante esse período e manterá os detalhes financeiros em um só lugar. Esses são dados redundantes, mas podem ser muito úteis ao consultar preços históricos (o que acontece com frequência, pois os traders estão extremamente interessados ​​em tendências). Para cada registro nesta tabela, armazenaremos:
  • trading_date – A data deste relatório. Se precisarmos compilar relatórios mais de uma vez por dia, teremos que fazer alterações no modelo – por exemplo, adicionando carimbos de data/hora que indicam quando um período de negociação começou e terminou.
  • item_id e currency_id – Faz referência ao item e a currency usado.
  • first_price , last_price , min_price , max_price e avg_price – O primeiro, último, máximo, mínimo e preço médio deste item durante este período.
  • total_amount – O valor total pago por esse item durante o período do relatório.
  • quantity – O número (quantidade) de itens negociados durante este período de relatório. Observe que um preço médio pode ser calculado a partir de total_amount e quantity , mas prefiro manter “total_amount” separado. Isso simplifica a situação quando criamos um relatório para um período de tempo mais longo, como semanalmente. Nesse caso, poderíamos adicionar todos os total_amount atributos e divida-os pela soma de todas as quantity atributos para obter um preço médio semanal.

Todos os atributos nesta tabela (exceto a chave primária e as chaves estrangeiras) podem ser NULL. Este será o caso quando inserirmos um registro para um novo período de negociação – não há negociações até o momento. No início de cada data, podemos esperar inserir um registro para cada item e atualizar esses valores à medida que o dia avança. O valor final atualizado também será o relatório final desse dia.

Comerciantes



Os Traders área de assunto é a última que discutiremos, mas é a área mais importante no modelo. Suas quatro tabelas (deixando de fora o country e item tabelas que já abordamos) armazenam informações sobre traders, seus estoques e suas ações. Observe que a currency tabela usada aqui é apenas uma cópia. É usado para simplificar o modelo e evitar a sobreposição de relações.

A mesa central é o trader tabela. Para cada trader, armazenaremos:

  • first_name e last_name – O nome e sobrenome do trader.
  • user_name e password – O nome de usuário e senha (hash) escolhidos pelo trader. O user_name atributo pode armazenar apenas valores UNIQUE.
  • email – O endereço de e-mail do trader. Isso será usado para concluir o processo de registro e para todos os contatos subsequentes com o comerciante. Ele também pode conter apenas valores UNIQUE.
  • confirmation_code – O código enviado ao usuário para concluir o processo de registro.
  • time_registered e time_confirmed – Timestamps de quando o trader se registrou e quando completou o processo de registro.
  • country_id – O country onde o comerciante mora.
  • preferred_currency_id – A currency que o trader deseja que os preços sejam exibidos.

A lista de todos os itens que um trader possui atualmente é armazenada no current_inventory tabela. Para cada trader_id ÚNICO – item_id par, armazenaremos a quantity o comerciante possui atualmente.

As duas tabelas restantes estão diretamente relacionadas a ofertas e negociações. Vamos supor que cada trader pode fazer uma oferta para comprar ou vender itens a um determinado preço. Quando uma oferta correspondente aparecer, o evento de negociação acontecerá. (Não entraremos em detalhes específicos das bolsas de valores, onde um corretor atua como mediador.)

Manteremos um registro de todas as ofertas na offer tabela. Qualquer comerciante pode fazer uma oferta para comprar ou vender itens. Para que isso aconteça, precisamos armazenar os seguintes detalhes:
  • trader_id e item_id – Refere-se ao trader quem fez essa oferta e o item eles querem comprar ou vender.
  • quantity – A quantidade que eles querem comprar ou vender.
  • buy e sell – Se esta oferta é para compra ou venda. Apenas um atributo pode ser definido por vez.
  • price – O preço de compra ou venda desejado. Não é necessário porque um trader pode querer comprar ou vender, independentemente do preço.
  • ts – O carimbo de data/hora em que este registro foi inserido.
  • is_active – Se esta oferta ainda está ativa. Ele pode se tornar inativo a) se o trader o definir como inativo, ou b) se a negociação tiver ocorrido.

A tabela final em nosso modelo contém dados relacionados ao evento de negociação. A negociação ocorre entre dois usuários depois que ambos fazem uma oferta. O preço utilizado pode ser o primeiro preço oferecido ou o preço atual, dependendo do que queremos implementar em nossa aplicação. Para cada trade evento, armazenaremos:
  • item_id – Refere-se ao item negociado.
  • seller_id e buyer_id – Ambos fazem referência ao trader tabela e denotar os usuários envolvidos no comércio.
  • quantity – Quanto desse item foi negociado nesta transação.
  • unit_price – O preço unitário usado para este item nesta troca.
  • description – Todos os detalhes adicionais, em formato textual.
  • offer_id – O ID da offer que iniciou este comércio. Observação:a primeira oferta inicia uma negociação, então esse é o ID que armazenaremos aqui.
  • ts – O carimbo de data/hora em que essa negociação aconteceu.

O que você acha?


Acabamos de considerar um modelo de dados para facilitar a negociação online de criptomoedas, ações e outros derivativos financeiros. Este é apenas o esqueleto do modelo; há um monte de outros detalhes que poderíamos adicionar. Estou pensando em documentos relacionados a comerciantes e uma maneira de armazenar informações de pagamento. O que você acrescentaria? Ou talvez remover? Por favor, diga-nos nos comentários.