組み込みデータベースの構造ってどうなってるの？：組み込みDBプログラミングの道しるべ（2）（2/2 ページ）

メモリ制約の厳しい組み込み機器で利用されるDBの内部構造とは？ これを理解すればDBの可能性をさらに実感できるはずだ。

[加藤大受，＠IT MONOist]

　トランザクション管理では、まったく別のアーキテクチャの製品も存在しています。例えば、“MVCC（MultiVersion Concurrency Control：多版型同時実行制御）”と呼ばれる履歴型のアーキテクチャを採用している「Firebird」では一切トランザクションログを作成せずに、トランザクション管理を行っています。

　ただ、瞬電のようなトラブルの多い組み込み機器では、ジャーナルファイルを利用したトランザクション管理が適しているかと思います。なぜなら、瞬電などの障害発生時は、ジャーナルファイルを利用することでデータを元の状態に戻すことが可能だからです。また、トランザクションログ領域を利用している場合ですと、瞬電によってこのログ領域までトラブルが発生する可能性も考えられるため、ジャーナリングファイルシステムを利用して、ファイルレベルでも耐障害性を考慮したうえで、ジャーナルファイル形式でのトランザクション管理を行うデータベースを利用するのが理想的だと筆者は考えます。

　最後に、ストレージ上の実データが更新されるタイミングですが、COMMIT処理のタイミングで更新されるというわけではありません。これは各データベースによって実装が異なっているためです。COMMIT処理のタイミングで、ストレージ上のデータを書き換えている製品もあれば、COMMIT処理のタイミングではメモリ上のデータのみが書き換えられ、非同期にストレージ上のデータを書き換えていく製品やチェックポイント処理と呼ばれるタイミングによってストレージ上のデータを書き換える製品も存在しています。

　一般的にチェックポイント処理による実データの反映を行うデータベース製品やCOMMIT処理後に非同期に実データへの反映を行う製品は、どちらかというと大規模で更新処理が多い情報系システムにて利用されることが多く、安定した環境でデータベースを稼働させることが前提となっています。このあたりはデータベースの選択の話になってしまいますが、筆者としては、やはり不安定な環境での利用が多い組み込みの世界ではCOMMIT処理のタイミングで実データを書き換える方が安心な気がします。

SQL言語について

　多くの組み込みデータベースは「SQL言語」に対応しています。

　SQLとは“Structured Query Language”の略で、『エス・キュー・エル』や『シークエル』と読まれます。SQL言語はリレーショナルデータベースの問い合わせ言語として開発されたものですが、現在は利用しているデータモデルによらず、ほとんどのデータベースで利用できるようになっています。

　SQL言語の利点は、ISOの標準規格として規格化されており、ほとんどのデータベースで共通化されている点です。登場当初、SQL言語には統一規格がなく、各データベースベンダで決められていましたが、ANSIによって規格の統一化が行われるようになりました。現在ではISOにて言語仕様の標準化が行われています。制定された年ごとにSQL86、SQL89、SQL92、SQL：1999、SQL：2003などの規格があります。

　実情をいうと、この規格への対応の程度はベンダごとにバラバラなのですが、各データベース製品はどの規格に準拠しているのかを明確にしているため、ユーザーはそれに合った言語を利用できます。ちなみに、組み込みデータベースではSQL92に対応するものが一般的です。

　ISOの標準化委員会では、問い合わせ用のSQL言語だけでなく、データベースへの“コールレベルインターフェイス（CLI：Call Level Interface）”やJavaを親言語とする“埋め込みSQL規格（SQLJ）”など、プログラムインターフェイスについても標準化されています。近年は、マルチメディア・フレームワーク、フルテキスト検索、空間データ（Spatial）、静止画像などの取り扱いについても標準化作業が行われており、徐々に製品の垣根が低くなっています。

　SQL言語はデータ処理を行う問い合わせのためだけでなく、データベースにデータを格納するためのテーブル構造の作成や検索を速めるためのインデックスの作成などにも利用できるようになっています。

　SQL言語を大きく分類すると以下のようになります。

• データ定義言語（DDL：Data Definition Language）　
  CREATE文：データベースオブジェクト（表、インデックス、制約など）の定義　
  ALTER文：データベースオブジェクトの定義変更　
  DROP文：データベースオブジェクトの削除
• データ操作言語（DML：Data Manipulation Language）　
  SELECT文：表からデータの検索、結果集合の取り出し　
  INSERT文：行データもしくは表データの挿入　
  DELETE文：表から特定行の削除　
  UPDATE文：表の特定行の更新
• データ制御言語（DCL：Data Control Language）　
  BEGIN文：トランザクションの開始　
  COMMIT文：トランザクションの確定　
  ROLLBACK文：トランザクションの取り消し　
  LOCK文：表などの資源を占有する（マルチユーザー環境のみ）

　SQL言語の利用形態として、「埋め込みSQL」と「動的SQL」があります。組み込みデータベースでは、動的SQLを使用できないものや埋め込みSQLに対応していないものがあります。

• 埋め込みSQL　
  埋め込みSQLはホスト言語内にSQLを埋め込み、問い合わせの結果集合を取得するために都合のよい方法として考えられた。データベースと通信するためのリソースの割り当て確保や開放、1行ごとにホスト言語のループ処理で取得するための命令（FETCH）などがある
• 動的SQL　
  SQL文をデータベースへの問い合わせのたびにデータベースエンジンに送信する方法。SQL文をソースコードで固定せずにデータベースへのアクセスごとに構文を書き換えたい場合に有用である

　皆さんがデータベースを利用するときは、どのSQL標準をサポートしているのか、動的SQLが利用できるのかを確認しておくことをお勧めします。

データベースの構造について

　最後にデータベースの構造について説明しておきましょう。

　データベースを利用するときは、まず「データベースエリア」と呼ばれるデータの置き場を作成します。この置き場が1つのファイルになるものや指定したフォルダの下に複数のファイルを作成するものなど、置き場を物理的にどのように作成するかは製品によって異なります。

　データベースエリアのサイズは、格納するデータサイズを基に指定します。データベースエリアがいっぱいになるとデータベースが自動的にある一定のサイズずつ大きくなります。データベースエリアには、物理的なデータを格納するデータのエリア、データベースに格納されている表やインデックスの情報などを管理するデータディクショナリのエリア、バイナリデータ用のエリア、問い合わせ時に利用されるテンポラリ領域である作業表のエリアがあります。作業表のエリアはメモリ上で処理できない場合にデータベースが自動的に利用するものです。データベースエリアの内部構造も各データベース製品によって異なっています。

　データベースエリアは「ページ」と呼ばれる単位で分割されています。一般的にデータベースは「ページサイズ」と呼ばれるI/O単位でデータを読み取ります。つまり、1ページが最低I/O単位となります。このページサイズを実際に利用する機器のI/O単位と合わせることで、少ないI/O処理で効率よくデータを呼び出すことができるというわけです。

　ページには「データページ」と「インデックスページ」があります。データページには各行のデータが入り、インデックスページにはインデックスのリーフ情報が書かれています。

　一般的に、データベースではテーブルなどのオブジェクトは、1オブジェクトにつき1セグメントに格納されており、1セグメントは複数のページから成っています。図2は物理データファイルの構造のイメージです。小さいサイズのテーブルの場合では物理データファイルに複数のテーブルが格納され、大きいテーブルの場合では物理データファイルの最大サイズにもよりますが、1セグメントが複数の物理データファイルから成ることもあります。ただ、データベースがどのように実データを管理しているかは製品によって大きく異なっています。セグメントの概念がなく、固定のページサイズで作成されたテーブル、インデックスの情報を管理するシステムテーブルで各テーブルの格納されている物理データファイルと利用中のページを管理するような製品も存在します。

図2　物理データファイルの構造（イメージ）

---

　次回もデータベースの内部構造にフォーカスを当て、テーブルなどのオブジェクト情報を管理しているシステムテーブルや、少ないバッファでどのようにデータ処理を行っているのかについて解説する予定です。（次回に続く）