Informix Guide to Database Design and Implementation

Informix Guide to
Database Design and
Implementation
Informix Extended Parallel Server, Version 8.3
Informix Dynamic Server.2000, Version 9.2
December 1999
Part No. 000-6525-8
Informix のソフトウェアおよびユーザ・マニュアルは「現状のまま」提供され、商品性の黙示的な保証お
よび特定の目的への適合性の黙示的な保証など、明示的か黙示的かを問わず、いかなる種類の保証も提供さ
れません。Informix のソフトウェアおよびユーザマニュアルの品質と性能についてのリスクは、すべて、
お客様の負担です。Informix のソフトウェアおよびユーザ・マニュアルに欠陥があった場合には、すべて
の必要なサービス、修理または修正のための費用は、すべて、（Informix または Informix の正規取扱店では
なく）お客様の負担となります。いかなる場合においても、Informix は Informix または Informix の正規代
理店がそうした損害の可能性を知らされていた場合であっても、Informix のソフトウェアまたはユーザ・
マニュアルの使用または使用不能から生じた、利益の喪失、節約の喪失あるいは他の偶発的または結果的な
損害など、いかなる損害についても責任を負わず、また第三者からのいかなる請求についても責任を負いま
せん。加えて、Informix は、厳格責任あるいは Informix の過失に基づく請求で Informix のソフトウェアま
たはユーザ・マニュアルの使用または使用不能から生じた一切の請求についても責任を負いません。管轄地
によっては、黙示的な保証の排除を認めていない管轄地もあり、その場合には上記の排除の全部または一部
が適用されないこともあります。この保証は、お客様に特定の法的な権利を付与するものですが、管轄地に
よって異なる、その他の権利がお客様に認められることもあります。
すべての権利は Informix に保留されます。本書についての著作権で保護される本書のいかなる部分も、グ
ラフィック、電子的方法、あるいは、コピー機、記録装置、テープ、情報記憶媒体、検索システムなどの機
械的方法など、形態あるいは方法を問わず、発行元の許可を得ないで、複製または使用することはできませ
ん。
発行者 : Informix Press
Informix Software, Inc.
4100 Bohannon Drive
Menlo Park, CA 94025-1032
Answers OnLine、C-ISAM、Client SDK、DataBlade、Data Director、Decision Frontier、Dynamic Scalable
Architecture、Dynamic Server、Dynamic Server, Developer Edition、Dynamic Server with Advanced
Decision Support Option、Dynamic Server with Extended Parallel Option、Dynamic Server with
MetaCube、Dynamic Server with Universal Data Option、Dynamic Server with Web Integration Option、
Dynamic Server, Workgroup Edition、Dynamic Virtual Machine、Extended Parallel Server、Formation、
Formation Architect、Formation Flow Engine、Gold Mine Data Access、IIF.2000、i.Reach、i.Sell、Illustra、
Informix、Informix 4GL、Informix Inquire、Informix Internet Foundation.2000、InformixLink、
Informix Red Brick Decision Server、Informix Session Proxy、Informix Vista、InfoShelf、Interforum、ISpy、Mediazation、MetaCube、NewEra、ON-Bar、OnLine Dynamic Server、OnLine/Secure
Dynamic Server、OpenCase、Orca、PaVER、Red Brick and Design、Red Brick Data Mine、
Red Brick Mine Builder、Red Brick Decisionscape、Red Brick Ready、Red Brick Systems、
Regency Support、Rely on Red Brick、RISQL、Solution Design、STARindex、STARjoin、SuperView、
TARGETindex、TARGETjoin、The Data Warehouse Company、The one with the smartest data wins.、
The world is being digitized. We’re indexing it.、Universal Data Warehouse Blueprint、Universal Database
Components、Universal Web Connect、ViewPoint、Visionary、Web Integration Suite は、Informix
Software, Inc. の登録商標です。
その他の名前やマークはすべて、それぞれの所有者の登録商標、または商標である可能性があります。
権利制限
ソフトウェアおよびその付随資料は、米国連邦政府の資金によって取得された場合、次の使用許諾条件のも
とに提供されます。(1) 米国連邦政府関係機関による使用については、FAR 52.227-19 に定義される「制限さ
れた権利」
、(2) 米国国防省による使用については、DFAR227.7202 に基づき別途合意された納入業者の使用
許諾条件が適用される以外、納入業者の標準使用許諾条件。本表記が付されているソフトウェアおよびその
付随資料のいかなる部分的あるいは全部の複製においては、本表記を必ず再製しなければなりません。
Copyright © 1981-1999 by Informix Software, Inc.
ii
Informix Guide to Database Design and Implementation
目次
目次
序
序の概要 . . . . . . . . . . . . . . . . . .
このマニュアルについて . . . . . . . . . . . . .
対象ユーザ . . . . . . . . . . . . . . . .
必要なソフトウェア . . . . . . . . . . . . .
ロケールについて . . . . . . . . . . . . .
デモンストレーション データベース . . . . . . .
新機能 . . . . . . . . . . . . . . . . . . .
バージョン 8.3 で導入された新しい機能 . . . . . .
バージョン 9.2 で導入された新しい機能 . . . . . .
表記規則 . . . . . . . . . . . . . . . . . .
文字の表記規則 . . . . . . . . . . . . . .
アイコンの表記規則 . . . . . . . . . . . . .
サンプル コードの表記規則 . . . . . . . . . .
関連マニュアル . . . . . . . . . . . . . . . .
オンライン マニュアル . . . . . . . . . . . .
ペーパー マニュアル . . . . . . . . . . . .
オンライン ヘルプ . . . . . . . . . . . . .
エラー メッセージ ファイル . . . . . . . . . .
ドキュメント ノート、リリース ノート、マシン ノート
参考文献 . . . . . . . . . . . . . . . . .
業界標準への準拠 . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
序3
序3
序3
序4
序4
序4
序5
序5
序5
序7
序7
序8
序 10
序 10
序 11
序 11
序 11
序 11
序 12
序 14
序 14
この章の概要 . . . . . . . . . . . . . . . . . . . .
データベースのデータ モデルの選択 . . . . . . . . . . .
1-3
1-3
セクション I
第1章
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
データベース設計と実装の基礎
データベースの設計
ANSI 標準準拠データベースの使用法 . . . . . . . .
データベースの ANSI 標準準拠への設定 . . . . .
既存のデータベースが ANSI 標準準拠であるかの判断
ANSI 標準準拠のデータベースと
ANSI 標準準拠でないデータベースとの相違点
使用するデータベース専用の言語環境の使用法 . . . .
第2章
.
.
. .
. .
1-6
1-10
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2-3
2-3
2-4
2-4
2-4
2-8
2-15
2-17
2-18
2-18
2-20
2-20
2-22
2-25
2-25
2-27
2-27
2-28
2-30
2-30
2-30
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3-3
3-3
3-4
3-24
3-25
3-25
. .
.
. .
4-3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
.
. .
リレーショナルデータモデルの実装
この章の概要
iv
1-4
1-5
1-5
データ型の選択
この章の概要 .
ドメインの定義 .
データ型 .
NULL 値 .
デフォルト値
チェック制約
第4章
. .
. .
. .
リレーショナルデータ モデルの作成
この章の概要 . . . . . . . . . . . .
データ モデルを作成する理由 . . . . . . .
実体 - 関係データ モデルの概要 . . . . . .
主なデータ オブジェクトの識別と定義 . . .
実体の識別 . . . . . . . . . . . .
関係の定義 . . . . . . . . . . . .
属性の識別 . . . . . . . . . . . .
データ オブジェクトの図式化 . . . . . . .
E-R ダイヤグラムの読み方 . . . . . .
住所録の例 . . . . . . . . . . . .
E-R データ オブジェクトの関係構造体への変換
表、行、列の定義 . . . . . . . . .
表のキーの決定 . . . . . . . . . .
関係の解決 . . . . . . . . . . . . .
m:n 関係の解決 . . . . . . . . . .
その他の特別な関係の解決 . . . . . .
データ モデルの正規化 . . . . . . . . .
第 1 正規形 . . . . . . . . . . . .
第 2 正規形 . . . . . . . . . . . .
第 3 正規形 . . . . . . . . . . . .
正規化ルールのまとめ . . . . . . . .
第3章
.
.
.
.
. .
.
. .
Informix Guide to Database Design and Implementation
. .
.
データベースの作成 . . . . .
CREATE DATABASE 文の使用
CREATE TABLE 文の使用方法
断片化された表の作成 . . .
CREATE INDEX 文の使用 . .
表名でのシノニムの使用方法 .
シノニム連鎖の使用方法 . .
コマンドスクリプトの使用方法
データの初期入力 . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4-3
4-4
4-6
4-8
4-8
4-13
4-15
4-16
4-17
この章の概要 . . . . . . . . . . . . . . . . . . .
フラグメント化とは . . . . . . . . . . . . . . . .
Extended Parallel Server に対する拡張フラグメント化 . . .
フラグメント化を使用する理由 . . . . . . . . . . .
フラグメント化の責任者 . . . . . . . . . . . . .
フラグメント化とログ . . . . . . . . . . . . . .
表のフラグメント化のための分散スキーム . . . . . . . .
式に基づく分散スキーム . . . . . . . . . . . . .
ラウンド ロビン分散スキーム . . . . . . . . . . .
範囲分散スキーム . . . . . . . . . . . . . . . .
システム定義ハッシュ分散スキーム . . . . . . . . .
ハイブリッド分散スキーム . . . . . . . . . . . .
検索からのフラグメントの除去 . . . . . . . . . . .
フラグメント表の作成 . . . . . . . . . . . . . . . .
フラグメント表を新たに作成する . . . . . . . . . .
フラグメント表内の行 ID . . . . . . . . . . . . .
フラグメント化されていない表からのフラグメント表の作成
スマート ラージ オブジェクトのフラグメント化 . . . . .
フラグメンテーション ストラテジの変更 . . . . . . . . .
INIT 節を使用してフラグメント化スキームを再初期化 . .
INIT 節を使用してハッシュ フラグメント化をハイブリッド
フラグメント化に変更 . . . . . . . . . . .
MODIFY 節を使用して既存のフラグメンテーション
ストラテジを変更 . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5-3
5-3
5-5
5-6
5-7
5-7
5-8
5-9
5-11
5-11
5-12
5-13
5-16
5-21
5-21
5-22
5-23
5-24
5-25
5-25
セクション II データベースの管理
第5章
表フラグメンテーション ストラテジ
. 5-27
. 5-27
目次
v
ATTACH 節および DETACH 節を使用して既存の
フラグメンテーション ストラテジを変更 . . .
ADD 節を使用してフラグメントを追加 . . . . . .
DROP 節を使用してフラグメントを削除 . . . . . .
一時表のフラグメント化 . . . . . . . . . . . . .
Extended Parallel Server による一時表のフラグメント化
表インデックスのフラグメント化 . . . . . . . . . .
連結インデックス . . . . . . . . . . . . . .
分離インデックス . . . . . . . . . . . . . .
行 ID . . . . . . . . . . . . . . . . . . .
フラグメント表に格納されているデータへのアクセス . . .
行 ID の代わりに主キーを使用する . . . . . . . .
フラグメント表の行 ID の列の作成 . . . . . . . .
フラグメント アクセス権の付与と取消し . . . . . .
第6章
.
.
.
.
.
.
.
.
.
.
.
.
.
5-28
5-30
5-31
5-31
5-31
5-33
5-33
5-34
5-35
5-36
5-36
5-37
5-38
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6-3
6-3
6-4
6-5
6-7
6-7
6-11
6-12
6-14
6-14
6-15
6-19
6-19
6-20
6-21
6-22
6-23
6-24
6-28
6-31
6-31
6-32
データベース サーバのアクセス権の付与と制限
この章の概要 . . . . . . . . . . . .
データベースへのアクセスの制御 . . . . .
アクセス権の付与 . . . . . . . . . . .
データベースレベルアクセス権 . . . .
所有者の権限 . . . . . . . . . . .
表レベルアクセス権 . . . . . . . .
列レベルアクセス権 . . . . . . . .
型レベル アクセス権 . . . . . . . .
ルーチン レベル アクセス権 . . . . . .
言語アクセス権 . . . . . . . . . .
アクセス権の自動化 . . . . . . . .
SPL ルーチンによるデータへのアクセスの制御
データの読込みの制限 . . . . . . . .
データへの変更の制限 . . . . . . . .
データへの変更の監視 . . . . . . . .
オブジェクト作成の制限 . . . . . . .
ビューの使用 . . . . . . . . . . . .
ビューの作成 . . . . . . . . . . .
ビューを用いたデータの変更 . . . . .
アクセス権とビュー . . . . . . . . . .
ビューの作成時のアクセス権 . . . . .
ビューを使用するときのアクセス権 . . .
vi
.
.
.
.
.
.
.
.
.
.
.
.
.
Informix Guide to Database Design and Implementation
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
セクション III オブジェクトリレーショナル データ
ベース
第7章
Dynamic Server での拡張データ型の作成と使用
この章の概要 . . . . . . . . . . .
ユーザ定義のデータ型 . . . . . . . .
不透明 (OPAQUE) 型 . . . . . .
ディスティンクト型 . . . . . . .
スマート ラージ オブジェクト . . . . .
BLOB 型 . . . . . . . . . . .
CLOB 型 . . . . . . . . . . .
スマート ラージ オブジェクトの使用 .
スマート ラージ オブジェクトのコピー
複合データ型 . . . . . . . . . . .
コレクション (COLLECTION) 型 . .
名前付き行 (ROW) 型 . . . . . .
名前なし行 (ROW) 型 . . . . . .
第8章
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 7-3
. 7-4
. 7-4
. 7-4
. 7-5
. 7-5
. 7-5
. 7-7
. 7-8
. 7-8
. 7-10
. 7-16
. 7-23
この章の概要 . . . . . . . . . . . . . . .
継承について . . . . . . . . . . . . . . .
型継承 . . . . . . . . . . . . . . . . .
型階層の定義 . . . . . . . . . . . . .
型階層内の型に対するルーチンのオーバーロード
継承と型代用性 . . . . . . . . . . . .
型階層からの名前付き行 (ROW) 型の削除 . . .
表継承 . . . . . . . . . . . . . . . . .
型階層と表階層との関係 . . . . . . . . .
表階層の定義 . . . . . . . . . . . . .
表階層内の表の動作の継承 . . . . . . . .
型階層内の表の動作の修正 . . . . . . . .
表階層内のシリアル (SERIAL) 型 . . . . . .
表階層への表の追加 . . . . . . . . . . .
表階層内の表の削除 . . . . . . . . . . .
表階層内の表の構造の変更 . . . . . . . .
表階層内の表の問合せ . . . . . . . . . .
表階層内の表のビューの作成 . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Dynamic Server による型継承と表継承
目次
8-3
8-3
8-3
8-4
8-7
8-8
8-9
8-10
8-11
8-12
8-13
8-15
8-18
8-19
8-20
8-21
8-21
8-21
vii
第9章
Dynamic Server でのユーザ定義キャストの作成と使用
この章の概要 . . . . . . . . . . . . . . . . . .
キャストとは . . . . . . . . . . . . . . . . . .
ユーザ定義キャストの作成 . . . . . . . . . . . .
キャストの起動 . . . . . . . . . . . . . . . .
ユーザ定義キャストに関する制限 . . . . . . . . . .
行 (ROW) 型のキャスト . . . . . . . . . . . . . . .
名前付き行 (ROW) 型と名前なし行 (ROW) 型の間のキャスト
名前なし行 (ROW) 型どうしのキャスト . . . . . . .
名前付き行 (ROW) 型どうしのキャスト . . . . . . .
フィールドの明示的キャストが必要な行 (ROW) 型変換 . .
行 (ROW) 型の各フィールドのキャスト . . . . . . .
コレクション (COLLECTION) 型のキャスト . . . . . . .
コレクション (COLLECTION) 型の変換の制限 . . . . .
要素型が異なるコレクションの変換 . . . . . . . . .
リレーショナル データから マルチセット (MULTISET) 型
コレクションへの変換 . . . . . . . . . .
ディスティンクト型のキャスト . . . . . . . . . . . .
ディスティンクト型での明示的キャストの使用 . . . . .
ディスティンクト型とソース型の間のキャスト . . . . .
スマート ラージ オブジェクトへのキャスト . . . . . . . .
ユーザ定義キャストのキャスト関数の作成 . . . . . . . .
名前付き行 (ROW) 型間でのキャストの例 . . . . . . .
ディスティンクト型間でのキャストの例 . . . . . . .
マルチレベル キャスト . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9-3
9-3
9-4
9-5
9-5
9-6
9-7
9-8
9-8
9-9
9-10
9-11
9-12
9-12
.
.
.
.
.
.
.
.
.
9-13
9-14
9-14
9-15
9-17
9-18
9-18
9-19
9-21
.
.
.
.
.
.
.
.
.
10-3
10-4
10-5
10-6
10-8
10-10
10-11
10-14
10-15
セクション IV 次元データベース
第 10 章
次元データ モデルの作成
この章の概要 . . . . . . . . .
データ ウェアハウスの概要 . . . .
次元データベースを作成する理由 .
次元データとは . . . . . . .
次元データ モデルのコンセプト . . .
ファクト表 . . . . . . . . .
データ モデルの次元 . . . . .
次元データ モデルの作成 . . . . .
ビジネス プロセスの選択 . . . .
viii
Informix Guide to Database Design and Implementation
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ビジネス プロセスの要約 . . . .
ファクト表の細分性の決定 . . .
次元と階層の明確化 . . . . . .
ファクト表のメジャー ( 基準 ) の選択
正規化の阻止 . . . . . . . .
次元表の属性の選択 . . . . . .
次元データ モデルの共通する問題の処理
次元表の属性数を最低限に抑える .
時々変更する次元の処理 . . . .
スノーフレーク スキーマの使用 . .
第 11 章
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
10-15
10-17
10-18
10-21
10-23
10-24
10-26
10-26
10-28
10-29
.
.
.
.
.
.
.
.
.
.
.
.
.
11-3
11-3
11-3
11-4
11-6
11-8
11-10
11-10
11-12
11-12
11-16
11-16
11-18
次元データベースの実装
この章の概要 . . . . . . . . . . . . . . . . . . .
次元データベース sales_demo の実装 . . . . . . . . . .
CREATE DATABASE 文の使用 . . . . . . . . . . .
CREATE TABLE 文を使用した次元表およびファクト表の作成
データ ソースからデータベースへのデータのマッピング . .
次元データベースへのデータのロード . . . . . . . .
データベース sales_demo の作成 . . . . . . . . . .
次元データベースのテスト . . . . . . . . . . . .
Extended Parallel Server のログ付き表とログなし表 . . . . .
表の種類の選択 . . . . . . . . . . . . . . . .
表の種類の切替え . . . . . . . . . . . . . . . .
データ ウェアハウス環境のインデックス . . . . . . . . .
データ ウェアハウス環境での GK インデックスの使用 . . .
索引
目次
ix
序
序
序の概要 . .
. .
.
. .
.
. .
. .
.
. .
.
. .
. .
序3
このマニュアルについて . . . . . . . . . . . . . . . . . . . .
対象ユーザ . . . . . . . . . . . . . . . . . . . . . . .
必要なソフトウェア . . . . . . . . . . . . . . . . . . . .
ロケールについて . . . . . . . . . . . . . . . . . . . . .
デモンストレーション データベース . . . . . . . . . . . . . .
序3
序3
序4
序4
序4
新機能 . . . . . . . . . . . . . . . . . . . . . . . . . .
バージョン 8.3 で導入された新しい機能 . . . . . . . . . . . . .
バージョン 9.2 で導入された新しい機能 . . . . . . . . . . . . .
拡張性の向上 . . . . . . . . . . . . . . . . . . . . .
Dynamic Server バージョン 7.30 から バージョン 9.2 へ引き継がれた機能
序5
序5
序5
序6
序6
表記規則 . . . . . . . . . . . . . . . . . .
文字の表記規則 . . . . . . . . . . . . . .
アイコンの表記規則 . . . . . . . . . . . .
コメントのアイコン . . . . . . . . . . .
機能、製品、およびプラットフォームのアイコン
規格準拠のアイコン . . . . . . . . . . .
サンプル コードの表記規則 . . . . . . . . .
. .
.
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 序7
. 序7
. 序8
. 序8
. 序8
. 序9
. 序 10
関連マニュアル . . . . . . . . . . . . . . . .
オンライン マニュアル . . . . . . . . . . . .
ペーパー マニュアル . . . . . . . . . . . . .
オンライン ヘルプ . . . . . . . . . . . . . .
エラー メッセージ ファイル . . . . . . . . . .
ドキュメント ノート、リリース ノート、マシン ノート
参考文献 . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
.
. .
.
. . 序 14
業界標準への準拠
.
. .
.
. .
. .
.
. .
.
. .
序 10
序 11
序 11
序 11
序 11
序 12
序 14
序 2 Informix Guide to Database Design and Implementation
序の概要
この序では、このマニュアルにある情報の概要を説明し、使用される表記規則を示
します。
このマニュアルについて
このマニュアルは、Informix データベースの設計、実装、管理に役立つ情報を提供
します。具体的には、データベース設計のさまざまなアプローチを示すデータ モデ
ルについて説明し、SQL (Structured Query Language : 構造化問合せ言語 ) を使用し
てデータベースを実装および管理する方法について示します。
このマニュアルのほかにも Informix 製品による SQL 実装について説明しているマ
ニュアルがあります。SQL と SPL (Stored Procedure Language : ストアド プロシ
ジャ言語 ) の基本的なルーチンおよび高度なルーチンを使用して、データベースの
データにアクセスし、操作する方法については、
『Informix Guide to SQL: Tutorial』
を参照してください。SQL および SPL の全構文の説明については、『Informix
Guide to SQL: Syntax』を参照してください。SQL 文以外で SQL 文に関わる情報に
ついては、
『Informix Guide to SQL: Reference』を参照してください。
対象ユーザ
このマニュアルは、以下のユーザを対象としています。
■
データベース管理者
■
データベース サーバ管理者
■
データベース アプリケーション プログラマ
このマニュアルは、ユーザが以下の知識、または経験を持っていることを前提とし
ています。
■
コンピュータ、オペレーティング システム、およびオペレーティング シ
ステムが提供するユーティリティの、実際的な知識
序 3
必要なソフトウェア
■
リレーショナル データベース操作の経験、またはデータベースの概念の理
解
■
コンピュータ プログラミングの経験
リレーショナル データベース、SQL、またはオペレーティング システムの経験が限
られている場合、
『Getting Started』の参考文献の一覧を参照してください。
必要なソフトウェア
このマニュアルは、データベース サーバが、以下のいずれかであることを前提とし
ています。
■
Informix Extended Parallel Server, Version 8.3
■
Informix Dynamic Server 2000, Version 9.2
ロケールについて
Informix 製品は、多くの言語、地域特有の情報、およびコード セットをサポートし
ます。地域固有のすべての情報は、GLS (Global Language Support : 広域言語サポー
ト ) ロケールと呼ばれる 1 つの環境にまとめられています。
このマニュアルは、U.S. 8859-1 English ロケールというデフォルトのロケールを使
用します。UNIX プラットフォームのデフォルトのロケールは en_us.8859-1 (ISO
8859-1) で、Windows NT プラットフォームのデフォルトのロケールは en_us.1252
(Microsoft 1252) です。このロケールは、日付、時刻、および通貨に対する米国英語
の表記規則をサポートします。また、このロケールは、ASCII コード セット、およ
び é、è、ñ などの 8 ビット文字を含む ISO 8859-1 コード セット、または Microsoft
1252 コード セットをサポートします。
データ、または SQL 識別子でデフォルト以外の文字を使用する場合、または文字
データをデフォルト以外の順序で照合する場合、適切なロケールを指定する必要が
あります。
データ、または SQL 識別子でデフォルト以外の文字を使用する場合、または文字
データをデフォルト以外の順序で照合する場合、適切なロケールを指定する必要が
あります。
デモンストレーション データベース
Informix データベース サーバ製品に付属する DB-Access には、以下のデモンスト
レーション用のデータベースが含まれます。
序
4 Informix Guide to Database Design and Implementation
新機能
■
stores_demo データベースでは、架空のスポーツ用品卸し売り業者の例を
使用して、関係スキーマについて説明します。Informix のマニュアルには、
stores_demo デモンストレーション データベースに基づく多くの例が含ま
れています。
XPS
■
sales_demo データベースは、データ ウェアハウス アプリケーションの次
元スキーマを説明します。次元データ モデルという概念については、第
10 章「次元データ モデルの作成」を参照してください。♦
IDS
■
superstores_demo データベースでは、オブジェクト関係スキーマについて
説明します。この superstores_demo データベースには、拡張データ型、
型および表の継承、およびユーザ定義ルーチンについての例が含まれてい
ます。♦
デモンストレーション データベースの作成、および構築の詳細については、
『DB-Access User’s Manual』を参照してください。これらのデータベースの詳細、
および内容の一覧については、
『Informix Guide to SQL: Reference』を参照してくだ
さい。
デモンストレーション データベースをインストールするのに使用するスクリプト
は、UNIX プラットフォームの場合は $INFORMIXDIR/bin ディレクトリに、
Windows プラットフォームの場合は %INFORMIXDIR%¥bin ディレクトリにあり
ます。
新機能
データベース サーバの新機能の一覧は、リリース ノートを参照してください。こ
の節では、このマニュアルに書かれている新しい機能を示します。
バージョン 8.3 で導入された新しい機能
このマニュアルは、Extended Parallel Server Version 8.3 で導入された以下の新しい
SQL の機能について説明します。
■
RANGE フラグメント化
■
広域分離インデックス
バージョン 9.2 で導入された新しい機能
このマニュアルは、Dynamic Server Version 9.2 で導入された新しい機能について
説明します。新しい機能は、以下の 2 つに分類されます。
序 5
バージョン 9.2 で導入された新しい機能
■
■
拡張性の向上
Dynamic Server Version 7.30 から Version 9.2 へ引き継がれた機能
拡張性の向上
このマニュアルは、Dynamic Server Version 9.2 で導入された拡張性の向上に関し
て、以下の項目を説明します。
■
■
SQL に対する一般的な拡張機能 : 行型に対する入れ子ピリオド表現式
スマート ラージ オブジェクトへの拡張機能 :
❑
スマート ラージ オブジェクトのラウンド ロビン フラグメント化
❑
スマート ラージ オブジェクトに対する ALTER TABLE 文
❑
データ型の表記規則 : バイト (BYTE) 型から BLOB 型、およびテキスト
(TEXT) 型から CLOB 型
■
コレクションに対する拡張機能 : 任意式の要素を使用するコレクション コ
ンストラクタ
■
行型に対する拡張機能 :
❑
行型におけるシリアル型
❑
行型に対する GRANT UNDER 文および REVOKE UNDER 文
Dynamic Server バージョン 7.30 から バージョン 9.2 へ引き継がれ
た機能
このマニュアルは、Dynamic Server Version 7.30 で初めてリリースされた機能につ
いても説明します。これらの機能は、以下の 2 つに分類されます。
■
■
序
信頼性、可用性、保守性 :
❑
ALTER FRAGMENT ATTACH 文および ALTER FRAGMENT
DETACH 文に関する拡張機能
❑
In-Place ALTER TABLE MODIFY および IN-PLACE ALTER TABLE
DROP ( 組込み型用 )
アプリケーションの移行 : CREATE VIEW 文における UNION 演算子
6 Informix Guide to Database Design and Implementation
表記規則
表記規則
ここでは、このマニュアルで使用される、以下の表記規則について説明します。表
記規則を覚えておくと、このマニュアル、およびほかのマニュアルの内容を理解す
るのに役に立ちます。
以下のような表記規則があります。
■
文字の表記規則
■
アイコンの表記規則
■
サンプル コードの表記規則
文字の表記規則
このマニュアルは、新しい用語、画面表示、コマンド構文などを表記するのに、以
下の規則を使用します。
表記規則
意味
KEYWORD
プログラミング言語の文中では、主要な要素 ( キーワード )
は、すべて大文字のセリフ フォントで表記されます。
computer
製品が表示する情報、およびユーザが入力する情報は、サン
セリフフォントで表記されます。
♦
この記号は、機能、製品、プラットフォーム、または標準準
拠などに特有の情報の終わりを表します。
➞
この記号は、メニュー項目を表します。たとえば、"[ ツール
]➞[ オプション ] を選択します。" は、[ ツール ] メニューの
[ オプション ] を選択することを意味します。
[]
メニュー、ボックス、ボタン、コマンドなどの、ユーザ イン
ターフェイスを表します。
ヒント : コマンドの入力、または実行の指示がある場合、入力後に Enter キーを押
してください。コマンド以外の文字の入力やほかのキーを押す指示がある場合、
Enter キーを押す必要はありません。
序 7
アイコンの表記規則
アイコンの表記規則
このマニュアルの本文では、いろいろなアイコンが使用されます。ここでは、これ
らのアイコンについて説明します。
コメントのアイコン
コメントのアイコンは、警告、重要な情報、およびヒントを表します。
アイコン
ラベル
説明
警告 :
重要な指示、注意、または情報を表します。
重要 :
説明されている機能、または操作に関する重要な情
報を表します。
ヒント :
説明されている機能の詳細、またはショートカット
を表します。
機能、製品、およびプラットフォームのアイコン
機能、製品、およびプラットフォームのアイコンは、機能、製品、またはプラット
フォームに特有な情報を表します。
アイコン
GLS
IDS
説明
Informix GLS (Global Language Support : 広域言語サポー
ト ) に関連する情報を表します。
Informix Dynamic Server 2000 に特有な情報を表します。
(1 / 2)
序
8 Informix Guide to Database Design and Implementation
アイコンの表記規則
アイコン
UNIX
WIN NT
XPS
説明
UNIX プラットフォームに特有な情報を表します。
Windows NT 環境に特有な情報を表します。
Informix Extended Parallel Server に特有な情報または構
文を表します。
(2 / 2)
これらのアイコンは、セクション内のパラグラフ、またはセクション全体に適用さ
れます。見出しの前にアイコンがある場合、アイコンが示す機能、製品、またはプ
ラットフォームに関連する情報は、同じレベル、または上位のレベルの異なる見出
しが現れるまで適用されます。♦ は、パラグラフ内の機能、製品、またはプラット
フォームに特有な情報の終わりを表します。
規格準拠のアイコン
規格準拠のアイコンは、標準準拠に関するガイドラインを含むパラグラフを表しま
す。
アイコン
ANSI
説明
ANSI 標準準拠データベースに固有な情報を表します。
これらのアイコンは、セクション内のパラグラフ、またはセクション全体に適用さ
れます。見出しの前にアイコンがある場合、アイコンが示す機能、製品、またはプ
ラットフォームに関連する情報は、同じレベル、または上位のレベルの異なる見出
しが現れるまで適用されます。♦ は、パラグラフ内の機能、製品、またはプラット
フォームに特有な情報の終わりを表します。
序 9
サンプル コードの表記規則
サンプル コードの表記規則
このマニュアルは、SQL コードの例を使用します。特に説明がない限り、コード
は、特定の Informix アプリケーション開発ツール専用ではありません。例の中に含
まれる SQL 文は、セミコロン (;) で区切られません。たとえば、以下のようなコー
ドの例が使用されます。
CONNECT TO stores_demo
...
DELETE FROM customer
WHERE customer_num = 121
...
COMMIT WORK
DISCONNECT CURRENT
この SQL コードをある製品で使用する場合、製品の構文規則を適用する必要があり
ます。たとえば、DB-Access を使用する場合、文と文の間はセミコロン (;) で区切る
必要があります。SQL API を使用する場合、EXEC SQL を構文の最初に指定し、構
文の最後にセミコロン (;)、または適切な分離記号を指定する必要があります。
ヒント : 前述のコードの例では、アプリケーション全体では必要でも、ここでは説
明する必要のないコードは、ピリオド (.) で示されています。
特定のアプリケーション開発ツール、または SQL API の SQL 文の詳細については、
製品に付属するマニュアルを参照してください。
関連マニュアル
補足情報については、以下のマニュアルを参照してください。
序
10
■
オンライン マニュアル
■
ペーパー マニュアル
■
エラー メッセージ ファイル
■
ドキュメント ノート、リリース ノート、マシン ノート
■
参考文献
Informix Guide to Database Design and Implementation
オンライン マニュアル
オンライン マニュアル
Informix 製品には、電子フォーマットの Informix マニュアルを含む、Answers
OnLine CD-ROM が付属しています。CD-ROM からマニュアルをインストールした
り、直接マニュアルにアクセスすることができます。オンライン マニュアルのイン
ストール、読取り、および印刷の詳細については、Answers OnLine に付属のイン
ストール説明書を参照してください。
オンライン マニュアルは、以下の Web サイトでも入手できます。
www.informix.com/answers
ペーパー マニュアル
Informix Dynamic Server のマニュアル セットは、Informix Dynamic Server、SQL
の実装、関連するアプリケーション プログラミング インターフェイスについて説
明します。また、Informix Dynamic Server キットには、各キットのコンポーネント
をサポートするマニュアルが含まれます。
Informix Dynamic Server マニュアル セットの各マニュアル、および Informix
『Getting Started with
Dynamic Server キットのマニュアルの概要については、
Informix Dynamic Server 2000』を参照してください。
WIN NT
オンライン ヘルプ
それぞれの GUI (Graphical User Interface : グラフィカル ユーザ インターフェイス )
には、その GUI についての情報および機能を表示するオンライン ヘルプが提供さ
れています。オンライン ヘルプを参照するには、その GUI 上でヘルプ機能を利用
します。
エラー メッセージ ファイル
Informix ソフトウェア製品は、Informix エラー メッセージ、およびエラーの対処方
法を含む ASCII ファイルを提供します。
序
11
ドキュメント ノート、リリース ノート、マシン ノート
UNIX
UNIX 環境でエラー メッセージ、および対処方法を表示するには、以下のコマンド
を使用します。
コマンド
説明
finderr
エラー メッセージをオンラインで表示します。
rofferr
エラー メッセージを印刷用にフォーマットします。
♦
WIN NT
Windows 環境でエラー メッセージ、および対処方法を表示するには、Informix
Find Error ユーティリティを使用します。このユーティリティを表示するには、タ
スク バーで、[ スタート ] ➞ [ プログラム ] ➞[Informix] を選択します。♦
これらのユーティリティの使用方法については、Answers OnLine を参照してくだ
さい。エラー メッセージおよび対処方法のリストについては、Answers OnLine で
HTML 形式のものも提供しています。
ドキュメント ノート、リリース ノート、マシン ノート
ペーパー マニュアル以外に、以下のオンライン ファイルが、このマニュアルの補
足情報を提供します。データベース サーバを使用する前に、以下のファイルの内容
を理解してください。これらのファイルには、アプリケーション、およびパフォー
マンスに関する重要な情報が含まれています。
序
12
Informix Guide to Database Design and Implementation
ドキュメント ノート、リリース ノート、マシン ノート
UNIX
UNIX のプラットフォームでは、以下のファイルが、
$INFORMIXDIR/release/en_us/0333 ディレクトリにあります。ファイル名にある
x.y は、使用するデータベース サーバのバージョン番号に置き換えて読んでくださ
い。
オンライン ファイル
内容
DDIDOC_x.y
これはこのマニュアルのバージョン用の documentation
notes ファイルで、マニュアルに含まれていない機能、ま
たはマニュアルが出版されてから変更された機能を説明
します。
SERVERS_x.y
これはリリース ノート ファイルで、Informix 製品の以前
の機能との違い、およびその違いが現在の製品に及ぼす
影響を説明します。このファイルには、問題点、および
対処方法も含まれます。
IDS_x.y または
XPS_x.y
これはマシン ノート ファイルで、コンピュータで
Informix 製品を設定、および使用するのに必要な作業を
説明します。マシン ノートには、製品と同じ名前が付い
ています。
♦
WIN NT
以下のファイルが、[Informix] フォルダにあります。このフォルダを表示するには、
タスクバーで [ スタート ] ➞ [ プログラム ] ➞ [Informix] を選択してください。
プログラム グループの項目
説明
Documentation Notes
これはドキュメント ノートで、マニュアルに対す
る追加項目、または削除された項目を説明します。
また、マニュアルに含まれていない機能、または
マニュアルが出版されてから変更された機能につ
いても説明します。
Release Notes
これはリリース ノートで、Informix 製品の以前の機
能との違い、およびその違いが現在の製品に及ぼ
す影響を説明します。このファイルには、問題点、
および対処方法も含まれます。
マシン ノートは、Windows 環境には適用されません。♦
序
13
参考文献
参考文献
データベース サーバ、およびオペレーティング システム プラットフォームの概要
を説明する文献の一覧は、
『Getting Started』を参照してください。
業界標準への準拠
SQL に関する業界標準は、ANSI (American National Standards Institute : 米国規格
協会 ) によって規格化されています。Informix の SQL ベースの製品は、ANSI
X3.135-1992 として公開された SQL-92 Entry Level に準拠しています。SQL-92 は、
ISO 9075:1992 と同一です。また、Informix データベース サーバの多くの機能は、
SQL-92 Intermediate Level と Full Level、および X/Open SQL CAE (common
applications environment : 共通アプリケーション環境 ) 標準に準拠しています。
序
14
Informix Guide to Database Design and Implementation
データベースの設計
リレーショナルデータ モデルの作成
データ型の選択
リレーショナルデータモデルの実装
セクション I
データベース設計と実装の
基礎
第1章
データベースの設計
この章の概要 . .
.
. .
.
. .
. .
.
. .
.
. .
. .
.
. .
.
. .
1-3
データベースのデータ モデルの選択 . .
.
. .
.
. .
. .
.
. .
.
. .
1-3
. . . . . . . .
. . . . . . . .
. . . . . . . .
1-4
1-5
1-5
ANSI 標準準拠データベースの使用法 . . . . . . .
データベースの ANSI 標準準拠への設定 . . . . .
既存のデータベースが ANSI 標準準拠であるかの判断
ANSI 標準準拠のデータベースと
ANSI 標準準拠でないデータベースとの相違点 .
トランザクション . . . . . . . . . . .
トランザクション ログ機能 . . . . . . . .
所有者名の指定 . . . . . . . . . . . .
オブジェクトへのアクセス権 . . . . . . .
デフォルトの排他レベル . . . . . . . . .
文字データ型 . . . . . . . . . . . . .
10 進数データ型 . . . . . . . . . . . .
エスケープ文字 . . . . . . . . . . . .
カーソルの動作 . . . . . . . . . . . .
SQL 通信領域の SQLCODE フィールド . . . .
ANSI 標準準拠データベースで使用できる SQL 文
シノニムの動作 . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1-6
1-6
1-7
1-7
1-7
1-8
1-8
1-9
1-9
1-9
1-9
1-10
1-10
使用するデータベース専用の言語環境の使用法 .
. .
.
. .
.
. .
1-10
.
. .
1-2
Informix Guide to Database Design and Implementation
この章の概要
この章では、データベース管理者 (DBA) がデータベースを効果的に設計するために
理解する必要のある問題について説明します。次のトピックについて説明します。
■
データベースのデータ モデルの選択
■
ANSI 標準準拠データベースの使用法
■
使用するデータベース専用の言語環境の使用法
データベースのデータ モデルの選択
Informix 製品を使用してデータベースを作成する前に、どのようなデータ モデルを
使用してデータベースを設計するかを決める必要があります。このマニュアルで
は、次のデータベース モデルについて説明します。
■
リレーショナル データ モデル
このデータ モデルは、OLTP (On-line Transaction Processing : オンライン
トランザクション処理 ) のデータベース設計の代表的なものです。OLTP
は、非常に小さな大量のトランザクションを 1 つも失うことなく処理する
ことを目的にしています。OLTP データベースは日常的な業務上の操作要
件に対応するように設計されており、データベースの性能はそのような操
作要件に合わせて調整されています。このマニュアルのセクション I
「データベース設計と実装の基礎」では、OLTP 用のリレーショナル デー
タ モデルを作成して実装する方法について説明しています。
データベースの設計
1-3
ANSI 標準準拠データベースの使用法
IDS
■
オブジェクト リレーショナル データ モデル
オブジェクト リレーショナル データベースを作成するための正式なモデ
ルはありません。オブジェクト リレーショナル データベースは基本的な
リレーショナル設計の原理を採用していますが、リレーショナル データ
ベースの機能を拡張するための拡張データ型、ユーザ定義ルーチン、ユー
ザ定義キャスト、およびユーザ定義集合などを含んでいます。このマニュ
アルのセクション III「オブジェクト リレーショナル データベース」では、
Dynamic Server の拡張機能を使用してデータベースに格納できるデータの
種類を拡張し、データの編成およびアクセスをより柔軟に行う方法につい
て説明しています。♦
■
次元データ モデル
このデータ モデルは、通常、一種のデータ ウェアハウスであるデータ
マートを作成するために使用されます。データ ウェアハウジング環境で
は、データベースはデータの抽出と分析のために最適化されています。こ
のような情報処理の種類を、OLAP (On-line Analytical Processing : オンラ
イン分析型処理 )、または意思決定支援処理といいます。このマニュアル
のセクション IV「次元データベース」では、OLAP 用の次元データ モデ
ルを作成して実装する方法について説明しています。
データベース設計に使用するデータ モデルだけでなく、次の項目についても決定す
る必要があります。これらの項目次第で、データベースを使用するアプリケーショ
ンで利用できる機能が決まります。
■
データベースを収容するのは、次のどちらのデータベース サーバか。
❑
Informix Dynamic Server 2000
❑
Informix Extended Parallel Server
■
データベースは ANSI 標準に準拠する必要があるか。
■
データベースでは、英語以外の言語の文字を表の中で使用するか。
この章では、これらの項目について説明し、これらの項目がデータベースに与える
影響についてまとめています。
ANSI 標準準拠データベースの使用法
CREATE DATABASE 文でキーワード MODE ANSI を使用すると、ANSI 標準準拠
データベースが作成されます。ANSI 標準準拠のデータベースと ANSI 標準準拠で
ないデータベースとの相違点については、1-6 ページを参照してください。
ANSI 標準準拠データデースを作成する理由を次に示します。
1-4
Informix Guide to Database Design and Implementation
データベースの ANSI 標準準拠への設定
■
オブジェクトへのアクセス権とアクセス
ANSI 規格では、表やシノニムなどのオブジェクトへのアクセス権とアク
セスについて規定しています。ただし、ANSI 標準準拠データベースを作
成することで、そのデータベースが ANSI/ISO SQL-92 標準準拠になると
は限りません。ANSI データベース上で CREATE INDEX 文の実行などの
ANSI 標準でない処理を行った場合は、警告を受け取りますが、アプリ
ケーション プログラムがその処理を禁止することはありません。
■
名前排他設定
ANSI 表命名規則により、複数のユーザが 1 つのデータベースで名前の不
一致を心配せずに表を作成できます。
IDS
■
トランザクション排他設定
■
データ復旧
ANSI 標準準拠データベースでは、バッファなしログと自動トランザク
ションが Dynamic Server に対して強制されます。♦
データベースの ANSI 標準準拠への設定
キーワード MODE ANSI を指定してデータベースを作成すると、そのデータベース
は ANSI 標準準拠であると考えられます。ANSI 標準準拠データベースでは、ロギ
ング モードをバッファ付きログに変更することや、ログ機能をオフにすることはで
きません。
既存のデータベースが ANSI 標準準拠であるかの判断
データベースが ANSI 標準準拠かどうかを判断する方法を次に示します。
■
sysmaster データベースから次の文を実行して、既存のデータベースが
ANSI 標準準拠であるかを判断できます。
SELECT is_ansi FROM sysdatabases
WHERE name = '< データベース名 >'
ANSI 標準準拠データベースの場合は値 1 が問合せから戻され、ANSI 標
準準拠でないデータベースの場合は 0 が戻されます。
■
Informix ESQL/C などの SQL API を使用している場合は、SQL 通信領域
(SQLCA) をテストできます。特に、DATABASE 文または CONNECT 文
を使用して ANSI 標準準拠データベースを開いた直後に、SQLCAWARN
構造体の 3 番目の要素には W が含まれます。SQLCA については、
『Informix Guide to SQL: Tutorial』または SQL API のマニュアルを参照し
てください。
データベースの設計
1-5
ANSI 標準準拠のデータベースと ANSI 標準準拠でないデータベースとの相違点
IDS
■
デフォルトのデータベース サーバが Dynamic Server の場合、ON-Monitor
ユーティリティを使用すると、そのサーバ上にあるすべてのデータベース
をリストできます。[Status] メニューの [Databases] オプションを使用する
とそのリストが表示されます。ANSI 標準準拠データベースは、リストの
ログ状態列に U* と表記されています。♦
ANSI 標準準拠のデータベースと
ANSI 標準準拠でないデータベースとの相違点
作成時にキーワード MODE ANSI を使用して ANSI 標準準拠に設定したデータベー
スと ANSI 標準準拠でないデータベースとの間には、次のような点に違いがありま
す。
■
トランザクション
■
トランザクション ログ機能
■
所有者名の指定
■
オブジェクトへのアクセス権
■
デフォルトの排他レベル
■
文字データ型
■
10 進数データ型
■
エスケープ文字
■
カーソルの動作
■
SQLCA の SQLCODE
■
使用できる SQL 文
■
シノニムの動作
トランザクション
ANSI 標準準拠データベースで使用するすべての SQL 文は、自動的にトランザク
ションに含まれます。ANSI 標準準拠でないデータベースでは、トランザクション
処理は省略可能です。
ANSI 標準準拠でないデータベースでは、1 つのトランザクションは BEGIN WORK
文で始まり、COMMIT WORK 文または ROLLBACK WORK 文で終わります。しか
し、ANSI 標準準拠データベースでは、すべての文が自動的にトランザクションに
含まれるので、BEGIN WORK 文は不要です。トランザクションの終わりを
COMMIT WORK 文または ROLLBACK WORK 文で示すだけでかまいません。
1-6
Informix Guide to Database Design and Implementation
ANSI 標準準拠のデータベースと ANSI 標準準拠でないデータベースとの相違点
トランザクションの詳細については、第 4 章「リレーショナルデータモデルの実
装」および『Informix Guide to SQL: Tutorial』を参照してください。
トランザクション ログ機能
Dynamic Server および Extended Parallel Server 上の ANSI 標準準拠データベースは
すべてバッファなしトランザクション ログ機能を使用して実行されます。
IDS
ANSI 標準準拠でないデータベースは、バッファ付きログまたはバッファなしログ
のどちらかを使用して実行できます。バッファなしログではより広範囲なデータ復
旧を利用でき、バッファ付きログではより優れた性能を利用できます。♦
XPS
ANSI 標準準拠でないデータベースでは、バッファなしログしか使用できません。
バッファなしログでは、より広範囲なデータ復旧を利用できます。♦
詳細については、
『Informix Guide to SQL: Syntax』の CREATE DATABASE 文の説
明を参照してください。
所有者名の指定
ANSI 標準準拠データベースでは、所有者名の指定が強制されます。SQL 文でオブ
ジェクト名を指定する場合、ANSI 標準では、そのオブジェクトの所有者でなけれ
ば、名前にプレフィックス < 所有者 >. を付けることが要求されます。< 所有者 >
と < 名前 > の組合せは、そのデータベース内で一意である必要があります。そのオ
ブジェクトの所有者であれば、データベース サーバはそのユーザ名をデフォルトと
して提供します。
ANSI 標準準拠でないデータベースでは、所有者名の指定は強制されません。
詳細については、
『Informix Guide to SQL: Syntax』の所有者名セグメントを参照し
てください。
オブジェクトへのアクセス権
ANSI 標準準拠データベースと ANSI 標準準拠でないデータベースでは、データ
ベース内で表を作成した場合に、デフォルトによって表レベルのアクセス権を付与
されるユーザが異なります。ANSI 標準の規定では、データベース サーバは表レベ
ルのアクセス権を表の所有者だけに (DBA と異なる場合は DBA にも ) 付与します。
しかし、ANSI 標準準拠でないデータベースでは、アクセス権は public に付与され
ます。さらに、Informix では、ANSI 標準にはない表レベルの 2 つのアクセス権、
Alter と Index を提供します。
データベースの設計
1-7
ANSI 標準準拠のデータベースと ANSI 標準準拠でないデータベースとの相違点
表レベルのアクセス権を付与する方法についての詳細は、このマニュアルの第 8 章
「Dynamic Server による型継承と表継承」、および『Informix Guide to SQL: Syntax』
の GRANT 文の説明を参照してください。
ユーザ定義ルーチンを実行するには、そのルーチンの Execute アクセス権を持って
いる必要があります。ANSI 標準準拠データベースで所有者アクセス権付きルーチ
ンを作成すると、そのユーザ定義ルーチンの所有者だけが Execute アクセス権を持
ちます。ANSI 標準準拠でないデータベースで所有者アクセス権付きルーチンを作
成すると、データベース サーバはデフォルトにより public に Execute アクセス権を
付与します。
SPL ルーチンのアクセス権の詳細については、このマニュアルの第 6 章「データ
ベース サーバのアクセス権の付与と制限」および『Informix Guide to SQL:
Tutorial』を参照してください。
デフォルトの排他レベル
データベースの排他レベルでは、使用しているプログラムがほかのプログラムの並
行動作から分離される程度を規定します。すべての ANSI 標準準拠データベースに
対するデフォルトの排他レベルは、繰返し可能読込みです。ログを使用する ANSI
標準準拠でないデータベースのデフォルトの排他レベルは、確定読込みです。ログ
を使用しない ANSI 標準準拠でないデータベースのデフォルトの排他レベルは、非
確定読込みです。
排他レベルについては、
『Informix Guide to SQL: Tutorial』
、および『Informix
Guide to SQL: Syntax』の SET TRANSACTION 文と SET ISOLATION 文の説明を参
照してください。
文字データ型
ANSI 標準準拠でないデータベースでは、規定のフィールド長より長い文字列が 文
字 (CHAR) 型、文字 (CHARACTER) 型、各国語文字 (NCHAR) 型、各国語可変長文
字 (NVARCHAR) 型、可変長文字 (VARCHAR) 型、可変長文字 (CHARACTER
VARYING) 型などの文字 (CHAR) 型フィールドに入力されてもエラーは発生しませ
ん。データベース サーバはエラー メッセージを生成することなく、余分な文字を
切り捨てます。したがって、挿入または更新された値が n バイトを超過していて
も、CHAR(n) 列または変数に、データの意味整合性が強制的に適用されることは
ありません。
ANSI 標準準拠データベースでは、規定のフィールド幅より長い文字列が文字
(CHAR) 型、文字 (CHARACTER) 型、可変長文字 (VARCHAR) 型、各国語文字
(NCHAR) 型、各国語可変長文字 (NVARCHAR) 型、可変長文字 (CHARACTER
VARYING) 型などの文字 (CHAR) 型フィールドに入力されると、エラーが発生しま
す。
1-8
Informix Guide to Database Design and Implementation
ANSI 標準準拠のデータベースと ANSI 標準準拠でないデータベースとの相違点
10 進数データ型
ANSI 標準準拠データベースでは、DECIMAL データ型に小数点以下桁数は使用さ
れません。小数点以下桁数は 0 と見なすことができます。
エスケープ文字
ANSI 標準準拠データベースでは、エスケープ文字はパーセント (%) とアンダスコ
ア (_) だけをエスケープできます。エスケープ文字を使用して、そのエスケープ文
字自体をエスケープすることもできます。エスケープ文字の詳細については、
『Informix Guide to SQL: Syntax』の条件セグメントを参照してください。
カーソルの動作
データベースが ANSI 準拠でない場合、SELECT 文の UPDATE カーソルを宣言する
ときに、キーワード FOR UPDATE を使用する必要があります。また、SELECT 文
は次の条件を満たす必要があります。
■
単一の表から選択する。
■
集計関数を含まない。
■
DISTINCT、GROUP BY、INTO TEMP、ORDER BY、UNION、UNIQUE
の節やキーワードを含まない。
ANSI 標準準拠データベースでは、カーソルを宣言するときにキーワード FOR
UPDATE を明示的に使用する必要はありません。ANSI 標準準拠データベースで
は、すべてのカーソルは、前掲の箇条書きの制約を満たす場合、潜在的に
UPDATE カーソルです。DECLARE 文でキーワード FOR READ ONLY を指定する
と、カーソルを読取り専用に指定できます。
詳細については、
『Informix Guide to SQL: Syntax』の DECLARE 文の説明を参照し
てください。
SQL 通信領域の SQLCODE フィールド
DELETE、INSERT INTO < 表名 > SELECT、SELECT...INTO TEMP、UPDATE のい
ずれの文の探索条件も満たす行がない場合、データベース サーバは、データベース
が ANSI 標準準拠のときは SQLCODE を 100 に設定し、データベースが標準準拠で
ないときは SQLCODE を 0 に設定します。
詳細については、
『Informix Guide to SQL: Tutorial』の SQLCODE の説明を参照し
てください。
データベースの設計
1-9
使用するデータベース専用の言語環境の使用法
ANSI 標準準拠データベースで使用できる SQL 文
アプリケーションで ANSI 標準準拠データベースとともに使用することが許される
SQL 文には、制限がありません。ANSI 標準準拠のデータベースでも ANSI 標準準
拠でないデータベースでも、Informix の拡張機能を使用できます。
シノニムの動作
ANSI 標準準拠データベースでは、シノニムは常にプライベートです。ANSI 標準準
拠データベースで、パブリック シノニムを作成しようとしたり、キーワード
PRIVATE を使用してプライベート シノニムを示そうとしたりすると、エラーが発
生します。
GLS
使用するデータベース専用の言語環境の使用法
GLS (Global Language Support : 広域言語サポート ) を使用すると、Informix バー
ジョン 7.2 以降の製品では、さまざまなロケールが使用できます。GLS ロケール
は、特定の言語または文化向けの規約を定義している環境です。
ヒント : Version 7.2 以降の製品では、NLS (Native Language Support : 各国語サ
ポート )、および ALS (Asian Language Support : アジア言語サポート ) が GLS に置
き換えられています。
デフォルトにより、Informix 製品は米国英語 ASCII コード セットを使用して、
ASCII 照合順序の米国英語環境で実行されます。次の機能のいずれかを使用する場
合は、デフォルトでないロケールに対応するように環境を設定します。
■
データに英語以外の文字
■
ユーザ指定のオブジェクト名に英語以外の文字
■
ASCII コード セット以外のソート順序および照合順序に対する準拠
■
辞書や電話帳などで使用される、地域固有の照合順序およびソート順序
GLS 環境変数の説明、および米国英語でない環境の実装方法の詳細については、
『Informix Guide to GLS Functionality』を参照してください。
1-10
Informix Guide to Database Design and Implementation
第2章
リレーショナルデータ モデ
ルの作成
この章の概要 . .
.
. .
.
. .
. .
.
. .
.
. .
. .
.
. .
.
. .
2-3
データ モデルを作成する理由
. .
. .
.
. .
.
. .
. .
.
. .
.
. .
2-3
.
. .
.
. .
.
. .
. .
.
. .
.
. .
2-4
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
実体 - 関係データ モデルの概要
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2-4
2-4
2-5
2-5
2-6
2-8
2-8
2-9
2-9
2-9
2-10
2-15
2-15
2-15
2-16
2-16
データ オブジェクトの図式化 . . . . . . . . . . . . . . . . . .
E-R ダイヤグラムの読み方 . . . . . . . . . . . . . . . . . .
住所録の例 . . . . . . . . . . . . . . . . . . . . . . .
2-17
2-18
2-18
E-R データ オブジェクトの関係構造体への変換
表、行、列の定義 . . . . . . . . .
列への制約の適用 . . . . . . .
ドメインの特性 . . . . . . . .
表のキーの決定 . . . . . . . . . .
主キー . . . . . . . . . . .
外部キー ( 結合列 ) . . . . . . .
住所録のダイヤグラムへのキーの追加
2-20
2-20
2-21
2-21
2-22
2-22
2-24
2-24
主なデータ オブジェクトの識別と定義
実体の識別 . . . . . . . .
実体の選択 . . . . . . .
実体リスト . . . . . . .
住所録の例 . . . . . . .
実体の図式化 . . . . . .
関係の定義 . . . . . . . .
接続性 . . . . . . . .
存在の依存性 . . . . . .
濃度 . . . . . . . . .
関係の発見 . . . . . . .
関係の図式化 . . . . . .
属性の識別 . . . . . . . .
実体の属性の選択 . . . .
属性の列挙 . . . . . . .
実体のオカレンスについて .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
関係の解決 . . . . . . . .
m:n 関係の解決 . . . .
その他の特別な関係の解決
データ モデルの正規化 .
第 1 正規形 . . . .
第 2 正規形 . . . .
第 3 正規形 . . . .
正規化ルールのまとめ
2-2
.
.
.
.
.
.
.
.
. .
. .
. .
.
.
.
. .
. .
. .
.
.
.
2-25
2-25
2-27
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
2-27
2-28
2-30
2-30
2-30
Informix Guide to Database Design and Implementation
. .
. .
. .
.
.
.
. .
. .
. .
.
.
.
. .
. .
. .
. .
. .
. .
この章の概要
リレーショナル データベースを作成する最初の手順は、データ モデルを作成する
ことです。データ モデルの作成とは、格納する必要のあるデータを正確かつ完全に
定義することです。この章では、データをモデル化する方法の概要を説明します。
第 3 章「データ型の選択」では、データ モデルを完成するために定義する列固有の
プロパティについて説明します。第 4 章「リレーショナルデータモデルの実装」で
は、この章で説明するデータ モデルの実装方法について説明します。
この章の内容を理解するには、SQL とリレーショナル データベース理論に関する
基礎知識が必要です。
データ モデルを作成する理由
データベースを構成するデータの型や必要な編成方法について、すでに何らかの構
想を持っているとします。この情報が、データ モデルを作成する出発点です。ある
種の形式化された表記法を使用してデータ モデルを作成する場合、設計するときに
次の 2 つの点で役に立ちます。
■
データ モデルについて徹底的に考えることができる。
通常、直感的なモデルには、あいまいな点や検討が済んでいない仮定が含
まれています。設計を形式化した場合は、これらの仮定が見つかります。
■
他の人でもその設計が理解しやすくなる。
形式化された記述はモデルを明確にするので、他の人が同じ形式でコメン
トや意見を述べることができます。
リレーショナルデータ モデルの作成
2-3
実体 - 関係データ モデルの概要
実体 - 関係データ モデルの概要
データのモデル化の形式化された方法には、複数の方法が存在します。それらのど
の方法を使用しても完全で正確なモデル化ができます。何らかの方法を知っている
場合は、ぜひそれを使用してください。
この章では、E-R (Entity-Relationship : 実体 - 関係 ) データ モデルの概要を説明しま
す。これは、Informix トレーニング コースで取り上げているモデル化の方法です。
E-R データ モデル化の方法では次の手順を使用します。
1.
主なデータベース オブジェクト ( 実体、関係、および属性 ) を識別し定義
する。
2.
E-R アプローチを使用して、データ オブジェクトを図式化する。
3.
E-R データ オブジェクトを関係型構造に変換する。
4.
論理データ モデルを解決する。
5.
論理データ モデルを正規化する。
この章では、手順 1 から 5 までを説明します。論理データ モデルを物理スキーマに
変換する最終的な手順については、第 4 章を参照してください。
データ モデル化の最終的な結果は、個人用住所録の最終的な表のセットを示す 2-29
ページの 図 2-21 と同様なダイヤグラムでエンコードされた、完全に定義された
データベース設計となります。この個人用住所録は、この章で例として作成しま
す。これは、1 つの章で完全に作成できるほどの小さいサイズであり、かつ全体の
方法を示すには十分大きなサイズなので、デモンストレーション データベースでな
くこの住所録を使用します。
主なデータ オブジェクトの識別と定義
データ モデルを作成するには、最初に、主なデータ オブジェクトを識別し、定義
します。主なデータ オブジェクトとは、実体、関係および属性です。
実体の識別
実体とは、ユーザにとって最も重要であるデータ オブジェクトです。通常、実体は
データベースに記録される人、場所、物、事柄などです。データ モデルを言語とし
た場合、実体は名詞に相当します。使用しているソフトウェアに備わっているデモ
ンストレーション データベースには、次の実体が含まれています。customer、
orders、items、stock、catalog、cust_calls、call_type、manufact、および state。
2-4
Informix Guide to Database Design and Implementation
実体の識別
実体の選択
データベースについてすぐにいくつかの実体を列挙できるはずです。識別可能なす
べての実体の予備的なリストを作成します。データベースのユーザとなる可能性の
ある人に、データベースに記録すべき事柄について意見を聞くためインタビューを
行います。実体ごとに、
「1 つの名前に少なくとも 1 つのアドレスを関連付ける」な
どの基本的な特性を決定します。実体に関して行った決定はすべて、ビジネス ルー
ルとなります。この章では、2-6 ページの住所録の例で、そのビジネス ルールをい
くつか示します。
その後、データ モデルを正規化して、実体のいくつかを拡張したり、ほかのデータ
オブジェクトにしたりすることができます。詳細については、2-27 ページの「デー
タ モデルの正規化」を参照してください。
実体リスト
実体リストが完成したと思われる場合は、そのリストを調べて各実体が次の特性を
持っていることを確認してください。
■
重要である。
データベースのユーザにとって重要で、かつ時間と費用をかけてコン
ピュータで処理するだけの価値がある実体のみを取り上げます。
■
一般性がある。
個々の実体ではなく、類型のみを取り上げます。たとえば、交響曲は実体
ですがベートーベンの第 5 交響曲は実体のインスタンスまたは実体のオカ
レンスです。
■
基本的である。
その実体の説明にほかの実体を必要とせず、独立して存在するもののみを
実体として取り上げます。それを説明するのに何か特徴や記述といったも
のがほかに必要なものは、独立した実体ではありません。たとえば、部品
番号は部品と呼ばれる基本的実体の 1 つの特徴です。また、他の実体から
導出できるものも、実体として取り上げないでください。たとえば、合計
や平均などの量は SELECT 文で式を使用すれば計算できます。
■
単一のものである。
命名した各実体がそれぞれ単一のクラスを表しているかを確認してくださ
い。1 つの実体を、それぞれ固有の特徴を持つ下位のカテゴリに分類する
ことはできません。2-6 ページの住所録の例では、電話番号は明らかに簡
単な実体であり、それぞれが異なる特徴を持つ 3 つのカテゴリで実際に構
成されています。
リレーショナルデータ モデルの作成
2-5
実体の識別
これらの条件に合う実体を選ぶことは、決して簡単ではなく、機械的に選ぶことは
できません。最善の選択を見つけるには、データベースに格納したいデータの性質
について慎重に検討する必要があります。このような検討を行うことによって、適
切なデータ モデルを作成することができます。次の節で、住所録の例を詳細に説明
します。
住所録の例
例として、個人用の住所録のためのデータベースを作成することを考えてみます。
このデータベースのモデルに格納すべき情報は、データベースのユーザが必要とす
る人と組織の名前、住所、電話番号です。
最初に実体を定義します。住所録のページをよく調べて、どんな実体があるかを識
別します。図 2-1 は、住所録のページの例です。
図 2-1
住所録の一部
NAME
PHONE
NAME
Catherine Morgan
PHONE
206-789-5396
ADDRESS
429 Bridge Way
Seattle, WA 98103
NAME
PHONE
NAME
PHONE
2-6
N
NAME
PHONE O
Norman Dearborn 206-598-8189 P
Q
ADDRESS
R
Morganthaler Industries
S
12558 E. 10th Ave. Seattle, WA
98102
206-509-6872 T
NAME
PHONE U
Thomas Morrison 503-256-6031 V
ADDRESS
W
866 Gage Road
X
Y
Klamath Falls, OR 97601
Z
Informix Guide to Database Design and Implementation
実体の識別
既存のデータの物理的な形は、誤解を招くことがあります。住所録のページと項目
のレイアウトに惑わされて、住所録の 1 つのエントリを 1 つの実体として指定しな
いように注意してください。住所録のエントリは、アルファベット順に並べられ、
名前、電話番号、住所の欄を持っています。モデル化するのはデータであって、
データの集まりではありません。
実体は一般的で重要か
見たところ、住所録に記録されている実体には次の項目が含まれています。
■
人や組織の名前
■
住所
■
電話番号
これらの実体は、前述の基準を満たしているでしょうか。モデルにとって重要であ
り、一般性があることは明らかです。
実体は基本的か
各実体は、他の実体に影響を与えずに個数を変化させることができます。この事実
は、基本的かどうかの判定に使用できます。引っ越したり仕事を変えたりしたため
に電話番号や現住所を持たない人も住所録に記載される場合があります。また、住
所録には、複数の人が使用している住所と電話番号が記載されていることもありま
す。名前、住所、電話番号の 3 つの実体はどれも、独立して個数を変化させること
ができます。これは、これらの実体が基本的であり、他のデータ依存していないこ
とを示しています。
実体は単一か
名前は個人名と会社名に分類することができます。このモデルではどの名前も特に
区別しないことにしました。つまり、会社の情報も個人の情報も同じように扱うこ
とにしました。同様に住所も、自宅の住所と会社の住所を区別して扱わずに、1 種
類と見なすことにしました。
ただし、複数の種類の電話番号があることになります。人が応答する通常の電話番
号、ファックスにつながるファックス番号、コンピュータにつながるモデム番号で
す。各種類の番号について異なる情報を記録することにします。つまり、この 3 種
類が異なる実体となります。
住所録の例では、次の実体を記録することに決定しました。
■
名前
■
住所 ( 郵送先 )
リレーショナルデータ モデルの作成
2-7
関係の定義
■
電話番号
■
ファックス番号
■
モデム番号
実体の図式化
E-R ダイヤグラムの使用方法については、この章で後述します。まず、図 2-2 に示
すように、住所録の例における各実体について、独立した長方形のボックスを作成
します。実体と関係を結び付ける方法については、2-17 ページの「データ オブジェ
クトの図式化」で示します。
名前
住所
電話
ファックス
モデム
図 2-2
住所録の例に
おける実体
関係の定義
データベースの実体を選択したら、その実体間の関係を考える必要があります。関
係は必ずしも明確ではありませんが、記録する価値のあるものをすべて見つけなけ
ればなりません。確実にすべての関係を見つけるには、考えられる関係をすべて列
挙する以外にありません。実体 A と実体 B のすべての組合せを想定し、
「A と B の
間にはどのような関係があるか」について考えます。
関係とは、2 つの実体の間の関連です。通常、関係は 2 つの実体を結ぶ動詞や前置
詞の中に含まれます。実体間の関係は、接続性、存在の依存性、濃度で表されま
す。
2-8
Informix Guide to Database Design and Implementation
関係の定義
接続性
接続性とは、実体のインスタンスの数を意味します。実体のインスタンスは、実体
の特定のオカレンスです。図 2-3 に示すように、接続性には 1 対 1 (1:1)、1 対多
(1:n)、多対多 (m:n) の 3 種類があります。
図 2-3
関係における接続性
1対1
1 対多
多対多
たとえば住所録の例では、住所は複数の名前と関連がある場合があります。名前と
住所との関連の接続性は、1 対多 (1:n) です。
存在の依存性
存在の依存性は、関係における実体が任意であるか、必須であるかを示します。ビ
ジネス ルールを分析して、実体が関係に存在しなければならないかどうかを確認し
ます。たとえば、1 つの名前には 1 つの住所が関連付けられていなくてはならない
というビジネス ルールがあるとします。このような関連は、名前と住所の実体の間
の関係に存在の依存性が必須であることを示します。存在の依存性が任意である例
として、ある人の子供のあるなしというビジネス ルールを挙げることができます。
濃度
濃度は、実体が関係に現れる回数に制約を適用します。1 対 1 の関係の濃度は、常
に 1 です。これに対して、1 対 n の関係の濃度は不定です。n は任意の数でかまいま
せん。n に上限を設ける必要がある場合は、その関係に濃度を指定します。たとえ
ば、店舗販売の例では、顧客が 1 回で買える品物の数の上限を指定すると考えられ
ます。通常、濃度の制約はアプリケーション プログラムまたは SPL (Stored
Procedure Language : ストアド プロシジャ言語 ) を使用して指定します。
濃度の詳細については、E-R データのモデル化についての参考資料を参照してくだ
さい。
リレーショナルデータ モデルの作成
2-9
関係の定義
関係の発見
実体間の関係を発見する方法としては、マトリックス形式で 2 つの実体の組合せを
列挙した表を作成するのが便利です。図 2-4 に示したマトリックスは、個人用住所
録の実体に関するものです。
名前
住所
番号
( 電話 )
番号
(ファックス )
番号
( モデム )
図 2-4
個人用住所録の実
体のマトリックス
名前
住所
番号
( 電話 )
番号
( ファックス )
番号
( モデム )
マトリックス内の陰をつけた部分は無視することができます。対角線上のセルは検
討を要します。つまり、
「実体 A のインスタンスと実体 A の別のインスタンスの間
にはどんな関係があるか」を考えなければなりません。このモデルの場合、その答
えは必ず、
「関係は 1 つもない」になります。名前どうしや住所と他の住所の間に
は関係がありません。少なくとも、このモデルでは記録する必要があるものは何も
ありません。A のインスタンスと A の別のインスタンスの間に関係がある場合は、
再帰的な関係があるといいます。2-27 ページの「その他の特別な関係の解決」を参
照してください。
2-10
Informix Guide to Database Design and Implementation
関係の定義
関係がないことがはっきりしたセルには、なしと記入します。図 2-5 に、現行のマ
トリックスを示します。
住所
名前
名前
番号
( 電話 )
番号
番号
( ファックス ) ( モデム )
図 2-5
初期の関係を示し
たマトリックス
なし
住所
なし
番号
( 電話 )
なし
番号
( ファックス )
なし
番号
( モデム )
なし
このモデルでは自分自身との間に関係がある実体はありませんが、ほかのモデルで
は同一の実体の間に関係が生じる場合があります。たとえば、社員という実体で
は、ある社員は別の社員の上司になることがあります。別の例としては、部品とい
う実体があります。ある部品が別の部品の構成要素になることがあります。
残った空白のセルには、上端の見出しの実体と左端の見出しの実体の間に存在する
接続関係の種類を書き込みます。関係には、次のような種類があります。
■
1 対 1 の関係 (1:1)。実体 A の 1 つの要素と関係する実体 B の要素は 1 つの
みです。実体 B の 1 つの要素と関係する実体 A の要素も 1 つのみです。
■
1 対多の関係 (1:n)。実体 A の要素は 1 つしかありません。ただし、実体 A
の要素には実体 B の要素を複数関連付けることができます。実体 B の要素
複数に実体 A の要素を 1 つだけ関連付けることもできます。
■
多対多の関係 (m:n)。実体 A の 1 つの要素と関係する実体 B の要素は複数
あります。また、実体 B の 1 つの要素と関係する実体 A の要素も複数あり
ます。
1 対多の関係がもっとも一般的です。住所録モデルの例では、1 対多と多対多の関
係を示します。
リレーショナルデータ モデルの作成
2-11
関係の定義
2-11 ページの 図 2-5 に示すように、最初の空白のセルは、名前と住所の間の関係を
示しています。名前と住所という実体の間には、どのような接続性があるでしょう
か。
「1 つの住所にいくつの名前を関連付けることができるか」について考えた結
果、名前は住所を持たないか、またはただ 1 つの住所を持つことにします。図 2-6
に示すように、名前の向かい側、住所の下に 0-1 と記入します。
名前
名前
図 2-6
名前と住所の関係
住所
なし
0-1
次に、1 つの名前にいくつの住所が関連しているかを考えます。住所は複数の名前
と関連があるということにします。たとえば、同じ会社に勤める人を何人か知って
いるかもしれませんし、同じ住所に住んでいる人を複数知っているかもしれませ
ん。
住所と関連する名前の数がゼロということはあり得るでしょうか。すなわち、住所
だけが存在し、その住所に対する名前が存在しないということはあるでしょうか。
この場合は、あり得ると決定しました。図 2-7 に示すように、住所の下、名前の向
かい側に 0-n と記入します。
名前
名前
図 2-7
住所と名前の関係
住所
なし
0-n
0-1
関連付けられた名前が 1 つもない住所は存在しないと決定した場合は、0-n ではな
く 1-n と記入します。
2-12
Informix Guide to Database Design and Implementation
関係の定義
関係する要素の濃度 ( 個数 ) がどちらか一方の実体の側で最大 1 に制限される場合
は、1:n の関係になります。この場合、名前と住所の関係は 1:n の関係です。
ここで、2-11 ページの 図 2-5 で、次のセルを検討します。つまり、名前と電話番号
との関係です。1 つの名前と関係する可能性がある電話番号は 1 つだけでしょうか、
それとも 2 つ以上関係することがあるでしょうか。住所録を見ると、一人に対して
複数の電話番号を記入している箇所が見受けられます。多忙なセールス担当者の場
合は、自宅の電話番号、会社の電話番号、ポケット ベルの番号、自動車電話番号な
どが記入されています。しかし、電話番号のない名前もあります。この場合は、
図 2-8 に示すように、名前の向かい側、電話番号の下に 0-n と記入します。
名前
名前
番号
( 電話 )
住所
なし
図 2-8
名前と電話番号の
関係
0-n
0-n
0-1
次に、逆方向の関係を検討します。各電話番号と関係する可能性がある名前は、い
くつあるでしょうか。電話番号には、1 つの名前のみ関係していると決定しました。
電話番号と関係する名前の数がゼロという場合はあり得るでしょうか。誰にも使用
されていない電話番号を記録する必要はないと決定しました。図 2-9 に示すように、
電話番号の下、名前の向かい側に 1 と記入します。
名前
名前
番号
( 電話 )
住所
なし
1
0-n
0-1
図 2-9
電話番号と名前の
関係
0-n
以下の要因を考慮して、マトリックスの残りの部分も同じように記入します。
リレーショナルデータ モデルの作成
2-13
関係の定義
■
名前は、複数のファックス番号と関係する可能性があります。たとえば、
会社にはいくつかのファクシミリがあることがあります。逆に考えると、
各ファックス番号は、複数の名前と関係する可能性があります。たとえ
ば、同じファックス番号を複数の人が使用することがあります。
■
各モデム番号が関係する名前は、ちょうど 1 つでなければなりません。( こ
れは意図的に決めたものです。設計の要件の 1 つと考えてください。) こ
れに対し各名前は、複数のモデム番号と関係する可能性があります。たと
えば、会社のコンピュータは複数のダイヤル回線に接続されることがあり
ます。
■
電話番号と住所の間には、現実には何らかの関係がありますが、このモデ
ルでは特に注意するような関係はありません。すでに名前によって間接的
な関係が示されています。
図 2-10 に、完全なマトリックスを示します。
名前
名前
住所
なし
0-n
0-1
住所
なし
番号
( 電話 )
番号
( ファックス )
番号
( 電話 )
番号
( ファックス )
1
0-n
なし
なし
番号
( モデム )
1-n
0-n
なし
図 2-10
完成した住所録の
マトリックス
1
0-n
なし
なし
なし
なし
なし
なし
番号
( モデム )
マトリックスに示されたそのほかの決定は、ファックス番号とモデム番号、電話番
号とファックス番号、電話番号とモデム番号それぞれの間に関係が存在しないとい
うことです。
電話番号とモデム番号の間の関係をサポートしないことなど、こうした決定の一部
には賛成できないものもあるでしょう。しかし、この例では、上記をビジネス ルー
ルとします。
2-14
Informix Guide to Database Design and Implementation
属性の識別
関係の図式化
まず、この節で作成したマトリックスを保存しておきます。E-R ダイヤグラムの作
成方法については、2-17 ページの「データ オブジェクトの図式化」で学習します。
属性の識別
実体には、特性や修飾子、品質、数量、機能としての属性が含まれています。属性
は、実体に関する事実または分割できない情報です。実体を表として表現するとき
に、実体の属性を新しい列としてモデルに追加します。
実体を識別して初めて、データベース属性が識別できます。実体を決定したら、
「各実体についてどのような特性を知る必要があるか」について考えます。たとえ
ば、実体が住所であれば、通り、市町村、郵便番号などを知る必要があるでしょ
う。住所という実体に関するこれらの特性それぞれが属性となります。
実体の属性の選択
属性を選ぶときは、次の条件を満たすものを選んでください。
■
重要性が高いこと
データベースのユーザにとって重要な属性のみを選んでください。
■
直接的であり、導出的ではないこと
たとえば、SELECT 文の記述から導出できるような、既存の属性から導出
できる属性がモデルの一部であってはなりません。データが導出される
と、データベースの保守が複雑になります。
この後の設計段階では、性能改善のために導出される属性の追加を検討す
る場合があります。しかしこの段階では、導出される属性は除外します。
データベース サーバの性能の改善方法については、
『Performance Guide』
を参照してください。
■
分割できないこと
属性は 1 つの値のみを含むもので、リストや繰り返されるグループを含ん
だものであってはなりません。複合的な値は、個々の属性に分けなければ
なりません。
■
同じタイプのデータを含んでいること
たとえば、誕生日という属性には日付の値のみを入れて、名前や電話番号
入れないはずです。
属性の定義方法のルールは、列の定義方法のルールと同じです。列の定義方法の詳
細については、2-21 ページの「列への制約の適用」を参照してください。
リレーショナルデータ モデルの作成
2-15
属性の識別
次の属性を住所録の例に追加して、2-19 ページの 図 2-15 に示すようなダイヤグラ
ムを作成します。
■
住所の実体には、通り名、市町村名、州名、および郵便番号を追加しま
す。
■
名前の実体には、誕生日、電子メール アドレス、記念日、および子供の名
前を追加します。
■
電話番号の実体には、自動車電話、自宅の電話、および勤務先の電話を区
別するためのタイプを追加します。1 つの電話番号は、1 つの電話のみに
関係します。
■
ファックスの実体には、ファクシミリが受信可能な時間帯を追加します。
■
モデムの実体には、9,600、14,400、28,800 など、モデムがサポートする
ボー レートを追加します。
属性の列挙
ここでは、住所録の例について、必要と思われる実体とともに属性を列挙します。
図 2-11 のような属性が列挙されるでしょう。
名前
fname
lname
bdate
anniv
email
child1
child2
child3
住所
street
city
state
zipcode
電話
ファックス X
vce_num
vce_type
fax_num
oper_from
oper_till
モデム
mdm_num
b9600
b14400
b28800
図 2-11
住所録の例の属性
実体のオカレンスについて
追加のデータ オブジェクトは、実体のオカレンス ( 発生数 ) です。表の各行は、実
体の特定の単一のオカレンスを表しています。たとえば、顧客が実体である場合、
表 costomer は顧客の概念を表します。その表では、各行は、たとえば Sue Smith と
いう 1 人の特定の顧客を表します。実体は表に、属性は列に、実体のオカレンスは
行になることを覚えておいてください。
2-16
Informix Guide to Database Design and Implementation
データ オブジェクトの図式化
データ オブジェクトの図式化
これで、データベース内の実体と関係を理解しました。これは、リレーショナル
データベースの設計プロセスで最も重要なことです。実体と関係が決まると、デー
タベース設計中の思考過程を表す方法が役に立つことがあります。
データ モデル化の方法の多くで、実体と関係をグラフィカルに表示することができ
ます。Informix では、C. R. Bachman が開発した E-R ダイヤグラム アプローチが使用
されています。E-R ダイヤグラムは、次の機能を果たします。
■
組織の情報ニーズをモデル化する。
■
実体とその関係を示す。
■
データ定義 ( データ フロー ダイヤグラム ) の出発点となる。
■
アプリケーション開発者のみならず、データベース管理者やシステム管理
者にとって文書化のためのすぐれた資料となる。
■
物理スキーマに変換できるデータベースの論理設計を作成する。
E-R ダイヤグラムには、いくつかのスタイルが存在します。好みのスタイルがある
場合は、それを使用してください。E-R ダイヤグラムの例を図 2-12 に示します。
名前
図 2-12
実体 - 関係ダイヤ
グラムの記号
住所
実体
実体
関係
E-R ダイヤグラムでは、ボックスは実体を表します。線は、実体と実体をつなぐ関
係を表します。また、図 2-13 に、次の性質の関係を表す場合のグラフィック記号の
使い方を示します。
■
接続関係を表す線上の円は、その関係が任意であることを示します。イン
スタンスがゼロの場合があります。
■
接続関係を表す線上の短い棒線は、その実体のちょうど 1 つのインスタン
スがほかの実体に関連付けられていることを示します。棒線は 1 とみなし
ます。
■
カラスの足跡は、関係が多数あることを示します。
リレーショナルデータ モデルの作成
2-17
E-R ダイヤグラムの読み方
任意
図 2-13
実体 - 関係ダイヤ
グラムにおける関
係の部分
任意
多数
ちょうど
1つ
E-R ダイヤグラムの読み方
E-R ダイヤグラムは、まず左から右に、次に右から左に読んでいきます。図 2-14 の
ような名前と住所の関係の場合は、次のように読んでいきます。名前は、ゼロまた
はちょうど 1 つの住所に関係することができます。また、住所は、ゼロ、1 つ、ま
たは多数の名前と関係することができます。
図 2-14
実体 - 関係ダイヤ
グラムの読み方
ゼロまたは
ちょうど 1 つ
名前
住所
ゼロまたは多数
住所録の例
図 2-15 に、実体、関係、属性を含んだ住所録の例を示します。このダイヤグラムに
は、マトリックスを使用して確立する関係が含まれています。ダイヤグラム中のシ
ンボルの意味を理解した後、
図 2-15 の E-R ダイヤグラムを 2-14 ページの 図 2-10 の
マトリックスと比較してください。両方の図で関係が同じになっているかを確認し
てください。
2-18
Informix Guide to Database Design and Implementation
住所録の例
2-14 ページの 図 2-10 に示したようなマトリックスは、それを記入する際、必然的
にあり得るすべての関係を考えなければならないため、初めてモデル設計する場合
には有効なツールとなります。ただし、図 2-15 のように、同じ関係がダイヤグラム
に現れる場合は、この種のダイヤグラムは、既存のモデルを再検討すると読みやす
くなります。
図 2-15
住所録の例の予備
的実体 - 関係ダイ
ヤグラム
名前
lname
fname
bdate
anniv
email
child1
child2
child3
電話
住所
street
city
state
zipcode
ファックス
vce_num
vce_type
fax_num
oper_fro
m
oper_till
モデム
mdm_num
b9600
b14400
b28800
ダイヤグラムが完成した後に
この章の残りの部分では、以下の作業を実行する方法について説明します。
■
実体、関係、属性を関係構造体に変換する。
■
E-R データ モデルを解決する。
■
E-R データ モデルを正規化する。
E-R データ モデルからデータベースを作成する方法については、第 4 章で説明しま
す。
リレーショナルデータ モデルの作成
2-19
E-R データ オブジェクトの関係構造体への変換
E-R データ オブジェクトの関係構造体への変換
これまで学習してきたすべてのデータ オブジェクト ( 実体、関係、属性、および実
体のオカレンス ) は、SQL 表、表どうしの結合、列、および行に変換されます。
データベースの表、列、行は、2-20 ページの「表、行、列の定義」に示すルールに
従っていなければなりません。
データ オブジェクトを正規化する前に、それがこれらのルールを満たしていること
を確認してください。データ オブジェクトを正規化するには、実体、関係、および
属性の間の依存性を分析します。正規化については、2-27 ページの「データ モデル
の正規化」を参照してください。
データ モデルを正規化した後は、SQL 文を使用してデータ モデルに基づくデータ
ベースを作成することができます。住所録の例のデータベースを作成し、データ
ベース スキーマを指定する方法については、第 4 章で説明します。
選択した各実体は、モデルにおける表として示されます。表は、抽象概念としての
実体を意味しており、各行は実体の特定の個別オカレンスを表します。さらに、実
体の各属性は表の列で表されます。
以下に E-R データ モデルを含む大部分の関係データ モデル法の基本的な考えかた
を示します。データ モデル設計時にこれらのルールに従って、モデルを正規化する
ときの時間と労力を節約してください。
表、行、列の定義
すでに、行および列からなる表という概念については理解していることと思いま
す。しかし、正式なデータ モデルの表は下記のルールが要求されます。
■
各行は独立していていなければならない。
表の各行は独立していて、同じ表のほかの行に依存することはありませ
ん。したがって、表の内部での行の順番は、モデルでは意味がありませ
ん。表のすべての行をランダムな順番に並び替えたとしても、モデルは正
しいはずです。
データベースを実装した後では、性能を上げるためにデータベース サーバ
に要求して特定の順序で行を保存することができますが、その順序はモデ
ルには影響を及ぼしません。
■
各行は一意でなければならない。
各行には、必ず一意の値を持つ列がなければなりません。この特性を持つ
単一の列がない場合は、複数の列の値を組にすることで行を識別できるよ
うな列の組合せが存在しなければなりません。
2-20
Informix Guide to Database Design and Implementation
表、行、列の定義
■
各列は独立していなければならない。
表の内部での列の順番は、モデルでは意味がありません。列を並び替えた
としても、モデルは正しいはずです。
データベースを実装した後では、すべての列を意味するアスタリスクを使
用しているプログラムや格納された問合せは列の最終的な順序に依存しま
すが、その順序はモデルには影響を及ぼしません。
■
各列の値は 1 つの値でなければならない。
各列が格納できるのは、1 つの値のみで、値の並びや繰り返されるグルー
プは、1 つの列には格納できません。複数の要素から合成された値は、
個々の列に分離する必要があります。たとえば、この章の例のように、個
人の姓と名前を別々の値として取り扱うことにした場合、姓と名前は 1 つ
の列にいっしょに格納するのではなく、別々の列に格納しなければなりま
せん。
■
各列は一意の名前を持たなければならない。
同じ表の内部の 2 つの列が同じ名前を共有することはできません。ただし
同様な情報を含む列を複数作成することはできます。たとえば、住所録の
例の表名前には子供の名前の列があります。この場合、各列の名前は
child1、child2 などとします。
■
各列は単一の型のデータを含んだものでなければならない。
各列は、同じデータ型の情報を格納しなければなりません。たとえば、整
数 (INTEGER) 型で示される列には、名前からの文字ではなく数値情報の
みを格納しなければなりません。
配列やシーケンシャル ファイルとして構成されたデータを扱った経験しかない場合
は、これらのルールは不自然に思えるかもしれません。しかし、リレーショナル
データベースの理論では、すべての型のデータは、これらのルールに従った表、
行、列のみを使用して表すことができます。多少経験を積めば、これらのルールを
機械的に適用できるようになります。
列への制約の適用
CREATE TABLE 文を使用して表と列を定義する場合、各列に制約を加えます。こ
れらの制約は、列に文字と数のどちらを入れるか、使用する日付の形式などの条件
を指定します。属性が想定できるような一式の有効値をドメインで識別する場合
は、ドメインに制約を記述します。
ドメインの特性
表を作成する場合、ドメインの特性を定義します。列には、次のドメイン特性を指
定できます。
リレーショナルデータ モデルの作成
2-21
表のキーの決定
■
データ型 ( 整数 (INTEGER) 型、文字 (CHAR) 型、日付 (DATE) 型など )
■
フォーマット ( たとえば、yy/mm/dd)
■
範囲 ( たとえば、1,000 ∼ 5,400)
■
意味 ( たとえば、個人の電話番号 )
■
許容値 ( たとえば、等級 S または U のみ )
■
一意性
■
NULL のサポート
■
デフォルト値
■
参照制約
ドメインの定義方法については、第 3 章を参照してください。表とデータベースの
作成方法については、第 4 章を参照してください。
表のキーの決定
表の列は、キー列または記述子列のどちらかです。キー列とは、表の内部の特定の
行を一意に識別する列です。たとえば、社会保険番号は各社員に一意です。記述子
列は、表の特定の行の一意ではない特性を指定します。たとえば、Sue という同じ
姓を持つ社員が 2 人いる場合を考えます。この Sue という名前は、1 人の社員の一
意な特性ではありません。表におけるキーには、主キーと外部キーという主なタイ
プがあります。
主キーと外部キーは、表を作成するときに指定します。主キーと外部キーは、表を
物理的に関係づけるために使用します。次の作業は、各表に主キーを指定すること
です。つまり、行のそれぞれを他の行と区別する何らかの定量化できる表の特性を
識別する必要があります。
主キー
表の主キーとは、行ごとに値が異なる列のことです。主キーの値は行ごとに異なる
ため、主キーは各行を一意に識別します。そのような列が存在しない場合は、値の
組合せが行ごとに異なるような複数の列の複合が主キーになります。
モデルの表はどれも、主キーを持たなければなりません。このルールは、すべての
行は一意でなくてはならないというルールを自動的に導き出します。必要に応じ
て、すべての列で主キーを構成することもできます。
主キーは、数値データ型 ( 整数 (INT) 型または小桁整数 (SMALLINT) 型 )、シリア
ル (SERIAL) 型、またはコードに使用するような短い文字列とします。長い文字列
を主キーとして使用しないことをお勧めします。
2-22
Informix Guide to Database Design and Implementation
表のキーの決定
主キー列では NULL は使用できません。NULL は比較することができません。つ
まり NULL については、「同じ」あるいは「異なる」といった比較はできません。
したがって、NULL は行を一意に識別することができません。NULL が使用できる
列を主キーや主キーの一部として使用することはできません。
実体の中には、カタログ番号や身分証明番号のように、モデルの外部で定義された
主キーを持つものもあります。こうしたキーは、ユーザが割り当てたキーです。
場合によっては、複数の列や列のグループが主キーとして使用できることもありま
す。主キーとして使用できる列や列のグループを候補キーと呼びます。候補キーは
一意性という特性により、SELECT 文の結果が予測できるため、注意する必要があ
ります。候補キーの列を選択すると、その結果には重複行が含まれていないことが
わかっているので、SELECT 文を実行した結果は選択した候補キーを主キーとする
1 つの表になります。
複合キー
実体によっては、確かな一意性を欠いたものがあります。たとえば、同姓同名の人
がいる場合があります。別々の本の題名が同じである場合もあります。通常、この
ような場合は複数の属性を組み合せて主キーとして使用できます。名前と住所が同
じという人はめったになく、異なる本でもタイトル、著者および発行日が同じとい
うこともほとんどあり得ないからです。
システム割当てキー
通常は、複合キーよりシステム割当て主キーのほうが便利です。システム割当キー
は、実体の各インスタンスに付けられる数値またはコードです。もっとも簡単に付
けることができるシステム割当てキーは、データベースが自動的に生成することの
できるシリアル番号です。Informix では、シリアル番号のためにシリアル (SERIAL)
型を使用します。しかし、意味のない数値コードは、データベース利用者には現実
的とはいえません。そのような場合は、実際のデータに基づいたコードをシステム
割当てキーとして使用することもできます。たとえば、従業員の識別コードは、個
人の頭文字と雇用された日付の数字を組み合わせて示すことができます。住所録の
例では、システム割当て主キーは表名で使用されています。
リレーショナルデータ モデルの作成
2-23
表のキーの決定
外部キー ( 結合列 )
外部キーとは、ほかの表の主キーと一致する値を持つ表の列または列のグループを
指します。外部キーは、表を結合するときに使用します。図 2-16 は、デモンスト
レーション データベースの顧客表と注文表の主キーと外部キーです。
顧客
customer_num
主キー
注文
customer_num customer_num
図 2-16
顧客 / 注文関係に
おける主キーと
外部キー
外部キー
表から行を削除するときは、外部キーによって制約を受けるので、外部キーに注目
する必要があります。行を削除するときには、その前に外部キーを介してその行を
参照している行をすべて削除しておくか、1 つの削除コマンドで主キーと外部キー
から行を削除できる特殊な構文を使用して関係を定義しておく必要があります。
データベース サーバでは、参照整合性に違反する削除は行えません。
参照整合性を保持するには、すべての外部キー列を削除してから、その外部キーが
参照している主キーを削除してください。データベースに参照整合性が課されてい
る場合、対応する外部キーが存在しているときにデータベース サーバは主キーの削
除を許可しません。また、既存の主キーの値を参照しない外部キーの値を追加する
こともできません。参照整合性については、
『Informix Guide to SQL: Tutorial』を
参照してください。
住所録のダイヤグラムへのキーの追加
図 2-17 に、最初に選択された主キーおよび外部キーを示します。このダイヤグラム
は、いくつかの重要な決定を反映しています。
表名前では、主キー rec_num が選択されています。rec_num のデータ型はシリア
ル (SERIAL) 型です。rec_num の値は、システムが生成します。表名前の他の列ま
たは属性を見ると列に関連付けられたデータ型のほとんどは文字型を基準にしたも
のであることがわかります。これらの列はどれも、単独では主キー候補として適切
ではありません。表の要素を組み合わせて複合キーを作成すると、キーは複雑にな
ります。シリアル (SERIAL) 型で提供されたキーを使用すれば、ほかの表を表 name
と結合することもできます。
電話、ファックス、およびモデムの各表では、電話番号は、主キーとして表示され
ます。これらの表は、キー rec_num を介して表名前に結合されます。
2-24
Informix Guide to Database Design and Implementation
関係の解決
表住所も、システムが生成した id_num という主キーを使用しています。ビジネス
ルールでは、名前が住所を使用していなくても住所は存在し得ることになっている
ので、表住所には主キーが必要です。ビジネス ルールで、名前が住所と関係してい
ないかぎり、住所は存在できないと定められている場合は、表住所は外部キー
rec_num でのみ表名前と結合することができます。
名前
rec_num PK
lname
fname
bdate
anniv
email
child1
child2
child3
ファックス X
電話
vce_num PK
rec_num FK
vce_type
fax_num PK
rec_num FK
oper_from
oper_till
住所
id_num PK
rec_num FK
street
city
state
zipcode
図 2-17
主キーと外部キー
を追加した住所録
のダイヤグラム
モデム
mdm_num PK
rec_num FK
b9600
b14400
b28800
PK= 主キー
FK= 外部キー
関係の解決
適切なデータ モデルの目的は、データベース サーバが迅速にアクセスできるよう
な構造体を作成することにあります。関係を解決し、データ モデルを正規化するこ
とにより、住所録のデータ モデルをさらに改善することができます。ここでは、
データベースの関係を解決する方法と、その理由について説明します。データ モデ
ルの正規化については、2-27 ページの「データ モデルの正規化」で説明します。
m:n 関係の解決
多対多 (m:n) の関係は、モデルとアプリケーション開発過程を複雑にするだけでな
く混乱をもたらします。m:n 関係を解決する鍵は、2 つの実体を分離して、これら
の実体の間に第 3 の交差実体によって 2 つの 1 対多 (1:n) の関係を作成することにあ
ります。交差実体には、通常、それが接続する両方の実体の属性が含まれます。
リレーショナルデータ モデルの作成
2-25
m:n 関係の解決
m:n 関係を解決するには、ビジネス ルールをもう一度解析します。関係を正確に図
式化しているでしょうか。住所録の例では、2-25 ページの 図 2-17 に示すように、
名前の実体とファックスの実体間の関係を m:n にしました。このビジネス ルールで
は、
「一人の人がゼロ、1 つまたは複数のファックス番号を持つことができる。1 つ
のファックス番号は、複数の人が使用することがある」となっています。電話の実
体の主キーとして先に選択したものに基づいて、m:n 関係は存在しています。
主キーとして指定した電話番号は、ファックスの実体に 2 回以上現れることがある
のでファックスの実体には問題があります。これは主キーの条件に違反していま
す。主キーは一意でなければならないことを思い出してください。
図 2-18 に示すように、名前の実体とファックスの実体の間に交差実体を追加すれ
ば、このような m:n の関係を解決できます。新しい交差実体、ファックス名には、
fax_num と rec_num という 2 つの属性が含まれています。実体の主キーは、これら
両方の属性を複合したものです。個別にみると、各属性は属性が由来する表を参照
する外部キーです。表名前と表ファックス名との間の関係は、1:n です。1 つの名前
が多くのファックス番号と関係することがあり得るからです。一方、各ファックス
名の組合せは、1 つの rec_num と関係する可能性があります。各番号は複数の
ファックス名の組合せと関係し得るので表ファックスと表ファックス名との間の関
係は 1:n です。
名前
rec_num PK
lname
fname
bdate
anniv
email
child1
child2
child3
rec_num PK
lname
fname
bdate
anniv
email
child1
child2
child3
交差
実体
ファックス名
fax_num PK FK
rec_num PK FK
ファックス X
ファックス X
fax_num PK
rec_num FK
oper_from
oper_till
fax_num PK
oper_from
oper_till
前
2-26
後
Informix Guide to Database Design and Implementation
PK= 主キー
FK= 外部キー
図 2-18
多対多 (m:n) 関係
の解決
その他の特別な関係の解決
その他の特別な関係の解決
上記以外にも、データベースの円滑な実行を妨げる特別な関係があります。これら
の関係には、次のようなものがあります。
■
複雑な関係
■
再帰的関係
■
冗長な関係
複雑な関係とは、3 つ以上の実体間の関係です。関係が存在するには、すべての実
体が存在しなければなりません。この複雑さを軽減するには、すべての複雑な関係
を実体として再分類し、元の実体のそれぞれに対する 2 進関係に整理します。
再帰的関係とは、同じ型の実体のオカレンス間の関係です。このタイプの関係はよ
く見られるものではありません。再帰的関係の例としては、部品表 ( パーツがサブ
パーツで構成されている ) や組織構造 ( ある社員が他の社員を管理する ) がありま
す。再帰的関係を解決しないほうを選択することもできます。再帰的関係の詳しい
例については、
『Informix Guide to SQL: Tutorial』を参照してください。
冗長な関係は、複数の関係が同じ概念を表す場合に存在します。冗長な関係は、
データ モデルを複雑にし、開発者がデータ モデルの属性を誤って設定する原因に
もなります。この関係は、E-R ダイヤグラムの中で重複した実体として表されま
す。たとえば、同じ属性を含む 2 つの実体がある場合があります。冗長な関係を解
決するには、データ モデルを見直します。同じ属性を含んだ実体が 2 つ以上ないで
しょうか。冗長性を解決するには、モデルに新しい実体を追加する必要がありま
す。データ モデルの冗長性の詳細については、
『Performance Guide』を参照してく
ださい。
データ モデルの正規化
この章の住所録は、よいモデル例です。今のままでもこのモデルをデータベースと
して実現することができますが、アプリケーション開発やデータ操作に、後日問題
が発生する可能性があります。正規化とは、属性を実体と関係付けるルールを適用
する形式化されたアプローチです。
データ モデルを正規化すると、以下の目標が達成できます。
■
設計の柔軟性を向上させる。
■
属性を正しい表に入れる。
■
データの冗長性を少なくする。
■
プログラムの性能を向上する。
リレーショナルデータ モデルの作成
2-27
第 1 正規形
■
アプリケーションの保守コストを引き下げる。
■
データ構造の安定性を最大限に高める。
正規化は、実体をより適切な物理特性にするためのいくつかの手順で構成されてい
ます。これらの手順を正規化ルールといいます。正規形と呼ぶこともあります。正
規形にはいくつかあります。この章では、最初の 3 つの正規形を説明します。各正
規形は、直前の形よりも構造性の高いものにするためにデータを制約します。この
ため、第 2 正規形を実現するには第 1 正規形を実現し、第 3 正規形を実現するには
第 2 正規形を実現しなければなりません。
第 1 正規形
実体に反復されるグループがない場合、その実体は第 1 正規形となります。した
がって、表に反復される列がない場合、その表は第 1 正規形となります。反復列
は、データの柔軟性を低下させ、ディスク スペースを浪費し、データの探索を困難
にします。図 2-19 の住所録の例では、表名前に反復列 child1、child2、child3 が含
まれています。
名前
lname
fname
bdate
anniv
email
child1
child2
child3
図 2-19
正規化前の
実体名前
反復列
現行の表にはいくつかの問題点があります。この表は、子供がいるいないに関わら
ず、一人につき 3 人の子供を記録するためのディスク スペースを常に確保しておか
なくてはなりません。記録できる子供の最大数は 3 人ですが、4 人以上の子供がい
る人もいるはずです。また、特定の子供を探す場合、各行につき 3 つの列をすべて
探索しなければなりません。
2-28
Informix Guide to Database Design and Implementation
第 1 正規形
反復列をなくして、表を第 1 正規形にするには、図 2-20 に示すように表を 2 つに分
割します。反復列を表のどちらかに入れます。2 つの表間の関連付けは主キーと外
部キーを組み合わせて確立されます。表名前と関連付けられていなければ子供はい
ないことになるので、外部キー rec_num で表名前を参照します。
図 2-20
実体名前の第 1 正
規形
名前
rec_num
lname
fname bdate
anniv
email
主キー
子供
rec_num
child_name
外部キー
ここで、2-25 ページの 図 2-17 の、第 1 正規形になっていないグループを確認して
ください。表 name と表 modem の関係は、列 b9600、b14400、b28800 が反復列と
考えられるので、第 1 正規形ではありません。列 b9600、b14400、b28800 のオカレ
ンスを格納するために表 modem に新しい列 b_type を追加します。図 2-21 に、第 1
正規形で正規化されたデータ モデルを示します。
名前
rec_num PK
lname
fname
bdate
anniv
email
電話
vce_num PK
rec_num
vce_type
子供
rec_num FK
child_name
ファックス
fax_num PK
oper_from
oper_till
住所
id_num PK
rec_num FK
street
city
state
zipcode
ファックス名
fax_num PK FK
rec_num PK FK
図 2-21
住所録のデータ
モデル
モデム
mdm_num PK
rec_num FK
b_type
PK= 主キー
FK= 外部キー
リレーショナルデータ モデルの作成
2-29
第 2 正規形
第 2 正規形
実体が第 1 正規形であり、かつその属性のすべてが全体 ( 主 ) キーに依存している
場合、その実体は第 2 正規形であるといいます。したがって、表中のすべての列は
その表の主キー全体に機能的に依存する必要があります。機能的依存性は、2 つの
異なる列内の値の間にリンクが存在することを示しています。
属性値が列に依存する場合、列の値を変更すると属性値も変わります。属性は列の
関数になります。これを具体的に説明すると、以下のようになります。
■
表に 1 列の主キーがある場合、属性はそのキーに依存していなければなら
ない。
■
表に複合主キーがある場合、属性は、1 つまたは数個の列ではなく、全体
としてのすべての列内の値に依存していなければならない。
■
属性が他の複数の列に依存している場合、その列は候補キーの列でなくて
はならない。つまり、列はすべての行で一意でなければならない。
モデルを第 2 正規形に変換する場合、データの冗長性が発生し、データの変更が困
難になる可能性があります。第 1 正規形の表を第 2 正規形の表に変換するには、主
キーに依存していない列を削除します。
第 3 正規形
実体が第 2 正規形であり、かつその属性のすべてが主キーに過渡的に依存していな
い場合、実体は第 3 正規形であるといいます。過渡的依存性とは、記述子のキー属
性が全体主キーだけでなく、ほかの記述子キー属性にも依存しており、これらのほ
かの属性も主キーに依存していることを意味します。SQL の用語では、第 3 正規形
とは、表内の列が、主キーに依存する記述子の列に依存していないことを意味しま
す。
第 3 正規形に変換するには、他の記述子キー属性に依存している属性を削除しま
す。
正規化ルールのまとめ
ここでは、以下の正規形について説明しました。
2-30
■
第 1 正規形 : 表に反復列が含まれていない場合、その表は第 1 正規形です。
■
第 2 正規形 : 表が第 1 正規形であり、
かつ全体 ( 主 ) キーに依存している列の
みを含んでいる場合、その表は第 2 正規形です。
■
第 3 正規形 : 表が第 2 正規形であり、かつ主キーに過渡的にも依存していな
い列だけが含まれている場合、その表は第 3 正規形です。
Informix Guide to Database Design and Implementation
正規化ルールのまとめ
これらのルールに従っている場合、リレーショナル データベースの創案者である E.
F. Codd に従えば、モデルの表は第 3 正規形です。表が第 3 正規形ではない場合は、
モデルに冗長なデータが存在するか、表を更新しようとするときに問題が発生する
可能性があります。
これらのルールを維持している属性を見つけることができない場合、次のいずれか
のエラーが発生している可能性があります。
■
その属性は明確に定義されていない。
■
その属性は直接的でなく導出される属性である。
■
その属性は、実際には属性ではなく、実体か関係である。
■
モデルから脱落した実体や関係がある。
リレーショナルデータ モデルの作成
2-31
第3章
データ型の選択
この章の概要 . .
.
. .
.
. .
. .
ドメインの定義 . . . . . . . .
データ型 . . . . . . . . .
データ型の選択 . . . . .
数値データ型 . . . . . .
日付、時間に関するデータ型
ブール (BOOLEAN) 型 . . .
文字型 . . . . . . . .
データ型の変更 . . . . .
NULL 値 . . . . . . . . .
デフォルト値 . . . . . . .
チェック制約 . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
. .
.
. .
. .
.
. .
.
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3-3
3-3
3-4
3-4
3-8
3-13
3-17
3-18
3-24
3-24
3-25
3-25
3-2
Informix Guide to Database Design and Implementation
この章の概要
データ モデルの作成が済んだら、そのデータ モデルをデータベースおよび表とし
て実装する必要があります。データ モデルを実装するには、最初に、ドメイン、つ
まりデータ値の集合を列ごとに定義します。この章では、列データ型と制約を定義
するときに決定する必要のある事項について説明します。
次の手順では、CREATE DATABASE 文と CREATE TABLE 文を使用して、モデル
を実装し、表にデータを入力します。第 4 章を参照してください。
ドメインの定義
第 2 章で説明したデータ モデルを完全なものとするには、各列にドメインを 1 つ定
義する必要があります。列のドメインは、列に設定されている制約を記述し、属性
( 列 ) が想定できる一連の有効値を示します。
ドメインを定義するのは、モデルのデータの意味整合性を保護するためです。つま
り、モデルのデータが現実を反映していることを確実にすることです。電話番号を
名前に置き換えたり、整数値のみ有効なデータに小数値を入力したりすることがで
きると、データ モデルの整合性は保証されなくなります。
ドメインを定義するには、まず、制約を定義します。データ値は、ドメインの部分
を構成する前にこの制約を満足する必要があります。列のドメインを指定するに
は、次の制約を使用します。
■
データ型
■
デフォルト値
■
チェック制約
各表の主キーと外部キーを識別して、列に対する参照制約を設定することができま
す。これらのキーを識別する方法については、第 2 章「リレーショナルデータ モデ
ルの作成」を参照してください。
データ型の選択
3-3
データ型
データ型
列に対する最初の制約は、列にデータ型を指定することにより課されます。列の
データ型を指定すると、その列にはそのデータ型の値のみ格納できるように制約す
ることになります。
それぞれのデータ型は、特定の種類の情報のみ表すことができます。ある列にとっ
ての正しいデータ型とは、その列に適したデータ値はすべて表現でき、その列に適
さない値はほとんど表現できないデータ型のことです。
この章では、Informix データベース サーバすべてでサポートされている組込みデー
タ型について説明します。
IDS
Dynamic Server でサポートされている拡張データ型については、第 7 章「Dynamic
Server での拡張データ型の作成と使用」を参照してください。♦
データ型の選択
表内のすべての列は、データベース サーバがサポートしているデータ型から選択し
たデータ型を持っていなければなりません。データ型の選択が重要である理由を、
次に示します。
3-4
■
列のデータ型を選択すると、その列に格納できる有効なデータ項目の集合
である基本ドメインが確立される。
■
データに対して実行できる操作の種類が決定される。たとえば、文字デー
タ型で定義された列に対しては SUM などの集計関数は適用できない。
■
ひとつひとつのデータが占有するディスク領域の大きさは、データ型に
よって決まる。行数が 10 あるいは数千の小さな表の場合、データ項目に
割り当てる領域の大きさを考慮する必要がない。表の行数が多くなると、
4 バイトと 8 バイトの差が重要になってくる。
Informix Guide to Database Design and Implementation
データ型
参照制約でのデータ型の使用方法
主キーと外部キーに対して列を選択するとき、ほとんどすべてのデータ型の組合せ
が一致する必要があります。たとえば、主キーを文字 (CHAR) 型で定義した場合、
外部キーも文字 (CHAR) 型で定義しなければなりません。しかし、ある表の主キー
にシリアル (SERIAL) 型を指定している場合は、関係する外部キーに整数
(INTEGER) 型を指定します。同じように、ある表の主キーに 8 バイト シリアル
(SERIAL8) 型を指定している場合は、関係する外部キーに 8 バイト整数 (INT8) 型を
指定します。任意の関係内で一緒に使用できるデータ型の組合せは、次の 2 つだけ
です。
IDS
■
シリアル (SERIAL) 型と整数 (INTEGER) 型
■
8 バイト シリアル (SERIAL8) 型と 8 バイト整数 (INT8) 型 ♦
3-6 ページの 図 3-1 に、データ型間の選択を要約したデシジョン ツリーを示します。
これらの選択については、以降の項で説明します。
データ型の選択
3-5
データ型
図 3-1
データ型の選択
データ項目が純粋に
数値である
はい
いいえ
すべての数値が
整数である
いいえ
はい
すべての数値が -(215-1)
と 215-1 の間にある
いいえ
小桁整数 (SMALLINT) 型
すべての数値が -(231-1)
と 231-1 の間にある
いいえ
はい
整数 (INTEGER) 型
すべての数値が -(264-1)
と 264 -1 の間にある
いいえ
はい
はい
8 バイト整数 (INT8) 型
10 進数 (DECIMAL) 型 (p,0)
小数点以下の桁数が
固定されている
いいえ
最大桁数が 8 桁
以下である
いいえ
最大桁数が 16 桁
以下である
いいえ
はい
10 進数 (DECIMAL) 型 (p,s)
はい
小桁実数 (SMALLFLOAT) 型
はい
実数 (FLOAT) 型
10 進数 (DECIMAL) 型 (p)
(1/2)
3-6
Informix Guide to Database Design and Implementation
データ型
データは時を表す
ものである
はい
いいえ
時間を表すか時刻を表
すか
時刻
時間
データはブール
はい
(BOOLEAN) 型である
ブール (BOOLEAN) 型
いいえ
日付のみである
時間隔 (INTERVAL) 型
はい
いいえ
データに英字以外の
文字が含まれている
はい
いいえ
日付 (DATE) 型
日時 (DATETIME) 型
データの長さは大き
く変化しない
いいえ
はい
各国語文字 (NCHAR) 型 (n)
各国語可変長文字 (NVARCHAR) 型 (m,r)
データは ASCII 文字列
である
はい
いいえ
データの長さは大き
く変化しない
はい
いいえ
はい
長さが 32,767 バイト
以下である
はい
データのどの場所に対し
ても読書きをする
文字 (CHAR) 型 (n)
いいえ
BLOB 型
いいえ
はい
255 バイト以上の長さ
である
ラージ可変長文字
(LVARCHAR) 型
いいえ
データのどの場所に対し はい
ても読書きをする
バイト (BYTE) 型
いいえ
可変長文字 (VARCHAR) 型 (m,r) または
CLOB 型
可変長文字 (CHARACTER VARYING) 型 (m,r) テキスト (TEXT) 型
(2/2)
データ型の選択
3-7
データ型
数値データ型
Informix データベース サーバでは、8 種類の数値データ型をサポートしています。
カウンタやコードに適したもの、科学技術分野の数値計算に適したもの、金額に適
したものなどがあります。
カウンタとコード整数 (INTEGER) 型、小桁整数 (SMALLINT) 型、および 8
バイト整数 (INT8) 型
整数 (INTEGER) 型と小桁整数 (SMALLINT) 型は、桁数の少ない整数を格納する
データ型です。カウント値、順序番号、数値による識別コード、格納される値の最
大値と最小値があらかじめわかっている整数値などを格納する列に指定するのに適
しています。
この 2 つのデータ型の値は、両方ともに 2 進数の整数として格納されます。整数
(INTEGER) 型の値は 32 ビット長で、231 から 231-1 の範囲にある整数を表すことが
できます。
小桁整数型 (SMALLINT) 型の値は、16 ビット長です。これらは、-32,767 から
32,767 の範囲にある値を表すことができます。
整数 (INT) 型と小桁整数 (SMALLINT) 型には次の利点があります。
■
占有する領域が小さい。小桁整数 (SMALLINT) 型の場合は 1 つの値あたり
2 バイト、整数 (INTEGER) 型の場合は 1 つの値あたり 4 バイトを占有しま
す。
■
これらのデータ型の列に対しては、SUM や MAX などの算術式、ソートや
比較を実行できる。
整数 (INTEGER) 型および小桁整数 (SMALLINT) 型を使用する場合の不利な点は、
格納できる値の範囲が制限されることです。範囲外の値を格納することはできませ
ん。もちろん、格納すべき最大値と最小値がわかっている場合は、このような制限
超過は問題になりません。
IDS
3-8
8 バイト整数 (INT8) 型をサポートしているのは Dynamic Server だけです。8 バイト
整数 (INT8) 型は、符号付きバイナリ整数として格納されます。このデータ型では、
値ごとに 8 バイトが使用されます。8 バイト整数 (INT8) 型データは、整数
(INTEGER) 型の 2 倍の領域を使用しますが、8 バイト整数 (INT8) 型には、データ表
現の範囲が大幅に大きくなるという利点があります。8 バイト整数 (INT8) 型は、(2 63 -1) ∼ 2 63 -1 の範囲の整数を表すことができます。♦
Informix Guide to Database Design and Implementation
データ型
自動シーケンス : シリアル (SERIAL) 型と 8 バイト シリアル (SERIAL8) 型
シリアル (SERIAL) 型は、特別の機能を持った整数 (INTEGER) 型です。同じよう
に、8 バイト シリアル (SERIAL8) 型も、特別の機能を持った 8 バイト整数 (INT8) 型
です。表に新しい行が挿入されると必ず、シリアル (SERIAL) 型または 8 バイト シ
リアル (SERIAL8) 型の列に対し、データベース サーバは自動的に新しい値を生成し
ます。
IDS
8 バイト シリアル (SERIAL8) 型をサポートしているのは Dynamic Server だけです。
♦
表に含むことのできるシリアル (SERIAL) 型または 8 バイト シリアル (SERIAL8) 型
列は 1 つだけです。ただし、シリアル (SERIAL) 型列と 8 バイト シリアル
(SERIAL8) 型列を両方とも 1 つずつ含むことができます。シリアル型の列の値は
データベースにより生成されるため、複数のユーザが同時に行を追加している場合
でも、追加される行のシリアル型の列には常に違う値が入ります。このような条件
下にあるとき、通常のプログラムで一意の数値コードを新しく生成することは非常
に困難なため、この機能はきわめて有益です。
シリアル (SERIAL) 型では、最大 231-1 の正の整数を生成できます。この結果、デー
タベース サーバは、231-1 個の行を表に挿入する時点までにすべての正のシリアル
番号を使用します。正のシリアル番号をすべて使い切るには、単一のアプリケー
ションなら 68 年間毎秒 1 行を挿入する必要があり、アプリケーションが 68 個あっ
ても 1 年間毎秒 1 行挿入する必要があるため、ほとんどのユーザで、正のシリアル
番号の不足が問題になることはありません。正のシリアル番号がすべて使用されて
しまうと、データベース サーバは引き続き新しい数値を生成します。データベース
サーバでは、整数の最大値を符号付きの整数として扱います。データベース サーバ
では正の値のみを使用するため、1 から始まる整数値が繰り返し生成されることに
なります。
8 バイト シリアル (SERIAL8) 型データは、最大 263 -1 の正の値を生成できます。適
切な開始値を使用しても、挿入操作中に 8 バイト シリアル (SERIAL8) 型値を繰り返
すことは事実上不可能です。
シリアル (SERIAL) 型と 8 バイト シリアル (SERIAL8) 型の場合、生成される番号の
シーケンスは必ず増加します。表から削除された行のシリアル番号が再び使用され
ることはありません。シリアル (SERIAL) 型または 8 バイト シリアル (SERIAL8) 型
の列でソートされる行は、それらの行が作成された順序で戻されます。これは、シ
リアル型だけの特徴です。
CREATE TABLE 文を使用して、シリアル (SERIAL) 型または 8 バイト シリアル
(SERIAL8) 型の列に開始値を指定することができます。したがって、表ごとに開始
値の異なるシステム割当てキーを自動的に生成することができます。データベース
stores_demo では、この手法が使用されています。stores_demo では、顧客番号が
101 から、注文番号が 1001 から始まっています。この小規模の業者が登録する顧客
の数が 899 を超えない限り、顧客番号はすべて 3 桁に、注文番号は 4 桁になります。
データ型の選択
3-9
データ型
シリアル (SERIAL) 型または 8 バイト シリアル (SERIAL8) 型の列は、自動的には一
意の列になりません。重複するシリアル番号が絶対に発生することがないようにす
るには、一意性制約を設定する必要があります。4-6 ページの「CREATE TABLE 文
の使用方法」を参照してください。DB-Access または SQL エディタで対話型スキー
マ エディタを使用して表を定義する場合、この表では自動的にシリアル (SERIAL)
型列または 8 バイト シリアル (SERIAL8) 型列に一意性制約が適用されます。
シリアル (SERIAL) 型と 8 バイト シリアル (SERIAL8) 型には次の利点があります。
■
システム割当てキーを手軽に作成できます。
■
複数のユーザが表を更新しているときでも一意の数値コードを生成しま
す。
■
生成される数値の範囲を表ごとに変えることができます。
シリアル (SERIAL) 型と 8 バイト シリアル (SERIAL8) 型の不都合な点は次のとおり
です。
■
各表には、シリアル (SERIAL) 型または 8 バイト シリアル (SERIAL8) 型列
が 1 列しか許されていません。
■
任意数しか生成できません。
次のシリアル (SERIAL) 型と 8 バイト シリアル (SERIAL8) 型の数の変更
シリアル (SERIAL) 型または 8 バイト シリアル (SERIAL8) 型の開始値は、この列が
作成されるときに設定されます。4-6 ページの「CREATE TABLE 文の使用方法」を
参照してください。列の作成後に、ALTER TABLE 文を使用すれば、次の値をリ
セットすることができます。次の値とは、次に挿入される行に使用される値を指し
ます。
列の現行の最大値より小さい値を次の値に設定することはできません。それを行う
と、データベース サーバが状況によって重複する数値を生成してしまうためです。
ただし、現行の最大値より大きい値に対してなら次の値を設定できるため、間を空
けてシリアル番号を生成することになります。
近似値 : 実数 (FLOAT) 型と小桁実数 (SMALLFLOAT) 型
科学技術や統計のアプリケーションで扱われる数値の多くは、有効数字が数桁のみ
で、数値の大きさが数値の正確な桁数と同じくらいに重要です。
3-10
Informix Guide to Database Design and Implementation
データ型
浮動小数点データ型はこのような種類のアプリケーションのために用意されていま
す。整数でも小数部を含む数値でも、あらゆる数値を表現でき、数値の大きさの範
囲は宇宙的規模から顕微鏡的規模に及びます。たとえば、地球から太陽までの平均
距離 (1.5 × 109 メートル ) もプランク定数 (6.625 × 10-27) も簡単に表すことができま
す。ただし、このデータ型は、精度に限りがあります。浮動小数点数は、数値の最
上位の数字のみ保持します。格納可能な桁数以下の数値ならば正確に格納されま
す。しかし、格納可能な桁数を超える数値は、近似値の形、つまり最下位の数字が
ゼロとして扱われる形で格納されます。
このような不正確さは多くのユーザにとって有益ですが、最下位の数字がゼロに
なってはならない金額や他の量を記録するのに浮動小数点を使用してはなりませ
ん。
浮動小数点用のデータ型には 2 種類のサイズがあります。実数 (FLOAT) 型は、倍精
度の 2 進の浮動小数点数を格納するためのデータ型で、C 言語に実装されています。
通常、実数 (FLOAT) 型の値には最大 8 バイトが必要です。小桁実数 (REAL) 型とも
呼ばれる小桁実数 (SMALLFLOAT) 型は、通常、最大 4 バイトを必要とする単精度
の 2 進浮動小数点数です。この 2 つのデータ型の主な違いは精度です。
浮動小数点用のデータ型には次の利点があります。
■
非常に大きな数値や非常に小さな数値を格納し、小数部を持つ数値も格納
する。
■
4 バイトまたは 8 バイトで数値を簡潔に表現する。
■
浮動小数点用のデータ型の列に対しては、AVG や MIN などの算術関数や、
ソート、比較を効率よく実行できる。
主な欠点は、精度の範囲を超える桁がゼロとして扱われることです。
精度を調整可能な浮動小数点数 :10 進数 (DECIMAL) 型 (p)
10 進数 (DECIMAL) 型 (p) は、実数 (FLOAT) 型や小桁実数 (SMALLFLOAT) 型に似
た浮動小数点データ型です。実数型や小桁実数型との主な違いは、有効数字の桁数
( 精度 ) を指定できることです。p で表される精度は 1 ∼ 32 の範囲をとることがで
き、小桁実数 （SMALLFLOAT）型の精度より少なく、実数 (FLOAT) 型の精度の 2
倍までが可能です。
10 進数 (DECIMAL) 型 (p) の数値の大きさの範囲は、10-130 ∼ 10124 です。
10 進数型には固定小数点形式のものもあり、混乱しやすいので注意が必要です。こ
の節で説明している 10 進数 (DECIMAL) 型 (p) は、精度のみを指定する 10 進数
(DECIMAL) 型です。10 進数 (DECIMAL) 型 (p) の数値が占める記憶域の大きさは、
その精度によって異なります。各数値が占める領域は、1 + p/2 バイトです。必要
に応じて、小数点以下の端数は切り上げられます。
データ型の選択
3-11
データ型
10 進数 (DECIMAL) 型 (p) は、実数 (FLOAT) 型と比較すると次のような利点を持っ
ています。
■
低精度から高精度まで、アプリケーションにあった精度を設定できる。
■
最大 32 桁の数値を正確に表現できる。
■
占有する記憶域の大きさは、数値の精度に比例する。
■
使用できる精度と値の範囲は、ホスト オペレーティング システムとは無
関係に Informix データベース サーバでサポートされる。
10 進数 (DECIMAL) 型 (p) の欠点は次のとおりです。
■
10 進数 (DECIMAL) 型 (p) の値の算術計算やソートは、実数 (FLOAT) 型の
値の場合よりいくらか遅くなります。
■
多くのプログラミング言語では、実数 (FLOAT) 型や整数 (INTEGER) 型が
サポートされているのと同じ方法では、10 進数 (DECIMAL) 型 (p) はサ
ポートされていません。プログラムでデータベースから 10 進数
(DECIMAL) 型 (p) 値を抽出する場合は、処理が行えるようにその値を別の
形式に変換する必要があります。
固定小数点数 :10 進数 (DECIMAL) 型と金額 (MONEY) 型
ほとんどのビジネス アプリケーションが格納しなければならない数値は、整数部と
小数部の桁数が決まっています。このような数値の例としてもっとも一般的なもの
は金額です。米国などのいくつかの国々の通貨は、小数部が 2 桁で記述されます。
通常記録されるトランザクションの種類によって、左側 ( 整数部 ) に必要な桁数は
わかっています。おそらく、家計などでは 5 桁、小規模のビジネスでは 7 桁、国家
予算などでは 12 から 13 桁でしょう。
この種の数値は、値の大きさとは無関係に特定の位置に小数点が固定されるため、
固定小数点数と呼ばれています。10 進数 (DECIMAL) 型 (p,s) は、10 進数を格納す
るためのデータ型です。この型の列を指定する場合、格納できる合計桁数として 1
から 32 までの精度 (p) を指定することができます。小数点以下桁数 (s) を小数点の
右側の桁数として指定します。図 3-2 に、精度と小数点以下桁数の関係を示してい
ます。小数点以下桁数がゼロになる場合もあり、これはその数値が整数であること
を意味しています。整数のみが格納される場合、10 進数 (DECIMAL) 型 (p,s) は最大
32 桁までの整数を格納できます。
図 3-2
精度と小数点以下
桁数
精度 :8 桁
DECIMAL(8,3)
31964.535
小数点以下桁数 :3 桁
3-12
Informix Guide to Database Design and Implementation
データ型
10 進数 (DECIMAL) 型 (p) と同様に、10 進数 (DECIMAL) 型 (p,s) もその精度に比例
した領域を必要とします。各値は、小数点以下桁数が偶数の場合は (p +3)/2 バイト
を占め、小数点以下桁数が奇数の場合は (p + 4)/2 バイトを占め、整数バイトに丸め
られます。
金額 (MONEY) 型は、10 進数 (DECIMAL) 型 (p,s) と同じです。ただし、機能が 1 つ
追加されています。表示のために金額 (MONEY) 型の数値が文字型に変換されると
きには必ず、通貨記号が自動的に追加されます。
整数（INTEGER）型や実数 (FLOAT) 型に対する 10 進数 (DECIMAL) 型 (p,s) の利点
は、整数 (INTEGER) 型の 10 桁や実数 (FLOAT) 型の 16 桁に比べて最大 32 桁という
多数の有効桁数を使用することができ、精度と必要な記憶域の大きさの両方をアプ
リケーションに合わせて調整できるということです。
10 進数 (DECIMAL) 型 (p,s) の欠点は、算術計算の効率が低いことと、プログラミン
グ言語の多くがこの形式の数値をサポートしていないということです。したがっ
て、プログラムでこの数値を抽出する場合、通常は、処理が行えるようにその数値
を別の数値形式に変換しなければなりません。
通貨フォーマットの選択
GLS
金額の表しかたは国によって異なります。Informix データベース サーバでは、金額
(MONEY) 型の値を表示する場合、ユーザが指定した通貨形式を参照します。デ
フォルトのロケールは、次のような形式の米国英語の通貨フォーマットです。
$7,822.45
英語以外のロケールについては、ロケール ファイルの MONETARY カテゴリで通
貨形式を変更することができます。ロケールの使用方法の詳細については、
『Informix Guide to GLS Functionality』を参照してください。♦
この通貨形式をカスタマイズするには、適切なロケールを選択するか、環境変数
『Informix Guide to SQL: Reference』
DBMONEY を設定します。詳細については、
を参照してください。
日付、時間に関するデータ型
Informix データベース サーバでは、時刻を記録するために 3 種類のデータ型をサ
ポートしています。日付 (DATE) 型は日付を格納します。日時 (DATETIME) 型は、
時刻を年から 1 秒以下 ( 小数で表現される ) までの精度で記録します。時間隔
(INTERVAL) 型はある時点からある時点までの時間の間隔、つまり継続時間を格納
します。
データ型の選択
3-13
データ型
日付 : 日付 (DATE) 型
日付 (DATE) 型は日付を格納します。日付 (DATE) 型の値は、実際には 1899 年 12
月 31 日午前 0 時を起点として数えた日数を示す符号付き整数として格納されます。
通常、日付型は今世紀の日付を示す正の整数を格納します。
日付 (DATE) 型のフォーマットは、はるか未来 (58,000 世紀 ) までの日付に対応でき
る精度を持っています。負の日付 (DATE) 型の値は、起点 (1899 年 12 月 31 日午前 0
時 ) から昔にさかのぼって数えた日数を意味します。つまり、日付 (DATE) 型の値
-1 は 1899 年 12 月 30 日を示します。
日付 (DATE) 型の値は整数のため、Informix データベース サーバで算術式に使用で
きます。たとえば、日付 (DATE) 型列の平均を求めたり、日付 (DATE) 型の列に 7 や
365 を加算することができます。さらに、特に日付 (DATE) 型値を操作するための
豊富な関数セットをサポートしています。詳細については、
『Informix Guide to
SQL: Syntax』を参照してください。
日付 (DATE) 型は、項目 1 つにつき 4 バイトを占有します。算術関数や比較は、日
付 (DATE) 型の列に対しては迅速に実行されます。
GLS
日付型フォーマットの選択
日付コンポーネントの表記方法には多くの種類があります。Informix データベース
サーバでは、日付 (DATE) 型の値を表示する場合、ユーザが指定した日付型フォー
マットを参照します。デフォルトのロケールは、次のような形式の米国英語の日付
型フォーマットです。
10/25/98
この日付フォーマットをカスタマイズするには、適切なロケールを選択するか、環
境変数 DBDATE を設定します。詳細については、
『Informix Guide to SQL:
Reference』を参照してください。
英語以外の言語については、ロケール ファイルの TIME カテゴリで日付型フォー
マットを変更することもできます。ロケールの使用方法の詳細については、
『Informix Guide to GLS Functionality』を参照してください。
3-14
Informix Guide to Database Design and Implementation
データ型
時刻 : 日時 (DATETIME) 型
日時 (DATETIME) 型は、A.D.1 年から開始される年代 ( 西暦 ) の任意の時刻を格納
します。日時 (DATETIME) 型は、実際には、精度が異なる 28 種類のデータ型に対
する総称です。日時 (DATETIME) 型 の列を定義するときには、その精度を指定し
ます。列には、年、月、日、時間、分、秒、および 小数部のリストから任意のシー
ケンスを選択して格納することができます。したがって年のみ、月と日のみ、日と
単なる時間またはミリ秒まで指定した時間のみを格納する 日時 (DATETIME) 型の
列を定義することができます。日時 (DATETIME) 型の値のサイズは、3-15 ページの
図 3-3 に示すように、精度によって 2 から 11 バイトまでの範囲にわたります。
日時 (DATETIME) 型 の利点は、特定の日付と時刻を格納できることです。日時
(DATETIME) 型列は 日付 (DATE) 型列よりも格納領域を多く必要とするのが普通
で、これは使用する DATETIME 修飾子によって異なります。また、日時
(DATETIME) 型では、その表示フォーマットは柔軟性に欠けています。表示フォー
マットを変更するには、3-16 ページの「日時 (DATETIME) 型または時間隔
(INTERVAL) 型のフォーマット」を参照してください。
精度
サイズ *
精度
サイズ *
year to year
year to month
year to day
year to hour
year to minute
year to second
year to fraction(f)
month to month
month to day
month to hour
month to minute
month to second
month to fraction(f)
day to day
3
4
5
6
7
8
8 + f/2
2
3
4
5
6
6 + f/2
2
day to hour
day to minute
day to second
day to fraction(f)
hour to hour
hour to minute
hour to second
hour to fraction(f)
minute to minute
minute to second
minute to fraction(f)
second to second
second to fraction(f)
fraction to fraction(f)
3
4
5
5 + f/2
2
3
4
4 + f/2
2
3
3 + f/2
2
2 + f/2
1 + f/2
図 3-3
日時 (DATETIME)
型の精度
* f が奇数の場合は、バイト数は偶数になるように切り上げられます。
期間 : 時間隔 (INTERVAL) 型
時間隔 (INTERVAL) 型は、継続時間、つまり、時間の長さを格納します。2 つの日
時 (DATETIME) 型値の差が、その間の時間の長さを表す時間隔 (INTERVAL) 型 の
値になります。違いがわかりやすくなるように、例をいくつか示します。
■
ある女性社員が、1997 年 1 月 21 日 ( 日付 (DATE) 型または日時
(DATETIME) 型 ) に入社しました。
データ型の選択
3-15
データ型
■
彼女は 254 日間勤務しました。これが時間隔 (INTERVAL) 型値、つまり
TODAY 関数と、開始の日付 (DATE) 型値または日時 (DATETIME) 型値の
間の差になります。
■
毎日 9:00 に勤務を開始しました ( 日時 (DATETIME) 型 の値 )。
■
1 日 8 時間 ( 時間隔 (INTERVAL) 型値 ) 働き、昼食に 45 分間 ( 別の時間隔
(INTERVAL) 型値 ) 休憩をとります。
■
彼女が勤務を終了する時間は 17 時 45 分 ( 勤務開始時刻を示す 日時
(DATETIME) 型 値と 2 つの時間隔 (INTERVAL) 型値の合計 ) です。
日時 (DATETIME) 型と同様に、時間隔 (INTERVAL) 型も異なる精度を持つ型の集
合です。時間隔 (INTERVAL) 型の値は、年数や月数を表すことができます。また日
数、時間数、分数、秒数、秒以下の数を表すこともできます。18 桁の精度が可能で
す。時間隔 (INTERVAL) 型値のサイズは、図 3-4 に示すように、公式によって 2 か
ら 12 バイトまでの範囲にわたります。
精度
サイズ *
精度
サイズ *
year(p) to year
year(p) to month
month(p) to month
day(p) to day
day(p) to hour
day(p) to minute
day(p) to second
day(p) to fraction(f)
hour(p) to hour
1 + p/2
2 + p/2
1 + p/2
1 + p/2
2 + p/2
3 + p/2
4 + p/2
5 + (p + f)/2
1 + p/2
hour(p) to minute
hour(p) to second
hour(p) to fraction(f)
minute(p) to minute
minute(p) to second
minute(p) to fraction(f)
second(p) to second
second(p) to fraction(f)
fraction to fraction(f)
2 + p/2
3 + p/2
4 + (p + f)/2
1 + p/2
2 + p/2
3 + (p + f)/2
1 + p/2
2 + (p + f)/2
1 + f/2
図 3-4
時間隔
(INTERVAL) 型の
精度
* バイト数は偶数になるように切り上げられます。
時間隔 (INTERVAL) 型の値は、正のことも負のこともあります。時間隔
(INTERVAL) 型の値は加算や減算に使用したり、他の値を掛けたり他の値で割った
りすることもできます。日付 (DATE) 型や日時 (DATETIME) 型の値に対しては、こ
のような演算はできません。
「4 月 23 日までの日数の半分は何日か」という問いは
理にかなっていますが、
「4 月 23 日の半分は何日か」という問いは無意味です。
日時 (DATETIME) 型または時間隔 (INTERVAL) 型のフォーマット
データベース サーバは常に、時間隔 (INTERVAL) 型や日時 (DATETIME) 型の値の
コンポーネントを < 年 >-< 月 >-< 時 >:< 分 >:< 秒 >.< 小数部 > のフォーマットで表
示します。日付 (DATE) 型の値をフォーマットするときなどとは違い、オペレー
ティング システムに定義された日付フォーマットは参照されません。
3-16
Informix Guide to Database Design and Implementation
データ型
日時 (DATETIME) 型値の日付部分を、システムに定義されているフォーマットで表
示する場合は、SELECT 文を使用します。まず、EXTEND 関数を使用してコンポー
ネント フィールドを分離します。次に、MDY() 関数を使用してこのフィールドを
引き渡します。MDY() 関数を使用すると、これらのフィールドが日付 (DATE) 型に
変換されます。次のコードはこの例の一部を示したものです。
SELECT ... MDY (
EXTEND (DATE_RECEIVED, MONTH TO MONTH),
EXTEND (DATE_RECEIVED, DAY TO DAY),
EXTEND (DATE_RECEIVED, YEAR TO YEAR) )
FROM RECEIPTS ...
GLS
日時 (DATETIME) 型フォーマットの選択
Informix データベース サーバでは、日時 (DATETIME) 型の値を表示する場合、
ユーザが指定した 日時 (DATETIME) 型フォーマットを参照します。デフォルトの
ロケールは、次のような形式の米国英語の 日時 (DATETIME) 型フォーマットです。
1998-10-25 18:02:13
英語以外の言語については、ロケール ファイルの TIME カテゴリを使用して、日時
(DATETIME) 型フォーマットを変更することができます。ロケールの使用方法の詳
細については、
『Informix Guide to GLS Functionality』を参照してください。
この日時 (DATETIME) 型フォーマットをカスタマイズするには、適切なロケールを
選択するか、環境変数 GL_DATETIME または DBTIME を設定します。これらの環
境変数の詳細については、
『Informix Guide to GLS Functionality』を参照してくだ
さい。
IDS
ブール (BOOLEAN) 型
ブール (BOOLEAN) 型は、1 バイト データ型の 1 つです。DB-Access またはリレー
ショナル オブジェクト マネージャでは、正当な値は、真 ('t')、偽 ('f')、または
NULL です。これらの値は、大文字と小文字を区別しません。
次の表に、ブール (BOOLEAN) 型データを表す方法を示します。
ブール (BOOLEAN) 型表現 内部表現
リテラル表現
TRUE ( 真 )
¥1
't'、'T'
FALSE ( 偽 )
¥0
'f'、'F'
NULL
内部用途のみ
NULL
データ型の選択
3-17
データ型
ブール (BOOLEAN) 型列を別のブール (BOOLEAN) 型列やブール (BOOLEAN) 型値
('t'、'f') と比較することができます。たとえば、次の表を作成するとします。
CREATE TABLE emp_info
(
emp_id INTEGER,
bool_col BOOLEAN
);
次の問合せを行うと、bool_col 値が真になっている表 emp_info から行が戻されま
す。
SELECT *
FROM emp_info
WHERE bool_col = 't';
次の問合せを行うと、bool_col 値が NULL になっている表 emp_info から行が戻さ
れます。
SELECT *
FROM emp_info
WHERE bool_col IS NULL;
次の例に示されているように、ブール (BOOLEAN) 型が割り当てられた列を使用し
ても、式の結果を得ることができます。
UPDATE emp_info
SET bool_col = (1 < 2)
WHERE emp_id = 439
GLS
文字型
Informix データベース サーバでは、文字 (CHAR) 型、各国語文字 (NCHAR) 型、特
殊用途の文字データ型である各国語可変長文字 (NVARCHAR) 型などの文字型をサ
ポートしています。
文字データ : 文字 (CHAR) 型 (n) と各国語文字 (NCHAR) 型 (n)
文字 (CHAR) 型 (n) は、n バイトのシーケンスを格納します。これらの文字には英
語と英語以外の文字を混在させることができ、1 バイトまたはマルチバイト ( アジ
ア諸語 ) のどちらにもなります。長さ n は、1 ∼ 32,767 の範囲で指定できます。
3-18
Informix Guide to Database Design and Implementation
データ型
データベース サーバが文字 (CHAR) 型 (n) 値を抽出したり格納したりする場合は必
ず、正確に n バイトが転送されます。挿入される値が n バイトよりも短い場合、
データベース サーバは 1 バイトの ASCII 空白文字を使用して、その値を n バイトま
で拡張します。挿入される値が n バイトを超過する場合、データベース サーバはエ
ラー メッセージを戻さずに超過する分の文字を切り捨てます。したがって、挿入ま
たは更新された値が n バイトを超過していても、文字 (CHAR) 型 (n) 列および変数
データの意味整合性が強制的に適用されることはありません。
文字 (CHAR) 型列のデータは、コード セットの順序でソートされます。たとえば、
ASCII コード セットでは、a はコード セット値 97、b は 98 などのように値を持って
います。データベース サーバは、文字 (CHAR) 型 (n) データをこの順序でソートし
ます。
各国語文字 (NCHAR) 型 (n) にも連続する n バイトが含まれています。これらの文
字には英語と英語以外の文字を混在させることができ、1 バイトまたはマルチバイ
ト ( アジア諸語 ) のどちらにもなります。n という長さには 文字 (CHAR) 型 (n) と同
じ制限があります。各国語文字 (NCHAR) 型 (n) の値が抽出または格納される場合
は必ず、正確に n バイトが転送されます。データにマルチバイト文字が含まれてい
る場合、転送される文字数はバイト数より小さくなります。挿入される値が n バイ
トよりも短い場合、データベース サーバは 1 バイトの ASCII 空白文字を使用して、
その値を n バイトまで拡張します。
ヒント : データベース サーバは、ロケールの定義に従って 1 バイトまたはマルチバ
イトの空白で拡張された値を受け入れます。
データベース サーバは、各国語文字 (NCHAR) 型 (n) の列のデータを、ロケールが
指定する順序でソートします。たとえば、フランス語のロケールでは、 ê は、値 e
の後、値 f の前にソートされるように指定しています。つまり、フランス語のロ
ケールによって決定されるソート順序は、e、 ê、f の順になります。ロケールの使
用方法の詳細については、
『Informix Guide to GLS Functionality』を参照してくだ
さい。
ヒント : 文字 (CHAR) 型 (n) のデータと各国語文字 (NCHAR) 型 (n) のデータの違い
は、ソートと比較の方法です。文字 (CHAR) 型 (n) 列には英語以外の文字を格納す
ることができます。ただし、データベース サーバはコード セット順序を使用して
文字 (CHAR) 型 (n) 列のソートや比較を行うため、予期した順序での結果が得られ
ない場合もあります。
文字 (CHAR) 型 (n) または各国語文字 (NCHAR) 型 (n) の値にはタブと空白を含めて
もかまいませんが、このほかの印字不可能な文字は含めないでください。INSERT
文または UPDATE 文を使用して行を挿入する場合や、ユーティリティ プログラム
で行をロードする場合には、印字不可能な文字は入力されません。しかし、埋込み
SQL を使用するプログラムによって行を作成する場合は、NULL (2 進のゼロ ) 文字
以外の任意の文字を挿入できます。標準的なプログラムやユーティリティは印字不
可能な文字を予測していないため、印字不可能な文字を文字型の列には格納しない
でください。
データ型の選択
3-19
データ型
文字 (CHAR) 型 (n) や各国語文字 (NCHAR) 型 (n) の利点は、
すべてのデータベース
サーバで使用できるということです。文字 (CHAR) 型 (n) や各国語文字 (NCHAR)
型 (n) の唯一の欠点は、固定長であるということです。データ値の長さが行ごとに
大きく異なる場合は、空白部分が無駄になります。
可変長文字 : 可変長文字 (CHARACTER VARYING) 型 (m,r)、可変長文字
(VARCHAR) 型 (m,r)、各国語可変長文字 (NVARCHAR) 型 (m,r)、および
ラージ可変長文字 (LVARCHAR) 型
次のデータ型のそれぞれについて、m は最大バイト数、r は最小バイト数を表しま
す。
ヒント : 可変長文字 (CHARACTER VARYING) 型 (m,r) は ANSI 標準準拠です。可変
長文字 (VARCHAR) 型 (M,R) は Informix データ型です。
文字型列の項目は、長さが一定でないことがよくあります。多くは平均的な長さ
で、最大長のデータはわずかにすぎません。このようなデータを格納する際にディ
スク領域を節約するため、次のデータ型が用意されています。
IDS
■
可変長文字 (CHARACTER VARYING) 型 (m,r)。可変長文字
(CHARACTER VARYING) 型 (m,r) は、最大 m バイト、最小 r バイトの
シーケンスを格納します。このデータ型は、可変長文字データの ANSI 標
準準拠のフォーマットです。可変長文字 (CHARACTER VARYING) 型
(m,r) は、文字データの比較にコード セット順序をサポートしています。
■
可変長文字 (VARCHAR) 型 (m,r)。可変長文字 (VARCHAR) 型 (M,R) は、
可変長の文字データを格納するための Informix 固有のデータ型です。機能
的には可変長文字 (CHARACTER VARYING) 型 (M,R) と同じです。
■
各国語可変長文字 (NVARCHAR) 型 (M,R)。各国語可変長文字
(NVARCHAR) 型 (M,R) も、可変長の文字列データを格納するための
Informix 固有のデータ型です。これは、ロケールが指定する順序で文字
データを比較します。
■
ラージ可変長文字 (LVARCHAR) 型。ラージ可変長文字 (LVARCHAR) 型
は、256 バイトより大きく 2 KB より小さい値の可変長の文字データを格納
するための Informix 固有のデータ型です。ラージ可変長文字
(LVARCHAR) 型では、そのデータ型の比較のためにコード セット順序が
サポートされています。♦
ヒント : このデータ比較方法の違いによって、各国語可変長文字 (NVARCHAR) 型
(m,r) のデータと可変長文字 CHARACTER VARYING 型 (m,r) や可変長文字
(VARCHAR) 型 (m,r) のデータが区別されます。ロケールによって決定されるコード
セットとソート順序については、3-18 ページの「文字データ : 文字 (CHAR) 型 (n)
と各国語文字 (NCHAR) 型 (n)」を参照してください。
3-20
Informix Guide to Database Design and Implementation
データ型
これらのデータ型の列を定義する場合、最大バイト数として m を指定します。挿入
される値が m バイトより少ないバイト数で構成されている場合も、文字 (CHAR) 型
(n) や各国語文字 (NCHAR) 型 (N) の値のように、データベース サーバが 1 バイトの
空白でその値を拡張することはありません。その代わりに、実際の内容のみを 1 バ
イト フィールドでディスクに格納します。インデックス付き列の場合の m の上限
は 254 バイト、インデックスなしの列の場合の m の上限は 255 バイトです。
2 番めのパラメータ r は、ディスクに格納される値に必要なバイト数の下限を設定
するオプションの予約長です。値が r バイトより少ないバイト数しか必要としない
場合でも、その値を保持するために常に r バイトが割り当てられます。このように
下限を設定するのは、行の更新時間を節約するためです。3-21 ページの「可変長文
字と実行時間」を参照してください。
可変長文字 (CHARACTER VARYING) 型 (m,r) または可変長文字 (VARCHAR) 型
(M,R) には、文字 (CHAR) 型 (n) と比較して次の利点があります。
■
データ項目に必要なバイト数が広範囲に変化したり、少数の項目のみが平
均以上のバイト数を必要としたりする場合に、ディスク領域を一定に保
つ。
■
小規模な表に対する問合せを高速化できる。
これらの利点は、各国語文字 (NCHAR) 型 (N) よりも各国語可変長文字
(NVARCHAR) 型 (M,R) に当てはまる特徴です。
可変長データ型の欠点は次のとおりです。
■
255 バイトを超える長さは許されない。
■
環境によっては表更新の速度が遅くなる。
■
Informix データベース サーバでは使用できない。
可変長文字と実行時間
可変長文字 (CHARACTER VARYING) 型 (m,r)、可変長文字 (VARCHAR) 型 (m,r)、
各国語可変長文字 (NVARCHAR) 型 (m,r) のいずれかを使用すると、表の行は固定
したバイト数の代わりにさまざまなバイト数を持つことになります。表の行がさま
ざまなバイト数を持っていると、データベース操作の速度はその影響を受けます。
ディスクの 1 ページにより多くの行が格納されるため、データベース サーバは、行
が固定したバイト数を持っている場合より少ないディスク操作で表を探索すること
ができます。その結果、問合せの実行速度は速くなります。挿入操作と削除操作に
ついても、同じ理由から多少速くなることがあります。
データ型の選択
3-21
データ型
行を更新する場合、データベース サーバの作業量は、もとの行のバイト数より新し
い行のバイト数に依存します。新しい行のバイト数がもとの行のバイト数以下であ
れば、実行時間は固定長の行の場合とそれほど変わりません。しかし、新しい行が
もとの行よりかなり多いバイト数を必要とする場合、データベース サーバは多くの
ディスク操作を何回も実行しなければならなくなることがあります。したがって、
可変長文字 (CHARACTER VARYING) 型 (m,r)、可変長文字 (VARCHAR) 型 (m,r)、
各国語可変長文字 (NVARCHAR) 型 (m,r) のデータを使用している表の更新は、固
定長フィールドの更新より速度が遅くなる場合もあります。
このような状況を改善するには、r にデータ項目の高い比率を含むバイト数を設定
する必要があります。これにより、ほとんどの行は予約長を使用するようになり、
埋め込みで無駄になる領域はわずかになります。更新が遅くなるのは、予約バイト
数を使用している値が予約バイト数より長いバイト数を使用している値と置換され
る場合のみです。
大規模な文字型オブジェクト : テキスト (TEXT) 型
テキスト (TEXT) 型は、テキスト データを格納するためのデータ型です。ビジネス
フォーム、プログラム ソースやデータ ファイル、またはメモなどの、独立型ド
キュメントを格納するように設計されています。テキスト (TEXT) 型の項目には任
意のデータを格納できますが、Informix ツールではテキスト (TEXT) 型の項目は印刷
可能であることを前提にしているため、このデータ型は印刷可能な ASCII テキスト
でなければならないという制約があります。
XPS
Extended Parallel Server は、列でテキスト (TEXT) 型をサポートしています。ただ
し、BLOB 領域にテキスト (TEXT) 型列を格納したり、SPL ルーチンでテキスト
(TEXT) 型値を使用したりすることはできません。♦
テキスト (TEXT) 型の値は、その行の他の列の値と一緒には格納されません。テキ
スト型の列の値に対しては、ディスク ページ全体が割り当てられ、そのページは通
常は、行の他の値が格納される領域とは別のところに確保されます。詳細について
は、
『Administrator’s Guide』を参照してください。
文字 (CHAR) 型 (n) と可変長文字 (VARCHAR) 型 (m,r) に対するテキスト (TEXT) 型
の利点は、ディスク容量の範囲内であれば、格納可能なテキスト (TEXT) 型データ
のサイズに制限がないことです。テキスト (TEXT) 型の欠点は以下のとおりです。
3-22
■
ディスク ページ全体が割り当てられるため、短いデータの場合はディスク
容量が無駄になる。
■
SQL 文でのテキスト (TEXT) 型の列の使用方法に制約がある。3-23 ページ
の「テキスト (TEXT) 型とバイト (BYTE) 型の使用方法」を参照してくださ
い。
■
Informix データベース サーバでは使用できない。
Informix Guide to Database Design and Implementation
データ型
バイナリ オブジェクト : バイト (BYTE) 型
バイト (BYTE) データ型は、プログラムが生成するあらゆるデータを保持するよう
設計されています。ここで言うデータとは、グラフィック イメージ、プログラムの
オブジェクト ファイル、任意のワード プロセッサやスプレッド シートが保存した
ドキュメントを指します。データベース サーバは、バイト (BYTE) 型列にあらゆる
長さ、かつあらゆる種類のデータを受け入れることができます。
XPS
Extended Parallel Server は、列でバイト (BYTE) 型をサポートしています。ただし、
BLOB 領域にバイト (BYTE) 型列を格納したり、SPL ルーチンでバイト (BYTE) 型値
を使用したりすることはできません。♦
テキスト (TEXT) 型の場合と同様に、バイト (BYTE) 型データ項目は通常の行データ
とは分離され、ディスク領域の全ディスク ページに格納されるのが普通です。
バイト (BYTE) 型の利点は、テキスト (TEXT) 型や文字 (CHAR) 型 (n) とは異なり、
あらゆるデータを受け入れることができるという点にあります。欠点は、テキスト
(TEXT) 型の場合と同じです。
テキスト (TEXT) 型とバイト (BYTE) 型の使用方法
データベース サーバは、テキスト (TEXT) 型とバイト (BYTE) 型列を格納し、抽出し
ます。通常、テキスト (TEXT) 型値やバイト (BYTE) 型値は、Informix ESQL/C のよ
うな埋込み SQL がサポートしている言語を使用して作成されたプログラムで取り
出され格納されます。このようなプログラムでは、テキスト (TEXT) 型値やバイト
(BYTE) 型値の取出し、挿入、更新を、順次ファイルの読み書きと似た要領で行う
ことができます。
対話的に実行する SQL 文でも、プログラムに埋め込んで使用する SQL 文でもテキ
スト (TEXT) 型列やバイト （BYTE）型列は、次の場合には使用できません。
■
算術式やブール式
■
GROUP BY 節や ORDER BY 節
■
UNIQUE 検査
■
インデックス作成については、単独でも、あるいは複合インデックスの一
部としても使用できません。
対話形式で入力される SELECT 文、またはフォームやレポート内の SELECT 文で
は、テキスト (TEXT) 型値やバイト (BYTE) 型値について、次の操作が可能になりま
す。
■
列名を選択できます。部分文字列指定を使用すると、値の一部を取り出す
ことができます。
■
LENGTH(< 列名 >) を指定すれば、列の長さを戻すことができます。
データ型の選択
3-23
NULL 値
■
IS [NOT] NULL 述語を使用すれば列をテストできます。
対話的な INSERT 文では、VALUES 節を使用してテキスト (TEXT) 型値やバイト
(BYTE) 型値を入力することができますが、列に与えることのできる値は NULL の
みです。SELECT 文から取り出した値を使う INSERT 文を使用すれば、別の表のテ
キスト (TEXT) 型値やバイト (BYTE) 型値の値をコピーできます。
対話的な UPDATE 文では、テキスト (TEXT) 型列やバイト (BYTE) 型列を更新して
NULL にしたり、テキスト (TEXT) 型列やバイト (BYTE) 型列を返す副問合せにした
りすることができます。
データ型の変更
表を作成した後で、ALTER TABLE 文を使用して列に関連付けられたデータ型を変
更することができます。このような変更が必要な場合もありますが、なるべく避け
てください。理由は次のとおりです。
■
データ型を変更するには、データベース サーバは表をコピーして作成し直
さなければなりません。大きな表の場合、コピーと再作成には多大な時間
とディスク領域が必要です。
■
データ型を変更すると、情報を消失することがあります。たとえば、文字
型の列の長さを短くすると、長い値は一部が切り捨てられてしまいます。
数値型の列の精度を低くした場合には、下位の桁が切り捨てられてしまい
ます。
■
既存のプログラム、フォーム、レポート、格納済みの問合せも場合によっ
ては変更が必要になります。
NULL 値
ほとんどの場合、表内の列には、NULL 値を格納することができます。NULL と
は、未知の列または使用されていない列に対する値のことです。たとえば、第 2 章
の住所録の例では表 name の列 anniv に NULL 値を格納できます。記念日がわから
ない場合は、指定しないでおきます。NULL とゼロ値または空白値を混同しないよ
うに注意してください。たとえば、次の文を使用すると、データベース
stores_demo の表 manufact に行が 1 行挿入され、列 lead_time の値が NULL になる
よう指定されます。
INSERT INTO manufact VALUES ('DRM', 'Drumm', NULL)
IDS
3-24
コレクション (collection) 型列には、NULL 要素を格納できません。コレクション
(collection) 型については、第 7 章を参照してください。♦
Informix Guide to Database Design and Implementation
デフォルト値
デフォルト値
デフォルト値とは、INSERT 文の中で明示的な値が指定されていない場合に列に挿
入される値のことです。デフォルト値にできるのは、ユーザが定義するリテラル文
字列か、次の SQL 定数式のうちの 1 つです。
■
USER
■
CURRENT
■
TODAY
■
DBSERVERNAME
デフォルト値を必要としない列もありますが、データ モデルを操作していると、デ
フォルト値を使用することによってデータ入力にかかる時間が節約できる場合や、
データ入力エラーを防ぐことができる場合があるということがわかります。たとえ
ば住所録のモデルには列 State があります。この列のデータを見ると、住所の 50
パーセント以上の州がカリフォルニア州であることがわかります。時間を節約する
ためには、文字列 CA を列 State のデフォルト値として指定します。
チェック制約
チェック制約によってデータ値に対して条件や要件を指定してからでなければ、
INSERT 文または UPDATE 文の実行中に列を割り当てることはできません。挿入や
更新を行っているときに、表に対して定義したチェック制約のいずれかについて行
の評価が偽と判定されると、データベース サーバはエラーを戻します。ただし、
チェック制約が NULL と評価されても、データベース サーバはエラーをレポート
したり、レコードを拒否したりしません。このため、表の作成時には、チェック制
約と NOT NULL 制約の両方を使用する必要があります。
制約を定義するには、CREATE TABLE 文または ALTER TABLE 文を使用します。
たとえば、次の例は、整数型の列のドメインについての制約で、範囲を制約しま
す。
Customer_Number >= 50000 AND Customer_Number <= 99999
文字型のドメインに対する制約を記述するには、MATCHES 述語やサポートされて
いる正規表現を使用します。次の例は、電話番号の列のドメインを合衆国内の電話
番号の形式に制限する制約です。
vce_num MATCHES '[2-9][2-9][0-9]-[0-9][0-9][0-9][0-9]'
チェック制約の詳細については、
『Informix Guide to SQL: Syntax』の CREATE
TABLE 文と ALTER TABLE 文を参照してください。
データ型の選択
3-25
第4章
リレーショナルデータモデ
ルの実装
この章の概要 . .
.
. .
.
. .
. .
.
. .
.
. .
. .
.
. .
.
データベースの作成 . . . . . . . . . . . . . . . . . . . .
CREATE DATABASE 文の使用 . . . . . . . . . . . . . .
同じ名前の使用は避ける . . . . . . . . . . . . . . .
DB 領域の選択 . . . . . . . . . . . . . . . . . .
トランザクションログ機能のタイプの選択 . . . . . . . . .
CREATE TABLE 文の使用方法 . . . . . . . . . . . . . .
断片化された表の作成 . . . . . . . . . . . . . . . . .
CREATE INDEX 文の使用 . . . . . . . . . . . . . . . .
キーワード ASC およびキーワード DESC の使用 . . . . . .
インデックスの双方向トラバース . . . . . . . . . . . .
インデックスの双方向トラバースの例 . . . . . . . . . .
昇順インデックスまたは降順インデックスの選択 . . . . . .
複合インデックスでのキーワード ASC とキーワード DESC の使用
表名でのシノニムの使用方法 . . . . . . . . . . . . . . .
シノニム連鎖の使用方法 . . . . . . . . . . . . . . . .
コマンドスクリプトの使用方法 . . . . . . . . . . . . . .
スキーマの保存 . . . . . . . . . . . . . . . . . .
ファイルの実行 . . . . . . . . . . . . . . . . . .
例 . . . . . . . . . . . . . . . . . . . . . . .
データの初期入力 . . . . . . . . . . . . . . . . . . .
ソースデータを表にロードする . . . . . . . . . . . . .
一括カード操作の実行 . . . . . . . . . . . . . . . .
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4-3
4-3
4-4
4-4
4-4
4-5
4-6
4-8
4-8
4-9
4-10
4-10
4-11
4-12
4-13
4-15
4-16
4-16
4-16
4-16
4-17
4-17
4-18
4-2
Informix Guide to Database Design and Implementation
この章の概要
この章では、SQL の構文を使用して、第 2 章 で説明したデータ モデルを実装する
方法について説明します。具体的には、データベースと表を作成し、その表にデー
タを入力する方法について説明します。また、この章ではデータベース ログ オプ
ション、表シノニム、コマンド スクリプトについても説明します。
データベースの作成
これで、データモデルをデータベースの表として作成する準備が整いました。実際
のデータベースを作成する作業では、CREATE DATABASE 文、CREATE TABLE
文、あるいは CREATE INDEX 文を使用します。『Informix Guide to SQL: Syntax』
では、これらの文の構文を詳しく説明しています。ここでは、データモデルを実装
する場合の CREATE DATABASE 文と CREATE TABLE 文の使用方法を説明しま
す。
住所録のデータモデルが、説明のためだけに使用されていることに注意してくださ
い。例を示すために、データモデルは SQL 文に変換されます。
同じデータベースモデルを 2 回以上作成する必要がある場合もあります。そのよう
な場合、そのモデルを作成する文をファイルに格納しておいて自動的に実行するこ
とができます。詳細は、4-16 ページの「コマンドスクリプトの使用方法」を参照し
てください。
表を作成したら、表にデータの行を入力します。これは、手動か、ユーティリティ
プログラムを使用するか、または特別にプログラミングすることによって行いま
す。
リレーショナルデータモデルの実装
4-3
CREATE DATABASE 文の使用
CREATE DATABASE 文の使用
データベースは、データモデルのすべての部分を保持する容器です。要素としては
表の他にビュー、インデックス、シノニム、データベースに関連付けられたその他
のオブジェクトがあります。これらの要素を作成するには、まずデータベースを作
成しなければなりません。
GLS
データベース サーバはデータベースを作成するときに、システム カタログにある
環境変数 DB_LOCALE からロケールを取り出してデータベースに格納します。こ
のロケールによって、データベースサーバがデータベースに格納されている文字
データを解釈する方法が決定されます。デフォルトでは、データベースのロケール
は、ISO8859-1 コード セットを使用する米国英語のロケールです。別のロケール使
用についての詳細は、
『Informix Guide to GLS Functionality』を参照してくださ
い。♦
データベースサーバは、データベースを作成するときに、データベースの存在とそ
のログ機能のモードを示すレコードをセットアップします。しかし、データベース
サーバはディスク領域を直接管理するため、これらのレコードはオペレーティング
システムのコマンドからはわかりません。
同じ名前の使用は避ける
通常、一つのコンピュータ上ではデータベースサーバの一つのコピーのみが実行さ
れており、そのコンピュータのユーザ全員が使用するデータベースを管理していま
す。データベースサーバが所有しているデータベース名の一覧は一つだけです。各
データベースには、そのデータベースサーバが管理する他のデータベースとは異な
る名前をつけなければなりません。( データベースサーバのコピーを二つ以上実行
することも可能です。たとえば、データベース サーバの複数のコピーを作成して、
操作データから分離した安全なテスト環境を構築することができます。この場合、
データベースを作成するときと、このデータベースに後でアクセスするときに、必
ず正しいデータベース サーバを使用してください。)
DB 領域の選択
データベース サーバには、データベースを特定の DB 領域に作成します。DB 領域
はディスク領域の一部に名前が付いたものです。特定の DB 領域を使用する必要が
あるかどうかはデータベースサーバ管理者に問い合わせてください。デーベース
サーバ管理者は、データベースを特定の DB 領域に配置することで、そのデータ
ベースをほかのデータベースから分離したり、そのデータベースを特定のディスク
装置に格納したりすることができます。DB 領域について、および DB 領域とディ
スク装置との関係については、
『Administrator’s Guide』を参照してください。複
数の DB 領域にまたがるデータベースの表をフラグメント化する方法については、
第 10 章「次元データ モデルの作成」を参照してください。
4-4
Informix Guide to Database Design and Implementation
CREATE DATABASE 文の使用
一部の DB 領域は、信頼性を高めるために、ミラーリング、つまり 2 つのディスク
装置に二重化されています。データベースの内容が特別に重要である場合、ミラー
リングされた DB 領域にそのデータベースを格納できます。
トランザクションログ機能のタイプの選択
ログ付きデータベースまたはログなしデータベースを指定するには、CREATE
DATABASE 文を使用しますデータベースサーバには、トランザクションログ機能
に関して次のような選択肢があります。
■
ログ機能をまったく使用しない。この選択はお勧めできません。ハード
ウェア障害が原因でデータベースが失われた場合、最後のバックアップ以
降に行われたデータ変更がすべて失われます。
CREATE DATABASE db_with_no_log
ログ機能を選択しない場合に、トランザクション処理に関連する BEGIN
WORK 文や他の SQL 文をデータベースで使用することができません。こ
のような事態は、データベースを使用するプログラムの処理内容に影響を
及ぼします。
Extended Parallel Server では、ログなしデータベースはサポートしませ
ん。ただし、データベース サーバはログなし表をサポートします。詳細
は、11-12 ページの「Extended Parallel Server のログ付き表とログなし表」
を参照してください。♦
XPS
■
通常 ( バッファなし ) のログ機能。これはほとんどのデータベースに対して
適切な選択です。障害が発生した場合は、コミットしていないトランザク
ションのみが失われます。
■
バッファ付きログ機能。データベースを失うとしても最新の変更のごく一
部だけで、または、まったく失われない可能性もあります。リスクが少な
い代わりに、変更時の性能はほとんど改善されません。
CREATE DATABASE a_logged_db WITH LOG
CREATE DATABASE buf_log_db WITH BUFFERED LOG
バッファ付きログ機能は頻繁に更新されるデータベースに最適ですが、更
新速度が重要になる場合は、クラッシュが発生したときに他のデータから
更新を再作成することができます。バッファ付きログ機能と通常のバッ
ファなしログ機能間の切換えは SET LOG 文を使用して行います。
リレーショナルデータモデルの実装
4-5
CREATE TABLE 文の使用方法
■
ANSI 標準準拠のログ機能。このログ機能は通常のバッファなしログ機能
と同じですが、トランザクション処理に対する ANSI 規則も適用されま
す。ANSI 標準準拠のデータベースについては、
『Getting Started』を参照
してください。
CREATE DATABASE std_rules_db WITH LOG MODE ANSI
ANSI 標準の SQL では、バッファ付きログ機能は使用できません。ANSI
標準準拠のデータベースを作成した場合は、トランザクションログ機能を
オフにすることはできません。
データベース サーバ管理者 (DBA) は、ANSI モードのとき以外は、後からトランザ
クション ログをオンにもオフにもできます。たとえば、DBA は、トランザクショ
ン ログをオフにした後で、新しい行を大量に挿入することができます。ANSI 標準
に準拠していないデータベースに対してログをオフにする方法については、
『Administrator’s Guide』を参照してください。
CREATE TABLE 文の使用方法
データモデルで設計した表を作成するには CREATE TABLE 文を使用します。
CREATE TABLE 文の記述は複雑になる場合もありますが、基本的には表の列を並
べたものにすぎません。表の各列について、次の情報を指定します。
■
列の名前
■
データ型 ( 作成した定義域の中のもの )
■
列が主キーの場合は、制約を表すキーワード PRIMARY KEY
■
列が外部キーの場合は、制約を表すキーワード FOREIGN KEY
■
列が主キーではなく、NULL を許さない列の場合は、制約を表すキーワー
ド NOT NULL
■
列が主キーではなく、値の重複を許さない列の場合は、制約を表すキー
ワード UNIQUE
■
列がデフォルト値を持つ場合は、制約を表すキーワード DEFAULT
■
列が検査制約を持つ場合は、制約を表すキーワード CHECK
簡単にいうと、CREATE TABLE 文は、2-29 ページの 図 2-21 データモデル図で描
いたことを表の言葉で表現するものです。次の例は、住所録データモデルの文を示
します。
CREATE TABLE name
(
rec_num SERIAL PRIMARY KEY,
lname CHAR(20),
fname CHAR(20),
bdate DATE,
anniv DATE,
4-6
Informix Guide to Database Design and Implementation
CREATE TABLE 文の使用方法
email VARCHAR(25)
)
CREATE TABLE child
(
child CHAR(20),
rec_num INT,
FOREIGN KEY (rec_num) REFERENCES NAME (rec_num)
)
CREATE TABLE address
(
id_num SERIAL PRIMARY KEY,
rec_num INT,
street VARCHAR (50,20),
city VARCHAR (40,10),
state CHAR(5) DEFAULT ’CA’,
zipcode CHAR(10),
FOREIGN KEY (rec_num) REFERENCES name (rec_num)
)
CREATE TABLE voice
(
vce_num CHAR(13) PRIMARY KEY,
vce_type CHAR(10),
rec_num INT,
FOREIGN KEY (rec_num) REFERENCES name (rec_num)
)
CREATE TABLE fax
(
fax_num CHAR(13),
oper_from DATETIME HOUR TO MINUTE,
oper_till DATETIME HOUR TO MINUTE,
PRIMARY KEY (fax_num)
)
CREATE TABLE faxname
(
fax_num CHAR(13),
rec_num INT,
PRIMARY KEY (fax_num, rec_num),
FOREIGN KEY (fax_num) REFERENCES fax (fax_num),
FOREIGN KEY (rec_num) REFERENCES name (rec_num)
)
CREATE TABLE modem
(
mdm_num CHAR(13) PRIMARY KEY,
rec_num INT,
b_type CHAR(5),
FOREIGN KEY (rec_num) REFERENCES name (rec_num)
)
リレーショナルデータモデルの実装
4-7
断片化された表の作成
上記の各例では、CREATE TABLE 文で格納オプションを指定していないため、表
データは、そのデータベースに指定されている同じ DB 領域に格納されます。表に
対してデータベースの格納場所とは異なる DB 領域を指定したり、表を複数の DB
領域にフラグメント化することができます。Informix のデータベースがサポートす
る各種の格納オプションについては、
『Informix Guide to SQL: Syntax』の CREATE
TABLE 文の説明を参照してください。次の節で、1 つの表を複数の DB 領域にフラ
グメント化する方法の 1 つを示します。
断片化された表の作成
データの格納場所を表レベルで制御するには、表を作成するときに FRAGMENT
BY 節を使用します。次の文は、ラウンド ロビン分散スキームに従ってデータを格
納するフラグメント表を作成します。この例では、データの行は、フラグメント
dbspace1、dbspace2、および dbspace3 にほぼ均等に分散されます。
CREATE TABLE name
(
rec_num SERIAL PRIMARY KEY,
lname CHAR(20),
fname CHAR(20),
bdate DATE,
anniv DATE,
email VARCHAR(25)
) FRAGMENT BY ROUND ROBIN IN dbspace1, dbspace2, dbspace3
フラグメント表の作成に使用できる各種の分散スキームの詳細については、第 5 章
を参照してください。
CREATE INDEX 文の使用
CREATE INDEX 文を使用して、表の中の 1 つまたは複数の列に対するインデック
スを作成し、必要に応じて物理表をインデックス順にクラスタ化してください。こ
こでは、インデックスを作成するときに使用できるオプションについて説明しま
す。CREATE INDEX 文についての詳細は、『Informix Guide to SQL: Syntax』を参
照してください。
図 4-1 に示す表を作成するとします。
4-8
Informix Guide to Database Design and Implementation
CREATE INDEX 文の使用
図 4-1
CREATE TABLE customer
(
cust_num
fname
lname
company
address1
address2
city
state
zipcode
phone
)
SERIAL(101) UNIQUE,
CHAR(15),
CHAR(15),
CHAR(20),
CHAR(20),
CHAR(20),
CHAR(15),
CHAR(2),
CHAR(5),
CHAR(18)
次の文は、表 customer の列 cust_num に対するインデックスを作成する方法を示し
ています。
CREATE INDEX cust_index ON customer (cust_num)
キーワード ASC およびキーワード DESC の使用
キーワード ASC は、昇順で管理されるインデックスを指定するときに使用します。
キーワード ASC は、デフォルトの整列スキームです。キーワード DESC は、降順
で管理されるインデックスを指定するときに使用します。
キーワード ASC およびキーワード DESC は、B ツリーだけに使用できます。
ソート順オプションに対する一意性制約の効果
CREATE TABLE 文または ALTER TABLE 文で、列または列のリストを一意なもの
として定義すると、データベース サーバは一意の昇順インデックスを実装します。
したがって、一意なものとして定義済みの列または列リストに対して、CREATE
INDEX 文を使用して昇順インデックスを追加することはできません。
しかし、それらの列に対して降順インデックスを作成したり、それらの列を、様々
な組合せの複合昇順インデックスに含めたりすることはできます。図 4-1 に示した
表 customer を使用すると、次の CREATE INDEX 文のシーケンスを作成できます。
CREATE INDEX c_temp1 ON customer (cust_num DESC)
CREATE INDEX c_temp2 ON customer (cust_num, zipcode)
この例では、列 cust_num に一意性制約がかけられています。1 つめの CREATE
INDEX 文の例は、列 cust_num に対して、降順でソートされるインデックスを作成
します。2 つめの CREATE INDEX 文の例は、列 cust_num を複合インデックスの一
部として含めます。
リレーショナルデータモデルの実装
4-9
CREATE INDEX 文の使用
複合インデックスについての詳細は、4-12 ページの「複合インデックスでのキー
ワード ASC とキーワード DESC の使用」を参照してください。
インデックスの双方向トラバース
列に対するインデックスを作成するときにキーワード ASC またはキーワード DESC
を指定しないと、データベース サーバは、デフォルトにより、キー値を昇順で格納
します。キーワード ASC を指定した場合、データベース サーバは、キー値を昇順
で格納します。キーワード DESC を指定した場合、データベース サーバは、キー値
を降順で格納します。
昇順とは、値が最小のキーから最大のキーへの順序でキー値が格納されることで
す。たとえば、表 customer の列 lname に対する昇順のインデックスを作成した場
合、姓は次の順序で格納されます。Albertson、Beatty、Currie。
降順とは、値が最大のキーから最小のキーへの順序でキー値が格納されることで
す。たとえば、表 customer の列 lname に対する降順のインデックスを作成した場
合、姓は次の順序で格納されます。Currie、Beatty、Albertson。
しかし、データベース サーバの双方向トラバース機能によって、1 つの列に対して
インデックスを 1 つだけ作成し、ソート列の昇順または降順で結果をソートするよ
うに指定する問合せに対して、そのインデックスを使用することができます。
インデックスの双方向トラバースの例
データベース サーバによるインデックスの双方向トラバースを、例を使用して説明
します。次の 2 つの問合せを入力するとします。
SELECT lname, fname FROM customer ORDER BY lname ASC
SELECT lname, fname FROM customer ORDER BY lname DESC
上記の例のように SELECT 文で ORDER BY 節を指定すると、列 ORDER BY に対す
るインデックスを作成することにより、問合せの性能を向上させることができま
す。データベース サーバの双方向トラバース機能のために、列 lname に対してイン
デックスを 1 つ作成するだけですみます。
たとえば、次の文で、列 lname に対する昇順のインデックスを作成します。
CREATE INDEX lname_bothways ON customer (lname ASC)
データベース サーバは、昇順インデックス lname_bothways を使用して、1 つめの
問合せの結果を昇順にソートし、2 つめの問合せの結果を降順にソートします。
4-10
Informix Guide to Database Design and Implementation
CREATE INDEX 文の使用
1 つめの問合せでは、結果を昇順にソートします。そのため、データベース サーバ
は、インデックス lname_bothways のページを左から右にトラバースし、値が最小
のキーから最大のキーへとキー値を抽出します。問合せの結果は次のようになりま
す。
lname
Albertson
Beatty
Currie
.
.
.
Vector
Wallack
Watson
fname
Frank
Lana
Philip
Raymond
Jason
George
インデックスを左から右へトラバースするというのは、データベース サーバがイン
デックスの最も左にあるリーフ ノードから開始して、最も右側にあるリーフ ノー
ドまで続行することを意味します。
2 つめの問合せでは、結果を降順にソートします。つまりデータベース サーバは、
インデックス lname_bothways のページを右から左にトラバースし、値が最大の
キーから最小のキーへとキー値を抽出します。問合せの結果は次のようになりま
す。
lname
Watson
Wallack
Vector
.
.
.
Currie
Beatty
Albertson
fname
George
Jason
Raymond
Philip
Lana
Frank
インデックスのリーフ ノードの詳細については、
『Administrator’s Guide』を参照
してください。
昇順インデックスまたは降順インデックスの選択
単一列のインデックスを昇順と降順のどちらのインデックスとして作成してもかま
いません。インデックスの格納順序をどちらに選択しても、データベース サーバ
は、問合せを処理するとき、そのインデックスを昇順、降順のどちらの順序でもト
ラバースできます。
リレーショナルデータモデルの実装
4-11
CREATE INDEX 文の使用
複合インデックスでのキーワード ASC とキーワード DESC の使用
表の 1 つの列に対して 1 つのインデックスを作成する場合、キーワード ASC または
キーワード DESC を指定する必要はありません。これは、データベース サーバが、
そのインデックスを昇順と降順のどちらでもトラバースできるためです。
ただし、表に対して複合インデックスを作成する場合、キーワード ASC とキー
ワード DESC が必要になります。たとえば、ORDER BY 節で複数の列をそれぞれ異
なる順序でソートするように指定した SELECT 文を入力し、この問合せに対するイ
ンデックスを使用する場合、列 ORDER BY に対応する複合インデックスを作成す
る必要があります。
たとえば、次の問合せを入力するとします。
SELECT stock_num, manu_code, description, unit_price
FROM stock
ORDER BY manu_code ASC, unit_price DESC
この問合せは、まず、列 manu_code の値による昇順でソートを行い、次に、列
unit_price の値による降順でソートを行います。この問合せに対するインデックス
を使用するには、ORDER BY 節の要件に対応する CREATE INDEX 文を実行する必
要があります。たとえば、次の文のいずれかを入力して、そのインデックスを作成
します。
CREATE INDEX stock_idx1 ON stock
(manu_code ASC, unit_price DESC)
CREATE INDEX stock_idx2 ON stock
(manu_code DESC, unit_price ASC)
この問合せを実行すると、データベース サーバは、作成するインデックス
stock_idx1 または stock_idx2 を使用して、問合せの結果を列 manu_code の値によ
る昇順にソートし、次に、列 unit_price の値による降順にソートします。作成した
インデックスが stock_idx1 である場合、データベース サーバは、この問合せを実行
するときにインデックスを左から右にトラバースします。作成したインデックスが
stock_idx2 である場合、データベース サーバは、この問合せを実行するときにイン
デックスを右から左にトラバースします。
どちらのインデックスを作成するかに関係なく、この問合せの結果は次のようにな
ります。
stock_num
8
205
110
304
manu_code
ANZ
ANZ
ANZ
ANZ
description
volleyball
3 golf balls
helmet
watch
unit_price
$840.00
$312.00
$244.00
$170.00
(1 / 2)
4-12
Informix Guide to Database Design and Implementation
表名でのシノニムの使用方法
stock_num
301
310
201
313
6
9
5
309
302
.
.
.
113
1
6
5
manu_code
ANZ
ANZ
ANZ
ANZ
ANZ
ANZ
ANZ
HRO
HRO
description
running shoes
kick board
golf shoes
swim cap
tennis ball
volleyball net
tennis racquet
ear drops
ice pack
unit_price
$95.00
$84.00
$75.00
$60.00
$48.00
$20.00
$19.80
$40.00
$4.50
SHM
SMT
SMT
SMT
18-speed, assmbld
baseball gloves
tennis ball
tennis racquet
$685.90
$450.00
$36.00
$25.00
(2 / 2)
この問合せが使用する複合インデックス stock_idx1 または stock_idx2 は、ORDER
BY 節で 2 つの列に対して同じソート方向を指定する問合せに対しては使用できま
せん。たとえば、次の問合せを入力するとします。
SELECT stock_num, manu_code, description, unit_price
FROM stock
ORDER BY manu_code ASC, unit_price ASC
SELECT stock_num, manu_code, description, unit_price
FROM stock
ORDER BY manu_code DESC, unit_price DESC
複合インデックスを使用してこれらの問合せの性能を向上させるには、次の
CREATE INDEX 文のいずれかを入力します。次のインデックスのどちらを使用し
ても、上記の問合せの性能を向上させることができます。
CREATE INDEX stock_idx3 ON stock
(manu_code ASC, unit_price ASC)
CREATE INDEX stock_idx4 ON stock
(manu_code DESC, unit_price DESC)
表名でのシノニムの使用方法
シノニムとは、ある名前の代わりに使用できる別の名前のことです。CREATE
SYNONYM 文を使用すると、表やビューに代替名を与えることができます。
リレーショナルデータモデルの実装
4-13
表名でのシノニムの使用方法
通常、シノニムを使用して現在のデータベースに存在しない表を参照します。たと
えば、次のような文を実行すると、表 customer や表 orders の名前に対するシノニ
ムを作成することができます。
CREATE SYNONYM mcust FOR masterdb@central:customer
CREATE SYNONYM bords FOR sales@boston:orders
作成したシノニムは、元の表名を使用している可能性があっても、現行データベー
スのすべての場所で使用することができます。以下にシノニムの使用例を示しま
す。
SELECT bords.order_num, mcust.fname, mcust.lname
FROM mcust, bords
WHERE mcust.customer_num = bords.Customer_num
INTO TEMP mycopy
CREATE SYNONYM 文では、シノニム名を現行データベースのシステム カタログ
表 syssyntable に格納します。現行データベースで作成された問合せであれば、い
ずれもこのシノニムを使用することができます。
短いシノニムを使用すると、問合せを書くのが容易になりますが、シノニムは別の
役割を果たすこともできます。シノニムを使用すると、問合せを変えずに、表を別
のデータベースやコンピュータに移動することができます。
たとえば、表 customer と表 orders を参照する問合せが複数あるとします。これら
の問合せは、プログラムやフォーム、レポートに埋め込まれています。これらの表
はデモンストレーション データベースの一部で、このデータベースはデータベース
サーバ avignon に置かれています。
ここで、ネットワークに接続された別のコンピュータ ( データベース サーバ
nantes) のユーザも、同じプログラム、フォーム、レポートが使用できるようにす
ると決定したとします。これらのユーザは、その地域での注文が含まれている
orders という名前の表が入っているデータベースを持っていますが、avignon にあ
る表 customer にアクセスする必要があります。
データベース サーバ nantes のユーザにとって、表 customer は外部表です。これ
は、特殊なバージョンのプログラムやレポート、つまり、表 customer をデータ
ベース サーバ名で修飾するバージョンを作成しなければならない、ということにな
るのでしょうか。もっとよい解決策は、次の例に示すように、これらのユーザの
データベースにシノニムを作成することです。
DATABASE stores_demo@nantes
CREATE SYNONYM customer FOR stores_demo@avignon:customer
4-14
Informix Guide to Database Design and Implementation
シノニム連鎖の使用方法
格納済みの問合せがご使用のデータベースで実行される場合、名前 customer は実
際の表を参照します。この問合せがその他のデータベースで実行される場合、名前
customer はシノニムを介して、データベース サーバ avignon にある表の参照とな
るよう変換されます。
シノニム連鎖の使用方法
前述の例を続けるために、ネットワークにコンピュータが新たに接続されたと仮定
します。そのコンピュータの名前は db_crunch です。avignon の負荷を減らすため
に、表 customer などの表は db_crunch に移動することにします。表 customer は
新しいデータベース サーバ上で簡単に再作成できますが、すべてのアクセスをこの
表に向けるにはどうすればよいでしょうか。一つの方法は、次の例に示すように、
シノニムをインストールし古い表を置き換えることです。
DATABASE stores_demo@avignon EXCLUSIVE
RENAME TABLE customer TO old_cust
CREATE SYNONYM customer FOR stores_demo@db_crunch:customer
CLOSE DATABASE
stores_demo@avignon 内で問合せを実行すると、表 customer に対する参照はシノ
ニムを見つけ、新しいコンピュータ上のバージョンにリダイレクトされます。ま
た、このような宛先変更は、前述の例におけるデータベース サーバ nantes から実
行される問合せに対しても起こります。データベース stores_demo@nantes 内のシ
ノニムは、やはり customer に対する参照をデータベース stores_demo@avignon に
リダイレクトします。しかし、そこにある新しいシノニムは、データベース
stores_demo@db_crunch に問合せを送信します。
この例のように、シノニムの連鎖は、1 回の操作ですべてのアクセスを目的の表に
向けたい場合に役立ちます。ただし、できる限り早く全ユーザのデータベースを更
新して、これらのシノニムが目的の表を直接指せるようにしなければなりません。
これを行わないと、データベース サーバが余分なシノニムを取り扱う場合に、余分
なオーバーヘッドが発生するほか、連鎖内のいずれかのコンピュータがダウンする
と、その表を見つけられなくなります。
一つのアプリケーションをローカル データベースに対して実行し、後で同じアプリ
ケーションを別のコンピュータ上のデータベースに対して実行することもできま
す。プログラムは、どちらの場合も同じように順調に実行されますが、ネットワー
ク データベース上では、実行速度が遅くなることがあります。データ モデルが同
じである限り、プログラムでは、ローカル データベース サーバとリモート データ
ベース サーバを区別することはできません。
リレーショナルデータモデルの実装
4-15
コマンドスクリプトの使用方法
コマンドスクリプトの使用方法
データベースと表は、SQL 文を対話的に入力することによって作成できます。場合
によってはこの操作を 2 回以上繰り返さなければならないことがあります。
たとえば、データベースの再作成は、試験バージョンが正常に動作した後で本稼動
バージョンを作成するときに必要になります。また、同じデータモデルを複数のコ
ンピュータについて実装しなければならない場合も、データベースの再作成が必要
になります。このような場合、データベースを作成するすべての文をファイルに書
き込んでおき自動的に実行するようにすれば、時間を節約できるとともに、エラー
の発生を減らすことができます。
スキーマの保存
自分用のモデルをファイル内に実装する文を作成することができます。ただし、自
分用のモデルを実装するプログラムを持つこともできます。dbschema は、データ
ベースの内容を検査し、再作成するために必要なすべての SQL 文を生成するユー
ティリティです。データベースの最初のバージョンを対話形式で作成した後、希望
どおりのデータベースになるまで変更を加えます。次に dbschema を使用して、そ
のデータベースを二重化するために必要な SQL 文を生成することができます。
dbschema ユーティリティについては『Informix Migration Guide』を参照してくだ
さい。
ファイルの実行
DB-Access や Relational Object Manager などの SQL 文を対話形式で入力するのに使
用するプログラムは、コマンド ファイルから実行することができます。DB-Access
や Relational Object Manager を起動して、ユーザや dbschema が作成したコマンド
ファイルを読み込ませて実行させることができます。詳細については、
『DB-Access
User’s Manual』や Relational Object Manager のマニュアルを参照してください。
例
ほとんどの Informix データベースサーバ製品は、デモンストレーションデータベー
スを備えています ( このデータベースは本書の例で使用されます )。デモンスト
レーション データベースは、このデータベースを作成するために Informix 製品を
呼び出すオペレーティング システムのコマンド スクリプトの形で配布されます。
このコマンドスクリプトをコピーして、自分のデータモデルを自動作成するための
原型として使用することができます。
4-16
Informix Guide to Database Design and Implementation
データの初期入力
データの初期入力
初期テストを行うとき、対話形式で表にデータを入力するもっとも簡単な方法は、
DB-Access または Relational Object Manager で INSERT 文を入力することです。デ
モンストレーションデータベースの表 manufact に行を入力するには、DB-Access
で次のコマンドを入力します。
INSERT INTO manufact VALUES ('MKL', 'Martin', 15)
別の言語で作成したアプリケーションプログラムがあれば、そのプログラムを使用
して行を入力することができます。
大きな表に初期の行を入力する場合、別のデータベースやオペレーティングシステ
ムファイルの表に格納されているデータを持ってくるという方法もよく取られま
す。その場合は、そのデータを新しいデータベースに一括して挿入することができ
ます。そのデータが他の Informix データベースに格納されている場合は、数通りの
方法でそのデータを取り出すことができます。
データベースの INSERT 文の一部で、別のデータベースサーバ上の他のデータベー
スにある目的のデータを選択することができます。次の例に示すように、デモンス
トレーションデータベースの表 items の情報を選択できます。
INSERT INTO newtable
SELECT item_num, order_num, quantity, stock_num,
manu_code, total_price
FROM stores_demo@otherserver:items
ソースデータを表にロードする
別の種類のファイルやデータベースがデータの元である場合は、それをフラットな
ASCII ファイルに変換する方法を見つける必要があります。フラットな ASCII ファ
イルとは、印刷不可能な文字を含まないファイルで、ファイルの各行が表の 1 行の
内容を表しているものです。
データをファイルに格納した後は、dbload ユーティリティを使用してそのデータ
を表にロードすることができます。dbload ユーティリティについての詳細は、
『Informix Migration Guide』を参照してください。DB-Access の LOAD 文を使用し
ても、フラットな ASCII ファイルから行をロードすることができます。LOAD 文と
『Informix Guide to SQL: Syntax』を参照してくだ
UNLOAD 文についての詳細は、
さい。
XPS
データをファイルに格納した後は、外部表を使用して、そのデータを表にロードす
ることができます。外部表の詳細については、
『Administrator’s Guide』を参照し
てください。♦
リレーショナルデータモデルの実装
4-17
データの初期入力
一括カード操作の実行
数百行や数千行の行を挿入する場合は、トランザクションログ機能をオフにするこ
とで、時間を大幅に短縮できます。ただし、このような挿入操作をトランザクショ
ンログに記録しても意味がありません。障害が発生して操作結果が失われても、簡
単に復元できるからです。大量のデータを一括ロードする手順を次に示します。
■
そのデータベースを他のユーザが使用している可能性が少しでもある場合
は、DATABASE EXCLUSIVE 文でそのデータベースに排他ロックを設定
します。
■
管理者に依頼してデータベースのログ機能をオフにしてください。
既存のログはデータベースを現在の状態に復旧するのに使用できるため、
データベースが失われた場合、行を復旧するために繰り返して大量挿入を
行うことができます。
Extended Parallel Server を使用するデータベースに対するログ機能をオフ
にすることはできません。しかし、データベースにログなし表（フォー
マットされていない永続表または静的永続表）を作成することができま
す。♦
XPS
■
表にデータをロードする文かユーティリティを実行します。
■
新しくロードされたデータベースをバックアップします。
完全バックアップまたは差分バックアップの実行を管理者に依頼するか、
onunload ユーティリティを使用して自分のデータベースだけのバイナリ
コピーをとってください。
■
トランザクション ログ機能を復元し、データベースの排他ロックを解除し
ます。
データベースにデータを初期入力する手順は、オペレーティングシステムコマンド
のスクリプトに格納することができます。ON-Monitor に相当するコマンド行を起
動することによって、データベースサーバ管理者コマンドの実行を自動化すること
ができます。
4-18
Informix Guide to Database Design and Implementation
表フラグメンテーション ストラテジ
データベース サーバのアクセス権の付与と制限
セクション II
データベースの管理
第5章
表フラグメンテーション ス
トラテジ
この章の概要 . .
.
. .
.
. .
. .
.
. .
.
. .
. .
.
. .
.
. .
5-3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5-3
5-5
5-6
5-7
5-7
表のフラグメント化のための分散スキーム . . . . . . . .
式に基づく分散スキーム . . . . . . . . . . . .
範囲規則 . . . . . . . . . . . . . . . . .
任意規則 . . . . . . . . . . . . . . . . .
式に基づいた分散スキームでの MOD 関数の使用方法 .
式に基づいたフラグメントの行の挿入と更新 . . . .
ラウンド ロビン分散スキーム . . . . . . . . . . .
範囲分散スキーム . . . . . . . . . . . . . . .
システム定義ハッシュ分散スキーム . . . . . . . .
ハイブリッド分散スキーム . . . . . . . . . . . .
式に基づくハイブリッド スキームの使用 . . . . .
範囲に基づくハイブリッド スキームの使用 . . . .
検索からのフラグメントの除去 . . . . . . . . . .
フラグメント除去の問合せ式 . . . . . . . . .
フラグメント除去の式に基づいた分散スキーム . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5-8
5-9
5-9
5-10
5-10
5-10
5-11
5-11
5-12
5-13
5-13
5-14
5-16
5-17
5-17
フラグメント表の作成 . . . . . . . . . . . . . . . . . . .
フラグメント表を新たに作成する . . . . . . . . . . . . .
フラグメント表内の行 ID . . . . . . . . . . . . . . . .
フラグメント化されていない表からのフラグメント表の作成 . . . .
複数のフラグメント化されていない表からのフラグメント表の作成
1 つのフラグメント化されていない表からのフラグメント表の作成
スマート ラージ オブジェクトのフラグメント化 . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5-21
5-21
5-22
5-23
5-23
5-24
5-24
フラグメンテーション ストラテジの変更 . . . . . . . .
INIT 節を使用してフラグメント化スキームを再初期化 . .
. .
. .
5-25
5-25
フラグメント化とは . . . . . . . . . . . . . .
Extended Parallel Server に対する拡張フラグメント化
フラグメント化を使用する理由 . . . . . . . .
フラグメント化の責任者 . . . . . . . . . .
フラグメント化とログ . . . . . . . . . . .
.
.
. .
. .
.
.
INIT 節を使用してハッシュ フラグメント化をハイブリッド
フラグメント化に変更 . . . . . . . . . . . .
MODIFY 節を使用して既存のフラグメンテーション
ストラテジを変更 . . . . . . . . . . . . .
ATTACH 節および DETACH 節を使用して既存の
フラグメンテーション ストラテジを変更 . . . . .
ATTACH 節を使用してフラグメントを追加 . . . .
DETACH 節を使用してフラグメントを削除 . . . .
ADD 節を使用してフラグメントを追加 . . . . . . .
DROP 節を使用してフラグメントを削除 . . . . . .
5-2
.
. .
. .
.
5-27
.
. .
. .
.
5-27
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
5-28
5-29
5-29
5-30
5-31
一時表のフラグメント化 . . . . . . . . . . . . . .
Extended Parallel Server による一時表のフラグメント化 .
ユーザ固有のフラグメンテーション ストラテジの定義
Extended Parallel Server によるフラグメンテーション
ストラテジの定義 . . . . . . . . . .
.
.
.
. .
. .
. .
. .
. .
. .
.
.
.
5-31
5-31
5-32
.
. .
. .
.
5-32
表インデックスのフラグメント化 . . . . . .
連結インデックス . . . . . . . . . .
分離インデックス . . . . . . . . . .
行 ID . . . . . . . . . . . . . .
行 ID の列の作成 . . . . . . . .
行 ID の列を作成すると何が実行されるか
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5-33
5-33
5-34
5-35
5-35
5-36
フラグメント表に格納されているデータへのアクセス . . . . . . . . .
行 ID の代わりに主キーを使用する . . . . . . . . . . . . . . .
フラグメント表の行 ID の列の作成 . . . . . . . . . . . . . . .
フラグメント アクセス権の付与と取消し . . . . . . . . . . . .
5-36
5-36
5-37
5-38
Informix Guide to Database Design and Implementation
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
この章の概要
この章では、データベース サーバがサポートするフラグメンテーション ストラテ
ジについて説明し、さまざまなフラグメンテーション ストラテジの例を示します。
次のトピックについて説明します。
■
フラグメント化とは
■
表フラグメントに応じた分散スキーム
■
フラグメント表の作成
■
フラグメント表の変更
■
一時表のフラグメント化
■
表インデックスのフラグメント化
■
フラグメント表に格納されているデータへのアクセス
データの競合を少なくし、問合せの性能を向上させるフラグメンテーション ストラ
テジを構築する方法については、
『Performance Guide』を参照してください。
フラグメント化とは
フラグメント化とは、データベース サーバ機能の 1 つであり、この機能を使用すれ
ば、表レベルでデータを格納する場所を制御できます。フラグメント化を使用すれ
ば、何らかのアルゴリズムまたはスキームに基づいて、任意の表内に、行またはイ
ンデックス キーのグループを定義することができます。各グループまたはフラグメ
ントは、パーティションとも呼ばれ、特定の物理ディスクと関連付けられた別個の
DB 領域に格納することができます。SQL 文を使用してフラグメントを作成し、そ
れらを DB 領域に割り当てます。
行またはインデックス キーをグループ化してフラグメントにするときに使用するス
キームは、分散スキームと呼ばれます。分散スキームと、フラグメントを一緒に配
置する DB 領域のセットにより、フラグメンテーション ストラテジが構成されま
す。フラグメンテーション ストラテジを組み立てるときに必要な意思決定について
は、
『Performance Guide』を参照してください。
表フラグメンテーション ストラテジ
5-3
フラグメント化とは
表行、インデックス キー、またはその両方をフラグメント化するかどうかを決め、
その行またはキーを複数のフラグメントに分散する方法を決めたら、この分散を実
現するスキームを決めます。Informix のデータベース サーバがサポートする分散ス
キームについては、5-8 ページの「表のフラグメント化のための分散スキーム」を
参照してください。
フラグメント表とインデックスを作成すると、データベース サーバは、各表の格納
場所と、その他の関連情報が入ったインデックス フラグメントを、sysfragments と
いう名前のシステム カタログ表に格納します。この表を使用すれば、フラグメント
表とインデックスに関する情報にアクセスできます。このシステム カタログ表に格
納されている情報の詳細については、
『Informix Guide to SQL: Reference』を参照し
てください。
エンド ユーザまたはクライアント アプリケーションの観点から見れば、フラグメ
ント表と、フラグメント化されていない表は同じです。クライアント アプリケー
ションでは、フラグメント表内のデータにアクセスできるようにするのに、どのよ
うな変更も必要ありません。
5-4
Informix Guide to Database Design and Implementation
Extended Parallel Server に対する拡張フラグメント化
分散スキームによっては、データベース サーバは、どのフラグメントにどのデータ
が格納されているかに関する情報を所有しているため、関連のないフラグメントに
アクセスすることなく、クライアントからのデータ要求を適切なフラグメントに
ルーティングすることができます。5-5 ページの 図 5-1 を参照してくださいただし、
ラウンド ロビン分散スキームおよび式に基づく分散スキームの場合、データベース
サーバは、クライアントからのデータ要求を適切なフラグメントにルーティングす
ることはできません。詳細は、5-8 ページの「表のフラグメント化のための分散ス
キーム」を参照してください。
クライアント
アプリケーション
クライアント
クライアント
クライアント
図 5-1
クライアント ア
プリケーションか
らのデータ要求の
データベース
サーバによる
ルーティング
アプリケー
ションの観点
から見た表
データベース
サーバの観点
から見た表
ディスク
XPS
Extended Parallel Server に対する拡張フラグメント化
Extended Parallel Server は、異なるコサーバに属する複数のディスク間で表とイン
デックスをフラグメント化することができます。各表フラグメントは、異なるコ
サーバに属する複数の物理ディスクと関連付けられた別個の DB 領域に常駐するこ
とができます。DB スライスには、複数のコサーバ間で数多くの DB 領域を管理する
機構が備わっています。DB スライスと DB 領域を作成すると、複数のコサーバ間で
フラグメント化された表とインデックスを作成することができます。
表フラグメンテーション ストラテジ
5-5
フラグメント化を使用する理由
複数のコサーバ間で表をフラグメント化する利点については、
『Performance
Guide』を参照してください。DB スライスと DB 領域の作成方法については、
『Administrator’s Guide』を参照してください。
フラグメント化を使用する理由
次の目標のうち 1 つでも当てはまるものがあれば、表のフラグメント化を検討して
ください。
■
単一ユーザ応答時間の向上
PDQ (Parallel Database Query : 並列データベース問合せ ) とともにフラグ
メント化を使用して、複数のディスクまたはコサーバに分散しているフラ
グメントを並列に走査すれば、個々の問合せの性能を高めることができま
す。ただし、これは、Extended Parallel Server の場合だけです。PDQ に
ついては、
『Administrator’s Guide』を参照してください。PDQ とフラグ
メント化の性能問題については、
『Performance Guide』を参照してくださ
い。
■
同時実行性の向上
フラグメント化を使用すれば、大型で使用頻度の高い表に配置されている
データの競合を減らすことができます。フラグメント化を使用すると競合
が減るのは、各フラグメントが別個の入出力デバイスに常駐し、データ
ベース サーバが該当のフラグメントに問合せを送るためです。
■
可用性の向上
フラグメント化を使用すれば、データの可用性を向上させることができま
す。フラグメント化が使用できなくなっても、データベース サーバは、ま
だ、残余フラグメントにアクセスできます。アクセスできないフラグメン
トをスキップする方法については、
『Administrator’s Guide』を参照して
ください。
■
バックアップと復元の特性の向上
フラグメント化を使用すると、バックアップと復元の細分性をよりきめ細
かくすることができます。この細分性を使用することにより、バックアッ
プと復元の操作にかかる時間を短くすることができます。さらに、
ON-Bar または ON-Archive を使用すれば、バックアップと復元の操作を
並列に実行して、性能を向上させることができます。ON-Bar バックアッ
プと復元のシステムについての詳細は、
『Backup and Restore Guide』を参
照してください。
IDS
5-6
ON-Archive についての詳細は、『Archive and Backup Guide』を参照して
ください。♦
Informix Guide to Database Design and Implementation
フラグメント化の責任者
XPS
■
データ ロード性能の向上
大容量のデータベースをロードする性能を向上させるには、外部表ととも
にフラグメント化を使用します。詳細については、
『Administrator’s
Guide』を参照してください。
Extended Parallel Server は、外部表を使用して、複数のコサーバ間でフラ
グメント化された表をロードする場合、データをフラグメントに並列に
ロードするためのスレッドを割り当てます。フラグメント ( 別のコサーバ
に配置された ) を表に追加すると、そのたびに、ほぼ線形の性能向上が期
待できます。♦
前記の目標は、それぞれ、最終的に実現するフラグメンテーション ストラテジに独
自の影響を与えます。使用する主要なフラグメント化目標により、フラグメンテー
ション ストラテジの実現方法が決まるか、あるいは少なくとも影響を受けることに
なります。フラグメント化を使用して前記の目標のどれかが満たされるかどうかを
決める場合、フラグメント化には何らかの管理活動や監視活動が余分に必要になる
ことを念頭に入れておいてください。
前記の目標およびフラグメンテーション ストラテジの組み立て方法の詳細について
は、
『Performance Guide』を参照してください。
フラグメント化の責任者
フラグメント化に関して、データベース サーバ管理者の責任と DBA ( データベース
管理者 ) の責任は、一部重複します。DBA は、表フラグメント化を含めることので
きるデータベース スキームを作成します。一方、データベース サーバ管理者は、
フラグメント表が常駐するディスク領域を割り当てることに責任を持ちます。こう
した責任は、どちらも単独で実行することはできません。このため、フラグメント
化を実装するには、データベース サーバ管理者と DBA の協力作業が必要になりま
す。このマニュアルでは、フラグメンテーション ストラテジを実現するのに DBA
が実行するタスクについてだけ説明します。フラグメンテーション ストラテジを実
現するのにデータベース サーバ管理者が実行するタスクについては、
『Administrator’s Guide』と『Performance Guide』を参照してください。
フラグメント化とログ
IDS
Dynamic Server では、フラグメント表は、ログ付きデータベースにもログなしデー
タベースにも属することができます。フラグメント化されていない表と同様に、フ
ラグメント表がログなしデータベースの一部になっている場合、障害が発生する
と、データの矛盾が発生する可能性があります。♦
表フラグメンテーション ストラテジ
5-7
表のフラグメント化のための分散スキーム
XPS
Extended Parallel Server では、フラグメント表は必ずログ付きデータベースに属し
ます。Extended Parallel Server では、複数のログ付き表型とログなし表型はサポー
トされていません。詳細は、11-12 ページの「Extended Parallel Server のログ付き
表とログなし表」を参照してください。♦
表のフラグメント化のための分散スキーム
分散スキームとは、行またはインデックスのエントリを複数のフラグメントに分散
するときにデータベース サーバが使用する方法の 1 つです。Informix のデータベー
ス サーバは、以下の分散スキームをサポートします。
■
式に基づく分散スキームこの分散スキームは、指定された値を含む行を同
じフラグメントに格納します。各フラグメントに行のセットを割り当てる
基準を定義するフラグメント化式を、範囲規則または任意規則として指定
します。残余フラグメントを指定すれば、ほかのどのフラグメントの基準
とも一致しない行をすべて保持することができます。ただし、残余フラグ
メントを指定すると、式に基づく分散スキームの効率が低下します。
■
ラウンド ロビン 分散スキームこの分散スキームは、一連のフラグメント
を循環しながら順次にフラグメントに行を配置することにより、行を均等
に分散させます。データベース サーバはこの規則を内部で定義していま
す。
INSERT 文では、データベース サーバは、乱数に基づいてハッシュ関数を
使用して、行を配置するフラグメントを特定します。INSERT カーソルで
は、データベース サーバは、ランダムに決めたフラグメントに最初の行を
配置し、次の順次フラグメントに 2 番目の行をというように順次配置して
いきます。フラグメントの 1 つがいっぱいであれば、そのフラグメントは
スキップされます。
XPS
5-8
■
範囲分散スキームこの分散スキームは、行が DB 領域間で均等にフラグメ
ント化されるようにします。範囲分散スキームでは、データベース サーバ
は、ユーザが指定する最小および最大整数値に基づいて、フラグメント間
での行の分散を決定します。データ分散を高密度かつ均等に行うときは、
範囲分散スキームをお勧めします。
■
システム定義ハッシュ分散スキームこの分散スキームは、内部的なシステ
ム定義規則を使用し、各フラグメントに同数の行を保持させることを目的
として行の分散を行います。
■
ハイブリッド分散スキームこの分散スキームは、2 つの分散スキームが組
み合わせられたものです。主分散スキームでは、DB スライスが選択され
ます。副分散スキームでは、DB スライス内の特定 DB 領域に行が配置され
ます。DB 領域は通常、別々のコサーバ上に常駐しています。♦
Informix Guide to Database Design and Implementation
式に基づく分散スキーム
分散スキームを指定するために使用する SQL 構文の詳細については、『Informix
Guide to SQL: Syntax』の CREATE TABLE 文および CREATE INDEX 文の説明を参
照してください。
式に基づく分散スキーム
式に基づく分散スキームを指定するには、CREATE TABLE 文または CREATE
INDEX 文の FRAGMENT BY EXPRESSION 節を使用してください。次の例では、
式に基づく分散スキームでフラグメント表を作成する FRAGMENT BY
EXPRESSION 節が使用されています。
CREATE
id_num
id_num
id_num
TABLE accounts (id_num INT...) FRAGMENT BY EXPRESSION
<= 100 IN dbspace_1,
<= 200 IN dbspace_2,
> 200 IN dbspace_3
CREATE TABLE 文の FRAGMENT BY EXPRESSION 節を使用してフラグメント表
を作成する場合は、作成する表の各フラグメントに条件を 1 つずつ指定する必要が
あります。
範囲規則または任意規則を定義すれば、複数のフラグメントにどのように行を分散
させればよいかを、データベース サーバに指示することができます。以降の節で
は、さまざまな種類の、式に基づく分散スキームを説明します。
範囲規則
範囲規則は、SQL 関係演算子と論理演算子を使用して、表内の各フラグメントの境
界を定義します。範囲規則には、次の演算子の制限付きセットを使用することがで
きます。
■
関係演算子 >、<、>=、<=
■
論理演算子 AND
範囲規則は、表内の列を 1 列だけ参照することができますが、この列への複数参照
は実行できません。次の例に示すように、表内の各フラグメントに式を 1 つずつ定
義します。
.
.
.
FRAGMENT
id_num >
id_num >
id_num >
BY
0
20
40
EXPRESSION
AND id_num <= 20 IN dbsp1,
AND id_num <= 40 IN dbsp2,
IN dbsp3
表フラグメンテーション ストラテジ
5-9
式に基づく分散スキーム
任意規則
任意規則は、SQL 関係演算子と論理演算子を使用します。範囲規則と違って、任意
規則では、規則を定義するのにどの関係演算子と論理演算子でも使用できます。さ
らに、この規則では、数多くの表列を参照することができます。次の例のように、
通常任意規則では、データをグループ化するのに論理演算子 OR を使用します。
.
.
.
FRAGMENT BY EXPRESSION
zip_num = 95228 OR zip_num = 95443 IN dbsp2,
zip_num = 91120 OR zip_num = 92310 IN dbsp4,
REMAINDER IN dbsp5
IDS
式に基づいた分散スキームでの MOD 関数の使用方法
FRAGMENT BY EXPRESSION 節で MOD 関数を使用して、表内の各行を整数 (
ハッシュ値 ) のセットにマッピングすることができます。データベース サーバは、
これらの値を使用して、所定の行を格納するフラグメントを決めます。次の例で
は、式に基づいた分散スキームでの MOD 関数の使用方法を示します。
.
FRAGMENT BY
MOD(id_num,
MOD(id_num,
MOD(id_num,
EXPRESSION
3) = 0 IN dbsp1,
3) = 1 IN dbsp2,
3) = 2 IN dbsp3
式に基づいたフラグメントの行の挿入と更新
行を挿入または更新する場合、データベース サーバは、指定された順序でフラグメ
ント式を評価して、その行がフラグメントのどれかに属しているかどうかを調べま
す。属していれば、データベース サーバは、フラグメントの 1 つにその行を挿入す
るか、フラグメントの 1 つでその行を更新します。フラグメントのどれにも属して
いなければ、その行は残りの節で指定されたフラグメント内に配置されます。分散
スキームに残りの節が含まれていない場合で、その行が既存のどのフラグメント式
の基準とも一致しない場合は、データベース サーバは、エラーを返します。
5-10
Informix Guide to Database Design and Implementation
ラウンド ロビン分散スキーム
ラウンド ロビン分散スキーム
ラウンド ロビン分散スキームを指定するには、CREATE TABLE 文の FRAGMENT
BY ROUND ROBIN 節を使用してください。次の文は、ラウンド ロビン分散スキー
ムでフラグメント表を作成します。
CREATE TABLE account_2...FRAGMENT BY ROUND ROBIN IN dbspace1, dbspace2, dbspace3
データベース サーバは、ラウンドロビン分散を使用する表に数多くの行を挿入する
要求を受信した場合、各フラグメント内の行の数がほぼ同じ状態になるように行を
分散します。ラウンド ロビン分散は、情報を複数のフラグメントに均等に分散させ
るため、均等分散とも呼ばれます。表でラウンドロビン分散を使用する場合、この
表に行を分散する規則は、データベース サーバの内部規則です。
重要 : ラウンドロビン分散スキームは、表行のフラグメント化だけに使用できま
す。表インデックスのフラグメント化には使用できません。5-33 ページの「表イン
デックスのフラグメント化」を参照してください。
XPS
範囲分散スキーム
データ分散が高密度かつ均等であり、フラグメント化列に重複が含まれない場合
は、範囲分散スキームを使用して複数の DB 領域に行を均等に分散させることがで
きます。範囲分散では、ユーザがフラグメント間の行の分散を決定するために指定
する MIN 値と MAX 値が使用されます。
次の文には、範囲分散スキームを指定する FRAGMENT BY RANGE 節が含まれて
います。
CREATE TABLE cust_account (cust_id INT)...FRAGMENT BY RANGE
(cust_id MIN 1000 MAX 5000) IN dbsp_1, dbsp_2, dbsp_3, dbsp_4)
表フラグメンテーション ストラテジ
5-11
システム定義ハッシュ分散スキーム
MIN 値と MAX 値は、列に入力される値の全範囲を指定します。MAX 値は、
FRAGMENT BY RANGE 節で指定する必要があります。ユーザが MIN 値を指定し
ないと、デフォルトの MIN 値は 0 になります。前述の例では、データベース サー
バは cust_id の値を使用して、表列を 4 つの DB 領域に分散させています。データ
ベース サーバは、次のように行をフラグメント化します。
格納領域
格納される行に含まれる列の値の範囲
dbsp_1
1000 <= cust_id < 2000
dbsp_2
2000 <= cust_id < 3000
dbsp_3
3000 <= cust_id < 4000
dbsp_4
4000 <= cust_id < 5000
単一列に対して範囲フラグメント化を使用できます。あるいは、ハイブリッド分散
スキームで、各 FRAGMENT BY RANGE 節に対応する異なる列に対して範囲ス
キームを指定できます。ハイブリッド分散スキームで範囲フラグメント化を使用す
る方法については、5-13 ページの「ハイブリッド分散スキーム」を参照してくださ
い。
XPS
システム定義ハッシュ分散スキーム
データベース サーバは、システム定義ハッシュ アルゴリズムを使用して、指定の
キーをハッシングすることにより、データを均等に分散させます。システム定義
ハッシュ アルゴリズムでフラグメント化を行うことで、データを均等に分散できる
だけでなく、ハッシングされたキーを使用する問合せに対するフラグメントを自動
的に除去できます。複数の表に対してハッシュ フラグメント化を使用すれば、問合
せで表を結合するときにフラグメントを除去でき、また、ローカル コサーバにより
多くの処理をさせることができます。
システム定義ハッシュ分散スキームは、複数のフラグメントにデータを均等に分散
させるのに望ましい方法ですが、以下の場合はほかの方法をとることをお勧めしま
す。
■
範囲問合せを使用する場合
範囲分散スキームを使用する方がフラグメントの除去がより効果的にな
り、問合せの性能が向上します。
5-12
Informix Guide to Database Design and Implementation
ハイブリッド分散スキーム
■
指定の列に含まれる重複値が非常に不均等であるか、または、異なる値の
数が非常に少ない場合
いずれの状態も、データ スキューが生じて、一部のフラグメントがその他
のフラグメントより大きくなることがあります。データ スキューが生じる
と、データベース サーバが処理のために必要とするデータの量が、一部の
フラグメントでは多く、その他のフラグメントでは少なくなるため、性能
の不均等化につながります。
システム定義ハッシュ分散スキームを指定するには、次のように、CREATE
TABLE 文で FRAGMENT BY HASH 節を使用してください。
CREATE TABLE new_tab (id INT name CHAR(30))
FRAGMENT BY HASH (col_a) IN dbspace1, dbspace2, dbspace3
システム定義ハッシュ分散スキームでは、フラグメントを配置する DB 領域を少な
くとも 2 つ指定するか、DB スライスを 1 つ指定してください。
また、システム定義ハッシュ分散スキームに複合キーを指定することもできます。
XPS
ハイブリッド分散スキーム
ハイブリッド分散スキームは、同じ表に対して、ベース ストラテジとレベル 2 のス
トラテジを組み合わせて適用します。ベース ストラテジは、式に基づくフラグメン
ト化と範囲フラグメント化のどちらでもかまいません。ハイブリッド分散スキーム
を使用して、1 つまたは 2 つの列に対して、さまざまなフラグメンテーション スト
ラテジを適用することができます。
ハイブリッド分散スキームを定義するときに、フラグメント化式の格納定義域とし
て、単一の DB スライス、単一の DB 領域、または複数の DB 領域を指定することが
できます。
この節では、さまざまなハイブリッド スキームの例を示します。
式に基づくハイブリッド スキームの使用
ベース ストラテジを式に基づくフラグメント化とした場合は、レベル 2 のストラテ
ジは、式に基づくストラテジの結果に適用されるシステム定義ハッシュ ストラテジ
になります。
データベース サーバは、式に基づくハイブリッド スキームで表に数多くの行を挿
入する要求を受信すると、それらの行を次のように分散させます。
■
分散スキームの、式に基づくベース ストラテジを使用して、その行を格納
する DB スライスを決定します。
表フラグメンテーション ストラテジ
5-13
ハイブリッド分散スキーム
■
ハイブリッド スキームのレベル 2 の システム定義ハッシュ ストラテジを
使用して、その行を格納するために、事前に決定された DB スライスの DB
領域を決定します。
次の文は、表の 2 つの列に基づくハイブリッド スキームを定義します。
CREATE TABLE hybrid_tab (col_1 INT, col_2 DATE, col_3 CHAR(4))
HYBRID (col_1) EXPRESSION col_2 < '01/01/1998' IN dbsl_1,
col_2 >= '01/01/1998' AND col_2 < '01/01/1999' IN dbsl_2,
REMAINDER IN dbsl_3;
表に値を挿入すると、データベース サーバは、col_2 の値を使用して、その行を格
納する DB スライスを決定します。データベース サーバは、col_1 に対してハッ
シュ値を生成して、その行を格納する DB スライス内の DB 領域を決定します。
式に基づくハイブリッド スキームと範囲に基づくハイブリッド スキームのどちら
を定義しても、同じ分散結果を得ることができます。ただし、分散結果が同じで
あっても、範囲に基づくハイブリッド スキームの方が、式に基づくハイブリッド
スキームよりも正確な方法であり、便利な構文を持っています。
範囲に基づくハイブリッド スキームの使用
ベース ストラテジを範囲フラグメント化とした場合は、レベル 2 のストラテジも範
囲フラグメント化になります。以降の節では、範囲に基づくハイブリッド スキーム
を使用して 1 つまたは 2 つの列で表をフラグメント化する方法について説明します。
ハイブリッド スキームで範囲フラグメント化を指定するのに使用できる制約、規
則、およびさまざまな方法については、
『Informix Guide to SQL: Syntax』を参照し
てください。
単一列に適用される 2 つの範囲ストラテジ
次の文は、複数のコサーバにまたがる DB スライス内の単一列にあり、かつ各コ
サーバ上の DB スライス内の DB 領域を通じて同じ列にあるデータをフラグメント
化します。
CREATE TABLE tab1 (id_num INT,...)
...
FRAGMENT BY HYBRID (RANGE (id_num))
RANGE(id_num MIN 1 MAX 1800)
IN slice1, slice2
5-14
Informix Guide to Database Design and Implementation
ハイブリッド分散スキーム
図 5-2 は、特定の id_num 値を含んだ行を、DB スライス内の DB 領域間で分散する
方法を示しています。
図 5-2
単一列に対するハイブリッド範囲フラグメント化
コサーバ 1
slice1.1
slice1.2
slice1
slice1.3
id_num
301- 600
id_num
1 - 300
slice2.1
slice2
コサーバ 3
コサーバ 2
slice2.2
id_num
901 - 1200
id_num
601 - 900
slice2.3
id_num
1201 - 1500
id_num
1501 - 1800
指定の範囲 0 ∼ 1800 を外れる store_num の値がある場合、データベース サーバは
エラーを戻し、その値は表に挿入しません。このような問題を防ぐために、単一の
DB 領域内に REMAINDER フラグメントを指定することができます。ただし、
REMAINDER フラグメントを指定すると、範囲検索を要求する問合せに対する範
囲フラグメント表の効率が低下します。
2 つの列に適用される独立範囲ストラテジ
2 つの別個の列に対して独立範囲ストラテジを使用して行を分散させるハイブリッ
ド範囲スキームを使用することができます。次のスキームは、各 DB 領域に範囲を
2 つずつ、つまり、2 つの列のそれぞれに 1 つずつの範囲を割り当てます。
CREATE TABLE tab2 (id_num INT, loc_num INT,...)
...
FRAGMENT BY HYBRID (RANGE (id_num MIN 1 MAX 30))
RANGE(loc_num MIN 100 MAX 500) IN sl_1, sl_2
表フラグメンテーション ストラテジ
5-15
検索からのフラグメントの除去
この例では、それらの範囲は DB スライスの DB 領域間で細分されません。図 5-3
は、データベース サーバが DB スライス内の各 DB 領域に、DB スライスと同じ範囲
を割り当てる方法を示しています。
図 5-3
2 つの列に対するハイブリッド範囲フラグメント化
コサーバ 1
コサーバ 2
sl_1.1
sl_1.2
sl_1
sl_2
sl_1.3
id_num
11- 20 AND
loc_num
100 - 300
id_num
1 - 10 AND
loc_num
100 - 300
sl_2.1
sl_2.2
id_num
1 - 10 AND
loc_num
301 - 500
コサーバ 3
id_num
21 - 30 AND
loc_num
100 - 300
sl_2.3
id_num
11- 20 AND
loc_num
301 - 500
id_num
21 - 30 AND
loc_num
301 - 500
WHERE oc_num = 206 のように、loc_num 列だけの値を指定する問合せは、ある
特定の DB スライス内のすべての DB 領域を識別します。WHERE id_num = 21
AND loc_num = 305 のように、id_num 列と loc_num 列の両方の値を指定する問
合せは、DB スライスと交差する DB 領域を一意に識別します。
検索からのフラグメントの除去
適切な分散スキームを使用すると、データベース サーバは、検索からフラグメント
を除去してから、実際の検索を実行することができます。この機能を使用すれば、
性能を大幅に向上させ、フラグメントが常駐しているディスクの競合を減らすこと
ができます。
分散スキームと問合せ式のさまざまな組合せに対するフラグメント除去動作の詳細
については、
『Performance Guide』を参照してください。
5-16
Informix Guide to Database Design and Implementation
検索からのフラグメントの除去
フラグメント除去の問合せ式
データベース サーバが検索からフラグメントを除去できるかどうかは、次の 2 つの
要因によって決定されます。
■
問合せ式のフォーム (WHERE 節内の式 )
■
検索されている表の分散スキーム
次の 2 種類の問合せ式を使用して、フラグメントを除去することができます。
■
範囲式
■
等式
次の問合せ式テンプレートがあるとします。
column operator value
範囲式は、関係演算子 (<、>、<=、>=) を使用し、等式は等演算子 (=、IN) を使用
します。どちらの問合せ式でも、その値は、リテラル、ホスト変数、SPL ルーチン
変数、または非相関副問合せである必要があります。
XPS
範囲式または等式内の値は、Extended Parallel Server 上のリテラルまたはホスト変
数である必要があります。この値を SPL ルーチン変数または非相関副問合せにする
ことはできません。♦
フラグメント除去の式に基づいた分散スキーム
ラウンドロビン分散スキームを使用して表をフラグメント化する場合、データベー
ス サーバは、フラグメントを除去できません。さらに、使用するデータベース
サーバによっては、式に基づいた分散スキームを使用しても、必ずしも、同じフラ
グメント除去動作が実行されるとは限りません。以降の項では、特定のフラグメン
ト化規則とフラグメント除去動作との間の関係について説明します。
表フラグメンテーション ストラテジ
5-17
検索からのフラグメントの除去
単一列に基づく非重複フラグメント
単一列で非重複フラグメントを作成するフラグメント化規則では、等式による問合
せだけでなく範囲式による問合せに対しても、フラグメントを除去することができ
ます。図 5-4 に、単一列で非重複フラグメントを作成するフラグメント化規則の例
を示します。
図 5-4
単一列に基づく非
重複フラグメント
例の図
.
.
.
FRAGMENT BY EXPRESSION
a <= 8 OR a IN (9,10) IN dbsp1,
10 < a <= 20 IN dbsp2,
a IN (21,22, 23) IN dbsp3,
a > 23 IN dbsp4;
a <= 8 OR a IN (9,10)
10 < a <= 20
10
a IN (21,22,23)
20
a > 23
23
列a
非重複フラグメントを作成するには、単一列に基づく範囲規則または任意規則を使
用してください。AND、IN、OR、および BETWEEN だけでなく関係演算子も使
用できます。ただし、BETWEEN 演算子を使用するときには注意してください。
データベース サーバは、キーワード BETWEEN を構文解析する場合、値の範囲内
に、指定したエンド ポイントを含みます。
IDS
5-18
単一列で非重複フラグメントを作成するフラグメント化規則は、フラグメント除去
の観点から見て望ましいフラグメント化規則です。というのは、範囲式と等式を使
用すれば、Dynamic Server がフラグメントを問合せから除去できるからです。デー
タベース サーバが、必ずしも、残余フラグメントを除去できるとは限らないので、
式では REMAINDER 節を使用しないでください。♦
Informix Guide to Database Design and Implementation
検索からのフラグメントの除去
単一列に基づく重複フラグメント
このカテゴリのフラグメント化規則に対して制限があるのは、そのフラグメント化
規則が単一の列に基づいていることだけです。フラグメントは、重複や非連続の状
態になることもあります。単一列に基づく範囲規則または任意規則を使用すること
ができます。図 5-5 に、この型のフラグメント化規則の例を示します。
図 5-5
単一列に基づく重
複フラグメント例
の図
.
.
.
FRAGMENT BY EXPRESSION
a <= 8 OR a IN (9,10,21,22,23) IN dbsp1,
a > 10 IN dbsp2;
a <= 8 OR a IN (9,10, 21, 22, 23)
10
20
23
列a
a > 10
この型の分散スキームを使用すると、データベース サーバは、式が適合する最初の
DB 領域に行をロードします。
IDS
このカテゴリのフラグメント化規則の場合、Dynamic Server は、等検索ではフラグ
メントを除去できますが、範囲検索ではフラグメントを除去できません。ただし、
等検索でフラグメントを除去する機能が役に立つのは、INSERT 演算子すべてと、
UPDATE 演算子の多くで、等検索が実行されるからです。
単一列に基づく重複フラグメントを受け入れることができるのは、連続値を使用し
て非重複フラグメントを作成する式を使用できない場合です。たとえば、時間の経
過とともに表が大きくなるとします。この場合、式に基づいた分散スキームで
MOD 関数を使用すれば、同じくらいのサイズのフラグメントを保持することがで
きます。このように MOD 関数を使用する場合、各フラグメントの値は連続しない
ため、式に基づいた分散スキームは、このカテゴリに分類されます。♦
XPS
Extended Parallel Server は、等検索または範囲検索でフラグメントを除去すること
ができます。♦
表フラグメンテーション ストラテジ
5-19
検索からのフラグメントの除去
複数列に基づく非重複フラグメント
このカテゴリのフラグメント化規則では、任意規則を使用して、複数の列に基づく
非重複フラグメントを定義します。これは、単一列に基づく式を使用しても十分な
細分性を得ることができない場合に、選ぶことができます。図 5-6 に、2 つの列に
基づく非重複フラグメントの例を示します。
図 5-6
2 つの列に基づく
非重複フラグメン
ト例の図
.
.
.
FRAGMENT BY EXPRESSION
0 < a <= 10 AND b IN ('E', 'F','G') IN dbsp1,
0 < a <= 10 AND b IN ('H', 'I','J') IN dbsp2,
10 < a <= 20 AND b IN ('E', 'F','G') IN dbsp3,
10 < a <= 20 AND b IN ('H', 'I','J') IN dbsp4,
20 < a <= 30 AND b IN ('E', 'F','G') IN dbsp5,
20 < a <= 30 AND b IN ('H', 'I','J') IN dbsp6;
列b
b IN ('H', 'I','J')
b IN ('E', 'F','G')
0 < a <= 10
5-20
10 < a <= 20
20 < a <= 30
Informix Guide to Database Design and Implementation
列a
フラグメント表の作成
IDS
XPS
この型の分散スキームの場合、Dynamic Server は、等検索ではフラグメントを除去
できますが、範囲検索ではフラグメントを除去できません。この場合も先の場合と
同じように、等検索でフラグメントを除去する機能が役に立つのは、INSERT 演算
子すべてと、UPDATE 演算子の多くで、等検索が実行されるからです。データ
ベース サーバが、必ずしも、残余フラグメントを除去できるとは限らないので、式
では REMAINDER 節を使用しないでください。♦
この型の分散スキームの場合、Extended Parallel Server は、等検索や範囲検索でフ
ラグメントを除去できます。また、Extended Parallel Server は、残余フラグメント
を除去することもできます。♦
フラグメント表の作成
ここでは、SQL 文を使用してフラグメント表を作成および管理する方法を説明しま
す。表を作成すると同時に表をフラグメント化することも、既存のフラグメント化
されていない表をフラグメント化することもできます。これらについての概要は、
以降の節で説明します。フラグメント表の作成に使用する SQL 文の構文について
の詳細は、
『Informix Guide to SQL: Syntax』を参照してください。
フラグメント表を作成する前に、適切なフラグメンテーション ストラテジを決めて
おく必要があります。フラグメンテーション ストラテジを組み立てる方法について
は、
『Performance Guide』を参照してください。
フラグメント表を新たに作成する
フラグメント表を作成するには、CREATE TABLE 文で FRAGMENT BY 節を使用
します。stores_demo データベースの表 orders に似たフラグメント表を作成すると
します。3 つのフラグメントに関してラウンド ロビン分散スキームの使用を決定
し、次に、データベース サーバ管理者と相談の上、各フラグメントに対して 1 つず
つの DB 領域 dbspace1、dbspace2、および dbspace3 を設定します。次の SQL 文は
フラグメント表を作成します。
CREATE TABLE my_orders (
order_num SERIAL(1001),
order_date DATE,
customer_num INT,
ship_instruct CHAR(40),
backlog CHAR(1),
po_num CHAR(10),
ship_date DATE,
ship_weight DECIMAL(8,2),
ship_charge MONEY(6),
paid_date DATE,
PRIMARY KEY (order_num),
FOREIGN KEY (customer_num) REFERENCES customer(customer_num))
FRAGMENT BY ROUND ROBIN IN dbspace1, dbspace2, dbspace3
表フラグメンテーション ストラテジ
5-21
フラグメント表内の行 ID
IDS
表 my_orders が Dynamic Server データベースに常駐している場合には、式に基づ
くフラグメント化を使用して表を作成することもできます。表 my_orders に 30,000
行あり、これを dbspace1、dbspace2、および dbspace3 に格納される 3 つのフラグ
メントに均等に分散させるとします。次の文は、列 order_num を使用して、式に
基づくフラグメンテーション ストラテジを定義する方法を示しています。
CREATE TABLE my_orders (order_num SERIAL, ...)
FRAGMENT BY EXPRESSION
order_num < 10000 IN dbspace1,
order_num < 20000 IN dbspace2,
order_num >= 20000 IN dbspace3
♦
XPS
表 my_orders が Extended Parallel Server データベースに常駐している場合は、シス
テム定義ハッシュ分散スキームで表を作成して、複数のフラグメント間で均等分散
を実行することができます。表 my_orders に 120,000 行があり、これを異なる DB
領域に格納される 6 つのフラグメントに均等に分散させるとします。SERIAL 列
order_num を使用してフラグメントを定義することにします。
次の文は、列 order_num を使用して、システム定義ハッシュ フラグメンテーショ
ン ストラテジを定義する方法を示しています。
CREATE TABLE my_orders (order_num SERIAL, ...)
FRAGMENT BY HASH (order_num) IN dbspace1, dbspace2,
dbspace3, dbspace4, dbspace5, dbspace6
フラグメント表とフラグメント化されていない表の SERIAL 列値間に相違が発生す
ることがあります。Extended Parallel Server は、フラグメント内で、順番に
SERIAL 値を割り当てます。ただし、フラグメントに、非連続範囲の値が含まれて
いることがあります。こうした値はどれも指定できません。Extended Parallel
Server は、こうした範囲を制御して、範囲が重複しないことだけを保証します。
ヒント : Extended Parallel Server 上の DB スライスまたは DB 領域に表フラグメン
トを格納することができます。♦
フラグメント表内の行 ID
フラグメント化されていない表には、行 ID と呼ばれる隠し列があります。データ
ベース サーバは、フラグメント化されていない表の各行に一意の行 ID を割り当て
ます。フラグメント表には、この行 ID の列が自動的に挿入されていることはあり
ません。
IDS
5-22
フラグメント表の場合、WITH ROWIDS 節を使用して、行 ID の列を表に追加する
ことができます。ただし、Dynamic Server は、型付き表に対する WITH ROWIDS
節はサポートしません。♦
Informix Guide to Database Design and Implementation
フラグメント化されていない表からのフラグメント表の作成
XPS
Extended Parallel Server では、列の値を使用してフラグメント表の行を識別する必
要があります。データベース サーバは、フラグメント表の行 ID をサポートしませ
ん。♦
アプリケーションのアクセス方法として、行 ID ではなく主キーを使用することを
お勧めします。主キーは SQL の ANSI 仕様で定義されているため、主キーを使用し
てデータにアクセスすると、アプリケーションの移植性が向上します。また、デー
タベースがフラグメント表のデータにアクセスするのに要する時間は、主キーを使
用したときの方が行 ID を使用したときよりも短縮されます。
フラグメント化されていない表からのフラグメント表の作成
次のような場合には、フラグメント化されていない表をフラグメント表に変換する
必要があります。
■
アプリケーションで実行されたバージョンの表をフラグメント化する
いくつかの小さな表を大きな 1 つのフラグメント表に変換したいと思うは
ずです。この方法について、次の項で説明します。5-23 ページの「複数の
フラグメント化されていない表からのフラグメント表の作成」を参照して
ください。
■
既存の大規模な表をフラグメント化する
5-24 ページの「1 つのフラグメント化されていない表からのフラグメント
表の作成」を参照してください。
変換を行う前に、新しく作成したフラグメント表を格納するための適切な数の DB
領域を設定しておく必要があります。
複数のフラグメント化されていない表からのフラグメント表の作成
複数のフラグメント化されていない表を結合して、1 つのフラグメント表にするこ
とができます。フラグメント化されていない表の構造は同一でなければならず、
別々の DB 領域に格納されていなければなりません。フラグメント化されていない
表を結合するには、ALTER FRAGMENT 文で ATTACH 節を使用します。
たとえば、account1、account2、および account3 の 3 つのフラグメント化されてい
ない表があるとします。そして、それぞれを DB 領域 dbspace1、dbspace2、および
dbspace3 に格納するとします。3 つの表の構造はすべて同じであり、この 3 つの表
を 1 つの表に結合し、その表を共通列 acc_num に基づく式でフラグメント化しま
す。
acc_num の値が 1120 以下の行は dbspace1 に格納します。acc_num の値が 1120 よ
り大きく 2000 より小さい行は dbspace2 に格納します。最後に、acc_num の値が
2000 より大きい行は dbspace3 に格納します。
表フラグメンテーション ストラテジ
5-23
スマート ラージ オブジェクトのフラグメント化
以上のフラグメンテーション ストラテジで表をフラグメント化するには、次の
SQL 文を実行します。
ALTER FRAGMENT ON TABLE tab1 ATTACH
tab1 AS acc_num <= 1120,
tab2 AS acc_num > 1120 and acc_num <= 2000,
tab3 AS acc_num > 2000
この結果、1 つの表 tab1 に結合されます。他の表 tab2 と tab3 は使い果たされて消
失します。
ALTER FRAGMENT 文の ATTACH と DETATCH の各節を使用して性能を向上さ
せる方法については、
『Performance Guide』を参照してください。
1 つのフラグメント化されていない表からのフラグメント表の作成
フラグメント化されていない表からフラグメント表を作成するには、ALTER
FRAGMENT 文の INIT 節を使用します。たとえば、表 orders をラウンド ロビンで
フラグメント表に変換するとします。次に示す SQL 文で変換します。
ALTER FRAGMENT ON TABLE orders INIT FRAGMENT BY ROUND ROBIN
IN dbspace1, dbspace2, dbspace3
フラグメント化されていない表に対する既存のインデックスは、その表と同じフラ
グメンテーション ストラテジでフラグメント化されます。
IDS
スマート ラージ オブジェクトのフラグメント化
CREATE TABLE 文の PUT 節で複数の SB 領域を指定し、1 つの列に対してスマート
ラージ オブジェクトのラウンド ロビン フラグメント化を行うことができます。
CLOB 列または BLOB 列に対して複数の SB 領域を指定した場合、データベース
サーバは、その列に対するスマート ラージ オブジェクトを、指定された SB 領域に
ラウンド ロビン方式で分散させます。次の CREATE TABLE 文によりデータベース
サーバは、ラージ オブジェクトを列 cat_photo から sbcat1、sbcat2、および sbcat3
にラウンド ロビン方式で分散させることができます。
CREATE TABLE catalog (
catalog_num SERIAL,
stock_num
SMALLINT,
manu_code
CHAR(3),
cat_descr
LVARCHAR,
cat_photo
BLOB)
PUT cat_picture in (sbcat1, sbcat2, sbcat3)
5-24
Informix Guide to Database Design and Implementation
フラグメンテーション ストラテジの変更
フラグメンテーション ストラテジの変更
フラグメント表を変更するには 2 種類の一般的な方法があります。1 番目は、フラ
グメント化されていない表に対する変更方法です。この変更方法には、列の追加、
列の削除、列のデータ型の変更などがあります。これらの変更方法では、通常はフ
ラグメント化されていない表に対して使用する ALTER TABLE 文を使用します。2
番目の変更方法は、フラグメンテーション ストラテジに対する変更方法です。この
節では、SQL 文を使用してフラグメンテーション ストラテジを変更する方法を説明
します。
フラグメンテーションを実装した後に、フラグメンテーション ストラテジを変更し
なければならない場合があります。最も頻繁にあるのは、内部問合せの並列化また
は相互問合せの並列化でフラグメンテーションを使用する場合にフラグメンテー
ション ストラテジを変更する必要が生じる場合です。このような場合に、フラグメ
ンテーション ストラテジの変更は、データベースサーバシステムの性能を向上する
方法の 1 つとして使用できます。
XPS
Extended Parallel Server は、ALTER FRAGMENT ON TABLE 文に対してだけ、次
のオプションをサポートします。
■
ATTACH 節
■
DETACH 節
■
INIT 節
HASH フラグメント化を使用する表は、INIT オプションだけをサポートします。
Extended Parallel Server は、ADD、DROP、および MODIFY オプションをサポー
トしません。ただし、追加、削除、または変更の処理を行うために、ADD、
DROP、および MODIFY の代わりにサポートされるオプションを使用することがで
きます。
重要 : Extended Parallel Server では、ALTER FRAGMENT ON INDEX 文または明
示的な ROWIDS 列をサポートしていません。♦
INIT 節を使用してフラグメント化スキームを再初期化
INIT 節が指定された ALTER FRAGMENT 文を使用して、フラグメント化されてい
ない表に対する新規のフラグメンテーション ストラテジの定義と初期化を行った
り、フラグメント表に対する既存のフラグメンテーション ストラテジを変換するこ
とができます。INIT 節を使用して、フラグメント化式の評価順序を変更することも
できます。
表フラグメンテーション ストラテジ
5-25
INIT 節を使用してフラグメント化スキームを再初期化
次の例は、INIT 節を使用してフラグメンテーション ストラテジを完全に再初期化
する方法を示しています。
まず、次のフラグメント表を作成するとします。
CREATE TABLE account (acc_num INTEGER, ...)
FRAGMENT BY EXPRESSION
acc_num <= 1120 in dbspace1,
acc_num > 1120 and acc_num < 2000 in dbspace2,
REMAINDER IN dbspace3
しかし、この分散スキームで作業を始めてから数か月後、dbspace2 に格納されるフ
ラグメントの行数がほかの 2 つのフラグメントの行数の 2 倍になっていることが判
明しました。この不均衡は、dbspace2 を含むディスクが入出力のボトルネックにな
る原因となります。
そこで、この状況を改善するため、分散を変更して各フラグメントの行数を平均化
します。3 つのフラグメントの代わりに 4 つのフラグメント含むように分散スキー
ムを変更することにします。新しい DB 領域 dbspace2a は、以前に dbspace2 に格納
されていた行の最初の半分を格納する新しいフラグメントを含めるためのもので
す。dbspace2 のフラグメントには、以前に格納されていた行の残りの半分が格納さ
れます。
新しい分散スキームを実装するには、まず DB 領域 dbspace2a を作成します。その
後、次の文を実行します。
ALTER FRAGMENT ON TABLE account INIT
FRAGMENT BY EXPRESSION
acc_num <= 1120 in dbspace1,
acc_num > 1120 and acc_num <= 1500 in dbspace2a,
acc_num > 1500 and acc_num < 2000 in dbspace2,
REMAINDER IN dbspace3
この文を実行するとすぐに、データベースサーバによって前のフラグメンテーショ
ン ストラテジが破棄され、表に格納されていた行は、新しいフラグメンテーション
ストラテジに従って再分散化されます。
また、ALTER FRAGMENT 文の INIT 節を使用して、次のことが行えます。
■
1 つのフラグメント化されていない表をフラグメント表に変換する。
■
フラグメント表をフラグメント化されていない表に変換する。
■
何らかのストラテジでフラグメント化した表を、別のフラグメンテーショ
ン ストラテジに変換する。
詳細は、
『Informix Guide to SQL: Syntax』の ALTER FRAGMENT 文を参照してく
ださい。
5-26
Informix Guide to Database Design and Implementation
INIT 節を使用してハッシュ フラグメント化をハイブリッド フラグメント化に変更
XPS
INIT 節を使用してハッシュ フラグメント化をハイブリッド
フラグメント化に変更
Extended Parallel Server では、フラグメンテーション ストラテジの変更にデータの
移動が必要となる場合、ALTER FRAGMENT ON TABLE 文で INIT 節を指定するこ
とができます。INIT 節を使用すると、データベース サーバは、新しいフラグメン
ト化スキームで表のコピーを作成し、元の表から読み取った行を新しい表に挿入す
ることができます。
ユーザの問合せが通常は列 id に対する等検索を使用するため、列 id に対してハッ
シュでフラグメントを分散させる次の表 prod_info を作成します。
CREATE TABLE prod_info
(id INT,
color INT,
details CHAR(100))
FRAGMENT BY HASH(id) IN dbsl
ある時点になって、列 id の値ではなく列 color の値を指定する、ほかの重要な問合
せを実行する必要があることに気づいたとします。この種のシナリオを処理するた
めに、表 prod_info のデータ レイアウトを変更して、フラグメントを除去しやすく
することができます。次の ALTER FRAGMENT 文は、INIT 節を使用して、ハッ
シュ分散スキームからハイブリッド分散スキームに変更する方法を示しています。
ALTER FRAGMENT ON TABLE prod_info INIT
FRAGMENT BY HYBRID(id)
EXPRESSION color = 1 IN dbsl, color = 2 IN dbsl2, ...
REMAINDER IN dbsl8
IDS
MODIFY 節を使用して既存のフラグメンテーション
ストラテジを変更
Dynamic Server では、MODIFY 節を指定した ALTER FRAGMENT 文を使用して、
既存のフラグメンテーション ストラテジで 1 つまたは複数の式を変更してくださ
い。
まず、次のフラグメント表を作成します。
CREATE TABLE account (acc_num INT, ...)
FRAGMENT BY EXPRESSION
acc_num <= 1120 IN dbspace1,
acc_num > 1120 AND acc_num < 2000 IN dbspace2,
REMAINDER IN dbspace3
表フラグメンテーション ストラテジ
5-27
ATTACH 節および DETACH 節を使用して既存の フラグメンテーション ストラテジを変更
次の ALTER FRAGMENT 文を実行した場合、0 以下の値のアカウント番号が、
dbspace1 にあるフラグメントに格納されていないことを確認します。
ALTER FRAGMENT ON TABLE account
MODIFY dbspace1 TO acc_num > 0 AND acc_num <=1120
MODIFY 節を使用しても、分散スキームに含まれているフラグメントの数を変更す
ることはできません。その代わりに、ALTER FRAGMENT 文で INIT 節または
ADD 節を使用してください。
XPS
ATTACH 節および DETACH 節を使用して既存の
フラグメンテーション ストラテジを変更
Extended Parallel Server では、データを移動する必要がある場合、INIT 節を指定し
た ALTER FRAGMENT 文を使用することができます。それ以外の場合、既存のフ
ラグメントの式を変更する以下のオプションを指定した ALTER FRAGMENT 文を
使用します。
■
DETACH 節を使用して、変更したい式のあるフラグメントを削除します。
■
ATTACH 節を使用して、新しい式でフラグメントを再度確保します。
まず、次のフラグメント表を作成します。
CREATE TABLE account (acc_num INT, ...)
FRAGMENT BY EXPRESSION
acc_num <= 1120 IN dbspace1,
acc_num > 1120 AND acc_num < 2000 IN dbspace2,
REMAINDER IN dbspace3
次の文は、dbspace1 に含まれているフラグメントを変更して、0 以下の値のアカウ
ント番号がこのフラグメントに格納されないようにします。
ALTER FRAGMENT ON TABLE account
DETACH dbspace1 det_tab;
CREATE TABLE new_tab (acc_num INT, ...)
FRAGMENT BY EXPRESSION
acc_num > 0 AND acc_num <=1120 IN dbspace1;
ALTER FRAGMENT ON TABLE account
ATTACH account, new_tab
INSERT INTO account SELECT * FROM det_tab;
DROP TABLE det_tab;
5-28
Informix Guide to Database Design and Implementation
ATTACH 節および DETACH 節を使用して既存の フラグメンテーション ストラテジ
重要 : 表がハッシュ フラグメント化されている場合には、ATTACH 節または
DETACH 節を指定した ALTER TABLE 文を使用することはできません。ただし、
ハッシュ フラグメント化されている表には、INIT 節を指定した ALTER TABLE 文を
使用できます。
ATTACH 節を使用してフラグメントを追加
ALTER FRAGMENT ON TABLE 文の ATTACH 節を使用すると、表にフラグメント
を追加することができます。次の文を使用して作成した表にフラグメントを追加す
るとします。
CREATE TABLE sales (acc_num INT, ...)
FRAGMENT BY ROUND ROBIN IN dbspace1, dbspace2, dbspace3
新規フラグメント dbspace4 を表 sales に追加するには、まず、sales と構造が同じ
で、その新規フラグメントを指定する表を新規作成します。その後、ALTER
FRAGMENT 文で ATTACH 節を使用して、この表に新規フラグメントを追加しま
す。次の文を使用すると、表 sales に新規フラグメントが追加されます。
CREATE TABLE new_tab (acc_num INT, ...)
IN dbspace4;
ALTER FRAGMENT ON TABLE sales
ATTACH sales, new_tab
ATTACH 節を実行すると、データベース サーバは表 sales を 4 つの DB 領域にフラ
グメント化します。そのうち 3 つが sales の DB 領域で、1 つが new_tab の DB 領域
です。表 new_tab は使い果たされます。
DETACH 節を使用してフラグメントを削除
ALTER FRAGMENT ON TABLE 文の DETACH 節を使用すると、表からフラグメン
トを削除することができます。次の文を使用して作成した表からフラグメントを削
除するとします。
CREATE TABLE sales (acc_num INT)...)
FRAGMENT BY EXPRESSION
acc_num <= 1120 IN dbspace1,
acc_num > 1120 AND acc_num <= 2000 IN dbspace2,
acc_num > 2000 AND acc_num < 3000 IN dbspace3,
REMAINDER IN dbspace4
表フラグメンテーション ストラテジ
5-29
ADD 節を使用してフラグメントを追加
データを失わずに、表 sales から、3 番目のフラグメントの dbspace3 を削除するに
は、次の文を実行します。
ALTER FRAGMENT ON TABLE sales
DETACH dbspace3 det_tab;
INSERT INTO sales SELECT * FROM det_tab;
DROP TABLE det_tab;
ALTER FRAGMENT 文を使用すると、表 sales の分散スキームから dbspace3 が切
り離され、新規の表 det_tab に行が配置されます。INSERT 文を使用すると、以前
に dbspace3 に挿入された行が、新規の表 sales に再挿入されます。この結果、この
時点で、フラグメントは、dbspace1、dbspace2、および dbspace4 の 3 つになりま
す。表 det_tab は、もはや必要でないので、DROP TABLE 文を使用して削除しま
す。
IDS
ADD 節を使用してフラグメントを追加
フラグメンテーション ストラテジを定義するとき、1 つまたは複数のフラグメント
の追加が必要になる場合があります。Dynamic Server では、ALTER FRAGMENT
文の ADD 節を使用すれば、表に新規フラグメントを追加することができます。次
の文を使用して作成した表にフラグメントを追加するとします。
CREATE TABLE sales (acc_num INT, ...)
FRAGMENT BY ROUND ROBIN IN dbspace1, dbspace2, dbspace3
新規フラグメント dbspace4 を表 sales に追加するには、次の文を実行します。
ALTER FRAGMENT ON TABLE sales ADD dbspace4
フラグメンテーション ストラテジが式に基づいている場合は、ALTER
FRAGMENT 文の ADD 節には、既存の DB 領域の前または後に DB 領域を 1 つ追
加するオプションが含まれています。
『Informix Guide to SQL: Syntax』の ALTER
ADD 節の詳細については、
FRAGMENT 文の説明を参照してください。
5-30
Informix Guide to Database Design and Implementation
DROP 節を使用してフラグメントを削除
IDS
DROP 節を使用してフラグメントを削除
フラグメンテーション ストラテジを定義するとき、1 つまたは複数のフラグメント
の削除が必要になる場合があります。Dynamic Server では、ALTER FRAGMENT
ON TABLE 文の DROP 節を使用すると、表からフラグメントを削除することがで
きます。次の文を使用して作成した表からフラグメントを削除するとします。
CREATE TABLE sales (col_a INT), ...)
FRAGMENT BY ROUND ROBIN IN dbspace1, dbspace2, dbspace3
次の ALTER FRAGMENT 文では、DROP 節を使用して、表 sales から、3 番目のフ
ラグメント dbspace3 を削除します。
ALTER FRAGMENT ON TABLE sales DROP dbspace3
この文を実行すると、dbspace3 内の行はすべて、残っている DB 領域の dbspace1
と dbspace2 に移動されます。
『Informix Guide to SQL: Syntax』の ALTER
DROP 節についての詳細は、
FRAGMENT 文を参照してください。
一時表のフラグメント化
一時表を作成する場合には、この一時表をフラグメント化することができます。
データベース サーバは、一時表の削除と同時に、その一時表用に作成されたフラグ
メントを削除します。一時表のフラグメント化に対しては、一時表のフラグメン
テーション ストラテジを変更できない ( 永続表ではフラグメンテーション ストラテ
ジを変更できるが ) という制限があります。
IDS
Dynamic Server では、CREATE TABLE 文の TEMP TABLE 節を使用すると、フラ
グメント化された一時表を作成することができます。♦
XPS
Extended Parallel Server による一時表のフラグメント化
Extended Parallel Server を使用すれば、種々のコサーバに属している複数のディス
ク間で、明示的な一時表をフラグメント化することができます。明示的な一時表と
は、次の SQL 文のどちらかを使用して作成した一時表を指します。
■
CREATE TABLE 文の TEMP TABLE オプションまたは SCRATCH TABLEオ
プション
■
SELECT 文の INTO TEMP 節または INTO SCRATCH 節
表フラグメンテーション ストラテジ
5-31
Extended Parallel Server による一時表のフラグメント化
重要 : コサーバが一時領域として使用したりアクセスしたりできるのは、そのコ
サーバ自体の DB 領域だけです。一時表は、永続表と同じように、複数の DB 領域
間で明示的にフラグメント化することができます。ただし、コサーバは、管理する
フラグメント内にだけデータを挿入します。
明示的な一時表に、ユーザ固有のフラグメンテーション ストラテジを定義すること
も、Extended Parallel Server に動的にフラグメンテーション ストラテジを決めさせ
ることもできます。( 詳細については、
『Performance Guide』を参照してください。
ユーザ固有のフラグメンテーション ストラテジの定義
一時表を作成するには、CREATE TABLE 文の TEMP TABLE 節または SCRATCH
TABLE 節を使用します。TEMP 表または SCRATCH 表をフラグメント化するには、
FRAGMENT BY 節を使用して、分散スキームと、一時表に使用する DB 領域または
DB スライスを指定してください。
Extended Parallel Server によるフラグメンテーション
ストラテジの定義
Extended Parallel Server は、次の型の問合せの実行中に、フラグメンテーション ス
トラテジを作成し決定します。
SELECT * FROM customer INTO SCRATCH temp_table
または
SELECT * FROM customer INTO TEMP temp_table
前述の問合せに応答して作成される明示的な一時表は、フレックス ( フレキシブル
な ) 一時表と呼ばれます。フレックス一時表は、ラウンドロビン分散スキームでフ
ラグメント化されます。列名とデータ型については、明示的な一時表ではわかって
いる必要があっても、フレックス一時表ではわかっている必要はありません。
SELECT...INTO TEMP 構文を使用した場合、Extended Parallel Server では、DB 領
域と DB スライスを使用して一時表を格納するときには、フレックス一時表演算子
を使用して格納方法を最適化します。フレックス演算子は、これらのフラグメント
への挿入を並列で実行します。それは、PDQ_PRIORITY が 0 である場合でも同じ
です。問合せまたはセグメントの並列化により、フレックス SQL 挿入演算子のイ
ンスタンスの数が決まります。各フレックス一時表演算子は、フレックス一時表の
フラグメントを格納する候補としてデータベース サーバが選択したコサーバ上で実
行されます。
5-32
Informix Guide to Database Design and Implementation
表インデックスのフラグメント化
重要 : フレキシブルな一時表の機能は、複数の DB 領域でデータの格納や検索を行
う場合、これらの DB 領域を管理する各種コサーバ上で、SQL 演算子を使用しま
す。コサーバは、その専用 DB 領域だけを使用しそこにアクセスすることができま
す。
各フレックス演算子がフレックス一時表のデータを受信すると、Extended Parallel
Server は、DBSPACETEMP の値に基づいて、使用可能な DB 領域の 1 つにフラグメ
ントを作成し、そのフラグメントにデータを少量追加します。その DB 領域が一杯
になると、データベース サーバは、別の DB 領域に一時表のフラグメントを作成し
ます。SQL 演算子は、引き続き、データをこの一時表に追加します。フレックス挿
入演算子のインスタンスは、データを受信しなければ、フラグメントを作成しませ
ん。
表インデックスのフラグメント化
表データと表インデックスはどちらもフラグメント化することができます。イン
デックスのフラグメンテーション ストラテジは、表データフラグメンテーション
ストラテジと同じにすること ( 連結インデックス ) も、表データ ストラテジから独
立させること ( 分離インデックス ) もできます。
連結インデックスを使用すると、一般的には、分離インデックスを使用した場合よ
り操作の効率が高くなります。インデックスの性能を考慮するための一般的な情報
については、
『Performance Guide』を参照してください。
連結インデックス
連結インデックスとは、明示的な格納オプションを使用せずに作成したインデック
スのことです。連結インデックスでは、インデックス フラグメントの数は、データ
フラグメントの数と同じになります。フラグメント表上にインデックスを作成する
が、該当するインデックスの分散スキームは指定しない場合、デフォルトでは、
データベース サーバが、表と同じ分散スキームに基づいてインデックスをフラグメ
ント化します。もっと具体的に言えば、データベース サーバは、表データと同じ規
則を使用してインデックス キーをフラグメントに分散し、対応する表データと同じ
DB 領域にそのインデックス キーを配置します。
IDS
Dynamic Server では、フラグメント化されていない表の連結インデックスは、表
データと同じ表領域に格納されます。このため、インデックス ページは、データ
ページでインタリーブされます。ただし、フラグメント表の連結インデックスは、
表データと異なる表領域に格納されます。このため、インデックスと表データは、
同じ DB 領域を共有しますが、インデックス ページは、データ ページでインタリー
ブされません。♦
表フラグメンテーション ストラテジ
5-33
分離インデックス
XPS
Extended Parallel Server では、連結インデックス ( フラグメント表に対するものも
フラグメント化されていない表に対するものも ) は、表データと異なる表領域に格
納されます。このため、インデックスと表データは同じ DB 領域を共有しますが、
インデックス ページはデータ ページでインタリーブされません。図 5-7 に、
Extended Parallel Server のフラグメント表に連結されるインデックスの格納スキー
ムを示します。
図 5-7
Extended Parallel Server 用の表に
連結されるインデックスの格納スキーム
コサーバ 1
DB 領域 1
データ インデックス
コサーバ 2
DB 領域 2
データ
インデックス
...
コサーバ n
...
DB 領域 n
...
データ
インデックス
♦
分離インデックス
インデックス用のフラグメント化スキームは、表データ用のフラグメント化スキー
ムと異なることもあります。分離インデックスは、表のフラグメント化から独立し
たフラグメンテーション ストラテジを持つインデックス、つまり、表がフラグメン
ト化されるときにフラグメント化されないインデックスです。
CREATE INDEX 文の FRAGMENT BY 節を使用すれば、任意の表に対するイン
デックスをフラグメント化することができます。
フラグメント表のインデックスがフラグメント化されないようにしたい場合は、
CREATE INDEX...IN DBSPACE 文を使用して、別々の DB 領域にインデックスを配
置することができます。
Informix データベースでは、ラウンド ロビン分散スキームを使用して分離インデッ
クスを作成することはできません。
IDS
5-34
Dynamic Server では、式に基づく分散スキームを使用すれば、表に対する分離イン
デックスを作成することができます。
Informix Guide to Database Design and Implementation
行 ID
ALTER FRAGMENT ON INDEX 文を使用すれば、フラグメント化されたインデッ
クスのフラグメンテーション ストラテジを変更することができます。♦
XPS
Extended Parallel Server では、式に基づいた分散スキーム、システム定義ハッシュ
分散スキーム、またはハイブリッド分散スキームを使用すれば、任意の表の分離イ
ンデックスを作成することができます。
Extended Parallel Server は、ローカル分離インデックスと広域分離インデックスの
両方をサポートします。ローカル分離インデックスのフラグメントは、同じコサー
バに格納されます。広域分離インデックスのフラグメントは、それぞれ異なるコ
サーバに格納されます。
Extended Parallel Server では、ALTER FRAGMENT ON INDEX 文をサポートして
いません。フラグメント化されたインデックスのフラグメンテーション ストラテジ
を変更するには、まず、DROP INDEX 文を使用してインデックスを削除した後、
CREATE INDEX 文を使用して、新規のフラグメンテーション ストラテジでイン
デックスを再作成する必要があります。♦
行 ID
行 ID とは、行の物理的位置を定義する整数を指します。フラグメント化されてい
ない表にある行の行 ID は、一意な定数値です。これとは対照的に、フラグメント
表にある行には行 ID は割り当てられません。行を参照する場合には、主キー値を
使用することをお勧めします。主キーは、SQL の ANSI 仕様で定義されています。
主キーを使用すると、アプリケーションの移植性が向上します。
IDS
アプリケーションで、フラグメント表の行 ID を参照する必要がある場合、このア
プリケーションに対処するには、Dynamic Server を使用すると、フラグメント表の
行 ID の列を明示的に作成することができます。明示的に作成された行 ID の列を使
用して行にアクセスすると、主キーを使用してアクセスするより時間がかかりま
す。
行 ID の列の作成
行 ID の列を作成するには、次の SQL 構文を使用してください。
■
CREATE TABLE 文の WITH ROWIDS 節
■
ALTER TABLE 文の ADD ROWIDS 節
■
ALTER FRAGMENT 文の INIT 節
行 ID の列は、作成または変更する表にある列の 1 つとして指定することによって、
作成することはできません。
表フラグメンテーション ストラテジ
5-35
フラグメント表に格納されているデータへのアクセス
行 ID の列を作成すると何が実行されるか
行 ID の列を作成すると、データベース サーバは、次の動作を実行します。
■
表内の各行に 4 バイトの一意値を追加する。
■
行 ID で表のデータにアクセスするときに使用する内部インデックスを作
成する。
■
内部インデックス用に、システム カタログ表 sysfragments に行を 1 行挿入
する。
♦
フラグメント表に格納されているデータへのアク
セス
複数の方法を使用して、フラグメント化されていない表に格納されている行にアク
セスすることができます。アクセスする行の行 ID を参照するのも 1 つの方法です。
IDS
Dynamic Server では、フラグメント表に格納されている行を行 ID により参照する
場合は、行 ID の列を明示的に作成する必要があります。行 ID の列の作成について
は、5-37 ページの「フラグメント表の行 ID の列の作成」を参照してください。
ユーザ アプリケーションがフラグメント表の行 ID を参照しようとしたときに、
ユーザが明示的に作成した行 ID がそのフラグメント表に指定されていない場合、
データベース サーバは該当のエラー メッセージを表示し、アプリケーションの実
行は停止されます。
Dynamic Server だけが、フラグメント表の行 ID をサポートします。♦
XPS
Extended Parallel Server で行を識別するには、列の値を使用する必要がありま
す。♦
IDS
行 ID の代わりに主キーを使用する
Informix では、アプリケーションにアクセスする方法として、行 ID ではなく主
キーを使用することをお勧めします。主キーは SQL の ANSI 仕様で定義されている
ため、主キーを使用してデータにアクセスすると、アプリケーションの移植性が向
上します。さらに、主キーでアクセスすることによって、多くの状況下で性能が飛
躍的に向上し、特に、並列アクセスのときに顕著です。
データにアクセスするための主キーの定義方法と使用方法についての詳細は、
『Informix Guide to SQL: Reference』と『Informix Guide to SQL: Syntax』を参照し
てください。
5-36
Informix Guide to Database Design and Implementation
フラグメント表の行 ID の列の作成
フラグメント表の行 ID の列の作成
アプリケーションの観点からみると、フラグメント表のなかの行 ID の列の機能は
フラグメント化されていない表の行 ID の機能と同じです。しかし、フラグメント
化されていない表の行 ID とは異なり、データベースサーバは、インデックスを使
用して行 ID を物理的な位置にマッピングします。
何らかの理由でアプリケーションが行 ID の列を使用してフラグメント表のデータ
にアクセスする必要がある場合は、フラグメント表に対する行 ID の列を作成しな
ければなりません。
この列は、表を作成したときに、CREATE TABLE 文の WITH ROWIDS 節を使用し
て作成することができます。CREATE TABLE...WITH ROWIDS 文を発行すると、
データベースサーバによって行 ID の列が作成され、フラグメント表の各行に、4 バ
イトずつ追加されます。さらに、データベースサーバは、行 ID によって表内の
データにアクセスするために使用する内部インデックスを作成します。行 ID の列
が作成された後、データベース サーバによってシステム カタログ表 sysfragments
に行が 1 行挿入されます。これは、行 ID の列の存在と属性を示すものです。
フラグメント表を作成した後で、行 ID の列が必要であると判明した場合には、
ALTER TABLE 文の ADD ROWIDS 節か ALTER FRAGMENT 文の INIT 節を使用
します。
フラグメント表の行 ID の列を削除するには、ALTER TABLE 文の DROP ROWIDS
節を使用します。詳細は、
『Informix Guide to SQL: Syntax』の ALTER TABLE 文の
説明を参照してください。
行 ID の列は、作成または変更する表内の列の 1 つとして指定して、作成または追
加することはできません。たとえば、次の文を実行します。
CREATE TABLE test_table (rowid INTEGER, ....)
この場合、次のようなエラーが戻されます。
-227 DDL options on rowid are prohibited. error.
表フラグメンテーション ストラテジ
5-37
フラグメント アクセス権の付与と取消し
フラグメント アクセス権の付与と取消し
有益なフラグメント アクセス権を付与したい場合は、データ分散を制御するストラ
テジを持つ必要があります。式によるデータ レコードのフラグメント化は効果的な
ストラテジの 1 つです。ラウンドロビンアルゴリズムによるデータレコード分散ス
トラテジは、新しいデータレコードが次のフラグメントに追加されるため、有益な
ストラテジではありません。ラウンド ロビン分散は、データ分散を追跡する有効な
方法をすべて無効にしてしまうため、フラグメント化の権限が実際に使用されるこ
とはなくなってしまいます。式に基づく分散とラウンド ロビン分散の間にはこのよ
うな違いがあるため、GRANT FRAGMENT 文と REVOKE FRAGMENT 文は、式に
基づいてフラグメント化された表にのみ適用されます。
重要 : ラウンド ロビン ストラテジでフラグメント化された表に対して、GRANT
FRAGMENT 文や REVOKE FRAGMENT 文を発行すると、コマンドは失敗し、エ
ラーメッセージが戻されます。
IDS
Dynamic Server だけが、GRANT FRAGMENT 文および REVOKE FRAGMENT 文
をサポートします。♦
フラグメント表を作成する場合、デフォルトのフラグメントアクセス権はありませ
ん。GRANT FRAGMENT 文を使用して、1 つ以上のフラグメントに対する挿入、
更新、削除のアクセス権を付与します。3 つのアクセス権すべてを 1 度に付与した
い場合は、GRANT FRAGMENT 文でキーワード ALL を使用します。ただし、フ
ラグメントを含む表の名前を指定しただけでは、フラグメントアクセス権を付与す
ることはできません。特定のフラグメントを指定する必要があります。
挿入、更新、削除の各アクセス権を取り消す場合は、REVOKE FRAGMENT 文を使
用します。この文は、1 人以上のユーザから、フラグメント表の 1 つ以上のフラグ
メントに対するアクセス権を取り消します。表に対して現在存在しているアクセス
権をすべて取り消したい場合は、キーワード ALL を使用することができます。コ
マンドにフラグメントを指定しないと、表のすべてのフラグメントに対して現在許
可されているアクセス権が取り消されます。
詳細については、
『Informix Guide to SQL: Syntax』の GRANT FRAGMENT 文、
REVOKE FRAGMENT 文、および SET 文の説明を参照してください。
5-38
Informix Guide to Database Design and Implementation
第6章
データベース サーバのアク
セス権の付与と制限
この章の概要 . .
.
. .
.
. .
. .
.
. .
.
. .
. .
.
. .
.
. .
6-3
データベースへのアクセスの制御 .
. .
.
. .
.
. .
. .
.
. .
.
. .
6-3
アクセス権の付与 . . . . . . . . . . . . . . . . . . . . .
データベースレベルアクセス権 . . . . . . . . . . . . . . .
Connect アクセス権 . . . . . . . . . . . . . . . . . .
Resource アクセス権 . . . . . . . . . . . . . . . . .
データベース管理者としてのアクセス権 . . . . . . . . . .
所有者の権限 . . . . . . . . . . . . . . . . . . . . .
表レベルアクセス権 . . . . . . . . . . . . . . . . . . .
アクセス権 . . . . . . . . . . . . . . . . . . . . .
Index アクセス権、Alter アクセス権、および References アクセス権
型付き表に対する Under アクセス権 . . . . . . . . . . . .
列レベルアクセス権 . . . . . . . . . . . . . . . . . . .
型レベル アクセス権 . . . . . . . . . . . . . . . . . . .
ユーザ定義型の Usage アクセス権 . . . . . . . . . . . . .
名前付き行 (ROW) 型の Under アクセス権 . . . . . . . . . .
ルーチン レベル アクセス権 . . . . . . . . . . . . . . . .
言語アクセス権 . . . . . . . . . . . . . . . . . . . . .
アクセス権の自動化 . . . . . . . . . . . . . . . . . . .
コマンドスクリプトによる自動化 . . . . . . . . . . . . .
ロールの使用 . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6-4
6-5
6-5
6-6
6-6
6-7
6-7
6-8
6-9
6-10
6-11
6-12
6-13
6-13
6-14
6-14
6-15
6-16
6-16
SPL ルーチンによるデータへのアクセスの制御
データの読込みの制限 . . . . . . .
データへの変更の制限 . . . . . . .
データへの変更の監視 . . . . . . .
オブジェクト作成の制限 . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6-19
6-19
6-20
6-21
6-22
ビューの使用 . . . . .
ビューの作成 . . .
型付きビュー . .
ビューの重複行 .
ビューに対する制限
ベースの変更の反映
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6-23
6-24
6-25
6-26
6-26
6-27
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ビューを用いたデータの変更 . . . . . . . . . . . . .
ビューを用いたデータの削除 . . . . . . . . . . .
ビューの更新 . . . . . . . . . . . . . . . . .
ビューへの挿入 . . . . . . . . . . . . . . . .
WITH CHECK OPTION キーワードの使用 . . . . . .
PREPARE 文で処理された文をビュー定義の変更時に再実行
アクセス権とビュー . . . . . . .
ビューの作成時のアクセス権 . . .
ビューを使用するときのアクセス権
6-2
.
.
.
. .
. .
. .
Informix Guide to Database Design and Implementation
. .
. .
. .
.
.
.
. .
. .
. .
.
.
.
.
.
.
.
.
.
. .
. .
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6-28
6-29
6-29
6-29
6-30
6-31
. .
. .
. .
.
.
.
6-31
6-31
6-32
この章の概要
この章では、データベースへのアクセスの制御方法について説明します。データ
ベースによっては、すべてのユーザがすべてのデータにアクセスできる場合もあり
ます。それ以外のデータベースでは、ユーザによっては、データの一部またはすべ
てへのアクセスが拒否されます。この章では、データへのアクセスを次のようなレ
ベルで制限することについて説明します。
■
GRANT 文と REVOKE 文を使用して、データベースや特定の表に対するア
クセス権を付与したり拒否したりすることができます。また、データベー
スの利用の仕方を制御することもできます。
■
CREATE PROCEDURE 文 または CREATE FUNCTION 文を使用して、
ユーザ定義ルーチンを記述およびコンパイルすることができます。ユーザ
定義ルーチンは、データベース表の読込み、変更、および作成をすること
ができるユーザの制御と監視を行います。
■
CREATE VIEW 文を使用して、データの制限済みビューや変更済みビュー
を準備することができます。制限は特定の列を除く縦方向または特定の行
を除く横方向に適用することができます ( 両方向でも行えます )。
■
GRANT 文と CREATE VIEW 文を結合して、ユーザが変更できる表の部分
やデータの内容を的確に制御することができます。
データベースへのアクセスの制御
通常のデータベース アクセス権のメカニズムでは、6-4 ページの「アクセス権の付
与」で説明する GRANT 文と REVOKE 文がベースになります。ただし、状況に
よってはオペレーティングシステムの機能を、データベースへのアクセスを制御す
るもう 1 つの方法として使用できることもあります。
オペレーティングシステムがアクセスを制御するかどうかに関係なく、データベー
ス全体の内容の機密レベルが高い場合は、コンピュータに固定されているパブリッ
クディスク上へ書込みを行うのは望ましいことではありません。データの機密を保
護しなければならないときは、通常のソフトウェア制御を使わないようにすること
ができます。
データベース サーバのアクセス権の付与と制限
6-3
アクセス権の付与
ユーザ自身または別の正当なユーザがデータベースを使用していないときは、その
データベースをオンラインで使用可能にしておく必要はありません。次のいずれか
の方法を使用して、アクセス不能にすることができますが、手間のかかり具合は、
方法ごとに異なります。
■
物理媒体をコンピュータから切り離して、別の場所に保管する。ディスク
自体がリムーバブルでない場合は、ディスクドライブがリムーバブルで
す。
■
データベース ディレクトリをテープにコピーして、テープを保管する。
■
暗号化ユーティリティを使用して、データベースファイルをコピーする。
暗号化バージョンのみを保持します。
重要 : 2 番目と 3 番目の方法では、コピーした後に、消去ファイルを NULL データ
で上書きするプログラムを使用して、必ず元のデータベースファイルを消去しなけ
ればなりません。
データベースディレクトリ全体を削除する代わりに、個々の表のファイルをコピー
してから消去することもできます。インデックスファイルにはインデックス付き列
からのデータのコピーが含まれているので注意が必要です。表ファイルだけではな
く、インデックスファイルも削除して消去します。
アクセス権の付与
データベースを使用する許可のことをアクセス権と呼びます。たとえば、データ
ベースを使用する許可を Connect アクセス権と呼び、表に行を挿入する許可を
Insert アクセス権と呼びます。GRANT 文を使用すると、データベース、表、
ビュー、またはプロシジャへのアクセス権を付与したり、ロールをユーザやほかの
ロールに付与したりできます。REVOKE 文を使用すると、データベース、表、
ビュー、またはプロシジャへのアクセス権を取り消したり、ロールをユーザやほか
のロールから取り消したりできます。ロールとは、payroll など、DBA (Database
Administrator : データベース管理者 ) が割り当てる作業タスクの分類です。ロール
を割り当てるとアクセス権の管理に便利に使用できます。
IDS
Dynamic Server だけがロールをサポートします。♦
次に示すアクセス権のグループによって、ユーザがデータに対して実行できるアク
ションを制御します。
IDS
6-4
■
データベース レベル アクセス権。データベース全体を制御します。
■
表レベル アクセス権。個々の表を制御します。
■
型レベル アクセス権。不透明 (OPAQUE) 型、ディスティンクト型、名前
付き行 (ROW) 型を使用できるユーザを決定します。
Informix Guide to Database Design and Implementation
データベースレベルアクセス権
■
言語レベル アクセス権。プログラミング言語を使用してユーザ定義ルーチ
ンを作成できるユーザを決定します。♦
■
ルーチン レベル アクセス権。ルーチンを実行できるユーザを決定します。
GRANT 文と REVOKE 文の構文については『Informix Guide to SQL: Syntax』を参
照してください。
データベースレベルアクセス権
3 つのレベルのデータベース アクセス権で、誰がデータベースにアクセスできるか
を総体的に制御します。
Connect アクセス権
最低限のアクセス権レベルとして、表の問合せや変更を行う基本的能力をユーザに
与える Connect アクセス権があります。Connect アクセス権を持っているユーザは
次の機能を実行することができます。
■
必要な表レベルアクセス権を持っているという条件で SELECT 文、INSERT
文、UPDATE 文および DELETE 文を実行する。
■
必要な表レベル アクセス権を持っているという条件で、SPL ルーチンを実
行する。
■
ビューがベースにしている表に対して問合せを行う許可が与えられている
という条件でビューを作成する。
■
一時表を作成して、その一時表に対するインデックスを作成する。
この Connect アクセス権を持っていないユーザは、データベースにアクセスできま
せん。通常、機密度の高いデータや個人データの含まれていないデータベースで
は、データベースの作成直後に GRANT CONNECT TO PUBLIC というアクセス権
を与えます。
Connect アクセス権を public に付与しないと、Connect アクセス権を明示的に付与
されたユーザのみが、データベースサーバによってデータベースにアクセスできま
す。限られたユーザのみがアクセス権を持つ必要がある場合は、それらのユーザに
Connect アクセス権を付与し、他のユーザには付与しません。
ユーザと public
アクセス権は名前を指定して単一のユーザに付与するか、public という名前ですべ
てのユーザに付与します。public に付与されるアクセス権は、デフォルトアクセス
権として機能します。
データベース サーバのアクセス権の付与と制限
6-5
データベースレベルアクセス権
文を実行する前に、必要なアクセス権がユーザに与えられているかどうかがデータ
ベースサーバによって判定されます。この情報はシステム カタログに格納されてい
ます。詳細は、6-8 ページの「システム カタログ表内のアクセス権」を参照してく
ださい。
データベースサーバは、まず最初に、アクセスを要求しているユーザに付与されて
いるアクセス権を探索します。要求しているアクセス権が見つかった場合は、その
情報を使用します。次に、制限の緩いアクセス権が public に付与されているかどう
かがチェックされます。付与されている場合は、制限の緩いアクセス権がデータ
ベースサーバによって使用されます。そのユーザにアクセス権がまったく付与され
ていなければ、データベースサーバは public に付与されているアクセス権を探しま
す。妥当なアクセス権が見つかれば、それが使用されます。
したがって、すべてのユーザに最小限のレベルのアクセス権を設定するには、アク
セス権を public に付与してください。特定の事情でそのアクセス権を無効にするに
は、より高いレベルの個別アクセス権をユーザに付与します。
Resource アクセス権
Resource アクセス権は、Connect アクセス権と同じ権限を持っています。また、
Resource アクセス権を持っているユーザは、新しい永久表、インデックス、および
SPL ルーチンを作成することもできます。したがって、永続割当てディスク領域を
作成できます。
データベース管理者としてのアクセス権
最高位のレベルのデータベース アクセス権はデータベース管理者つまり DBA が保
有します。つまり、データベースの作成者は、必然的に DBA になります。DBA と
してのアクセス権の所有者は、次の機能を実行することができます。
6-6
■
DROP DATABASE 文、START DATABASE 文、および ROLLFORWARD
DATABASE 文を実行する。
■
所有者が誰であるかにかかわらず、オブジェクトを削除したり変更したり
する。
■
他のユーザが所有する表、ビュー、およびインデックスを作成する。
■
データベースアクセス権 (DBA としてのアクセス権も含む ) を別のユーザに
付与する。
■
システムカタログ表の NEXT SIZE（この属性に限る ) を変更して、
systables 以外のすべてのシステムカタログ表の行の挿入、削除、更新を行
う。
Informix Guide to Database Design and Implementation
所有者の権限
警告 : DBA としてのアクセス権を持っているユーザは、ほとんどのシステム カタ
ログ表を変更することができますが、それらのシステム カタログ表で行の更新、削
除、または挿入を行わないように強く推奨します。システムカタログ表を変更する
と、データベースの整合性が失われてしまう可能性があります。ALTER TABLE 文
を使用して、システム カタログ表の追加エクステントのサイズを変更することはで
きません。
所有者の権限
データベースと、その中のすべての表、ビュー、インデックス、プロシジャおよび
シノニムには所有者が設定されています。DBA としてのアクセス権を持っている
ユーザは、他のユーザが所有するオブジェクトも作成することができますが、通常
は、オブジェクトを作成したユーザが、そのオブジェクトの所有者になります。
オブジェクトの所有者は、そのオブジェクトに対するすべての権限を持っていて、
他のアクセス権を持っていなくても、そのオブジェクトの変更や削除を実行するこ
とができます。
XPS
GK (Generalized Key : 一般化キー ) インデックスの場合、所有権は、ほかのオブ
ジェクトの場合とは多少異なる方法で処理されます。どんな表でも、GK インデッ
クスの FROM 節に現れる場合は、たとえその表の作成者でない人が GK インデッ
クスを作成したとしても、その GK インデックスを削除するまで、削除することは
できません。♦
表レベルアクセス権
表ごとに 7 種類のアクセス権を適用して、所有者のアクセス権を所有者でないユー
ザに許可することができます。そのうちの 4 つ、つまり、Select アクセス権、Insert
アクセス権、Delete アクセス権、Update アクセス権は、表の内容に対するアクセ
スを制御します。Index アクセス権はインデックスの作成を制御します。Alter アク
セス権は、表定義を変更する許可を制御します。References アクセス権は、表に対
して参照制約を指定するための許可を制御します。
ANSI 標準準拠データベースでは、表の所有者のみにアクセス権が与えられます。
それ以外のデータベースでは、表作成の一環として、Alter アクセス権と
References アクセス権以外のすべての表アクセス権が、データベースサーバによっ
て自動的に public に付与されます。すべての表アクセス権を public に自動的に付
与した場合は、Connect アクセス権を持っていれば、どのユーザでも新しく作成さ
れた表にアクセスできます。そうしたくない場合 ( この表にアクセスできてはなら
ないユーザが Connect アクセス権を持っている場合 ) は、表の作成後に、public か
らの表に対するアクセス権をすべて取り消す必要があります。
データベース サーバのアクセス権の付与と制限
6-7
表レベルアクセス権
アクセス権
4 つのアクセス権によって、ユーザによる表へのアクセスの仕方を制御します。表
の所有者として、次のアクセス権を個々に付与したり、取り消したりすることがで
きます。
■
Select アクセス権では、一時表への取り出しなどの選択操作を実行するこ
とができます。
■
Insert アクセス権では、新しい行を追加することができます。
■
Update アクセス権では、既存の行を変更することができます。
■
Delete アクセス権では、行を削除することができます。
Select アクセス権は、ユーザが表の内容を抽出するのに必要です。ただし、Select
アクセス権は、他のアクセス権の前提条件ではありません。ユーザは、Select アク
セス権を持っていなくても、Insert アクセス権や Update アクセス権を持つことが
できます。
たとえば、アプリケーションに使用状況表が設定されている場合があります。その
場合は、ある特定のプログラムが開始されるたびに行が使用状況表に挿入され、そ
の行が使用されたことが記録されます。プログラムは、終了前にその行を更新して
実行時間を表示したり、そのユーザが実行した作業のカウントを記録します。
プログラムのすべてのユーザがこの使用状況表で行を挿入、または更新できるよう
にする場合は、その表に対する Insert アクセス権と Update アクセス権を public に
付与します。しかし、Select アクセス権は限られたユーザにのみ付与するものとし
ます。
システム カタログ表内のアクセス権
アクセス権は、システムカタログ表に記録されています。Connect アクセス権を持
つすべてのユーザは、システムカタログ表について問合せを行い、どんなアクセス
権が誰に付与されているかを判別することができます。
データベース アクセス権はシステム カタログ表 sysusers に記録されていて、この
表では主キーはユーザ ID になっています。また、それ以外の列のみにアクセス権
レベルを表す単一文字、C、R または D が含まれています。キーワード PUBLIC に
アクセス権が付与されていることは、ユーザ名 public( 小文字 ) で分かります。
6-8
Informix Guide to Database Design and Implementation
表レベルアクセス権
表レベルアクセス権は、表番号、権限授与者、および被権限授与者からなる複合主
キーを使用する systabauth に記録されています。列 tabauth では、図 6-1 のダイヤ
グラムが示しているリスト内で、アクセス権が符号化されます。
無条件更新
無条件選択
*
挿入
インデックス
su-idxar
列アクセス権が付与されている場合
削除
参照
図 6-1
符号化された
アクセス権の
リスト
変更
ハイフン (--) は、付与されていないアクセス権を表すので、すべてのアクセス権が
付与されている場合は su-idxar と表します。 -u------ は、Update アクセス権
のみが付与されていることを表します。通常、コード文字には小文字が使用されま
すが、GRANT 文でキーワード WITH GRANT OPTION を使用するときは大文字に
なります。
3 つ目の位置にアスタリスク (*) が記されている場合は、その表と被権限授与者に何
らかの列レベルアクセス権が存在しています。特定のアクセス権は syscolauth に記
録されます。その主キーは、表番号、権限授与者、被権限授与者、および列番号か
ら成る複合主キーです。属性は、アクセス権の型を示す 3 文字のどれかで表されま
す。s、u、または r のどれかになります。
Index アクセス権、Alter アクセス権、および References アクセス権
Index アクセス権の保持者は、表に対してインデックスを作成したり変更したりす
ることができます。Index アクセス権は、Select アクセス権、Insert アクセス権、
Update アクセス権および Delete アクセス権と同じように、表の作成時に自動的に
public に付与されます。
Index アクセス権は、どのユーザに対しても付与することができますが、ユーザが
実際にアクセスするには、データベースに対する Resource アクセス権も必要です。
したがって、Index アクセス権は自動的に付与されますが (ANSI 標準準拠データ
ベースの場合を除く )、データベースに対して Connect アクセス権しか持っていな
いユーザは、Index アクセス権を実際に使用することはできません。インデックス
は大きなディスク領域を占める可能性があるので、こうした制限は妥当だと言えま
す。
Alter アクセス権の保有者は、表に対して ALTER TABLE 文を使用し ( 列を追加し
たり削除したりする権限も含む )、シリアル (SERIAL) 型列の開始点をリセットした
りすることができます。Alter アクセス権は、データモデルを十分に理解していて、
その権限を慎重に使用するユーザにのみ付与します。
データベース サーバのアクセス権の付与と制限
6-9
表レベルアクセス権
References アクセス権を使用すると、表に対する参照制約を強制することができま
す。Alter アクセス権と同じように、References アクセス権はデータモデルを十分
に理解しているユーザにだけ付与してください。
IDS
型付き表に対する Under アクセス権
Under アクセス権を付与したり取り消したりして、ユーザが継承階層構造内の上位
表として型付き表を使用できるかどうかを制御できます。Under アクセス権は、表
が作成されると自動的に public に付与されます。ただし、ANSI 標準準拠データ
ベースの場合は違います。ANSI 標準準拠データベースでは、表に対する Under ア
クセス権は、その表の所有者に対して付与されます。ある表を継承階層構造内の上
位表として定義できるユーザを制限するには、まず public に対する Under アクセ
ス権を取り消し、次に、Under アクセス権を付与するユーザを指定する必要があり
ます。たとえば、限られたユーザのグループだけが表 employee を継承階層構造の
上位表として使用できるようにする場合、次の文を実行します。
REVOKE UNDER ON employee
FROM PUBLIC;
GRANT UNDER ON employee
TO johns, cmiles, paulz
UNDER 節を使用して継承階層構造内に表を作成する方法については、8-10 ページ
の「表継承」を参照してください。
IDS
表フラグメントのアクセス権
GRANT FRAGMENT 文を使用して、フラグメント表の個々のフラグメントに挿入、
更新、および削除のアクセス権を付与することができます。
たとえば、式によって、DB 領域 dbsp1、dbsp2、dbsp3 に常駐する 3 つのフラグメ
ントにフラグメント化されている表 customer を作成します。次の文は、最初の 2
つのフラグメント (dbsp1 と dbsp2) だけに対する挿入アクセス権をユーザ jones、
reed、および mathews に付与します。
GRANT FRAGMENT INSERT ON customer (dbsp1, dbsp2)
TO jones, reed, mathews
重要 : GRANT FRAGMENT 文は、式に基づく分散スキームを使用してフラグメン
ト化されている表に対してのみ有効です。
6-10
Informix Guide to Database Design and Implementation
列レベルアクセス権
ある表のフラグメントすべてにアクセス権を付与するには、GRANT 文または
GRANT FRAGMENT 文を使用します。
『Informix Guide
GRANT FRAGMENT 文と REVOKE FRAGMENT 文については、
to SQL: Syntax』を参照してください。
列レベルアクセス権
特定の列の名前を使用して、Select アクセス権、Update アクセス権、および
References アクセス権を修飾することができます。特定の列名を指定することで、
表に対する非常に具体的なアクセス権を付与することができます。特定の列のみの
確認、特定の列のみの更新、あるいは、特定の列に対する参照制約の強制をユーザ
が行えるようにすることができます。
GRANT 文と REVOKE 文を使用すると、表データの作成および表データへのアク
セスが制限できます。この機能によって、従業員の給与、勤務評価などの機密性の
高い属性を特定のユーザのみが確認できるようにするにはどうすべきかという問題
が解決します。具体的に説明できるように、従業員データの表が次の例に示すよう
に定義されていると仮定します。
CREATE TABLE hr_data
(
emp_key INTEGER,
emp_name CHAR(40),
hire_date DATE,
dept_num SMALLINT,
user-id CHAR(18),
salary DECIMAL(8,2)
performance_level CHAR(1),
performance_notes TEXT
)
この表には機密データが含まれているので、作成直後に次の文を実行します。
REVOKE ALL ON hr_data FROM PUBLIC
人事部内の限られたメンバーとすべてのマネージャに対して、次の文を実行しま
す。
GRANT SELECT ON hr_data TO harold_r
このようにして、限られたユーザが列すべてを見ることを許可します。マネージャ
のビューをその部下だけに制限する方法については、この章の最終節を参照してく
ださい。勤務評価を行う重役に対しては、次のような文を実行できます。
GRANT UPDATE (performance_level, performance_notes)
ON hr_data TO wallace_s, margot_t
データベース サーバのアクセス権の付与と制限
6-11
型レベル アクセス権
この文を使用して、部下の評価を管理職が入力できるようにします。人事部長、ま
たは給与レベルを変更できる資格があるユーザに対してのみ、次のような文を実行
します。
GRANT UPDATE (salary) ON hr_data to willard_b
人事部内の一般社員に対しては、次のような文を実行することができます。
GRANT UPDATE (emp_key, emp_name, hire_date, dept_num)
ON hr_data TO marvin_t
この文では、機密性のない列を保守できる権限が、ある一定のユーザに与えられま
すが、勤務評定や給与を変更する権限をそれらのユーザに付与することは拒否され
ます。コンピュータのユーザ ID を割り当てる MIS 部門の社員には、次のような文
が与えられます。
GRANT UPDATE (user_id) ON hr_data TO eudora_b
データベースへの接続が許可されていても、給与や勤務評価を見ることはできない
すべてのユーザに代わって次のような文を実行し、それらのユーザが機密性のない
データを見られるようにしてください。
GRANT SELECT (emp_key, emp_name, hire_date, dept_num, user-id)
ON hr_data TO george_b, john_s
これらのユーザは次のような問合せを実行することができます。
SELECT COUNT(*) FROM hr_data WHERE dept_num IN (32,33,34)
ただし、次のような問合せを実行しようとすると、エラーメッセージが表示され、
データは表示されません。
SELECT performance_level FROM hr_data
WHERE emp_name LIKE '*Smythe'
IDS
型レベル アクセス権
Dynamic Server は、ユーザ定義データ型をサポートしています。ユーザ定義データ
型が作成されると、DBA またはそのデータ型の所有者だけが、その型を誰が使用
できるかを制御する型レベル アクセス権を適用できます。Dynamic Server は、次
の型レベル アクセス権をサポートしています。
6-12
■
Usage アクセス権。ユーザ定義データ型を使用できる権限を制御します。
■
Under アクセス権。名前付き行 (ROW) 型を継承階層構造の上位型として
定義できる権限を制御します。
Informix Guide to Database Design and Implementation
型レベル アクセス権
ユーザ定義型の Usage アクセス権
不透明 (OPAQUE) 型、ディスティンクト型、または名前付き行 (ROW) 型を誰が使
用できるかを制御するには、データ型に Usage アクセス権を指定します。Usage ア
クセス権を使用すると、DBA、またはデータ型の所有者は、列、プログラム変数 (
または名前付き行 (ROW) 型の場合は表やビュー ) にデータ型を割り当てたり、デー
タ型にキャストを割り当てたりするユーザの権限を制限できます。Usage アクセス
権は、データ型が作成されると自動的に public に付与されます。ただし、ANSI 標
準準拠データベースの場合は違います。ANSI 標準準拠データベースでは、ある
データ型に対する Usage アクセス権は、そのデータ型の所有者に対して付与されま
す。
不透明 (OPAQUE) 型、ディスティンクト型、または名前付き行 (ROW) 型を誰が使
用できるかを制限するには、まず public の Usage アクセス権を取り消し、次に、
Usage アクセス権を付与するユーザの名前を指定する必要があります。たとえば、
circle という名前のデータ型の使用をあるユーザのグループだけに制限する場合、
次の文を実行します。
REVOKE USAGE ON circle
FROM PUBLIC;
GRANT USAGE ON circle
TO dawns, stevep, terryk, camber;
名前付き行 (ROW) 型の Under アクセス権
名前付き行 (ROW) 型に対して Under アクセス権を付与したり取り消したりできま
す。Under アクセス権は、名前付き行 (ROW) 型を継承階層構造内の別の名前付き
行 (ROW) 型の上位型として割り当てることができるユーザを制御します。Under
アクセス権は、名前付き行 (ROW) 型が作成されると自動的に public に付与されま
す。ただし、ANSI 標準準拠データベースの場合は違います。ANSI 標準準拠データ
ベースでは、名前付き行 (ROW) 型に対する Under アクセス権は、その型の所有者
に対して付与されます。
あるユーザが名前付き行 (ROW) 型を継承階層構造内の上位型として定義する権限
を制限するには、まず public の Under アクセス権を取り消してから、Under アク
セス権を付与するユーザ名を指定します。たとえば、限られたユーザのグループだ
けが名前付き行 (ROW) 型 person_t を継承階層構造内の上位型として使用できるよ
うにする場合、次の文を使用します。
REVOKE UNDER ON person_t
FROM PUBLIC;
GRANT UNDER ON person_t
TO howie, jhana, alison
データベース サーバのアクセス権の付与と制限
6-13
ルーチン レベル アクセス権
UNDER 節を使用して名前付き行 (ROW) 型を継承階層構造内に作成する方法につ
いては、8-3 ページの「型継承」を参照してください。
ルーチン レベル アクセス権
Execute アクセス権を UDR (User-defined routine : ユーザ定義ルーチン ) に適用し
て、その UDR を実行する権限を非所有者に付与できます。ANSI 標準に準拠しない
データベースで UDR を作成すると、デフォルトのルーチン レベル アクセス権は
PUBLIC になります。つまり、最初に取り消さない限り、Execute アクセス権を特定
のユーザに付与する必要はありません。ANSI 標準準拠データベースでルーチンを
作成すると、デフォルトでは Execute アクセス権が他のユーザに与えられません。
したがって、特定のユーザに Execute アクセス権を付与する必要があります。次の
例は、ユーザ orion に Execute アクセス権を付与して、READ_ADDRESS という名
前の UDR を orion が使用できるようにします。
GRANT EXECUTE ON read_address TO orion;
ルーチン レベル アクセス権は、システム カタログ表 sysprocauth に記録されます。
システム カタログ表 sysprocauth は、ルーチン番号、権限授与者、および被権限授
与者から成る主キーを使用します。列 procauth では、Execute アクセス権は小文字
e によって示されます。また、WITH GRANT オプションで Execute アクセス権が付
与されている場合は、このアクセス権は大文字 E で表されます。
ルーチン レベル アクセス権の詳細については、『Informix Guide to SQL: Tutorial』
を参照してください。
IDS
言語アクセス権
Dynamic Server を使用すると、ユーザは UDR を SPL (Stored Procedure Language :
ストアド プロシジャ言語 )、C、または Java のどれを使用しても作成できます。
.UDR を作成するには、ユーザはデータベース内の Resource アクセス権を持ってい
る必要があります。さらに、UDR を C または Java で作成する場合、ユーザは C ま
たは Java に対する Usage アクセス権も持っている必要があります。
デフォルトでは、C または Java の UDR に対する Usage アクセス権は、ユーザ
informix と、DBA アクセス権を持つユーザに付与されます。ただし、ユーザ
informix だけが C または Java に対する Usage アクセス権をほかのユーザに付与で
きます。DBA アクセス権を持つユーザは、C または Java に対する Usage アクセス
権を持っていますが、C または Java に対する Usage アクセス権をほかのユーザに付
与することはできません。
6-14
Informix Guide to Database Design and Implementation
アクセス権の自動化
次の文は、ユーザ informix が UDR を C で作成する権限をユーザ mays、jones、お
よび smith に付与します。
GRANT USAGE ON LANGUAGE C TO mays, jones, freeman
SPL ルーチンの Usage アクセス権は、デフォルトで public に付与されます。
たとえば、SPL ルーチンに対するデフォルトの Usage アクセス権が PUBLIC から取
り消されたとします。次の文は、DBA アクセス権を持つユーザが SPL ルーチンに
対する Usage アクセス権をユーザ franklin、reeves、および wilson に付与します。
GRANT USAGE ON LANGUAGE SPL TO franklin, reeves, wilson
アクセス権の自動化
この設計方法では、データベースを最初にセットアップするときに、かなりの数の
GRANT 文を実行しなければならない場合があります。また、ユーザの仕事が変わ
るにしたがって、アクセス権を常に保守する必要があります。たとえば、人事部の
ある社員が解雇された場合は、できる限り早く Update アクセス権を取り消す必要
があります。そのような措置をとらないと、この解雇された社員によって次のよう
な文が実行されてしまう可能性があります。
UPDATE hr_data
SET (emp_name, hire_date, dept_num) = (NULL, NULL, 0)
機密データが含まれているモデルでは、必要に応じて毎日または毎時間ごとにアク
セス権を少しずつ変更しなければならない場合があります。アクセス権の変更が必
要になる場合は、アクセス権を保守しやすいように自動化ツールを用意することが
できます。
最初の手順としては、表の構造ではなく、ユーザの仕事内容に基づいてアクセス権
クラスを指定しなければなりません。たとえば、マネージャには次のアクセス権が
必要です。
■
この例で示された表 hr_data に対する Select アクセス権と限定的な Update
アクセス権
■
このデータベースと他のデータベースに対する Connect アクセス権
■
それらのデータベース内の複数の表に対するある程度のアクセス権
マネージャが幹部に昇進したり、フィールド オフィスに出向したりした場合は、そ
れまでのアクセス権をすべて取り消して、新しい一連のアクセス権を付与する必要
があります。
データベース サーバのアクセス権の付与と制限
6-15
アクセス権の自動化
サポートするアクセス権クラスを定義して、アクセス権を与えなければならない
データベース、表および列を、それぞれのクラスごとに指定してください。次に、
クラスごとに 2 つの自動化ルーチン、つまりユーザにクラスを付与するためのルー
チンとそのクラスを取り消すためのルーチンを設定します。
コマンドスクリプトによる自動化
使用するオペレーティングシステムは、コマンドスクリプトの自動実行をサポート
しているはずです。ほとんどの操作環境では、DB-Access や Relational Object
Manager などの対話型 SQL ツールでコマンドと SQL 文を受け付けて、コマンド行
から実行できるようになっています。この 2 つの機能を組み合わせて、アクセス権
の保守を自動化することができます。
詳細は、使用するオペレーティング システム、および DB-Access または Relational
Object Manager のバージョンによって異なります。つまり、次の機能を実行するコ
マンドスクリプトを作成する必要があります。
■
アクセス権が変更されるユーザ ID をパラメータとして解釈する。
■
そのユーザIDを含むようにカスタマイズされたGRANT文またはREVOKE
文のファイルを作成する。
■
データベースを選択して、作成された GRANT 文または REVOKE 文の
ファイルを実行するように指示するパラメータを指定し、DB-Access また
は、Relational Object Manager を起動する。
このようにすれば、ユーザのアクセス権クラスの変更操作を減らして、1 つまたは
2 つのコマンドにすることができます。
IDS
ロールの使用
ユーザのアクセス権を場合に応じて簡単に変更するもう 1 つの方法は、ロールを使
用することです。データベース環境でのロールの概念は、オペレーティングシステ
ムでのグループの概念に似ています。ロールとは、一つのデータベース機能であ
り、DBA はこの機能を使用し、クラスのメンバとして扱うことによって、多くの
ユーザのアクセス権を標準化したり変更したりすることができます。
たとえば、社内のニュースやメッセージを扱うデータベースに対して接続アクセス
権、挿入アクセス権、および削除アクセス権を付与する news_mes というロールを
作成することができます。新たに従業員が入社しても、その従業員をロール
news_mes に追加するだけで済みます。この新しい従業員は、ロール news_mes の
アクセス権を獲得します。このプロセスは、その逆の働きもします。つまり、
news_mes のすべてのメンバーのアクセス権を変更するには、そのロールのアクセ
ス権を変更します。
6-16
Informix Guide to Database Design and Implementation
アクセス権の自動化
ロールの作成
ロール作成プロセスを開始するには、ロールの名前、および付与する接続とアクセ
ス権を決定します。接続とアクセス権は、まったくの自由裁量によって判断するわ
けですが、ロールを命名するときに考慮しなければならないいくつかの要素があり
ます。次の語は、ロールの名前に使用しないでください。
alter
connect
DBA
default
delete
execute
index
insert
none
null
public
references
resource
select
update
ロールの名前は、データベース内の既存のロール名と異なっている必要がありま
す。またサーバ コンピュータにとって既知となっているネットワーク ユーザも含
め、オペレーティング システムにとって既知のユーザ名とも異なっていなければな
りません。自分のロール名が一意であることを確認するには、次のシステムカタロ
グ表だけではなく、データベースを現在使用している共有メモリ構造体のユーザの
名前をチェックします。
■
sysusers
■
systabauth
■
syscolauth
■
sysprocauth
■
sysfragauth
■
sysroleauth
状況が逆で、ユーザをデータベースに追加しているときには、そのユーザ名が既存
のロール名と同じになっていないかをチェックしてください。
ロール名を承認した後は、CREATE ROLE 文を使用して、新しいロールを作成しま
す。ロールを作成すると、デフォルトでは、ロール管理用のすべてのアクセス権が
DBA に与えられます。
重要 : ロールの有効範囲は現行データベースだけです。そのため、SET ROLE 文を
実行すると、そのロールは現行データベースだけに設定されます。
ユーザのアクセス権の操作と他のロールへのロールの付与
DBA は GRANT 文を使用して、ロール アクセス権をユーザに付与することができ
ます。また、アクセス権を他のユーザに付与するオプションをユーザに提供するこ
ともできます。それには、GRANT 文の WITH GRANT OPTION 節を使用します。
WITH GRANT OPTION 節を使用できるのは、アクセス権をユーザに付与するとき
に限られます。
データベース サーバのアクセス権の付与と制限
6-17
アクセス権の自動化
たとえば、次の問合せは、オプション grantable を指定してロールへのアクセス権
を付与しているので、エラーが戻されます。
GRANT SELECT on tab1 to rol1
WITH GRANT OPTION
重要 : アクセス権をロールに付与するときに GRANT 文の WITH GRANT OPTION
節を使用してはなりません。ユーザのみが、アクセス権を他のユーザに付与するこ
とができます。
ロール アクセス権を付与するときは、GRANT 文でユーザ名の代わりにロール名を
使用することができます。ロールを別のロールに付与することもできます。たとえ
ば、ロール A がロール B に付与されているとします。その場合は、ユーザがロー
ル B を有効化すると、ロール A とロール B の両方からアクセス権がユーザに与え
られます。
ただし、ロール付与のサイクルを推移させることはできません。ロール A をロール
B に付与して、ロール B をロール C に付与し、さらに C を A に付与するとエラー
が戻されます。
アクセス権を変更する必要がある場合は、REVOKE 文を使用して既存のアクセス権
を削除してから、GRANT 文を使用して新しいアクセス権を追加します。
ユーザによるロールの有効化の必要性
DBA がアクセス権を付与してユーザをロールに追加した後、データベースセッ
ションで SET ROLE 文を使用して、ロールを有効化しなければなりません。ロール
を有効化しない限りは、public に関連付けられたアクセス権、または、オブジェク
トの所有者であるという理由で直接付与されたアクセス権に限定されます。
ロールでのメンバシップの確認とロールの削除
どのユーザがロールに含まれているのかわからない状態になる場合があります。こ
の場合は、ロールを作成していないか、ロールを作成したユーザが有効でないこと
が考えられます。システム カタログ表 sysroleauth とシステム カタログ表 sysusers
に対して問合せを行って、どの表に対してどのユーザがアクセスを許可されている
か、さらにロールがいくつ存在しているかを確認してください。
どのユーザがどのロールのメンバーなのかがわかると、すでに一部のロールが不要
であることに気付く場合があります。ロールの削除には、DROP ROLE 文を使用し
ます。ただし、ロールを削除するには、次の条件を満たしていなければなりませ
ん。
■
6-18
システム カタログ表 sysusers にロールとしてリストされているロールのみ
を削除することができます。
Informix Guide to Database Design and Implementation
SPL ルーチンによるデータへのアクセスの制御
■
ロールを削除するには、DBA としてのアクセス権を持っているか、あるい
はロールを削除するために付与できるロールのオプションを与えられてい
なければなりません。
SPL ルーチンによるデータへのアクセスの制御
SPL ルーチンを使用して、データベース内の個々の表または列へのアクセスを制御
することができます。ルーチンを使用して、さまざまな段階のアクセス制御を実行
することができます。SPL のルーチンの詳細については、
『Informix Guide to SQL:
『Extending
Tutorial』を参照してください。外部ユーザ定義ルーチンについては、
Informix Dynamic Server 2000』を参照してください。SPL の強力な機能の一つとし
て、SPL ルーチンを DBA アクセス権付きルーチンとして指定できる機能がありま
す。DBA アクセス権付きルーチンを作成すると、ほとんどの、あるいはまったく
表アクセス権を持たないユーザが、ルーチンの実行時に DBA アクセス権を獲得し
ます。このルーチンでは、限られた範囲内で、ユーザは一時的な DBA アクセス権
を使用してタスクを実行することができます。DBA アクセス権付き機能を使用し
た場合は、次のタスクを実行することができます。
■
個々のユーザが表から読み込める情報の量を制限します。
■
データベースに対するあらゆる変更を制限して、表全体が空にされたり、
誤って変更されるようなことがないようにします。
■
削除や挿入などの、表に対する変更のクラス全体を監視します。
■
SPL ルーチン内で行われるあらゆるオブジェクトの作成 ( データ定義 ) を制
限して、表、インデックス、およびビューの作成方法を完全に制御できる
ようにします。
データの読込みの制限
次の例のルーチンでは、ユーザには SQL 構文が見えませんが、ユーザが表
customer に対して SELECT アクセス権を持っている必要があります。何をユーザが
選択できるかを制限する場合は、次の環境で機能するようなルーチンを作成しま
す。
■
自分自身が、データベースの DBA である。
■
ユーザが、データベースに対する Connect アクセス権を持っている。そし
て、表に対する SELECT アクセス権は持っていない。
■
キーワード DBA を使用して、SPL ルーチン ( または SPL ルーチンのセット
) が作成されている。
データベース サーバのアクセス権の付与と制限
6-19
データへの変更の制限
■
SPL ルーチン ( または SPL ルーチンのセット ) が、ユーザに代わって表から
読み込む。
顧客の名前、住所および電話番号のみをユーザが読めるようにする場合は、次の例
に示すようにプロシジャを変更します。
CREATE DBA PROCEDURE read_customer(cnum INT)
RETURNING CHAR(15), CHAR(15), CHAR(18);
DEFINE p_lname,p_fname CHAR(15);
DEFINE p_phone CHAR(18);
SELECT fname, lname, phone
INTO p_fname, p_lname, p_phone
FROM customer
WHERE customer_num = cnum;
RETURN p_fname, p_lname, p_phone;
END PROCEDURE;
データへの変更の制限
SPL ルーチンを使用して、表に加えられる変更を制限することができます。SPL
ルーチンを使用して、すべての変更の経路を指定します。ユーザが直接変更を加え
るのではなく、SPL ルーチンが変更を行うことになります。ユーザによる動作を 1
回に 1 つずつの行の削除に制限して、表内のすべての行が誤って削除されないよう
にするには、次のようなアクセス権でデータベースをセットアップします。
■
自分自身が、データベースの DBA である。
■
すべてのユーザが、データベースに対する Connect アクセス権を持ってい
る。RESOURCE アクセス権を持っている場合がある。保護されている表
に対しては、Delete アクセス権 ( この例の場合 ) を持っていない。
■
キーワード DBA を使用して、SPL ルーチンを作成する。
■
自分自身の SPL ルーチンが削除を実行する。
次のような SPL プロシジャを作成します。このプロシジャでは、customer_num に
対して WHERE 節を使用して、表 customer から行を削除します。
CREATE DBA PROCEDURE delete_customer(cnum INT)
DELETE FROM customer
WHERE customer_num = cnum;
END PROCEDURE;
6-20
Informix Guide to Database Design and Implementation
データへの変更の監視
データへの変更の監視
SPL ルーチンを使用して、データベースに加えられた変更のレコードを作成するこ
とができます。特定のユーザが行った変更を記録したり、変更が行われるたびにレ
コードを作成したりすることができます。
単一のユーザがデータベースに対して行うすべての変更を監視することができま
す。それぞれのユーザによる変更を追跡する SPL ルーチンを使用して、すべての変
更の経路を指定します。ユーザ acctclrk がデータベースに変更を加えるたびに記録
したい場合は、次のアクセス権でデータベースをセットアップします。
■
自分自身が、データベースの DBA である。
■
他のすべてのユーザが、データベースに対する Connect アクセス権を持っ
ている。RESOURCE アクセス権を持っている場合もあります。保護され
ている表に対しては、Delete アクセス権 ( この例の場合 ) を持っていない。
■
キーワード DBA を使用して、SPL ルーチンを作成する。
■
SPL ルーチンが削除を実行し、特定のユーザによる変更を記録する。
次のような SPL ルーチンを作成します。このルーチンでは、表の更新時に、ユーザ
が提供する顧客番号を使用します。ユーザが acctclrk である場合は、削除のレコー
ドはファイル updates に入れられます。
UNIX
CREATE DBA PROCEDURE delete_customer(cnum INT)
DEFINE username CHAR(8);
DELETE FROM customer
WHERE customer_num = cnum;
IF username = ’acctclrk’ THEN
SYSTEM ’echo Delete from customer by acctclrk >>
/mis/records/updates’ ;
END IF
END PROCEDURE;
データベース サーバのアクセス権の付与と制限
6-21
オブジェクト作成の制限
プロシジャを用いて行われた削除をすべて監視するには、IF 文を削除して、
SYSTEM 文に一般性を持たせます。前のルーチンを変更して、すべての削除を記録
する場合は、次のようなプロシジャになります。
CREATE DBA PROCEDURE delete_customer(cnum INT)
DEFINE username CHAR(8);
LET username = USER ;
DELETE FROM tbname WHERE customer_num = cnum;
SYSTEM
'echo Deletion made from customer table, by '||username
||'>>/hr/records/deletes';
END PROCEDURE;
♦
オブジェクト作成の制限
作成されるオブジェクト、およびその作成方法を抑制するには、次の設定で SPL
ルーチンを使用します。
■
自分自身が、データベースの DBA である。
■
他のすべてのユーザが、データベースに対する Connect アクセス権を持て
いる。Resource アクセス権は持っていない。
■
キーワード DBA を使用して、SPL ルーチン ( または SPL ルーチンのセット
) を作成する。
■
自分自身の SPL ルーチン ( または SPL ルーチンのセット ) が、定義したとお
りに表、インデックス、およびビューを作成する。そのようなルーチンを
使用して、トレーニング データベース環境をセットアップできる。
次の例が示しているように、SPL ルーチンには、1 つまたは複数の表や、関連付け
られているインデックスの作成を含めることができます。
CREATE DBA PROCEDURE all_objects()
CREATE TABLE learn1 (intone SERIAL, inttwo INT NOT NULL,
charcol CHAR(10) );
CREATE INDEX learn_ix ON learn1 (inttwo);
CREATE TABLE toys (name CHAR(15) NOT NULL UNIQUE,
description CHAR(30), on_hand INT);
END PROCEDURE;
6-22
Informix Guide to Database Design and Implementation
ビューの使用
プロシジャ all_objects を使用して表に対する列の追加を制御するには、データベー
スに対する Resource アクセス権をすべてのユーザから取り消します。プロシジャ
の外で SQL 文を使用して、ユーザが表、インデックスまたはビューを作成しよう
としても、その操作は許可されません。また、ユーザがプロシジャを実行するとき
は、一時的な DBA アクセス権が与えられるので、たとえば CREATE TABLE 文な
どは成功します。また、追加するそれぞれの列には必ず制約が設定されます。さら
にユーザが作成したオブジェクトは、そのユーザによって所有されます。プロシ
ジャ all_objects の場合は、このプロシジャを実行するユーザは誰でも、二つの表と
インデックスを所有することになります。
ビューの使用
ビューとは、合成した表のようなものです。ビューは、表ではないものを表である
かのように問い合わせることができ、場合によっては、表であるかのように更新す
ることもできます。しかし、ビューは表ではありません。実際の表と他のビューに
存在するデータの集合体です。
ビューのベースになるのは SELECT 文です。ビューを作成するときは、ビューのア
クセス時にビューの内容を生成する SELECT 文を定義します。ユーザは、SELECT
文を使用したビューの問合せも行います。データベースサーバは、ユーザの
SELECT 文を、ビューに対して定義した SELECT 文とマージして、その結合された
文を実際に実行します。
その結果、表のような外観になります。表に非常によく似ているため、ビューの
ベースとして他のビューを使用したり、表と他のビューの結合をベースにしたりす
ることができます。
ビューの内容を決定する SELECT 文の作成者は、ビューを次のいずれかの目的に使
用することができます。
■
ユーザを表の特定の列に制限する。
指定するのは、ビュー内の選択リスト内で許可されている列のみです。
■
ユーザを表の特定の行に制限する。
許可された行のみを返す WHERE 節を指定します。
■
挿入する値または更新する値の範囲に制約を加える。
キーワード WITH CHECK OPTION(6-30 ページを参照 ) を使用して、制約
を強制することができます。
データベース サーバのアクセス権の付与と制限
6-23
ビューの作成
■
冗長データをデータベースに格納せずに、導出データにアクセスできるよ
うにする。
ビュー内の選択リストにデータを導出する式を書きます。ビューに対して
問合せを行うたびに、そのデータが新たに導出されます。導出されたデー
タは常に最新ですが、冗長性はデータモデルに導入されません。
■
複雑な SELECT 文の詳細を隠す。
ビュー内の複数表結合による複雑性を隠し、ユーザとアプリケーションプ
ログラマにとって繰返しが不要になるようにします。
ビューの作成
次の例では、データベース stores_demo の表をベースにしてビューを作成します。
CREATE VIEW name_only AS
SELECT customer_num, fname, lname FROM customer
このビューは表の 3 つの列のみを表出させます。しかし、WHERE 節が含まれてい
ないので、表示できる行は制限しません。
GLS
次の例では、ISO 8859-1 コード セットを使用するデフォルトの米国英語ロケール以
外のロケールが有効になっている場合に使用できる表をベースにして、ビューを作
成します。この例では、ビュー名、列名および表名に英字以外の文字が含まれてい
ます。
CREATE VIEW çà_va AS
SELECT numéro, nom FROM abonnés;
♦
次の例は二つの表の結合をベースにしています。
CREATE VIEW full_addr AS
SELECT address1, address2, city, state.sname, zipcode
FROM customer, state
WHERE customer.state = state.code
州名の表によって、データベースの冗長性が軽減されます。つまり、完全な州名を
格納するのは 1 回だけでよいので、Minnesota などの長い州名の場合は便利です。
このビュー full_addr を使用して、すべての行に完全な州名が格納されているかの
ように、住所を抽出することができます。次の二つの問合せは同等です。
SELECT * FROM full_addr WHERE customer_num = 105
SELECT address1, address2, city, state.sname, zipcode
FROM customer, state
WHERE customer.state = state.code
AND customer_num = 105
6-24
Informix Guide to Database Design and Implementation
ビューの作成
ただし、結合に基づくビューを定義するときは注意しなければなりません。そのよ
うなビューは修正不能です。つまり、それらのビューに UPDATE 文、DELETE 文
または INSERT 文を使用することはできません。ビューを用いたデータの修正方法
については、6-28 ページを参照してください。
次の例は、ビューに表示できる行を制限します。
CREATE VIEW no_cal_cust AS
SELECT * FROM customer WHERE NOT state = 'CA'
このビューは、表 customer のすべての列を表出させますが、特定の行に限られま
す。次の例は、ユーザに関連のある行にユーザを限定するビューです。
CREATE VIEW my_calls AS
SELECT * FROM cust_calls WHERE user_id = USER
表 cust_calls のすべての列が表示されますが、問合せを実行できるユーザのユーザ
ID が記述されている行のみで使用できます。
IDS
型付きビュー
同じ型のデータを表示する 2 つのビューを区別する場合は、型付きビューを作成し
ます。たとえば、次の表に 2 つのビューを作成します。
CREATE TABLE emp
(
name
VARCHAR(30),
age
INTEGER,
salary INTEGER
);
次の文は、表 emp 上に、name_age および name_salary という 2 つの型付きビュー
を作成します。
CREATE ROW TYPE name_age_t
(
name
VARCHAR(20),
age
INTEGER);
CREATE VIEW name_age OF TYPE name_age_t AS
SELECT name, age FROM emp;
CREATE ROW TYPE name_salary_t
(
name
VARCHAR(20),
salary INTEGER);
CREATE VIEW name_salary OF TYPE name_salary_t AS
SELECT name, salary FROM emp
データベース サーバのアクセス権の付与と制限
6-25
ビューの作成
型付きビューを作成すると、ビューが表示するデータは型付き行 (ROW) 型になり
ます。たとえば、ビュー name_age とビュー name_salary には、可変長文字
(VARCHAR) 型と整数 (INTEGER) 型データが含まれます。型付きのビューである
ため、ビュー name_age に対する問合せは name_age の型の列ビューを戻し、
ビュー name_salary に対する問合せは、name_salary の型の列ビューを戻します。
したがって、Dynamic Server は、ビュー name_age が戻す行と ビュー name_salary
が戻す行とを区別できます。
型付きビューの方が、型なしビューよりも大きな利点を持つ場合があります。たと
えば、関数 myfunc() をオーバーロードした場合です。指定した引数の型によって
は、データベース サーバは別の関数 myfunc() を呼び出します。関数のオーバー
ロードの詳細については、
『Extending Informix Dynamic Server 2000』を参照して
ください。ビュー name_age とビュー name_salary は型付きビューであるため、次
の文は、エイリアス p に関連付けられているビューの型に応じて適切な関数
myfunc() に解決されます。
SELECT myfunc(p) FROM name_age p;
SELECT myfunc(p) FROM name_salary p;
同じデータ型を持つ 2 つのビューを型付きビューとして作成しないと、Dynamic
Server は 2 つのビューが表示する行を区別できません。
ビューの重複行
基礎となる表に一意の行しか含まれていない場合も、ビューでは重複行が作成され
る可能性があります。ビューの SELECT 文が重複行を返すことができる場合は、
ビュー自体が重複行を含んでいるように見えることがあります。
この問題を防止する方法は 2 つあります。そのうちの 1 つはビューの選択リストに
キーワード DISTINCT を指定することです。ただし、キーワード DISTINCT を指
定すると、ビューを用いたデータの変更が行えなくなります。もう 1 つの方法は、
一意に制約されている 1 つの列、または列のグループを常に選択することです。主
キーまたは候補キーの列を選択した場合、確実に一意の行だけが戻されます。主
キーと候補キーについては、第 2 章を参照してください。
ビューに対する制限
ビューは、実際には表ではないので、ビューにインデックスを付けたり、ビューを
ALTER TABLE 文や RENAME TABLE 文などのオブジェクトにしたりすることはで
きません。また、ビューの列の名前を RENAME COLUMN 文で変更することもで
きません。ビューの定義に関する何かを変更するには、ビューをいったん削除して
から再度作成しなければなりません。
6-26
Informix Guide to Database Design and Implementation
ビューの作成
ユーザの問合せとマージしなければならないので、ビューのベースになる SELECT
文には次の節やキーワードを含めないようにしてください。
INTO TEMP 節 ユーザの問合せには INTO TEMP 節が含まれている可能性がありま
す。ビューにも INTO TEMP 節が含まれていると、データの格納先
が不明になります。
ORDER BY 節 ユーザの問合せには ORDER BY 節が含まれている可能性がありま
す。ビューにも ORDER BY 節が含まれていると、列の選択やソー
ト方向が矛盾する場合があります。
ビューの基となる SELECT 文には、キーワード UNION を指定することができま
す。そうした場合は、データベース サーバはそのビューを暗黙的一時表に格納しま
すが、この一時表でユニオンが必要に応じて評価されます。ユーザの問合せでは、
この一時表を基本表として使用します。
ベースの変更の反映
ビューのベースになっている表やビューを変更する方法はいくつかあります。
ビューには、ほとんどの変更が自動的に反映されます。
表やビューが削除されると、同じデータベース内でその表やビューに依存している
ビューも自動的に削除されます。
ビューの定義を変更する唯一の方法は、そのビューを削除して再度作成することで
す。したがって、他のビューが依存しているビューの定義を変更する場合は、他の
ビューも再度作成しなければなりません ( すべて削除されているからです )。
表の名前を変更すると、同じデータベース内でその表に依存しているビューも、そ
の新しい名前を使用できるように変更されます。また、列の名前を変更すると、同
じデータベース内でその表に依存しているビューも、その固有の列を選択できるよ
うに更新されます。ただし、ビュー自体の中の列名は変更されません。この例の場
合は、表 customer に対して次のビューを再呼出ししてください。
CREATE VIEW name_only AS
SELECT customer_num, fname, lname FROM customer
ここで、表 customer が次の方法で変更されると仮定します。
RENAME COLUMN customer.lname TO surname
顧客の名字を直接選択するには、ここで新しい列名を選択しなければなりません。
しかし、ビューを介して見た場合には、列の名前は変わりません。次の二つの問合
せは同等です。
SELECT fname, surname FROM customer
SELECT fname, lname FROM name_only
データベース サーバのアクセス権の付与と制限
6-27
ビューを用いたデータの変更
列を削除して表を変更しても、ビューは変更されません。ビューが使用されている
と、エラー -217 ( 問合せのどの表にも、列が見つかりません ) が返されます。
ビューが変更されないのは、列を削除してから同じ名前の新しい列を追加すること
によって、列の順序を変更できるからです。これを行うと、その表をベースにして
いるビューが、引き続き機能します。列の元の順序が維持されます。
データベースサーバでは、ビューのベースとして、外部データベース内の表と
ビューを使用することができます。他のデータベースの表とビューを変更しても、
ビューには反映されません。そのような変更は、誰かがビューに対する問合せを
行って、外部表が変更されているというエラーを受け取るまで分からない場合があ
ります。
ビューを用いたデータの変更
ビューは、表であるかのように変更することができます。使用する SELECT 文に
よって、変更できるビューと変更できないビューがあります。制限は、DELETE
文、UPDATE 文または INSERT 文を使用するかどうかによって異なります。
SELECT 文に次の機能や特性が含まれている場合は、ビューに対して変更を行うこ
とはできません。
■
複数の表の結合
データベースサーバが、変更したデータを結合された表に正しく分散させ
ようとすると、さまざまな問題が起こります。
■
集計関数または GROUP BY 節
ビューの行が、多数の結合されたデータ行を表すことになります。データ
ベースサーバは、変更されたデータをそれらの行に分散することができま
せん。
■
キーワード DISTINCT またはそのシノニム UNIQUE
ビューの行は、多くの重複行からの選択要素を表すことになります。デー
タベースサーバは、元の行のうちのどの行が、その変更を受け取らなけれ
ばならないかを認識することができません。
■
キーワード UNION
ビューの行には、その行を生成した表を識別するためのタグは付いていま
せん。したがって、データベース サーバでは、更新や削除の操作の場合
は、更新または削除する必要のある行が含まれる表を識別できません。挿
入の操作の場合は、行の挿入先の表を識別できません。
ビューにこれらの要素がまったくなければ、ビューの各行が一つの表の 1 行に確実
に対応します。これらのビューは、修正可能です。この場合にも、適切なアクセス
権を持つ特定のユーザしかビューを修正できません。ビューに対するアクセス権に
ついての詳細は、6-31 ページ以降を参照してください )。
6-28
Informix Guide to Database Design and Implementation
ビューを用いたデータの変更
ビューを用いたデータの削除
修正可能なビューでは、あたかも表であるかのように DELETE 文を使用することが
できます。データベースサーバは、ベースにしている表の固有の行を削除します。
ビューの更新
修正可能なビューは、あたかも表であるかのように UPDATE 文を使用することが
できます。ただし、修正可能なビューには、導出列がまだ含まれている場合があり
ます。つまり、CREATE VIEW 文の選択リスト内の式で作成された列のことです。
導出列は更新できません。導出列は仮想列と呼ばれることもあります。
定数値を含む単純な列の算術的な組合せから列が導出されている場合、( たとえば
order_date + 30)、原則的にはデータベースサーバで式の逆算方法 ( この場合は
更新値から 30 を減算する ) を判定して、更新を実行することができます。しかし、
さらに複雑な式もあり、そういった式のほとんどは簡単には逆算できません。した
がってデータベースサーバは、導出列の更新をサポートしません。
次の例は、導出列と、それに対して受け入れることができる UPDATE 文が含まれ
ている、修正可能なビューを示しています。
CREATE VIEW call_response(user_id,received,resolved,duration
)AS
SELECT user_id,call_dtime,res_dtime, res_dtime-call_dtime
FROM cust_calls
WHERE user_id = USER;
UPDATE call_response SET resolved = TODAY
WHERE resolved IS NULL;
このビューの列 duration は式を表しているため更新できません ( データベースサー
バは原則的に見ても、式で指定されている二つの列間で更新値の分散する方法を判
定できません )。ただし、導出列が SET 節で指定されていなければ、ビューが表で
あるかのように更新を実行することができます。
ビューは、基礎となる表の行が一意であっても重複行を返すことがあります。ある
重複行を別の重複行と区別することはできません。一連の重複行のいずれか一つを
更新すると ( たとえば、カーソルを使用して、WHERE CURRENT を更新する )、
基礎表のどの行で更新を受け取るのかが分からなくなることがあります。
ビューへの挿入
ビューが修正可能であり、かつ導出列が含まれていない場合、ビューに行を挿入す
ることができます。二番目の制限が設けられているのは、挿入された行はすべての
列の値を表す必要があり、データベースサーバは、挿入された値を式を用いて分散
させる方法を認識できないからです。前の例に示すように、ビュー call_response
に挿入しようとすると失敗します。
データベース サーバのアクセス権の付与と制限
6-29
ビューを用いたデータの変更
修正可能なビューに導出列が含まれていなければ、あたかも表であるかのように、
そのビューに挿入することができます。ただし、データベースサーバは、ビューに
よって表出されない列の値としてナルを使用します。そのような列にナルを使用で
きない場合は、エラーが発生して挿入に失敗します。
WITH CHECK OPTION キーワードの使用
ビューの条件を満たさない行、つまりビューで見ることができない行をビューに挿
入することができます。また、ビューの行を更新して、その行がビューの条件を満
たさないようにすることもできます。
ビューの行が更新され、ビューの条件が満たされなくなることを防止するために、
ビューの作成時にキーワード WITH CHECK OPTION を追加することができます。
この節を使用すると、挿入されたそれぞれの行や、更新されたそれぞれの行を検査
して、ビューの WHERE 節によって設定されている条件を満たしていることを確認
するように、データベースサーバに指示が出されます。条件が満たされていない
と、データベースサーバはエラーメッセージを表示して、その操作を拒否します。
ビュー定義に演算子 UNION が含まれている場合、キーワード WITH CHECK
OPTION を指定することはできません。
前の例では、次の例に示すように call_response という名前のビューが定義されて
います。
CREATE VIEW call_response(user_id,received,resolved,duration)AS
SELECT user_id,call_dtime,res_dtime,res_dtime -call_dtime
FROM cust_calls
WHERE user_id = USER
ビューの列 user_id は、次の例に示すように更新することができます。
UPDATE call_response SET user_id = 'lenora'
WHERE received BETWEEN TODAY AND TODAY - 7
このビューには、user_id が USER と等しくなる行が必要です。tony という名前の
ユーザがこの更新を実行すると、更新された行がビューに表示されなくなります。
しかし、次の例に示すようにビューを作成することができます。
CREATE VIEW call_response (user_id,received,resolved,duration) AS
SELECT user_id,call_dtime,res_dtime,res_dtime-call_dtime
FROM cust_calls
WHERE user_id = USER
WITH CHECK OPTION
tony による前の更新は、エラーとして拒否されます。
6-30
Informix Guide to Database Design and Implementation
アクセス権とビュー
WITH CHECK OPTION 機能を使用して、ブール式として記述できるあらゆる種類
のデータ制約を実行することができます。次の例では、データに対するすべての論
理制約が、WHERE 節の条件として表される表のビューを作成することができま
す。次に表に対するすべての変更が、ビューを用いて行われるように要求すること
ができます。
CREATE VIEW order_insert AS
SELECT * FROM orders O
WHERE order_date = TODAY -- no back-dated entries
AND EXISTS -- ensure valid foreign key
(SELECT * FROM customer C
WHERE O.customer_num = C.customer_num)
AND ship_weight < 1000 -- reasonableness checks
AND ship_charge < 1000
WITH CHECK OPTION
データベースサーバは既存の行を抽出するときに有効になる可能性がある EXISTS
や他のテストの影響で orders からのデータ表示の効率が悪くなります。ただし、
orders への挿入が、このビューのみを用いて行われる場合は ( しかも、まだ整合性
制約を使用して、データを制約していない場合 )、日付をさかのぼって挿入したり、
無効な顧客番号、過度の積込重量、および積出費などを挿入したりすることはでき
ません。
PREPARE 文で処理された文をビュー定義の変更時に再実行
データベース サーバは、ビューで SELECT 文を PREPARE 文で処理するとき、その
時点で存在するビューの定義を使用します。あるビューで SELECT 文を PREPARE
文で処理した後にそのビューの定義が変更されると、PREPARE 文で処理された文
の実行結果が不正になることがあります。新しいビュー定義が反映されないためで
す。SQL エラーは生成されません。
アクセス権とビュー
ビューを作成するときに、データベース サーバは、基礎となる表とビューに対する
ユーザのアクセス権をテストします。ビューを使用する場合は、そのビューに関す
るユーザのアクセス権だけがテストされます。
ビューの作成時のアクセス権
データベースサーバは、ビュー定義で SELECT 文を実行するために必要となるすべ
てのアクセス権をユーザが持っているかどうかをテストします。必要なアクセス権
がないと、ビューは作成されません。
データベース サーバのアクセス権の付与と制限
6-31
ビューを使用するときのアクセス権
このテストによって、表に対するビューの作成と、ビューに対する問合せを実行し
ても、ユーザは表に不正にアクセスすることができなくなります。
ユーザがビューを作成した後は、そのビューの作成者であり所有者でもあるユーザ
には、少なくともビューに対する Select アクセス権がデータベースサーバによって
付与されます。新しく作成する表の場合のように、自動的に public にアクセス権が
付与されるわけではありません。
データベースサーバは、ビュー定義を検査して、そのビューが修正可能であるかど
うかを確認します。ビューが修正可能な場合は、データベースサーバによって、そ
のビューに対する Insert アクセス権、Delete アクセス権、および Update アクセス
権が付与されますが、その場合は基礎となる表またはビューに対しても、それらの
アクセス権がユーザに付与されていることが前提になります。つまり、新しい
ビューが修正可能である場合には、データベースサーバは、Insert アクセス権、
Delete アクセス権、Update アクセス権を基礎となる表またはビューからコピーし
て、新しい表に対して付与します。基礎表に対して Insert アクセス権しか持ってい
ない場合は、ビューに対しても Insert アクセス権のみが付与されます。
このテストによって、ユーザは、まだ付与されていないアクセス権に、ビューを使
用してアクセスすることができなくなります。
ビューを変更したりインデックス付けすることはできないので、Alter アクセス権
と Index アクセス権がビューに対して与えられることはありません。
ビューを使用するときのアクセス権
ビューを使用しようとすると、データベースサーバは、そのビューに対して付与さ
れているアクセス権のみをテストします。基礎となっている表へのアクセス権はテ
ストしません。
ビューを作成した場合は、前のパラグラフで述べたアクセス権が与えられます。作
成者でない場合は、WITH GRANT OPTION アクセス権を持っていた作成者などが
付与したアクセス権が与えられることになります。
6-32
Informix Guide to Database Design and Implementation
ビューを使用するときのアクセス権
したがって、表を作成して、その表に対するパブリックアクセスを取り消すことが
できます。このようにして、ビューを用いて次の表に対するアクセス権を付与する
ことができます。次の表はその定義を示しています。
CREATE TABLE hr_data
(
emp_key INTEGER,
emp_name CHAR(40),
hire_date DATE,
dept_num SMALLINT,
user-id CHAR(18),
salary DECIMAL(8,2),
performance_level CHAR(1),
performance_notes TEXT
)
6-11 ページの「列レベルアクセス権」では、表 hr_data にアクセス権を直接付与す
る方法を示しています。次の例では、別の方法がとられています。表の作成時に、
次の文が実行されたものとします。
REVOKE ALL ON hr_data FROM PUBLIC
このような文は、ANSI 標準準拠データベースでは不要です。ここで、さまざまな
クラスのユーザに対して一連のビューを作成します。機密性のある列に対する読込
み専用アクセス権を持っているべきユーザには、次のビューを作成します。
CREATE VIEW hr_public AS
SELECT emp_key, emp_name, hire_date, dept_num, user_id
FROM hr_data
このビューに対して Select アクセス権を付与されているユーザは、機密性のない
データを見ることはできますが、更新することはできません。新しい行を入力しな
ければならない人事部の社員に対しては、次の例に示されているように、別の
ビューを作成します。
CREATE VIEW hr_enter AS
SELECT emp_key, emp_name, hire_date, dept_num
FROM hr_data
これらのユーザには、このビューに対する Select アクセス権と Insert アクセス権を
付与します。表とビューの作成者として、その表とビューに対する Insert アクセス
権を持っているので、その表に対するアクセス権を持たない他のユーザに、ビュー
に対する Insert アクセス権を付与することができます。
新しいユーザ ID を入力したり更新したりする MIS 部門の社員に代わって、次の例
が示しているように、別のビューを作成します。
CREATE VIEW hr_MIS AS
SELECT emp_key, emp_name, user_id
FROM hr_data
データベース サーバのアクセス権の付与と制限
6-33
ビューを使用するときのアクセス権
このビューは、部門番号と採用日を表出させないという点で、前のビューとは異
なっています。
なお、マネージャは、あらゆる列へのアクセス権だけではなく、自分の部下に限っ
て勤務評価データを更新できる必要があります。これらの要求を満たすには、それ
ぞれの従業員の部門番号とコンピュータユーザ ID が記述されている表 hr_data を
作成します。管理職自身も、管理している部門のメンバであるというルールを忘れ
てはなりません。そこで、次のビューによって、自分の部下のみを反映する行に管
理職を限定します。
CREATE VIEW hr_mgr_data AS
SELECT * FROM hr_data
WHERE dept_num =
(SELECT dept_num FROM hr_data
WHERE user_id = USER)
AND NOT user_id = USER
最後の条件は、マネージャが表内の自分の行に対して更新のアクセス権を持たない
ようにするために必要です。したがって、次の文が示しているように、このビュー
では、一定の列に対してのみ、Update アクセス権を安全にマネージャに付与する
ことができます。
GRANT SELECT, UPDATE (performance_level, performance_notes)
ON hr_mgr_data TO peter_m
6-34
Informix Guide to Database Design and Implementation
Dynamic Server での拡張データ型の作成と使用
Dynamic Server による型継承と表継承
Dynamic Server でのユーザ定義キャストの作成と使用
セクション lll
オブジェクトリレーショナ
ル データベース
第7章
Dynamic Server での拡張
データ型の作成と使用
この章の概要 . .
.
. .
.
. .
. .
.
. .
. .
7-3
ユーザ定義のデータ型 . . . . . . . . . . . . . . . . . . . . .
不透明 (OPAQUE) 型 . . . . . . . . . . . . . . . . . . . .
ディスティンクト型 . . . . . . . . . . . . . . . . . . . .
7-4
7-4
7-4
スマート ラージ オブジェクト . . . . .
BLOB 型 . . . . . . . . . . .
CLOB 型 . . . . . . . . . . .
スマート ラージ オブジェクトの使用 .
スマート ラージ オブジェクトのコピー
.
.
.
.
.
7-5
7-5
7-5
7-7
7-8
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7-8
7-10
7-11
7-11
7-13
7-13
7-14
7-15
7-15
7-16
7-16
7-17
7-17
7-19
7-20
7-21
7-22
7-22
7-23
7-24
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
.
.
.
.
.
.
.
.
.
.
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
複合データ型 . . . . . . . . . . . . . . . . . . . . . . .
コレクション (COLLECTION) 型 . . . . . . . . . . . . . .
コレクション (COLLECTION) 型の NULL 値 . . . . . . . . .
セット (SET) 型 コレクション (COLLECTION) 型の使用 . . . . .
マルチセット (MULTISET) 型 コレクション (COLLECTION) 型の使用
リスト (LIST) 型 コレクション (COLLECTION) 型の使用 . . . . .
コレクション (COLLECTION) 型の入れ子 . . . . . . . . . .
既存の表へのコレクション (COLLECTION) 型の追加 . . . . . .
コレクション (COLLECTION) 型に許されるデータ型の制限 . . .
名前付き行 (ROW) 型 . . . . . . . . . . . . . . . . . . .
名前付き行 (ROW) 型を使用する場合 . . . . . . . . . . .
名前付き行 (ROW) 型の名前の選択 . . . . . . . . . . . .
名前付き行 (ROW) 型の制限 . . . . . . . . . . . . . . .
名前付き行 (ROW) 型を使用した型付き表の作成 . . . . . . .
型なし表から型付き表への変換 . . . . . . . . . . . . . .
名前付き行 (ROW) 型を使用した列の作成 . . . . . . . . . .
別の行 (ROW) 型の中での名前付き行 (ROW) 型の使用 . . . . .
名前付き行 (ROW) 型の削除 . . . . . . . . . . . . . . .
名前なし行 (ROW) 型 . . . . . . . . . . . . . . . . . . .
名前なし行 (ROW) 型で許容されるデータ型に関する制限 . . . .
7-2
Informix Guide to Database Design and Implementation
IDS
この章の概要
この章では、拡張データ型について説明します。拡張データ型を使用すると、オブ
ジェクト リレーショナル データベースを構築できます。オブジェクト リレーショ
ナルという用語は、特定のデータベース設計方法またはモデルに関連付けられたも
のではなく、Dynamic Server 機能を使用してデータベース機能を拡張した任意の
データベースを指します。
オブジェクト リレーショナル データベースは、リレーショナル データベースに対
立するものではなく、リレーショナル データベースの既存機能を拡張したもので
す。通常、データベースが格納および操作できるデータの種類を拡張するには、
Dynamic Server の機能を組み合わせて使用します。Dynamic Server の機能には、
拡張データ型、スマート ラージ オブジェクト、型と表の継承、ユーザ定義のキャ
スト、およびユーザ定義ルーチン (UDR) があります。このセクションの章で、これ
らの機能について説明します。UDR については、
『Extending Informix Dynamic
Server 2000』および『Informix Guide to SQL: Tutorial』を参照してください。
この章では、オブジェクト リレーショナル データベースを構築するために作成、
および使用する拡張データ型について説明します。次のトピックについて説明しま
す。
■
ユーザ定義型 ( 不透明 (OPAQUE) 型とディスティンクト型 )
■
複合データ型 ( コレクション (COLLECTION) 型と行 (ROW) 型 )
■
スマート ラージ オブジェクト
オブジェクト リレーショナル データベースの例として、superstores_demo データ
ベースを作成できます。これには、Dynamic Server で利用できるほとんどの機能の
例が含まれます。ただし、superstores_demo データベースには、不透明
(OPAQUE) 型および外部ユーザ定義ルーチンの例は含まれません。
superstores_demo データベースを作成する方法については、このマニュアルの
「序」を参照してください。
Dynamic Server での拡張データ型の作成と使用
7-3
ユーザ定義のデータ型
ユーザ定義のデータ型
ユーザ定義のデータ型とは、不透明 (OPAQUE) 型、またはディスティンクト型で
す。
不透明 (OPAQUE) 型
不透明 (OPAQUE) 型は、カプセル化されたデータ型で、CREATE OPAQUE TYPE
文で作成します。不透明 (OPAQUE) 型を作成するときは、データ型の構造体、そ
の不透明 (OPAQUE) 型を操作する関数、演算子、および集合も明示的に定義する
必要があります。不透明型 (OPAQUE) 型は、列およびプログラム変数を定義する
ときに使用できます。方法は、組込み型を使用する場合と同様です。
不透明 (OPAQUE) 型の作成については、『Extending Informix Dynamic
Server 2000』および『Informix Guide to SQL: Syntax』を参照してください。
ディスティンクト型
ディスティンクト型は、カプセル化されたデータ型で、CREATE DISTINCT TYPE
文で作成します。ディスティンクト型は、基になったデータ型と表現は同じです
が、性質は異なります。ディスティンクト型は、組込み型、不透明 (OPAQUE) 型、
名前付き行 (ROW) 型、またはほかのディスティンクト型から作成できます。ディ
スティンクト型は、次のデータ型からは作成できません。
■
シリアル (SERIAL) 型
■
8 バイト シリアル (SERIAL8) 型
■
コレクション (COLLECTION) 型
■
名前なし行 (ROW) 型
ディスティンクト型はソース データ型の構造体を継承するので、ディスティンクト
型を作成するときにはデータ型の構造体が暗黙的に定義されます。ディスティンク
ト型を操作する関数、演算子、および集合を定義することもできます。
ディスティンクト型については、9-14 ページの「ディスティンクト型のキャスト」、
『Informix Guide to SQL: Syntax』および『Informix Guide to SQL: Reference』を参
照してください。
7-4
Informix Guide to Database Design and Implementation
スマート ラージ オブジェクト
スマート ラージ オブジェクト
スマート ラージ オブジェクトは、BLOB 型、または CLOB 型に定義するオブジェク
トです。スマート ラージ オブジェクトにより、アプリケーション プログラムはラ
ンダムに列データにアクセスできます。つまり、BLOB 列、または CLOB 列の任意
の部分に対し、任意の順序で読み取りまたは書き込みができます。BLOB 列、また
は CLOB 列を作成すると、バイナリ形式のデータ、または文字データを格納するこ
とができます。
BLOB 型
BLOB 型を使用すると、プログラムが生成するあらゆるデータを格納できます。対
象になるデータには、グラフィック イメージ、サテライト イメージ、ビデオ ク
リップ、オーディオ クリップ、またはワード プロセッサやスプレッドシートで保
存した整形済みドキュメントがあります。データベース サーバは、BLOB 列にあら
ゆる長さ、かつあらゆる種類のデータを受け入れることができます。
CLOB オブジェクトと同様、BLOB オブジェクトは標準の行データとは別のディス
ク領域のディスク ページ全体に格納されます。
BLOB 型の利点は、CLOB 型とは異なり、あらゆるデータを受け入れることができ
るという点にあります。それを除けば、BLOB 型の利点と欠点は、CLOB 型と同じ
です。
CLOB 型
CLOB 型は、テキストのブロックを格納するときに使用できます。CLOB 型は、
HTML または PostScript のような整形済みテキストを含め、ASCII テキスト データ
を格納するように設計されています。CLOB オブジェクトには任意のデータを格納
できますが、Informix ツールでは CLOB オブジェクトは印字可能であることを前提
にしているため、このデータ型は印字可能な ASCII テキストに使用してください。
CLOB の値は、その行のほかの列の値と一緒には格納されません。CLOB の値に対
しては、ディスク ページ全体が割り当てられます。そのページは通常、行のほかの
値が格納される領域とは別のところに確保されます。詳細については、
『Administrator’s Guide』を参照してください。
Dynamic Server での拡張データ型の作成と使用
7-5
CLOB 型
CLOB 型は テキスト (TEXT) 型に似ていますが、CLOB 型には次の利点があります。
■
アプリケーション プログラムは、CLOB オブジェクトの任意の部分に対
し、読出しまたは書込みができます。
■
アプリケーション プログラムが CLOB オブジェクトの任意の部分にアクセ
スできることにより、アクセス時間が大幅に高速化されます。
■
デフォルト特性のオーバーライドが、比較的簡単に行えます。データベー
ス管理者は、SB 領域のデフォルト特性を列レベルでオーバーライドするこ
とができます。アプリケーション プログラマは、CLOB オブジェクトを作
成するときには、列のデフォルト特性の一部をオーバーライドすることが
できます。
■
等演算子 (=) を使用して、2 つの CLOB の値が等しいかどうかをテストで
きます。
■
CLOB オブジェクトは、システム障害が発生した場合は復旧可能です。ま
た、DBA またはアプリケーション プログラマがトランザクション排他設
定モードを指定すると、それに従います。ただし、CLOB オブジェクトを
復旧するには、データベース システムに、CLOB オブジェクトの処理に十
分な大きさのバッファを提供できるリソースが必要です。
■
CLOB データ型を使用すると、ユーザ定義のデータ型を格納する大きな領
域を提供できます。
■
DataBlade の開発者は、CLOB 型のインデックスを作成できます。
CLOB 型の欠点は次のとおりです。
7-6
■
ディスク ページ全体が割り当てられるため、短いデータの場合はディスク
容量が無駄になります。
■
SQL 文での CLOB 列の使用には制約があります。7-7 ページの「スマート
ラージ オブジェクトの使用」を参照してください。
■
すべての Informix データベース サーバで使用できるわけではありません。
Informix Guide to Database Design and Implementation
スマート ラージ オブジェクトの使用
スマート ラージ オブジェクトの使用
BLOB 型または CLOB 型の列を格納するには、SB 領域を割り当てる必要がありま
す。SB 領域は、BLOB データ、または CLOB データを、最も効率的に格納する論理
記憶単位です。ユーザが BLOB データまたは CLOB データを取り出したり格納した
りできるようにする Informix ESQL/C プログラムを作成できます。スマート ラー
ジ オブジェクトに直接アクセスし、操作するアプリケーション プログラムを作成
する方法については『Informix ESQL/C Programmer’s Manual』を参照してくださ
い。
BLOB 列や CLOB 列は、対話的に実行する SQL 文、およびプログラムに埋め込んで
使用する SQL 文中の、次の箇所では使用できません。
■
算術式やブール式
■
GROUP BY 節や ORDER BY 節
■
UNIQUE 検査
■
インデックス作成のとき、InformixB+ ツリー インデックスの一部として
ただし、DataBlade の開発者は、CLOB 列のインデックスを作成できます。
対話的に入力された SELECT 文では、BLOB 列または CLOB 列は次のようになりま
す。
■
DEFAULT NULL 節を付けて表を作成すると、デフォルト値として NULL
値を指定できます。
■
表を作成するとき NOT NULL 制約を使うと、NULL 値を不許可にできま
す。
■
IS [NOT] NULL 述部を使用することによって、NULL が入っているかどう
かを検査できます。
ESQL/C プログラムから ifx_lo_stat() 関数を使うと、BLOB データまたは CLOB
データの長さを判断できます。
Dynamic Server での拡張データ型の作成と使用
7-7
スマート ラージ オブジェクトのコピー
スマート ラージ オブジェクトのコピー
Dynamic Server が提供する関数を SQL 文の中から呼び出して、スマート ラージ オ
ブジェクトをインポートおよびエクスポートできます。図 7-1 に、スマート ラージ
オブジェクト関数を示します。
図 7-1
スマート ラージ オブジェクトを扱う SQL 関数
関数名
目的
FILETOBLOB()
ファイルを BLOB 列にコピーします。
FILETOCLOB()
ファイルを CLOB 列にコピーします。
LOCOPY()
BLOB データまたは CLOB データを、別の BLOB 列また
は CLOB 列にコピーします。
LOTOFILE()
BLOB データまたは CLOB データを、ファイルにコピー
します。
スマート ラージ オブジェクト関数の構文の詳細については、
『Informix Guide to
SQL: Syntax』の式セグメントを参照してください。
重要 : BLOB 型と CLOB 型との間でキャストすることはできません。
複合データ型
複合データ型は、通常、ほかの既存のデータ型の複合です。たとえば、組み込み
型、不透明 (OPAQUE) 型、ディスティンクト型、またはほかの複合型をコンポー
ネントに含む複合データ型を作成できます。ユーザ定義型に比べ、複合データ型に
は、ユーザが複合データ型の各コンポーネントにアクセスし、操作できるという重
要な利点があります。
これに対し、組込み型とユーザ定義型は、独立した ( カプセル化された ) データ型
です。そのため、不透明 (OPAQUE) 型のコンポーネントの値にアクセスするには、
不透明 (OPAQUE) 型に定義した関数を使うのが唯一の方法です。
7-8
Informix Guide to Database Design and Implementation
複合データ型
図 7-2 に、Dynamic Server がサポートする複合データ型、および複合データ型の作
成に使用する構文を示します。
図 7-2
複合データ型
複合データ型
コレクション
(COLLECTION) 型
リスト
(LIST) 型
セット
(SET) 型
マルチセット
(MULTISET) 型
行 (ROW) 型
名前付き行 (ROW) 型
CREATE ROW TYPE
名前なし行
(ROW) 型 ROW
図 7-2 で示す複合データ型により、次の拡張データ型がサポートされます。
■
コレクション (COLLECTION) 型。コレクション (COLLECTION) 型は、
データのコレクションを表セルに格納したり、操作する必要がある場合に
使用できます。コレクション (COLLECTION) 型は、列に割り当てること
ができます。
■
行 (ROW) 型。行 (ROW) 型は、一般的に複数のフィールドを含みます。列
または変数に複数の種類のデータを格納するときに、行 (ROW) 型を作成
できます。行 (ROW) 型には 2 種類あります。名前付き行 (ROW) 型と名前
なし行 (ROW) 型です。名前なし行 (ROW) 型は、列および変数に割り当て
ることができます。名前付き行 (ROW) 型は、列、変数、表、または
ビューに割り当てることができます。名前付き行 (ROW) 型を表に割り当
てると、表は型付き表になります。型付き表の主な利点は、継承階層構造
を定義するのに使用できるということです。
この章で説明する複合データ型で、SELECT、INSERT、UPDATE、および
『Informix Guide to SQL: Tutorial』
DELETE の各演算子の使い方の詳細については、
を参照してください。
Dynamic Server での拡張データ型の作成と使用
7-9
コレクション (COLLECTION) 型
コレクション (COLLECTION) 型
コレクション (COLLECTION) 型により、データのコレクションを表の 1 つの行に
格納して操作することができます。コレクション (COLLECTION) 型には 2 つのコ
ンポーネントがあります。そのコレクション (COLLECTION) 型が、セット (SET)
型、マルチセット (MULTISET) 型、またはリスト (LIST）型 のどれかを決定する型
コンストラクタと、そのコレクションに含められるデータの型を指定する要素型で
す。セット (SET) 型、マルチセット (MULTISET) 型、およびリスト (LIST) 型 の各
コレクション (COLLECTION) 型については、次の節で詳しく説明します。
コレクションの要素は、ほとんどすべてのデータ型をとることができます。例外の
一覧については、7-15 ページの「コレクション (COLLECTION) 型に許されるデー
タ型の制限」を参照してください。コレクションの要素とは、コレクションが含む
値です。次の値を含むコレクションがあるとします。{'blue', 'green',
'yellow', 'red'}。ここで、'blue' は、コレクション中の 1 つの要素を表しま
す。コレクションの各要素は、同じ型にする必要があります。たとえば、要素型が
整数 (INTEGER) 型のコレクションに含めることができるのは、整数の値だけです。
コレクション (COLLECTION) 型の要素型は、1 つのデータ型 ( 列 ) を表すことも、
複数のデータ型 ( 行 ) を表すこともできます。次の例で、列 col_1 は整数の セット
(SET) 型を表します。
col_1 SET(INTEGER NOT NULL)
複数のデータ型を含むコレクション (COLLECTION) 型を定義するには、名前付き
行 (ROW) 型、または名前なし行 (ROW) 型を使用します。次の例で、列 col_2 は
フィールド name およびフィールド salary を含む行の セット (SET) 型 を表します。
col_2 SET(ROW(name VARCHAR(20), salary INTEGER) NOT NULL)
重要 : コレクション (COLLECTION) 型を定義する場合、型定義の一部として NOT
NULL 制約を含める必要があります。コレクション (COLLECTION) 型には、ほかの
列制約は許されません。
列をコレクション (COLLECTION) 型として定義すると、コレクション
(COLLECTION) 型に対して次の操作を実行できるようになります。
■
コレクション (COLLECTION) 型の個別要素を選択および変更できます。こ
れは、ESQL/C プログラムでだけ実行できます。
■
コレクション (COLLECTION) 型に含まれる要素の数をカウントできます。
■
ある値がコレクション(COLLECTION)型に含まれているかどうかを判断で
きます。
コレクション (COLLECTION) 型を作成するのに使用する構文については、
『Informix Guide to SQL: Syntax』のデータ型セグメントを参照してください。コレ
クション (COLLECTION) 型の値を別のコレクション (COLLECTION) 型に変換する
方法については、
『Informix Guide to SQL: Tutorial』を参照してください。
7-10
Informix Guide to Database Design and Implementation
コレクション (COLLECTION) 型
コレクション (COLLECTION) 型の NULL 値
コレクション (COLLECTION) 型には、NULL 要素を含めることはできません。し
かし、コレクション (COLLECTION) 型が行 (ROW) 型の場合は、コレクション
(COLLECTION) 型に含まれる行 (ROW) 型のフィールドに、NULL 値を挿入できま
す。コレクション (COLLECTION) 型列がある表を、次のように作成するとします。
CREATE TABLE tab1 (col1 INT,
col2 SET(ROW(a INT, b INT) NOT NULL));
次の文は、行 (ROW) 型のコンポーネント フィールドだけが NULL 値を指定してい
るので、許可されます。
INSERT INTO tab1 VALUES ( 25,"SET{ROW(NULL, NULL)}");
INSERT INTO tab1 VALUES ( 35,"SET{ROW(4, NULL)}");
INSERT INTO tab1 VALUES ( 45,"SET{ROW(14, NULL),
ROW(NULL,5)}");
UPDATE tab1 SET col2 = "SET{ROW(NULL, NULL)}" WHERE col1 = 45;
しかし、次の各文ではコレクション (COLLECTION) 型要素が NULL 値を指定して
いるので、エラー メッセージを戻します。
INSERT INTO tab1 VALUES ( 45, "SET{NULL)}");
UPDATE tab1 SET col2 = "SET{NULL}" WHERE col1 = 55;
セット (SET) 型 コレクション (COLLECTION) 型の使用
セット (SET) 型 は、要素を順序付けしないコレクション (COLLECTION) 型で、各
要素は一意です。次のような特性を持つ要素のコレクション (COLLECTION) 型を
格納する場合は、列をセット (SET) 型 コレクション (COLLECTION) 型として定義
します。
■
要素には、重複した値が含まれていない。
■
要素に関連付けられた、特別な順序はない。
Dynamic Server での拡張データ型の作成と使用
7-11
コレクション (COLLECTION) 型
セット (SET) 型 の使い方を説明します。人事部が、従業員の扶養家族に関する情報
を必要としているとします。コレクション (COLLECTION) 型を使用して、従業員
の扶養家族の名前を格納する表 employee の列を定義できます。次の文で作成され
る表の列 dependents は、セット (SET) 型 として定義されます。
CREATE TABLE employee
(
name
CHAR(30),
address
CHAR (40),
salary
INTEGER,
dependents SET(VARCHAR(30) NOT NULL)
);
指定された行の dependents 列に対する問合せは、従業員の扶養家族全員の名前を
リターンします。この場合、セット (SET) 型 が適切なコレクション
(COLLECTION) 型です。各従業員の扶養家族のコレクション (COLLECTION) 型に
は、重複した値は含まれないからです。列を セット (SET) 型 として定義すると、コ
レクション (COLLECTION) 型の各要素が一意であることが保証されます。
要素が行 (ROW) 型のコレクション (COLLECTION) 型を定義する方法を説明しま
す。列 dependents に従業員の扶養家族の名前、および生年月日を含めるとします。
次の例では、列 dependents は要素型が行 (ROW) 型の セット (SET) 型 として定義さ
れています。
CREATE TABLE employee
(
name
CHAR(30),
address
CHAR (40),
salary
INTEGER,
dependents SET(ROW(name VARCHAR(30), bdate DATE)
NOT NULL)
);
列 dependents のコレクション (COLLECTION) 型の各要素には、name の値、およ
び bdate の値が含まれます。表 employee の各行には、従業員の情報と共に、従業
員の扶養家族の名前および生年月日のコレクション (COLLECTION) 型が含まれま
す。たとえば、扶養家族がいない従業員の場合、列 dependents のコレクション
(COLLECTION) 型は空です。10 人の扶養家族がいる従業員の場合、コレクション
(COLLECTION) 型には 10 個の要素が含まれます。
7-12
Informix Guide to Database Design and Implementation
コレクション (COLLECTION) 型
マルチセット (MULTISET) 型 コレクション (COLLECTION) 型の使
用
マルチセット (MULTISET) 型 は、重複した値を取ることができる、要素のコレク
ション (COLLECTION) 型です。たとえば、整数の マルチセット (MULTISET) 型 に
は、重複した要素のあるコレクション (COLLECTION) 型 {1,3,4,3,3} を含めることが
できます。次のような特性を持つ要素のコレクション (COLLECTION) 型を格納す
る場合は、列を マルチセット (MULTISET) 型 コレクション (COLLECTION) 型とし
て定義できます。
■
要素が一意でない可能性がある。
■
要素に、関連付けられた特別な順序はない。
マルチセット (MULTISET) 型 の使い方を説明します。人事部が従業員の賞与を追
跡する必要があるとします。各従業員の賞与を長期にわたって追跡するために、従
業員が受け取ったすべての賞与を記録する表の列を、マルチセット (MULTISET) 型
を使用して定義します。次の例で、列 bonus は マルチセット (MULTISET) 型 です。
CREATE TABLE employee
(
name
CHAR(30),
address
CHAR (40),
salary
INTEGER,
bonus
MULTISET(MONEY NOT NULL)
);
この文の列 bonus を使用して、各従業員の賞与のコレクション (COLLECTION) 型
を格納し、アクセスできます。指定された行の列 bonus に対する問合せは、従業員
が受け取った各賞与の金額を戻します。従業員は、同じ額の賞与を複数回受け取る
ことがあります。その場合、コレクション (COLLECTION) 型の要素は、すべて一
意ではなくなります。そのため列 bonus は、重複した値を許可する マルチセット
(MULTISET) 型 として定義します。
リスト (LIST) 型 コレクション (COLLECTION) 型の使用
リスト (LIST) 型 は、順序付けされた要素のコレクション (COLLECTION) 型で、重
複した値を許可します。リスト (LIST) 型 と マルチセット (MULTISET) 型 の違い
は、リスト (LIST) 型 の要素にはそれぞれ、コレクション (COLLECTION) 型の中で
の順序を示す位置が与えられるという点にあります。リスト (LIST) 型内での要素の
順序は、リスト (LIST) 型 に値を挿入する順序に対応します。次のような特性を持
つ要素のコレクション (COLLECTION) 型を格納する場合には、列を リスト (LIST)
型 コレクション (COLLECTION) 型として定義できます。
■
要素に、関連付けられた特別な順序がある。
■
要素が、一意でない可能性がある。
Dynamic Server での拡張データ型の作成と使用
7-13
コレクション (COLLECTION) 型
リスト (LIST) 型 の使い方を説明します。営業部が営業部員ごとの月別総売り上げ
高を記録する必要があるとします。営業部員ごとの月別総売り上げ高を含む表の列
は、リスト (LIST) 型 を使用して定義できます。次の例で作成される表の列
month_sales は リスト (LIST) 型 です。リスト (LIST) 型 の最初のエントリ ( 要素 ) に
は、順序を示す位置として 1 が与えられ、1 月に対応します。2 番めの要素には、順
序を示す位置として 2 が与えられ、2 月に対応します。ほかの要素も同様です。
CREATE TABLE sales_person
(
name
CHAR(30),
month_sales LIST(MONEY NOT NULL)
);
この文の month_sales 列を使用して、営業部員ごとの月別総売り上げ高を格納し、
アクセスできます。つまり、month_sales 列に対して問合せを実行し、次の値を取
得できます。
■
ある営業部員が特定の月に達成した総売り上げ高
■
特定の月の営業部員別総売り上げ高
コレクション (COLLECTION) 型の入れ子
入れ子コレクション (COLLECTION) 型は、別のコレクション (COLLECTION) 型を
含むコレクション (COLLECTION) 型です。どのコレクション (COLLECTION) 型
も、別のコレクション (COLLECTION) 型の中に入れ子にすることができます。コ
レクション (COLLECTION) 型の入れ子の深さに、制限はありません。しかし、1 レ
ベルか 2 レベルを超える入れ子にしたコレクション (COLLECTION) 型の挿入また
は更新を実行するのは困難です。次の例で、入れ子コレクション (COLLECTION)
型に定義した列を作成する方法をいくつか示します。
col_1 SET(MULTISET(VARCHAR(20) NOT NULL) NOT NULL);
col_2 MULTISET(ROW(x CHAR(5), y SET(INTEGER NOT NULL))
NOT NULL);
col_3 LIST(MULTISET(ROW(a CHAR(2), b INTEGER) NOT NULL)
NOT NULL);
入れ子コレクション (COLLECTION) 型にアクセスする方法については、
『Informix
Guide to SQL: Tutorial』を参照してください。
7-14
Informix Guide to Database Design and Implementation
コレクション (COLLECTION) 型
既存の表へのコレクション (COLLECTION) 型の追加
ALTER TABLE 文を使用して、コレクション (COLLECTION) 型の列を追加または
削除できます。ALTER TABLE 文を使うと、任意のデータ型の列を追加または削除
できます。たとえば、次の文は、セット (SET) 型 として定義された列 flowers を表
nursery に追加します。
ALTER TABLE nursery ADD
flowers
SET(VARCHAR(30) NOT NULL)
既存のコレクション (COLLECTION) 型列は変更できません。また、非コレクショ
ン (COLLECTION) 型列をコレクション (COLLECTION) 型に変換することはできま
せん。
コレクション (COLLECTION) 型列の追加と削除の詳細については、
『Informix
Guide to SQL: Syntax』の ALTER TABLE 文を参照してください。
重要 : ALTER TABLE 文を使用して型付き表に列を追加することはできません。表
に割り当てられた名前付き行 (ROW) 型によって、表の構造が指定されるためです。
コレクション (COLLECTION) 型に許されるデータ型の制限
次のデータ型は、コレクション (COLLECTION) 型の要素型としては使用できませ
ん。
■
テキスト (TEXT) 型
■
バイト (BYTE) 型
■
シリアル (SERIAL) 型
■
8 バイト シリアル (SERIAL8) 型
Dynamic Server での拡張データ型の作成と使用
7-15
名前付き行 (ROW) 型
名前付き行 (ROW) 型
名前付き行 (ROW) 型は、単一名で定義されたフィールドのグループです。フィー
ルドは、行 (ROW) 型のコンポーネントを指します。列と混同しないように注意し
てください。列は、表にだけ関連付けられます。名前付き行 (ROW) 型のフィール
ドは、C 言語の構造体のフィールド、またはオブジェクト指向プログラミングのク
ラスのメンバに似ています。名前付き行 (ROW) 型を作成した後、行 (ROW) 型に割
り当てた名前によって、データベースの中で一意な型が表されます。名前付き行
(ROW) 型を作成するには、行 (ROW) 型の名前と、その行 (ROW) 型を構成する
フィールドの名前とデータ型を指定します。次の例で、person_t という名前付き行
(ROW) 型を作成する方法を示します。
CREATE ROW TYPE person_t
(
name
VARCHAR(30) NOT NULL,
address VARCHAR(20),
city
VARCHAR(20),
state
CHAR(2),
zip
VARCHAR(9),
bdate
DATE
);
person_t 行 (ROW) 型には、6 つのフィールドが含まれます。name、address、city、
state、zip、および bdate の 6 つのフィールドです。行 (ROW) 型のフィールドを定
義するときには、ほとんどのデータ型を使用することができます。行 (ROW) 型が
サポートしないデータ型については、7-17 ページの「名前付き行 (ROW) 型の制限」
を参照してください。名前付き行 (ROW) 型を作成すると、ほかのデータ型を使用
するのと同じように、この型を使用できます。たとえば、person_t は、ほかのデー
タ型が使用できるすべての場所で使用できます。
名前付き行 (ROW) 型を作成するために使用する構文については、『Informix Guide
to SQL: Syntax』の CREATE ROW TYPE 文を参照してください。行 (ROW) 型の値
をキャストする方法については、第 9 章「Dynamic Server でのユーザ定義キャスト
の作成と使用」を参照してください。
名前付き行 (ROW) 型を使用する場合
名前付き行 (ROW) 型は、Dynamic Server で新しいデータ型を作成する方法の 1 つ
です。名前付き行 (ROW) 型を作成するときは、データベース サーバが理解できる
データ型で、フィールドのテンプレートを定義します。このように、行 (ROW) 型
のフィールド定義は、表の列定義に似ています。どちらも、データベース サーバが
識別できるデータ型で構築します。
7-16
Informix Guide to Database Design and Implementation
名前付き行 (ROW) 型
ユーザがアクセスする必要のあるコンポーネント値のコンテナとして機能する型が
必要な場合は、名前付き行 (ROW) 型を作成できます。たとえば、ユーザが直接、
住所の値の個々のコンポーネント値、つまり町名、市、州、および郵便番号にアク
セスする必要がある場合は、住所の値をサポートする名前付き行 (ROW) 型を作成
できます。address 型を名前付き行 (ROW) 型として作成すると、ユーザはいつで
も、それぞれのフィールドに直接アクセスできます。
それに対し、住所の値を扱う不透明 (OPAQUE) 型を作成すると、住所情報はすべ
て C 言語のデータ構造体に格納されます。不透明 (OPAQUE) 型のコンポーネント
値はカプセル化されるので、コンポーネント値を町名、市、州、郵便番号に展開す
る関数を定義する必要があります。このように、不透明 (OPAQUE) 型は名前付き
行 (ROW) 型よりも定義および使用方法が複雑な型です。
データ型を定義する前に、その型が単に、ユーザが直接アクセスできる値のグルー
プのコンテナであるかどうかを判断します。この説明に当てはまる場合、名前付き
行 (ROW) 型を使用します。
名前付き行 (ROW) 型の名前の選択
SQL 識別子の命名規則に違反しない限り、名前付き行 (ROW) 型にはどんな名前で
も付けられます。SQL 識別子の命名規則は、
『Informix Guide to SQL: Syntax』の識
別子セグメントで説明します。型名と表名を混同しないように、このマニュアルの
例では、行 (ROW) 型の名前の末尾に文字列 _t を付けることにより、名前付き行
(ROW) 型であることを示します。
名前付き行 (ROW) 型を作成するには、Resource アクセス権が必要です。データ型
はすべて、同じネーム スペースを共有します。名前付き行 (ROW) 型に割り当てる
名前は、データベースに存在するほかのデータ型と違うものにしてください。
ANSI 標準準拠データベースでは、owner.type の組み合わせをデータベースで一
意にする必要があります。ANSI 標準準拠でないデータベースでは、名前をデータ
ベースで一意にする必要があります。
重要 : ほかのユーザが使用する前に、名前付き行 (ROW) 型に Usage アクセス権を
付与する必要があります。名前付き行 (ROW) 型のアクセス権の付与と取消しにつ
いては、第 11 章「次元データベースの実装」を参照してください。
名前付き行 (ROW) 型の制限
このセクションでは、名前付き行 (ROW) 型を使用するときに適用される制限につ
いて説明します。
Dynamic Server での拡張データ型の作成と使用
7-17
名前付き行 (ROW) 型
名前付き行 (ROW) 型のフィールドのデータ型に関する制限
ラージ オブジェクトの列を含む型付き表を作成する場合、テキスト (TEXT) 型また
はバイト (BYTE) 型ではなく、BLOB 型または CLOB 型を使用することをお勧めし
ます。下位方向の互換性のために、テキスト (TEXT) 型またはバイト (BYTE) 型の
フィールドを含む名前付き行 (ROW) 型を作成したり、これらの型を使って既存の
型なし表を型付き表に再生したりできます。しかし、テキスト (TEXT) 型やバイト
(BYTE) 型のフィールドを含む名前付き行 (ROW) 型を使用して型付き表を作成する
ことはできますが、このような行 (ROW) 型を列として使用することはできません。
BLOB 型や CLOB 型のフィールドを含む名前付き行 (ROW) 型は、型付き表または
列に割り当てることができます。
名前付き行 (ROW) 型の制約に関する制限
CREATE ROW TYPE 文で名前付き行 (ROW) 型のフィールドに対して指定できるの
は、NOT NULL 制約だけです。ほかの制約は、CREATE TABLE 文で定義する必要
があります。詳細については、
『Informix Guide to SQL: Syntax』の CREATE
TABLE 文を参照してください。
名前付き行 (ROW) 型のインデックスに関する制限
CREATE INDEX 文を使用して名前付き行 (ROW) 型列のインデックスを作成するこ
とはできません。しかし、ユーザ定義ルーチンを使用して、行 (ROW) 型列の関数
インデックスを作成することはできます。
シリアル (SERIAL) 型を含む名前付き行 (ROW) 型に関する制限
表の列型として、シリアル (SERIAL) 型または 8 バイト シリアル (SERIAL8) 型を含
む名前付き行 (ROW) 型は使用できません。次の文は、データベース サーバが表を
作成しようとしたときに、エラーを戻します。
CREATE ROW TYPE row_t (s_col SERIAL)
CREATE TABLE bad_tab (col1 row_t)
しかし、シリアル (SERIAL) 型または 8 バイト シリアル (SERIAL8) 型を含む名前付
き行 (ROW) 型を使用して、型付き表を作成することはできます。
表の階層構造でのシリアル (SERIAL) 型および 8 バイト シリアル (SERIAL8) 型の使
用と動作については、8-18 ページの「表階層内のシリアル (SERIAL) 型」を参照し
てください。
7-18
Informix Guide to Database Design and Implementation
名前付き行 (ROW) 型
名前付き行 (ROW) 型を使用した型付き表の作成
表は、型付き表または型なし表として作成できます。型付き表は、名前付き行
(ROW) 型が割り当てられた表です。型なし表は、名前付き行 (ROW) 型が割り当て
られていない表です。CREATE ROW TYPE 文は、名前付き行 (ROW) 型を作成しま
すが、行 (ROW) 型のインスタンスの格納域は割り当てません。名前付き行 (ROW)
型のインスタンスの格納域を割り当てるには、行 (ROW) 型を表に割り当てる必要
があります。次の例で、型付き表を作成する方法を示します。
CREATE ROW TYPE person_t
(
name
VARCHAR(30),
address VARCHAR(20),
city
VARCHAR(20),
state
CHAR(2),
zip
INTEGER,
bdate
DATE
);
CREATE TABLE person OF TYPE person_t;
最初の文で、person_t 型を作成します。2 番めの文で、表 person を作成します。こ
の表に、person_t 型のインスタンスが格納されます。厳密に言えば、型付き表の各
行に、表に割り当てられた名前付き行 (ROW) 型のインスタンスが格納されます。
前の例で、person_t 型のフィールドは、表 person の列を定義します。
重要 : 名前付き行 (ROW) 型を作成する順序は重要です。名前付き行 (ROW) 型を使
用して型付き表を定義する前に、その型が存在している必要があります。
型付き表へのデータ挿入は、型なし表へのデータ挿入と同様に行います。型付き表
にデータを挿入すると、行 (ROW) 型のインスタンスが作成され、表に挿入されま
す。次の例で、表 person に行を挿入する方法を示します。
INSERT INTO person
VALUES ('Brown, James', '13 First St.', 'San Carlos', 'CA',
94070, '01/04/1940')
INSERT 文により、person_t 型のインスタンスが作成され、表に挿入されます。名
前付き行 (ROW) 型に定義した列を挿入、更新、および削除する方法の詳細につい
ては、
『Informix Guide to SQL: Tutorial』を参照してください。
1 つの名前付き行 (ROW) 型を使用して、複数の型付き表を作成できます。この場
合、表の名前は一意ですが、すべての表が同じ型を共有します。
重要 : 一時表の型付き表は作成できません。
データ モデルを実装するときに型付き表を使用する利点については、8-3 ページの
「型継承」を参照してください。
Dynamic Server での拡張データ型の作成と使用
7-19
名前付き行 (ROW) 型
型なし表から型付き表への変換
型なし表に比べ、型付き表には、継承階層構造で使用できるという利点がありま
す。一般に、継承によって表は別の表の表現および動作を取得することができま
す。継承の詳細については、8-3 ページの「継承について」を参照してください。
既存の型なし表を型付き表に変換するには、ALTER TABLE 文を使用します。たと
えば、次の型なし表について考えます。
CREATE TABLE manager
(
name
VARCHAR(30),
department VARCHAR(20),
salary
INTEGER
);
型なし表を型付き表に変換するには、名前付き行 (ROW) 型のフィールド名と
フィールド型の両方を、既存の表の列名と列型に一致させる必要があります。たと
えば、表 manager を型付き表にするには、まず、表の列定義に一致する名前付き行
(ROW) 型を作成する必要があります。次の文は、表 manager の列に一致する
フィールド名とフィールド型を含む manager_t 型を作成します。
CREATE ROW TYPE manager_t
(
name
VARCHAR(30),
department VARCHAR(30),
salary
INTEGER
);
既存の型なし表に割り当てる名前付き行 (ROW) 型を作成した後、ALTER TABLE
文を使用して、型を表に割り当てます。次の文は、表 manager を変更し、型
manager_t の型付き表にします。
ALTER TABLE manager ADD TYPE manager_t
新しい表 manager は、古い表と同じ列とデータ型を含みながら、型付き表の利点も
提供します。
7-20
Informix Guide to Database Design and Implementation
名前付き行 (ROW) 型
名前付き行 (ROW) 型を使用した列の作成
型付き表と型なし表のどちらにも、名前付き行 (ROW) 型に定義した列を含めるこ
とができます。名前付き行 (ROW) 型に定義した列は、型付き表、または型なし表
のどちらの列でも同じように動作します。次の例で、最初の文は名前付き行 (ROW)
型 address_t を作成します。2 番めの文は、address_t 型を表 employee の address 列
に割り当てます。
CREATE ROW TYPE address_t
(
street VARCHAR(20),
city
VARCHAR(20),
state
CHAR(2),
zip
VARCHAR(9)
);
CREATE TABLE employee
(
name
VARCHAR(30),
address address_t,
salary INTEGER
);
この CREATE TABLE 文で、address 列には street、city、state、および zip という
address_t 型のフィールドがあります。そのため、表 employee は 3 つの列だけで、
name、street、city、state、zip、および salary の値を含んでいます。行 (ROW) 型
に定義した列の個々のフィールドにアクセスするには、ピリオド表記を使用しま
す。ピリオド表記を使用して列のフィールドにアクセスする方法については、
『Informix Guide to SQL: Tutorial』を参照してください。
行 (ROW) 型を割り当てた列にデータを挿入するときは、ROW コンストラクタを使
用して行 (ROW) 型の行定数値を指定する必要があります。次の例で、INSERT 文を
使用して表 employee に行を挿入する方法を示します。
INSERT INTO employee
VALUES ('John Bryant',
ROW('10 Bay Street', 'Madera', 'CA', 95400)::address_t,
55000);
強い型指定は、名前付き行 (ROW) 型の挿入または更新には適用されません。行の
値を確実に名前付き行 (ROW) 型の値にするには、前の例で示したように、名前付
き行 (ROW) 型に明示的にキャストし、名前付き行 (ROW) 型の値を生成する必要が
あります。INSERT 文は、3 つの値を挿入します。そのうち 1 つは、4 つの値を含む
行 (ROW) 型の値です。厳密に言えば、この操作は列 name と列 salary に分割でき
ない値を挿入し、address_t 型のインスタンスを作成して列 address に挿入します。
行 (ROW) 型に定義した列を挿入、更新、および削除する方法の詳細については、
『Informix Guide to SQL: Tutorial』を参照してください。
Dynamic Server での拡張データ型の作成と使用
7-21
名前付き行 (ROW) 型
別の行 (ROW) 型の中での名前付き行 (ROW) 型の使用
名前付き行 (ROW) 型は、別の行 (ROW) 型のフィールドのデータ型として使用でき
ます。入れ子行 (ROW) 型は、別の行 (ROW) 型を含む行 (ROW) 型です。どの行
(ROW) 型をどの行 (ROW) 型の中に入れてもかまいません。行 (ROW) 型の入れ子の
深さに制限はありません。しかし、深い入れ子にした行 (ROW) 型の挿入または更
新を実行する場合、構文の使い方に注意が必要です。
名前付き行 (ROW) 型の場合、行 (ROW) 型を作成する順序が重要です。別の行
(ROW) 型の列またはフィールドを定義する前に、その名前付き行 (ROW) 型が存在
している必要があります。次の例では、最初の文で address_t 型を作成し、2 番めの
文でそれを使用して、employee_t 型の address フィールドの型を定義します。
CREATE ROW TYPE address_t
(
street VARCHAR (20),
city
VARCHAR(20),
state
CHAR(2),
zip
VARCHAR(9)
);
CREATE ROW TYPE employee_t
(
name
VARCHAR(30) NOT NULL,
address address_t,
salary INTEGER
);
重要 : 行 (ROW) 型を再帰的に使用することはできません。type_t が行 (ROW) 型の
場合、type_t を type_t に含まれるフィールドのデータ型として使用することはでき
ません。
名前付き行 (ROW) 型の削除
名前付き行 (ROW) 型を削除するには、DROP ROW TYPE 文を使用します。型を削
除できるのは、依存性がない場合だけです。次の条件に 1 つでも当てはまる場合、
その名前付き行 (ROW) 型は削除できません。
■
現在、型が表に割り当てられている。
■
現在、型が表の列に割り当てられている。
■
現在、型が別の行 (ROW) 型のフィールドに割り当てられている。
次の例で、person_t 型を削除する方法を示します。
DROP ROW TYPE person_t restrict;
7-22
Informix Guide to Database Design and Implementation
名前なし行 (ROW) 型
名前付き行 (ROW) 型を型階層から削除する方法については、8-9 ページの「型階層
からの名前付き行 (ROW) 型の削除」を参照してください。
名前なし行 (ROW) 型
名前なし行 (ROW) 型は、ROW コンストラクタで作成する、型付きフィールドのグ
ループです。名前付き行 (ROW) 型と名前なし行 (ROW) 型の重要な違いは、名前な
し行 (ROW) 型は表に割り当てることができない、という点です。名前なし行
(ROW) 型は、列またはフィールドの型定義にだけ使用します。また、名前なし行
(ROW) 型は構造体だけで識別されます。これに対し、名前付き行 (ROW) 型は名前
で識別されます。行 (ROW) 型の構造体は、フィールドの数とデータ型で構成され
ます。
次の文は、2 つの名前なし行 (ROW) 型を表 student の列に割り当てます。
CREATE TABLE student
(
s_name
ROW(f_name VARCHAR(20), m_init CHAR(1),
l_name VARCHAR(20) NOT NULL),
s_address
ROW(street VARCHAR(20), city VARCHAR(20),
state CHAR(2), zip VARCHAR(9))
);
表 student の列 s_name と列 s_address には、それぞれ複数のフィールドが含まれて
います。名前なし行 (ROW) 型のフィールドは、それぞれ異なるデータ型にできま
す。表 student の列は 2 つだけですが、名前なし行 (ROW) 型によって、全部で 7 つ
のフィールドが定義されます。f_name、m_init、l_name、street、city、state、お
よび zip の 7 つです。
次の例で、INSERT 文を使用して表 student にデータを挿入する方法を示します。
INSERT INTO student
VALUES (ROW('Jim', 'K', 'Johnson'), ROW('10 Grove St.',
'Eldorado', 'CA', 94108))
行 (ROW) 型に定義した列を変更する方法の詳細については、
『Informix Guide to
SQL: Tutorial』を参照してください。
2 つの名前なし行 (ROW) 型が同じ数のフィールドを含み、対応するフィールドが同
じ型である場合、データベース サーバはこの 2 つを区別しません。名前なし行
(ROW) 型の型チェックでは、フィールド名は無関係です。たとえば、データベース
サーバは次の名前なし行 (ROW) 型を区別しません。
ROW(a INTEGER, b CHAR(4));
ROW(x INTEGER, y CHAR(4));
Dynamic Server での拡張データ型の作成と使用
7-23
名前なし行 (ROW) 型
名前なし行 (ROW) 型の構文については、
『Informix Guide to SQL: Syntax』を参照
してください。行 (ROW) 型の値をキャストする方法については、第 9 章
「Dynamic Server でのユーザ定義キャストの作成と使用」を参照してください。
名前なし行 (ROW) 型で許容されるデータ型に関する制限
名前なし行 (ROW) 型のフィールド型として、次のデータ型は使用できません。
■
シリアル (SERIAL) 型
■
8 バイト シリアル (SERIAL8) 型
■
バイト (BYTE) 型
■
テキスト (TEXT) 型
これらの型が名前なし行 (ROW) 型のフィールド定義で指定されると、データベー
ス サーバはエラーを戻します。
7-24
Informix Guide to Database Design and Implementation
第8章
Dynamic Server による型継承
と表継承
この章の概要 . .
.
. .
.
. .
. .
.
. .
.
. .
. .
.
. .
.
. .
8-3
継承について . .
.
. .
.
. .
. .
.
. .
.
. .
. .
.
. .
.
. .
8-3
型継承 . . . . . . . . . . . . . . . .
型階層の定義 . . . . . . . . . . . .
型階層内の型に対するルーチンのオーバーロード
継承と型代用性 . . . . . . . . . . . .
型階層からの名前付き行 (ROW) 型の削除 . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8-3
8-4
8-7
8-8
8-9
表継承 . . . . . . . . . . . . . .
型階層と表階層との関係 . . . . . .
表階層の定義 . . . . . . . . . .
表階層内の表の動作の継承 . . . . . .
型階層内の表の動作の修正 . . . . . .
表階層内の表に対する制約 . . . .
表階層内の表へのインデックスの追加
表階層内の表のトリガ . . . . . .
表階層内のシリアル (SERIAL) 型 . . .
表階層への表の追加 . . . . . . . .
表階層内の表の削除 . . . . . . . .
表階層内の表の構造の変更 . . . . . .
表階層内の表の問合せ . . . . . . .
表階層内の表のビューの作成 . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8-10
8-11
8-12
8-13
8-15
8-16
8-17
8-17
8-18
8-19
8-20
8-21
8-21
8-21
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8-2
Informix Guide to Database Design and Implementation
IDS
この章の概要
この章では、型継承と表継承について説明し、型階層と表階層を作成して各階層内
の型と表を修正する方法について取り上げます。次のことについて説明します。
■
継承について
■
型継承
■
表継承
継承について
継承は、ある型や表が、別の型や表のプロパティを取得できるようにする処理で
す。プロパティを継承する型、表をそれぞれ副型、副表と呼びます。プロパティを
継承される型、表をそれぞれ上位型、上位表と呼びます。継承では差分修正を実行
できるため、型や表は、プロパティの全般的なセットを継承して、それぞれに固有
のプロパティを追加できます。継承を使用しての修正は、継承された上位型や上位
表が修正によって変更されない程度に行います。
Dynamic Server は、名前付き行 (ROW) 型と型付き表に対してだけ継承をサポート
します。Dynamic Server では、単一継承しかサポートされません。単一継承では、
それぞれの副型や副表には上位型や上位表が 1 つずつしかありません。
型継承
型継承は名前付き行 (ROW) 型だけに適用されます。継承を使用して、名前付き行
(ROW) 型を型階層にグループ化できます。型階層では、それぞれの副型が、その副
型の上位に定義されている上位型の表現 ( データ フィールド ) と動作 (UDR、集合、
および演算子 ) を継承します。型階層には、次の利点があります。
■
データ モデルのモジュール実装が容易になります。
■
スキーマ コンポーネントを一貫して再使用できるようになります。
Dynamic Server による型継承と表継承
8-3
型階層の定義
■
誤ってデータ フィールドを除外することがなくなります。
■
別のデータ型に定義されている UDR の継承が可能になります。
型階層の定義
図 8-1 に、3 つの名前付き行 (ROW) 型を持つ単純な型階層の例を示します。
person_t
図 8-1
型階層の例
employee_t
sales_rep_t
この型階層の最上位にある上位型には、その下にある副型すべてが継承するフィー
ルドのグループが含まれています。上位型が存在しないと、その副型を作成できま
せん。次の例では、8-4 ページの 図 8-1 の型階層の上位型 person_t を作成します。
CREATE ROW TYPE person_t
(
name
VARCHAR(30) NOT NULL,
address VARCHAR(20),
city
VARCHAR(20),
state
CHAR(2),
zip
INTEGER,
bdate
DATE
);
副型を作成するには、キーワード UNDER と、その副型がプロパティを継承する上
位型の名前を指定します。次の例では、person_t のフィールドすべてを継承する副
型として employee_t を定義する方法を示します。この例では、person_t 型に存在
しないフィールド salary と manager を追加します。
CREATE ROW TYPE employee_t
(
salary INTEGER,
manager VARCHAR(30)
)
UNDER person_t;
8-4
Informix Guide to Database Design and Implementation
型階層の定義
重要 : 上位型のプロパティを継承する副型を作成するには、その上位型に対する
UNDER アクセス権を持っている必要があります。UNDER アクセス権については、
第 11 章を参照してください。
8-4 ページの 図 8-1 の型階層では、sales_rep_t は employee_t の副型です。person_t
が employee_t の上位型であるのと同様に、employee_t は sales_rep_t の上位型で
す。次の例では sales_rep_t を作成します。sales_rep_t は、person_t と employee_t
のフィールドすべてを継承し、さらに 4 つの新しいフィールドを追加します。副型
を修正してもその上位型には影響しないため、sales_rep_t に追加された 4 つの
フィールドは employee_t にはありません。
CREATE ROW TYPE sales_rep_t
(
rep_num
INT8,
region_num INTEGER,
commission DECIMAL,
home_office BOOLEAN
)
UNDER employee_t;
sales_rep_t 型には、次の 12 のフィールドがあります。name、address、city、
state、zip、bdate、salary、manager、rep_num、region_num、commission、およ
び home_office です。
employee_t 型と sales_rep_t 型のインスタンスは共に、person_t 型に定義されてい
る UDR すべてを継承します。employee_t に定義される追加の UDR はすべて
employee_t 型のインスタンスと、その副型である sales_rep_t のインスタンスに自
動的に適用されますが、person_t のインスタンスには適用されません。
Dynamic Server による型継承と表継承
8-5
型階層の定義
前述の型階層は、各副型が単一の上位型から継承する単一継承の例でした。図 8-2
に、単一の上位型に対して複数の副型を定義する方法を示します。単一継承では、
1 つしかない上位型から各副型が継承する必要がありますが、定義する型階層の深
さと幅にはほとんど制限がありません。
図 8-2
ツリー構造体の型階層の例
person_t
employee_t
sales_rep_t
.
.
.
customer_t
engineer_t
.
.
.
us_customer_t
local_customers_t
.
.
.
non_us_customer_t
regional_customers_t
.
.
.
すべての階層において、最上位にある型を最上位型と呼びます。図 8-2 では、
person_t がこの階層の最上位型です。最上位型を除く階層内のすべての型が、同時
に上位型にも副型にもなる可能性があります。たとえば、customer_t は person_t の
副型で us_customer_t の上位型です。階層の下位にある型には最上位型のプロパ
ティが含まれますが、最上位型から直接プロパティを継承するわけではありませ
ん。たとえば、us_customer_t の上位型は customer_t の 1 つだけですが、
customer_t 自体が person_t の副型であるため、customer_t が person_t から継承す
るフィールドとルーチンは、us_customer_t にも継承されます。
8-6
Informix Guide to Database Design and Implementation
型階層内の型に対するルーチンのオーバーロード
型階層内の型に対するルーチンのオーバーロード
ルーチン オーバーロードとは、1 つの名前を複数のルーチンに割り当てて、それら
のルーチンが操作できる異なる型の引数を指定する機能のことです。型階層では、
副型はその上位型に定義されているルーチンを自動的に継承します。ただし、新し
いルーチンを副型に定義して、継承されたルーチンを同じ名前で上書きすることが
できます。たとえば、型 person_t のインスタンスの姓と誕生日を戻す getinfo()
ルーチンを型 person_t に対して作成します。employee_t のインスタンスの姓と給
与を戻す、別の getinfo() ルーチンを型 employee_t に対して登録できます。このよ
うに、図 8-3 に示すように、ルーチンをオーバーロードして、型階層内の各型に対
し、ルーチンをカスタマイズすることができます。
図 8-3
型階層内のルーチン オーバーロードの例
person_t
getinfo()
employee_t
getinfo()
sales_rep_t
getinfo()
ルーチンをオーバーロードすると、型階層内のさまざまな型に対して同じ名前でも
引数が異なるルーチンが複数定義されます。その場合、指定する引数によって、実
行されるルーチンが決定します。たとえば、型 enployee_t の引数を指定して
getinfo() を呼び出すと、型 employee_t に定義されている get_info() ルーチンが、同
じ名前を持つ、継承されたルーチンを無効にします。同様に、型 sales_rep_t に別の
getinfo() を定義した場合、型 seles_rep_t の引数を指定して getinfo() を呼び出すと、
sales_rep_t が employee_t から継承したルーチンが無効になります。
UDR (User-defined Routines : ユーザ定義ルーチン ) を作成して登録する方法につい
ては、
『Extending Informix Dynamic Server 2000』を参照してください。
Dynamic Server による型継承と表継承
8-7
継承と型代用性
継承と型代用性
型階層では、副型はその上位型に定義されているルーチンすべてを自動的に継承し
ます。したがって、副型の引数を指定してルーチンを呼び出し、その副型にルーチ
ンが定義されていない場合、データベース サーバは上位型に定義されているルーチ
ンを起動できます。型代用性とは、上位型のインスタンスが予期される場合に副型
のインスタンスを使用する機能のことです。たとえば、型 person_t の引数を取り、
型 person_t のインスタンスの姓と誕生日を戻すルーチン p_info() を作成するとしま
す。ほかの p_info() ルーチンが登録されていないときに型 employee_t の引数を指
定して p_info() を起動すると、この p_info() ルーチンは、person_t から継承される、
型 employee_t のインスタンスの姓と誕生日のフィールドを戻します。この動作は、
employee_t が上位型 person_t から関数を継承するために可能になります。
通常、データベース サーバは、ルーチンの評価を行う場合、ルーチンの起動時に指
定されたルーチン名と引数に一致するシグネチャを検索します。そのようなルーチ
ンが見つかると、データベース サーバはそのルーチンを使用します。正確に一致す
るルーチンが見つからない場合、データベース サーバは、同じ名前を持ち、そして
起動時に指定された引数の上位型である型の引数を持つルーチンを検索します。8-9
ページの 図 8-4 に、副型 sales_rep_t の引数を使用して get() ルーチンが呼び出され
たときに、データベース サーバが使用できるルーチンを検索するプロセスを示しま
す。型 sales_rep_t には get() ルーチンが定義されていませんが、データベース サー
バは、階層内のより上位の型に定義されている get() ルーチンを見つけるまで検索
します。この場合、sales_rep_t にもその上位型 employee_t にも get() ルーチンは定
義されていません。しかし person_t にルーチンが定義されているため、このルーチ
ンが起動されて sales_rep_t のインスタンス上で動作します。
8-8
Informix Guide to Database Design and Implementation
型階層からの名前付き行 (ROW) 型の削除
図 8-4
データベース サーバによる型階層内のルーチンの検索の例
person_t
get()
employee_t
sales_rep_t
データベース サーバが使用できるルーチンを検索するプロセスをルーチン分析と呼
びます。ルーチン分析の詳細については、
『Extending Informix Dynamic
Server 2000』を参照してください。
型階層からの名前付き行 (ROW) 型の削除
型階層から名前付き行 (ROW) 型を削除するには、DROP ROW TYPE 文を使用しま
す。ただし、依存性のない型しか削除できません。次の条件のどちらかにあてはま
る場合、名前付き行 (ROW) 型は削除できません。
■
現在、表に割り当てられている
■
別の型の上位型になっている
次の例では、型 sales_rep_t を削除する方法を示します。
DROP ROW TYPE games_t restrict;
上位型を削除するには、まず、その上位型からプロパティを継承する副型をそれぞ
れ削除する必要があります。作成したときと逆の順序で、型階層内の型を削除しま
す。たとえば、図 8-4 の型 person_t を削除するには、まず、次の順序で person_t の
副型を削除する必要があります。
DROP ROW TYPE sale_rep_t restrict;
DROP ROW TYPE employee_t restrict;
DROP ROW TYPE person_t restrict;
重要 : 型を削除するには、データベース管理者、またはその型の所有者である必要
があります。
Dynamic Server による型継承と表継承
8-9
表継承
表継承
名前付き行 (ROW) 型に定義されている表しか、表継承をサポートしていません。
表継承とは、ある表が表階層でその表の上位にある上位表から動作 ( 制約、格納オ
プション、トリガ ) を継承できるようにするプロパティです。表階層とは、表の間
に定義できる関係のことで、それにより副表が上位表の動作を継承します。表継承
には、次の利点があります。
■
データ モデルのモジュール実装が容易になります。
■
スキーマ コンポーネントを一貫して再使用できるようになります。
■
表階層内の表のいくつかまたはすべてを範囲に持つ問合せを作成できるよ
うになります。
表階層では、副表は、次のプロパティをその上位表から自動的に継承します。
■
すべての制約定義 ( 主キー制約、一意性制約、および参照制約 )
■
格納オプション
■
すべてのトリガ
■
インデックス
■
アクセス方法
重要 : 型付き表は行 ID をサポートしません。したがって、型階層内に表を作成す
る場合は、WITH ROWID 節や ADD ROWID 節を指定できません。
8-10
Informix Guide to Database Design and Implementation
型階層と表階層との関係
型階層と表階層との関係
表階層内の表はすべて、対応する型階層内の名前付き行 (ROW) 型に割り当てられ
ている必要があります。図 8-5 に、型階層と表階層の関係の例を示します。
図 8-5
型階層と表階層の関係の例
型階層
表階層
person_t
person
employee_t
employee
sales_rep_t
sales_rep
Dynamic Server による型継承と表継承
8-11
表階層の定義
名前付き行 (ROW) 型が、表階層内の表と必ずしも 1 対 1 の関係を持たない型階層を
定義することもできます。図 8-6 に、一部の名前付き行 (ROW) 型だけを表に割り当
てる型階層の作成方法を示します。
図 8-6
一部の名前付き行 (ROW) 型だけを表に割り当てる継承階層構造の例
型階層
表階層
person_t
customer_t
retail_customer_t
retail_customer
whlsale_customer_t
whlsale_customer
表階層の定義
表を定義するために使用する型は、表を作成する前に存在している必要がありま
す。同様に、型階層を定義してからでなければ、対応する表階層を定義することは
できません。表階層内の特定の副表と上位表との間の関係を確立するには、キー
ワード UNDER を使用します。次の CREATE TABLE 文は、8-11 ページの 図 8-5 の
単純な表階層を定義します。この節の例では、型 person_t、employee_t、および
sales_rep_t が既に存在することを前提にしています。
CREATE TABLE person OF TYPE person_t;
CREATE TABLE employee OF TYPE employee_t
UNDER person;
CREATE TABLE sales_rep OF TYPE sales_rep_t
UNDER employee;
8-12
Informix Guide to Database Design and Implementation
表階層内の表の動作の継承
表 person、employee、および sales_rep がそれぞれ、型 person_t、employee_t、お
よび sales_rep_t に対して定義されます。このように、型階層内の型すべてに対し
て、対応する表が表階層内に存在します。さらに、表階層の表どうしの間の関係
が、型階層の型どうしの関係と一致している必要があります。たとえば、表 person
から表 employee への継承は、型 person_t から型 employee_t への継承と同様に、
表 employee から表 sales_rep への継承は、型 employee_t から型 sales_rep_t への継
承と同様に行われる必要があります。
副表は、上位表に追加された継承可能なプロパティすべてを自動的に継承します。
したがって、上位表のプロパティは常に追加および変更が可能で、副表はそれらの
変更を自動的に継承します。詳細は、8-15 ページの「型階層内の表の動作の修正」
を参照してください。
重要 : 上位表のプロパティを継承する副表を作成するには、その上位表に対する
UNDER アクセス権を持っている必要があります。詳細は、6-10 ページの「型付き
表に対する Under アクセス権」を参照してください。
表階層内の表の動作の継承
ある上位表の副表を作成すると、その副表は、次のプロパティを含む上位表のプロ
パティすべてを継承します。
■
上位表のすべての列
■
制約定義
■
格納オプション
■
インデックス
■
参照整合性
■
トリガ
■
アクセス方法
Dynamic Server による型継承と表継承
8-13
表階層内の表の動作の継承
さらに、表 c が表 b から継承を行い、表 b が表 a から継承を行う場合、表 c は、表
b に一意の動作、および表 b が表 a から継承した動作を自動的に継承します。した
がって、実際に動作を定義する上位表は、その動作を継承する副表から、いくつか
のレベルを隔てたところに存在している可能性があります。たとえば、次の表階層
を例にとります。
CREATE TABLE person OF TYPE person_t
(PRIMARY KEY (name))
FRAGMENT BY EXPRESSION
name < 'n' IN dbspace1,
name >= 'n' IN dbspace2;
CREATE TABLE employee OF TYPE employee_t
(CHECK(salary > 34000))
UNDER person;
CREATE TABLE sales_rep OF TYPE sales_rep_t
LOCK MODE ROW
UNDER employee;
この表階層では、表 employee と表 sales_rep が表 person の主キー名とフラグメン
テーション ストラテジを継承します。表 sales_rep は表 employee のチェック制約を
継承して、LOCK MODE を追加します。次の表に、階層内の各表の動作を示しま
す。
8-14
表
表の動作
person
PRIMARY KEY、FRAGMENT BY EXPRESSION
employee
PRIMARY KEY、FRAGMENT BY EXPRESSION、CHECK 制約
sales_rep
PRIMARY KEY、FRAGMENT BY EXPRESSION、CHECK 制約、
LOCK MODE ROW
Informix Guide to Database Design and Implementation
型階層内の表の動作の修正
また、表階層には、ある 1 つの副表に定義する動作で、上位表から継承した異なる
動作を無効にできるような副表が含まれることがあります。次の表階層を例にとり
ます。この表階層は、表 employee で新しい格納オプションが追加されたことを除
いては、前の例で使用したものと同じです。
CREATE TABLE person OF TYPE person_t
(PRIMARY KEY (name))
FRAGMENT BY EXPRESSION
name < 'n' IN person1,
name>= 'n' IN person2;
CREATE TABLE employee OF TYPE employee_t
(CHECK(salary > 34000))
FRAGMENT BY EXPRESSION
name < 'n' IN employ1,
name>= 'n' IN employ2
UNDER person;
CREATE TABLE sales_rep OF TYPE sales_rep_t
LOCK MODE ROW
UNDER employee;
ここでも、表 employee と表 sales_rep が、表 person の主キー名を継承します。た
だし、表 employee のフラグメンテーション ストラテジが表 person のフラグメン
テーション ストラテジを無効にします。したがって、表 employee と表 sales_rep は
共に、DB 領域 employ1 と employ2 にデータを格納し、表 person は DB 領域
person1 と person2 にデータを格納します。
型階層内の表の動作の修正
いったん表階層を定義すると、既存の表の構造 ( 列 ) は修正できません。ただし、
階層内の表の動作を修正することはできます。8-16 ページの 図 8-7 に、表階層内で
修正できる表の動作と、その修正に使用する構文を示します。
Dynamic Server による型継承と表継承
8-15
型階層内の表の動作の修正
図 8-7
表階層内で修正できる表の動作
表の動作
構文
注意事項
制約定義
ALTER TABLE
制約の追加または削除を行うには、ADD CONSTRAINT 節
または DROP CONSTRAINT 節を使用します。詳細は、
8-16 ページの「表階層内の表に対する制約」を参照してく
ださい。
インデックス
CREATE
INDEX、ALTER
INDEX
詳細については、8-17 ページの「表階層内の表へのイン
デックスの追加」および『Informix Guide to SQL: Syntax』
の CREATE INDEX 文と ALTER INDEX 文の説明を参照し
てください。
トリガ
CREATE/DROP
TRIGGER
継承されたトリガを削除することはできません。ただし、
上位表からトリガを削除したり、副表にトリガを追加して
継承されたトリガを無効にしたりすることはできます。上
位表や副表のトリガを修正する方法については、8-17 ペー
ジの「表階層内の表のトリガ」を参照してください。トリ
ガを作成する方法については、『Informix Guide to SQL:
Tutorial』を参照してください。
階層内の上位表を修正すると、既存の副表はすべて新しい表の動作を自動的に継承
します。
重要 : ALTER TABLE 文を使用して表階層内の表を修正する場合は、ADD
CONSTRAINT 節、DROP CONSTRAINT 節、MODIFY NEXT SIZE 節、および
LOCK MODE 節しか使用できません。
表階層内の表に対する制約
制約の変更または削除は、その制約が定義されている表でしか実行することができ
ません。継承された制約については、副表から削除も変更もできません。ただし、
副表で新しい制約を追加することはできます。また、ある表に追加制約を定義する
と、その制約を定義した表から継承を行う副表によって、その追加制約が継承され
ます。制約は加算的であるため、継承された制約のすべて、および現在の ( 追加さ
れた ) 制約のすべてが適用されます。
8-16
Informix Guide to Database Design and Implementation
型階層内の表の動作の修正
表階層内の表へのインデックスの追加
階層内の上位表にインデックスを定義すると、その上位表の下位に定義するすべて
の副表もまた、そのインデックスを継承します。表 tab_a、tab_b、tab_c を含む表
階層において、tab_a が tab_b の上位表で、tab_b が tab_c の上位表になっている場
合を想定します。tab_b の列にインデックスを作成すると、そのインデックスは
tab_b と tab_c 両方の該当する列に作成されることになります。tab_a の列にイン
デックスを作成すると、そのインデックスは tab_a、tab_b、および tab_c に存在す
ることになります。
重要 : 副表が上位表から継承するインデックスに対しては、削除も修正も行うこと
ができません。ただし、副表にインデックスを追加することはできます。
インデックス、一意性制約、および主キーはすべて密接に関連しています。一意性
制約または主キーを指定すると、データベース サーバはその列に一意性インデック
スを自動的に作成します。したがって、上位表に定義した主キーや一意性制約は、
副表すべてに適用されます。たとえば、上位表と副表 1 つずつ、計 2 つの表があり、
両方の表に列 emp_id がある場合を想定します。emp_id に一意性制約を持たせるよ
う上位表が指定している場合、副表には、副表と上位表の両方にわたって一意であ
る emp_id 値が含まれる必要があります。
重要 : ある表階層内のいくつかの表が主キーを継承しない場合でも、同一の表階層
内で複数の主キーを定義することはできません。
表階層内の表のトリガ
継承されたトリガは削除できません。ただし、副表上にトリガを作成して、その副
表が上位表から継承するトリガを無効にすることはできます。制約とは異なり、ト
リガは非加算的であるため、階層内の上位表の最も近いトリガだけが適用されま
す。
副表が上位表から継承したトリガを無効にする場合、空のトリガをその副表に作成
すると上位表からのトリガを無効にできます。トリガは非加算的であるため、この
空のトリガはこの副表、およびその下位の副表すべてに対して実行されます。これ
らのトリガまでが無効にされることはありません。
Dynamic Server による型継承と表継承
8-17
表階層内のシリアル (SERIAL) 型
表階層内のシリアル (SERIAL) 型
表階層では、シリアル (SERIAL) 型列と 8 バイト シリアル (SERIAL8) 型列を使用で
きます。ただし、1 つの表階層では、シリアル (SERIAL) 型列と 8 バイト シリアル
(SERIAL8) 型列を 1 つずつしか使用できません。たとえば、次の型階層と表階層を
作成します。
CREATE ROW TYPE parent_t (a INT)
CREATE ROW TYPE child1_t (s_col SERIAL) UNDER parent_t
CREATE ROW TYPE child2_t (s8_col SERIAL8) UNDER child1_t
CREATE ROW TYPE child3_t (d FLOAT) UNDER child2_t
CREATE TABLE parent_tab of type parent_t
CREATE TABLE child1_tab of type child1_t UNDER parent_tab
CREATE TABLE child2_tab of type child2_t UNDER child1_tab
CREATE TABLE child3_tab of type child3_t UNDER child2_tab
表 parent_tab には、シリアル (SERIAL) 型は含まれません。表 child1_tab がこの階
層内でシリアル (SERIAL) 型カウンタを初めて使用します。表 child2_tab はシリア
ル (SERIAL) 型列を child1_tab から継承して、8 バイト シリアル (SERIAL8) 型列を
追加します。表 child3_tab は、シリアル (SERIAL) 型列と 8 バイト シリアル
(SERIAL8) 型列の両方を継承します。
階層内の任意の表の列 s_col または列 s8_col に挿入された値 0 は、単調に増加する
値を挿入します。この場合、どの表が挿入を受け取ったのかは関係ありません。
CREATE ROW TYPE 文でシリアル (SERIAL) 型または 8 バイト シリアル (SERIAL8)
型の開始カウンタ値を設定することはできません。表階層内のシリアル (SERIAL)
型列または 8 バイト シリアル (SERIAL8) 型列の開始値を設定するには、ALTER
TABLE 文を使用します。次の文は、表を修正して、表階層内の任意の場所に挿入
される次のシリアル (SERIAL) 型値および 8 バイト シリアル (SERIAL8) 型値を変更
する方法を示します。
ALTER TABLE child3_tab
MODIFY (s_col SERIAL(100), s8_col SERIAL8 (200))
前述した動作を除けば、型なし表のシリアル (SERIAL) 型列に適用される規則はす
べて、その表階層内のシリアル (SERIAL) 型列にも適用されます。シリアル
、および『Informix
(SERIAL) 型の詳細については、第 3 章「データ型の選択」
Guide to SQL: Reference』を参照してください。
8-18
Informix Guide to Database Design and Implementation
表階層への表の追加
表階層への表の追加
表階層を定義した後で、ALTER TABLE 文を使用してその階層内の表の列を追加、
削除、または修正することはできません。ただし、既存の継承関係が侵害されない
場合に限り、新しい副型と副表を既存の階層に追加できます。図 8-8 に、型と、そ
の型に対応する表を既存の階層に追加する方法の 1 例を示します。破線は、追加さ
れた副型と副表を示します。
図 8-8
既存の継承階層に副型と副表を追加する方法の例
型階層
表階層
person_t
person
employee_t
employee
sales_rep_t
sales_rep
us_sales_rep_t
us_sales_rep
次の文は、図 8-8 の継承階層に型と表を追加する方法を示します。
CREATE ROW TYPE us_sales_rep_t
(
domestic_sales DECIMAL(15,2)
)
UNDER employee_t;
CREATE TABLE us_sales_rep OF TYPE us_sales_rep_t
UNDER sales_rep;
Dynamic Server による型継承と表継承
8-19
表階層内の表の削除
また、既存の上位型およびそれに並列する上位表から分岐する副型と副表を追加す
ることもできます。図 8-9 に、型 customer_t と表 customer を既存の階層に追加す
る方法を示します。この例では、表 customer と表 employee の両方が表 person か
らプロパティを継承します。
図 8-9
既存の上位型と上位表の下位に型と表を追加する方法の例
customer_t
型階層
表階層
person_t
person
employee_t
employee
sales_rep_t
sales_rep
customer
次の文は、型 customer_t と表 customer をそれぞれ型 person_t と表 person の下位
に作成します。
CREATE ROW TYPE customer_t
(
cust_num
INTEGER
)
UNDER person_t;
CREATE TABLE customer OF TYPE customer_t
UNDER person;
表階層内の表の削除
ある表と、その表に対応する名前付き行 (ROW) 型に依存性がない場合、つまり上
位表および上位型となっていない場合は、それらの表と型を削除することができま
す。表を先に削除してからでないと型を削除できません。表の削除方法について
は、
『Informix Guide to SQL: Syntax』の DROP TABLE 文を参照してください。名
前付き行 (ROW) 型の削除方法については、7-22 ページの「名前付き行 (ROW) 型の
削除」を参照してください。
8-20
Informix Guide to Database Design and Implementation
表階層内の表の構造の変更
表階層内の表の構造の変更
ALTER TABLE 文を使用して、表階層内の表の列を追加、削除、または修正するこ
とはできません。ALTER TABLE 文を使用して制約を追加、削除、または修正する
ことはできますが、次に示す ALTER TABLE 文の節は、型付き表では不許可になっ
ています。
■
ADD、DROP、MODIFY の各節
■
ADD ROWID、DROP ROWID の各節
上記の制約があるために、表階層内の表の列を追加、削除、修正したり、そのほか
の方法で表の構造を変更したりする処理には、時間がかかる場合があります。
表階層内の表の構造を変更するには
1.
修正するすべての副表と上位表からデータをダウンロードします。
2.
副表と副型を削除します。
3.
アンロードされたデータ ファイルを修正します。
4.
上位表を修正します。
5.
副型と副表を再作成します。
6.
データをアップロードします。
表階層内の表の問合せ
表階層を使用すると、上位表とその副表を範囲とする SELECT 文、UPDATE 文、
または DELETE 文を 1 つの SQL コマンドで構築できます。たとえば、表階層内の
任意の上位表に対する問合せは、その上位表の列すべてのデータ、およびその上位
表から副表が継承する列すべてのデータを戻します。問合せ結果を表階層内の表 1
つに制限するには、キーワード ONLY を問合せに含める必要があります。表階層内
の表のデータを問い合わせて修正する方法の詳細については、
『Informix Guide to
SQL: Tutorial』を参照してください。
表階層内の表のビューの作成
ビューは、表階層内のどの表に基づいても作成できます。たとえば、次の文は、
8-11 ページの 図 8-5 で示す表階層の最上位表 person のビューを作成します。
CREATE VIEW name_view AS
SELECT name FROM person
Dynamic Server による型継承と表継承
8-21
表階層内の表のビューの作成
表 person が上位表であるため、ビュー name_view には、表 person、employee、
および sales_rep の列 name からのデータが表示されます。表 person からのデータ
だけを表示するビューを作成するには、次の例に従って、キーワード ONLY を使用
します。
CREATE VIEW name_view AS
SELECT name FROM ONLY(person)
重要 : 上位表に定義されているビューに対して挿入や更新を実行することはできま
せん。データベース サーバが、表階層内のどこに新しい行を挿入するか判断できな
いためです。
型付きビューの作成方法については、6-25 ページの「型付きビュー」を参照してく
ださい。
8-22
Informix Guide to Database Design and Implementation
第9章
Dynamic Server でのユーザ定
義キャストの作成と使用
この章の概要 . .
.
. .
.
. .
. .
.
. .
.
. .
. .
.
. .
.
. .
9-3
キャストとは . . . . . . . . . . . . . . . . . . . . . . . .
ユーザ定義キャストの作成 . . . . . . . . . . . . . . . . . .
キャストの起動 . . . . . . . . . . . . . . . . . . . . . .
ユーザ定義キャストに関する制限 . . . . . . . . . . . . . . .
9-3
9-4
9-5
9-5
行 (ROW) 型のキャスト . . . . . . . . . . . . . . .
名前付き行 (ROW) 型と名前なし行 (ROW) 型の間のキャスト
名前なし行 (ROW) 型どうしのキャスト . . . . . . . .
名前付き行 (ROW) 型どうしのキャスト . . . . . . . .
フィールドの明示的キャストが必要な行 (ROW) 型変換 . . .
名前なし行 (ROW) 型のフィールドの明示的キャスト . .
名前付き行 (ROW) 型のフィールドの明示的キャスト . .
行 (ROW) 型の各フィールドのキャスト . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9-6
9-7
9-8
9-8
9-9
9-9
9-10
9-10
コレクション (COLLECTION) 型のキャスト . . . . . .
コレクション (COLLECTION) 型の変換の制限 . . . .
要素型が異なるコレクションの変換 . . . . . . .
要素型の変換に暗黙的キャストを行う場合 . . . .
要素型の変換に明示的キャストが必要な場合 . . .
リレーショナル データから マルチセット (MULTISET) 型
コレクションへの変換 . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9-11
9-12
9-12
9-13
9-13
.
.
. .
.
. .
9-13
ディスティンクト型のキャスト . . . . . . . .
ディスティンクト型での明示的キャストの使用
ディスティンクト型とソース型の間のキャスト
ディスティンクト型のキャストの追加と削除
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9-14
9-14
9-15
9-16
. .
.
. .
.
. .
9-17
ユーザ定義キャストのキャスト関数の作成 . . . . . . . . . . . . . .
名前付き行 (ROW) 型間でのキャストの例 . . . . . . . . . . . .
ディスティンクト型間でのキャストの例 . . . . . . . . . . . . .
マルチレベル キャスト . . . . . . . . . . . . . . . . . . .
9-18
9-18
9-19
9-21
スマート ラージ オブジェクトへのキャスト
. .
.
.
.
.
.
.
.
.
.
. .
.
.
.
.
9-2
Informix Guide to Database Design and Implementation
IDS
この章の概要
この章では、ユーザ定義キャストについて説明し、実行時キャストを使用して拡張
データ型のデータ変換を実行する方法を説明します。次のトピックについて説明し
ます。
■
キャストとは
■
行 (ROW) 型のキャスト
■
コレクション (COLLECTION) 型のキャスト
■
ディスティンクト型のキャスト
■
スマート ラージ オブジェクトへのキャスト
■
ユーザ定義キャストのキャスト関数の作成
キャストとは
キャストは、あるデータ型の値を別のデータ型に変換するメカニズムです。キャス
トにより、異なるデータ型の値を比較したり、あるデータ型の値を別のデータ型の
値と置き換えたりすることができます。キャストは、次の種類の式でサポートされ
ます。
■
列式
■
定数式
■
関数式
■
SPL (Stored Procedure Language : ストアド プロシジャ言語 ) 変数
■
ホスト変数 (ESQL)
■
文の局所変数 (SLV : Statement Local Variable) 式
あるデータ型の値を別のデータ型に変換するには、データベースまたはデータベー
ス サーバにキャストが必要です。Dynamic Server では、次の種類のキャストをサ
ポートします。
Dynamic Server でのユーザ定義キャストの作成と使用
9-3
ユーザ定義キャストの作成
■
組込みキャスト
組込みキャストは、データベース サーバに組み込まれているキャストで
す。組込みキャストは、異なる組込みデータ型間の変換を自動的に実行し
ます。システム定義キャストは、すべての Informix データベース サーバ
でサポートされます。組込みキャストについては、
『Informix Guide to
SQL: Reference』を参照してください。
■
ユーザ定義キャスト
ユーザ定義キャストは、ユーザが CREATE CAST 文で作成するキャストで
す。ユーザ定義キャストは、多くの場合、あるデータ型から別のデータ型
への変換を処理するキャスト関数を必要とします。ユーザ定義キャストを
登録し、使用するには、CREATE CAST 文を使用する必要があります。
❑
ユーザ定義の明示的キャスト
CREATE CAST 文でキャストを作成するときに、キーワード
EXPLICIT を含めると、ユーザ定義キャストは明示的になります。デ
フォルトは、明示的です。明示的キャストは、自動的には起動しませ
ん。明示的キャストを起動するには、キーワード CAST...AS、また
は、キャスト演算子である二重コロン (::) を使用する必要があります。
❑
ユーザ定義の暗黙的キャスト
CREATE CAST 文でキャストを作成するときに、キーワード
IMPLICIT を含めると、ユーザ定義キャストは暗黙的になります。
データベース サーバは、実行時に、自動的に暗黙的キャストを起動し
てデータ変換を実行します。
ユーザ定義キャストの作成
2 つのデータ型間の変換を実行する組込みキャストがデータベース サーバで提供さ
れない場合、データ型変換を処理するユーザ定義キャストを作成できます。ユーザ
定義キャストとは、CREATE CAST 文で作成するキャストです。ユーザ定義キャス
トは、一般に、次の拡張データ型のデータ型変換を提供するのに使用します。
■
9-4
不透明 (OPAQUE) 型。不透明 (OPAQUE) 型の開発者は、不透明
(OPAQUE) 型の内部表現および外部表現の変換を処理するキャストを定義
する必要があります。不透明 (OPAQUE) 型のキャストを作成し、登録す
る方法については、
『Extending Informix Dynamic Server 2000』を参照し
てください。
Informix Guide to Database Design and Implementation
キャストの起動
■
ディスティンクト型。ディスティンクト型とソース型を直接比較すること
はできません。しかし、ディスティンクト型からソース型、およびソース
型からディスティンクト型への明示的キャストは Dynamic Server によっ
て自動的に登録されます。ディスティンクト型は、ソース型に定義された
キャストを継承しません。また、ディスティンクト型に定義するユーザ定
義キャストは、ソース型には使用できません。ディスティンクト型のキャ
ストを作成し、使用する方法の詳細と例については、9-18 ページの「ユー
ザ定義キャストのキャスト関数の作成」を参照してください。
■
名前付き行 (ROW) 型。名前付き行 (ROW) 型は、ほとんどの場合、キャス
トを作成することなく別の行 (ROW) 型の値に明示的にキャストすること
ができます。ただし一部のデータ型では、名前付き行 (ROW) 型との間で
値を変換するためには、まず変換を処理するキャストを作成する必要があ
ります。
ユーザ定義キャストを作成し、使用する方法の例については、9-19 ページの「ディ
スティンクト型間でのキャストの例」を参照してください。CREATE CAST 文の構
文については、
『Informix Guide to SQL: Syntax』を参照してください。
キャストの起動
組込みキャスト、およびユーザ定義の暗黙的キャストの場合、データベース サーバ
は自動的に ( 暗黙的に ) データ変換を処理するキャストを起動します。たとえば、
式を明示的にキャストすることなしに、整数 (INT) 型の値を小桁整数 (SMALLINT)
型、実数 (FLOAT) 型、または文字 (CHAR) 型の値と比較することができます。
データベース サーバは、これらの組込みデータ型間の変換を、透過的に処理するシ
ステム定義キャストを提供します。
2 つのデータ型間の変換を処理する明示的なユーザ定義キャストを定義する場合、
キーワード CAST...AS、またはキャスト演算子である二重コロン (::) で、キャスト
を明示的に起動する必要があります。次の部分的な例で、明示的キャストを起動す
る 2 つの方法を示します。
... WHERE new_col = CAST(old_col AS newtype)
... WHERE new_col = old_col::newtype
ユーザ定義キャストに関する制限
2 つの組込みデータ型間のユーザ定義キャストは作成できません。次のデータ型を
1 つでも含むユーザ定義キャストも作成できません。
■
コレクション (COLLECTION) 型
■
名前なし行 (ROW) 型
Dynamic Server でのユーザ定義キャストの作成と使用
9-5
行 (ROW) 型のキャスト
■
BLOB 型
■
CLOB 型
■
テキスト (TEXT) 型
■
バイト (BYTE) 型
一般的に、2 つのデータ型間のキャストでは、それぞれのデータ型のコンポーネン
ト値の個数は一致している必要があります。たとえば、行 (ROW) 型のフィールド
と不透明 (OPAQUE) 型のフィールドが対応していれば、その行 (ROW) 型と不透明
(OPAQUE) 型の間のキャストは可能です。格納構造が同じ 2 つのデータ型間で変換
を実行する場合、キャスト関数なしで CREATE CAST 文が使用できます。そうでな
い場合、キャスト関数を作成し、CREATE CAST 文で登録する必要があります。
キャスト関数を使用してユーザ定義キャストを作成する方法の例については、9-18
ページの「ユーザ定義キャストのキャスト関数の作成」を参照してください。
行 (ROW) 型のキャスト
名前付きと名前なしの 2 つの行 (ROW) 型の値は、両方の行 (ROW) 型のフィールド
の個数が同じで、かつ次の条件のいずれか 1 つに当てはまる場合にのみ、比較また
は置換を行うことができます。
■
2 つの行 (ROW) 型の対応するフィールドがすべて同じデータ型である。
フィールドの個数が同じで、対応するフィールドのデータ型も同じ場合、
その 2 つの行 (ROW) 型は構造的に等価だと見なされます。
■
2 つの名前付き行 (ROW) 型を比較するときに変換を実行する、ユーザ定義
キャストが存在する。
■
データ型が異なる対応フィールドの値に対して必要な変換を実行する、シ
ステム定義のキャスト、またはユーザ定義キャストが存在する。
対応するフィールドが同じデータ型でない場合、システム定義キャストま
たはユーザ定義キャストを使用して、フィールドのデータ変換を処理でき
ます。
各フィールドのデータ変換を処理する組込みキャストがあれば、ある行 (ROW) 型
の値を、ほかの行 (ROW) 型に明示的にキャストできます。ただし、両方の行
(ROW) 型がどちらも名前なし行 (ROW) 型の場合は除きます。この場合、明示的
キャストは必要ありません。
フィールド変換を処理する組込みキャストがない場合、フィールド変換を処理する
ユーザ定義キャストを作成できます。キャストは、暗黙的なものにも、明示的なも
のにもできます。
9-6
Informix Guide to Database Design and Implementation
名前付き行 (ROW) 型と名前なし行 (ROW) 型の間のキャスト
一般的に、行 (ROW) 型を別の行 (ROW) 型にキャストする場合、明示的キャストま
たは暗黙的キャストで、それぞれのフィールド変換を処理します。対応するフィー
ルドの変換に明示的キャストが必要な場合、キャストされたフィールドの値は、対
応するフィールドの値に正確に一致する必要があります。明示的にキャストされた
値に、データベース サーバが追加の暗黙的キャストを適用することはありません。
名前付き行 (ROW) 型と名前なし行 (ROW) 型の間のキャスト
名前付き行 (ROW) 型の値を名前なし行 (ROW) 型の値と比較するには、明示的キャ
ストを使用します。図 9-1 で示す名前付き行 (ROW) 型と表を作成するとします。
図 9-1
CREATE ROW TYPE info_t (x CHAR(1), y CHAR(20))
CREATE TABLE customer (cust_info info_t)
CREATE TABLE retailer (ret_info ROW (a CHAR(1), b CHAR(20)))
INSERT INTO customer2 VALUES(ROW('t','philips')::info_t2)
次の INSERT 文で、表 customer と表 retailer の行 (ROW) 型の値を作成する方法を
示します。
INSERT INTO customer VALUES(ROW('t','philips')::info_t)
INSERT INTO retailer VALUES(ROW('f','johns'))
表 customer のデータを表 retailer のデータと比較または置換するには、一方の行
(ROW) 型の値をもう一方の行 (ROW) 型に変換する明示的キャストを使用する必要
があります。次の問合せで、名前なし行 (ROW) 型の ret_info 列は、名前付き行
(ROW) 型の info_t に明示的にキャストされます。
SELECT cust_info
FROM customer, retailer
WHERE cust_info = ret_info::info_t
一般的に、名前付き行 (ROW) 型と名前なし行 (ROW) 型の間で変換を実行するに
は、一方の行 (ROW) 型をもう一方の行 (ROW) 型に明示的にキャストする必要があ
ります。明示的キャストは、どちらの方向にも実行できます。名前付き行 (ROW)
型を名前なし行 (ROW) 型にキャストすることも、名前なし行 (ROW) 型を名前付き
行 (ROW) 型にキャストすることもできます。次の文は、前の例と同じ結果を戻し
ます。ただし、この例では、名前付き行 (ROW) 型が名前なし行 (ROW) 型に明示的
にキャストされます。
SELECT cust_info
FROM customer, retailer
WHERE cust_info::ROW(a CHAR(1), b CHAR(20)) = ret_info
Dynamic Server でのユーザ定義キャストの作成と使用
9-7
名前なし行 (ROW) 型どうしのキャスト
名前なし行 (ROW) 型どうしのキャスト
構造的に等価な 2 つの名前なし行 (ROW) 型は、明示的キャストを行わなくても比
較できます。両方の行 (ROW) 型のフィールドの個数が同じで、かつデータ型が異
なる対応フィールドの値を変換するキャストが存在する場合も、名前なし行 (ROW)
型と別の名前なし行 (ROW) 型を比較できます。つまり、フィールド変換を処理す
るキャストが、すべてシステム定義キャストまたは暗黙的キャストであれば、ある
名前なし行 (ROW) 型から別の名前なし行 (ROW) 型へのキャストは暗黙的です。そ
うでない場合、名前なし行 (ROW) 型を別の行 (ROW) 型と比較するには、明示的に
キャストする必要があります。
次の表 prices を作成するとします。
CREATE TABLE prices
(
col1
ROW(a SMALLINT, b FLOAT)
col2
ROW(x INT, y REAL)
)
対応するフィールド間の変換を実行する組込みキャストがあれば、2 つの名前なし
行 (ROW) 型の値は明示的キャストなしで比較できます。そのため、次の問合せで
は col1 と col2 の値を比較する明示的キャストは必要ありません。
SELECT *
FROM prices
WHERE col1 = col2
この例では、データベース サーバは暗黙的に組込みキャストを起動し、小桁整数
(SMALLINT) 型のフィールド値を整数 (INT) 型に、小桁実数 (REAL) 型のフィール
ド値を実数 (FLOAT) 型に変換します。
2 つの行 (ROW) 型の対応するフィールドが互いに暗黙的にキャストできない場合、
この 2 つの型の間で変換を処理するユーザ定義キャストがあれば、明示的にキャス
トできます。
名前付き行 (ROW) 型どうしのキャスト
名前付き行 (ROW) 型は、強い型指定です。つまり、2 つの名前付き行 (ROW) 型が
構造的に等価でも、データベース サーバはその 2 つの行 (ROW) 型を別々の型とし
て認識します。そのため、2 つの名前付き行 (ROW) 型間の比較を実行する前に、
ユーザ定義キャストを作成し、登録する必要があります。2 つの名前付き行 (ROW)
型間の変換を処理するキャストを作成し、使用する方法の例については、18 ページ
の「名前付き行 (ROW) 型間でのキャストの例」を参照してください。
9-8
Informix Guide to Database Design and Implementation
フィールドの明示的キャストが必要な行 (ROW) 型変換
フィールドの明示的キャストが必要な行 (ROW) 型変換
フィールドに異なるデータ型を含む、名前付きと名前なしの 2 つの行 (ROW) 型の
間で明示的にキャストをするには、対応するフィールド データ型の変換を処理する
システム定義またはユーザ定義キャストが必要となります。
2 つの行 (ROW) 型の間で明示的にキャストするとき、データベース サーバは
フィールド データ型の変換を処理するのに必要な明示的キャストを自動的に起動し
ます。つまり、行 (ROW) 型値の明示的キャストを実行するとき、行 (ROW) 型の
個々のフィールドを明示的にキャストする必要はありません。ただし、フィールド
のデータ型変換の処理に、複数レベルのキャストが必要な場合は除きます。
このセクションでは、図 9-2 で示す行 (ROW) 型と表を例に使用して、名前付き行
(ROW) 型と名前なし行 (ROW) 型の明示的キャストの動作を示します。
図 9-2
CREATE DISTINCT TYPE d_float AS FLOAT
CREATE ROW TYPE row_t (a INT, b d_float)
CREATE TABLE tab1 (col1 ROW (a INT, b d_float))
CREATE TABLE tab2(col2 ROW (a INT, b FLOAT))
CREATE TABLE tab3 (col3 row_t)
名前なし行 (ROW) 型のフィールドの明示的キャスト
2 つの行 (ROW) 型間の変換に、特定のフィールド値を変換する明示的キャストが含
まれる場合、行 (ROW) 型値は明示的にキャストできますが、個々のフィールドを
明示的にキャストする必要はありません。
次の文で、表 tab1 に値を挿入する方法を示します。
INSERT INTO tab1 VALUES (ROW( 3, 5.66::FLOAT::d_float))
tab1 の col1 の値を tab2 の col2 に挿入するには、行の値を明示的にキャストする必
要があります。データベース サーバは、tab1 の d_float ディスティンクト型と表
tab2 の実数 (FLOAT) 型の変換を、自動的には処理しません。
INSERT INTO tab2
SELECT col1::ROW(a INT, b FLOAT)
FROM tab1
この例で、フィールド b を変換するのに使用するキャストは、明示的です。d_float
から実数 (FLOAT) 型への変換には、明示的キャストが必要です。ディスティンク
ト型をソース型に変換するには、明示的キャストが必要です。
Dynamic Server でのユーザ定義キャストの作成と使用
9-9
行 (ROW) 型の各フィールドのキャスト
一般的に、1 つ以上のフィールドが明示的キャストを使用する 2 つの名前なし行
(ROW) 型の間でキャストをするには、フィールド レベルではなく、行 (ROW) 型レ
ベルで明示的にキャストする必要があります。
名前付き行 (ROW) 型のフィールドの明示的キャスト
ある値を名前付き行 (ROW) 型として明示的にキャストするとき、データベース
サーバは、フィールド値をターゲット データ型に変換するのに使用する暗黙的キャ
ストまたは明示的キャストを自動的に起動します。次の文では、col1 を型 row_t に
明示的にキャストすることにより、実数 (FLOAT) 型のフィールド値を d_float に変
換する明示的キャストが自動的に起動します。
INSERT INTO tab3 SELECT col2::row_t
FROM tab2
次の INSERT 文には、row_t 型への明示的キャストが含まれます。行 (ROW) 型への
明示的キャストにより、型 row_t のフィールド b を実数 (FLOAT) 型から d_float に
変換する明示的キャストも起動します。一般的に、行 (ROW) 型への明示的キャス
トは、行 (ROW) 型に含まれる、深さが 1 レベルのフィールドの明示的キャストも
起動して変換を処理します。
INSERT INTO tab3
VALUES (ROW(5, 6.55::FLOAT)::row_t)
次の文も有効で、前の文と同じ結果を戻します。ただし、この文は値 row_t を表
tab3 に挿入するときに実行される明示的キャストを、すべて示しています。
INSERT INTO tab3
VALUES (ROW(5, 6.55::float::d_float)::row_t)
前の例で、行 (ROW) 型のフィールド b の変換には、2 レベルのキャストが必要で
す。データベース サーバは、小数点を含む値をすべて、10 進数 (DECIMAL) 型とし
て処理します。また、10 進数 (DECIMAL) 型と d_float 型の間には暗黙的キャスト
がありません。そのため、2 レベルのキャストが必要です。1 つめは、10 進数
(DECIMAL) 型から実数 (FLOAT) 型へのキャストで、2 つめは、実数 (FLOAT) 型か
ら d_float へのキャストです。
行 (ROW) 型の各フィールドのキャスト
行 (ROW) 型のフィールドの操作に明示的キャストが必要な場合、フィールドが関
連付けられている行 (ROW) 型に関係なく、個々のフィールド値を明示的にキャス
トできます。次の文は、フィールド値の明示的キャストを使用して変換を処理する
ものです。
SELECT col1 from tab1, tab2
WHERE col1.b = col2.b::FLOAT::d_float
9-10
Informix Guide to Database Design and Implementation
コレクション (COLLECTION) 型のキャスト
行 (ROW) 型のフィールドの操作に暗黙的キャストが必要な場合、適切なフィール
ド値を指定するだけで、データベース サーバが自動的に変換を処理します。次の文
は、異なるデータ型のフィールド値を比較するものです。このとき、組込みキャス
トにより自動的に整数 (INT) 型と実数 (FLOAT) 型の値との間で変換が行われます。
SELECT col1 from tab1, tab2
WHERE col1.a = col2.b
コレクション (COLLECTION) 型のキャスト
明示的キャストを使用して、要素型が異なる 2 つのコレクション (COLLECTION)
型の間で変換を実行できることもあります。2 つのコレクション (COLLECTION) 型
の値を比較または置換するには、両方のコレクション (COLLECTION) 型とも、
セット (SET) 型、マルチセット (MULTISET) 型、またはリスト (LIST) 型のいずれか
となっている必要があります。
■
すべてのコンポーネント型が同じ場合、2 つの要素型は等価です。たとえ
ば、一方のコレクション (COLLECTION) 型の要素型が行 (ROW) 型の場
合、もう一方のコレクション (COLLECTION) 型も、フィールドの数と
データ型が同じである行 (ROW) 型です。
■
データベースには、データ型が異なる要素型の、任意のまたはすべてのコ
ンポーネントの間で変換を実行するキャストが存在します。
対応する要素型のデータ型が異なる場合、Dynamic Server は、組込みキャ
ストまたはユーザ定義キャストを使用して要素型のデータ変換を処理でき
ます。
データベース サーバがコレクション (COLLECTION) 型の値を挿入、更新、または
比較するとき、要素型レベルで型チェックが発生します。そのため、2 つのコレク
ション (COLLECTION) 型間のキャストでは、要素型レベルでデータ変換を実行し
ます。コレクションに格納された実データは、特定の要素型のデータであるためで
す。
図 9-3 で示す型と表を作成するとします。これらの型と表は、後ほど、コレクショ
ンのキャストの例で使用します。
Dynamic Server でのユーザ定義キャストの作成と使用
9-11
コレクション (COLLECTION) 型の変換の制限
図 9-3
CREATE DISTINCT TYPE my_int AS INT
CREATE TABLE set_tab1 (col1 SET(my_int NOT NULL))
CREATE TABLE set_tab2(col2 SET(INT NOT NULL))
CREATE TABLE set_tab3 (col3 SET(FLOAT NOT NULL))
CREATE TABLE list_tab (col4 LIST(INT NOT NULL))
CREATE TABLE m_set_tab(col5 MULTISET(INT NOT NULL))
コレクション (COLLECTION) 型の変換の制限
セット (SET) 型、マルチセット (MULTISET) 型、およびリスト (LIST) 型の各コレク
ション (COLLECTION) 型は、それぞれ異なる特性を持っているため、異なるコレ
クション (COLLECTION) 型間の変換はできません。たとえば、リスト (LIST) 型の
コレクションに格納された要素には、関連付けられた特別な順序があります。リス
ト (LIST) 型のコレクションに挿入した要素をマルチセット (MULTISET) 型のコレク
ションに挿入すると、この順序は失われます。そのため、2 つのコレクションが同
じ要素型であっても、異なるコレクション (COLLECTION) 型の要素を使用したコ
レクションの挿入または更新は、できません。次の INSERT 文はエラーを戻しま
す。挿入を実行しようとする列はマルチセット (MULTISET) 型のコレクションで、
挿入しようとする値はリスト (LIST) 型のコレクションであるためです。
INSERT INTO m_set_tab SELECT col4 FROM list_tab
要素型が異なるコレクションの変換
コレクション (COLLECTION) 型が同じで、要素型が異なる 2 つのコレクション間
で変換を行う方法は、それぞれのコレクションの要素型、および、要素型が異なる
場合にデータベース サーバが一方の要素型をもう一方の要素型に変換するのに使用
するキャストの種類に依存します。
9-12
■
2 つの要素型の変換を処理する、組込みキャストまたは暗黙的なユーザ定
義キャストが存在する場合は、コレクション (COLLECTION) 型の間で明
示的にキャストする必要はありません。
■
要素型の変換を処理する明示的キャストが存在する場合、コレクション
(COLLECTION) 型の明示的キャストを実行できます。
Informix Guide to Database Design and Implementation
リレーショナル データから マルチセット (MULTISET) 型 コレクションへの変換
要素型の変換に暗黙的キャストを行う場合
2 つのコレクションの異なる要素型を変換する暗黙的キャストがデータベースに存
在する場合は、一方のコレクション要素をもう一方のコレクションに挿入または更
新するときに、明示的キャストを行う必要はありません。次の INSERT 文は、表
set_tab2 から要素を抽出し、その要素を表 set_tab3 に挿入します。set_tab2 のコレ
クション列の要素型は整数 (INT) 型で、set_tab3 のコレクション列の要素型は実数
(FLOAT) 型ですが、組込みキャストが整数 (INT) 型と実数 (FLOAT) 型の値の変換
を暗黙的に処理します。この場合、明示的キャストは不要です。
INSERT INTO set_tab3 SELECT col2 FROM set_tab2
要素型の変換に明示的キャストが必要な場合
2 つのコレクションの異なる要素型の変換を明示的キャストで実行する場合、一方
のコレクション (COLLECTION) 型を、もう一方のコレクション (COLLECTION) 型
に明示的にキャストする必要があります。次の例では、整数 (INT) 型 と my_int の
要素型の変換に、明示的キャストが必要です。ディスティンクト型とソース型の
キャストは、常に明示的です。
次の INSERT 文は、表 set_tab2 から要素を抽出し、その要素を表 set_tab1 に挿入す
るものです。set_tab2 のコレクション列の要素型は 整数 (INT) 型で、set_tab1 のコ
レクション列の要素型は my_int です。整数 (INT) 型 と my_int の要素型の変換に明
示的キャストが必要なので、コレクション (COLLECTION) 型を明示的にキャスト
する必要があります。
INSERT INTO set_tab1 SELECT col2::SET(my_int NOT NULL)
FROM set_tab2
コレクション (COLLECTION) 型の明示的キャストを実行するには、コンストラク
タ ( セット (SET) 型、マルチセット (MULTISET) 型、または リスト (LIST) 型 )、要
素型、およびキーワード NOT NULL を含める必要があります。
リレーショナル データから マルチセット (MULTISET) 型
コレクションへの変換
関係表からのデータがある場合、コレクション副問合せを使用して、行の値をマル
チセット (MULTISET) 型のコレクションにキャストできます。次の表を作成すると
します。
CREATE TABLE tab_a ( a_col INTEGER)
CREATE TABLE tab_b (ms_col MULTISET(ROW(a INT) NOT NULL) )
Dynamic Server でのユーザ定義キャストの作成と使用
9-13
ディスティンクト型のキャスト
次の例で、コレクション副問合せを使用して表 tab_a の整数 (INT) 型の値の行をマ
ルチセット (MULTISET) 型のコレクションに変換する方法を示します。tab_a のす
べての行をマルチセット (MULTISET) 型のコレクションに変換し、表 tab_b に挿入
します。
INSERT INTO tab_b VALUES ((MULTISET (SELECT a_col
FROM tab_a)))
ディスティンクト型のキャスト
ディスティンクト型では、ディスティンクト型がソース型として使用する組込み型
の組込みキャストは、一切継承されません。そのため、組込みデータ型をほかの
データ型に暗黙的に変換する組込みキャストを、組込み型をソース型として使用す
るディスティンクト型で利用することはできません。しかし、組込み型のディス
ティンクト型を作成するとき、データベース サーバは、ディスティンクト型から組
込み型への変換、および組込み型からディスティンクト型への変換を処理する 2 つ
の明示的キャストを提供します。
ディスティンクト型での明示的キャストの使用
ディスティンクト型の値とソース型の値を比較または置換するには、一方の型をも
う一方の型に明示的にキャストする必要があります。たとえば、ソース型の値で
ディスティンクト型列の挿入または更新をするには、その値を明示的にディスティ
ンクト型にキャストする必要があります。
整数 (INTEGER) 型を基にしたディスティンクト型 int_type と、型 int_type の列が
ある表を作成するとします。
CREATE DISTINCT TYPE int_type AS INTEGER
CREATE TABLE tab_z(col1 int_type)
表 tab_z に値を挿入するには、次のように、col1 列の値を int_type に明示的にキャ
ストする必要があります。
INSERT INTO tab_z VALUES (35::int_type)
10 進数 (NUMERIC) 型を基にしたディスティンクト型 num_type と、型 num_type
の列がある表を作成するとします。
CREATE DISTINCT TYPE num_type AS NUMERIC
CREATE TABLE tab_x (col1 num_type)
9-14
Informix Guide to Database Design and Implementation
ディスティンクト型とソース型の間のキャスト
ディスティンクト型 num_type は、10 進数 (NUMERIC) 型のシステム定義キャスト
を一切継承しません。そのため、次の挿入には 2 レベルのキャストが必要です。最
初のキャストで、値 35 を整数 (INT) 型から 10 進数 (NUMERIC) 型に変換します。2
番めのキャストで、10 進数 (NUMERIC) 型から num_type に変換します。
INSERT INTO tab_x VALUES (35::NUMERIC::num_type)
次の、表 tab_x に対する INSERT 文はエラーを戻します。整数 (INT) 型から
num_type に直接変換するキャストは存在しません。
INSERT INTO tab_x VALUES (70::num_type)
ディスティンクト型とソース型の間のキャスト
ディスティンクト型のデータ表現はソース型と同じですが、ディスティンクト型を
ソース型と直接比較することはできません。そのため、ディスティンクト型を作成
したときに、Dynamic Server によって次の明示的キャストが自動的に登録されま
す。
■
ディスティンクト型からソース型へのキャスト
■
ソース型からディスティンクト型へのキャスト
2 つのディスティンクト型を作成するとします。1 つは映画のタイトルを処理し、
もう 1 つは音楽録音物のタイトルを処理します。図 9-4 で、可変長文字
(VARCHAR) 型を基にした 2 つのディスティンクト型を作成する方法を示します。
図 9-4
CREATE DISTINCT TYPE movie_type AS VARCHAR(30);
CREATE DISTINCT TYPE music_type AS VARCHAR(30);
図 9-5 では、型 movie_type、music_type、および 可変長文字 (VARCHAR) 型の列
を含む表 entertainment を作成しています。
図 9-5
CREATE TABLE entertainment
(
video
movie_type,
compact_disc
music_type,
laser_disc
VARCHAR(30)
);
Dynamic Server でのユーザ定義キャストの作成と使用
9-15
ディスティンクト型とソース型の間のキャスト
ディスティンクト型とソース型を比較するには、一方のデータ型からもう一方に明
示的キャストを実行する必要があります。たとえば、ビデオとレーザー ディスクの
両方で手に入る映画を調べるとします。次の文は、ディスティンクト型 music_type
の値をソース型である可変長文字 (VARCHAR) 型の値と比較するために、WHERE
節での明示的キャストを必要とします。この例では、ソース型をディスティンクト
型に明示的にキャストします。
SELECT video
FROM entertainment
WHERE video = laser_disc::movie_type
前の例では、ソース型をディスティンクト型に明示的にキャストします。しかし、
次の文で示すように、ディスティンクト型をソース型に明示的にキャストすること
もできます。
SELECT video
FROM entertainment
WHERE video::VARCHAR(30) = laser_disc
同じソース型に定義した 2 つのディスティンクト型の間で変換を実行するには、明
示的キャストを行う必要があります。次の文は、music_type の値を movie_type の
値と比較するために、明示的キャストを必要とします。
SELECT video
FROM entertainment
WHERE video = compact_disc::movie_type
ディスティンクト型のキャストの追加と削除
ディスティンクト型に強い型指定を適用するために、データベース サーバはディス
ティンクト型とソース型の間の変換を処理する明示的キャストを提供します。しか
し、ディスティンクト型の作成者は、既存の明示的キャストを削除して暗黙的キャ
ストを作成できます。これにより、ディスティンクト型とソース型の変換に明示的
キャストが不要になります。
重要 : データベース サーバが提供するディスティンクト型とソース型の間の明示的
キャストを削除して、代わりにこれらのデータ型変換を処理する暗黙的キャストを
作成すると、ディスティンクト型のもつ独自性が損なわれます。
次の DROP CAST 文は、9-15 ページの 図 9-4 で示す movie_type に自動的に定義さ
れた 2 つの明示的キャストを削除するものです。
DROP CAST(movie_type as VARCHAR(30))
DROP CAST(VARCHAR(30) AS movie_type)
9-16
Informix Guide to Database Design and Implementation
スマート ラージ オブジェクトへのキャスト
既存のキャストを削除した後は、movie_type と可変長文字 (VARCHAR) 型の間の
変換を処理する 2 つの暗黙的キャストを作成できます。次の CREATE CAST 文は、
2 つの暗黙的キャストを作成します。
CREATE IMPLICIT CAST (movie_type AS VARCHAR(30))
CREATE IMPLICIT CAST (VARCHAR(30) AS movie_type)
2 つのデータ型間の変換を実行するキャストがデータベースに存在している場合、
そのデータ型間のキャストは作成できません。
ディスティンクト型とソース型の間の変換を実行する暗黙的キャストを作成する
と、この 2 つの型を、明示的キャストを行うことなく比較できます。次の文では、
video 列と laser_disc 列の比較には、変換が必要となります。暗黙的キャストを作
成したので、可変長文字 (VARCHAR) 型 と movie_type の間の変換は暗黙的です。
SELECT video
FROM entertainment
WHERE video = laser_disc
スマート ラージ オブジェクトへのキャスト
データベース サーバは、テキスト (TEXT) 型およびバイト (BYTE) 型のオブジェクト
をそれぞれ、BLOB 型および CLOB 型に変換できるように、次のキャストを提供し
ます。
■
BLOB
■
CLOB
この機能により、従来のデータベースのバイト (BYTE) 型およびテキスト (TEXT) 型
のデータを、BLOB 列および CLOB 列に移行できます。
次の例で、明示的キャストを使用して、stores_demo データベースの表 catalog にあ
るバイト (BYTE) 型列値を BLOB 列値に変換し、superstores_demo データベースの
表 catalog を更新する方法を示します。
UPDATE catalog SET advert = ROW (
(SELECT cat_picture::BLOB from stores_demo:catalog
WHERE catalog_num = 10027), advert.caption)
where catalog_num = 10027
データベース サーバは、BLOB 型をバイト (BYTE) 型の値に変換するキャスト、ま
たは CLOB 型をテキスト (TEXT) 型の値に変換するキャストは提供しません。
Dynamic Server でのユーザ定義キャストの作成と使用
9-17
ユーザ定義キャストのキャスト関数の作成
ユーザ定義キャストのキャスト関数の作成
データベースに、不透明 (OPAQUE) 型、ディスティンクト型、または名前付き行
(ROW) 型が含まれている場合、異なるデータ型間の変換ができるユーザ定義キャス
トを作成する必要が生じることがあります。格納構造が同じ 2 つのデータ型の間で
変換を実行する場合は、キャスト関数なしで CREATE CAST 文を使用できます。し
かし、場合によっては、キャスト関数を作成してからキャストとして登録する必要
があります。次の場合には、キャスト関数を作成する必要があります。
■
格納構造が異なる 2 つのデータ型間の変換
■
データ変換を意味のあるものにするために、値の操作を含む変換
次のセクションでは、キャスト関数を必要とするユーザ定義キャストを作成する方
法を示します。
名前付き行 (ROW) 型間でのキャストの例
図 9-6 で示す、2 つの名前付き行 (ROW) 型と表を作成するとします。名前付き行
(ROW) 型は構造的に等価ですが、writer_t と editor_t は一意なデータ型です。
図 9-6
CREATE ROW TYPE writer_t (name VARCHAR(30), depart CHAR(3)
CREATE ROW TYPE editor_t (name VARCHAR(30), depart CHAR(3))
CREATE TABLE projects
(
book_title VARCHAR(20),
writer writer_t,
editor editor_t
)
2 つの名前付き行 (ROW) 型間の変換を処理するには、まず、ユーザ定義キャストを
作成する必要があります。次の例は、キャスト関数を作成し、型 writer_t から
editor_t への変換を処理するキャストとして登録します。
CREATE FUNCTION cast_rt (w writer_t)
RETURNS editor_t
RETURN (ROW(w.name, w.depart)::editor_t);
END FUNCTION;
CREATE CAST (writer_t as editor_t WITH cast_rt)
9-18
Informix Guide to Database Design and Implementation
ディスティンクト型間でのキャストの例
キャストを作成して登録すると、型 writer_t の値を editor_t に明示的にキャストで
きます。次の問合せは、型 writer_t の値を editor_t に変換するために、WHERE 節
で明示的キャストを使用します。
SELECT book_title
FROM projects
WHERE CAST(writer AS editor_t) = editor
もちろん、キャスト演算子 :: を使用して、同じキャストを実行することもできま
す。これを次の例で示します。
SELECT book_title
FROM projects
WHERE writer::editor_t = editor
ディスティンクト型間でのキャストの例
通貨を表すディスティンクト型、dollar、yen、および sterling を定義するとしま
す。2 つの通貨間の比較には、金額に為替レートをかける必要があります。そのた
め、あるデータ型からほかのデータ型へのキャストを処理するだけではなく、比較
する値の為替レートも計算するキャスト関数を作成する必要があります。
図 9-7 で、同じソース型、実数 (DOUBLE PRECISION) 型を基にした 3 つのディス
ティンクト型を定義する方法を示します。
図 9-7
CREATE DISTINCT TYPE dollar AS DOUBLE PRECISION
CREATE DISTINCT TYPE yen AS DOUBLE PRECISION
CREATE DISTINCT TYPE sterling AS DOUBLE PRECISION
ディスティンクト型を定義した後は、比較可能な製品のメーカー価格を提供する表
を作成できます。図 9-8 では、dollar、yen、および sterling の各ディスティンクト
型列を含む表 manufact_price を作成しています。
図 9-8
CREATE TABLE manufact_price
(
product_desc VARCHAR(20),
us_price dollar,
japan_price yen,
uk_price sterling
)
Dynamic Server でのユーザ定義キャストの作成と使用
9-19
ディスティンクト型間でのキャストの例
表 manufact_price に値を挿入するとき、次のように、dollar、yen、および sterling
の値を適切なディスティンクト型にキャストできます。
INSERT INTO manufact_price
VALUES ('baseball', 5.00::DOUBLE PRECISION::dollar,
510.00::DOUBLE PRECISION::yen,
3.50::DOUBLE PRECISION::sterling)
ディスティンクト型は、ソース型で利用できる組込みキャストを継承しないので、
前の INSERT 文はそれぞれ 2 つのキャストを必要とします。それぞれの INSERT 文
で、内部キャストは 10 進数 (DECIMAL) 型を実数 (DOUBLE PRECISION) 型に変換
し、外部キャストは実数 (DOUBLE PRECISION) 型を適切なディスティンクト型
(dollar、yen、または sterling) に変換します。
dollar 型、yen 型、および sterling 型を比較する前に、キャスト関数を作成し、
キャストとして登録する必要があります。図 9-9 に、dollar と yen の値を比較する
ときに使用する SPL 関数 dollar_to_yen() を作成する方法を示します。為替レートを
考慮し、関数は dollar 値に 106 をかけて、等価な yen 値を導出します。
図 9-9
CREATE FUNCTION dollar_to_yen(d dollar)
RETURNS yen
RETURN (d::DOUBLE PRECISION * 106)::CHAR(20)::yen;
END FUNCTION
図 9-10 では、sterling 値と dollar 値を比較する SPL 関数を作成しています。為替
レートを考慮し、関数は sterling 値に 1.59 をかけて、等価な dollar 値を導出しま
す。
図 9-10
CREATE FUNCTION sterling_to_dollar(s sterling)
RETURNS dollar
RETURN (s::DOUBLE PRECISION * 1.59)::CHAR(20)::dollar;
END FUNCTION
キャスト関数を作成した後、CREATE CAST 文を使用し、関数をキャストとして登
録する必要があります。図 9-11 に、dollar_to_yen() 関数と sterling_to_dollar() 関数
を明示的キャストとして登録する方法を示します。
図 9-11
CREATE CAST(dollar AS yen WITH dollar_to_yen);
CREATE CAST(sterling AS dollar WITH sterling_to_dollar)
関数をキャストとして登録した後は、この関数を、データ型の変換が必要な操作で
使用します。キャスト関数を作成し、キャストとして登録するのに使用する構文に
ついては、
『Informix Guide to SQL: Syntax』の CREATE FUNCTION 文および
CREATE CAST 文を参照してください。
9-20
Informix Guide to Database Design and Implementation
マルチレベル キャスト
次の問合せでは、dollar 値と yen 値を比較するために、dollar_to_yen() 関数を起動
する明示的キャストが WHERE 節に含まれています。
SELECT *
FROM manufact_price
WHERE CAST(us_price AS yen) < japan_price
次の問合せは、キャスト演算子である二重コロン (::) を使用して、前の問合せで示
したものと同じ変換を実行します。
SELECT *
FROM manufact_price
WHERE us_price::yen < japan_price
明示的キャストを使用すると、問合せが戻す値を変換することもできます。次の問
合せは、キャストを使用して、dollar 値と等価な yen 値を戻します。問合せの
WHERE 節も、dollar 値と yen 値を比較するために、明示的キャストを使用します。
SELECT us_price::yen, japan_price
FROM manufact_price
WHERE us_price::yen < japan_price
マルチレベル キャスト
ここまで、キャストの例はすべて単一レベル キャストでした。単一レベル キャス
トとは、単純に、あるデータ型の値をターゲット データ型に変換するために、専用
のキャストを 1 つだけ必要とする操作です。単一レベル キャストは、暗黙的または
明示的のいずれかです。マルチレベル キャストとは、あるデータ型の値をターゲッ
ト データ型に変換するために、1 つの式に複数のレベルのキャストを必要とする操
作のことです。マルチレベル キャストには、暗黙的キャストと明示的キャストの両
方または一方を含めることができます。場合によっては、データベース サーバはい
くつかの組込みキャストを使用して、あるデータ型の値を別のデータ型に暗黙的に
キャストします。または、次の問合せで示すように、2 つのデータ型の間で変換を
する場合に、複数の明示的キャストを使用する必要が生じることもあります。9-19
ページの 図 9-8 で示す yen 値と sterling 値を直接比較するキャストは、存在しない
ので、問合せは 2 つの明示的キャストを必要とします。最初の ( 内部の ) キャスト
は、sterling 値を dollar 値に変換します。2 番めの ( 外部の ) キャストは、dollar 値
を yen 値に変換します。
SELECT *
FROM manufact_price
WHERE japan_price < uk_price::dollar::yen
sterling から yen へのキャストがデータベースに存在しないため、この問合せは
sterling から yen を取得するためには 2 レベルのキャストを必要とします。
Dynamic Server でのユーザ定義キャストの作成と使用
9-21
マルチレベル キャスト
yen から sterling に直接変換する、別のキャスト関数を追加することもできます。
9-22 ページの 図 9-12 に、関数 yen_to_sterling() を作成し、キャストとして登録す
る方法を示します。為替レートを考慮し、関数は yen 値に .01 をかけて、等価な
sterling 値を導出します。
図 9-12
CREATE FUNCTION yen_to_sterling(y yen)
RETURNS sterling
RETURN (y::DOUBLE PRECISION * .01)::CHAR(20)::sterling;
END FUNCTION;
CREATE CAST (yen AS sterling WITH yen_to_sterling)
図 9-12 のキャストを追加すると、次の問合せで示すように、単一レベル キャスト
を使用して yen 値と sterling 値を比較することができます。
SELECT japan_price:sterling, uk_price
FROM manufact_price
WHERE japan_price::sterling) < uk_price
SELECT 文では、明示的キャストが yen 値を等価な sterling 値として戻します。
WHERE 節では、キャストによって yen 値と sterling 値の比較を可能にしています。
9-22
Informix Guide to Database Design and Implementation
次元データ モデルの作成
次元データベースの実装
セクション IV
次元データベース
第 10 章
次元データ モデルの作成
この章の概要 . .
.
. .
.
. .
. .
10-3
データ ウェアハウスの概要 . . . . . . . . . . . . . . . . . . .
次元データベースを作成する理由 . . . . . . . . . . . . . . .
次元データとは . . . . . . . . . . . . . . . . . . . . . .
10-4
10-5
10-6
次元データ モデルのコンセプト
ファクト表 . . . . . .
データ モデルの次元 . . .
次元要素 . . . . . .
次元属性 . . . . . .
次元表 . . . . . .
. .
. .
. .
. .
. .
. .
. .
.
. .
. . .
. . .
. . .
. . .
. . .
. . .
.
. .
. . .
. . .
. . .
. . .
. . .
. . .
次元データ モデルの作成 . . . . . . . . . .
ビジネス プロセスの選択 . . . . . . . .
ビジネス プロセスの要約 . . . . . . . .
ファクト表の細分性の決定 . . . . . . . .
細分性のデータベース サイズへの影響力 .
ビジネスプロセスを使用しての細分性の決定
次元と階層の明確化 . . . . . . . . . .
ファクト表のメジャー ( 基準 ) の選択 . . . .
ファクト表を次元表と結合するキーの使用 .
正規化の阻止 . . . . . . . . . . . .
次元表の属性の選択 . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
. .
.
. .
.
. .
. .
. .
. .
. .
. .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
.
.
.
.
.
.
10-8
10-10
10-11
10-12
10-13
10-14
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
10-14
10-15
10-15
10-17
10-17
10-17
10-18
10-21
10-22
10-23
10-24
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
次元データ モデルの共通する問題の処理 . . . . . . . . . . . . . . 10-26
次元表の属性数を最低限に抑える . . . . . . . . . . . . . . . 10-26
時々変更する次元の処理 . . . . . . . . . . . . . . . . . . 10-28
スノーフレーク スキーマの使用 . . . . . . . . . . . . . . . . 10-29
10-2
Informix Guide to Database Design and Implementation
この章の概要
この章では、次元データ モデルのコンセプトおよびテクニックを紹介し、簡単な次
元データ モデルの作成方法を説明します。第 11 章 では、SQL を使用してこの次元
データ モデルを実装する方法を説明します。この章の内容は、次のとおりです。
■
データ ウェアハウスの概要
■
次元データ モデルのコンセプト
■
次元データ モデルの作成
■
次元データ モデルの一般的な問題の処理
大規模なデータ ウェアハウスについては、次元データ モデルはリレーショナル
データ モデルよりも管理が困難です。このため、データ ウェアハウスでは通常、
リレーショナル データ モデルに基づいています。しかし、次元データ モデルは、
データ ウェアハウスのサブセットであるデータ マートを作成する場合に特に適し
ています。
この章で取り扱う次元データ モデルの一般原則は、Dynamic Server や、Extended
Parallel Server で作成するデータベースに適用されます。どのデータベース サーバ
を使用して次元データベースを作成するかを、単一の要素だけで決定することはで
きません。しかし、大規模なスケーラブル ウェアハウスは Extended Parallel Server
で作成し、小型のウェアハウス、OLTP システム、および運用システムは Dynamic
Server で作成することを想定しています。
次元データ モデルのコンセプトを理解するには、SQL やリレーショナル データ
ベースの理論についての基本的な知識が必要です。この章では、データ ウェアハウ
スのコンセプトを要約し、簡単な次元データ モデルを説明するにすぎませ
ん。Informix では、次元データ モデルのより高度なコンセプトやテクニックを学ぶ
には、この章を読んでから、序 14 ページ「参考文献」に紹介されている書籍を読
まれることをお勧めします。
次元データ モデルの作成
10-3
データ ウェアハウスの概要
データ ウェアハウスの概要
データ ウェアハウスという用語は、最も広い意味では、きわめて多くの履歴データ
を格納しているデータベースのことを指します。データは一連のスナップショット
として格納され、そのスナップショットの各レコードは、ある特定の時点でのデー
タを表わします。このデータ スナップショットで、ユーザが履歴を再作成したり、
何らかの時点と別の時点との間で正確な比較をしたりできます。データ ウェアハウ
スは、ウェアハウスにロードされる前に抽出するデータを統合し、変換します。
データ ウェアハウスの第一の長所は、格納されている膨大な情報に簡単にアクセス
したり、分析したりできることです。
データ ウェアハウスという用語が、人によっては違うことを意味することがあるた
め、このマニュアルでは、データ ウェアハウスとデータ ウェアハウス環境という
包括的な用語を使用して、データを格納するために使用する次のフォーマットをい
います。
■
データ ウェアハウス
データ抽出のために最適化されたデータベースです。データをトランザク
ション レベルで格納するのではなく、あるレベルのデータを要約します。
日常の操作を自動化する従来の OLTP データベースとは違い、データ ウェ
アハウスは長期にわたってエンタープライズ全体のパフォーマンスを評価
できる意思決定支援環境を提供します。通常、リレーショナル データ モ
デルを使用して、データ ウェアハウスを作成します。
■
データ マート
小型のデータベースに格納され、エンタープライズ全体の戦略計画ではな
く特定の目的またはデータ サブジェクトを指向する、データ ウェアハウ
スのサブセットです。データ マートには、操作データ、要約データ、ス
ペーシャル ( 地理空間 ) データ、メタデータを組み込むことができます。
通常、次元データ モデルを使用して、データ マートを作成します。
■
操作データ ストア
意思決定を行うときに 1 度に 1 つまたは 2 つのレコードを参照するように
最適化されたサブジェクト指向のシステムです。操作データ ストアは、タ
イムリーで、現行の統合データを含んでいるハイブリッド形式のデータ
ウェアハウスです。データには通常、トランザクションよりも高いレベル
の細分性があります。操作データは事務的な日常の意思決定に使用できま
す。このデータは、データ ウェアハウスの共通データ ソースとしての役
割を果たすことができます。
10-4
Informix Guide to Database Design and Implementation
次元データベースを作成する理由
■
リポジトリ
リポジトリは、複数のデータ ソースを結合して、1 つの正規化されたデー
タベースにします。リポジトリ内のレコードは、頻繁に更新されます。
データは、履歴データではなく、操作データです。特定のシステム要件に
よっては、特定の意思決定の問合せにリポジトリが使用できます。リポジ
トリは、操作処理用の統合化されたエンタプライズ全体のデータ ソースを
必要とする企業のニーズに適合しています。
次元データベースを作成する理由
リレーショナル データベースは通常、オンライン トランザクション処理 (OLTP :
Online Transaction Processing) 用に最適化されています。OLTP システムは、業務
上の日常的な操作ニーズを満たすように設計され、データベースのパフォーマンス
はそのような操作上のニーズに合わせて調整されます。したがって、リレーショナ
ル データベースでは少数のレコードなら迅速に検索できますが、大量のレコードを
検索し、急いで要約する場合には、速度が遅くなることがあります。OLTP システ
ムにあり得る欠点は、次のとおりです。
■
ビジネス エンタープライズ全体では、データに一貫性がない場合がありま
す。
■
データへのアクセスが複雑になる可能性があります。
これとは対照的に、次元データベースは、ビジネスの動向や予測の分析を支援する
ように設計され、調整されています。この種の情報処理は、オンライン分析型処理
(OLAP :Online Analytical Processing) または意思決定支援処理として知られていま
す。OLAP は、データベース設計者が情報処理への次元的なアプローチのことをい
うときに使用する用語でもあります。
次元データベースは、データ抽出と分析のために最適化されています。データベー
スにロードした新しいデータは通常、多くの場合は複数のソースから、バッチで更
新されます。OLTP システムが、受注入力のような特定の処理を中心にデータを整
理する傾向にあるのに対し、次元データベースはサブジェクト指向の傾向にあり、
「どんな製品が売れ筋か、どんな時期に製品が一番売れるか、どこの地区の販売が
弱いか」といった質問に答えることを目的としています。
次元データ モデルの作成
10-5
次元データとは
次の表に、OLTP データベースと OLAP データベースとの主な違いを要約します。
リレーショナル データベース (OLTP)
次元データベース (OLAP)
データを細分化
データを要約
現行のデータ
履歴データ
1 度に 1 つのレコードを処理
1 度に多数のレコードを処理
処理指向
サブジェクト指向
高構造化反復処理向けに設計
高構造化されていない分析処理向けに
設計
リレーショナル テクノロジによって企業が解決をはかろうとする問題の多くは、元
来、多次元的なものです。たとえば、地域ごとの製品の売上げ、製品ごとの地域の
売上げなどの要約を作成する SQL では、従来のリレーショナル データベースでの
処理に何時間もかかるかもしれません。しかし、次元データベースでは、同じ問合
せが一瞬のうちに処理できます。
次元データとは
従来のリレーショナル データベースは、レコードのリストを中心として整理されて
います。各レコードには、属性 ( フィールド ) に整理された関連情報が組み込まれ
ています。デモンストレーション データベース stores_demo の表 customer はその
代表例であり、名前、会社、住所、電話番号などのフィールドが入っています。こ
の表には複数のフィールドに情報がありますが、表の各行には 1 件の顧客が属して
いるにすぎません。顧客名と、たとえば電話番号のようなほかのフィールドを持つ
2 次元的なマトリックスを作成する場合、1 対 1 の対応しか表現できません。図 10-1
に、1 対 1 の対応だけがあるフィールドを使用した表を示します。
図 10-1
フィールド間に 1 対 1 の対応がある表
10-6
顧客
電話番号 --->
Ludwig Pauli
408-789-8075
----------------
----------------
Carole Sadler
----------------
415-822-1289
----------------
Philip Currie
----------------
----------------
414-328-4543
Informix Guide to Database Design and Implementation
次元データとは
このマトリックスの前記の表 customer からフィールドを任意に組合わせることは
できますが、1 対 1 の対応で常に終わるため、この表には多次元性がなく、次元
データベースには不向きであることがわかります。
そこで、表のフィールド間に 1 対 1 よりも多くの対応が含まれているリレーショナ
ル データベースを考えてみます。国内の各地域の製品売上げについての売上げデー
タを含んだ表を作成するとします。説明を簡単にするために、この会社には 3 種類
の製品があって、3 つの地域で販売しているとします。図 10-2 に、このデータをリ
レーショナル表に格納する方法を示します。
図 10-2
簡単なリレーショナル表
製品
地域
販売数量
サッカーボール
東部
2300
サッカーボール
西部
4000
サッカーボール
中央
5600
テニスラケット
東部
5500
テニスラケット
西部
8000
テニスラケット
中央
2300
野球ボール
東部
10000
野球ボール
西部
22000
野球ボール
中央
34000
10-7 ページの 図 10-2 の表によると、1 地域で複数の製品が販売され、また 1 製品が
複数の地域で販売されています。したがって、この表には多次元的な表現が適して
います。図 10-3 に、製品と地域データの多対多の関係を、よりうまく表現している
2 次元的なマトリックスを示します。
次元データ モデルの作成
10-7
次元データ モデルのコンセプト
製品
図 10-3
簡単な 2 次元的な例
地域
中央
東部
西部
サッカーボール
5600
2300
4000
テニスラケット
2300
5500
8000
野球ボール
34000
10000
22000
このデータを図 10-2 の 3 つのフィールドのあるリレーショナル表にすることはでき
ますが、データは図 10-3 の 2 次元的なマトリックスのほうがより自然です。
従来のリレーショナル表よりも、次元表のほうがパフォーマンスは良くなります。
次元的なアプローチによって、要約したり、比較したりするデータへのアクセスが
簡単になります。たとえば、次元表を使用して、西部で販売されている製品の数を
問い合せる場合は、データベース サーバが列 west を検索し、その列のすべての行
の合計を計算します。リレーショナル表で同じ問合せを実行する場合、データベー
ス サーバは列 region が west になる行を検索、抽出してから、そのデータを集計
します。この種の問合せでは、次元表を使用すると、リレーショナル表が west の
レコードすべてを検索するために要するほんのわずかな間に、列 west のすべての
値を合計できます。
次元データ モデルのコンセプト
次元データベースを作成するには、次元データ モデルから着手します。次元データ
モデルは、データベースを作成するための方法を簡単かつ理解しやすくします。次
元データベースは、どの次元にもアクセスできる、3 次元または 4 次元のデータ
ベース キューブ ( 立方体 ) と考えることができます。次元データベースを作成する
には、データを視覚化するモデルが必要です。
ユーザの業務は異なる市場で製品を販売することであり、時経過のパフォーマンス
を評価するとします。このビジネス プロセスを、時間、製品、および市場という各
次元が含まれているデータのキューブ ( 立方体 ) と考えるのは簡単です。図 10-4
は、この次元モデルを示しています。キューブ ( 立方体 ) の各線に沿ったさまざま
な交差部分には、このビジネスのメジャー ( 基準 ) が含まれています。このメ
ジャー ( 基準 ) は、製品、市場、および時間データという特定の組み合わせに対応
します。
10-8
Informix Guide to Database Design and Implementation
次元データ モデルのコンセプト
図 10-4
時間、製品、および市場の次元のあるビジネスの次元モデル
間
市場
時
製品
次元モデルは、スター結合スキーマともいいます。このモデルのダイアグラムが、
中央に表があり、その周囲にほかの表が配置されていて星のように見えるために、
データベース設計者はこの名前を使用しています。このスキーマによる表は中央の
表だけで、ほかのすべての表は複数結合によって接続されます。この中央の表を
ファクト表といい、ほかの表を次元表といいます。すべての次元表には、次元表と
ファクト表とを結ぶ連結部が、問合せには関係なく、１ つだけあります。図 10-5
に、異なる市場で製品を販売し、時経過による業績を評価するあるビジネスの簡単
な次元モデルを示します。
次元データ モデルの作成
10-9
ファクト表
図 10-5
代表的な次元モデル
時間の次元
time_key
day_of_week
月
四半期
年
holiday_flag
販売ファクト表
製品の次元
time_key
product_key
store_key
dollars_sold
units_sold
dollars_cost
product_key
description
brand
category
店舗の次元
store_key
store_name
address
floor_plan_type
ファクト表
ファクト表は、ビジネスのメジャー ( 基準 ) を格納し、各次元表の最低レベルの
キー値を示します。メジャー ( 基準 ) は、サブジェクトについての量的なデータ、
または実際のデータです。メジャー ( 基準 ) は通常、数値であり、質問の量や数に
対応します。メジャー ( 基準 ) の例には、価格、製品の売上げ、製品の在庫、収益
などがあります。メジャー ( 基準 ) は、表内の列に基づくこともでき、算出される
こともできます。
10-10 Informix Guide to Database Design and Implementation
データ モデルの次元
図 10-6 に、販売数量の合計、収益、ある日のあるアカウントへのある製品の販売利
益がメジャー ( 基準 ) となっているファクト表を示します。
図 10-6
サンプル
レコードによる
ファクト表
製品コード
アカウント
コード
日コード
販売数量
収益
利益
1
5
32104
1
82.12
27.12
3
17
33111
2
171.12
66.00
1
13
32567
1
82.12
27.12
ファクト表を設計する前に、そのファクト表の細分性を決定する必要があります。
細分性は、そのファクト表の個々の低レベル レコードを定義する方法に対応しま
す。細分性は、個別のトランザクション、毎日のスナップショット、あるいは毎月
のスナップショットであったりします。図 10-6 のファクト表には、各アカウントに
販売した製品ごとに毎日 1 行が組み込まれています。したがって、このファクト表
の細分性は、アカウント別、日別の製品として表現します。
データ モデルの次元
次元は、実世界での 1 セットのオブジェクト、またはイベントを表します。データ
モデルのために明確にした各次元は、次元表として実装しなければなりません。次
元とは、ファクト表のメジャー ( 基準 ) を意味あるものにする修飾子です。次元は質
問の何が、いつ、どこでという局面に答えるからです。たとえば、次元をゴシック
体で示している次のビジネス上の質問を考えてください。
■
昨年はどんなアカウントが最高の収益を生み出したか。
■
ベンダごとの利益はどうか。
■
各製品は、どれくらいの数量が売れたか。
上記の質問のうち、収益、利益、および販売数量は次元ではなくメジャー ( 基準 )
であり、数量データまたは実際のデータを表します。
次元データ モデルの作成
10-11
データ モデルの次元
次元要素
次元では、さまざまなレベルの要約に複数の次元要素を定義できます。たとえば、
販売組織の構造に関連するすべての要素が 1 つの次元を構築していることがありま
す。図 10-7 に、アカウント次元が定義する次元要素を示します。
アカウント次元
地域
次元要素
図 10-7
アカウント次元
における
次元要素
テリトリ
アカウント
次元は、関連要素の階層から構築されています。次元と次元の間には階層的な関係
があるので、ユーザは、前の詳細レベルよりも高いレベル にあるデータにアクセス
したり ( ロール アップする )、低いレベルにあるデータにアクセスしたりする ( ドリ
ル ダウンする ) 問合せを構築することができます。図 10-7 に、次元要素の階層的関
係を示します。アカウントはテリトリにロール アップし、テリトリは地域にロール
アップします。ユーザは、抽出するデータに応じて、異なるレベルの次元で問合せ
ができます。たとえば、ユーザがすべての地域に対する問合せを実行してから、
もっと詳細な情報を得るためにテリトリまたはアカウントのレベルまでドリル ダウ
ンする場合があります。
次元要素は通常、ほかの表との連結を容易にするため、数値コードまたは短い文字
列としてデータベースに格納されます。
各次元要素では、次元が複数の次元要素を定義するのと同じ方法で、複数の次元属
性が定義できます。
10-12 Informix Guide to Database Design and Implementation
データ モデルの次元
次元属性
次元属性とは、次元表の列のことをいいます。各属性は、次元階層内の要約のある
レベルのことをいいます。次元要素が次元表内の階層的な関係を定義するのに対し
て、属性はユーザがよく知っている用語で次元要素を表します。図 10-8 に、アカウ
ント次元の次元要素と対応する属性を示します。
次元要素
地域
テリトリ
次元属性
図 10-8
次元要素に対応
する属性
地域
地域サイズ
地域管理者
テリトリ
営業員
アカウント
アカウント コード
アカウント名
次元属性は次元内の項目を記述するため、テキストの場合に最も便利です。
ヒント : 設計プロセスにある間に、生産データ ソースからの数値データ フィール
ドが計測済みのファクトなのか属性なのかがわからないことがあります。一般に、
サンプリングを行うたびに数値データ フィールドが変化する計測値の場合は、ファ
クトです。ほぼ一定の何かを個別に評価した説明の場合は、次元属性です。
次元データ モデルの作成
10-13
次元データ モデルの作成
次元表
次元表は、ビジネスの次元についての説明をテキスト形式で格納する表です。次元
表には、適切な場合、階層の各レベルの要素と属性が含まれています。データ分析
に必要な最低レベルの詳細によって、その階層の最低レベルが決定します。この基
本レベルよりも高いレベルが冗長データを格納します。この正規化されていない表
では、問合せに必要な結合部分の数が低減して、ユーザが高いレベルに問合せして
から詳細レベルにドリル ダウンすることが簡単になります。ドリル ダウンという
用語は、次元表の行ヘッダを問合せに追加することを意味します。図 10-9 に、アカ
ウント次元を基盤とする次元表の例を示します。
図 10-9
次元表の例
アカウント
コード
アカウント
名前
テリトリ
営業員
地域
地域サイズ
地域管理者
1
Jane’s Mfg.
101
B. Adams
中西部
50 以上
T. Sent
2
TBD Sales
101
B. Adams
中西部
50 以上
T. Sent
3
Molly’s
Wares
101
B. Adams
中西部
50 以上
T. Sent
4
The Golf Co.
201
T. Scott
中西部
50 以上
T. Sent
次元データ モデルの作成
次元データ モデルを作成するには、データベース設計を完成させるために必要な意
思決定を概説する方法論が必要です。この方法論では、トップダウン ( 上から下へ
) のアプローチを使用します。それは、データを収集する組織の主要プロセスを最初
に明確にするからです。組織が使用している既存の情報ソースから着手することが
データベース設計者にとっての重要なタスクです。プロセスが明確になったら、各
ビジネス プロセスから 1 つまたは複数のファクト表を作成します。次の手順では、
データ モデルを作成するために使用する方法論を説明します。
次元データベースを作成するには
1.
モデル化するサブジェクト分野を分析するために使用するビジネス プロセ
スを選択します。
10-14 Informix Guide to Database Design and Implementation
ビジネス プロセスの選択
2.
ファクト表の細分性を決定します。
3.
各ファクト表の次元と階層を明確にします。
4.
ファクト表のメジャー ( 基準 ) を明確にします。
5.
各次元表の属性を決定します。
6.
ユーザにデータ モデルを確認させます。
次元データベースは、複数のビジネス モデルにもとづいていたり、多くのファクト
表を持っていたりしますが、この節で説明するデータ モデルは単一のビジネス プ
ロセスに基づいており、ファクト表も 1 つです。
ビジネス プロセスの選択
ビジネス プロセスは、従来のシステムが支援する組織において重要なオペレーショ
ンです。このシステムからデータを収集して、次元データベースに使用します。ビ
ジネス プロセスでは、それらのデータを使用してエンドユーザが何を行うのか、ど
こから来たデータなのか、そのデータを意味あるものにするにはどうやって変換す
るのかを明確にします。財務、売上げ分析、市場分析、顧客プロファイルなど、数
多くのソースから情報が発生します。次のリストは、どんなデータを次元データ
ベースに組み込むかを判断するために使用するかもしれないさまざまなビジネス プ
ロセスを示しています。
■
販売
■
出荷
■
在庫
■
受注
■
請求
ビジネス プロセスの要約
たとえば、もっと効率的なマーケティング戦略を開発できるように、ユーザの組織
が顧客の購買動向を製品ラインと地域ごとに分析するとします。このシナリオで
は、データ モデルの対象エリアは販売です。
多くのインタビューを行い、販売ビジネス プロセスを完全に分析してから、ユーザ
の組織は次の情報を収集するとします。
■
顧客ベースの情報が変化しました。
以前は、営業地区を都市ごとに分割していました。現在、顧客のベース
は、2 つの地域に対応しています。地域 1 としてカリフォルニアと地域 2
としてそのほかの州です。
次元データ モデルの作成
10-15
ビジネス プロセスの要約
■
次のレポートは、マーケティング上で最も重要です。
❑
ベンダ当たりの製品別の毎月の収益、コスト、純利益
❑
製品、地域、月別の収益と販売数量
❑
毎月の顧客収益
❑
ベンダ当たりの四半期の収益
■
販売分析のほとんどは月ごとの結果に基づくものですが、後で、週ごと、
または会計期間ごとに売り上げを分析することができます。
■
データ入力システムは、リレーショナル データベースにあります。
作業用のデータ モデルを開発するには、販売情報のリレーショナル デー
タベースに次のプロパティがあると想定できます。
❑
データベース stores_demo は、マーケティング部門が使用する収益
データの多くを提供します。
❑
分析担当者が使用する製品コードは、カタログ番号として表 catalog
に格納されています。
❑
製品ライン コードは、ストック番号として表 stock に格納されていま
す。製品ライン名は、説明として格納されています。
❑
製品階層はやや複雑です。各製品ラインには多くの製品があり、各
メーカーにも多くの製品があります。
■
各製品のコスト データはすべて、異なる購買システムの costs.lst というフ
ラット ファイルに格納されています。
■
顧客データは、データベース stores_demo に格納されています。
地域情報は、このデータベースにまだ追加されていません。
次元モデルの重要な特性は、このモデルが内部の表名や列名ではなく、エンド ユー
ザがよく知っているビジネス ラベルを使用しているということです。ビジネス プ
ロセスが完了すれば、次元データ モデルのメジャー ( 基準 )、次元、および関係を
作成するために必要なすべての情報が入手できます。この次元データ モデルを使用
して、第 11 章で説明するデータベース sales_demo を実装します。
デモンストレーション データベース stores_demo は、この章で開発する次元データ
モデルの主要なデータ ソースです。データベース sales_demo の表を移植するため
に使用するデータ ソースについての詳細は、11-6 ページの「データ ソースから
データベースへのデータのマッピング」を参照してください。
10-16 Informix Guide to Database Design and Implementation
ファクト表の細分性の決定
ファクト表の細分性の決定
対象分野についての関連情報をすべてそろえたら、設計プロセスでの次の手順は
ファクト表の細分性を決定することです。これを行うには、ファクト表に個別の低
いレベルのどんなレコードを組み込むかを決定する必要があります。ファクト表の
細分性を作り上げる構成要素は、データ モデルの次元と直接一致します。したがっ
て、ファクト表の細分性を定義するときは、データ モデルの次元を明確にします。
細分性のデータベース サイズへの影響力
ファクト表の細分性は、データベースに必要な格納領域量も決定します。たとえ
ば、ファクト表について考えられる次の細分性を考えてください。
■
日別地域別の製品
■
月別地域別の製品
日別地域別の製品という細分性を持つデータベースのサイズは、月別地域別の製品
という細分性を持ったデータベースよりもはるかに大きくなります。これは、トラ
ンザクションの月次要約ではなく、毎日のトランザクションそれぞれについてのレ
コードがデータベースに組み込まれるからです。細分性が細かすぎると自然と膨大
なデータベースになってしまう可能性があるため、ファクト表の細分性は注意して
決定する必要があります。反対に、細分性を大まかにしすぎると、ユーザがデータ
ベースに対して意味のある問合せを行うのに十分な詳細が得られないことになりま
す。
ビジネスプロセスを使用しての細分性の決定
ビジネス プロセスから収集した情報を入念に検討することによって、ファクト表の
細分性を決定するには何が必要かがわかります。要約すると、もっと効率的なマー
ケティング戦略が開発できるように、ユーザの組織は顧客の購買動向を製品ライン
別と地区別に分析するということです。
製品別顧客
ファクト表の細分性は常に、対応する各次元の最低のレベルを表わします。ビジネ
ス プロセスからの情報を検討すれば、ファクト表の顧客と製品の次元についての細
分性が明らかになります。顧客と製品については、これ以上は正当に細かくできま
せん。これらは既に、ファクト表の各レコードの最低のレベルを表しています。製
品が複数のコンポーネントで構成されている場合もあるので、製品は、さらに製品
コンポーネントのレベルにまで細分化できることもあります。
次元データ モデルの作成
10-17
次元と階層の明確化
製品別地区別の顧客
ユーザの組織が分析する顧客購買動向には地理的な構成要素が含まれているため、
この場合も、地域情報については最低レベルを決定する必要があります。ビジネス
プロセスでは、これまでは販売地区が都市によって分割されていましたが、ユーザ
の組織では現在、顧客ベースの 2 つの地域間で区別が行われています。地域 1 とし
てカリフォルニア州と地域 2 としてそのほかの州です。しかし、最低のレベルには
販売地区データも組み込まれているため、地区が地理的情報の最低レベルを表し、
ファクト表の細分性をさらに定義する第 3 の構成要素となっています。
製品別地区別日別の顧客
顧客購買動向は常に時経過によって発生するため、ファクト表の細分性には時間要
素を組み込む必要があります。ユーザの組織では、週、会計期間、月、四半期、年
およびごとにレポートを作成するように決定したとします。最低レベルでは、基本
の細分性である「日」を選択します。この細分性により、火曜日の売り上げと金曜
日の売り上げを比較したり、毎月の最初の日の売り上げを比較したりすることがで
きます。ファクト表の細分性は、これで完成しました。
日の細分性を選択するという決定は、次元表 time の各レコードが日を表わすこと
を意味します。格納要件という点から見ると、毎日のデータが 10 年分あっても、
約 3,650 レコードにすぎず、比較的小さな次元表といえます。
次元と階層の明確化
ファクト表の細分性を決定したら、データ モデルの主要な次元を明確にするのは簡
単です。これは、細分性を定義する各コンポーネントが次元に対応しているからで
す。図 10-10 は、ファクト表の細分性とデータ モデルの次元との関係を示していま
す。
ファクト表の細分性
次元 :
図 10-10
データ モデルの
次元に対応する
ファクト表の
細分性
製品別地区別日別の顧客
顧客
製品
地理
時間
データ モデルの次元 ( 顧客、製品、地理、時間 ) を正しい位置に使用すると、ス
キーマ ダイアグラムが形になってきます。
10-18 Informix Guide to Database Design and Implementation
次元と階層の明確化
ヒント : この時点で、ファクト表の主要な細分性にさらに次元を追加できます。こ
の場合、新しい次元は主要次元の各組み合わせにおいて単一の値しかとれません。
追加した次元がさらにレコードを発生させることになって、細分性に違反すること
を確認した場合は、ファクト表の細分性を改訂して、追加した次元が納まるように
する必要があります。このデータ モデルについては、追加的な次元を追加する必要
はありません。
次元データ モデルの作成
10-19
次元と階層の明確化
この時点で、各次元の次元要素と階層がマップできます。図 10-11 は、次元、次元
要素、および固有の階層間の関係を示しています。
次元要素
属性
ベンダ
ベンダ
製品
製品名
製品ライン
製品ライン名
製品
顧客
顧客名
前企業
地域
州
州名
地区
地区名
年
四半期
月
日
10-20 Informix Guide to Database Design and Implementation
受注日
図 10-11
次元、次元要素、
および固有の
階層間の関係
ファクト表のメジャー ( 基準 ) の選択
ほとんどの場合、次元要素では、各次元についての考えられる最低の細分性を表現
する必要があります。これは、問合せが個別の低いレベルのレコードにアクセスす
るからではなく、問合せには厳密な方法でデータベースを検索する必要があるから
です。つまり、データ ウェアハウス環境が提起する問題が通常、大まかなもので
あったとしてもまだ、これらの質問は製品詳細の最低レベルに依存します。
ファクト表のメジャー ( 基準 ) の選択
データ モデルのメジャー ( 基準 ) には、データそのものだけでなく、既存のデータ
から計算する新しい値も含まれます。そのため、メジャー ( 基準 ) を調べると、
ファクト表の細分性だけでなく次元の数も調整する必要がでてくる場合もありま
す。
データ モデルを設計するときに必要なもう 1 つの重要な決定事項は、計算結果を
ファクト表に格納するか、これらの値を実行時に導出するかです。
答えなければならない質問は、
「ビジネスを分析するのにどんなメジャー ( 基準 ) を
使用するか」です。メジャー ( 基準 ) は、どれくらいの量、またはどれくらいの数
かを示す量的なデータか、実際のデータであることを思い出してください。販売ビ
ジネス プロセスの分析から集めた情報は、次のリストのメジャー ( 基準 ) になりま
す。
■
収益
■
コスト
■
販売数量
■
純利益
次元データ モデルの作成
10-21
ファクト表のメジャー ( 基準 ) の選択
これらのメジャーを使用して、図 10-12 のファクト表が完成します。
製品次元
時間次元
時間コード
製品コード
図 10-12
各次元表を
参照する販売
ファクト表
販売ファクト表
製品コード
時間コード
地区コード
顧客コード
収益
コスト
販売数量
純利益
地理次元
地区コード
顧客次元
顧客コード
ファクト表を次元表と結合するキーの使用
さしあたり、10-22 ページの 図 10-12 のスキーマは、データベースの論理設計と物
理設計の両方が示されていると考えてください。データベースには次の 5 つの表が
含まれています。
■
販売ファクト表
■
製品次元表
■
時間次元表
■
顧客次元表
■
地理次元表
10-22 Informix Guide to Database Design and Implementation
正規化の阻止
各次元表には、主キー ( 製品、時間コード、顧客、地域コード ) が含まれていて、
ファクト表では対応する列は外部キーです。ファクト表には、これら 4 つの外部
キーの組み合わせである主 ( 複合 ) キーもあります。原則として、ファクト表の各
外部キーには、次元表にそれと 1 対になるキーがなければなりません。さらに、複
合キーを備えている次元データベースの表は、ファクト表である必要があります。
つまりこれは、多数対多数の関係を表わす次元データベースの各表がファクト表で
あることを意味します。
ヒント : 主キーは、整数 (INT) 型、小桁整数 (SMALLINT) 型、シリアル (SERIAL) 型
といった短い数値データ型か、コードに使用するような短い文字列にします。長い
文字列を主キーとして使用しないようにお勧めします。
正規化の阻止
ファクト表の 4 つの外部キーは、きちんと管理された連続整数である場合、ファク
ト表の 4 つのキーすべてに対して 16 バイト ( 時間、製品、顧客、および地理につい
て 4 バイトずつ ) まで小さくして予約できます。ファクト表の 4 つのメジャー ( 基準
) が各 4 バイトの整数列であれば、別に 16 バイトだけを予約する必要しかありませ
ん。したがって、ファクト表の各レコードは 32 バイトになるにすぎません。何十
億の列のあるファクト表でも、約 32 GB の主データ空間が必要になるだけです。
コンパクトなキーやデータを使用している、記憶量の少ないファクト表が次元デー
タベースの典型です。次元モデルのファクト表は元来、高度に正規化されていま
す。ファクト表の 4 つのキー間のきわめて複雑な多数対多数の関係はこれ以上正規
化できません。4 つの次元表に相互間系がないからです。実際には、各製品は、各地
区のすべての顧客に対して毎日販売されています。
ファクト表は、次元データベースで一番大きな表です。次元表は通常、ファクト表
よりもかなり小さいため、データベースのディスク領域を計算するときには次元表
を無視することができます。ディスク領域を節約するためだけに次元データベース
のどんな表でも正規化するという努力は、的を得ていません。さらに、正規化され
た次元表は、ユーザが単一の次元表を探索して制約を設定したり、便利な行ヘッダ
を選択したりする能力を低減します。
次元データ モデルの作成
10-23
次元表の属性の選択
次元表の属性の選択
ファクト表が完成したら、各次元表の次元属性を決定できます。属性を選択する方
法を説明するために、時間次元を考えてみましょう。販売ビジネス プロセスのデー
タ モデルは、次元表 time の各レコードが日を表わすように、時間次元に対応する
日の細分性を定義します。この表の各フィールドは、そのレコードが表わしている
特定日によって定義されることを覚えておいてください。
販売ビジネス プロセスの分析で、マーケティング部門が月次、四半期、年次のレ
ポートを必要としていることも示されているため、時間次元には、日、月、四半
期、年という要素が含まれます。各要素には、長い文字列を含んでいる列値を回避
するために、その要素とコード属性を説明する属性が割り当てられています。
図 10-13 は、次元表 time の属性と、表の各フィールドのサンプル値を示していま
す。
図 10-13
時間次元の属性
時間コード
注文日
月コード
月
四半期コード
四半期
年
35276
07/31/1996
7
july
3
third q
1996
35277
08/01/1996
8
aug
3
third q
1996
35278
08/02/1996
8
aug
3
third q
1996
10-24 Informix Guide to Database Design and Implementation
次元表の属性の選択
10-24 ページの 図 10-13 では、割り当てる属性名は、エンド ユーザがデータベース
上で問合せを簡単に作成できるような、なじみのあるビジネス用語とすべきである
ことを示しています。図 10-14 では、各次元表に定義されている属性すべてを備え
た販売ビジネス プロセスの完璧なデータ モデルを示します。
製品次元
時間次元
製品コード
時間コード
製品名
ベンダ
ベンダ名
製品ライン
製品ライン名
注文日
月
四半期
年
販売ファクト表
製品コード
図 10-14
販売ビジネス
プロセスの完璧
な次元データ
モデル
時間コード
地区コード
顧客コード
地理次元
収益
コスト
販売数量
純利益
顧客次元
地区コード
顧客コード
地区
州
州名
地域
顧客名
会社
ヒント : 各次元表に定義する属性の数は一般に、最低限に保つべきです。属性が多
すぎる次元表は、行を過度に大きくしたり、パフォーマンスを劣化させたりするこ
とがあります。詳細は、10-26 ページの「次元表の属性数を最低限に抑える」を参
照してください。
次元データ モデルの作成
10-25
次元データ モデルの共通する問題の処理
次元データ モデルの共通する問題の処理
これまでの節で説明してきた次元モデルは、次元データ モデルの最も基本的なコン
セプトとテクニックを説明するものにすぎません。エンタープライズのビジネス上
のニーズを明確にするために作成するデータ モデルには、通常、データベースから
できる限り最高の問合せパフォーマンスを得るために解決する必要のある、さらな
る問題や困難が含まれています。この節では、次元データ モデルを作成するときに
最も共通して発生する問題の解決に使用できるさまざまな方法を説明します。
次元表の属性数を最低限に抑える
顧客情報や製品情報が入っている次元表には、ゆうに 50 ∼ 100 個の属性があった
り、行が数百万あったりします。しかし、属性が多すぎる次元表は、行を過度に大
きくしたり、パフォーマンスを劣化させたりすることがあります。このため、特定
の属性のグループを次元表から切り離して、小次元表という別個の表に配置するこ
ともあります。小次元表は、大きな次元表から切り離された小さな属性グループか
ら構成されます。次の特性のどちらかを持つ属性に小次元表を作成できます。
■
問合せの制約として、フィールドをほとんど使用しない。
■
フィールドを頻繁に比較し合う。
10-26 Informix Guide to Database Design and Implementation
次元表の属性数を最低限に抑える
図 10-15 は、顧客表から切り離された人口情報についての小次元表を示しています。
図 10-15
人口情報の小次
元表
顧客表
顧客コード
顧客名
人口コード
.
.
.
ファクト表
顧客コード
人口コード
.
.
.
人口表
人口コード
収入レベル
配偶者の有無
.
.
.
ファクト表と顧客表の両方の外部キーとして、人口キーを人口表に格納できます。
これにより、人口表をファクト表に直接結合できます。また、直接顧客表と一緒に
人口キーを使用して、人口属性を閲覧することもできます。
次元データ モデルの作成
10-27
時々変更する次元の処理
時々変更する次元の処理
OLTP システムとは対照的に、ほとんど更新されない次元データベースでは、ほと
んどの次元は時が経っても比較的変化しません。販売地区または地域、あるいは会
社の名前や住所にはほとんど変更がないからです。しかし、履歴比較を行うには、
これらの変更は、それが発生した時点で処理する必要があります。図 10-16 は、変
更が加えられた次元の例を示しています。
図 10-16
変更した次元
顧客
101
Bill Adams
The Sports Palace
Des Plaines
Il
移動 !
Arlington Heights
.
.
.
次元に発生した変更を処理するには、次の 3 種類の方法が使用できます。
■
次元列に格納されている値を変更します。
10-28 ページの 図 10-16 には、顧客次元表の Bill Adams のレコードが更
新されて、新しい住所である Arlington Heights が示されています。
この時点で、この顧客のこれまでの販売履歴のすべてが、Des Plaines では
なく、Arlington Heights 地区と関連付けられます。
■
新しい値や一般化キーを使用して 2 番めの次元レコードを作成します。
この方法は、効率的に履歴を区分わけします。顧客次元表はこの時点で、
Bill Adams についての 2 つの履歴を含んでいます。キー 101 のある以前の
レコードが残り、この時点ではファクト表のレコードも以前のレコードに
関連付けられています。新しいレコードも Bill Adams の顧客次元表に追加
されて、以前のキーと、たとえば 101.01 といったバージョンの桁から構成
される新しいキーが付きます。Bill Adams のファクト表に追加された後続
のすべてのレコードが、この新しいキーと関連付けられます。
■
影響を受ける属性の顧客次元表に新しいフィールドを追加して、以前の属
性の名前を変更します。
新しい値についての以前の履歴を追跡したり、以前の履歴の新しい値を追
跡したりする必要がない限り、この方法はほとんど使用されません。顧客
次元表は、current address という名前の新しい属性を取得し、以前の属性
を original address に変更します。Bill Adams についての情報を含んでい
るレコードには、元の住所と現在の住所の両方の値が含まれます。
10-28 Informix Guide to Database Design and Implementation
スノーフレーク スキーマの使用
スノーフレーク スキーマの使用
スノーフレーク スキーマは、スター スキーマの変形であり、かなり大きな次元表
を複数の表に正規化します。ファクト表の集合体を使用している場合に大きな次元
表の結合を避けたい場合は、階層のある次元をスノーフレーク構造に分解すること
ができます。たとえば、製品次元表から切り離すブランド情報がある場合は、ブラ
ンドごとの単一の行から構成されていて、製品次元表よりも大幅に行数の少ないブ
ランド スノーフレークが作成できます。図 10-17 は、ブランド要素と製品ライン要
素のスノーフレークと、集合表 brand_agg を示しています。
製品表
製品コード
ブランド表
ブランド コード
製品名
ブランド名
ブランド管理者
販売ファクト表
製品コード
図 10-17
スノーフレーク
スキーマの例
時間コード
.
.
.
アカウント コード
brand code
製品ライン
コード
収益
コスト
販売数量
純利益
顧客コード
製品ライン表
製品ライン コード
集合表次元
ブランド コード
製品ライン名
ライン管理者
総収益
総コスト
ブランド コードとブランド当たりの総収益から構成される集合 brand_agg を作成す
る場合は、スノーフレーク スキーマを使用すると、次の表 brand と brand_agg の問
合せが示すように、より大きな表 sales との結合が避けられます。
SELECT brand.brand_name, brand_agg.total_revenue
FROM brand, brand_agg
WHERE brand.brand_code = brand_agg.brand_code
AND brand.brand_name = 'Anza'
スノーフレーク次元表を使用しない場合、すべてのブランドと製品ラインの属性を
含んでいる可能性のある、きわめて大きな次元表である表 product 全体に SELECT
UNIQUE 文または SELECT DISTINCT 文を使用して、重複行を除去します。
次元データ モデルの作成
10-29
スノーフレーク スキーマの使用
次元表が比較的小さくて、スノーフレーク スキーマが不要であっても、数百万行も
ある顧客や製品の次元表のあるような小売業や通信販売ビジネスでは、スノーフ
レーク スキーマを使用するとパフォーマンスが大幅に向上します。
集合表が利用できない場合、スノーフレーク スキーマで正規化された次元要素に結
合する何らかのものは現在、次の問合せが示すように 3 方向結合である必要があり
ます。3 方向結合によって、次元データベースのパフォーマンス上の長所が幾分損
なわれてしまいます。
SELECT brand.brand_name, SUM(sales.revenue)
FROM product, brand, sales
WHERE product.brand_code = brand.brand_code
AND brand.brand_name = 'Alltemp'
GROUP BY brand_name
10-30 Informix Guide to Database Design and Implementation
第 11 章
次元データベースの実装
この章の概要 . .
.
. .
.
. .
. .
.
. .
.
. .
. .
.
. .
次元データベース sales_demo の実装 . . . . . . . . . .
CREATE DATABASE 文の使用 . . . . . . . . . . .
CREATE TABLE 文を使用した次元表およびファクト表の作成
データ ソースからデータベースへのデータのマッピング . .
次元データベースへのデータのロード . . . . . . . . .
データベース sales_demo の作成 . . . . . . . . . . .
次元データベースのテスト . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 11-3
. 11-3
. 11-4
. 11-6
. 11-8
. 11-10
. 11-10
Extended Parallel Server のログ付き表とログなし表
表の種類の選択 . . . . . . . . . . . .
スクラッチ一時表と一時表 Temp . . . .
ロウ永続表 . . . . . . . . . . . .
静的永続表 . . . . . . . . . . . .
オペレーショナル永続表 . . . . . . .
標準永続表 . . . . . . . . . . . .
表の種類の切替え . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
データ ウェアハウス環境のインデックス . . . . . .
データ ウェアハウス環境での GK インデックスの使用
選択での GK インデックスの定義 . . . . . .
式での GK インデックスの定義 . . . . . . .
結合された表での GK インデックスの定義 . . .
. .
.
11-3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11-12
11-12
11-13
11-14
11-15
11-15
11-15
11-16
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11-16
11-18
11-18
11-18
11-19
11-2
Informix Guide to Database Design and Implementation
XPS
この章の概要
この章では、SQL を使用して、第 10 章 で説明した次元データ モデルを実装する方
法について説明します。このデータベースは、データ ウェアハウス環境を説明する
ための単なる例です。例として示すために、説明は SQL 文に翻訳してあります。
この章では、Extended Parallel Server で利用できる、データベース sales_demo に
ついて説明します。この章では、データ ウェアハウジングや大規模なデータベース
アプリケーションのニーズに適した Extended Parallel Server 特有の表の種類とイン
デックスについても説明します。♦
次元データベース sales_demo の実装
この節では、第 10 章 で説明したデータ モデルから次元データベースを作成するた
めに使用できる SQL 文について説明します。対話型 SQL を使用して、データベー
スを作成するための文を 1 つずつ書けます。または、スクリプトを実行して、デー
タベースの実装に必要なすべての文を自動的に実行できます。CREATE
DATABASE 文と CREATE TABLE 文は、データベース内の表としてデータ モデル
を作成します。データベースを作成した後、LOAD 文と INSERT 文を使用して表を
構築できます。
CREATE DATABASE 文の使用
データベース内に表やオブジェクトを作成するには、まずデータベースを作成する
必要があります。
Informix データベース サーバでデータベースを作成する場合、サーバは、データ
ベースが存在していることとデータベースのロギング モードを示すレコードを設定
します。データベース サーバはディスク領域を直接管理するので、これらのレコー
ドはオペレーティング システムのコマンドでは見ることができません。
次元データベースの実装
11-3
CREATE TABLE 文を使用した次元表およびファクト表の作成
Extended Parallel Server を使用してデータベースを作成すると、ログ機能は常にオ
ンになります。ただし、データベースにログなし表を作成することもできます。詳
細は、11-12 ページの「Extended Parallel Server のログ付き表とログなし表」を参
照してください。
次の文で、sales_demo というデータベースを作成するのに使用する構文を示しま
す。
CREATE DATABASE sales_demo
CREATE TABLE 文を使用した次元表およびファクト表の作成
この節では、次元データベース sales_demo の表を作成するために使用する
CREATE TABLE 文について説明します。
参照整合性は、もちろん、次元データベースにとって重要な要件です。しかし、次
に示すデータベース sales_demo のスキーマでは、ファクト表と次元表の間に存在
する主キーと外部キーの関係を定義していません。このスキーマでそのような主
キーと外部キーとの関係を定義していない理由は、データをロードする際にデータ
ベース サーバが制約確認を実行しなければ、ロードのパフォーマンスが大幅に向上
するためです。データ ウェアハウス環境で特定の時間内に数十から数百 GB のデー
タをロードする必要が頻繁にある場合、データをロードするパフォーマンスは、
データベースをウェアハウス環境に実装する方法を決定するにあたって重要な要素
になります。稼働中のデータ マートとしてデータベース sales_demo が実装されて
いることを想定した場合、ファクト表と次元表との間の参照整合性を保つために、
データベース サーバではなくデータ抽出ツールが使用されます。
ヒント : 表を作成してロードした後で、参照整合性を保つために、ALTER TABLE
文を使用して主キー制約と外部キー制約を表に追加できます。この方法は、高速
ロード モードの場合にだけ必要です。制約とインデックスが必要で、ロードする前
に削除するのに手間がかかる場合には精細ロード モードが最適なオプションです。
11-4
Informix Guide to Database Design and Implementation
CREATE TABLE 文を使用した次元表およびファクト表の作成
以下の文は、表 time、geography、product、および customer を作成します。これ
らの表は、ファクト表 sales に対する次元表です。シリアル (SERIAL) 型のフィール
ドは、表 geography の列 district_code の主キーとして機能します。
CREATE TABLE time
(
time_code INT,
order_date DATE,
month_code SMALLINT,
month_name CHAR(10),
quarter_code SMALLINT,
quarter_name CHAR(10),
year INTEGER
)
CREATE TABLE geography
(
district_code SERIAL,
district_name CHAR(15),
state_code CHAR(2),
state_name CHAR(18),
region SMALLINT
)
CREATE TABLE product (
product_code INTEGER,
product_name CHAR(31),
vendor_code CHAR(3),
vendor_name CHAR(15),
product_line_code SMALLINT,
product_line_name CHAR(15)
)
CREATE TABLE customer (
customer_code INTEGER,
customer_name CHAR(31),
company_name CHAR(20)
)
次元データベースの実装
11-5
データ ソースからデータベースへのデータのマッピング
ファクト表 sales には、それぞれの次元表へのポインタがあります。たとえば、
customer_code は表 customer を参照し、district_code は表 geography を参照しま
す。表 sales には、売上数量、売上高、コスト、および純利益のメジャー ( 基準 ) も
含まれています。
CREATE TABLE sales
(
customer_code INTEGER,
district_code SMALLINT,
time_code INTEGER,
product_code INTEGER,
units_sold SMALLINT,
revenue MONEY(8,2),
cost MONEY(8,2),
net_profit MONEY(8,2)
)
ヒント : 最も便利なメジャー ( ファクト ) は加算的な数値です。データ ウェアハウ
ス環境では、データベースのサイズが非常に大きいため、ファクト表に対するほと
んどすべての問合せで、その答えを構築するために数千から数百万のレコードが必
要になります。そのようなレコードを圧縮するために使用できる唯一の方法は、レ
コードを集約することです。表 sales では、メジャーの各列が数値データ型で定義
されているので、units_sold、revenue、cost、net_profit の各列から答えを容易に作
成できます。
ファイル createdw.sql には、上記の CREATE TABLE 文がすべて含まれています。
データ ソースからデータベースへのデータのマッピング
デモンストレーション データベース stores_demo は、データベース sales_demo の
主データ ソースです。
11-6 ページの 図 11-1 は、データ ウェアハウスのビジネス用語とデータ ソースとの
関係を表しています。その表は、データベース sales_demo のそれぞれの列と表の
データ ソースも表しています。
図 11-1
データ ウェアハウスのビジネス用語とデータ ソースの関係
ビジネス用語
データ ソース
表 . 列名
ファクト表 sales
製品コード
sales.product_code
顧客コード
sales.customer_code
(1 / 3)
11-6
Informix Guide to Database Design and Implementation
データ ソースからデータベースへのデータのマッピング
ビジネス用語
データ ソース
表 . 列名
地区コード
sales.district_code
時間コード
sales.time_code
収益
stores_demo:items.total_price
sales.revenue
売上数量
stores_demo:items.quantity
sales.units_sold
コスト
costs.lst (per unit)
sales.cost
純利益
計算結果 : 収益 - コスト
sales.net_profit
製品
stores_demo:catalog.catalog_num
product.product_code
製品名
stores_demo:stock.manu_code およ
び stores_demo:stock.description
product.product_name
製品ライン
stores_demo:orders.stock_num
product.product_line_code
製品ライン名
stores_demo:stock.description
product.product_line_name
ベンダ
stores_demo:orders.manu_code
product.vendor_code
ベンダ名
stores_demo:manufact.manu_name
product.vendor_name
次元表 product
次元表 customer
顧客
stores_demo:orders.customer_num
customer.customer_code
顧客名
stores_demo:customer.fname +
stores_demo:customer.lname
customer.customer_name
会社名
stores_demo:customer.company
customer.company_name
次元表 geography
地区コード
生成される
geography.district_code
地区
stores_demo:customer.city
geography.district_name
州
stores_demo:customer.state
geography.state_code
州名
stores_demo.state.sname
geography.state_name
(2 / 3)
次元データベースの実装
11-7
次元データベースへのデータのロード
ビジネス用語
データ ソース
表 . 列名
地方
導出される :If 州 = "CA" THEN
地方 = 1, ELSE 地方 = 2
geography.region
時間コード
生成される
time.time_code
注文日
stores_demo:orders.order_date
time.order_date
月
derived from order date generated
time.month_name
time.month.code
四半期
derived from order date generated
time.quarter_name
time.quarter_code
年
注文日から導出される
time.year
次元表 time
(3 / 3)
接尾辞 .unl を持ついくつかのファイルには、データベース sales_demo 内にロード
されたデータが含まれています。データベースを作成してロードする SQL 文を含む
ファイルには、接尾辞 .sql が付いています。
UNIX オペレーティング システム上でデータベース サーバを実行している場合、
ファイル *.sql および *.unl にはディレクトリ $INFORMIXDIR/demo/dbaccess から
アクセスできます。♦
UNIX
WIN NT
Windows NT オペレーティング システム上でデータベース サーバを実行している
場合、ファイル *.sql および *.unl にはディレクトリ
%INFORMIXDIR%/demo/dbaccess からアクセスできます。♦
サフィックスが .sql のファイルには、コマンド ファイルとして DB-Access または
Relational Object Manager からもアクセスできます。
次元データベースへのデータのロード
次元データベースを実装する場合に重要なことは、効果的なロード方法を立案して
文章化することです。この節では、データベース sales_demo の表を構築するため
に使用できる LOAD 文と INSERT 文について説明します。
ヒント : 稼動中のデータ ウェアハウス環境では、通常、LOAD 文または INSERT 文
を使用して Informix データベースに対する大量のデータのロードを実行することは
ありません。
11-8
Informix Guide to Database Design and Implementation
次元データベースへのデータのロード
Informix データベース サーバには、高性能なデータのロードとアンロードを行うさ
まざまな機能があります。
Extended Parallel Server を使用してデータベースを作成する場合は、外部表を使用
して高性能なロードとアンロードを実行できます。♦
ハイパフォーマンスなロードについては、
『Administrator’s Guide』または highperformance loader documentation のマニュアルを参照してください。
次の文は、表 sales 内にロードされる各行の時間コードの確定に使用できるように、
最初に表 time にデータをロードします。
LOAD FROM 'time.unl'
INSERT INTO time
次の文は表 geography にデータをロードします。表 geography にデータをロードす
ると、その地区コード データを、表 sales にロードするために使用できます。
INSERT INTO geography(district_name, state_code,
state_name)
SELECT DISTINCT c.city, s.code, s.sname
FROM stores_demo:customer c, stores_demo:state s
WHERE c.state = s.code
次の文は、表 geography に地方コードを追加します。
UPDATE geography
SET region = 1
WHERE state_code = 'CA'
UPDATE geography
SET region = 2
WHERE state_code <> 'CA'
次の文は、表 customer にデータをロードします。
INSERT INTO customer
(customer_code, customer_name, company_name)
SELECT c.customer_num, trim(c.fname) ||' '|| c.lname,
c.company
FROM stores_demo:customer c
次の文は、表 product にデータをロードします。
INSERT INTO product
(product_code, product_name, vendor_code,
vendor_name,product_line_code, product_line_name)
SELECT a.catalog_num,
trim(m.manu_name)||' '||s.description,
m.manu_code, m.manu_name,
次元データベースの実装
11-9
データベース sales_demo の作成
s.stock_num, s.description
FROM stores_demo:catalog a, stores_demo:manufact m,
stores_demo:stock s
WHERE a.stock_num = s.stock_num
AND a.manu_code = s.manu_code
AND s.manu_code = m.manu_code
次の文は、ファクト表 sales の行に、製品の顧客別、日付別、地区別のデータを
ロードします。表 cost にあるコストの値を使用して、コストの合計が計算されます
( コスト * 数量 )。
INSERT INTO sales
(customer_code, district_code, time_code,
product_code, units_sold, cost, revenue,
net_profit)
SELECT
c.customer_num, g.district_code, t.time_code,
p.product_code, SUM(i.quantity),
SUM(i.quantity * x.cost), SUM(i.total_price),
SUM(i.total_price) - SUM(i.quantity * x.cost)
FROM stores_demo:customer c, geography g, time t,
product p,stores_demo:items i,
stores_demo:orders o, cost x
WHERE c.customer_num = o.customer_num
AND o.order_num = i.order_num
AND p.product_line_code = i.stock_num
AND p.vendor_code = i.manu_code
AND t.order_date = o.order_date
AND p.product_code = x.product_code
AND c.city = g.district_name
GROUP BY 1,2,3,4
データベース sales_demo の作成
次元データベース sales_demo はデータベース stores_demo のデータを使用するの
で、データベース sales_demo を実装するには、次元データベース sales_demo と
データベース stores_demo の両方を作成する必要があります。
dbaccessdemo スクリプトを使用してデータベース sales_demo を実装する方法につ
いては、
『DB-Access User’s Manual』を参照してください。
次元データベースのテスト
SQL 問合せを作成すると、ビジネス プロセスのまとめにリストされている標準レ
ポートのために必要なデータを抽出できます (10-15 ページの「ビジネス プロセスの
要約」を参照してください )。以下のアド ホックな問合せを使用して、次元データ
ベースが適切に実装されていることをテストします。
11-10 Informix Guide to Database Design and Implementation
次元データベースのテスト
次の文は、各ベンダの製品ラインごとに、毎月の収益、コスト、および純利益の値
を返します。
SELECT vendor_name, product_line_name, month_name,
SUM(revenue) total_revenue, SUM(cost) total_cost,
SUM(net_profit) total_profit
FROM product, time, sales
WHERE product.product_code = sales.product_code
AND time.time_code = sales.time_code
GROUP BY vendor_name, product_line_name, month_name
ORDER BY vendor_name, product_line_name
次の文は、製品別、地方別、月別の収益と売上数量の値を返します。
SELECT product_name, region, month_name,
SUM(revenue), SUM(units_sold)
FROM product, geography, time, sales
WHERE product.product_code = sales.product_code
AND geography.district_code = sales.district_code
AND time.time_code = sales.time_code
GROUP BY product_name, region, month_name
ORDER BY product_name, region
次の文は、毎月の顧客収益の値を返します。
SELECT customer_name, company_name, month_name,
SUM(revenue)
FROM customer, time, sales
WHERE customer.customer_code = sales.customer_code
AND time.time_code = sales.time_code
GROUP BY customer_name, company_name, month_name
ORDER BY customer_name
次の文は、ベンダ別の四半期ごとの収益の値を返します。
SELECT vendor_name, year, quarter_name, SUM(revenue)
FROM product, time, sales
WHERE product.product_code = sales.product_code
AND time.time_code = sales.time_code
GROUP BY vendor_name, year, quarter_name
ORDER BY vendor_name, year
次元データベースの実装
11-11
Extended Parallel Server のログ付き表とログなし表
Extended Parallel Server のログ付き表とログなし
表
この節では、Extended Parallel Server のさまざまな表の種類について説明します。
これらの表は、データ ウェアハウス環境で使用すると特に便利です。Dynamic
Server が表のログを記録するのと同様に、Extended Parallel Server はデフォルトで
表のログを記録します。しかし、大量のデータがある一方で挿入、更新、削除がほ
とんどないデータ ウェアハウス環境やアプリケーションでは、同一のデータベース
内にログ付き表とログなし表との組合せが必要なことが多くあります。多くの場
合、一時表は、データベース セッションが終了すると持続しないので不適切です。
ログ付き表とログなし表の両方の必要条件を満たすために、Extended Parallel
Server では次の種類の永続表と一時表をサポートしています。
■
ロウ永続表 ( ログなし )
■
静的永続表 ( ログなし )
■
オペレーショナル永続表 ( ログ付き )
■
標準永続表 ( ログ付き )
■
スクラッチ一時表 ( ログなし )
■
Temp 一時表 ( ログ付き )
表の種類を指定せずに CREATE TABLE 文を発行すると、標準永続表が作成されま
す。
これらの表を作成するために使用する構文については、
『Informix Guide to SQL:
Syntax』の CREATE TABLE 文を参照してください。表の種類を変更するために使
用する構文については、
『Informix Guide to SQL: Syntax』の ALTER TABLE 文を参
照してください。
重要 : コサーバが一時領域として使用したりアクセスしたりできるのは、そのコ
サーバ自体の DB 領域だけです。一時表では永続表と同様に DB 領域内を明示的に
フラグメント化できますが、コサーバは、そのコサーバ自体が管理するフラグメン
ト内にだけデータを挿入できます。
表の種類の選択
データ ウェアハウス環境の個々の表では、要求される条件がそれぞれ異なることが
多くあります。以下の質問に答えていくと、使用する適切な表の種類を決定しやす
くなります。
■
表にインデックスは必要ですか ?
■
表に定義する必要のある制約は ?
11-12 Informix Guide to Database Design and Implementation
表の種類の選択
■
表のリフレッシュまたは更新の周期は ?
■
表は読取り専用表ですか ?
■
表のログを記録する必要はありますか ?
図 11-2 では、Extended Parallel Server がサポートする 6 種類の表の属性を一覧表示
しており、外部表を使用してこれらの種類の表にデータをロードする方法を示して
います。この表の情報を使用して、使用する表に固有の必要条件に一致する表の種
類を選択してください。
図 11-2
Extended Parallel Server の表の種類の特性
ログ付き
インデッ
クス
簡単な
追加の
使用
スクラッチ なし
なし
なし
あり
Temp
なし
あり
あり
ロウ
あり
なし
静的
あり
オペレー
ショナル
標準
種類
ロール
バック
可能
回復機能
アーカイブ
からの復元
外部表
ロード モード
なし
なし
なし
高速または
精細ロード
モード
あり
あり
なし
なし
高速または
精細ロード
モード
なし
あり
なし
なし
なし
高速または
精細ロード
モード
なし
あり
なし
なし
なし
なし
なし
あり
あり
あり
あり
あり
あり
なし
高速または
精細ロード
モード
あり
あり
あり
なし
あり
あり
あり
精細ロード
モード
永続性
スクラッチ一時表と一時表 Temp
スクラッチ表とは、インデックス、制約、ロールバック機能のいずれもサポートし
ていないログなし一時表です。
次元データベースの実装
11-13
表の種類の選択
表 Temp は、簡単な追加のようなバルク操作もサポートするログ付き一時表です。
高速モードのロードでは、バッファ キャッシュをバイパスする簡単な追加を使用し
ます。簡単な追加では、バッファ管理に関連するオーバーヘッドはなくなります
が、データのログは記録しません )。Temp 表は、インデックス、制約、および
ロールバック機能をサポートしています。
ヒント : INTO TEMP 節を指定した SELECT 文と INTO SCRATCH 節を指定した
SELECT 文は、通常の挿入と同様に、複数のコサーバ上で並列になります。INTO
TEMP 節を指定した SELECT 文と INTO SCRATCH 節を指定した SELECT 文によ
り、複数のノードにフラグメント一時表が明示的に作成された場合、Extended
Parallel Server はそれらのフラグメント一時表を自動的にサポートします。
Extended Parallel Server は、以下の基準に従って明示的な一時表を作成します。
■
Temp 表またはスクラッチ表を構築するために使用する問合せによって行
が生成されない場合、データベース サーバはフラグメント化されていない
空の表を作成します。
■
問合せによって生成される行が 8 KB を超えない場合、一時表は 1 つの DB
領域内に常駐します。
■
そのような行が 8 KB を超える場合、Extended Parallel Server は複数のフ
ラグメントを作成し、ラウンドロビン フラグメンテーション スキーマを
使用してそれらのフラグメントを構築します。
ロウ永続表
ロウ表は、簡単な追加を使用するログなし永続表です。高速モードのロードでは、
バッファ キャッシュをバイパスする簡単な追加を使用します。ロウ表には、高速
モードでデータをロードできます。高速モードのロードについては、
『Administrator’s Reference』を参照してください。
ロウ表は、更新、挿入、削除をサポートしますが、それらのログは記録しません。
ロウ表は、インデックス、参照制約、ロールバック機能、回復機能、アーカイブか
らの復元機能のいずれもサポートしていません。
最初のデータのロードとスクラビングにロウ表を使用します。それらの手順を完了
したら、より高いレベルに表を変更します。たとえば、ロウ表にロードしていると
きにエラーか障害が発生すると、その結果のデータは、障害が発生した時点にディ
スク上にあったデータになります。
データ ウェアハウス環境では、以下の両方の条件に当てはまる場合、ファクト表を
ロウ表として作成できます。
■
いくつかの機構によっては制約やインデックスが必要なことがあるが、そ
のような制約もインデックスもファクト表で指定する必要がない。
11-14 Informix Guide to Database Design and Implementation
表の種類の選択
■
ファクト表を作成することにもファクト表にデータをロードすることにも
コストがかからない。ファクト表は、意思決定支援のために便利ですが必
須ではない。データが損失したら、容易にデータを表に再ロードできる。
静的永続表
静的表は、ログなしの読取り専用永続表で、挿入、更新、削除のいずれの操作もサ
ポートしていません。挿入、更新、削除のいずれの操作も表で実行しない場合は、
静的表として表を作成できます。静的表では、非クラスタ インデックスや参照制約
を作成したりドロップしたりできます。なぜなら、そのような操作は、データに影
響を与えないためです。
静的表では、ロールバック機能、回復機能、アーカイブからの復元機能のいずれも
サポートしていません。静的表の利点は、読み取り専用であるために、問合せの実
行時にデータベース サーバが簡単な走査を使用できることと、サーバがロックする
のを防げることです。
ヒント : GK インデックスを使用する表を作成する場合、静的表は重要です。静的
表は、GK インデックスをサポートする唯一の表の種類であるためです。
オペレーショナル永続表
オペレーショナル表は、ログ付き永続表で、簡単な追加を使用しますがレコード単
位のログは記録しません。オペレーショナル表では、高速更新の操作を実行できま
す。
オペレーショナル表では、操作をロールバックしたり、障害から回復したりできま
すが、ロードされる大量の挿入レコードはログに記録されないので、ログのアーカ
イブから確実に復元することはできません。オペレーショナル表を使用するのは、
ほかのソースからデータを導出するために、復元機能は重要でない場合で、ロール
バック機能も回復機能も必要ない場合です。
周期的にデータがリフレッシュされるので、ファクト表をオペレーショナル表とし
て作成できます。オペレーショナル表では、インデックスも制約もない場合に高速
ロード モードをサポートし、データは回復可能です。
標準永続表
Extended Parallel Server の標準表は、Dynamic Server で作成するログ付きデータ
ベースの表と同じです。すべての操作はレコード単位でログに記録されるので、標
準表はアーカイブから復元できます。標準表は、回復機能とロールバック機能をサ
ポートしています。
次元データベースの実装
11-15
表の種類の切替え
表の更新とリフレッシュの周期が頻繁でない場合、標準表で表を作成できます。リ
フレッシュ周期の間に制約とインデックスを削除する必要がないためです。イン
デックスは、作成に時間と手間がかかりますが必要です。
ヒント : 標準表では簡単な追加を使用しないので、外部表を使用してロードを実行
する場合に高速ロード モードを使用できません。
表の種類の切替え
ALTER TABLE コマンドを使用して、永続表の種類を切り替えます。変更する表
が、新しい表の種類の制限事項を満たしていない場合、変更は失敗し、説明のエ
ラー メッセージが表示されます。表の変更には、次の制限事項が適用されます。
■
表の種類を RAW に変更する前に、インデックスと参照制約を削除する必
要があります。
■
変更した表が完全回復機能の制限事項を満たすように、表の種類を
STANDARD に変更する前にレベル 0 のアーカイブを実行する必要があり
ます。
■
一時表 Temp やスクラッチ一時表を変更することはできません。
データ ウェアハウス環境のインデックス
従来の B ツリー インデックスに加えて、Extended Parallel Server は次のようなイン
デックスを提供します。これらのインデックスを使用すると、データ ウェアハウス
環境でのアドホック問合せのパフォーマンスを向上できます。
■
ビットマップ インデックス
ビットマップ インデックスは、B ツリー インデックスの特別なバリエー
ションです。ビットマップ インデックスは、既婚と未婚の別、または性別
など、種類が少ない値のうちの 1 つを含む列のインデックスを作成する場
合に使用できます。値の重複が多いので、ビットマップ インデックスは、
列が含む値ごとに圧縮したビットマップを格納します。ビットマップ イン
デックスを使用すると、同じキーを含む行間の距離が減少するので格納効
率が向上します。
次の両方の条件に当てはまる場合にビットマップ インデックスを使用でき
ます。
❑
インデックス内のキー値に、多くの重複があります。
❑
表走査のパフォーマンスを向上するためにオプティマイザが使用でき
るインデックスが、表内の複数の列に付いています。
11-16 Informix Guide to Database Design and Implementation
データ ウェアハウス環境のインデックス
■
一般化キー (GK) インデックス
GK インデックスを使用すると、式の結果、データ セットの選択、または
結合された表からのデータ セットの積を、B ツリー インデックスまたは
ビットマップ インデックス内のキーとして格納できます。これは、1 つま
たは複数の大規模表での特定の問合せに便利です。
GK インデックスを作成する場合は、含まれるすべての表は静的表である
必要があります。
インデックス機能の効率を向上するために、Extended Parallel Server は次の機能を
サポートしています。
■
同一の表アクセスに使用できるように複数のインデックスを自動的に結合
します。
複数列インデックスを単一列インデックスと結合できます。
■
スキップ走査というアクセス方法で表を読み取ります。
表の行を走査する場合、データベース サーバはインデックスが示す行だけ
を読み取ります。その場合、行がデータベース内にある順序で行を読み取
ります。スキップ走査アクセス方法では、1 つのページを 2 度読み取るこ
とはありません。各ページは、ランダムにではなく順次に読み取られるの
で、入出力資源の要件は減少します。スキップ走査では、インデックス列
でのフィルタ処理が不要になるので、CPU 要件も減少します。
■
ハッシュ半結合を使用して、複数表結合を処理する作業を減らします。
ハッシュ半結合は、1 つの大きな ( ファクト ) 表が多くの小さな ( 次元 ) 表
に結合されるスター スキーマに対する問合せなどで特に便利です。ハッ
シュ半結合では、結合を開始する前に、効率的に行の数をできる限り減ら
すことができます。
データベースに対して実行する問合せの種類を解析することは、作成するインデッ
クスの種類を決めるためにも役立ちます。問合せのパフォーマンスを向上させるた
めに使用できるインデックスおよびインデックス作成方法については、
『Performance Guide』を参照してください。
次元データベースの実装
11-17
データ ウェアハウス環境での GK インデックスの使用
データ ウェアハウス環境での GK インデックスの使用
特定の種類の問合せを表で頻繁に使用する場合は、GK インデックスを作成すると
便利です。以下の例では、1 つまたは複数の大きな表での問合せ用に GK インデッ
クスを作成して使用する方法について説明しています。この例では、データベース
sales_demo の表に基づいて説明しています。
選択での GK インデックスの定義
州 = "CA" となる値を戻す、ファクト表 sales での典型的な問合せについて考えま
す。このような種類の問合せのパフォーマンスを向上するために、GK インデック
スを作成すると 1 つの SELECT 文の結果をインデックス内の 1 つのキーとして格納
できます。次の文はインデックス state_idx を作成します。インデックス state_idx
は、地域データによって検索を制限する問合せのパフォーマンスを向上できます。
CREATE GK INDEX state_idx on geography
(SELECT district_code FROM geography
WHERE state_code = "CA")
データベース サーバは、州 = "CA" の場合に製品別、地方別、月別の収益と売り上
げ数量を戻す、次のような種類の問合せにインデックス state_idx を使用できます。
データベース サーバは、州 = "CA" の場合に表 geography から行を抽出するために
インデックス state_idx を使用して、問合せ全体のパフォーマンスを向上させます。
SELECT product_name, region, month_name, SUM(revenue),
SUM(units_sold)
FROM product, geography, time, sales
WHERE product.product_code = sales.product_code AND
geography.district_code = sales.district_code AND
state_code = "CA" AND time.time_code = sales.time_code
GROUP BY product_name, region, month_name
ORDER BY product_name, region
式での GK インデックスの定義
ある式の結果をインデックス内の 1 つのキーとして格納するために GK インデック
スを作成できます。次の文はインデックス cost_idx を作成します。インデックス
cost_idx を使用すると、販売した製品のコストを含む表 sales に対する問合せのパ
フォーマンスを向上できます。
CREATE GK INDEX cost_idx on sales
(SELECT units_sold * cost FROM sales)
11-18 Informix Guide to Database Design and Implementation
データ ウェアハウス環境での GK インデックスの使用
データベース サーバは、製品の購入に $10,000.00 を超える金額を使った顧客名を戻
す、次のような種類の問合せにインデックス cost_idx を使用できます。
SELECT customer_name
FROM sales, customer
WHERE sales.customer_code = customer.customer_code
AND units_sold * cost > 10000.00
結合された表での GK インデックスの定義
結合された表からのデータ セットの積の結果をインデックス内のキーとして格納す
るために GK インデックスを作成できます。次元表 time の年データを使用して、表
sales のエントリに GK インデックスを作成するとします。次の文でインデックス
time_idx を作成します。
CREATE GK INDEX time_idx on sales
(SELECT year FROM sales, time
WHERE sales.time_code = time.time_code)
重要 : 前述の GK インデックスを作成するには、表 sales の列 time_code は、表
time の列 time_code ( 主キー ) を参照する外部キーである必要があります。
データベース サーバは、1996 年より後に製品を購入した顧客名を戻す、次のよう
な種類の問合せにインデックス time_idx を使用できます。
SELECT customer_name
FROM
sales, customer, time
WHERE sales.time_code = time.time_code AND year > 1996
AND sale.customer_code = customer.customer_code
次元データベースの実装
11-19
記号 数字 A
B C
D
あ行
E
F
か行
G
H
さ行
I
た行
J
K
な行
L
M
は行
N O
ま行
P
や行
Q
R
ら行
S
わ行
索引
記号
:: ( 二重コロン )、キャスト演算
子 9-4
数字
1 対 1 の関係 2-9, 2-11
1 対多の関係 2-9, 2-11
10 進数 (DECIMAL) 型
固定小数点 3-12
浮動小数点 3-11, 3-12
8 バイトシリアル (SERIAL8) 型の
初期化 3-9
8 バイト整数 (INT8) 型 3-8
A
ADD ROWID 節、ALTER TABLE
文の 5-37
ALTER FRAGMENT 文
ADD 節 5-30
ATTACH 節 5-29
DETACH 節 5-30
DROP 節 5-31
INIT 節 5-25, 5-26
MODIFY 節 5-28
行識別子列の追加 5-37
ALTER TABLE 文
ADD ROWIDS 節 5-37
DROP ROWIDS 節 5-37
∼に対するアクセス権 6-9
表の種類の切替え 11-16
列のデータ型の変更 3-24
Alter アクセス権 6-9
ANSI 標準準拠
アイコン 序 9
決定 1-5
説明 1-4
レベル 序 14
ANSI 標準準拠データベース
アクセス権 1-7
効果
10 進数型 1-9
SQLCODE 1-9
エスケープ文字 1-9
オブジェクトへのアクセス
権 1-7
カーソルの動作 1-9
所有者名の指定 1-7
デフォルトの排他レベル 1-8
トランザクション 1-6
トランザクションログ機能 1-7
作成の理由 1-4
使用できる SQL 文 1-10
所有者名の指定 1-7
設定 1-5
バッファ付きログ機能の制限 4-6
表アクセス権 6-7
ASC キーワード、CREATE INDEX
文の 4-9
B
BLOB 型
SQL での制限 7-7
説明 7-5
C
CLOB 型
SQL での制限 7-7
T
U
V W
X
Y
Z
索引
記号 数字 A
B C
D
あ行
E
F
か行
G
H
さ行
I
た行
J
K
な行
L
M
は行
N O
ま行
P
や行
DBMONEY 環境変数 3-13
dbschema ユーティリティ 4-16
DBSPACETEMP 環境変数 5-33
DBTIME 環境変数 3-17
Delete アクセス権 6-8, 6-32
DELETE 文
∼に対するアクセス権 6-5, 6-8
ビューへの適用 6-29
DESC キーワード、CREATE
INDEX 文の 4-9
DISTINCT キーワード、修正可能
なビューの制限 6-28
DROP CAST 文の使用 9-16
DROP ROWIDS 節、ALTER
TABLE 文の 5-37
説明 7-5
Codd、E. F. 2-31
Connect アクセス権 6-5
CREATE DATABASE 文
コマンドスクリプトでの 4-16
実装
次元データモデル 11-3
リレーショナルデータモデル
の 4-4
CREATE FUNCTION 文、
キャスト登録の例 9-20
CREATE INDEX 文
ASC キーワード 4-9
DESC キーワード 4-9
使用 4-8
ソート順 4-9
CREATE TABLE 文
FRAGMENT BY EXPRESSION 節
で 5-9
SCRATCH 5-32
TEMP 5-32
WITH ROWIDS 節 5-37
コマンドスクリプトでの 4-16
説明 4-6
CREATE VIEW 文
WITH CHECK OPTION キーワー
ド 6-30
使用 6-24
∼に対する制限 6-26
Find Error ユーティリティ 序 12
finderr ユーティリティ 序 12
FRAGMENT BY EXPRESSION 節、
CREATE TABLE 文の 5-9
D
G
DB スライス、フラグメント化での
役割 5-5
DB 領域
CREATE DATABASE 文を使用し
ての選択 4-4
フラグメント化での役割 5-3
DBA「データベース管理者」を参
照
DB-Access
UNLOAD 文 4-17
∼を使用したデータベースの作
成 4-16
DB-Access ユーティリティ 序 4
DBDATE 環境変数 3-14
dbload ユーティリティ、表への
データのロード 4-17
GK インデックス「一般化キーイン
デックス」を参照
GL_DATETIME 環境変数 3-17
GRANT 文
データベースレベルアクセス
権 6-4
表レベルアクセス権 6-6
GROUP BY キーワード、修正可能
なビューの制限 6-28
E
en_us.8859-1 ロケール 序 4
EXISTS キーワード、条件の副問合
せで使用 6-31
F
I
Index アクセス権 6-9
INFORMIXDIR/bin ディレクト
リ 序5
2 Informix Guide to Database Design and Implementation
Q
R
ら行
S
T
U
V W
X
Y
Z
わ行
INIT 節、ALTER FRAGMENT
の 5-26
Insert アクセス権 6-8, 6-32
INSERT 文
∼に対するアクセス権 6-5, 6-8
ビューを使用しての 6-29
INTO TEMP キーワード、ビュー
での制限 6-27
ISO 8859-1 コードセット 序 4
M
MODE ANSI キーワード
ANSI 標準準拠の設定 1-6
ANSI 標準準拠のログ機能 4-6
MODIFY 節、ALTER FRAGMENT
文の 5-27
N
NLS、バージョン 7.2 製品との互換
性 1-10
NOT NULL キーワード、CREATE
TABLE 文での使用 4-6
NULL 値
主キーでの制限 2-22
定義 3-24
O
ON-Archive、バックアップと復元
の操作 5-6
ON-BAR、バックアップと復元の
操作 5-6
ORDER BY キーワード
ORDER BY 列のインデック
ス 4-10
ビューの制限 6-27
P
PDQ( 並列データベース問合せ )、
フラグメント化とともに使
用 5-6
PUBLIC キーワード、すべての
ユーザに付与されるアクセス
権 6-5
記号 数字 A
B C
D
あ行
E
F
か行
R
References アクセス権 6-10
Resource アクセス権 6-6
REVOKE 文、アクセス権の付
与 6-4 – 6-16
rofferr ユーティリティ 序 12
S
sales_demo データベース 序 5
SQL 文の使用
作成 11-4
ロード 11-8
コマンドファイルを使用した作
成 11-10
データソース 11-6
データモデル 10-16
SB 領域 7-7
Select アクセス権
定義 6-8
ビューを使用しての 6-32
列レベル 6-11
SELECT 文
修正可能なビューでの 6-28
∼に対するアクセス権 6-5, 6-8
ビューに対する 6-31
SET LOG 文、バッファ付きとバッ
ファなし 4-5
SQL コード 序 10
stores_demo データベース 序 5
superstores_demo データベー
ス 7-3
sysfragments システムカタログ
表 5-4
syssyntable システムカタログ
表 4-14
T
Temp 表 11-13
U
UNION キーワード
修正可能なビューの制限 6-28
ビューの定義での 6-27
G
H
さ行
I
た行
J
K
な行
L
M
は行
N O
ま行
P
や行
UNIQUE キーワード
CREATE TABLE 文における制
約 4-6
修正可能なビューの制限 6-28
UNIX オペレーティングシステム
デフォルトのロケール 序 4
Update アクセス権
定義 6-8
ビューを使用しての 6-32
UPDATE 文
∼に対するアクセス権 6-5, 6-8
ビューへの適用 6-29
W
WHERE キーワード、データ制約
の実行 6-31
Windows NT
デフォルトのロケール 序 4
WITH CHECK OPTION キーワー
ド、CREATE VIEW 文の 6-30
WITH ROWIDS 節、CREATE
TABLE 文の 5-37
Q
R
ら行
S
T
U
V W
X
Y
Z
わ行
Execute 6-14
Index 6-9
Insert 6-8, 6-32
Resource 6-6
Select 6-8, 6-11, 6-32
Update 6-8, 6-32
言語 6-14
システムカタログ内の符号化 6-8
自動化 6-15
データベース管理者 6-6
データベースレベル 6-5
ビューおよび 6-31 – 6-34
ビューに対する 6-32
ビューの作成が必要とされ
る 6-31
表レベル 6-7 – 6-10
付与 6-4 – 6-16
ユーザとパブリック 6-5
ルーチンレベル 6-14
列レベル 6-11
アジア言語サポート、バージョン
7.2 製品との互換性 1-10
い
X
X/Open 準拠レベル 序 14
あ
アーカイブ、およびフラグメント
化 5-6
アイコン
機能 序 8
警告 序 8
重要 序 8
準拠 序 9
製品 序 8
ヒント 序 8
プラットフォーム 序 8
アクセス、フラグメント表のデー
タへの 5-36
アクセス権 6-8
ANSI 標準準拠データベース 1-7
Connect 6-5
DBA 6-6
Delete 6-8, 6-32
一時表
およびフラグメント化 5-31
フレキシブルな 5-32
明示的 5-31
一般化キーインデックス
定義
結合された表での 11-19
式での 11-18
選択での 11-18
一般化キーインデックス、所有
権 6-7
意味整合性 3-3
入れ子
行 (ROW) 型の 7-22
コレクション (COLLECTION) 型
の 7-14
インデックス
CREATE INDEX 文を使用した作
成 4-9
ORDER BY 列での 4-10
一般化キー
説明 11-17
定義 11-18
索引 3
記号 数字 A
B C
D
あ行
E
F
か行
広域分離 5-35
昇順と降順 4-11
双方向トラバース 4-10
ソート順オプション 4-9
データウェアハウス環境 11-16
添付の定義 5-33
独立の定義 5-34
ビットマップの説明 11-16
表インデックスのフラグメント
化 5-33
複合インデックスでの ASC キー
ワードと DESC キーワードの
使用 4-12
ローカル分離 5-35
え
エラーメッセージのメッセージ
ファイル 序 11
エラーメッセージファイル 序 11
お
オペレーショナル表 11-15
オンライントランザクション処理
(OLTP) の説明 10-5
オンライン分析型処理 (OLAP) の
説明 10-5
オンラインヘルプ 序 11
オンラインマニュアル 序 11
か
外部キー 2-24
外部表を使用してのデータのロー
ド 4-17, 5-7
拡張、SQL への
ANSI 標準準拠データベースで
の 1-10
型階層
∼からの行 (ROW) 型の削除 8-9
説明 8-3
定義 8-4
ルーチンのオーバーロード 8-4
型コンストラクタ 7-10
型代用性 8-8
型付き表
G
H
さ行
I
た行
J
K
な行
L
M
は行
N O
ま行
P
や行
型なし表からの作成 7-20
定義 7-19
「フラグメント表」も参照
型なし表
型付き表への変換 7-20
定義 7-19
各国語可変長文字 (NVARCHAR)
型 3-20
各国語文字 (NCHAR) 型 3-18
可変長 (VARCHAR) 型 3-20
可変長文字 (CHARACTER
VARYING) 型 3-20
可用性、フラグメント化による向
上 5-6
環境、米国英語以外の 1-10
関係
1 対 1 2-9, 2-11
1 対多 2-9, 2-11
再帰的 2-27
実体 2-5
冗長な 2-27
接続性 2-9, 2-11
属性 2-15
存在の依存性 2-9
多対多 2-9, 2-11
多対多の解決 2-25
データモデルでの定義 2-8
任意 2-9
濃度 2-13
濃度の制約 2-9
必須 2-9
複合 2-27
マトリックスを使用した発
見 2-10
簡単な追加、説明 11-14
き
キー
外部 2-24
主 2-22
複合 2-23
キー列 2-22
記述子列 2-22
機能、この製品に新しく導入され
た 序5
機能アイコン 序 8
機能的依存性 2-30
4 Informix Guide to Database Design and Implementation
Q
R
ら行
S
T
U
V W
X
Y
わ行
キャスト 9-3 – 9-22
CAST AS キーワード 9-4
起動 9-5
行 (ROW) 型 9-6 – 9-11
コレクション (COLLECTION)
型 9-11 – 9-14
コレクション (COLLECTION) 型
の要素 9-13
削除 9-16
システム定義 9-4
タイプ 9-3
単一レベルとマルチレベル 9-21
ディスティンクト型 9-5, 9-14,
9-15
名前付き行 (ROW) 型 9-5, 9-10
名前なし行 (ROW) 型フィール
ド 9-9
明示的、起動 9-4
明示的キャストの演算子 9-4
ユーザ定義 9-18 – 9-21
暗黙的 9-4
説明 9-4
明示的 9-4
ユーザ定義の作成 9-4
行
定義 2-20
リレーショナルモデルの 2-20
行 ID の列の説明 5-22
行 (ROW) 型
入れ子にした 7-22
カテゴリ 7-9
キャスト 9-6 – 9-11
個々のフィールドのキャス
ト 9-10
業界標準への準拠 序 14
行識別子
説明 5-35
フラグメント表での 5-35, 5-37
フラグメント表での削除 5-37
フラグメント表での作成 5-37
金額 (MONEY) 型
国際金額フォーマット 3-13
説明 3-12
表示フォーマット 3-13
均等分散 5-11
Z
記号 数字 A
B C
D
あ行
E
F
か行
G
H
さ行
I
た行
J
K
な行
L
M
は行
N O
ま行
P
や行
け
し
警告のアイコン 序 8
継承 8-3 – 8-22
型代用性 8-8
単一 8-3
表階層 8-10
結合、修正可能なビューの制
限 6-28
言語アクセス権 6-14
時間隔 (INTERVAL) 型
説明 3-15
表示フォーマット 3-16
式、使用できるキャスト 9-3
式に基づいた分散スキーム
およびフラグメント除去 5-17
使用 5-9
説明 5-8
任意規則 5-10
範囲規則 5-9
式フラグメント、検索方法 5-16
次元データベース、
sales_demo 11-4
次元データモデル
作成 10-14 – 10-25
次元 10-11
次元表 10-14
次元要素 10-12
実装 11-3
小次元表 10-26
ファクト表 10-10
メジャーの定義 10-10
次元表
説明 10-14
属性の選択 10-24
システムカタログ表
syscolauth 6-8
sysfragments 5-4
systabauth 6-8
sysusers 6-8
内のアクセス権 6-8
システム定義ハッシュ分散スキー
ム
使用 5-12
説明 5-8
実数 (FLOAT) 型 3-10
実体
関連する属性 2-15
住所録例での 2-7
選択の基準 2-7
定義 2-4
∼の重要性 2-5
ビジネスルール 2-5
表により表される 2-22
命名 2-4
実体 - 関係図
記号の意味 2-17
こ
広域言語サポート (GLS) 序 4
広域分離インデックス 5-35
更新、フラグメント表の 5-25
候補キー 2-23
コード、サンプル、の表記規則 序
10
コードセット 1-10
コードセット、ISO 8859-1 序 4
固定小数点 3-12
コマンドスクリプト、データベー
スの作成 4-16
コメントアイコン 序 8
コレクション (COLLECTION) 型
入れ子にした 7-14
型コンストラクタ 7-10
型チェック 9-11
キャスト 9-11 – 9-14
要件 9-13
例 9-13
∼に対する制限 7-15
要素の型 7-10
さ
再帰的関係 2-11, 2-27
細分性、ファクト表の 10-11
参考文献 序 14
参照整合性、主キーと外部キーの
定義 2-24
参照制約、
データ型の注意事項 3-5
サンプルコードの表記 序 10
Q
R
ら行
S
T
U
V W
X
Y
Z
わ行
接続性 2-17
説明 2-17
読み方 2-18
実体のオカレンス、定義 2-16
シノニム
ANSI 標準準拠データベースで
の 1-10
連鎖 4-15
シノニム、表名に対する 4-13
集計関数、修正可能なビューの制
限 6-28
重要な説明、のアイコン 序 8
主キー
制限 2-22
定義 2-22
フラグメント表での 5-23
フラグメント表での使用 5-36
主キー制約、複合 2-23
準拠
アイコン 序 9
業界標準への 序 14
上位型 8-3
上位表 8-3
小桁実数 (SMALLFLOAT) 型 3-10
小桁整数 (SMALLINT) 型 3-8
小次元表の説明 10-26
冗長な関係 2-27
初期入力、表の 4-17
所有権 6-7
シリアル (SERIAL) 型の初期化 3-9
新機能、この製品の 序 5
す
スクラッチ表 11-13
スター結合スキーマ
「次元データモデル」も参照
説明 10-9
スマートラージオブジェクト
SB 領域の記憶域 7-7
SQL での制限 7-7
SQL での対話的使用 7-7
インポートおよびエクスポー
ト 7-8
コピー用関数 7-8
説明 7-5
フラグメント化 5-24
索引 5
記号 数字 A
B C
D
あ行
E
F
か行
G
H
さ行
I
た行
J
K
な行
L
M
は行
N O
ま行
せ
た
正規化
第 1 正規型 2-28
第 2 正規型 2-30
第 3 正規型 2-30
データモデルの 2-27
利点 2-27
ルール 2-28
ルールのまとめ 2-30
正規型 2-28
整数 (INTEGER) 型 3-8
静的表 11-15
性能、バッファ付きログ機能 4-5
製品アイコン 序 8
制約
ドメインの定義 3-3
濃度 2-9
セキュリティ
オペレーティングシステムの機能
の使用 6-3
挿入された値の制約 6-23, 6-30
データベースレベルアクセス
権 6-3
データベースをアクセス不能にす
る 6-3
ビューへのアクセスの制限 6-31
表レベルアクセス権 6-11
ユーザ定義ルーチンを使用して
の 6-3
列および行へのアクセスの制
限 6-23, 6-25
接続性、関係における 2-9, 2-11,
2-17
設定、ANSI 標準準拠の 1-6
セット (SET) 型コレクション
(COLLECTION) 型 7-11
第 1 正規型 2-28
第 2 正規型 2-30
第 3 正規型 2-30
代用性 8-8
多対多の関係 2-9, 2-11, 2-25
単一継承 8-3
そ
操作データストアの説明 10-4
属性
識別 2-15
∼の重要性 2-15
分割できない 2-15
ソフトウェアの要件 序 4
存在の依存性 2-9
P
や行
て
ディスティンクト型
キャスト 9-5, 9-14, 9-15
説明 7-4
データ
dbload ユーティリティを使用し
てのロード 4-17
外部表を使用してのロード 4-17
データ、フラグメント表でのアク
セス 5-36
データウェアハウスの説明 10-4
データウェアハウスのモデル「次
元データモデル」を参照
データ型
10 進数 (DECIMAL) 型 3-11, 3-12
8 バイトシリアル (SERIAL8)
型 3-9
8 バイト整数 (INT8) 型 3-8
ALTER TABLE 文を使用しての変
更 3-24
BLOB 7-5
CLOB 7-5
各国語可変長文字 (NVARCHAR)
型 3-20
各国語文字 (NCHAR) 型 3-18
可変長文字 (CHARACTER
VARYING) 型 3-20
可変長文字 (VARCHAR) 型 3-20
行 (ROW) 型 7-9
金額 (MONEY) 型 3-12
固定小数点 3-12
コレクション (COLLECTION)
型 7-9
参照制約での 3-5
時間隔 (INTERVAL) 型 3-15
小桁実数 (REAL) 型 3-10
小桁実数 (SMALLFLOAT)
型 3-10
6 Informix Guide to Database Design and Implementation
Q
R
ら行
S
T
U
V W
X
Y
Z
わ行
シリアル (SERIAL) 型、表階層
の 8-18
数値 3-8
スマートラージオブジェクト 7-5
整数 (INTEGER) 型 3-8
選択 3-4 – 3-7
テキスト (TEXT) 型 3-22
日時 (DATETIME) 型 3-15
バイト (BYTE) 型 3-23
日付 (DATE) 型 3-14
日付、時間に関する 3-13
複合データ型 7-8
浮動小数点 3-10
不透明 (OPAQUE) 型 7-4
文字 (CHAR) 型 3-18
データベース
ANSI 標準準拠
決定 1-5
設定 1-5
新しい表の作成 4-17
外部データベース、∼でのビュー
の使用 6-28
デモンストレーション
sales_demo 10-16, 11-4
stores_demo 序 5
superstores_demo 7-3
命名 4-4
データベース管理者 (DBA) 6-6
データベースサーバ、外部データ
ベースでのビューの許可 6-28
データベースレベルアクセス権
Connect アクセス権 6-5
Resource アクセス権 6-6
説明 6-5
データベース管理者としてのアク
セス権 6-6
データマートの説明 10-4
データモデル
1 対 1 の関係 2-11
1 対多の関係 2-11
関係の定義 2-8
作成
次元 10-14 – 10-25
リレーショナル 2-3 – 2-19
次元 10-8
実体 - 関係 2-4
住所録の例 2-6
説明 2-3
属性 2-15
記号 数字 A
B C
D
あ行
E
F
か行
G
H
さ行
I
た行
J
K
な行
L
M
は行
N O
ま行
多対多の関係 2-11
リレーショナル 2-3
テキスト (TEXT) 型
使用 3-23
説明 3-22
デフォルト値
定義 3-25
列に対する指定 3-25
デフォルトのロケール 序 4
デモンストレーションデータベー
ス 序4
∼に対する制限 7-17
命名規則 7-17
例 7-16
∼を使用した型付き表の作
成 7-19
名前なし行 (ROW) 型
説明 7-23
∼に対する制限 7-24
例 7-23
と
日時 (DATETIME) 型
国際日時フォーマット 3-17
説明 3-15
表示フォーマット 3-16
任意の実体、関係における 2-9
透過的依存性 2-30
同時実行性
シリアル (SERIAL) 型と 8 バイト
シリアル (SERIAL8) 型の
値 3-9
フラグメント化を使用した向
上 5-6
導出データ、ビューにより生成さ
れた 6-24
ドキュメントノート 序 13
ドメイン
制約 3-3
定義 2-21
特性 2-22
列の 3-3
トランザクション、ANSI 標準準拠
データベース、効果 1-6
トランザクションログ機能
ANSI 標準準拠データベース、効
果 1-7
CREATE DATABASE 文を使用し
ての確立 4-4
バッファ付き 4-5
ローディングを速くするためにオ
フにする 4-18
な
名前付き行 (ROW) 型
キャスト 9-5
削除 7-22
使用する場合 7-16
説明 7-16
としての列の定義 7-21
P
や行
に
の
濃度
関係における 2-13
制約 2-9
は
排他レベル、ANSI 標準準拠データ
ベースのデフォルト 1-8
バイト (BYTE) 型
使用 3-23
説明 3-23
ハイブリッド分散スキーム
使用 5-13
説明 5-8, 5-13
バックアップと復元の操作、フラ
グメント化 5-6
ハッシュ分散スキーム「システム
定義ハッシュ分散スキーム」を
参照
バッファ付きログ機能 4-5
バッファなしログ機能 4-5
範囲分散スキーム
使用 5-11
説明 5-8
判断、ANSI 標準準拠の 1-5
Q
R
ら行
S
T
U
V W
X
Y
Z
わ行
ひ
日付 (DATE) 型
説明 3-14
表示フォーマット 3-14
フォーマットのカスタマイ
ズ 3-14
日付 (DATE) 型、
シリアル (SERIAL) 型 3-9
必須の実体、関係における 2-9
ビットマップインデックスの説
明 11-16
ビュー
WITH CHECK OPTION キーワー
ドの使用 6-30
アクセス権 6-31 – 6-34
アクセスするときのアクセス
権 6-32
仮想列 6-29
型付き 6-25
作成 6-24
説明 6-23
重複行の更新 6-29
定義の変更時の反映 6-31
∼での行の削除 6-29
∼に行を挿入 6-29
表示されない列に挿入された
NULL 6-30
ベースとなるものが削除されると
削除される 6-27
ベースの変更の反映 6-27
変更 6-28 – 6-31
変更の制限 6-28
表
アクセス権 6-7 – 6-10
インデックスの作成 4-8
外部キー、定義 2-24
キー列 2-22
記述子列 2-22
候補キー、定義 2-23
実体を表す 2-22
所有権 6-7
データのロード 4-17
∼の行 ID 5-22
∼の主キー 2-22
表の作成 4-6
複合キー、定義 2-23
∼名でのシノニム 4-13
リレーショナルモデルの 2-20
索引 7
記号 数字 A
B C
D
あ行
E
F
か行
表インデックスフラグメント
化 5-33
表階層
新しい表の追加 8-19
継承されたプロパティ 8-12
シリアル (SERIAL) 型 8-18
説明 8-10
定義 8-12
∼のトリガ 8-17
表の動作の修正 8-15
表記規則、マニュアル 序 7
表継承の定義 8-10
標準永続表
説明 11-15
変更 11-16
表フラグメントの削除 5-31
表フラグメントの追加 5-30
表レベルアクセス権
Alter アクセス権 6-9
Index アクセス権 6-9
References アクセス権 6-10
アクセス権 6-8
定義と使用 6-7
ヒントのアイコン 序 8
ふ
ファクト表
細分性の決定 10-17
説明 10-10
∼の細分性 10-11
フィールド、行 (ROW) 型の 7-16
ブール (BOOLEAN) 型 3-17
副型 8-3
複合キー 2-23
複合データ型
カテゴリ 7-9
説明 7-8
副表 8-3
浮動少数点 3-10
不透明 (OPAQUE) 型
∼のキャスト 9-4
フラグメント
数の変更 5-26
検索から除去する場合 5-16
削除 5-31
説明 5-3
G
H
さ行
I
た行
J
K
な行
L
M
は行
N O
ま行
P
や行
単一列に基づく非重複フラグメン
ト 5-18
追加 5-30
複数列に基づく非重複フラグメン
ト 5-20
変更 5-28
フラグメント化
DB スライス役割 5-5
PDQ とともに 5-6
一時表 5-31
行識別子および 5-35
再初期化 5-25
式の評価方法 5-10
主キーの使用 5-35
スマートラージオブジェクト
の 5-24
説明 5-3
等検索 5-17
バックアップと復元の操作 5-6
範囲検索 5-17
表インデックスの 5-33
複数のコサーバ間での 5-5
フラグメントの除去 5-16
分散スキームの種類 5-8
明示的な行識別子列の作成 5-35
目標 5-6
ログ 5-7
フラグメント式、任意式 5-10
フラグメント表
1 つのフラグメント化されていな
い表からの作成 5-24
行識別子の使用 5-37
作成方法 5-21
主キーの使用 5-23, 5-36
データへのアクセス 5-36
∼の行 ID 5-22
複数のフラグメント化されていな
い表からの作成 5-23
フラグメントの削除 5-31
フラグメントの追加 5-30
変更 5-25
プラットフォームアイコン 序 8
フレックス一時表 5-33
演算子 5-32
定義 5-32
フラグメント化 5-33
フレックス演算子 5-32
プログラムグループ
ドキュメントノート 序 13
8 Informix Guide to Database Design and Implementation
Q
R
ら行
S
T
U
V W
X
Y
わ行
リリースノート 序 13
分割できない属性 2-15
分散スキーム
式に基づいた
使用 5-9
説明 5-8
任意規則 5-10
範囲規則 5-9
システム定義ハッシュ
使用 5-12
説明 5-8
定義 5-3
ハイブリッド
使用 5-13
説明 5-8
範囲
使用 5-11
説明 5-8
フラグメント数の変更 5-26
ラウンドロビン
使用 5-11
説明 5-8
へ
ぺーパーマニュアル 序 11, 序 12
ま
マシンノート 序 13
マニュアルの種類
エラーメッセージファイル 序 11
オンラインヘルプ 序 11
オンラインマニュアル 序 11
参考文献 序 14
ドキュメントノート 序 13
ペーパーマニュアル 序 11, 序 12
マシンノート 序 13
リリースノート 序 13
マルチセット (MULTISET) 型コレ
クション (COLLECTION)
型 7-13
も
文字 (CHAR) 型 3-18
Z
記号 数字 A
B C
D
E
あ行
F
か行
G
H
さ行
I
た行
J
K
な行
L
M
は行
N O
ま行
P
や行
ゆ
る
ユーザ定義キャスト、
データ型間でのキャスト 9-14
ユーザ定義データ型
ディスティンクト型 7-4
∼のキャスト 9-4
ユーザ定義ルーチン
アクセス権の付与 6-14
セキュリティの目的 6-3
ユーティリティプログラム
dbload 4-18, 11-3, 11-12
dbschema 4-16
ルーチンオーバーロード 8-7
ルーチン分析 8-9
ルーチンレベルアクセス権 6-14
要素型 7-10
ら
ろ
ラウンドロビン分散スキーム
および INSERT カーソル 5-8
および INSERT 文 5-8
使用 5-11
説明 5-8
ロウ永続表
説明 11-14
変更 11-16
ローカル分離インデックス 5-35
ロード、データの
dbload ユーティリティを使用し
ての 4-17
外部表を使用しての 4-17
ロール
CREATE ROLE 文の使用 6-17
GRANT 文を使用したアクセス権
の付与 6-17
SET ROLE 文を使用した有効
化 6-18
sysroleauth システムカタログ
表 6-18
sysusers システムカタログ
表 6-18
定義 6-16
名前付けのルール 6-17
ログ機能
データベースサーバに対する選
択 4-5
バッファ付き 4-5
バッファなし 4-5
ログ付き表
作成 11-3, 11-12
特性 11-12
り
リスト (LIST) 型コレクション
(COLLECTION) 型 7-13
リポジトリの説明 10-5
リリースノート 序 13
リレーショナルデータモデルの作
成 2-3 – 2-19
リレーショナルモデル
1 対 1 の関係 2-11
1 対多の関係 2-11
関係の解決 2-25
実体 2-4
説明 2-3
属性 2-15
多対多の関係 2-11
データの正規化 2-27
表、行、列の定義ルール 2-20
R
ら行
S
T
U
V W
X
Y
Z
わ行
ログなし表
作成 11-3, 11-12
特性 11-12
ロケール 序 4, 1-10
en_us.8859-1 序 4
デフォルト 序 4
れ
列
定義 2-20
名前付き行 (ROW) 型としての定
義 7-21
名前なし行 (ROW) 型としての定
義 7-23
フラグメント表の変更 5-25
列レベルアクセス権 6-11
連鎖、シノニムの 4-15
よ
Q
索引 9