IBM iのデータベース
IBM iのデータベースの起源は、1977年に発表（1979年出荷開始）されたS/38のリレーショナル・データベースに遡ります。当時はまだ、リレーショナル・データベース（RDB）は理論的には美しいが全く実用にならない「学者の玩具」に過ぎないと揶揄され、標準SQL規格もまだ定まっていない状況でした（最初の標準SQL規格は1986年発表のSQL86）。 このため、S/38ではDDS（Data Definition Specification：データ定義仕様）というファイル・オブジェクトを定義するための独自仕様を使ってテーブル（DBファイル）を定義することになります。また、S/34の利用者からの移行を容易にするために、RPGのREAD/EXCPT/CHAINなどレコードレベルのアクセス命令（以下Record Level Access、略してRLAと記す）でテーブルにアクセスできるように設計されました。 その後、S/38はAS/400、iSeries、IBM iへと進化しますが、後方互換性を保証するという40年来の約束を守り続けた結果、今日に至ってもDDSによるテーブル定義とRLAが使用可能なRDBマシンという側面が残っています。 RDBが本格的にビジネス用のデータベースとして使われるようになって約30年が経ち、今や単にデータベースと言えばRDBを指すような状況になっていますし、RDBを使っていないITシステムはまず考えられません。そしてRDBと不可分の関係にあるSQLは、今やITの世界における標準であり常識と言っても良いでしょう。 こうしたIT環境の変化に伴い、データベースのモダナイゼーションの対象として、DDSによるDBファイル定義からSQLのDDLによるテーブル定義への移行、そしてRLAからSQLによるテーブルアクセスへの移行という２つの事柄に注目が集まることになります。それぞれの理由について少し詳しく見てみましょう。DDSからDDLへの移行が必要な理由
DDSで定義されたDBファイルであってもSQLでアクセスすることが可能ですので、敢えてDDLでテーブルを定義し直さなくても、単にSQLによるアクセスにプログラムを書き換えれば十分ではないかと思われるかもしれません。しかし、DDSによるDBファイル定義をDDLによるテーブル定義に移行すること推奨するのにはそれなりの理由があります。（１）読込みパフォーマンスの向上
RLAによってDDSで定義されたDBファイルを読み込む場合、データの正当性チェックが行われるのに対して、DDLで定義されたテーブルの場合はデータの正当性チェックは書き込み時に行われ、読み込み時には行われません。このため、ファイルの定義をDDSからDDLに変えるだけで読み込み処理時間が短くなります。あるレポートによるとDDLで定義されたテーブル読み込みで約30％～40％の処理速度の向上が見られたと報告されています[1]。 逆に書き込み時にはDDLで定義されたテーブルは正当性チェックが行われるので、結局上記のメリットは相殺されてしまうのではないかと思われるかもしれませんが、ファイルの読み取りと書き込みの頻度は25対１であるという調査結果もあるように、一般的なアプリケーションでは圧倒的に読み込み操作の回数の方が多いので、DDSによるDBファイル定義からDDLによるテーブル定義に変えることによるパフォーマンス向上のメリットは大きいと言えます。 実際、あるお客様の環境で約60のジョブを約30分間実行したケースでは、DDLで定義したテーブルを使用した場合、DDSで定義されたDBファイルを使用した場合に比べCPU使用率が10％程度低下し、かつ更新件数は約16％増加したという報告がなされています[1]。（２）DDSではできないことがある
V5頃まではDDLで定義されたテーブルで出来ることは、DDSでもできるようにデータベースの機能拡張がなされてきました。たとえば、DDLで定義できる参照整合性やチェック制約の機能、トリガー機能などは、DDSで定義されたDBファイルにADDPFCSTコマンドやADDPFTGRコマンドを使って同じ機能を実現することができます。 しかし、DDSで定義されるDBファイルに対する機能強化はそれ以降ほとんどなされておらず、DDLでしか利用できないデータベース機能が追加されてきています。たとえば、IBM i 7.2で追加された行や列へのアクセスを制御するRCAC（Row and Column Access Control）機能や、IBM i 7.3で追加されたシステム期間テンポラル表（以下、テンポラル表と略記）の機能などがあります。RCACはDDSで定義されたDBファイルに対しても使うことができますが、その設定作業や設定を有効にするにはDDLを使用する必要がありますし、テンポラル表はDDLでしか定義することができません。 RCACやテンポラル表が提供する機能は、論理ファイルやプログラムの工夫で対応可能だという反論もあるでしょうが、RCACやテンポラル表を使った場合に比べプログラムロジックが複雑になり、修正や変更に手間がかかります。モダナイゼーションの目的に照らしたとき、これは好ましいことではないことは明らかです。 さらに将来の展望を考えると、今後のデータベース機能の強化、拡張はDDLの使用を前提に行われることはまず間違いありません。こうした観点からもDDSからDDLへの移行は重要です。RLAからSQLへの移行が必要な理由
データベース・アクセスについても、従来のRLAの代わりにSQLによるデータベース・アクセスに積極的に移行するべきです。その理由は以下のとおりです。（１）パフォーマンス上の優位性
IBM iにはClassic Query Engine(CQE)とSQL Query Engine(SQE)という2種類の照会エンジンがあります。SQEはCQEに代わる新しいSQL照会エンジンで、CQEと異なりオプティマイザーがMIより下の層で動く上にアルゴリズムも改良されているのでCQEよりも高速に最適化が行われます。このことから、CQEを使う論理ファイル経由のデータベース・アクセスより、SQLのView経由の方がパフォーマンスが向上します。また、SQLはSMP（Symmetric Multi-Processing）機能を活用することで照会や索引作成などを並列処理することができ、旧来のRLAよりも高いパフォーマンスを発揮できます。（２）高い柔軟性
SQLを使うことでビジネスロジックとデータモデルが分離できるので、適切なデータモデル作りができていれば、データベースへの変更（例えば新しい列の追加など）が生じてもその部分を参照していないプログラムは修正やリコンパイルが不要です。したがって、ビジネス要件の変更に柔軟かつ迅速に対応できます。（３）優れた拡張性
旧来のRLAに比べ、SQLは処理レコード件数が増えた場合でもあまり処理時間が大きくならないという特長があります。例えば10件程度のレコードを処理する時間はどちらの場合も処理時間に大きな差はありませんが、処理レコード件数が100件、1,000件、10,000件と増えてゆくと、RLAでは処理時間が指数関数的に増大するのに対し、SQLの処理時間はあまり大きく変化しません[2]。特に大量データの処理が求められる現代のバッチ処理環境ではSQLによるデータ処理のメリットは非常に大きいと言えます。（４）機能進化の将来性
近年IBMはSQL関連の機能を強化してきていますが、RLAについてはこの20年、後方互換性を保証しているだけで大きな機能強化を行っていません。最近の例を挙げればテンポラル表のサポートのようにSQLインターフェースを前提とした機能強化が行われています。こうしたSQLの新しい機能を活用することで、従来は複雑にならざるを得なかったプログラムロジックを簡潔に記述できるようになります。（５）業界標準である
今日、SQLはリレーショナル・データベース（RDB）の操作に関する業界標準であり、使用するプラットフォームを選ばない言語です。若いプログラマーは既に何らかのプラットフォーム上でRDBの扱い方を学んでおり、SQLを使えば全く違和感なくIBM iのRDBを扱うことができます。（６）プログラムロジックが簡潔に
SQLは従来の手続き型の言語と違い、処理手順を記述する代わりに処理対象のデータの条件を記述するので、どのようなデータを対象に処理を行っているかが分かりやすいという特長があります。そのためSQLで処理を行った方が、簡潔で処理内容が理解しやすいプログラムを書くことができます。 以上、DDS誕生の歴史的な経緯を含め、DDSによるデータベース定義からDDLによるデータベース定義に移行すること及びRLAからSQLによるデータアクセスへ移行することのメリットについて説明しましたが、次回は更にデータベースに関する根本的テーマであるデータベース設計のモダナイゼーションについて説明する予定です。どうぞお楽しみに。 【参考文献】 [1] “Modernizing Database Access The Madness Behind the Methods”, Dan Cruikshank [2] “Application Modernization – DB2 for i Style”, Kent Milligan & Mike Cain＜著者プロフィール＞
西原 裕善（にしはら ひろよし）
日本IBMでSEとしてS/34、S/38のシステム設計および導入作業に従事した後、米国ロチェスターの国際技術支援部門に出向し、全世界のIBM SEやお客様に対してAS/400の技術サポートを行う。帰国後、日本IBM システムズ・エンジニアリング（株）でITアーキテクトとして様々なシステムのアーキテクチャ設計を担当。現在はフリーのテクニカル・ライターとしてIBM iを中心に執筆活動を行っています。
