京ぽんに採用されたインメモリDB「ENCIRQ DFF」：組み込みデータベースカタログ（3）（2/3 ページ）

ENCIRQ PLを使ったライブラリ呼び出し

　DFFにおけるSQLの記述はちょっと面白い形を取る。DFFで利用されるのは、ENCIRQ PL（EPL）と呼ぶ記述言語である。察しの良い方はお分かりだろうが、これはOracleのPL/SQLに範を取ったもので、PL/SQLから組み込みに必要な部分を抜き出し、再構成したようなものをイメージすると分かりやすい。

DFFを使ったアプリ開発の流れ

　図2は、DFFを使った具体的な開発手順をまとめたものである。プログラマはEPLを使ってデータおよびデータ操作の定義を行う。このEPLを検証するENCIRQ Prototyperと、EPLをCのソースに変換するENCIRQ Generatorが開発ツールとして提供される。EPLの記述が完了してソースコードを生成できたら、そこから先の作業は通常の組み込みシステム開発と同じである。この時点で、プログラマがデータベースのことを意識する必要はほとんどない。データベースのハンドリングはEPLから生成されたAPI内部で行われるので、単にAPIを呼び出すことだけを考えればよい。そして、最終的なシステムのビルド時にENCIRQ Service Libraryをリンクすることで、データベース機能を持つプログラムの完成という仕組みだ。

図2　DFFを使った開発プロセス

ENCIRQ PLコーディングの実際

　ここまでは、Embedded SQLではよく見る構図である。あまり一般的でないのはここからだ。先に「EPLはOracleのPL/SQLに範を取った」としたが、その構造は大きく異なっている。一般にEmbedded SQLでは、Cなどのソースの中にSQL文を埋め込み、これをプリプロセッサなどで分離してアクセスライブラリを呼び出すという形になる。これに対してEPLでは、Adaによく似た文法でデータベースアクセスを記述する。必要に応じてローカル変数や外部関数の呼び出し、例外ハンドラまで記述することができる。つまり、単にGET／PUTといった低水準のAPIを作るのではなく、より上位レベルのデータベースアクセスロジックをまとめて作り込めるようになっている。逆に、単にSQL文字列を渡してこれをパースするようなルーチンは、EPLでは記述できない。EPLでは、動的なSQL文を動作時にパースして実行する処理をサポートしていないからだ。

ENCIRQ PLのサンプル

　DFFを適用するには、最初にデータやデータに対する操作、インターフェイスなどの定義をきちんと行う必要がある。場当たり的な開発スタイルに慣れてしまうと面倒なやり方に見えるかもしれない。しかし、昨今の組み込み開発ではシステムの肥大化に伴い、きちんとシステム定義を行うことが必須になりつつあり、むしろ現状に即した開発が可能になる、というべきであろう。逆に、高いレベルでうまくデータベースアクセスを抽象化できれば、データやデータ操作の管理が非常に容易になる。EPLがAdaのフォーマットを採用しているのは「開発者の趣味だと思います」（吉原氏）とのことだったが、Adaがこうした問題に早くから注目し、それに対して一定の解決策を提示していることを知って、あえて採用したのではないかと思う。

　ちなみにエンサークでは、EPL担当とそのほか（例えばビジネスロジックなど）の担当の分離を推奨している。すると、EPL担当はデータ管理とEPLの記述に専念でき、システム全体を通してのデータの整合性を保ちやすい。そのほかのエンジニアは逆に、データベースアクセスを意識せずに開発を進めることができるようになる。