いまさら聞けない 組み込みデータベース入門：組み込みDB技術解説（1/2 ページ）

　「組み込みデータベース（以下、組み込みDB）」というジャンルが認知されてきたのはここ1、2年のことです。しかし、データベース（以下、DB）自体は組み込みシステムにおいてまったく新しいものではありません。その管理規模に大小があるものの、多くの組み込みシステムは何らかのDB的なデータ処理プログラムを持っていると考えてよいでしょう。

　その中で、最も規模が大きい組み込みシステムのうちの1つが“携帯電話”です。そこで、本記事では身近な携帯電話を例に、組み込みDBについて解説していきます。

組み込みDBとは？

　「組み込みDB」とは、何でしょうか？

　一言でいうと、組み込みシステムに特有の制約・設計思想に基づいたデータベース管理システム（DBMS）のことです。一般的には、厳しいリソース制約上での稼働、ゼロアドミニストレーション、高い信頼性、リアルタイム性などが特長として挙げられます。

　「組み込みシステム」という言葉が生活家電から制御系システム、情報家電、PC規模の情報処理システムまで幅広い規模のシステムを表すように、「組み込みDB」もサイズが数十kbytesクラスの小型DBからDBMSとして遜色（そんしょく）のない機能を備えた数MbytesクラスのDBまで幅広い規模の製品が存在しています。

組み込みDBの役割

　組み込みDBはデータ管理ミドルウェアとして、これまでアプリケーションが自前で賄っていたデータ処理機能を提供します。機能はDB製品によって異なりますが、以下に代表的な組み込みDBの機能を示します。

• SQL言語によるDB定義・操作（検索・ソート処理など）
• トランザクション制御（コミット／ロールバック、セーブポイント）
• マルチアクセス対応（C／S型 DB）
• ユーザー認証によるセキュリティ
• ロック（テーブル・行レベル）による排他制御
• 不意の電源遮断が起こった場合のデータ整合性チェックと自動リカバリ
• テーブル同士のリレーションの自動管理
• インデックスによる高速な検索処理

　これらの機能をDBに任せてしまえば、アプリケーション開発とデータ処理層は分離され、それまでアプリケーションによるデータ処理に費やしていた開発負荷を大きく軽減できます。

　「では、具体的にどのくらい向上できるのか？」と思われることでしょう。

　そこで、アプリケーションプログラムのステップ数を比較し、実際の効果を数値で見てみましょう（表1）。

　高機能化の進むデジタル家電製品において、ソフトウェアのソースコードのステップ数は一般に数十万から百万行程度といわれています。その中でもソフトウェアの規模が突出して大きい製品が携帯電話で、その総ステップ数は200〜300万行に及びます。

　図1の測定結果が示すとおり、それまでDBをまったく使用していなかったアプリケーションがDBを使用することで、データ処理に関するプログラムに限っていえば、そのステップ数は50〜200分の1に縮小されます。1万行のプログラムが、たったの50〜200行になってしまうのです。

　DBによりデータ処理の開発を効率化できれば、他社との差別化を図るためのアプリケーション機能の開発に専念できるようになります。また、近年組み込み機器の内蔵メモリに保存できるデータ量が増えたことでレコードの検索や並べ替えといった、DBならではの便利な機能の実装も容易に行えるようになってきました。

組み込みDBの種類

　では、組み込みDBソフトウェアにはどのような種類や特長があるのでしょうか？

　現在、エンタープライズ系のDBMSでは“リレーショナルデータベース（RDB）”が主流となっていますが、その流れは組み込みDBにも当てはまります。つまり、多くの組み込みデータベースはRDBであり、DBへの問い合わせ言語として多くの組み込みDBがSQLに対応しています。

　組み込みDBは、しばしばその仕組みから大きく2つの種類に分類されます。1つは「インプロセス型（またはライブラリ型）DB」、もう1つは「クライアント・サーバ（C／S）型DB」です。

　以下にそれぞれの特長を紹介します。

• インプロセス型（ライブラリ型）DB
  インプロセス型DBは、データ管理機能をライブラリとして提供し、アプリケーションに組み込まれる形で実装されます。アプリケーションとDBが同じプロセスで動作するため、後述のC／S型DBと比べフットプリント（DBの稼働に必要なメモリサイズ）が数十kbytesからと小さいのが特長で、またSQLによるアクセスプログラムがあらかじめコンパイルされて実装されるため高速に処理を行うことができます。
  一方、サイズと引き換えになった機能制限がデメリットといえます。インプロセス型のDBは、サイズを小さくするためDBMSとしての機能を最低限にとどめており、例えば動的SQLやストアドプロシージャ／トリガに対応していなかったり、SQLの使用制限があったりします。また、インプロセス型の特性上、1プロセスが1DBを利用する作りになっており、複数処理の同時実行や複数のアプリケーションからのDBアクセスを行うには、アプリケーション側のプログラムで補う必要があります。
  そのためインプロセス型DBは、システムのリソースが限られていて、比較的単純な処理のみを行う場合（制御系システムなど）やアプリケーションが固定で機能追加・変更やデータ構造の変更をあまり行わない場合などの使用に適しているといえます。
• クライアント・サーバ型DB
  クライアント・サーバ（以下、C／S）型DBは、いわゆるエンタープライズ系DBMSがそうであるように、DBプロセスがアプリケーションプロセスから独立してDBサーバとして起動しており、複数処理の同時実行や複数のアプリケーションからのDBアクセスに対応できます。また、動的SQLを実行できるため、アプリケーションを柔軟に設計することが可能です。さらに、プラットフォームやデータ型、APIのサポート幅も多く、DB管理ツールなど便利なDBMS機能を備えている一方で、ターゲットシステムに合わせて不要な機能の取捨選択も可能です。
  デメリットとしては、多機能な分、数百kbytes程度のフットプリントを要することとアプリケーションとDB間でプロセス間通信が発生するためにインプロセス型DBと比べてオーバヘッドが大きくなるという点が挙げられます。しかし、最近の組み込み機器はメモリの大容量化・低価格化に伴って性能・機能性をより重視する傾向にあり、約数百kbytesのC／S型DBのサイズもそれほど問題にならなくなってきています。
  つまり、C／S型DBは、複数アプリケーションからのDBアクセスを想定した使い方をする場合や組み込みシステムの中でも比較的大きなメモリを持つ多機能型製品（情報処理系システムなど）での使用に適しているといえます。

図1　クライアント・サーバ型DBMSとインプロセス型DBMS