キー順アクセス・パスは、データ記述仕様 (DDS) で定義されたキー・フィールドの内容に基づきます。
この種のアクセス・パスは、レコードの追加または削除が行われるたびに、あるいはレコードが更新されて キー・フィールドの内容が変わったときに更新されます。キー順アクセス・パスは、物理ファイルと論理フ ァイルの両方で有効です。ファイル内のレコード順序は、ファイルの作成時に DDS で定義され、システム により自動的に保守されます。
文字フィールドとして定義したキー・フィールドは、EBCDIC 文字用に定義されている順序に基づいて配 列されます。数字フィールドとして定義したキー・フィールドは、そのフィールドについて UNSIGNED (符号なしの値) または ABSVAL (絶対値) DDS キーワードが指定されない限り、代数の値に基づいて配列 されます。 キー・フィールドを 2 バイト文字セットとして定義することもできますが、ビット表現に基づ く、1 バイト文字として配列されるにすぎません。
フィールド・プロシージャーを持つ物理ファイル・フィールドは、正しい配列つまり正しい順序にみえない ことがあります。その理由は、アクセス・パスが、ファイル内のフィールドに返されるデータの外部形式で はなく、アクセス・パスに保管されるデータの内部形式を持っているためです。このように順序が間違って いるようにみえる現象は、フィールド・プロシージャーを持つ物理ファイル・フィールド上にキー・フィー ルドが定義されている論理ファイルの場合にも発生します。このようなタイプのキー順アクセス・パスを使
用すると、等価要求 (等価の取得、次の等価、または前の等価) では正しく動作するようにみえますが、他 の取得要求 (次、前、および類似のもの) では、正しくないレコードを返すようにみえる場合があります。
代替照合順序、SRTSEQ (分類順序)、ABSVAL (絶対値)、DIGIT (桁) または ZONE (ゾーン) の使用を試 みるキー・フィールドは、フィールド・プロシージャーを持つ物理ファイル・フィールド上では許可されま せん。
代替照合順序によるキー・フィールドの配列:
文字フィールドとして定義されたキー・フィールドを EBCDIC 文字順序または代替照合順序のいずれかで 配列できます。
たとえば、以下のようなレコードがあるとします。
Record Empname Deptnbr Empnbr
1 Jones, Mary 45 23318
2 Smith, Ron 45 41321
3 JOHNSON, JOHN 53 41322
4 Smith, ROBERT 27 56218
5 JONES, MARTIN 53 62213
Empname がキー・フィールドであり、文字フィールドの場合に、EBCDIC 文字の順序を使用すると、レコ
ードは以下のように配列されます。
Record Empname Deptnbr Empnbr
1 Jones, Mary 45 23318
3 JOHNSON, JOHN 53 41322
5 JONES, MARTIN 53 62213
2 Smith, Ron 45 41321
4 Smith, ROBERT 27 56218
ここで、EBCDIC 順序により、予期しなかった順番で分類がなされたことに注意してください。これは、
小文字が大文字よりも前に分類されるからです。したがって、Smith, Ron は Smith, ROBERT よりも前に分 類されることになります。代替照合順序を使用すると、大文字と小文字を使用して入力されたレコードを、
以下の例のように分類することができます。
Record Empname Deptnbr Empnbr
3 JOHNSON, JOHN 53 41322
5 JONES, MARTIN 53 62213
1 Jones, Mary 45 23318
4 Smith, ROBERT 27 56218
2 Smith, Ron 45 41321
文字のキー・フィールドに対して代替照合順序を使用するには、 DDS の ALTSEQ キーワードを指定し、
代替照合順序が入っている表の名前を指定します。表を作成する場合、表の各 2 バイトを 1 つの文字に対 応させます。文字を分類する順番を変更するには、2 桁の値を、分類させるときに等価とする文字と同じ値 に変更します。大文字と小文字を区別しないで分類する場合の説明については、ライブラリー QUSRSYS の QCASE256 表に用意されています。
関連概念:
DDS の概念
SRTSEQ パラメーターを使用したキー・フィールドの配列:
SRTSEQ パラメーターを使用して、文字データを含むキー・フィールドを分類順序で配列することができ
ます。
たとえば、以下のようなレコードがあるとします。
Record Empname Deptnbr Empnbr
1 Jones, Marilyn 45 23318
2 Smith, Ron 45 41321
3 JOHNSON, JOHN 53 41322
4 Smith, ROBERT 27 56218
5 JONES, MARTIN 53 62213
6 Jones, Martin 08 29231
Empname フィールドがキー・フィールドで、かつ文字フィールドである場合は、*HEX 順序 (EBCDIC 順
序) により次のようにレコードが配列されます。
Record Empname Deptnbr Empnbr
1 Jones, Marilyn 45 23318
6 Jones, Martin 08 29231
3 JOHNSON, JOHN 53 41322
5 JONES, MARTIN 53 62213
2 Smith, Ron 45 41321
4 Smith, ROBERT 27 56218
*HEX 順序では、すべての小文字が大文字より前に分類されることに注意してください。したがって、
Smith, Ron は Smith, ROBERT よりも前に分類されることになります。また、JOHNSON, JOHN は小文字と大
文字の Jones の間に分類されます。レコードが大/小文字の混合形式で入力されている場合は、レコードの
分類のために *LANGIDSHR 分類順序を使用することができます。大文字と小文字に対して同じ照合の順 番を使用する *LANGIDSHR 順序では、次のようなレコードになります。
Record Empname Deptnbr Empnbr
3 JOHNSON, JOHN 53 41322
1 Jones, Marilyn 45 23318
5 JONES, MARTIN 53 62213
6 Jones, Martin 08 29231
4 Smith, ROBERT 27 56218
2 Smith, Ron 45 41321
*LANGIDSHR 順序では、大文字と小文字が等価として扱われることに注意してください。したがって、
JONES, MARTIN と Jones, Martin は等価であり、基礎となるファイルと同じ順序で分類されます。これは 誤りではありませんが、報告書では、小文字の Jones をすべて大文字の JONES の前に置く方が、見た目 に良いかもしれません。レコードが大文字や小文字をそろえずに使用して入力されている場合、レコードを 分類するために、*LANGIDUNQ 分類順序を使用することができます。小文字と大文字に対して異なる (た だし、順次の) 照合の順番を使用する *LANGIDUNQ 順序では、次のようなレコードになります。
Record Empname Deptnbr Empnbr
3 JOHNSON, JOHN 53 41322
1 Jones, Marilyn 45 23318
Record Empname Deptnbr Empnbr
6 Jones, Martin 08 29231
5 JONES, MARTIN 53 62213
4 Smith, ROBERT 27 56218
2 Smith, Ron 45 41321
*LANGIDSHR および *LANGIDUNQ 分類順序は、ご使用のシステムでサポートされるあらゆる言語に対 して使用できます。 LANGID パラメーターは、*LANGIDSHR と *LANGIDUNQ のどちらの分類順序を 使用するかを決定します。 SRTSEQ パラメーターは分類順序を指定し、また LANGID パラメーターは言 語を指定するために使用します。
キー・フィールドを昇順または降順に配列:
キー・フィールドは昇順または降順に配列することができます。キー・フィールドを記述する際には、昇順 が省略時です。ただし、降順 (DESCEND) DDS キーワードを使用すれば、キー・フィールドを降順で配列 することを指定できます。
たとえば、以下のようなレコードがあるとします。
Record Empnbr Clsnbr Clsnam Cpdate
1 56218 412 Welding I 032188
2 41322 412 Welding I 011388
3 64002 412 Welding I 011388
4 23318 412 Welding I 032188
5 41321 412 Welding I 051888
6 62213 412 Welding I 032188
Empnbr フィールドがキー・フィールドの場合、このようなレコードの編成方法として以下の 2 つが考え
られます。
v 昇順。アクセス・パスのレコードの順番が以下の表に示されています。
Record Empnbr Clsnbr Clsnam Cpdate
4 23318 412 Welding I 032188
5 41321 412 Welding I 051888
2 41322 412 Welding I 011388
1 56218 412 Welding I 032188
6 62213 412 Welding I 032188
3 64002 412 Welding I 011388
v 降順。アクセス・パスのレコードの順番が以下の表に示されています。
Record Empnbr Clsnbr Clsnam Cpdate
3 64002 412 Welding I 011388
6 62213 412 Welding I 032188
1 56218 412 Welding I 032188
2 41322 412 Welding I 011388
5 41321 412 Welding I 051888
4 23318 412 Welding I 032188
複数のキー・フィールドの使用:
データベース・ファイルのレコードを配列するのに、複数のキー・フィールドを使用することができます。
キー・フィールドはみな同じ順序を使用する必要はありません。
たとえば、2 つのキー・フィールドを使用する場合、1 つのフィールドが昇順を使用し、もう一方が降順を 使用してもかまいません。たとえば、以下のようなレコードがあるとします。
Record Order Ordate Line Item Qtyord Extens
1 52218 063088 01 88682 425 031875
2 41834 062888 03 42111 30 020550
3 41834 062888 02 61132 4 021700
4 52218 063088 02 40001 62 021700
5 41834 062888 01 00623 50 025000
アクセス・パスが、キー・フィールドとしてまず Order フィールド、次に Line フィールドを両方とも昇 順で使用すると、アクセス・パスのレコードの順番は以下のようになります。
Record Order Ordate Line Item Qtyord Extens
5 41834 062888 01 00623 50 025000
3 41834 062888 02 61132 4 021700
2 41834 062888 03 42111 30 020550
1 52218 063088 01 88682 425 031875
4 52218 063088 02 40001 62 021700
アクセス・パスが、キー・フィールドとしてまず Order を昇順で使用し、次に Line フィールドを降順で 使用すると、アクセス・パスのレコードの順番は以下のようになります。
Record Order Ordate Line Item Qtyord Extens
2 41834 062888 03 42111 30 020550
3 41834 062888 02 61132 4 021700
5 41834 062888 01 00623 50 025000
4 52218 063088 02 40001 62 021700
1 52218 063088 01 88682 425 031875
1 つのファイル内で、あるレコードのキー・フィールドの内容が、別のレコードのキー・フィールドの内容 と同じであった場合には、重複キー値を持つレコードがあるファイルということになります。ただし、重複 キー値と呼べるのは、1 つのレコードのすべての キー・フィールドで重複している場合だけです。たとえ ば、レコード様式に Order と Ordate の 2 つのキー・フィールドがある場合は、 Order と Ordate の両 方のフィールドの内容が複数のレコードで同一のときに、重複キー値が生じます。これらのレコードには、
重複キー値があります。
Order Ordate Line Item Qtyord Extens
41834 062888 03 42111 30 020550
41834 062888 02 61132 04 021700
41834 062888 01 00623 50 025000
Line フィールドを 3 番目のキー・フィールドとして使用してファイルを定義すると、重複キーがなくなり ます。
(第 1 キー・フィール ド) order
(第 2 キー・フィール ド) ordate
(第 3 キー・フィー
ルド) line Item Qtyord Extens
41834 062888 03 42111 30 020550
41834 062888 02 61132 04 021700
41834 062888 01 00623 50 025000
複数のレコード様式を持つ論理ファイルには、それらのレコード様式が異なる物理ファイルに基づくもので あっても、重複キー値を持つレコードを含むことができます。つまり、キー値は、別々のレコード様式から のものであっても、重複キー値であるとみなされます。
重複キー値の防止:
DB2 for i では、データベース・ファイルのレコードは重複キー値を持つことができます。ただし、ファイ
ルに重複キー値が含まれないようにすることができます。
たとえば、キー・フィールドを顧客番号フィールドとして定義するファイルを作成する場合、システムにフ ァイルの各レコードが固有の顧客番号を持つことを確かめることが望まれます。
ファイルに重複キー値がないようにするには、データ記述仕様 (DDS) で UNIQUE キーワードを指定しま す。UNIQUE キーワードを指定すると、キー値がすでにファイルに存在するレコードのキー値と同じであ る場合、レコードを入力したり、またはファイルにコピーしたりできなくなります。また固有制約を用いて も、強制的に固有キーの保全性を保つことができます。
重複キー値を持つ複数のレコードが物理ファイルにすでに存在する場合には、関連する論理ファイルでは
UNIQUE キーワードを指定できません。関連する物理ファイルに重複キー値が入っているのに、 UNIQUE
キーワードを指定して論理ファイルを作成しようとしても、論理ファイルは作成されません。システムから は、その旨を示すメッセージが送られ、さらに、どのレコードに重複キー値が入っているかを示すメッセー ジ (最大 20 個) が送られます。
ファイルに UNIQUE キーワードを指定した場合、新しいレコードを追加するためにどのようなファイルを 使用したとしても、ファイルに追加されたいずれかのレコードは、ファイル内の既存のレコードのキー値と 重複するキー値を持つことはできません。たとえば、LF1 と LF2 の 2 つの論理ファイルが、物理ファイ ル PF1 を基にしているとします。LF1 には、UNIQUE キーワードが指定されています。PF1 にレコード を追加するのに LF2 を使用した場合に、LF1 に重複キー値が発生するようなときはレコードが追加できな くなります。
キー・フィールドのいずれかで NULL 値が許可されている場合、このようなフィールドに挿入された NULL 値は、ファイルの作成時にアクセス・パスをどのように定義したかによって、重複となる場合とな らない場合があります。 UNIQUE キーワードの *INCNULL パラメーターは、固有のアクセス・パスに重 複キーが存在するかどうかを判別するときに、NULL 値を含めることを示します。*EXCNULL パラメータ ーは、重複キー値が存在するかどうかを判別するときに、NULL 値を含めないことを示します。
以下の例は、固有のキー値を必要とする論理ファイルの DDS を示しています。
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8 A* ORDER TRANSACTION LOGICAL FILE (ORDFILL)
A UNIQUE
A R ORDHDR PFILE(ORDHDRP)
A K ORDER
A