　1番目のデータ処理の独立ですが、自前でデータ管理を実装するのに比べ、メモリ管理やデータ管理を分離できるようになります。一般的にデータベースを利用する方が自前で実装するよりもメモリ効率はよくなります。これは別の機会に説明していきますが、データベースは少ないメモリでのデータ検索技術に優れているためです。一般的にプログラムとデータベースとのやりとりはAPI（Application Program Interface）によって行われ、プログラム側にデータ処理ロジックが含まれずに、さまざまな制御や処理のロジックとデータ管理を分離できるようになります。最近では組み込み分野でもデータベースとの接続はAPIだけでなく、ODBC（Open DataBase Connectivity）やJDBC（Java DataBase Connectivity）などの汎用的なミドルウェア技術を利用できるようになっています。データベースの問い合わせ言語であるSQLが利用できるのであれば、さらにプログラムとデータ管理部分のロジックをきれいに分離できるようになります。

　2番目のデータ処理の再利用ですが、プログラムとデータベースとのやりとりがAPIやミドルウェアの場合、それらに渡すパラメータやSQL文によってデータ処理の内容を簡単に変えることができるため、自前でデータ処理を実装するのに比べ、はるかにデータ処理部分の保守性が高くなります。

　3番目のデータ処理の性能劣化の防止ですが、自前でデータ処理を実装した場合、データ量が多くなると利用するメモリ量も多くなるだけでなく、検索に時間がかかるのが一般的です。しかし、データベースを利用するとデータ量が増えてもそれほど性能は劣化しません。これはデータベースが効率よくメモリを利用したり、キャッシュを活用したりしているためです。将来的にデータ量が増えていくアプリケーションではデータベースを利用するメリットは非常に高くなります。また、データベースにはトランザクション機能があり、データを安全に更新したり、削除したりすることができます。トランザクション機能の詳細については別の機会に詳しく説明していきましょう。

　最後の大量データ処理への対応ですが、データベースはデータ管理・データ処理が得意な技術です。そのため、大量データの追加や削除があったとしても、メモリやCPU（Central Processing Unit）に大きな負担を掛けずに実行できます。

　ここで挙げたもの以外にもデータベースの利点はまだまだ存在します。

　ではデータベースを利用することによる“デメリット”は何でしょうか。筆者が考えるデメリットは次のようなものです。

データ処理部分がブラックボックスになる
データ構造設計を事前にしっかりと行う必要がある
データベース利用のためのノウハウが必要

　まず、当然のことですが「SQLite」などのオープンソースのデータベースを除き、データベースは商用製品を利用することになるため、データ処理部分がブラックボックスになります。エンタープライズ系のデータベースと異なり、利用されるメモリ量などは設定できますが、メモリをどのように利用しているのか、データをどのような構造に格納しているかが不明瞭（めいりょう）になります。組み込み開発ではソースコードがないと不安に感じることも多いので、重要なデータ処理を行う部分がブラックボックスになることを毛嫌いされる方もいるのではないかと思います。しかし、筆者はデータベースのソースコードがあったからといっても簡単に理解できるとは思えません。もし、データベースについて詳しく理解されたい方は「Berkeley DB」「Firebird」「MySQL」などのオープンソースのデータベースのソースコードを参照してみるといいでしょう。ただし、そのソースコードは最低でも50万行はあり、検索部分のコードはアルゴリズムの固まりなので、読むのに非常に高度な知識が必要となるでしょう。

　データベースを利用することでデータ構造設計は柔軟になりますが、この柔軟性を拡張性に生かしていくためには、しっかりと事前にデータ構造設計を行う必要性が生まれます。一般的にデータベースを利用するときのデータ構造設計に正解はありません。リレーショナルデータベースの場合では正規化という方法論がありますが、正規化することが必ずしも最高のパフォーマンスを引き出せるというわけではありません。つまり、3番目に書いたとおり、データベース利用のためのノウハウを蓄えていくことが必要になるわけです。このノウハウを蓄えることがデータベースを効果的に活用するための近道だといえるでしょう。

　ではノウハウはどのように蓄えていけばいいのでしょうか。筆者からのアドバイスとしては次のとおりです。

利用するデータベース製品を絞ること
データベース技術を身に付けること
とにかく触ってみること

　データベースは製品によってそれぞれ特徴が異なります。特に組み込みデータベースは製品によってアーキテクチャも利用方法も異なっています。そのため、プロジェクトや会社で利用するデータベースを絞り込んだ方がノウハウもたまりやすいと思います。ただし、利用するOS（Operating System）、チップ、搭載メモリなど、環境によって利用できないデータベース製品もあるので、1種類に絞るのはよくないと思われます。よく利用されるOSやチップとデータ量に合わせて、2～3種類のデータベース製品を検討してみるといいでしょう。

　データベースを理解するには、SQLやトランザクション技術、インデックス技術などのデータベース技術を理解する必要があります。現在市販されているデータベース関連の書籍のほとんどは特定のデータベース製品の技術を解説したものばかりで、汎用的な技術を説明した書籍は非常に少なくなっています。そのため、本記事だけでなく、連載中に汎用技術を身に付けられる書籍を紹介しながら、皆さんのデータベース技術の向上のお手伝いをしていこうと思います。

　最後に、データベースを理解するためには組み込みデータベースをとにかく触ってみることです。以前は皆無でしたが、最近では筆者が勤めている企業から提供されている「Entier」のように組み込みデータベースの体験版をWebサイトでダウンロードできるものが増えてきています。また、詳細なホワイトペーパーなどの技術資料が公開されていることもあります。組み込みデータベースを理解するには、ダウンロードして利用してみること、その製品のセミナーに参加して概要を知ることがノウハウを蓄えていくための一番の近道だといえるでしょう。


	関連リンク：
⇒	組み込みデータベース「Entier」体験版

組み込みデータベースに求められる機能

　情報系で利用されるデータベースと組み込み系で利用されるデータベースは何か違いがあるのでしょうか。確かにインストールするだけで数百Mbytesを消費するものを組み込みで利用することはできません。筆者の考える組み込み分野で求められるデータベースの特徴をまとめると表2のようになります。


インストールサイズ	小さい
使用メモリ量	小さい
機能	機能の取り外し（プラグイン）
扱うデータの種類	数値、文字列、バイナリ、地図情報（POI）
扱うデータ量	数kbytes～数百Gbytes
対応SQL	SQL-92とSQL-99の一部
SQL仕様への準拠	望ましい
表2　組み込みデータベースに求められる特徴

　これらの特徴はすんなりと理解できるものだと思いますが、筆者としては地図情報（POI：Point Of Interest）への対応が組み込みデータベースとしては必要だと感じています。また、インストールサイズ、実行メモリを小さくするために、使用しない機能を取り外すことができることも必須となるでしょう。最後にSQL仕様への準拠ですが、利用者から見れば特定の製品に依存するよりも、できる限り仕様に準拠したものを利用したいものです。SQLが利用できることにより、情報系システムの開発者出身の人でも情報系で培ってきたデータベースの知識を利用することができます。これらの意味で仕様への準拠も必要でしょう。

　以上、今回は組み込みデータベースを学ぶうえでの前提知識についてお話をしました。データベースはデータ管理の必要性から生まれたテクノロジーです。組み込み分野でも今後さらに利用されていくものであり、ぜひこの機会に理解を深めてほしいと思います。さて、次回は「組み込みデータベースのアーキテクチャ」について紹介し、組み込みデータベースの構造を説明していきます。（次回に続く）