表内でのデータの編成方法を決めたなら、 次の段階は、CREATE TABLE ステートメントを使って表を作成することです。 表の説明は、接続先のデータベースのシステム・カタログの中に格納されます。
CREATE TABLE ステートメントの構文についての詳細は、 SQL 解説書 に説明があります。 要約表を作成することについては、 要約表の作成を参照してください。 表、列、その他のデータベース・オブジェクトの命名については、 付録 A, 命名規則を参照してください。
CREATE TABLE ステートメントを使うと、 表の名前として修飾付きまたは修飾なしの識別子が付けられ、 表の各列の定義が与えられます。 表ごとに別々の表スペースに保管して、 1 つの表スペースには 1 つの表しか含まれないようにすることができます。 表の除去や作成を頻繁に行う場合は、表をそれぞれ別の表スペースに格納し、 表ではなく表スペースを除去するほうが効率的です。 1 つの表スペース内に多数の表を保管することもできます。 区分データベース環境では、選択された表スペースは、 表データが保管されるノード・グループおよびデータベース区画も定義します。
表には、当初、何もデータが入っていません。 表にデータ行を加えるには、次のどちらかを使用します。
表データの出し入れについての詳細は、データ移動ユーティリティー 手引きおよび解説書 に記されています。
変更内容をログに記録せずに、表にデータを追加することができます。 CREATE TABLE ステートメントの NOT LOGGED INITIALLY 文節を使用すると、 変更内容は表にログ記録されません。 表が作成されたのと同じ作業単位内の INSERT、DELETE、UPDATE、CREATE INDEX、DROP INDEX、または ALTER TABLE の操作によって表に対して行われた変更は、 いずれもログに記録されません。 ログ記録は、後続の作業単位で開始します。
表には、1 つまたは複数の列定義が含まれています。 1 つの表について、最大 500 列を定義することができます。 列は、エンティティーの属性を表します。 1 つの列の値は、すべて同じタイプの情報です。 詳しくは、SQL 解説書 を参照してください。
注: | 4 KB のページ・サイズを使用しているときには、最大で 500 列です。 ページ・サイズが 8 KB、16 KB、または 32 KB のときは、最大で 1012 列です。 |
列定義には、列名、データ・タイプ、 およびもし必要ならヌル値属性 または省略時値 (ユーザーがオプションで選択します) が含まれます。
列名は列に含まれる情報について記述したもので、簡単に識別できるものにすべきです。 これはその表内では固有なものでなければなりませんが、 他の表では同じ名前を使用することができます。 命名規則については、オブジェクト名を参照してください。
列のデータ・タイプは、列の値の長さと有効なデータの種類を示すものです。 データベース・マネージャーで使うデータ・タイプには、文字ストリング、数値、日付、 時間、ラージ・オブジェクトがあります。 漢字ストリング・データ・タイプは、 マルチバイト文字セットを使用するデータベース環境だけで利用できます。 また、ユーザー定義特殊タイプで列を定義することもできます。 この点については、ユーザー定義タイプ (UDT) の作成を参照してください。
省略時属性の指定は、 値が指定されていない場合にどの値を使用するかを指定するものです。 省略時値を指定するか、またはシステム定義の省略時値を使用することができます。 省略時値は、ヌル値属性を指定した列でも指定しない列でも指定することができます。
ヌル値属性仕様は、列にヌル値を含めることができるかどうかを示します。
コントロール・センターを使用して表を作成するには、以下のようにします。
|
コマンド行を使用して表を作成するには、以下のように入力します。
CREATE TABLE <NAME> (<column_name> <data_type> <null_attribute>) IN <TABLE_SPACE_NAME)
RESOURCE 表スペースに EMPLOYEE 表を作成するための CREATE TABLE ステートメントの例を次に示します。 この表はサンプル・データベースの中で定義されています。
CREATE TABLE EMPLOYEE (EMPNO CHAR(6) NOT NULL PRIMARY KEY, FIRSTNME VARCHAR(12) NOT NULL, MIDINIT CHAR(1) NOT NULL WITH DEFAULT, LASTNAME VARCHAR(15) NOT NULL, WORKDEPT CHAR(3), PHONENO CHAR(4), PHOTO BLOB(10M) NOT NULL) IN RESOURCE
表を作成するときは、表の列を構造型の属性に基づいたものとなるよう選ぶことができます。 そのような表を「タイプ付き表」といいます。
タイプ付き表は、別のタイプ付き表から列の一部を継承するように定義できます。 そのような表を「副表」といい、副表から継承された表を「スーパー表」といいます。 タイプ付き表とすべての副表を組み合わせたものを「表階層」といいます。 表階層内の最上部にある表 (副表を持たない表) を階層の「ルート表」といいます。
以下の部分では、この例を基にして、考慮すべき他の項目を取り上げます。
照会の結果に基づいて定義される表を作成することもできます。 この種の表は、要約表 と呼ばれます。 詳しくは、要約表の作成を参照してください。
ラージ・オブジェクト列が入っている表を作成する前に、 次の事柄を決定する必要があります。
これらの変更をログに記録したくない場合は、 表の作成時に NOT LOGGED 文節を指定して、ログ記録をオフにする必要があります。
CREATE TABLE EMPLOYEE (EMPNO CHAR(6) NOT NULL PRIMARY KEY, FIRSTNME VARCHAR(12) NOT NULL, MIDINIT CHAR(1) NOT NULL WITH DEFAULT, LASTNAME VARCHAR(15) NOT NULL, WORKDEPT CHAR(3), PHONENO CHAR(4), PHOTO BLOB(10M) NOT NULL NOT LOGGED) IN RESOURCE
LOB 列の大きさが 1 GB を超える場合は、ログ記録をオフにしなければなりません。 (目安として、大きさが 10 MB を超える LOB 列はログに記録することができません。) 列定義に指定した他のオプションと同様、 ログ記録オプションを変更するための唯一の方法は、表を再作成することです。
変更をログに記録することを選択しなくても、 LOB 列にはシャドー が作成されて、 ロールバックがシステム生成エラーの結果であるか、 アプリケーションの要求であるかによって、変更をロールバックすることができます。 シャドーの作成は、現行の記憶域の内容が上書きされない場所では、 回復技法となります。 つまり、古くなった未修正ページは "シャドー"・コピーとして保持されます。 これらのコピーは、トランザクション・ロールバックのサポートに必要ではなくなると、 破棄されます。
注: | RESTORE および ROLLFORWARD コマンドを使用してデータベースを回復するとき、 "NOT LOGGED" になっており、 最後のバックアップで書き込まれた LOB データは 2 進ゼロで置き換えられます。 |
CREATE TABLE ステートメントの COMPACT 文節を使用すると、 LOB 列をできる限り小さくすることができます。 次に例を示します。
CREATE TABLE EMPLOYEE (EMPNO CHAR(6) NOT NULL PRIMARY KEY, FIRSTNME VARCHAR(12) NOT NULL, MIDINIT CHAR(1) NOT NULL WITH DEFAULT, LASTNAME VARCHAR(15) NOT NULL, WORKDEPT CHAR(3), PHONENO CHAR(4), PHOTO BLOB(10M) NOT NULL NOT LOGGED COMPACT) IN RESOURCE
特に LOB 値のサイズが (行わなければならない記憶域調整のために) 増えた場合には、 LOB 列を小さくした表を付加するときに、 パフォーマンス上のコスト がかかります。
予備ファイルの割り振りがサポートされておらず、 LOB が SMS 表スペースに置かれている、OS/2 のようなプラットフォームでは、 COMPACT 文節を使用することを検討してください。 予備ファイルの割り振りは、 オペレーティング・システムが物理ディスク・スペースを使用する方法と関係があります。 予備ファイルの割り振りをサポートするオペレーティング・システムは、 予備ファイルの割り振りをサポートしないオペレーティング・システムに比べ、 LOB の保管にそれほどの物理ディスク容量を使用しません。 COMPACT オプションを指定すると、 予備ファイルの割り振りがサポートされているかどうかに関係なく、 大量の物理ディスク容量を "節約" することができます。 COMPACT を使用した場合には物理ディスク容量が節約できるので、 オペレーティング・システムが予備ファイルの割り振りをサポートしていない場合には、 COMPACT を使用することを検討すべきです。
注: | DB2 システム・カタログは LOB 列を使用しており、 以前のバージョンよりも多くのスペースを使用します。 |
カタログ表の中にラージ・オブジェクト (LOB) 列があります。 LOB データは他のデータと一緒にバッファー・プールの中には保持されず、 必要になるたびにディスクから読み取られます。 ディスクからの読み取りによって、カタログの LOB 列が含まれている場合には、 DB2 のパフォーマンスが低下します。 ファイル・システムは通常データを保管 (またはキャッシュ) するための独自の場所を持っているので、 SMS 表スペースを使用するか、ファイル・コンテナー上に作成された DMS 表スペースを使用して、 LOB が以前に参照されている場合に入出力が発生する可能性を避けるようにしてください。
この節では、制約の定義方法について説明します。
制約についての詳細は、 制約の強制について計画するおよび SQL 解説書 を参照してください。
固有制約 は、 指定されたキー内のそれぞれの値が固有なものになるようにします。 1 つの表は、最大 1 つの固有制約を基本キーとして定義して、 任意の数の固有制約を持つことができます。
CREATE TABLE または ALTER TABLE ステートメントの UNIQUE 文節を使用して固有制約を定義します。 固有キーは複数の列で構成できます。 1 つの表上で、複数の固有制約が許されます。 ただし、副表に固有制約を定義することはできません。
いったん確立されると、 INSERT または UPDATE ステートメントが表内のデータを修正するときに、 データベース・マネージャーによって、その固有制約が自動的に施行されます。 固有制約は、固有索引を通して施行されます。
固有制約が ALTER TABLE ステートメントに定義され、 その固有キーの同じ列のセット上に索引が存在する場合、 その索引は固有索引となり、制約によって使用されます。
任意の固有制約を 1 つとって、 それを基本キー として使用することができます。 基本キーは、(他の固有制約と一緒に) 参照制約の中の親キーとして使用することができます。 1 つの表当たり 1 つの基本キーだけが可能です。 基本キーを定義するには、 CREATE TABLE または ALTER TABLE ステートメントで PRIMARY KEY 文節を使います。 基本キーには、複数の列を含めることができます。
1 次索引は、基本キーの値が固有なものとなるように施行します。 基本キーの指定された表を作成すると、 データベース・マネージャーはその基本キーについての 1 次索引を作成します。
固有制約として使用される索引に対するパフォーマンス上のヒントには、 以下のものがあります。
表定義と列定義に参照制約を追加すると、参照保全が課せられます。 参照制約は、 CREATE TABLE または ALTER TABLE ステートメントの FOREIGN KEY 文節および REFERENCES 文節を使用して確立されます。 タイプ付き表に対する参照制約や、 タイプ付き表である親表に対する参照制約の効果についての詳細は、 SQL 解説書 を参照してください。
外部キーの指定によって、1 つの表の行内または 2 つの表の行間の値について、 制約が施行されます。 データベース・マネージャーは、表定義で指定された制約を検査し、 それに応じて関係を維持します。 その目標は、1 つのデータベース・オブジェクトが別のオブジェクトを参照するときに、 いつでも整合性が保たれているようにすることです。
たとえば、基本キーと外部キーは、それぞれ部署番号の列を持ちます。 EMPLOYEE 表の場合、列名は WORKDEPT であり、DEPARTMENT 表の場合、列名は DEPTNO です。 この 2 つの表の間の関係は、次の制約によって定義されています。
親表である DEPARTMENT を定義する SQL ステートメントは、次のとおりです。
CREATE TABLE DEPARTMENT (DEPTNO CHAR(3) NOT NULL, DEPTNAME VARCHAR(29) NOT NULL, MGRNO CHAR(6), ADMRDEPT CHAR(3) NOT NULL, LOCATION CHAR(16), PRIMARY KEY (DEPTNO)) IN RESOURCE
従属表である EMPLOYEE を定義する SQL ステートメントは、次のとおりです。
CREATE TABLE EMPLOYEE (EMPNO CHAR(6) NOT NULL PRIMARY KEY, FIRSTNME VARCHAR(12) NOT NULL, LASTNAME VARCHAR(15) NOT NULL, WORKDEPT CHAR(3), PHONENO CHAR(4), PHOTO BLOB(10m) NOT NULL, FOREIGN KEY DEPT (WORKDEPT) REFERENCES DEPARTMENT ON DELETE NO ACTION) IN RESOURCE
DEPTNO 列を DEPARTMENT 表の外部キーとして指定し、 WORKDEPT を EMPLOYEE 表の外部キーとして指定すると、 WORKDEPT 値についての参照制約を定義することになります。 この制約は、2 つの表の間での値の参照保全を施行するものとなります。 この場合、EMPLOYEE 表に追加される従業員の部署番号は、 DEPARTMENT 表の中にあるものでなければなりません。
EMPLOYEE 表の参照制約の削除規則は、NO ACTION です。 つまり、DEPARTMENT 表から部署を削除しようとしても、 その部署に従業員がいれば削除はできません。
この例では CREATE TABLE ステートメントを使って参照制約を追加していますが、 ALTER TABLE ステートメントを使うこともできます。 構造と内容の両方における表の修正を参照してください。
別の例: 前の例の中で使用されたのと同じ表定義が使用されます。 また、DEPARTMENT 表は、EMPLOYEE 表より前に作成されます。 各部署にはマネージャーがおり、そのマネージャーは EMPLOYEE 表にリストされています。 DEPARTMENT 表の MGRNO 番号は、実際には EMPLOYEE 表の外部キーになっています。 この参照サイクルのために、この制約にはわずかに問題があります。 外部キーは後で追加することができます (基本キーと外部キーの追加を参照)。 また、CREATE SCHEMA ステートメントを使用して、 EMPLOYEE 表と DEPARTMENT 表の両方を同時に作成することもできます (SQL 解説書 の例を参照)。
外部キーは、同じ表または別の表内の基本キーまたは固有キーを参照します。 外部キーを割り当てると、指定した参照制約にしたがって参照保全が維持されます。 外部キーを定義するには、 CREATE TABLE または ALTER TABLE ステートメントで FOREIGN KEY 文節を使います。
外部キーの中の列の数は、 親表の対応する基本制約または固有制約 (親キーと呼ばれる) の中の列の数と同じでなければなりません。 さらに、キー列定義の対応する部分は、 それぞれ同じデータ・タイプ、同じ長さでなければなりません。 外部キーには、制約名 を割り当てることができます。 名前は、割り当てなくても自動的に割り当てられます。 使いやすさのためには、自分で制約名 を割り当て、 システムが生成した名前は使用しないようにすることをお勧めします。
複合外部キーの値は、 外部キーの各列の値が親キーの対応する列の値と等しければ、 親キーの値と一致します。 ヌル値が含まれる外部キーは、親キーが定義上ヌル値を持つことができないため、 親キーの値と一致することはありません。 しかし、外部キーのヌル値は、ヌル値ではないどの部分の値とも無関係に常に有効です。
外部キー定義に適用される規則は、次のとおりです。
REFERENCES 文節は、関係の中の親表を指定し、必要な制約を定義するためのものです。 この文節は列定義の中に含めることもできますし、 CREATE TABLE または ALTER TABLE ステートメントの中に FOREIGN KEY 文節を伴う別個の文節として含めることもできます。
REFERENCES 文節を列制約として指定する場合、 暗黙の列リストは、指定する列名で構成されることになります。 複数の列にそれぞれ別個の REFERENCES 文節を使うことも可能ですし、 1 つの列で複数の文節を使うことも可能です。
REFERENCES 文節には削除規則が含まれています。 この例の中で使用される規則は、ON DELETE NO ACTION です。 つまり、部署に従業員が配属されているなら、その部署は削除できません。 削除規則としては、このほかに ON DELETE CASCADE、ON DELETE SET NULL、 および ON DELETE RESTRICT があります。 DELETE 規則を参照してください。
LOAD ユーティリティーは自己参照と従属表の制約検査をオフにして、 これらの表を検査保留状態にします。 LOAD ユーティリティーが完了してから、 オフになっていたすべての表の制約検査をオンにする必要があります。 たとえば、DEPARTMENT 表と EMPLOYEE 表だけが検査保留状態になっている場合には、 以下のコマンドを実行することができます。
SET INTEGRITY FOR DEPARTMENT, EMPLOYEE IMMEDIATE CHECKED
IMPORT ユーティリティーは、参照保全によって次のような影響を受けます。
これらの関数を使用する場合は、まずその表が親表となっている外部キーをすべて除去してください。 インポートが終了したら、ALTER TABLE ステートメントで外部キーを再作成してください。
表の検査制約は、 表検査制約が定義されている表の行ごとに適用される検索条件を指定するものです。 表に表検査制約を作成するには、表の作成時または変更時に検査制約定義を表に対応付けます。 この制約は、 INSERT または UPDATE ステートメントで表の中のデータを変更する時に自動的に活動化されます。 表の検査制約は、DELETE または SELECT ステートメントに影響を及ぼしません。 検査制約はタイプ付き表に関連付けることができます。
制約名は、 同じ CREATE TABLE ステートメント内に指定されている他の制約と同じものにすることはできません。 制約名を指定しない場合は、その制約の 18 文字の固有識別子がシステムによって生成されます。
表検査制約は、キーの固有性でカバーできないデータ保全規則、 または参照保全制約を施行するために使用されます。 場合によっては、定義域検査を実施するために、表の検査制約を使用することもできます。 CREATE TABLE ステートメントで発行された次の制約は、 すべての活動の開始日付が同じ活動の終了日付より後になっていないことを確認します。
CREATE TABLE EMP_ACT (EMPNO CHAR(6) NOT NULL, PROJNO CHAR(6) NOT NULL, ACTNO SMALLINT NOT NULL, EMPTIME DECIMAL(5,2), EMSTDATE DATE, EMENDATE DATE, CONSTRAINT ACTDATES CHECK(EMSTDATE <= EMENDATE) ) IN RESOURCE
この例では CREATE TABLE ステートメントを使って表検査制約を追加していますが、 ALTER TABLE ステートメントを使うこともできます。 構造と内容の両方における表の修正を参照してください。
生成列は基礎表に定義されます。 生成列に格納される値は、式を使って計算された値です。 挿入操作や更新操作で指定された値ではありません。 作成する表で、特定の式や述部を頻繁に使用することが分かっている場合、 その表に 1 つまたは複数の生成列を追加することができます。 生成列を使用すると、 表データを照会する際のパフォーマンスを向上させることができます。
たとえば、パフォーマンスが重要な場合、 式の評価の費用を高める恐れのある要因が 2 つあります。
照会のパフォーマンスを向上させるには、 式の結果を入れるために、列をもう 1 つ定義することができます。 そうすれば、同じ式を含んだ照会を発行するときに、生成列を直接に使用できます。 あるいは、最適化プログラムの照会書き直し構成要素で、 その式を生成列に置き換えることもできます。
生成列には、非固有の索引を作成することもできます。
照会時に複数の表のデータを結合する場合、生成列を追加すると、 最適化プログラムがより良い結合の方針を選択できるかもしれません。
以下に、CREATE TABLE ステートメントを使って生成列を定義する方法の例を示します。
CREATE TABLE t1 (c1 INT, c2 DOUBLE, c3 DOUBLE GENERATED ALWAYS AS (c1 + c2) c4 GENERATED ALWAYS AS (CASE WHEN c1 > c2 THEN 1 ELSE NULL END))
この表を作成した後で、生成列を使用して索引を作成できます。 たとえば、次のようにします。
CREATE INDEX i1 ON t1(c4)
生成列を照会に利用できます。 たとえば、次の照会があるとします。
SELECT COUNT(*) FROM t1 WHERE c1 > c2
これは、以下のように書き換えることができます。
SELECT COUNT(*) FROM t1 WHERE c4 IS NOT NULL
別の例を以下に示します。
SELECT c1 + c2 FROM t1 WHERE (c1 + c2) * c1 > 100
これは、以下のように書き換えることができます。
SELECT c3 FROM t1 WHERE c3 * c1 > 100
生成列は、照会のパフォーマンスを向上させるために使用します。 したがって、恐らく、生成列を追加するのは、表を作成したり、 表にデータを読み込んだ後になるでしょう。 詳細については、表の作成とデータの読み込みを参照してください。
一時表を定義するには、DECLARE GLOBAL TEMPORARY TABLE ステートメントを使用します。 このステートメントは 1 つのアプリケーションの中から使用されます。 ユーザー定義一時表が保持されるのは、 アプリケーションがデータベースから切断されるまでの間だけです。
この表の記述は、システム・カタログには現れません。 したがって、この表を他のアプリケーションのために保持したり、 他のアプリケーションと共用したりすることはできません。
この表を使用するアプリケーションが終了したりデータベースから切断されたりすると、 表の中のデータはすべて削除され、表は暗黙的に除去されます。
一時表を定義する方法の例を以下に示します。
DECLARE GLOBAL TEMPORARY TABLE gbl_temp LIKE empltabl ON COMMIT DELETE ROWS NOT LOGGED IN usr_tbsp
このステートメントにより、 gbl_temp というユーザー一時表が作成されます。 このユーザー一時表の列は、 名前と記述が empltabl の列と完全に一致するように定義されています。 暗黙定義には、列名、データ・タイプ、ヌル可能特性、 および列の省略時値の属性だけが含まれます。 他のすべての列属性 (固有制約、外部キー制約、トリガー、索引を含む) は、 定義されていません。 COMMIT 操作を実行すると、 表で WITH HOLD カーソルがオープンしていなければ、 表の中のデータはすべて削除されます。 ユーザー一時表に対する変更内容はログに記録されません。 ユーザー一時表は、 指定されたユーザー一時表スペースに置かれます。 この表スペースがないと、この表の宣言は失敗します。
DECLARE GLOBAL TEMPORARY TABLE ステートメントの詳細については、 SQL 解説書 を参照してください。
注: | ユーザー定義一時表は、以下のものをサポートしません。
|
識別列 を使用すると、表に追加する個々の行に対し、 それぞれ固有であることが保証された数値を DB2 が自動的に生成します。 表に追加する個々の行を固有に識別する必要があることが分かっている場合、 その表を作成する際に、識別列を追加できます。
いったん作成した後で、表の記述を更新して、識別列を組み込むことはできません。
CREATE TABLE ステートメントで AS IDENTITY 文節を使用すると、 識別列を指定できます。
以下に、CREATE TABLE ステートメントを使って識別列を定義する方法の例を示します。
CREATE TABLE table (col1 INT, col2 DOUBLE, col3 INT NOT NULL GENERATED ALWAYS AS IDENTITY (START WITH 100, INCREMENT BY 5))
この例では、3 番目の列が識別列です。 この列で使用される値を指定して、 追加される個々の行を固有に識別することもできます。 この例の場合、最初に入力される行については、値 "100" が識別列に入れられます。 この表に行が追加されるごとに、値は 5 ずつ増えます。
識別列を使用する他の例としては、 注文番号、従業員番号、在庫番号、事例番号などがあります。 ALWAYS または BY DEFAULT を指定して、 DB2 によって識別列の値が生成されるようにすることができます。
GENERATED ALWAYS として定義された識別列は、 固有になることが保証されます。 使用される値は、常に DB2 によって生成されます。 アプリケーションが明示的に値を指定することはできません。 識別列を GENERATED BY DEFAULT として定義すると、 アプリケーションが明示的に識別列の値を指定できます。 アプリケーションが値を指定しないと、 DB2 が値を生成します。 アプリケーションが値を制御するので、 値が固有であることを DB2 が保証することはできません。 GENERATED BY DEFAULT 文節は、 既存の表の内容をコピーする目的でデータ伝搬を行う場合や、 表のアンロードや再ロードを行う場合に使用します。
注: | 現在、識別列は、 区分データベース環境ではサポートされていません。 |
識別列を新しい表に定義することに関する追加情報は、 SQL 解説書 を参照してください。
CREATE TABLE ステートメントの変種を使用して、タイプ付き表を作成できます。 タイプ付き表に関する必要なすべての情報については、 アプリケーション開発の手引き を参照してください。
構造型を作成して、対応する表および副表を作成したら、 タイプ付き表にデータを読み込むことができます。 タイプ付き表に関する必要なすべての情報については、 アプリケーション開発の手引き を参照してください。
階層表とは、タイプ付き表階層の実装に関連付けられた表であり、 階層のルート表と同時に作成されます。 階層表に関する必要なすべての情報については、 アプリケーション開発の手引き を参照してください。
表データは、表の索引や、 表に関連した長形式列データと同じ表スペースに格納することができます。 また索引や長形式の列データを、 それ以外の表データとは別の表スペースに入れることもできます。 CREATE TABLE ステートメントを実行する前に、 すべての表スペースが存在していなければなりません。 表の一部を分離することができるのは、 DMS 表スペースを使用している場合だけです。
コントロール・センターを使用して複数の表スペースに 1 つの表を作成するには、
以下のようにします。
|
コマンド行を使用して複数の表スペースに 1 つの表を作成するには、 以下のように入力します。
CREATE TABLE <name> (<column_name> <data_type> <null_attribute>) IN <table_space_name> INDEX IN <index_space_name> LONG IN <long_space_name>
次の例では、別の表スペースに表の別の部分を格納するために、 EMP_PHOTO 表が作成される方法を示します。
CREATE TABLE EMP_PHOTO (EMPNO CHAR(6) NOT NULL, PHOTO_FORMAT VARCHAR(10) NOT NULL, PICTURE BLOB(100K) ) IN RESOURCE INDEX IN RESOURCE_INDEXES LONG IN RESOURCE_PHOTO
この例では、EMP_PHOTO データが次のように作成されます。
1 つの表に複数の DMS 表スペースを使用することについては、 表スペース設計時の考慮事項を参照して、さらに考慮してください。
詳しくは、SQL 解説書 を参照してください。
物理的に分割つまり区分化される表を作成する前に、以下のことを考慮する必要があります。
区分データベース環境で表を作成する場合、区分化キー という、 追加のオプションが存在します。 区分化キーは、表の定義の一部であるキーです。 このキーは、各データ行が保管される区画を判別します。
後から変更することはできないため、適切な区分化キーを選択することが重要です。 さらに、何らかの固有索引を (したがって、固有キーまたは基本キーも)、 区分化キーのスーパーセットとして定義しなければなりません。 つまり、区分化キーが定義された場合、固有キーおよび基本キーは、 区分化キーと同じ列をすべて含まなければなりません (固有キーと基本キーには、 それ以上の列が含まれる場合があります)。
区分化キーを明示して指定しない場合、以下の省略時値が使用されます。 省略時の区分化キーが適切であることを確認してください。
以下はその例です。
CREATE TABLE MIXREC (MIX_CNTL INTEGER NOT NULL, MIX_DESC CHAR(20) NOT NULL, MIX_CHR CHAR(9) NOT NULL, MIX_INT INTEGER NOT NULL, MIX_INTS SMALLINT NOT NULL, MIX_DEC DECIMAL NOT NULL, MIX_FLT FLOAT NOT NULL, MIX_DATE DATE NOT NULL, MIX_TIME TIME NOT NULL, MIX_TMSTMP TIMESTAMP NOT NULL) IN MIXTS12 PARTITIONING KEY (MIX_INT) USING HASHING
上記の例で、表スペースは MIXTS12 であり、 区分化キーは MIX_INT です。 区分化キーが明示して指定されない場合、区分化キーは MIX_CNTL になります。 (基本キーが指定されず、区分化キーが定義されない場合、区分化キーは、 リスト内の最初のロング列以外の列になります。)
1 つの表の 1 つの行、およびその行に関するすべての情報は、 常に同じデータベース区画上に常駐します。
1 つの表の 1 区画についてのサイズの限界は、 64 GB または使用可能ディスク・スペースのうち、いずれか小さいほうになります。 (表スペースに 4 KB のページ・サイズを想定しています。) 表のサイズは、 データベース区画の数の 64 GB (または使用可能ディスク・スペース) 倍までの大きさにすることができます。 表スペースのページ・サイズが 8 KB の場合、表のサイズは、 データベース区画の数の 128 GB (または使用可能ディスク・スペース) 倍までの大きさにすることができます。 表スペースのページ・サイズが 16 KB の場合、表のサイズは、 データベース区画の数の 256 GB (または使用可能ディスク・スペース) 倍までの大きさにすることができます。 表スペースのページ・サイズが 32 KB の場合、表のサイズは、 データベース区画の数の 512 GB (または使用可能ディスク・スペース) 倍までの大きさにすることができます。