Database
 sql >> Baza danych >  >> RDS >> Database

Model danych do handlu akcjami, funduszami i kryptowalutami

Handel kryptowalutami, kupowanie akcji itp. jest obecnie niezwykle popularny – jest postrzegany jako łatwy zysk. Ceny obecnie rosną, ale nie wiemy, kiedy to się zmieni. Z drugiej strony wiemy, że w pewnym momencie tak się stanie. Ale nie jesteśmy tu po to, by przewidywać finansowe. Zamiast tego porozmawiamy o modelu danych, który można wykorzystać do obsługi handlu kryptowalutami i instrumentami finansowymi, takimi jak akcje lub udziały funduszy.

Co musisz wiedzieć o handlu walutami i akcjami

Udoskonalenia technologiczne w ciągu ostatnich kilku dekad miały znaczący wpływ na handel. Obecnie istnieje wiele platform transakcyjnych online, z których możesz korzystać. Większość dzisiejszych transakcji odbywa się wirtualnie – możesz zobaczyć papiery w muzeach, ale prawdopodobnie nie zobaczysz tych, które kupujesz w formie papierowej. I nie musisz pakować swoich toreb i udać się na Wall Street lub inną giełdę, aby dokonać transakcji. W zaciszu własnego komputera lub urządzenia mobilnego możesz kupować lub sprzedawać finansowe instrumenty pochodne (takie jak obligacje, akcje lub towary).

Większość transakcji (sprzedaż instrumentów pochodnych) podlega tym samym zasadom. Są sprzedający i kupujący. Jeśli zgodzą się na cenę, dojdzie do wymiany. Po transakcji cena tego finansowego instrumentu pochodnego zostanie ponownie obliczona, a proces będzie kontynuowany z nowymi handlowcami. Akcje i inne instrumenty pochodne działają w ten sam sposób.

Co to jest kryptowaluta? Prawdopodobnie słyszałeś o Bitcoin i innych kryptowalutach. Ale czym one są? Kryptowaluty są jak waluty wirtualne, ale nie są powiązane z walutami świata rzeczywistego (takimi jak euro czy dolary). Zamiast tego użytkownicy mogą wymieniać między sobą kryptowaluty, takie jak tokeny. Następnie mogą negocjować sprzedaż, która zamienia ich tokeny w rzeczywiste pieniądze. Te transakcje sprzedaży działają dokładnie tak, jak transakcje na akcjach i akcjach opisane powyżej.

Temat ten jest złożony i w naszym modelu moglibyśmy mieć wiele szczegółów (np. ewidencję dokumentów i transakcji). Zamierzam zachować prostotę; Nie będę wdrażać żadnego rodzaju automatycznego handlu ani żadnych formuł do generowania nowych cen po zdarzeniu handlowym.

Przyjrzyjmy się więc temu prostemu modelowi handlu.

Model danych




Model danych składa się z trzech obszarów tematycznych:

  1. Currencies
  2. Items
  3. Traders

Zaprezentujemy każdy obszar tematyczny w kolejności, w jakiej jest wymieniony.

Waluty

Currencies temat jest prosty. Zawiera cztery tabele, w których przechowywane są wszystkie używane przez nas waluty i ich kursy wymiany. Waluty są ważne, ponieważ:

  • Będziemy używać jednej waluty, zwanej walutą bazową , do handlu. Internetowa platforma handlu akcjami prawdopodobnie użyje dolara amerykańskiego (USD) jako waluty bazowej, niezależnie od rzeczywistych regionów traderów. Wszystkie transakcje zostaną przeliczone na walutę bazową.
  • Możemy również mieć waluty inne niż bazowe lub lokalne dla wszystkich krajów, w których dostępna jest nasza platforma handlowa. To pozwoliłoby nam wyświetlać ceny w lokalnej walucie, ale nadal wykonywać transakcje w walucie bazowej.

Pozostałe dwie tabele dotyczą walut i krajów.

Najważniejszą tabelą w tym obszarze tematycznym jest currency stół. Tutaj będziemy przechowywać wszystkie waluty, którymi kiedykolwiek handlowaliśmy, w tym kryptowaluty. To, czy waluta jest uwzględniona w tej tabeli, zależy od tego, czy waluta ta zostanie użyta do zapłaty za sprzedawane przedmioty. Dla każdej waluty przechowujemy:

  • code – Kod używany do WYJĄTKOWEGO oznaczenia tej waluty. W przypadku walut krajowych będzie to kod ISO 4217 (np. USD dla dolara amerykańskiego) lub inny oficjalny kod. Moglibyśmy również użyć ISO 4217 dla kryptowalut; XBT to kod ISO Bitcoina. Jednak Bitcoin używa również kodu BTC nieformalnie.
  • name – UNIKALNA nazwa tej waluty (np. dolar amerykański).
  • is_active – Jeśli waluta jest aktualnie aktywna w naszym systemie.
  • is_base – Jeśli ta waluta jest walutą bazową naszego systemu. Zwykle będziemy mieć tylko jedną walutę bazową na raz. Możliwe, że moglibyśmy mieć więcej niż jeden, na przykład euro dla krajów UE i dolary amerykańskie dla innych obszarów. W takim przypadku mamy możliwość przypisania waluty bazowej do każdego kraju z tym atrybutem.

Następna tabela zawiera aktualne i historyczne kursy pomiędzy parami walutowymi. W currency_rate tabeli, przechowamy currency_id chcemy porównać z base_currency_id jak również rate kiedy ta para była przechowywana (ts ). Ponieważ będziemy przechowywać stawki tak, jak były w różnych momentach, ta tabela będzie przechowywać zarówno dane historyczne, jak i bieżące.

Lista wszystkich odpowiednich krajów jest przechowywana w country słownik. Oprócz klucza głównego (id ), zawiera jeden atrybut, który przechowuje UNIKALNY kraj name .

Ostatnia tabela w tym obszarze tematycznym to currency_used stół. W większości przypadków kraj będzie zawsze używał tej samej waluty. Jednak zmiany mogą się zdarzyć, jak wtedy, gdy wiele krajów UE zastąpiło swoje waluty narodowe euro. Aby uwzględnić taką ewentualność, będziemy przechowywać historię wszystkich używanych przez nas walut. Dla każdego rekordu w tej tabeli będziemy przechowywać odniesienia do country tabela (country_id ), currency tabela (currency_id ) i kiedy użyto tej waluty (date_from i date_to ). Jeśli date_to ma wartość NULL, oznacza to, że ta waluta jest obecnie w użyciu. Oczywiście w danym kraju powinna obowiązywać tylko jedna waluta. Nie zaimplementujemy tego sprawdzenia w modelu; zamiast tego sprawdzimy, kiedy rekord zostanie dodany lub zaktualizowany w tej tabeli.

Przedmioty

Tabele w Items obszar tematyczny określa wszystkie przedmioty dostępne do handlu oraz ich aktualny status. Rejestruje również wszystkie zmiany, które zaszły w tych elementach w czasie.

item tabela zawiera wszystkie przedmioty, które handlarze mogą kupić lub sprzedać (lub które kupili lub sprzedali). Mogą to być akcje, fundusze lub kryptowaluty. Każdy handel z udziałem tych instrumentów finansowych wykorzystuje prawie dokładnie ten sam proces, więc możemy użyć tej samej struktury dla nich wszystkich. Dla każdego przedmiotu przechowujemy:

  • code – UNIKALNY kod tekstowy dla tego elementu, podobny do tego, którego używamy dla akcji (np. NASDAQ używa kodu „AAPL” dla Apple Inc).
  • name – Pełna nazwa firmy (w przypadku akcji), funduszu lub kryptowaluty.
  • is_active – Czy ten przedmiot jest dostępny do handlu, czy nie.
  • currency_id – Odwołuje się do currency używana jako waluta podstawowa dla tego przedmiotu.
  • details – Wszystkie dodatkowe szczegóły (takie jak liczba wyemitowanych akcji) w formacie tekstowym.

price tabela śledzi wszystkie zmiany cen w czasie. Po wprowadzeniu zmiany zapiszemy czas (ts ) i buy i sell cena za przedmiot (item_id ) zaangażowany. Przechowamy również odniesienie do currency tabeli, która informuje nas o walucie używanej do ustawienia wartości tego elementu w tym czasie. Zwróć uwagę, że preferowana waluta dla dowolnego przedmiotu może ulec zmianie.

Ostatnią tabelą w tym obszarze tematycznym jest report stół. Ideą jest przechowywanie regularnych (tj. codziennych) raportów dla każdej pozycji. Ten raport będzie oparty na handlu w tym okresie i będzie przechowywać dane finansowe w jednym miejscu. Są to dane zbędne, ale mogą okazać się bardzo przydatne podczas sprawdzania cen historycznych (co zdarza się często, ponieważ handlowcy są bardzo zainteresowani trendami). Dla każdego rekordu w tej tabeli będziemy przechowywać:

  • trading_date – Data tego raportu. Jeśli potrzebujemy kompilować raporty częściej niż raz dziennie, będziemy musieli wprowadzić zmiany w modelu – m.in. dodawanie znaczników czasu, które wskazują, kiedy okres handlowy rozpoczął się i zakończył.
  • item_id i currency_id – Odwołuje się do powiązanego item i currency używany.
  • first_price , last_price , min_price , max_price i avg_price – Pierwsza, ostatnia, maksymalna, minimalna i średnia cena tego przedmiotu w tym okresie.
  • total_amount – Całkowita kwota zapłacona za ten przedmiot w okresie sprawozdawczym.
  • quantity – Liczba (ilość) pozycji w obrocie w tym okresie sprawozdawczym. Pamiętaj, że średnią cenę można obliczyć na podstawie total_amount i quantity , ale wolę oddzielić „total_amount”. Upraszcza to sytuację, gdy tworzymy raport na dłuższy okres czasu, np. tygodniowy. W takim przypadku moglibyśmy dodać wszystkie total_amount atrybuty i podziel je przez sumę wszystkich quantity atrybuty, aby uzyskać tygodniową średnią cenę.

Wszystkie atrybuty w tej tabeli (inne niż klucz podstawowy i klucze obce) mogą mieć wartość NULL. Tak będzie w przypadku, gdy wstawimy rekord dla nowego okresu rozliczeniowego – do tej pory nie ma żadnych transakcji. Na początku każdej daty możemy się spodziewać, że wstawimy jeden rekord dla każdego elementu i zaktualizujemy te wartości w miarę upływu dnia. Ostateczna zaktualizowana wartość będzie również ostatecznym raportem na ten dzień.

Handlowcy

Traders temat jest ostatnim, który omówimy, ale jest to najważniejszy obszar w modelu. Jego cztery tabele (pomijając country i item tabele, które już omówiliśmy) przechowują informacje o handlowcach, ich zapasach i ich działaniach. Zwróć uwagę, że currency użyta tutaj tabela jest tylko kopią. Służy do uproszczenia modelu i uniknięcia nakładania się relacji.

Centralną tabelą jest trader stół. Dla każdego przedsiębiorcy przechowujemy:

  • first_name i last_name – Imię i nazwisko przedsiębiorcy.
  • user_name i password – Nazwa użytkownika i hasło (hash) wybrane przez handlowca. user_name atrybut może przechowywać tylko UNIKALNE wartości.
  • email – Adres e-mail przedsiębiorcy. Będzie to wykorzystane do zakończenia procesu rejestracji i wszystkich kolejnych kontaktów z przedsiębiorcą. Może również zawierać tylko UNIKALNE wartości.
  • confirmation_code – Kod wysłany do użytkownika w celu zakończenia procesu rejestracji.
  • time_registered i time_confirmed – Znaczniki czasu rejestracji przedsiębiorcy i zakończenia procesu rejestracji.
  • country_idcountry gdzie mieszka przedsiębiorca.
  • preferred_currency_idcurrency w których przedsiębiorca chce wyświetlać ceny.

Lista wszystkich przedmiotów, które obecnie posiada handlowiec, jest przechowywana w current_inventory stół. Dla każdego UNIKALNEGO trader_iditem_id parę, przechowamy quantity przedsiębiorca jest obecnie właścicielem.

Pozostałe dwie tabele są bezpośrednio związane z ofertami i transakcjami. Zakładamy, że każdy handlowiec może złożyć ofertę kupna lub sprzedaży przedmiotów po określonej cenie. Kiedy pojawi się pasująca oferta, nastąpi wydarzenie handlowe. (Nie będziemy wchodzić w szczegóły, które są specyficzne dla giełd papierów wartościowych, gdzie pośrednik pełni rolę mediatora).

Będziemy rejestrować wszystkie oferty w offer stół. Każdy handlarz może złożyć ofertę kupna lub sprzedaży przedmiotów. Aby tak się stało, musimy zapisać następujące dane:

  • trader_id i item_id – Odwołuje się do trader kto złożył tę ofertę i item chcą kupić lub sprzedać.
  • quantity – Ilość, którą chcą kupić lub sprzedać.
  • buy i sell – Jeśli ta oferta dotyczy kupna lub sprzedaży. Jednocześnie można ustawić tylko jeden atrybut.
  • price – Pożądana cena kupna lub sprzedaży. Nie jest to wymagane, ponieważ inwestor może chcieć kupić lub sprzedać bez względu na cenę.
  • ts – Znacznik czasu wstawienia tego rekordu.
  • is_active – Czy ta oferta jest nadal aktywna. Może stać się nieaktywny a) jeśli trader ustawi go jako nieaktywny, lub b) jeśli transakcja miała miejsce.

Ostatnia tabela w naszym modelu zawiera dane związane ze zdarzeniem handlowym. Handel odbywa się między dwoma użytkownikami po złożeniu przez nich oferty. Użyta cena może być pierwszą oferowaną ceną lub aktualną ceną, w zależności od tego, co chcemy zaimplementować w naszej aplikacji. Dla każdej trade wydarzenie, będziemy przechowywać:

  • item_id – Odnosi się do item w obrocie.
  • seller_id i buyer_id – Oba odwołują się do trader tabeli i oznacz użytkowników zaangażowanych w handel.
  • quantity – Ile tego przedmiotu zostało sprzedane w tej transakcji.
  • unit_price – Cena jednostkowa użyta dla tego przedmiotu w tej transakcji.
  • description – Wszystkie dodatkowe szczegóły w formacie tekstowym.
  • offer_id – Identyfikator offer który zainicjował ten handel. Uwaga:pierwsza oferta inicjuje wymianę, więc to identyfikator, który będziemy tutaj przechowywać.
  • ts – Znacznik czasu, w którym doszło do tej transakcji.

Co myślisz?

Właśnie rozważaliśmy model danych ułatwiający handel online kryptowalutami, akcjami i innymi finansowymi instrumentami pochodnymi. To tylko nagie kości modelu; istnieje wiele innych szczegółów, które moglibyśmy dodać. Zastanawiam się nad dokumentami związanymi z traderami i sposobem na przechowywanie informacji o płatnościach. Co byś dodał? A może usunąć? Powiedz nam w komentarzach.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Jak dezaktywować wtyczki z bazy danych WordPress

  2. Wprowadzenie do Hadoop i Big Data

  3. Maskowanie danych w aplikacjach DB

  4. Twórz niesamowite listy samodzielnie lub GitHub jako notatnik

  5. Jak wykonać surowy SQL w SQLAlchemy