第1回はデータベースにアクセスするAPIで最も広く使われているSQLという言語の実行モデルを再確認します。なぜこの言語がリレーショナル・モデルのみならず他のデータ・モデルに対しての操作にも使われるようになったのか、それは実行モデルの汎用性に一因があります。
今回は汎用性を実現する実装の全体像についてみていきます。連載の第2回以降ではデータ・アクセスの効率を高めるそれぞれの構成要素についてみていく予定です。最新情報の棚卸を通じて、アプリケーションとデータベースのパフォーマンス改善や、連携のヒントとなれば幸いです。なお、本連載で例として挙げるデータベースはオラクルが提供しているものが多いですが、オラクル製品を使っていない方にも参考にしていただけるように解説していきます。
対象読者
この連載では以下の読者を想定しています。
- データ資産を活用する、新しいアプリケーションの構想や設計を担われる方
- データ基盤の運用を担われている方や、今後の検討をされる方
- 新たに開発するアプリケーションの、最適なデータベースをお探しの方
- 目的別データベースから、価値ある情報を素早く引き出す検討をされる方
データベース・マネジメント・システム（DBMS）の階層構造
データベース・マネジメント・システム（以下、DBMS）の技術の解説というと多くの場合、トランザクション分離レベルの実装やメモリー管理、ストレージ管理などの内部実装の階層を区別したものになる傾向があります。ある特定のDBMS実装を学ぶにはその階層分けでもよいのですが、この連載では少し違った切り口で区分します。それは「1. API」「2. データ・モデルとデータ型」そして「3. アーキテクチャと実装」の3階層です。
1つ目の階層はAPIです。DBMSの主流であるリレーショナル・モデルの話が出てくるとき、大抵の場合SQLがほぼセットで扱われています。ですが、SQLというのは実はデータ・モデルにアクセスするAPIの1つでしかありません。SQL以外を見てみても、Key Value Storeはデータへのアクセス・パスがDBMSによって決め打ちされたAPI（と一体化したデータ・モデル）ですし、RESTはHTTPのメソッドを使用したAPIです。
2つ目の階層はデータ・モデルとデータ型です。データ・モデルはアプリケーションが扱うデータの関連を定義したデータ構造の抽象概念です。データ・モデルにはリレーショナル以外にもドキュメントやグラフなどがあり、データ型にも文字列や数値だけでなく画像などの非構造化データもあります。これらDBMSのデータ・モデルやデータ型にアクセスするインターフェースがAPIの階層です。
そして3つ目の階層がアーキテクチャと実装です。DBMSは極めてサイズの大きなデータ容量を扱うため、アクセスを高速化するアーキテクチャと実装の工夫がDBMS内の様々な階層で行われています。索引やパーティショニング、イン・メモリー技術やクラスタ構成などです。クエリーの性能やスケーラビリティを決めるのはアーキテクチャと実装の階層であって、抽象概念を扱うAPIやデータ・モデルの階層ではありません。
JavaやPHPなどの言語を使って記述されるアプリケーションのコードにはDBMSのAPIを記述してデータ・モデルとデータ型にアクセスします。本来、APIというのはApplication Programming Interfaceの名前の通りインターフェースであり、そのAPIを呼び出す側のコードはAPIの内部実装をなるべく気にしなくてもよいようになっていることが理想です。インターフェースと実装の分離はプログラミングの基本です。これに照らし合わせると、アプリケーションのコード設計はDBMSのAPIとデータ・モデルだけを気にするべきでDBMSの内部実装を気にするべきではない、となるわけですが、なぜそのようなことが可能になっているのでしょうか？
