Database
 sql >> база данни >  >> RDS >> Database

Модел на данни за търговия с акции, фондове и криптовалути

Търговията с криптовалути, купуването на акции и други подобни е изключително популярна в наши дни – възприема се като лесна печалба. В момента цените се покачват, но не можем да знаем кога това ще се промени. От друга страна, знаем, че в един момент ще стане. Но ние не сме тук, за да правим финансови прогнози. Вместо това ще говорим за модел на данни, който може да се използва за подпомагане на търговията с криптовалути и финансови инструменти като акции или дялове от фондове.

Какво трябва да знаете за търговията с валути и акции

Технологичните подобрения през последните няколко десетилетия оказаха значително влияние върху търговията. Сега има много платформи за онлайн търговия, които можете да използвате. По-голямата част от днешната търговия се извършва виртуално – можете да видите акциите на хартия в музеите, но е малко вероятно да видите акциите, които купувате в хартиена форма. И не е нужно да опаковате багажа си и да се отправяте към Уолстрийт или друга фондова борса, за да направите сделка. От комфорта на собствения си компютър или мобилно устройство можете да купувате или продавате финансови деривати (като облигации, акции или стоки).

Повечето сделки (продажби на финансови деривати) следват същите правила. Има продавачи и купувачи. Ако се договорят за цена, търговията се случва. След сделката цената на този финансов дериват ще бъде преизчислена и процесът ще продължи с нови търговци. Акциите и другите деривати работят по същия начин.

Какво е криптовалута? Вероятно сте чували за биткойн и други криптовалути. Но какви са те? Криптовалутите са като виртуални валути, но не са обвързани с реални валути (като евро или долари). Вместо това потребителите могат да търгуват с криптовалути помежду си като токени. След това те могат да договорят продажба, която превръща техните токени в реални пари. Тези продажби функционират точно като сделките с акции и акции, описани по-горе.

Тази тема е сложена и бихме могли да имаме много подробности в нашия модел (например записи на документи и транзакции). Ще го опростя; Няма да прилагам никаква автоматична търговия или формули за генериране на нови цени след търговско събитие.

И така, нека да разгледаме този прост модел на търговия.

Моделът на данните




Моделът на данни се състои от три предметни области:

  1. Currencies
  2. Items
  3. Traders

Ще представим всяка тематична област в реда, в който е изброен.

Валути

Currencies предметната област е проста. Той съдържа четири таблици, които съхраняват всяка валута, която използваме, и техните обменни курсове. Валутите са важни, защото:

  • Ще използваме една валута, наречена основна валута , за търговия. Платформа за онлайн търговия с акции вероятно ще използва щатския долар (USD) като основна валута, независимо от действителните региони на търговците. Всички транзакции ще бъдат конвертирани в основната валута.
  • Можем да имаме и небазови или местни валути за всички страни, където е налична нашата платформа за търговия. Това ще ни позволи да показваме цените в местната валута, но въпреки това да извършваме сделки в основната валута.

Останалите две таблици са свързани с валути и държави.

Най-важната таблица в тази предметна област е currency маса. Тук ще съхраняваме всички валути, които някога сме използвали за търговия, включително криптовалути. Дали дадена валута е включена в тази таблица зависи от това дали тази валута ще бъде използвана за плащане на търгуваните артикули. За всяка валута ще съхраняваме:

  • code – Код, използван за УНИКАЛНО обозначаване на тази валута. За национални валути това ще бъде кодът по ISO 4217 (напр. USD за щатски долар) или друг официален код. Можем също да използваме ISO 4217 за криптовалути; XBT е ISO кодът на биткойн. Биткойн обаче също използва кода BTC неофициално.
  • name – УНИКАЛНО име на тази валута (напр. щатски долар).
  • is_active – Ако валутата е активна в момента в нашата система.
  • is_base – Ако тази валута е основната валута на нашата система. Обикновено ще имаме само една основна валута в даден момент. Възможно е да имаме повече от един, като например използването на евро за държави от ЕС и щатски долари за други области. В този случай имаме възможността да присвоим основна валута на всяка държава с този атрибут.

Следващата таблица съхранява текущи и исторически курсове между валутни двойки. В currency_rate таблица, ще съхраняваме currency_id искаме да сравним с base_currency_id както и rate когато тази двойка е била съхранена (ts ). Тъй като ще съхраняваме тарифите, каквито са били в различни моменти от време, тази таблица ще съхранява както исторически, така и текущи данни.

В country речник. Освен първичния ключ (id ), съдържа един атрибут, който притежава УНИКАЛНА държава name .

Последната таблица в тази тематична област е currency_used маса. В повечето случаи една държава винаги ще използва една и съща валута. Все пак могат да се случат промени, както когато много страни от ЕС замениха националните си валути с еврото. За да покрием такава възможност, ще съхраняваме история на всички валути, които сме използвали. За всеки запис в тази таблица ще съхраняваме препратки към country таблица (country_id ), currency таблица (currency_id ) и кога е била използвана тази валута (date_from и date_to ). Ако date_to е NULL, тогава тази валута се използва в момента. Разбира се, за всяка държава трябва да се използва само една валута. Няма да приложим тази проверка в модела; вместо това ще извършим проверка, когато се добави или актуализира запис в тази таблица.

Елементи

Таблици в Items предметната област определя всички артикули, налични за търговия, и тяхното текущо състояние. Той също така записва всички промени, които са се случили с тези елементи във времето.

item таблицата изброява всички артикули, които търговците могат да купят или продадат (или които са купили или продали). Това могат да бъдат акции, фондове или криптовалути. Всяка търговия, включваща тези финансови инструменти, използва почти същия процес, така че можем да използваме една и съща структура за всички тях. За всеки артикул ще съхраняваме:

  • code – УНИКАЛЕН текстов код за този артикул, подобен на този, който използваме за акции (напр. NASDAQ използва кода „AAPL“ за Apple Inc).
  • name – Пълното име на компанията (за акции), фонд или криптовалута.
  • is_active – Дали този артикул е наличен за търговия или не.
  • currency_id – Препраща currency използва се като основна валута за този артикул.
  • details – Всички допълнителни подробности (като броя на издадените акции) в текстов формат.

price таблицата проследява всички промени в цените във времето. След като е настъпила промяна, ще съхраняваме времето (ts ), и buy и sell цена за артикула (item_id ) участващи. Ще съхраняваме и препратка към currency таблица, която ни казва валутата, използвана за задаване на стойността на този артикул по това време. Обърнете внимание, че предпочитаната валута за всеки артикул може да се промени.

Последната таблица в тази тематична област е report маса. Идеята е да съхранявате редовни (т.е. ежедневни) отчети за всеки артикул. Този отчет ще се основава на търговията през този период и ще съхранява финансовите подробности на едно място. Това са излишни данни, но може да се окаже много полезно при запитване на исторически цени (което се случва често, тъй като търговците са изключително заинтересовани от тенденциите). За всеки запис в тази таблица ще съхраняваме:

  • trading_date – Датата на този доклад. Ако трябва да съставяме отчети по-често от веднъж на ден, ще трябва да правим промени в модела – напр. добавяне на времеви печати, които показват кога е започнал и приключил периодът на търговия.
  • item_id и currency_id – Препраща към свързания item и currency използван.
  • first_price , last_price , min_price , max_price и avg_price – Първата, последната, максималната, минималната и средната цена за този артикул през този период.
  • total_amount – Общата сума, платена за този артикул през отчетния период.
  • quantity – Броят (количеството) на артикулите, търгувани през този отчетен период. Моля, имайте предвид, че средната цена може да бъде изчислена от total_amount и quantity , но предпочитам да запазя „total_amount“ отделно. Това опростява ситуацията, когато създаваме отчет за по-дълъг период от време, например ежеседмично. В този случай бихме могли да добавим цялата total_amount атрибути и ги разделете на сумата от всички quantity атрибути, за да получите средна седмична цена.

Всички атрибути в тази таблица (различни от първичния ключ и външните ключове) могат да бъдат NULL. Такъв ще бъде случаят, когато вмъкнем запис за нов период на търговия – досега няма сделки. В началото на всяка дата можем да очакваме, че ще вмъкнем по един запис за всеки елемент и ще актуализираме тези стойности с напредването на деня. Окончателната актуализирана стойност ще бъде и окончателният отчет за този ден.

Търговци

Traders предметната област е последната, която ще обсъдим, но е най-важната област в модела. Неговите четири таблици (без country и item таблици, които вече разгледахме) съхраняват информация за търговците, техните запаси и техните действия. Имайте предвид, че currency използваната тук таблица е просто копие. Използва се за опростяване на модела и избягване на припокриване на отношенията.

Централната маса е trader маса. За всеки търговец ще съхраняваме:

  • first_name и last_name – Името и фамилията на търговеца.
  • user_name и password – Потребителското име и паролата (хеш), избрани от търговеца. user_name атрибутът може да съхранява само УНИКАЛНИ стойности.
  • email – имейл адрес на търговеца. Това ще се използва за завършване на процеса на регистрация и за всички последващи контакти с търговеца. Може също да съдържа само УНИКАЛНИ стойности.
  • confirmation_code – Кодът, изпратен до потребителя, за да завърши процеса на регистрация.
  • time_registered и time_confirmed – Времеви печати за това кога търговецът се е регистрирал и кога е завършил процеса на регистрация.
  • country_idcountry където живее търговецът.
  • preferred_currency_idcurrency в които търговецът иска цените да се показват.

Списъкът с всички артикули, които търговецът притежава в момента, се съхранява в current_inventory маса. За всеки УНИКАЛЕН trader_iditem_id двойка, ще съхраняваме quantity търговецът притежава в момента.

Останалите две таблици са пряко свързани с оферти и сделки. Ще приемем, че всеки търговец може да направи оферта за покупка или продажба на артикули на определена цена. Когато се появи съвпадаща оферта, търговското събитие ще се случи. (Няма да навлизаме в подробности, които са специфични за фондовите борси, където брокерът служи като посредник.)

Ще запазим запис на всички оферти в offer маса. Всеки търговец може да направи оферта за покупка или продажба на артикули. За да се случи това, трябва да съхраним следните подробности:

  • trader_id и item_id – Препраща към trader кой е пуснал тази оферта и item те искат да купуват или продават.
  • quantity – Количеството, което искат да купят или продадат.
  • buy и sell – Ако тази оферта е за покупка или продажба. В даден момент може да се задава само един атрибут.
  • price – Желаната покупна или продажна цена. Не е задължително, защото търговецът може да иска да купи или продаде, независимо каква е цената.
  • ts – клеймото за време, когато този запис е бил вмъкнат.
  • is_active – Дали тази оферта все още е активна. Може да стане неактивен а) ако търговецът го зададе на неактивен, или б) ако търговията е осъществена.

Крайната таблица в нашия модел съдържа данни, свързани с търговското събитие. Търговията се извършва между двама потребители, след като и двамата направят оферта. Използваната цена може да бъде първата предложена цена или текущата цена, в зависимост от това какво искаме да приложим в нашето приложение. За всяка trade събитие, ние ще съхраняваме:

  • item_id – Отнася се за item търгувани.
  • seller_id и buyer_id – И двете се отнасят за trader таблица и обозначават потребителите, участващи в търговията.
  • quantity – Колко от този артикул е изтъргуван в тази транзакция.
  • unit_price – Единичната цена, използвана за този артикул в тази търговия.
  • description – Всички допълнителни подробности, в текстов формат.
  • offer_id – ИД на offer който инициира тази търговия. Забележка:Първата оферта инициира търговия, така че това е идентификационният номер, който ще съхраняваме тук.
  • ts – Времевата марка, когато се е случила тази търговия.

Какво мислите?

Току-що разгледахме модел на данни за улесняване на онлайн търговията с криптовалути, акции и други финансови деривати. Това е само голите кости на модела; има куп други подробности, които можем да добавим. Мисля за документи, свързани с търговци и начин за съхранение на информация за плащане. Какво бихте добавили? Или може би премахнете? Моля, кажете ни в коментарите.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Разбийте големите операции за изтриване на парчета

  2. Вашето окончателно ръководство за SQL присъединяване:INNER JOIN – Част 1

  3. Хекатон с обрат:TVP в паметта – част 3

  4. Завършване на SQL. Истории за успех и провал

  5. SQL СЪЗДАВАНЕ НА ТАБЛИЦА... КАТО Инструкция SELECT