最近、暗号通貨の取引や株式の購入などが非常に人気があり、簡単な利益として認識されています。価格は現在上昇していますが、いつ変更されるかはわかりません。一方で、いつかはそうなることを私たちは知っています。しかし、私たちは財務予測を行うためにここにいるわけではありません。代わりに、暗号通貨や株式やファンド株などの金融商品の取引をサポートするために使用できるデータモデルについて説明します。
取引通貨と株式について知っておくべきこと
過去数十年の技術的改善は、取引に大きな影響を及ぼしました。現在、使用できる多くのオンライン取引プラットフォームがあります。今日の取引のほとんどは事実上行われています。美術館で紙の株を見ることができますが、紙の形で購入した株を見る可能性は低いです。また、バッグを詰めてウォール街やその他の証券取引所に行って取引する必要はありません。自分のコンピューターやモバイルデバイスの快適さから、金融デリバティブ（債券、株式、商品など）を売買できます。
ほとんどの取引（金融デリバティブの販売）は同じ規則に従います。売り手と買い手がいます。彼らが価格について合意すれば、取引は起こります。取引後、その金融デリバティブの価格が再計算され、プロセスは新しいトレーダーで続行されます。株式やその他のデリバティブも同じように機能します。
暗号通貨とは何ですか？ あなたはおそらくビットコインや他の暗号通貨について聞いたことがあるでしょう。しかし、彼らは何ですか？暗号通貨は仮想通貨に似ていますが、実際の通貨（ユーロやドルなど）に関連付けられていません。代わりに、ユーザーはトークンのように自分たちの間で暗号通貨を交換することができます。その後、トークンを実際のお金に変える販売を交渉できます。これらの販売は、上記の株式および株式取引とまったく同じように機能します。
この主題は複雑であり、モデルに多くの詳細を含めることができます（ドキュメントやトランザクションの記録など）。シンプルに保ちます。トレードイベント後に新しい価格を生成するための自動取引や数式は実装しません。
それでは、この単純な取引モデルを見てみましょう。
データモデル
データモデルは、次の3つのサブジェクト領域で構成されています。
通貨アイテムトレーダー
各サブジェクトエリアは、リストされている順序で表示されます。
通貨
通貨 主題分野は単純です。これには、使用するすべての通貨とその為替レートを格納する4つのテーブルが含まれています。通貨は次の理由で重要です：
- 基本通貨と呼ばれる1つの通貨を使用します 、取引用。オンライン株式取引プラットフォームは、トレーダーの実際の地域に関係なく、基本通貨として米ドル（USD）を使用する可能性があります。すべての取引は基本通貨に変換されます。
- 非基本通貨または現地通貨を使用することもできます 私たちの取引プラットフォームが利用できるすべての国のために。これにより、現地通貨で価格を表示しながら、基本通貨で取引を実行できるようになります。
残りの2つの表は、通貨と国に関するものです。
このサブジェクト領域で最も重要なテーブルは、通貨です。 テーブル。これは、暗号通貨を含む、これまで取引に使用したすべての通貨を保存する場所です。この表に通貨が含まれるかどうかは、その通貨が取引アイテムの支払いに使用されるかどうかによって異なります。通貨ごとに、以下を保存します：
コード –その通貨を一意に示すために使用されるコード。国の通貨の場合、これはISO 4217コード（米ドルの場合はUSDなど）またはその他の公式コードになります。暗号通貨にはISO4217を使用することもできます。 XBTはビットコインのISOコードです。ただし、ビットコインはコードBTCも非公式に使用しています。名前 –その通貨の一意の名前（例：米ドル）。-
is_active–通貨が現在システムでアクティブになっている場合。 -
is_base–この通貨がシステムの基本通貨である場合。通常、一度に使用できる基本通貨は1つだけです。 EU加盟国にユーロを使用し、他の地域に米ドルを使用するなど、複数の可能性があります。その場合、この属性を使用して各国に基本通貨を割り当てることができます。
次の表は、通貨ペア間の現在および過去のレートを格納します。 currency_rate テーブルには、 currency_idを保存します base_currency_idと比較したい rate このペアが保存されたとき（ ts ）。さまざまな時点でのレートを保存するため、このテーブルには履歴データと現在のデータの両方が保存されます。
関連するすべての国のリストが国に保存されます 辞書。主キー（ id ）、一意の国の nameを保持する1つの属性が含まれています 。
このサブジェクト領域の最後のテーブルは、 currency_usedです。 テーブル。ほとんどの場合、国は常に同じ通貨を使用します。それでも、多くのEU諸国が自国通貨をユーロに置き換えたときのように、変化が起こる可能性があります。このような事態に備えて、使用したすべての通貨の履歴を保存します。この表のレコードごとに、 countryへの参照を保存します テーブル（ country_id ）、通貨 テーブル（ currency_id ）、およびこの通貨が使用されたとき（ date_from およびdate_to ）。 date_toの場合 がNULLの場合、この通貨は現在使用中です。もちろん、国ごとに1つの通貨のみを使用する必要があります。モデルにそのチェックを実装しません。代わりに、このテーブルでレコードが追加または更新されたときにチェックを実行します。
アイテム
アイテムのテーブル サブジェクトエリアは、取引可能なすべてのアイテムとその現在のステータスを定義します。また、これらのアイテムに時間の経過とともに発生したすべての変更も記録されます。
アイテム 表には、トレーダーが購入または販売できる（または購入または販売した）すべてのアイテムがリストされています。これらは、株式、ファンド、または暗号通貨である可能性があります。これらの金融商品を含む取引は、ほぼ同じプロセスを使用するため、すべての金融商品に同じ構造を使用できます。アイテムごとに、以下を保存します：
コード –共有に使用するものと同様の、そのアイテムの一意のテキストコード（たとえば、NASDAQはApple Incのコード「AAPL」を使用します）。名前 –会社のフルネーム（株式の場合）、ファンド、または暗号通貨。-
is_active–このアイテムが取引可能かどうか。 -
currency_id–通貨を参照しますこのアイテムの基本通貨として使用されます。 詳細 –テキスト形式のすべての追加の詳細（発行された株式数など）。
価格 テーブルは、時間の経過に伴うすべての価格変更を追跡します。変更が発生したら、時間を保存します（ ts ）、および購入 およびsell アイテムの価格（ item_id ） 関与。 通貨への参照も保存します その時点でそのアイテムの値を設定するために使用された通貨を示すテーブル。すべてのアイテムの優先通貨が変更される可能性があることに注意してください。
このサブジェクトエリアの最後の表は、レポートです。 テーブル。アイデアは、各アイテムの定期的な（つまり毎日の）レポートを保存することです。このレポートは、その期間中の取引に基づいており、財務の詳細を1か所に保持します。これは冗長なデータですが、過去の価格を照会するときに非常に役立つことがわかります（これは、トレーダーがトレンドに非常に興味を持っているため、頻繁に発生します）。この表のレコードごとに、以下を保存します：
-
Trading_date–このレポートの日付。レポートを1日に2回以上コンパイルする必要がある場合は、モデルに変更を加える必要があります。取引期間がいつ開始および終了したかを示すタイムスタンプを追加します。 -
item_idおよびcurrency_id–関連するアイテムを参照しますおよび通貨使用済み。 -
first_price、last_price、min_price、max_priceおよびavg_price–この期間中のこのアイテムの最初、最後、最大、最小、および平均価格。 -
total_amount–レポート期間中にそのアイテムに支払われた合計金額。 数量–このレポート期間中に取引されたアイテムの数（数量）。平均価格はtotal_amountから計算できることに注意してください およびquantity、しかし私は「total_amount」を分離しておくことを好みます。これにより、毎週など、より長い期間のレポートを作成する場合の状況が単純化されます。その場合、すべてのtotal_amountを追加できます。 属性を作成し、それらをすべての数量の合計で割ります 週平均価格を取得するための属性。
このテーブルのすべての属性（主キーと外部キーを除く）はNULLにすることができます。これは、新しい取引期間のレコードを挿入する場合に当てはまります。これまでのところ取引はありません。各日付の初めに、アイテムごとに1つのレコードを挿入し、日が進むにつれてこれらの値を更新することが期待できます。最終的に更新された値は、その日の最終レポートにもなります。
トレーダー
トレーダー サブジェクトエリアは最後に説明しますが、モデルで最も重要なエリアです。その4つのテーブル（国を除く） およびitem すでに説明した表）は、トレーダー、その在庫、およびその行動に関する情報を格納します。 通貨に注意してください ここで使用されているテーブルは単なるコピーです。モデルを単純化し、関係の重複を回避するために使用されます。
中央のテーブルはtrader テーブル。トレーダーごとに、以下を保存します：
-
first_nameおよびlast_name–トレーダーの名前と名前。 -
user_nameおよびpassword–トレーダーが選択したユーザー名とパスワード（ハッシュ）。user_name属性はUNIQUE値のみを格納できます。 メール–トレーダーのメールアドレス。これは、登録プロセスを完了するため、およびその後のトレーダーとのすべての連絡に使用されます。 UNIQUE値のみを保持することもできます。confirmation_code–登録プロセスを完了するためにユーザーに送信されるコード。-
time_registeredおよびtime_confirmed–トレーダーが登録したときと登録プロセスを完了したときのタイムスタンプ。 -
country_id–国トレーダーが住んでいる場所。 -
Preferred_currency_id–通貨トレーダーが価格を表示したいこと。
トレーダーが現在所有しているすべてのアイテムのリストは、 current_inventoryに保存されます。 テーブル。 UNIQUE trader_idごとに – item_id ペアの場合、数量を保存します トレーダーは現在所有しています。
残りの2つのテーブルは、オファーとトレードに直接関連しています。各トレーダーは、特定の価格で商品を売買するオファーを出すことができると想定します。一致するオファーが表示されると、トレードイベントが発生します。 （ブローカーが仲介役を務める証券取引所に固有の詳細については説明しません。）
オファーにすべてのオファーの記録を保持します テーブル。すべてのトレーダーは、アイテムを購入または販売するオファーを出すことができます。これを実現するには、次の詳細を保存する必要があります。
-
trader_idおよびitem_id–traderを参照しますそのオファーとアイテムを配置したのは誰か彼らは売買したいのです。 数量–購入または販売したい数量。購入およびsell–このオファーが売買用の場合。一度に設定できる属性は1つだけです。価格–希望する売買価格。トレーダーは価格に関係なく売買したい場合があるため、必須ではありません。-
ts–このレコードが挿入されたときのタイムスタンプ。 -
is_active–このオファーがまだ有効かどうか。 a）トレーダーが非アクティブに設定した場合、またはb）取引が行われた場合、非アクティブになる可能性があります。
モデルのファイナルテーブルには、トレーディングイベントに関連するデータが含まれています。 2人のユーザーがオファーを行った後、2人のユーザー間で取引が行われます。使用される価格は、アプリケーションに実装する内容に応じて、最初に提示された価格または現在の価格になります。 取引ごとに イベント、保存します：
-
item_id–itemを指します取引されました。 -
seller_idおよびbuyer_id–どちらもトレーダーを参照しています表を作成し、取引に関与するユーザーを示します。 数量–このトランザクションでそのアイテムのどれだけが取引されたか。-
unit_price–この取引でこのアイテムに使用される単価。 説明–すべての追加の詳細（テキスト形式）。-
offer_id–オファーのIDそれがこの取引を開始しました。注：最初のオファーは取引を開始するため、ここに保存するIDです。 -
ts–この取引が発生したときのタイムスタンプ。
どう思いますか？
暗号通貨、株式、その他の金融デリバティブのオンライン取引を容易にするためのデータモデルを検討しました。これはモデルの骨組みにすぎません。追加できる詳細は他にもたくさんあります。トレーダーに関連するドキュメントと支払い情報を保存する方法を考えています。何を追加しますか？または多分削除しますか？コメントで教えてください。