En datamodell för handel med aktier, fonder och kryptovalutor

Att handla med kryptovalutor, köpa aktier och liknande är extremt populärt nuförtiden – det uppfattas som lätt vinst. Priserna stiger just nu, men vi kan inte veta när det kommer att ändras. Å andra sidan vet vi att det kommer någon gång. Men vi är inte här för att göra ekonomiska förutsägelser. Istället kommer vi att prata om en datamodell som kan användas för att stödja handeln med kryptovalutor och finansiella instrument som aktier eller fondandelar.

Vad du behöver veta om handel med valutor och aktier

Tekniska förbättringar under de senaste decennierna har haft en betydande inverkan på handeln. Det finns nu många online handelsplattformar du kan använda. Det mesta av dagens handel sker praktiskt taget - du kan se pappersaktier på museer, men du kommer sannolikt inte att se aktierna du köper i pappersform. Och du behöver inte packa dina väskor och bege dig till Wall Street eller någon annan börs för att göra en affär. Från din egen dator eller mobila enhet kan du köpa eller sälja finansiella derivat (som obligationer, aktier eller råvaror).

De flesta affärer (försäljning av finansiella derivat) följer samma regler. Det finns säljare och köpare. Om de kommer överens om ett pris sker affären. Efter handeln kommer priset på det finansiella derivatet att räknas om och processen kommer att fortsätta med nya handlare. Aktier och andra derivat fungerar på samma sätt.

Vad är kryptovaluta? Du har säkert hört talas om Bitcoin och andra kryptovalutor. Men vad är de? Kryptovalutor är som virtuella valutor, men de är inte bundna till verkliga valutor (som euro eller dollar). Istället kan användare handla kryptovalutor sinsemellan som tokens. De kan sedan förhandla fram en försäljning som förvandlar deras tokens till faktiska pengar. Dessa försäljningar fungerar precis som aktie- och aktieaffärerna som beskrivs ovan.

Detta ämne är komplext och vi skulle kunna ha många detaljer i vår modell (t.ex. register över dokument och transaktioner). Jag ska hålla det enkelt; Jag kommer inte att implementera någon form av automatisk handel eller några formler för att generera nya priser efter en handelshändelse.

Så låt oss ta en titt på denna enkla handelsmodell.

Datamodellen

Datamodellen består av tre ämnesområden:

Currencies
Items
Traders

Vi kommer att presentera varje ämnesområde i den ordning det är listat.

Valutor

Currencies ämnesområdet är enkelt. Den innehåller fyra tabeller som lagrar varje valuta vi använder och deras växelkurser. Valuta är viktiga eftersom:

Vi kommer att använda en valuta, kallad basvalutan , för handel. En aktiehandelsplattform online kommer sannolikt att använda den amerikanska dollarn (USD) som basvaluta, oavsett handlarnas faktiska regioner. Alla transaktioner kommer att konverteras till basvalutan.
Vi kan också ha icke-basvalutor eller lokala valutor för alla länder där vår handelsplattform är tillgänglig. Detta skulle tillåta oss att visa priser i den lokala valutan men ändå utföra affärer i basvalutan.

De återstående två tabellerna relaterar till valutor och länder.

Den viktigaste tabellen i detta ämnesområde är currency tabell. Det är här vi kommer att lagra alla valutor vi någonsin har använt för handel, inklusive kryptovalutor. Huruvida en valuta ingår i denna tabell beror på om den valutan kommer att användas för att betala för de handlade föremålen. För varje valuta lagrar vi:

code – En kod som används för att UNIKT beteckna den valutan. För nationella valutor kommer detta att vara ISO 4217-koden (t.ex. USD för amerikanska dollar) eller någon annan officiell kod. Vi skulle också kunna använda ISO 4217 för kryptovalutor; XBT är Bitcoins ISO-kod. Bitcoin använder dock även koden BTC informellt.
name – Valutans UNIKA namn (t.ex. amerikanska dollar).
is_active – Om valutan för närvarande är aktiv i vårt system.
is_base – Om denna valuta är vårt systems basvaluta. Vanligtvis har vi bara en basvaluta åt gången. Det är möjligt att vi kan ha mer än en, till exempel att använda euro för EU-stater och amerikanska dollar för andra områden. I så fall har vi möjlighet att tilldela en basvaluta till varje land med detta attribut.

Nästa tabell lagrar aktuella och historiska kurser mellan valutapar. I currency_rate tabell lagrar vi currency_id vi vill jämföra med ett base_currency_id samt rate när detta par lagrades (ts ). Eftersom vi kommer att lagra kurser som de var vid olika tidpunkter, kommer den här tabellen att lagra både historiska och aktuella data.

En lista över alla relevanta länder lagras i country lexikon. Förutom primärnyckeln (id ), innehåller det ett attribut som har ett UNIKT land name .

Den sista tabellen i detta ämnesområde är currency_used tabell. I de flesta fall kommer ett land alltid att använda samma valuta. Ändå kan förändringar ske, som när många EU-länder bytte ut sina nationella valutor mot euron. För att täcka en sådan händelse kommer vi att lagra en historik över alla valutor vi har använt. För varje post i den här tabellen lagrar vi referenser till country tabell (country_id ), currency tabell (currency_id ), och när denna valuta användes (date_from och date_to ). Om date_to är NULL, då används denna valuta för närvarande. Naturligtvis bör endast en valuta användas per land. Vi kommer inte att implementera den kontrollen i modellen; istället kommer vi att utföra en kontroll när en post läggs till eller uppdateras i den här tabellen.

Artiklar

Tabeller i Items ämnesområde definierar alla föremål som är tillgängliga för handel och deras nuvarande status. Den registrerar också alla ändringar som har hänt med dessa objekt över tiden.

item Tabellen listar alla föremål som handlare kan köpa eller sälja (eller som de har köpt eller sålt). Dessa kan vara aktier, fonder eller kryptovalutor. All handel som involverar dessa finansiella instrument använder nästan exakt samma process, så vi kan använda samma struktur för dem alla. För varje vara lagrar vi:

code – En UNIK textkod för den artikeln, liknande den vi använder för aktier (t.ex. NASDAQ använder koden "AAPL" för Apple Inc).
name – Företagets fullständiga namn (för aktier), fond eller kryptovaluta.
is_active – Om denna artikel är tillgänglig för handel eller inte.
currency_id – Refererar till currency används som basvaluta för denna artikel.
details – Alla ytterligare detaljer (som antalet utgivna aktier) i textformat.

price Tabellen spårar alla prisförändringar över tiden. När en ändring har skett, lagrar vi tiden (ts ), och buy och sell pris för artikeln (item_id ) involverade. Vi lagrar även en referens till currency tabell, som talar om för oss vilken valuta som användes för att ställa in värdet på objektet vid den tidpunkten. Observera att önskad valuta för alla föremål kan ändras.

Den sista tabellen i detta ämnesområde är report tabell. Tanken är att lagra regelbundna (dvs dagliga) rapporter för varje artikel. Denna rapport kommer att baseras på handel under den perioden, och den kommer att hålla finansiella detaljer på ett ställe. Detta är redundanta data, men det kan visa sig vara mycket användbart när man frågar efter historiska priser (vilket händer ofta, eftersom handlare är extremt intresserade av trender). För varje post i den här tabellen lagrar vi:

trading_date – Datum för denna rapport. Om vi behöver sammanställa rapporter oftare än en gång om dagen måste vi göra ändringar i modellen – t.ex. lägga till tidsstämplar som anger när en handelsperiod började och slutade.
item_id och currency_id – Refererar till det relaterade item och currency används.
first_price , last_price , min_price , max_price och avg_price – Det första, sista, högsta, lägsta och genomsnittliga priset för denna artikel under denna period.
total_amount – Det totala belopp som betalats för den posten under rapportperioden.
quantity – Antalet (kvantiteten) artiklar som handlats under denna rapportperiod. Observera att ett genomsnittspris kan beräknas från total_amount och quantity , men jag föredrar att hålla "total_amount" separat. Detta förenklar situationen när vi skapar en rapport för en längre tidsperiod, till exempel varje vecka. I så fall kan vi lägga till hela total_amount attribut och dividera dem med summan av alla quantity attribut för att få ett veckomedelpris.

Alla attribut i den här tabellen (förutom primärnyckeln och främmande nycklar) kan vara NULL. Detta kommer att vara fallet när vi infogar ett rekord för en ny handelsperiod – det finns inga affärer än så länge. I början av varje datum kan vi förvänta oss att vi infogar en post för varje artikel och uppdaterar dessa värden allt eftersom dagen fortskrider. Det slutgiltiga uppdaterade värdet kommer också att vara slutrapporten för den dagen.

Handlare

Traders ämnesområdet är det sista vi kommer att diskutera, men det är det viktigaste området i modellen. Dess fyra tabeller (utan country och item tabeller som vi redan har täckt) lagrar information om handlare, deras lager och deras handlingar. Observera att currency tabellen som används här är bara en kopia. Den används för att förenkla modellen och undvika att relationer överlappar varandra.

Den centrala tabellen är trader tabell. För varje handlare lagrar vi:

first_name och last_name – Näringsidkarens för- och efternamn.
user_name och password – Användarnamnet och lösenordet (hash) som valts av näringsidkaren. user_name attribut kan endast lagra UNIKA värden.
email – Handlarens e-postadress. Detta kommer att användas för att slutföra registreringsprocessen och för alla efterföljande kontakter med handlaren. Den kan också endast innehålla UNIKA värden.
confirmation_code – Koden som skickas till användaren för att slutföra registreringsprocessen.
time_registered och time_confirmed – Tidsstämplar för när näringsidkaren registrerade sig och när de slutförde registreringsprocessen.
country_id – country där näringsidkaren bor.
preferred_currency_id – currency att näringsidkaren vill att priser ska visas i.

Listan över alla artiklar som en handlare för närvarande äger lagras i current_inventory tabell. För varje UNIK trader_id – item_id par, lagrar vi quantity handlaren för närvarande äger.

De återstående två tabellerna är direkt relaterade till erbjudanden och byten. Vi antar att varje handlare kan lägga ett erbjudande om att köpa eller sälja föremål till ett visst pris. När ett matchande erbjudande dyker upp kommer handelshändelsen att inträffa. (Vi går inte in på detaljer som är specifika för börser, där en mäklare fungerar som medlare.)

Vi kommer att hålla ett register över alla erbjudanden i offer tabell. Alla handlare kan lägga ett erbjudande om att köpa eller sälja föremål. För att få detta att hända måste vi lagra följande information:

trader_id och item_id – Refererar till trader vem som lade det erbjudandet och item de vill köpa eller sälja.
quantity – Den kvantitet de vill köpa eller sälja.
buy och sell – Om detta erbjudande är för köp eller försäljning. Endast ett attribut kan ställas in åt gången.
price – Önskat köp- eller säljpris. Det är inte nödvändigt eftersom en handlare kanske vill köpa eller sälja oavsett priset.
ts – Tidsstämpeln när denna post infogades.
is_active – Om det här erbjudandet fortfarande är aktivt. Den kan bli inaktiv a) om handlaren ställer in den på inaktiv, eller b) om handeln har ägt rum.

Finaltabellen i vår modell innehåller data relaterade till handelshändelsen. Handel sker mellan två användare efter att båda lagt ett erbjudande. Priset som används kan vara det första priset som erbjuds eller det aktuella priset, beroende på vad vi vill implementera i vår applikation. För varje trade händelse, vi lagrar:

item_id – Avser item handlas.
seller_id och buyer_id – Båda refererar till trader tabell och beteckna användarna som är involverade i handeln.
quantity – Hur mycket av den artikeln som handlades i den här transaktionen.
unit_price – Enhetspriset som används för denna artikel i denna handel.
description – Alla ytterligare detaljer, i textformat.
offer_id – ID för offer som startade denna handel. Obs! Det första erbjudandet initierar en affär, så det är ID:t vi lagrar här.
ts – Tidsstämpeln när den här handeln skedde.

Vad tycker du?

Vi har precis övervägt en datamodell för att underlätta onlinehandel med kryptovalutor, aktier och andra finansiella derivat. Detta är bara modellens nakna ben; det finns en massa andra detaljer vi kan lägga till. Jag tänker på dokument relaterade till handlare och ett sätt att lagra betalningsinformation. Vad skulle du lägga till? Eller kanske ta bort? Berätta för oss i kommentarerna.