AccessクエリとSQLの関係 デザインビューとSQLビュー

Accessに対して、SQL ServerやOracleなどは"本格的な"データベースという位置付けで説明されることが多い。
自分でもこのフレーズを何回となく、書いてきたかも知れない。

そんなことを言われると、Accessは本格的じゃなくて、亜流なのか、と思ってしまうが、Accessだってちゃんとしたリレーショナルデータベースである。
クエリデザイナでSQLを知らなくてもチョチョイとクエリを作れてしまう。とても「お手軽」な感じなので、格式ある伝統的手法ではないやり方でデータベースを使っているから、「本格的ではない」になるのかしら。
SQLを知らない人でもデータベースを扱えるように作られたAccessは、亜流だけど"すごい"、っていうことになるのかも。
それに、Accessだって、SQLビューにすれば、正式な作法であるSQLで「本格的なデータベース操作をできる」っていうことにならないか?
そういうわけ(どういうわけ?)でAccessクエリとSQLの対応がどうなっているのかをちょっと調べてみることにした。

Accessだってプロシージャや関数を作成することができるし、トリガーだってできる。決して亜流ではないわけである。

ビューの切り替え

まずは、基本的なことから。
Accessのクエリは3種類の表示が可能である。表示形態は「ビュー」と呼ばれており、以下のものが存在する。
 1 デザインビュー
 2 データシートビュー
 3 SQLビュー
これらのビューは、ツールバーの[表示]ボタンで切り替えられる。
ステータスバーでも切替られる。
1 デザインビュー
これが、SQLを知らない人がクエリを作成するときのデフォルトのビュー(表示形式)であろう。
Accessデザインビュー.png
2 データシートビュー
データを入力するときは、この表示形式を使うことになる。クエリを実行した結果でもある。
Accessデータシートビュー.png
3 SQLビュー
クエリの命令をSQL言語で表示するビューである。デザインビューで作成したクエリの内容と同等なSQL命令が表示される。
AccessSQLビュー.png
概念的には、1と3は同一の「クエリ定義情報」を異なる形で見せているだけで、実体としては同じ、と思って良い。
2は、クエリの定義と実行結果という決定的な違いがある。1と3は、クエリの定義を表示しているが、2は、クエリを実行した後の検索されたレコード情報を表示している。なので、デザインビューまたはSQLビューを表示している状態で「実行」ボタンをクリックするとデータシートビューに切り替わる。
Accessクエリビューの切り替え.png
この点が大きく異なるので、2のデータシートビューは対比するのに紛らわしいので、今後あまり話題にはならないかも。

デザインビュー

デザインビューをよく見ていくことにする。
まずは、大きく上下ふたつにわかられていることがわかる。
上部分
デザインビューの上半分には、テーブルまたはクエリを追加することができる。ここに表示されているオブジェクトからデータを検索してくることになる。
例では、テーブルfooのひとつだけが存在している。
クエリを作成する際に、テーブル、クエリを選択するダイアログが表示される。ここでfooを選択してクエリを作成したので、クエリ1にはテーブルfooが含まれているかたちとなっている。
SQLとの対比
クエリ全体は、ひとつのSELECT命令に相当する。上半分では、どのテーブルからデータを引っ張ってくるかの指定になるので、SQLでいうと、SELECT命令のFROM句に相当する。
SQLビューにしたときのSELECT命令を見てみると...
SELECT foo.*
FROM foo;
となっている。「FROM foo」のところがデザインビューの上半分に表示されている、と理解して欲しい。
Accessデザインビューの上半分.png
下半分
下半分は、クエリの抽出条件を設定するエリアとなる。
テーブルのどのフィールド(列)を取ってくるのか、はたまた、レコードの抽出はどういった条件とするのかを設定していく。
例では、条件らしいものは設定せず、fooテーブルのすべてを取ってきてね、といったルーズな設定にしている。
SQLとの対比
デザインビューの下半分は、SELECT命令のいろいろなところに反映されることになる。今現在は、foo.*しか設定していないので、SELECT命令のSELECT句だけが指定されている状態である。
Accessデザインビュー下半分.png
本日のところは、以上とする。
以降、抽出条件の詳細を追ってみることにする。
AccessクエリとSQLの関係 フィールド

投稿者プロフィール

asai
asai