1.2 データベースとは
そもそも、どうしてデータベースを使うのだろうか。ファイルにデータを書き込むプログラムを書くのは造作ないにもかかわらず、データ管理専用のソフトウェアをわざわざ用いる利点はなんだろうか。この点について改めて考えてみたい。
データベースと一口に言ってもさまざまな種類がある。SQL Anywhereでも採用しており、最もよく使われているのがRDBMS（Relational DataBase Management System）と呼ばれているものである。
RDBMSは、データを2次元の表（テーブル）のように管理する。テーブルはカラムと行からなり、カラムがデータ項目を意味し、1件1件のデータが行として記録される。一般にテーブルは多数あるので、必要な情報が複数のテーブルにまたがっていることもあるが、テーブル同士を結合するなどして、欲しい情報だけを選択できる。テーブルはエンティティと呼ばれることもあるが、本連載ではデータモデルといった概念は扱わないので、単純に「テーブル」と呼ぶことにする。同様に、タプルやレコードやローではなく「行」を使用し、フィールドや属性ではなく「カラム」で統一する。
データベースを用いる利点は、データとアプリケーションとを分離し、別々に扱えるようになることである。その結果、保守管理しやすくなり、開発生産性も向上する。では、もう少し詳細に見ていこう。
データの独立性
アプリケーションがデータベースを使わず、たとえば、カンマ区切りのCSVファイルにデータを1件ずつ記録し、その処理をアプリケーション自身が実装するような場合を考えてみよう。この場合、データ保存の物理的性質にアプリケーションが強く依存することになる。
システムの利用が長くなり、業務処理の拡大に伴ってデータ形式の変更が迫られたとする。記録すべきデータ項目を増やしたり、記録されているデータの型を数値から文字列に変更したり、カンマ区切りをタブ区切りに変更したりしなければならなくなった場合、データファイルだけでなく、アプリケーション上の処理も修正が必要になる。
あるいは、扱うデータ量が増えて、処理速度を向上させる機能を追加することもあるだろう。インデックス検索できるようにしたり、ファイルを分割して管理できるようにしたりするような場合も、相応のロジック変更や追加が必要になる。
アプリケーションとデータとの依存性が高いシステムは、一方の変更が他方に影響するため、保守性や拡張性に劣る。このような事態を避けるため、CSVファイルを扱う場合であっても、データ操作部分をライブラリ化したりして、アプリケーションとデータとの依存度を下げるように努めるだろう。
この「ライブラリ化されたデータ操作」を突き詰めたものがデータベースだ。データベースはデータの保存や管理に専念し、SQLという標準的なアクセス手段を提供する。その際の接続方法もODBCやJDBCといった標準化されたインターフェイスを使う。アプリケーションは、そのようなインターフェイスを利用して、データベースの物理的性質が隠蔽されたままデータにアクセスする。
データベースの導入により、アプリケーションとデータとの独立性が高まり、それぞれを個別に管理することが可能となる。検索速度を向上させようとデータベースファイルやインデックスを追加しても、アプリケーションのコードを変更する必要はない。管理対象となる情報を広げようとテーブルやカラムを増やしても、アプリケーション側の変更は、データベースを使用しない場合よりもずっと少ないだろう。逆に、アプリケーション側でロジックを変更しても、データベースに手を加えることはない。さらに、データベースに接続するアプリケーションの種類が増えても、「標準的な接続方法」に対応してさえいれば、データベースはそのままでよいのである。
ポータビリティ
データベースの物理的詳細についてアプリケーションは関知せず、アプリケーションとデータベースは独立した関係になるため、別のOSのマシンにデータベースを移行することも可能となる。ファイル構造や文字コードといったOSごとの差異がデータベースサーバで吸収されるからだ。特に、SQL Anywhereではデータベースファイルが1つで済み、しかもファイルフォーマットがOSに依存しないため、データベースの移行は容易である。
データベースの中央管理
複数システムが利用するデータであっても、1つのデータベースに集中させることができるので、バックアップやチューニングといった維持管理を一ヶ所で行うことができ、都合がよい。
逆に言うと、相当量のデータ処理を一ヶ所で行うことになるため、管理責任も増す。規模が大きくなれば、データベース管理者（Database Administrator：DBA）を割り当て、保守にあたらせる必要がある。さらに大規模であれば、DBAチームを編成しなければならないだろう。DBAは、貴重なデータが障害時に失われないよう気を配るのはもちろんであるが、多数のアクセスをこなせるようにデータベースやクエリをチューニングしたりする。このような運用管理だけでなく、データ管理の視点からシステム設計の手助けをする場合もある。
SQL Anywhereは、保守の手間をなるべく省くように設計されたデータベースである。ファイルサイズの拡張や統計情報の更新は自動でなされ、コストベースのオプティマイザによりクエリの実行プランも適宜見直される。また、インデックスの作成を支援するインデックスコンサルタントという機能もある。
信頼性
データベースに求められる信頼性はさまざまな面がある。たとえば、（1）意図しないデータが記録されない、（2）データベースがいつでも利用できる、（3） 障害が起きても修復可能、などが挙げられる。
データベースでは、データの記録はトランザクション単位で行われる。トランザクションとは、データベースを利用する側にとって、これ以上分割することのできない処理をまとめたものだ。トランザクションの実行結果は、「成功した」「失敗して元に戻った（ロールバックされた）」の2つしかないため（トランザクションの原子性）、トランザクションの途中でたとえ障害が起きたとしても、ユーザが意図しない中途半端なデータの状態にデータベースが陥ることはない。
保存されるデータの値に制約をつけることも可能だ。たとえば、整数型で1から100までの値だけ許可するように条件を設定できる。複数のアプリケーションがデータベース上の同一のデータを利用するときなどはアプリケーション間の整合性を保つのが難しくなるが、データベース上で制限を設ければ、意図しないデータの入力を未然に防げる。
データベースでは、データを複数のファイルに記録して冗長にすることで、耐障害性を高めている。トランザクションログの利用がこれにあたる。また、1つのデータベースに対して複数のファイルを割り当て、記録を分散することもある。ファイルを別々のディスクに置くことは、ディスク障害の影響を減らし、パフォーマンスの向上にもつながる。
たいていのデータベース製品にはバックアップツールが付属しており、データベースが稼働中のままバックアップを行うことができる。データベースサーバに障害が起こったときは、リカバリツールなどを用いて、バックアップから復旧する。
セキュリティ
データベースにはセキュリティ機能も必要だ。たとえば、データベースファイルの暗号化やデータ通信の暗号化により、第三者からの盗聴を防ぐ。データベースにアクセスするユーザを設定して、データアクセスに対して認証・承認をかけることもできる。データベース内で可能な処理の権限をユーザごとに指定するのである。また、誰がどのような操作をしたのか、監査履歴を残すことも可能だ。
パフォーマンス
複雑なSQL処理であっても、データベースサーバはインデックスなどを用いて効率的にデータを取得するので、処理の遅いものがあれば、インデックスの追加などでチューニングできる。もちろん、このようなチューニングはアプリケーションの変更を必要としない。また、一度アクセスしたデータは、データベースサーバのメモリ上にキャッシュされるので、頻繁に参照されるデータはメモリ上に残りやすくなり、システム全体のパフォーマンスが向上する。
チューニングを手助けしてくれるツールを利用することもできる。たとえば、SQL Anywhereには、「Index Consultant（インデックスコンサルタント）」というツールがある。どのカラムにどのようなインデックスを作成すべきか判断するのは元来難しいものだが、このツールはその作業を支援・自動化してくれる。
複数のユーザがデータベースにアクセスする場合は、データの共有と同時アクセスという相反する課題を解決する必要がある。データベースは、排他制御の仕組みなどを用いて、論理的な整合性を保ちつつ、並列処理して効率を上げている。SQL Anywhereは、行ロックを用いて、並列処理の整合性を実現している。
開発生産性
これまで見てきたような機能を自分で実装しようとしたら、大変な工数になるはずであり、そこにデータベース製品を利用する価値がある。それだけでなく、データアクセスが標準化されるので、サードパーティ製のツールが利用しやすくなる。さらに、データベースの知識は製品に依存しない部分も多いので、知識や実装の共有につながるといった効果もある。このように、データベースの利用により開発生産性が向上する。
