標準SQLとデータベースの入門知識！専門書の著者がSELECT文の書き方も解説

SQLはDBを操作するための言語です。ただしプログラミング言語とは少し異なっていて、データを2次元の表のかたちで管理するRDBという種類のDBを操作するために使います。ちなみにDBを格納するところは、RDBで「テーブル」と呼ばれており、Excelでいう「シート」のようなイメージで使えます。

例えば、ある塾の生徒に関するサンプルデータを、テーブル上で次のように管理してみました。「生徒マスター」というテーブル、「生徒番号」と「氏名」それから複数の校舎がある塾という想定で「校舎」という項目で作成しています。

基本のSQL文は「SELECT文」と呼ばれていて、例えば上記の「生徒マスター」のテーブルから、新宿校舎に通っている生徒の「生徒番号」と「氏名」を取得するためには次のように書きます。

「SELECT」の後には、「生徒番号」と「氏名」など欲しい項目を書いて、FROMの後ろにテーブル名を書きます。このSELECT文は本書のサンプルデータで試すことができます。詳しい書き方は、後ほど詳しくお伝えできればと思います。

RDBは多くのシステムやアプリケーションと深い関わりがあり、それに伴うエンジニアの業務はたくさんあるので、SQLについて知っておくと業務を円滑に進められます。例えSQLを直接書かないとしても、SQLがわかれば、データをどう取得しているか、そのためにどのようなDB設計になっているのかを理解した上で業務に臨むことができます。

他にも前任者から引き継いだファイルにデータを取り出すある種の“呪文”としてSQLのメモが残されているケースがありますね。“呪文”で取り出したデータをExcelに入れてそれを毎回加工しています、なんてことも無駄ですし、何より手作業はミスの元にもなります。SQLを書き換えて自分の欲しい形に直して取得する方が良いですよね。

もちろんです。私が関わっている範囲で言えば、財務会計や管理会計などの分野でもSQLが活用されていることがあります。SQLで過去のデータを色々な形で抽出して分析に使えるので、さまざまなシーンでの課題解決に役立ちます。また、SQLが頭に入っていると、DBの不備にも自然と気づくようになります。

典型的なのは「データをとりあえずその時必要な形で整えて、そのままメンテナンスし続けている」ケースです。そもそもがデータを正しく維持するための設計を行っていないので、データを更新するにも整合性のチェックのため多大な手間がかかる、あるいは整合性のチェックができない、新しい観点からデータを見なおそうとしてもあれこれ工夫しないと集計すらできない……。多くはExcelですが、ExcelでもDB設計を念頭に整備することでデータの使い勝手が良くなります。もちろんDBへの移行もしやすくなりますね。

テーブル作成に一から取り組むのはハードルが高いので、まずはSELECT文に親しむのが良いと思います。テーブルについては、例えば、サンプルデータをMicrosoft社などからダウンロードしても良いし、GUIツールを活用して作って見るのも良いでしょう。DBMS（RDBを使うためのシステム、データベースソフト）は、クラウドなどでも使用できますがそのためにはまた別の知識が必要なので、無料で入手できるDBMSを使ってローカル環境で試す方が手軽です。なので、まずは次のような流れでDBを構築して、自由に試せるローカル環境でSELECT文をいろいろ入力してみましょう。

SQLの基本的な記述ルールはいくつかありますが、まず「各単語は半角スペースまたは改行で区切って、文末には『;』を付ける」ということを覚えておきましょう。

はい、問題ありません。実際の入力例としては次のようになります。ここでは、studentsというテーブルにある「student_id（生徒のID）」と「student_name（生徒の氏名）」という列を表示していますが、どの書き方でもOKです。ちなみにWHEREで指定している「branch」には、生徒が通っている校舎の名前として池袋や新宿などの文字列が入っており、本書のサンプルデータ（sampledb）で実行できます。

次の4つのルールも合わせて覚えておくと良いと思います。

例えば、先ほどのテーブルで新宿校舎に通っている生徒についてコメントを入れたいときには、次のように記載します。

DBMS付属のGUI環境やコマンドラインツールでSELECT文を実行すると、その場で実行結果やエラーメッセージを確認できます。

まず最初に書くのは取得したい列を指定する「SELECT句」です。「SELECT 列名, 列名,」とほしい列を並べて書いたり、列同士で計算したりすることができます。複数の列を指定したい場合は、先ほどの例のように「,」で区切って並べます。また、列名を「*」にすると、指定したテーブルのすべての列が対象になります。

まず、絞り込みの指定は「WHERE」を使うので、取得するデータの条件は「WHERE〜」で示します。このWHERE句を使いつつ、複数の条件を「AND」と「OR」を組み合わせてSELECT文を打ち込みます。例えば「国語で100点」のデータを抽出するときには、次のようにANDとORを使います。

この場合は、「国語」と「100点」の両方の条件に当てはまったデータだけが「真」として抽出されますが、「OR」を使えばどちらか一方が「真」の場合でも抽出されます。ORを使ったSELECT文の例は以下になります。

ANDとORなら、ANDの方が優先されます。でも、両方を記載するときには、括弧で優先順位を明示しておく方が意図が明確になるのでおすすめです。

SELECT文に慣れてくると、次のように複雑なデータも抽出して分析できるようになります。これは、生徒と受講科目を表示して、各科目の平均点を追加したSELECT文です。SELECT文の学習用に作ったもので、塾の生徒以外も模擬試験を受けに来ているケースを考慮しているためちょっと複雑になっていますが、一度欲しい形のSELECT文を作ればいつ実行してもその時の最新データから一発で欲しい形のデータを取得できるというのもSQLの魅力です。

DBの設計というと壮大な話に聞こえるかもしれませんが、一つひとつの内容は意外とシンプルです。まず、DBを設計するときに役立つERモデルについて紹介します。

ERモデルのEはエンティティ（＝モノ）の略で、Rはリレーションシップ（関係）の略です。つまり、ER図は「存在するモノや事象」と「エンティティ間の関係性」の組み合わせでシステム内のデータやデータ間の処理構造を設計しています。ただ、元々のERモデル用の図よりも、RDB用に調整された次のような図の方が、テーブルやテーブル同士の関係性をイメージしやすいでしょう。

これは「生徒マスター」というエンティティと「試験結果」というエンティティがあり、試験結果の生徒番号は生徒マスターに必ず存在するというリレーションシップがある、ということを示しています。

これはRDB用の定義で、個々のデータ（レコード）を特定するのに使う項目を表しています。ここでは生徒を特定するのに「生徒番号」を使う、ということで生徒番号を主キーとしています。「試験結果」にもこの生徒番号を入れることで、「生徒マスター」と「試験結果」の関係性を示します。関係性のために入っている、つまり、両者を結びつけるために入っているのが外部キーです。このようにDBで管理したいモノゴトを図に落とし込んだものがER図です。

ER図を作る第一の目的はDBの設計ですが、事象をわかりやすく表現できるので全体を理解しやすくなります。ビジネスの解析および設計にも等しい作業として捉えられることもあり、事業を分析して検討することにも使われます。ER図を見るのはDBの設計をする人だけではなく、入出力プログラムを書くシステム設計者などが参照することも。ときには現場の実務担当者に見てもらうこともあります。

次のようなER図を見ていただくとわかりやすいと思います。例えば、「商品」「仕入先」「倉庫」のER図を作成しようとすると、いくつかのパターンが考えられます。どこにリレーションシップがあるのかによって、ER図は異なりますし、それによってテーブルや参照の定義も変わってくるわけです。

ちなみに、❶と❷をそれぞれテーブルの定義に直すと次のようになります。M1、M2、M3がそれぞれ商品、仕入先、倉庫のマスターで、各列の定義は省略していますが構造はなんとなくわかると思います。この部分はGUIで作れるようになっていることが多いので心配せずに挑戦していただければと思います。

大抵の方がつまずくのは、値のわからないデータを「NULL」として処理する場面です。例えば、塾の例でいうと「校舎が決まっていない」「電話番号が書かれていない」など、決められた項目に入れられる値がない場合にNULLと表現しますが、わからないときに何でもNULLとしてデータを入れていくとDBが機能しづらくなっていきます。

データを登録するときには便利かもしれませんが、その後のデータ活用・分析でNULLは扱いにくい値です。NULLは「不明」という特殊な値なので、計算や大小比較に使うことができません。NULLのデータが１件でもあると、SELECT文が予想外の結果を返すこともあります。

処理の負荷を下げるためにそのような処理を行う場合もありますが、本来は異なります。そもそも、どの列に入るのか決まっていないデータを登録していいのかという問題も。本来は必要事項がわかっているデータだけを登録するべきです。

NULLかどうかという判定はできるので、NULLを除外するという条件を加えます。とはいえ、まずはNULLが発生しないテーブルを検討することが大切です。生徒用のテーブルであれば、生徒番号や氏名はNULLを禁止、これらが判明するまでは登録しないという運用で良いはずです。生徒番号が未定であったり、さまざまな項目が不明な生徒も登録したいのであれば、それはどういう目的なのか、生徒番号が決まっている正規の受講生と同じテーブルで管理するのが適切なのか、などを検討します。SQLではテーブル作成時に「NOT NULL」を指定することでNULLを禁止することもできます。

データに混乱をもたらすこともありますが、上手く使えばNULLは便利なので、運用と設計の両軸で対策を考えていただければと思います。

「今までSQLを使ったことがあるけど利便性を感じられなかった」、「思ったようにSQLを操作できない」という方は、まずRDB用のDB設計について知っていただければと思います。今回の記事でもお伝えしたように、テーブルではなくDBに問題があることも少なくないからです。DB設計についても学びながら、SQLを日々の業務効率化に役立てていただければと思います。