sql >> Databáze >  >> RDS >> Database

Datový model pro obchodování s akciemi, fondy a kryptoměnami

Obchodování s kryptoměnami, nákup akcií a podobně je v dnešní době extrémně populární – je vnímáno jako snadný zisk. Ceny aktuálně rostou, ale nevíme, kdy se to změní. Na druhou stranu víme, že v určitém okamžiku bude. Ale nejsme tu od toho, abychom dělali finanční předpovědi. Místo toho budeme hovořit o datovém modelu, který lze použít k podpoře obchodování s kryptoměnami a finančními nástroji, jako jsou akcie nebo akcie fondů.

Co potřebujete vědět o obchodování s měnami a akciemi

Technologická vylepšení v posledních několika desetiletích měla významný dopad na obchodování. Nyní existuje mnoho online obchodních platforem, které můžete použít. Většina dnešního obchodování se provádí virtuálně – papírové akcie můžete vidět v muzeích, ale pravděpodobně neuvidíte akcie, které si koupíte v papírové podobě. A nemusíte si sbalit kufry a vydat se na Wall Street nebo jinou burzu, abyste mohli obchodovat. Z pohodlí svého počítače nebo mobilního zařízení můžete nakupovat nebo prodávat finanční deriváty (jako jsou dluhopisy, akcie nebo komodity).

Většina obchodů (prodejů finančních derivátů) se řídí stejnými pravidly. Existují prodávající a kupující. Pokud se dohodnou na ceně, dojde k obchodu. Po skončení obchodu bude cena tohoto finančního derivátu přepočítána a proces bude pokračovat s novými obchodníky. Akcie a další deriváty fungují stejným způsobem.

Co je to kryptoměna? Pravděpodobně jste slyšeli o bitcoinu a dalších kryptoměnách. Ale co jsou zač? Kryptoměny jsou jako virtuální měny, ale nejsou vázány na reálné měny (jako eura nebo dolary). Místo toho mohou uživatelé mezi sebou obchodovat s kryptoměnami jako s tokeny. Poté mohou vyjednat prodej, který změní jejich tokeny na skutečné peníze. Tyto prodeje fungují přesně jako výše popsané obchody s akciemi a akciemi.

Toto téma je složité a v našem modelu bychom mohli mít spoustu detailů (např. záznamy dokumentů a transakcí). Budu to dělat jednoduše; Nebudu implementovat žádný druh automatického obchodování ani žádné vzorce pro generování nových cen po obchodní události.

Pojďme se tedy podívat na tento jednoduchý obchodní model.

Datový model




Datový model se skládá ze tří tematických oblastí:

  1. Currencies
  2. Items
  3. Traders

Každou oblast představíme v pořadí, v jakém je uvedena.

Měny

Currencies předmět je jednoduchý. Obsahuje čtyři tabulky, které ukládají každou měnu, kterou používáme, a jejich směnné kurzy. Měny jsou důležité, protože:

  • Budeme používat jednu měnu, která se nazývá základní měna , pro obchodování. Online platforma pro obchodování s akciemi bude pravděpodobně používat jako základní měnu americký dolar (USD), bez ohledu na skutečné regiony obchodníků. Všechny transakce budou převedeny na základní měnu.
  • Můžeme mít také nezákladní nebo místní měny pro všechny země, kde je naše obchodní platforma dostupná. To by nám umožnilo zobrazovat ceny v místní měně, ale stále provádět obchody v základní měně.

Zbývající dvě tabulky se týkají měn a zemí.

Nejdůležitější tabulkou v této oblasti je currency stůl. Zde budeme ukládat všechny měny, které jsme kdy používali k obchodování, včetně kryptoměn. Zda je měna zahrnuta v této tabulce, závisí na tom, zda bude tato měna použita k platbě za obchodované položky. Pro každou měnu uložíme:

  • code – Kód používaný k JEDINEČNÉMU označení této měny. U národních měn to bude kód ISO 4217 (např. USD pro americký dolar) nebo nějaký jiný oficiální kód. Mohli bychom také použít ISO 4217 pro kryptoměny; XBT je kód ISO bitcoinu. Bitcoin však také neformálně používá kód BTC.
  • name – UNIKÁTNÍ název této měny (např. americký dolar).
  • is_active – Pokud je měna aktuálně aktivní v našem systému.
  • is_base – Pokud je tato měna základní měnou našeho systému. Obvykle budeme mít vždy pouze jednu základní měnu. Je možné, že bychom mohli mít více než jeden, například používat eura pro státy EU a americké dolary pro jiné oblasti. V takovém případě máme možnost přiřadit základní měnu každé zemi s tímto atributem.

V další tabulce jsou uloženy aktuální a historické kurzy mezi měnovými páry. V currency_rate tabulky, uložíme currency_id chceme porovnat s base_currency_id stejně jako rate kdy byl tento pár uložen (ts ). Vzhledem k tomu, že budeme ukládat sazby tak, jak byly v různých časových okamžicích, bude tato tabulka ukládat historická i aktuální data.

Seznam všech relevantních zemí je uložen v country slovník. Kromě primárního klíče (id ), obsahuje jeden atribut, který obsahuje name UNIKÁTNÍ země .

Poslední tabulka v této oblasti je currency_used stůl. Ve většině případů bude země vždy používat stejnou měnu. Přesto může dojít ke změnám, jako když mnoho zemí EU nahradilo své národní měny eurem. Abychom takovou možnost pokryli, uložíme historii všech měn, které jsme použili. Pro každý záznam v této tabulce uložíme odkazy na country tabulka (country_id ), currency tabulka (currency_id ), a kdy byla tato měna použita (date_from a date_to ). Pokud date_to je NULL, pak se tato měna aktuálně používá. V každé zemi by se samozřejmě měla používat pouze jedna měna. Tuto kontrolu do modelu nezavedeme; místo toho provedeme kontrolu při přidání nebo aktualizaci záznamu v této tabulce.

Položky

Tabulky v Items předmětová oblast definuje všechny položky dostupné pro obchod a jejich aktuální stav. Zaznamenává také všechny změny, ke kterým došlo v průběhu času u těchto položek.

item tabulka uvádí všechny položky, které mohou obchodníci koupit nebo prodat (nebo které koupili či prodali). Mohou to být akcie, fondy nebo kryptoměny. Jakýkoli obchod s těmito finančními nástroji používá téměř přesně stejný proces, takže pro všechny můžeme použít stejnou strukturu. U každé položky uložíme:

  • code – UNIKÁTNÍ textový kód pro tuto položku, podobný tomu, který používáme pro akcie (např. NASDAQ používá kód „AAPL“ pro Apple Inc).
  • name – Úplný název společnosti (u akcií), fondu nebo kryptoměny.
  • is_active – Zda je tato položka k dispozici pro obchod nebo ne.
  • currency_id – Odkazuje na currency používá se jako základní měna pro tuto položku.
  • details – Všechny další podrobnosti (jako je počet vydaných akcií) v textové podobě.

price tabulka sleduje všechny změny cen v průběhu času. Jakmile dojde ke změně, uložíme čas (ts ) a buy a sell cena za položku (item_id ) zapojeny. Uložíme také odkaz na currency tabulka, která nám říká měnu použitou k nastavení hodnoty dané položky v daném okamžiku. Všimněte si, že preferovaná měna pro jakoukoli položku se může změnit.

Poslední tabulkou v této tematické oblasti je report stůl. Cílem je ukládat pravidelné (tj. denní) zprávy pro každou položku. Tato zpráva bude založena na obchodování během tohoto období a bude uchovávat finanční podrobnosti na jednom místě. Toto jsou nadbytečná data, ale mohou se ukázat jako velmi užitečná při dotazování na historické ceny (což se stává často, protože obchodníci se extrémně zajímají o trendy). Pro každý záznam v této tabulce uložíme:

  • trading_date – Datum této zprávy. Pokud potřebujeme sestavovat sestavy častěji než jednou denně, budeme muset provést změny v modelu – např. přidání časových razítek, které označují, kdy obchodní období začalo a skončilo.
  • item_id a currency_id – Odkazuje na související item a currency použité.
  • first_price , last_price , min_price , max_price a avg_price – První, poslední, maximální, minimální a průměrná cena za tuto položku během tohoto období.
  • total_amount – Celková částka zaplacená za danou položku během vykazovaného období.
  • quantity – Počet (množství) položek obchodovaných během tohoto vykazovaného období. Upozorňujeme, že průměrnou cenu lze vypočítat z total_amount a quantity , ale preferuji ponechat „celková_částka“ odděleně. To zjednodušuje situaci, kdy vytváříme report na delší časové období, např. týdenní. V takovém případě bychom mohli přidat všechny total_amount atributy a vydělte je součtem všech quantity atributy, abyste získali týdenní průměrnou cenu.

Všechny atributy v této tabulce (kromě primárního klíče a cizích klíčů) mohou mít hodnotu NULL. To bude případ, kdy vložíme záznam pro nové obchodní období – zatím nejsou žádné obchody. Na začátku každého data můžeme očekávat, že vložíme jeden záznam pro každou položku a aktualizujeme tyto hodnoty v průběhu dne. Konečná aktualizovaná hodnota bude také konečnou zprávou pro daný den.

Obchodníci

Traders předmětová oblast je poslední, o které budeme diskutovat, ale je to nejdůležitější oblast v modelu. Jeho čtyři tabulky (pomineme-li country a item tabulky, které jsme již probrali) ukládají informace o obchodníkech, jejich zásobách a jejich akcích. Všimněte si, že currency zde použitá tabulka je pouze kopie. Používá se ke zjednodušení modelu a zamezení překrývání vztahů.

Centrální tabulka je trader stůl. Pro každého obchodníka uložíme:

  • first_name a last_name – Jméno a příjmení obchodníka.
  • user_name a password – Uživatelské jméno a heslo (hash) zvolené obchodníkem. user_name atribut může ukládat pouze UNIKÁTNÍ hodnoty.
  • email – E-mailová adresa obchodníka. Ten bude použit k dokončení procesu registrace a pro všechny následné kontakty s obchodníkem. Může také obsahovat pouze UNIKÁTNÍ hodnoty.
  • confirmation_code – Kód odeslaný uživateli k dokončení procesu registrace.
  • time_registered a time_confirmed – Časová razítka, kdy se obchodník zaregistroval a kdy dokončil proces registrace.
  • country_idcountry kde obchodník žije.
  • preferred_currency_idcurrency že obchodník chce zobrazit ceny.

Seznam všech položek, které obchodník aktuálně vlastní, je uložen v current_inventory stůl. Pro každý UNIKÁTNÍ trader_iditem_id páru, uložíme quantity obchodník v současné době vlastní.

Zbývající dvě tabulky přímo souvisí s nabídkami a obchody. Budeme předpokládat, že každý obchodník může podat nabídku k nákupu nebo prodeji položek za určitou cenu. Když se objeví odpovídající nabídka, dojde k obchodní události. (Nebudeme zabíhat do podrobností, které jsou specifické pro burzy, kde broker slouží jako zprostředkovatel.)

Všechny nabídky budeme evidovat v offer stůl. Každý obchodník může podat nabídku k nákupu nebo prodeji položek. Aby se to stalo, musíme uložit následující podrobnosti:

  • trader_id a item_id – Odkazuje na trader kdo podal nabídku a item chtějí koupit nebo prodat.
  • quantity – Množství, které chtějí koupit nebo prodat.
  • buy a sell – Pokud je tato nabídka na nákup nebo prodej. Najednou lze nastavit pouze jeden atribut.
  • price – Požadovaná nákupní nebo prodejní cena. Není to vyžadováno, protože obchodník může chtít koupit nebo prodat bez ohledu na cenu.
  • ts – Časové razítko, kdy byl tento záznam vložen.
  • is_active – Zda je tato nabídka stále aktivní. Může se stát neaktivním a) pokud jej obchodník nastaví jako neaktivní, nebo b) pokud se obchod uskutečnil.

Závěrečná tabulka v našem modelu obsahuje data související s obchodní událostí. Obchodování probíhá mezi dvěma uživateli poté, co oba podají nabídku. Použitá cena může být první nabízená cena nebo aktuální cena v závislosti na tom, co chceme v naší aplikaci implementovat. Pro každý trade událost, uložíme:

  • item_id – Odkazuje na item obchodováno.
  • seller_id a buyer_id – Oba odkazují na trader tabulku a označují uživatele zapojené do obchodu.
  • quantity – Kolik z této položky bylo zobchodováno v této transakci.
  • unit_price – Jednotková cena použitá pro tuto položku v tomto obchodu.
  • description – Všechny další podrobnosti v textovém formátu.
  • offer_id – ID offer která tento obchod iniciovala. Poznámka:První nabídka zahájí obchod, takže zde uložíme ID.
  • ts – Časové razítko, kdy k tomuto obchodu došlo.

Co si myslíte?

Právě jsme zvažovali datový model pro usnadnění online obchodování s kryptoměnami, akciemi a dalšími finančními deriváty. To jsou jen holé kosti modelu; existuje spousta dalších podrobností, které bychom mohli přidat. Mám na mysli dokumenty související s obchodníky a způsob, jak ukládat platební údaje. co byste dodal? Nebo možná odstranit? Řekněte nám to prosím v komentářích.


  1. 4 způsoby, jak nahradit NULL jinou hodnotou v MySQL

  2. Zvyšte výkon pomocí hromadného shromažďování v Oracle

  3. Co jsou poddotazy v oracle

  4. Transparent Data Encryption (TDE) na serveru SQL Server ve skupině AlwaysOn Availability na příkladu