05　IBMiの基礎［データベース］　～Db2 for iの特徴を踏まえたデータベース設計・開発の概要　｜新・IBM i入門ガイド［開発編］

アプリケーション開発は、大きく「処理（プロセス）」と「データ」に分けられる。

「処理」は、昨今のアプリケーション・モダナイゼーションやデジタルトランスフォーメーション（DX）でも見られるように、業務の変化に伴い、変更される可能性が高い。

一方の「データ」は、そもそも後から設計変更することが容易ではないこともあり、変更が発生することはほとんどない。そのためデータベースの設計はとても重要と言える。

IBM iのデータベースであるDb2 for iは、OSに組み込まれて提供されるリレーショナル・データベースであるため、「個別の導入作業が不要である」「他のRDBと比較して運用の際に考慮すべき設定がOSにより管理される」という特徴がある。しかしデータベース設計、アプリケーション設計で検討すべき項目や、開発で実施する作業は、他のDb2ファミリーのデータベースと同じである。

ここではDb2 for iの特徴を踏まえながら、設計・開発の概要を説明する。

Db2 for iの特徴

Db2 for iのインターフェースには、一般的に使われるSQLに加えて、従来からIBM iが独自に備えるシステム・インターフェースがある。

IBM iでテーブルを作成する方法は、大きく2種類ある。1つは、SQLでDDL（Data Definition Language：データ定義言語）のCreate Tableコマンドを使用する方法。もう1つは、システム・インターフェースのDDS（Data Description Specification：データ記述仕様）を使用して作成する方法である。

DDSでは、ファイルのデータ属性を記述したソース・ファイルをコンパイルすることで、物理ファイルや論理ファイルを作成する。DDLで作成したテーブル、DDSで作成した物理ファイルや論理ファイルはともに、他方のインターフェースからの操作が可能である（詳細は後述する）。

データのアクセスにはさまざまな方法があるが、代表的なSQLとレコード・レベル・アクセス（以下、RLA）について説明する。

SQLは、5250インターフェースからSTRSQLコマンドを実行することにより使用できる対話型SQL画面や、アプリケーション・プログラムの中で組み込みSQLとして使用できる。

一方のRLAは、RPGプログラムなどで使用される主流のアクセス方法である。

両者の特徴として、RLAは大量データをバッチ処理などで順次処理する際に非常に高速かつ効率よくアクセスできる処理方法である。

それに対してSQLは、レコードセット単位でのアクセスを主体とし、アプリケーション側の検索、データ結合ロジックをデータベースに任せることによりアプリケーション開発の効率化、およびビジネスロジックとデータ間のモジュール化を促進させる処理方法と言える。

このほかにIBM Navigator for i、Access Client Solutions（ACS）、Web Queryといったツールからのアクセスも可能である。

またDb2 for iは新たなOSのバージョンやTechnology Refresh（TR）にて、新機能を提供し続けている。

たとえば現時点での最新バージョンであるIBM i 7.5ではBoolean型のサポート、2進基数索引（Binary Radix Index）の最大サイズを1.7TBから16TBへ大幅拡張、SQL標準の完全準拠などが新機能として提供された。

さらにIBM i 7.5 TR1では、IBM Watsonの地理空間分析（Geospatial Analytics）がDb2 for iに組み込まれ、地理空間情報の生成・分析、およびその情報の基となるデータの保存や管理がSQLで活用できるようになった。

ビジネスで地理空間情報を用いた意思決定を行うケース、たとえば物流の最適な配送ルートの決定や、フランチャイズの新規出店場所の検討といった利用が期待される。

新規アプリケーション開発や既存アプリケーションを見直す際には、ぜひDb2 for iの機能拡張やSQLプログラミングの新機能を確認し、積極的な組み込みを検討してほしい。

これらを理解した上で、いよいよDb2 for iでのデータベース設計・開発について説明する。

データベース設計の流れ

データベース設計は図表1に示すとおり、一般的に（1）概念設計、（2）論理設計、（3）物理設計のフェーズに分けられる。（1）と（2）はシステムによらず普遍的であり、（3）は物理固有の考慮が必要となる。

以下に、それらを具体的に記述する。

（1）　概念設計　

プロジェクトの要件定義では、基本計画に基づき、新規の業務アプリケーションに対する要件を洗い出し、対象を絞り込み、最終的な要件を決定する。業務の仕組みや流れを整理するために、処理やデータの流れをデータフローやデータストアにまとめる。

概念設計ではこれらのアウトプットを参考に、システムで扱うデータ項目を整理する。データ項目の整理では、データの正規化も行う。データの正規化は、冗長性の排除、データの正しさを保証する保全性の向上、データ形式の統一、定義や命名方法の標準化をすることが目的である。

またデータ構造やデータ間の関連をわかりやすく視覚的に捉えるため、ER図を作成する。ER図はその名のとおり、データを実体（エンティティ）と関連（リレーション）で示し、図式表現する。実体や関連に属性（アトリビュート）を持たせることも可能である。

（2）論理設計　

概要設計のアウトプットを元に、システムではなくビジネスの観点で設計を行う。たとえばテーブルや索引の設計を行うなかで、不必要に正規化されていないか、といった観点でデータを最適化する。またテーブルや列に対して制約を定義して、データ保全の観点から検討する。

さらにデータ操作方法（SQL、RLAなど）やデータ構造の定義方法（SQLまたはDDS）についても検討する。

（3）物理設計

パフォーマンスや可用性も考慮し、システムの観点で、Db2 for iのオブジェクトとしてデータベース、テーブル、索引、制約を定義し、実際のハードウェアにどのように構築するかを決定する。

最終的に必要となるハードウェア資源や、ジャーナル設計といった詳細についても検討する。Db2 for iでは、CCSIDについても必ず検討が必要である。

データベース開発作業

データベース開発では、実際に物理ファイル、論理ファイルといったデータベース・オブジェクトを作成する。SQLおよびDDSによる方法を簡単に紹介する。

（1）SQLによる方法　

SQLではDDLを使用してテーブル、インデックスなどを作成する。作成されたテーブルはPF、インデックスはLFというオブジェクト・タイプとなるが、オブジェクトの属性値の中にSQLという属性が付与され、DDLで作成されたことが識別可能である。

（2）DDSによる方法

DDSによる物理ファイル、論理ファイルの作成の流れを図表2にまとめる。

DDSで物理ファイルを作成する場合、CRTSRCPFコマンドにてソース物理ファイルを作成し、図表3のようなフィールドを定義する。その後、CRTPFコマンドにより物理ファイルを作成し、最後に実データを入力すれば完成である。

 

一方論理ファイルはデータを持たず、定義のみを指定する。CRTSRCLFコマンドにてソース論理ファイルを作成し、図表4のように定義が完成したら、CRTLFコマンドにより論理ファイルが作成される。

デジタル・トランスフォーメーションにおいて、企業が有する大量のデータを最新のAIやIoTなどのデジタル技術と組み合わせ、これまでにない新たな価値や体験を生み出し、世の中が変わっていく事例を多く目にしていることと思う。

企業が持つ「データ」の価値の重要性が、これまで以上に高まっていることは言うまでもない。この重要な「データ」をさらに活かすためにも、今後のDb2 for iの動向や活用は意識しておきたい。