Comments
Description
Transcript
簡単シリーズ データベース･オブジェクト作成編 2004/03
簡単シリーズ データベース･オブジェクト作成編 2004/03 目次 第1章 データベース・オブジェクトの概要 1.1 1.2 オブジェクトの構成図 オブジェクトの管理方法 第2章 オブジェクト作成方法 2.1 2.2 2.3 2.4 2.5 2.6 2.6.1 2.6.2 2.7 2.8 2.9 2.10 オブジェクト作成フロー データ記憶域管理 データ-ベース 表スペース スキーマ 表 MQT MDC ビュー 別名 索引 連合システム 第3章 データのロード 添付資料 添付 表の制約 第１章 データベース・オブジェクトの概要 1.1 オブジェクトの構成図 データベース・オブジェクトとは、表スペース、表、ビュー、索引、パッケージ、ログ、ロックなど、DB2 UDBデータベースの構成要素を表します。 インスタンス データベース１ 表スペース１ 表スペース０ 表 索引 表スペース２ 表 表 表 データベース２ 表スペース０ 表 表スペース１ 表 索引 当 資 料 で 扱 う 対 象 データベース・オブジェクト ¾ インスタンス ¾ データベース ¾ 表スペース ¾ スキーマ ¾表 ¾ ビュー ¾ 別名 ¾ 索引 ¾ システム・カタログ表 ¾ トリガー ¾ ストアード・プロシージャー ¾ ユーザー定義関数 ¾ バッファー・プール ¾ パッケージ DB2 UDB(Windows、UNIXなど) ※インスタンス DB2導入時に自動的に1つのインスタンスが作成されます。 インスタンスはデータベースをカタログしたり、構成パラメーターを設定したりすることのできる論理的なデータベース管理システムです。 使用環境に応じて1つのサーバー上に複数のインスタンスを定義することができます。 1.2 オブジェクトの管理方法 DB内のオブジェクトを作成、変更、削除するにはSQLデータ定義言語(DDL)を使用します。 z DDLには以下の3つの主要なSQLがあります。 ・データベース・オブジェクトの作成 CREATE ＜database object＞ XXXX ・データベース・オブジェクトの削除 DROP ＜database object＞ XXXX ・データベース・オブジェクトの変更 ALTER ＜database object＞ XXXX database object 例 ： DATABASE TABLESPACE SCHEMA TABLE VIEW ALIAS INDEX 以下に示すさまざまなインターフェースを使用してSQLを実行することができます。 z コマンド行プロセッサー 対話式SQL文、またはDB2 UDBコマンドを実行するのに使用できる、テキスト形式のアプリケーションです。このインターフェースからデータベースにアクセスして操作 することができます。 z コントロール・センター システムの構成、ディレクトリーの管理、システムのバックアップと回復、ジョブのスケジューリング、および媒体の管理などの管理タスクをグラフィカル・ユーザー・イン ターフェースを介して実行できます。 上記の他に、SQL文を作成、実行するほかスケジューリング機能も提供するDB2ツールがあります。 z タスク・センター ジョブ（SQL、DB2 UDBコマンド、オペレーティング・システムのコマンド）の保存、実行、スケジューリングを行います。 z コマンド・センター SQL、DB2 UDBコマンド、オペレーティング・システムのコマンドを実行する対話式のウィンドウを提供します。 第2章 オブジェクトの作成方法 2.1 オブジェクト作成フロー インスタンス作成 物理特性と運用管理基準の検討と決定 2.2章 データベース作成 2.3章 デフォルトのユーザー表、一時表、カタログ表スペースの定義 表スペースの作成 2.4章 データベースの物理配置、コンテナー、SMS or DMS バッファー・プール エクステント・サイズ、プリフェッチ・サイズ スキーマの作成 2.5章 論理設計の反映 表の作成 2.6章 MQT 2.6.1章 MDC 2.6.2章 列の設計とキー、参照整合性、制約 連合システムの構築 2.10章 ビュー,別名の作成 2.7,2.8章 論理設計の反映とパフォーマンス 索引の作成 2.9章 データのロード 3章 索引の列、索引タイプ 単一のSQLで複数のデータ・ソースにアクセス 2.2 データ記憶域管理 SMSとDMSの比較 物理スペース(コンテナー) SMS(システム管理スペース) DMS(データベース管理スペース) ディレクトリー ファイル、RAWデバイス /db/payroll/tbsp1/cont1 RAWデバイス ファイル 特性 あらかじめ記憶域は割り当てない あらかじめ記憶域を割り当てる 拡張可能 1つの表の索引、LOBを別の表スペースに保存可能 表スペース内のコンテナーの数を動的に増やせる × ○ 索引データを別の表スペースに保管できる × ○ LONG、LOBデータを別の表スペースに保管できる × ○ スペースは必要なときにのみ割り当てられる ○ × 動的にコンテナー数の追加、削除と 既存コンテナーのサイズの拡張、縮小ができる × ○ データベースは表スペースと呼ばれる論理的な記憶域で分けられます。表スペースは、記憶域管理の観点から、システム管理スペース（SMS）とデータベース管理スペース（DMS）の 2種類に分類できます。 z z z z 通常は、十分に調整したDMS表スペースの方がSMS表スペースよりも性能が優れています。 SMS表スペースでは個人用の小さなデータベースの場合、管理が容易です。 サイズが大きく、これからも拡張する可能性のあるデータベースの場合、SMS表スペースは一時表スペースとしてのみ使用し、ユーザー表にはDMS表スペースを使用し、さらに各表スペースに 複数のコンテナーを割り当てるのが効果的です。 CREATE TABLE文で表を定義する際に表データを格納する表スペースを明示的に指定することができます。 2.2 データ記憶域管理 表スペースとコンテナーを使用して、システム上にデータが保管される方法を定義することができます。 表スペース データベースは、表スペース(表を保管するスペース)と呼ばれる論理的な記憶域単位に分けられます。表スペースは、コンテナーと呼ばれる物理記憶装置（ディレクトリー、デバイス、 ファイルが対応）に分けられ、システム管理スペース(SMS)またはデータベース管理スペース(DMS)のどちらかの方法で管理されます。 ・SMS：OSのファイルシステム・マネージャーが表を保管するスペースを割り振って管理 ・DMS：データベース・マネージャーが記憶スペースを制御 コンテナー 物理記憶装置のことで、ディレクトリー名、デバイス名、またはファイル名によって識別できます。 1つの表スペースには複数のコンテナーを割り当てることができます。また、1つのコンテナーが属することができる表スペースは1つだけです。 DB2はラウンドロビン方式で各コンテナーにエクステント（ページの集まり）単位で領域を割り振り、順にデータを格納していきます。そのため特定の表スペースに属するコンテナー間で データは均等に配置されます。 z ディレクトリーコンテナー ：SMS表スペースで指定できる唯一のタイプ z デバイスコンテナー(RAWデバイス) ：AIX、Solaris、HP-UXでは文字特殊インターフェースを備えた論理ボリューム Windows、Linuxでは未フォーマットの区画または物理ディスク z ファイルコンテナー ：DMS表スペースが使用する事前割り振りサイズのファイル SMS表スペースとDMS表スペースのメリット z SMS表スペース ：スペースが必要になる時点まで、スペースがシステムによって割り振られることはありません。 コンテナーの事前定義が不要なため、データベースの作成に必要な初期作業が少なくてすみます。 z DMS表スペース ：表スペースのサイズは、“ALTER TABLESPACE”文を使用して変更することができます。 コンテナーの追加、削除、サイズ変更時、既存のデータは最適な入出力効率を保つため、新しいコンテナーのセットにわたって自動的に再バランスが 行われます。追加の場合、BEGIN NEW STRIPE SETオプションの指定により表スペースに新しいストライプ・セットを作成し、データの再バランスを抑 止することもできます。 格納するデータのタイプ（LONGおよびLOB、索引、正規表データ)で、表を複数の表スペースへ分割できます。 RAWデバイスとファイルコンテナーの比較 デバイスとファイルの間に操作上の違いはありません。 ファイルコンテナーと比べた際の、RAWデバイスを使用するメリットと考慮点は以下の通りです。 z メリット ：高速アクセス。 ファイルコンテナーの場合、ファイルシステム実行時のオーバーヘッドがかかるため、デバイスより効率的でないことがあります。DB2 UDBはファイルシステムをバイパ スすることによりデバイスコンテナーを直接管理してパフォーマンスを改善していますが、ファイルの場合はファイルシステムと対話する必要があります。 高可用性（HA）構成では、スタンバイ・サーバーへの引継ぎ時に行われるファイル・システムのチェック時間を短縮するためRAWデバイスの利用を検討してください。 z 考慮点 ：ファイルシステムのキャッシュを使用できません。これを補うためにDB2 UDBのバッファーを増やす必要が生じることがあります。 LOBはバッファー・プールが使用されず直接ディスクへアクセスされるため、ファイルコンテナーへ格納した方がファイルシステムキャッシュを利用でき一般に高速です。 デバイスはセットアップと保守に関連した管理上のオーバーヘッドがかかります。 デバイスはコンテナーを1つしかサポートできません。 2.3 データベース 例 ｢SAMPLE｣という名前のDBを作成します。 CREATE DATABASE SAMPLE >>-CREATE--+-DATABASE-+--database-name----------------------------------------------> '-DB---------‘ |--+---------------+--+-----------------------+-----------------------------------------> '-ON--+-path--+-' '-ALIAS--database-alias- ' '-drive- ' >--+----------------------------------------------+------------------------------------> '-USING CODESET--codeset--TERRITORY--territory-' >--+------------------------------------+----------------------------------------------> | .-SYSTEM---------. | '-COLLATE USING--+-COMPATIBILITY--+-' +-IDENTITY---------+ +-IDENTITY_16BIT---+ '-NLSCHAR--------' >--+--------------------+--+----------------------------- +----------------------------> '-NUMSEGS--numsegs-' '-DFT_EXTENT_SZ--dft_extentsize-' >--+---------------------------------------+-------------------------------------------> '-CATALOG TABLESPACE--| tblspace-defn |-' >--+-----------------------------------+-----------------------------------------------> '-USER TABLESPACE--| tblspace-defn |-' >--+------------------------------------------+----------------------------------------> '-TEMPORARY TABLESPACE--| tblspace-defn |-‘ >--+--------------------------------------------------------------------------------+--> | .-DB ONLY-----. | '-AUTOCONFIGURE--+-----------------------------------+-APPLY--+-DB AND DBM-+-' | .--------------------------. | '-NONE--------' | V | | '-USING--input-keyword--param-value-+-' tblspace-defn: |--MANAGED BY---------------------------------------------------> .-,-----------------. V | >--+-SYSTEM USING--(----'container-string'-+--)------------------------------+--> | .-,---------------------------------------------. | | V | | '-DATABASE USING--(----+-FILE---+--'container-string'--number-of-pages-+--)-' '-DEVICE-' >--+-----------------------------+------------------------------> '-EXTENTSIZE--number-of-pages-' >--+--------------------------------+---------------------------> '-PREFETCHSIZE--number-of-pages-' データベースを作成すると3種類の表スペース(デフォルトSMS)が作られます。 ・カタログ表スペース (calatog)SYSCATSPACE :システム・カタログ表を含む ・一次表スペース (temporary)TEMPSPACE1 :一次表を含む ・ユーザー表スペース (regular)USERSPACE1 :ユーザー表、索引を含む 省略時の3つの表スペース、ログがここに取られます。 十分な空きスペースがあることを確認してください。 SampleDBのための最低15MBのディスク容量が必要になります。 on path/drive node0000 SQL00001 SQLT0000.0 SYSCATSPACE SQLT0001.0 TEMPSPACE1 SQLT0002.0 USERSPACE1 表 索引 物理構造コンテナー 論理構造表スペース 2.3 データベース データベースは表や索引の集合体です。接続、運用上の単位となります。 一つのインスタンスに複数のデータベースを作成することができます。 ●ON path/drive UNIX ベースのシステムでは、データベースを作成するパスを指定します。パスを指定しないと、データベースはデータベース・マネージャー構成ファイル (dftdbpath パラメーター) に指定 されている省略時値のデータベース・パスに作成されます。Windows OSでは、ドライブ識別子を指定します。 ●USING CODESET codeset データベースに入力するデータに使用するコード設定を指定します。 データベースを作成した後は、指定のコード・セットを変更できません。 ●TERRITORY territory データベースに入力するデータに使用する地域を指定します。 データベースを作成した後は、指定のテリトリーを変更できません。 ●COLLATE USING データベースに使用する照合順序のタイプを識別します。 データベースを作成した後は、照合順序を変更できません。 ・SYSTEM（デフォルト） ：現行のテリトリーに基づいた照合順序（辞書順）。 ・COMPATIBILITY ：DB2 V2の照合順序です。一部の照合表が拡張されています。このオプションはそれらの表の直前のバージョンを使用することを指定します。 ・IDENTITY ：ストリングがバイト単位で比較される、照合順序を認識します。 ・IDENTITY_16BIT ：Unicode Technical Report #26で指定された、CESU-8照合順序。Unicodeデータベースを作成する場合にのみ使用できます。 ・NLSCHAR ：特定のコード・セット/テリトリー用の固有の照合規則を使用するシステム定義の照合順序。 ※日本語環境で五十音順にデータを照合したい場合には、IDENTITYを指定します。 2.4 表スペース 例 SMS DMS AIX CREATE TABLESPACE AIXSMS MANAGED BY SYSTEM USING (‘/database/firstcontain',‘/database/secondcontain') CREATE TABLESPACE AIXDMS MANAGED BY DATABASE USING (device ‘/dev/rdata1’ 1024, device ‘/dev/rdata2’ 1024) EXTENTSIZE 8 Windows CREATE TABLESPACE WindowsSMS MANAGED BY SYSTEM USING (‘E:¥db¥firstcnt',‘F:¥db¥sndcnt',‘G:¥thirdcnt') CREATE TABLESPACE WindowsDMS MANAGED BY DATABASE USING (file ‘C:¥db¥index.tbs' 1000) .-REGULAR----------------. >>-CREATE--+-------------------------+--TABLESPACE--tablespace-name-----> +-LARGE------------------+ | .-SYSTEM-. | '-+---------+-TEMPORARY-' '-USER---‘ .-PAGESIZE--4096----------. >--+--------------------------+---------------------------------> '-PAGESIZE--integer--+---+--' '-K-‘ >--MANAGED BY--+-SYSTEM--| system-containers |-----+------------->>--+---------------------------------+--------------------------> '-DATABASE--| database-containers |-‘ '-EXTENTSIZE--+-number-of-pages-+-' '-integer--+-K-+---' '-M-' >--+------------------------------------+------------------------->>--+------------------------------+-----------------------------> '-PREFETCHSIZE--+-number-of-pages-+-‘ '-BUFFERPOOL--bufferpool-name-' '-integer--+-K-+--' +-M-+ '-G-' データベース内に新しい表スペースを作成し、 その表スペースにコンテナーを割り当て、 表スペースの定義と作成をカタログに記録します。 コンテナー定義 SMS表スペース DMS表スペース system-containers: .------------------------------------------- -----------------------. | .--,-------------------. | V V | | |----USING--(----'--container-string--'-+--)--+------------------------+-+--| '-| on-db-partitions-clause |-' database-containers: .----------------------------------------------------- --. V | |----USING--| container-clause |--+------------------------+-+--| '-| on-db-partitions-clause |-' container-clause: .-,-----------------------------------------------------. V | |--(----+-FILE---+--'--container-string--'--+-number-of-pages-+-+--)--| '-DEVICE-' '-integer--+-K-+---' +-M-+ '-G-' 2.4 表スペース 表スペースは、データベースとそのデータベース内に格納されている表との間に入る記憶モデル、論理層です。 データベースの中に表スペースが作成され、表スペースの中に表などのオブジェクトが作成されます。 実際にデータを格納する物理的な媒体はコンテナーです(2.2章参照)。 バックアップ/リストアーの単位にもなりえます。 以下の種類の表スペースが作成できます。 z REGULAR ：一時表を除くすべてのデータを保管します。 z LARGE ：LONGまたはLOBの表の列を保管します。また、構造タイプ列または索引データを保管することもできます。表スペースはDMS表スペースでなければなりません。 z TEMPORARY ：一時表を格納します。ソートや結合時にデータベース・マネージャーが使用する作業領域です。1つのデータベースに最低1つは必要です。 ●PAGESIZE integer [K] 表スペースに使用するページサイズを定義します。4、8、16、または 32 を指定します。 表スペースのタイプは、SMS/DMSのどちらかを指定します。 表スペースをSMS（システム管理スペース）にするか、DMS（データベース管理スペース）にするかの選択は、トレードオフの関係を含む基本的な選択です。 検討の際の考慮点については、2.2章を参照してください。 ●MANAGED BY SYSTEM ：表スペースを、SMS（システム管理スペース) 表スペースとして指定します。 z system-containers句 SMS表スペースに対するコンテナーを指定します。 z USING (‘container-string’,...) 1つ、または複数のディレクトリー名を指定します。 ●MANAGED BY DATABASE ：表スペースを、DMS(データベース管理スペース）表スペースとして指定します。 z database-containers句 DMS表スペースに対するコンテナーを指定します。 z USING （FILE ‘container-string’ number-of-pages,…） 1つ、または複数のファイル名、サイズを指定します。 z USING （DEVICE ‘container-string’ number-of-pages,…） 1つ、または複数のデバイス名、サイズを指定します。FILEとDEVICEのコンテナーを混合して指定できます。 ●EXTENTSIZE number-of-pages 次のコンテナーに移る前に、コンテナーに書き込まれるページの数を指定します。 デフォルトはDFT_EXTENT_SZデータベース構成パラメーターによって指定されます。 ●PREFETCHSIZE number-of-pages データのプリフェッチ中に、表スペースから一度に読み取られるページ数を指定します。プリフェッチでは照会に必要なデータがその照会で参照される前に読み取られるため、照会では入 出力の実行を待たずに済みます。デフォルトはDFT_PREFETCH_SZデータベース構成パラメーターによって指定されます。 ●BUFFERPOOL bufferpool-name 表スペースに対して使用する、すでに存在しているバッファー・プールの名前を指定します。指定しない場合は、デフォルトのバッファー・プール（IBMDEFAULTBP）が使用されます。 注）一時表スペース、およびバッファー・プールのページ・サイズは、REGULAR表スペースのページ・サイズと一致していなければなりません。 2.4 表スペース RAWデバイスの場合のDMS表スペースの作成例 Windows create tablespace TSRAWWIN managed by database using (device ‘¥¥.¥F’ 40960) EXTENTSIZE 8 AIX create tablespace TSRAWAIX managed by database using (device ‘/dev/rn3hd03’ 40960) EXTENTSIZE 8 ※AIXでRAWデバイスを指定する場合 論理ボリュームを使用します。 rootで論理ボリュームを作成します。 # mklv –y 'n1hd01' db2vg 20 # ls -l /dev/*n1hd01 brw-rw---- 1 root system ... /dev/n1hd01 crw-rw---- 1 root system ... /dev/rn1hd01 インスタンス・オーナーはRAWディバイスに書き込み権限が必要となります。 # chown instnn.admnn /dev/rn1hd01 # ls -l /dev/*n1hd01 brw-rw---- 1 root system ... /dev/n1hd01 crw-rw---- 1 instnn admnn ... /dev/rn1hd01 2.4 表スペース DB2 UDBは、RAWデバイスをサポートしています。(Windows 95、およびWindows 98以外) この種類の装置を識別するための物理的、または論理的方法は以下の通りです。 Windowsでの指定方法(構文) ¥¥.¥PhysicalDriveN ここでNは、システムにある物理ドライブのいずれかを表します。この場合、Nを0、1、2、または他の正の整数に置き換えることができます。 ¥¥.¥PhysicalDrive5 Windowsで論理RAW区画 (つまり未フォーマットの区画)を指定するには、次の構文を使用します。 ¥¥.¥N: ここでN: は、システムにある論理ドライブ名を表します。たとえば、N: をE: または他のドライブ名で置き換えることができます。 ※装置にログを書き込むには、Windows NTバージョン4.0(サービス・パック 3適用済み)をインストールしておく必要があります。 Windows 2000以降の場合、ボリュームの作成時に割り当てられるGUID(グローバル・ユニークID)をデバイスIDとして、表スペース定義でコンテナーを指定する場合に使用できます。 UNIXベースのプラットフォーム UNIXデバイスは文字シリアル・デバイス、ブロック構造デバイスの2つの区分に分類されます。すべてのファイル・システム・デバイスの場合、通常各ブロック・デバイスごとに対応する文字 シリアル・デバイス（ロー・デバイス）を持っています。ブロック構造デバイスは普通、“hd0”、“fd0”のような名前で指定され、文字シリアル・デバイスは普通、“rhd0”、“rfd0”のような名前で 指定されます。これらの文字シリアル・デバイスは、ブロック・デバイスよりも速いアクセス速度を持っています。文字シリアル・デバイス名は、CREATE TABLESPACEコマンド上で使用する 必要があり、ブロック・デバイス名は使用できません。UNIXプラットフォームではインスタンス・オーナーは、使用するデバイス・コンテナーの文字シリアル・デバイス(/dev/rhd0など)に対す るアクセス権限を持っている必要があります。 AIXではDB2 UDBコンテナー用に使用する物理ディスク上のボリューム・グループを指定して論理ボリュームを作成します。RAWデバイスは論理ボリュームの単位で作成されます。 2.5 スキーマ 完全なテーブル名 “スキーマ名．テーブル名” 例1 RICKという名前のスキーマをユーザー RICKを所有者として作成します。 CREATE SCHEMA RICK AUTHORIZATION RICK >>-CREATE SCHEMA------------------------------------------------> >--+-schema-name------------------------------------+-------------> +-AUTHORIZATION--authorization-name--------------+ '-schema-name--AUTHORIZATION--authorization-name-' >--+---------------------- ---+------------------------------------>< | .------------------------. | |V || '---schema-SQL-statement-+-' スキーマの所有者の決定方法 オブジェクトを作成する際にスキーマを指定しない場合、現行の許可IDで修飾されたオブジェクトになります。 そのオブジェクトはユーザーの許可IDを使用して暗黙スキーマに関連付けられます。 オブジェクトがSQLの中で参照されるときに、スキーマ名がSQLの中で指定されない場合もオブジェクトは発行者(動的SQL)の許可IDを使用して暗黙的に修飾されます。 例2 CONNECT TO SAMPLE USER db2admin USING password ･･･db2adminユーザーがSAMPLEデータベースへ接続します。 CREATE TABLE TAB1 (COL1 CHAR(5) ) ･･･表TAB1は、スキーマdb2adminのオブジェクトとして作成されます。 SELECT * FROM TAB1 ･･･db2admin.TAB1が参照されます。 2.5 スキーマ スキーマは、DB2 UDB内でデータベース・オブジェクトを論理的にグループ化するのに使用されるデータベース・オブジェクトです。 ほとんどのデータベース・オブジェクトは、2つの部分からなる命名規則(schema_name.object_name)を使用して命名されます。 名前の最初の部分はスキーマと呼ばれます。2番目の部分はオブジェクト名です。 ●schema-name スキーマの名前を指定します。すでにシステム・カタログに存在する名前を指定することはできません。また“SYS”で始まる名前は使用できません。スキーマの所有者は、ステートメントを 発行した許可IDです。 ●AUTHORIZATION authorization-name スキーマの所有者であるユーザーを指定します。値authorization-nameは、スキーマの名前の指定にも使用されます。authorization-nameは、すでにシステム・カタログに存在するスキー マを指定することはできません。 ●schema-name AUTHORIZATION authorization-name authorization-nameという名前のユーザーをスキーマの所有者として、schema-nameという名前のスキーマを指定します。schema-nameは、すでにシステム・カタログに存在する名前を指 定することはできません。また“SYS”で始まる名前は使用できません。 ●schema-SQL-statement CREATE SCHEMAステートメントの一部として以下のSQLステートメントを組み込むことができます。 ・タイプ付き表およびマテリアライズ照会表を除いたCREATE TABLEステートメント (2.6章CREATE TABLEを参照) ・タイプ付きビューを除いたCREATE VIEWステートメント (2.7章CREATE VIEWを参照) ・CREATE INDEXステートメント (2.9章CREATE INDEXを参照) ・COMMENTステートメント ・GRANTステートメント 2.6 表 例 DEPARTX表スペースに表TDEPTを作成します。 DEPTNO、DEPTNAME、MGRNO、およびADMRDEPTは列の名前です。 CHARは列のデータが固定長文字データ、VARCHARは列のデータが可変長文字データであることを意味します。NOT NULLは列にヌル値を含めることができないことを示します。 基本キーは、列DEPTNOで構成されます。 CREATE TABLE TDEPT ( DEPTNO CHAR(3) NOT NULL, DEPTNAME VARCHAR(36) NOT NULL, MGRNO CHAR(6), ADMRDEPT CHAR(3) NOT NULL, PRIMARY KEY (DEPTNO) ) IN DEPARTX >>-CREATE--TABLE--table-name------------------------------------> |-(-column-name--+--------------------+-)---------------------------> | | '-| data-type |---------' >--+-----------------+--------------------------------------------> '-| column-options |-' >--+--------------------------------------------------------------> '-IN--tablespace-name1-----+-------------------------------+----> '-INDEX IN--tablespace-name2------' '-LONG IN--tablespace-name3------' column-options: .--------------------------------------------------------------------------------------------. V | |----+-------------------------------------------------------------------------------------+-+-| +-NOT NULL-----------------------------------------------------------------------------+ | | +-| lob-options |---------------------------------------------------------------------------+ | | +-+-----------------------------+--+-+-PRIMARY KEY-+---------------------------------+-+ '-CONSTRAINT--constraint-name-' | '-UNIQUE-------' | +-| references-clause |--------------------------------+ '-CHECK--(--check-condition--)--| constraint-attributes |-' 4K ページ・サイズ 表内の最大列 行の最大長（B） 最大表サイズ(区画あたり) （GB） 8K ページ・サイズ 16K ページ・サイズ 32K ページ・サイズ 500 1012 1012 1012 4005 8101 16293 32677 64 128 256 512 2.6 表 表は列と行からなり、順序付けられていないデータ・レコードの集合を保管します。 ●column-name data-type 列名や列の属性のリストを指定します。列の属性として使用可能なデータタイプは、以下に示すDB2提供のデータ・タイプです。 データ・タイプ 2進ストリング 文字ストリング 日時 2バイト文字 ストリング DATE TIME TIMESTAMP 10進数 整数 CHAR BLOB 浮動 少数点数 DECIMAL DBCLOB GRAPHIC VARCHAR DATALINK 数値 SMALLINT LONG VARCHAR INTEGER VARGRAPHIC BIGINT DOUBLE/FLOAT REAL CLOB LONG VARGRAPHIC ●column-options 詳細はマニュアル(SQLリファレンス)を参照してください。 表に制約を設けることによって、表の間の関係、表の内部での関係などを維持でき、データレコードが固有であることを保証できます。制約はデータべース・マネージャーが適用する規制 です。固有制約、参照制約、検査制約の3種類の制約があります。詳細は、添付資料を参照してください。 ※表は、一旦作成すると列名、データタイプを変更することはできません。 2.6.1 MQT（マテリアライズ照会表） ■MQT （マテリアライズ照会表） 例 CUSTOMER_ORDER表から2003年分の注文の総計を計算した結果をデータに持つSUMMARY_CUSTOMER_ORDER_2003表を作成します。 CREATE TABLE SUMMARY_CUSTOMER_ORDER_2003 AS (SELECT SUM(AMOUNT) AS TOTAL_SUM, TRANS_DT, STATUS FROM CUSTOMER_ORDER WHERE TRANS_DT BETWEEN '1/1/2003' AND '12/31/2003' GROUP BY TRANS_DT, STATUS) DATA INITIALLY DEFERRED REFRESH DEFERRED >>-CREATE--TABLE--table-name----------------------------------------------------------> materialized-query-definition: |--+-----------------------+--AS-- (--fullselect--)--+-WITH NO DATA--+--------------+-+--| | .-,------------. | | '-| copy-options |-' | | V | | '-| refreshable-table-options |------------' '- (----column-name-+--)-' refreshable-table-options: |--DATA INITIALLY DEFERRED--REFRESH--+-DEFERRED-+--*----------> '-IMMEDIATE-' .-ENABLE QUERY OPTIMIZATION--. >--+------------------------------+--*----------------------------> '-DISABLE QUERY OPTIMIZATION-' .-MAINTAINED BY SYSTEM-. >--+------------------------+--*----------------------------------| '-MAINTAINED BY USER----' MQTの制限事項 zマテリアライズ照会表の構造は変更できません。 zマテリアライズ照会表に参照される基本表の列の長さは変更できません。 zユニーク索引は作成できません。 2.6.1 MQT（マテリアライズ照会表） MQT（マテリアライズ照会表）とは照会結果に基づいて定義される表で、1つ以上の表のデータを事前に計算した結果が格納されています。 MQTは、AS fullselect文節とIMMEDIATEまたはREFRESH DEFERREDオプションを指定した、CREATE TABLEステートメントを使用して定義します。 複雑な照会が必要な場合の応答時間を改善したい場合に使用します。 照会の経路指定が可能 DB2 UDB V8より前のDB2 UDBでは集約された結合のみを参照するサマリー表がサポートされていました。V8より、集約されない結合が定義に含まれるMQTに、照会を経路指定できる ようになりました。オプティマイザーは、要求された情報がMQTに含まれていることを認識し、基本表の代わりにMQTを使用します。 ニックネームによるマテリアライズ照会表 リモート・データをDB2インスタンス上にローカルにキャッシュすることができます。 ●DATA INITIALLY DEFERRED 表へのデータ挿入を据え置きます。データは後でREFRESH TABLEステートメントによって挿入することができます。 ●REFRESH DEFERRED/IMMEDIATE 基本表の変更時にMQTを自動的にリフレッシュするか（REFRESH IMMEDIATE）、またはREFRESH TABLEステートメントを使ってリフレッシュするか（REFRESH DEFERRED）を指定します。 REFRESH DEFERREDを使用して定義されたMQTは、関連したステージング表を作成することにより、増分リフレッシュが可能です。MQTの基礎表が挿入/削除/更新ステートメントによっ て変更された場合、変更内容はステージング表へ伝えられた後、“REFRESH TABLE”文使用時にリフレッシュされます。 ●MANAGED BY SYSTEM/USER MQTのデータがシステムによって保守されるか（SYSTEM）、ユーザーによって保守されるか（USER）を指定します。 2.6.2 MDC（多次元クラスタリング） ■MDC （多次元クラスタリング） 例 REGION および YEAR 列に次元を持つSALES表を作成します。データはREGIONおよびYEAR列の値の固有な組み合わせを基にしてエクステントに編成されます。 CREATE TABLE SALES ( BRANCH_ID INTEGER, BRANCH_NAME CHAR(20) BRANCH_SALES INTEGER, REGION CHAR(5), YEAR INTEGER ) ORGANIZE BY DIMENSIONS ( REGION, YEAR ) >>-CREATE--TABLE--table-name------------------------------------------------> >--+-| element-list |-------------------------------------------------------------> >--+-----------------------------------------------------------------------+--> | .-,----------------------------. | | .-DIMENSIONS-. V | | '-ORGANIZE BY--+-+-------------+--(----+-column-name-----------+-+--)-+-' | | .-,-----------------. | | | | V | | | '-(----column-name-+--)--‘ | '-KEY SEQUENCE--| sequence-key-spec |------------------' 2.6.2 MDC（多次元クラスタリング） MDC（多次元クラスタリング）とはクラスター索引の考え方を推し進めて1つディメンション（次元）だけでなく同時に複数のディメンションに基づいてクラスタリングを行う機能です。指定した 次元のデータの値に従って、物理的にデータが格納されていく仕組みです。 1つの表のデータが複数の次元でクラスタリングされていることによって、大規模な表に対する複合照会などでパフォーマンスが大きく改善します。 データウェアハウジングや大規模なデータベース環境、オンライン・トランザクション処理（OLTP）環境で使用します。 クラスター索引との違い クラスター索引は1つの表に1つのみ作成可能なのに対し、MDCは指定したそれぞれのディメンションごとにディメンション・ブロック索引とすべてのディメンションのキー列を含む複合ブ ロック索引を自動的に作成します。 クラスター索引はデータの並び順を保つために定期的に保守が必要なのに対し、MDCは各次元のディメンションを自動的かつ動的に保守することができます。 ●ORGANIZE BY DIMENSIONS (column-name,…) column-nameには表データをクラスター化するために使用する、各列または列のグループのディメンションを指定します。ディメンション・リストで括弧を使用すると、列のグループは1つ のディメンションとして扱われるように指定されます。 ●クラスター索引 ●MDC クラスター索引 ディメンション・ブロック索引 ディメンション・ブロック索引 九州 2003 関西 2003 Region Year Region 関東 2003 関東 2002 Year 2.7 ビュー 例 PROJECT表に基づくビューMA_PROJを作成します。このビューには、文字‘MA’で始まるプロジェクト番号(PROJNO)を持つ行だけを入れます。 CREATE VIEW MA_PROJ AS SELECT * FROM PROJECT WHERE SUBSTR(PROJNO, 1, 2) = 'MA' >>-CREATE--VIEW--view-name---------------------------------------> >--+---------------------------------------------+--AS------------> | .-,--------------. | | V | | +-(----column-name-+--)-----------------------+ >--+------------------------------------+--fullselect----------------> >--+------------------------------------+--------------------------> | .-CASCADED-. | '-WITH--+-----------+--CHECK OPTION-' '-LOCAL----' ※ ビューを作成する基礎表またはビューは事前に存在していなければなりません。 CREATE VIEW文を使用して作成される論理表 基礎表と同様にDML文でアクセス。 create view emp_view1 (empid,deptno,jobtitle,hiredate) as select id,dept,job,hiredate from employee where dept=10 検査オプション付きビュー 条件が常に検査されるようにする。 create view emp_view2 (empid,deptno,jobtitle,hiredate) as select id,dept,job,hiredate from employee where dept=10 with check option with check optionが指定されていない場合はdept=10以外の行は追加、更新の検査はしない。 2.7 ビュー ビューは1つ以上の表のデータを表とは別の形で表示するための仮想の表のことで、“CREATE VIEW”文を使用して作成されます。定義すると、基礎表と同様にDML文(SELECT、INSERT、 UPDATE、DELETEなど)を使用してアクセスできるようになります。 以下のことが可能です。 ・表の全てを含めることも、一部の列のみを含めることもできる。 ・ビューに基づいて作成することもできる。 ・元の表と対応する列名と異なる列名を付けることができる。 ・アプリケーション・プログラミングやエンドユーザーは照会によって表データを柔軟に調べることができる。 ・アプリケーション・プログラミングに表データのサブセットを提供して挿入または更新されるデータを検証することができる。 ビュー用のデータは表データと別に保存されるわけではなく、ビューで表示されるデータは基本表に保存されているものです。 ビューの作成後、アクセス特権を指定できます。これにより、基礎表の制限されたビューにしかアクセスできなくなるので、データセキュリティーが得られます。 ●column-name ビューの列の名前を指定します。列名のリストを指定する場合、リスト中の列の名前の数は、全選択の結果表の列の数と同じ数でなければなりません。各column-name(列名)は、固有で、 しかも非修飾でなければなりません。列名のリストの指定がない場合、ビューの列は、全選択の結果表の列名を継承します。 ●WITH CHECK OPTION ビューによって挿入または更新される行すべてが、ビューの定義に従う(ビューの探索条件を満たしている)という制約を指定します。 ・CASCADED ：そのビューが従属するビューの制約も全て継承します。さらにそのビューに従属するビューもこのような制約の対象になります。 ・LOCAL ：そのビューの制約だけを適用します。そのビューに従属するビューもこの制約の対象となります。 z CASCADEDとLOCALの差異 view1 defined on table T view2 defined on view1 WITH Y CHECK OPTION view3 defined on view2 view4 defined on view3 WITH Y CHECK OPTION view5 defined on view4 ※Yは次の表でLOCALまたはCASCADEDに置き換える。 YがLOCALの場合 YがCASCADEDの場合 view1でのチェック条件 対象となるビューなし 対象となるビューなし view2でのチェック条件 view2 view2、view1 view3でのチェック条件 view2 view2、view1 view4でのチェック条件 view2、view4 view4、view3、view2、view1 view5でのチェック条件 view2、view4 view4、view3、view2、view1 2.8 別名 例 HEDGESは表T1に対して別名A1を作成します。 CREATE ALIAS A1 FOR T1 ⇒⇒⇒ HEDGES.T1に対して別名HEDGES.A1が作成されます。 ここで、 SELECT * FROM A1 は、実際には次のものになります。 SELECT * FROM T1 >>-CREATE----ALIAS----alias-name--FOR--+-table-name--+--------->< +-view-name---+ +-nickname----+ '-alias-name2-' ※ 別名は存在しない表またはビューにも定義することができます。 ただし、その別名を含むSQLステートメントがプリコンパイルされるときまでにはそのオブジェクトは存在していなければなりません。 別名または別名が参照するオブジェクトを削除するとその別名が存在する全てのパッケージが無効とマークされ、その別名に依存する全てのビューおよびトリガーが作動不能とマー クされます。 2.8 別名 別名は、表やビューを間接的に参照する方法です。 これにより、SQL ステートメントに表やビューの修飾名を指定せずに済みます。表名やビュー名を変更しても、別名の定義を変えるだけで済みます。 24時間365日連続稼動のシステムのバックアップ/リカバリー運用の時などに使用されます。 例えば、表の実体がTAB01∼TAB12など複数存在する環境で、当月の売上データを保持する実体に「当月売上表」という別名を作成します。月末には“DROP ALIAS”、“CREATE ALIAS”文を実行することで一瞬にして「当月売上表」の指す実体を別のものに切り替えるという月次処理を行い、切り替えられた古い「当月売上表」は「前月売上表」としてバックアップや リカバリーに利用するなどの運用が考えられます。 別名は他の別名に対して作成することもできます。別名は、ビューやトリガーの定義、また SQL ステートメントの中で使用できます。ただし、既存の表名やビュー名を参照する表検査制 約では使用できません。 ●alias-name 別名を指定します。この名前が、現行データベースに既に存在する表、ビュー、ニックネーム、または別名は使用できません。 2つの部分からなる名前を指定する場合、‘SYS’で始まるスキーマ名は使用できません。 別名を定義する際の規則は、表名の定義に使用される規則と同じです。 ●FOR table-name、view-name、nickname、 または alias-name2 alias-nameを定義する対象のオブジェクト名を指定します。他の別名(alias-name2)を指定する場合、その別名は、定義される新しいalias-name(完全修飾形式の)と同じであってはなりま せん。 ※別名は、ステートメントのコンパイル時に表名やビュー名に置き換えられます。別名または別名連鎖が表名やビュー名に置換できないと、エラーになります。 2.9 索引 例 PROJECT表に対してUNIQUE_NAMという名前の索引を作成します。 この索引の目的は、プロジェクト名(PROJNAME)の値が同じ 2 つの項目が表に作成されないようにすることです。索引項目は昇順に並べます。 CREATE UNIQUE INDEX UNIQUE_NAM ON PROJECT(PROJNAME) >>-CREATE--+--------+--INDEX--index-name------------------------> '-UNIQUE-' .-,-----------------------. V .-ASC--. | >--ON--+-table-name------+--(----column-name--+------+-+--)-----> | | '-DESC-' '-nickname--------' >--+-------------------------------------+--*-------------------> | .-,--------------. | | V | | '-INCLUDE-------(----column-name-+--)-‘ >--+-----------------------------------------------------------------------+--> +-CLUSTER-------------------------------------------------------------+ >--+--------------------------+-----------------------------------------------> -ALLOW REVERSE SCANS----' ※ 索引を作成する基本表は事前に存在していなければなりません。 インデックス作成の指針 z基本キーまたはユニークインデックスを作成する。 z結合列にインデックスを作成する。 zWHERE句で指定された検索条件の列にインデックスを作成する。 zソート列（DISTINCT、ORDER BY句、GROUP BY句）で指定されることが多い列にインデックスを作成する。 z外部キーとして指定されている列にインデックスを作成する。 インデックスの数 zOLTP系の環境では1テーブルに1つか2つにする。 z照会専用のテーブルでは、5つ程度を目安とする。 z照会/OLTP混在環境では、インデックスは2つから5つくらいに抑える。 2.9 索引 索引は一つの表に関連した物理オブジェクトで、指定された列の内容によって分類された、行の場所のリストです。一つの表に対して複数の索引を作成することもできます。 索引の目的 z SQL照会のパフォーマンスを向上させる。 索引を作成すると、表の中の行により効率的にアクセスすることができます。索引は表から条件に一致するデータを検索する際に表全体を走査する代わりに使用されます。 z 行のユニーク性を維持する。 ●UNIQUE ユニーク索引としたい場合に指定します。 表には索引キーの値が同じである複数の行を含めることができなくなります。そのため、表の行の更新、新しい行の挿入を行うSQLステートメントの終了時に、固有性が確保されます。 また、この固有性は、CREATE INDEXステートメントの実行の過程でも検査されます。重複するキー値を含む行がすでに表に含まれている場合、索引は作成されません。 UNIQUEを使用する場合、NULL値は他の値と同様に扱われます。たとえば、キーが、NULL値可能の単一列である場合、その列では 1 つのNULL値しか含めることができません。 UNIQUEオプションの指定があり、しかも表に区分化キーがある場合、索引キーの列は区分化キーのスーパーセットである必要があります。 ●ASC 索引項目が、列の値の昇順で保持されるように指定します。これがデフォルトの設定です。 ●DESC 索引項目が、列の値の降順で保持されるように指定します。 ●INCLUDE UNIQUEを指定した索引にのみ指定することができます。 特定の索引と共に、特に頻繁に取り出すケースが多い列を優先してその索引に列の値を保持させます。付加した列は、索引列とはなりますが、ユニーク性のチェックは行われません。 ●CLUSTER 当該の索引を表のクラスター化索引として指定します。指定すると、できるだけ索引順に近い順序で表のデータの並び替えが行われるため、照会のパフォーマンスが向上します。 ●ALLOW REVERSE SCANS 索引が前方向走査と反対方向走査の両方、すなわちCREATE INDEXの実行時に定義した順序とその反対(逆)の順序とをサポートすることを指定します。 2.10 連合システム 例 連合サーバーを構成し、リモートOracle8i上のSCOTTスキーマEMP表を通常のDB2 UDBの表と同様にアクセスできるように設定します。 ①DB2連合データベースに接続しNET8ラッパーを作成します。 CREATE WRAPPER NET8 ②サーバーを定義します。 CREATE SERVER O81SVR TYPE ORACLE VERSION ‘8i’ WRAPPER NET8 OPTIONS(NODE ‘ORA817’) ③連合サーバー上のユーザーdb2usrをOracle上のSCOTTユーザーに対応させます。 CREATE USER MAPPING FOR db2usr SERVER O81SVR OPTIONS （REMOTE_AUTHID ‘SCOTT’, REMOTE_PASSWORD ‘TIGER’） ④OracleのSCOTTスキーマのEMP表を連合サーバーのdb2usrユーザースキーマ内のEMP表としてマッピングします。 CREATE NICKNAME EMP FOR “O81SVR”.”SCOTT”.”EMP” EMP表 Oracle 8i SELECT * FROM EMP DB2連合サーバー SQL Server DB2連合データベース DB2クライアント：db2usr ･ ･ ･ グローバルカタログ 表構造ファイル XML 2.10 連合システム 連合システムは、サーバーとして動作するDB2インスタンス、連合データベースとして機能するデータベース、1つ以上のデータ・ソース、およびデータベースとデータ・ソースにアクセス するクライアント（ユーザーとアプリケーション）で構成されます。連合システムを使用すると、DB2表、Oracle表、XMLタグ付きファイルにあるデータなどの複数のデータソースを単一の SQLステートメントで結合することができます。DB2同士の場合、DB2とInformixの場合は標準機能で可能です。Oracle、SQL Server等他社データ・ソースやXMLタグ付きファイルとの連合 の場合はDB2 Information Integratorを使用して可能になります。 連合システムで可能になること z ローカル表とリモート・データソースからのデータをすべてのデータがローカルにあるかのように結合する。 z Oracle等のリモートのリレーショナル・データソースのデータを、あたかもデータが連合データベースに保管されているかのように更新する。 z DB2とOracle等のリモートのリレーショナル・データソースとの間で、双方向にデータの複製ができる。 z データソースに分散要求を送信して処理させることにより、データソース側で処理するという利点を生かす。 z データソース側でのSQLの制約を補うため、分散要求の一部を連合サーバー側で処理する。 連合システム構築手順 z ラッパーの登録･･･連合サーバーがデータソースへの接続・操作を行うモジュールを定義します。 CREATE WRAPPER wrapper-name LIBRARY library-name OPTIONS (… z サーバーの登録･･･データソースを連合データベースへ定義します。 CREATE SERVER server-name TYPE server-type VERSION server-version WRAPPER wrapper-name… z ユーザーマッピングの登録･･･連合データベース上のユーザーと、データソース側のユーザーの関連付けを定義します。 CREATE USER MAPPING FOR authorization-name SERVER server-name OPTIONS〔… z ニックネームの登録･･･連合データベースへ登録する表やビューなどのオブジェクトに対してニックネームを定義します。 CREATE NICKNAME nickname FOR remote-object-name OPTIONS（… ※これらの定義はCREATE文を使用して行うことにより、連合データベース内に（オブジェクトとして）カタログされます。 第3章 データのロード 3 データのロード データを表に挿入するユーティリティーとして、LOADとIMPORTがあります。 LOADはテーブルの初期ロードなど、大量のデータを移動する処理を目的として設計されています。データ量が多い場合、IMPORTよりも高速にデータを挿入することができます。 IMPORTは内部的にSQLのINSERTを実行するのに対し、LOADは形式化されたページを直接データベースに書き出します。 LOADユーティリティー IMPORTユーティリティー LOADとIMPORTの比較 ・大量のデータを挿入する場合 ・IMPORTに比べはるかに高速 ・フォーマットされたページを直接データベースに書き込む ・SQLのINSERT ログ ・ログ記録は最小限 ・全ての行がロギングされる （COMMITCOUNTパラメータを指定しないとログ がいっぱいになることがあるので注意が必要） データの挿入先 ・表および索引は宛先データベースに存在している必要があ る ・IXF形式のファイルの場合、表定義、索引の作 成はインポートの過程で行われる 表および索引が入っている表スペース 内のオブジェクトへのアクセス ・LOAD中の表と同一表スペースにあるオブジェクトへのアク セス可能 ・IMPORT中の表と同一表スペースにあるオブ ジェクトへのアクセス可能 ・LOAD中の表は照会アクセス可能(ALLOW READ ACCESS) （LOAD INSERT時の照会アクセスは、既存データのみ可、新 規ロードデータはLOAD完了まで不可） ・IMPORT中の表もアクセス可能（ALLOW WRITE ACCESS） （非排他(IX)ロックと非互換のロックは待機） 統計 ・LOAD REPLACEモードでSTATISTICS YESオプションにす ればロードの最中に統計が収集される（※注1） ・IMPORT後にRUNSTATSを実行する 必要な特権、権限 ・データベースに対するLOAD権限 ・関係するオブジェクトに対するINSERTおよびDELETE特権 など ・CONTROL特権 ・関係するオブジェクトに対するINSERTおよび SELECT特権など ※注1 使用例 LOAD FROM product.ixf OF IXF INSERT INTO product STATISTICS YES WITH DISTRIBUTION AND DETAILED INDEXES ALL 3 データのロード LOADには主に以下の2つのモードを用います。 z REPLACEモード 既存の表にあるデータの置換。既存データを入れ替える場合に用いる。 LOAD FROM product.ixf OF IXF REPLACE INTO product z INSERTモード 既存の表への新規データの挿入。既存データに追加する場合に用いる。 LOAD FROM product.ixf OF IXF INSERT INTO product 空の表にデータを挿入する場合は、INSERTモードで実行した方がパフォーマンスが良くなります。 それ以外はREPLACEモードでLOADを実行する方が、最高のパフォーマンスが得られます。 ロードの入力ファイル z DEL (区切り ASCII ファイル) 例 10001,“Peter”,“Smith”,307 z ASC (非区切り ASCII ファイル） 例 10001 Peter Smith 307 z IXF (統合交換形式ファイル) z CURSOR (SELECTまたはVALUESステートメントに対して宣言されたカーソル) SQL照会の結果を、先にデータ・ファイルにエクスポートすることなく、直接データベースにロードすることができます。 例 表 ABC.TABLE1 には以下の 3 つの列があります。 col1 INT DECLARE mycurs CURSOR col2 CHAR(10) col3 DATE 表 ABC.TABLE2 には以下の 3 つの列があります。 col1 VARCHAR LOAD FROM mycurs col2 INT col3 DATE 以下のコマンドを実行すると、すべてのデータが ABC.TABLE1 から ABC.TABLE2 にロードされます。 DECLARE mycurs CURSOR FOR SELECT col2,col1,col3 FROM abc.table1 LOAD FROM mycurs OF CURSOR INSERT INTO abc.table2 ●COPY NO/YES ロードするデータを保存するかどうかの指定を行います。 LOADはログを出力しないため、アーカイブ・ロギングの時にCOPY NO（デフォルト）では表スペースがバックアップ・ペンディング状態になります。 COPY YESを指定するとロールフォワードが可能になります。 ●ALLOW NO ACCESS / ALLOW READ ACCESS ロードターゲット表に対するアクセスの可/不可の指定をします。 ABC.TABLE1 col1 col2 col3 1 AB 20030101 2 EF 20030201 3 LM 20030301 4 RS 20030401 ABC.TABLE2 col1 col2 col3 ST 1 20030404 XY 2 20030505 3 データのロード 例 data.delファイルよりデータをSTAFF表に追加します。 LOAD FROM “C:¥data.del” OF DEL INSERT INTO STAFF (ID, NAME) COPY NO ALLOW READ ACCESS .-,---------------. V | >>-LOAD--+--------+--FROM----+-filename----+-+--OF--filetype---------------------> '-CLIENT-' +-pipename---+ +-device-----+ '-cursorname-' >--+-INSERT-----+---INTO--table-name--+----------------------+-------------------> +-REPLACE---+ | .-,--------------. | +-RESTART---+ | V | | '-TERMINATE-‘ '-(----insert-column-+--)-' >--+--------------------------------------------------------------------------------------+--> | .-YES-. | '-STATISTICS--+-+-----+--+-WITH DISTRIBUTION--+---------------------------------+-+-+-' | | '-AND--+----------+--INDEXES ALL-' | | | | '-DETAILED-' | | | '-+-AND-+--+----------+--INDEXES ALL-------------------------------' | | '-FOR-' '-DETAILED-' | '-NO--------------------------------------------------------------------------' >--+-------------------------------------------------------------+--> | .-NO----------------------------------------------. | +-COPY--+-YES--+-USE TSM--+----------------+-----------+-+-+ | | '-OPEN--num-sess--SESSIONS-' | | | | .-,------------------. | | | | V | | | | +-TO----device/directory-+------------------------+ | | '-LOAD--lib-name--+----------------------------+-' | | '-OPEN--num-sess--SESSIONS-' | '-NONRECOVERABLE--------------------------------------------' .-ALLOW NO ACCESS-----------------------------. >--+------------------------------------------------+--------------> '-ALLOW READ ACCESS--+----------------------+-' '-USE--tablespace-name-' 3 データのロード ロードのプロセスは以下の4つのフェーズで構成されています。 ロード・フェーズ z データが表に保管され、必要に応じて索引キーと表統計が収集される。 z SAVECOUNTパラメーターで指定された間隔で、一貫性ポイントが設定される。 z 障害が発生した場合、RESTARTオプションにより、最後の一貫性ポイントより続行可能。 z ロードの前にバックアップを取得することを推奨。 構築フェーズ z ロード・フェーズで収集された索引キーに基づいて索引が作成される。 削除フェーズ z 固有制約に違反したすべての行が削除される。 例外表が指定されていれば、無効の行は例外表に保管される。 索引コピーフェーズ z ALLOW READ ACCESSオプションを指定したロード操作時で、索引作成にSYSTEM TEMPORARY表スペースを指定した場合のみ、SYSTEM TEMPORARY表 スペースから元の表スペースへ索引データがコピーされる。 添付資料 添付 表の制約 表は列と行からなり、順序付けられていないデータ・レコードの集合を保管します。 表に制約を設けることによって、表の間の関係、表の内部での関係などを維持でき、データレコードが固有であることを保証できます。 制約はデータべース・マネージャーが適用する規制で、以下の3種類があります。 固有制約 キーの値が表内で固有な場合のみ、その値が有効になるという規則。 z NOT NULLである。 z CREATE TABLE文、またはALTER TABLE文で、PRIMARY KEY文節、またはUNIQUE文節を使用して定義する。 参照制約 すべての外部キーのすべての値が有効である状態を保証する規則で、以下の3種類がある。 z INSERT 規則 外部キーの非NULLの挿入値が、親表の親キーの何らかの値に一致していなければならない。暗黙的に適用される。 z DELETE 規則 親表の行の削除時のアクションを指定する。 department表(親表) ・RESTRICT ・NO ACTION deptno deptname mgrno ・CASCADE (primary key) ・SET NULL z UPDATE 規則 親表の行、または従属表の行の更新時のアクションを指定する。 ・RESTRICT ・NO ACTION empno (primary firstname lastname Workdept (foreign key) key) 検査制約 employee表(従属表) 列に許可する値を指定することにより、表レベルでのデータ保全性を定義する規則。 z CREATE TABLE文、またはALTER TABLE文で定義する。 z INSERT、UPDATEされるたびに検査が行われる。 z 検査制約の定義はシステム・カタログ表に保管される。 SYSIBM.SYSCHECKS z 検査制約の追加時、表の全ての行が検査制約に適合していた場合、制約は正常に作成される。一部、または全てが適合しない場合、制約は作成されない。 z SET INTEGRITYステートメントを使用して、検査制約をオフにすることができる。 z 検査制約の変更は、DROP、ADD句を使用して可能。 ALTER TABLE EMPLOYEE DROP CONSTRAINT check_job ALTER TABLE EMPLOYEE ADD CONSTRAINT check_job CHECK(JOB IN (‘OPERATOR’,’CLERK’)) phoneno