二層クライアント・サーバ型 データベース・システム
データファイルへのアクセスを専らデータベース・サーバだけが行い、ネットワーク上に分散するユーザPCのアプリケーションはデータベースサーバと通信することで間接的にデータアクセスを行うものです。
メリット
- データベースが比較的安全に保たれる
- クライアント・アプリケーションと、データベース・サーバ間の通信量は、ファイルサーバ型のシステムに比較して激減するため、LAN内のシステムにおいてはネットワーク回線がボトルネックになることはまず起こりえない
- 多数のデータベース･トランザクションを同時に処理できるようになる
- 接続ユーザ別に適切にセキュリティ・レベルを設定できる
- 多くの製品で、サーバ上に一部のアプリケーション機能を登録する「ストアド･プロシージャ」を利用でき、通信量をさらに減らせる
- データベース・サーバ1台のハードウェアを増強することで、システム全体の性能を引き上げることができる
デメリット
- データベースアプリケーションと、ファイルサーバの間の通信量がまだ大きい場合が多く、WAN越しのアクセスの場合はネットワーク回線がボトルネックとなって性能が低下したり、通信が切れてクライアントアプリケーションの動作が不安定になったりする。
- 一般に、クライアント・サーバ間の通信接続の数に比例して、データベース・サーバ上でメモリ・リソースが消費されるため、ユーザ数が一定レベルを越えて増加した場合に、サーバーのメモリが不足し、性能が低下する。
- データベース・サーバ製品には、もともとハイエンドのユーザ向けに開発された製品が多く、さまざまな設定変更によって性能を向上させられる反面、必要な設定項目が莫大で、管理者の負担が大きくなりやすい。そもそも、データベース・サーバーを常時稼動させつづける必要があり、そのための管理工数の発生は避けられない。
コメント
多数のユーザが接続する環境において、データの安全とシステムの性能を確保できるのがこの形式です。このセグメントの支配的な製品であるOracle やMicrosoft SQL Serveは、最低数万円～数百万円以上のサーバーライセンスが発生する高価な製品ですが、毎日大量のデータが更新される大規模な業務システムの構築には、このタイプのアーキテクチャを採用するのが無難です。
しかし、現在主流のRDBMS製品のクライアント・サーバ間通信は、LAN内で使用することを前提に設計されているため、システムのユーザが地理的に分散した拠点からインターネットやWAN回線越しにアクセスする場合には、十分な性能を発揮できません。また、同時に数百人を超える多数のユーザが接続するような場合にも、大きな負荷がかかるデータベース・サーバのリソースがボトルネックとなる可能性があります。こうなってきた場合は、後述の三層クライアント・サーバ型のアーキテクチャに移行する必要があります。
なぜクライアント・サーバ型のデータベース・システムは障害に強いのか
このタイプのシステムの場合、データベースファイルに直接アクセスするのはもっぱらデータベース・サーバ上のプロセスに限られ、クライアント・アプリケーションはどんなに多数存在しても、データベース・サーバとの通信を通じて間接的にデータにアクセスするだけです。そのため、クライアントPCで障害が発生しても、データベース・サーバがその状況に対処できるように設計されていれば、データの安全は保たれるのです。(データベースの更新はトランザクションという単位にまとめて処理されるようになっており、クライアントとの接続がトランザクションの途中で切断された場合には、トランザクション開始前の状態にデータを戻す（ロールバック）処理が行われます)
また、ハイエンドのDBMS製品には、データベース・サーバを稼動させ、データベースを利用可能状態に保ったまま、データベースのバックアップを取得できる機能が用意されています。24時間稼動が求められる場合や、常時大量に発生するデータベースの更新について、特に安全性が重視される場合には、これらの製品を選定することになります。
データベース・サーバの安定稼動を保つためには、データベース・サーバのマシン上で、なるべく他のアプリケーションを実行しないようにすることがまず大切です。勿体無いように見えても、データベース・サーバに、ファイルサーバやプリントサーバを兼ねさせることは避けた方がよいでしょう。さらに万全を期すならば、十分なメモリ・ハードディスク・CPUパワーを備えたマシンをデータベース・サーバに用いた上で、このサーバを厳重に管理された部屋に隔離します。悪意の侵入者からデータを守るには、ネットワークのセキュリティのみならず、物理的なセキュリティを確保することも重要です。もちろん、建物が地震で倒壊するようではいけません。
なぜクライアント・サーバ間の通信量が、ファイルサーバ型に比べて減るのか
ファイルサーバ型のシステムの場合は、それぞれのクライアント・アプリケーションがデータベースファイルを必要に応じてスキャンしていましたが、クライアント・サーバ型システムの場合は、データベースファイルのスキャンはデータベース・サーバのみが行い、それぞれのクライアント・アプリケーションは、検索結果のデータや、更新内容のデータのみをサーバとやりとりします。ゆえに、通信量が減るのは当然です。
代表的な製品
| Oracle | |
| このカテゴリの代表的なハイエンド製品です。早くからレコード単位のロック機構を採用し、巨大データベースの安定稼動で一番実績のあるDBMSです。PL/SQLという開発言語によって、アプリケーション機能をデータベース・サーバ上で構築することが可能です。日本の企業向けデータベース市場では圧倒的な強さを誇っており、データベース技術者は仕事上、まずOracle(PL/SQL)は知っておいた方が有利です。お金さえかければ、際限なく性能を上げていけるところがすごいところです。ただし、高価で、管理の手間がかかるシステムであるため、中小規模以下のシステムにまで、わざわざ導入する必要があるかどうかは疑問です。それにもかかわらずSIベンダがOracleのシステムを提案してくるとしたら、それは「このユーザはお金持ち」と思っているか、Oracle技術者が余っているかであると考えてもよいでしょう。
性能と安定稼動のために、本格的なシステムの場合は、UNIXマシンをデータベース・サーバに使うのが普通です。 |
|
| Oracle 8i Enterprise | 260万円(25ユーザ)～：マルチプロセッサのマシン性能を引き出せるバージョン |
| Oracle 8i Standard (Workgroup Server) |
19万円～ (1ユーザ39,000) |
| Oracle 8i Personal | シングルユーザ限定の開発・テスト用 |
| Microsoft SQL Server | |
| マイクロソフトのDBMS製品です。Windows NTマシンをデータベース・サーバとして使い、管理の手間もあまりかからないため、データベース管理に専任の担当者を置かずに運用するには、Oracleよりも無難な製品です。ストアドプロシージャの作成にはTransact-SQL(Sybase Adaptive Server Enterprise と共通)を使い、機能的にも見劣りはしません。性能面でも、ハードウェアに十分コストをかければ、やはり際限なくパワフルといえるでしょう。
マーケットでは強敵Oracleの前に苦戦しており、DBMS本来の機能に加えて、データ分析などの付加機能を充実させて対抗しています。これらの付加機能を使うユーザにとっては割安な買い物になり得ます。（Oracleの場合は、同様の機能が大抵サードパーティから売り出されています） 今のところSQL Server 導入時に問題なのは、日本のデータベース技術者の多くがOracle技術者であるため、SQL Serverでのシステム構築をやりたがらないことでしょう。 それでもMicrosoftには資金力があり、将来にわたってOracleとともに主要製品でありつづけると思います。 |
|
| 価格 | オープンプライスですがOracleと同等か少し安い程度でしょう |
| Sybase (Adaptive Server Enterprise) |
|
| 市場での存在感は最近下降ぎみですが、かつてはOracleと覇を競い合った正統派ハイエンドDBMSです。個人的には、昔々、SYBASE11のプロジェクトにどっぷり浸かっていた時期もあり、未だに懐かしい思いでいっぱいです。Microsoft SQL Server は、もともと Sybase の旧バージョンのソースを買ってスタートしており、今はすっかり別物に進化したものの、ストアドプロシージャを記述するSQL拡張言語の Transact-SQL が両者でほぼ共通しています。 なお、Sybase SQL Anywhere は全く別の、PC＆モバイルDBユーザをターゲットとし、PCとモバイル環境との間でのデータの双方向レプリケーションなど、おもしろい機能を持った製品です。 |
|
| 価格 | 62.4万～ |
上記三つの製品が、代表的なデータベース・サーバー製品です。この二つは何と言っても莫大な開発費が投じられており、高価なハードウェアを用意することで、F1レーシングカー並みの、けた違いの性能を引き出せるシステム構成が可能です。現在の世界記録などは、ここ→www.tpc.org
で公開されていますが、ハードだけで10億円ぐらいかかる世界です。
単なる二層クライアント･サーバという以上に、さまざまな周辺の機能が付加されています。そういう意味で、他のシンプルな二層クライアント・サーバ型のDBMS製品と同列に比較するのは、ちょっと問題があるかもしれません。
いずれにせよ、これらの高価な製品がデータベースのすべてであるように誤解されていることが、大企業以外の事業所にクライアント・サーバ型のデータベースが普及できない原因であると思います。
| Interbase | |
| ボーランドの製品です。当サイトにはDelphiプログラマの方が多く来るのでご存知かもしれませんが、世間での知名度はまったくない、マイナー製品です。SQL Server よりも、ずっと簡単なDBMSで、管理の手間はほとんどかからず、ユーザ数1,000未満ぐらいまでの範囲で使え、ストアドプロシージャ機能もあって、なかなかの高性能です。オープンソース版があるので、導入時のソフトウェアコストはタダになってしまいます。Delphiには、Interbaseにネイティブにアクセスするためのコンポーネント IBX が付属しますので、開発は楽です。問題はシステムのインストールと導入後のメンテナンスですが、本当は、手がかからないデータベースなのですけれども...聞いたことのない製品を運用するのは、ユーザにとって恐いというのもよくわかります。導入後＆運用まで面倒を見るシステムベンダーにとっては、良い選択肢になるかもしれません。 参考URL: Borland: www.interbase.com |
|
| 価格 | 6万～（10ユーザ25万弱） |
| MySQL / PostgreSQL | |
| Linuxの世界で育ってきたオープンソースのデータベースです。とりあえず、無料で使えて、そこそこ高機能です。よってコメントはInterbaseのそれに準じます。とはいえ、自分でWebサイトを運営しようとして、アメリカのウェブ・ホスティング・サービス会社と契約すると、MySQLやPostgreSQLを使えるということに気がつくことも多いはずです。このようにMySQLやPostgreSQLは、主にWebアプリケーションのバックエンド向けに使われることが多く、アプリケーション開発用のインタフェースは、PerlやPHPで発達してきたため、Windows上で動作するクライアントアプリケーションを作るための環境はInterbaseに比べると貧弱です。
Web開発者向けという位置付けでよいでしょう。 |
想定されるアプリケーションと、実装例
実際のところ、大企業などで、すでにOracleの基幹業務データベース・システムが構築されている場合、そのシステム自体のクライアントアプリケーションとして、さらに、巨大なシステムの小回りの効かないところを補完するシステムとして、クライアントアプリケーションが構築されることになります。
| Oracle + ADO - Visual Basiｃ Oracle + oo4o - Visual Basic Oracle + BDE - Delphi Oracle + DOA - Delphi |
|
| ユーザ数 | 数人～数十人程度 |
| ネットワーク | LAN |
| DBMS | Oracle |
| クライアント | Visual BasicもしくはDelphiでGUIを構成 |
| データベース接続 | OCI(Oracleネイティブ) または ADO(MS ActiveX Data Objects)または BDE(Borland Database Engine) |
| Oracleクライアントの作成環境としては、いくつかの開発言語や、データベース接続技術の選択が存在します。 言うまでもなく、弊社のお勧めは最後の Oracle + Direct Oracle Access + Delphi なのですが...（笑）こちらを読んで納得していただけたら幸いです。（→ Delphi + ORACLE アプリケーション開発） |
|
| SQL Server + ADO + Visual Basic SQL Server + ADO Express + Delphi |
|
| ユーザ数 | 数人～数十人程度 |
| ネットワーク | LAN |
| DBMS | SQL Server |
| クライアント | Visual BasicもしくはDelphiでGUIを構成 |
| データベース接続 | ADO |
| SQL Server への接続方法として最も効率よいのはADOです。DelphiからADOを利用するには、Dephiに付属して提供されるADO Expressを使えばよいでしょう。Delphi5 Professionalの場合は ADO Express が別売りになってしまいますので、この際Delphi6にアップグレードするか、倹約したければDiamond ADOを試してみるとよいでしょう。 BDEによるODBCアクセスは、ナンセンスなので、候補にはなりません。 |
|
| Interbase + Interbase Express + Delphi | |
| ユーザ数 | 数人～数十人程度 |
| ネットワーク | LAN |
| DBMS | Interbase |
| クライアント | Delphi |
| データベース接続 | Interbase Express または dbExpress ? |
| Interbase は、Delphiユーザしか使わないでしょう。Interbase Express (IBX)は、ボーランドから無料で入手できます。日本ではあまり知られていませんが、IBXの代わりになる接続技術として、Interbase Objects(IBO)も利用可能です。もともとボーランドはIBOを買収しようと申し出て、作者に断られてしまったため、別の個人から権利を買い取って作ったのがIBXであるという経緯もあり、IBOの方が製品として安定しているという評判です。 |
|
