こんにちは。入社１年目のS.K.です。７月の技術ブログを担当させていただきます。
今回のテーマは、SQLの理論的な背景を取り扱います。
SQLはデータベースを利用する際の基本のツールですが、だからこそ知っておきたいところですね。

表（テーブル）と関係（リレーショナル）

SQLはリレーショナルデータベース（RDB）の利用に必要な技術ですが、そもそもRDBとは何でしょうか。
簡単な説明として、Excelなどで見られる表形式のデータという記述を見かけますが、RDBは「表モデル」ではなく「関係モデル」と言われます。
では、「関係モデル」とはどういうことでしょうか。

「表」と「関係」の相違点として、以下の点が挙げられます。

• 「表」には重複するレコードが存在してもよいが、「関係」では許されない。
• 「表」の行は上から下へ順序付けられているが、「関係」では行の順序付けはない。
• 「表」の列は左から右へ順序付けられているが、「関係」では列の順序付けはない。
• 「表」は同一の項目に値を複数持たせることが可能だが、「関係」では許されない。

1に関して、SalesForceでは各レコードに対して固有のIDが割り当てられるので、完全に重複するレコードは存在しない事実があります。
2と3については、実際のSQLの文において凝ったことをしない限り、配列でよくあるインデックスによる指定は不可です。
4については、Excelをイメージするとわかりやすいですが、「一つの項目を分割して複数指定する」ということは許されないということです。

このようにみると、RDBはデータベースとして正確性・厳密性を重視して設計されているように感じます。
当然と言えば当然ですが、「順序付けがない」というのはちょっと驚きました。

RDBの何が優れているのか

現代において、データベースと言えばRDBを指す場合がほとんどです。
ではなぜ、RDBはこれほど広範に使われるようになったのでしょうか。

RDBが優れていた点として、言うまでもなく、テーブルというものが「表」に類似していることが挙げられます。
この特性は、Excelなどのスプレッドシートを使い慣れた人にとって、データの格納する方法が直感的にイメージしやすいという点があります。「表」によるデータ管理は、Excelなどの登場以前から一般的であったため、RDBのスタイルは人々に受け入れやすいものでした。

もう一点、RDBには優れている点があります。先ほど述べた、行と列が順序付けられていない点です。
プログラムを書くことに慣れ始めた人からすると不思議に思いますが、これはRDBの設計思想が関係しています。
もともと、RDBはプログラムの専門の教育を受けていない人に使いやすいデータベースとして作られました。そのため、扱いの難しい位置表現（アドレスやポインタなど）は徹底的に隠蔽されています。

なぜこのようをするのかというと、RDBでは「ループをなくすこと」を最重要の事項としているからです。ループはバグを起こしやすい箇所であるため、そもそもこれを行えないようにしました。実際、ファイルからデータを抽出する際などに、一般的なプログラムはループを必要とすることが多いですが、SQLではそもそもループが存在しません。ループがなくても、データを取得できるようになっています。

以上の長所は、RDBが一般に浸透する上で非常に重要でした。
特に後者は、アセンブラやC言語の後に続くJavaやPythonなどのプログラミング言語でも見られる動きです（その試みが上手くいっているかは別として）。
RDB（とSQL）は、後発のプログラミング言語に要請されていることを先取りしていたのです。

SQLでは、メモリ上の扱いを気にすることなく（パフォーマンスの問題を考えなければ）データを取り扱うことができます。

また、SQLの処理は一文で完結しています。前述したように、RDBの行には順序がなく、これを操作するSQLにはループの処理がありません。
つまり、C言語、JAVA、Pythonなどに代表される手続き型言語で行われる、一行ずつファイルを読み込むという操作ではありません。
SQLによるデータの取得は、データを一つずつ取得するというより、データベースという集合から条件に合う部分を切り取っているという考え方が近いです。

それが如実に表れている例として、SQLによるテーブルの自己結合があります。
SQLでは、もともとあるテーブルに別々の名前を付けて、直積や任意のキーでの結合が簡単に行えます。

図示したような簡単なケースでは問題になりにくいですが、より複雑な場合において、一般的なプログラミング言語で実行するのは少々手間でしょう（ライブラリなどで解決することもできますが）。当然ループが（以下略）なので、SQLがいかにデータベースの取り扱いに長けているのかがわかると思います。

これらの事実から、ループ内でSQLを実行することが避けるべき行いであることも自然とわかります。
集合の式一つで定義できるところを、わざわざ切り分けて個別に定義するのですから、数学的な観点からも無駄が多いですね。

感想

SQL・RDBの設計思想に触れ、JAVAやPythonなどのプログラミング言語との違いを学ぶことができました。
RDBの行や列に順序がない（最近では、列については違うようですが）こと、SQLが集合論ベースの内容となっているのは意外でした。
SQLをループ内で書いてはいけないというのも、とりあえず知っているに留まっていたので、この内容をやってよかったと思います。

難解なところや冗長な部分は極力省略してまとめたつもりでしたが、全体的に駆け足になってしまい、まとまりが足りない感じになってしまいました｡反省です。