CREATE TABLE

相対パス内の円記号文字は、Unix スタイル（/）と Windows の円記号（\）のどちらでも使用できます。必要であれば、2 種類の記号を混在させて使用することもできます。ディレクトリ構造スキーマは知っているかもしれませんが、接続されているサーバーの種類を知っている（あるいは管理している）とは限らないので、これは便利な機能です。パスは入力したとおりに X$File に格納されます。Zen エンジンは、パスを利用してファイルを開く際、円記号文字を適切なプラットフォームのタイプに変換します。また、データファイルはサポートされるすべてのプラットフォーム間でバイナリ互換性を共有するため、ディレクトリ構造がプラットフォーム間で同一である（および、パスに基づくファイル名が相対パスで指定されている）限りは、データベースファイルおよび DDF をこれらに変更を加えることなく、あるプラットフォームから別のプラットフォームへ移動することができます。これにより、標準化されたデータベーススキーマを使用したクロスプラットフォームの展開が可能になります。

•

相対パスを指定するとき、USING 句のディレクトリ構造は既存である必要はありません。Zen は必要に応じて、USING 句のパスのためにディレクトリを作成します。

USING 句を使用しないと、Zen により、テーブル名を基に拡張子 .mkd の一意のファイル名が生成され、データベースのデータファイルパスに指定されている最初のディレクトリにファイルが作成されます。

USING 句が既存のデータファイルを示す場合は、Zen により DDF にテーブルが作成され、SQL_SUCCESS_WITH_INFO が返されます。返された情報メッセージは、辞書エントリが既存のデータファイルをポイントするようになったことを示します。CREATE TABLE で SQL_SUCCESS のみが返されるようにしたい場合は、CREATE ステートメントで IN DICTIONARY を指定します。WITH REPLACE を指定する（下記参照）と、同一名の既存データファイルはすべて破棄され、新規に作成したファイルで上書きされます。

メモ：既存のデータファイルを指定した場合、Zen は成功を表すステータスコードを返します。

既存のデータファイルに対してリレーショナルインデックス定義を作成する（たとえば、IDENTITY 型の列定義を含む CREATE TABLE USING を使用する）たびに、Zen はそのファイルに定義されている Btrieve インデックスを自動的にチェックし、既存の Btrieve インデックスがリレーショナルインデックス定義のパラメーターのセットを提供しているかどうかを判定します。既存の Btrieve インデックスと新しい定義が一致する場合は、リレーショナルインデックス定義と既存の Btrieve インデックスの間に関連付けが作成されます。一致するインデックスがない場合は、Zen は新しいインデックス定義を作成し、IN DICTIONARY が使用されていなければ、ファイルに新しいインデックスを作成します。

WITH REPLACE

WITH REPLACE が USING キーワードと共に指定されたときはいつでも、Zen は既存のファイル名を指定されたファイル名で自動的に上書きします。オペレーティングシステムがファイルの上書きを許している場合、ファイルは常に上書きされます。WITH REPLACE はデータファイルにのみ作用します。DDF には作用しません。

WITH REPLACE を使用する際には次の規則が適用されます。

•

WITH REPLACE は USING と併せてのみ使用できます。

•

IN DICTIONARY と一緒に使用すると、WITH REPLACE は無視されます。IN DICTIONARY は DDF にのみ作用することを指定するものだからです。

CREATE TABLE ステートメントで WITH REPLACE を使用した場合、USING 句で指定された場所にファイルが存在すると、Zen は新規データファイルを作成してその既存ファイルと置き換えます。Zen は、同じ名前を持つ元のファイルに格納されているデータをすべて破棄します。WITH REPLACE を使用していないとき、指定された場所にファイルが存在すると、Zen はステータスコードを返し、新しいファイルを作成しません。ただし、テーブル定義は DDF に追加されます。

WITH REPLACE はデータファイルにのみ作用します。辞書内のテーブル定義には作用しません。

DCOMPRESS

DCOMPRESS オプションは、ディスク上のファイルサイズを減らすために、テーブルのデータファイルがレコード圧縮を使用することを指定します。次の例では、レコード圧縮を行う、ページサイズが 1024 バイトのテーブルが作成されます。

CREATE TABLE t1 DCOMPRESS PAGESIZE=1024 (c1 INT DEFAULT 10, c2 CHAR(10) DEFAULT 'abc')

詳細については、『Advanced Operations Guide』の「レコードおよびページ圧縮」を参照してください。

PCOMPRESS

PCOMPRESS オプションは、指定したテーブルのデータファイルがページ圧縮を使用することを指定します。次の例では、ページ圧縮を行う、ページサイズが 1024 バイトのテーブルが作成されます。

CREATE TABLE t1 PCOMPRESS PAGESIZE=1024 (c1 INT DEFAULT 10, c2 CHAR(10) DEFAULT 'abc')

詳細については、『Advanced Operations Guide』の「レコードおよびページ圧縮」を参照してください。

PAGESIZE

PAGESIZE オプションは、指定したテーブルのデータファイルが使用するページのサイズバイト数を指定します。サイズの値には、ファイルバージョンに応じて次のような値を指定できます。

•

512 – 4096：9.0 より前のファイルバージョンの場合（512 バイトの倍数で最大 4096 バイト）

•

512、1024、1536、2048、2560、3072、3584、4096、または 8192：ファイルバージョンが 9.0 の場合

•

1024、2048、4096、8192、または 16384：ファイルバージョンが 9.5 の場合

•

4096、8192、または 16384：ファイルバージョンが 13.0 の場合

次の例では、ファイル圧縮を行う、ページサイズが 8192 バイトのテーブルが作成されると共に、相対パスによって識別される特定のデータファイル、..\data1.mkd の作成が指定されます。

CREATE TABLE t1 DCOMPRESS PAGESIZE=8192 USING '..\data1.mkd' (c1 INT DEFAULT 10, c2 CHAR(10) DEFAULT 'abc')

LINKDUP

複数のレコードが、インデックスキーに同一の重複した値を持つことができます。重複キー値を持つレコードを記憶しておく 2 つの方法は、リンク重複（linkdup）および繰り返し重複と呼ばれますリンク重複と繰り返し重複の詳細については、『Advanced Operations Guide』の「重複キーの操作方法」を参照してください。

LINKDUP キーワードが指定されていない場合、CREATE INDEX ステートメントは繰り返し重複を使用します。

物理レコード内で、リンク重複インデックスごとに 8 バイトが余分に必要になります。LINKDUP キーワードを使用すると、これ以降に作成するリンク重複インデックス用にこれらの余分なバイトを予約することができます。

したがって、LINKDUP キーワードが指定されている場合は、以下が適用されます。

•

CREATE INDEX ステートメントは、ポインター数に指定した値に達するまではリンク重複方法を使用します。

•

ポインター数に指定した値に達したら、CREATE INDEX ステートメントは繰り返し重複方法を使用します。

•

ポインター数に指定した値に達しているとき、リンク重複インデックスを削除すると、CREATE INDEX ステートメントは次のキーに対してリンク重複方法を使用します。

•

CREATE INDEX ステートメントは、リンク重複キー用のポインターが予約されていない場合には繰り返し重複キーを作成できません。

例

以下の例では、CREATE TABLE のさまざまな使用法を示します。

次のような構文では、指定されたデータ型の Student_ID、Transaction_Number、Log、Amount_Owed、Amount_Paid、Registrar_ID、および Comments の列から成る、Billing という名前のテーブルが作成されます。

CREATE TABLE Billing

(Student_ID UBIGINT,

Transaction_Number USMALLINT,

Log TIMESTAMP,

Amount_Owed DECIMAL(6,2),

Amount_Paid DECIMAL(6,2),

Registrar_ID DECIMAL(10,0),

Comments LONGVARCHAR)

============

この例では、ID、Dept_Name、Designation、Salary、Building_Name、Room_Number、および Rsch_Grant_Amount の列から成り、列 ID に基づく主キーを持つ Faculty という名前のテーブルがデータベースに作成されます。

CREATE TABLE Faculty

(ID UBIGINT,

Dept_Name CHAR(20) CASE,

Designation CHAR(10) CASE,

Salary CURRENCY,

Building_Name CHAR(25) CASE,

Room_Number UINTEGER,

Rsch_Grant_Amount DOUBLE,

PRIMARY KEY(ID))

次の例では、Name 列にインデックスを作成し、変更不可を指定します。Name 列のデータは変更できません。

CREATE TABLE organizations

(Name LONGVARCHAR NOT MODIFIABLE,

Advisor CHAR(30),

Number_of_people INTEGER,

Date_started DATE,

Time_started TIME,

Date_modified TIMESTAMP,

Total_funds DOUBLE,

Budget DECIMAL(2,2),

Avg_funds REAL,

President VARCHAR(20) CASE,

Number_of_executives SMALLINT,

Number_of_meetings TINYINT,

Office UTINYINT,

Active BIT,)

============

次の例では、生徒の住所を保存するために StudentAddress というテーブルが必要であるとします。Student テーブルの id 列を主キーに変更してから、Student を主テーブルとして参照する StudentAddress テーブルを作成する必要があります（Student テーブルは Demodata サンプルデータベースの一部です）。StudentAddress テーブルの作成方法を 4 種類示します。

まず、Student テーブルの id 列を主キーにします。

ALTER TABLE Student ADD PRIMARY KEY (id)

次のステートメントは、DELETE CASCADE 規則を使って、Student テーブルの id 列を参照する外部キーを持つ StudentAddress テーブルを作成します。これは、Student テーブル（この場合、Student は親テーブルになる）から行が削除されるときはいつも、StudentAddress テーブル内でその行と同じ id を持つすべての行も削除されることを示します。

CREATE TABLE StudentAddress (id UBIGINT REFERENCES Student (id) ON DELETE CASCADE, addr CHAR(128))

次のステートメントは、DELETE RESTRICT 規則を使って、Student テーブルの id 列を参照する外部キーを持つ StudentAddress テーブルを作成します。これは、Student テーブルから行が削除されたとき、その行と同じ id を持つ行が StudentAddress テーブルに存在する場合は常に、エラーが発生することを示します。親テーブルである Student テーブルの行を削除するには、事前に StudentAddress テーブルでその id を持つ行をすべて明示的に削除する必要があります。

CREATE TABLE StudentAddress (id UBIGINT REFERENCES Student (id) ON DELETE RESTRICT, addr CHAR(128))

次のステートメントは、UPDATE RESTRICT 規則を使って、Student テーブルの id 列を参照する外部キーを持つ StudentAddress テーブルを作成します。これは、Student テーブルに存在しない id を持つ行が StudentAddress テーブルに追加された場合は、エラーが発生することを示します。言い換えると、外部キーに親の行を参照させるには、その前に親の行がなければならないということです。これは Zen のデフォルトの動作です。

なお、Zen ではこれ以外の更新規則を一切サポートしていません。したがって、この規則は明示的に示しても示さなくてもかまいません。また、削除規則を明示的に指定していないので、DELETE RESTRICT が使用されます。

CREATE TABLE StudentAddress (id UBIGINT REFERENCES Student (id) ON UPDATE RESTRICT, addr CHAR(128))

============

この例は、テーブルの作成時にオルタネートコレーティングシーケンス（ACS）を使用する方法を示しています。使用する ACS ファイルは、Zen で提供されるサンプルファイルです。

CREATE TABLE t5 (c1 CHAR(20) COLLATE 'file_path\upper.alt')

upper.alt は、ソートする際に大文字と小文字を同等に扱います。たとえば、データベースに abc、ABC、DEF、Def という値がこの順序で挿入されている場合、upper.alt を使ってソートすると、abc、ABC、DEF、Def のように返されます

abc と ABC という値、DEF と Def という値は、まったく同一と見なされ、挿入された順序で返されます。標準の ASCII ソートでは、大文字は小文字の前に配列されており、ソート結果は ABC、DEF、Def、abc となります。また、SELECT c1 FROM t5 WHERE c1 = 'Abc' ステートメントは、abc および ABC を返します。

============

次の例は、テーブル t1 を作成し、リンク重複キー用に予約するポインターの数を 4 に設定します。CREATE INDEX ステートメントによって、テーブルにインデックスキーを作成します。

DROP table t1

CREATE TABLE t1 LINKDUP=4 (c1 int, c2 int, c3 int)

CREATE INDEX link_1 on t1(c1,c2)

CREATE INDEX link_2 on t1(c1,c3)

CREATE UNIQUE INDEX link_3 on t1(c3)

CREATE INDEX link_4 on t1(c1)

CREATE INDEX link_5 on t1(c2)

CREATE INDEX link_6 on t1(c2,c3)

CREATE INDEX ステートメントの結果は次のようになります。

•