データベースはそれ単体で利用するものではありません。多くの場合、アプリケーションを通じて操作します。SQLの話題に入る前に、アプリケーションとデータベースのつながり方を見ておきましょう。
- アプリケーションあってのデータベース -
一般に、リレーショナル・データベースは、SQL ServerやOracleなどに代表されるリレーショナル・データベース管理システム(RDBMS――Relational
Database Management System)を介して、クライアント・サーバー方式のネットワークで利用することが前提となっています。
しかし、クライアント・サーバー方式のネットワークでこれらRDBMSを利用するのは、そう簡単ではありません。データベースやネットワークに対する知識と経験、さらには、データベースを利用するアプリケーションを開発するための知識と経験も必要になってきます。
リレーショナル・データベースは、データベースそのものを制御したり管理したりする機構――RDBMSと、それを利用してデータベースを操作するアプリケーションの双方が機能して、はじめて意味を持ちます。
- ２種類の動作形態 -
データベースはデータベース・サーバーに保存され、サーバー側で稼働するRDBMSがデータベースを直接操作します。RDBMSに対してデータベースを操作する指示を出すのが、個々のアプリケーションです。
アプリケーションの動作形態は、その実行場所によって大きく二つに分かれます。
| ・ |
クライアントサイド
クライアント側のメモリ上で、クライアントのCPU能力を使って実行されるアプリケーションです。データベースのアクセスなど必要なときだけ、アプリケーションはサーバーに処理を依頼します。 |
・ |
サーバーサイド
サーバー側のメモリ上で、サーバーのCPU能力を使って実行されるアプリケーションです。アプリケーションはネットワークを介して、個々のクライアントに画面に表示するデータを送ったり、クライアントから送られてきた入力データを受け取ったりします。 |
- サーバーサイドはWebだけではない -
クライアントサイド／サーバーサイドという言葉は、Webアプリケーションの実行形態の分類としておなじみになりました。しかし、アプリケーションをクライアントとサーバーのどちら側で実行するかという区別は、Webアプリケーションに限らず存在します。
ASPやJavaサーブレットなどのWebアプリケーション実行方式が一般化する前には、CやVisual Basic(VB)で開発したOS依存型のアプリケーションが主流で、それらの多くはクライアントにインストールされてクライアント側で実行される、クライアントサイドのアプリケーションでした。
しかし、クライアント・サーバー方式以前のホスト方式では、ホスト・コンピュータで稼働するアプリケーションを複数の端末で利用する形態が一般的でした※１。その流儀を受け継ぎ、クライアント・サーバー方式のネットワーク上でも、テキスト端末でサーバー上のアプリケーションとデータをやり取りする形態が存在しました。
SQL Serverでも、クライアント用のツールでSQL Serverの稼働するデータベース・サーバーに接続し、テーブルに対して並べ替えやレコード抽出などを指示して、結果をクライアントのディスプレイに表示することが可能です。SQL
ServerなどのRDBMSはミドルウェアであってアプリケーションと呼ぶには無理がありますが、このような実行形態もまた「サーバーサイド的」であると言えます※２。
| ※１ |
今ではインターネットに取って代わられたパソコン通信も、ホスト方式の一形態です。パソコンは電話回線を通じてホストに接続し、パソコン通信ソフト（ターミナルソフト）を使ってホスト側で動作するプログラムとやり取りしました |
| ※２ |
考えてみれば、クライアントサーバー方式による分散処理は一極集中型のホスト方式に代わって、資源と機能を各コンピュータに割り振る仕組みですから、どのような実行形態も見方によってサーバーサイド的になります |
- SQLという共通言語 -
サーバーサイドであれクライアントサイドであれ、ネットワークでデータベースの管理・制御とそれを利用する機構とを分割した場合、アプリケーションはRDBMSに対してデータベースを操作するための指示を送らなければなりません。当然、その内容はアプリケーションによって異なります。
あるアプリケーションは、「Hanbai.dbというデータベースの“顧客”テーブルに対して“顧客番号=801325のレコードから氏名と住所を抽出せよ”」という命令を送りたいでしょうし、別のアプリケーションは「Zaimu.dbというデータベースの“支払”テーブルに対して“本年度第一四半期の支出総額を計算せよ”」という命令を送り出すかもしれません。その内容は、アプリケーションに課せられた目的によって、また、アプリケーションが操作されている状況によって、常に変化します。
このように、アプリケーションがデータベース・サーバーに対して発する処理命令は千差万別ですが、そのために用いる「言葉」まで千差万別では、RDBMSは大変です。英語とフランス語を理解できる人に、中国語で話しかけても意志は通じません。RDBMSは様々な処理命令の「言葉」を理解できるように設計されていなければならなくなります。
その問題を解決するのが「SQLという共通言語」です。
|
Accessも忘れないで！
SQL ServerやOracleなどの本格的RDBMSは、本文でも述べたようにその扱いが難しく、一朝一夕に技術をマスターできるものではありません。
そこで、手軽にリレーショナル・データベースを扱うアプリケーションを作れるよう提供されたのが、Accessに代表されるデータベース・アプリケーション開発環境です。Accessはリレーショナル・データベースを制御するRDBMSの機能と共に、その機能を使ってアプリケーションを開発する機能を持ち、作ったアプリケーションの実行環境にもなります。CやVisual
Basicなどの難しい言語を使うことなく、視覚的な画面設計と分かりやすいマクロ機能でアプリケーションを組み上げていけます。また、複雑なテーブルのリレーション設定やレコードの抽出命令も、GUIによって視覚的に行えます。
さらにAccessは、SQL Serverに接続してネットワーク上のリレーショナル・データベースを制御する機能も持っています。
何より、VBAを使わなくてもクエリとマクロだけでアプリケーションの中枢処理が構築できる点は、特筆に値します。Accessはプログラマーなどの技術者向けではなく、Excelに毛が生えた程度のエンドユーザー向けツールと捉えられる傾向が依然として強いようですが、筆者としてはAccessの「程良く簡単でそれなりに高度な」開発機能は、もっと注目されてよいと思います。 |
 |
|
|
