|
このセクションでは、インデックスを作成できる Btrieve データ型(キー タイプ)について説明します。MicroKernel は内部的に、文字列キーを 1 バイトずつ左から右へ比較します。デフォルトで、MicroKernel は ASCII 値に基づいて文字列キーをソートします。しかし、文字列キーは、大文字小文字を無視したり、オルタネート コレーティング シーケンス(ACS)を使用するように定義することもできます。
MicroKernel は、符号なしバイナリ キーを一度に 1 WORD ずつ比較します。Intel 8086 プロセッサ ファミリは Integer の上位バイトと下位バイトを反転させるため、MicroKernel はこれらのキーを右から左へ比較します。
特定のデータ型が複数のサイズで使用できる(たとえば、4 バイトと 8 バイトの FLOAT 値が使用できる)場合は、(新しいキーの作成に使用される)キー長パラメーターにより、そのキーのすべての値に適用されるサイズが定義されます。許可されていないキーの長さを使ってキーを定義しようとすると、ステータス 29(キー長が不正)になります。
次の表は、キー タイプとそれに関連付けられたコードの一覧を示します。表に続いて、各キー タイプの内部記憶形式について説明します。
AUTOINC キー タイプは、2 バイトまたは 4 バイト長の符号付き Intel 整数です。AUTOINC キーは、内部的に Intel バイナリ整数形式で格納され、WORD 内で上位バイトと下位バイトが反転されています。MicroKernel は AUTOINC キーをその絶対値を基に、右から左へと一度に 1 WORD ずつ別のレコードに保存されている値と比較してソートします。AUTOINC キーを使用すると、ファイルにレコードを挿入するとき、既存の最大の値より 1 大きい値を自動的に割り当てることができます。値は絶対値を基にソートされるため、データ型が符号付きと考えた場合、可能性のあるレコード数は期待するレコード数のおおよそ半分になります。
ファイルから削除された値は、自動的には再使用されません。挿入または更新でゼロ(0)値を入力したら次に来る値を割り当てるようにデータベース エンジンに指示している場合、データベースは単純に最も大きい値を調べ、その値に 1 を足した結果を挿入します。
すべてのレコードまたは一部のレコードで 1 つのフィールドの値を 0 に初期化し、後から AUTOINC タイプのインデックスを追加できます。この機能により、必要になるまで実際にインデックスを作成しなくても AUTOINC キーの準備をすることができます。
インデックスを追加すると、MicroKernel は各フィールドの 0 値を適切に変更します。値の番号付けは、そのフィールドで現在定義されている最大値に 1 を足した値から始まります。フィールドに 0 以外の値が存在する場合、MicroKernel はそれらを変更しません。ただし、0 以外の重複する値がフィールドに存在する場合は、MicroKernel はエラー ステータス コードを返します。
MicroKernel は、AUTOINC キーを含んでいる各オープン ファイルに関連付けられる自動インクリメント値の、以前に使用した最大値を保持します。この値は、AUTOINC フィールドに ASCII ゼロを含むレコードについて INSERT オペレーションが発生した場合にのみ、確立されて増加します。キー ページの並行性を利用して同時変更が行えるように、値はすべてのクライアントから使用されます。
ファイルの次の AUTOINC 値は、前の AUTOINC 値を使った INSERT が発生するたびに増加されます。これは、INSERT がトランザクション内にあるかどうか、また変更がコミットされるかどうかに関係なく起こります。
ただし、以下の項目がすべて真の場合には、INSERT 中にこの値を小さくすることができます。
つまり、1 トランザクション内の最初の INSERT のみが、次回使用可能な AUTOINC 値を小さくすることができます。その後、次回使用可能な AUTOINC 値は増加し続けます。
例を示して、AUTOINC 値を小さくできる方法をわかりやすくしましょう。レコード 1、2、3 および 4 を含む自動インクリメント ファイルがあるとします。次回使用可能な AUTOINC 値は 5 です。
クライアント1 がトランザクションを開始し、新しいレコードを 2 件挿入すると、次回使用可能な AUTOINC 値は 7 に増えます(クライアント1 は値 5 と 6 を取得します)。クライアント2 がトランザクションを開始し、また新しいレコードを 2 件挿入します。これにより、次回使用可能な AUTOINC 値は 9 に増えます(クライアント2 は値 7 と 8 を取得します)。
クライアント1 がレコード 4、5、6 を削除します。次回使用可能な AUTOINC 値は INSERT でしか調整されないので、同じ値のままです。次に、クライアント1 がコミットを行います。コミットされたバージョンのファイルには、現在レコード 1、2 および 3 が含まれています。
クライアント2 の場合、ファイルにはレコード 1、2、3、7 および 8 が含まれます(7 と 8 はまだコミットされていません)。次にクライアント2 がもう 1 件レコードを挿入すると、レコード 9 になり、次回使用可能な AUTOINC 値は 10 に増えます。クライアント2 がレコード 3、7、8、9 を削除します。クライアント2 では、現在ファイルにはコミット済みのレコード 1 と 2 だけが含まれています。
次にクライアント2 がもう 1 件レコードを挿入すると、レコード 10 になります。次回使用可能な AUTOINC 値は 11 に増えます。この値は、変更を含んでいるページに保留状態のほかの変更があるため、3 に減らされません。
次に、クライアント2 がトランザクションを中止します。コミットされたバージョンのファイルには、現在レコード 1、2 および 3 が含まれていますが、次回使用可能な AUTOINC 値は 11 のままです。
どちらかのクライアントが、トランザクションの内外を問わずもう 1 件レコードを挿入すると、次回使用可能な AUTOINC 値は 4 に減少されます。これは、値を小さくするのに必要な条件がすべて真であるために起こります。
自動インクリメントした値が範囲外になる場合は、ステータス コード 5 が返されます。データベース エンジンは、値の「折り返し」を試みることも、再度ゼロから始めることもしません。ただし、以前に挿入した値が削除されており、自動インクリメントのシーケンス中で欠番になっている箇所がわかる場合は、未使用値を直接挿入することができます。
AUTOINC キーには、次の制限が適用されます。
ファイルにレコードを挿入すると、MicroKernel は AUTOINC キー値を次のように扱います。
BFLOAT キー タイプは、単精度実数または倍精度実数です。単精度実数は、23 ビットの仮数、128 でバイアスされた 8 ビットの指数、およびサイン ビットで格納されます。4 バイト float の内部レイアウトは次のとおりです。
倍精度実数の表現法は、仮数が 23 ビットではなく 55 ビットである点を除いては、単精度実数の表現法と同じです。最小有効数字の 32 ビットは、バイト 0 から 3 に格納されます。
BFLOAT 型は、一般に古い BASIC アプリケーションで使用されます。Microsoft はこのデータ型を MBF(Microsoft Binary Format)と呼びますが、Visual Basic 環境でこの型はサポートしていません。新しいデータベース定義では、BFLOAT ではなく FLOAT を使用する必要があります。
メモ
旧バージョンの Pervasive PSQL では、このデータ型は STRING と呼ばれていました。
CHAR キー タイプは、左から右へ並んだ文字の連なりです。キー値がヌルであるかどうかを MicroKernel が判定する場合を除いて、各文字は単一バイトに ASCII 形式で表されます。CHAR データは、キーのサイズいっぱいになるまで空白を埋め込む必要があります。
CURRENCY キー タイプは、8 バイトの符号付き数値を表し、Intel バイナリ整数形式で並べ替えられ格納されています。このため、その内部表現法は 8 バイトの INTEGER データ型と同じです。CURRENCY データ型には、小数点以下に 4 桁が想定されており、通貨のデータ値の分数部分を表します。
DATE キー タイプは、内部的に 4 バイト値として格納されます。日と月はそれぞれ 1 バイトのバイナリ形式で格納されます。年は、年の値全体を表す 2 バイトのバイナリ数です。MicroKernel は、日を 1 番目のバイトに、月を 2 番目のバイトに、年を月に続く 2 バイトの WORD に置きます。
日付フィールドに使用する C 言語の構造体の例を示します。
日付フィールドの year 部には、年全体の整数表現が設定されるようにする必要があります。たとえば、2001 年の場合は 2,001 です。
DECIMAL キー タイプは、内部的に、1 バイトごとに 2 つの 10 進数を含む、パックされた 10 進数として格納されます。n バイトの DECIMAL フィールドの内部表現法は次のとおりです。
サイン ニブルは、正の数の場合は 0xF または 0xC で、負の数の場合は 0xD です。Pervasive ODBC および Pervasive ActiveX コントロールでは常に、正のサイン ニブルに 0xF を使用します。小数点は含意されているため、DECIMAL フィールドには格納されません。DECIMAL フィールドの値の小数点位置のトラッキングはアプリケーションが行います。MicroKernel がキーを正しく照合するために、DECIMAL キー タイプの値はすべて、小数点以下の桁数を同じにする必要があります。DECIMAL 型は、一般に COBOL アプリケーションで使用されます。
8 バイトの decimal は、15 桁の数字とサインを保持することができます。10 バイトの decimal では、19 桁の数字とサインを保持できます。decimal 値は、左側の桁をゼロで埋める必要があります。
注意
C 言語の定義が FLOAT(4 バイト)または DOUBLE(8 バイト)データ型に対してサポートしている精度を超える精度は失われます。小数点以下の桁数が多い数値に精度が要求される場合は、DECIMAL 型の使用を考慮してください。
FLOAT キー タイプは、単精度実数または倍精度実数の IEEE 規格に準拠しています。4 バイト FLOAT の内部形式は次のように、23 ビットの仮数、127 でバイアスされた 8 ビットの指数、およびサイン ビットで構成されます。
8 バイトの FLOAT キーは、52 ビットの仮数、1023 でバイアスされた 11 ビットの指数、およびサイン ビットを持ちます。内部形式は次のとおりです。
GUID データ型は 16 バイトの数字で、内部的には 16 バイトのバイナリ値として格納されます。拡張データ型の値は 27 です。
通常、GUID はグローバルな一意識別子として使用されます。これはリレーショナル インターフェイスの UNIQUEIDENTIFIER データ型に相当します(UNIQUEIDENTIFIER を参照してください)。
GUID は 9.5 以上のファイル形式を必要とすることに注意してください。
GUID を構成するバイトのソート順序は、10、11、12、13、14、15、8、9、6、7、4、5、0、1、2、3 という順序で比較されます。
GUID のキー セグメント長は 16 バイトにする必要があります。開発者リファレンス『Btrieve API Guide』の「キー仕様ブロック」を参照してください。
INTEGER キー タイプは、符号付き整数で、偶数バイトを保持する必要があります(1 は例外)。何桁の数字でも含むことができます。INTEGER フィールドは、内部的に Intel バイナリ整数形式で格納され、WORD 内で上位バイトと下位バイトが反転されています。MicroKernel は、キーを右から左へと一度に 1 WORD ずつ評価します。サインは、右端のバイトの上位ビットに格納しなければなりません。INTEGER 型は、ほとんどの開発環境でサポートされています。
長さ(バイト単位)
|
値の範囲
|
---|---|
1
|
0 - 255
|
2
|
-32768 - 32767
|
4
|
-2147483648 - 2147483647
|
8
|
-9223372036854775808 - 9223372036854775807
|
LOGICAL キー タイプは、1 バイト値または 2 バイト値として格納されます。MicroKernel は LOGICAL キー タイプを文字列として照合します。これにより、アプリケーションは、格納されている真または偽を表す値を判定することができます。
LSTRING キー タイプは、文字列の最初のバイトに文字列の長さのバイナリ表現を含む点を除いて、通常の STRING 型と同じ特性を持ちます。LSTRING キー タイプのサイズは、最大 255 バイトに制限されています。LSTRING キーのバイト 0 に格納されている長さにより、有効バイト数が判断されます。データベース エンジンは、値をソートまたは検索する際、指定された文字列の長さを超える値はすべて無視します。LSTRING 型は、一般に古い Pascal アプリケーションで使用されます。
MONEY キー タイプの内部表現法は DECIMAL 型と同じですが、小数点以下が 2 桁に想定されます。
NUMERIC データ型の数字はそれぞれ 1 バイトを占めます。NUMERIC 値は、先頭に 0 を付けて右揃えされ、ASCII 文字列として格納されます。数値の右端のバイトには、埋め込み符号が EBCDIC 値で含まれます。デフォルトで、正の NUMERIC データ型の符号値は符号なし数値です。NUMERIC 型は、一般に COBOL アプリケーションで使用されます。
オプションで、正の NUMERIC データ型の符号の値をシフトするよう指定できます。次の表は、符合値のデフォルト(シフトされていない)状態とシフトされた状態の比較を示します。
桁
|
デフォルト(シフトなし)の符合値
|
シフトされた符合値
|
||
---|---|---|---|---|
|
正
|
負
|
正
|
負
|
1
|
1
|
J
|
A
|
J
|
2
|
2
|
K
|
B
|
K
|
3
|
3
|
L
|
C
|
L
|
4
|
4
|
M
|
D
|
M
|
5
|
5
|
N
|
E
|
N
|
6
|
6
|
O
|
F
|
O
|
7
|
7
|
P
|
G
|
P
|
8
|
8
|
Q
|
H
|
Q
|
9
|
9
|
R
|
I
|
R
|
0
|
0
|
}
|
{
|
}
|
シフト形式を有効にするには、Pervasive PSQL データベース エンジンが実行されているマシンで、ある設定を手動で指定しなければなりません。設定 DBCobolNumeric を "yes" にセットします。次の表は、設定の指定方法について、エンジンのサーバー プラットフォームごとにまとめてあります。完全な手順については、NUMERIC を参照してください。
サーバー プラットフォーム
|
設定の指定方法
|
---|---|
Windows 32 ビット
|
オペレーティング システムで提供されるレジストリ エディターを使用して、DBCobolNumeric 設定を次のキーの新しい文字列値としてレジストリに追加します。
HKEY_LOCAL_MACHINE/SOFTWARE/PERVASIVE SOFTWARE/DATABASE NAMES/VERSION x / SETTINGS
(x はバージョン番号を表します)
文字列値に "yes" を設定します。
メモ:ほとんどの Windows オペレーティング システムで、"Pervasive Software" のキーの場所は
HKEY_LOCAL_MACHINE ¥ SOFTWARE ¥ PERVASIVE SOFTWARE です。ただし、HKEY_LOCAL_MACHINE ¥ SOFTWARE の下位以降の場所はオペレーティング システムによって異なる可能性があります。
注意:レジストリの編集は高度な操作です。誤って編集すると、オペレーティング システムが起動しなくなる恐れがあります。必要であれば、経験豊富な技術者に依頼して編集を行ってもらってください。Pervasive Software はレジストリの破損に対して責任を負いません。
データベース エンジンまたはエンジン サービスを停止して、再起動します。『Pervasive PSQL User's Guide』の Windows サーバー上でのサーバー エンジンの起動と停止および Windows 上でのワークグループ エンジンの起動と停止を参照してください。
|
Linux
|
bti.ini の [Database Names] エントリの下に DBCobolNumeric 設定を追加します。
[Database Names]
デフォルトでは、bti.ini は /usr/local/psql/etc ディレクトリにあります。
データベース エンジンを停止して、再起動します。『Pervasive PSQL User's Guide』の Linux 上でのデータベース エンジンの起動と停止を参照してください。
|
符合値がデフォルト(シフトされていない)形式で含まれている正の NUMERIC データが既にあるかもしれません。DBCobolNumeric を "yes" に設定した後、引き続き同じテーブルへデータを追加すると、形式が混在することになります。データの符合値の形式を混在させたままにしておくことはお勧めできません。
形式が混在した状態を解消する、あるいは防ぐには、UPDATE ステートメントを使用して、NUMERIC 列をその列自身で更新します。たとえば、テーブル t1 には NUMERIC データ型の列 c1 があるとします。DBCobolNumeric を "yes" に設定後、c1 を UPDATE TABLE t1 SET c1 = c1 のように更新します。
UPDATE を参照してください。
NUMERICSA キー タイプ(NUMERIC SIGNED ASCII と呼ばれることもあります)は、COBOL データ型で、埋め込みサインが EBCDIC 値ではなく ASCII 値である点を除けば、NUMERIC データ型と同じです。
桁
|
デフォルトの符号値
|
|
---|---|---|
|
正
|
負
|
1
|
1 または Q
|
q
|
2
|
2 または R
|
r
|
3
|
3 または S
|
s
|
4
|
4 または T
|
t
|
5
|
5 または U
|
u
|
6
|
6 または V
|
v
|
7
|
7 または W
|
w
|
8
|
8 または X
|
x
|
9
|
9 または Y
|
y
|
0
|
0 または P
|
p
|
NUMERICSLB キー タイプ(SIGN LEADING と呼ばれることもあります。Cobol コンパイラ オプション -dcb を使用します)は、COBOL データ型で、NUMERIC データ型の値と似た値を持ちます。NUMERICSLB 値は、先頭に 0 を付けて右揃えされ、ASCII 文字列として格納されます。
NUMERICSLS キー タイプ(SIGN LEADING SEPARATE と呼ばれることもあります)は、COBOL データ型で、NUMERIC データ型の値と似た値を持ちます。NUMERICSLS 値は、先頭に 0 を付けて左揃えされ、ASCII 文字列として格納されます。ただし、NUMERICSLS 文字列の左端のバイトは、「+」(ASCII 0x2B)か「-」(ASCII 0x2D)のいずれかになります。この点が、右端のバイトにそのバイトの値と共に符号を埋め込む NUMERIC 値とは異なります。
NUMERICSTB キー タイプ(SIGN TRAILING と呼ばれることもあります。Cobol コンパイラ オプション -dcb を使用します)は、COBOL データ型で、NUMERIC データ型の値と似た値を持ちます。NUMERICSTB 値は、先頭に 0 を付けて右揃えされ、ASCII 文字列として格納されます。
NUMERICSTS キー タイプ(SIGN TRAILING SEPARATE と呼ばれることもあります)は、COBOL データ型で、NUMERIC データ型の値と似た値を持ちます。NUMERICSTS 値は、先頭に 0 を付けて右揃えされ、ASCII 文字列として格納されます。ただし、NUMERICSTS 文字列の右端のバイトは、「+」(ASCII 0x2B)か「-」(ASCII 0x2D)のいずれかになります。この点が、右端のバイトにそのバイトの値と共に符号を埋め込む NUMERIC 値とは異なります。
REAL 型は 4 バイト FLOAT として定義されます。
TIME キー タイプは、内部的に 4 バイト値として格納されます。100 分の 1 秒、秒、分、時の値が、それぞれ 1 バイトのバイナリ形式で格納されます。MicroKernel は、100 分の 1 秒の値を最初のバイトに、それ以降のバイトにそれぞれ、秒、分、時の値を置きます。
TIMESTAMP データ型は日付と時刻の値を表します。SQL アプリケーションでは、このデータ型を使用して、レコードを最後に更新した日付と時刻をレコードにスタンプします。TIMESTAMP 値は、グレゴリオ暦 0001 年 1 月 1 日の世界協定時刻(UTC)から経過したセプタ秒(10-7 秒)を表す、8 バイトの符号なし値として格納されます。
メモ
ODBC 標準に従って、CURRENT_TIMESTAMP() や NOW() などのスカラー関数は、データ型のうち小数の秒を表す部分は無視します。これらの関数を使用する際、Pervasive PSQL は小数の秒を無視しないで、3 桁のミリ秒を表示するという点に注意することが重要です。
TIMESTAMP は、次の構成要素から成る日付と時刻の値を扱うことを目的としています。構成要素は、年、月、日、時、分、秒、ミリ秒です。次の表は、これらの各構成要素で有効な値を示します。
YEAR
|
0001 から 9999
|
MONTH
|
01 から 12
|
DAY
|
01 から 31、グレゴリオ暦の年と月の値によって決められます。
|
HOUR
|
00 から 23
|
MINUTE
|
00 から 59
|
SECOND
|
00 から 59
|
MILLISECOND
|
000 から 999
|
値は、内部的に TIMESTAMP MicroKernel キーとして格納されます。これは 8 バイト長のフィールドで、タイムスタンプ精度が示す秒の分数に変換された日付値および時刻値全体を含みます。たとえば、タイムスタンプ精度が 6 の場合はマイクロ秒に変換され、タイムスタンプ精度が 3 の場合はミリ秒に変換されます。
現地時刻で TIMESTAMP の値を指定すると、SRDE はそれを UTC(Coordinated Universal Time)(以前は GMT(Greenwich Mean Time)と呼びました)に変換してから、MicroKernel レコードに格納します。TIMESTAMP の値を要求すると、SRDE はそのデータを返す前に UTC から現地時刻に変換します。
注意
データベース エンジンを実行するコンピューターのタイム ゾーン情報が正しく設定されていることが重大です。タイム ゾーンをまたいだ移動をした場合、というよりタイム ゾーン情報を変更した場合、返されるデータは UTC から現地時刻に変換されるときに変わります。現地時刻/UTC 変換は、SRDE 内で、SRDE が動作している場所のタイム ゾーン情報を使用して発生します。SRDE エンジンとタイム ゾーンが異なるセッションのタイム ゾーン情報は、現地時刻/UTC 変換には使用されません。
タイムスタンプ データは格納する前に変換されるため、TIMESTAMP 型は、データベース本体の外にあるイベントを参照する現地時刻データや現地日付データでの使用には向きません。特に、季節時間の変更が行われるタイム ゾーン(米国のサマー タイムなど)ではそうです。
たとえば、10 月 15 日に、11 月 15 日午前 10 時の予定を記録するタイムスタンプ値を入力したとします。タイム ゾーンは U.S. 中部であるとします。SRDE は値を格納するとき、現在の現地時刻情報を使って値を UTC に変換します(CDT の場合、UTC - 5 時間)。したがって、時間値 15 が格納されます。11 月 1 日に予定の時刻を確認するとします。現在、お使いのコンピューターは標準時間になっています。これは、10 月にサマー タイムの切り替えが発生したためです。これにより、変換は(UTC - 6 時間)になります。予定時刻を抽出すると、現地時刻の午前 9 時(15 UTC - 6 CST)が表示されますが、これは正しい予定時刻ではありません。
データベース エンジンをあるタイム ゾーンから別のタイム ゾーンに移動させた場合も、同種の問題が発生します。
SRDE は DATE 値および TIME 値は UTC に変換しないので、外部データを記録する場合は、できる限りいつも DATE 列および TIME 列を使用することをお勧めします。TIMESTAMP 列を使用する唯一の理由は、データベースに入力したレコードの時間順を判定する固有の機能に必要だからです。
UNSIGNED BINARY キーは、キーの最大長である 255 バイトまでであれば何バイトにでもできます。UNSIGNED キーは、上位バイトから下位バイトへと 1 バイトごとに比較されます。キーの最初のバイトが下位バイトです。キーの最後のバイトが上位バイトです。
データベース エンジンは、UNSIGNED BINARY キーを符号なしの INTEGER キーとしてソートします。これらのキーの違いは、INTEGER にはサイン ビットがあるのに対し、UNSIGNED BINARY タイプにはないという点と、UNSIGNED BINARY キーは 4 バイトより長くすることができるという点です。
WSTRING は、ヌルで終わらない Unicode 文字列です。文字列の長さはフィールドの長さで決まります。WSTRING は SQL ではサポートされません。
WZSTRING は、2 つのヌルで終わる Unicode 文字列です。文字列の長さは、フィールド内の Unicode NULL(2 ヌル バイト)の位置で決まります。これは、Btrieve でサポートされる ZSTRING 型に対応します。WZSTRING は SQL ではサポートされません。
ZSTRING キー タイプは、C 文字列に対応します。ZSTRING 型は、バイナリ 0 を含むバイトで終わるという点以外は、通常の文字列型と同じ特性を持ちます。MicroKernel は、キー値がヌルかどうかを判定する場合を除き、ZSTRING 内で見つけた最初のバイナリ 0 より後の値をすべて無視します。
ZSTRING 型の最大長は、ヌル終端文字を含めて、255 バイトです。ヌル値を許可する列のキーとして使用する場合、文字列の先頭 254 バイトのみがキーに使用されます。このわずかな制限は、キーの合計長が 255 バイトに制限されていることにより生じるもので、1 バイトは列のヌル インジケーターが占めるため、残り 254 バイトだけがキー値になります。
|