DDLを使用したアプリケーション・データベースの改修
DDSデータベースをDDLとして再定義してモダナイゼーションする
System i のアプリケーション開発者は、アプリケーションをモダナイゼーションするために多大なエネルギーと労力を注いでいます。つまり、既存のアプリケーションをウェブ用に改修したり、レガシー・アプリケーションを更新してリッチ・クライアントのインタフェースを開発したりしています。アプリケーションをモダナイゼーションする際に、データベースは非常に重要な部分となります。また、緑色画面のアプリケーションを一新することに気をとられるあまり、無視されがちな部分でもありました。
DDSは、System i のデータベースを定義するために従来から用いられている手法です。しかし、SQLにおけるデータ定義言語(DDL: Data Definition Language)はデータベース定義用の標準言語であり、IBMは、System i 上のDDLを機能強化し続けています。DDSデータベースをDDLとして再定義することで、アプリケーションのデータベース性能を向上させることができ、モダナイゼーションされた業界標準のデータベース・プラットフォームをベースにすることができます。本稿では、アプリケーション・データベースをモダナイゼーションする利点、DDSベースとSQLベースのデータベース・プラットフォームの違い、DDLへ変換することの利点、DDLデータベースの作成および管理用にSystem i が提供しているツール、再定義すべきデータベースの評価上の考慮点、DDSとDDLを組み合わせて使用するのが良い場合、などについて説明します。
なぜデータベースをモダナイゼーションするのか
微調整や論理ファイルの追加などがあったとしても、何年にも渡って問題なく動作しており、まったくと言っていいほど保守が必要でなかったデータベースを、なぜわざわざモダナイゼーションするのでしょうか。データベースをモダンなものにする理由は、主に2つあります。
- データベースの機能を向上させる(たとえば制約を追加する－これについては後述します)ことで、アプリケーションをモダナイゼーションするのに要するプログラミング作業量を少なくすることができます。
- 従来の緑色画面のアプリケーションからだけではなく、さまざまなポイントからデータベースへアクセスできるようになります。ウェブ・ベースのアプリケーションやリッチ・クライアントのアプリケーションからデータベースにアクセスする必要のあるようなアプリケーションを開発する場合、同じビジネス・ルールをいろいろなアプリケーションに、そのほとんどの場合異なるプログラミング言語を用いて実装(そして管理)するのとは対照的に、データベースを介してできるだけ多くのビジネス・ルールを確実に実装できなければなりません。
データベース・モダナイゼーション・プロジェクトを開始する際は、データベースに対する変更が現在運用中のアプリケーションに与える影響を考慮して、そのインパクトを最小限に抑えなければなりません。アプリケーションのモダナイゼーションに関するもう1つの重要な点は(従来のRPGやCobolを使用してモダナイゼーションする場合、新しいクライアント・ベースの技術を用いてモダナイゼーションする場合に関わらず)、ストアード・プロシージャを使用したり、ODBC接続やJDBC接続などの直接接続を使用したりして、プログラム内でデータベースにアクセスするのに今までよりも多くのSQLが使用されるようになる、ということです。データベースへのアクセスや管理にSQLが今までより多く使用されるようになると、パフォーマンスのオーバーヘッドが生じ、その結果、データベースをモダナイゼーションする際にSQLを介したアクセス用にデータベースを設計し、調整しなければなりません。
データベースの違い
System i 組み込みのデータベースと他のデータベース・プラットフォームとでは、重要な違いがあります。DB2やOracleなどの他のデータベースと比較して、System i のデータベースは、IBMがトリガーやファイル制約などの機能を追加してデータベースに対して定期的に機能を追加しているわりには、かなり安定しています。
従来のSystem i データベースはDDSとして定義されています。これは物理ファイル、論理ファイル、ジョイン論理ファイルの領域です。DDSも十分に機能を果たしていますが、そうであるが故に、DDSのコア部分に対してここ14年間まったく変更がなされてきませんでした。
しかし、データベース管理やデータベース開発の一部のルールが数年にわたって変更になり、こうした変更がデータベース・モダナイゼーション・プロジェクトに影響する可能性がでてきました。S/38やAS/400の初期の頃には、物理ファイル上に構築する論理ファイルの数を最小化していました。今日ではその逆となっています。つまり、1つのファイルへのアクセス・パスが多ければ多いほど、ファイルに対してクエリーをかけた際にパフォーマンスが向上するようになっています。データベースの設計に対する従来のアプローチは、(論理ファイルの数を最小限に抑えることで)アクセス・パスの数を最小限に抑えるというものであったのに対し、現在では、できるだけ多くのアクセス・パスを用意して、SQL文のパフォーマンスを向上させるというアプローチになっています。
そうしているうちに、OracleやDB2などといった、他のデータベース・プラットフォームが進化してきました。System i の専門家たちも、MySQLやDB2 Personal Developer's Editionを試用して、他のプラットフォーム上でデータベースを定義してみる価値があるかもしれないと考えるようになりました。他のプラットフォーム上のデータベースの定義を見てみることで、データベースの再定義をDDSからDDLへの移行と見なすのではなく、「純粋な」データベース定義の概念の理解に役立てることができるのです。また、他のプラットフォームがどのようになっているのかを調べることは、けっして悪いことではありません。System i 以外の世界のSQLデータベースを調べ始めたばかりであれば、後述の「データベース・ネーム・ゲーム」のコラムを読むと、従来のi5/OSベースのデータベース・プラットフォームで使われている用語とSQLベースのデータベース・プラットフォームで使われている用語の違いがわかります。
DDLの利点
DDSの代わりにDDLを使用してデータベースを定義することの主な利点は、機能、データの整合性、そしてパフォーマンスの向上です。その代わりにトレードオフとなるのは、一部のDDSの機能が使用できなくなることです(これについては後述します)。DDLの主な機能は以下の通りです。
- 独自のデータ・タイプを定義できます。たとえば、ACCOUNT_CODEというデータ・タイプを15文字のフィールドとして定義することができます。ですから、データベース中でアカウント・コードを識別する必要があるときはいつでも、名前を指定して、そのデータ・タイプがACCOUNT_CODEであることを識別するだけでよいのです(15文字のフィールドであることを覚えておく必要はありません)。
- ビューのビューを定義することができます。つまり、複雑なジョイン論理ビューを1つ定義したあと、その複雑なジョイン論理を複数のビューに渡って繰り返すのではなく、定義した複雑なビューの、より簡単なビューを定義できます。さらに、2つのビューの間にジョインを定義することもできます。
- DDSが提供する抽出カラムと同様の抽出カラムよりももっと複雑な抽出カラムを、ビューの中に構築することができます。抽出カラムは、他のカラムに適用した式の計算結果などといった、簡単なコンストラクトの場合もありますし(たとえばQUANTITY * PRICE)、SQLのスカラー関数を使用した、より複雑なコンストラクトの場合もあります(たとえば、今日の日付と生年月日との差から年齢を計算するようなカラムを定義する)。
- 要約情報を提供するビューを定義することができます。
- SQL SELECT文のWHERE節で定義できるような、DDSに比べてより詳細な選択基準を持ったビューを定義することができます。
DDLはデータの整合性に関する以下のような利点を提供します。
- DDLで定義されたデータベースは、テーブルに行が書き込まれたときに妥当性チェックを実行することができます。これに対して、DDSで定義されたデータベースは、テーブルから行が読み出されたときに、カラムの値に対して妥当性チェックを実行します。言い換えれば、DDLで定義されたカラムには、不正なデータを書き込むことができません。
- 制約(プライマリ、ユニーク、チェック)により、特定のテーブルの特定のカラム中のデータに対して、制限をかけることができます。DDSで定義されたテーブルに対しても制約を適用することはできますが、制約はDDLの定義に対してより直接的に統合されています。
- 参照整合性(外部キー制約)により、テーブル間の関係を定義することができます。外部キー制約は、他の制約と同様に、DDSで定義されたテーブルに適用することができますが、外部キー制約の方がDDL定義に対してより直接的に統合されています。
- トリガーをテーブルに適用することもできます。しかしここでも、トリガーをDDSで定義されているテーブルに適用することはできますが、トリガーはDDL定義に対してより直接的に統合されています。
DDLで定義されたデータベースが、DDSで定義されたデータベースよりも圧倒的にパフォーマンスで優れているのは、以下のDDL機能によるものです。
- クラシック・クエリー・エンジン(CQE: Classic Query Engine)とSQLクエリー・エンジン(SQE: SQL Query Engine)という、2つのクエリー・エンジンを使用して、クエリーを処理しています。クエリーに対するアクセス・プランを生成するとき(たとえば組み込みSQL)、システムはDDSで定義されたデータにはCQEを使用し、DDLで定義されたデータに対してはSQEを使用します。SQEの方がデータへのアクセスが高速です。
- DDLを使用すると、エンコード・ベクター・インデックス(EVI)を定義して、意思決定支援やクエリー・レポート生成環境などにおいて、データへのアクセスを高速に行えます。
DDLで定義されたデータベースを使用することで得られるその他の利点は、他のデータベース・プラットフォーム標準に準拠していること(つまり、他のプラットフォームのデータベース・アナリストがDDSは理解できなくてもDDLを理解できること)です。また、DDLで定義されたデータベースはDDSで定義されたデータベースよりもオープンですので、たとえば、データベースの設計、開発やレポート生成用のサードパーティー製ツールを使用して、より容易にデータベースにアクセスすることができます。
DDLデータベースのツール
DDLで定義されたデータベースとDDL関連のすべてのデータベース・オブジェクトをSystem i上で作成し管理するには、Navigator for i5/OSのデータベース関数を使用します。NavigatorにはGUI DDLツール群があり、これを使用すると、テーブル、インデックス、ビュー、制約、トリガーなどを定義して管理することができます。例として、テーブルを作成するためのインタフェースを図1に示します。
データベース関数は、DDLで定義されたデータベース・オブジェクトとDDSで定義されたデータベース・オブジェクトの両方を表示します。[Databases]を開いて作業対象のデータベースを開くと、データベース・オブジェクトを表示することができます。
データベースを再定義するには、データベース・オブジェクト用のSQLコードを調べて修正することから始めるのが良いでしょう。オブジェクトを右クリックすると、選択されたオブジェクト用のSQLを生成できるオプションが表示されます。次に、図2に示すように、生成されたSQLを[Run SQL Scripts]ウインドウ内に置きます(データベース・オブジェクトを右クリックして、[Run SQL Scripts]を選択します)。必要があれば、[Run SQL Scripts]ウインドウ内でもオブジェクトを修正することができます。
Navigator for i5/OS内のRun SQL Scriptsオプションは、DDLのソースを管理するためのネイティブのSQLインタフェースを提供しています。このDDLソースは、物理ファイルおよび論理ファイル用に現在管理しているソースと同等のものです。違うのは、SQLスクリプトには、テーブル、インデックス、制約、トリガーの定義を複数持たせることができる点であり、これに対し従来は、物理ファイルや論理ファイルのデータベース・オブジェクトごとにソースを記述し、コマンドを実行して制約やトリガーを定義していました。
DB2 UDB Query ManagerおよびSQL Development Kit (57xxST1)があって、コマンド・ラインのインタフェースを使用したい場合は、Run SQL Scriptsオプションを実行する代わりに、Start SQL (STRSQL)コマンドおよびRun SQL Statements (RUNSQLSTM)コマンドを5250セッションで実行することができます。しかし、DDL用のインタフェースとしては、Navigator for i5/OSを使用したほうが良いでしょう。なぜなら、Navigator for i5/OSは、DDL用のGUIツールと適切なスクリプト・エディタを備えているからです。
DDLの「つぼ」
データベースの再定義を検討する前に、DDLとDDSの違いについていくつか理解しておく必要があります。両者の違いはいずれも大きな支障となるものではありませんが、現在のデータベースがどのように定義されているかによっては、(表示ファイルや印刷ファイルの定義を変更するなどといった)追加の作業が必要な場合があります。
DDSユーザーが知っておくべき最も重要なDDLの「つぼ」は、以下の通りです。
- DDLでは、デフォルトの列名はロング名です。DDSでは、ロング名はALIASキーワードで定義しておかなければなりません(もちろんこれはCobolプログラマにとっては良い知らせです)。
- デフォルトでは、DDLのすべての列はnullでもかまいません。これは、DDSとは異なります。
- DDSのキーワードがすべてDDLでサポートされているわけではありません。中でも、EDTCDEキーワードとEDTWRDキーワードには注意してください。
- DDLでは、テーブル(物理ファイル)をキーで定義できない場合があります。リレーショナル・データベースの設計原理に従っていれば、これは問題にならないはずです。
- DDLでは、(フィールド参照ファイルと同様に)別のテーブルを参照してテーブルを定義することができますが、その情報は、参照情報の一部として各列に保持されるわけではありません。DDSはそのような参照情報を保持しますが、その情報を取得するには、たとえばDisplay File Field Description (DSPFFD)コマンドを使用します。
- DDLでは、インデックスはキー付き論理ファイルですが、V6R1より前は、1つのシーケンスしか定義できないキー付き論理ファイルでした(つまり、インデックスには選択、投影、ユニオン、ジョイン論理などを入れることはできませんでした)。V6R1ではこの制限がある程度緩和され、インデックスを定義する際にWHERE節を指定することができるようになりました。
- DDLのビューはキー付きでない論理ファイルです。つまり、キーでデータに直接アクセスしたい場合には、ビューを定義する際に利用できる有用な機能はすべて、高級言語プログラミングではほとんどあるいは全く役に立たないということです。実際のところ、ビューは組み込みSQLを使用している場合のみ有用です。
- V5R4以前は、DDLでテーブルやビュー用のレコード・フォーマット名を指定することはできませんでした。つまり、テーブル名とレコード・フォーマット名は同じということであり、RPGプログラマにとって、これは問題となっていました。
DDSデータベースの再定義
データベースをDDSで再定義するということは、全てDDSのデータベースにしなければならないというものではありません。DDLとDDSを混在させることも可能です。必要があれば、(DDSで定義した)物理ファイル上に(DDLを使用して)インデックスやビューを定義できるのと同じくらい簡単に、(DDLで定義した)テーブル上に(DDSを使用して)論理ファイルを定義することができます。
DDSデータベースをモダナイゼーションするときは、対象となっているDDSデータベースをDDLデータベースとして再定義するという、単純な方法を選択することもできます。しかし、「DDLの利点」のセクションで前述した通り、新しいDDL/SQLのデータベース機能をいくつか組み入れると、より大きな恩恵が得られます。理想的には、モダナイゼーションすることを、データベースの設計を再評価する好機ととらえると良いでしょう。既存のデータベースについて、プライマリー・キーの制約やユニーク・キーの制約を定義できる箇所や、外部キーの制約やチェックの制約を定義できる場所がないかを調査すると良いでしょう。
既存のDDSデータベースをDDLデータベースとして再定義する主な目的の1つは、DDLによるアプリケーションのパフォーマンス向上を図りながら、変更による既存のアプリケーションへの影響を最小限に抑えることです。もちろん、データベースを再定義する際は、単に、Navigator for i5/OSですべての必要な物理ファイルと論理ファイルを選択し、Generate SQLオプションを選択して、出力されるスクリプトを実行するだけでよい、というものではありません。
DDSデータベースをDDLで再定義する際は、現在のデータベースの状態によって変換作業の難易度が異なります。再定義に際しては、以下の点を考慮しなければなりません。
データベースを再定義する際に使用しているOSのバージョン。前述した通り、V5R4より前のリリースでは、テーブルやビューに対するレコード・フォーマット名を指定することができません。この場合、レコード・フォーマット名を使用してテーブルやビューを作成してから、データベース・オブジェクトの名前を必要な名前に変更しなければなりません。さらに、シーケンス(キー)と選択(選択/除外)ロジックが混在しているような既存の論理ファイルと等価なインデックスを定義したい場合は、V6R1を実行しておく必要があります。
データベースをどれくらいリレーショナルにしたいか。DDLは、DDSと比較すると、リレーショナル・データベースのルールへの適合が高くなっています。たとえば、DDSで物理ファイルに対するキーを定義できるのと同様には、DDLでテーブル用のキーを定義することはできません。このDDLの制限を回避するには、元々の物理ファイルとは異なる名前のテーブルを定義しておいて、元の物理ファイルと同じ名前のインデックスを定義します。
アプリケーションにどんな変更をする必要があるのか。DDLが生成したデータベース・オブジェクト用のレコード・フォーマット識別子をチェックして、そのレコード・フォーマット識別子が、元のDDSで定義されたデータベース・オブジェクトに適合していることを確かめる必要があります。適合していないと、新しいオブジェクトを参照するプログラムがレベル・チェック・エラーとなります。
さらに、今までフィールド定義用の物理ファイルまたは論理ファイルを参照していた表示ファイルと印刷ファイルもチェックしなければなりません。表示ファイルや印刷ファイルがEDTCDEキーワードまたはEDTWRDキーワード(または、DDLがサポートしていない任意のキーワード)を含むフィールドを参照していた場合、その定義を変更してキーワードを指定するか、またはDDSで定義された別のファイルを参照するように変更しなければなりません。たとえば、DDSで定義されたフィールド参照ファイルを、単に表示ファイルと印刷ファイルをサポートする目的に使用することも検討してください。
すべてのDDS定義がDDLでサポートされているわけではありません(たとえば、選択カラム付きのジョイン論理ファイル、選択/除外基準、定義されたキーなど)。DDSで記述された論理ファイルをDDLで定義されたテーブル上に構築したほうがよいのか、ビューを定義して組み込みSQLを使用するようにアプリケーションを変更し、そのビューにアクセスするようにした方がよいのか、どちらかを選択しなければなりません。
賢いモダナイゼーション
System i データベースのモダナイゼーションをするのに、SQL/DDLは良い選択肢です。なぜなら、SQL/DDLが機能、整合性、パフォーマンスの面でDDSに優る恩恵をもたらすからです。(データベースのパフォーマンスやSQL、DDSの使用方法については、後述の「Find Out More」に記載されている記事を参照してください。)
DDLを使用してアプリケーション・データベースをモダナイゼーションしようと決断したら、データベースを再評価する時間を設け、データ・タイプ、チェック制約、外部キー制約、トリガーなどがどこに恩恵をもたらすかを確認した方がよいでしょう。再定義することで一番恩恵をうけるのはどのデータベースなのかについても検討してください。また、DDSの一部の機能を保持したままDDLの機能、整合性、パフォーマンス面で利点を手に入れたい場合は、DDLとDDSを組み合わせて使用できるということも、覚えておいてください。
データベース・ネーム・ゲーム
もしあなたが従来型のSystem i開発者で、他のデータベース・プラットフォームについて勉強し始めたところであれば、最大の課題は用語の意味の違いに慣れることでしょう。従来のSystem i の命名規則と標準的なデータベースの命名規則の比較を、図Aに示します。ご覧になっておわかりいただける通り、従来の方法で作成されたオブジェクトと標準的なデータベース・オブジェクトの間に、一対一の等価性はありません。特に、スキーマ、インデックス、ビューについてはそうなっています。
"スキーマ"("コレクション"とも呼ばれている)は、ライブラリにリレーショナル・データベースのサポート情報が加わったものです。スキーマにはジャーナルとジャーナル・レシーバーが含まれており、スキーマで作成されたテーブルはデフォルトで自動的にジャーナルにアタッチされます。またスキーマには、そのスキーマ中のデータベース・オブジェクトに関する情報のための、システム全体に渡るカタログ・ファイルのビューが含まれています。スキーマは開発環境では有用ですが、運用環境では全てのテーブルを1つのジャーナルにアタッチするほうが好まれるので、スキーマはほとんど役に立ちません。
