|
すべては表から始まった |
|---|
図1：パンチカードデータベース
|
このころは，データベースということを意識して，パンチカードを使っていた人はいませんでした．それは，パンチカードはデータベースとなり得たかもしれませんが，そのデータベースを有効利用するDBMS（データベース管理システム）が存在しなかったからです．DBMSは，個々のアプリケーションの中に埋没して，その性能や機能は，そのアプリケーションを設計・開発した人のスキルに依存していました．
しかし，データ件数が増加して，効率的なデータ管理が必要になってくると，個々のアプリケーションごとにDBMS部分を組み込んでいては，非効率的になってきました．そこで，汎用性の高いDBMS製品が世の中に登場してくるのです．そして，このことが，汎用性を保ちつつ，性能を向上するという現在のDBMS自体の命題を生んだのです．
|
なぜ，リレーションが必要になったか |
|---|
現在主流であるDBMSは，RDBMSです．RDBMSが主流になったのは「表」というものを効率的に管理することができるだけではなく，リレーションという概念を導入して，人に優しいDBMSだったからです．
では，なぜ，リレーションが「人に優しい」のでしょうか．RDBMSは，リレーションを導入することにより，テーブルの親子関係を定義することが可能です．そして，親テーブルからデータを選択して，子テーブルに入れることにより，半角全角の違いや，送りかなの違いが発生しないようにできるのです．勘違いしないで欲しいのは，情報をコード化できるのが利点ではなく，コンピュータが不得意な同義語を入力しないように注意しなくてもよいのがリレーションの利点なのです（図2）．
そして，その利点を生かすようにリレーションをはるために，テーブル間のポインタとして，情報のコード化と主キーと外部キーによる情報の一元管理が必要になるのです．先ほど「人に優しい」と書きましたが，正確には「少しは人に優しくなった」ということになります．
図2：リレーションシップの例
しかし，RDBMSでデータを管理することが前提になりつつある現在では，本来，人が覚えていなくてもよいコード情報まで，いつのまにか覚える癖をつけられつつあります．郵便番号しかり，出席番号しかり，電話番号しかりです．どうして，住所を覚えているのに，郵便局のシステムが郵便物を振り分けるための単なるコードまで覚えていなければいけないのでしょうか．まあ，電話に関しては，名前でダイアルできたり，液晶に表示された一覧から名前を選べばダイアルできたりして，次第に人の感性に近づきつつあるのが救いです．確かに，Windowsシステムでいえば，コード入力とドロップダウンリストの両方をサポートすることによる入力の効率化などの側面があることはわかりますが，それは，コンピュータと人とのインターフェイスがまだまだ未成熟なために発生している過渡的な形態であることを忘れてはいけないと思います．
閑話休題．さて，本質的な問題は内因しているかもしれませんが，RDBMSはシステム開発に必要不可欠なファクターであることに変わりはありません．現時点では，実用的なシステムを構築するのに一番適したDBMSです．それは，RDBMSには，正規化という定量的な手法が確立されているからです．正規化は，きちんと正規化手法と業務を理解していれば，誰がやってもほぼ同じ結論を導き出せます．また，ER図などで表現したときに，曖昧さを排除することもできるので，開発者と業務を理解しているお客様との間で共通認識を得るのにも適しています．
|
DBMSの過去 〜ディスクI/O負荷軽減による性能向上 |
|---|
DBMSが使われだしたころは，複数の利用者が同時に使うシステムは，ホストコンピュータが主流であり，クライアントサーバーばかりかネットワークという言葉すらも縁遠いころでした（ホストコンピュータと端末の間は，通信回線とか通信路と呼ばれていました）．つまり，基本は，一極集中型であり，画面表示部分，ビジネスロジック，DBMSがすべてひとつのコンピュータに収まっていました（図3）．
図3：ホストシステム型DBMS
このころDBMSの性能を上げるには，ディスクI/Oをいかに速くするかにかかっていました．例えば，データのキャッシングなどは，このころに開発されたディスクI/O負荷軽減の対策なのです．もちろん，SQL ServerやOacleでもディスクI/O負荷軽減のためのチューニング項目を備えています．
|
DBMSの現在 〜ネットワーク負荷軽減による性能向上 |
|---|
一極集中型から，C/S型にシステムの形態が移り変わった現在では，ディスクI/Oがボトルネックになることはあまりなくなりました．ハードウェアの構成ミスによるメモリ不足を除いて考えると，ディスクI/Oではなく，ネットワーク速度がボトルネックになることが多くなったからです（図4）．つまり，DBMSをC/S型で使うことは，ボトルネックが発生したときは，以前の形態よりも確実に遅くなることを意味しています．では，どうしてC/S型が台頭してきたのでしょうか．それは，きちんと設計すれば，サーバー側の負荷を大幅に増大させずに，ユーザーインターフェイスを大幅に改善できるからです．
図4：C/S型DBMS
ストアドプロシージャ
C/S型のRDBMSも手をこまねいていたわけではなく，ネットワークの負荷を減らす工夫を用意してきました．それが，ストアドプロシージャと呼ばれるサーバー側で動作する構造化言語です（図5）．ストアドプロシージャを使うことにより，SQL文を複数発行しなければ生成できない情報を1個のストアドプロシージャの呼び出しで取得できるようになります．ストアドプロシージャは，ネットワーク負荷を軽減する以外にも，ビジネスロジックをサーバーで一元管理できるので，障害修正や仕様追加が発生してもプログラム配布の手間が要らず一極集中型のころのような感覚でC/Sシステムを管理できます．
図5：ストアドプロシージャの概念
分散処理
ネットワークの負荷を軽減するために，ストアドプロシージャは有効な手段ですが，マスタテーブルから一覧を表示したり，情報を次々に絞り込んでいくような使い道のときには，あまり効果がありません．このような目的を実用的に実現するには，レプリケーションなどの分散処理を行ないます（図6）．レプリケーションは，機能的には以前より実装されてきましたが，使いやすさや実用性がでてきたのは，ごく最近だと思います．
図6：レプリケーションの概念
Win95〜UNIXまでのスケーラビリティ
分散処理をさらに進めていくと，サーバまでではなく，クライアントにすらDBMSを搭載したくなります．そこで，Windows 95からUNIXマシンまで，周りにあるすべてのコンピュータで，同一アーキテクチャーのDBMSが動作します（図7）．開発が得意なDBMSを導入先に応じたOSに搭載することができます．
図7：マルチOS対応の概念
|
DBMSの（近）未来 〜ありのままの姿〜 |
|---|
モバイル対応
デスクトップマシンやそれにひけをとらない性能を発揮するノートブックマシンならば，サーバーと同じアーキテクチャのDBMSを動作させるのに十分なハードウェアスペックを保有しています．しかし，携帯用端末などのモバイルでの使い勝手を考慮した小型ノートブックマシンなどで使うのは，ハードウェアスペックがプア過ぎます．そこで，シングルユーザ用にシェイプアップしたDBMSが登場してきました．そして，モバイル用DBMSと社内のDBMSをレプリケーションできるようにして，社外で収集した情報を全員で共有したり，社内で保有している情報から必要な部分を持ち出したりできるようになります．特徴的なのは，レプリケーションの通信方法として，LANのような高品質な高速回線以外にも，携帯電話やインターネットメール，パソコン通信も使えるようになる点です．直出直帰で外出が続いても，自宅からパソコン通信などでレプリケーションデータをやり取りすることで，知りえた情報，知りたい情報を社内と共有できるようになります．
大規模対応
DBMSを取り巻く状況の中で一番の変化は，インターネットが急速に広まっり，DBMSへの接続ユーザー数が爆発的に増加したことでしょう．ユーザーが接続とサーバー側である程度のメモリを消費しますから，インターネットに対応するときに問題になってくるのは，必要メモリ量×ユーザー数がかなり大きくなってしまう点です．そこで，ひとつのコネクションを複数のユーザーで共有して論理的なユーザ数を減らしたりする工夫がはじまっています．
異DBMS間連携
DBMSがさまざまな部署で使われ始めるとDBMSを統一するよりも異DBMS間で接続する必要が生じてきます．この要望は，他社DBMSのリプレースに躍起になっているDBMSメーカにとっても渡りに船の要望だったようです．OracleとSQL Serverの相互接続が可能になったり，ホストコンピュータのDB2と相互接続できるようになると思います．この技術が使い物になるかどうかは，ODBCを使ってではなく，各社のネイティブインターフェイス間の接続ゲートウェイができるかどうかにかかっています．
論理モデルに対応した性能向上
正規化したデータモデルをそのままDBMSに定義してもテーブルのジョインが多発して，必ずしも良好なパフォーマンスを得ることができませんでした．そのため，一度正規化したモデルをDBMSの特性に合わせて，正規化を崩して定義しなければなりませんでした．これは必ずしもより良い方向性ではありません．そこで，スタージョインと呼ばれるテーブルのジョインを高速化しつつあります．
例えば，構造化プログラムやロジックの共通化もプログラムにとっては性能を低下させる要因です．しかし，その低下の度合いが気にならないくらい少ないために，性能向上よりも保守性などのその他の利点を優先しているのです．ですから，近い将来には，正規化くずしは性能向上の最後の手段として余り使われなくなるようになるでしょう．
ストアドプロシージャのオープン言語化
オラクル社やサイベース社が自社のRDBMSのストアドプロシージャ記述言語としてJavaを組み込みました．これは単にオープンな汎用言語を組み込んだということではなく，クライアントサイドでの有効な言語をサーバーサイドでも利用できるようにして，RDBMSの有効利用法の敷居を少しでも低くしようとしているのだと思います．しかし，ストアドプロシージャのJava化の流れにマイクロソフト社が乗るかといえば，乗らないでしょう．それは，Javaという言語を取り巻く問題からではなく，マイクロソフト社には，Visual Basicというクライアントサイドで成功を収めた自社言語製品が存在するからです．ですから，まったく根拠のない予想ですが，Visual Basic for SQL Serverという言語仕様が発表されて，SQL ServerのストアドプロシージャがVisual Basicで記述できる日がくるのではないかと思っています．
オブジェクト対応
DBMSには，RDBMS以外に，OODB（オブジェクト指向データベース）があります．OODBは，オブジェクト指向の考えをデータベースに適用したもので，現実の情報をオブジェクトモデルとしてとらえて，そのオブジェクトモデルをそのままの形でデータベースに格納すること念頭に置いています．OODBがあまり一般的にならないのは手軽に使える製品がないのも一因ですが，オブジェクトモデル化する定量的な方法が確定していないためでしょう．しかし，オブジェクト指向はこれからの開発ではますます必要なものなので，OODBをSQL文で使うとか，ORDBMS(オブジェクト指向RDBMS)などが主流になってくるでしょう．
|
おわりに |
|---|
MS-DOSのころには，ファイルシステムというのをかなり意識していたと思います．しかし，段々，ファイルシステムを意識することは少なくなってきたのではないでしょうか．いつの日かデータベースを意識せずにいつの間にか効率的にデータベースを使っているときがくると思います．そのときは，身近な家電の中にも高性能なデータベースが入っているかもしれません．
int21 ホームページ | PCDN ホームページ
Copyright (c) 1998 int21 Corporation All Rights Reserved.
For questions or comments, please send mail to: pcdn@int21.co.jp