【第9回】　ベース – データベース：DDS

はじめに

第7回と第8回の 2 回にわたってオープンソース系の言語を紹介しましたがいかがだったでしょうか？ ほかのプラットフォームでも使用されている SoE を担う主な言語は、すべて IBM i でサポートされていることは理解いただけたと思います。同じプラットフォーム上で、基幹システム構築に欠かせない RPG / COBOL と SoE を担うこれらの言語がサポートされているという事実が、今後も IBM i が基幹システムを支えるマシンとして中心で有り続けるであろう理由なのだと思います。一つの言語だけでシステム構築を行う時代ははるか昔のことです。これからは IBM i のシステム開発に多くの技術者が参加して、ハイブリッドなシステム構築プロジェクトが推進されていくことでしょう。 今回と次回の 2 回は言語から離れて、RDBMS について考えていきたいと思います。AS/400 から IBM i と名称が変わってはいますが、四半世紀以上に渡りこのコンピューターが企業を支えることができた功績の多くは、安定して稼働し続けている RDBMS にあるといっても過言ではないでしょう。過去から現在、そして未来に向かって IBM i のデータベースはどのような道をたどり、そして今後どう発展していくのか。２回にわたって皆さんと考えていきたいと思います。最初の第９回では過去から現在までを振り返っていきましょう。キーワードは「ベース」です。

IBM i のデータベース

今から 50 年近く前の 1970 年、IBM のコッド博士がひとつの論文を発表します。現在多くのプラットフォームのデータベースで実装されているリレーショナル・モデルの元となった理論です（「A Relational Model of Data for Large Shared Data Banks」）。この理論は紆余曲折を経て、RDBMS（Relational Database Management System）として System/38 に実装されました。論文発表から 9 年後の 1979 年のことです。 リレーショナル・データベースは、すべてのデータを正規化という手順を経て複数の二次元の表形式にしてデータを保管します。データは参照時に必要なデータをそれぞれの表の関係（リレーショナル）を使用して集めることができます。正規化の目的はデータの冗長化の排除と不整合の排除にあると思いますが、基幹システムのデータ設計時には、この2点は必ず検討しなければならないのは皆さんご存じのとおりです。 System/38 が画期的だったのは、この RDBMS をハードウェアに近いマイクロコード内に実装したことです。現在においてもほかのプラットフォームでは、RDBMS は OS とアプリケーションの間（ミドルウェア）に位置付けられていますが、S/38 では当初から OS（最もハードに近いマイクロコード）の基本機能でした。この実装により、System/38 のデータベース機能は信頼性の高いものとなり、AS/400 もその仕組みを採用し、現在の IBM i に受け継がれています。 OS の基本機能として提供することで、OS の他の機能との連携を密にすることが可能になります。たとえば一貫したセキュリティーの RDBMS への適用や、ハードが新しくなった場合の利点をいち早く享受できるなど、メリットは数多く存在します。S/38 から IBM i にいたるまで、すべてのユーザーがこのメリットを享受しているからこそ、信頼性の高いコンピューターという評価を今もなお受け続けているのです。

オブジェクトの作成インターフェイス

S/38 から続く IBM i の RDBMS は、物理ファイルと論理ファイルの 2 種類で構成されます。それぞれのファイルの特徴は以下のとおりです。

• 物理ファイル
･実際のデータ（レコード）が保存されているファイル
• 論理ファイル
･単独では存在せず必ず物理ファイルに関連づけられる ･物理ファイルのデータの見方を定義する ･実レコードは持たない

物理ファイルは、レコードの長さだけを定義して作成（内部記述ファイル）することも可能ですが、今回はその例については割愛します。 物理ファイルも論理ファイルも、それぞれレコードの形（どんな情報をどういう順番で並べるか、それぞれのタイプと名前をどうするかなど）を定義しなければなりません。この形を定義するために使用されるのが今回取り上げる DDS（Data Description Specifications：データ記述仕様）です。 物理ファイルを作成するのは CRTPF コマンド、論理ファイルは CRTLF コマンドをそれぞれ使用します。このコマンドの実行時に DDS で定義したレコードの形を参照してファイルが作成されます。ここでのポイントはあくまで DDS は形を定義する仕様であるという点です。 ･DDS ･形を決める ･CRTPF / CRTLF コマンド ･あらかじめ記述された DDS を用いて物理 / 論理ファイルを作成する DDS は、作成コマンドを実行するときに参照可能な形でシステム内に存在していなければなりません。一般的には QDDSSRC というソース・ファイルにファイルごとにメンバーに分けて保管します。その際に使用するのが SEU（エディター）ですが、もちろん RDi を使用することも可能です。各作成コマンドは、参照元としてソース・ファイルおよびメンバーを指定するパラメーターがあり、作成するファイルの形を定義した DDS が保管されているソース・ファイルおよびメンバーをそのパラメーターに指定します。

IBM i のファイルについて

ではここで、IBM i におけるファイルの概念について少しまとめておきたいと思います。皆さんは「ファイル」と聞くと何を思い浮かべるでしょうか？一番多いのはデータベース「ファイル」だと思います。また PC ではディスクに保管されているもの（テキストファイルや EXE ファイルなど）を思い浮かべる人もいるかもしれません。もともとファイルはコンピューター上でデータを扱いやすくするための仕組みのことを言います。ですから皆さんが想像するものはすべて正解ということになりますね。 IBM i ではオブジェクト・タイプが *FILE を「ファイル」と呼んでいます。IBM i には以下のような種類があります。 ･物理ファイル ･論理ファイル ･表示装置ファイル ･印刷装置ファイル ･通信（ICF）ファイル ･・・・ では、このファイルを言語で扱う場合について考えてみましょう。IBM i の RPG 言語では、上記ファイルに対しての読み書きは同じ命令を使います。そして、対象となるファイルの種類ごとにその後のデータの処理が異なってきます。たとえば、物理・論理ファイルへの読み書きは RDBMS を経由してのレコードの読み書きとなります。表示装置ファイルの読み書きは、5250 画面を介したユーザーとの情報のやりとりとなります。印刷装置ファイルへの書き込み（読み込みはありません）は、プリンターに印刷データとして送られて実際に紙に情報が印刷されます（実際はスプールデータとして出力待ち行列に保管される場合が多い）。通信ファイルへの読み書きは、あらかじめ設定された通信構成を経由して、ほかのシステムとデータの送受信を行います。もう一度言いますが、ファイルへの読み書きはすべて同じ命令を使用します。このため、RPG プログラマーはデータの保管状態や書き込み先のことを意識せず、プログラムを記述することができるのですね。 ただし、あらかじめ決めておかなければならない共通事項があります。それはレコードの形（IBM i ではレコード様式）です。画面にはどんな情報をどの順番で送るか、印刷はどの情報をどういう順番で並べるか、相手システムに送信する情報をどういう並び順で送るか、これらの情報をまとめたものをすべてレコード様式と言います。定義方法は大きく２つあります。ひとつは、データを送受信するプログラム内部で定義する方法と、もうひとつはファイル・オブジェクトそのものに定義を保存しておく方法です。前者を内部記述、後者を外部記述といいます。 ファイルそのものにレコード様式を記憶させる（外部記述）には、ファイルを作成する際に定義するレコードの形を何処（どこ）かに記述しておかなければいけません。このときに使用されるのが DDS なのです。IBM i では物理・論理ファイルだけでなく、その他のファイル（*FILE）の形を定義するにも DDS が使用されます。

あらためて DDS とは

では改めて DDS の利点をまとめておきましょう。まず、何と言っても記述仕様が簡単であり、外部記述データベース・ファイルの作成および保守が容易である点が挙げられます。レコードの形をソース・ファイルのメンバーとして保管しておき、作成（CRTPF、CRTLF）および保守（CHGPF）時にそれを指定するだけで RDBMS オブジェクトが作成および変更ができるのですから。 企業の基幹システムは SoR であり、トランザクション処理を中心としたシステムであることは何度も説明してきました。これを実現するためには優れた RDBMS が必須ですが、そのオブジェクトを簡単に作成および保守できる DDS はとても優れた仕組みであったわけです。基幹システム・プログラムはデータベース・ファイルの作成および保守に苦労することなく、RPG 等の言語でビジネス・ロジックを構築することに集中できたのです。DDS でファイルを作成し、RPG 等の言語でレコードレベル・アクセスによるトランザクション処理を行うシステム開発が基本であった AS/400 が、四半世紀を経た今でも最前線で業務をサポートしているのはこういう仕組みが有ったからなんですね。 しかし、もう一度言いますが、DDS はあくまでもレコードの形を事前に取り決めた設計書に過ぎません。データベースを作成するのはコマンドですし、RDBMS は 実際のデータ処理時に DDS で記述されたものを参照することは無いのです。 外部記述ファイルを作成および保守する手順をここでまとめておきましょう。 ･QDDSSRC などのソース・ファイルに記述したものを入力もしくは修正 ･各ファイル作成および変更コマンドにてファイルを作成および変更 DDS が参照されるのは、このファイル作成および変更時（指定された場合）のみです。

DDS でできることできないこと

これまで見てきたように、DDS とはレコードの形を記述するための仕組みであり、情報を保持するデータベース・ファイルの作成にのみ特化したものではありません。ここでは、RDBMS に欠かせない機能の中で DDS でできること（記述できること）とそうでないことをまとめてみたいと思います。

• できること
･項目の属性（フィールド名、データ・タイプ、長さなど）の定義 ･項目の説明（カラムヘディングや説明文） ･キー項目の定義 ･レコードの選択、除外、レコードの形の変更（論理ファイルにて） ･・・・
• できないこと
･ファイル同士の参照制約（リファレンシャル・インテグリティ）の定義 ･トリガー・プログラムの定義 ･フィールド単位のセキュリティー設定 ･自動インクリメント・フィールドの定義 ･監査列の定義 ･テンポラル表の定義 ･・・・

管理の側面から見ると、DDS はソース・ファイルのメンバーとして保存しなければならないため、RDi のツールなどを使用しなければ VCS でバージョン管理することはできません。ただし、プログラムオブジェクトと違い、DDS で定義したレコードの形はファイルに保存されており、その情報を取り出すコマンドが用意されている（DSPFFD など）ので、その情報があれば DDS ソースがなくなっても元の DDS 情報を取り出すことは可能です。実際にソース・メンバーとして復元するにはツール・プログラムを購入するか自作する必要があります。 何度も触れたとおり、DDS はあくまでも形を定義するために使用するものであり、RDBMS のさまざまな機能を定義するものではありません。上記で書いたように自動的に番号をインクリメントしていくフィールドの定義や、フィールドごとのセキュリティーの設定、7.3 で追加されたテンポラル表の定義など、これらは DDS の守備範囲ではなく、次回紹介する DDL（Data Definition Language）を使用して定義することになります。物理ファイルを情報の単なる保管庫として今後も運用していくとすれば DDS を使用して作成する方法でじゅうぶんだと思いますが、これからも RDBMS に追加されていくであろう多くの機能を使うためには DDS から DDL への移行は必須と考えなければならないでしょう。 幸いなことに、DDS から成されたファイルであっても SQL で処理することは可能です。また、DDS / CRTPF で作成されたファイルから、そのオブジェクトを生成する SQL を出力させることも可能です。方法は 2 種類あります。 ･i ナビゲーターから自動生成 ･API を使用して生成 この機能を活用すれば、DDS から DDL の移行は格段に簡単になると思います。ぜひ試してみてください。

コマンドで実現可能な RDBMS の機能

現在サポートされている RDBMS の機能のうち、先ほど紹介したように DDS で定義できないものはたくさんあります。そのほとんどは SQL インターフェイスを経由して実装することが可能であり、われわれは積極的に SQL に移行していく必要があると思います。詳細は次回お話しますが、それらの機能の中で OS のコマンドを実行することで定義可能な機能もいくつかありますのでここで簡単に紹介したいと思います。 まずはファイル同士の参照制約を紹介しましょう。参照制約とは、データベースに保存されているデータがすべて有効であることをシステムが保証する仕組みのことです。有効かどうかの判断基準は以下のとおりです。 ･固有制約 ･一次キー制約 ･参照制約 固有制約を定義することにより、ファイルに固有キー・アクセス・パスが定義されます。キーの値には NULL 値を含むことが可能です。 一次キー制約を定義することにより、ファイルに一次キー・アクセス・パスが定義されます。固有制約は対象フィールドを NULL 値可能で定義できますが、一次キーは許されない点に注意しましょう。 参照制約は、外部キーが定義されます。外部キーとは別のファイルの情報を特定する場合に使用される情報のことで、多くの場合マスター・ファイルのキー（一次キー）を指定します。たとえば顧客マスターに登録されている顧客からの受注データしか受注ファイルには存在しないというルールは、この外部キーによってチェックされます。 上記の制約は、ADDPFCST コマンドを使用することにより物理ファイルに追加され、RMVPFCST コマンドを使うことで物理ファイルから除去することが可能です。物理ファイルに指定した UNIQUE キーワードとキーフィールドを指定すると、どのインターフェイスからでも重複キーが発生するようなデータの保守はシステムによってチェックされ実施できないのは皆さんご存じのとおりですが、参照制約もそれと同様にシステムがチェックするものであり、どのインターフェイスを使用したとしてもそのルールに反する保守は行うことができません。DDS を使用してこれらを定義することはできませんが、存在している物理ファイルにあとからコマンドで定義することは可能なので覚えておきましょう。 もうひとつはトリガー・プログラムの追加です。トリガー・プログラムとは、物理ファイルのデータへの操作（追加、更新、削除および読み取り）が行われるタイミングで、システムにより自動的に呼び出されるプログラムのことです。オブジェクト・タイプが *PGM であればどの言語で作成されたものであってもトリガー・プログラムとして登録することが可能です。各データ操作イベントの前と後で呼び出す等の指定が可能であり、ビジネス・ロジックをトリガー・プログラムで実装することで、業務規則の一カ所での定義およびサーバーでの一括実行が可能となります。設計をしっかり行うことにより、今まではプログラムで記述していたデータのライフサイクル全般のロジックを、一カ所にまとめることができるのです。 トリガー・プログラムの作成は、RPG などの言語になりますが、作成したプログラムと物理ファイルを関連付けるのは DDS では行うことはできません。代わりに ADDPFTRG コマンドを使用します。 参照制約もトリガー・プログラムも、IBM i で利用可能な RDBMS にとってはとても重要な機能です。しかし、これは DDS を通してのみデータベースを理解していると見過ごしてしまいがちな機能です。この２つの機能だけでなく、DDS では実現できない多くのことがありますので、今後は次回紹介する DDL を通して IBM i のデータベースを理解するようにしていきましょう。

おわりに

最初にも触れましたが、リレーショナル・データベースは正規化という手順を経て複数の表を作成し、それを使用してデータを保管していくものであり、それを管理するのが RDBMS です。RDBMS で処理されるファイルは物理ファイルと論理ファイルの２種類です。データを保管するためのファイル・オブジェクトが物理ファイルであり、参照時に表の形を一時的に別の形にしたり、複数の表を一つにまとめたりするのが論理ファイルです。この２つのオブジェクトを作成するのはあくまで OS の機能であり、その形を決める設計図が DDS です。あくまでも結果として作成されるのは *FILE オブジェクトです。 DDS とレコードレベル・アクセスの方式は、今後も使われていくことでしょう。しかし、新機能はすべて SQL での実装となります。プログラミング言語は、適材適所で選択していくハイブリッド開発は当たり前なのですが、データベースに関しては DDS と SQL のハイブリッドは複雑さを増長してしまう結果になりかねません。データベースの作成および管理を SQL / DDL に統一していくのは今後の選択肢のひとつになると思います。少なくとも今後のシステム設計においては、SQL でしか設定できない機能を利用する前提で行うべきであるのはいうまでもありません。SQL の技術者もたくさんいらっしゃると思います。また、RPG でも SQL 文をコーディング（組み込み SQL）することができますので、SQL は必須と捉えて取り組んでいきましょう！

著者プロフィール