今回は，RDBMSとフラット・ファイルの両環境でアプリケーションを動作させたいときの設計である。フラット・ファイルに合わせるとRDBMSの高度なSQLは利用できない。高度なSQLを使える設計にすると，新たな課題が出てくる。四つの方法を示そう。
本特集ではJavaシステムのトラブルを取り上げ，複数の解決案候補を解説します。Javaシステムを題材にしていますが，言語は違ってもトラブルの本質には共通する点がありますので，Javaを使わない方にもぜひ読んでほしいと思います。連載1回目は「システム・テスト時の異常終了」，連載2回目は「ネットワーク障害に端を発したWebシステムの異常」といったトラブルを説明しました。今回は「異常」というより「開発上の課題」に近いものですが，Javaは複数の実行環境で利用されることが多く，そういうケースにありがちな課題です。
まずは，課題の説明から行いましょう。
フラット・ファイルとRDBMSの両方で動作
今回は組み込み機器を用いたレジスター・システムです。店舗で顧客が商品を購入した情報を記録したり，その情報を集計したりする機能を備えています。対象機器は1種類ではなく様々な機器があり，OSで見るとWindows，Linux，組み込み専用OSといった違いがあります。これらの機器の上で同じ機能を持ったアプリケーションを動作させなければなりませんが，どの実行環境にもJavaVM（仮想マシン）が搭載されており，ハードウエアやOSの違いはJavaVMが隠蔽（いんぺい）してくれます。
しかし，一つ大きな問題がありました。データベースです。OSがWindowsやLinuxの場合は一般的な商用のRDBMSを利用できるのですが，今回対象となった組み込み専用OSでは一般的なRDBMSを利用できず，フラット・ファイルを使うしかなかったのです。（図1上）。組み込み機器には，購入した商品の情報，どのような支払いを行ったかといった情報など（以降これらをまとめてトランザクション・データと呼びます）を格納する必要があります。RDBMS上ではそれらを「ヘッダー・テーブル」「商品テーブル」「支払いテーブル」の三つのテーブルに格納しています。ヘッダー・テーブルと商品テーブル，ヘッダー・テーブルと支払いテーブルが1対多の関係を持っています。それをフラット・ファイルでは，可変長のファイルとして設計しています（図1下）。
実行環境ごとにアプリケーションを開発すると，メンテナンスが煩わしくなります。できるだけ実行環境に依存しないアプリケーションを開発したいところです。また，アプリケーションを動作させる機器が将来にわたって増えるかもしれないので，移植性の確保もポイントになりました。これが今回の課題です。
