市場シミュレーション（第18回）：SQL入門(I)

はじめに

前回の「市場シミュレーション（第17回）：ソケット(XI)」では、MetaTrader 5とExcel間で情報をやり取りする実装のデモを完了しました。ExcelからMetaTrader 5を制御する方法については扱いませんでした。これは慎重に扱う必要があるためです。この部分は各自の目的や設計思想に依存するため、記事末尾にいくつか参考資料を示し、各自で理解できるようにしています。

使用するSQLプログラムがMySQLであっても、SQL Server、SQLite、OpenSQL、あるいはその他のものであっても問題ではありません。これらはすべて共通点を持っており、その共通要素がSQL言語です。たとえMySQL Workbenchを使用しない場合でも、MetaEditorやMQL5を通じてデータベースを直接操作し、MetaTrader 5上で操作することが可能です。ただしそのためにはSQLの知識が必要になります。SQLに関する書籍やオンライン教材は多数存在します。必要なのは基本概念を理解し、自分のプログラミング言語でSQLと通信する方法を習得することです。

ただし、SQLを使用する前にいくつかの制約があります。SQLを学ぶためには、少なくともデータベースを作成できる必要があります。これが基本的な出発点です。

データベース入門

SQLの利用方法にはいくつかのシンプルな方法があります。1つ目はコマンドラインに直接コマンドを入力する方法です。2つ目はWorkbenchやMetaEditorのようなツールを使用する方法です。3つ目はMQL5で記述したプログラムにSQLコマンドを組み込み、MetaTrader 5上で実行する方法です。実行中のプログラムからデータベースへアクセスできます。さらに別の基本的な方法として、ソケットを用いてSQLサーバーと通信する方法もあります。これらの方法はSQLベースのすべてのデータベースシステムで広く利用可能です。したがって、ここで説明する内容はすべて互換性のあるシステムで使用できます。「これはできない」と考える必要はありません。標準SQLを使用している限り、実行可能です。

ただし注意点があります。OpenSQL、MySQL、SQLite、SQL Serverなど、いずれのSQLシステムでも、そのシステム専用のコマンドが存在する場合があります。これらの専用コマンドを使用すると、他のSQLシステムでは同じ操作ができなくなります。

補足として、最初の段階では Workbenchを使用します。その理由は後ほど説明されます。

以上を踏まえて、最も単純なコマンドである「空のデータベースの作成」を見ていきます。ここでまず明確にしておきますが、拡張子を .DB に変更するだけで何らかのファイルを作成することは完全に無意味です。システムはそれをデータベースとして認識しません。データベースを作成するにはコマンドを使用する必要があり、その方法自体は非常に単純です。ただしコマンドを見る前に、別の点について触れておきます。

SQLでは予約語を大文字で記述することが、しばしば（ほぼ慣習的に）推奨されます。しかしSQL自体は大文字・小文字を区別しません。そのため、コード記述時にコマンドを大文字で書き忘れても問題はありません。その場合は、以下のボタンを使用することでコード全体、またはSQL予約語をすべて大文字に変換できます。

SQLの最初のコマンド

ここから実際にコマンドを見ていきます。最初に学ぶべきコマンドはCREATE DATABASEです。以下の図でその形式を確認できます。

図中で青色かつ太字で示されている部分がSQLコードであり、黒色で示されている部分がデータベース名です。これが最初に使用するコマンドです。このコマンドを入力した後、コード上部に表示されている稲妻アイコンのいずれかをクリックします。それぞれの稲妻アイコンは異なる動作をします。ここでは初学者向けとして、左端のアイコンをクリックします。また、各アイコンの用途と動作を理解しておくことは重要であり、特にスクリプトのデバッグ時に役立ちます。この点については後ほど説明します。これに注意してください。もしMetaEditor上でSQLを直接使用してデータベースを作成する場合は、方法が異なります。この場合、図に示されているオプションを選択する必要があります。

これをおこなうと、MetaEditorは作成するデータベースファイルの保存場所と名前の指定を求めてきます。これは単純な操作です。MQL5コードによってデータベースファイルを作成することも可能です。ただしこれは後の章で扱います。MQL5や他の言語でSQLを扱いながら実際に構築するための材料を十分に揃えてから説明する方が適切だからです。一方で、MQL5コード内でソケットを使用してSQLサーバーに接続する場合、Workbenchで表示されているSQLコマンドをそのまま送信することができ、その結果として同じ処理、すなわちデータベースの作成が可能になります。

しかしこれは別の話題です。現時点では最も単純で直接的な方法、すなわちMetaEditor、Workbench、またはコマンドラインを使用する方法に進みます。ただしコマンドラインを使用する場合は、出力の表示形式を理解しておく必要がありますが、それは慣れの問題です。この記事の目的は明確さを最優先にすることなので、

ここではMetaEditorとWorkbenchのみを使用します。

これらの手順をMetaEditorで実行すると、最終的に次のような結果になります。ご覧の通り、この例ではWorkbench側のデータベースと区別するために名前を変更しています。

この時点でMetaEditorは追加作業の準備が整っています。しかしWorkbench側ではまだ次のステップに進むことはできません。いくつか追加の手順が必要です。次に進む前に、図で強調されている項目をクリックします。

これら2つのオプションのどちらを使用しても結果は同じです。次の図のように、データベースファイル自体はすでに作成されていますが、まだそのデータベースは以降のSQL操作の対象として選択されていません。

データベースに対して操作をおこなう前には、そのデータベースを選択する必要があります。その方法の一つがSQLコマンドUSEです。以下に示します。

Workbenchを使用する際には、ここで1つ重要な点を考慮する必要があります。コマンドラインで操作をおこなう場合、この時点では「02行目の内容」だけを入力すればよく、そのまま次のステップに進むことができます。しかしWorkbenchでは処理の流れが少し異なります。ここで2つの稲妻アイコンをハイライトしている点に注意してください。これがどのように動作するのかを見ていきます。SQLのスクリプトを作成する際には、複数のコマンドをまとめて記述することがよくあります。このスクリプトはドキュメント目的としても使用されます。しかしスクリプトを使用する場合には、いくつか追加の注意点があります。まず、スクリプトを一度に実行する場合には問題は発生しません。しかし同じスクリプトを段階的に実行しようとすると、最初から実行し直そうとした際に問題が発生します。このためSQL学習を途中で諦める人が多く、これは典型的なつまずきの原因の一つです。

さて、ここでは02行目だけを実行したいとします。そのためには3つの方法があります。1つ目は、02行目を選択し、左側にハイライトされているボタンをクリックする方法です。2つ目は、02行目にテキストカーソルを置き、右側のハイライトされたボタンをクリックする方法です。このときカーソルのアイコンが表示されていることに注意してください。この場合、カーソルが置かれている行のみが実行されます。

3つ目の方法もあります。これは主に、コードがすでに部分的に実行されている場合でも、最初から強制的に実行したいときに使用されます。この場合、SQLでテスト状況を作成する必要があります。コードを最初から実行しようとすると、01行目でエラーが発生します。なぜこのようなことが起こるのでしょうか。それはSQLがデータベースファイルを再作成しようとするためです。しかしそのファイルはすでに存在しているため、この試みは失敗します。その結果、以降のコードは実行されません。これは左側のアイコンを、行を選択せずにクリックすることで確認できます。

スクリプトを扱う際には、既にデータベースが存在している状態で、その中身だけを変更したいというケースが頻繁にあります。このような場合、スクリプト自体を変更するためにデータベースを削除するという方法は避けるべきです。この問題を解決する方法の一つは、01行目をダブルダッシュ（--）を使ってコメントアウトすることです。これは以下の図のようにおこないます。あるいは、別の方法もあります。

前の図で見たように、SQLコードをコメントアウトする方法には2つあります。1つ目の方法は、図に示されている通り、01行目がコメントとして認識される方法です。この方法は、単一行をコメントアウトする必要がある場合に有用です。しかし複数行をまとめてコメントアウトすることも可能です。その場合はMQL5と同様に、スラッシュ2つではなく「スラッシュ＋アスタリスク（/* */）」を使用します。

さて、先ほどの方法でも対応は可能ですが、実際にはデータベース内にすでに存在しているために失敗する可能性のある要素が多く含まれる長いSQLコードの場合、この方法は十分ではありません。そのため、より洗練された解決策が必要になります。この解決策は次の図に示されています。

図を確認すると、01行目に別のコマンドが使用されていることが分かります。しかしこのコマンドによってスクリプトは正しく期待通りに実行されます。これは、データベースファイルが存在しない場合には新規作成され、すでに存在している場合にはエラーとして扱われないためです。つまり、ファイルの存在有無を事前に確認する構造になっています。このようなIFコマンドを用いた構造はSQLでは非常に一般的であり、特にデータベースの長期的に繰り返し使用されるスクリプトでは頻繁に見られます。実行が完了すると、図に示されている結果が得られます。つまり、データベースファイルが現在の使用対象として設定されます。

ご覧の通り、すべては非常にシンプルかつ実用的です。重要なのは、それぞれの命令やコマンドが何をするのかを理解することです。コマンドやその組み合わせを暗記することに時間を費やす必要はありません。それぞれの役割を理解し、必要に応じて使えばよいのです。したがってこの時点で、MetaEditorで到達した段階と同じレベルにあります。次に扱うコマンドはMetaEditorでもWorkbenchでも使用可能です。このコマンドはこれまでよりやや複雑ですが、知識は少しずつ積み重なっていきます。

テーブルの作成

テーブルを作成するためのこのコマンドは、特に学習段階において最も頻繁に使用するものの一つです。その目的は、後に別のコマンドによってデータを格納するためのテーブルを作成することです。しかし、これまでのコマンドとは異なり、ここから先は複雑さが増し、最初は困難に感じる場合があります。ただし、慣れれば理解できるようになるので心配する必要はありません。最終的にはこのコマンドの使い方を理解できるようになります。

問題は結局ひとつです。つまり、テーブルを作成する前に、そのテーブルに格納するデータをどのようにモデル化するかを事前に考えておく必要があるということです。この点は、SQL学習の初期段階において間違いなく最も難しい部分です。理由は単純で、実装を開始する前に「何を作るのか」を明確に想定しておく必要があるためです。何千ものことを計画したとしても、テーブルに格納するデータの型を適切に設計できていなければ、それらはすべて無意味になります。適切なデータ型の選択とは異なり、データの配置順序自体はそれほど重要ではありません。しかしデータ型を誤ると、後から新しいデータに対応できない不適切なテーブルを作成してしまうことになります。

一方で、あまりに汎用的な設計にしてしまうと、必要以上にリソースやストレージを消費することになります。そのため、まずは利用可能なデータ型を学習することを推奨します。これは特定用途のデータベース設計をおこなう前におこなうべきです。この記事の末尾には参考リンクを掲載する予定ですので、そこから学習を始めてください。

まずはそこからで構いません。この分野については追加情報を自ら探すべきです。幸いなことに、各データ型について詳細に解説している情報は多数存在します。誰かが答えを与えてくれるのを待つ必要はありません。

説明を簡単にするため、デモ目的として次のシナリオを想定します。B3（ブラジル証券取引所）のある銘柄について、価格履歴を管理したいとします。最も単純な方法は、以下のようにWorkbenchを使用することです。

SQLコード自体は複数行に見えますが、実際には1つのコマンドとして扱われます。結果はWorkbenchのschemas領域に表示されます。ただし、このテーブルは作成され、値を受け取ることが可能であるにもかかわらず、場合によっては適切ではありません。その理由は後ほど説明されます。その前に、同じテーブルをMetaEditorで作成する方法を見てみます。これは下の画像で確認できます。

ご覧の通り、コマンドは完全に同一であり、結果も同じになります。Workbenchで実行できるほぼすべてのコマンドはMetaEditorでも実行可能であり、動作します。ただしここで重要なのは「ほぼすべて」と言っている点であり、「すべてのコマンドが実行可能」という意味ではありません。SQL上では実行できるものの、MetaEditor経由では実行できないコマンドが一部存在します。この点については後ほど簡単に触れます。ただしここでは急ぐ必要はありません。

次に、このテーブルが特定のシナリオにおいて不適切である理由を理解します。最初の理由はモデル自体にあります。なぜこのようなことが起こるのでしょうか。本来は価格データを保持するためのものではないのか、と思うかもしれません。確かに価格値そのものは取得できます。重要なのは価格履歴を保存することです。このモデルではそれが十分に対応できません。つまり現在の価格のみを保証する構造になっており、履歴データを扱うには不十分です。

そのため追加情報が必要になります。例えば日付や時刻などです（ケースに依存します）。仮に終値のみが必要であるとします。その場合、毎日新しいデータをテーブルに追加することになります。したがって先ほどのコードも修正が必要になります。

ここで、「なぜ最初からこうしなかったのか。なぜテーブル作成後に修正するのか」という疑問が生じるかもしれません。これは意図的です。テーブルに新しい列を追加する方法を示すためです。すでに述べた通り、オブジェクトの作成順序は重要ではありません。SQLはそれらを正しくデータベースに格納します。次に実行すべきコマンドは、アニメーションで示されているものです。

このコマンドをMetaEditorで08行目から実行すると、同じ結果が得られます。すなわち、価格取得の日付に関するデータを格納する新しい列が作成されます。これは以下の通りです。

その後、同じ結果をWorkbenchで得るためには、以下のコマンドを実行します。

これらのフィールドに入力される値やその準備方法については、別の機会に扱います。実際、データベースへの値の挿入や削除は慎重に行う必要があります。むやみに変更を繰り返すべきではありません。そのような方法では、データベースは長期運用に適さないものになってしまいます。理想的なのは、計画に基づいて要素を追加・削除し、データベースを主にクエリ用途として使用することです。

設計を先に考える

本記事では繰り返し述べてきたように、このシンプルなデータベースは動作はするものの、理想的ではありません。これは、どのように使用するかという計画次第で、ストレージ消費量の面でより最適化できる余地があるためです。しかし、ここで「なぜストレージ容量を気にする必要があるのか。足りなくなったらディスクを買えばいい」と考えるかもしれません。それも一つの選択肢ではありますが、それは問題の本質的な解決にはなりません。問題はディスク容量ではなく、データベースの設計方法および使用方法そのものにあります。

ここで述べる内容は問題の本質の一端にすぎません。データベースに関してより深い経験があれば、この問題がさらに根本的なものであることが理解できるはずです。実際、この分野で専門家を目指す人向けの専用コースも存在します。ただし、本記事では詳細には踏み込みません。このテーマは1〜2本の記事で扱える範囲を大きく超えているためです。

重要なのは、SQLプログラミングを少し学んだり、データベースの教科書を読んだだけで「データベースを扱える」と考えることは不適切だという点です。そのような主張ができるのは、この業界で長年実務経験を積んだ後に限られます。そしてそのような立場にあっても、完全な自信を持ってそう言う人はほとんどいません。

理由は単純で、データベースは非常に広い領域であり、多くの側面がすでに研究されていますが、個々のケースはすべて異なるためです。つまり、単一の万能解は存在しません。

では、B3（ブラジル証券取引所）で取引される銘柄の価格履歴を保存するための、この8行のシンプルなスクリプトにおける問題を見ていきます。最初の問題は、価格を保存するフィールドには、0.00〜999.99の範囲の値しか入力できないことです。つまり、一部の銘柄はこのテーブルに保存できない可能性があります。これは、これらの銘柄の価格がテーブルの想定する範囲と一致しないためです。この問題は追加の列を作成することで解決できますが、その結果として、コード列または新しく追加された列のいずれかが、データベース内で不要なストレージを消費することになります。

2つ目の問題は、価格日時を保存するレコードはISO 8601形式を使用していることです。ここで重要なのは、この形式がデータベースにとってどのような意味を持つのかという点です。そのためにはまず別の問いに答える必要があります。「いつからいつまでの価格データを保存するのか」という点です。この期間の定義によって、より適切な形式を選択でき、結果としてストレージ消費量を削減し、データベース全体のパフォーマンスを改善できます。

理解のために次のように考えてください。1年は365日ありますが、取引所は必ずしも毎日開いているわけではありません。しかしここでは、毎日取引が行われると仮定します。この場合、SmallInt（符号付き）を使用すれば0〜32767の範囲を表現できます。これは約89年分の日次データをカバーできます。符号なし（0〜65535）であれば約179年分をカバーできます。それにもかかわらず、ISO 8601形式のように多くのバイト数を使う代わりに、わずか2バイトで済ませることができます。179年分の日次データが蓄積された場合、その差がどれほど大きなデータ量になるかは想像できるはずです。

3つ目の問題は先ほどと同様にストレージに関係していますが、対象となるフィールドは異なります。ここでは銘柄名に関する問題です。この問題はさらに複雑です。なぜなら、銘柄名は時折変更されるためです。しかし、銘柄名が変わったとしても、それが示す企業の本質や挙動が変わるわけではないと考えるなら、履歴そのものは影響を受けません。

さて、市場に関係なく取引される銘柄数には上限があります。その中で、価格履歴を取得したいと考えるのは一部の銘柄に限られます。それにもかかわらず、1バイトで255銘柄まで表現できるにもかかわらず、なぜ6バイトも使用する必要があるのでしょうか。

ここで再び前の問題に戻ります。長期的に見れば、どれだけのバイト数が節約されるかを考えてください。さらに、銘柄名が変更された場合でも、過去データを書き換える必要はなく、1つのエントリを変更するだけで済むという利点もあります。

最終的な考察

本記事では、可能な限りシンプルかつ理解しやすい方法で、基本的なデータベースの作成方法を示しました。また、Workbenchで使用できるほぼすべてのコマンドはMetaEditorでも使用可能であり、同じ結果を得られることを示しました。ただし、MetaEditorでは使用できない命令が1つ存在します。本記事ではそれは扱っておらず、またデータベースへのデータ入力やクエリ実行の方法についても説明していません。

しかしこのテーマは非常に広範であるため、オンライン調査、講座、または関連書籍を通じて学習することを推奨します。いずれにせよ本記事では、MQL5におけるSQL利用のための最低限の材料を提示するため、さらにいくつかのコマンドを紹介します。次の記事では、SQLをもう少し詳細に扱います。

参照文献

ISO 8601

DataTypes in SQLite

MySQLオンラインマニュアル

ファイル	説明
Experts\Expert Advisor.mq5	Chart TradeとEA間の相互作用をデモンストレーションする（相互作用にはMouse Studyが必要）
Indicators\Chart Trade.mq5	送信する注文を設定するウィンドウを作成する（Mouse Studyが必要）
Indicators\Market Replay.mq5	リプレイ/シミュレーションサービスと対話するためのコントロールを作成する（Mouse Studyが必要）
Indicators\Mouse Study.mq5	グラフィカルコントロールとユーザー間のインタラクションを提供する（リプレイシステムと実市場での運用の両方に必要）
Services\Market Replay.mq5	市場リプレイ/シミュレーションサービス（システム全体のメインファイル）を作成および維持する
Code VS C++\Servidor.cpp	C++で作成されたソケットサーバーを作成および維持する（ミニチャット版）
Python Server.py	MetaTrader 5とExcel間の通信用のPythonソケットを作成および維持する
Indicators\Mini Chat.mq5	インジケーターを使用してミニチャット機能を有効にする（サーバーが必要）
Experts\Mini Chat.mq5	EAを使用してミニチャット機能を有効にする（サーバーが必要）
Scripts\SQLite.mq5	MQL5でSQLスクリプトを使用する方法を示す
Files\Script 01.sql	外部キーを持つシンプルなテーブルの作成方法を示す
Files\Script 02.sql	テーブルに値を追加する方法を示す