En datamodel for handel med aktier, fonde og kryptovalutaer

Handel med kryptovalutaer, køb af aktier og lignende er ekstremt populært i disse dage - det opfattes som let fortjeneste. Priserne stiger i øjeblikket, men vi kan ikke vide, hvornår det ændrer sig. På den anden side ved vi, at det bliver det på et tidspunkt. Men vi er ikke her for at lave økonomiske forudsigelser. I stedet vil vi tale om en datamodel, der kan bruges til at understøtte handel med kryptovalutaer og finansielle instrumenter som aktier eller fondsandele.

Hvad du behøver at vide om handel med valutaer og aktier

Teknologiske forbedringer i de sidste par årtier har haft en betydelig indvirkning på handel. Der er nu mange online handelsplatforme, du kan bruge. Det meste af dagens handel foregår virtuelt - du kan se papiraktier på museer, men du vil sandsynligvis ikke se de aktier, du køber i papirform. Og du behøver ikke at pakke dine kufferter og tage til Wall Street eller nogen anden børs for at foretage en handel. Fra din egen computer eller mobilenhed kan du købe eller sælge finansielle derivater (såsom obligationer, aktier eller råvarer).

De fleste handler (salg af finansielle derivater) følger de samme regler. Der er sælgere og købere. Hvis de bliver enige om en pris, sker handlen. Efter handlen vil prisen på det finansielle derivat blive genberegnet, og processen vil fortsætte med nye handlende. Aktier og andre derivater fungerer på samme måde.

Hvad er kryptovaluta? Du har sikkert hørt om Bitcoin og andre kryptovalutaer. Men hvad er de? Kryptovalutaer er ligesom virtuelle valutaer, men de er ikke bundet til virkelige valutaer (som euro eller dollar). I stedet kan brugere handle kryptovalutaer indbyrdes som tokens. De kan derefter forhandle et salg, der forvandler deres tokens til faktiske penge. Disse salg fungerer nøjagtigt som aktie- og aktiehandlerne beskrevet ovenfor.

Dette emne er komplekst, og vi kunne have mange detaljer i vores model (f.eks. registreringer af dokumenter og transaktioner). Jeg vil holde det enkelt; Jeg vil ikke implementere nogen form for automatisk handel eller nogen formler til at generere nye priser efter en handelsbegivenhed.

Så lad os tage et kig på denne enkle handelsmodel.

Datamodellen

Datamodellen består af tre emneområder:

Currencies
Items
Traders

Vi præsenterer hvert emneområde i den rækkefølge, det er angivet.

Valutaer

Currencies emneområdet er enkelt. Den indeholder fire tabeller, der gemmer hver valuta, vi bruger, og deres vekselkurser. Valutaer er vigtige, fordi:

Vi vil bruge én valuta, kaldet basisvalutaen , til handel. En online aktiehandelsplatform vil sandsynligvis bruge den amerikanske dollar (USD) som sin basisvaluta, uanset de handlendes faktiske regioner. Alle transaktioner vil blive konverteret til basisvalutaen.
Vi kan også have ikke-basisvalutaer eller lokale valutaer for alle de lande, hvor vores handelsplatform er tilgængelig. Dette ville give os mulighed for at vise priser i den lokale valuta, men stadig udføre handler i basisvalutaen.

De resterende to tabeller vedrører valutaer og lande.

Den vigtigste tabel i dette emneområde er currency bord. Det er her, vi gemmer alle valutaer, vi nogensinde har brugt til handel, inklusive kryptovalutaer. Hvorvidt en valuta er inkluderet i denne tabel afhænger af, om denne valuta vil blive brugt til at betale for de handlede varer. For hver valuta gemmer vi:

code – En kode, der bruges til UNIKT at angive denne valuta. For nationale valutaer vil dette være ISO 4217-koden (f.eks. USD for amerikanske dollar) eller en anden officiel kode. Vi kunne også bruge ISO 4217 til kryptovalutaer; XBT er Bitcoins ISO-kode. Bitcoin bruger dog også koden BTC uformelt.
name – Denne valutas UNIKKE navn (f.eks. US Dollar).
is_active – Hvis valutaen i øjeblikket er aktiv i vores system.
is_base – Hvis denne valuta er vores systems basisvaluta. Normalt har vi kun én basisvaluta ad gangen. Det er muligt, at vi kunne have mere end én, såsom at bruge euro til EU-stater og amerikanske dollars til andre områder. I så fald har vi mulighed for at tildele en basisvaluta til hvert land med denne attribut.

Den næste tabel gemmer aktuelle og historiske kurser mellem valutapar. I currency_rate tabel, gemmer vi currency_id vi vil sammenligne med en base_currency_id samt rate da dette par blev gemt (ts ). Da vi gemmer kurserne, som de var på forskellige tidspunkter, vil denne tabel gemme både historiske og aktuelle data.

En liste over alle relevante lande er gemt i country ordbog. Udover den primære nøgle (id ), indeholder den en attribut, der har et UNIKT land name .

Den sidste tabel i dette emneområde er currency_used bord. I de fleste tilfælde vil et land altid bruge den samme valuta. Alligevel kan der ske ændringer, som da mange EU-lande udskiftede deres nationale valutaer med euroen. For at dække en sådan eventualitet gemmer vi en historik over alle de valutaer, vi har brugt. For hver post i denne tabel gemmer vi referencer til country tabel (country_id ), currency tabel (currency_id ), og hvornår denne valuta blev brugt (date_from og date_to ). Hvis date_to er NULL, så er denne valuta i brug i øjeblikket. Selvfølgelig bør der kun være én valuta i brug pr. land. Vi vil ikke implementere det tjek i modellen; i stedet udfører vi en kontrol, når en post tilføjes eller opdateres i denne tabel.

Elementer

Tabeller i Items emneområdet definerer alle varer, der er tilgængelige for handel, og deres aktuelle status. Det registrerer også alle ændringer, der er sket med disse elementer over tid.

item tabel viser alle varer, som handlende kan købe eller sælge (eller som de har købt eller solgt). Disse kan være aktier, fonde eller kryptovalutaer. Enhver handel, der involverer disse finansielle instrumenter, bruger næsten nøjagtig den samme proces, så vi kan bruge den samme struktur for dem alle. For hver vare gemmer vi:

code – En UNIK tekstkode for den vare, der ligner den, vi bruger til aktier (f.eks. bruger NASDAQ koden "AAPL" for Apple Inc.).
name – Det fulde navn på virksomheden (for aktier), fond eller kryptovaluta.
is_active – Om denne vare er tilgængelig for handel eller ej.
currency_id – Refererer til currency bruges som basisvaluta for denne vare.
details – Alle yderligere detaljer (såsom antallet af udstedte aktier) i tekstformat.

price tabel sporer alle prisændringer over tid. Når en ændring er sket, gemmer vi tiden (ts ), og buy og sell pris for varen (item_id ) involveret. Vi gemmer også en reference til currency tabel, som fortæller os den valuta, der blev brugt til at indstille værdien af den pågældende vare på det tidspunkt. Bemærk, at den foretrukne valuta for enhver vare kan ændre sig.

Den sidste tabel i dette emneområde er report bord. Ideen er at gemme regelmæssige (dvs. daglige) rapporter for hver vare. Denne rapport vil være baseret på handel i denne periode, og den vil opbevare finansielle detaljer ét sted. Dette er overflødige data, men det kan vise sig at være meget nyttigt, når man forespørger på historiske priser (hvilket sker ofte, da handlende er ekstremt interesserede i trends). For hver post i denne tabel gemmer vi:

trading_date – Datoen for denne rapport. Hvis vi skal udarbejde rapporter oftere end én gang om dagen, skal vi lave ændringer i modellen – f.eks. tilføjelse af tidsstempler, der angiver, hvornår en handelsperiode begyndte og sluttede.
item_id og currency_id – Henviser til den relaterede item og currency brugt.
first_price , last_price , min_price , max_price og avg_price – Den første, sidste, maksimum, minimum og gennemsnitlige pris for denne vare i denne periode.
total_amount – Det samlede beløb, der er betalt for den pågældende post i rapporteringsperioden.
quantity – Antallet (mængden) af varer handlet i denne rapporteringsperiode. Bemærk venligst, at en gennemsnitspris kan beregnes ud fra total_amount og quantity , men jeg foretrækker at holde "total_amount" adskilt. Dette forenkler situationen, når vi opretter en rapport for en længere periode, f.eks. ugentligt. I så fald kunne vi tilføje hele total_amount attributter og dividere dem med summen af alle quantity attributter for at få en ugentlig gennemsnitspris.

Alle attributter i denne tabel (bortset fra den primære nøgle og fremmednøglerne) kan være NULL. Dette vil være tilfældet, når vi indsætter en rekord for en ny handelsperiode - der er ingen handler indtil videre. I begyndelsen af hver dato kan vi forvente, at vi indsætter én post for hver vare og opdaterer disse værdier, efterhånden som dagen skrider frem. Den endelige opdaterede værdi vil også være den endelige rapport for den pågældende dag.

Forhandlere

Traders fagområde er det sidste, vi vil diskutere, men det er det vigtigste område i modellen. Dens fire tabeller (bortset fra country og item tabeller, som vi allerede har dækket) gemmer oplysninger om handlende, deres varebeholdninger og deres handlinger. Bemærk, at currency tabellen brugt her er kun en kopi. Det bruges til at forenkle modellen og undgå, at relationer overlapper hinanden.

Den centrale tabel er trader bord. For hver forhandler gemmer vi:

first_name og last_name – Den erhvervsdrivendes for- og efternavne.
user_name og password – Brugernavn og adgangskode (hash) valgt af den erhvervsdrivende. user_name attribut kan kun gemme UNIKKE værdier.
email – Den erhvervsdrivendes e-mailadresse. Dette vil blive brugt til at fuldføre registreringsprocessen og til alle efterfølgende kontakter med den erhvervsdrivende. Den kan også kun indeholde UNIKKE værdier.
confirmation_code – Koden sendt til brugeren for at fuldføre registreringsprocessen.
time_registered og time_confirmed – Tidsstempler for, hvornår den erhvervsdrivende registrerede sig, og hvornår de gennemførte registreringsprocessen.
country_id – country hvor den erhvervsdrivende bor.
preferred_currency_id – currency at den erhvervsdrivende ønsker priser vist i.

Listen over alle varer, som en forhandler i øjeblikket ejer, er gemt i current_inventory bord. For hver UNIK trader_id – item_id par, gemmer vi quantity den erhvervsdrivende ejer i øjeblikket.

De resterende to tabeller er direkte relateret til tilbud og handler. Vi antager, at hver erhvervsdrivende kan afgive et tilbud om at købe eller sælge varer til en bestemt pris. Når et matchende tilbud vises, vil handelsbegivenheden finde sted. (Vi vil ikke gå ind i detaljer, der er specifikke for børser, hvor en mægler fungerer som mægler.)

Vi registrerer alle tilbud i offer bord. Enhver erhvervsdrivende kan afgive et tilbud om at købe eller sælge varer. For at få dette til at ske, skal vi gemme følgende detaljer:

trader_id og item_id – Henviser til trader hvem der afgav tilbuddet og item de vil købe eller sælge.
quantity – Den mængde, de ønsker at købe eller sælge.
buy og sell – Hvis dette tilbud er til køb eller salg. Der kan kun indstilles én egenskab ad gangen.
price – Den ønskede købs- eller salgspris. Det er ikke påkrævet, fordi en erhvervsdrivende måske ønsker at købe eller sælge, uanset prisen.
ts – Tidsstemplet, da denne post blev indsat.
is_active – Om dette tilbud stadig er aktivt. Den kan blive inaktiv a) hvis den erhvervsdrivende indstiller den til inaktiv, eller b) hvis handlen har fundet sted.

Den endelige tabel i vores model indeholder data relateret til handelsbegivenheden. Handel finder sted mellem to brugere, efter at de begge har afgivet et tilbud. Den anvendte pris kan være den første tilbudte pris eller den aktuelle pris, afhængigt af hvad vi ønsker at implementere i vores applikation. For hver trade begivenhed, vi gemmer:

item_id – Henviser til item handles.
seller_id og buyer_id – Begge refererer til trader tabel og angiv de brugere, der er involveret i handelen.
quantity – Hvor meget af denne vare blev handlet i denne transaktion.
unit_price – Den enhedspris, der er brugt for denne vare i denne handel.
description – Alle yderligere detaljer i tekstformat.
offer_id – ID'et for offer som startede denne handel. Bemærk:Det første tilbud starter en handel, så det er det ID, vi gemmer her.
ts – Tidsstemplet, hvor denne handel fandt sted.

Hvad synes du?

Vi har lige overvejet en datamodel til at lette online handel med kryptovalutaer, aktier og andre finansielle derivater. Dette er blot modellens bare knogler; der er en masse andre detaljer, vi kunne tilføje. Jeg tænker på dokumenter relateret til handlende og en måde at gemme betalingsoplysninger på. Hvad ville du tilføje? Eller måske fjerne? Fortæl os venligst i kommentarerne.