• 検索結果がありません。

論理ファイルの作成

ドキュメント内 rbafopdf.ps (ページ 51-58)

論理ファイルは、1 つ以上の物理ファイルのレコード様式を定義するもので、データは入れません。データ

記述仕様 (DDS) を使用して、さまざまな論理ファイルを作成し、そのレコード様式およびアクセス・パス

を記述することができます。

論理ファイルをセットアップするための規則の大半は、すべての種類の論理ファイルに適用されます。これ らのトピックでは、1 つのカテゴリーの論理ファイルにしか適用されない規則については、それがどのカテ ゴリーに適用されるかを明記しています。すべてのカテゴリーの論理ファイルに適用できる規則については 特定のカテゴリーを明記していません。

論理ファイルの作成

データ記述仕様 (DDS) を使用して論理ファイルを作成できます。

論理ファイルを作成する前に、論理ファイルの基礎となる 1 つ以上の物理ファイルがすでに存在していな ければなりません。

論理ファイルを作成するには、以下のステップに従ってください。

1. 論理ファイルの DDS をソース・ファイルに入力します。 これは、原始ステートメント入力ユーティリ

ティー (SEU) を使用して行うことができます。次の例は、論理ファイル ORDHDRL (発注ヘッダー・

ファイル) の DDS を示しています。

|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8 A* ORDER HEADER LOGICAL FILE (ORDHDRL)

A R ORDHDR PFILE(ORDHDRP)

A K ORDER

このファイルは、キー・フィールド Order (発注番号) を使用してアクセス・パスを定義しています。

レコード様式は、関連する物理ファイル ORDHDRP と同一です。論理ファイルのレコード様式名は、

フィールド記述を指定していないため、物理ファイルのレコード様式名と同じである必要があります。

2. 論理ファイルを作成します。 「論理ファイルの作成 (CRTLF)」コマンドを使用できます。次の例は、

CRTLF コマンドの入力方法を示します。

CRTLF FILE(DSTPRODLB/ORDHDRL)

TEXT('Order header logical file')

示されているように、このコマンドではいくつかの省略時が使用されています。たとえば、SRCFILE およ

び SRCMBR パラメーターが指定されていないため、システムは IBM 提供のソース・ファイル

QDDSSRC からの DDS を使用し、ソース・ファイル・メンバー名は ORDHDRL (CRTLF コマンドで指定 されているファイル名と同じ) になります。同じ名前の 1 つのメンバーを持つファイル ORDHDRL ファ イルは、DSTPRODLB ライブラリーに配置されます。

1 つの物理ファイルに複数の論理ファイルを作成することができます。1 つの物理ファイルに作成できる論 理ファイルの最大数は 32KB です。

ビューは論理ファイルと似ています。 System i ナビゲーターを使用して、または CREATE VIEW SQL ステートメントを使用してビューを作成できます。

関連概念:

271ページの『ソース・ファイルの処理』

さまざまな方法を使用して、データをソース・ファイルに入力して保守できます。

222ページの『複数の様式を持つファイルに追加するレコード様式の識別』

アプリケーションがデータベースに追加されるレコードに対してレコード様式名の代わりにファイル名を使 用しており、しかも使用するファイルが複数のレコード様式を持つ論理ファイルである場合には、データベ ースのどこにレコードを入れるかを決めるために、様式選択プログラムを作成する必要があります。

ビューの作成と使用 関連資料:

論理ファイルの作成 (CRTLF) コマンド CREATE VIEW

複数のレコード様式を持つ論理ファイルの作成:

複数様式論理ファイルを用いると、1 つの論理ファイルを参照するだけで複数の物理ファイルからのレコー ドを使用できるようになります。

そうした複数様式論理ファイルのそれぞれのレコード様式は、常に 1 つ以上の物理ファイルと関連してい ます。複数のレコード様式で同じ物理ファイルを使用することができます。

以下の例は、フィールド参照ファイルから作成される物理ファイル ORDDTLP のデータ記述仕様 (DDS) を示しています。

|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8 A* ORDER DETAIL FILE (ORDDTLP) - PHYSICAL FILE RECORD DEFINITION

A REF(DSTREF)

A R ORDDTL TEXT('Order detail record')

A CUST R

A ORDER R

A LINE R

A ITEM R

A QTYORD R

A DESCRP R

A PRICE R

A EXTENS R

A WHSLOC R

A ORDATE R

A CUTYPE R

A STATE R

A ACTMTH R

A ACTYR R

A

以下の例は、ORDHDRP 物理ファイルの DDS を示しています。

|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8 A* ORDER HEADER FILE (ORDHDRP) - PHYSICAL FILE RECORD DEFINITION

A REF(DSTREFP)

A R ORDHDR TEXT('Order header record')

A CUST R

A ORDER R

A ORDATE R

A CUSORD R

A SHPVIA R

A ORDSTS R

A OPRNME R

A ORDMNT R

A CUTYPE R

A INVNBR R

A PRTDAT R

A SEQNBR R

A OPNSTS R

A LINES R

A ACTMTH R

A ACTYR R

A STATE R

A

次の例では、2 つのレコード様式を持った論理ファイル ORDFILL を作成する方法を示します。1 つのレ コード様式は ORDHDRP 物理ファイルからの発注ヘッダー・レコードに対して定義され、もう 1 つのレ コード様式は ORDDTLP 物理ファイルからの発注明細レコードに対して定義されます。

論理ファイルのレコード様式 ORDHDR は、順序付けのために 1 つのキー・フィールド Order を使用し ています。また、論理ファイルのレコード様式 ORDDTL は、順序付けのために OrderLine の 2 つの キー・フィールドを使用しています。

以下の例は、ORDFILL 論理ファイルの DDS を示しています。

|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8 A* ORDER TRANSACTION LOGICAL FILE (ORDFILL)

A R ORDHDR PFILE(ORDHDRP)

A K ORDER

A

A R ORDDTL PFILE(ORDDTLP)

A K ORDER

A K LINE

A

2 つの関連する物理ファイルを持つ論理ファイル ORDFILL を作成するためには、以下の方法で「論理フ ァイルの作成 (CRTLF)」コマンドを使用します。

CRTLF FILE(DSTPRODLB/ORDFILL)

TEXT('Order transaction logical file')

DDS ソースは、QDDSSRC ファイルの ORDFILL メンバーの中にあります。同じ名前のメンバーを持つフ ァイル ORDFILL ファイルは、DSTPRODLB ライブラリーに配置されます。ORDFILL 論理ファイル・メ

ンバーのアクセス・パスは、ORDHDRP と ORDDTLP の両ファイルからのレコードを配列します。両方の 物理ファイルのレコード様式は、共通のフィールドである Order がキーとなっています。それらのレコー ド様式は、それらが論理ファイル記述で指定された順序のために、最初に ORDHDRP ヘッダー・ファイル から、次に ORDDTLP 明細ファイルから取り出されたファイル間の重複を使用して、Order の順序で組み 合わせられます。 FIFO、LIFO、あるいは FCFO を指定していないので、同じファイル内の重複キーを取 り出す順序は保証されません。

注: いくつかの条件下では、複数様式論理ファイルを使用するよりも、複数の論理ファイルを使用した方が 良い場合があります。たとえば、キー順アクセスが複数様式論理ファイルで使用されたとき、ファイルの 1 つにほとんどレコードがない場合には、パフォーマンスが低下する可能性があります。複数様式であって も、論理ファイルは 1 つの索引 (それぞれの物理ファイルからの項目が入った) しか持ちません。アプリ ケーション・プログラムにより行われている処理の種類により (たとえば、小さいファイルを処理するキー とともに RPG SETLL と READE を使用している場合) 、システムは小さいファイルの項目を見つけるた めにすべての索引項目を検索しなければならないかもしれません。索引が多くの項目をもつ場合は、各ファ イルのキーの数と索引のキーの順序によっては、索引検索にかなりの時間がかかるかもしれません。(小さ いファイルにレコードがない場合は、パフォーマンスは影響を受けません。なぜなら、システムは高速パス を使用し、索引を検索しないからです。)

複数の様式を持つ論理ファイル内でのレコードの取り出し方法の制御:

複数のレコード様式を持つ論理ファイルにはキー・フィールド定義が必要です。

それぞれのレコード様式は独自のキー・フィールド定義を持つことができます。レコード様式のキー・フィ ールドを別の様式のレコードと組み合わせるように定義することができます。各々のレコード様式ではキー にすべてのキー・フィールドを含める必要はありません。

たとえば、以下のようなレコードがあるとします。

3. ヘッダー・レコード様式

Record Order Cust Ordate

1 41882 41394 050688

2 32133 28674 060288

4. 明細レコード様式

Record Order Line Item Qtyord Extens

A 32133 01 46412 25 125000

B 32133 03 12481 4 001000

C 41882 02 46412 10 050000

D 32133 02 14201 110 454500

E 41882 01 08265 40 008000

データ記述仕様 (DDS) では、ヘッダー・レコードの様式をまず定義してから明細レコードの様式を定義し ます。アクセス・パスが両方のレコード様式の最初のキー・フィールドとして Order フィールドを使用 し、 2 番目のレコード様式だけの 2 番目のキー・フィールドとして Line フィールドを使用する (両方と も昇順で) 場合、アクセス・パスのレコードの順序は以下のようになります。

v レコード 2

v レコード A

v レコード D

v レコード B

v レコード 1

v レコード E

v レコード C

注: 重複キー値を持つレコードは、まず、物理ファイルが指定されている順序で配列されます。その後、1 つのレコード様式の中にまだ重複が存在する場合には、重複するレコードは FIFO、LIFO、または FCFO キーワードに指定されている順序で配列されます。たとえば、論理ファイルに DDS キーワード FIFO を 指定している場合、その様式内で重複するレコードは先入れ先出しの順序で示されることになります。

複数レコード様式の論理ファイルの場合、キー・フィールドについて *NONE DDS 機能を使用して、 1 つのレコード様式のレコードを、同じアクセス・パスにある他のレコード様式のレコードから分離すること ができます。一般的に、すべてのレコード様式からのレコードはキー値に基づいて組み合わされます。 た だし、DDS で 1 つのキー・フィールドに *NONE を指定している場合には、*NONE の前のすべてのレ コード様式に現れるキー・フィールドを持つレコードだけが組み合わされます。複数のレコード様式からキ ーによってそのようなレコードが検索されるとき、 *NONE の前のすべてのレコード様式に含まれるキ ー・フィールドだけが使用されます。使用されるキー・フィールドの数を増やすには、扱うレコード様式の 数を制限してください。

次の例の論理ファイルは 3 つのレコード様式を含んでおり、それぞれ異なる物理ファイルと関連していま す。

レコード様式 物理ファイル キー・フィールド

EMPMSTR EMPMSTR Empnbr (従業員番号) 1

EMPHIST EMPHIST Empnbr, Empdat (採用日) 2

EMPEDUC EMPEDUC Empnbr, Clsnbr (クラス番号) 3

注: すべてのレコード様式には、1 つの共通のキー・フィールドである Empnbr フィールドがあります。

この例の DDS は以下のようになります。

|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8 A

A K EMPNBR 1

A

A K EMPNBR 2

A K EMPDAT

A

A K EMPNBR 3

A K *NONE

A K CLSNBR

A

*NONE は、EMPMSTR の 2 番目および 3 番目のキー・フィールドに、および EMPHIST の 3 番目のフ ィールドにあるものとみなされます。なぜなら、これらのキー・フィールドの位置の後にはキー・フィール ドが何もないからです。

レコードの配列は、以下のようになります。

Empnbr Empdat Clsnbr レコード様式名

426 EMPMSTR

426 6/15/74 EMPHIST

426 412 EMPEDUC

426 520 EMPEDUC

Empnbr Empdat Clsnbr レコード様式名

427 EMPMSTR

427 9/30/75 EMPHIST

427 412 EMPEDUC

*NONE は、レコード様式 EMPHIST と EMPEDUC の区切り記号として働きます。同じ Empnbr フィー ルドのある EMPHIST のすべてのレコードはまとめてグループ化され、Empdat フィールドによって分類さ れます。同じ Empnbr フィールドのある EMPEDUC のすべてのレコードはまとめてグループ化され、

Clsnbr フィールドによって分類されます。

注: 上記の順序付けを保証するために、キー順アクセス・パスに追加のキー・フィールド値が入れられてい るため、重複キー値は予測不可能です。

関連概念:

DDS の概念

複数の様式を持つ論理ファイルへのレコードの追加方法の制御:

複数様式論理ファイルにレコードを追加するには、レコードを書き込む物理ファイルに基づいてメンバーを 識別する必要があります。

使用しているアプリケーションで様式中の特定メンバーを指定できない場合には、論理ファイルのそれぞれ の様式を 1 つの物理ファイル・メンバーと関連付けなければなりません。基になる 1 つ以上の物理ファイ ルに複数のメンバーがある場合、 『論理ファイル・メンバーの定義』で述べている DTAMBRS パラメー ターを使用して、 1 つのメンバーを各々の様式に固有に関係付けるようにします。最後に、複数様式論理 ファイルの各々の様式に固有の名前を付けます。複数様式論理ファイルをこのような方法で定義すると、追 加操作で様式名を指定するとき、それはレコードを追加する特定の物理ファイル・メンバーとなります。

複数様式の論理ファイルにレコードを追加する場合、アプリケーション・プログラムがレコード様式名では なくファイル名を使用するときは、様式選択プログラムを作成する必要があります。

関連概念:

222ページの『複数の様式を持つファイルに追加するレコード様式の識別』

アプリケーションがデータベースに追加されるレコードに対してレコード様式名の代わりにファイル名を使 用しており、しかも使用するファイルが複数のレコード様式を持つ論理ファイルである場合には、データベ ースのどこにレコードを入れるかを決めるために、様式選択プログラムを作成する必要があります。

論理ファイル・メンバーの定義:

データを論理グループに分けるために、論理ファイルにメンバーを定義することができます。 論理ファイ ル・メンバーは、1 つまたはいくつかの物理ファイル・メンバーと関連付けることができます。

次の図は、この概念を図示しています。

ドキュメント内 rbafopdf.ps (ページ 51-58)