Informix データベース設計および実装 ガイド (日本語版) (PDF:2.4MB)

DB2 IBM Informix
®
򔻐򗗠򙳰
バージョン 10.0/8.5
IBM Informix データベース設計および実装 ガイド
GB88-8666-00
(英文原典：G251-2271-00)
DB2 IBM Informix
®
򔻐򗗠򙳰
バージョン 10.0/8.5
IBM Informix データベース設計および実装 ガイド
GB88-8666-00
(英文原典：G251-2271-00)
お願い
本書および本書で紹介する製品をご使用になる前に、 241 ページの『特記事項』に記載されている情報をお読み
ください。
本書には、IBM の専有情報が含まれています。その情報は、使用許諾条件に基づき提供され、著作権により保護されて
います。本書に記載される情報には、いかなる製品の保証も含まれていません。また、本書で提供されるいかなる記述
も、製品保証として解釈すべきではありません。
IBM は、お客様が提供するいかなる情報も、お客様に対してなんら義務も負うことのない、自ら適切と信ずる方法で、
使用もしくは配布することができるものとします。
本マニュアルに関するご意見やご感想は、次の URL からお送りください。今後の参考にさせていただきます。
http://www.ibm.com/jp/manuals/main/mail.html
なお、日本 IBM 発行のマニュアルはインターネット経由でもご購入いただけます。詳しくは
http://www.ibm.com/jp/manuals/
の「ご注文について」をご覧ください。
(URL は、変更になる場合があります)
お客様の環境によっては、資料中の円記号がバックスラッシュと表示されたり、バックスラッシュが円記号と表示され
たりする場合があります。
原 典：
G251–2271–00
IBM Informix
IBM Informix Database Design and Implementation Guide
Version 10.0/8.5
発 行：
日本アイ・ビー・エム株式会社
担 当：
ナショナル・ランゲージ・サポート
第1刷 2005.1
この文書では、平成明朝体™W3、平成明朝体™W7、平成明朝体™W9、平成角ゴシック体™W3、平成角ゴシック体™
W5、および平成角ゴシック体™W7を使用しています。この(書体*)は、
（財）日本規格協会と使用契約を締結し使用して
いるものです。フォントとして無断複製することは禁止されています。
注*
平成明朝体™W3、平成明朝体™W7、平成明朝体™W9、平成角ゴシック体™W3、
平成角ゴシック体™W5、平成角ゴシック体™W7
© Copyright International Business Machines Corporation 1996, 2004. All rights reserved.
© Copyright IBM Japan 2005
目次
はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
本書について. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
対象ユーザ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
ソフトウェア要件 . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
ロケールに関する前提事項 . . . . . . . . . . . . . . . . . . . . . . . . . x
デモンストレーション データベース . . . . . . . . . . . . . . . . . . . . . . xi
Extended Parallel Server バージョン 8.50 の新機能 . . . . . . . . . . . . . . . . . . xi
Dynamic Server バージョン 10.0 の新機能. . . . . . . . . . . . . . . . . . . . . xii
表記規則 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
文字の表記規則. . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
機能、製品、およびプラットフォーム . . . . . . . . . . . . . . . . . . . . . xiii
構文ダイアグラム . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
コード例の表記規則 . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
関連マニュアル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii
インストール ガイド . . . . . . . . . . . . . . . . . . . . . . . . . . xviii
オンライン ノート . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii
Informix エラー メッセージ集 . . . . . . . . . . . . . . . . . . . . . . . . xx
マニュアル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi
オンライン ヘルプ . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi
アクセシビリティ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi
IBM Informix Dynamic Server バージョン 10.0 および CSDK バージョン 2.90 マニュアル セット
xxii
業界標準への準拠 . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxv
第 1 部 データベース設計と実装の基本 . . . . . . . . . . . . . . . . . . 1
第 1 章 データベースの計画 . . . . . . . . . . . . . . . . . . . . . . . . . 3
データベースのデータ モデルの選択 . . . . . . . . . . . . . . . . . . . . . . . 3
ANSI 標準準拠データベースの使用法 . . . . . . . . . . . . . . . . . . . . . . . 4
ANSI 標準準拠データベースと非 ANSI 標準準拠データベースとの相違点 . . . . . . . . . 5
既存のデータベースが ANSI 標準準拠であるかの判断 . . . . . . . . . . . . . . . . 9
使用するデータベース専用の言語処理環境の使用法 (GLS) . . . . . . . . . . . . . . . . 9
第 2 章 リレーショナル データ モデルの作成
データ モデルの作成 . . . . . . . . .
実体 - 関係データ モデルの概要 . . . . .
主なデータ オブジェクトの識別と定義 . . .
エンティティの識別 . . . . . . . .
関係の定義 . . . . . . . . . . .
属性の識別 . . . . . . . . . . .
データ オブジェクトの図式化 . . . . . .
E-R ダイアグラムの読取り . . . . . .
© Copyright IBM Corp. 1996, 2004
. . . . . . . . . . . . . . . . . . . 11
. . . . . . . . . . . . . . . . . . . 12
. . . . . . . . . . . . . . . . . . . 12
. . . . . . . . . . . . . . . . . . . 13
. . . . . . . . . . . . . . . . . . . 13
. . . . . . . . . . . . . . . . . . . 16
. . . . . . . . . . . . . . . . . . . 22
. . . . . . . . . . . . . . . . . . . 24
. . . . . . . . . . . . . . . . . . . 25
iii
住所録の例 . . . . . . . . . . . .
E-R データ オブジェクトの関係構造体への変換 .
表、行、列の定義 . . . . . . . . . .
表のキーの決定 . . . . . . . . . . .
関係の解決 . . . . . . . . . . . . .
m:n 関係の解決. . . . . . . . . . .
その他の特別な関係の解決 . . . . . . .
データ モデルの正規化 . . . . . . . . .
第 1 正規形 . . . . . . . . . . . .
第 2 正規形 . . . . . . . . . . . .
第 3 正規形 . . . . . . . . . . . .
正規化ルールのまとめ . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
26
27
27
29
32
32
33
34
35
36
37
37
第 3 章 データ型の選択 . . . . . . . . . . . . . . . . . . . . . . . . . . 39
ドメインの定義 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
データ型 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
データ型の選択 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
数値型 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
日付、時間に関するデータ型 . . . . . . . . . . . . . . . . . . . . . . . . 49
ブール データ型 (IDS) . . . . . . . . . . . . . . . . . . . . . . . . . . 53
文字 (CHARACTER) 型 (GLS). . . . . . . . . . . . . . . . . . . . . . . . 53
NULL 値 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
デフォルト値 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
チェック制約 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
参照制約 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
第 4 章 リレーショナル データ モデルの実装 . . . . . . . . . . . . . . . . . . . 61
データベースの作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
CREATE DATABASE の使用 . . . . . . . . . . . . . . . . . . . . . . . . 62
CREATE TABLE の使用. . . . . . . . . . . . . . . . . . . . . . . . . . 64
CREATE INDEX の使用 . . . . . . . . . . . . . . . . . . . . . . . . . . 66
表名のシノニムの使用 . . . . . . . . . . . . . . . . . . . . . . . . . . 67
シノニム連鎖の使用 . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
コマンド スクリプトの使用 . . . . . . . . . . . . . . . . . . . . . . . . 69
データベースへのデータの追加 . . . . . . . . . . . . . . . . . . . . . . . . 70
他の Informix データベースからのデータの移動 . . . . . . . . . . . . . . . . . . 72
ソース データを表にロードする . . . . . . . . . . . . . . . . . . . . . . . 72
一括ロード操作の実行 . . . . . . . . . . . . . . . . . . . . . . . . . . 72
第 2 部 データベースの管理 . . . . . . . . . . . . . . . . . . . . . . 75
第 5 章 表フラグメント化ストラテジ
フラグメント化とは . . . . . .
フラグメント化を使用する理由 .
フラグメント化の責任者 . . . .
拡張フラグメント化 (XPS) . . .
iv
. . . . . . . . . . . . . . . . . . . . . . 77
. . . . . . . . . . . . . . . . . . . . . . 78
. . . . . . . . . . . . . . . . . . . . . . 79
. . . . . . . . . . . . . . . . . . . . . . 79
. . . . . . . . . . . . . . . . . . . . . . 79
IBM Informix データベース設計および実装 ガイド
フラグメント化とロギング . . . . . . . . . . . .
表のフラグメント化のための分散スキーム . . . . . . . .
式ベース分散スキーム . . . . . . . . . . . . .
ラウンドロビン分散スキーム . . . . . . . . . . .
範囲分散スキーム (XPS) . . . . . . . . . . . . .
システム定義ハッシュ分散スキーム (XPS) . . . . . . .
ハイブリッド分散スキーム (XPS) . . . . . . . . . .
フラグメント表の作成 . . . . . . . . . . . . . .
フラグメント表を新たに作成する . . . . . . . . . .
フラグメント化されていない表からのフラグメント表の作成 .
フラグメント表内の行 ID . . . . . . . . . . . .
スマート ラージ オブジェクトのフラグメント化 (IDS) . .
フラグメント化ストラテジの修正 . . . . . . . . . . .
フラグメント化ストラテジの再初期化 . . . . . . . .
Dynamic Server のフラグメント化ストラテジの修正 . . .
XPS のフラグメント化ストラテジの修正 . . . . . . .
フラグメント アクセス権の付与と取消し (IDS) . . . . . .
第 6 章 データベース サーバのアクセス権の付与と制限.
SQL を使用したデータへのアクセスの制限 . . . . .
データベースへのアクセスの制御 . . . . . . . . .
アクセス権の付与 . . . . . . . . . . . . . .
データベース レベル アクセス権 . . . . . . .
所有権 . . . . . . . . . . . . . . . .
表レベル アクセス権 . . . . . . . . . . .
列レベル アクセス権 . . . . . . . . . . .
型レベル アクセス権 . . . . . . . . . . .
ルーチン レベル アクセス権 . . . . . . . . .
言語レベル アクセス権 . . . . . . . . . . .
アクセス権の自動化 . . . . . . . . . . . .
実行時に現行のロールを判別する方法 . . . . . .
SPL ルーチンによるデータへのアクセスの制御. . . .
データの読込みの制限 . . . . . . . . . . .
データへの変更の制限 . . . . . . . . . . .
データへの変更の監視 . . . . . . . . . . .
オブジェクト作成の制限 . . . . . . . . . .
ビューの使用 . . . . . . . . . . . . . . .
ビューの作成 . . . . . . . . . . . . . .
ビューに関する制限 . . . . . . . . . . . .
ビューを用いたデータの変更 . . . . . . . . .
アクセス権とビュー . . . . . . . . . . . . .
ビューの作成時のアクセス権 . . . . . . . . .
ビューを使用するときのアクセス権 . . . . . .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
80
80
81
83
83
84
85
85
86
87
88
89
90
90
91
92
95
. 97
. 98
. 98
. 99
. 100
. 102
. 102
. 105
. 106
. 108
. 108
. 109
. 113
. 113
. 113
. 114
. 115
. 116
. 116
. 117
. 119
. 121
. 124
. 124
. 124
第 7 章 分散問合せの使用方法 . . . . . . . . . . . . . . . . . . . . . . . . 127
分散問合せの概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
目次
v
単一の Dynamic Server インスタンスのデータベース間の分散問合せ
分散問合せの調整元と関係先 . . . . . . . . . . . . . .
分散問合せを使用するためのデータベース サーバの構成 . . . . .
分散問合せの構文 . . . . . . . . . . . . . . . . . .
リモート サーバおよびデータベースへのアクセス . . . . . . .
リモート オブジェクトのアクセスに有効な文 . . . . . . . .
遠隔表へのアクセス . . . . . . . . . . . . . . . . .
その他のリモート操作 . . . . . . . . . . . . . . . .
分散問合せの監視 . . . . . . . . . . . . . . . . . .
サーバ環境と分散問合せ . . . . . . . . . . . . . . . .
PDQPRIORITY 環境変数 . . . . . . . . . . . . . . .
DEADLOCK_TIMEOUT . . . . . . . . . . . . . . . .
データベース アクセスの制限 . . . . . . . . . . . . . .
トランザクション処理 . . . . . . . . . . . . . . . . .
排他レベル . . . . . . . . . . . . . . . . . . . .
DEADLOCK_TIMEOUT および SET LOCK MODE . . . . . .
2 相コミットと復旧 . . . . . . . . . . . . . . . . .
サーバ間の互換性に関する問題 (XPS) . . . . . . . . . . . .
バイト (BYTE) 型およびテキスト (TEXT) 型 . . . . . . . .
その他の制限 . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
128
128
129
129
130
130
131
132
133
133
133
133
134
134
134
134
135
135
135
135
第 3 部 オブジェクト リレーショナル データベース . . . . . . . . . . . . 137
第 8 章 Dynamic Server での拡張データ型の作成と使用. . . . . . . . . . . . . . . 139
Informix のデータ型 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
基本データ型または最小のデータ型 . . . . . . . . . . . . . . . . . . . . . 141
事前定義型 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
拡張データ型 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
スマート ラージ オブジェクト . . . . . . . . . . . . . . . . . . . . . . . . 145
BLOB 型 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
CLOB 型 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
スマート ラージ オブジェクトの使用 . . . . . . . . . . . . . . . . . . . . . 146
スマート ラージ オブジェクトのコピー . . . . . . . . . . . . . . . . . . . . 147
複合データ型 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
コレクション (COLLECTION) 型 . . . . . . . . . . . . . . . . . . . . . . 148
名前付き行型 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
名前なし行型 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
第 9 章 Dynamic Server による型継承と表継承.
継承について . . . . . . . . . . . . .
型継承 . . . . . . . . . . . . . . .
型階層の定義 . . . . . . . . . . . .
型階層内の型に対するルーチンのオーバーロード
継承と型代用性 . . . . . . . . . . .
型階層からの名前付き行型の削除 . . . . .
表継承 . . . . . . . . . . . . . . .
vi
IBM Informix データベース設計および実装 ガイド
. . . . . . . . . . . . . . . . . 163
. . . . . . . . . . . . . . . . . 163
. . . . . . . . . . . . . . . . . 164
. . . . . . . . . . . . . . . . . 164
. . . . . . . . . . . . . . . . . 166
. . . . . . . . . . . . . . . . . 167
. . . . . . . . . . . . . . . . . 168
. . . . . . . . . . . . . . . . . 169
型階層と表階層との関係 . .
表階層の定義 . . . . . .
表階層内の表の動作の継承 .
表階層内の表の動作の修正 .
表階層内のシリアル (SERIAL)
表階層への表の追加 . . . .
表階層内の表の削除 . . . .
表階層内の表の構造の変更 .
表階層内の表の問合せ . . .
表階層内の表のビューの作成 .
.
.
.
.
型
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
第 10 章 Dynamic Server でのユーザ定義キャストの作成と使用 . . . . . .
キャストとは . . . . . . . . . . . . . . . . . . . . . . . .
ユーザ定義キャストの作成 . . . . . . . . . . . . . . . . . .
キャストの起動 . . . . . . . . . . . . . . . . . . . . . .
ユーザ定義キャストに関する制限 . . . . . . . . . . . . . . . .
行 (ROW) 型のキャスト . . . . . . . . . . . . . . . . . . . .
名前付き行型と名前なし行型の間のキャスト . . . . . . . . . . . .
名前なし行型どうしのキャスト . . . . . . . . . . . . . . . . .
名前付き行型の間でのキャスト . . . . . . . . . . . . . . . . .
フィールドでの明示的キャストの使用 . . . . . . . . . . . . . . .
行 (ROW) 型の各フィールドのキャスト . . . . . . . . . . . . . .
コレクション (COLLECTION) 型のキャスト. . . . . . . . . . . . . .
コレクション (COLLECTION) 型の変換の制限 . . . . . . . . . . . .
要素型が異なるコレクション . . . . . . . . . . . . . . . . . .
リレーショナル データから マルチセット (MULTISET) 型コレクションへの変換
ディスティンクト (DISTINCT) 型のキャスト . . . . . . . . . . . . .
ディスティンクト (DISTINCT) 型での明示的キャストの使用 . . . . . . .
ディスティンクト (DISTINCT) 型とソース型の間のキャスト . . . . . . .
ディスティンクト (DISTINCT) 型のキャストの追加と削除 . . . . . . . .
スマート ラージ オブジェクトへのキャスト . . . . . . . . . . . . .
ユーザ定義キャストのキャスト関数の作成 . . . . . . . . . . . . . .
名前付き行型間でのキャストの例 . . . . . . . . . . . . . . . .
ディスティンクト (DISTINCT) 型間でのキャストの例 . . . . . . . . .
マルチレベル キャスト . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
169
170
171
172
174
175
176
176
177
177
. . . . . . 179
. . . . . . 180
. . . . . . 180
. . . . . . 181
. . . . . . 181
. . . . . . 182
. . . . . . 183
. . . . . . 183
. . . . . . 184
. . . . . . 184
. . . . . . 186
. . . . . . 186
. . . . . . 187
. . . . . . 187
. . . . . . 188
. . . . . . 188
. . . . . . 189
. . . . . . 189
. . . . . . 190
. . . . . . 191
. . . . . . 192
. . . . . . 192
. . . . . . 193
. . . . . . 194
第 4 部 次元データベース . . . . . . . . . . . . . . . . . . . . . . . 197
第 11 章 次元データ モデルの作成
データ ウェアハウスの概要 . . .
次元データベースを作成する理由
次元データとは . . . . . .
次元データ モデルのコンセプト . .
ファクト表 . . . . . . . .
データ モデルの次元 . . . .
次元データ モデルの作成 . . . .
. . . . . . . . . . . . . . . . . . . . . . 199
. . . . . . . . . . . . . . . . . . . . . . 200
. . . . . . . . . . . . . . . . . . . . . . 201
. . . . . . . . . . . . . . . . . . . . . . 202
. . . . . . . . . . . . . . . . . . . . . . 204
. . . . . . . . . . . . . . . . . . . . . . 205
. . . . . . . . . . . . . . . . . . . . . . 206
. . . . . . . . . . . . . . . . . . . . . . 208
目次
vii
ビジネス プロセスの選択 . . . . .
ビジネス プロセスの要約 . . . . .
ファクト表の細分性の決定 . . . .
次元と階層の明確化 . . . . . . .
ファクト表のメジャー (基準) の選択 .
正規化の防止 . . . . . . . . .
次元表の属性の選択 . . . . . . .
次元データ モデルの共通する問題の処理 .
次元表の属性数を最小限に抑える . .
時々変更する次元の処理 . . . . .
スノーフレーク スキーマの使用 . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
208
209
210
211
214
215
216
217
217
218
219
第 12 章 次元データベースの実装 (XPS) . . . . . . . . . . . . . . . . . . . . 221
次元データベース sales_demo の実装 . . . . . . . . . . . . . . . . . . . . . . 221
CREATE DATABASE の使用. . . . . . . . . . . . . . . . . . . . . . . . 222
CREATE TABLE 文を使用した次元表およびファクト表の作成 . . . . . . . . . . . . 222
データ ソースからデータベースへのデータのマッピング . . . . . . . . . . . . . . 224
次元データベースへのデータのロード . . . . . . . . . . . . . . . . . . . . . 225
データベース sales_demo の作成 . . . . . . . . . . . . . . . . . . . . . . 227
次元データベースのテスト . . . . . . . . . . . . . . . . . . . . . . . . 227
Extended Parallel Server のログ付き表とログなし表 . . . . . . . . . . . . . . . . . 228
表タイプの選択 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
表のタイプの切替え . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
データ ウェアハウス環境のインデックス . . . . . . . . . . . . . . . . . . . . . 232
データ ウェアハウス環境での GK インデックスの使用 . . . . . . . . . . . . . . . . 233
選択での GK インデックスの定義 . . . . . . . . . . . . . . . . . . . . . . 233
式での GK インデックスの定義 . . . . . . . . . . . . . . . . . . . . . . . 234
結合された表での GK インデックスの定義 . . . . . . . . . . . . . . . . . . . 234
第 5 部 付録 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
付録. アクセシビリティ .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 237
特記事項
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 241
索引 .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 245
viii
.
IBM Informix データベース設計および実装 ガイド
はじめに
本書について. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
対象ユーザ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
ソフトウェア要件 . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
ロケールに関する前提事項 . . . . . . . . . . . . . . . . . . . . . . . . . x
デモンストレーション データベース . . . . . . . . . . . . . . . . . . . . . . xi
Extended Parallel Server バージョン 8.50 の新機能 . . . . . . . . . . . . . . . . . . xi
Dynamic Server バージョン 10.0 の新機能. . . . . . . . . . . . . . . . . . . . . xii
表記規則 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
文字の表記規則. . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
機能、製品、およびプラットフォーム . . . . . . . . . . . . . . . . . . . . . xiii
構文ダイアグラム . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
コマンド行構文ダイアグラムの読み方 . . . . . . . . . . . . . . . . . . . . xv
キーワードおよび句読点 . . . . . . . . . . . . . . . . . . . . . . . . xvi
識別子と名前 . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
コード例の表記規則 . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
関連マニュアル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii
インストール ガイド . . . . . . . . . . . . . . . . . . . . . . . . . . xviii
オンライン ノート . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii
オンライン ノートの入手先 . . . . . . . . . . . . . . . . . . . . . . . xix
オンライン ノートのファイル名 . . . . . . . . . . . . . . . . . . . . . . xx
Informix エラー メッセージ集 . . . . . . . . . . . . . . . . . . . . . . . . xx
マニュアル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi
オンライン マニュアル . . . . . . . . . . . . . . . . . . . . . . . . . xxi
ペーパー マニュアル. . . . . . . . . . . . . . . . . . . . . . . . . . xxi
オンライン ヘルプ . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi
アクセシビリティ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi
IBM Informix Dynamic Server バージョン 10.0 および CSDK バージョン 2.90 マニュアル セット
xxii
業界標準への準拠 . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxv
はじめに
ここでは、本書に記載する情報の概要を説明し、使用する表記規則を示します。
本書について
このマニュアルは、Informix データベースの設計、実装、管理に役立つ情報を提供しま
す。具体的には、データベース設計のさまざまなアプローチを示すデータ モデルについ
て説明し、SQL (Structured Query Language: 構造化問合せ言語) を使用してデータベー
スを実装および管理する方法について示します。
© Copyright IBM Corp. 1996, 2004
ix
本書の他のにも、Informix 製品による SQL 実装について説明しているマニュアルがあ
ります。SQL とストアド プロシジャ言語 (SPL) の基本的なルーチン、および高度なル
ーチンを使用して、データベースのデータにアクセスし、操作する方法については、
「IBM Informix: SQL ガイド: チュートリアル」を参照してください。SQL および SPL
の全構文の説明については、「IBM Informix: SQL ガイド: 構文」を参照してくださ
い。言語文を除く SQL 文に関する情報については、「IBM Informix: SQL ガイド: 参
照」を参照してください。
対象ユーザ
本書は、次のユーザを対象としています。
v データベース管理者
v データベース サーバ管理者
v データベース アプリケーションのプログラマ
このマニュアルは、ユーザが次の知識や経験を保有していることを前提としています。
v 使用するコンピュータ、オペレーティング システム、およびオペレーティング シス
テムが提供するユーティリティに関する実際的な知識
v リレーショナル データベース操作の経験、またはデータベースの概念の理解
v コンピュータ プログラミングの経験
リレーショナル データベース、SQL、またはご使用のオペレーティング システムに関
する補足情報が必要な場合は、「IBM Informix: Dynamic Server スタートアップ ガイ
ド」の、ご使用のデータベース サーバの項目を参照してください。
ソフトウェア要件
本書は、データベース サーバが以下のいずれかであることを前提としています。
v IBM Informix Dynamic Server バージョン 10.0
v IBM Informix Extended Parallel Server バージョン 8.50
ロケールに関する前提事項
IBM Informix 製品は、多くの言語、国/地域別情報、およびコード セットをサポートし
ています。文字セット、照合、数値データの表記、通貨、日付、および時刻に関する情
報はすべて、広域言語サポート (GLS) ロケールと呼ばれる 1 つの環境にまとめられて
います。
本書に記載する例は、デフォルト ロケール en_us.8859-1 を使用することを前提として
います。このロケールは、日付、時刻、および通貨について米国英語 (U.S. English) の
表記規則をサポートします。さらにこのロケールでは、ASCII コード セットと、é、è、
および ñ などの多くの 8 ビット文字を含む ISO 8859-1 コード セットをサポートしま
す。
x
IBM Informix データベース設計および実装 ガイド
データまたは SQL 識別子でデフォルト以外の文字を使用する場合、または文字データ
をデフォルト以外の規則で照合する場合は、適切な非デフォルト ロケールを指定する必
要があります。
デフォルト以外のロケールの指定方法、追加構文、および GLS ロケールに関するその
他の考慮事項については、「IBM Informix: GLS ユーザーズ ガイド」を参照してくださ
い。
デモンストレーション データベース
データベース サーバ製品に付属する DB–Access ユーティリティには、以下のデモンス
トレーション データベースが 1 つ以上含まれます。
v すべての IBM Informix データベースを対象に、stores_demo データベースは、架空
のスポーツ用品卸し売り業者の例を使用してリレーショナル スキーマについて説明
しています。IBM Informix の資料に記載されている例の多くは、stores_demo データ
ベースを基にしています。
v Extended Parallel Server を対象に、sales_demo データベースはデータ ウェアハウジ
ング アプリケーションの次元スキーマを説明しています。次元データ モデルという
概念については、この「IBM Informix: データベース設計および実装 ガイド」の第 4
部を参照してください。
v Dynamic Server を対象に、superstores_demo データベースはオブジェクト リレーシ
ョナル スキーマについて説明しています。superstores_demo データベースには、拡
張データ型、型と表の継承、およびユーザ定義ルーチンについての例が含まれていま
す。
デモンストレーション データベースの作成およびデータの追加については、
「IBM Informix: DB-Access ユーザーズ ガイド」を参照してください。これらのデータ
ベースとその内容については、「IBM Informix: SQL ガイド: 参照」を参照してくださ
い。
デモンストレーション データベースのインストールに使用するスクリプトは、UNIX プ
ラットフォームの場合は $INFORMIXDIR/bin ディレクトリ、Windows 環境の場合
は、%INFORMIXDIR%¥bin ディレクトリにあります。
Extended Parallel Server バージョン 8.50 の新機能
IBM Informix Extended Parallel Server バージョン 8.50 の新機能については、
「IBM Informix: Dynamic Server スタートアップ ガイド、バージョン 8.50」を参照して
ください。
はじめに
xi
Dynamic Server バージョン 10.0 の新機能
IBM Informix Dynamic Server バージョン 10.0 の新機能について詳しくは、バージョン
10.0 の「IBM Informix: Dynamic Server スタートアップ ガイド」を参照してください。
表記規則
ここでは、このマニュアルで使用される、以下の表記規則について説明します。これら
の表記規則を把握しておくと、本書および他の関連マニュアルの内容を理解するのに役
立ちます。
以下のような表記規則があります。
v 文字の表記規則
v その他の表記規則
v 構文ダイアグラム
v コマンド行の表記規則
v コード例の表記規則
文字の表記規則
本書では、新しい用語、画面表示、コマンド構文などを表記するのに、以下の規則を使
用します。
xii
表記規則
意味
KEYWORD
プログラミング言語の文中では、主要な要素 (キーワード) は、すべ
て大文字のセリフ フォントで表記されます。
イタリック体
イタリック体
イタリック体
本文中では、新しい用語および強調語がイタリック体で表記されま
す。構文とコードの例では、ユーザが指定する変数値は、イタリック
体で表示されます。
太文字
太文字
プログラム エンティティの名前 (クラス、イベント、および表)、環
境変数、ファイルやパス名、およびインターフェイス要素 (アイコ
ン、メニュー項目、およびボタンなど) が太文字で表示されます。
モノスペース
モノスペース
製品が表示する情報、およびユーザが入力する情報は、モノスペース
で表記されます。
KEYSTROKE
ユーザが押すキーは、大文字のサンセリフ フォントで表記されます
>
この記号は、メニュー項目を表します。例えば、「ツール」>「オプ
ション」を選択する、という記述は、「ツール」メニューから「オプ
ション」項目を選択することを指します。
IBM Informix データベース設計および実装 ガイド
ヒント: 文字の「入力」、またはコマンドの「実行」を指示された場合は、入力直後に
Enter を押してください。ただし、テキストを「手入力」、または他のキーを
「押す」ように指示された場合は、Enter を押す必要はありません。
機能、製品、およびプラットフォーム
機能、製品、およびプラットフォームのマークアップは、機能、製品、またはプラット
フォームに固有な情報を表します。このマークアップの例を次に示します。
Dynamic Server
IBM Informix Dynamic Server 固有の情報を示します。
Dynamic Server の終り
Extended Parallel Server
IBM Informix Extended Parallel Server 固有の情報を示します
Extended Parallel Server の終り
UNIX のみ
UNIX プラットフォーム固有の情報を示します。
UNIX のみ の終り
Windows のみ
Windows 環境固有の情報を示します。
Windows のみ の終り
これらのマークアップは、セクション内の 1 つ以上のパラグラフに適用される場合があ
ります。セクション全体が特定の製品またはプラットフォームに適用する場合は、次の
ように見出しテキストで示します。
表のソート (Linux のみ)
構文ダイアグラム
本書で使用する構文ダイアグラムは、以下のコンポーネントで構成されます。このダイ
アグラムは、システム レベルのコマンドを除くすべてのコマンドと、文の構文を表しま
す。
はじめに
xiii
注: 2004 年以降、構文ダイアグラムは IBM 標準に準拠する形に再フォーマットされま
した。
SQL 文およびコマンド行文を表す構文ダイアグラムは、以下のように変更されました。
v 文の最初と最後には、終端の縦線に代わり、二重矢印が使用されます。
v 構文セグメント ダイアグラムの最初と最後には、矢印の代わりに縦線が使用されま
す。
v ループを繰り戻す回数は、ゲート記号内の数字としてではなく、ダイアグラムの脚注
に表示されます。
v 構文が複数行にわたる場合は、同じ行にループ ダウンするのではなく、次の行に示
されます。
v 製品または条件固有のパスは、アイコンではなく、ダイアグラムの脚注に表示されま
す。
次の表に、構文ダイアグラムのコンポーネントを示します。
コンポーネントの PDF での表示
xiv
コンポーネントの HTML での表示
説明
>>----------------------
文の開始を示します。
----------------------->
文が次行に続くことを示し
ます。
>-----------------------
文が前行からの続きである
ことを示します。
-----------------------><
文の終端を示します。
--------SELECT----------
必須項目です。
--+-----------------+--’------LOCAL------’
オプションの項目です。
---+-----ALL-------+--+--DISTINCT-----+
’---UNIQUE------’
選択項目のある必須項目で
す。項目を 1 つのみ指定
する必要があります。
---+------------------+--+--FOR UPDATE-----+
’--FOR READ ONLY--’
オプショナル項目がメイン
行の下に選択肢で表示さ
れ、そのいずれかを指定で
きます。
IBM Informix データベース設計および実装 ガイド
コンポーネントの PDF での表示
コンポーネントの HTML での表示
説明
.---NEXT---------.
----+----------------+--+---PRIOR--------+
’---PREVIOUS-----’
メイン行の下にある値はオ
プションで、そのいずれか
を指定できます。項目を指
定しない場合、行の上にあ
る値がデフォルトとして使
用されます。
.-------,-----------.
V
|
---+-----------------+--+---index_name---+
’---table_name---’
オプションの項目です。複
数の項目を指定できます。
各項目はコンマで区切る必
要があります。
>>-| Table Reference |-><
構文セグメントの参照で
す。
Table Reference
構文セグメントです。
|--+-----view--------+--|
+------table------+
’----synonym------’
コマンド行構文ダイアグラムの読み方
以下のコマンド行構文ダイアグラムでは、前セクションの表にリストした要素をいくつ
か使用しています。
No-Conversion ジョブの作成
onpladm create job
job
-n -d
-p
-t
device -D
database
project
table (1)
Setting the Run Mode
-S
server
-T
target
注:
1
4 ページ参照
はじめに
xv
このダイアグラムの 2 行目には、「Setting the Run Mode」という名前のセグメントが
あります (ダイアグラムの脚注に示す 4 ページに詳細を記載)。このセグメントを、次
のセグメント ダイアグラムで示します (ダイアグラムにはセグメント開始と終了のコン
ポーネントを使用します)。
Setting the Run Mode:
l
c
-f
d
p
a
u
n
N
コマンドを正しく入力するには、左上のコマンドから開始します。次に、ダイアグラム
を右へ進み、必要な要素を入力します。ダイアグラムの要素は、大文字と小文字を区別
をする必要があります。
「No-Conversion ジョブの作成」ダイアグラムは、以下の手順を示しています。
1. onpladm create job を入力し、次にジョブ名を入力します。
2. 任意で -p と入力し、プロジェクト名を入力します。
3. 以下の必須要素を入力します。
v -n
v -d およびデバイス名
v -D およびデータベース名
v -t および表名
4. オプションで、以下の中から 1 つ以上の要素を選択し、任意の回数まで繰り返すこ
とができます。
v -S およびサーバ名
v -T およびターゲット サーバ名
v run mode。run mode を設定するには、Setting the Run Mode セグメント ダイア
グラムに従います。まず -f を入力し、次にオプションで d、p、または a を入力
し、最後にオプションで l または u を入力します。
5. 終端記号までダイアグラムを読み進めます。
これで、ダイアグラムが終了します。
キーワードおよび句読点
システム レベルのコマンドを除き、すべてのコマンドおよび文に予約された単語です。
構文ダイアグラム内のキーワードは、大文字で表記されます。コマンド内のキーワード
には、大文字と小文字の両方を使用できます。ただし、構文ダイアグラム内のキーワー
ドと完全に一致するスペルにしてください。
xvi
IBM Informix データベース設計および実装 ガイド
また、構文やコマンド内の句読点も、構文ダイアグラム内と一致するように使用しなけ
ればなりません。
識別子と名前
変数は、構文ダイアグラムや例の中で、識別子や名前の代わりに使用されます。変数は
コンテキストによって、任意の名前、識別子、リテラルに置き換えられます。また変数
は、追加構文ダイアグラムで拡張される複合構文要素を表すためにも使用されます。構
文ダイアグラム、例、またはテキスト内で使用される変数は、小文字のイタリック体 で
表記されます。
次の構文ダイアグラムでは、変数を使用して、単純な SELECT 文の一般的な形を示し
ています。
SELECT column_name FROM table_name
この形の SELECT 文を作成する場合は、変数 column_name および table_name を特定
の列名と表名に置き換えます。
コード例の表記規則
このマニュアルでは、SQL コードの例が随所に使用されています。特に明記されていな
い限り、記載されるコードは、特定の IBM 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 文の詳細については、
製品に付属するマニュアルを参照してください。
はじめに
xvii
関連マニュアル
詳しくは、以下のマニュアル セットを参照してください。
v インストール ガイド
v オンライン ノート
v Informix エラー メッセージ集
v マニュアル
v オンライン ヘルプ
インストール ガイド
インストール ガイドは、製品 CD の /doc ディレクトリ、または IBM Web サイトか
らダウンロードした場合には製品の圧縮ファイルの /doc ディレクトリにあります。ま
た、インストール ガイドは、IBM Informix Online Documentation サイト
(http://www.ibm.com/software/data/informix/pubs/library/) からも入手できます。
オンライン ノート
以下のセクションでは、このマニュアルの情報を補足するオンライン ファイルについて
説明します。IBM Informix 製品を使用する前に、これらのファイルを参照してくださ
い。このファイルには、アプリケーションおよびパフォーマンスに関する重要な情報が
含まれています。
xviii
IBM Informix データベース設計および実装 ガイド
オンライン ファイル
説明
フォーマット
TOC ノート
HTML
TOC (目次) ノート ファイルには、リリース
ノート、修正された問題と既知の問題について
のファイル、および個々のマニュアル タイト
ルに該当するすべてのドキュメント ノート フ
ァイルへの、ハイパーリンクの包括的なディレ
クトリが記載されています。
ドキュメント ノート
それぞれのマニュアルのドキュメント ノート HTML、テキ
には、マニュアルに記載されている情報を補足 スト
する重要な情報と修正、マニュアルの出版後に
変更された情報が含まれています。
リリース ノート
リリース ノート ファイルには、IBM Informix HTML、テキ
製品の以前バージョンとの機能の違いと、その スト
違いが現行の製品に及ぼす影響について記載し
ています。製品により、このファイルに既知の
問題とその修正処置も含まれる場合がありま
す。
マシン ノート
(Windows 以外のプラットフォームのみ) マシ テキスト
ン ノート ファイルには、ご使用のコンピュー
タで IBM Informix 製品を構成して使用するた
めに行うべきプラットフォーム固有の処置につ
いて記載しています。
修正された問題と既知
の問題についてのファ
イル
このテキスト ファイルには、現行バージョン テキスト
で確認されている問題がリストされています。
また、ユーザから報告された現行バージョンお
よび以前のバージョンで修正された問題もリス
トされています。
オンライン ノートの入手先
オンライン ノートは IBM Informix Online Documentation サイト
(http://www.ibm.com/software/data/informix/pubs/library/) から入手できます。さらに、以下
に説明するように、これらのファイルをインストール後、またはインストール前に取得
できます。
インストール前
すべてのオンライン ノートは、製品 CD の /doc ディレクトリにあります。ドキュメ
ント ノート、リリース ノート、および修正された問題と既知の問題についてのファイ
ルにアクセスする最も簡単な方法は、TOC ノート ファイルからのハイパーリンクを介
したアクセスです。
はじめに
xix
マシン ノート、および修正された問題と既知の問題についてのファイルは、テキスト
フォーマットでのみ提供されます。
インストール後
デフォルト ロケールの UNIX プラットフォームでは、ドキュメント ノート、リリース
ノート、およびマシン ノートのファイルは、$INFORMIXDIR/release/en_us/0333 ディ
レクトリにあります。
Dynamic Server
Windows では、ドキュメント ノートおよびリリース ノートは Informix フォルダに格
納されています。このフォルダを表示するには、タスクバーから、「スタート」>「プ
ログラム」>「IBM Informix Dynamic Server version」>「Documentation Notes」また
は「Release Notes」を選択します。
マシン ノートは、Windows プラットフォームには適用されません。
Dynamic Server の終り
オンライン ノートのファイル名
オンライン ノートのファイル形式は以下のとおりです。
オンライン ファイル
ファイル形式
例
TOC ノート
prod_os_tocnotes_version.html
ids_win_tocnotes_10.0.html
ドキュメント ノート
prod_bookname_docnotes_version.html/txt
ids_hpl_docnotes_10.0.html
リリース ノート
prod_os_relnotes_version.html/txt
ids_unix_relnotes_10.0.txt
マシン ノート
prod_machine_notes_version.txt
ids_machine_notes_10.0.txt
修正された問題と既知の問 prod_defects_version.txt
題についてのファイル
ids_win_fixed_and_known
_defects_version.txt
ids_defects_10.0.txt
client_defects_2.90.txt
ids_win_fixed_and_known
_defects_10.0.txt
Informix エラー メッセージ集
このファイルは、Informix 製品のバージョン番号別のエラー メッセージおよび修正処置
の包括的なインデックスです。
xx
IBM Informix データベース設計および実装 ガイド
UNIX プラットフォームでは、finderr コマンドを使用してエラー メッセージおよび修
正処置を確認します。
Dynamic Server
Windows では、Informix エラー メッセージ集ユーティリティを使用してエラー メッセ
ージおよび修正処置を確認します。このユーティリティを表示するには、タスクバーか
ら「スタート」>「プログラム」>「IBM Informix Dynamic Server version」>
「Informix エラー メッセージ集」を選択します。
Dynamic Server の終り
IBM Informix Online Documentation サイト
(http://www.ibm.com/software/data/informix/pubs/library/) でこれらのファイルにアクセスす
ることもできます。
マニュアル
オンライン マニュアル
IBM Informix 製品では、電子フォーマットのマニュアルを含む CD が提供されます。
マニュアルを CD からインストールするか、または CD からこれらに直接アクセスで
きます。オンライン マニュアルのインストール、表示、および印刷の方法については、
CD に付属するインストール ガイドを参照してください。同じオンライン マニュアル
を IBM Informix Online Documentation サイト
(http://www.ibm.com/software/data/informix/pubs/library/) から入手することもできます。
ペーパー マニュアル
ハードコピー マニュアルを注文するには、営業担当員に連絡するか、または IBM
Publications Center Web サイト (http://www.ibm.com/software/howtobuy/data.html) にアク
セスしてください。
オンライン ヘルプ
それぞれのグラフィカル ユーザ インターフェイス (GUI) で提供される IBM Informix
オンライン ヘルプでは、そのインターフェイスおよび機能についての情報が表示されま
す。オンライン ヘルプを表示するには、それぞれの GUI のヘルプ機能を使用してくだ
さい。
アクセシビリティ
IBM は、身体障害のある閲覧者にもマニュアルへのアクセスを可能にするように努力し
ています。IBM のマニュアルは HTML 形式で入手できるため、スクリーン リーダ (読
上げソフトウェア) などの支援テクノロジーを使用してアクセスできます。IBM のマニ
ュアルの構文ダイアグラムは、スクリーン リーダ (読上げソフトウェア) を使用する場
はじめに
xxi
合に限り利用できる小数点付き 10 進数フォーマットに従っています。小数点付き 10
進数フォーマットについて詳しくは、付録の『アクセシビリティ』を参照してくださ
い。
IBM Informix Dynamic Server バージョン 10.0 および CSDK バージョン 2.90 マ
ニュアル セット
以下の表に、IBM Informix Dynamic Server バージョン 10.0 および CSDK バージョン
2.90 マニュアル セットを構成するマニュアルのリストを表示します。これらのマニュ
アルの PDF および HTML バージョンは、
http://www.ibm.com/software/data/informix/pubs/library/ で入手できます。これらのマニュ
アルのハードコピー バージョンは、IBM Publications Center
(http://www.ibm.com/software/howtobuy/data.html) で注文できます。
表 1. Database Server のマニュアル
マニュアル
内容
管理者ガイド
データベース サーバの理解、構成、および管理。
管理者の参照
Informix Dynamic Server 用の参考資料。データベース サーバ ユーティリ
ティ onmode と onstat の構文、構成パラメータと sysmasters 表と論理
ログ レコードについての説明などが含まれます。
バックアップおよび復元 ガ
イド
データのバックアップおよび復元を行うために ON-Bar および ontape ユ
ーティリティを使用する際に理解しておく必要がある概念と方法。
DB-Access ユーザーズ ガイ
ド
DB-Access ユーティリティを使用した、Informix データベースのデータの
アクセス、修正、および取得。
DataBlade API
Function Reference
DataBlade API 関数、および DataBlade API がサポートする ESQL/C 関
数のサブセット。DataBlade API を使用して、Informix データベースのデ
ータにアクセスするクライアント LIBMI アプリケーションおよび C 言
語のユーザ定義ルーチンを開発できます。
DataBlade API
Programmer’s Guide
Dynamic Server で提供されている C 言語のアプリケーション プログラ
ミング インターフェイスである DataBlade API。DataBlade API を使用し
て、Informix データベースに格納されているデータにアクセスするクライ
アント アプリケーションおよびサーバ アプリケーションを開発します。
データベース設計および実
装 ガイド
Informix データベースの設計、実装、および管理。
エンタープライズ レプリケ
ーション ガイド
複数のデータベース サーバ間でデータを複製するためにエンタープライ
ズ レプリケーション システムを設計、実装、および管理する方法。
エラー メッセージ ファイ
ル
IBM Informix 製品の使用時に受け取る可能性がある番号付きエラー メッ
セージの原因と修正処置。
xxii
IBM Informix データベース設計および実装 ガイド
表 1. Database Server のマニュアル (続き)
マニュアル
内容
スタートアップ ガイド
IBM Informix Dynamic Server にバンドルされている製品、および他の
IBM 製品とのインターオペラビリティの説明。Dynamic Server の重要な
機能と各バージョンの新機能の要約。
SQL ガイド: 参照
Informix データベース、データ型、システム カタログ表、環境変数、お
よび stores_demo デモンストレーション データベースについての情報。
SQL ガイド: 構文
Informix のすべての SQL 文と SPL 文の構文についての詳細な説明。
SQL ガイド: チュートリア
ル
Informix 製品で実装された SQL についてのチュートリアル。リレーショ
ナル データベースでの作業時に使用される基本的な概念と用語を説明し
ます。
ハイ パフォーマンス ロー
ダ ユーザーズ ガイド
Informix データベースへ/から大量のデータをロードおよびアンロードする
ための、ハイ パフォーマンス ローダ (HPL) へのアクセスと使用。
インストール ガイド
(Microsoft Windows 用)
Windows での IBM Informix Dynamic Server のインストール。
インストール ガイド
(UNIX および Linux 用)
UNIX および Linux での IBM Informix Dynamic Server のインストー
ル。
J/Foundation Developer’s
Guide
Java プログラム言語による Informix Dynamic Server with J/Foundation 用
ユーザ定義ルーチン (UDR) の記述。
Large Object Locator
DataBlade Module User’s
Guide
ラージ オブジェクト データを作成または格納する他のモジュールから使
用可能な DataBlade ファウンデーション モジュールである Large Object
Locator の使用。Large Object Locator は、ラージ オブジェクトへの単一
で一貫したインターフェイスの作成を可能にし、データベースの外部に保
存されているデータも組み込むようにラージ オブジェクトの概念を拡張
します。
移行ガイド
Informix データベース サーバの最新バージョンへの変換および最新バー
ジョンからのリバージョン。異なる Informix データベース サーバ間の移
行について説明します。
Optical Subsystem Guide
光ディスクへのバイト (BYTE) 型およびテキスト (TEXT) 型データの格
納を支援するユーティリティである光ディスク記憶サブシステム。
パフォーマンス ガイド
最適なパフォーマンスを実現するための IBM Informix Dynamic Server の
構成と運用。
R-Tree Index User’s Guide
適切なデータ型に対する R ツリー インデックスの作成、R ツリー アク
セス方法を使用する演算子クラスの新規作成、および R ツリー副アクセ
ス方法を使用するデータベースの管理。
SNMP Subagent Guide
簡易ネットワーク管理プロトコル (SNMP) ネットワーク マネージャによ
る Informix サーバ状態の監視を可能にする、IBM Informix サブエージェ
ント。
はじめに
xxiii
表 1. Database Server のマニュアル (続き)
マニュアル
内容
Storage Manager 管理者ガイ
ド
Informix データベース サーバ向けの記憶装置およびメディアを管理する
Informix 格納域マネージャ (ISM)。
Trusted Facility Guide
監査ログの作成と管理を含む、Dynamic Server の安全保護監査機能。
ユーザ定義ルーチンおよび
データ タイプ 開発者ガイ
ド
新規の型を定義し、ユーザ定義ルーチン (UDR) を使用して IBM Informix
Dynamic Server の機能を拡張する方法。
Virtual-Index Interface
Programmer’s Guide
IBM Informix Dynamic Server に組み込まれたインデックス方式を拡張す
るための、仮想インデックス インターフェイス (VII) による副アクセス
方法 (インデックス) の作成。通常は DataBlade モジュールで使用しま
す。
Virtual-Table Interface
Programmer’s Guide
仮想テーブル インターフェイス (VTI) での主アクセス方法の作成。これ
により、ユーザは Informix の表、および Informix Dynamic Server のス
トレージ方式に準拠しないデータに対して、単一の SQL インターフェイ
スを使用できます。
表 2. クライアント/接続関連のマニュアル
マニュアル
内容
Client Products Installation
Guide
UNIX、Linux、および Windows を使用しているコンピュータへの、IBM
Informix Client Software Developer’s Kit (Client SDK) および IBM
Informix Connect のインストール。
Embedded SQLJ User’s
Guide
Java プログラムに SQL 文を埋め込むための IBM Informix Embedded
SQLJ の使用。
ESQL/C Programmer’s
Manual
C 言語用埋込み SQL の IBM Informix 実装。
GLS ユーザーズ ガイド
IBM Informix API およびデータベース サーバでの、各国の言語、国/地域
別情報、およびコード セットの処理を可能にする、広域言語サポート
(GLS) 機能。
JDBC Driver Programmer’s
Guide
Java アプリケーションまたはアプレットから Informix データベースへの
接続を行うための、JDBC ドライバのインストールと使用。
.NET Provider Reference
Guide
.NET クライアント アプリケーションによる Informix データベース内の
データのアクセスと操作を可能にするための、Informix .NET Provider の
使用。
ODBC Driver Programmer’s
Manual
Informix データベースにアクセスし、Informix データベース サーバと対
話するための、Informix ODBC Driver API の使用。
xxiv
IBM Informix データベース設計および実装 ガイド
表 2. クライアント/接続関連のマニュアル (続き)
マニュアル
内容
OLE DB Provider
Programmer’s Guide
ActiveX Data Object (ADO) アプリケーションや Web ページなどのクラ
イアント アプリケーションから Informix サーバのデータへのアクセスを
可能にするための、Informix OLE DB Provider のインストールと構成。
Object Interface for C++
Programmer’s Guide
C++ オブジェクト インターフェイスおよび全クラス参照からなるアーキ
テクチャ。
表 3. DataBlade Developer’s Kit のマニュアル
マニュアル
内容
DataBlade Developer’s Kit
User’s Guide
BladeSmith および BladePack を使用した DataBlade モジュールの開発と
パッケージ化。
DataBlade Module
Development Overview
DataBlade モジュール開発の基本的な説明。DataBlade モジュールの開発
例が含まれています。
DataBlade Module Installation DataBlade モジュールのインストール、および Informix データベースで
and Registration Guide
DataBlade モジュールを管理するための BladeManager の使用。
業界標準への準拠
米国規格協会 (ANSI) と国際標準化機構 (ISO) は、共同で構造化問合せ言語 (SQL) 用
の一連の業界標準を確立しました。IBM Informix SQL ベースの製品は、ISO 9075:1992
と同一である、SQL-92 エントリ レベル (ANSI X3.135-1992 として発行) に完全準拠し
ています。さらに、Informix データベース サーバの多くの機能が、SQL-92 中間および
全レベル、および X/Open SQL CAE (共通アプリケーション環境) 標準に準拠していま
す。
はじめに
xxv
xxvi
IBM Informix データベース設計および実装 ガイド
第 1 部 データベース設計と実装の基本
© Copyright IBM Corp. 1996, 2004
1
2
IBM Informix データベース設計および実装 ガイド
第 1 章 データベースの計画
データベースのデータ モデルの選択 . . . . . . . . . . . . . .
ANSI 標準準拠データベースの使用法 . . . . . . . . . . . . . .
ANSI 標準準拠データベースと非 ANSI 標準準拠データベースとの相違点
トランザクション . . . . . . . . . . . . . . . . . .
トランザクション ログ機能 . . . . . . . . . . . . . . .
所有者名の指定 . . . . . . . . . . . . . . . . . . .
オブジェクトへのアクセス権 . . . . . . . . . . . . . .
デフォルトの排他レベル . . . . . . . . . . . . . . . .
文字 (CHARACTER) 型 . . . . . . . . . . . . . . . .
10 進数 (DECIMAL) 型 . . . . . . . . . . . . . . . .
エスケープ文字 . . . . . . . . . . . . . . . . . . .
カーソルの動作 . . . . . . . . . . . . . . . . . . .
SQL 通信領域の SQLCODE フィールド . . . . . . . . . . .
シノニムの動作 . . . . . . . . . . . . . . . . . . .
既存のデータベースが ANSI 標準準拠であるかの判断 . . . . . . .
使用するデータベース専用の言語処理環境の使用法 (GLS) . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
4
5
5
6
6
6
7
7
7
8
8
8
8
9
9
本章について
本章では、データベース管理者 (DBA) がデータベースを効果的に計画するために理解
する必要のある問題について説明します。データベースのデータ モデルを選択する方
法、ANSI 標準準拠データベースの使用法、およびデータベースのカスタマイズ済み言
語処理環境の使用法について説明します。
データベースのデータ モデルの選択
IBM Informix 製品を使用してデータベースを作成する前に、どのようなデータ モデル
を使用してデータベースを設計するかを決める必要があります。このマニュアルでは、
次のデータベース モデルについて説明します。
v リレーショナル データ モデル
このデータ モデルは、オンライン トランザクション処理 (OLTP) のデータベース設
計の代表的なモデルです。OLTP は、非常に小さいトランザクションを 1 つも失う
ことなく処理することを目的にしています。OLTP データベースは日常的な業務上の
要件に対応するように設計されており、データベースのパフォーマンスはそのような
要件に合わせて調整されています。このマニュアルの 1 ページの『第 1 部 データベ
ース設計と実装の基本』では、OLTP 用のリレーショナル データ モデルを作成して
実装する方法について説明しています。 75 ページの『第 2 部 データベースの管
理』では、データベースを管理する方法について説明しています。
© Copyright IBM Corp. 1996, 2004
3
v オブジェクト リレーショナル データ モデル
Dynamic Server はオブジェクト リレーショナル データベースをサポートしていま
す。オブジェクト リレーショナル データベースは基本的なリレーショナル設計の原
理を採用していますが、リレーショナル データベースの機能を拡張するための拡張
データ型、ユーザ定義ルーチン、ユーザ定義キャスト、およびユーザ定義集合などを
含んでいます。このマニュアルの 137 ページの『第 3 部 オブジェクト リレーショ
ナル データベース』 では、Dynamic Server の拡張機能を使用してデータベースに格
納できるデータ型を拡張し、データの編成およびアクセスをより柔軟に行う方法につ
いて説明しています。
v 次元データ モデル
このデータ モデルは通常、一種のデータ ウェアハウスであるデータ マートを作成
するために使用されます。データ ウェアハウジング環境では、データベースはデー
タの抽出と分析のために最適化されています。このような情報処理のタイプは、
OLAP (Online Analytical Processing: オンライン分析型処理)、または意思決定支援処
理として知られています。このマニュアルの 197 ページの『第 4 部 次元データベー
ス』 では、OLAP 用の次元データ モデルを作成して実装する方法について説明して
います。
データベース設計に使用するデータ モデルだけでなく、次の項目についても決定する必
要があります。これらの項目次第で、データベースを使用するアプリケーションで利用
できる機能が決定します。
v 次のどちらのデータベース サーバを使用するか。
– Dynamic Server
– Extended Parallel Server
v データベースは ANSI 標準準拠である必要があるか。
v データベースでは、英語以外の言語の文字を表の中で使用するか。
本章では、これらの項目について説明し、これらの項目がデータベースに与える影響に
ついてまとめています。
ANSI 標準準拠データベースの使用法
CREATE DATABASE 文で MODE ANSI キーワードを使用するときは、ANSI 標準準
拠データベースを作成します。ただし、ANSI 標準準拠データベースを作成しても、こ
のデータベースが ANSI 標準準拠のままであることは保証されません。ANSI データベ
ースで ANSI 標準以外のアクション (例えば、CREATE INDEX など) を実行すると、
警告が出されますが、アプリケーション プログラムはそのアクションを禁止しません。
ANSI 標準準拠データベースを作成する理由を次に示します。
v オブジェクトへのアクセス権とアクセス
4
IBM Informix データベース設計および実装 ガイド
ANSI 規格では、表やシノニムなどのオブジェクトへのアクセス権とアクセスについ
て規定しています。
v 名前排他設定
ANSI 表命名規則により、複数のユーザが 1 つのデータベースで名前を重複させずに
表を作成できます。
v トランザクション排他設定
v データ復旧
ANSI 標準準拠データベースは、Dynamic Server のバッファなしログおよび暗黙的な
トランザクションを強制します。
ANSI 標準準拠データベースと ANSI 標準準拠でないデータベースの両方に同じ SQL
文を使用できます。
ANSI 標準準拠データベースと非 ANSI 標準準拠データベースとの相違点
ANSI 標準準拠として指定したデータベースと、ANSI 標準準拠でないデータベース
は、次の領域で動作が異なります。
v トランザクション
v トランザクション ログ機能
v 所有者名の指定
v オブジェクトへのアクセス権
v デフォルトの排他レベル
v 文字 (CHARACTER) 型
v 10 進数 (DECIMAL) 型
v エスケープ文字
v カーソルの動作
v SQLCA の SQLCODE
v シノニムの動作
トランザクション
トランザクション とは、単一の作業単位として扱われる SQL 文のコレクションのこと
です。ANSI 標準準拠データベースで発行されるすべての SQL 文は、自動的にトラン
ザクションに含まれます。ANSI 標準準拠でないデータベースでは、トランザクション
処理は省略可能です。
ANSI 標準準拠でないデータベースでは、トランザクションは BEGIN WORK 文と、
COMMIT WORK 文または ROLLBACK WORK 文で囲まれます。ただし、ANSI 標準
準拠データベースでは、すべての文が自動的にトランザクションに含まれるため、
第 1 章 データベースの計画
5
BEGIN WORK 文が不要です。トランザクションの終わりは示す必要があるため、
COMMIT WORK または ROLLBACK WORK 文を使用して示します。
トランザクションについて詳しくは、 61 ページの『第 4 章 リレーショナル データ モ
デルの実装』 および「IBM Informix: SQL ガイド: チュートリアル」を参照してくださ
い。
トランザクション ログ機能
ANSI 標準準拠データベースは、バッファなしトランザクション ログ機能付きで実行さ
れます。ANSI 標準準拠データベースでは、ロギング モードをバッファ付きログに変更
することや、ログ機能をオフにすることはできません。
Dynamic Server の ANSI 標準準拠でないデータベースは、バッファ付きログ機能付
き、またはバッファなしログ機能付きで実行できます。バッファなしログではより広範
囲なデータ復旧を利用でき、バッファ付きログではより優れたパフォーマンスを利用で
きます。
Extended Parallel Server の ANSI 標準準拠でないデータベースは、バッファなしログ機
能付きでのみ実行できます。バッファなしログではより広範囲なデータ復旧を利用でき
ます。
詳しくは、「IBM Informix: SQL ガイド: 構文」にある CREATE DATABASE 文の説明
を参照してください。
所有者名の指定
ANSI 標準準拠データベースでは、所有者名の指定が強制されます。SQL 文でオブジェ
クト名を指定するとき、ANSI 標準では、そのオブジェクトの所有者でない限り、名前
に owner というプレフィックスを組み込む必要があります。owner と name の組合せ
は、そのデータベース内で固有である必要があります。そのオブジェクトの所有者であ
れば、データベース サーバはそのユーザ名をデフォルトとして提供します。
ANSI 標準準拠でないデータベースは、所有者名の指定を強制しません。詳しくは、
「IBM Informix: SQL ガイド: 構文」の『所有者名セグメント』を参照してください。
オブジェクトへのアクセス権
ANSI 標準準拠データベースと ANSI 標準準拠でないデータベースでは、データベース
内で表を作成した場合に、デフォルトによって表レベルのアクセス権を付与されるユー
ザが異なります。ANSI 標準の規定では、データベース サーバは表レベルのアクセス権
を表の所有者のみに (DBA と異なる場合は DBA にも) 付与します。しかし、ANSI 標
準準拠でないデータベースでは、アクセス権が PUBLIC に付与されます。さらに、デー
タベース サーバでは、ANSI 標準にはない表レベルの 2 つのアクセス権、Alter と
Index を提供します。
6
IBM Informix データベース設計および実装 ガイド
ユーザ定義ルーチンを実行するには、そのルーチンの Execute アクセス権を持っている
必要があります。ANSI 標準準拠データベースで所有者アクセス権付きルーチンを作成
すると、そのユーザ定義ルーチンの所有者のみが Execute アクセス権を持ちます。ANSI
標準準拠でないデータベースで所有者アクセス権付きルーチンを作成すると、データベ
ース サーバはデフォルトで PUBLIC に Execute アクセス権を付与します。
環境変数「NODEFDAC」を「yes」に設定すると、ユーザによる表または所有者アクセ
ス権付きルーチンの作成時に自動的には PUBLIC にアクセス権を付与しないことによ
り、ANSI 標準準拠でないデータベースに ANSI 標準準拠データベースの動作をエミュ
レートさせることができます。アクセス権について詳しくは、 97 ページの『第 6 章 デ
ータベース サーバのアクセス権の付与と制限』、および「IBM Informix: SQL ガイド:
構文」にある GRANT 文の説明を参照してください。
デフォルトの排他レベル
データベースの排他レベルでは、使用しているプログラムが他のプログラムの並行動作
から分離される程度を規定します。すべての ANSI 標準準拠データベースに対するデフ
ォルトの排他レベルは、繰返し可能読込みです。トランザクション ログ機能を使用する
ANSI 標準準拠でないデータベースのデフォルトの排他レベルは、確定読込みです。ト
ランザクション ログ機能を使用しない ANSI 標準準拠でないデータベースのデフォル
トの排他レベルは、非確定読込みです。排他レベルについては、「IBM Informix: SQL
ガイド: チュートリアル」、および「IBM Informix: SQL ガイド: 構文」にある SET
TRANSACTION 文と SET ISOLATION 文の説明を参照してください。
文字 (CHARACTER) 型
データベースが ANSI 標準準拠でない場合、文字型フィールド (文字 (CHAR) 型、文
字 (CHARACTER) 型、ラージ可変長文字 (LVARCHAR) 型、各国語文字 (NCHAR)
型、各国語可変長文字 (NVARCHAR) 型、可変長文字 (VARCHAR) 型、可変長文字
(CHARACTER VARYING) 型) に、指定されたフィールド長を超える文字列が入力され
た場合でもエラーは戻されません。データベース サーバはエラー メッセージを戻さず
に超過する分の文字を切り捨てます。したがって、挿入または更新された値が n バイト
を超えている場合、CHAR(n) 列または変数のデータの意味整合性は強制されません。
ANSI 標準準拠データベースでは、文字 (CHAR) 型フィールド (文字 (CHAR) 型、文字
(CHARACTER) 型、ラージ可変長文字 (LVARCHAR) 型、各国語文字 (NCHAR) 型、各
国語可変長文字 (NVARCHAR) 型、可変長文字 (VARCHAR) 型、可変長文字
(CHARACTER VARYING) 型) に、指定されたフィールド幅を超える文字列が入力され
た場合、エラーが戻されます。
10 進数 (DECIMAL) 型
ANSI 標準準拠でないデータベースの場合、小数点以下桁数は指定せずに精度のみを指
定して宣言した 10 進数 (DECIMAL) 型は、指定された精度の浮動小数点値を格納でき
ます。精度も小数点以下桁数も指定しない場合、デフォルトの精度は 16 です。
第 1 章 データベースの計画
7
ANSI 標準準拠データベースでは、10 進数 (DECIMAL) 型の値はすべて固定小数点値で
あり、明示的な精度で宣言される必要があります。10 進数 (DECIMAL) 型に小数点以
下桁数 (scale) を指定しない場合、scale = 0 となり、整数値のみを格納できます。
エスケープ文字
ANSI 標準準拠データベースでは、エスケープ文字は特別な意味を持つパーセント (%)
文字とアンダスコア (_) 文字のみをエスケープできます。エスケープ文字を使用して、
そのエスケープ文字自体をエスケープすることもできます。エスケープ文字について詳
しくは、「IBM Informix: SQL ガイド: 構文」にある『条件セグメント』を参照してく
ださい。
カーソルの動作
データベースが ANSI 標準準拠でない場合は、SELECT 文の UPDATE カーソルを宣言
するときに FOR UPDATE キーワードを使用する必要があります。また、SELECT 文は
次の条件を満たす必要があります。
v 単一の表から選択する。
v 集計関数を含まない。
v DISTINCT、GROUP BY、INTO TEMP、ORDER BY、UNION、または UNIQUE 節
およびキーワードを含まない。
ANSI 標準準拠データベースではカーソルの宣言時に FOR UPDATE キーワードが暗黙
的に使用され、すべてのカーソルは、前掲の箇条書きの制約を満たす場合、潜在的に
UPDATE カーソルです。DECLARE 文で FOR READ ONLY キーワードを使用する
と、カーソルを読取り専用に指定できます。
詳しくは、「IBM Informix: SQL ガイド: 構文」にある DECLARE 文の説明を参照して
ください。
SQL 通信領域の SQLCODE フィールド
行が DELETE、INSERT INTO tablename SELECT、SELECT...INTO TEMP、または
UPDATE 文の検索基準を満たしていない場合、データベースが ANSI 標準準拠である
ときにはデータベース サーバが SQLCODE を 100 に設定し、データベースが ANSI
標準準拠でないときには 0 に設定します。
詳しくは、「IBM Informix: SQL ガイド: チュートリアル」にある SQLCODE の説明を
参照してください。
シノニムの動作
シノニムは常に、ANSI 標準準拠データベースでプライベートです。ANSI 標準準拠デ
ータベースで、パブリック シノニムを作成しようとしたり、キーワード PRIVATE を
使用してプライベート シノニムを示そうとしたりすると、エラーが発生します。
8
IBM Informix データベース設計および実装 ガイド
詳しくは、「IBM Informix: SQL ガイド: 構文」にある CREATE SYNONYM 文の説明
を参照してください。
既存のデータベースが ANSI 標準準拠であるかの判断
次のリストでは、データベースが ANSI 標準準拠であるかどうかを判別するための方法
を 2 つ紹介します。
v データベース sysmaster から、次の文を実行できます。
SELECT name,is_ansi FROM sysmaster:sysdatabases
この問合せの結果、データベース サーバ上のデータベースごとに、ANSI 標準準拠デ
ータベースである場合は値 1、非 ANSI 標準準拠データベースである場合は値 0 が
戻されます。
v IBM Informix ESQL/C などの SQL API を使用する場合は、SQL 通信領域 (SQLCA)
をテストできます。特に、SQLCAWARN 構造体内の 3 番目の要素には、
DATABASE または CONNECT 文を使用して ANSI 標準準拠データベースを開いた
直後に、W が含まれます。SQLCA については、「IBM Informix: SQL ガイド: チュー
トリアル」またはお手持ちの SQL API マニュアルを参照してください。
使用するデータベース専用の言語処理環境の使用法 (GLS)
広域言語サポート (GLS) を使用すると、さまざまなロケールを使用できます。GLS ロ
ケールは、特定の言語または文化向けの規約を定義している環境です。
デフォルトでは、IBM Informix 製品は米国英語 (U.S.-English) ASCII コード セットを
使用し、米国英語 (U.S.-English) 環境で ASCII 照合順序を使用して実行されます。次の
機能のいずれかを使用する場合は、デフォルトでないロケールに対応するように環境を
設定します。
v データに非 ASCII 文字
v ユーザ指定のオブジェクト名に非 ASCII 文字
v デフォルト以外のコード セットのソート順序および照合順序に対する準拠
v 辞書や電話帳などで使用される、地域固有の照合順序およびソート順序
GLS 環境変数の説明、およびデフォルト以外のロケールを実装する方法の詳細について
は、「IBM Informix: GLS ユーザーズ ガイド」を参照してください。
第 1 章 データベースの計画
9
10
IBM Informix データベース設計および実装 ガイド
第 2 章 リレーショナル データ モデルの作成
データ モデルの作成 . . . . . . . . . .
実体 - 関係データ モデルの概要 . . . . . .
主なデータ オブジェクトの識別と定義 . . . .
エンティティの識別 . . . . . . . . .
エンティティの選択 . . . . . . . .
エンティティ リスト . . . . . . . .
住所録の例 . . . . . . . . . . .
エンティティの図式化 . . . . . . .
関係の定義 . . . . . . . . . . . .
接続性 . . . . . . . . . . . . .
存在の依存性 . . . . . . . . . .
多重度 . . . . . . . . . . . . .
関係の発見 . . . . . . . . . . .
関係の図式化 . . . . . . . . . .
属性の識別 . . . . . . . . . . . .
エンティティの属性の選択 . . . . . .
属性のリスト . . . . . . . . . .
エンティティのオカレンスについて . . .
データ オブジェクトの図式化 . . . . . . .
E-R ダイアグラムの読取り . . . . . . .
住所録の例 . . . . . . . . . . . .
E-R データ オブジェクトの関係構造体への変換 .
表、行、列の定義 . . . . . . . . . .
列への制約の適用 . . . . . . . . .
ドメインの特性 . . . . . . . . . .
表のキーの決定 . . . . . . . . . . .
主キー . . . . . . . . . . . . .
外部キー (結合列) . . . . . . . . .
住所録のダイアグラムへのキーの追加 . .
関係の解決 . . . . . . . . . . . . .
m:n 関係の解決. . . . . . . . . . .
その他の特別な関係の解決 . . . . . . .
データ モデルの正規化 . . . . . . . . .
第 1 正規形 . . . . . . . . . . . .
第 2 正規形 . . . . . . . . . . . .
第 3 正規形 . . . . . . . . . . . .
© Copyright IBM Corp. 1996, 2004
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
12
12
13
13
13
13
14
16
16
17
17
17
18
22
22
23
24
24
24
25
26
27
27
28
29
29
29
30
31
32
32
33
34
35
36
37
11
正規化ルールのまとめ
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 37
本章について
リレーショナル データベースを作成する最初の手順は、データ モデルを作成すること
です。データ モデルの作成とは、格納する必要のあるデータを正確かつ完全に定義する
ことです。本章では、データをモデル化する方法の概要を説明します。データ モデルの
列固有のプロパティの定義については、 39 ページの『第 3 章 データ型の選択』を参照
してください。本章で説明されるデータ モデルの実装方法を理解するには、 61 ページ
の『第 4 章 リレーショナル データ モデルの実装』を参照してください。
本章の内容を理解するには、SQL とリレーショナル データベース理論に関する基礎知
識が必要です。
データ モデルの作成
データベースを構成するデータの型や必要な編成方法について、すでに何らかの構想を
持っているとします。この情報が、データ モデルを作成する出発点です。形式化された
表記を使用してデータ モデルを作成すると、次の点で役立ちます。
v データ モデルについて徹底的に考慮できる。
通常、直感的なモデルには、あいまいな点や検討が済んでいない仮定が含まれていま
す。設計を形式化した場合は、これらの仮定が明確になります。
v 他の人でもその設計が理解しやすくなる。
形式化された記述はモデルを明確にするため、他の人が同じ形式でコメントや意見を
述べることができます。
実体 - 関係データ モデルの概要
データのモデル化の形式化された方法には、複数の方法が存在します。それらのどの方
法を使用しても、完全で正確なモデル化が可能です。何らかの方法が明確になっている
場合は、その方法を使用することを強くお勧めします。
本章では、E-R (entity-relationship: 実体 - 関係 ) データ モデルの概要を説明します。
E-R データ モデル化の方法では、次の手順に従います。
1. 主なデータベース オブジェクト (エンティティ、関係、および属性) を識別し定義
する。
2. E-R アプローチを使用してデータ オブジェクトを図式化する。
3. E-R データ オブジェクトを関係型構造体に変換する。
4. 論理データ モデルを解決する。
5. 論理データ モデルを正規化する。
12
IBM Informix データベース設計および実装 ガイド
本章では、手順 1 から 5 までを説明します。論理データ モデルを物理スキーマに変換
する最終的な手順については、第 4 章で説明されています。
データ モデル化の最終的な結果は、個人用住所録の最終的な表のセットを示す 36 ペー
ジの図 21 と同様のダイアグラムでエンコードされた、完全に定義されたデータベース
設計となります。この個人用住所録は、本章で例として作成します。これは、1 つの章
で完全に作成できるほどの小さいサイズであり、かつ全体の方法を示すには大きすぎる
サイズであるため、デモンストレーション データベースでなくこの住所録を使用しま
す。
主なデータ オブジェクトの識別と定義
データ モデルを作成するには、最初に主なデータ オブジェクト (エンティティ、関
係、および属性) を識別して、定義します。
エンティティの識別
エンティティ とは、ユーザにとって最も重要であるデータ オブジェクトです。通常、
エンティティはデータベースに記録される人、場所、物、事柄などです。データ モデル
を言語とした場合、エンティティは名詞に相当します。ご使用のソフトウェアに備わっ
ているデモンストレーション データベースには、customer、orders、items、stock、
catalog、cust_calls、call_type、manufact、および state というエンティティが含まれてい
ます。
エンティティの選択
データベースについて即時にいくつかのエンティティをリストできることがあります。
識別可能なすべてのエンティティの予備的なリストを作成します。データベースのユー
ザとなる可能性のある人に、データベースに記録すべき事柄について意見を求めます。
エンティティごとに、「1 つの名前に少なくとも 1 つの住所を関連付ける」などの基本
的な特性を決定します。エンティティに関して行った決定はすべて、ビジネス ルール
となります。本章では、15 ページの住所録の例で、そのビジネス ルールをいくつか示
します。
その後、データ モデルを正規化 して、一部のエンティティを拡張したり、他のデータ
オブジェクトにしたりすることができます。詳しくは、34 ページの『データ モデルの
正規化』を参照してください。
エンティティ リスト
エンティティ リストが完成したと見なされる場合は、そのリストを調べて各エンティテ
ィに次の特性があることを確認してください。
v 重要である。
データベースのユーザにとって重要で、かつ時間と費用をかけてコンピュータで処理
する価値があるエンティティのみを取り上げます。
第 2 章 リレーショナル データ モデルの作成
13
v 一般的である。
個々のエンティティではなく、類型のみを取り上げます。例えば、交響曲 はエンテ
ィティですがベートーベンの第 5 交響曲 はエンティティのインスタンスまたはエン
ティティのオカレンスです。
v 基本的である。
そのエンティティの説明に他のエンティティを必要とせず、独立して存在するものの
みをエンティティとして取り上げます。それを説明するのに何か特徴や記述といった
ものが他のに必要なものは、独立したエンティティではありません。例えば部品番号
は、部品 と呼ばれる基本エンティティの 1 つの特徴です。また、他のエンティティ
から導出できるものも、エンティティとして取り上げないでください。例えば、合計
や平均などの量は SELECT 文で式を使用して計算できます。
v 単一である。
命名した各エンティティがそれぞれ単一のクラスを表しているかを確認してくださ
い。1 つのエンティティを、それぞれ固有の特徴を持つ下位のカテゴリに分類するこ
とはできません。15 ページの図 1 の住所録の例では、電話番号は明らかに簡単なエ
ンティティであり、それぞれが異なる特徴を持つ 3 つのカテゴリで実際に構成され
ています。
これらの条件に合うエンティティを選択することは、決して簡単ではなく、自動的に選
択することはできません。最善の選択を見つけるには、データベースに格納するデータ
の性質について慎重に検討する必要があります。このような検討を行うことによって、
適切なデータ モデルを作成できます。次のセクションで、住所録の例を詳細に説明しま
す。
住所録の例
例として、個人用の住所録のためのデータベースを作成することを想定します。このデ
ータベースのモデルに格納すべき情報は、データベースのユーザが必要とする人と組織
の名前、住所、電話番号です。
最初にエンティティを定義します。住所録のページを慎重に確認し、含まれるエンティ
ティを識別します。15 ページの図 1 は、住所録のページの例です。
14
IBM Informix データベース設計および実装 ガイド
Catherine Morgan
206-789-5396
429 Bridge Way
Seattle, WA 98103
N
O
Norman Dearborn 206-598-8189 P
Q
R
Morganthaler Industries
S
12558 E. 10th Ave. Seattle, WA
98102
206-509-6872 T
U
Thomas Morrison 503-256-6031 V
W
866 Gage Road
X
Klamath Falls, OR 97601
Y
Z
図 1. 住所録の一部
既存のデータの物理的な形式は、誤解を招くことがあります。住所録のページおよびエ
ントリのレイアウトに惑わされて、住所録の 1 つのエントリを 1 つのエンティティと
して指定しないように注意してください。住所録では、名前、番号、および住所のフィ
ールドから成るレコードがアルファベット順に並んでいます。モデル化するのはデータ
であって、データの集まりではありません。
一般的で重要なエンティティ: 一見して、住所録に記録されているエンティティに
は次の項目が含まれています。
v 人や組織の名前
v 住所
v 電話番号
これらのエンティティは、前述の基準を満たしているでしょうか。モデルにとって重要
であり、一般的であることは明らかです。
第 2 章 リレーショナル データ モデルの作成
15
基本的なエンティティ: 各エンティティは、他のエンティティに影響を与えずに個数
を変化させることができます。この事実は、基本的かどうかの判定に使用できます。引
っ越したり仕事を変えたりしたために電話番号や現住所を持たない人も住所録に記載さ
れる場合があります。また、住所録には、複数の人が使用している住所と電話番号が記
載されていることもあります。名前、住所、電話番号の 3 つのエンティティはどれも、
独立して個数を変化させることができます。これは、これらのエンティティが基本的で
あり、他のデータ依存していないことを示しています。
分割できないエンティティ: 名前は個人名と会社名に分類できます。このモデルで
はどの名前も特に区別しないことにしました。つまり、会社の情報も個人の情報も同じ
ように扱うことにしました。同様に住所も、自宅の住所と会社の住所を区別して扱わず
に、1 つと見なすことにしました。
ただし、複数の電話番号があることになります。人が応答する通常の電話 番号、ファッ
クスに接続するためのファックス 番号、コンピュータに接続するためのモデム 番号で
す。各タイプの番号について異なる情報を記録することにします。つまり、この 3 つの
タイプが異なるエンティティとなります。
住所録の例では、次のエンティティを記録することに決定しました。
v 名前
v 住所 (郵送先)
v 電話番号
v ファックス番号
v モデム番号
エンティティの図式化
E-R ダイアグラムの使用方法については、本章で後述します。まず、住所録の例の各エ
ンティティごとに長方形ボックスを作成します (図 2 を参照)。24 ページの『データ オ
ブジェクトの図式化』に、エンティティを関係と結び付ける方法を示してあります。
図 2. 住所録の例におけるエンティティ
関係の定義
データベースのエンティティを選択したら、そのエンティティ間の関係を考える必要が
あります。関係は必ずしも明確ではありませんが、記録する価値のあるものをすべて見
つけなければなりません。確実にすべての関係を見つけるには、考えられる関係をすべ
16
IBM Informix データベース設計および実装 ガイド
てリストする以外にありません。エンティティ A とエンティティ B のすべてのペアを
想定し、「A と B の間にはどのような関係があるか」について考えます。
関係とは、2 つのエンティティの間の関連です。通常、関係は 2 つのエンティティを結
ぶ動詞や前置詞の中に含まれます。エンティティ間の関係は、接続性、存在の依存性、
および多重度 という言葉で説明されます。
接続性
接続性とは、エンティティのインスタンスの数を意味します。エンティティのインスタ
ンスは、エンティティの特定のオカレンスです。図 3 に示すように、接続性には 1 対
1 (1:1)、1 対多 (1:n)、多対多 (m:n) の 3 つのタイプがあります。
1
1
1
図 3. 関係における接続性
例えば住所録の例では、住所は複数の名前と関連がある場合があります。住所のエンテ
ィティと名前のエンティティとの関係の接続性は、1 対多 (1:n) です。
存在の依存性
存在の依存性は、関係におけるエンティティが任意であるか、必須であるかを示しま
す。ビジネス ルールを分析して、エンティティが関係に存在しなければならないかどう
かを確認します。例えば、1 つの名前には 1 つの住所が関連付けられていなくてはなら
ないというビジネス ルールがあるとします。このような関連は、名前と住所のエンティ
ティの間の関係に存在の依存性が必須であることを示します。存在の依存性が任意であ
る例として、ある人の子供のあるなしというビジネス ルールを挙げることができます。
多重度
多重度は、エンティティが関係に表示される回数に制約を適用します。1 対 1 の関係の
多重度は、常に 1 です。これに対して、1 対 n の関係の多重度は不定です。n は任意
の数で構いません。n に上限を設ける必要がある場合は、その関係に多重度を指定しま
す。例えば、店舗販売の例では、顧客が 1 回で買える品物の数の上限を指定すると考え
られます。通常、多重度の制約はアプリケーション プログラムまたは (SPL) を使用し
て指定します。
第 2 章 リレーショナル データ モデルの作成
17
関係の発見
エンティティ間の関係を発見する方法としては、マトリックス形式で 2 つのエンティテ
ィの組合せをリストした表を作成するのが便利です。図 4 のマトリックスは、個人用住
所録のエンティティを反映しています。
(
(
(
) (
)
)
(
(
)
)
)
図 4. 個人用住所録のエンティティのマトリックス
マトリックス内の影をつけた部分は無視できます。対角線上のセルは検討を要します。
つまり、「A と別の A の間にはどのような関係があるか」を考える必要があります。
このモデルの場合、その答えは必ず、「関係は 1 つもない」になります。名前どうしや
住所と他の住所の間には関係がありません。少なくとも、このモデルでは記録する必要
があるものは何もありません。A と別の A の間に関係がある場合は、再帰的 な関係が
あります (33 ページの『その他の特別な関係の解決』を参照してください)。
関係がないことがはっきりしたすべてのセルについて、マトリックスに「なし」と記入
します。図 5 に、記入後のマトリックスを示します。
18
IBM Informix データベース設計および実装 ガイド
(
(
(
) (
)
)
(
(
)
)
)
図 5. 初期の関係を示したマトリックス
このモデルでは自分自身との間に関係があるエンティティはありませんが、他のモデル
では同一のエンティティの間に関係が生じる場合があります。例えば、社員というエン
ティティでは、ある社員は別の社員の上司になることがあります。別の例としては、部
品というエンティティがあります。ある部品が別の部品の構成要素になることがありま
す。
残った空白のセルには、上端の見出しのエンティティと左端の見出しのエンティティの
間に存在する接続関係のタイプを書き込みます。関係には、次のようなタイプがありま
す。
v 1 対 1 (1:1)。1 つのエンティティ B に対して複数のエンティティ A が存在するこ
とはなく、1 つの A に対して複数の B が存在することもありません。
v 1 対多 (1:n)。複数のエンティティ A が存在することはありませんが、複数のエンテ
ィティ B を A に関連付けることができます (また、その逆も可能です)。
v 多対多 (m:n)。複数のエンティティ A を 1 つの B に関連付けることができ、複数の
エンティティ B を 1 つの A に関連付けることもできます。
1 対多の関係が最も一般的です。住所録モデルは、1 対多および多対多の関係を表して
います。
19 ページの図 5 に示すように、最初の空白のセルは、名前と住所の間の関係を示して
います。名前と住所というエンティティの間には、どのような接続性があるでしょう
か。「1 つの住所にいくつの名前を関連付けることができるか」について考えた結果、
名前は住所を持たない か、または唯一 1 つ の住所を持つことにします。図 6 に示す
ように、名前の向かい側、住所の下に 0-1 と記入します。
第 2 章 リレーショナル データ モデルの作成
19
0-1
図 6. 名前と住所の関係
次に、1 つの名前にいくつの住所が関連しているかを考えます。住所は複数の名前と関
連があるということにします。例えば、同じ会社に勤める人を何人か知っているかもし
れませんし、同じ住所に住んでいる人を複数知っているかもしれません。
住所と関係する名前の数がゼロ という場合はあり得るでしょうか。すなわち、住所のみ
が存在し、その住所に対する名前が存在しないということはあるでしょうか。この場合
は、あり得ると決定しました。図 7 に示すように、住所の下、名前の向かい側に 0-n
と記入します。
0-n
0-1
図 7. 住所と名前の関係
関連付けられた名前が 1 つもない住所は存在しないと決定した場合は、0-n ではなく
1-n と記入します。
関係する要素の多重度 (個数) がどちらか一方のエンティティの側で最大 1 に制限され
る場合は、1:n の関係になります。この場合、名前と住所の関係は 1:n の関係です。
ここで、19 ページの図 5 にある次のセルについて検討します。つまり、名前と電話番
号との関係です。1 つの名前と関係する可能性がある電話番号は 1 つだけでしょうか、
それとも 2 つ以上関係することがあるでしょうか。住所録を見ると、一人に対して複数
の電話番号を記入している箇所が見受けられます。多忙なセールス担当者の場合は、自
宅の電話番号、会社の電話番号、ポケット ベルの番号、自動車電話番号などが記入され
ています。しかし、電話番号のない名前もあります。図 8 に示すように、名前の向かい
側、番号 (電話) の下に 0-n と記入します。
20
IBM Informix データベース設計および実装 ガイド
(
)
0-n
0-1
0-n
図 8. 名前と電話番号の関係
次に、逆方向の関係を検討します。各電話番号と関係する可能性がある名前は、いくつ
あるでしょうか。電話番号には、1 つの名前のみ関係していると決定しました。電話番
号と関係する名前の数がゼロという場合はあり得るでしょうか。誰にも使用されていな
い電話番号を記録する必要はないと決定しました。図 9 に示すように、番号 (電話) の
下、名前の向かい側に 1 と記入します。
(
)
0-n
0-1
1
0-n
図 9. 電話番号と名前の関係
以下の要因を考慮して、マトリックスの残りの部分も同じように記入します。
v 名前は、複数のファックス番号と関係する可能性があります。例えば、会社にはいく
つかのファクシミリがあることがあります。逆に考えると、各ファックス番号は、複
数の名前と関係する可能性があります。例えば、同じファックス番号を複数の人が使
用することがあります。
v 各モデム番号が関係する名前は、ちょうど 1 つでなければなりません (これは任意に
決めたものです。設計の要件の 1 つと考えてください)。これに対し各名前は、複数
のモデム番号と関係する可能性があります。例えば、会社のコンピュータは複数のダ
イヤル回線に接続されることがあります。
v 電話番号と住所の間には、現実には何らかの関係がありますが、このモデルでは特に
注意するような関係はありません。すでに、間接関係が名前 を介して存在していま
す。
図 10 に、完成したマトリックスを示します。
第 2 章 リレーショナル データ モデルの作成
21
(
)
0-n
0-1
(
) (
1
0-n
)
1-n
0-n
1
0-n
)
(
(
(
)
)
図 10. 完成した住所録のマトリックス
マトリックスに示されたその他の決定は、ファックス番号とモデム番号、電話番号とフ
ァックス番号、電話番号とモデム番号それぞれの間に関係が存在しないということで
す。
電話番号とモデム番号の間の関係をサポートしないことなど、このような決定の一部に
は賛成できないものもあるでしょう。しかし、この例では、上記をビジネス ルールとし
ます。
関係の図式化
まず、本セクションで作成したマトリックスを保存しておきます。E-R ダイアグラムの
作成方法については、24 ページの『データ オブジェクトの図式化』で説明します。
属性の識別
エンティティには、特性や修飾子、品質、数量、機能としての属性 が含まれています。
属性は、エンティティに関する事実または分割できない情報です。エンティティを表と
して表現するときに、エンティティの属性を新しい列としてモデルに追加します。
エンティティを識別して初めて、データベース属性が識別できます。エンティティを決
定したら、「各エンティティについてどのような特性を知る必要があるか」について考
えます。例えば、エンティティが住所 の場合は、番地、市区町村、および 郵便番号 に
関する情報が必要でしょう。住所 というエンティティに関するこれらの特性それぞれが
属性となります。
22
IBM Informix データベース設計および実装 ガイド
エンティティの属性の選択
属性は、次の条件を満たすものを選択してください。
v 重要性が高いこと
データベースのユーザにとって重要な属性のみを選択してください。
v 直接的であり、導出的ではないこと
例えば、SELECT 文の記述から導出できるような、既存の属性から導出できる属性が
モデルの一部であってはなりません。データが導出されると、データベースの保守が
複雑になります。
この後の設計段階では、パフォーマンス改善のために導出される属性の追加を検討す
る場合があります。しかしこの段階では、導出される属性は除外します。データベー
ス サーバのパフォーマンスを向上させる方法については、「IBM Informix: Dynamic
Server パフォーマンス ガイド」を参照してください。
v 分割できないこと
属性は 1 つの値のみを含むもので、リストや繰り返されるグループを含んだもので
あってはなりません。複合的な値は、個々の属性に分けなければなりません。
v 同じタイプのデータを含んでいること
例えば、誕生日という属性には日付の値のみを入れて、名前や電話番号入れないはず
です。
属性の定義方法のルールは、列の定義方法のルールと同じです。列の定義方法の詳細に
ついては、28 ページの『列への制約の適用』を参照してください。
次の属性を住所録の例に追加して、26 ページの図 15に示すようなダイアグラムを作成
します。
v 住所 のエンティティには、番地、市区町村、都道府県、および郵便番号を追加しま
す。
v 名前 のエンティティには、誕生日、電子メール アドレス、記念日、および子供の名
前を追加します。
v 電話番号 のエンティティには、自動車電話、自宅の電話、および勤務先の電話を区
別するためのタイプを追加します。1 つの電話番号は、1 つの電話のみに関係しま
す。
v ファックス のエンティティには、ファクシミリが受信可能な時間帯を追加します。
v モデム のエンティティには、9,600、14,400、28,800 など、モデムがサポートするボ
ー レートを追加します。
第 2 章 リレーショナル データ モデルの作成
23
属性のリスト
ここでは、住所録の例について、必要と思われるエンティティとともに属性をリストし
ます。図 11 のようなリストになります。
fname
lname
bdate
anniv
email
child1
child2
child3
street
city
state
zipcode
vce_num
vce_type
fax_num
oper_from
oper_till
mdm_num
b128000
b256000
図 11. 住所録の例の属性
エンティティのオカレンスについて
追加のデータ オブジェクトは、エンティティのオカレンス (発生数) です。表の各行
は、エンティティの特定の単一のオカレンスを表しています。例えば、顧客 がエンティ
ティである場合、顧客表は顧客の概念を表します。その表では、各行は、例えば Sue
Smith という 1 人の特定の顧客を表します。エンティティは表に、属性は列に、エンテ
ィティのオカレンスは行になることに留意してください。
データ オブジェクトの図式化
これで、データベース内のエンティティと関係を理解できました。これは、リレーショ
ナル データベースの設計プロセスで最も重要です。エンティティと関係の決定後は、デ
ータベース設計中の思考過程を表す方法が役立つことがあります。
多くのデータ モデル化の方法で、エンティティと関係をグラフィカルに表示できます。
IBM Informix のマニュアルでは、C. R. Bachman が開発した E-R ダイアグラム アプ
ローチが使用されています。E-R ダイアグラムには次の目的があります。E-R ダイアグ
ラムは、
v 組織の情報ニーズをモデル化する。
v エンティティとその関係を示す。
v データ定義 (データ フロー ダイアグラム) の出発点となる。
v アプリケーション開発者のみならず、データベース管理者やシステム管理者にとって
文書化に関する非常に有用な資料となる。
v 物理スキーマに変換できるデータベースの論理設計を作成する。
24
IBM Informix データベース設計および実装 ガイド
E-R ダイアグラムにはいくつかのスタイルがあります。任意のスタイルを設定済みであ
る場合は、それを使用してください。図 12 に、E-R ダイアグラムのサンプルを示しま
す。
図 12. 実体 - 関係ダイアグラムの記号
E-R ダイアグラムでは、ボックスがエンティティを表します。線は、エンティティとエ
ンティティを結ぶ関係を表します。また、図 13 に、関係における次の特徴を表す場合
のグラフィック記号の使い方を示します。
v 接続関係を表す線上の円は、その関係が任意 であることを示します。インスタンス
がゼロの場合があります。
v 接続関係を表す線上の短い棒線は、そのエンティティのちょうど 1 つ のインスタン
スが他のエンティティに関連付けられていることを示します。棒線は 1 と見なしま
す。
v カラスの足跡は、関係が多数 あることを示します。
1
図 13. 実体 - 関係ダイアグラムにおける関係の部分
E-R ダイアグラムの読取り
E-R ダイアグラムは、まず左から右に、次に右から左に読み取ります。図 14 にある 名
前と住所 の関係の場合は、次のように関係を読み取ります。名前は、ゼロまたは正確に
1 つの住所に関連付けることができます。また、住所は、ゼロ、1 つ、または多数の名
前に関連付けることができます。
第 2 章 リレーショナル データ モデルの作成
25
1
1
図 14. 実体 - 関係ダイアグラムの読み方
住所録の例
図 15 に、エンティティ、関係、および属性を含んだ住所録の例を示します。このダイ
アグラムには、マトリックスを使用して確立する関係が含まれています。ダイアグラム
の記号について理解したら、図 15 の E-R ダイアグラムを 22 ページの図 10 のマトリ
ックスと比較してください。両方の図で関係が同一であるかを確認してください。
22 ページの図 10 に示したようなマトリックスは、それを記入する際、必然的にあり得
るすべての関係を考えなければならないため、初めてモデル設計する場合には有効なツ
ールとなります。ただし、図 15 のように、同じ関係がダイアグラムに表示される場合
は、この種のダイアグラムは、既存のモデルを再検討すると読みやすくなります。
Lname
fname
bdate
anniv
email
child1
child2
child3
vce_num
vce_type
Street
city
state
zipcode
fax_num
oper_from
oper_till
mdm_num
b9600
b14400
b28800
図 15. 住所録の例における予備的な実体 - 関係ダイアグラム
26
IBM Informix データベース設計および実装 ガイド
ダイアグラムが完成した後に
本章の残りの部分では、以下の作業を実行する方法について説明します。
v エンティティ、関係、属性を関係構造体に変換する。
v E-R データ モデルを解決する。
v E-R データ モデルを正規化する。
第 4 章に、E-R データ モデルからデータベースを作成する方法を示します。
E-R データ オブジェクトの関係構造体への変換
これまで理解してきたすべてのデータ オブジェクト (エンティティ、関係、属性、およ
びエンティティのオカレンス) は、SQL 表、表間の結合、列、および行に変換されま
す。データベースの表、列、行は、27 ページの『表、行、列の定義』 に示すルールに
従っていなければなりません。
データ オブジェクトを正規化する前に、それがこれらのルールを満たしていることを確
認してください。データ オブジェクトを正規化するには、エンティティ、関係、および
属性の間の依存性を分析します。正規化については、34 ページの『データ モデルの正
規化』で説明しています。
データ モデルを正規化した後は、SQL 文を使用してデータ モデルに基づくデータベー
スを作成できます。住所録の例のデータベースを作成し、データベース スキーマを指定
する方法については、第 4 章で説明します。
選択した各エンティティは、モデルにおける表として示されます。表は、抽象概念とし
てのエンティティを意味しており、各行はエンティティの特定の個別オカレンス を表し
ます。さらに、エンティティの各属性は表の列で表されます。
以下に E-R データ モデルを含む大部分の関係データ モデル法の基本的な考え方を示
します。データ モデル設計時にこれらのルールに従って、モデルを正規化するときの時
間と労力を節約してください。
表、行、列の定義
ユーザはこの段階で、行 と列 から成る表 の概念について熟知していることが想定され
ます。しかし、正式なデータ モデルの表定義では、下記のルールが要求されます。
v 各行は独立していていなければならない。
表の各行は独立していて、同じ 表の他の行に依存することはありません。したがっ
て、表の内部での行の順番は、モデルでは意味がありません。表のすべての行をラン
ダムな順番に並び替えたとしても、モデルは正しいはずです。
データベースを実装した後では、効率化のためにデータベース サーバに要求して特
定の順序で行を保存できますが、その順序はモデルには影響を及ぼしません。
第 2 章 リレーショナル データ モデルの作成
27
v 各行は一意でなければならない。
各行には、必ず一意の値を持つ列がなければなりません。この特性を持つ単一の列が
ない場合は、複数の列の値を組にすることで行を識別できるような列の組合せが存在
しなければなりません。
v 各列は独立していなければならない。
表の内部での列の順番は、モデルでは意味がありません。列を並び替えたとしても、
モデルは正しいはずです。
データベースを実装した後では、すべての列 を意味するアスタリスクを使用してい
るプログラムや格納された問合せは列の最終的な順序に依存しますが、その順序はモ
デルには影響を及ぼしません。
v 各列の値は 1 つの値でなければならない。
各列が格納できるのは、1 つの値のみで、値の並びや繰り返されるグループは、1 つ
の列には格納できません。複数の要素から合成された値は、個々の列に分離する必要
があります。例えば、本章の例のように、個人の姓と名前を別個の値として取り扱う
ことにした場合、姓と名前は 1 つの名前列に一緒に格納するのではなく、別個の列
に格納しなければなりません。
v 各列は一意の名前を持たなければならない。
同じ表の内部の 2 つの列が同じ名前は共有できません。ただし同様の情報を含む列
を複数作成することはできます。例えば、住所録の例の名前表には子供の名前の列が
あります。それぞれの列に child1、child2 などと名前を付けることができます。
v 各列は単一の型のデータを含んだものでなければならない。
各列は、同じデータ型の情報を格納しなければなりません。例えば、整数 (INTEGER)
型で示される列には、名前からの文字ではなく数値情報のみを格納しなければなりま
せん。
配列や順次ファイルとして構成されたデータを扱った経験のみの場合は、これらのルー
ルは不自然であると認識されるかもしれません。しかし、リレーショナル データベース
の理論では、すべての型のデータは、これらのルールに従った表、行、列のみを使用し
て表すことができます。多少経験を積むことで、これらのルールを自動的にに適用でき
るようになります。
列への制約の適用
CREATE TABLE 文を使用して表と列を定義する場合、各列に制約を加えます。これら
の制約は、列に文字と数のどちらを入れるか、使用する日付の形式などの条件を指定し
ます。属性が想定できるような一式の有効値をドメイン で識別する場合は、ドメインに
制約を記述します。
28
IBM Informix データベース設計および実装 ガイド
ドメインの特性
表を作成する場合、ドメインの特性を定義します。列には、次のドメイン特性を指定で
きます。
v データ型 (整数 (INTEGER) 型、文字 (CHAR) 型、日付 (DATE) 型など)
v フォーマット (例えば、yy/mm/dd)
v 範囲 (例えば、1,000 から 5,400)
v 意味 (例えば、シリアル番号)
v 許容値 (例えば、等級 S または U のみ)
v 一意性
v NULL のサポート
v デフォルト値
v 参照制約
ドメインの定義方法については、第 3 章を参照してください。表とデータベースの作成
方法については、第 4 章を参照してください。
表のキーの決定
表の列はキー 列か、または記述子 列のいずれかです。キー列とは、表の内部の特定の
行を一意に識別する列です。例えば、社会保障番号は各社員に一意です。記述子列は、
表の特定の行の一意ではない特性を指定します。また例えば、2 人の社員が Sue という
同じ名を持つ場合が考えられます。この Sue という名前は、1 人の社員の一意の特性で
はありません。表におけるキーには、主キーと外部キーという主なタイプがあります。
主キーと外部キーは、表を作成するときに指定します。主キーと外部キーは、表を物理
的に関連付けるために使用します。次の作業は、各表に主キーを指定することです。つ
まり、行のそれぞれを他の行と区別する何らかの定量化できる表の特性を識別する必要
があります。
主キー
表の主キー とは、行ごとに値が異なる列のことです。主キーの値は行ごとに異なるた
め、主キーは各行を一意に識別します。そのような列が存在しない場合は、値の組合せ
が行ごとに異なるような複数の列の複合 が主キーになります。
モデルの表はどれも、主キーを持たなければなりません。このルールは、すべての行は
一意でなくてはならないというルールに自動的に準じます。必要に応じて、すべての列
で主キーを構成することもできます。
効率性を高めるため、主キーは、数値データ型 (整数 (INT) 型または小桁整数
(SMALLINT) 型)、シリアル (SERIAL) 型、または 8 バイト シリアル (SERIAL8) 型、
あるいは short 型文字列 (コードに使用) である必要があります。主キーとして長い文
字列を使用しないことをお勧めします。
第 2 章 リレーショナル データ モデルの作成
29
主キー列では NULL は使用できません。NULL は比較できません。つまり NULL につ
いては、「同じ」あるいは「異なる」といった比較はできません。したがって、NULL
は行を一意に識別できません。NULL が使用できる列を主キーや主キーの一部として使
用することはできません。
エンティティの中には、カタログ番号や身分証明番号のように、モデルの外部で定義さ
れた主キーを持つものもあります。場合によっては、複数の列や列のグループが主キー
として使用できることもあります。主キーとして使用できる列や列のグループを候補キ
ー と呼びます。候補キーは一意性という特性により、SELECT 文の結果が予測できる
ため、注意する必要があります。
複合キー: エンティティによっては、確かな一意性を欠いたものがあります。例え
ば、同姓同名の人がいる場合があります。別個の本の題名が同じである場合もありま
す。通常、このような場合は複数の属性を組み合わせて主キーとして使用できます。名
前と住所が同じという人はめったになく、異なる本でもタイトル、著者および発行日が
同じということもほぼあり得ないためです。
システム割当てキー: 通常は、複合キーよりシステム割当て主キーのほうが便利で
す。システム割当てキーは、エンティティが最初にデータベースに追加されるときにエ
ンティティの各インスタンスに指定できる数値またはコードです。最も簡単に指定でき
るシステム割当てキーは、データベースが自動的に生成可能なシリアル番号です。
Informix データベース サーバでは、シリアル番号にシリアル (SERIAL) 型および 8 バ
イト シリアル (SERIAL8) 型を使用します。しかし、意味のない数値コードの指定は、
データベース利用者には有用でない場合があります。このような場合、実際のデータに
基づいたコードをシステム割当てキーとして使用することもできます。例えば、従業員
の識別コードは、個人の頭文字と雇用された日付の数字を組み合わせて示すことができ
ます。住所録の例では、システム割当て主キーは名前表で使用されています。
外部キー (結合列)
外部キー とは、他の表の主キー と一致する値を持つ表の列または列のグループを指し
ます。外部キーは、表を結合するときに使用します。図 16 は、デモンストレーション
データベースの顧客表と注文表の主キーと外部キーです。
図 16. 顧客/注文関係における主キーと外部キー
ヒント: 表のメンテナンスと使用を容易にするためには、関係を容易に理解できるよう
に主キーと外部キーの名前を選択することが重要です。図 16 では、主キーと
30
IBM Informix データベース設計および実装 ガイド
外部キーの両方の列に同じ名前 customer_num が付けられています。また、図
16 の列が別個の名前を持つように、customer_custnum と orders_custnum と
いう名前を付けることもできます。
表から行を削除するときは、外部キーによって制約を受けるため、モデル内では外部キ
ーに注目する必要があります。行を削除するときには、その前に外部キーを介してその
行を参照している行をすべて削除しておくか、1 つの削除コマンドで主キーと外部キー
から行を削除できる特殊な構文を使用して関係を定義しておく必要があります。データ
ベース サーバでは、参照整合性に違反する削除は実行できません。
参照整合性を保持するには、すべての外部キー列を削除してから、その外部キーが参照
している主キーを削除してください。データベースに参照整合性が課されている場合、
対応する外部キーが存在しているときにデータベース サーバは主キーの削除を許可しま
せん。また、既存の主キーの値を参照しない外部キーの値を追加することもできませ
ん。参照整合性について詳しくは、「IBM Informix: SQL ガイド: チュートリアル」を
参照してください。
住所録のダイアグラムへのキーの追加
図 17 に、主キーと外部キーの初期選択肢を示します。このダイアグラムは、いくつか
の重要な決定を反映しています。
名前表では、主キー rec_num が選択されています。rec_num のデータ型はシリアル
(SERIAL) 型です。rec_num の値は、システムが生成します。名前表の他の列または属
性を見ると列に関連付けられたデータ型のほとんどは文字型を基準にしたものであるこ
とが分かります。これらの列はどれも、単独では主キー候補として適切ではありませ
ん。表の要素を組み合わせて複合キーを作成すると、キーは複雑になります。シリアル
(SERIAL) 型で提供されたキーを使用すると、他の表を名前表と結合することもできま
す。
電話、ファックス、モデム、および住所の各表は、rec_num キーを介して名前表に結合
されています。
電話、ファックス、およびモデムの各表では、電話番号が主キーとして使用されていま
す。住所表には、主キーとしての役割以外には目的がない特別な列 (id_num) が含まれ
ています。これは、id_num が存在しないとすると、重複した主キーが存在しないよう
にするためには他のすべての列を複合キーとして使用する必要があるためです。主キー
としてすべての列を使用すると、非常に非効率で紛らわしくなります。
第 2 章 リレーショナル データ モデルの作成
31
rec_num PK
Iname
fname
bdate
anniv
email
child1
child2
child3
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
mdm_num PK
rec_num FK
b9600
b14400
b28800
PK =
FK =
図 17. 主キーと外部キーを追加した住所録のダイアグラム
関係の解決
適切なデータ モデルの目的は、データベース サーバが迅速にアクセスできるような構
造体を作成することにあります。関係を解決し、データ モデルを正規化することによ
り、住所録のデータ モデルをさらに改善できます。ここでは、データベースの関係を解
決する方法と、その理由について説明します。データ モデルの正規化については、34
ページの『データ モデルの正規化』で説明しています。
m:n 関係の解決
多対多 (m:n) の関係は、モデルとアプリケーション開発過程を複雑にするだけでなく混
乱を招きます。m:n 関係を解決する鍵は、2 つのエンティティを分離して、これらのエ
ンティティの間に第 3 の交差 エンティティによって 2 つの 1 対多 (1:n) の関係を作
成することにあります。交差エンティティには、通常、それが接続する両方のエンティ
ティの属性が含まれます。
m:n 関係を解決するには、ビジネス ルールを再度解析します。関係を正確に図式化して
いるでしょうか。住所録の例では、32 ページの図 17 に示すように、名前 のエンティ
ティとファックス のエンティティが m:n の関係になっています。このビジネス ルール
では、「一人の人がゼロ、1 つ以上のファックス番号を持つことができる。1 つのファ
ックス番号は、複数の人が使用することがある」となっています。電話 のエンティティ
の主キーとして先に選択したものに基づいて、m:n 関係は存在しています。
32
IBM Informix データベース設計および実装 ガイド
主キーとして指定した電話番号は、 ファックス のエンティティに 2 回以上表示される
ことがあるためファックス のエンティティには問題があります。これは主キーの条件に
違反しています。主キーは一意でなければならないことに留意してください。
この m:n の関係を解決するために、図 18 に示すように、名前 のエンティティとファ
ックス のエンティティとの間に交差エンティティを追加できます。新しい交差エンティ
ティ、ファックス名 には、fax_num と rec_num という 2 つの属性が含まれていま
す。エンティティの主キーは、これら両方の属性を複合したものです。個別にみると、
各属性は属性が由来する表を参照する外部キーです。名前表とファックス名表との間の
関係は、1:n です。1 つの名前が多くのファックス番号と関係することがあり得るため
です。一方、各ファックス名の組合せは、1 つの rec_num と関係する可能性がありま
す。各番号は複数のファックス名の組合せと関係し得るためファックス表とファックス
名表との間の関係は 1:n です。
図 18. 多対多 (m:n) 関係の解決
その他の特別な関係の解決
上記以外にも、データベースの円滑な実行を妨げる特別な関係があります。これらの関
係には、次のようなものがあります。
v 複雑な関係
v 再帰的関係
第 2 章 リレーショナル データ モデルの作成
33
v 冗長な関係
複雑な 関係とは、3 つ以上のエンティティ間の関係です。関係が存在するには、すべて
のエンティティが存在しなければなりません。この複雑さを軽減するには、すべての複
雑な関係をエンティティとして再分類し、元のエンティティのそれぞれに対する 2 進関
係に整理します。
再帰的 関係とは、同じ型のエンティティのオカレンス間の関係です。このタイプの関係
は頻繁に発生するものではありません。再帰的関係の例としては、部品表 (パーツがサ
ブパーツで構成されている) や組織構造 (ある社員が他の社員を管理する) があります。
再帰的関係を解決しないほうを選択することもできます。再帰的関係の詳しい例につい
ては、「IBM Informix: SQL ガイド: チュートリアル」を参照してください。
冗長な 関係は、複数の関係が同じ概念を表す場合に存在します。冗長な関係は、データ
モデルを複雑にし、開発者がデータ モデルの属性を誤って設定する原因にもなります。
この関係は、E-R ダイアグラムの中で重複したエンティティとして表されます。例え
ば、同じ属性を含む 2 つのエンティティがある場合があります。冗長な関係を解決する
には、データ モデルを見直します。同じ属性を含んだエンティティが 2 つ以上指定さ
れていないでしょうか。冗長性を解決するには、モデルに新しいエンティティを追加す
る必要があります。「IBM Informix: Dynamic Server パフォーマンス ガイド」に、デー
タ モデルの冗長性に関連するトピックがあります。
データ モデルの正規化
本章の住所録は、良いモデル例です。現状のままでもこのモデルをデータベースとして
実現できますが、アプリケーション開発やデータ操作に、後で問題が発生する可能性が
あります。正規化 とは、属性をエンティティと関連付けるルールを適用する形式化され
たアプローチです。
データ モデルを正規化すると、以下の目標が達成できます。どちらのデータ型も、以下
を実行できます。
v 設計の柔軟性を向上させる。
v 属性を正しい表に入れる。
v データの冗長性を少なくする。
v プログラマの能率を高める。
v アプリケーションの保守コストを引き下げる。
v データ構造の安定性を最大限に高める。
正規化は、エンティティをより適切な物理特性にするためのいくつかの手順で構成され
ています。これらの手順を正規化ルールと呼びます。正規形 と呼ばれることもありま
す。正規形にはいくつかあります。本章では、最初の 3 つの正規形を説明します。各正
34
IBM Informix データベース設計および実装 ガイド
規形は、直前の正規形よりもデータを制約します。このため、第 2 正規形を実現するに
は第 1 正規形を実現し、第 3 正規形を実現するには第 2 正規形を実現しなければなり
ません。
第 1 正規形
エンティティに反復されるグループがない場合、そのエンティティは第 1 正規形となり
ます。したがって、表に反復される列がない場合、その表は第 1 正規形となります。反
復列は、データの柔軟性を低下させ、ディスク領域を浪費し、データの探索を困難にし
ます。図 19 の住所録の例では、名前表に child1、child2、および child3 という反復列
が含まれています。
rec_num lname
fname
bdate
anniv
email
child1
child2
child3
図 19. 正規化前のエンティティ名前
現行の表にはいくつかの問題点があります。この表は、子供の有無にかかわらず、3 人
の子供を記録するためのディスク領域を常に確保しておかなくてはなりません。記録可
能な子供の最大数は 3 人ですが、4 人以上の子供を持つ人もいるはずです。また、特定
の子供を探す場合、各行につき 3 つの列をすべて探索しなければなりません。
反復列を除去して、表を第 1 正規形にするには、図 20 に示すように表を 2 つに分割
します。反復列を表のどちらかに入れます。2 つの表間の関連付けは主キーと外部キー
を組み合わせて確立されます。名前表と関連付けられていなければ子供はいないことに
なるため、外部キー rec_num で名前表を参照します。
rec_num
lname
fname bdate anniv
rec_num
email
child_name
図 20. エンティティ名前の第 1 正規形
ここで、32 ページの図 17 で第 1 正規形でないグループを確認します。名前表とモデ
ム表 の関係は、b9600、b14400、b28800 列が反復列と考えられるため、第 1 正規形で
はありません。 b9600、b14400、b28800 列のオカレンスを格納するためにモデム表に
第 2 章 リレーショナル データ モデルの作成
35
新しい属性 b_type を追加します。図 21に、第 1 正規形で正規化されたデータ モデル
を示します。
rec_num PK
lname
fname
bdate
anniv
email
vce_num PK
rec_num FK
vce_type
fax_num PK
FK
fax_num PK
Oper_from
oper_till
rec_num FK
child_name
id_num PK
rec_num
FK
street
city
state
zipcode
b_type
mdm_num
PK
rec_num FK
PK=
FK=
図 21. 住所録のデータ モデル
第 2 正規形
すべての属性が全体 (主) キーに依存している場合、そのエンティティは第 2 正規形と
なります。したがって、表中のすべての列はその表の主キー全体に機能的に依存する 必
要があります。機能的依存性は、2 つの異なる列内の値の間にリンクが存在することを
示しています。
属性値が列に依存する 場合、列の値を変更すると属性値も変わります。属性は列の関数
になります。これを具体的に説明すると、以下のようになります。
v 表に 1 列の主キーがある場合、属性はそのキーに依存していなければならない。
v 表に複合主キーがある場合、属性は、1 つまたは数個の列ではなく、全体としてのす
べての列内の値に依存していなければならない。
v 属性が他の複数の列に依存している場合、その列は候補キーの列でなくてはならな
い。つまり、列はすべての行で一意でなければならない。
モデルを第 2 正規形に変換する場合、データの冗長性が発生し、データの変更が困難に
なる可能性があります。第 1 正規形の表を第 2 正規形の表に変換するには、主キーに
依存していない列を削除します。
36
IBM Informix データベース設計および実装 ガイド
第 3 正規形
エンティティが第 2 正規形であり、かつその属性のすべてが主キーに過渡的に依存して
いない場合、エンティティは第 3 正規形となります。過渡的依存性 とは、記述子のキ
ー属性が全体主キーのみでなく、他の記述子キー属性にも依存しており、これらの他の
属性も主キーに依存していることを意味します。SQL の用語では、第 3 正規形とは、
表内の列が、主キーに依存する記述子の列に依存していないことを意味します。
第 3 正規形に変換するには、他の記述子キー属性に依存している属性を削除します。
正規化ルールのまとめ
ここでは、以下の正規形について説明しました。
v 第 1 正規形: 表に反復列が含まれていない場合、その表は第 1 正規形です。
v 第 2 正規形: 表が第 1 正規形であり、かつ全体 (主) キーに依存している列のみを含
んでいる場合、その表は第 2 正規形です。
v 第 3 正規形: 表が第 2 正規形であり、かつ主キーに過渡的にも依存していない列の
みが含まれている場合、その表は第 3 正規形です。
これらのルールに従っている場合、リレーショナル データベースの創案者である E. F.
Codd によると、モデルの表は第 3 正規形です。表が第 3 正規形ではない場合は、モ
デルに冗長なデータが存在するか、表を更新しようとするときに問題が発生する可能性
があります。
これらのルールを維持している属性を見つけることができない場合、次のいずれかのエ
ラーが発生している可能性があります。
v その属性は明確に定義されていない。
v その属性は直接的でなく導出される属性である。
v その属性は、実際には属性ではなく、エンティティか関係である。
v モデルから欠落したエンティティや関係がある。
第 2 章 リレーショナル データ モデルの作成
37
38
IBM Informix データベース設計および実装 ガイド
第 3 章 データ型の選択
ドメインの定義 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
データ型 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
データ型の選択 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
数値型 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
カウンタとコード: 整数 (INTEGER) 型、小桁整数 (SMALLINT) 型、および 8 バイト整数
(INT8) 型 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
自動シーケンス: シリアル (SERIAL) 型および 8 バイト シリアル (SERIAL8) 型 . . . . .
近似値: 実数 (FLOAT) 型と小桁実数 (SMALLFLOAT) 型 . . . . . . . . . . . . .
精度を調整可能な浮動小数点: DECIMAL(p) 型 . . . . . . . . . . . . . . . . .
固定精度の数値: 10 進数 (DECIMAL) 型と金額 (MONEY) 型 . . . . . . . . . . . .
日付、時間に関するデータ型 . . . . . . . . . . . . . . . . . . . . . . . .
カレンダ日付: 日付 (DATE) 型 . . . . . . . . . . . . . . . . . . . . . .
時刻: 日時 (DATETIME) 型 . . . . . . . . . . . . . . . . . . . . . . .
日時 (DATETIME) 型フォーマットの選択 (GLS) . . . . . . . . . . . . . . . .
ブール データ型 (IDS) . . . . . . . . . . . . . . . . . . . . . . . . . .
文字 (CHARACTER) 型 (GLS). . . . . . . . . . . . . . . . . . . . . . . .
文字データ: CHAR(n) と NCHAR(n). . . . . . . . . . . . . . . . . . . . .
可変長文字列: CHARACTER VARYING(m,r) 型、VARCHAR(m,r) 型、NVARCHAR(m,r) 型、お
よびラージ可変長文字 (LVARCHAR) 型 . . . . . . . . . . . . . . . . . . .
可変長文字と実行時間 . . . . . . . . . . . . . . . . . . . . . . . . .
大規模な文字型オブジェクト: テキスト (TEXT) 型 . . . . . . . . . . . . . . . .
バイナリ オブジェクト: バイト (BYTE) 型 . . . . . . . . . . . . . . . . . .
テキスト (TEXT) 型とバイト (BYTE) 型の使用方法 . . . . . . . . . . . . . . .
データ型の変更 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NULL 値 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
デフォルト値 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
チェック制約 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
参照制約 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
40
40
43
44
44
46
47
47
49
49
50
52
53
53
53
54
55
56
57
57
58
58
59
59
60
本章について
データ モデルの作成が済んだら、そのデータ モデルをデータベースおよび表として実
装する必要があります。データ モデルを実装するには、最初に、ドメイン、つまりデー
タ値の集合を列ごとに定義します。この章では、列データ型と制約を定義するときに決
定する必要のある事項について説明します。
2 番目の手順では、第 4 章で説明しているように、CREATE DATABASE 文と
CREATE TABLE 文を使用してモデルを実装し、表にデータを追加します。
© Copyright IBM Corp. 1996, 2004
39
ドメインの定義
第 2 章で説明したデータ モデルを完全なものとするには、各列にドメインを 1 つ定義
する必要があります。列のドメイン は、列に設定されている制約を記述し、属性 (列)
が想定できる一連の有効値を示します。
ドメインを定義するのは、モデルのデータの意味整合性 を保護するためです。つまり、
モデルのデータが適切に現実を反映していることを確実にすることです。電話番号を名
前に置き換えたり、整数値のみ有効なデータに小数値を入力したりすることができる
と、データ モデルの整合性は保証されなくなります。
ドメインを定義するには、制約 を定義します。データ値は、ドメインの一部を構成する
前にこの制約を満たす必要があります。列のドメインを指定するには、次の制約を使用
します。
v データ型
v デフォルト値
v チェック制約
v 参照制約
データ型
列に対する最初の制約は、列にデータ型を指定することにより課されます。データ型を
選択するとき、そのデータ型によって表すことができる値のみを含むように列を制約し
ます。
それぞれのデータ型は、特定の情報のみ表すことができます。ある列にとっての正しい
データ型とは、その列に適したデータ値はすべて表現でき、その列に適さない値はほと
んど表現できないデータ型のことです。
本章では、組込みデータ型について説明します。
Dynamic Server
Dynamic Server がサポートする拡張データ型について詳しくは、 139 ページの『第 8
章 Dynamic Server での拡張データ型の作成と使用』を参照してください。
Dynamic Server の終り
データ型の選択
表内の列ごとにデータ型が必要です。データ型の選択が重要である理由を、次に示しま
す。
v 列に格納できる有効なデータ項目のセットが設定される。
40
IBM Informix データベース設計および実装 ガイド
v データに対して実行できる操作のタイプが決定される。
例えば、文字データ型で定義された列に対しては SUM などの集計関数は適用できな
い。
v 各データが占有するディスク領域の大きさは、データ型によって決定する。
表が小さい場合、何十万行の表の場合ほど、データ項目に割り当てる領域について考
慮する必要はありません。表の行数がそれほど多くなると、4 バイト データ型と 8
バイト データ型の差が重要になってきます。
42 ページの図 22 は、組込みデータ型の選択肢をまとめた決定木を示します。これらの
選択については、以降のセクションで説明します。
第 3 章 データ型の選択
41
図 22. データ型の選択 (1/2)
42
IBM Informix データベース設計および実装 ガイド
図 22. データ型の選択 (2/2)
数値型
数値データ型には、カウンタやコードに最適なもの、科学技術分野の数値計算に最適な
もの、金額に最適なものなどがあります。
第 3 章 データ型の選択
43
カウンタとコード: 整数 (INTEGER) 型、小桁整数 (SMALLINT) 型、および
8 バイト整数 (INT8) 型
整数 (INTEGER) 型と小桁整数 (SMALLINT) 型は、小さい整数を保持します。カウン
ト値、順序番号、数値による識別コード、格納される値の最大値と最小値があらかじめ
分かっている整数値などを格納する列に指定するのに適しています。
この 2 つのデータ型はどちらも、符号付き 2 進整数として格納されます。整数
(INTEGER) 型の値は 32 ビットで、-231 から 231-1 までの整数を表すことができま
す。
小桁整数 (SMALLINT) 型の値は 16 ビットのみです。これらは、-32,767 から 32,767
の範囲にある値を表すことができます。
整数 (INT) 型と小桁整数 (SMALLINT) 型のデータ型には以下の利点があります。
v 占有する領域が小さい。小桁整数 (SMALLINT) 型の場合は 1 つの値あたり 2 バイ
ト、整数 (INTEGER) 型の場合は 1 つの値あたり 4 バイトを占有します。
v SUM や MAX などの算術式、およびその式に関するソート比較を実行できます。
整数 (INTEGER) 型と小桁整数 (SMALLINT) 型を使用する場合の欠点は、格納できる
値の範囲が制限されることです。範囲外の値を格納することはできません。もちろん、
格納すべき最大値と最小値が分かっている場合は、このような制限超過は問題になりま
せん。
整数 (INTEGER) 型には収まらないような、より広い範囲の値を格納する場合は、INT8
型を使用できます。
INT8 型には次の利点があります。
v 広い範囲の値を保持できます (- (263 -1) から 263 -1 の範囲の整数)。
v SUM や MAX などの算術式、およびその式に関するソート比較を実行できます。
INT8 型を使用することの欠点は、整数 (INTEGER) 型よりも多くのディスク領域を使
用するということです。INT8 型のデータを 1 つ格納するために、IBM Informix
Extended Parallel Server (XPS) は 8 バイト、IBM Informix Dynamic Server (IDS) は 10
バイトのディスク領域を使用します。
自動シーケンス: シリアル (SERIAL) 型および 8 バイト シリアル
(SERIAL8) 型
シリアル (SERIAL) 型は、特殊な機能を持つ正整数 (INTEGER) 型です。同様に、8 バ
イト シリアル (SERIAL8) 型は、特殊な機能を持つ正の INT8 型です。表に新しい行が
挿入されると必ず、シリアル (SERIAL) 型または 8 バイト シリアル (SERIAL8) 型の
列に対し、データベース サーバは自動的に新しい値を生成します。
44
IBM Informix データベース設計および実装 ガイド
1 つの表に、複数のシリアル (SERIAL) 型および 8 バイト シリアル (SERIAL8) 型の
列を入れることはできません。値はデータベースにより生成されるため、複数のユーザ
が同時に行を追加している場合でも、追加される行のシリアル値は常に異なります。こ
のような条件下にあるとき、通常のプログラムで一意の数値コードを新しく生成するこ
とは非常に困難なため、この機能はきわめて有益です。(ただし、Dynamic Server はシ
ーケンス オブジェクトもサポートしています。これにより、演算子 CURRVAL および
NEXTVAL を介してこの機能をサポートすることもできます。シーケンス オブジェク
トについて詳しくは、「IBM Informix: SQL ガイド: 構文」の CREATE SEQUENCE に
関する説明を参照してください。)
シリアル (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 桁になります。
シリアル (SERIAL) 型または 8 バイト シリアル (SERIAL8) 型の列は、自動的に一意
の列になりません。重複するシリアル番号が絶対に発生することがないようにするに
は、一意性制約を設定する必要があります。64 ページの『CREATE TABLE の使用』
を参照してください。DB–Access で対話型スキーマ エディタを使用して表を定義する
と、一意性制約がシリアル (SERIAL) 型または 8 バイト シリアル (SERIAL8) 型の列
に自動的に適用されます。
シリアル (SERIAL) 型と 8 バイト シリアル (SERIAL8) 型のデータ型には以下の利点
があります。
v システム割当てキーを手軽に作成できます。
第 3 章 データ型の選択
45
v 複数のユーザが表を更新しているときでも一意の数値コードを生成します。
v 生成される数値の範囲を表ごとに変えることができます。
シリアル (SERIAL) 型と 8 バイト シリアル (SERIAL8) 型のデータ型には以下の欠点
があります。
v 1 つの表内で許可されるシリアル (SERIAL) 型または 8 バイト シリアル (SERIAL8)
型の列は 1 つのみです。
v 任意数しか生成できません。
次のシリアル (SERIAL) 型と 8 バイト シリアル (SERIAL8) 型の数の変更:
データベース サーバは、列の作成時にシリアル (SERIAL) 型または 8 バイト シリア
ル (SERIAL8) 型の列の開始値を設定します (64 ページの『CREATE TABLE の使用』
を参照してください)。後で ALTER TABLE 文を使用して 次の 値 (次の挿入行に使用
される値) をリセットできます。
次の 値は現行の最大値より大きい任意の値に設定できます。このようにすると、間を空
けてシリアル番号を生成することになります。
次の 値を列の現行の最大値より小さい値に設定しようとすると、エラーは発生しません
が値は設定されません。次の 値を列にある値よりも小さい値に設定することを許可する
と、状況によっては重複する数値が生成されてしまうため、許可されません。
近似値: 実数 (FLOAT) 型と小桁実数 (SMALLFLOAT) 型
科学技術や統計のアプリケーションで扱われる数値の多くは、有効桁が数桁のみで、数
値の大きさが数値の正確な桁数と同じくらいに重要です。
浮動小数点データ型はこのようなアプリケーションのために用意されています。整数で
も小数部を含む数値でも、あらゆる数値を表現でき、数値の大きさの範囲は宇宙的規模
から顕微鏡的規模に及びます。地球から太陽までの平均距離 (1.5 x 1011 メートル)
や、プランク定数 (6.626 x 10-34 ジュール秒) などを容易に表すことができます。例え
ば、次のようにします。
CREATE
INSERT
INSERT
INSERT
TABLE t1 (f FLOAT);
INTO t1 VALUES (0.00000000000000000000000000000000000001);
INTO t1 VALUES (1.5e11);
INTO t1 VALUES (6.626196e-34);
浮動小数点用のデータ型には 2 つのサイズがあります。実数 (FLOAT) 型は、コンピュ
ータ上に C 言語で実装される倍精度の 2 進浮動小数点数です。実数 (FLOAT) 型の値
は通常、8 バイトを必要とします。小桁実数 (SMALLFLOAT) 型 (小桁実数 (REAL) 型
とも呼ばれる) 型は通常、4 バイトを必要とする単精度の 2 進浮動小数点数です。この
2 つのデータ型の主な違いは精度です。
浮動小数点用のデータ型には次の利点があります。
v 非常に大きいまたは小さい数値を格納し、小数部を持つ数値も格納する。
46
IBM Informix データベース設計および実装 ガイド
v 4 バイトまたは 8 バイトで数値を簡潔に表現する。
v 浮動小数点用のデータ型の列では、AVG、MIN などの算術関数や、ソート比較を効
率的に実行できる。
主な欠点は、精度の範囲を超える桁がゼロとして扱われることです。
精度を調整可能な浮動小数点: DECIMAL(p) 型
ANSI 標準準拠でないデータベースでは、DECIMAL(p) 型は、実数 (FLOAT) 型および
小桁実数 (SMALLFLOAT) 型に類似した浮動小数点データ型です。実数型や小桁実数型
との主な違いは、有効桁の桁数 (精度) を指定できることです。p として表記する精度
の範囲は 1 から 32 まで (小桁実数 (SMALLFLOAT) より低い精度から実数 (FLOAT)
型の 2 倍の精度まで) です。DECIMAL(p) の数値の範囲は 10-130 から 10124 までで
す。DECIMAL(p) 型の数値が使用する格納領域は、その精度 (1 + p/2 バイト (必要に
応じて整数に切り上げられる)) によって異なります。
しかし、ANSI 標準準拠データベースでは DECIMAL(p) 型は小数点以下桁数がゼロの固
定小数点型であるため、DECIMAL(p) 型は、データの値の有効桁数が p 以上の場合で
も常に、精度が p である整数値を格納します。小数部分は切り捨てられます。
DECIMAL(p) 型を DECIMAL(p,s) 型 (次のセクションで説明) と混同しないでくださ
い。DECIMAL(p) 型は、指定された精度のみを持ちます。
DECIMAL(p) 型には、実数 (FLOAT) 型に対する以下の利点があります。
v 低精度から高精度まで、アプリケーションにあった精度を設定できる。
v 最大 32 桁の数値を正確に表現できる。
v 占有する記憶域の大きさは、数値の精度に比例する。
v 使用できる精度と値の範囲は、ホスト オペレーティング システムとは無関係に
Informix データベース サーバでサポートされる。
DECIMAL(p) 型には以下の欠点があります。
v DECIMAL(p) 型の値での算術演算とソートのパフォーマンスは、実数 (FLOAT) 型の
値の場合よりも多少低下します。
v 多くのプログラム言語では、DECIMAL(p) 型データ フォーマットは、実数 (FLOAT)
型および整数 (INTEGER) 型と同じ方法ではサポートされません。プログラムでデー
タベースから DECIMAL(p) 型値を抽出する場合は、処理が実行できるようにその値
を別の形式に変換する必要があります。
v DECIMAL(p) 型の形式と値は、データベースが ANSI 標準準拠かどうかに依存しま
す。
固定精度の数値: 10 進数 (DECIMAL) 型と金額 (MONEY) 型
ほとんどのビジネス アプリケーションが格納しなければならない数値は、整数部と小数
部の桁数が決まっています。例えば、米国の通貨では小数部が 2 桁で記述されます。通
第 3 章 データ型の選択
47
常記録されるトランザクションのタイプによって、左側 (整数部) に必要な桁数が分か
ります。個人的な家計などでは 5 桁、中小規模ビジネスでは 7 桁、国家予算などでは
12 から 13 桁と考えられます。
この種の数値は、値の大きさとは無関係に特定の位置に小数点が固定されるため、固定
小数点数 と呼ばれています。DECIMAL(p,s) 型は、10 進数を保持するように設計され
ています。この型の列を指定するときには、その精度 (p) を、格納できる合計桁数とし
て 1 から 32 までの範囲で指定します。また、小数点以下桁数 (s) を、小数部の桁数と
して指定します (図 23 は、精度と小数点以下桁数の関係を示します)。小数点以下桁数
がゼロになる場合もあり、これはその数値が整数であることを意味しています。整数の
みが格納されるとき、DECIMAL(p,s) 型は 32 桁までの整数を格納できます。
: 8
DECIMAL(8,3)
31964.535
: 3
図 23. 精度と小数点以下桁数
DECIMAL(p) 型と同様に、DECIMAL(p,s) 型は、その精度に比例した領域を占有しま
す。各値は、小数点以下桁数が偶数の場合は (p +3)/2 バイトを占め、小数点以下桁数が
奇数の場合は (p + 4)/2 バイトを占め、整数バイトに丸められます。
金額 (MONEY) 型は、DECIMAL(p,s) 型と同じですが、追加の機能が 1 つあります。
表示のために金額 (MONEY) 型の数値が文字型に変換されるときには必ず、通貨記号が
自動的に追加されます。
整数 (INTEGER) 型および実数 (FLOAT) 型に対する DECIMAL(p,s) 型の利点は、使用
できる精度の幅が広いこと (整数 (INTEGER) 型の 10 桁や実数 (FLOAT) 型 16 桁と
比較して最大 32 桁) と、精度と必要な格納量をアプリケーションに応じて調整できる
ことです。
DECIMAL(p,s) 型の欠点は、算術計算の効率が低いことと、プログラミング言語の多く
がこの形式の数値をサポートしていないということです。したがって、プログラムでこ
の数値を抽出する場合、通常は、処理が実行できるようにその数値を別の数値形式に変
換しなければなりません。
48
IBM Informix データベース設計および実装 ガイド
通貨フォーマットの選択:
広域言語サポート
金額の表記方法は国によって異なります。Informix データベース サーバでは、金額
(MONEY) 型の値を表示する場合、ユーザが指定した通貨形式を参照します。デフォル
トのロケールは、次のような形式の米国英語 (U.S. English) の通貨フォーマットを指定
します。
$7,822.45
英語以外のロケールについては、ロケール ファイルの MONETARY カテゴリで通貨形
式を変更できます。ロケールの使用方法について詳しくは、「IBM Informix: GLS ユー
ザーズ ガイド」を参照してください。
広域言語サポート の終り
この通貨形式をカスタマイズするには、適切なロケールを選択するか、環境変数
DBMONEY を設定します。詳しくは、「IBM Informix: SQL ガイド: 参照」を参照して
ください。
日付、時間に関するデータ型
日付、時間に関するデータ型は時間を記録します。日付 (DATE) 型は、カレンダ日付を
格納します。日時 (DATETIME) 型は、時刻を年から 1 秒以下 (小数で表現される) ま
での精度で記録します。時間隔 (INTERVAL) 型はある時点からある時点までの時間の
間隔、つまり継続時間を格納します。
カレンダ日付: 日付 (DATE) 型
日付 (DATE) 型は、カレンダ日付を格納します。日付 (DATE) 型の値は、実際には
1899 年 12 月 31 日の真夜中を起点として数えた日数を示す符号付き整数として解釈さ
れます。
日付 (DATE) 型のフォーマットは、はるか未来 (58,000 世紀) までの日付に対応できる
精度を持っています。負の日付 (DATE) 型の値は、起点 (1899 年 12 月 31 日午前 0
時) から昔にさかのぼって数えた日数として解釈されます。つまり、日付 (DATE) 型の
値 -1 は 1899 年 12 月 30 日を示します。
日付 (DATE) 型の値は整数であるため、値は算術式に使用できます。例えば、日付
(DATE) 型列の平均を求めたり、日付 (DATE) 型の列に 7 や 365 を加算できます。さ
らに、特に日付 (DATE) 型値を操作するための豊富な関数セットをサポートしていま
す。詳しくは、「IBM Informix: SQL ガイド: 構文」を参照してください。
日付 (DATE) 型はコンパクトで、1 項目あたり 4 バイトしか使用しません。算術関数
や比較は、日付 (DATE) 型の列に対しては迅速に実行されます。
第 3 章 データ型の選択
49
日付 (DATE) 型フォーマットの選択 (GLS): 日付コンポーネントの表記方法には
多くのタイプがあります。アプリケーションは日付 (DATE) 型の値を表示するとき、ユ
ーザが指定した日付フォーマットを参照します。デフォルトのロケールは、次のような
米国英語の日付フォーマットを指定します。
10/25/2001
この日付フォーマットをカスタマイズするには、適切なロケールを選択するか、環境変
数 DBDATE を設定します。詳しくは、「IBM Informix: SQL ガイド: 参照」を参照し
てください。
デフォルト以外のロケールの場合、GL_DATE 環境変数を使用して日付フォーマットを
指定できます。ロケールの使用方法について詳しくは、「IBM Informix: GLS ユーザー
ズ ガイド」を参照してください。
時刻: 日時 (DATETIME) 型
日時 (DATETIME) 型は、1 A.D から始まる年号の時刻を格納します。実際には、日時
(DATETIME) 型は、それぞれ異なる精度を持つ 28 個のデータ型のファミリです。日時
(DATETIME) 型の列を定義するときは、その精度を指定します。列には、year、month、
day、hour、minute、second、および fraction のリストからいずれかのシーケンスを含め
ることができます。したがって年のみ、月と日のみ、日と単なる時間またはミリ秒まで
指定した時間のみを格納する 日時 (DATETIME) 型の列を定義できます。日時
(DATETIME) 型の値のサイズは、50 ページの表 4 に示すように、精度によって 2 から
11 バイトまでの範囲にわたります。
日時 (DATETIME) 型の利点は、特定の日付と時刻を格納できることです。一般的に、
日時 (DATETIME) 型の列には、日時 (DATETIME) 型の修飾子に応じて、日付 (DATE)
型の列より大きい格納領域が必要です。また、日時 (DATETIME) 型の表示フォーマッ
トには柔軟性がありません。表示フォーマットの問題を回避する方法について詳しく
は、52 ページの『日時 (DATETIME) 型または時間隔 (INTERVAL) 型のフォーマッ
ト』を参照してください。
表 4. 日時 (DATETIME) 型の精度
50
精度
サイズ*
精度
サイズ*
year to year
3
day to hour
3
year to month
4
day to minute
4
year to day
5
day to second
5
year to hour
6
day to fraction(f)
5 + f/2
year to minute
7
hour to hour
2
year to second
8
hour to minute
3
year to fraction (f)
8 + f/2
hour to second
4
month to month
2
hour to fraction(f)
4 + f/2
IBM Informix データベース設計および実装 ガイド
表 4. 日時 (DATETIME) 型の精度 (続き)
精度
サイズ*
精度
サイズ*
month to day
3
minute to minute
2
month to hour
4
minute to second
3
month to minute
5
minute to fraction(f)
3 + f/2
month to second
6
second to second
2
month to fraction(f)
6 + f/2
second to fraction(f)
2 + f/2
day to day
2
fraction to fraction(f)
1 + f/2
* f が奇数の場合は、次のフル バイトにサイズを切り上げます。
時間隔 (INTERVAL) 型を使用した期間: 時間隔 (INTERVAL) 型は、継続時間、
つまり、時間の長さを格納します。2 つの日時 (DATETIME) 型の値の差は、それらを
分離する時間間隔を表す時間隔 (INTERVAL) 型です。違いが分かりやすくなるよう
に、例をいくつか示します。
v 従業員が 1997 年 1 月 21 日 (日付 (DATE) 型または日時 (DATETIME) 型) に勤務
し始めました。
v その従業員は、254 日間勤務しました (これは時間隔 (INTERVAL) 型の値で、
TODAY 関数と、日付 (DATE) 型または日時 (DATETIME) 型の値との差です)。
v 毎日 9:00 に勤務を開始しました (日時 (DATETIME) 型の値)。
v 8 時間 (時間隔 (INTERVAL) 型の値) 労働で、昼休みを 45 分間 (別の時間隔
(INTERVAL) 型の値) とります。
v 彼女が勤務を終了する時間は 17 時 45 分 (勤務開始時刻を示す日時 (DATETIME)
型値と 2 つの時間隔 (INTERVAL) 型値の合計) です。
日時 (DATETIME) 型と同様に、時間隔 (INTERVAL) 型は、異なる精度を持つデータ型
のファミリです。時間隔 (INTERVAL) 型の値は、年数や月数を表すことができます。
また日数、時間数、分数、秒数、秒以下の数を表すこともできます。18 桁の精度が可能
です。時間隔 (INTERVAL) 型の値のサイズ範囲は、表 5 に示される公式に応じて 2 か
ら 12 です。
表 5. 時間隔 (INTERVAL) 型の精度
精度
サイズ*
精度
サイズ*
year(p) to year
1 + p/2
hour(p) to minute
2 + p/2
year(p) to month
2 + p/2
hour(p) to second
3 + p/2
month(p) to month
1 + p/2
hour(p) to fraction(f)
4 + (p + f)/2
day(p) to day
1 + p/2
minute(p) to minute
1 + p/2
day(p) to hour
2 + p/2
minute(p) to second
2 + p/2
第 3 章 データ型の選択
51
表 5. 時間隔 (INTERVAL) 型の精度 (続き)
精度
サイズ*
精度
サイズ*
day(p) to minute
3 + p/2
minute(p) to fraction(f)
3 + (p + f)/2
day(p) to second
4 + p/2
second(p) to second
1 + p/2
day(p) to fraction(f)
5 + (p + f)/2
second(p) to fraction(f)
2 + (p + f)/2
hour(p) to hour
1 + p/2
fraction to fraction(f)
1 + f/2
* 小数のサイズは次のフル バイトに切り上げます。
時間隔 (INTERVAL) 型の値は、正と負のどちらにすることもできます。時間隔
(INTERVAL) 型の値は加算や減算に使用したり、他の値を掛けたり他の値で割ったりす
ることもできます。日付 (DATE) 型または日時 (DATETIME) 型の場合は、そのような
計算はできません。「4 月 23 日までの日数の半分は何日か」という問いは理にかなっ
ていますが、「4 月 23 日の半分は何日か」という問いは無意味です。
日時 (DATETIME) 型または時間隔 (INTERVAL) 型のフォーマット: データ
ベース サーバは常に、時間隔 (INTERVAL) 型または日時 (DATETIME) 型の値のコン
ポーネントを year-month-day hour:minute:second.fraction の順序で表示します。データベ
ース サーバは、オペレーティング システムに定義された日付フォーマットを参照しま
せん。日付 (DATE) 型の値をフォーマットするときに参照します。
システム定義のフォーマットで日時 (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 ...
日時 (DATETIME) 型フォーマットの選択 (GLS)
アプリケーションは日時 (DATETIME) 型の値を表示するとき、ユーザが指定した日時
(DATETIME) 型フォーマットを参照します。デフォルトのロケールは、次のような形式
の米国英語の日時 (DATETIME) 型フォーマットです。
2001-10-25 18:02:13
デフォルト以外のロケールの場合、GL_DATETIME 環境変数を使用して日時
(DATETIME) 型フォーマットを指定できます。ロケールの使用方法について詳しくは、
「IBM Informix: GLS ユーザーズ ガイド」を参照してください。
52
IBM Informix データベース設計および実装 ガイド
この日時 (DATETIME) 型フォーマットをカスタマイズするには、適切なロケールを選
択するか、GL_DATETIME または DBTIME 環境変数を設定します。これらの環境変
数について詳しくは、「IBM Informix: GLS ユーザーズ ガイド」を参照してください。
ブール データ型 (IDS)
ブール (BOOLEAN) 型は 1 バイト データ型です。ブール型の正当な値は、真 (’t’)、偽
(’f’)、または NULL です。値の大文字と小文字は区別されません。
ブール (BOOLEAN) 型の列を、別のブール (BOOLEAN) 型の列またはブール値と比較
できます。例えば、以下のような SELECT 文を使用できます。
SELECT * FROM sometable WHERE bool_col = ’t’;
SELECT * FROM sometable WHERE bool_col IS NULL;
文字 (CHARACTER) 型 (GLS)
Informix データベース サーバは、文字 (CHAR) 型、各国語文字 (NCHAR) 型、各国語
可変長文字 (NVARCHAR) 型 (特殊用途の文字データ型) などの文字データ型をサポー
トします。
文字データ: CHAR(n) と NCHAR(n)
CHAR(n) 型には、n バイトのシーケンスが含まれます。これらの文字には英語と英語以
外の文字を混在させることができ、1 バイトまたはマルチバイト (アジア諸語) のどち
らにもなります。長さ n の範囲は 1 から 32,767 までです。
データベース サーバが 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 より短い場合、データベース サーバは空白文字を値に追加して、正
確に n バイトにします。
第 3 章 データ型の選択
53
データベース サーバは、NCHAR(n) の列のデータを、ロケールが指定する順序に従っ
てソートします。例えば、フランス語のロケールは、文字 ê が値 e の後、値 f の前に
ソートされるように指定します。つまり、フランス語のロケールが指定するソート順
は、e、ê、f などです。ロケールの使用方法について詳しくは、「IBM Informix: GLS ユ
ーザーズ ガイド」を参照してください。
ヒント: CHAR(n) 型と NCHAR(n) 型のデータの差は、データのソートと比較の方法の
みです。CHAR(n) 型の列には英語以外の文字を格納できます。ただし、データ
ベース サーバはコード セット順序を使用して CHAR(n) 型の列でソートや比
較を行うため、予期した順序での結果を得ることができない場合もあります。
CHAR(n) 型または NCHAR(n) 型の値は、タブと空白を含むことはできますが、通常、
その他の非印刷文字は含みません。INSERT 文または UPDATE 文を使用して行を挿入
する場合や、ユーティリティ プログラムで行をロードする場合には、印字不可能な文字
は入力されません。しかし、埋込み SQL を使用するプログラムによって行を作成する
場合は、NULL (2 進のゼロ) 文字以外の任意の文字を挿入できます。標準的なプログラ
ムやユーティリティは印字不可能な文字を予測していないため、印字不可能な文字を文
字型の列には格納しないでください。
CHAR(n) 型または NCHAR(n) 型のデータの利点は、すべてのデータベース サーバで
利用できるということです。CHAR(n) 型または NCHAR(n) 型の欠点は、固定長である
ということのみです。データ値の長さが行ごとに大きく異なる場合は、空白部分が無駄
になります。
可変長文字列: CHARACTER VARYING(m,r) 型、VARCHAR(m,r) 型、
NVARCHAR(m,r) 型、およびラージ可変長文字 (LVARCHAR) 型
文字型列の項目は、長さが一定でないことがあります。多くは平均的な長さで、最大長
のデータは少数です。次のデータ型のそれぞれについて、m は最大バイト数、r は最小
バイト数を表します。このようなデータを格納する際にディスク領域を節約するため、
次のデータ型が用意されています。
v CHARACTER VARYING(m,r) 型。CHARACTER VARYING(m,r) 型には、最大 m
バイト、最小 r バイトのシーケンスが含まれます。このデータ型は、可変長文字デー
タの ANSI 標準準拠のフォーマットです。CHARACTER VARYING(m,r) 型は、文字
データの比較のためにコード セット順序をサポートします。
v VARCHAR (m,r) 型。VARCHAR(m,r) 型は、可変長文字データを格納するための
Informix 固有のデータ型です。機能的には、CHARACTER VARYING(m,r) 型と同じ
です。
v NVARCHAR (m,r) 型。NVARCHAR (m,r) 型も、可変長文字データを格納するため
の Informix 固有のデータ型です。これは、ロケールが指定する順序で文字データを
比較します。
54
IBM Informix データベース設計および実装 ガイド
Dynamic Server
v ラージ可変長文字 (LVARCHAR) 型。ラージ可変長文字 (LVARCHAR) 型は、長さ
が 1 バイトから 32,739 バイトまでの可変長文字データを格納するための Informix
固有のデータ型です。ラージ可変長文字 (LVARCHAR) 型は、データの比較のために
コード セット順序をサポートします。
Dynamic Server の終り
ヒント: データの比較方法の差により、NVARCHAR(m,r) 型データは、CHARACTER
VARYING(m,r) 型や VARCHAR(m,r) 型のデータと区別されます。ロケールが
コード セットとソート順を決定する方法について詳しくは、53 ページの『文
字データ: CHAR(n) と NCHAR(n)』を参照してください。
これらのデータ型の列を定義するとき、バイトの最大 数として m を指定します。挿入
された値が m バイトより少なくても、データベース サーバは 1 バイトの空白文字を
値に追加しません (CHAR(n) 型および NCHAR(n) 型の値の場合は追加されます)。その
代わりに、実際の内容のみを 1 バイト フィールドでディスクに格納します。m の上限
は、インデックス付き列で 254 バイト、インデックスなしの列で 255 バイトです。
2 番目のパラメータ r は、ディスクに格納される値に必要なバイト数の下限を設定する
オプションの予約 長です。値が r バイト未満しか要求しない場合でも、その値を保持
するために r バイトが割り当てられます。このように下限を設定するのは、行の更新時
間を節約するためです (55 ページの『可変長文字と実行時間』を参照してください)。
CHAR(n) 型に対する CHARACTER VARYING(m,r) 型または VARCHAR(m,r) 型の利点
は、以下のとおりです。
v データ項目に必要なバイト数が広範囲に変化したり、少数の項目のみが平均以上のバ
イト数を必要としたりする場合に、ディスク領域を一定に保つ。
v 小規模な表に対する問合せを高速化できる。
これらの利点は、NCHAR(n) 型と比較したNVARCHAR(m,r) 型にも当てはまります。
可変長データ型の欠点は次のとおりです。
v 255 バイトを超える長さは許可されない。
v 環境によっては表更新の速度が遅くなる。
v すべての Informix データベース サーバで利用できるとは限らない。
可変長文字と実行時間
CHARACTER VARYING(m,r) 型、VARCHAR(m,r) 型、または NVARCHAR(m,r) 型の
いずれかを使用するとき、表の行は固定バイト数ではなく可変バイト数を持ちます。表
の行がさまざまなバイト数を持っていると、データベース操作の速度はその影響を受け
ます。
第 3 章 データ型の選択
55
ディスクの 1 ページにより多くの行が格納されるため、データベース サーバは、行が
固定したバイト数を持っている場合より少ないディスク操作で表を探索できます。その
結果、問合せの実行速度は速くなります。挿入操作と削除操作についても、同じ理由か
ら多少速くなることがあります。
行を更新する場合、データベース サーバの作業量は、もとの行のバイト数より新しい行
のバイト数に依存します。新しい行のバイト数がもとの行のバイト数以下であれば、実
行時間は固定長の行の場合とそれほど変わりません。しかし、新しい行がもとの行より
非常に多いバイト数を必要とする場合、データベース サーバは多くのディスク操作を何
回も実行しなければならなくなることがあります。したがって、CHARACTER
VARYING(m,r) 型、VARCHAR(m,r) 型、または NVARCHAR(m,r) 型のデータを使用す
る表の更新は、固定長フィールドの更新よりも時間がかかる可能性があります。
このような状況を改善するには、r にデータ項目の高い比率を含むバイト数を設定する
必要があります。これにより、ほとんどの行は予約長を使用するようになり、埋め込み
で無駄になる領域はわずかになります。更新が遅くなるのは、予約バイト数を使用して
いる値が予約バイト数より長いバイト数を使用している値と置換される場合のみです。
大規模な文字型オブジェクト: テキスト (TEXT) 型
テキスト (TEXT) 型は、テキストのブロックを格納します。ビジネス フォーム、プロ
グラム ソースやデータ ファイル、またはメモなどの、独立型ドキュメントを格納する
ように設計されています。テキスト (TEXT) 型項目には任意のデータを格納できます
が、Informix ツールはテキスト (TEXT) 型項目が印刷可能であると想定するため、この
データ型は印刷可能な ASCII テキストに制限してください。
Extended Parallel Server
Extended Parallel Server は列内のテキスト (TEXT) 型をサポートしますが、BLOB 領域
にテキスト (TEXT) 型の列を格納したり、SPL ルーチンでテキスト (TEXT) 型の値を
使用することは許可しません。
Extended Parallel Server の終り
テキスト (TEXT) 型の値は、その行の他の列の値と一緒には格納されません。テキスト
型の列の値に対しては、ディスク ページ全体が割り当てられ、そのページは通常は、行
の他の値が格納される領域とは別のところに確保されます。詳しくは、「IBM Informix:
Dynamic Server 管理者ガイド」を参照してください。
CHAR(n) 型および VARCHAR(m,r) 型に対するテキスト (TEXT) 型の利点は、テキス
ト (TEXT) 型のデータ項目のサイズに制限がないことです (ただし、データを保持する
ディスク デバイスの容量まで)。テキスト (TEXT) 型の欠点は以下のとおりです。
v ディスク ページ全体が割り当てられるため、短いデータの場合はディスク容量が無
駄になります。
56
IBM Informix データベース設計および実装 ガイド
v SQL 文でテキスト (TEXT) 型の列の使用方法が制限されます (この制限について詳し
くは、57 ページの『テキスト (TEXT) 型とバイト (BYTE) 型の使用方法』を参照し
てください)。
v すべての Informix データベース サーバで使用できるわけではありません。
バイナリ オブジェクト: バイト (BYTE) 型
バイト (BYTE) 型は、プログラムが生成できるすべてのデータを保持するよう設計され
ています。このデータは例えば、グラフィック イメージ、プログラム オブジェクト フ
ァイル、任意のワード プロセッサやスプレッド シートによって保存されたドキュメン
トなどです。データベース サーバは、バイト (BYTE) 型列にあらゆる長さ、かつあら
ゆるタイプのデータを受け入れることができます。
Extended Parallel Server
Extended Parallel Server は列内のバイト (BYTE) 型をサポートしますが、BLOB 領域に
バイト (BYTE) 型の列を格納したり、SPL ルーチンでバイト (BYTE) 型の値を使用す
ることは許可しません。
Extended Parallel Server の終り
テキスト (TEXT) 型の場合と同様に、バイト (BYTE) 型データ項目は通常の行データと
は分離され、ディスク領域の全ディスク ページに格納されるのが普通です。
テキスト (TEXT) 型や CHAR(n) 型とは対照的に、バイト (BYTE) 型の利点は、どのよ
うなデータでも受け入れることです。欠点は、テキスト (TEXT) 型の場合と同じです。
テキスト (TEXT) 型とバイト (BYTE) 型の使用方法
データベース サーバは、テキスト (TEXT) 型およびバイト (BYTE) 型の列を格納およ
び取得します。テキスト (TEXT) 型またはバイト (BYTE) 型の値を取得および格納する
には、通常、IBM Informix ESQL/C などの埋込み SQL をサポートする言語で書かれた
プログラムを使用します。このようなプログラムでは、テキスト (TEXT) 型値やバイト
(BYTE) 型値の取出し、挿入、更新を、順次ファイルの読み書きと類似した要領で行う
ことができます。
SQL 文では、対話型かプログラム式かにかかわらず、以下の場合にテキスト (TEXT)
型またはバイト (BYTE) 型の列は使用できません。
v 算術式やブール式
v GROUP BY 節または ORDER BY 節の中
v UNIQUE テスト
v インデックス作成については、単独でも、あるいは複合インデックスの一部としても
使用できません。
第 3 章 データ型の選択
57
対話型で入力するか、またはフォームかレポートに入力する SELECT 文では、テキス
ト (TEXT) 型またはバイト (BYTE) 型の値に以下の操作を実行できます。
v 列名を選択できます。部分文字列指定を使用すると、値の一部を取り出すことができ
ます。
v LENGTH (column_name) を使用して、列の長さを戻すことができます。
v IS [NOT] NULL 述部を使用して、列をテストできます。
対話型の INSERT 文では、VALUES 節を使用して、テキスト (TEXT) 型またはバイト
(BYTE) 型の値を挿入できますが、その列に指定できる値は NULL のみです。ただし、
INSERT 文の SELECT フォームを使用すると、テキスト (TEXT) 型またはバイト
(BYTE) 型の値を別の表からコピーできます。
対話型の UPDATE 文では、テキスト (TEXT) 型またはバイト (BYTE) 型の列を
NULL に更新したり、テキスト (TEXT) 型またはバイト (BYTE) 型の列を戻す副問合
せに更新したりすることができます。
データ型の変更
表を作成した後で、ALTER TABLE 文を使用して列に関連付けられたデータ型を変更で
きます。このような変更が必要な場合もありますが、なるべく避けてください。理由は
次のとおりです。
v データ型を変更するには、データベース サーバは表をコピーして作成し直さなけれ
ばなりません。大きい表の場合、コピーと再作成には多大な時間とディスク領域が必
要です。
v データ型を変更すると、情報を消失することがあります。例えば、文字型の列の長さ
を短くすると、長い値は一部が切り捨てられます。数値型の列の精度を低くした場合
には、下位の桁が切り捨てられます。
v 既存のプログラム、フォーム、レポート、格納済みの問合せも場合によっては変更が
必要になります。
NULL 値
ほとんどの場合、表内の列には、NULL 値を格納できます。NULL とは、未知の列また
は使用されていない列に対する値のことです。例えば、第 2 章の住所録の例では、
name 表の anniv 列に NULL 値を含めることができます。記念日が分からない場合
は、その値を指定しません。NULL とゼロ値または空白値を混同しないように注意して
ください。例えば、次の文を使用すると、データベース stores_demo の manufact 表に
行が 1 行挿入され、lead_time 列の値が NULL になるよう指定されます。
INSERT INTO manufact VALUES (’DRM’, ’Drumm’, NULL)
58
IBM Informix データベース設計および実装 ガイド
Dynamic Server
コレクション (COLLECTION) 型の列は NULL 要素を含むことができません。コレク
ション (COLLECTION) 型については、第 8 章で説明しています。
Dynamic Server の終り
デフォルト値
デフォルト値とは、INSERT 文の中で明示的な値が指定されていない場合に列に挿入さ
れる値のことです。デフォルト値にできるのは、ユーザが定義するリテラル文字列か、
次の SQL 定数式のうちの 1 つです。
v USER
v CURRENT
v TODAY
v 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]’
第 3 章 データ型の選択
59
チェック制約について詳しくは、「IBM Informix: SQL ガイド: 構文」に記載されてい
る CREATE TABLE 文および ALTER TABLE 文を参照してください。
参照制約
各表の主キーと外部キーを識別して、列に対する参照制約を設定できます。これらのキ
ーを識別する方法については、11 ページの『第 2 章 リレーショナル データ モデルの
作成』 を参照してください。
主キーと外部キーに対して列を選択するとき、ほとんどすべてのデータ型の組合せが一
致する必要があります。例えば、主キーを文字 (CHAR) 型で定義した場合、外部キーも
文字 (CHAR) 型で定義しなければなりません。しかし、ある表の主キーにシリアル
(SERIAL) 型を指定している場合は、関係する外部キーに整数 (INTEGER) 型を指定し
ます。同様に、ある表の主キーに 8 バイト シリアル (SERIAL8) 型を指定するとき、
関係する外部キーに 8 バイト整数 (INT8) 型を指定します。任意の関係内で一緒に使用
できるデータ型の組合せは、次の 2 つのみです。
v シリアル (SERIAL) 型と整数 (INTEGER) 型
v 8 バイト シリアル (SERIAL8) 型と 8 バイト整数 (INT8) 型
参照制約付きの表を作成する方法について詳しくは、「IBM Informix: SQL ガイド: 構
文」に記載されている CREATE TABLE 文および ALTER TABLE 文を参照してくださ
い。
60
IBM Informix データベース設計および実装 ガイド
第 4 章 リレーショナル データ モデルの実装
データベースの作成 . . . . . . . . . . .
CREATE DATABASE の使用 . . . . . . .
ファイル名の重複の回避 . . . . . . . .
DB 領域の選択 . . . . . . . . . . .
トランザクション ログ機能のタイプの選択 .
CREATE TABLE の使用. . . . . . . . .
フラグメント表の作成 . . . . . . . .
表の削除または修正 . . . . . . . . .
CREATE INDEX の使用 . . . . . . . . .
複合インデックス . . . . . . . . . .
インデックスの双方向トラバース . . . . .
表名のシノニムの使用 . . . . . . . . .
シノニム連鎖の使用 . . . . . . . . . .
コマンド スクリプトの使用 . . . . . . .
スキーマの保存 . . . . . . . . . . .
ファイルの実行 . . . . . . . . . . .
例 . . . . . . . . . . . . . . .
データベースへのデータの追加 . . . . . . .
他の Informix データベースからのデータの移動 .
ソース データを表にロードする . . . . . .
一括ロード操作の実行 . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
61
62
62
62
63
64
66
66
66
67
67
67
69
69
70
70
70
70
72
72
72
本章について
本章では、SQL 構文を使用して、第 2 章で説明されているデータ モデルを実装する方
法について説明します。具体的には、データベースと表を作成し、その表にデータを入
力する方法について説明します。また、この章ではデータベース ログ オプション、表
シノニム、コマンド スクリプトについても説明します。
データベースの作成
これで、データ モデルをデータベースの表として作成する準備が整いました。作成する
には、CREATE DATABASE 文、CREATE TABLE 文、および CREATE INDEX 文を
使用します。これらの文の構文については、「IBM Informix: SQL ガイド: 構文」で説
明しています。このセクションでは、CREATE DATABASE 文および CREATE TABLE
文を使用して、データ モデルを実装する方法を説明します。
住所録のデータ モデルが、説明の目的に限り使用されていることに注意してください。
例を示すために、データ モデルは SQL 文に変換されます。
© Copyright IBM Corp. 1996, 2004
61
同じデータベース モデルを 2 回以上作成する必要がある場合もあります。モデルを作
成する文を保管して、後からその文を再実行できます。詳しくは、69 ページの『コマン
ド スクリプトの使用』を参照してください。
表を作成したら、表にデータの行を入力します。これは、手動か、ユーティリティ プロ
グラムを使用するか、または特別にプログラミングすることによって行います。
CREATE DATABASE の使用
データベースは、データ モデルのすべての部分を保持するコンテナです。要素としては
表の他にビュー、インデックス、シノニム、データベースに関連付けられたその他のオ
ブジェクトがあります。これらの要素を作成するには、まずデータベースを作成しなけ
ればなりません。
データベース サーバはデータベースを作成するときに、システム カタログにある環境
変数 DB_LOCALE からロケールを取り出してデータベースに格納します。このロケー
ルによって、データベース サーバがデータベースに格納されている文字データを解釈す
る方法が決定されます。デフォルトでは、データベース ロケールは ISO8859-1 コード
セットを使用する米国英語 (U.S. English) ロケールです。代わりのロケールを使用する
方法については、「IBM Informix: GLS ユーザーズ ガイド」を参照してください。
データベース サーバは、データベースを作成するときに、データベースの存在とそのロ
グ機能のモードを示すレコードをセットアップします。データベース サーバはディスク
領域を直接管理するため、このレコードはオペレーティング システムのコマンドからは
認識できません。
ファイル名の重複の回避
通常、1 つのコンピュータ上ではデータベース サーバの 1 つのコピーのみが実行され
ており、そのコンピュータのユーザ全員が使用するデータベースを管理しています。デ
ータベース サーバが所有しているデータベース名の一覧は 1 つのみです。各データベ
ースには、そのデータベース サーバが管理する他のデータベースとは異なる名前をつけ
なければなりません。(データベース サーバのコピーを 2 つ以上実行することも可能で
す。例えば、データベース サーバの複数のコピーを作成して、操作データから分離した
安全なテスト環境を構築できます。この場合、データベースを作成するときと、このデ
ータベースに後でアクセスするときに、必ず正しいデータベース サーバを使用してくだ
さい。)
DB 領域の選択
データベース サーバには、データベースを特定の DB 領域 に作成します。DB 領域は
ディスク領域の一部に名前が付いたものです。特定の DB 領域を使用する必要があるか
どうかはデータベース サーバ管理者に問合せてください。データベースを別の DB 領
域に置いて、そのデータベースを他のデータベースから分離したり、そのデータベース
を特定のディスク デバイスに格納したりすることができます。DB 領域、および DB
領域とディスク デバイスとの関係について詳しくは、「IBM Informix: Dynamic Server
62
IBM Informix データベース設計および実装 ガイド
管理者ガイド」を参照してください。複数の DB 領域にわたる表、または同じ DB 領
域に複数のフラグメントがある表をフラグメント化する方法については、 199 ページの
『第 11 章 次元データ モデルの作成』を参照してください。
一部の DB 領域は、信頼性を高めるために、ミラーリング、つまり 2 つのディスク デ
バイスに二重化されています。データベースの内容が特別に重要である場合、ミラーリ
ングされた DB 領域にそのデータベースを格納できます。
トランザクション ログ機能のタイプの選択
ログ付きデータベースまたはログなしデータベースを指定するには、CREATE
DATABASE 文を使用します。データベース サーバには、トランザクション ログ機能
に関して次のような選択肢があります。
v まったくログに記録しない。この選択は推奨されません。ハードウェア障害が原因で
データベースが失われた場合、最後のバックアップ以降に行われたデータ変更がすべ
て失われます。
CREATE DATABASE db_with_no_log
ログ機能を選択しない場合に、トランザクション処理に関連する BEGIN WORK 文
や他の SQL 文をデータベースで使用できません。このような事態は、データベース
を使用するプログラムの処理内容に影響を及ぼします。
Extended Parallel Server は、ログなしデータベースをサポートしません。しかし、デ
ータベース サーバはログなし表をサポートします。詳しくは、129 ページの『分散
問合せを使用するためのデータベース サーバの構成』を参照してください。
v 通常 (バッファなし) のログ機能。 これはほとんどのデータベースに対して適切な選
択です。障害が発生した場合は、コミットしていないトランザクションのみが失われ
ます。
CREATE DATABASE a_logged_db WITH LOG
v バッファ付きログ機能。 データベースを失うとしても最新の変更のごく一部のみ、
またはまったく失われない可能性もあります。リスクが少ない代わりに、変更時のパ
フォーマンスはほとんど改善されません。
CREATE DATABASE buf_log_db WITH BUFFERED LOG
バッファ付きログ機能は頻繁に更新されるデータベースに最適です (そのため更新速
度が重要) が、障害が発生したときは他のデータから更新を再作成してください。バ
ッファ付きログ機能と通常のログ機能を切り替えるには、SET LOG 文を使用しま
す。
v ANSI 標準準拠のログ機能。 このログ機能は通常のバッファなしログ機能と同じです
が、トランザクション処理に対する ANSI 規則も適用されます。詳しくは、4 ページ
の『ANSI 標準準拠データベースの使用法』を参照してください。
CREATE DATABASE std_rules_db WITH LOG MODE ANSI
第 4 章 リレーショナル データ モデルの実装
63
ANSI SQL の設計では、バッファ付きログ機能の使用が禁止されています。ANSI 標
準準拠のデータベースを作成した場合は、トランザクション ログ機能をオフにする
ことはできません。
ANSI 標準準拠でない Dynamic Server のデータベースの場合は、データベース サーバ
管理者 (DBA) は、トランザクション ログ機能をオン/オフにしたり、バッファ付きログ
をバッファなしログに変更したりすることができます。例えば、多くの新規行を挿入す
る前に、ログ機能をオフにできます。
IBM Informix Server Administrator (ISA)、または ondblog ユーティリティと ontape ユ
ーティリティを使用すると、ログ機能状態あるいはバッファリング モードを変更できま
す。これらのツールについて詳しくは、「IBM Informix: Dynamic Server 管理者ガイ
ド」を参照してください。また、SET LOG 文を使用すると、バッファ付きログとバッ
ファなしログを切り替えることもできます。SET LOG について詳しくは、
「IBM Informix: SQL ガイド: 構文」を参照してください。
CREATE TABLE の使用
データ モデルで設計した表を作成するには CREATE TABLE 文を使用します。この文
は複雑な形式をしていますが、基本的には表の列のリストです。表の各列について、次
の情報を指定します。
v 列の名前
v データ型 (作成した定義域の中のもの)
この文には、以下の制約の 1 つ以上が含まれる場合もあります。
v 主キー制約
v 外部キー制約
v NOT NULL 制約
v 一意性制約
v デフォルト制約
v チェック制約
簡単にいうと、CREATE TABLE 文は、36 ページの図 21 データ モデル図で描いたこ
とを表の言葉で表現するものです。次の例は、住所録データ モデルの文を示します。
CREATE TABLE name
(
rec_num SERIAL PRIMARY KEY,
lname
CHAR(20),
fname
CHAR(20),
bdate
DATE,
anniv
DATE,
email
VARCHAR(25)
);
64
IBM Informix データベース設計および実装 ガイド
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)
);
上記の各例では、CREATE TABLE 文で格納オプションを指定していないため、表デー
タは、そのデータベースに指定されている同じ DB 領域に格納されます。表に対してデ
ータベースの格納場所とは異なる DB 領域を指定したり、表を複数の DB 領域にフラ
第 4 章 リレーショナル データ モデルの実装
65
グメント化できます。Informix データベース サーバがサポートする各種格納オプション
について詳しくは、「IBM Informix: SQL ガイド: 構文」に記載されている 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 章を参
照してください。
表の削除または修正
表に関連付けられたインデックスおよびデータとともに表を削除するには、DROP
TABLE 文を使用します。表の定義を変更するには (例えば、チェック制約を追加するな
ど)、ALTER TABLE 文を使用します。表の定義を保持したままで、表のすべての行お
よび対応するすべてのインデックス データを削除するには、TRUNCATE 文を使用しま
す。これらの文について詳しくは、「IBM Informix: SQL ガイド: 構文」を参照してく
ださい。
CREATE INDEX の使用
CREATE INDEX 文を使用して、表の中の 1 つ以上の列に対するインデックスを作成
し、必要に応じて物理表をインデックス順にクラスタ化してください。ここでは、イン
デックスを作成するときに使用できるオプションについて説明します。CREATE INDEX
文について詳しくは、「IBM Informix: SQL ガイド: 構文」を参照してください。
次のようにして、customer 表を作成するとします。
CREATE TABLE customer
(
cust_num SERIAL(101) UNIQUE
fname
CHAR(15),
lname
CHAR(15),
company
CHAR(20),
address1 CHAR(20),
address2 CHAR(20),
66
IBM Informix データベース設計および実装 ガイド
city
CHAR(15),
state CHAR(2),
zipcode
CHAR(5),
phone
CHAR(18)
);
次の文は、customer 表の lname 列にインデックスを作成する方法を示します。
CREATE INDEX lname_index ON customer (lname);
複合インデックス
複数の列を含むインデックスを作成できます。例えば、次のようなインデックスを作成
できます。
CREATE INDEX c_temp2 ON customer (cust_num, zipcode);
インデックスの双方向トラバース
ASC および DESC キーワードは、データベース サーバがインデックスを管理する順序
を指定します。列にインデックスを作成し、これらのキーワードを省略するか、あるい
は ASC キーワードを指定すると、データベース サーバはキー値を昇順で格納します。
キーワード DESC を指定した場合、データベース サーバは、キー値を降順で格納しま
す。
昇順とは、値が最小のキーから最大のキーへの順序でキー値が格納されることです。例
えば、customer 表の lname 列に対する昇順のインデックスを作成した場合、姓は
Albertson、Beatty、Currie の順序でインデックスに格納されます。
降順とは、値が最大のキーから最小のキーへの順序でキー値が格納されることです。例
えば、customer 表の lname 列に降順のインデックスを作成すると、姓は
Currie、Beatty、Albertson の順序でインデックスに格納されます。
データベース サーバの双方向トラバース機能によって、1 つの列にインデックスを 1
つのみ作成し、ソート列が昇順または降順になるように結果のソートを指定する問合せ
のために、そのインデックスを使用できます。
表名のシノニムの使用
シノニム とは、ある SQL 識別子の代わりに使用できる別の名前のことです。CREATE
SYNONYM 文を使用すると、表、ビュー、または (Dynamic Server の場合) シーケンス
オブジェクトに代替名を宣言できます。
通常、シノニムを使用して現在のデータベースに存在しない表を参照します。例えば、
次のような文を実行すると、customer 表や orders 表の名前に対するシノニムを作成で
きます。
CREATE SYNONYM mcust FOR masterdb@central:customer;
CREATE SYNONYM bords FOR sales@boston:orders;
第 4 章 リレーショナル データ モデルの実装
67
作成したシノニムは、次の例に示すように、オリジナルの表名が有効である多くのコン
テキストで使用できます。
SELECT bords.order_num, mcust.fname, mcust.lname
FROM mcust, bords
WHERE mcust.customer_num = bords.Customer_num
INTO TEMP mycopy;
CREATE SYNONYM 文では、シノニム名を現行データベースの syssyntable システム
カタログ表に格納します。現行データベースで作成された問合せであれば、いずれもこ
のシノニムを使用できます (ただし、USETABLENAME 環境変数が設定されている場
合は、SQL の DDL 文の中には表名をシノニムで代用することをサポートしないものが
あります)。
短いシノニムを使用すると、問合せを書くのが容易になりますが、シノニムは別の役割
を果たすこともできます。シノニムを使用すると、問合せを変えずに、表を別のデータ
ベースやコンピュータに移動できます。
例えば、customer 表と orders 表を参照する問合せが複数あるとします。これらの問合
せは、プログラムやフォーム、レポートに埋め込まれています。これらの表はデモンス
トレーション データベースの一部で、このデータベースはデータベース サーバ
avignon に置かれています。
ここで、ネットワークに接続された別のコンピュータ (データベース サーバ nantes) の
ユーザも、同じプログラム、フォーム、レポートが使用できるようにすると決定したと
します。これらのユーザは、その地域での注文が含まれている orders という名前の表
が入っているデータベースを持っていますが、avignon にある customer 表にアクセス
する必要があります。
これらのユーザにとって、customer 表は外部表です。これは、特殊なバージョンのプロ
グラムやレポート、つまり、customer 表をデータベース サーバ名で修飾するバージョ
ンを作成しなければならない、ということになるのでしょうか。有効な解決策は、次の
例に示されるように、これらのユーザのデータベースにシノニムを作成することです。
DATABASE stores_demo@nantes;
CREATE SYNONYM customer FOR stores_demo@avignon:customer;
格納済みの問合せがご使用のデータベースで実行される場合、名前 customer は実際の
表を参照します。問合せがその他のデータベースで実行される場合、名前 customer は
シノニムを介して、データベース サーバ avignon にある表への参照として解決されま
す。(ANSI 標準準拠でないデータベースの場合、シノニムは、データベース内のシノニ
ム、表、ビュー、およびシーケンス オブジェクトの名前の中で一意である必要がありま
す。ANSI 標準準拠データベースの場合、データベースに tabid 値で登録されたオブジ
ェクトのネーム スペース内で、owner.synonym の組合せが一意である必要がありま
す。)
68
IBM Informix データベース設計および実装 ガイド
シノニム連鎖の使用
前述の例を続けるために、ネットワークにコンピュータが新たに接続されたと仮定しま
す。そのコンピュータの名前は db_crunch です。avignon の負荷を軽減するために、
customer 表などの表は db_crunch に移動されます。表は新しいデータベース サーバ上
にとても簡単に再作成できますが、どうすればすべてのアクセスをこの表に向けること
ができますか。1 つの方法は、次の例に示すように、シノニムをインストールし古い表
を置き換えることです。
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 回の操作ですべてのアクセスを目的の表に向け
たい場合に役立ちます。ただし、できる限り早く全ユーザのデータベースを更新して、
これらのシノニムが目的の表を直接指せるようにしなければなりません。これを行わな
いと、データベース サーバが余分なシノニムを取り扱う場合に、余分なオーバーヘッド
が発生する他の、連鎖内のいずれかのコンピュータがダウンすると、その表を見つけら
れなくなります。
1 つのアプリケーションをローカル データベースに対して実行し、後で同じアプリケー
ションを別のコンピュータ上のデータベースに対して実行することもできます。プログ
ラムは、どちらの場合も同じように順調に実行されますが、ネットワーク データベース
上では、実行速度が遅くなることがあります。データ モデルが同じである限り、プログ
ラムではデータベース同士の違いを区別できません。
コマンド スクリプトの使用
対話式に SQL 文を入力して、データベースや表を作成できます。場合によってはこの
操作を 2 回以上繰り返さなければならないことがあります。例えば、データベースの再
作成は、試験バージョンが正常に動作した後で本稼働バージョンを作成するときに必要
になります。また、同じデータ モデルを複数のコンピュータについて実装しなければな
らない場合も、データベースの再作成が必要になります。時間を掛けずにエラーの発生
数を減らすには、データベースを作成するためのすべての文をファイルに書き込み、後
でそれらの文を再実行します。
第 4 章 リレーショナル データ モデルの実装
69
スキーマの保存
dbschema は、データベースの内容を検査し、再作成するために必要なすべての SQL
文を生成するユーティリティです。データベースの最初のバージョンを作成して、希望
どおりのデータベースになるまで変更を加えます。次に dbschema を使用して、そのデ
ータベースを二重化するために必要な SQL 文を生成できます。dbschema ユーティリ
ティについて詳しくは、「IBM Informix: 移行ガイド」を参照してください。
ファイルの実行
SQL 文を対話式に入力するために使用するプログラム (DB–Access など) は、コマンド
ファイルから実行できます。DB–Access を開始して、ユーザまたは dbschema が用意し
たコマンド ファイルを読み取り、実行できます。詳しくは、「IBM Informix: DB-Access
ユーザーズ ガイド」を参照してください。
例
ほとんどの IBM Informix データベース サーバ製品は、デモンストレーション データ
ベースを備えています (このデータベースは本書の例で使用されます)。デモンストレー
ション データベースは、このデータベースを作成するために IBM Informix 製品を呼び
出すオペレーティング システムのコマンド スクリプトの形で配布されます。このコマ
ンド スクリプトをコピーして、自分のデータ モデルを自動作成するための原型として
使用できます。
データベースへのデータの追加
初期のテストの場合、データベースにデータを追加する最も簡単な方法は、DB–Access
で INSERT 文を入力する方法です。例えば、デモンストレーション データベースの
manufact 表に行を挿入するには、DB–Access で次のコマンドを入力します。
INSERT INTO manufact VALUES ('MKL', 'Martin', 15);
アプリケーション プログラム (C 言語のアプリケーションなど) を準備する場合は、そ
のアプリケーションを使用してデータベース表に行を挿入できます。
次の表は、データベースへの情報の入力に使用できる IBM Informix ツールのリストで
す。「参照」列の頭字語については、表の後で説明します。
70
ツール
内容
dbaccessdemo
dbaccessdemo_ud
サンプル データベースを作成し、そこにデータ DB-A
を追加する。
SQLR
DB–Access
明示コマンドを入力して、データベースを編集
する。
DB-A
SQLS
onunload および
onload
データベース全体または選択されたデータベー
ス表を、テープまたはディスク上のファイルと
の間でコピーする。
MG
AR
IBM Informix データベース設計および実装 ガイド
参照
ツール
内容
参照
dbload
データを 1 つ以上のテキスト ファイルから 1
つ以上の既存の表にロードする。
MG
ハイ パフォーマンス
ローダ
データベース全体、選択された表、または選択
された表から選択された列をコピーする。
HPL
LOAD および
UNLOAD
テキスト ファイルから (テキスト ファイルへ)
データをロードする。
SQLS
dbexport および
dbimport
テキスト ファイルを使用してデータベース全体 MG
をコピーする。
エンタープライズ レ
プリケーション
指定された表が更新されるたびに、選択された
データベースを更新する。
ER
onxfer
データを Extended Parallel Server から
IBM Informix Dynamic Server へコピーする。
MG
C アプリケーション
C プログラムに埋め込まれた SQL コマンドを
使用して、データベースを更新する。
ESQLC
DAPI
DBDK
Java アプリケーショ
ン
Java プログラムに埋め込まれた SQL コマンド
を使用して、データベースを更新する。
Java
DBDK
ゲートウェイ アプリ
ケーション
非 Informix データベースからデータにアクセス GM
する。
GU
ニーモニック
「参照」列の説明
SQLR
IBM Informix: SQL ガイド: 参照
SQLS
IBM Informix: SQL ガイド: 構文
MG
IBM Informix: 移行ガイド
AR
IBM Informix: Dynamic Server 管理者の参照
GM
IBM Informix: Enterprise Gateway Manager User Manual
GU
IBM Informix: Enterprise Gateway User Manual
DBDK
IBM Informix: DataBlade Developer’s Kit User’s Guide
ESQL/C
IBM Informix: ESQL/C Programmer’s Manual
Java
IBM Informix: J/Foundation Developer’s Guide
HPL
IBM Informix: ハイ パフォーマンス ローダ ユーザーズ ガイド
DB-A
IBM Informix: DB-Access ユーザーズ ガイド
ER
IBM Informix: Dynamic Server エンタープライズ レプリケーション
ガイド
第 4 章 リレーショナル データ モデルの実装
71
DAPI
IBM Informix: DataBlade API Programmer’s Guide
他の Informix データベースからのデータの移動
多くの場合、表の初期の行は、別の Informix データベースやオペレーティング システ
ム ファイルの表に格納されているデータから取り込むことができます。次のユーティリ
ティを使用すると、大量のデータを移動できます。
v onunload/onload ユーティリティ
v dbexport/dbimport ユーティリティ
v dbload ユーティリティ
v SQL LOAD 文
v ハイ パフォーマンス ローダ (HPL)
また、データベースの INSERT 文の一部として、別のデータベース サーバ上の他のデ
ータベースからデータを選択することもできます。次の例に示すように、デモンストレ
ーション データベースの items 表の情報を選択できます。
INSERT INTO newtable
SELECT item_num, order_num, quantity, stock_num,
manu_code, total_price
FROM stores_demo@otherserver:items;
ソース データを表にロードする
データ ソースが Informix データベースでない場合は、それをフラット ASCII ファイ
ルに変換する方法を見つける必要があります。フラット ASCII ファイルとは印刷可能
なデータのファイルのことで、ファイルの各行が表の 1 行の内容を表します。
dbload ユーティリティを使用すると、ASCII ファイルに格納されたデータを表にロード
できます。dbload について詳しくは、「IBM Informix: 移行ガイド」を参照してくださ
い。また、DB–Access で LOAD 文を使用すると、フラット ASCII ファイルから行を
ロードできます。LOAD 文と UNLOAD 文について詳しくは、「IBM Informix: SQL ガ
イド: 構文」を参照してください。
Extended Parallel Server
外部表 を使用すると、ファイルに格納されたデータを表にロードできます。外部表につ
いて詳しくは、「IBM Informix: Dynamic Server 管理者ガイド」を参照してください。
Extended Parallel Server の終り
一括ロード操作の実行
数百行や数千行の行を挿入する場合は、トランザクション ログ機能をオフにすること
で、時間を大幅に短縮できます。ただし、このような挿入操作をトランザクション ログ
72
IBM Informix データベース設計および実装 ガイド
に記録しても意味がありません。障害が発生して操作結果が失われても、簡単に復元で
きるためです。大量のデータを一括ロードする手順を次に示します。
v そのデータベースを他のユーザが使用している可能性が少しでもある場合は、
DATABASE EXCLUSIVE 文でそのデータベースに排他ロックを設定します。
v 管理者に依頼してデータベースのログ機能をオフにしてください。
既存のログはデータベースを現在の状態に復旧するのに使用できるため、データベー
スが失われた場合、行を復旧するために繰り返して大量挿入を行うことができます。
Extended Parallel Server
Extended Parallel Server を使用するデータベースに対するログ機能をオフにすること
はできません。しかし、データベースにログなし表 (フォーマットされていない永続
表または静的永続表) を作成できます。
Extended Parallel Server の終り
v 表にデータをロードする文かユーティリティを実行します。
v 新しくロードされたデータベースをバックアップします。
完全バックアップまたは差分バックアップの実行を管理者に依頼するか、onunload
ユーティリティを使用してご使用のデータベースのみのバイナリ コピーを作成して
ください。
v トランザクション ログ機能を復元し、データベースの排他ロックを解除します。
第 4 章 リレーショナル データ モデルの実装
73
74
IBM Informix データベース設計および実装 ガイド
第 2 部 データベースの管理
© Copyright IBM Corp. 1996, 2004
75
76
IBM Informix データベース設計および実装 ガイド
第 5 章 表フラグメント化ストラテジ
フラグメント化とは . . . . . . . . . . . . . . .
フラグメント化を使用する理由 . . . . . . . . . .
フラグメント化の責任者 . . . . . . . . . . . . .
拡張フラグメント化 (XPS) . . . . . . . . . . . .
フラグメント化とロギング . . . . . . . . . . . .
表のフラグメント化のための分散スキーム . . . . . . . .
式ベース分散スキーム . . . . . . . . . . . . .
範囲規則 . . . . . . . . . . . . . . . . .
任意規則 . . . . . . . . . . . . . . . . .
MOD 関数の使用 (IDS) . . . . . . . . . . . .
行の挿入と更新 . . . . . . . . . . . . . . .
ラウンドロビン分散スキーム . . . . . . . . . . .
範囲分散スキーム (XPS) . . . . . . . . . . . . .
システム定義ハッシュ分散スキーム (XPS) . . . . . . .
ハイブリッド分散スキーム (XPS) . . . . . . . . . .
フラグメント表の作成 . . . . . . . . . . . . . .
フラグメント表を新たに作成する . . . . . . . . . .
フラグメント化されていない表からのフラグメント表の作成 .
複数の非フラグメント表の使用 . . . . . . . . .
単一の非フラグメント表の使用 . . . . . . . . .
フラグメント表内の行 ID . . . . . . . . . . . .
スマート ラージ オブジェクトのフラグメント化 (IDS) . .
フラグメント化ストラテジの修正 . . . . . . . . . . .
フラグメント化ストラテジの再初期化 . . . . . . . .
Dynamic Server のフラグメント化ストラテジの修正 . . .
ADD 節の使用 . . . . . . . . . . . . . . .
DROP 節の使用 . . . . . . . . . . . . . .
MODIFY 節の使用. . . . . . . . . . . . . .
XPS のフラグメント化ストラテジの修正 . . . . . . .
INIT 節の使用 . . . . . . . . . . . . . . .
ATTACH 節と DETACH 節の使用 . . . . . . . .
フラグメント アクセス権の付与と取消し (IDS) . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
78
79
79
79
80
80
81
82
82
82
83
83
83
84
85
85
86
87
87
88
88
89
90
90
91
91
92
92
92
93
93
95
本章について
この章では、データベース サーバがサポートするフラグメント化ストラテジについて説
明し、さまざまなフラグメント化ストラテジの例を示します。フラグメント化、表フラ
グメントのための分散スキーム、フラグメント表の作成と修正、およびフラグメント表
へのアクセス権の付与について説明します。
© Copyright IBM Corp. 1996, 2004
77
データの競合を少なくし、問合せのパフォーマンスを向上させるフラグメント化ストラ
テジを構築する方法については、「IBM Informix: Dynamic Server パフォーマンス ガイ
ド」を参照してください。
フラグメント化とは
フラグメント化とは、データベース サーバ機能の 1 つであり、この機能を使用する
と、表レベルでデータを格納する場所を制御できます。フラグメント化を使用すると、
何らかのアルゴリズムまたはスキーマ に基づいて、任意の表内に、行またはインデック
ス キーのグループを定義できます。各グループまたはフラグメント は、パーティショ
ン とも呼ばれ、特定の物理ディスクと関連付けられた別の DB 領域に格納できます。
SQL 文を使用して、フラグメントを作成し、それらを DB 領域に割り当てます。
行またはインデックス キーをフラグメントにグループ化するため使用するスキーマは、
分散スキーム と呼ばれます。分散スキームと、フラグメントを一緒に配置する DB 領
域のセットにより、フラグメント化ストラテジ が構成されます。フラグメント化ストラ
テジの構成に必要な注意点については、「IBM Informix: Dynamic Server パフォーマン
ス ガイド」を参照してください。
表行、インデックス キー、またはその両方をフラグメント化するかどうかを決め、その
行またはキーを複数のフラグメントに分散する方法を決めたら、この分散を実現するス
キーマを決めます。Informix データベース サーバがサポートしている分散スキームにつ
いては、80 ページの『表のフラグメント化のための分散スキーム』を参照してくださ
い。
フラグメント表とインデックスを作成すると、データベース サーバは、各表の格納場所
およびインデックス フラグメントを、その他の関連情報とともに sysfragme nts という
名前のシステム カタログ表に格納します。この表を使用すると、フラグメント表とイン
デックスに関する情報にアクセスできます。ユーザ定義ルーチンをフラグメント化式の
一部として使用している場合、その情報は sysfragexprudrdep に記録されます。このシ
ステム カタログ表に格納されている情報について詳しくは、「IBM Informix: SQL ガイ
ド: 参照」を参照してください。
エンド ユーザまたはクライアント アプリケーションの観点から見れば、フラグメント
表と、フラグメント化されていない表は同じです。クライアント アプリケーションで
は、フラグメント表内のデータにアクセスできるようにするのに、どのような変更も必
要ありません。
分散スキームによっては、データベース サーバは、どのフラグメントにどのデータが格
納されているかに関する情報を所有しているため、関連のないフラグメントにアクセス
することなく、クライアントからのデータ要求を適切なフラグメントにルーティングで
きます。(ただし、ラウンドロビン分散スキームおよび式に基づく分散スキームの場合、
78
IBM Informix データベース設計および実装 ガイド
データベース サーバは、クライアントからのデータ要求を適切なフラグメントにルーテ
ィングすることはできません。詳しくは、80 ページの『表のフラグメント化のための分
散スキーム』を参照してください。)
フラグメント化を使用する理由
以下のうち少なくとも 1 つを向上させることを目標とする場合は、表のフラグメント化
を検討してください。
v シングルユーザ応答時間
v 並行性
v 可用性
v バックアップと復元の特性
v データのロード
前記の目標は、それぞれ、最終的に実現するフラグメント化ストラテジに独自の影響を
与えます。使用する主要なフラグメント化目標により、フラグメント化ストラテジの実
現方法が決定するか、あるいは少なくとも影響を受けることになります。フラグメント
化を使用して前記の目標のどれかが満たされるかどうかを決める場合、フラグメント化
には何らかの管理活動や監視活動が余分に必要になることを念頭に入れておいてくださ
い。
前記の目標およびフラグメント化ストラテジの組み立て方法の詳細については、
「IBM Informix: Dynamic Server パフォーマンス ガイド」を参照してください。
フラグメント化の責任者
フラグメント化に関して、データベース サーバ管理者の責任と DBA(データベース管理
者) の責任は、一部重複します。DBA は、表フラグメント化を含めることのできるデー
タベース スキーマを作成します。一方、データベース サーバ管理者は、フラグメント
表が常駐するディスク領域を割り当てることに責任を持ちます。このような責任は、ど
ちらも単独で実行することはできません。このため、フラグメント化を実装するには、
DBA とデータベース サーバ管理者の協力作業が必要になります。このマニュアルで
は、フラグメント化ストラテジを実現するのに DBA が実行するタスクについてのみ説
明します。フラグメント化ストラテジを実現するためにデータベース サーバー管理者が
実行するタスクについては、「IBM Informix: Dynamic Server 管理者ガイド」および
「IBM Informix: Dynamic Server パフォーマンス ガイド」を参照してください。
拡張フラグメント化 (XPS)
Extended Parallel Server は、異なるコサーバに属する複数のディスク間で表とインデッ
クスをフラグメント化できます。各表フラグメントは、異なるコサーバに属する複数の
物理ディスクと関連付けられた別個の DB 領域に常駐できます。DB スライス には、
第 5 章 表フラグメント化ストラテジ
79
複数のコサーバ間で数多くの DB 領域を管理する機能が備わっています。DB スライス
と DB 領域を作成すると、複数のコサーバ間でフラグメント化された表とインデックス
を作成できます。
複数のコサーバ間で表をフラグメント化する利点については、「IBM Informix: Extended
Parallel Server Performance Guide」を参照してください。DB スライスと DB 領域の作
成方法については、「IBM Informix: Extended Parallel Server Administrator’s Guide」を
参照してください。
フラグメント化とロギング
Dynamic Server
Dynamic Server では、フラグメント表は、ログ付きデータベースにもログなしデータベ
ースにも属することができます。フラグメント化されていない表と同様に、フラグメン
ト表がログなしデータベースの一部になっている場合、障害が発生すると、データの矛
盾が発生する可能性があります。
Dynamic Server の終り
Extended Parallel Server
Extended Parallel Server では、フラグメント表は常時ログ付きデータベースに属しま
す。ただし Extended Parallel Server は、複数のログ付き表タイプとログなし表タイプを
サポートしません。詳しくは、129 ページの『分散問合せを使用するためのデータベー
ス サーバの構成』を参照してください。
Extended Parallel Server の終り
表のフラグメント化のための分散スキーム
分散スキーム とは、行またはインデックスのエントリを複数のフラグメントに分散する
ときにデータベース サーバが使用する方法の 1 つです。Informix データベース サーバ
は、以下の分散スキームをサポートします。
v 式ベース。 この分散スキームは、指定された値を含む行を同じフラグメントに格納
します。各フラグメントに行のセットを割り当てる基準を定義するフラグメント化式
を、範囲規則または任意規則として指定します。残余フラグメント を指定すると、
他のどのフラグメントの基準とも一致しない行をすべて保持できます。ただし、残余
フラグメントを指定すると、式に基づく分散スキームの効率が低下します。
v ラウンドロビン。 この分散スキームは、一連のフラグメントを循環しながら順次に
フラグメントに行を配置することにより、行を均等に分散させます。データベース
サーバはこの規則を内部で定義しています。
80
IBM Informix データベース設計および実装 ガイド
INSERT 文では、データベース サーバは、乱数に基づいてハッシュ関数を使用し
て、行を配置するフラグメントを特定します。INSERT カーソルでは、データベース
サーバは、ランダムに決めたフラグメントに最初の行を配置し、次の順次フラグメン
トに 2 番目の行をというように順次配置していきます。フラグメントの 1 つがいっ
ぱいであれば、そのフラグメントはスキップされます。
Extended Parallel Server
v 範囲分散。この分散スキームにより、行が確実に DB 領域間で均等にフラグメント化
されます。範囲分散スキームでは、データベース サーバはユーザが指定する最小お
よび最大整数値に基づいて、フラグメント間での行の分散を決定します。データ分散
を高密度かつ均等に行うときは、範囲分散スキームを使用してください。
v システム定義ハッシュ。この分散スキームは、内部的なシステム定義規則を使用し、
各フラグメントに含まれる行数を均一にしながら行の分散を行います。
v ハイブリッド。 この分散スキームは、2 つの分散スキームが組み合わせられたもの
です。主 分散スキームでは、DB スライスが選択されます。2 次 分散スキームで
は、DB スライス内の特定の DB 領域に行が配置されます。通常、DB 領域は別個の
コサーバ上に常駐しています。
Extended Parallel Server の終り
分散スキームを指定するために使用する SQL 構文について詳しくは、「IBM Informix:
SQL ガイド: 構文」に記述されている CREATE TABLE 文、および CREATE INDEX
文の説明を参照してください。フラグメント化のパフォーマンスについては、
「IBM Informix: Dynamic Server パフォーマンス ガイド」を参照してください。
式ベース分散スキーム
式ベース分散スキームを使用するには、CREATE TABLE または CREATE INDEX 文
の FRAGMENT BY EXPRESSION 節を使用してください。次の例では、FRAGMENT
BY EXPRESSION 節を使用して、式ベース分散スキームでフラグメント表を作成してい
ます。
CREATE TABLE accounts (id_num INT, name char(15))
FRAGMENT BY EXPRESSION
id_num <= 100 IN dbspace_1,
id_num <100 AND id_num <= 200 IN dbspace_2,
id_num > 200 IN dbspace_3
CREATE TABLE 文の FRAGMENT BY EXPRESSION 節を使用してフラグメント表を
作成する場合は、作成する表の各フラグメントに条件を 1 つずつ指定する必要がありま
す。
第 5 章 表フラグメント化ストラテジ
81
範囲規則 または 任意規則 を定義することにより、複数のフラグメントに行を分散させ
る方法をデータベース サーバに指示できます。以降のセクションでは、さまざまなタイ
プの、式に基づく分散スキームを説明します。
範囲規則
範囲規則は、SQL 関係演算子と論理演算子を使用して、表内の各フラグメントの境界を
定義します。範囲規則には、次の演算子の制限付きセットを使用できます。
v 関係演算子 >、<、>=、<=
v 論理演算子 AND および OR
v 組込み関数を含む代数式
範囲規則は、次の例に示すように、簡単な代数式に基づくことができます。この例で
は、表現式は列への単純参照です。
FRAGMENT BY EXPRESSION
id_num > 0 AND id_num <= 20 IN dbsp1,
id_num > 20 AND id_num <= 40 IN dbsp2,
id_num > 40 IN dbsp3
範囲規則内の表現式は、さらに多くの代数式の論理積または論理和とすることができま
す。次の例では、2 つの範囲のセットを定義するために使用する 2 つの代数式を表示し
ています。最初の範囲のセットは代数式「YEAR(Died) - YEAR(Born)」を基にしていま
す。2 番目の範囲のセットは「MONTH(Born)」を基にしています。
FRAGMENT BY EXPRESSION
YEAR(Died) - YEAR(Born) < 21 AND MONTH(Born) >= 1
YEAR(Died) - YEAR(Born) < 40 AND MONTH(Born) >= 4
AND MONTH(Born) < 4 IN dbsp1,
AND MONTH(Born) < 7 IN dbsp2,
任意規則
任意規則は、SQL 関係演算子と論理演算子を使用します。範囲規則と違って、任意規則
では、規則を定義するのにどの関係演算子と論理演算子でも使用できます。さらに、こ
の規則では、数多くの表列を参照できます。次の例のように、通常任意規則では、デー
タをグループ化するのに論理演算子 OR を使用します。
FRAGMENT
zip_num =
zip_num =
REMAINDER
BY EXPRESSION
95228 OR zip_num = 95443 IN dbsp2,
91120 OR zip_num = 92310 IN dbsp4,
IN dbsp5
MOD 関数の使用 (IDS)
FRAGMENT BY EXPRESSION 節で MOD 関数を使用して、表内の各行を整数 (ハッ
シュ値) のセットにマッピングできます。データベース サーバは、これらの値を使用し
て、所定の行を格納するフラグメントを決めます。次の例では、式に基づいた分散スキ
ームでの MOD 関数の使用方法を示します。
82
IBM Informix データベース設計および実装 ガイド
FRAGMENT BY EXPRESSION
MOD(id_num, 3) = 0 IN dbsp1,
MOD(id_num, 3) = 1 IN dbsp2,
MOD(id_num, 3) = 2 IN dbsp3
行の挿入と更新
行を挿入または更新する場合、データベース サーバは、指定された順序でフラグメント
式を評価して、その行がフラグメントのどれかに属しているかどうかを調べます。属し
ていれば、データベース サーバは、フラグメントの 1 つにその行を挿入するか、フラ
グメントの 1 つでその行を更新します。フラグメントのどれにも属していなければ、そ
の行は残りの節で指定されたフラグメント内に配置されます。分散スキームに残りの節
が含まれていない場合で、その行が既存のどのフラグメント式の基準とも一致しない場
合は、データベース サーバは、エラーを戻します。
ラウンドロビン分散スキーム
ラウンドロビン分散スキームを指定するには、CREATE TABLE 文の FRAGMENT BY
ROUND ROBIN 節を使用してください。次の文はラウンドロビン分散スキームでフラ
グメント表を作成します。
CREATE TABLE account_2
...
...
FRAGMENT BY ROUND ROBIN IN dbspace1, dbspace2, dbspace3
データベース サーバは、ラウンドロビン分散を使用する表に数多くの行を挿入する要求
を受信した場合、各フラグメント内の行の数がほぼ同じ状態になるように行を分散しま
す。ラウンドロビン分散は、情報を複数のフラグメントに均等に分散させるため、均等
分散 とも呼ばれます。表でラウンドロビン分散を使用する場合、この表に行を分散する
規則は、データベース サーバの内部規則です。
重要: ラウンドロビン分散スキームが使用できるのは、表のフラグメント化のみです。
この分散スキームを使用してインデックスをフラグメント化することはできませ
ん。
範囲分散スキーム (XPS)
データ分散が高密度かつ均等であり、フラグメント化列に重複が含まれない場合は、範
囲分散スキームを使用して複数の DB 領域に行を均等に分散させることができます。範
囲分散では、ユーザがフラグメント間の行の分散を決定するために指定する MIN 値と
MAX 値が使用されます。
次の文には、範囲分散スキームを指定する FRAGMENT BY RANGE 節が含まれていま
す。
第 5 章 表フラグメント化ストラテジ
83
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)
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 節に対応する異なる列に対して範囲スキーマを指
定できます。ハイブリッド分散スキームで範囲フラグメント化を使用する方法について
は、85 ページの『ハイブリッド分散スキーム (XPS)』を参照してください。
システム定義ハッシュ分散スキーム (XPS)
データベース サーバは、システム定義ハッシュ アルゴリズムを使用して、指定のキー
をハッシュすることにより、データを均等に分散させます。システム定義ハッシュ アル
ゴリズムでフラグメント化を行うことで、データを均等に分散できるだけでなく、ハッ
シュされたキーを使用する問合せに対するフラグメントを自動的に除去できます。複数
の表に対してハッシュ フラグメント化を使用すると、問合せで表を結合するときにフラ
グメントを除去でき、また、ローカル コサーバにより多くの処理をさせることができま
す。
システム定義ハッシュ分散スキームは、複数のフラグメントにデータを均等に分散させ
るのに望ましい方法ですが、以下の場合は他の方法をとることをお勧めします。
v 範囲問合せを使用する場合
範囲分散スキームを使用する方がフラグメントの除去がより効果的になり、問合せの
パフォーマンスが向上します。
v 指定の列に含まれる重複値が非常に不均等であるか、または、異なる値の数が非常に
少ない場合
いずれの状態も、データ スキューが生じて、一部のフラグメントがその他のフラグ
メントより大きくなることがあります。データ スキューが生じると、データベース
84
IBM Informix データベース設計および実装 ガイド
サーバが処理のために必要とするデータの量が、一部のフラグメントでは大きく、そ
の他のフラグメントでは小さくなるため、パフォーマンスの不均等化につながりま
す。
システム定義ハッシュ分散スキームを指定するには、次のように CREATE TABLE 文
で FRAGMENT BY HASH 節を使用してください。
CREATE TABLE new_tab (id INT, name CHAR(30))
FRAGMENT BY HASH (id) IN dbspace1, dbspace2, dbspace3;
システム定義ハッシュ分散スキームでは、フラグメントを配置する DB 領域を少なくと
も 2 つ指定するか、DB スライスを 1 つ指定してください。
また、システム定義ハッシュ分散スキームに複合キーを指定することもできます。
ハイブリッド分散スキーム (XPS)
ハイブリッド 分散スキームは、同じ表に対してベース ストラテジとレベル 2 ストラテ
ジを組み合わせて適用します。ベース ストラテジは、式に基づくフラグメント化または
範囲フラグメント化のどちらでも構いません。ハイブリッド分散スキームを使用して、1
つまたは 2 つの列に対して、さまざまなフラグメント化ストラテジを適用できます。
ハイブリッド分散スキームを定義するときに、フラグメント化式の格納定義域として、
単一の DB スライス、単一の DB 領域、または複数の DB 領域を指定できます。
次の文は、表の 2 つの列に基づくハイブリッド スキーマを定義します。
CREATE TABLE hybrid_tab (col_1 INT, col_2 DATE, col_3 CHAR(4))
FRAGMENT BY HYBRID (col_1) EXPRESSION
col_1 >= 0 AND col_1 < 20 IN dbspace_1,
col_1 >= 20 AND col_1 < 40 IN dbspace_2,
col_1 >= 40 IN dbspace_3;
フラグメント表の作成
ここでは、SQL 文を使用してフラグメント表を作成および管理する方法を説明します。
表を作成すると同時に表をフラグメント化することも、既存のフラグメント化されてい
ない表をフラグメント化することもできます。これらについての概要は、以降のセクシ
ョンで説明します。フラグメント表の作成に使用する SQL 文の構文について詳しく
は、「IBM Informix: SQL ガイド: 構文」を参照してください。
フラグメント表を作成する前に、適切なフラグメント化ストラテジを決めておく必要が
あります。フラグメント化ストラテジを構成する方法については、「IBM Informix:
Dynamic Server パフォーマンス ガイド」を参照してください。
第 5 章 表フラグメント化ストラテジ
85
フラグメント表を新たに作成する
フラグメント表を作成するには、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
Dynamic Server
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 >= 10000 and order_num < 20000 IN dbspace2,
order_num >= 20000 IN dbspace3
Dynamic Server の終り
Extended Parallel Server
my_orders 表が Extended Parallel Server データベースに常駐している場合は、システム
定義ハッシュ分散スキームで表を作成して、複数のフラグメント間で均等分散を実行で
きます。ここでは my_orders 表が 120,000 行あり、これを異なる DB 領域に格納され
る 6 つのフラグメントに均等に分散させる状況を想定します。シリアル (SERIAL) 型
列 order_num を使用してフラグメントを定義することにします。
86
IBM Informix データベース設計および実装 ガイド
次の例は、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 領域に表フラグメントを
格納できます。
Extended Parallel Server の終り
フラグメント化されていない表からのフラグメント表の作成
次のような場合には、フラグメント化されていない表をフラグメント表に変換する必要
があります。
v アプリケーションで実行されたバージョンの表をフラグメント化する
いくつかの小さい表を大きい 1 つのフラグメント表に変換しようとする場合があり
ます。この方法について、次のセクションで説明します。セクション 87 ページの
『複数の非フラグメント表の使用』 の指示に従ってください。
v 既存の大規模な表をフラグメント化する
セクション 88 ページの『単一の非フラグメント表の使用』 の指示に従ってくださ
い。
変換を行う前に、新しく作成したフラグメント表を格納するための適切な数の DB 領域
を設定しておく必要があります。
複数の非フラグメント表の使用
複数のフラグメント化されていない表を結合して、1 つのフラグメント表にすることが
できます。フラグメント化されていない表の構造は同一でなければならず、別個の DB
領域に格納されていなければなりません。フラグメント化されていない表を結合するに
は、ALTER FRAGMENT 文で ATTACH 節を使用します。
例えば、3 つの非フラグメント表 account1、account2、および account3 があるとしま
す。そしてそれぞれを DB 領域 dbspace1、dbspace2、および dbspace3 に格納するとし
ます。3 つの表の構造はすべて同じであり、この 3 つの表を 1 つの表に結合し、その
表を共通列 acc_num に基づく式でフラグメント化します。
第 5 章 表フラグメント化ストラテジ
87
acc_num の値が 1120 以下の行は dbspace1 に格納します。acc_num の値が 1120 より
大きく 2000 より小さい行は dbspace2 に格納します。最後に、acc_num の値が 2000
より大きい行は dbspace3 に格納します。
以上のフラグメント化ストラテジで表をフラグメント化するには、次の 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 と DETACH の各節を使用してパフォーマンスを
向上させる方法については、「IBM Informix: Dynamic Server パフォーマンス ガイド」
を参照してください。
単一の非フラグメント表の使用
非フラグメント表からフラグメント表を作成するには、ALTER FRAGMENT 文の INIT
節を使用します。例えば、表 orders をラウンドロビンでフラグメント表に変換するとし
ます。次の SQL 文は変換を実行します。
ALTER FRAGMENT ON TABLE orders INIT
FRAGMENT BY ROUND ROBIN IN dbspace1, dbspace2, dbspace3;
フラグメント化されていない表に対する既存のインデックスは、その表と同じフラグメ
ント化ストラテジでフラグメント化されます。
フラグメント表内の行 ID
行 ID とは、行の物理位置を定義する整数を指します。フラグメント化されていない表
にある行の行 ID は、一意の定数値です。一方、フラグメント表の行には、行 ID は
割り当てられません。
重要: アプリケーションのアクセス方法として、行 ID ではなく主キーを使用すること
をお勧めします。主キーは SQL の ANSI 仕様で定義されているため、主キーを
使用してデータにアクセスすると、アプリケーションの移植性が向上します。
Extended Parallel Server
データベース サーバは、フラグメント表の行 ID をサポートしません。
Extended Parallel Server の終り
88
IBM Informix データベース設計および実装 ガイド
Dynamic Server
アプリケーションで、フラグメント表の行 ID を参照する必要がある場合、このアプリ
ケーションに対処するには、Dynamic Server を使用すると、フラグメント表の行 ID の
列を明示的に作成できます。ただし Dynamic Server は、型付き表に対する WITH
ROWIDS 節をサポートしていません。
行 ID の列を作成するには、次の SQL 構文を使用してください。
v CREATE TABLE 文の WITH ROWIDS 節
v ALTER TABLE 文の ADD ROWIDS 節
v ALTER FRAGMENT 文の INIT 節
行 ID の列を作成すると、データベース サーバは、次の動作を実行します。
v 表内の各行に 4 バイトの一意値を追加する。
v 行 ID で表のデータにアクセスするときに使用する内部インデックスを作成する。
v 内部インデックス用に、システム カタログ表 sysfragments に行を 1 行挿入する。
Dynamic Server の終り
スマート ラージ オブジェクトのフラグメント化 (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_photo in (sbcat1, sbcat2, sbcat3;
第 5 章 表フラグメント化ストラテジ
89
フラグメント化ストラテジの修正
フラグメント表を変更するには 2 つの一般的な方法があります。1 番目は、フラグメン
ト化されていない表に対する変更方法です。この変更方法には、列の追加、列の削除、
列のデータ型の変更などがあります。これらの変更方法では、通常はフラグメント化さ
れていない表に対して使用する ALTER TABLE 文を使用します。2 番目の変更方法
は、フラグメント化ストラテジに対する変更方法です。このセクションでは、SQL 文を
使用してフラグメント化ストラテジを変更する方法を説明します。
フラグメント化を実装した後に、フラグメント化ストラテジを変更しなければならない
場合があります。最も頻繁にあるのは、内部問合せの並列化または相互問合せの並列化
でフラグメント化を使用する場合にフラグメント化ストラテジを変更する必要が生じる
場合です。このような場合に、フラグメント化ストラテジの変更は、データベース サー
バ システムのパフォーマンスを向上する方法の 1 つとして使用できます。
フラグメント化ストラテジの再初期化
INIT 節が指定された ALTER FRAGMENT 文を使用して、フラグメント化されていな
い表に対する新規のフラグメント化ストラテジの定義と初期化を行ったり、フラグメン
ト表に対する既存のフラグメント化ストラテジを変換できます。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 を作成し、その後で次の
文を実行します。
90
IBM Informix データベース設計および実装 ガイド
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 節を使用して、次のアクションを行うこともでき
ます。
v 1 つのフラグメント化されていない表をフラグメント表に変換する。
v フラグメント表をフラグメント化されていない表に変換する。
v 何らかのストラテジでフラグメント化した表を、別のフラグメント化ストラテジに変
換する。
詳しくは、「IBM Informix: SQL ガイド: 構文」の ALTER FRAGMENT 文の説明を参
照してください。
Dynamic Server のフラグメント化ストラテジの修正
Dynamic Server では、ADD、DROP、および MODIFY 節を使用して、表またはインデ
ックスに対するフラグメント化ストラテジを修正できます。これらのオプションの構文
について詳しくは、「IBM Informix: SQL ガイド: 構文」に記述されている ALTER
FRAGMENT 文の説明を参照してください。
ADD 節の使用
フラグメント化ストラテジを定義するとき、1 つ以上のフラグメントの追加が必要にな
る場合があります。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 つ追加するオプションが含まれ
ています。
第 5 章 表フラグメント化ストラテジ
91
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
に移動されます。
MODIFY 節の使用
既存のフラグメント化ストラテジの 1 つ以上の式を修正するには、MODIFY 節を指定
した ALTER FRAGMENT 文を使用します。
まず、次のフラグメント表を作成します。
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;
次の 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 のフラグメント化ストラテジの修正
Extended Parallel Server では、ALTER FRAGMENT ON TABLE 文の次のオプションが
サポートされています。
v ATTACH 節
v DETACH 節
v INIT 節
92
IBM Informix データベース設計および実装 ガイド
ハッシュ フラグメント化を使用する表では、INIT オプションのみがサポートされてい
ます。
Extended Parallel Server は、DROP および MODIFY オプション、ALTER FRAGMENT
ON INDEX 文、または明示的な行 ID 列をサポートしていません。削除または修正操
作を処理するには、DROP および MODIFY の代わりにサポートされているオプション
を使用してください。
INIT 節の使用
フラグメント化ストラテジの変更においてデータの移動が必要な場合、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;
ATTACH 節と DETACH 節の使用
データを移動する必要がある場合、INIT 節を指定した ALTER FRAGMENT 文を使用
できます。それ以外の場合、既存のフラグメントの式を変更する以下のオプションを指
定した ALTER FRAGMENT 文を使用します。
v DETACH 節を使用して、修正する式のあるフラグメントを削除する。
v 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;
第 5 章 表フラグメント化ストラテジ
93
次の文は、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;
重要: 表がハッシュ フラグメント化されている場合には、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;
sales 表からデータを失わずに 3 番目のフラグメント dbspace3 を削除するには、次の
文を実行します。
94
IBM Informix データベース設計および実装 ガイド
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)
有益なフラグメント アクセス権を付与する場合は、データ分散を制御するストラテジを
持つ必要があります。式によるデータ レコードのフラグメント化は効果的なストラテジ
の 1 つです。ラウンドロビン アルゴリズムによるデータ レコード分散ストラテジは、
新しいデータ レコードが次のフラグメントに追加されるため、有益なストラテジではあ
りません。ラウンドロビン分散は、データ分散を追跡する有効な方法をすべて無効にし
てしまうため、フラグメント化の権限が実際に使用されることはなくなってしまいま
す。式ベース分散とラウンドロビン分散ではこのような違いがあるため、GRANT
FRAGMENT 文と REVOKE FRAGMENT 文は式ベースでフラグメント化された表にの
み適用されます。
フラグメント表を作成する場合、デフォルトのフラグメントアクセス権はありません。
GRANT FRAGMENT 文を使用して、1 つ以上のフラグメントに対する挿入、更新、削
除のアクセス権を付与します。3 つのアクセス権すべてを一度に付与する場合は、
GRANT FRAGMENT 文でキーワード ALL を使用します。ただし、フラグメントを含
む表の名前を指定しただけでは、フラグメントアクセス権を付与することはできませ
ん。特定のフラグメントを指定する必要があります。
挿入、更新、削除の各アクセス権を取り消す場合は、REVOKE FRAGMENT 文を使用し
ます。この文は、1 人以上のユーザから、フラグメント表の 1 つ以上のフラグメントに
対するアクセス権を取り消します。表に対して現在存在しているアクセス権をすべて取
り消す場合は、キーワード ALL を使用できます。コマンドにフラグメントを指定しな
いと、表のすべてのフラグメントに対して現在許可されているアクセス権が取り消され
ます。
詳しくは、「IBM Informix: SQL ガイド: 構文」の GRANT FRAGMENT 文、REVOKE
FRAGMENT 文、および SET 文の説明を参照してください。
第 5 章 表フラグメント化ストラテジ
95
96
IBM Informix データベース設計および実装 ガイド
第 6 章 データベース サーバのアクセス権の付与と制限
SQL を使用したデータへのアクセスの制限 . . . . . . . . . . .
データベースへのアクセスの制御 . . . . . . . . . . . . . . .
アクセス権の付与 . . . . . . . . . . . . . . . . . . . .
データベース レベル アクセス権 . . . . . . . . . . . . .
Connect アクセス権 . . . . . . . . . . . . . . . . .
Resource アクセス権. . . . . . . . . . . . . . . . .
データベース管理者アクセス権 . . . . . . . . . . . . .
所有権 . . . . . . . . . . . . . . . . . . . . . .
表レベル アクセス権 . . . . . . . . . . . . . . . . .
アクセス権 . . . . . . . . . . . . . . . . . . . .
Index アクセス権、Alter アクセス権、および References アクセス権
型付き表に対する Under アクセス権 (IDS) . . . . . . . . .
表フラグメントのアクセス権 (IDS) . . . . . . . . . . . .
列レベル アクセス権 . . . . . . . . . . . . . . . . .
型レベル アクセス権 . . . . . . . . . . . . . . . . .
ユーザ定義データ型の Usage アクセス権 . . . . . . . . . .
名前付き行型の Under アクセス権 . . . . . . . . . . . .
ルーチン レベル アクセス権 . . . . . . . . . . . . . . .
言語レベル アクセス権 . . . . . . . . . . . . . . . . .
SPL ルーチン . . . . . . . . . . . . . . . . . . .
外部ルーチン . . . . . . . . . . . . . . . . . . .
アクセス権の自動化 . . . . . . . . . . . . . . . . . .
コマンド スクリプトによる自動化 . . . . . . . . . . . .
ロールの使用 . . . . . . . . . . . . . . . . . . .
実行時に現行のロールを判別する方法 . . . . . . . . . . . .
SPL ルーチンによるデータへのアクセスの制御. . . . . . . . . .
データの読込みの制限 . . . . . . . . . . . . . . . . .
データへの変更の制限 . . . . . . . . . . . . . . . . .
データへの変更の監視 . . . . . . . . . . . . . . . . .
オブジェクト作成の制限 . . . . . . . . . . . . . . . .
ビューの使用 . . . . . . . . . . . . . . . . . . . . .
ビューの作成 . . . . . . . . . . . . . . . . . . . .
型付きビュー (IDS) . . . . . . . . . . . . . . . . .
ビューの重複行 . . . . . . . . . . . . . . . . . .
ビューに関する制限 . . . . . . . . . . . . . . . . . .
ベースの変更の反映 . . . . . . . . . . . . . . . . .
ビューを用いたデータの変更 . . . . . . . . . . . . . . .
ビューを用いたデータの削除 . . . . . . . . . . . . . .
ビューの更新 . . . . . . . . . . . . . . . . . . .
ビューへの挿入 . . . . . . . . . . . . . . . . . .
© Copyright IBM Corp. 1996, 2004
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 98
. 98
. 99
. 100
. 100
. 101
. 101
. 102
. 102
. 102
. 104
. 104
. 105
. 105
. 106
. 107
. 107
. 108
. 108
. 108
. 109
. 109
. 110
. 110
. 113
. 113
. 113
. 114
. 115
. 116
. 116
. 117
. 118
. 119
. 119
. 120
. 121
. 121
. 121
. 122
97
WITH CHECK OPTION キーワードの使用 . . . . . .
PREPARE 文で処理された文をビュー定義の変更時に再実行
アクセス権とビュー . . . . . . . . . . . . . . . .
ビューの作成時のアクセス権 . . . . . . . . . . . .
ビューを使用するときのアクセス権 . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
122
123
124
124
124
本章について
この章では、データベースへのアクセスの制御方法について説明します。データベース
によっては、すべてのユーザがすべてのデータにアクセスできる場合もあります。それ
以外のデータベースでは、ユーザによっては、データの一部またはすべてへのアクセス
が拒否されます。
SQL を使用したデータへのアクセスの制限
データへのアクセスは次のようなレベルで制限できます。
v GRANT 文と REVOKE 文を使用して、データベースや特定の表に対するアクセス権
を付与したり拒否したりすることができます。また、データベースの利用の仕方を制
御することもできます。
v CREATE PROCEDURE 文 または CREATE FUNCTION 文を使用して、ユーザ定義
ルーチンを記述およびコンパイルできます。ユーザ定義ルーチンは、データベース表
の読込み、変更、および作成可能なユーザの制御と監視を行います。
v CREATE VIEW 文を使用して、データの制限付きビューや修正済みビューを作成で
きます。制限は特定の列を除く縦方向または特定の行を除く横方向に適用できます
(双方向でも実行できます)。
v GRANT 文と CREATE VIEW 文を結合して、ユーザが変更できる表の部分やデータ
の内容を的確に制御できます。
v Dynamic Server では、SET ENCRYPTION PASSWORD 文、および SQL に組み込ま
れている暗号化と復号化関数を使用して、機密データの列レベルでの暗号化を実装で
きます。暗号化された文字型、BLOB 型、または CLOB 型の列を許可なしで表示で
きたユーザも、DES あるいは Triple-DES 暗号化キー (データベース内には保管され
ていません) がなければ、データをプレーン テキストに回復することはできません。
データベースへのアクセスの制御
通常のデータベース アクセス権のメカニズムでは、99 ページの『アクセス権の付与』
で説明する GRANT 文と REVOKE 文がベースになります。ただし、状況によってはオ
ペレーティング システムの機能を、データベースへのアクセスを制御するもう 1 つの
方法として使用できることもあります。
オペレーティング システムがアクセスを制御するかどうかに関係なく、データベース全
体の内容の機密レベルが高い場合は、コンピュータに固定されているパブリックディス
98
IBM Informix データベース設計および実装 ガイド
ク上へ書込みを行うのは望ましいことではありません。データの機密を保護しなければ
ならないときは、通常のソフトウェア制御を使わないようにすることができます。
ユーザ自身または別の正当なユーザがデータベースを使用していないときは、そのデー
タベースをオンラインで使用可能にしておく必要はありません。次のいずれかの方法を
使用して、アクセス不能にすることができますが、かかる労力は、方法ごとに異なりま
す。
v 物理媒体をコンピュータから切り離して、別の場所に保管する。ディスク自体がリム
ーバブルでない場合は、ディスク ドライブがリムーバブルです。
v データベース ディレクトリをテープにコピーして、テープを保管する。
v 暗号化ユーティリティを使用して、データベース ファイルをコピーする。暗号化バ
ージョンのみを保持します。
重要: 2 番目と 3 番目の方法では、コピーした後に、消去ファイルを NULL データで
上書きするプログラムを使用して、必ず元のデータベース ファイルを消去しなけ
ればなりません。
データベース ディレクトリ全体を削除する代わりに、個々の表のファイルをコピーして
から消去することもできます。インデックス ファイルにはインデックス付き列からのデ
ータのコピーが含まれているため注意が必要です。表ファイルのみではなく、インデッ
クス ファイルも削除して消去します。
アクセス権の付与
データベースを使用する許可のことをアクセス権 と呼びます。例えば、データベースを
使用する許可を Connect アクセス権と呼び、表に行を挿入する許可を Insert アクセス
権と呼びます。GRANT 文を使用すると、データベース、表、ビュー、またはプロシジ
ャへアクセス権を付与すること、またはあるロール (データベース サーバ管理の役割分
担) をユーザや他のロールへ付与できます。REVOKE 文を使用すると、データベースま
たはデータベース オブジェクトへのアクセス権を取り消すこと、またはあるロールをユ
ーザや他のロールから取り消すことができます。
ロール とは、payroll など、DBA が割り当てるアクセス権の分類です。ロールが
CREATE ROLE 文で作成された後で、DBA は GRANT 文を使用して、そのロールにア
クセス権を割り当て、個々のユーザ (または他のロール) にそのロールを割り当てるこ
とができます。これにより、類似した作業タスクを行う各ユーザはその作業タスクに必
要なアクセス権のセットを保有できます。アクセス権をロールに、そしてロールをユー
ザに割り当てることにより、アクセス権の管理を単純化できます。アクセス権の管理に
おけるロールの役割について詳しくは、109 ページの『外部ルーチン』および110 ペー
ジの『ロールの使用』も参照してください。
次に示すアクセス権のグループによって、ユーザがデータおよびデータベース オブジェ
クトに対して実行できるアクションを制御します。
第 6 章 データベース サーバのアクセス権の付与と制限
99
v データベース レベル アクセス権
v 所有アクセス権
v 表レベル アクセス権
v 列レベル アクセス権
Dynamic Server
v 型レベル アクセス権
v ルーチン レベル アクセス権
v 言語レベル アクセス権
Dynamic Server の終り
v アクセス権の自動化
GRANT 文と REVOKE 文の構文については、「IBM Informix: SQL ガイド: 構文」を
参照してください。
データベース レベル アクセス権
3 つのレベルのデータベース アクセス権で、誰がデータベースにアクセスできるかを総
体的に制御します。ロールではなく、個々のユーザのみがデータベース レベル アクセ
ス権を保有できます。
Connect アクセス権
最低限のアクセス権レベルとして、表の問合せや変更を行う基本的能力をユーザに与え
る Connect アクセス権があります。Connect アクセス権を持っているユーザは次の機能
を実行できます。
v 必要な表レベル アクセス権を持っているという条件で、SELECT 文、INSERT 文、
UPDATE 文、および DELETE 文を実行する。
v 必要な表レベル アクセス権を持っているという条件で、SPL ルーチンを実行する。
v ビューがベースにしている表に対して問合せを行う許可が与えられているという条件
でビューを作成する。
v 一時表を作成し、その一時表に対するインデックスを作成する。
この Connect アクセス権を持っていないユーザは、データベースにアクセスできませ
ん。通常、機密度の高いデータや個人データの含まれていないデータベースでは、デー
タベースの作成直後に GRANT CONNECT TO PUBLIC というアクセス権を与えます。
Connect アクセス権を PUBLIC に付与しないと、Connect アクセス権を明示的に付与さ
れたユーザのみがデータベース サーバによってデータベースにアクセスできます。限ら
れたユーザのみがアクセス権を持つ必要がある場合は、それらのユーザに Connect アク
セス権を付与し、他のユーザには付与しません。
100
IBM Informix データベース設計および実装 ガイド
ユーザと public: アクセス権は、名前を指定して単一のユーザに付与するか、
PUBLIC という名前ですべてのユーザに付与します。PUBLIC に付与されるアクセス権
は、デフォルトアクセス権として機能します。
文を実行する前に、必要なアクセス権がユーザに与えられているかどうかがデータベー
ス サーバによって判定されます。この情報はシステム カタログに格納されています。
詳しくは、103 ページの『システム カタログ表内のアクセス権』を参照してください。
データベース サーバは、最初に、アクセスを要求しているユーザに付与されているアク
セス権を探索します。要求しているアクセス権が見つかった場合は、その情報を使用し
ます。次に、制限の緩いアクセス権が PUBLIC に付与されているかどうかがチェックさ
れます。付与されている場合は、制限の緩いアクセス権がデータベース サーバによって
使用されます。そのユーザにアクセス権がまったく付与されていなければ、データベー
ス サーバは PUBLIC に付与されているアクセス権を検索します。妥当なアクセス権が
見つかれば、それが使用されます。
したがって、すべてのユーザに対する最小限のレベルのアクセス権を設定するには、
PUBLIC にアクセス権を付与します。特定の事情でそのアクセス権を無効にするには、
より高いレベルの個別アクセス権をユーザに付与します。
Resource アクセス権
Resource アクセス権は、Connect アクセス権と同じ権限を持っています。また、
Resource アクセス権を持っているユーザは、新しい永久表、インデックス、および SPL
ルーチンを作成することもできます。したがって、永続割当てディスク領域を作成でき
ます。
データベース管理者アクセス権
最高位のレベルのデータベース アクセス権はデータベース管理者つまり DBA が保有
します。つまり、データベースの作成者は、必然的に DBA になります。DBA アクセ
ス権の所有者は次の機能を実行できます。
v DROP DATABASE 文、START DATABASE 文、および ROLLFORWARD
DATABASE 文を実行する。
v 所有者が誰であるかにかかわらず、オブジェクトの削除または変更を行う。
v 他のユーザが所有する表、ビュー、およびインデックスを作成する。
v データベース アクセス権 (DBA アクセス権を含む) を別のユーザに付与する。
バージョン 10.0 より前の Dynamic Server のリリースでは、DBA はシステム カタロ
グ表の行を直接修正する DML 文および DDL 文を実行できました。しかし、このリリ
ースでは、ユーザ informix のみがシステム カタログ表を直接修正できます。ただし、
ユーザ informix であっても、システム カタログ表の内容またはスキーマは修正しない
ことを、IBM は強くお勧めします。そのような操作によりデータベースの整合性が破壊
されてしまう可能性があるためです。
第 6 章 データベース サーバのアクセス権の付与と制限
101
所有権
データベースと、その中のすべての表、ビュー、インデックス、プロシジャおよびシノ
ニムには所有者が設定されています。DBA としてのアクセス権を持っているユーザ
は、他のユーザが所有するオブジェクトも作成できますが、通常は、オブジェクトを作
成したユーザが、そのオブジェクトの所有者になります。
データベース オブジェクトの所有者は、そのオブジェクトに対するすべての権限を持っ
ていて、他のアクセス権を持っていなくても、そのオブジェクトの変更や削除を実行で
きます。
Extended Parallel Server の一般化キー (GK) インデックスの場合、所有権が処理される
方法は、その他のオブジェクトの場合と多少異なります。表の作成者以外の人物が GK
インデックスを作成したとしても、GK インデックスの FROM 節に表示される表はい
ずれも、GK インデックスが削除されるまで削除できません。詳しくは、233 ページの
『データ ウェアハウス環境での GK インデックスの使用』を参照してください。
表レベル アクセス権
表ごとに 7 つのアクセス権を適用して、所有者のアクセス権を所有者でないユーザに許
可できます。そのうちの 4 つ、つまり、Select アクセス権、Insert アクセス権、Delete
アクセス権、Update アクセス権は、表のデータに対する DML アクセスを制御しま
す。Index アクセス権はインデックスの作成を制御します。Alter アクセス権は、表定義
を変更する許可を与えます。References アクセス権は、表に対して参照制約を指定する
ための許可を与えます。
ANSI 標準準拠データベースでは、表の所有者のみにアクセス権が与えられます。それ
以外のデータベースでは、表作成の一環として、Alter アクセス権と References アクセ
ス権以外のすべての表アクセス権が、データベース サーバによって自動的に PUBLIC
に付与されます。ただし、すべての表アクセス権を PUBLIC に与えないように、環境変
数 NODEFDAC が「yes」に設定されている場合は除きます。データベース サーバがす
べての表アクセス権を PUBLIC に自動的に付与する場合は、Connect アクセス権を持っ
ていればどのユーザでも新しく作成された表にアクセスできます。そうしたくない場合
(この表にアクセスできてはならないユーザが Connect アクセス権を持っている場合)
は、表の作成後に、PUBLIC からの表に対するアクセス権をすべて取り消す必要があり
ます。
アクセス権
4 つのアクセス権によって、ユーザによる表へのアクセスの仕方を制御します。表の所
有者として、次のアクセス権を個々に付与したり、取り消したりすることができます。
v Select アクセス権では、一時表への取り出しなどの選択操作を実行できます。
v Insert アクセス権では、新しい行を追加できます。
v Update アクセス権では、既存の行を変更できます。
v Delete アクセス権では、行を削除できます。
102
IBM Informix データベース設計および実装 ガイド
Select アクセス権は、ユーザが表の内容を抽出するのに必要です。ただし、Select アク
セス権は、他のアクセス権の前提条件ではありません。ユーザは、Select アクセス権を
持っていなくても、Insert アクセス権や Update アクセス権を持つことができます。
例えば、アプリケーションに使用状況表が設定されている場合があります。その場合
は、ある特定のプログラムが開始されるたびに行が使用状況表に挿入され、その行が使
用されたことが記録されます。プログラムは、終了前にその行を更新して実行時間を表
示したり、そのユーザが実行した作業のカウントを記録します。
プログラムのすべてのユーザがこの使用状況表で行を挿入、または更新できるようにす
る場合は、その表に対する Insert アクセス権と Update アクセス権を PUBLIC に付与
します。しかし、Select アクセス権は限られたユーザにのみ付与するものとします。
システム カタログ表内のアクセス権: アクセス権は、システムカタログ表に記録
されています。Connect アクセス権を持つすべてのユーザは、システムカタログ表につ
いて問合せを行い、どんなアクセス権が誰に付与されているかを判別できます。
データベース アクセス権は sysusers システム カタログ表に記録されています。この表
では、主キーはユーザ ID になっており、またそれ以外の列のみにアクセス権レベルを
表す単一文字 C、R、または D が含まれています。キーワード PUBLIC にアクセス権
が付与されていることは、ユーザ名 PUBLIC (小文字) で分かります。
表レベル アクセス権は、表番号、権限授与者、および被権限授与者から成る複合主キー
を使用する systabauth に記録されています。列 tabauth では、リスト内で次のように
アクセス権が符号化されます。
コード 意味
s
無条件選択
u
更新
付与されていないアクセス権
i
挿入
d
削除
x
インデックス
a
変更
r
参照
ハイフン (-) は、付与されていないアクセス権を表すため、すべてのアクセス権が付与
されている場合は su-idxar と表します。 -u------ は、Update アクセス権のみが付与
されていることを表します。通常、コード文字には小文字が使用されますが、GRANT
文でキーワード WITH GRANT OPTION を使用するときは大文字になります。
3 つ目の位置にアスタリスク (*) が記されている場合は、その表と被権限授与者に何ら
かの列レベル アクセス権が存在しています。特定のアクセス権は syscolauth に記録さ
れます。その主キーは、表番号、権限授与者、被権限授与者、および列番号から成る複
合主キーです。属性は、s、u、または r の 3 文字で、アクセス権の型を示します。
第 6 章 データベース サーバのアクセス権の付与と制限
103
Index アクセス権、Alter アクセス権、および References アクセス権
Index アクセス権の保持者は、表に対してインデックスを作成したり変更したりするこ
とができます。Index アクセス権は、Select アクセス権、Insert アクセス権、Update ア
クセス権および Delete アクセス権と同じように、表の作成時に自動的に PUBLIC に付
与されます。
Index アクセス権は、どのユーザに対しても付与できますが、ユーザが実際にアクセス
するには、データベースに対する Resource アクセス権も必要です。したがって、Index
アクセス権は自動的に付与されますが (ANSI 標準準拠データベースの場合を除く)、デ
ータベースに対して Connect アクセス権しか持っていないユーザは、Index アクセス権
を実際に使用することはできません。インデックスは大きいディスク領域を占める可能
性があるため、このような制限は妥当です。
Alter アクセス権の保有者は、表に対して ALTER TABLE 文を使用し (列を追加したり
削除したりする権限も含む)、シリアル (SERIAL) 型列の開始点をリセットしたりするこ
とができます。Alter アクセス権は、データ モデルを十分に理解していて、その権限を
慎重に使用するユーザにのみ付与します。
References アクセス権を使用すると、表に対する参照制約を強制できます。Alter アクセ
ス権と同じように、References アクセス権はデータ モデルを十分に理解しているユーザ
にのみ付与してください。
型付き表に対する Under アクセス権 (IDS)
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 節を使用して表を継承階層構造内に作成する方法については、169 ページの
『表継承』を参照してください。
104
IBM Informix データベース設計および実装 ガイド
表フラグメントのアクセス権 (IDS)
GRANT FRAGMENT 文を使用して、フラグメント表の個々のフラグメントに挿入、更
新、および削除のアクセス権を付与できます。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 文または
GRANT FRAGMENT 文を使用します。
GRANT FRAGMENT 文と REVOKE FRAGMENT 文について詳しくは、
「IBM Informix: SQL ガイド: 構文」を参照してください。
列レベル アクセス権
特定の列の名前を使用して、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
人事部内の限られたメンバとすべてのマネージャに対して、次の文を実行します。
第 6 章 データベース サーバのアクセス権の付与と制限
105
GRANT SELECT ON hr_data TO harold_r
このようにして、限られたユーザが列すべてを見ることを許可します。マネージャのビ
ューをその部下のみに制限する方法については、この章の最終セクションを参照してく
ださい。勤務評価を行う重役に対しては、次のような文を実行できます。
GRANT UPDATE (performance_level, performance_notes)
ON hr_data TO wallace_s, margot_t
この文を使用して、部下の評価を管理職が入力できるようにします。人事部長、または
給与レベルを変更できる資格があるユーザに対してのみ、次のような文を実行します。
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’
型レベル アクセス権
Dynamic Server は、ユーザ定義データ型 (UDT) をサポートしています。ユーザ定義デ
ータ型が作成されると、DBA またはそのデータ型の所有者のみが、その UDT の使用
者を制御する型レベル アクセス権を付与または取り消すことができます。Dynamic
Server は、次の型レベル アクセス権をサポートしています。
v Usage アクセス権。ユーザ定義データ型の使用許可です。
106
IBM Informix データベース設計および実装 ガイド
v Under アクセス権。名前付き行型を継承階層構造内の上位型として定義できる許可で
す。
ユーザ定義データ型の Usage アクセス権
不透明 (OPAQUE) 型、ディスティンクト (DISTINCT) 型、または名前付き行型を誰が
使用できるかを制御するには、データ型に Usage アクセス権を指定します。Usage アク
セス権を使用すると、DBA またはデータ型の所有者は、列、プログラム変数 (または名
前付き行型の場合は表やビュー) にデータ型を割り当てる権限、またはデータ型にキャ
ストを割り当てるユーザの権限を制限できます。Usage アクセス権は、データ型が作成
されると自動的に PUBLIC に付与されます (ANSI 標準準拠データベースの場合を除き
ます)。ANSI 標準準拠データベースでは、データ型に対する Usage アクセス権はその
データ型の所有者に対して付与されます。
不透明 (OPAQUE) 型、ディスティンクト (DISTINCT) 型、または名前付き行型を使用
できるユーザを制限するには、まず PUBLIC の Usage アクセス権を取り消し、次に
Usage アクセス権を付与するユーザの名前を指定する必要があります。例えば、circle
という名前のデータ型の使用をあるユーザのグループのみに制限する場合、次の文を実
行します。
REVOKE USAGE ON circle
FROM PUBLIC;
GRANT USAGE ON circle
TO dawns, stevep, terryk, camber;
名前付き行型の Under アクセス権
名前付き行型に対して、Under アクセス権を付与、または取り消すことができます。こ
れにより、ユーザーが名前付き行型を継承階層構造内で別の名前付き行型の上位型とし
て割り当てられる能力を制御します。Under アクセス権は、名前付き行型が作成される
と自動的に PUBLIC に付与されます。ただし、ANSI 標準準拠データベースの場合は違
います。ANSI 標準準拠データベースでは、名前付き行型に対する Under アクセス権は
そのデータ型の所有者に対して付与されます。
特定のユーザが名前付き行型を継承階層構造内の上位型として定義する権限を制限する
には、まず PUBLIC の Under アクセス権を取り消してから、Under アクセス権を付与
するユーザ名を指定します。例えば、限られたユーザのグループのみが名前付き行型
person_t を継承階層構造内の上位型として使用できるようにする場合、次の文を使用し
ます。
REVOKE UNDER ON person_t
FROM PUBLIC;
GRANT UNDER ON person_t
TO howie, jhana, alison
UNDER 節を使用して名前付き行型を継承階層構造内に作成する方法については、164
ページの『型継承』を参照してください。
第 6 章 データベース サーバのアクセス権の付与と制限
107
ルーチン レベル アクセス権
Execute アクセス権をユーザ定義ルーチン (UDR) に適用して、その UDR を実行する
権限を非所有者に付与できます。ANSI 標準に準拠しないデータベースで UDR を作成
すると、デフォルトのルーチン レベル アクセス権は PUBLIC になります。つまり、最
初に取り消さない限り、Execute アクセス権を特定のユーザに付与する必要はありませ
ん。ANSI 標準準拠データベースでルーチンを作成すると、デフォルトでは Execute ア
クセス権が他のユーザに与えられません。したがって、特定のユーザに Execute アクセ
ス権を付与する必要があります。次の例では、ユーザ orion に Execute アクセス権を付
与し、orion が read_address という名前の UDR を使用できるようにします。
GRANT EXECUTE ON read_address TO orion;
ルーチン レベル アクセス権は、システム カタログ表 sysprocauth sysprocauth に記録
されます。システム カタログ表 sysprocauth は、ルーチン番号、権限授与者、および
被権限授与者から成る主キーを使用します。procauth 列では、Execute アクセス権は小
文字 e によって示されます。また、WITH GRANT オプションで Execute アクセス権
が付与されている場合、このアクセス権は大文字 E で表されます。
ルーチン レベル アクセス権について詳しくは、「IBM Informix: SQL ガイド: チュー
トリアル」を参照してください。
言語レベル アクセス権
Dynamic Server は、組込みのストアド プロシジャ言語 (SPL) で記述された UDR をサ
ポートしています。また、C 言語および Java 言語で記述された UDR (外部ルーチン
と呼ばれます) もサポートしています。UDR を作成するには、ユーザはデータベース内
における RESOURCE アクセス権を持っている必要があります。さらに、ストアド プ
ロシジャ言語 (SPL) で UDR を作成する場合は、ストアド プロシジャ言語 (SPL) に対
する Usage アクセス権も保有している必要があります。
SPL ルーチン
デフォルトでは、SPL に対する言語の Usage アクセス権は、ユーザ informix と、DBA
アクセス権を保有するユーザに付与されます。ただし、ユーザ informix のみが言語の
Usage アクセス権を他のユーザに付与できます。DBA アクセス権を持つユーザは、言
語の Usage アクセス権を保有していますが、これらの権限を他のユーザに付与すること
はできません。SPL ルーチンを作成するための Usage アクセス権は、デフォルトで
PUBLIC に付与されます。
次の文は、ユーザ informix が UDR を SPL で作成するアクセス権を PUBLIC から取
り消し、ユーザ mays、jones、および freeman に付与する方法を示しています。
REVOKE USAGE ON LANGUAGE SPL FROM PUBLIC
GRANT USAGE ON LANGUAGE SPL TO mays, jones, freeman
108
IBM Informix データベース設計および実装 ガイド
例えば、SPL ルーチンに対するデフォルトの Usage アクセス権が PUBLIC から取り消
されたとします。次の文は、DBA アクセス権を持つユーザが、SPL ルーチンを登録す
る Usage アクセス権をユーザ franklin、reeves、および wilson に付与する方法を示し
ます。
GRANT USAGE ON LANGUAGE SPL TO franklin, reeves, wilson
外部ルーチン
Dynamic Server のこのリリースでは、C 言語または Java 言語で記述された外部ルーチ
ンに対する言語レベルのアクセス権はサポートしていません。ただし、
IFX_EXTEND_ROLE 構成パラメータが ON の場合は、C 言語または Java 言語で記述
された UDR または DataBlade モジュールをユーザが登録、削除、または置換する場合
に必要な、組込みの EXTEND ロールを使用することにより、同等の機能が提供されま
す。
データベース サーバ管理者 (DBSA) (デフォルトではユーザ informix) のみが
EXTEND ロールを付与できます。他のロールとは異なり、SET ROLE 文で EXTEND
ロールをアクティブにしたり、GRANT 文で EXTEND ロールにアクセス権を割り当て
る必要はありません。ただし、この機能が有効なときは、このロールを保有しているユ
ーザのみが外部 UDR または DataBlade モジュールを作成または削除できます。
また、データベース サーバ管理者 (DBSA) は、IFX_EXTEND_ROLE 構成パラメータを
OFF に設定してこの制限を無効にするか、未設定のままにしておくことを選択すること
もできます。この場合は、そのデータベース上で RESOURCE アクセス権を保有するユ
ーザは、C 言語または Java 言語で記述された UDR を作成できます。
アクセス権の自動化
この設計方法では、データベースを最初にセットアップするときに、非常に多くの数の
GRANT 文を実行しなければならない場合があります。また、ユーザの業務内容が変更
されるごとに、常にアクセス権を管理する必要があります。例えば、人事部のある社員
が解雇された場合は、できる限り早く Update アクセス権を取り消す必要があります。
そのような措置をとらないと、この解雇された社員によって次のような文が実行されて
しまう可能性があります。
UPDATE hr_data
SET (emp_name, hire_date, dept_num) = (NULL, NULL, 0)
機密データが含まれているモデルでは、必要に応じて毎日または毎時間ごとにアクセス
権を少しずつ変更しなければならない場合があります。アクセス権の変更が必要になる
場合は、アクセス権を保守しやすいように自動化ツールを用意できます。
最初の手順としては、表の構造ではなく、ユーザの仕事内容に基づいてアクセス権クラ
スを指定しなければなりません。例えば、マネージャには次のアクセス権が必要です。
v この例で示された hr_data 表に対する Select アクセス権と限定的な Update アクセ
ス権
第 6 章 データベース サーバのアクセス権の付与と制限
109
v このデータベースと他のデータベースに対する Connect アクセス権
v それらのデータベース内の複数の表に対するある程度のアクセス権
マネージャが幹部に昇進したり、フィールド オフィスに出向したりした場合は、それま
でのアクセス権をすべて取り消して、新しい一連のアクセス権を付与する必要がありま
す。
サポートするアクセス権クラスを定義して、アクセス権を与えなければならないデータ
ベース、表および列を、それぞれのクラスごとに指定してください。次に、クラスごと
に 2 つの自動化ルーチン、つまりユーザにクラスを付与するためのルーチンとそのクラ
スを取り消すためのルーチンを設定します。
コマンド スクリプトによる自動化
使用するオペレーティング システムは、コマンド スクリプトの自動実行をサポートし
ているはずです。ほとんどの操作環境では、DB–Access などの対話型 SQL ツールでコ
マンドと SQL 文を受け付けて、コマンド行から実行できるようになっています。この
2 つの機能を組み合わせて、アクセス権の保守を自動化できます。
詳細は、使用するオペレーティング システム、および使用している対話型 SQL ツール
によって異なります。次の機能を実行するスクリプトを作成する必要があります。
v アクセス権が変更されるユーザ ID をパラメータとして解釈する。
v そのユーザ ID を含むようにカスタマイズされた GRANT 文または REVOKE 文の
ファイルを作成する。
v データベースを選択し、作成された GRANT 文または REVOKE 文のファイルを実
行するように指示するパラメータを指定して、対話型 SQL ツール (DB–Access など)
を起動する。
このようにすると、ユーザのアクセス権クラスの変更操作を減らして、1 つまたは 2 つ
のコマンドにすることができます。
ロールの使用
ユーザのアクセス権を場合に応じて簡単に変更するもう 1 つの方法は、ロールを使用す
ることです。データベース環境でのロールの概念は、オペレーティング システムでのグ
ループの概念に類似しています。ロールとは、1 つのデータベース機能であり、DBA
はこの機能を使用し、クラスのメンバとして扱うことによって、多くのユーザのアクセ
ス権を標準化したり変更したりすることができます。
例えば、社内のニュースやメッセージを扱うデータベースに対して接続アクセス権、挿
入アクセス権、および削除アクセス権を付与する news_mes というロールを作成できま
す。新たに従業員が入社しても、その従業員をロール news_mes に追加するだけで済み
ます。この新しい従業員は、ロール news_mes のアクセス権を獲得します。このプロセ
スは、その逆の処理も行います。つまり、news_mes のすべてのメンバのアクセス権を変
更するには、そのロールのアクセス権を変更します。
110
IBM Informix データベース設計および実装 ガイド
ロールの作成: ロール作成プロセスを開始するには、ロールの名前、およびそのロー
ルを保有するユーザに付与する接続とアクセス権を決定します。接続とアクセス権の判
断は完全に各ユーザの領域ですが、新規ロールの名前を宣言するときに考慮しなければ
ならないいくつかの要素があります。次の SQL キーワードは、ロールの名前に使用し
ないでください。
alter
connect
DBA
default
delete
execute
extend
index
insert
none
null
public
references
resource
select
update
ロール名は、データベース内の既存のロール名と異なっている必要があります。またサ
ーバ コンピュータにとって既知となっているネットワーク ユーザも含め、オペレーテ
ィング システムにとって既知のユーザ名とも異なっていなければなりません。自分のロ
ール名が一意であることを確認するには、次のシステムカタログ表だけではなく、デー
タベースを現在使用している共有メモリ構造体のユーザの名前をチェックします。
v sysusers
v systabauth
v syscolauth
v sysfragauth
v sysprocauth
v sysfragauth
v sysroleauth
v sysxtdtypeauth
状況が逆で、ユーザをデータベースに追加しているときには、そのユーザ名が既存のロ
ール名と同じになっていないかをチェックしてください。
ロール名を承認した後は、CREATE ROLE 文を使用して、新しいロールを作成します。
ロールを作成すると、デフォルトでは、ロール管理用のすべてのアクセス権が DBA に
与えられます。
重要: ロールの有効範囲は現行データベースのみです。そのため、SET ROLE 文を実行
すると、そのロールは現行データベースのみに設定されます。
ユーザのアクセス権の操作と、あるロールの他のロールへの付与: DBA である
場合は、GRANT 文を使用して、ロール アクセス権をユーザに付与できます。また、ア
クセス権を他のユーザに付与するオプションをユーザに提供することもできます。これ
を行うには、GRANT 文の WITH GRANT OPTION 節を使用します。次の例に示すよ
うに、ロールに対してアクセス権を付与するときに WITH GRANT OPTION 節を使用
することもできます。
第 6 章 データベース サーバのアクセス権の付与と制限
111
GRANT rol1 TO usr1 WITH GRANT OPTION;
ロール アクセス権を付与するときは、GRANT 文でユーザ名の代わりにロール名を使用
できます。あるロールを別のロールに付与することもできます。例えば、ロール A が
ロール B に付与されているとします。その場合は、ユーザがロール B を有効化する
と、ロール A とロール B の両方からアクセス権がユーザに与えられます。
ただし、ロール付与のサイクルを推移させることはできません。ロール A をロール B
に付与して、ロール B をロール C に付与し、さらに C を A に付与するとエラーが
戻されます。
アクセス権を変更する必要がある場合は、REVOKE 文を使用して既存のアクセス権を削
除してから、GRANT 文を使用して新しいアクセス権を追加します。
デフォルト ロールおよびデフォルト以外のロールの有効化: DBA がアクセス権
を付与してユーザをロールに追加した後、ロールを有効にする 2 つの方法があります。
v DBSA は、GRANT DEFAULT ROLE 文を使用して、PUBLIC あるいは個々のユーザ
に対してデフォルト ロール を指定できます。このロールは、ユーザがデータベース
に接続すると、初期ロール設定として自動的にアクティブになります。
v ユーザが保有するロールをユーザが SET ROLE 文でそのロールを指定したときにア
クティブにすることもできます。
ロールが有効になると、ユーザまたは PUBLIC に明示的に付与されたすべてのアクセス
権だけでなく、そのロールに付与されたすべてのアクセス権も利用できるようになりま
す。
ロールにアクセス権を付与し、その後、そのロールを指定した各ユーザのデフォルト ロ
ールとして付与すると、特定のアクセス権のセットを必要とするアプリケーションを実
行するユーザのセッションの場合には便利です。必要なアクセス権をユーザに特別に割
り当てる GRANT 文および SET ROLE 文を組み込むためにアプリケーションを再コン
パイルするのが現実的でない場合には、デフォルト ロールを使用します。
ロールでのメンバシップの確認とロールの削除: どのユーザがロールに含まれて
いるのか分からない状態になる場合があります。この場合は、ロールを作成していない
か、ロールを作成したユーザが有効でないことが考えられます。システム カタログ表
sysroleauth とシステム カタログ表 sysusers に対して問合せを行って、どの表に対して
どのユーザがアクセスを許可されているか、さらにロールがいくつ存在しているかを確
認してください。
どのユーザがどのロールを保有しているかが分かると、すでに一部のロールが不要であ
ることに気付く場合があります。ロールを削除するには、DROP ROLE 文を使用しま
す。ただし、ロールを削除するには、次の条件を満たしていなければなりません。
v システム カタログ表 sysusers にロールとしてリストされているロールのみを削除で
きますが、組込みのロール (NONE や EXTEND など) は削除できません。
112
IBM Informix データベース設計および実装 ガイド
v ロールを削除するには、DBA としてのアクセス権を持っているか、あるいはロール
を削除するために付与できるロールのオプションを与えられていなければなりませ
ん。
実行時に現行のロールを判別する方法
適切なアクセス権を付与されたロールを使用しているときにアクセス権に関する予期し
ないエラーが発生した場合には、実行時にそのロールが有効化されたことを確認してく
ださい。データベースに接続している間にこの情報を取得するには、コマンド onstat -g
sql または onstat -g ses を使用、あるいは SQL の CURRENT_ROLE( ) 関数または
DEFAULT_ROLE( ) 関数を呼び出すことができます。
SPL ルーチンによるデータへのアクセスの制御
SPL ルーチンを使用して、データベース内の個々の表または列へのアクセスを制御でき
ます。ルーチンを使用して、さまざまな段階のアクセス制御を実行できます。SPL の強
力な機能の 1 つとして、SPL ルーチンを DBA アクセス権付きルーチンとして指定で
きる機能があります。DBA アクセス権付きルーチンを作成すると、ほとんどの、ある
いはまったく表アクセス権を持たないユーザが、ルーチンの実行時に DBA アクセス権
を獲得します。このルーチンでは、限られた範囲内で、ユーザは一時的な DBA アクセ
ス権を使用してタスクを実行できます。DBA アクセス権付きルーチンを使用すること
により、次のタスクを実行できます。
v 個々のユーザが表から読み込める情報の量を制限します。
v データベースに対するあらゆる変更を制限して、表全体が空にされたり、誤って変更
されるようなことがないようにします。
v 削除や挿入などの、表に対する変更のクラス全体を監視します。
v SPL ルーチン内で行われるあらゆるオブジェクトの作成 (データ定義) を制限して、
表、インデックス、およびビューの作成方法を完全に制御できるようにします。
SPL のルーチンについて詳しくは、「IBM Informix: SQL ガイド: チュートリアル」を
参照してください。
データの読込みの制限
次の例のルーチンでは、ユーザには SQL 構文が見えませんが、ユーザが customer 表
に対して Select アクセス権を持っている必要があります。何をユーザが選択できるかを
制限する場合は、次の環境で機能するようなルーチンを作成します。
v 自身が、データベースの DBA である。
v ユーザが、データベースに対する Connect アクセス権を持っている。そして、表に対
する SELECT アクセス権は持っていない。
v DBA キーワードを使用して、SPL ルーチン (または SPL ルーチンのセット) を作成
する。
第 6 章 データベース サーバのアクセス権の付与と制限
113
v 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 つずつの行の削除
に制限して、表内のすべての行が誤って削除されないようにするには、次のようなアク
セス権でデータベースをセットアップします。
v 自身が、データベースの DBA である。
v すべてのユーザが、データベースに対する Connect アクセス権を持っている。
Resource アクセス権は持っていないと考えられる。保護されている表に対しては、
Delete アクセス権 (この例の場合) を持っていない。
v DBA キーワードを使用して、SPL ルーチンを作成する。
v 自身の SPL ルーチンが削除を実行する。
次のような SPL プロシジャを作成します。このプロシジャでは、customer_num に対
して WHERE 節を使用して、customer 表から行を削除します。
CREATE DBA PROCEDURE delete_customer(cnum INT)
DELETE FROM customer
WHERE customer_num = cnum;
END PROCEDURE;
114
IBM Informix データベース設計および実装 ガイド
データへの変更の監視
SPL ルーチンを使用して、データベースに加えられた変更のレコードを作成できます。
特定のユーザが行った変更を記録したり、変更が行われるたびにレコードを作成したり
することができます。
単一のユーザがデータベースに対して行うすべての変更を監視できます。それぞれのユ
ーザによる変更を追跡する SPL ルーチンを使用して、すべての変更の経路を指定しま
す。ユーザ acctclrk がデータベースに変更を加えるたびに記録する場合は、次のアクセ
ス権でデータベースをセットアップします。
v 自身が、データベースの DBA である。
v 他のすべてのユーザが、データベースに対する Connect アクセス権を持っている。
Resource アクセス権は持っていないと考えられる。保護されている表に対しては、
Delete アクセス権 (この例の場合) を持っていない。
v DBA キーワードを使用して、SPL ルーチンを作成する。
v SPL ルーチンが削除を実行し、特定のユーザによる変更を記録する。
次の例のような SPL ルーチンを作成します (UNIX プラットフォームの場合)。このル
ーチンでは、ユーザ指定の顧客番号を使用して表を更新します。ユーザが acctclrk であ
る場合は、削除のレコードはファイル updates に入れられます。
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;
プロシジャを用いて行われた削除をすべて監視するには、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;
第 6 章 データベース サーバのアクセス権の付与と制限
115
オブジェクト作成の制限
作成されるオブジェクト、およびその作成方法を抑制するには、次の設定で SPL ルー
チンを使用します。
v 自身が、データベースの DBA である。
v 他のすべてのユーザが、データベースに対する Connect アクセス権を持ている。
Resource アクセス権は持っていない。
v DBA キーワードを使用して、SPL ルーチン (または SPL ルーチンのセット) を作成
する。
v 自身の 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;
プロシジャ all_objects を使用して表に対する列の追加を制御するには、データベースに
対する Resource アクセス権をすべてのユーザから取り消します。プロシジャの外で
SQL 文を使用して、ユーザが表、インデックスまたはビューを作成しようとしても、そ
の操作は許可されません。ユーザがプロシジャを実行するときは、一時的な DBA アク
セス権が与えられるため、例えば CREATE TABLE 文などは成功します。また、追加
するそれぞれの列には必ず制約が設定されます。さらに、ユーザが作成したオブジェク
トは、そのユーザによって所有されます。プロシジャ all_objects の場合は、このプロシ
ジャを実行するユーザは誰でも、2 つの表とインデックスを所有することになります。
ビューの使用
ビュー とは、合成した表のようなものです。ビューは、表ではないものを表であるかの
ように問合せることができ、場合によっては、表であるかのように更新することもでき
ます。しかし、ビューは表ではありません。実際の表と他のビューに存在するデータの
集合体です。
ビューの基本となるのは SELECT 文です。ビューを作成するときは、ビューのアクセ
ス時にビューの内容を生成する SELECT 文を定義します。ユーザは、SELECT 文を使
用したビューの問合せも行います。データベース サーバはユーザの SELECT 文をビュ
ーに対して定義した SELECT 文 とマージして、その結合された文を実際に実行するこ
116
IBM Informix データベース設計および実装 ガイド
ともあります。ビューのパフォーマンスについては、「IBM Informix: Dynamic Server
パフォーマンス ガイド」を参照してください。
ビューの内容を決定する SELECT 文の作成者は、ビューを次のいずれかの目的に使用
できます。
v ユーザを表の特定の列に制限する。
指定するのは、ビュー内の選択リスト内で許可されている列のみです。
v ユーザを表の特定の行に制限する。
許可された行のみを戻すように WHERE 節を指定する。
v 挿入する値または更新する値の範囲に制約を加える。
WITH CHECK OPTION (122 ページを参照) を使用して、制約を強制できます。
v 冗長データをデータベースに格納せずに、導出データにアクセスできるようにする。
ビュー内の選択リストにデータを導出する式を書きます。ビューに対して問合せを行
うたびに、そのデータが新たに導出されます。導出されたデータは常に最新ですが、
冗長性はデータ モデルに導入されません。
v 複雑な SELECT 文の詳細を隠す。
ビュー内の複数表結合による複雑性を隠し、ユーザとアプリケーション プログラマ
にとって繰返しが不要になるようにします。
ビューの作成
次の例では、データベース stores_demo の表をベースにしてビューを作成します。
CREATE VIEW name_only AS
SELECT customer_num, fname, lname FROM customer
このビューは表の 3 つの列のみを表出させます。しかし、WHERE 節が含まれていない
ため、表示できる行は制限しません。
次の例は 2 つの表の結合をベースにしています。
CREATE VIEW full_addr AS
SELECT address1, address2, city, state.sname,
zipcode, customer_num
FROM customer, state
WHERE customer.state = state.code
州名の表によって、データベースの冗長性が軽減されます。つまり、完全な州名を格納
するのは 1 回のみでよいため、Minnesota などの長い州名の場合は便利です。このビュ
ー full_addr を使用して、すべての行に完全な州名が格納されているかのように、住所
を抽出できます。次の 2 つの問合せは同等です。
第 6 章 データベース サーバのアクセス権の付与と制限
117
SELECT * FROM full_addr WHERE customer_num = 105
SELECT address1, address2, city, state.sname,
zipcode, customer_num
FROM customer, state
WHERE customer.state = state.code AND customer_num = 105
ただし、結合に基づくビューを定義するときは注意しなければなりません。そのような
ビューは修正不能 です。つまり、それらのビューには UPDATE 文、DELETE 文、ま
たは INSERT 文を使用できません。ビューを用いたデータの修正方法については、121
を参照してください。
次の例は、ビューに表示できる行を制限します。
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
118
IBM Informix データベース設計および実装 ガイド
型付きビューを作成すると、ビューが表示するデータは型付き行 (ROW) 型になりま
す。例えば、name_age ビューと name_salary ビューには、可変長文字 (VARCHAR)
型と整数 (INTEGER) 型のデータが含まれます。ビューは型付きであるため、name_age
ビューに問合せを行うと型 name_age の列ビューが戻され、name_salary ビューに問合
せを行うと、型 name_salary の列ビューが戻されます。したがって、データベース サ
ーバは name_age ビューが戻す行と name_salary ビューが戻す行を区別できます。
場合によっては、型付きビューのほうが型なしビューに比べて便利なことがあります。
例えば、関数 myfunc() を次のようにオーバーロードすると想定します。
CREATE FUNCTION myfunc(aa name_age_t) ......;
CREATE FUNCTION myfunc(aa name_salary_t) .....;
name_age ビューと name_salary ビューは型付きビューであるため、次の文は適切な
myfunc() 関数に解決されます。
SELECT myfunc(name_age) FROM name_age;
SELECT myfunc(name_salary) FROM name_salary;
また、上記の SELECT 文は表名の別名を使用して書くこともできます。
SELECT myfunc(p) FROM name_age p;
SELECT myfunc(p) FROM name_salary p;
同じデータ型を持つ 2 つのビューを型付きビューとして作成しないと、データベース
サーバは 2 つのビューが表示する行を区別できません。関数オーバロードについて詳し
くは、「IBM Informix: ユーザ定義ルーチンおよびデータ タイプ 開発者ガイド」を参照
してください。
ビューの重複行
基礎となる表に一意の行しか含まれていない場合も、ビューでは重複行が作成される可
能性があります。ビューの SELECT 文が重複行を戻すことができる場合は、ビュー自
体が重複行を含んでいるように見えることがあります。
この問題を防止する方法は 2 つあります。1 つの方法は、ビューの射影リストにキーワ
ード DISTINCT を指定することです。ただし、キーワード DISTINCT を指定すると、
ビューを用いたデータの変更が実行できなくなります。もう 1 つの方法は、一意に制約
されている 1 つの列、または列のグループを常に選択することです。主キーまたは候補
キーの列を選択した場合、確実に一意の行のみが戻されます。主キーと候補キーについ
ては、第 2 章 を参照してください。
ビューに関する制限
ビューは、実際には表ではないため、ビューにインデックスを付けたり、ビューを
ALTER TABLE 文や RENAME TABLE 文などのオブジェクトにしたりすることはでき
第 6 章 データベース サーバのアクセス権の付与と制限
119
ません。また、ビューの列の名前を RENAME COLUMN 文で変更することもできませ
ん。ビューの定義に関する何かを変更するには、ビューをいったん削除してから再度作
成しなければなりません。
ユーザの問合せとマージしなければならないため、ビューのベースになる 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
顧客の名字を直接選択するには、ここで新しい列名を選択しなければなりません。しか
し、ビューを介して見た場合には、列の名前は変わりません。次の 2 つの問合せは同等
です。
120
IBM Informix データベース設計および実装 ガイド
SELECT fname, surname FROM customer
SELECT fname, lname FROM name_only
列を削除して表を変更しても、ビューは変更されません。ビューが使用されていると、
エラー -217 (問合せのどの表にも、列 (%s) が見つかりません (または SLV が未定
義)。) が戻されます。ビューが変更されないのは、列を削除してから同じ名前の新しい
列を追加することによって、列の順序を変更できるためです。これを行うと、その表を
ベースにしているビューが、引き続き機能します。列の元の順序が維持されます。
データベース サーバでは、ビューのベースとして、外部データベース内の表とビューを
使用できます。他のデータベースの表とビューを変更しても、ビューには反映されませ
ん。そのような変更は、誰かがビューに対する問合せを行って、外部表が変更されてい
るというエラーを受け取るまで分からない場合があります。
ビューを用いたデータの変更
ビューは、表であるかのように変更できます。使用する SELECT 文によって、変更で
きるビューと変更できないビューがあります。制限は DELETE 文、UPDATE 文、また
は INSERT 文を使用するかによって異なります。
ビューにビューを定義した SELECT 文に次の項目が含まれていなかった場合、そのビ
ューは修正可能 です。
v 複数の表の結合
v 集計関数または GROUP BY 節
v DISTINCT キーワードまたはそのシノニム UNIQUE
v UNION キーワード
ビューにこれらの要素がまったくなければ、ビューの各行が 1 つの表の 1 行に確実に
対応します。
ビューを用いたデータの削除
修正可能なビューでは、表と同様に DELETE 文を使用できます。データベース サーバ
は、ベースにしている表の固有の行を削除します。
ビューの更新
修正可能なビューでは、表と同様に UPDATE 文を使用できます。ただし、データベー
ス サーバでは導出列の更新がサポートされていません。導出 列とは、CREATE VIEW
文の選択リスト内の式で作成された列のことです (例: order_date + 30)。
次の例は、導出列と、それに対して受け入れることができる UPDATE 文が含まれてい
る、修正可能なビューを示しています。
第 6 章 データベース サーバのアクセス権の付与と制限
121
CREATE
VIEW 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 response SET resolved = TODAY
WHERE resolved IS NULL;
このビューの列 duration は式を表しているため更新できません (データベース サーバ
は原則的に見ても、式で指定されている 2 つの列間で更新値の分散する方法を判定でき
ません)。ただし、導出列が SET 節で指定されていなければ、ビューが表であるかのよ
うに更新を実行できます。
ビューは、基礎となる表の行が一意であっても重複行を戻すことがあります。ある重複
行を別の重複行と区別することはできません。一連の重複行のいずれか 1 つを更新する
と (例えば、カーソルを使用して、WHERE CURRENT を更新する)、基礎表のどの行で
更新を受け取るのかが分からなくなることがあります。
ビューへの挿入
ビューが修正可能であり、かつ 導出列が含まれていない場合、ビューに行を挿入できま
す。二番目の制限が設けられているのは、挿入行はすべての列の値を提供する必要があ
るのに、挿入された値を式を用いて分散させる方法をデータベース サーバが認識できな
いためです。前の例に示すように、response ビューに挿入を試みると失敗します。
修正可能なビューに導出列が含まれていなければ、あたかも表であるかのように、その
ビューに挿入できます。ただし、データベース サーバは、ビューによって公開されない
列の値として NULL を使用します。そのような列に NULL 値を使用できない場合は、
エラーが発生して挿入に失敗します。
Dynamic Server のビュー (複合ビューも含む) で行を挿入する (あるいは UPDATE や
DELETE 操作を実行する) もう 1 つのメカニズムは、「IBM Informix SQL ガイド: 構
文」で説明されているように、INSTEAD OF トリガを作成することです。
WITH CHECK OPTION キーワードの使用
ビューの条件を満たさない行、つまりビューで見ることができない行をビューに挿入で
きます。また、ビューの行を更新して、その行がビューの条件を満たさないようにする
こともできます。
ビューの行が更新され、ビューの条件が満たされなくなることを回避するため、ビュー
の作成時に WITH CHECK OPTION キーワードを追加してください。この節を使用す
ると、挿入されたそれぞれの行や、更新されたそれぞれの行を検査して、ビューの
WHERE 節によって設定されている条件を満たしていることを確認するように、データ
ベース サーバに指示が出されます。条件が満たされていないと、データベース サーバ
はエラーメッセージを表示して、その操作を拒否します。
122
IBM Informix データベース設計および実装 ガイド
重要: ビュー定義に UNION 演算子が含まれている場合、WITH CHECK OPTION キー
ワードを指定することはできません。
前の例では、次の例に示すように response という名前のビューが定義されています。
CREATE VIEW 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 response SET user_id = ’lenora’
WHERE received BETWEEN TODAY AND TODAY - 7
このビューには、user_id が USER と等しくなる行が必要です。ユーザ tony がこの更
新を実行すると、更新された行はビューに表示されなくなります。しかし、次の例に示
すようにビューを作成できます。
CREATE VIEW
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 による前の UPDATE 操作は、エラーとしてリジェクトされます。
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 文で
第 6 章 データベース サーバのアクセス権の付与と制限
123
処理した後にそのビューの定義が変更されると、PREPARE 文で処理された文の実行結
果が不正になることがあります。新しいビュー定義が反映されないためです。SQL エラ
ーは生成されません。
アクセス権とビュー
ビューを作成 するときに、データベース サーバは、基礎となる表とビューに対するユ
ーザのアクセス権をテストします。ビューを使用 する場合は、そのビューに関するユー
ザのアクセス権のみがテストされます。
ビューの作成時のアクセス権
データベース サーバは、ビュー定義で SELECT 文を実行するために必要となるすべて
のアクセス権をユーザが持っているかどうかをテストします。必要なアクセス権がない
と、ビューは作成されません。
このテストによって、表に対するビューの作成と、ビューに対する問合せを実行して
も、ユーザは表に不正にアクセスできなくなります。
ユーザがビューを作成した後は、そのビューの作成者であり所有者でもあるユーザに
は、少なくともビューに対する Select アクセス権がデータベース サーバによって付与
されます。新しく作成する表の場合のように、自動的に PUBLIC にアクセス権が付与さ
れるわけではありません。
データベース サーバは、ビュー定義を検査して、そのビューが修正可能であるかどうか
を確認します。ビューが修正可能な場合は、データベース サーバによって、そのビュー
に対する Insert アクセス権、Delete アクセス権、および Update アクセス権が付与され
ますが、その場合は基礎となる表またはビューに対しても、それらのアクセス権がユー
ザに付与されていることが前提になります。つまり、新しいビューが修正可能である場
合には、データベース サーバは、Insert アクセス権、Delete アクセス権、Update アク
セス権を基礎となる表またはビューからコピーして、新しい表に対して付与します。基
礎表に対して Insert アクセス権しか持っていない場合は、ビューに対しても Insert アク
セス権のみが付与されます。
このテストによって、ユーザは、まだ付与されていないアクセス権に、ビューを使用し
てアクセスできなくなります。
ビューを変更したりインデックス付けすることはできないため、Alter アクセス権と
Index アクセス権がビューに対して与えられることはありません。
ビューを使用するときのアクセス権
ビューを使用しようとすると、データベース サーバは、そのビューに対して付与されて
いるアクセス権のみをテストします。基礎となっている表へのアクセス権はテストしま
せん。
124
IBM Informix データベース設計および実装 ガイド
ビューを作成した場合は、前のパラグラフで述べたアクセス権が与えられます。作成者
でない場合は、WITH GRANT OPTION アクセス権を持っていた作成者などが付与した
アクセス権が与えられることになります。
したがって、表を作成してからその表に対する PUBLIC によるアクセスを取り消すこと
ができます。その後で、ビューを使用してその表に対して限定されたアクセス権を付与
できます。次の表はその定義を示しています。
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
)
105 ページの『列レベル アクセス権』では、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 部門の社員に代わって、次の例が
示しているように、別のビューを作成します。
第 6 章 データベース サーバのアクセス権の付与と制限
125
CREATE VIEW hr_MIS AS
SELECT emp_key, emp_name, user_id
FROM hr_data
このビューは、部門番号と採用日を表出させないという点で、前のビューとは異なって
います。
なお、マネージャは、あらゆる列へのアクセス権だけではなく、自分の部下に限って勤
務評価データを更新できる必要があります。これらの要求を満たすには、それぞれの従
業員の部門番号とコンピュータ ユーザ 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
126
IBM Informix データベース設計および実装 ガイド
第 7 章 分散問合せの使用方法
分散問合せの概要 . . . . . . . . . . . . . . . . . .
単一の Dynamic Server インスタンスのデータベース間の分散問合せ
分散問合せの調整元と関係先 . . . . . . . . . . . . . .
分散問合せを使用するためのデータベース サーバの構成 . . . . .
分散問合せの構文 . . . . . . . . . . . . . . . . . .
リモート サーバおよびデータベースへのアクセス . . . . . . .
データベース名 . . . . . . . . . . . . . . . . .
データベース オブジェクト名 . . . . . . . . . . . .
コサーバ ID の指定 (XPS) . . . . . . . . . . . . .
リモート オブジェクトのアクセスに有効な文 . . . . . . . .
遠隔表へのアクセス . . . . . . . . . . . . . . . . .
表に対する権限 . . . . . . . . . . . . . . . . .
表参照の修飾 . . . . . . . . . . . . . . . . . .
その他のリモート操作 . . . . . . . . . . . . . . . .
リモート データベースのオープン . . . . . . . . . . .
リモート データベースの作成 . . . . . . . . . . . .
リモート シノニムの作成 . . . . . . . . . . . . . .
分散問合せの監視 . . . . . . . . . . . . . . . . . .
サーバ環境と分散問合せ . . . . . . . . . . . . . . . .
PDQPRIORITY 環境変数 . . . . . . . . . . . . . . .
DEADLOCK_TIMEOUT . . . . . . . . . . . . . . . .
データベース アクセスの制限 . . . . . . . . . . . . . .
トランザクション処理 . . . . . . . . . . . . . . . . .
排他レベル . . . . . . . . . . . . . . . . . . . .
DEADLOCK_TIMEOUT および SET LOCK MODE . . . . . .
2 相コミットと復旧 . . . . . . . . . . . . . . . . .
サーバ間の互換性に関する問題 (XPS) . . . . . . . . . . . .
バイト (BYTE) 型およびテキスト (TEXT) 型 . . . . . . . .
その他の制限 . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
128
128
128
129
129
130
130
130
130
130
131
132
132
132
132
132
132
133
133
133
133
134
134
134
134
135
135
135
135
本章について
この章では分散問合せの概要を説明します。分散問合せでは、IBM Informix データベー
ス サーバのネットワーク内にある複数のデータベースにわたるデータへの共用アクセス
が可能です。異なるデータベース サーバで管理される複数のデータベースを、単一の分
散問合せで参照できます。
© Copyright IBM Corp. 1996, 2004
127
分散問合せの概要
IBM Informix データベース サーバでは、同一データベース サーバまたは複数データベ
ース サーバにわたる 1 つ以上のデータベースに対する問合せを行うことができます。
このタイプの問合せのことを、分散問合せ と呼びます。各データベース サーバは、単
一のホスト コンピュータ上、同じネットワークの異なるコンピュータ上、またはゲート
ウェイ上に存在できます (一般に、この章で分散問合せに関して説明されている機能お
よび制限のほとんどは、複数のデータベースのオブジェクトあるいはデータを参照する
関数呼出しに適用し、そして INSERT、DELETE、または UPDATE での分散操作にも
適用します)。
注: IBM Informix Extended Parallel Server バージョン 8.40 は関係先機能のみをサポー
トしています。このバージョンから分散問合せを開始することはできません。IBM
Informix Extended Parallel Server バージョン 8.50 は、関係先機能と調整元機能を
両方サポートしています。制約事項はあります。
単一の Dynamic Server インスタンスのデータベース間の分散問合せ
同一の IBM Informix Dynamic Server インスタンスのデータベース間の分散操作では、
戻されるデータ型について以下のような制限があります。
v 問合せ、DML 操作、または関数呼出しは、BLOB、BOOLEAN、CLOB、および
LVARCHAR 組込み不透明型など、任意の組込みデータ型を戻すことができます。
v 問合せ、DML 操作、または関数呼出しは、ディスティンクト (DISTINCT) 型および
不透明 (OPAQUE) 型を戻すことはできません。ただし、それらの型が組込みデータ
型の明示的なキャストであり、ディスティンクト (DISTINCT) 型、不透明型、および
明示的キャストがすべて、データ型の格納または受信を行うそれぞれの関係先データ
ベースで定義されている場合は除きます。
分散問合せの調整元と関係先
複数のデータベース サーバにわたる分散操作をサポートするために、IBM Informix サ
ーバは 1 つの調整元と 1 つ以上の関係先から成る階層関係を管理しています。調整元
と関係先は以下のように定義されています。
v 調整元は、広域トランザクションの解決を指示します。さらに、問合せをコミットす
るかアボートするかも決定します。
v 関係先は、1 つのブランチでの分散問合せの実行を指示します。ブランチは分散問合
せの一部で、その関係先のデータベース サーバのみを含みます。
以下の例では、ローカル データベース db、同一のサーバ上にある外部データベース
db2、およびリモート サーバ new_york上の外部データベース db2 を使用する、マルチ
サーバ環境を参照しています。
以下は、データベース db を調整元として別のサーバ上のデータにアクセスする問合せ
の例です。
128
IBM Informix データベース設計および実装 ガイド
database db; select col1, col2 from db2:tab1, master_db@newyork:tab2;
セッションはただ 1 つのローカル データベースを持ちますが、複数の外部データベー
スをオープンできます。分散問合せは常に調整元から開始する必要があります。
分散問合せを使用するためのデータベース サーバの構成
分散問合せで複数の IBM Informix サーバを使用するにためには、そこに含まれるすべ
てのデータベース サーバがネットワーク上のサーバ間通信を使用できるように構成され
ていることを確認する必要があります。分散問合せを有効にするために以下の構成ファ
イルの編集が必要な場合があります。
v sqlhosts ファイル
v onconfig ファイル
v /etc/hosts.equiv または .rhosts
v /etc/services
v /etc/hosts
sqlhosts ファイルには、それぞれのデータベース サーバに対する接続情報が含まれま
す。複数のデータベース サーバをセット アップして分散問合せを使用する場合、次の
いずれかの方法で sqlhosts 情報を格納します。
v INFORMIXSQLHOSTS で指定される 1 つの sqlhosts ファイルに格納
v それぞれのデータベース サーバ ディレクトリの sqlhosts ファイルに個別に格納
注: IBM Informix Extended Parallel Server バージョン 8.40 は関係先機能のみをサポー
トしています。このバージョンから分散問合せを開始することはできません。IBM
Informix Extended Parallel Server バージョン 8.50 は、関係先機能と調整元機能を
両方サポートしています。制約事項はあります。
sqlhosts ファイルの構成について詳しくは、「管理者ガイド」を参照してください。
分散問合せの構文
このセクションでは、分散問合せ内で、リモート サーバ、リモート データベース、リ
モート データベース オブジェクトを指定する方法を説明します。
注: 分散問合せを設計するときには、すべてのサーバ バージョンでは作動しない SQL
構文があることに注意してください。Dynamic Server では有効でも Extended
Parallel Server では有効でない構文は Extended Parallel Server ではサポートされ
ず、その逆も同様です。
これらの潜在的な構文上の非互換性があるため、SQL 文が調整元での検査段階をパスし
ても、その文が関係先に渡されるとエラーを戻す可能性があります。
第 7 章 分散問合せの使用方法
129
リモート サーバおよびデータベースへのアクセス
分散問合せにおける文のコアとなる要素は、データベース セグメントです。これらのセ
グメントの構文を合わせて使用することにより、リモート データベース サーバ、デー
タベース、またはデータベース オブジェクトを指定できます。
データベース名
データベース名セグメントは、データベースの名前の指定に使用されます。以下の例
で、リモート データベースを指定するいくつかの異なる方法を示します。
empinfo@personnel ’//personnel/empinfo’
データベース オブジェクト名
データベース オブジェクト名セグメントは、制約、インデックス、トリガ、シノニムな
どのデータベース オブジェクトの名前の指定に使用されます。次の例は、リモート オ
ブジェクトへのアクセス方法を示しています。
empinfo@personnel:markg.emp_names empinfo@personnel:emp_names
コサーバ ID の指定 (XPS)
調整元と関係先が両方とも Extended Parallel Server である環境で分散問合せを実行して
いる場合は、データベースおよびデータベース オブジェクトのセグメントの一部として
コサーバを指定できます。次の例は、コサーバ ID の指定方法を示しています。
[email protected] [email protected]:emp_names
注: どのセッションにおいても、リモート サーバへの最初の参照によってそのサーバ上
のオブジェクトへの後続の参照の指定方法が決定されます。あるサーバ上のオブジ
ェクトを修飾するためにいったんコサーバ ID が使用されると、その同じサーバに
対する後続の参照でも (他のオブジェクトへの参照であっても) 同じコサーバ ID を
指定する必要があります。異なるリモート サーバに使用されるコサーバ ID は独立
したものです。
リモート オブジェクトのアクセスに有効な文
以下の文では、データベースおよびデータベース オブジェクト セグメントの一部とし
てリモート オブジェクトがサポートされており、分散問合せ内で使用できます。
v INSERT 文
v SELECT 文
v UPDATE 文
v DELETE 文
v CREATE VIEW 文
v CREATE SYNONYM 文
v CREATE DATABASE 文
v DATABASE 文
130
IBM Informix データベース設計および実装 ガイド
v LOAD 文
v UNLOAD 文
v LOCK 文
v UNLOCK 文
v INFO 文
Extended Parallel Server (XPS) 8.50 の場合は、データを変更または追加する文ではリモ
ート オブジェクトを参照できません。例えば、リモート オブジェクトに対して操作す
る INSERT 文、UPDATE 文、および DELETE 文はサポートされていません。Extended
Parallel Server でサポートされていない分散問合せについて詳しくは、ページ 7-7 の
『サーバ間の互換性に関する問題 (XPS)』を参照してください。
遠隔表へのアクセス
遠隔表は、現行のデータベース サーバ以外のデータベース サーバ上の表です。別のサ
ーバ上の表にアクセスするための一般的な構文は以下のとおりです。
database@server:[owner.]table
ここで、table には表名、ビュー名、またはシノニムを指定できます。オプションで表の
所有者を指定できます。完全な構文オプションについては、「IBM Informix SQL ガイド
: 構文」の『Database and Database Object segments』のドキュメントを参照してくださ
い。
以下は、遠隔表にアクセスする問合せの例です。
DATABASE locdb; SELECT l.name, r.assignment FROM rdb@rsys:rtab r,
loctab l WHERE l.empid = r.empid;
この問合せは、ローカル表 loctab の列 name と empid、および遠隔表 rtab の列
assignment と empid にアクセスします。データは empid を結合列として使用して結合
されます。
以下は、遠隔表のデータにアクセスし、その結果をローカル表に挿入する問合せの例で
す。
DATABASE locdb; INSERT INTO loctab SELECT * FROM rdb@rsys:rtab;
この問合せは遠隔表 rtab からすべてのデータを選択し、ローカル表 loctab に挿入しま
す。
次の例は、リモート データベース rdb の列 empid および priority を使用して、ローカ
ル データベースにビューを作成します。
DATABASE locdb; CREATE VIEW myview (empid, empprty)
AS SELECT empid, priority FROM rdb@rsys:rtab;
第 7 章 分散問合せの使用方法
131
表に対する権限
他のデータベースの表または遠隔表にアクセスする権限は、その表のある場所で制御さ
れます。リモート サーバにアクセスするときに、問合せを実行しているユーザのログイ
ン名とパスワードを使用して接続が確立されます。リモート データにアクセスするため
には、そのユーザが遠隔表に対して適切な権限を持っている必要があります。
分散問合せを処理するときに、データベース サーバは、リモート オブジェクトへのア
クセス時に現行のローカル データベースでアクティブであるロールを無視します。リモ
ート サーバ上では、各リモート データベースに適用されるデフォルト ロールが使用さ
れます。デフォルト ロールが定義されていない場合、ユーザのアクセス権により各リモ
ート データベースのオブジェクトに対するアクセス権限が定義されます。
表参照の修飾
表参照を現行のデータベースおよびサーバ名で修飾できます。修飾が指定されない場
合、データベースとサーバの現行のコンテキストが暗黙に指定されます。例えば、現行
データベースが locdb、現行サーバが currsys の場合、次の loctab に対する各参照は等
価です。
locdb@currsys:loctab
locdb:loctab
loctab
その他のリモート操作
データの問合せと更新以外にも、分散問合せのフレームワークを使用して実行できるリ
モート操作があります。
リモート データベースのオープン
DATABASE 文でリモート オブジェクトを指定することにより、次の例のようにリモー
ト データベースをオープンできます。
DATABASE dbname@servername;
DATABASE "//servernam/database";
リモート データベースの作成
CREATE DATABASE 文使用時にデータベース名をサーバ名で修飾することにより、リ
モート データベースを作成できます。
CREATE DATABASE remfoo@rsys;
リモート シノニムの作成
CREATE SYNONYM 文で修飾名を使用することで、別のデータベースの表あるいは遠
隔表のシノニムを作成できます。例えば、次の文により rdb@srsys:rtab: のシノニムが
作成されます。
CREATE SYNONYM myrtab FOR rdb@rsys:rtab;
132
IBM Informix データベース設計および実装 ガイド
あるシノニムがローカル サーバとリモート サーバの両方に存在する可能性がありま
す。上の例では、rtab がそれ自身 rdb2@rsys2:rtab2 に対するシノニムである可能性があ
ります。シノニムの連鎖は、カタログ情報抽出時に、その表が存在する物理データベー
スおよびサーバが見つかるまで追跡されます。シノニムが結局それ自身を指す場合には
エラーが戻されます。
分散問合せの監視
onstat -x ユーティリティを使用して、分散問合せの調整元で発生するトランザクション
情報を表示します。
5 番目の位置にある次のフラグ コードが分散問合せに使用されます。
C
分散問合せ調整元。
S
分散問合せ関係先
B
分散問合せ調整元および分散問合せ関係先の両方
R
リモート オブジェクト参照を使用したトランザクション (XPS)
onstat -x の使用方法について詳しくは、「管理者の参照」を参照してください。
サーバ環境と分散問合せ
このセクションでは、分散問合せの動作に影響する構成パラメータと環境変数をリスト
します。
PDQPRIORITY 環境変数
接続の確立時に、セッションに有効な PDQPRIORITY の値がリモート サイトに送信さ
れます。調整元でのこのパラメータへの以降の変更は、リモート サイトに反映されませ
ん。しかし、この環境変数の正確な動作は、分散問合せにおけるデータベース サーバの
役割 (調整元または関係先) に依存します。
PDQPRIORITY の構文およびセマンティクスは、各サーバ バージョン間で異なりま
す。PDQPRIORITY の設定については、「パフォーマンス ガイド」を参照してくださ
い。
DEADLOCK_TIMEOUT
この構成パラメータは、トランザクションがロックを待機する時間の長さを指定するた
めに使用されます。分散トランザクションが指定された秒数以上待機しなければならな
い場合、トランザクションを所有するスレッドはマルチサーバ デッドロックが存在する
ものと判断します。 次のようなエラー メッセージが戻ります。
-143 ISAM error: deadlock detected.
第 7 章 分散問合せの使用方法
133
この構成パラメータの使用方法について詳しくは、「管理者ガイド」を参照してくださ
い。
データベース アクセスの制限
Informix データベース サーバ環境で分散問合せを実行するためには、すべてのデータベ
ースが互換性のある ANSI モードとログ機能を持っている必要があります。
分散問合せは ANSI 標準準拠でないデータベースでも ANSI 標準準拠のデータベース
でも実行できますが、関係する各データベースが同じ ANSI モードを持っている必要が
あります。言い換えれば、分散問合せに関係するすべてのデータベースが ANSI 標準準
拠であるか、どれも ANSI 標準準拠でない必要があります。分散問合せは、一貫性があ
る限り、バッファ付きまたはバッファなしログ機能のいずれを持つデータベースに対し
ても実行できます。
Extended Parallel Server はログ機能なしのデータベースをサポートしていません。した
がって、Extended Parallel Server を調整元または関係先として使用する分散問合せに関
係するすべてのデータベースはログ機能付きである必要があります。
トランザクション処理
このセクションでは、トランザクション処理環境で分散問合せを使用するときの考慮事
項について説明します。
排他レベル
トランザクションの排他レベルは、遠隔サイトでのトランザクション開始時にリモート
サーバに送信されます。トランザクション中に排他レベルが変更された場合、新しい値
が遠隔サイトに送信されます。
DEADLOCK_TIMEOUT および SET LOCK MODE
分散問合せ使用時に、構成パラメータ DEADLOCK_TIMEOUT とともに SET LOCK
MODE 文を使用して、サーバのデッドロックを防ぐことができます。
SET LOCK MODE の WAIT オプションを要求すると、データベース サーバはデッド
ロックの可能性に対して保護されます。しかし、データベース サーバは、デッドロック
が発生することを認識すると操作を終了し、エラーを戻します。
DEADLOCK_TIMEOUT 構成パラメータは、データベース サーバ スレッドがロックを
獲得するまでに待機する最大の秒数を指定します。この値は SET LOCK MODE WAIT
文で使用されるデフォルト値です。この値は、同じトランザクション内の現行データベ
ース サーバとリモート データベース サーバに対してロックを獲得する場合にのみ適用
されます。
134
IBM Informix データベース設計および実装 ガイド
SET LOCK MODE 文について詳しくは、「IBM Informix SQL ガイド: 構文」を参照し
てください。DEADLOCK_TIMEOUT 構成パラメータについて詳しくは、 133 ページの
『DEADLOCK_TIMEOUT』および「IBM Informix Dynamic Server 管理者ガイド」の多
相コミット プロトコルに関する章を参照してください。
2 相コミットと復旧
複数のデータベース サーバにわたって分散問合せが一様にコミットまたはロールバック
されるように、2 相コミット プロトコルが使用されています。データベース サーバ
は、複数のデータベース サーバのデータを更新する任意のトランザクションに対して、
2 相コミット プロトコルを自動的に使用します。
Extended Parallel Server はリモート更新をサポートしないため、単一のトランザクショ
ン内での複数の更新は不可能です。したがって、Extended Parallel Server から開始され
る問合せには 2 相コミット プロトコルは適用されません。この場合、分散トランザク
ションはローカル トランザクションと同様に扱われ、障害が発生したポイントに応じて
ロールバックまたはコミットされます。2 相コミット プロトコルを使用する必要のある
文はアボートされ、エラー メッセージが戻されます。
詳しくは、「IBM Informix Dynamic Server 管理者ガイド」の多相コミット プロトコル
に関する章を参照してください。
サーバ間の互換性に関する問題 (XPS)
このセクションでは、Extended Parallel Server ではサポートされていない分散問合せの
要素をリストします。
バイト (BYTE) 型およびテキスト (TEXT) 型
遠隔表のデータへのアクセス時にはバイト (BYTE) 型およびテキスト (TEXT) 型はサポ
ートされません。Extended Parallel Server の組込みデータ型のみがサポートされます。
ユーザ定義データ型を基にした Dynamic Server の組込みデータ型はサポートされませ
ん。
その他の制限
Extended Parallel Server では、分散問合せ使用時に以下の制限があります。
v リモート ストアド プロシジャはサポートされていません。
v トリガは、トリガ定義内で遠隔オブジェクトを参照できません。
v IBM Informix ゲートウェイ製品はサポートされていません。
第 7 章 分散問合せの使用方法
135
136
IBM Informix データベース設計および実装 ガイド
第 3 部 オブジェクト リレーショナル データベース
© Copyright IBM Corp. 1996, 2004
137
138
IBM Informix データベース設計および実装 ガイド
第 8 章 Dynamic Server での拡張データ型の作成と使用
Informix のデータ型 . . . . . . . . . . . . . . . . . . . . .
基本データ型または最小のデータ型 . . . . . . . . . . . . . .
事前定義型 . . . . . . . . . . . . . . . . . . . . . . .
ブール (BOOLEAN) 型とラージ可変長文字 (LVARCHAR) 型 . . . . .
BLOB 型と CLOB 型 . . . . . . . . . . . . . . . . . .
その他の事前定義型 . . . . . . . . . . . . . . . . . . .
拡張データ型 . . . . . . . . . . . . . . . . . . . . . .
複合データ型 . . . . . . . . . . . . . . . . . . . . .
ユーザ定義データ型 . . . . . . . . . . . . . . . . . . .
ディスティンクト (DISTINCT) 型 . . . . . . . . . . . . . .
不透明 (OPAQUE) 型 . . . . . . . . . . . . . . . . . .
DataBlade データ型 . . . . . . . . . . . . . . . . . . .
スマート ラージ オブジェクト . . . . . . . . . . . . . . . . .
BLOB 型 . . . . . . . . . . . . . . . . . . . . . . .
CLOB 型 . . . . . . . . . . . . . . . . . . . . . . .
スマート ラージ オブジェクトの使用 . . . . . . . . . . . . . .
スマート ラージ オブジェクトのコピー . . . . . . . . . . . . .
複合データ型 . . . . . . . . . . . . . . . . . . . . . . .
コレクション (COLLECTION) 型 . . . . . . . . . . . . . . .
コレクションの NULL 値 . . . . . . . . . . . . . . . . .
セット (SET) 型のコレクション (COLLECTION) 型の使用 . . . . . .
マルチセット (MULTISET) 型のコレクション (COLLECTION) 型の使用 .
リスト (LIST) 型のコレクション (COLLECTION) 型の使用 . . . . .
コレクション (COLLECTION) 型の入れ子 . . . . . . . . . . .
既存の表へのコレクション (COLLECTION) 型の追加. . . . . . . .
コレクション (COLLECTION) 型に関する制限 . . . . . . . . . .
名前付き行型 . . . . . . . . . . . . . . . . . . . . . .
名前付き行型を使用する場合 . . . . . . . . . . . . . . . .
名前付き行型の名前の選択 . . . . . . . . . . . . . . . .
名前付き行型の制限 . . . . . . . . . . . . . . . . . . .
名前付き行型を使用した型付き表の作成 . . . . . . . . . . . .
表の型の変更 . . . . . . . . . . . . . . . . . . . . .
名前付き行型を使用した列の作成 . . . . . . . . . . . . . .
別の行 (ROW) 型の中での名前付き行型の使用 . . . . . . . . . .
名前付き行型の削除 . . . . . . . . . . . . . . . . . . .
© Copyright IBM Corp. 1996, 2004
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
140
141
141
142
142
142
142
143
143
143
144
144
145
145
145
146
147
147
148
149
150
151
151
152
152
153
153
154
154
155
156
157
158
159
159
139
名前なし行型 .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 160
本章について
この章では、拡張データ型について説明します。拡張データ型を使用すると、オブジェ
クト リレーショナル データベースを作成できます。オブジェクト リレーショナル と
いう用語は、特定のデータベース設計方法またはモデルに関連付けられたものではな
く、Dynamic Server 機能を使用してデータベース機能を拡張した任意のデータベースを
指します。
オブジェクト リレーショナル データベースは、リレーショナル データベースに対立す
るものではなく、リレーショナル データベースの既存機能を拡張したものです。通常、
データベースで格納と操作が可能なデータ型を増やすには、Dynamic Server の機能をい
くつか組み合わせて使用します。これらの機能には、拡張データ型、スマート ラージ
オブジェクト、型と表の継承、ユーザ定義のキャスト、およびユーザ定義ルーチン
(UDR) があります。この部の各章で、これらの機能について説明します。UDR につい
ては、「IBM Informix: ユーザ定義ルーチンおよびデータ タイプ 開発者ガイド」および
「IBM Informix: SQL ガイド: チュートリアル」を参照してください。
オブジェクト リレーショナル データベースの例として、superstores_demo データベー
スを作成できます。このデータベースには、Dynamic Server のいくつかの機能の例が含
まれます。superstores_demo データベースを作成する方法については、「IBM Informix:
DB-Access ユーザーズ ガイド」を参照してください。
Informix のデータ型
39 ページの『第 3 章 データ型の選択』の図 22には、表の列に格納されるデータの型
に応じて、適切なデータ型を選択するためのチャートが示されています。141 ページの
図 24 は、データベース サーバがデータ型を管理する方法を反映するデータ型の階層を
示しています。
140
IBM Informix データベース設計および実装 ガイド
図 24. Informix のデータ型
基本データ型または最小のデータ型
すべての Informix データベース サーバは、基本 データ型、または最小の データ型を
サポートしています。これらの型は SELECT 文で指定できる最小単位であるため、基
本的です。拡張データ型と事前定義型をサポートしているのは、Dynamic Server のみで
す。事前定義型は別のカテゴリにありますが、これは事前定義型には拡張データ型との
共通特性があるものの、事前定義型はデータベース サーバによって提供されるためで
す。
基本データ型については、 39 ページの『第 3 章 データ型の選択』を参照してくださ
い。
事前定義型
データベース サーバは、基本データ型を提供しているのと同様に、事前定義型を提供し
ています。ただし、事前定義型には、拡張データ型との共通特性があります。
第 8 章 Dynamic Server での拡張データ型の作成と使用
141
ブール (BOOLEAN) 型とラージ可変長文字 (LVARCHAR) 型
ブール (BOOLEAN) 型とラージ可変長文字 (LVARCHAR) 型は、組込みデータ型と同
様に動作しますが、これらの型はシステム カタログ表で拡張データ型として定義される
という点で組込みデータ型とは異なります。
詳しくは、39 ページの『第 3 章 データ型の選択』および「IBM Informix: SQL ガイド
: 参照」のシステム カタログ表の説明を参照してください。
BLOB 型と CLOB 型
BLOB 型と CLOB 型は基本データ型ではありません。これは、BLOB 型または CLOB
型からユーザがデータへランダムにアクセスできるためです。BLOB 型および CLOB
型の列を持つ表を作成できますが、作成した列に直接データを挿入することはできませ
ん。データを挿入、操作するには、関数を使用する必要があります。
詳しくは、145 ページの『スマート ラージ オブジェクト』を参照してください。
その他の事前定義型
BLOB 型、ブール (BOOLEAN) 型、CLOB 型、およびラージ可変長文字 (LVARCHAR)
型を除き、通常、事前定義型は表の列のデータ型とはなりません。代わりに、事前定義
型は、複合データ型、事前定義型、およびユーザ定義ルーチンと関連付けられた関数で
使用されます。次の表は残りの事前定義型のリストです。
clientbinval
ifx_lo_spec
ifx_lo_stat
impexp
impexpbin
indexkeyarray
lolist
pointer
rtnparamtypes
selfuncargs
sendrecv
stat
stream
これらの事前定義型について詳しくは、「IBM Informix: ユーザ定義ルーチンおよびデー
タ タイプ 開発者ガイド」を参照してください。
拡張データ型
拡張データ型により、組込みデータ型では容易に表すことができないデータを表現する
データ型を作成できます。ただし、分散トランザクションでは拡張データ型を使用でき
ません。図 25 は拡張データ型を示しています。
142
IBM Informix データベース設計および実装 ガイド
図 25. 拡張データ型
複合データ型
複合データ型は、すべてのデータが 1 つの型 (LIST、SET、および MULTISET) である
データ オブジェクトのコレクション、または異なる型のオブジェクトのグループ (名前
付き行と名前なし行) です。
ユーザ定義データ型
ユーザ定義データ型は、データベース サーバから提供されないデータ型です。ユーザ
は、データベース サーバが不透明 (OPAQUE) 型、またはディスティンクト
(DISTINCT) 型を管理するために必要なすべての情報を指定する必要があります。
ディスティンクト (DISTINCT) 型
ディスティンクト (DISTINCT) 型は、カプセル化されたデータ型で、CREATE
DISTINCT TYPE 文で作成します。ディスティンクト (DISTINCT) 型は、基になったデ
ータ型と表現は同じですが、性質は異なります。ディスティンクト (DISTINCT) 型は、
第 8 章 Dynamic Server での拡張データ型の作成と使用
143
組込みデータ型、不透明 (OPAQUE) 型、名前付き行型、または他のディスティンクト
(DISTINCT) 型から作成できます。ディスティンクト (DISTINCT) 型は、次のデータ型
からは作成できません。
v シリアル (SERIAL) 型
v 8 バイト シリアル (SERIAL8) 型
v コレクション (COLLECTION) 型
v 名前なし行型
ディスティンクト (DISTINCT) 型はソース データ型の構造体を継承するため、ディス
ティンクト (DISTINCT) 型を作成するときにはデータ型の構造体が暗黙的に定義されま
す。ディスティンクト (DISTINCT) 型を操作する関数、演算子、および集合を定義する
こともできます。
ディスティンクト (DISTINCT) 型については、188 ページの『ディスティンクト
(DISTINCT) 型のキャスト』、「IBM Informix: SQL ガイド: 構文」、および
「IBM Informix: SQL ガイド: 参照」を参照してください。
不透明 (OPAQUE) 型
不透明 (OPAQUE) 型は、カプセル化されたデータ型で、CREATE OPAQUE TYPE 文
で作成します。不透明 (OPAQUE) 型を作成するときは、データ型の構造体、その不透
明 (OPAQUE) 型を操作する関数、演算子、および集合も明示的に定義する必要があり
ます。不透明型 (OPAQUE) 型は、列およびプログラム変数を定義するときに使用でき
ます。方法は、組込みデータ型を使用する場合と同様です。
不透明 (OPAQUE) 型の作成については、「IBM Informix: ユーザ定義ルーチンおよびデ
ータ タイプ 開発者ガイド」および「IBM Informix: SQL ガイド: 構文」を参照してく
ださい。
DataBlade データ型
143 ページの図 25 のダイアグラムには、実際にはデータ型ではありませんが、
DataBlade データ型が記述されています。DataBlade とは、ユーザ定義データ型とユーザ
定義ルーチンのセットで、特殊アプリケーション用のツールを提供しています。例え
ば、イメージ管理、時系列、および天体観測のためのツールは、それぞれ異なる
DataBlade が提供しています。このようなアプリケーションでは、不透明 (OPAQUE) 型
と同時に他のユーザ定義データ型が必要になることが多くあります。DataBlade の開発
については、「IBM Informix: DataBlade API Programmer’s Guide」および DataBlade
Developers Kit を参照してください。IBM が提供している DataBlades に関する情報に
ついては、顧客担当者にお問合せください。
144
IBM Informix データベース設計および実装 ガイド
スマート ラージ オブジェクト
スマート ラージ オブジェクト とは、BLOB 型または CLOB 型に定義されるオブジェ
クトです。スマート ラージ オブジェクトにより、アプリケーション プログラムはラン
ダムに列データにアクセスできます。つまり、BLOB 列、または CLOB 列の任意の部
分に対し、任意の順序で読み取りまたは書込みができます。BLOB 列または CLOB 列
を作成することにより、バイナリ形式のデータまたは文字データを格納できます。
BLOB 型
BLOB 型を使用すると、プログラムが生成するあらゆるデータを格納できます。対象と
なるデータには、グラフィック イメージ、サテライト イメージ、ビデオ クリップ、オ
ーディオ クリップ、またはワード プロセッサやスプレッドシートで保存した定様式文
書があります。データベース サーバは、BLOB 列にあらゆる長さ、かつあらゆるタイ
プのデータを受け入れることができます。
CLOB オブジェクトと同様、BLOB オブジェクトは標準の行データとは別のディスク領
域のディスク ページ全体に格納されます。
BLOB 型には、CLOB 型とは異なり、あらゆるデータを受け入れることができるという
利点があります。この点を除けば、BLOB 型の利点と欠点は、CLOB 型と同じです。
CLOB 型
CLOB 型は、テキストのブロックを格納するときに使用できます。この型は、HTML ま
たは PostScript のような定様式テキストを含む、ASCII テキスト データを格納するよ
うに設計されています。CLOB オブジェクトには任意のデータを格納できますが、
IBM Informix ツールは CLOB オブジェクトが印刷可能であることを前提としているた
め、このデータ型は印刷可能な ASCII テキストのみに使用してください。
CLOB の値は、その行の他の列の値と一緒には格納されません。CLOB の値に対して
は、ディスク ページ全体が割り当てられます。そのページは通常、行の他の値が格納さ
れる領域とは別のところに確保されます。(詳しくは、「IBM Informix: Dynamic Server
管理者ガイド」を参照してください)。
CLOB 型はテキスト (TEXT) 型に類似していますが、CLOB 型には次の利点がありま
す。
v アプリケーション プログラムは、CLOB オブジェクトの任意の部分に対し、読出し
または書込みができます。
v アプリケーション プログラムが CLOB オブジェクトの任意の部分にアクセスできる
ことにより、アクセス時間が大幅に高速化されます。
第 8 章 Dynamic Server での拡張データ型の作成と使用
145
v デフォルト特性のオーバーライドが、比較的簡単に実行できます。データベース管理
者は、SB 領域のデフォルト特性を列レベルで上書きできます。アプリケーション プ
ログラマは、CLOB オブジェクトを作成するときには、列のデフォルト特性の一部を
オーバーライドできます。
v 等演算子 (=) を使用して、2 つの CLOB の値が等しいかどうかをテストできます。
v CLOB オブジェクトは、システム障害が発生した場合にリカバリすることが可能であ
り、また DBA またはアプリケーション プログラマがトランザクション排他設定モ
ードを指定した場合はそれに従います。ただし、CLOB オブジェクトを復旧するに
は、データベース システムに、CLOB オブジェクトの処理に十分な大きさのバッフ
ァを提供できるリソースが必要です。
v CLOB 型を使用すると、ユーザ定義のデータ型を格納する大きい領域を提供できま
す。
v DataBlade の開発者は、CLOB 型のインデックスを作成できます。
CLOB 型の欠点は次のとおりです。
v ディスク ページ全体が割り当てられるため、短いデータの場合はディスク容量が無
駄になります。
v SQL 文での CLOB 列の使用には制約があります (146 ページの『スマート ラージ
オブジェクトの使用』を参照してください)。
v すべての Informix データベース サーバで使用できるわけではありません。
スマート ラージ オブジェクトの使用
BLOB 型または CLOB 型の列を格納するには、SB 領域を割り当てる必要がありま
す。SB 領域 は、BLOB データまたは CLOB データを最も効率的に格納する論理記憶
単位です。ユーザが BLOB データまたは CLOB データの取り出しおよび格納ができる
ようになる IBM Informix ESQL/C プログラムを作成できます。スマート ラージ オブ
ジェクトに直接アクセスして操作するアプリケーション プログラマは、「IBM Informix:
ESQL/C Programmer’s Manual」を参照してください。
対話型またはプログラム式の SQL 文において、BLOB または CLOB 列を次のように
使用することはできません。
v 算術式やブール式
v GROUP BY 節または ORDER BY 節の中
v UNIQUE テスト
v インデックス作成において、Informix B ツリーの一部として
ただし、DataBlade の開発者は、CLOB 列のインデックスを作成できます。
対話式で入力された SELECT 文で、BLOB 列または CLOB 列は次のようになります。
146
IBM Informix データベース設計および実装 ガイド
v DEFAULT NULL 節を付けて表を作成すると、デフォルト値として NULL 値を指定
できます。
v 表の作成時に NOT NULL 制約を使用すると、NULL 値を不許可にできます。
v IS [NOT] NULL 述部を使用することにより、テストできます。
ESQL/C プログラムから ifx_lo_stat() 関数を使用すると、BLOB データまたは CLOB
データの長さを判断できます。
スマート ラージ オブジェクトのコピー
Dynamic Server には SQL 文から呼び出してスマート ラージ オブジェクトをインポー
トおよびエクスポートできる関数が提供されています。表 6 にスマート ラージ オブジ
ェクト関数を示します。
表 6. スマート ラージ オブジェクトを扱う SQL 関数
関数名
内容
FILETOBLOB()
FILETOCLOB()
LOCOPY()
ファイルを BLOB 列にコピーします。
ファイルを CLOB 列にコピーします。
BLOB データまたは CLOB データを別の BLOB または
CLOB 列にコピーします
BLOB データまたは CLOB データをファイルにコピーしま
す
LOTOFILE()
スマート ラージ オブジェクト関数の詳細および構文については、「IBM Informix: SQL
ガイド: 構文」の式セグメントの説明を参照してください。
重要: BLOB 型と CLOB 型との間でのキャストは許可されていません。
複合データ型
複合データ型は、通常、他の既存のデータ型の複合です。例えば、組み込み型、不透明
(OPAQUE) 型、ディスティンクト (DISTINCT) 型、または他の複合データ型をコンポー
ネントに含む複合データ型を作成できます。ユーザ定義データ型に比べ、複合データ型
には、ユーザが複合データ型の各コンポーネントにアクセスし、操作できるという重要
な利点があります。
これに対し、組込みデータ型とユーザ定義データ型は、独立した (カプセル化された)
型です。そのため、不透明 (OPAQUE) 型のコンポーネントの値にアクセスするには、
不透明 (OPAQUE) 型に定義した関数を使うのが唯一の方法です。
図 26 に、Dynamic Server がサポートする複合データ型、および複合データ型の作成に
使用する構文を示します。
第 8 章 Dynamic Server での拡張データ型の作成と使用
147
図 26. 複合データ型
図 26 で示す複合データ型により、次の拡張データ型がサポートされます。
v コレクション (COLLECTION) 型。コレクション (COLLECTION) 型は、データのコ
レクションを表セルに格納したり、操作する必要がある場合に使用できます。コレク
ション (COLLECTION) 型は、列に割り当てることができます。
v 行 (ROW) 型。行 (ROW) 型は、一般的に複数のフィールドを含みます。列または変
数に複数のタイプのデータを格納するときに、行 (ROW) 型を作成できます。行
(ROW) 型には、名前付き行型と名前なし行型の 2 つのタイプがあります。名前なし
行型は、列および変数に割り当てることができます。名前付き行型は、列、変数、
表、またはビューに割り当てることができます。名前付き行型を表に割り当てると、
表は型付き表 になります。型付き表の主な利点は、継承階層構造を定義するのに使
用できるということです。
この章で説明する複合データ型で SELECT、INSERT、UPDATE、および DELETE の操
作を実行する方法について詳しくは、「IBM Informix: SQL ガイド: チュートリアル」
を参照してください。
コレクション (COLLECTION) 型
コレクション (COLLECTION) 型により、データのコレクションを表の 1 つの行に格納
して操作できます。コレクション (COLLECTION) 型には 2 つのコンポーネントがあり
ます。1 つはそのコレクション (COLLECTION) 型がセット (SET) 型、マルチセット
(MULTISET) 型、またはリスト (LIST) 型のいずれであるかを決定する型コンストラク
タ で、もう 1 つはそのコレクションに含めることができるデータ型を指定する要素型
です。(セット (SET) 型、マルチセット (MULTISET) 型、リスト (LIST) 型の各コレク
ション (COLLECTION) 型については、次のセクションで詳しく説明します)。
コレクションの要素は、ほとんどすべてのデータ型をとることができます。(例外の一覧
については、153 ページの『コレクション (COLLECTION) 型に関する制限』を参照)。
コレクションの要素 とは、コレクションが含む値です。次の値を含むコレクションを考
えます。{'blue'、'green'、'yellow'、および 'red'}。'blue' はコレクション中の単
一の要素を表します。コレクションの各要素は、同じ型にする必要があります。例え
ば、要素型が整数 (INTEGER) 型のコレクションに含めることができるのは、整数の値
のみです。
148
IBM Informix データベース設計および実装 ガイド
コレクションの要素型は、1 つのデータ型 (列) を表すことも、複数のデータ型 (行) を
表すこともできます。次の例で、列 col_1 は整数の SET を表します。
col_1 SET(INTEGER NOT NULL)
複数のデータ型を含むコレクション (COLLECTION) 型を定義するには、名前付き行
型、または名前なし行型を使用します。次の例で、列 col_2 はフィールド name および
フィールド salary を含む行のセット (SET) 型を表します。
col_2 SET(ROW(name VARCHAR(20), salary INTEGER) NOT NULL)
重要: コレクション (COLLECTION) 型を定義する場合は、型定義の一部として NOT
NULL 制約を含める必要があります。コレクション (COLLECTION) 型には、他
の列制約は許可されません。
列をコレクション (COLLECTION) 型として定義すると、コレクションに対して次の操
作を実行できるようになります。
v コレクションの個別要素を選択および変更できます。これは、ESQL/C プログラムで
のみ実行できます。
v コレクションに含まれる要素の数をカウントできます。
v ある値がコレクションに含まれているかどうかを判断できます。
コレクション (COLLECTION) 型の作成に使用する構文については、「IBM Informix:
SQL ガイド: 構文」のデータ型セグメントの説明を参照してください。コレクション
(COLLECTION) 型の値を別のコレクション (COLLECTION) 型に変換する方法について
は、「IBM Informix: SQL ガイド: チュートリアル」を参照してください。
コレクションの NULL 値
コレクション (COLLECTION) 型に、NULL 要素を含めることはできません。しかし、
コレクションが行 (ROW) 型の場合は、コレクションに含まれる行 (ROW) 型の任意の
フィールドに、NULL 値を挿入できます。コレクション列がある表を、次のように作成
するとします。
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;
第 8 章 Dynamic Server での拡張データ型の作成と使用
149
しかし、次の各文ではコレクション要素が NULL 値を指定しているため、エラー メッ
セージを戻します。
INSERT INTO tab1 VALUES ( 45, "SET{NULL)}");
UPDATE tab1 SET col2 = "SET{NULL}" WHERE col1 = 55;
セット (SET) 型のコレクション (COLLECTION) 型の使用
セット (SET) 型は、要素を順序付けしないコレクションで、各要素は一意です。次のよ
うな特性を持つ要素のコレクションを格納する場合は、列をセット (SET) 型のコレクシ
ョン (COLLECTION) 型として定義します。
v 要素には、重複した値が含まれていない。
v 要素に、関連付けられた特別な順序はない。
セット (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) 型で
す。各従業員の扶養家族のコレクションには、重複した値は含まれないためです。列を
セット (SET) 型として定義すると、コレクションの各要素が一意であることが保証され
ます。
要素が行 (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 のコレクションの各要素には、name の値、および bdate の値が含まれ
ます。employee 表の各行には、従業員の情報とともに、従業員の扶養家族の名前および
150
IBM Informix データベース設計および実装 ガイド
生年月日のコレクションが含まれます。例えば、扶養家族がいない従業員の場合、列
dependents のコレクションは空です。10 人の扶養家族がいる従業員の場合、コレクシ
ョンには 10 個の要素が含まれます。
マルチセット (MULTISET) 型のコレクション (COLLECTION) 型の使用
マルチセット (MULTISET) 型は、重複した値を取ることができる、要素のコレクショ
ンです。例えば、整数のマルチセット (MULTISET) 型には、重複した要素のあるコレ
クション {1,3,4,3,3} を含めることができます。次のような特性を持つ要素のコレクショ
ンを格納する場合は、列をマルチセット (MULTISET) 型のコレクション
(COLLECTION) 型として定義できます。
v 要素が、一意でない可能性がある。
v 要素に、関連付けられた特別な順序はない。
マルチセット (MULTISET) 型の使い方を説明します。人事部が従業員の賞与を追跡す
る必要があるとします。各従業員の賞与を長期にわたって追跡するために、従業員が受
け取ったすべての賞与を記録する表の列を、マルチセット (MULTISET) 型を使用して
定義します。次の例で、列 bonus はマルチセット (MULTISET) 型です。
CREATE TABLE
(
name
address
salary
bonus
);
employee
CHAR(30),
CHAR (40),
INTEGER,
MULTISET(MONEY NOT NULL)
この文の列 bonus を使用して、各従業員の賞与のコレクションを格納し、アクセスで
きます。指定された行の列 bonus に対する問合せは、従業員が受け取った各賞与の金
額を戻します。従業員は、同じ額の賞与を複数回受け取ることがあります。その場合、
コレクションの要素は、すべて一意ではなくなります。そのため列 bonus は、重複し
た値を許可するマルチセット (MULTISET) 型として定義します。
リスト (LIST) 型のコレクション (COLLECTION) 型の使用
リスト (LIST) 型は、要素の順序付きコレクションで、重複した値を含むことができま
す。リスト (LIST) 型とマルチセット (MULTISET) 型の違いは、リスト (LIST) 型の各
要素にはコレクション (COLLECTION) 型における順序を表す位置が与えられる点にあ
ります。リスト内での要素の順序は、リスト (LIST) 型に値を挿入する順序に対応しま
す。次のような特性を持つ要素のコレクションを格納する場合には、列をリスト
(LIST) 型のコレクション (COLLECTION) 型として定義できます。
v 要素に、関連付けられた特別な順序がある。
v 要素が、一意でない可能性がある。
リスト (LIST) 型の使い方を説明します。営業部が営業部員ごとの月別総売り上げ高を
記録する必要があるとします。営業部員ごとの月別総売り上げ高を含む表の列は、リス
第 8 章 Dynamic Server での拡張データ型の作成と使用
151
ト (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 列に対して問合せを実行し、次の値を取得できま
す。
v ある営業部員が特定の月に達成した総売り上げ高
v 特定の月の営業部員別総売り上げ高
コレクション (COLLECTION) 型の入れ子
入れ子コレクション (COLLECTION) 型 は、別のコレクション (COLLECTION) 型を含
むコレクション (COLLECTION) 型です。どのコレクション (COLLECTION) 型も、別
のコレクション (COLLECTION) 型の中に入れ子にすることができます。コレクション
(COLLECTION) 型の入れ子の深さに、制限はありません。しかし、1 レベルか 2 レベ
ルを超える入れ子にしたコレクションの挿入または更新を実行するのは困難です。次の
例で、入れ子コレクション (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) 型にアクセスする方法については、
「IBM Informix: SQL ガイド: チュートリアル」を参照してください。
既存の表へのコレクション (COLLECTION) 型の追加
ALTER TABLE 文を使用して、コレクション (COLLECTION) 型の列を追加または削除
できます。ALTER TABLE 文を使うと、任意のデータ型の列を追加または削除できま
す。例えば、次の文は、セット (SET) 型として定義された列 flowers を nursery 表に
追加します。
ALTER TABLE nursery ADD flower SET(VARCHAR(30) NOT NULL)
既存のコレクション (COLLECTION) 型列は変更できません。また、非コレクション
(COLLECTION) 型列をコレクション (COLLECTION) 型に変換することはできません。
152
IBM Informix データベース設計および実装 ガイド
コレクション (COLLECTION) 型の列の追加と削除について詳しくは、「IBM Informix:
SQL ガイド: 構文」の ALTER TABLE 文の説明を参照してください。
コレクション (COLLECTION) 型に関する制限
次のデータ型は、コレクションの要素型としては使用できません。
v テキスト (TEXT) 型
v バイト (BYTE) 型
v シリアル (SERIAL) 型
v 8 バイト シリアル (SERIAL8) 型
CREATE INDEX 文では、コレクション (COLLECTION) 型のインデックスを作成する
ことも、コレクション (COLLECTION) 型の列の関数インデックスを作成することもで
きません。
名前付き行型
名前付き行型 は、単一名で定義されたフィールドのグループです。フィールド は、行
(ROW) 型のコンポーネントを指します。列と混同しないように注意してください。列
は、表にのみ関連付けられます。名前付き行型のフィールドは、C 言語の構造体のフィ
ールド、またはオブジェクト指向プログラミングのクラスのメンバに類似しています。
名前付き行型を作成した後、行 (ROW) 型に割り当てた名前によって、データベースの
中で一意の型が表されます。名前付き行型を作成するには、行 (ROW) 型の名前と、そ
の行 (ROW) 型を構成するフィールドの名前とデータ型を指定します。次の例で、
person_t という名前付き行型を作成する方法を示します。
CREATE ROW
(
name
address
city
state
zip
bdate
);
TYPE person_t
VARCHAR(30) NOT NULL,
VARCHAR(20),
VARCHAR(20),
CHAR(2),
VARCHAR(9),
DATE
person_t 行 (ROW) 型には、6 つのフィールド、すなわち name、address、city、
state、zip、および bdate が含まれます。名前付き行型を作成すると、他のデータ型を
使用するのと同じように、この型を使用できます。person_t は、他のデータ型が使用で
きるすべての場所で使用できます。次の CREATE TABLE 文では、person_t データ型
を使用しています。
CREATE TABLE sport_club
(
sport
CHAR(20),
sportnum INT,
第 8 章 Dynamic Server での拡張データ型の作成と使用
153
member
since
paidup
person_t,
DATE,
BOOLEAN
)
行 (ROW) 型のフィールドを定義するときには、ほとんどのデータ型を使用できます。
行 (ROW) 型がサポートしないデータ型については、155 ページの『名前付き行型の制
限』を参照してください。
名前付き行型の作成に使用する構文については、「IBM Informix: SQL ガイド: 構文」
の CREATE ROW TYPE 文の説明を参照してください。行 (ROW) 型の値をキャスト
する方法については、 179 ページの『第 10 章 Dynamic Server でのユーザ定義キャス
トの作成と使用』を参照してください。
名前付き行型を使用する場合
名前付き行型は、Dynamic Server で新しいデータ型を作成する方法の 1 つです。名前
付き行型を作成するときは、データベース サーバが理解できるデータ型で、フィールド
のテンプレートを定義します。このように、行 (ROW) 型のフィールド定義は、表の列
定義と類似しています。どちらの場合も、データベース サーバが認識できるデータ型で
構築します。
ユーザがアクセスする必要のあるコンポーネント値のコンテナとして機能する型が必要
な場合は、名前付き行型を作成できます。例えば、ユーザが直接、住所の値の個々のコ
ンポーネント値、つまり番地、市町村、州、および郵便番号にアクセスする必要がある
場合は、住所の値をサポートする名前付き行型を作成できます。住所の型を名前付き行
型として作成すると、ユーザはいつでも、それぞれのフィールドに直接アクセスできま
す。
それに対し、住所の値を扱う不透明 (OPAQUE) 型を作成すると、住所情報はすべて C
言語のデータ構造体に格納されます。不透明 (OPAQUE) 型のコンポーネント値はカプ
セル化されるため、コンポーネント値を町名、市、州、郵便番号に展開する関数を定義
する必要があります。このように、不透明 (OPAQUE) 型は名前付き行型よりも定義お
よび使用方法が複雑な型です。
データ型を定義する前に、その型が単に、ユーザが直接アクセスできる値のグループの
コンテナであるかどうかを判断します。この説明に当てはまる場合、名前付き行型を使
用します。
名前付き行型の名前の選択
SQL 識別子の命名規則に違反しない限り、名前付き行型には任意の名前を付けられま
す。SQL 識別子の命名規則については、「IBM Informix: SQL ガイド: 構文」の識別子
セグメントの説明を参照してください。型名と表名を混同しないように、このマニュア
ルの例では、行 (ROW) 型の名前の末尾に文字列 _t を付けることにより、名前付き行
型であることを示します。
154
IBM Informix データベース設計および実装 ガイド
名前付き行型を作成するには、Resource アクセス権が必要です。データ型はすべて、同
じネーム スペースを共有します。名前付き行型に割り当てる名前は、データベースに存
在する他のデータ型と違うものにしてください。ANSI 準拠データベースでは、
owner.type の組合せをデータベース内で一意にする必要があります。ANSI 標準準拠で
ないデータベースでは、名前をデータベースで一意にする必要があります。
重要: 名前付き行型に USAGE アクセス権を付与しないと、ユーザはこの型を使用でき
ません。名前付き行型のアクセス権の付与と取消しについては、 221 ページの
『第 12 章 次元データベースの実装 (XPS)』 を参照してください。
名前付き行型の制限
本セクションでは、名前付き行型を使用するときに適用される制限について説明しま
す。
データ型に関する制限: ラージ オブジェクトの列を含む型付き表を作成する場合
は、テキスト (TEXT) 型またはバイト (BYTE) 型ではなく、BLOB 型または CLOB 型
を使用することをお勧めします。下位方向の互換性のために、テキスト (TEXT) 型また
はバイト (BYTE) 型のフィールドを含む名前付き行型を作成したり、これらの型を使っ
て既存の型なし表を型付き表に再生したりできます。しかし、テキスト (TEXT) 型やバ
イト (BYTE) 型のフィールドを含む名前付き行型を使用して型付き表を作成することは
できますが、このような行 (ROW) 型を列として使用することはできません。BLOB 型
または CLOB 型のフィールドを含む名前付き行型は、型付き表または列に割り当てる
ことができます。
制約に関する制限: CREATE ROW TYPE 文で、名前付き行型のフィールドに対して
指定できるのは、NOT NULL 制約のみです。他の制約は、CREATE TABLE 文で定義
する必要があります。詳しくは、「IBM Informix: SQL ガイド: 構文」の CREATE
TABLE 文の説明を参照してください。
インデックスに関する制限: CREATE INDEX 文を使用して名前付き行型列のイン
デックスを作成することはできません。しかし、ユーザ定義ルーチンを使用して、行
(ROW) 型列の関数インデックスを作成することはできます。
シリアル (SERIAL) 型に関する制限: 表の列型として、シリアル (SERIAL) 型ま
たは 8 バイト シリアル (SERIAL8) 型を含む名前付き行型は使用できません。次の文
は、データベース サーバが表を作成しようとしたときに、エラーを戻します。
CREATE ROW TYPE row_t (s_col SERIAL)
CREATE TABLE bad_tab (col1 row_t)
しかし、シリアル (SERIAL) 型または 8 バイト シリアル (SERIAL8) 型を含む名前付
き行型を使用して、型付き表を作成することはできます。
第 8 章 Dynamic Server での拡張データ型の作成と使用
155
表階層構造におけるシリアル (SERIAL) 型および SERIAL8 型の使用と動作について
は、174 ページの『表階層内のシリアル (SERIAL) 型』を参照してください。
名前付き行型を使用した型付き表の作成
表は、型付き表または型なし表として作成できます。型付き表 は、名前付き行型が割り
当てられた表です。型なし表 は、名前付き行型が割り当てられていない表です。
CREATE ROW TYPE 文は、名前付き行型を作成しますが、行 (ROW) 型のインスタン
スの記憶域は割り当てません。名前付き行型のインスタンスの記憶域を割り当てるに
は、行 (ROW) 型を表に割り当てる必要があります。次の例で、型付き表を作成する方
法を示します。
CREATE ROW
(
name
address
city
state
zip
bdate
);
TYPE person_t
VARCHAR(30),
VARCHAR(20),
VARCHAR(20),
CHAR(2),
INTEGER,
DATE
CREATE TABLE person OF TYPE person_t;
最初の文で、person_t 型を作成します。2 番目の文で、表 person を作成します。この
表に、person_t 型のインスタンスが格納されます。厳密に言えば、型付き表の各行に、
表に割り当てられた名前付き行型のインスタンスが格納されます。前の例で、person_t
型のフィールドは、person 表の列を定義します。
重要: 名前付き行型を作成する順序は重要です。名前付き行型を使用して型付き表を定
義する前に、その型が存在している必要があります。
型付き表へのデータ挿入は、型なし表へのデータ挿入と同様に行います。型付き表にデ
ータを挿入すると、行 (ROW) 型のインスタンスが作成され、表に挿入されます。次の
例で、person 表に行を挿入する方法を示します。
INSERT INTO person
VALUES (’Brown, James’, ’13 First St.’, ’San Carlos’, ’CA’, 94070,
’01/04/1940’)
INSERT 文により、person_t 型のインスタンスが作成され、表に挿入されます。名前付
き行型に定義した列に対して挿入、更新、および削除を行う方法について詳しくは、
「IBM Informix: SQL ガイド: チュートリアル」を参照してください。
1 つの名前付き行型を使用して、複数の型付き表を作成できます。この場合、表の名前
は一意ですが、すべての表が同じ型を共有します。
重要: 一時表である型付き表を作成することはできません。
156
IBM Informix データベース設計および実装 ガイド
データ モデルを実装するときに型付き表を使用する利点については、164 ページの『型
継承』を参照してください。
表の型の変更
型なし表に比べ、型付き表には、継承階層構造で使用できるという利点があります。一
般に、継承によって表は別の表の表現および動作を取得できます。詳しくは、163 ペー
ジの『継承について』を参照してください。
ALTER TABLE 文の DROP 節および ADD 節により、型付き表と型なし表の変換を行
うことができます。ADD または DROP のどちらの操作を行っても、表に格納されてい
るデータへの影響はありません。
型なし表から型付き表への変換: 既存の型なし表を型付き表に変換するには、
ALTER TABLE 文を使用します。例えば、次の型なし表について考えます。
CREATE TABLE manager
(
name
VARCHAR(30),
department VARCHAR(20),
salary
INTEGER
);
型なし表を型付き表に変換するには、名前付き行型のフィールド名とフィールド型の両
方を、既存の表の列名と列型に一致させる必要があります。例えば、manager 表を型付
き表にするには、まず、表の列定義に一致する名前付き行型を作成する必要がありま
す。次の文は、manager 表の列に一致するフィールド名とフィールド型を含む
manager_t 型を作成します。
CREATE ROW TYPE manager_t
(
name
VARCHAR(30),
department VARCHAR(20),
salary
INTEGER
);
既存の型なし表に割り当てる名前付き行型を作成した後、ALTER TABLE 文を使用し
て、型を表に割り当てます。次の文は、manager 表を変更し、型 manager_t の型付き
表にします。
ALTER TABLE manager ADD TYPE manager_t
新しい manager 表は、古い表と同じ列とデータ型を含みながら、型付き表の利点も提
供します。
型付き表から型なし表への変換: 型付き表を型なし表へ変換する場合も、ALTER
TABLE 文を使用します。
ALTER TABLE manager DROP TYPE
第 8 章 Dynamic Server での拡張データ型の作成と使用
157
ヒント: 型付き表へ列を追加するには、型の削除、列の追加、表への型の追加を行う 3
つの ALTER TABLE 文が必要です。
名前付き行型を使用した列の作成
型付き表と型なし表のどちらにも、名前付き行型に定義した列を含めることができま
す。名前付き行型に定義した列は、型付き表、または型なし表のどちらの列でも同じよ
うに動作します。次の例で、最初の文は名前付き行型 address_t を作成します。2 番目
の文は、address_t 型を employee 表の address 列に割り当てます。
CREATE ROW
(
street
city
state
zip
);
TYPE address_t
VARCHAR(20),
VARCHAR(20),
CHAR(2),
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) 型に定
義した列の個々のフィールドにアクセスするには、ピリオド表記を使用してください。
ピリオド表記を使用して列のフィールドにアクセスする方法については、
「IBM Informix: SQL ガイド: チュートリアル」を参照してください。
行 (ROW) 型を割り当てた列にデータを挿入するときは、ROW コンストラクタを使用
して行 (ROW) 型の行リテラル値を指定する必要があります。次の例で、INSERT 文を
使用して employee 表に行を挿入する方法を示します。
INSERT INTO employee
VALUES (’John Bryant’,
ROW(’10 Bay Street’, ’Madera’, ’CA’, 95400)::address_t, 55000);
強い型指定は、名前付き行型の挿入または更新には適用されません。行の値を確実に名
前付き行型の値にするには、前の例で示したように、名前付き行型に明示的にキャスト
し、名前付き行型の値を生成する必要があります。INSERT 文は、3 つの値を挿入しま
す。そのうち 1 つは、4 つの値を含む行 (ROW) 型の値です。厳密に言えば、この操作
は列 name と列 salary に分割できない値を挿入し、address_t 型のインスタンスを作成
して列 address に挿入します。
行 (ROW) 型に定義した列に対して挿入、更新、および削除を行う方法について詳しく
は、「IBM Informix: SQL ガイド: チュートリアル」を参照してください。
158
IBM Informix データベース設計および実装 ガイド
別の行 (ROW) 型の中での名前付き行型の使用
名前付き行型は、別の行 (ROW) 型のフィールドのデータ型として使用できます。入れ
子行 (ROW) 型 は、別の行 (ROW) 型を含む行 (ROW) 型です。どの行 (ROW) 型をど
の行 (ROW) 型の中に入れても構いません。行 (ROW) 型の入れ子の深さに制限はあり
ません。しかし、深い入れ子にした行 (ROW) 型の挿入または更新を実行する場合、構
文の使い方に注意が必要です。
名前付き行型の場合、行 (ROW) 型を作成する順序が重要です。別の行 (ROW) 型の列
またはフィールドを定義する前に、その名前付き行型が存在している必要があります。
次の例では、最初の文で address_t 型を作成し、この型を 2 番目の文で使用して、
employee_t 型の address フィールドの型を定義しています。
CREATE ROW
(
street
city
state
zip
);
TYPE address_t
VARCHAR (20),
VARCHAR(20),
CHAR(2),
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 に含まれるフィールドのデータ型として使用することはで
きません。
名前付き行型の削除
名前付き行型を削除するには、DROP ROW TYPE 文を使用します。型を削除できるの
は、依存性がない場合のみです。次の条件に 1 つでも当てはまる場合、その名前付き行
型は削除できません。
v 現在、表に割り当てられている
v 現在、型が表の列に割り当てられている。
v 現在、型が別の行 (ROW) 型のフィールドに割り当てられている。
次の例で、person_t 型を削除する方法を示します。
DROP ROW TYPE person_t restrict;
名前付き行型を型階層から削除する方法については、168 ページの『型階層からの名前
付き行型の削除』を参照してください。
第 8 章 Dynamic Server での拡張データ型の作成と使用
159
名前なし行型
名前なし行型 は、ROW コンストラクタで作成する型付きフィールドのグループです。
名前付き行型と名前なし行型の重要な違いは、名前なし行型は表に割り当てることがで
きない、という点です。名前なし行型は、列またはフィールドの型定義にのみ使用しま
す。また、名前なし行型は構造体のみで識別されます。これに対し、名前付き行型は名
前で識別されます。行 (ROW) 型の構造体は、フィールドの数とデータ型で構成されま
す。
次の文は、2 つの名前なし行型を 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 には、それぞれ複数のフィールドが含まれてい
ます。名前なし行型のフィールドは、それぞれ異なるデータ型にできます。student 表
の列は 2 つのみですが、名前なし行型によって 7 つのフィールド、すなわち
f_name、m_init、l_name、street、city、state、および zip が定義されます。
次の例で、INSERT 文を使用して student 表にデータを挿入する方法を示します。
INSERT INTO student
VALUES (ROW(’Jim’, ’K’, ’Johnson’), ROW(’10 Grove St.’,
’Eldorado’, ’CA’, 94108))
行 (ROW) 型に定義した列を修正する方法について詳しくは、「IBM Informix: SQL ガ
イド: チュートリアル」を参照してください。
2 つの名前なし行型が同じ数のフィールドを含み、対応するフィールドが同じ型である
場合、データベース サーバはこの 2 つを区別しません。名前なし行型の型チェックで
は、フィールド名は無関係です。例えば、データベース サーバは次の名前なし行型を区
別しません。
ROW(a INTEGER, b CHAR(4));
ROW(x INTEGER, y CHAR(4));
名前なし行型の構文については、「IBM Informix: SQL ガイド: 構文」を参照してくだ
さい。行 (ROW) 型の値をキャストする方法については、 179 ページの『第 10 章
Dynamic Server でのユーザ定義キャストの作成と使用』を参照してください。
次のデータ型は、名前なし行型のフィールド型には使用できません。
v シリアル (SERIAL) 型
v 8 バイト シリアル (SERIAL8) 型
v バイト (BYTE) 型
160
IBM Informix データベース設計および実装 ガイド
v テキスト (TEXT) 型
これらの型が名前なし行型のフィールド定義で指定されると、データベース サーバはエ
ラーを戻します。
第 8 章 Dynamic Server での拡張データ型の作成と使用
161
162
IBM Informix データベース設計および実装 ガイド
第 9 章 Dynamic Server による型継承と表継承
継承について . . . . . . . . . . . . .
型継承 . . . . . . . . . . . . . . .
型階層の定義 . . . . . . . . . . . .
型階層内の型に対するルーチンのオーバーロード
継承と型代用性 . . . . . . . . . . .
型階層からの名前付き行型の削除 . . . . .
表継承 . . . . . . . . . . . . . . .
型階層と表階層との関係 . . . . . . . .
表階層の定義 . . . . . . . . . . . .
表階層内の表の動作の継承 . . . . . . .
表階層内の表の動作の修正 . . . . . . .
表階層内の表に関する制約 . . . . . .
表階層内の表へのインデックスの追加 . . .
表階層内の表のトリガ . . . . . . . .
表階層内のシリアル (SERIAL) 型 . . . . .
表階層への表の追加 . . . . . . . . . .
表階層内の表の削除 . . . . . . . . . .
表階層内の表の構造の変更 . . . . . . .
表階層内の表の問合せ . . . . . . . . .
表階層内の表のビューの作成 . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
163
164
164
166
167
168
169
169
170
171
172
173
173
174
174
175
176
176
177
177
本章について
この章では、型継承と表継承について説明し、型階層と表階層を作成して各階層内の型
と表を修正する方法について取り上げます。
継承について
継承 は、ある型や表が、別の型や表のプロパティを取得できるようにする処理です。プ
ロパティを継承する型を副型、表を副表 と呼びます。プロパティが継承される型を上位
型、表を上位表 と呼びます。継承では差分修正を実行できるため、型や表は、プロパテ
ィの全般的なセットを継承して、それぞれに固有のプロパティを追加できます。継承を
使用しての修正は、継承された上位型や上位表が修正によって変更されない程度に行い
ます。
Dynamic Server は、名前付き行型と型付き表に対してのみ継承をサポートしています。
Dynamic Server では、単一継承のみがサポートされています。単一継承 では、それぞ
れの副型や副表に上位型や上位表が 1 つずつしかありません。
© Copyright IBM Corp. 1996, 2004
163
型継承
型継承は名前付き行型のみに適用されます。継承を使用して、名前付き行型を型階層 に
グループ化できます。型階層では、それぞれの副型が、その副型の上位に定義されてい
る上位型の表現 (データ フィールド) と動作 (UDR、集合、および演算子) を継承しま
す。型階層には、次の利点があります。
v データ モデルのモジュール実装が容易になります。
v スキーマ コンポーネントを一貫して再使用できるようになります。
v 誤ってデータ フィールドを除外することがなくなります。
v 別のデータ型に定義されている UDR の継承が可能になります。
型階層の定義
164 ページの図 27 に、3 つの名前付き行型を持つ単純な型階層の例を示します。
person_t
employee_t
sales_rep_t
図 27. 型階層の例
この型階層の最上位にある上位型には、その下にある副型すべてが継承するフィールド
のグループが含まれています。上位型が存在しないと、その副型を作成できません。次
の例では、164 ページの図 27 の型階層の上位型 person_t を作成します。
CREATE ROW
(
name
address
city
state
zip
bdate
);
TYPE person_t
VARCHAR(30) NOT NULL,
VARCHAR(20),
VARCHAR(20),
CHAR(2),
INTEGER,
DATE
副型を作成するには、キーワード UNDER と、その副型がプロパティを継承する上位型
の名前を指定します。次の例では、person_t のフィールドすべてを継承する副型として
employee_t を定義する方法を示します。この例では、person_t 型に存在しないフィール
ド salary と manager を追加します。
164
IBM Informix データベース設計および実装 ガイド
CREATE ROW TYPE employee_t
(
salary
INTEGER,
manager VARCHAR(30)
)
UNDER person_t;
重要: 上位型のプロパティを継承する副型を作成するには、その上位型に対する
UNDER アクセス権を持っている必要があります。UNDER アクセス権について
は、 221 ページの『第 12 章 次元データベースの実装 (XPS)』を参照してくださ
い。
164 ページの図 27 の型階層では、sales_rep_t は employee_t の副型です。これは、
person_t が employee_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 のインスタンスには適用されません。
前述の型階層は、各副型が単一の上位型から継承する単一継承の例でした。図 28 に、
単一の上位型に対して複数の副型を定義する方法を示します。単一継承では、1 つしか
ない上位型から各副型が継承する必要がありますが、定義する型階層の深さと幅にはほ
とんど制限がありません。
第 9 章 Dynamic Server による型継承と表継承
165
person_t
employee_t
sales_rep_t
.
.
.
customer_t
engineer_t
.
.
.
us_customer_t
local_customers_t
.
.
.
non_us_customer_t
regional_customers_t
.
.
.
図 28. ツリー構造体の型階層の例
すべての階層において、最上位にある型を最上位型 と呼びます。図 28 では、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 にも継承されます。
型階層内の型に対するルーチンのオーバーロード
ルーチン オーバーロード とは、1 つの名前を複数のルーチンに割り当てて、それらの
ルーチンが操作できる異なる型の引数を指定する機能のことです。型階層では、副型は
その上位型に定義されているルーチンを自動的に継承します。ただし、新しいルーチン
を副型に定義して、継承されたルーチンを同じ名前でオーバーライドできます。例え
ば、型 person_t のインスタンスの姓と誕生日を戻す getinfo() ルーチンを、型 person_t
に対して作成するとします。この場合、employee_t のインスタンスの姓と給与を戻す別
の getinfo() ルーチンを型 employee_t に対して登録できます。図 29 に示すように、ル
ーチンをオーバーロードすることにより、型階層内の各タイプに対してルーチンをカス
タマイズできます。
166
IBM Informix データベース設計および実装 ガイド
図 29. 型階層内のルーチン オーバーロードの例
ルーチンをオーバーロードすると、型階層内のさまざまな型に対して同じ名前でも引数
が異なるルーチンが複数定義されます。その場合、指定する引数によって、実行される
ルーチンが決定します。例えば、型 employee_t の引数を指定して getinfo() を呼び出す
と、型 employee_t に定義されている getinfo() ルーチンが、同じ名前を持つ、継承され
たルーチンを無効にします。同様に、型 sales_rep_t に別の getinfo() を定義した場合、
型 sales_rep_t の引数を指定して getinfo() を呼び出すと、sales_rep_t が employee_t か
ら継承したルーチンが無効になります。
ユーザ定義ルーチン (UDR) を作成して登録する方法については、「IBM Informix: ユー
ザ定義ルーチンおよびデータ タイプ 開発者ガイド」を参照してください。
継承と型代用性
型階層では、副型はその上位型に定義されているルーチンすべてを自動的に継承しま
す。したがって、副型の引数を指定してルーチンを呼び出し、その副型にルーチンが定
義されていない場合、データベース サーバは上位型に定義されているルーチンを起動で
きます。型代用性 とは、上位型のインスタンスが予期される場合に副型のインスタンス
を使用する機能のことです。例えば、型 person_t の引数をとり、型 person_t のインス
タンスの姓と誕生日を戻すルーチン p_info() を作成するとします。他に p_info() ルー
チンが登録されていないときに型 employee_t の引数を指定して p_info() を起動する
と、このルーチンは、型 employee_t のインスタンスの名前と誕生日のフィールド
(person_t から継承された) を戻します。この動作が可能であるのは、employee_t が上
位型 person_t から関数を継承するためです。
通常、データベース サーバは、ルーチンの評価を行う場合、ルーチンの起動時に指定さ
れたルーチン名と引数に一致するシグニチャを検索します。そのようなルーチンが見つ
かると、データベース サーバはそのルーチンを使用します。正確に一致するルーチンが
見つからない場合、データベース サーバは、同じ名前を持ち、ルーチンが起動されたと
きに指定された引数型の上位型である引数型を持つルーチンを検索します。168 ページ
の図 30 で、副型 sales_rep_t の引数を使用して get() ルーチンが呼び出されたときに、
データベース サーバが使用できるルーチンを検索するプロセスを示します。sales_rep_t
型には get() ルーチンが定義されていませんが、データベース サーバは階層内の上位型
に定義されている get() ルーチンを見つけるまで検索します。この場合、sales_rep_t に
第 9 章 Dynamic Server による型継承と表継承
167
もその上位型 employee_t にも get() ルーチンは定義されていません。しかし person_t
にルーチンが定義されているため、このルーチンが起動されて sales_rep_t のインスタ
ンス上で動作します。
person_t
get()
employee_t
sales_rep_t
図 30. データベース サーバによる型階層内のルーチンの検索の例
データベース サーバが使用できるルーチンを検索するプロセスをルーチン解決 と呼び
ます。ルーチン解決について詳しくは、「IBM Informix: ユーザ定義ルーチンおよびデー
タ タイプ 開発者ガイド」を参照してください。
型階層からの名前付き行型の削除
型階層から名前付き行型を削除するには、DROP ROW TYPE 文を使用します。ただ
し、依存性のない型しか削除できません。次の条件のどちらかにあてはまる場合、名前
付き行型は削除できません。
v 現在、表に割り当てられている
v 別の型の上位型になっている
次の例では、型 sales_rep_t を削除する方法を示します。
DROP ROW TYPE sales_rep_t RESTRICT;
上位型を削除するには、まず、その上位型からプロパティを継承する副型をそれぞれ削
除する必要があります。作成したときと逆の順序で、型階層内の型を削除します。例え
ば、図 30 の型 person_t を削除するには、まず、次の順序で person_t の副型を削除す
る必要があります。
DROP ROW TYPE sale_rep_t RESTRICT;
DROP ROW TYPE employee_t RESTRICT;
DROP ROW TYPE person_t RESTRICT;
重要: 型を削除するには、データベース管理者、またはその型の所有者である必要があ
ります。
168
IBM Informix データベース設計および実装 ガイド
表継承
名前付き行型に定義されている表しか、表継承をサポートしていません。表継承 とは、
ある表が表階層でその表の上位にある上位表から動作 (制約、格納オプション、トリガ)
を継承できるようにするプロパティです。表階層 とは、表の間に定義できる関係のこと
で、それにより副表が上位表の動作を継承します。表継承には、次の利点があります。
v データ モデルのモジュール実装が容易になります。
v スキーマ コンポーネントを一貫して再使用できるようになります。
v 表階層内の表の一部またはすべてを範囲に持つ問合せを作成できるようになります。
表階層では、副表は、次のプロパティをその上位表から自動的に継承します。
v すべての制約定義 (主キー制約、一意性制約、および参照制約)
v 格納オプション
v すべてのトリガ
v インデックス
v アクセス方法
型階層と表階層との関係
表階層内の表はすべて、対応する型階層内の名前付き行型に割り当てられている必要が
あります。図 31 に、型階層と表階層の関係の例を示します。
person_t
person
employee_t
employee
sales_rep_t
sales_rep
図 31. 型階層と表階層の関係の例
名前付き行型が、表階層内の表と必ずしも 1 対 1 の関係を持たない型階層を定義する
こともできます。図 32 に、一部の名前付き行型のみを表に割り当てる型階層の作成方
法を示します。
第 9 章 Dynamic Server による型継承と表継承
169
person_t
customer_t
retail_customer_t
whlsale_customer_t
retail_customer
whlsale_customer
図 32. 一部の名前付き行型のみを表に割り当てる継承階層構造の例
表階層の定義
表を定義するために使用する型は、表を作成する前に存在している必要があります。同
様に、型階層を定義してからでなければ、対応する表階層を定義することはできませ
ん。表階層内の特定の副表と上位表との間の関係を確立するには、キーワード UNDER
を使用します。次の CREATE TABLE 文は、169 ページの図 31 の単純な表階層を定義
します。このセクションの例では、型 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;
表 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 型への継承と同様に行
われる必要があります。
副表は、上位表に追加された継承可能なプロパティすべてを自動的に継承します。した
がって、上位表のプロパティは常に追加および変更が可能で、副表はそれらの変更を自
動的に継承します。詳しくは、172 ページの『表階層内の表の動作の修正』を参照して
ください。
170
IBM Informix データベース設計および実装 ガイド
重要: 上位表のプロパティを継承する副表を作成するには、その上位表に対する
UNDER アクセス権を持っている必要があります。詳しくは、104 ページの『型
付き表に対する Under アクセス権 (IDS)』を参照してください。
表階層内の表の動作の継承
ある上位表の副表を作成すると、その副表は、次のプロパティを含む上位表のプロパテ
ィすべてを継承します。
v 上位表のすべての列
v 制約定義
v 格納オプション
v インデックス
v 参照整合性
v トリガ
v アクセス方法
さらに、表 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 を追加します。次の表に、階層内の各表の動作を示します。
表
表の動作
person
PRIMARY KEY、FRAGMENT BY EXPRESSION
employee
PRIMARY KEY、FRAGMENT BY EXPRESSION、CHECK 制約
sales_rep
PRIMARY KEY、FRAGMENT BY EXPRESSION、CHECK 制約、
LOCK MODE ROW
第 9 章 Dynamic Server による型継承と表継承
171
また、表階層には、ある 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 に
データを格納します。
表階層内の表の動作の修正
いったん表階層を定義すると、既存の表の構造 (列) は修正できません。ただし、階層
内の表の動作を修正することはできます。173 ページの表 7 に、表階層内で修正できる
表の動作と、その修正に使用する構文を示します。
172
IBM Informix データベース設計および実装 ガイド
表 7. 表階層内で修正できる表の動作
表の動作
構文
注意事項
制約定義
ALTER TABLE
制約を追加または削除するには、ADD
CONSTRAINT 節または DROP CONSTRAINT
節を使用します。詳しくは、173 ページの『表
階層内の表に関する制約』を参照してくださ
い。
インデックス
CREATE INDEX、ALTER
INDEX
詳しくは、173 ページの『表階層内の表へのイ
ンデックスの追加』および「IBM Informix: SQL
ガイド: 構文」の CREATE INDEX 文および
ALTER INDEX 文の説明を参照してください。
トリガ
CREATE/DROP TRIGGER
継承されたトリガは削除できません。ただし、
上位表からトリガを削除したり、副表にトリガ
を追加して継承されたトリガを無効にしたりす
ることはできます。上位表や副表のトリガを修
正する方法については、174 ページの『表階層
内の表のトリガ』を参照してください。トリガ
を作成する方法については、「IBM Informix:
SQL ガイド: チュートリアル」を参照してくだ
さい。
階層内の上位表を修正すると、既存の副表はすべて新しい表の動作を自動的に継承しま
す。
重要: ALTER TABLE 文を使用して表階層内の表を修正する場合に使用できるのは、
ADD CONSTRAINT 節、DROP CONSTRAINT 節、MODIFY NEXT SIZE 節、お
よび LOCK MODE 節のみです。
表階層内の表に関する制約
制約の変更または削除は、その制約が定義されている表でしか実行できません。継承さ
れた制約については、副表から削除も変更もできません。ただし、副表で新しい制約を
追加することはできます。また、ある表に追加制約を定義すると、その制約を定義した
表から継承を行う副表によって、その追加制約が継承されます。制約は加算的であるた
め、継承された制約のすべて、および現在の (追加された) 制約のすべてが適用されま
す。
表階層内の表へのインデックスの追加
階層内の上位表にインデックスを定義すると、その上位表の下位に定義するすべての副
表もまた、そのインデックスを継承します。表 tab_a、tab_b、および tab_c を含む表
階層において、tab_a が tab_b の上位表で、tab_b が tab_c の上位表である場合を想
定します。tab_b の列にインデックスを作成すると、そのインデックスは tab_b と
第 9 章 Dynamic Server による型継承と表継承
173
tab_c の両方の該当する列に作成されることになります。tab_a の列にインデックスを
作成すると、そのインデックスは tab_a、tab_b、および tab_c に存在することになり
ます。
重要: 副表が上位表から継承するインデックスに対しては、削除も修正も行うことがで
きません。ただし、副表にインデックスを追加することはできます。
インデックス、一意性制約、および主キーはすべて密接に関連しています。一意性制約
または主キーを指定すると、データベース サーバはその列に一意性インデックスを自動
的に作成します。したがって、上位表に定義した主キーや一意性制約は、副表すべてに
適用されます。例えば、2 つの表 (上位表と副表) があり、両方の表に列 emp_id があ
る場合を想定します。emp_id に一意性制約を持たせるように上位表が指定している場
合、副表には副表と上位表の両方に一意である emp_id 値が含まれている必要がありま
す。
重要: ある表階層内のいくつかの表が主キーを継承しない場合でも、同一の表階層内で
複数の主キーを定義することはできません。
表階層内の表のトリガ
継承されたトリガは削除できません。ただし、副表上にトリガを作成して、その副表が
上位表から継承するトリガを無効にすることはできます。制約とは異なり、トリガは非
加算的であるため、階層内の上位表の最も近いトリガのみが適用されます。
副表が上位表から継承したトリガを無効にする場合、空のトリガをその副表に作成する
と上位表からのトリガを無効にできます。トリガは非加算的であるため、この空のトリ
ガはこの副表、およびその下位の副表すべてに対して実行されます。これらのトリガま
でが無効にされることはありません。
表階層内のシリアル (SERIAL) 型
表階層では、シリアル (SERIAL) 型と 8 バイト シリアル (SERIAL8) 型の列を使用で
きます。ただし、1 つの表階層では、シリアル (SERIAL) 型列と 8 バイト シリアル
(SERIAL8) 型列をそれぞれ 1 つしか使用できません。例えば、次の型階層と表階層を
作成します。
CREATE
CREATE
CREATE
CREATE
ROW
ROW
ROW
ROW
TYPE
TYPE
TYPE
TYPE
CREATE
CREATE
CREATE
CREATE
TABLE
TABLE
TABLE
TABLE
parent_t
child1_t
child2_t
child3_t
parent_tab
child1_tab
child2_tab
child3_tab
(a INT);
(s_col SERIAL) UNDER parent_t;
(s8_col SERIAL8) UNDER child1_t;
(d FLOAT) UNDER child2_t;
of
of
of
of
type
type
type
type
parent_t;
child1_t UNDER parent_tab;
child2_t UNDER child1_tab;
child3_t UNDER child2_tab;
parent_tab 表には、シリアル (SERIAL) 型は含まれません。child1_tab はこの階層内で
シリアル (SERIAL) 型カウンタを初めて使用します。child2_tab はシリアル (SERIAL)
174
IBM Informix データベース設計および実装 ガイド
型列を 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) 型列と 8 バイト シリアル
(SERIAL8) 型列に適用される規則はすべて、その表階層内のシリアル (SERIAL) 型列と
8 バイト シリアル (SERIAL8) 型列にも適用されます。詳しくは、 39 ページの『第 3
章 データ型の選択』および「IBM Informix: SQL ガイド: 参照」を参照してください。
表階層への表の追加
表階層を定義した後で、ALTER TABLE 文を使用してその階層内の表の列を追加、削
除、または修正することはできません。ただし、既存の継承関係が侵害されない場合に
限り、新しい副型と副表を既存の階層に追加できます。図 33 に、型およびその型に対
応する表を既存の階層に追加する方法の 1 例を示します。破線は、追加された副型と副
表を示します。
person_t
person
employee_t
employee
sales_rep_t
sales_rep
us_sales_rep_t
us_sales_rep
図 33. 既存の継承階層に副型と副表を追加する方法の例
第 9 章 Dynamic Server による型継承と表継承
175
次の文は、図 33 の継承階層に型と表を追加する方法を示します。
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;
また、既存の上位型およびそれに並列する上位表から、分岐する副型と副表を追加する
こともできます。図 34 に customer_t 型と customer 表を既存の階層に追加する方法を
示します。この例では、customer 表と employee 表の両方が person 表からプロパティ
を継承します。
customer_t
person_t
person
employee_t
employee
sales_rep_t
sales_rep
customer
図 34. 既存の上位型と上位表の下位に型と表を追加する方法の例
次の文は、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;
表階層内の表の削除
ある表と、その表に対応する名前付き行型に依存性がない場合、つまり上位表および上
位型となっていない場合は、それらの表と型を削除できます。表を先に削除してからで
ないと型を削除できません。表の削除に関する一般情報については、「IBM Informix:
SQL ガイド: 構文」の DROP TABLE 文に関する説明を参照してください。名前付き行
型の削除方法については、159 ページの『名前付き行型の削除』を参照してください。
表階層内の表の構造の変更
ALTER TABLE 文を使用して表階層内の表の列を追加、削除、または修正することはで
きません。ALTER TABLE 文を使用して制約を追加、削除、または修正することは で
きます。
表階層内の表の列を追加、削除、または修正する (あるいはその他の方法で表の構造を
変更する) 処理には、時間がかかる場合があります。
176
IBM Informix データベース設計および実装 ガイド
表階層内の表の構造を変更するには:
1. 修正するすべての副表と上位表からデータをダウンロードします。
2. 副表と副型を削除します。
3. アンロードされたデータ ファイルを修正します。
4. 上位表を修正します。
5. 副型と副表を再作成します。
6. データをアップロードします。
表階層内の表の問合せ
表階層を使用すると、上位表とその副表を対象とする SELECT 文、UPDATE 文、また
は DELETE 文を 1 つの SQL コマンドで構築できます。例えば、表階層内の任意の上
位表に対する問合せは、その上位表の列すべてのデータ、およびその上位表から副表が
継承する列すべてのデータを戻します。問合せ結果を表階層内の表 1 つに制限するに
は、ONLY キーワードを問合せに含める必要があります。表階層内の表のデータを問合
せて修正する方法の詳細については、「IBM Informix: SQL ガイド: チュートリアル」
を参照してください。
表階層内の表のビューの作成
ビューは、表階層内のどの表に基づいても作成できます。例えば、次の文は 169 ページ
の図 31 で示す表階層の最上位表である person 表のビューを作成します。
CREATE VIEW name_view AS SELECT name FROM person
person 表が上位表であるため、ビュー name_view には person 表、employee 表、およ
び sales_rep 表の name 列からのデータが表示されます。person 表からのデータのみ
を表示するビューを作成するには、次の例に示すように ONLY キーワードを使用しま
す。
CREATE VIEW name_view AS SELECT name FROM ONLY(person)
重要: 上位表に定義されているビューに対して挿入や更新を実行することはできませ
ん。これはデータベース サーバが表階層内で新しい行を挿入する位置を判断でき
ないためです。
型付きビューの作成方法については、118 ページの『型付きビュー (IDS)』を参照して
ください。
第 9 章 Dynamic Server による型継承と表継承
177
178
IBM Informix データベース設計および実装 ガイド
第 10 章 Dynamic Server でのユーザ定義キャストの作成と
使用
キャストとは . . . . . . . . . . . . . . . . . . . . . . . .
ユーザ定義キャストの作成 . . . . . . . . . . . . . . . . . .
キャストの起動 . . . . . . . . . . . . . . . . . . . . . .
ユーザ定義キャストに関する制限 . . . . . . . . . . . . . . . .
行 (ROW) 型のキャスト . . . . . . . . . . . . . . . . . . . .
名前付き行型と名前なし行型の間のキャスト . . . . . . . . . . . .
名前なし行型どうしのキャスト . . . . . . . . . . . . . . . . .
名前付き行型の間でのキャスト . . . . . . . . . . . . . . . . .
フィールドでの明示的キャストの使用 . . . . . . . . . . . . . . .
名前なし行型のフィールドの明示的キャスト . . . . . . . . . . .
名前付き行型のフィールドの明示的キャスト . . . . . . . . . . .
行 (ROW) 型の各フィールドのキャスト . . . . . . . . . . . . . .
コレクション (COLLECTION) 型のキャスト. . . . . . . . . . . . . .
コレクション (COLLECTION) 型の変換の制限 . . . . . . . . . . . .
要素型が異なるコレクション . . . . . . . . . . . . . . . . . .
要素型に暗黙的キャストを使用する . . . . . . . . . . . . . .
要素型の変換に明示的キャストを使用する . . . . . . . . . . . .
リレーショナル データから マルチセット (MULTISET) 型コレクションへの変換
ディスティンクト (DISTINCT) 型のキャスト . . . . . . . . . . . . .
ディスティンクト (DISTINCT) 型での明示的キャストの使用 . . . . . . .
ディスティンクト (DISTINCT) 型とソース型の間のキャスト . . . . . . .
ディスティンクト (DISTINCT) 型のキャストの追加と削除 . . . . . . . .
スマート ラージ オブジェクトへのキャスト . . . . . . . . . . . . .
ユーザ定義キャストのキャスト関数の作成 . . . . . . . . . . . . . .
名前付き行型間でのキャストの例 . . . . . . . . . . . . . . . .
ディスティンクト (DISTINCT) 型間でのキャストの例 . . . . . . . . .
マルチレベル キャスト . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
180
180
181
181
182
183
183
184
184
185
185
186
186
187
187
187
187
188
188
189
189
190
191
192
192
193
194
本章について
この章では、ユーザ定義キャストについて説明し、実行時キャストを使用して拡張デー
タ型のデータ変換を実行する方法を説明します。
© Copyright IBM Corp. 1996, 2004
179
キャストとは
キャスト は、あるデータ型の値を別のデータ型に変換するメカニズムです。キャストに
より、異なるデータ型の値を比較したり、あるデータ型の値を別のデータ型の値と置き
換えたりすることができます。Dynamic Server は次のタイプの式によるキャストをサポ
ートしています。
v 列式
v 定数式
v 関数式
v SPL 変数
v ホスト変数 (ESQL)
v 文の局所変数 (SLV) 式
あるデータ型の値を別のデータ型に変換するには、データベースまたはデータベース サ
ーバにキャストが必要です。Dynamic Server では、次のタイプのキャストをサポートし
ます。
v 組込みキャスト。組込みキャスト は、データベース サーバに組み込まれているキャ
ストです。組込みキャストは、異なる組込みデータ型間の変換を自動的に実行しま
す。
v ユーザ定義キャスト。ユーザ定義キャストでは、多くの場合、あるデータ型から別の
データ型への変換を処理するキャスト関数 が必要になります。ユーザ定義キャスト
を登録し、使用するには、CREATE CAST 文を使用する必要があります。
CREATE CAST 文でキャストを作成するときに、EXPLICIT キーワードを含めると、ユ
ーザ定義キャストは明示的 になります。デフォルト オプションは、明示的です。明示
的キャストは、自動的には起動しません。明示的キャストを起動するには、キーワード
CAST...AS、または、キャスト演算子である二重コロン (::) を使用する必要がありま
す。
CREATE CAST 文でキャストを作成するときに、IMPLICIT キーワードを含めると、ユ
ーザ定義キャストは暗黙的 になります。データベース サーバは、実行時に、自動的に
暗黙的キャストを起動してデータ変換を実行します。
キャストはすべて syscasts システム カタログ表に組み込まれます。syscasts について
詳しくは、「IBM Informix: SQL ガイド: 参照」を参照してください。
ユーザ定義キャストの作成
2 つのデータ型間の変換を実行する組込みキャストがデータベース サーバで提供されな
い場合、データ型変換を処理するユーザ定義キャストを作成できます。ユーザ定義キャ
ストは、一般に、次の拡張データ型のデータ型変換を提供するのに使用します。
180
IBM Informix データベース設計および実装 ガイド
v 不透明 (OPAQUE) 型。不透明 (OPAQUE) 型の開発者は、不透明 (OPAQUE) 型の内
部表現および外部表現の変換を処理するキャストを定義する必要があります。不透明
(OPAQUE) 型のキャストを作成し、登録する方法については、「IBM Informix: ユー
ザ定義ルーチンおよびデータ タイプ 開発者ガイド」を参照してください。
v ディスティンクト (DISTINCT) 型。ディスティンクト (DISTINCT) 型とソース型を
直接比較することはできません。しかし、ディスティンクト (DISTINCT) 型からソー
ス型、およびソース型からディスティンクト (DISTINCT) 型への明示的キャストは
Dynamic Server によって自動的に登録されます。ディスティンクト (DISTINCT) 型
は、ソース型に定義されたキャストを継承しません。また、ディスティンクト
(DISTINCT) 型に定義するユーザ定義キャストは、ソース型には使用できません。デ
ィスティンクト (DISTINCT) 型のキャストを作成し、使用する方法の詳細と例につい
ては、192 ページの『ユーザ定義キャストのキャスト関数の作成』 を参照してくだ
さい。
v 名前付き行型。名前付き行型は、ほとんどの場合、キャストを作成することなく別の
行 (ROW) 型の値に明示的にキャストできます。ただし一部のデータ型では、名前付
き行型との間で値を変換するためには、まず変換を処理するキャストを作成する必要
があります。
ユーザ定義キャストを作成し、使用する方法の例については、193 ページの『ディステ
ィンクト (DISTINCT) 型間でのキャストの例』を参照してください。CREATE CAST
文の構文については、「IBM Informix: SQL ガイド: 構文」を参照してください。
キャストの起動
組込みキャスト、およびユーザ定義の暗黙的キャストの場合、データベース サーバは自
動的に (暗黙的に) データ変換を処理するキャストを起動します。例えば、式を明示的
にキャストせずに、整数 (INT) 型の値を小桁整数 (SMALLINT) 型、実数 (FLOAT)
型、または文字 (CHAR) 型の値と比較できます。これは、データベース サーバに用意
されているシステム定義キャストが、これらの組込みデータ型間での変換をユーザに見
えることなく処理するためです。
2 つのデータ型間の変換を処理する明示的なユーザ定義キャストを定義する場合、キー
ワード CAST...AS、またはキャスト演算子である二重コロン (::) で、キャストを明示的
に起動する必要があります。次の部分的な例で、明示的キャストを起動する 2 つの方法
を示します。
... WHERE new_col = CAST(old_col AS newtype)
... WHERE new_col = old_col::newtype
ユーザ定義キャストに関する制限
2 つの組込みデータ型間のユーザ定義キャストは作成できません。次のデータ型を 1 つ
でも含むユーザ定義キャストも作成できません。
第 10 章 Dynamic Server でのユーザ定義キャストの作成と使用
181
v コレクション (COLLECTION) 型: リスト (LIST) 型、マルチセット (MULTISET)
型、またはセット (SET) 型
v 名前なし行型
v スマート ラージ オブジェクト型: CLOB 型または BLOB 型
v シンプル ラージ オブジェクト: テキスト (TEXT) 型またはバイト (BYTE) 型
一般的に、2 つのデータ型間のキャストではそれぞれのデータ型のコンポーネント値の
個数は一致している必要があります。例えば、行 (ROW) 型のフィールドと不透明
(OPAQUE) 型のフィールドが対応していれば、その行 (ROW) 型と不透明 (OPAQUE)
型の間のキャストは可能です。格納構造が同じ 2 つのデータ型の間で変換を実行する場
合は、キャスト関数なしで CREATE CAST 文を使用できます。そうでない場合、キャ
スト関数を作成し、CREATE CAST 文で登録する必要があります。キャスト関数を使用
してユーザ定義キャストを作成する方法の例については、192 ページの『ユーザ定義キ
ャストのキャスト関数の作成』 を参照してください。
行 (ROW) 型のキャスト
名前付きと名前なしの 2 つの行 (ROW) 型の値は、両方の行 (ROW) 型のフィールドの
個数が同じで、さらに次の条件のいずれか 1 つに当てはまる場合にのみ、比較または置
換を行うことができます。
v 2 つの行 (ROW) 型の対応するフィールドがすべて同じデータ型である。
フィールドの個数が同じで、対応するフィールドのデータ型も同じ場合、その 2 つ
の行 (ROW) 型は 構造的に等価 であると見なされます。
v 2 つの名前付き行型を比較するときに変換を実行する、ユーザ定義キャストが存在す
る。
v データ型が異なる対応フィールドの値に対して必要な変換を実行する、システム定義
のキャスト、またはユーザ定義キャストが存在する。
対応するフィールドが同じデータ型でない場合、システム定義キャストまたはユーザ
定義キャストを使用して、フィールドのデータ変換を処理できます。
各フィールドのデータ変換を処理する組込みキャストがあれば、ある行 (ROW) 型の値
を、他の行 (ROW) 型に明示的にキャストできます。ただし、両方の行 (ROW) 型がど
ちらも名前なし行型の場合は除きます。この場合、明示的キャストは必要ありません。
フィールド変換を処理する組込みキャストがない場合、フィールド変換を処理するユー
ザ定義キャストを作成できます。キャストは、暗黙的なものにも、明示的なものにもで
きます。
一般的に、行 (ROW) 型を別の行 (ROW) 型にキャストする場合、明示的キャストまた
は暗黙的キャストで、それぞれのフィールド変換を処理します。対応するフィールドの
変換に明示的キャストが必要な場合、キャストされたフィールドの値は、対応するフィ
182
IBM Informix データベース設計および実装 ガイド
ールドの値に正確に一致する必要があります。明示的にキャストされた値に、データベ
ース サーバが追加の暗黙的キャストを適用することはありません。
名前付き行型と名前なし行型の間のキャスト
名前付き行型の値を名前なし行型の値と比較するには、明示的キャストを使用します。
次の名前付き行型と表を作成するとします。
CREATE
CREATE
CREATE
INSERT
ROW TYPE info_t (x CHAR(1), y CHAR(20))
TABLE customer (cust_info info_t)
TABLE retailer (ret_info ROW (a CHAR(1), b CHAR(20)))
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) 型に変換する明示的キャストを使用する必要があ
ります。次の問合せで、名前なし行型の ret_info 列は、名前付き行型の info_t に明示
的にキャストされます。
SELECT cust_info
FROM customer, retailer
WHERE cust_info = ret_info::info_t
一般的に、名前付き行型と名前なし行型の間で変換を実行するには、一方の行 (ROW)
型をもう一方の行 (ROW) 型に明示的にキャストする必要があります。明示的キャスト
は、どちらの方向にも実行できます。名前付き行型を名前なし行型にキャストすること
も、名前なし行型を名前付き行型にキャストすることもできます。次の文は、前の例と
同じ結果を戻します。ただし、この例では、名前付き行型が名前なし行型に明示的にキ
ャストされます。
SELECT cust_info
FROM customer, retailer
WHERE cust_info::ROW(a CHAR(1), b CHAR(20)) = ret_info
名前なし行型どうしのキャスト
構造的に等価な 2 つの名前なし行型は、明示的キャストを行わなくても比較できます。
両方の行 (ROW) 型のフィールドの個数が同じで、かつデータ型が異なる対応フィール
ドの値を変換するキャストが存在する場合も、名前なし行型と別の名前なし行型を比較
できます。つまり、フィールド変換を処理するキャストが、すべてシステム定義キャス
トまたは暗黙的キャストであれば、ある名前なし行型から別の名前なし行型へのキャス
トは暗黙的です。そうでない場合、名前なし行型を別の行 (ROW) 型と比較するには、
明示的にキャストする必要があります。
次の prices 表を作成するとします。
第 10 章 Dynamic Server でのユーザ定義キャストの作成と使用
183
CREATE TABLE prices
(col1 ROW(a SMALLINT, b FLOAT)
col2 ROW(x INT, y REAL) )
対応するフィールド間の変換を実行する組込みキャストがあれば、2 つの名前なし行型
の値は明示的キャストなしで比較できます。そのため、次の問合せでは col1 と col2 の
値を比較する明示的キャストは必要ありません。
SELECT * FROM prices WHERE col1 = col2
この例では、データ ベースサーバは暗黙的に組込みキャストを起動し、小桁整数
(SMALLINT) 型のフィールド値を整数 (INT) 型に、小桁実数 (REAL) 型のフィールド
を実数 (FLOAT) 型に変換します。
2 つの行 (ROW) 型の対応するフィールドが互いに暗黙的にキャストできない場合、こ
の 2 つの型の間で変換を処理するユーザ定義キャストがあれば、明示的にキャストでき
ます。
名前付き行型の間でのキャスト
名前付き行型は、強い型指定です。つまり、2 つの名前付き行型が構造的に等価であっ
ても、データベース サーバはその 2 つの行 (ROW) 型を別個の型として認識します。
そのため、2 つの名前付き行型間の比較を実行する前に、ユーザ定義キャストを作成
し、登録する必要があります。2 つの名前付き行型間の変換を処理するキャストを作成
し、使用する方法の例については、192 ページの『名前付き行型間でのキャストの例』
を参照してください。
フィールドでの明示的キャストの使用
フィールドに異なるデータ型を含む、名前付きと名前なしの 2 つの行 (ROW) 型の間で
明示的にキャストをするには、対応するフィールド データ型の変換を処理するシステム
定義またはユーザ定義キャストが必要となります。
2 つの行 (ROW) 型の間で明示的にキャストするとき、データベース サーバはフィール
ド データ型の変換を処理するのに必要な明示的キャストを自動的に起動します。つま
り、行 (ROW) 型値の明示的キャストを実行するとき、行 (ROW) 型の個々のフィール
ドを明示的にキャストする必要はありません。ただし、フィールドのデータ型変換の処
理に、複数レベルのキャストが必要な場合は除きます。
このセクションでは、次の例に示す行 (ROW) 型と表を使用して、名前付き行型と名前
なし行型の明示的キャストの動作を示します。
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);
184
IBM Informix データベース設計および実装 ガイド
名前なし行型のフィールドの明示的キャスト
2 つの行 (ROW) 型間の変換に、特定のフィールド値を変換する明示的キャストが含ま
れる場合、行 (ROW) 型値は明示的にキャストできますが、個々のフィールドを明示的
にキャストする必要はありません。
次の文で、tab1 表に値を挿入する方法を示します。
INSERT INTO tab1 VALUES (ROW( 3, 5.66::FLOAT::d_float))
tab1 の col1 の値を tab2 の col2 に挿入するには、行の値を明示的にキャストする必
要があります。データベース サーバは、tab1 の d_float ディスティンクト
(DISTINCT) 型と表 tab2 の実数 (FLOAT) 型の変換を、自動的には処理しません。
INSERT INTO tab2 SELECT col1::ROW(a INT, b FLOAT) FROM tab1
この例で、フィールド b を変換するのに使用するキャストは、明示的です。d_float か
ら実数 (FLOAT) 型への変換には、明示的キャストが必要です。ディスティンクト
(DISTINCT) 型をソース型に変換するには、明示的キャストが必要です。
一般的に、1 つ以上のフィールドが明示的キャストを使用する 2 つの名前なし行型の間
でキャストをするには、フィールド レベルではなく、行 (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 章 Dynamic Server でのユーザ定義キャストの作成と使用
185
します。また、10 進数 (DECIMAL) 型と d_float 型の間には暗黙的キャストがありま
せん。そのため、2 レベルのキャストが必要です。
行 (ROW) 型の各フィールドのキャスト
行 (ROW) 型のフィールドの操作に明示的キャストが必要な場合、フィールドが関連付
けられている行 (ROW) 型に関係なく、個々のフィールド値を明示的にキャストできま
す。次の文は、フィールド値の明示的キャストを使用して変換を処理するものです。
SELECT col1 from tab1, tab2 WHERE col1.b = col2.b::FLOAT::d_float
行 (ROW) 型のフィールドの操作に暗黙的キャストが必要な場合、適切なフィールド値
を指定するだけで、データベース サーバが自動的に変換を処理します。次の文は、異な
るデータ型のフィールド値を比較するものです。このとき、組込みキャストにより自動
的に整数 (INT) 型と実数 (FLOAT) 型の値との間で変換が行われます。
SELECT col1 from tab1, tab2 WHERE col1.a = col2.b
コレクション (COLLECTION) 型のキャスト
明示的キャストを使用して、要素型が異なる 2 つのコレクション (COLLECTION) 型の
間で変換を実行できることもあります。2 つのコレクション (COLLECTION) 型の値を
比較または置換するには、両方のコレクションがともにセット (SET) 型、マルチセット
(MULTISET) 型、またはリスト (LIST) 型のいずれかとなっている必要があります。
v すべてのコンポーネント型が同じ場合、2 つの要素型は等価です。例えば、一方のコ
レクション (COLLECTION) 型の要素型が行 (ROW) 型の場合、もう一方のコレクシ
ョン (COLLECTION) 型も、フィールドの数とデータ型が同じである行 (ROW) 型で
す。
v データベースには、データ型が異なる要素型の、任意のまたはすべてのコンポーネン
トの間で変換を実行するキャストが存在します。
対応する要素型のデータ型が異なる場合、Dynamic Server は、組込みキャストまたは
ユーザ定義キャストを使用して要素型のデータ変換を処理できます。
データベース サーバがコレクション (COLLECTION) 型の値を挿入、更新、または比較
するとき、要素型レベルで型チェックが発生します。そのため、2 つのコレクション
(COLLECTION) 型間のキャストでは、要素型レベルでデータ変換を実行します。コレク
ションに格納された実データは、特定の要素型のデータであるためです。
次の型と表は、このセクションのコレクション (COLLECTION) 型のキャストの例で使
用します。
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));
186
IBM Informix データベース設計および実装 ガイド
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 -- returns error
要素型が異なるコレクション
コレクション (COLLECTION) 型が同じで、要素型が異なる 2 つのコレクション間で変
換を行う方法は、それぞれのコレクションの要素型、および要素型が異なる場合にデー
タベース サーバが一方の要素型をもう一方の要素型に変換するのに使用するキャストの
タイプに依存します。
v 2 つの要素型の変換を処理する、組込みキャストまたは暗黙的なユーザ定義キャスト
が存在する場合は、コレクション (COLLECTION) 型の間で明示的にキャストする必
要はありません。
v 要素型の変換を処理する明示的キャストが存在する場合、コレクション
(COLLECTION) 型の明示的キャストを実行できます。
要素型に暗黙的キャストを使用する
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) 型に明示
第 10 章 Dynamic Server でのユーザ定義キャストの作成と使用
187
的にキャストする必要があります。次の例では、整数 (INT) 型と my_int の要素型の変
換に、明示的キャストが必要です。ディスティンクト (DISTINCT) 型とソース型のキャ
ストは、常に明示的です。
次の 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) );
次の例で、コレクション副問合せを使用して tab_a 表の整数 (INT) 型の値の行をマル
チセット (MULTISET) 型のコレクションに変換する方法を示します。tab_a のすべての
行をマルチセット (MULTISET) 型のコレクションに変換し、tab_b 表に挿入します。
INSERT INTO tab_b VALUES (
(MULTISET (SELECT a_col FROM tab_a)))
ディスティンクト (DISTINCT) 型のキャスト
ディスティンクト (DISTINCT) 型では、ディスティンクト (DISTINCT) 型がソース型と
して使用する組込みデータ型の組込みキャストは、一切継承されません。そのため、組
込みデータ型を他のデータ型に暗黙的に変換する組込みキャストを、組込みデータ型を
ソース型として使用するディスティンクト (DISTINCT) 型で利用することはできませ
ん。しかし、組込みデータ型のディスティンクト (DISTINCT) 型を作成するとき、デー
タベース サーバは、ディスティンクト (DISTINCT) 型から組込みデータ型への変換、
および組込みデータ型からディスティンクト (DISTINCT) 型への変換を処理する 2 つ
の明示的キャストを提供します。
188
IBM Informix データベース設計および実装 ガイド
ディスティンクト (DISTINCT) 型での明示的キャストの使用
ディスティンクト (DISTINCT) 型の値とソース型の値を比較または置換するには、一方
の型をもう一方の型に明示的にキャストする必要があります。例えば、ソース型の値で
ディスティンクト (DISTINCT) 型列の挿入または更新をするには、その値を明示的にデ
ィスティンクト (DISTINCT) 型にキャストする必要があります。
次のように、整数 (INTEGER) 型を基にしたディスティンクト (DISTINCT) 型 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) 型を基にしたディスティンクト (DISTINCT) 型
num_type と、型 num_type の列がある表を作成するとします。
CREATE DISTINCT TYPE num_type AS NUMERIC;
CREATE TABLE tab_x (col1 num_type);
ディスティンクト (DISTINCT) 型 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) -- returns error
ディスティンクト (DISTINCT) 型とソース型の間のキャスト
ディスティンクト (DISTINCT) 型のデータ表現はソース型と同じですが、ディスティン
クト (DISTINCT) 型をソース型と直接比較することはできません。そのため、ディステ
ィンクト (DISTINCT) 型を作成したときに、Dynamic Server によって次の明示的キャス
トが自動的に登録されます。
v ディスティンクト (DISTINCT) 型からソース型へのキャスト
v ソース型からディスティンクト (DISTINCT) 型へのキャスト
2 つのディスティンクト (DISTINCT) 型を作成すると想定します。1 つは映画のタイト
ル、もう 1 つは音楽録音物のタイトルを処理します。可変長文字 (VARCHAR) 型を基
にしたディスティンクト (DISTINCT) 型は次のように作成します。
第 10 章 Dynamic Server でのユーザ定義キャストの作成と使用
189
CREATE DISTINCT TYPE movie_type AS VARCHAR(30);
CREATE DISTINCT TYPE music_type AS VARCHAR(30);
その後、型 movie_type、型 music_type、および可変長文字 (VARCHAR) 型の列を含む
entertainment 表を作成できます。
CREATE TABLE entertainment
(
video
movie_type,
compact_disc music_type,
laser_disv
VARCHAR(30)
);
ディスティンクト (DISTINCT) 型とソース型を比較するには、一方のデータ型からもう
一方に明示的キャストを実行する必要があります。例えば、ビデオとレーザ ディスクの
両方で入手できる映画を調べる場合を想定します。次の文は、ディスティンクト
(DISTINCT) 型 (music_type) の値をそのソース型である可変長文字 (VARCHAR) 型の
値と比較するために、WHERE 節での明示的キャストを必要とします。この例では、ソ
ース型をディスティンクト (DISTINCT) 型に明示的にキャストします。
SELECT video FROM entertainment
WHERE video = laser_disc::movie_type
しかし、次の文で示すように、ディスティンクト (DISTINCT) 型をソース型に明示的に
キャストすることもできます。
SELECT video FROM entertainment
WHERE video::VARCHAR(30) = laser_disc
同じソース型に定義した 2 つのディスティンクト (DISTINCT) 型の間で変換を実行す
るには、ターゲットとなるディスティンクト (DISTINCT) 型にキャストする前に、ソー
ス型に戻す中間キャストを行う必要があります。次の文では、music_type の値を
movie_type の値を比較しています。
SELECT video FROM entertainment
WHERE video = compact_disc::VARCHAR(30)::movie_type
ディスティンクト (DISTINCT) 型のキャストの追加と削除
ディスティンクト (DISTINCT) 型に強い型指定を適用するために、データベース サー
バはディスティンクト (DISTINCT) 型とソース型の間の変換を処理する明示的キャスト
を提供します。しかし、ディスティンクト (DISTINCT) 型の作成者は、既存の明示的キ
ャストを削除して暗黙的キャストを作成できます。これにより、ディスティンクト
(DISTINCT) 型とソース型の変換に明示的キャストが不要になります。
重要: データベース サーバが提供するディスティンクト (DISTINCT) 型とソース型の間
の明示的キャストを削除して、代わりにこれらのデータ型変換を処理する暗黙的
キャストを作成すると、ディスティンクト (DISTINCT) 型のもつ独自性が損なわ
れます。
190
IBM Informix データベース設計および実装 ガイド
次の DROP CAST 文は、movie_type に自動的に定義された 2 つの明示的キャストを
削除します。
DROP CAST(movie_type AS VARCHAR(30));
DROP CAST(VARCHAR(30) AS movie_type);
既存のキャストを削除した後で、movie_type と可変長文字 (VARCHAR) 型の間の変換
を処理する 2 つの暗黙的キャストを作成できます。次の CREATE CAST 文は、2 つの
暗黙的キャストを作成します。
CREATE IMPLICIT CAST (movie_type AS VARCHAR(30));
CREATE IMPLICIT CAST (VARCHAR(30) AS movie_type);
2 つのデータ型間の変換を実行するキャストがデータベースに存在している場合、その
データ型間のキャストは作成できません。
ディスティンクト (DISTINCT) 型とソース型の間の変換を実行する暗黙的キャストを作
成すると、この 2 つの型を、明示的キャストを行うことなく比較できます。次の文で
は、video 列と laser_disc 列の比較には、変換が必要となります。暗黙的キャストを作
成したため、可変長文字 (VARCHAR) 型と movie_type の間の変換は暗黙的です。
SELECT video FROM entertainment
WHERE video = laser_disc
スマート ラージ オブジェクトへのキャスト
データベース サーバが提供しているキャストにより、テキスト (TEXT) 型およびバイ
ト (BYTE) 型のオブジェクトを BLOB 型および CLOB 型のデータに変換できます。
この機能により、既存のデータベースのバイト (BYTE) 型およびテキスト (TEXT) 型の
データを BLOB 列および CLOB 列に移行できます。
次の例は、stores_demo データベースの catalog 表にあるバイト (BYTE) 型の列値を
BLOB 列値に変換し、superstores_demo データベースの catalog 表を更新する方法を示
しています。
UPDATE catalog SET advert = ROW (
(SELECT cat_photo::BLOB FROM stores_demo:catalog
WHERE catalog_num = 10027),
advert.caption)
WHERE catalog_num = 10027
データベース サーバは、BLOB 型をバイト (BYTE) 型の値に変換するキャスト、また
は CLOB 型をテキスト (TEXT) 型の値に変換するキャストを提供していません。
第 10 章 Dynamic Server でのユーザ定義キャストの作成と使用
191
ユーザ定義キャストのキャスト関数の作成
データベースに、不透明 (OPAQUE) 型、ディスティンクト (DISTINCT) 型、または名
前付き行型が含まれている場合、異なるデータ型間の変換ができるユーザ定義キャスト
を作成する必要が生じることがあります。格納構造が同じ 2 つのデータ型の間で変換を
実行する場合は、キャスト関数なしで CREATE CAST 文を使用できます。しかし、場
合によっては、キャスト関数を作成してからキャストとして登録する必要があります。
次の場合には、キャスト関数を作成する必要があります。
v 格納構造が異なる 2 つのデータ型間の変換
v データ変換を意味のあるものにするために、値の操作を含む変換
次のセクションでは、キャスト関数を必要とするユーザ定義キャストを作成する方法を
示します。
名前付き行型間でのキャストの例
次の例に示す名前付き行型と表を作成すると想定します。名前付き行型は構造的に等価
ですが、writer_t と editor_t は一意のデータ型です。
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 つの名前付き行型間の変換を処理するには、まず、ユーザ定義キャストを作成する必
要があります。次の例は、キャスト関数を作成し、型 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);
キャストを作成して登録すると、型 writer_t の値を editor_t へ明示的にキャストでき
ます。次の問合せは、型 writer_t の値を editor_t に変換するために、WHERE 節で明
示的キャストを使用しています。
SELECT book_title FROM projects
WHERE CAST(writer AS editor_t) = editor;
もちろん、キャスト演算子 :: を使用して、同じキャストを実行することもできます。こ
れを次の例で示します。
192
IBM Informix データベース設計および実装 ガイド
SELECT book_title FROM projects
WHERE writer::editor_t = editor;
ディスティンクト (DISTINCT) 型間でのキャストの例
通貨を表すディスティンクト (DISTINCT) 型、dollar、yen、および sterling を定義する
とします。2 つの通貨間の比較には、金額に為替レートをかける必要があります。その
ため、あるデータ型から他のデータ型へのキャストを処理するだけではなく、比較する
値の為替レートも計算するキャスト関数を作成する必要があります。
次の例は、同じソース型である実数 (DOUBLE PRECISION) 型を基にした 3 つのディ
スティンクト (DISTINCT) 型を定義する方法を示しています。
CREATE DISTINCT TYPE dollar AS DOUBLE PRECISION;
CREATE DISTINCT TYPE yen AS DOUBLE PRECISION;
CREATE DISTINCT TYPE sterling AS DOUBLE PRECISION;
ディスティンクト (DISTINCT) 型を定義した後は、比較可能な製品のメーカー価格を提
供する表を作成できます。次の例では、dollar、yen、および sterling の各ディスティン
クト (DISTINCT) 列を含む manufact_price 表を作成しています。
CREATE TABLE manufact_price
(
product_desc VARCHAR(20),
us_price
dollar,
japan_price
yen,
uk_price
sterling
);
manufact_price 表に値を挿入するとき、次のように、dollar、yen、および sterling の値
を適切なディスティンクト (DISTINCT) 型にキャストできます。
INSERT INTO manufact_price
VALUES (’baseball’, 5.00::DOUBLE PRECISION::dollar,
510.00::DOUBLE PRECISION::yen,
3.50::DOUBLE PRECISION::sterling);
ディスティンクト (DISTINCT) 型は、ソース型で利用できる組込みキャストを継承しな
いため、前の INSERT 文はそれぞれ 2 つのキャストを必要とします。それぞれの
INSERT 文で、内部キャストは 10 進数 (DECIMAL) 型を実数 (DOUBLE PRECISION)
型に変換し、外部キャストは実数 (DOUBLE PRECISION) 型を適切なディスティンクト
(DISTINCT) 型 (dollar、yen、または sterling) に変換します。
dollar 型、yen 型、および sterling 型を比較する前に、キャスト関数を作成し、キャス
トとして登録する必要があります。次の例では、dollar、yen、および sterling の値の比
較に使用できる SPL 関数を作成しています。各関数は、入力値に為替レートを反映し
た値を乗算します。
CREATE FUNCTION dollar_to_yen(d dollar)
RETURN (d::DOUBLE PRECISION * 106)::CHAR(20)::yen;
END FUNCTION;
第 10 章 Dynamic Server でのユーザ定義キャストの作成と使用
193
CREATE FUNCTION sterling_to_dollar(s sterling)
RETURNS dollar
RETURN (s::DOUBLE PRECISION * 1.59)::CHAR(20)::dollar;
END FUNCTION;
キャスト関数を作成した後、CREATE CAST 文を使用し、キャストとして登録する必要
があります。次の文は、dollar_to_yen() 関数と sterling_to_dollar() 関数を明示的キャス
トとして登録する方法を示します。
CREATE CAST(dollar AS yen WITH dollar_to_yen);
CREATE CAST(sterling AS dollar WITH sterling_to_dollar);
関数をキャストとして登録した後は、この関数を、データ型の変換が必要な操作で使用
します。キャスト関数の作成、キャストとしての登録に使用する構文については、
「IBM Informix: SQL ガイド: 構文」の CREATE FUNCTION 文と CREATE CAST 文
の説明を参照してください。
次の問合せでは、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 つの式に複数のレベルのキャストを必要とする操作のことです。yen 値と
sterling 値の間のキャストは存在しないため、この 2 つのデータ型を比較する問合せで
は複数のキャストが必要になります。最初の (内部の) キャストは、sterling 値を dollar
値に変換します。2 番目の (外部の) キャストは、dollar 値を yen 値に変換します。
SELECT * FROM manufact_price
WHERE japan_price < uk_price::dollar::yen
yen から sterling への直接変換を処理する別のキャスト関数を追加することもできま
す。次の例は、関数 yen_to_sterling() を作成し、キャストとして登録しています。為替
レートを考慮し、関数は yen 値に .01 をかけて、等価な sterling 値を導出します。
194
IBM Informix データベース設計および実装 ガイド
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);
yen から sterling へのキャストを追加すると、次の問合せで示すように、単一レベル
キャストを使用して yen 値と sterling 値を比較できます。
SELECT japan_price::sterling, uk_price FROM manufact_price
WHERE japan_price::sterling) < uk_price;
SELECT 文では、明示的キャストが yen 値を等価な sterling 値として戻します。
WHERE 節では、キャストによって yen 値と sterling 値の比較を可能にしています。
第 10 章 Dynamic Server でのユーザ定義キャストの作成と使用
195
196
IBM Informix データベース設計および実装 ガイド
第 4 部 次元データベース
© Copyright IBM Corp. 1996, 2004
197
198
IBM Informix データベース設計および実装 ガイド
第 11 章 次元データ モデルの作成
データ ウェアハウスの概要 . . . . . . . .
次元データベースを作成する理由 . . . . .
次元データとは . . . . . . . . . . .
次元データ モデルのコンセプト . . . . . . .
ファクト表 . . . . . . . . . . . . .
データ モデルの次元 . . . . . . . . .
次元要素 . . . . . . . . . . . .
次元属性 . . . . . . . . . . . .
次元表 . . . . . . . . . . . . .
次元データ モデルの作成 . . . . . . . . .
ビジネス プロセスの選択 . . . . . . . .
ビジネス プロセスの要約 . . . . . . . .
ファクト表の細分性の決定 . . . . . . .
細分性のデータベース サイズへの影響力 . .
ビジネス プロセスを使用しての細分性の決定
次元と階層の明確化 . . . . . . . . . .
ファクト表のメジャー (基準) の選択 . . . .
ファクト表を次元表と結合するキーの使用 .
正規化の防止 . . . . . . . . . . . .
次元表の属性の選択 . . . . . . . . . .
次元データ モデルの共通する問題の処理 . . . .
次元表の属性数を最小限に抑える . . . . .
時々変更する次元の処理 . . . . . . . .
スノーフレーク スキーマの使用 . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
200
201
202
204
205
206
206
207
207
208
208
209
210
210
210
211
214
215
215
216
217
217
218
219
本章について
この章では、次元データ モデルのコンセプトおよびテクニックを紹介し、簡単な次元デ
ータ モデルの作成方法を説明します。 221 ページの『第 12 章 次元データベースの実
装 (XPS)』では、SQL を使用して次元データ モデルを実装する方法を説明します。
大規模なデータ ウェアハウスについては、次元データ モデルはリレーショナル データ
モデルよりも管理が困難です。このため、データ ウェアハウスでは通常、リレーショナ
ル データ モデルに基づいています。しかし、次元データ モデルは、データ ウェアハ
ウスのサブセットであるデータ マートを作成する場合に特に適しています。
この章で取り扱う次元データ モデルの一般原則は、Dynamic Server や、Extended
Parallel Server で作成するデータベースに適用されます。どのデータベース サーバを使
用して次元データベースを作成するかを、単一の要素のみで決定することはできませ
© Copyright IBM Corp. 1996, 2004
199
ん。しかし、大規模なスケーラブル ウェアハウスは Extended Parallel Server で作成
し、小型のウェアハウス、OLTP システム、および運用システムは Dynamic Server で
作成することを想定しています。
次元データ モデルのコンセプトを理解するには、SQL やリレーショナル データベース
の理論についての基本的な知識が必要です。この章では、データ ウェアハウスのコンセ
プトを要約し、簡単な次元データ モデルを説明するにすぎません。
データ ウェアハウスの概要
データ ウェアハウス という用語は、最も広い意味では、極めて多くの履歴データを格
納しているデータベースのことを指します。データは一連のスナップショットとして格
納され、そのスナップショットの各レコードは、ある特定の時点でのデータを表しま
す。このデータ スナップショットで、ユーザが履歴を再作成したり、何らかの時点と別
の時点との間で正確な比較をしたりできます。データ ウェアハウスは、ウェアハウスに
ロードされる前に抽出するデータを統合し、変換します。データ ウェアハウスの第一の
長所は、格納されている膨大な情報に簡単にアクセスしたり、分析したりできることで
す。
データ ウェアハウスという用語は、人によっては違うことを意味することがあります。
このマニュアルでは、データを格納するために使用する次の形式を包括する、データ ウ
ェアハウス とデータ ウェアハウス環境 という用語を使用します。
v データ ウェアハウス
データ抽出のために最適化されたデータベースです。データをトランザクション レ
ベルで格納するのではなく、あるレベルのデータを要約します。日常の操作を自動化
する従来の OLTP データベースとは違い、データ ウェアハウスは長期にわたってエ
ンタープライズ全体 のパフォーマンスを評価できる意思決定支援環境を提供しま
す。通常、リレーショナル データ モデルを使用して、データ ウェアハウスを作成
します。
v データ マート
小型のデータベースに格納され、エンタープライズ全体の戦略計画ではなく特定の目
的またはデータ サブジェクトを指向する、データ ウェアハウスのサブセットです。
データ マートには、操作データ、要約データ、スペーシャル (地理空間) データ、メ
タデータを組み込むことができます。通常、次元データ モデルを使用して、データ
マートを作成します。
v 操作データ ストア
意思決定を行うときに一度に 1 つまたは 2 つのレコードを参照するように最適化さ
れたサブジェクト指向のシステムです。操作データ ストアは、タイムリーで、現行
の統合データを含んでいるハイブリッド形式のデータ ウェアハウスです。データに
は通常、トランザクションよりも高いレベルの細分性があります。操作データは事務
200
IBM Informix データベース設計および実装 ガイド
的な日常の意思決定に使用できます。このデータは、データ ウェアハウスの共通デ
ータ ソースとしての役割を果たすことができます。
v リポジトリ
リポジトリは、複数のデータ ソースを結合して、1 つの正規化されたデータベース
にします。リポジトリ内のレコードは、頻繁に更新されます。データは、履歴データ
ではなく、操作データです。特定のシステム要件によっては、特定の意思決定の問合
せにリポジトリが使用できます。リポジトリは、操作処理用の統合化されたエンター
プライズ全体のデータ ソースを必要とする企業のニーズに適合しています。
次元データベースを作成する理由
リレーショナル データベースは通常、オンライン トランザクション処理 (OLTP) 用に
最適化されています。 OLTP システムは、業務上の日常的な操作ニーズを満たすように
設計され、データベースのパフォーマンスはそのような操作上のニーズに合わせて調整
されます。したがって、リレーショナル データベースでは少数のレコードなら迅速に検
索できますが、大量のレコードを検索し、急いで要約する場合には、速度が遅くなるこ
とがあります。OLTP システムの欠点となる可能性があるのは、次の点です。
v ビジネス エンタープライズ全体では、データに一貫性がない場合があります。
v データへのアクセスが複雑になる可能性があります。
これとは対照的に、次元データベースは、ビジネスの動向や予測の分析を支援するよう
に設計され、調整されています。このような情報処理のタイプは、OLAP (Online
Analytical Processing: オンライン分析型処理)、または意思決定支援処理として知られて
います。OLAP は、データベース設計者が情報処理への次元的なアプローチのことをい
うときに使用する用語でもあります。
次元データベースは、データ抽出と分析のために最適化されています。データベースに
ロードした新しいデータは通常、多くの場合は複数のソースから、バッチで更新されま
す。OLTP システムが、受注入力のような特定の処理を中心にデータを整理する傾向に
あるのに対し、次元データベースはサブジェクト指向の傾向にあり、「どんな製品が売
れ筋か、どんな時期に製品が一番売れるか、どこの地区の販売が弱いか」といった質問
に答えることを目的としています。
次の表に、OLTP データベースと OLAP データベースとの主な違いを要約します。
リレーショナル データベース (OLTP)
次元データベース (OLAP)
データを細分化
データを要約
現行のデータ
履歴データ
一度に 1 つのレコードを処理
一度に多数のレコードを処理
処理指向
サブジェクト指向
高構造化反復処理向けに設計
高構造化されていない分析処理向けに設計
第 11 章 次元データ モデルの作成
201
リレーショナル テクノロジによって企業が解決を図ろうとする問題の多くは、元来、多
次元的なものです。例えば、地域ごとの製品の売上げ、製品ごとの地域の売上げなどの
要約を作成する SQL では、従来のリレーショナル データベースでの処理に何時間もか
かるかもしれません。しかし、次元データベースでは、同じ問合せが一瞬のうちに処理
できます。
この章で説明している OLTP データベースと OLAP データベースとの特性上のスキー
マ設計の相違に加えて、通常、これら 2 つのタスクに合わせて問合せオプティマイザの
調整の仕方を変える必要があります。例えば、OLTP 操作では、入れ子ループ結合をサ
ポートするために、OPTCOMPIND 設定 (同名の環境変数または構成パラメータで指定)
は通常ゼロに設定します。対照的に、OLAP 操作では OPTCOMPIND を 2 に設定して
コスト本位の問合せ予定をサポートする方が効率的です。OPTCOMPIND 環境変数およ
び OPTCOMPIND 構成パラメータそれぞれについて詳しくは、「IBM Informix: SQL ガ
イド: 参照」および「IBM Informix: Dynamic Server 管理者の参照」を参照してくださ
い。OPTCOMPIND、結合方式、および問合せオプティマイザについて詳しくは、
「IBM Informix: Dynamic Server パフォーマンス ガイド」を参照してください。
Dynamic Server では、OLTP と OLAP の両方の操作を必要とするようなセッションの
中で動的に OPTCOMPIND 設定を変更できる、SET ENVIRONMENT OPTCOMPIND
文もサポートしています。SQL の SET ENVIRONMENT 文について詳しくは、
「IBM Informix: SQL ガイド: 構文」を参照してください。
次元データとは
従来のリレーショナル データベースは、レコードのリストを中心として整理されていま
す。各レコードには、属性 (フィールド) に整理された関連情報が組み込まれていま
す。デモンストレーション データベース stores_demo の customer 表はその代表例で
あり、名前、会社、住所、電話番号などのフィールドが入っています。この表には複数
のフィールドに情報がありますが、表の各行には 1 件の顧客が属しているにすぎませ
ん。顧客名と、例えば電話番号のような他のフィールドを持つ 2 次元的なマトリックス
を作成する場合、1 対 1 の対応しか表現できません。表 8 に、1 対 1 の対応のみがあ
るフィールドを使用した表を示します。
表 8. フィールドが 1 対 1 で対応している表
顧客
電話番号 --->
Ludwig Pauli
Carole Sadler
Philip Currie
408-789-8075
-------------------------------
---------------415-822-1289
----------------
------------------------------414-328-4543
このマトリックスの前記の customer 表からフィールドを任意に組み合わせることはで
きますが、1 対 1 の対応で常に終わるため、この表には多次元性がなく、次元データベ
ースには不向きであることが分かります。
202
IBM Informix データベース設計および実装 ガイド
そこで、表のフィールド間に 1 対 1 よりも多くの対応が含まれているリレーショナル
データベースを考えてみます。国内の各地域の製品売上げについての売上げデータを含
んだ表を作成するとします。説明を簡単にするために、この会社には 3 つの製品があっ
て、3 つの地域で販売しているとします。表 9 に、このデータをリレーショナル表に格
納する方法を示します。
表 9. 簡単なリレーショナル表
製品
地域
販売数量
サッカー ボール
サッカー ボール
サッカー ボール
テニスラケット
テニスラケット
テニスラケット
野球ボール
野球ボール
野球ボール
東部
西部
中央
東部
西部
中央
東部
西部
中央
2300
4000
5600
5500
8000
2300
10000
22000
34000
203 ページの表 9 の表によると、1 地域で複数の製品が販売され、また 1 製品が複数
の地域で販売されています。したがって、この表には多次元的な表現が適しています。
表 10 に、製品と地域データの多対多の関係を、より効果的に表現している 2 次元的な
マトリックスを示します。
東部
西部
サッカー ボール
テニスラケット
野球ボール
2300
5500
10000
4000
8000
22000
製品
表 10. 簡単な 2 次元的な例
地域
中央
5600
2300
34000
このデータを表 9の 3 つのフィールドのあるリレーショナル表にすることはできます
が、データは表 10の 2 次元的なマトリックスのほうがより自然です。
従来のリレーショナル表よりも、次元 表のほうがパフォーマンスは良くなります。次元
的なアプローチによって、要約したり、比較したりするデータへのアクセスが簡単にな
ります。例えば、次元表を使用して、西部で販売されている製品の数を問い合せる場合
は、データベース サーバが West 列を検索し、その列のすべての行の合計を計算しま
す。リレーショナル表で同じ問合せを実行する場合、データベース サーバは Region 列
が west になる行を検索、抽出してから、そのデータを集計します。この種の問合せで
は、次元表を使用すると、リレーショナル表が west のレコードすべてを検索するため
に要する時間のごく一部で、West 列のすべての値を合計できます。
第 11 章 次元データ モデルの作成
203
次元データ モデルのコンセプト
次元データベースを作成するには、次元データ モデルから着手します。次元データ モ
デルは、データベースを作成するための方法を簡単かつ理解しやすくします。次元デー
タベースは、どの次元にもアクセスできる、3 次元または 4 次元のデータベース キュ
ーブ (立方体) と考えることができます。次元データベースを作成するには、データを
視覚化するモデルが必要です。
ユーザの業務は異なる市場で製品を販売することであり、時経過のパフォーマンスを評
価するとします。このビジネス プロセスを、時間、製品、および市場という各次元が含
まれているデータのキューブ (立方体) と考えるのは簡単です。図 35 は、この次元モデ
ルを示しています。キューブ (立方体) の各線に沿ったさまざまな交差部分には、この
ビジネスのメジャー (基準) が含まれています。このメジャー (基準) は、製品、市場、
および時間データという特定の組合せに対応します。
図 35. 時間、製品、および市場の次元のあるビジネスの次元モデル
次元モデルは、スター結合スキーマ とも呼ばれます。このモデルのダイアグラムが、中
央に表があり、その周囲に他の表が配置されていて星のように見えるために、データベ
ース設計者はこの名前を使用しています。このスキーマによる表は中央の表のみで、他
のすべての表は複数結合によって接続されます。この中央の表をファクト表、他の表を
次元表 と呼びます。すべての次元表には、次元表とファクト表とを結ぶ連結部が、問合
せには関係なく、1 つだけあります。図 36 に、異なる市場で製品を販売し、時経過に
よる業績を評価するあるビジネスの簡単な次元モデルを示します。
204
IBM Informix データベース設計および実装 ガイド
Sales
time_key
product_key
store_key
dollars_sold
units_sold
dollars_cost
time_key
day_of_week
month
quarter
year
holiday_flag
product_key
description
brand
category
store_key
store_name
address
floor_plan_type
図 36. 代表的な次元モデル
ファクト表
ファクト表は、ビジネスのメジャー (基準) を格納し、各次元表の最低レベルのキー値
を示します。メジャー (基準) は、サブジェクトについての量的なデータ、または実際
のデータです。メジャー (基準) は通常、数値であり、質問の量 や数 に対応します。
メジャー (基準) の例には、価格、製品の売上げ、製品の在庫、収益などがあります。
メジャー (基準) は、表内の列に基づくこともでき、算出されることもできます。
表 11 に、販売数量の合計、収益、ある日のあるアカウントへのある製品の販売利益が
メジャー (基準) となっているファクト表を示します。
表 11. サンプル レコードによるファクト表
製品コード
アカウント
コード
日コード
販売数量
収益
利益
1
5
32104
1
82.12
27.12
3
17
33111
2
171.12
66.00
1
13
32567
1
82.12
27.12
ファクト表を設計する前に、そのファクト表の細分性 を決定する必要があります。細分
性は、そのファクト表の個々の低レベル レコードを定義する方法に対応します。細分性
は、個別のトランザクション、毎日のスナップショット、あるいは毎月のスナップショ
ットであったりします。表 11 のファクト表には、各アカウントに販売した製品ごとに
毎日 1 行が組み込まれています。したがって、このファクト表の細分性は、アカウント
別、日別の製品 として表現します。
第 11 章 次元データ モデルの作成
205
データ モデルの次元
次元 は、実世界での 1 セットのオブジェクト、またはイベントを表します。データ モ
デルのために明確にした各次元は、次元表として実装しなければなりません。次元と
は、ファクト表のメジャー (基準) を意味あるものにする修飾子です。次元は質問の何
が、いつ、どこでという局面に答えるためです。例えば、次元をゴシック体で示してい
る次のビジネス上の事項を考えてください。
v 昨年 はどのアカウント が最大の利益を生み出しましたか。
v ベンダ ごとの利益はどのようでしたか。
v 各製品 はどのくらいの数量が売れましたか。
上記の質問のうち、収益、利益、および販売数量は次元ではなく メジャー (基準) であ
り、数量データまたは実際のデータを表します。
次元要素
次元では、さまざまなレベルの要約に複数の次元要素 を定義できます。例えば、販売組
織の構造に関連するすべての要素が 1 つの次元を構築していることがあります。図 37
に、アカウント次元が定義する次元要素を示します。
図 37. アカウント次元における次元要素
次元は、関連要素の階層から構築されています。次元と次元の間には階層的な関係があ
るため、ユーザは、前の詳細レベルよりも高いレベル にあるデータにアクセスしたり
(ロール アップする)、低いレベルにあるデータにアクセスしたりする (ドリル ダウンす
る) 問合せを構築できます。図 37 に、次元要素の階層的関係を示します。アカウント
はテリトリにロール アップし、テリトリは地域にロール アップします。ユーザは、抽
出するデータに応じて、異なるレベルの次元で問合せができます。例えば、ユーザがす
べての地域に対する問合せを実行してから、詳細な情報を得るためにテリトリまたはア
カウントのレベルまでドリル ダウンする場合があります。
次元要素は通常、他の表との連結を容易にするため、数値コードまたは短い文字列とし
てデータベースに格納されます。
206
IBM Informix データベース設計および実装 ガイド
各次元要素では、次元が複数の次元要素を定義するのと同じ方法で、複数の次元属性が
定義できます。
次元属性
次元属性とは、次元表の列のことを指します。各属性は、次元階層内でのあるレベルに
おける要約です。次元要素が次元表内の階層的な関係を定義するのに対して、属性はユ
ーザが熟知している用語で次元要素を表します。図 38 に、アカウント次元の次元要素
と対応する属性を示します。
図 38. 次元要素に対応する属性
次元属性は次元内の項目を記述するため、テキストの場合に最も便利です。
ヒント: 設計プロセスにある間に、生産データ ソースからの数値データ フィールドが
計測済みのファクトなのか属性なのかが分からないことがあります。一般に、
サンプリングを行うたびに数値データ フィールドが変化する計測値の場合は、
ファクトです。ほぼ一定の何かを個別に評価した説明の場合は、次元属性で
す。
次元表
次元表 は、ビジネスの次元についての説明をテキスト形式で格納する表です。次元表に
は、適切な場合、階層の各レベルの要素と属性が含まれています。データ分析に必要な
最低レベルの詳細によって、その階層の最低レベルが決定します。この基本レベルより
も高いレベルが冗長データを格納します。この正規化されていない表では、問合せに必
要な結合部分の数が低減して、ユーザが高いレベルに問合せしてから詳細レベルにドリ
ル ダウンすることが簡単になります。ドリル ダウン という用語は、次元表の行ヘッダ
を問合せに追加することを意味します。表 12に、アカウント次元を基にした次元表の例
を示します。
第 11 章 次元データ モデルの作成
207
表 12. 次元表の例
アカウント
コード
アカウント名
テリトリ
営業員
地域
地域
サイズ
地域
管理者
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. モデル化するサブジェクト分野を分析するために使用するビジネス プロセスを選択
します。
2. ファクト表の細分性を決定します。
3. 各ファクト表の次元と階層を明確にします。
4. ファクト表のメジャー (基準) を明確にします。
5. 各次元表の属性を決定します。
6. ユーザにデータ モデルを確認させます。
次元データベースは、複数のビジネス モデルに基づいていたり、多くのファクト表を持
っていたりしますが、このセクションで説明するデータ モデルは単一のビジネス プロ
セスに基づいており、ファクト表も 1 つです。
ビジネス プロセスの選択
ビジネス プロセス は、従来のシステムが支援する組織において重要なオペレーション
です。このシステムからデータを収集して、次元データベースに使用します。ビジネス
プロセスでは、それらのデータを使用してエンド ユーザが何を行うのか、どこから抽出
したデータなのか、そのデータを意味あるものにするにはどのように変換するのかを明
確にします。財務、販売分析、市場分析、顧客プロファイルなど、数多くのソースから
情報が発生します。次のリストは、どんなデータを次元データベースに組み込むかを判
断するために使用する可能性があるさまざまなビジネス プロセスを示しています。
208
IBM Informix データベース設計および実装 ガイド
v 販売
v 出荷
v 在庫
v 注文
v 送り状
ビジネス プロセスの要約
例えば、より効率的なマーケティング戦略を開発できるように、ユーザの組織が顧客の
購買傾向を製品ラインと地域ごとに分析するとします。このシナリオでは、データ モデ
ルの対象エリアは販売です。
多くのインタビューを行い、販売ビジネス プロセスを完全に分析してから、ユーザの組
織は次の情報を収集するとします。
v 顧客ベースの情報が変化しました。
以前は、営業地区を都市ごとに分割していました。現在、顧客のベースは 2 つの地
域に対応しています。地域 1 としてカリフォルニア州、地域 2 としてその他の州で
す。
v 次のレポートは、マーケティング上で最も重要です。
– ベンダ当たりの製品別の毎月の収益、コスト、純利益
– 製品、地域、月別の収益と販売数量
– 毎月の顧客収益
– ベンダ当たりの四半期の収益
v 販売分析のほとんどは月ごとの結果に基づくものですが、週ごと、あるいは後日会計
期間ごとに売り上げを分析できます。
v データ入力システムは、リレーショナル データベースにあります。
作業用のデータ モデルを開発するには、販売情報のリレーショナル データベースに
次のプロパティがあると想定できます。
– データベース stores_demo は、マーケティング部門が使用する収益データの多く
を提供します。
– 分析担当者が使用する製品コードは、カタログ番号として catalog 表に格納されて
います。
– 製品ライン コードは、ストック番号として stock 表に格納されています。製品ラ
イン名は、説明として格納されています。
– 製品階層はやや複雑です。各製品ラインには多くの製品があり、各メーカーにも多
くの製品があります。
v 各製品のコスト データはすべて、異なる購買システムの costs.lst というフラット フ
ァイルに格納されています。
第 11 章 次元データ モデルの作成
209
v 顧客データは、データベース stores_demo に格納されています。
地域情報は、このデータベースにまだ追加されていません。
次元モデルの重要な特性は、このモデルが内部の表名や列名ではなく、エンド ユーザが
熟知しているビジネス ラベルを使用しているということです。ビジネス プロセスが完
了すると、次元データ モデルのメジャー (基準)、次元、および関係を作成するために
必要なすべての情報が入手できます。この次元データ モデルを使用して、 221 ページの
『第 12 章 次元データベースの実装 (XPS)』 で説明するデータベース sales_demo 実
装します。
デモンストレーション データベース stores_demo は、この章で開発する次元データ モ
デルの主要なデータ ソースです。データベース sales_demo の表を移植するために使用
するデータ ソースについての詳細は、224 ページの『データ ソースからデータベース
へのデータのマッピング』を参照してください。
ファクト表の細分性の決定
対象分野についての関連情報をすべてそろえたら、設計プロセスでの次の手順はファク
ト表の細分性を決定することです。これを行うには、ファクト表に個別の低いレベルの
どんなレコードを組み込むかを決定する必要があります。ファクト表の細分性を作り上
げる構成要素は、データ モデルの次元と直接一致します。したがって、ファクト表の細
分性を定義するときは、データ モデルの次元を明確にします。
細分性のデータベース サイズへの影響力
ファクト表の細分性は、データベースに必要な格納領域量も決定します。例えば、ファ
クト表について考えられる次の細分性を考えてください。
v 日別地域別の製品
v 月別地域別の製品
日別地域別の製品 という細分性を持つデータベースのサイズは、月別地域別の製品 と
いう細分性を持ったデータベースよりもはるかに大きくなります。これは、トランザク
ションの月次要約ではなく、毎日のトランザクションそれぞれについてのレコードがデ
ータベースに組み込まれるためです。細分性が細かすぎると自然と膨大なデータベース
になってしまう可能性があるため、ファクト表の細分性は注意して決定する必要があり
ます。反対に、細分性を大まかにしすぎると、ユーザがデータベースに対して意味のあ
る問合せを行うのに十分な詳細が得られないことになります。
ビジネス プロセスを使用しての細分性の決定
ビジネス プロセスから収集した情報を入念に検討することによって、ファクト表の細分
性を決定するには何が必要かが分かります。要約すると、さらに効率的なマーケティン
グ戦略が開発できるように、ユーザの組織は顧客の購買傾向を製品ライン別と地域別に
分析するということです。
210
IBM Informix データベース設計および実装 ガイド
製品別顧客: ファクト表の細分性は常に、対応する各次元の最低のレベルを表しま
す。ビジネス プロセスからの情報を検討すると、ファクト表の顧客と製品の次元につい
ての細分性が明らかになります。顧客と製品はこれ以上細分化できません。これらは既
に、ファクト表の各レコードの最低のレベルを表しています。製品が複数のコンポーネ
ントで構成されている場合もあるため、製品は、さらに製品コンポーネントのレベルに
まで細分化できることもあります。
製品別地域別の顧客: ユーザの組織が分析する顧客購買傾向には地理的な構成要素が
含まれているため、この場合も、地域情報については最低レベルを決定する必要があり
ます。ビジネス プロセスでは、これまでは販売地区は市区町村別に分割されていました
が、ユーザの組織では現在、顧客ベースの 2 つの地域を区別しています。地域 1 はカ
リフォルニア州、地域 2 はその他の州です。しかし、最低のレベルには販売地区データ
も組み込まれているため、地区が地理的情報の最低レベルを表し、ファクト表の細分性
をさらに定義する第 3 の構成要素となっています。
製品別地域別日別の顧客: 顧客購買傾向は常に時経過によって発生するため、ファ
クト表の細分性には時間要素を組み込む必要があります。ユーザの組織では、週、会計
期間、月、四半期、および年ごとにレポートを作成するように決定したとします。最低
レベルでは、基本の細分性である「日」を選択します。この細分性により、火曜日の売
り上げと金曜日の売り上げを比較したり、毎月の最初の日の売り上げを比較したりする
ことができます。ファクト表の細分性は、これで完成しました。
日の細分性を選択するための決定は、time 次元表の各レコードが日を表すことを意味し
ます。格納要件という点では、毎日のデータが 10 年分あっても約 3,650 レコードにす
ぎず、比較的小さい次元表であると見なされます。
次元と階層の明確化
ファクト表の細分性を決定したら、データ モデルの主要な次元を明確にするのは簡単で
す。これは、細分性を定義する各コンポーネントが次元に対応しているためです。図 39
は、ファクト表の細分性とデータ モデルの次元との関係を示しています。
図 39. データ モデルの次元に対応するファクト表の細分性
データ モデルの次元 (顧客、製品、地理、時間) を正しい位置に使用すると、スキーマ
ダイアグラムが形になってきます。
第 11 章 次元データ モデルの作成
211
ヒント: この時点で、ファクト表の主要な細分性にさらに次元を追加できます。この場
合、新しい次元は主要次元を組み合わせる際に単一の値しかとれません。次元
を追加したためにさらにレコードが生成され、細分性に違反することが確認さ
れた場合は、ファクト表の細分性を変更して、追加した次元が納まるようにす
る必要があります。このデータ モデルについては、追加的な次元を追加する必
要はありません。
この時点で、各次元の次元要素と階層がマップできるようになりました。図 40は、次
元、次元要素、および固有の階層間の関係を示しています。
212
IBM Informix データベース設計および実装 ガイド
図 40. 次元、次元要素、および固有の階層間の関係
ほとんどの場合、次元要素では、各次元についての考えられる最低の細分性を表現する
必要があります。これは、問合せが個別の低いレベルのレコードにアクセスするからで
はなく、問合せには厳密な方法でデータベースを検索する必要があるためです。つま
り、データ ウェアハウス環境が提起する問題が通常、大まかなものであったとしてもま
だ、これらの質問は製品詳細の最低レベルに依存します。
第 11 章 次元データ モデルの作成
213
ファクト表のメジャー (基準) の選択
データ モデルのメジャー (基準) には、データそのものだけでなく、既存のデータから
計算する新しい値も含まれます。そのため、メジャー (基準) を調べると、ファクト表
の細分性だけでなく次元の数も調整する必要がでてくる場合もあります。
データ モデルを設計するときに必要なもう 1 つの重要な決定事項は、計算結果をファ
クト表に格納するか、これらの値を実行時に導出するかです。
答えなければならない質問は、「ビジネスを分析するのにどんなメジャー (基準) を使
用するか」です。メジャー (基準) は、どれくらいの量、またはどれくらいの数 かを示
す量的なデータか、実際のデータであることに留意してください。販売ビジネス プロセ
スの分析から集めた情報は、次のリストのメジャー (基準) になります。
v 収益
v コスト
v 販売数量
v 純利益
これらのメジャーを使用して、図 41 のファクト表が完成します。
図 41. 各次元表を参照する販売ファクト表
214
IBM Informix データベース設計および実装 ガイド
ファクト表を次元表と結合するキーの使用
さしあたり、214 ページの図 41 のスキーマは、データベースの論理設計と物理設計の
両方が示されていると考えてください。データベースには次の 5 つの表が含まれていま
す。
v Sales ファクト表
v Product 次元表
v Time 次元表
v Customer 次元表
v Geography 次元表
各次元表には、主キー (製品、時間コード、顧客、地域コード) が含まれていて、ファ
クト表では対応する列は外部キーです。ファクト表には、これら 4 つの外部キーの組合
せである主 (複合) キーもあります。原則として、ファクト表の各外部キーには、次元
表にそれと 1 対になるキーがなければなりません。さらに、複合キーを備えている次元
データベースの表は、ファクト表である必要があります。つまりこれは、多数対多数の
関係を表す次元データベースの各表がファクト表であることを意味します。
ヒント: 主キーは、短い数値データ型 (整数 (INT) 型、小桁整数 (SMALLINT) 型、シ
リアル (SERIAL) 型) または (コードに使用するような) 短い文字列にします。
長い文字列を主キーとして使用しないようにしてください。
正規化の防止
ファクト表の 4 つの外部キーは、きちんと管理された連続整数である場合、ファクト表
の 4 つのキーすべてに対して 16 バイト (時間、製品、顧客、および地理について 4
バイトずつ) まで小さくして予約できます。ファクト表の 4 つのメジャー (基準) が各
4 バイトの整数列であれば、別に 16 バイトのみを予約する必要しかありません。した
がって、ファクト表の各レコードは 32 バイトになるにすぎません。何十億の列のある
ファクト表でも、約 32GB の基本データ領域しか必要としません。
コンパクトなキーやデータを使用している、記憶量の少ないファクト表が次元データベ
ースの典型です。次元モデルのファクト表は元来、高度に正規化されています。ファク
ト表の 4 つのキー間のきわめて複雑な多数対多数の関係はこれ以上正規化できません。
4 つの次元表に相関関係がないためです。実際には、各製品は、各地域のすべての顧客
に対して毎日販売されています。
ファクト表は、次元データベースで最大の表です。次元表は通常、ファクト表よりも非
常に小さいため、データベースのディスク領域を計算するときには次元表を無視できま
す。単にディスク領域を節約するために次元データベースのあらゆる表を正規化するの
は、適切ではありません。さらに、正規化された次元表は、ユーザが単一の次元表を探
索して制約を設定したり、便利な行ヘッダを選択したりする機能を低減します。
第 11 章 次元データ モデルの作成
215
次元表の属性の選択
ファクト表が完成したら、各次元表の次元属性を決定できます。属性を選択する方法を
説明するために、時間次元を考えてみましょう。販売ビジネス プロセスのデータ モデ
ルは、time 次元表の各レコードが日を表すように、時間次元に対応する日の細分性を定
義します。この表の各フィールドは、そのレコードが表している特定日によって定義さ
れることを覚えておいてください。
また、販売ビジネス プロセスの分析で、マーケティング部門が月次、四半期、年次のレ
ポートを必要としていることも示されているため、時間次元には、日、月、四半期、年
という要素が含まれます。各要素には、長い文字列を含んでいる列値を回避するため
に、その要素とコード属性を説明する属性が割り当てられています。表 13 は、time 次
元表の属性と、表の各フィールドのサンプル値を示しています。
表 13. 時間次元の属性
時間
コード
注文日
35276
35277
35278
07/31/1999
08/01/1999
08/02/1999
月コード
月
四半期
コード
四半期
年
7
8
8
july
aug
aug
3
3
3
third q
third q
third q
1999
1999
1999
216 ページの表 13 では、割り当てる属性名は、エンド ユーザがデータベース上で問合
せを簡単に作成できるような、なじみのあるビジネス用語とすべきであることを示して
います。図 42 では、各次元表に定義されている属性すべてを備えた販売ビジネス プロ
セスの完ぺきなデータ モデルを示します。
216
IBM Informix データベース設計および実装 ガイド
図 42. 販売ビジネス プロセスの完ぺきな次元データ モデル
次元データ モデルの共通する問題の処理
これまでのセクションで説明してきた次元モデルは、次元データ モデルの最も基本的な
コンセプトとテクニックを説明するものにすぎません。エンタープライズのビジネス上
のニーズを明確にするために作成するデータ モデルには、通常、データベースからでき
る限り最大の問合せパフォーマンスを得るために解決する必要のある、さらなる問題や
困難が含まれています。このセクションでは、次元データ モデルを作成するときに最も
共通して発生する問題の解決に使用できるさまざまな方法を説明します。
次元表の属性数を最小限に抑える
顧客情報や製品情報が入っている次元表には、50 から 100 個の属性があったり、行が
数百万あったりします。しかし、属性が多すぎる次元表は、行を過度に大きくしたり、
パフォーマンスを劣化させたりすることがあります。このため、特定の属性のグループ
を次元表から切り離して、小次元 表という別個の表に配置することもあります。小次元
表は、大きい次元表から切り離された小さい属性グループから構成されます。次の特性
のどちらかを持つ属性に小次元表を作成できます。
v 問合せの制約として、フィールドをほとんど使用しない。
v フィールドを頻繁に比較し合う。
第 11 章 次元データ モデルの作成
217
図 43 は、顧客表から切り離された人口情報についての小次元表を示しています。
図 43. 人口情報の小次元表
ファクト表と顧客表の両方の外部キーとして、人口キーを人口表に格納できます。これ
により、人口表をファクト表に直接結合できます。また、直接顧客表と一緒に人口キー
を使用して、人口属性を閲覧することもできます。
時々変更する次元の処理
OLTP システムとは対照的に、ほとんど更新されない次元データベースでは、ほとんど
の次元は時が経過しても比較的 変化しません。販売地区または地域、あるいは会社の名
前や住所にはほとんど変更がないためです。しかし、履歴比較を行うには、これらの変
更は、それが発生した時点で処理する必要があります。図 44 は、変更が加えられた次
元の例を示しています。
図 44. 変更した次元
218
IBM Informix データベース設計および実装 ガイド
次元に発生した変更を処理するには、次の 3 つの方法が使用できます。
v 次元列に格納されている値を変更します。
図 44には、customer 次元表の Bill Adams のレコードが更新されて、新しい住所で
ある Arlington Heights が示されています。この時点で、この顧客のこれまでの販
売履歴のすべてが、Des Plaines ではなく、Arlington Heights 地区と関連付けられま
す。
v 新しい値や一般化キーを使用して 2 番目の次元レコードを作成します。
この方法は、効率的に履歴を区分します。customer 次元表はこの時点で、Bill Adams
についての 2 つの履歴を含んでいます。キー 101 のある以前のレコードが残り、こ
の時点ではファクト表のレコードも以前のレコードに関連付けられています。新しい
レコードも Bill Adams の customer 次元表に追加されて、以前のキーと、例えば
101.01 といったバージョンの桁から構成される新しいキーが付きます。Bill Adams
のファクト表に追加された後続のすべてのレコードが、この新しいキーと関連付けら
れます。
v 影響を受ける属性の customer 次元表に新しいフィールドを追加して、以前の属性の
名前を変更します。
新しい値についての以前の履歴を追跡したり、以前の履歴の新しい値を追跡したりす
る必要がない限り、この方法はほとんど使用されません。customer 次元表は、
current address という名前の新しい属性を取得し、以前の属性を original address
に変更します。Bill Adams についての情報を含んでいるレコードには、元の住所と現
在の住所の両方の値が含まれます。
スノーフレーク スキーマの使用
スノーフレーク スキーマは、スター スキーマの変形であり、非常に大きい次元表を複
数の表に正規化します。ファクト表の集合体を使用している場合に大きい次元表の結合
を避けたい場合は、階層のある次元をスノーフレーク構造に分解できます。例えば、製
品次元表から切り離すブランド情報がある場合は、ブランドごとの単一の行から構成さ
れていて、製品次元表よりも大幅に行数の少ないブランド スノーフレークが作成できま
す。図 45 は、ブランド要素と製品ライン要素のスノーフレークと、brand_agg 集合表
を示しています。
第 11 章 次元データ モデルの作成
219
図 45. スノーフレーク スキーマの例
ブランド コードとブランド当たりの総収益から構成される集合 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 文を使用して、重複行を除去します。
次元表が比較的小さくて、スノーフレーク スキーマが不要であっても、数百万行もある
顧客や製品の次元表のあるような小売業や通信販売ビジネスでは、スノーフレーク スキ
ーマを使用するとパフォーマンスが大幅に向上します。
集合表が利用できない場合、スノーフレーク スキーマで正規化された次元要素に結合す
る何らかのものは現在、次の問合せが示すように 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
220
IBM Informix データベース設計および実装 ガイド
第 12 章 次元データベースの実装 (XPS)
次元データベース sales_demo の実装 . . . . . . . . . .
CREATE DATABASE の使用. . . . . . . . . . . .
CREATE TABLE 文を使用した次元表およびファクト表の作成
データ ソースからデータベースへのデータのマッピング . .
次元データベースへのデータのロード . . . . . . . . .
データベース sales_demo の作成 . . . . . . . . . .
次元データベースのテスト . . . . . . . . . . . .
Extended Parallel Server のログ付き表とログなし表 . . . . .
表タイプの選択 . . . . . . . . . . . . . . . .
スクラッチ一時表と Temp 一時表 . . . . . . . . .
ロウ永続表 . . . . . . . . . . . . . . . . .
静的永続表 . . . . . . . . . . . . . . . . .
オペレーショナル永続表 . . . . . . . . . . . .
標準永続表 . . . . . . . . . . . . . . . . .
表のタイプの切替え . . . . . . . . . . . . . . .
データ ウェアハウス環境のインデックス . . . . . . . . .
データ ウェアハウス環境での GK インデックスの使用 . . . .
選択での GK インデックスの定義 . . . . . . . . . .
式での GK インデックスの定義 . . . . . . . . . . .
結合された表での GK インデックスの定義 . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
221
222
222
224
225
227
227
228
229
229
230
231
231
231
232
232
233
233
234
234
本章について
この章では、SQL を使用して、199 ページの『第 11 章 次元データ モデルの作成』で
説明した次元データ モデルを実装する方法について説明します。このデータベースは、
データ ウェアハウス環境を説明するための例を単に示すものです。例として示すため
に、説明は SQL 文に翻訳してあります。
この章では、Extended Parallel Server で利用できる、データベース sales_demo につい
て説明します。この章では、データ ウェアハウジングや大規模なデータベース アプリ
ケーションのニーズに適した Extended Parallel Server 特有の表のタイプとインデックス
についても説明します。
次元データベース sales_demo の実装
このセクションでは、第 11 章で説明したデータ モデルから次元データベースを作成す
るために使用できる SQL 文について説明します。対話型 SQL を使用して、データベ
ースを作成するための文を 1 つずつ記述できます。または、スクリプトを実行して、デ
ータベースの実装に必要なすべての文を自動的に実行できます。CREATE DATABASE
© Copyright IBM Corp. 1996, 2004
221
文と CREATE TABLE 文は、データベース内の表としてデータ モデルを作成します。
データベースを作成した後、LOAD 文と INSERT 文を使用して表を構築できます。
CREATE DATABASE の使用
データベース内に表やオブジェクトを作成するには、まずデータベースを作成する必要
があります。
Informix データベース サーバでデータベースを作成する場合、サーバは、データベース
が存在していることとデータベースのロギング モードを示すレコードを設定します。デ
ータベース サーバはディスク領域を直接管理するため、これらのレコードはオペレーテ
ィング システムのコマンドでは見ることができません。
Extended Parallel Server を使用してデータベースを作成すると、ログ機能は常にオンに
なります。ただし、データベースにログなし表を作成することもできます。詳しくは、
129 ページの『分散問合せを使用するためのデータベース サーバの構成』を参照してく
ださい。
次の文で、sales_demo というデータベースを作成するのに使用する構文を示します。
CREATE DATABASE sales_demo
CREATE TABLE 文を使用した次元表およびファクト表の作成
このセクションでは、次元データベース sales_demo の表を作成するために使用する
CREATE TABLE 文について説明します。
参照整合性は、もちろん、次元データベースにとって重要な要件です。しかし、次に示
すデータベース sales_demo のスキーマでは、ファクト表と次元表の間に存在する主キ
ーと外部キーの関係を定義していません。このスキーマでそのような主キーと外部キー
との関係を定義していない理由は、データをロードする際にデータベース サーバが制約
確認を実行しなければ、ロードのパフォーマンスが大幅に向上するためです。データ ウ
ェアハウス環境で特定の時間内に数十から数百 GB のデータをロードする必要が頻繁に
ある場合、データをロードするパフォーマンスは、データベースをウェアハウス環境に
実装する方法を決定するにあたって重要な要素になります。稼働中のデータ マートとし
てデータベース sales_demo が実装されていることを想定した場合、ファクト表と次元
表との間の参照整合性を保つために、データベース サーバではなくデータ抽出ツールが
使用されます。
ヒント: 表を作成してロードした後で、参照整合性を保つために、ALTER TABLE 文を
使用して主キー制約と外部キー制約を表に追加できます。この方法は、高速ロ
ード モードの場合にのみ必要です。制約とインデックスが必要で、ロードする
前に削除するのに手間がかかる場合には精細ロード モードが最適なオプション
です。
222
IBM Informix データベース設計および実装 ガイド
以下の文は、time、geography、product、および customer 表を作成します。これらの
表は、sales ファクト表に対する次元表です。シリアル (SERIAL) 型のフィールドは、
geography 表の district_code 列の主キーとして機能します。
CREATE TABLE
(
time_code
order_date
month_code
month_name
quarter_code
quarter_name
year INTEGER
);
time
INT,
DATE,
SMALLINT,
CHAR(10),
SMALLINT,
CHAR(10),
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)
);
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)
);
第 12 章 次元データベースの実装 (XPS)
223
ヒント: 最も便利なメジャー (ファクト) は加算的な数値です。データ ウェアハウス環
境では、データベースのサイズが非常に大きいため、ファクト表に対するほと
んどすべての問合せで、その答えを構築するために数千から数百万のレコード
が必要になります。そのようなレコードを圧縮するために使用できる唯一の方
法は、レコードを集約することです。sales 表では、メジャーの各列が数値デー
タ型で定義されているため、units_sold、revenue、cost、net_profit の各列から
答えを容易に作成できます。
ユーザの便宜のために、ファイル createdw.sql には、上記の CREATE TABLE 文がす
べて含まれています。
データ ソースからデータベースへのデータのマッピング
デモンストレーション データベース stores_demo は、データベース sales_demo の主
データ ソースです。
224 ページの表 14 は、データ ウェアハウスのビジネス用語とデータ ソースとの関係
を表しています。その表は、データベース sales_demo のそれぞれの列と表のデータ ソ
ースも表しています。
表 14. データ ウェアハウスのビジネス用語とデータ ソースの関係
ビジネス用語
Sales ファクト表
製品コード
顧客コード
地区コード
時間コード
収益
販売数量
コスト
純利益
Product 次元表
製品
製品名
製品ライン
製品ライン名
ベンダ
ベンダ名
Customer 次元表
顧客
顧客名
224
データ ソース
表.列名
stores_demo:items.total_price
stores_demo:items.quantity
costs.lst (per unit)
計算結果: 収益 - コスト
sales.product_code
sales.customer_code
sales.district_code
sales.time_code
sales.revenue
sales.units_sold
sales.cost
sales.net_profit
stores_demo:catalog.catalog_num
stores_demo:stock.manu_code および
stores_demo:stock.description
stores_demo:orders.stock_num
stores_demo:stock.description
stores_demo:orders.manu_code
stores_demo:manufact.manu_name
product.product_code
product.product_name
stores_demo:orders.customer_num
stores_demo:customer.fname +
stores_demo:customer.lname
customer.customer_code
customer.customer_name
IBM Informix データベース設計および実装 ガイド
product.product_line_code
product.product_line_name
product.vendor_code
product.vendor_name
表 14. データ ウェアハウスのビジネス用語とデータ ソースの関係 (続き)
ビジネス用語
データ ソース
表.列名
会社名
stores_demo:customer.company
customer.company_name
生成される
stores_demo:customer.city
stores_demo:customer.state
stores_demo.state.sname
導出される: If state = ″CA″ THEN
region = 1, ELSE region = 2
geography.district_code
geography.district_name
geography.state_code
geography.state_name
geography.region
Time 次元表
時間コード
注文日
月
生成される
stores_demo:orders.order_date
derived from order date generated
四半期
derived from order date generated
年
注文日から導出される
time.time_code
time.order_date
time.month_name
time.month.code
time.quarter_name
time.quarter_code
time.year
Geography 次元表
地区コード
地区
州
州名
地域
接尾辞 .unl を持ついくつかのファイルには、データベース sales_demo 内にロードされ
たデータが含まれています。データベースを作成してロードする SQL 文を含むファイ
ルには、接尾辞 .sql が付いています。
UNIX のみ
UNIX 上でデータベース サーバを実行している場合、*.sql および *.unl ファイルには
ディレクトリ $INFORMIXDIR/demo/dbaccess からアクセスできます。
UNIX のみ の終り
Windows のみ
Windows 上でデータベース サーバを実行している場合、*.sql および *.unl ファイルに
はディレクトリ %INFORMIXDIR%¥demo¥dbaccess からアクセスできます。
Windows のみ の終り
次元データベースへのデータのロード
次元 データベースを実装する場合に重要なことは、効果的なロード方法を立案して文章
化することです。このセクションでは、データベース sales_demo の表を構築するため
に使用できる LOAD 文と INSERT 文について説明します。
第 12 章 次元データベースの実装 (XPS)
225
ヒント: 稼働中のデータ ウェアハウジング環境では、通常、LOAD 文または INSERT
文を使用して Informix データベースとの大量のデータのロードを実行すること
はありません。
Informix データベース サーバには、データのロードとアンロードを行うさまざまなハイ
パフォーマンスな機能があります。
Extended Parallel Server を使用してデータベースを作成する場合は、外部表 を使用して
ハイパフォーマンスなロードとアンロードを実行できます。
ハイパフォーマンスなロードについては、「IBM Informix: Dynamic Server 管理者ガイ
ド」または「IBM Informix: ハイ パフォーマンス ローダ ユーザーズ ガイド」を参照し
てください。
次の文は、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,
s.stock_num, s.description
FROM stores_demo:catalog a, stores_demo:manufact m,
226
IBM Informix データベース設計および実装 ガイド
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 を実装する方法について
は、「IBM Informix: DB-Access ユーザーズ ガイド」を参照してください。
次元データベースのテスト
SQL 問合せを作成すると、ビジネス プロセスのサマリにリストされる標準レポートに
必要なデータを抽出できます (209 ページの『ビジネス プロセスの要約』を参照)。以
下のアドホック問合せを使用して、次元データベースが適切に実装されていることをテ
ストします。
次の文は、各ベンダの製品ラインごとに、毎月の収益、コスト、および純利益の値を戻
します。
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
第 12 章 次元データベースの実装 (XPS)
227
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
Extended Parallel Server のログ付き表とログなし表
本セクションでは、さまざまな表タイプについて説明します。これらの表は、データ ウ
ェアハウジング環境で使用すると特に便利です。Dynamic Server が表のログを記録する
のと同様に、デフォルトで Extended Parallel Server は表のログを記録します。しかし、
大量のデータがある一方で挿入、更新、削除がほとんどないデータ ウェアハウス環境や
アプリケーションでは、同一のデータベース内にログ付き表とログなし表との組合せが
必要なことが多くあります。多くの場合、一時表は、データベース セッションが終了す
ると持続しないため不適切です。ログ付き表とログなし表の両方の必要条件を満たすた
めに、Extended Parallel Server では次のタイプの永続表と一時表をサポートしていま
す。
v ロウ永続表 (ログなし)
v 静的永続表 (ログなし)
v オペレーショナル永続表 (ログ付き)
v 標準永続表 (ログ付き)
228
IBM Informix データベース設計および実装 ガイド
v スクラッチ一時表 (ログなし)
v Temp 一時表 (ログ付き)
表のタイプを指定せずに CREATE TABLE 文を発行すると、標準永続表が作成されま
す。表タイプを変更するには、ALTER TABLE 文を使用します。構文について詳しく
は、「IBM Informix: SQL ガイド: 構文」を参照してください。
重要: コサーバが一時領域として使用およびアクセスできるのは、そのコサーバが所有
する DB 領域のみです。一時表では永続表と同様に DB 領域内を明示的にフラ
グメント化できますが、コサーバは、そのコサーバ自体が管理するフラグメント
内にのみデータを挿入できます。
表タイプの選択
データ ウェアハウス環境の個々の表では、要求される条件がそれぞれ異なることが多く
あります。以下の質問に答えていくと、使用する適切な表のタイプを決定しやすくなり
ます。
v 表にインデックスは必要ですか?
v 表に定義する必要のある制約は?
v 表のリフレッシュまたは更新の周期は?
v 表は読取り専用表ですか?
v 表のログを記録する必要はありますか?
表 15 では、Extended Parallel Server がサポートする 6 つの表の属性を一覧表示してお
り、外部表を使用してこれらのタイプの表にデータをロードする方法を示しています。
この表の情報を使用して、使用する表に固有の必要条件に一致する表のタイプを選択し
てください。
表 15. Extended Parallel Server の表のタイプの特性
タイプ
永続性
ログ付き
インデックス
簡単な
ロール
追加の使用
バック可能
アーカイブ
復旧可能
外部表ロード
からの復元
スクラッチ
なし
なし
なし
あり
なし
なし
なし
Temp
なし
あり
あり
あり
あり
なし
なし
ロウ
あり
なし
なし
あり
なし
なし
なし
モード
高速または精細
ロード モード
高速または精細
ロード モード
高速または精細
ロード モード
静的
あり
なし
あり
なし
なし
なし
なし
なし
オペレーショナル
あり
あり
あり
あり
あり
あり
なし
高速または精細
ロード モード
標準
あり
あり
あり
なし
あり
あり
あり
精細ロード モード
スクラッチ一時表と Temp 一時表
スクラッチ表とは、インデックス、制約、ロールバック機能のいずれもサポートしてい
ないログなし一時表です。
第 12 章 次元データベースの実装 (XPS)
229
Temp 表は、ライト アペンドのようなバルク操作もサポートするログ付き一時表です。
高速モードのロードでは、バッファ キャッシュをバイパスするライト アペンド を使用
します。ライト アペンドでは、バッファ管理に関連するオーバーヘッドはなくなります
が、データのログは記録しません)。Temp 表は、インデックス、制約、およびロールバ
ック機能をサポートしています。
ヒント: SELECT...INTO TEMP および SELECT...INTO SCRATCH 文は、通常の挿入と
同様に、複数のコサーバ上で並列になります。 SELECT...INTO TEMP 文と
SELECT...INTO SCRATCH 文により、複数のノードにフラグメント一時表が明
示的に作成された場合、Extended Parallel Server はそれらのフラグメント一時
表を自動的にサポートします。
Extended Parallel Server は、以下の基準に従って明示的な一時表を作成します。
v Temp 表またはスクラッチ表を構築するために使用する問合せによって行が生成され
ない場合、データベース サーバはフラグメント化されていない空の表を作成しま
す。
v 問合せによって生成される行が 8KB を超えない場合、一時表は 1 つの DB 領域内
に常駐します。
v そのような行が 8KB を超える場合、Extended Parallel Server は複数のフラグメント
を作成し、ラウンドロビン フラグメント化スキーマを使用してそれらのフラグメン
トを構築します。
ロウ永続表
ロウ表は、ライト アペンドを使用するログなし永続表です。高速モードのロードでは、
バッファ キャッシュをバイパスするライト アペンド を使用します。ロウ表には、高速
モードでデータをロードできます。高速モードのロードについては、「IBM Informix:
Dynamic Server 管理者の参照」を参照してください。
ロウ表は、更新、挿入、削除をサポートしますが、それらのログは記録しません。ロウ
表は、インデックス、参照制約、ロールバック機能、回復機能、アーカイブからの復元
機能のいずれもサポートしていません。
最初のデータのロードとスクラビングにロウ表を使用します。それらの手順を完了した
ら、より高いレベルに表を変更します。例えば、ロウ表にロードしているときにエラー
か障害が発生すると、その結果のデータは、障害が発生した時点にディスク上にあった
データになります。
データ ウェアハウス環境では、以下の両方の条件に当てはまる場合、ファクト表をロウ
表として作成できます。
v 機構によっては制約やインデックスが必要なことがあるが、そのような制約もインデ
ックスもファクト表で指定する必要がない。
230
IBM Informix データベース設計および実装 ガイド
v ファクト表を作成することにもファクト表にデータをロードすることにもコストがか
からない。ファクト表は、意思決定支援のために便利ですが必須ではない。データが
損失したら、容易にデータを表に再ロードできる。
静的永続表
静的表は、ログなしの読取り専用永続表で、挿入、更新、削除のいずれの操作もサポー
トしていません。挿入、更新、削除のいずれの操作も表で実行しない場合は、静的表と
して表を作成できます。静的表では、非クラスタ インデックスや参照制約を作成したり
ドロップしたりできます。なぜなら、そのような操作は、データに影響を与えないため
です。
静的表では、ロールバック機能、回復機能、アーカイブからの復元機能のいずれもサポ
ートしていません。静的表の利点は、読み取り専用であるために、問合せの実行時にデ
ータベース サーバが簡単な走査を使用できることと、サーバがロックするのを防げるこ
とです。
ヒント: GK インデックスを使用する表を作成する場合、静的表は重要です。これは、
静的表が GK インデックスをサポートする唯一の表タイプであるためです。
オペレーショナル永続表
オペレーショナル表は、ログ付き永続表で、ライト アペンドを使用しますがレコード単
位のログは記録しません。オペレーショナル表では、高速更新の操作を実行できます。
オペレーショナル表では、操作をロールバックしたり、障害から回復したりできます
が、ロードされる大量の挿入レコードはログに記録されないため、ログのアーカイブか
ら確実に復元することはできません。オペレーショナル表を使用するのは、他のソース
からデータを導出するために、復元機能は重要でない場合で、ロールバック機能も回復
機能も必要ない場合です。
周期的にデータがリフレッシュされるため、ファクト表をオペレーショナル表として作
成できます。オペレーショナル表では、インデックスも制約もない場合に高速ロード モ
ードをサポートし、データは回復可能です。
標準永続表
Extended Parallel Server の標準表は、Dynamic Server で作成するログ付きデータベース
の表と同じです。すべての操作はレコード単位でログに記録されるため、標準表はアー
カイブから復元できます。標準表は、回復機能とロールバック機能をサポートしていま
す。
表の更新とリフレッシュの周期が頻繁でない場合、標準表で表を作成できます。リフレ
ッシュ周期の間に制約とインデックスを削除する必要がないためです。インデックス
は、作成に時間と手間がかかりますが必要です。
第 12 章 次元データベースの実装 (XPS)
231
ヒント: 標準表ではライト アペンドを使用しないため、外部表を使用してロードを実行
する場合には高速ロード モードを使用できません。
表のタイプの切替え
ALTER TABLE コマンドを使用して、永続表のタイプを切り替えます。変更する表が、
新しい表のタイプの制限事項を満たしていない場合、変更は失敗し、説明のエラー メッ
セージが表示されます。表の変更には、次の制限事項が適用されます。
v 表のタイプを RAW に変更する前に、インデックスと参照制約を削除する必要があり
ます。
v 変更した表が完全回復機能の制限事項に適合するよう、表タイプを STANDARD タイ
プに変更する前にレベル 0 のアーカイブを実行する必要があります。
v Temp 一時表やスクラッチ一時表は変更できません。
データ ウェアハウス環境のインデックス
従来の B-tree ツリー インデックスに加えて、Extended Parallel Server は次のようなイ
ンデックスを提供します。これらのインデックスを使用すると、データ ウェアハウス環
境でのアドホック問合せのパフォーマンスを向上できます。
v ビットマップ インデックス
ビットマップ インデックスは、B ツリー インデックスの特別なバリエーションで
す。ビットマップ インデックスは、既婚と未婚の別、または性別など、タイプが少
ない値のうちの 1 つを含む列のインデックスを作成する場合に使用できます。値の
重複が多いため、ビットマップ インデックスは、列が含む値ごとに圧縮したビット
マップを格納します。ビットマップ インデックスを使用すると、同じキーを含む行
間の距離が減少するため格納効率が向上します。
次の両方の条件に当てはまる場合にビットマップ インデックスを使用できます。
– インデックス内のキー値に、多くの重複があります。
– 表走査のパフォーマンスを向上するためにオプティマイザが使用できるインデック
スが、表内の複数の列に付いています。
v 一般化キー (GK) インデックス
GK インデックスを使用すると、式の結果、データ セットの選択、または結合された
表からのデータ セットの積を、B-tree ツリー インデックスまたはビットマップ イ
ンデックス内のキーとして格納できます。これは、1 つ以上の大規模表での特定の問
合せに便利です。
GK インデックスを作成する場合は、そこに含まれるすべての表は静的表でなければ
なりません。
232
IBM Informix データベース設計および実装 ガイド
また、インデックス機能の効率を向上させるために、Extended Parallel Server は次の機
能をサポートしています。
v 同一の表アクセスに使用できるように複数のインデックスを自動的に結合します。
複数列インデックスを単一列インデックスと結合できます。
v スキップ走査というアクセス方法で表を読み取ります。
表の行を走査する場合、データベース サーバはインデックスが示す行のみを読み取
ります。その場合、行がデータベース内にある順序で行を読み取ります。スキップ走
査 アクセス方法では、1 つのページが 2 回読み取られることはありません。各ペー
ジは、ランダムにではなく順番に読み取られるため、入出力リソースの要件は減少し
ます。スキップ走査では、インデックス列でのフィルタ処理が不要になるため、CPU
要件も減少します。
v ハッシュ半結合を使用して、複数表結合を処理する作業を減らします。
ハッシュ半結合は、1 つの大きい (ファクト) 表が多くの小さい (次元) 表に結合され
るスター スキーマに対する問合せなどで特に便利です。ハッシュ半結合では、結合
を開始する前に、効率的に行の数をできる限り減らすことができます。
データベースに対して実行する問合せのタイプを解析することは、作成するインデック
スのタイプを決めるためにも役立ちます。問合せのパフォーマンスを向上させるために
使用できるインデックスおよびインデックス作成方法については、「IBM Informix:
Dynamic Server パフォーマンス ガイド」を参照してください。
データ ウェアハウス環境での 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 を使用できます。デー
第 12 章 次元データベースの実装 (XPS)
233
タベース サーバで、州 = "CA" の場合に state_idx インデックスを使用して geography
表から行を抽出すると、問合せ全体のパフォーマンスが向上します。
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 インデックスを作成します。このインデックスを使
用すると、販売した製品のコストを含む sales 表に対する問合せのパフォーマンスを向
上できます。
CREATE GK INDEX cost_idx ON sales
(SELECT units_sold * cost FROM sales);
データベース サーバは、製品の購入に $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;
234
IBM Informix データベース設計および実装 ガイド
第 5 部 付録
© Copyright IBM Corp. 1996, 2004
235
236
IBM Informix データベース設計および実装 ガイド
付録. アクセシビリティ
このマニュアルの HTML バージョンの構文ダイアグラムは、小数点付き 10 進数構文
フォーマットに従っています。このフォーマットは、スクリーン リーダ (読上げソフト
ウェア) を使用している場合に限り利用できるフォーマットです。
小数点付き 10 進数構文ダイアグラム
小数点付き 10 進数フォーマットでは、構文要素はそれぞれ別の行に書き込まれます。2
つ以上の構文要素が、まとめて使用される (またはどちらも使用されない) 場合、単一
の複合構文要素と見なすことができるため、それらの要素が同じ行に表示される場合が
あります。
各行は小数点付き 10 進数値で開始されます。例えば、3、3.1 または 3.1.1 などで
す。これらの数字を正確に聞き取るために、必ずスクリーン リーダ (読上げソフトウェ
ア) が句読点を読み取るように設定してください。同じ小数点付き 10 進数値を持つす
べての構文要素 (例えば、数値 3.1 を含むすべての構文要素) は相互に排他的な選択肢
です。行 3.1 USERID および行 3.1 SYSTEMID を聞き取った場合、構文に USERID また
は SYSTEMID のいずれかを記述できますが、両方を組み込むことはできません。
小数点付き 10 進数の番号付けレベルにより、ネストのレベルが示されます。例えば、
小数点付き 10 進数値 3 の構文要素の後に、小数点付き 10 進数値 3.1 の構文要素が
続く場合、3.1 と番号付けされている構文要素はすべて、3 と番号付けされている構文
要素に従属します。
構文要素についての情報を追加するために、小数点付き 10 進数値の横に特定の単語お
よび記号が付加されます。場合により、これらの単語および記号が要素の先頭で使用さ
れることがあります。識別を容易にするため、該当する単語または記号が構文要素の一
部である場合には、その単語または記号の前に円記号 (¥) を付加します。* 記号を小数
点付き 10 進数値の横に付加して、その構文要素が反復することを示すことができま
す。例えば、小数点付き 10 進数値 3 の構文要素 *FILE は、読取り時に 3 ¥* FILE と
示されます。フォーマット 3* FILE は、構文要素 FILE が反復することを示します。フ
ォーマット 3* ¥* FILE は、構文要素 * FILE が反復することを示します。
構文要素文字列の分離に使用されるコンマなどの文字は、構文では分離する項目の直前
に表示されます。これらの文字は、各項目と同じ行に表示される場合と、関連項目と同
じ小数点付き 10 進数値を持つ別の行に表示される場合があります。行には構文要素に
ついての情報を提供する別の記号も表示される場合があります。例えば、5.1*、5.1
LASTRUN、5.1 DELETE などの行は、LASTRUN および DELETE 構文要素を複数使用する場
© Copyright IBM Corp. 1996, 2004
237
合に、これらの要素をコンマで分離する必要があることを意味します。分離文字を指定
しない場合、各構文要素の分離には空白が使用されるものと想定します。
構文要素の前に % 記号がある場合、別の場所で定義されている参照を示します。% 記号
に続く文字列はリテラルではなく、構文フラグメントの名前です。例えば、行 2.1 %OP1
は、別の構文フラグメント OP1 を参照する必要があることを意味します。
小数点付き 10 進数値の横に次の単語および記号が付加されます。
238
?
オプションの構文要素を指定します。後ろに ? 記号が続く小数点付き 10 進数
値は、対応する小数点付き 10 進数値の構文要素すべて、およびそれに従属す
る構文要素がオプションであることを示します。ある小数点付き 10 進数値に
構文要素が 1 つのみ含まれる場合、? 記号はその構文要素と同じ行に表示され
ます (例えば、5? NOTIFY)。ある小数点付き 10 進数値に構文要素が複数含ま
れる場合、? 記号は行に単独で表示され、以下オプションの構文要素が続きま
す。例えば、5 ?、5 NOTIFY、5 UPDATE などの行を聞き取った場合、構文要素
NOTIFY と UPDATE がオプションであることが分かります。つまり、それらをい
ずれも選択しないか、1 つのみ選択します。? 記号は、レールロード構文ダイ
アグラムでのバイパス線に相当します。
!
デフォルトの構文要素を指定します。小数点付き 10 進数値とそれに続く ! 記
号および構文要素は、同じ小数点付き 10 進数値を共用するすべての構文要素
に対し、構文要素がデフォルト オプションであることを示します。同じ小数点
付き 10 進数値を共用する構文要素のうちの 1 つのみで ! 記号を指定できま
す。例えば、2? FILE、2.1! (KEEP)、2.1 (DELETE) などの行を聞き取った場合
は、(KEEP) が FILE キーワードに対するデフォルト オプションであることが
分かります。この例では、オプションを指定せずに FILE キーワードを組み込
んだ場合、デフォルト オプション KEEP が適用されます。デフォルト オプシ
ョンは 1 レベル上の小数点付き 10 進数値にも適用します。この例では、FILE
キーワードが省略されるとデフォルトの FILE(KEEP) が使用されます。しか
し、2? FILE、2.1、2.1.1! (KEEP)、および 2.1.1 (DELETE) などの行を聞き取
った場合は、デフォルト オプション KEEP は 1 レベル上の小数点付き 10 進
数値 2.1 (関連キーワードなし) のみに適用し、2? FILE には適用しません。
キーワード FILE が省略されると、いずれも使用されません。
*
ゼロ回以上の反復が可能な構文要素を指定します。後ろに * 記号が続く小数点
付き 10 進数値は、この構文要素をゼロ回以上使用できることを示します。つ
まり、これはオプションであり、かつ反復可能です。例えば、行 5.1*
data-area を聞き取った場合、複数の data-area を記述するか、または 1 つも
記述しないことが可能であると分かります。 3*、3 HOST、3 STATE などの行を
聞き取った場合は、HOST、STATE 両方を記述するか、またはいずれも記述しな
いことが可能であると分かります。
IBM Informix データベース設計および実装 ガイド
注:
1. 小数点付き 10 進数値の横にアスタリスク (*) があり、その小数点付き 10
進数値が指定された項目が 1 つのみである場合は、その同じ項目を複数回
反復できます。
2. 小数点付き 10 進数値の横にアスタリスクがあり、その小数点付き 10 進数
値がいくつかの項目で指定されている場合は、そのリストから複数の項目を
使用できますが、各項目を複数回使用することはできません。前の例では、
HOST STATE と記述することはできますが、HOST HOST とは記述できませ
ん。
3. * 記号は、レールロード構文ダイアグラムでのループバック線に相当しま
す。
+
1 回以上組み込む必要がある構文要素を指定します。後ろに + 記号が続く小
数点付き 10 進数値は、この構文要素を 1 回以上組み込む必要があることを示
します。例えば、行 6.1+ data-area を聞き取った場合、少なくとも 1 つの
data-area を記述する必要があります。 2+、2 HOST、2 STATE などの行を聞き
取った場合、HOST または STATE、もしくはその両方を記述する必要があると分
かります。 * 記号の場合と同様、その小数点付き 10 進数値が指定された唯一
の項目である場合に限り、特定の項目を反復できます。+ 記号は、* 記号と同
様に、レールロード構文ダイアグラムでのループバック線に相当します。
付録. アクセシビリティ
239
240
IBM Informix データベース設計および実装 ガイド
特記事項
本書に記載の製品、サービス、または機能が日本においては提供されていない場合があ
ります。日本で利用可能な製品、サービス、および機能については、日本 IBM の営業
担当員にお尋ねください。本書で IBM 製品、プログラム、またはサービスに言及して
いても、その IBM 製品、プログラム、またはサービスのみが使用可能であることを意
味するものではありません。これらに代えて、IBM の知的所有権を侵害することのな
い、機能的に同等の製品、プログラム、またはサービスを使用することができます。た
だし、IBM 以外の製品とプログラムの操作またはサービスの評価および検証は、お客様
の責任で行っていただきます。
IBM は、本書に記載されている内容に関して特許権 (特許出願中のものを含む) を保有
している場合があります。本書の提供は、お客様にこれらの特許権について実施権を許
諾することを意味するものではありません。実施権についてのお問い合わせは、書面に
て下記宛先にお送りください。
〒106-0032
東京都港区六本木 3-2-31
IBM World Trade Asia Corporation
Licensing
以下の保証は、国または地域の法律に沿わない場合は、適用されません。IBM およびそ
の直接または間接の子会社は、本書を特定物として現存するままの状態で提供し、商品
性の保証、特定目的適合性の保証および法律上の瑕疵担保責任を含むすべての明示もし
くは黙示の保証責任を負わないものとします。国または地域によっては、法律の強行規
定により、保証責任の制限が禁じられる場合、強行規定の制限を受けるものとします。
この情報には、技術的に不適切な記述や誤植を含む場合があります。本書は定期的に見
直され、必要な変更は本書の次版に組み込まれます。IBM は予告なしに、随時、この文
書に記載されている製品またはプログラムに対して、改良または変更を行うことがあり
ます。
本書において IBM 以外の Web サイトに言及している場合がありますが、便宜のため
記載しただけであり、決してそれらの Web サイトを推奨するものではありません。そ
れらの Web サイトにある資料は、この IBM 製品の資料の一部ではありません。それ
らの Web サイトは、お客様の責任でご使用ください。
IBM は、お客様が提供するいかなる情報も、お客様に対してなんら義務も負うことのな
い、自ら適切と信ずる方法で、使用もしくは配布することができるものとします。
© Copyright IBM Corp. 1996, 2004
241
本プログラムのライセンス保持者で、(i) 独自に作成したプログラムとその他のプログラ
ム (本プログラムを含む) との間での情報交換、および (ii) 交換された情報の相互利用
を可能にすることを目的として、本プログラムに関する情報を必要とする方は、下記に
連絡してください。
IBM Corporation
J46A/G4
555 Bailey Avenue
San Jose, CA 95141-1003
U.S.A.
本プログラムに関する上記の情報は、適切な使用条件の下で使用することができます
が、有償の場合もあります。
本書で説明されているライセンス・プログラムまたはその他のライセンス資料は、IBM
所定のプログラム契約の契約条項、IBM プログラムのご使用条件、またはそれと同等の
条項に基づいて、IBM より提供されます。
この文書に含まれるいかなるパフォーマンス・データも、管理環境下で決定されたもの
です。そのため、他の操作環境で得られた結果は、異なる可能性があります。一部の測
定が、開発レベルのシステムで行われた可能性がありますが、その測定値が、一般に利
用可能なシステムのものと同じである保証はありません。さらに、一部の測定値が、推
定値である可能性があります。実際の結果は、異なる可能性があります。お客様は、お
客様の特定の環境に適したデータを確かめる必要があります。
IBM 以外の製品に関する情報は、その製品の供給者、出版物、もしくはその他の公に利
用可能なソースから入手したものです。IBM は、それらの製品のテストは行っておりま
せん。したがって、他社製品に関する実行性、互換性、またはその他の要求については
確証できません。IBM 以外の製品の性能に関する質問は、それらの製品の供給者にお願
いします。
IBM の将来の方向または意向に関する記述については、予告なしに変更または撤回され
る場合があり、単に目標を示しているものです。
表示されている IBM の価格は IBM が小売り価格として提示しているもので、現行価
格であり、通知なしに変更されるものです。卸価格は、異なる場合があります。
本書には、日常の業務処理で用いられるデータや報告書の例が含まれています。より具
体性を与えるために、それらの例には、個人、企業、ブランド、あるいは製品などの名
前が含まれている場合があります。これらの名称はすべて架空のものであり、名称や住
所が類似する企業が実在しているとしても、それは偶然にすぎません。
著作権使用許諾:
本書には、様々なオペレーティング・プラットフォームでのプログラミング手法を例示
するサンプル・アプリケーション・プログラムがソース言語で掲載されています。お客
242
IBM Informix データベース設計および実装 ガイド
様は、サンプル・プログラムが書かれているオペレーティング・プラットフォームのア
プリケーション・プログラミング・インターフェースに準拠したアプリケーション・プ
ログラムの開発、使用、販売、配布を目的として、いかなる形式においても、IBM に対
価を支払うことなくこれを複製し、改変し、配布することができます。このサンプル・
プログラムは、あらゆる条件下における完全なテストを経ていません。従って IBM
は、これらのサンプル・プログラムについて信頼性、利便性もしくは機能性があること
をほのめかしたり、保証することはできません。お客様は、IBM のアプリケーション・
プログラミング・インターフェースに準拠したアプリケーション・プログラムの開発、
使用、販売、配布を目的として、いかなる形式においても、IBM に対価を支払うことな
くこれを複製し、改変し、配布することができます。
それぞれの複製物、サンプル・プログラムのいかなる部分、またはすべての派生的創作
物にも、次のように、著作権表示を入れていただく必要があります。
© (お客様の会社名) (西暦年). このコードの一部は、IBM Corp. のサンプル・プログ
ラムから取られています。© Copyright IBM Corp. (年を入れる).All rights reserved.
この情報をソフトコピーでご覧になっている場合は、写真やカラーの図表は表示されな
い場合があります。
特記事項
243
商標
AIX; DB2; DB2 Universal Database; Distributed Relational Database Architecture;
NUMA-Q; OS/2、OS/390、および OS/400; IBM Informix®; C-ISAM®; Foundation.2000™;
IBM Informix ® 4GL; IBM Informix®DataBlade®Module; Client SDK™; Cloudscape™;
Cloudsync™; IBM Informix®Connect; IBM Informix®Driver for JDBC; Dynamic Connect™;
IBM Informix®Dynamic Scalable Architecture™(DSA); IBM Informix®Dynamic Server™;
IBM Informix®Enterprise Gateway Manager (Enterprise Gateway Manager); IBM
Informix®Extended Parallel Server™; i.Financial Services™; J/Foundation™; MaxConnect™;
Object Translator™; Red Brick™; IBM Informix® SE; IBM Informix® SQL;
InformiXML™; RedBack®; SystemBuilder™; U2™; UniData®; UniVerse®; wintegrate® は、
IBM Corporation の商標です。
Java およびすべての Java 関連の商標およびロゴは、Sun Microsystems, Inc. の米国およ
びその他の国における商標または登録商標です。
Windows、Windows NT および Excel は、Microsoft Corporation の米国およびその他の
国における商標です。
UNIX は、The Open Group の米国およびその他の国における登録商標です。
本書で言及しているその他の会社名、製品名およびサービス名はそれぞれ各社の商標ま
たは登録商標です。
244
IBM Informix データベース設計および実装 ガイド
索引
日本語, 数字, 英字, 特殊文字の順に配列されてい
ます。なお, 濁音と半濁音は清音と同等に扱われ
ています。
［ア行］
アーカイブ、およびフラグメント化
アクセシビリティ xxi
79
構文ダイアグラム、スクリーン リーダ (読上げソフ
トウェア) による読取り 237
小数点付き 10 進数フォーマットの構文ダイアグラ
ム 237
アクセス権 102
インデックス 104
型付き表 104
言語 108
システム カタログ内の符号化
実行 108
自動化
一般化キー インデックス (続き)
定義
結合された表での
式での 234
選択での
意味整合性 40
入れ子
行 (ROW) 型
233
159
コレクション (COLLECTION) 型
インストール ガイド xviii
インデックス
一般化キー 232, 233
双方向トラバース 67
データ ウェアハウジング環境
名前付き行型の制限
103
108, 109
データベース レベル 100
データベース管理者 101
ビューでの 124
ビューと 124
ビューの作成に必要な 124
表レベル 102
付与 99
ユーザと public 101
ルーチン レベル 108
列レベル 105
ANSI 対非 ANSI 6
Connect 100
Delete 102, 124
Insert 102, 124
Resource 101
Select 102, 105, 124
Update 102, 124
暗号化されたデータ 98
一時表 229
一般化キー インデックス
所有権 102
データ ウェアハウス 233
© Copyright IBM Corp. 1996, 2004
234
152
232
155
ビットマップ、説明 232
CREATE INDEX 文 67
エラー メッセージ xx
エンティティ
オカレンス
住所録の例
24
16
選択の基準 16
属性 23
定義 13
表で表す 29
オペレーショナル表 231
オンライン トランザクション処理 (OLTP)
オンライン ノート xviii, xix
オンライン ヘルプ xxi
オンライン マニュアル xxi
オンライン分析型処理 (OLAP) 201
201
［カ行］
カーソルの動作
ANSI 対非 ANSI 8
階層
参照： 行 (ROW) 型
参照： 継承
参照： 表階層
外部キー 30
245
外部表、データのロード
行 (ROW) 型の削除
作成
関係における必須のエンティティ
72, 79
型階層
オーバーロード ルーチン
関係モデル
関係の解決
164
説明
168
外部 30
主 29
148
型代用性 167
型付き表
型なし表からの作成
複合 30
キー列 29
157
キーワード
構文ダイアグラム内
規格準拠
定義 156
参照： フラグメント表
型なし表
型付き表への変換
定義 156
過渡的依存性 37
可変長文字 (CHARACTER VARYING) 型
可変長文字 (VARCHAR) 型 54
規則
構文記法
xiii
構文ダイアグラム xiii
コマンド行 xv
サンプル コード xvii
54
可用性、フラグメント化による向上 79
環境、米国英語 (U.S. English) 以外 9
環境変数 xii
表記 xii
表記上 xii
キャスト
暗黙的、定義
102
USETABLENAME 68
関係
エンティティ 14
オプション 17
再帰的 34
冗長 34
接続性 17, 19
属性 23
存在の依存性 17
多重度 21
多重度の制約 17
多対多 17, 19
多対多、解決 32
データ モデルでの定義 16
必須 17
複雑な 33
マトリックスを使用して発見 18
1 対 1 17, 19
1 対多 17, 19
関係におけるオプションのエンティティ
関係における接続性 17, 19
xvi
業界標準 xxv
記述子列 29
157
各国語可変長文字 (NVARCHAR) 型 54
各国語文字 (NCHAR) 型 53
246
27
キー
164
型コンストラクタ
NODEFDAC
32
12
表、行、および列の定義のルール
関数的依存関係 36
164
説明 164
型継承、説明
17
180
演算子 180
起動 181
行 (ROW) 型 182
組込み 180
コレクション (COLLECTION) 型 186
コレクション (COLLECTION) 型の要素 188
削除 191
説明 180
ディスティンクト (DISTINCT) 型 181, 189
名前付き行型 181, 185
名前なし行型フィールド 185
明示的、定義 180
ユーザ定義 180, 192
CAST AS キーワード 180
行
17
IBM Informix データベース設計および実装 ガイド
関係モデルにおける
定義 27
行 ID 89
行 (ROW) 型
入れ子にした 159
カテゴリ 148
27
［サ行］
行 (ROW) 型 (続き)
キャスト 182, 186
業界標準、準拠 xxv
均一分散
再帰的関係
83
金額 (MONEY) 型
説明 48
表示フォーマット
継承
30
参照制約
データ型に関する考慮事項
49
104
237
時間隔 (INTERVAL) 型
単一 163
表階層 169
結合、修正可能なビューでの制限
説明 51
表示フォーマット 52
式、キャストで使用できる
121
任意規則
82
範囲規則を使用した
次元データ モデル
作成 208
xvii
コード例の表記規則 xvii
広域言語サポート (GLS) x
構文セグメント xvi
82
次元 206
次元表 207
次元要素 206
構文ダイアグラム
キーワード xvi
スクリーン リーダ (読上げソフトウェア)での読取り
237
の規則 xiii
変数 xvii
固定小数点 48
コマンド スクリプト、データベースの作成
コマンド行の表記規則
サンプル ダイアグラム xv
読み方 xv
コレクション (COLLECTION) 型
暗黙的キャスト 187
入れ子にした 152
型コンストラクタ 148
型チェック 186
キャスト 186
キャストの制限 187
異なる要素型 187
制限 153
明示的キャスト 188
要素型 148
180
式ベース分散スキーム
使用 81
説明 80
108
コード セット
デフォルト 9
コード、サンプル、の規則
60
視覚障害
構文ダイアグラムの読取り
163
階層構造内のアクセス権
型 164
型代用性 167
言語アクセス権
19, 34
細分性、ファクト表 205
参照整合性、主キーと外部キーの定義
69
実装する
小次元表
221
217
ファクト表 205
メジャー (基準)、定義 205
次元データベース、sales_demo 222
次元表
説明 207
属性の選択 216
システム カタログ表
アクセス権 103
syscolauth 103
sysfragexprudrdep 78
sysfragments 78
systabauth 103
sysusers 103
システム定義ハッシュ分散スキーム
使用 84
説明 81
システム要件
ソフトウェア x
データベース x
事前定義型 142
実数 (FLOAT) 型 46
索引
247
スマート ラージ オブジェクト (続き)
実体 - 関係ダイアグラム
説明 24
読取り 25
SB 領域の記憶域 146
SQL での対話型使用 146
シノニム
連鎖
SQL の制限
ANSI 標準準拠データベースで
シノニムの連鎖 69
146
正規化
69
第 1 正規形 35
第 2 正規形 36
8
集計関数、修正可能なビューでの制限
第 3 正規形
121
修正された問題と既知の問題についてのファイル
主キー
システム割当て 30
xix
37
データ モデルの
利点 34
ルール 35, 37
定義 29
複合 30
上位型 163
正規形 35
整数 (INTEGER) 型
静的表 231
上位表
制約
163
小桁実数 (SMALLFLOAT) 型 46
小桁整数 (SMALLINT) 型 44
小次元表、説明 217
小数点付き 10 進数フォーマットの構文ダイアグラム
237
冗長な関係 34
34
44
多重度 17
ドメインの定義 40
名前付き行型の制限
155
セキュリティ
アクセスの制限 117, 118, 124
オペレーティング システム機能の使用
所有権 102
所有者名の指定
挿入された値の制約 117, 122
データベース レベル アクセス権
ANSI 対非 ANSI 6
シリアル (SERIAL) 型
データベースをアクセス不能にする
表レベル アクセス権 105
開始点のリセット 104
参照制約 60
主キーとしての 29
初期化 45
制限 144, 153, 155, 160
説明 44
表階層 174
身体障害、視覚
構文ダイアグラムの読取り 237
スクラッチ表 229
スクリーン リーダ (読上げソフトウェア)
構文ダイアグラムの読取り 237
スター結合スキーマ
説明 204
参照： 次元データ モデル
すべてのマニュアルのマニュアル セット xxii
スマート ラージ オブジェクト
インポートとエクスポート 147
コピー用関数 147
説明 145
フラグメント化 89
248
IBM Informix データベース設計および実装 ガイド
ユーザ定義ルーチンを使用しての
操作データ ストア 200
属性
識別 22
重要な特質 23
分割不可能 23
ソフトウェア要件 x
存在の依存性 17
［タ行］
第 1 正規形 35
第 2 正規形 36
第 3 正規形 37
代用性 167
多重度
関係における 21
制約 17
多対多の関係 17, 19, 32
単一継承 163
99
99
98
98
データ型 (続き)
データ
外部表を使用したロード 72
dbload ユーティリティを使用したロード
72
文字 (CHAR) 型 53
10 進数 (DECIMAL) 型
47, 48
データ ウェアハウジング モデル
参照： 次元データ モデル
8 バイト シリアル (SERIAL8) 型
データ ウェアハウス、説明
データ マート、説明 200
ALTER TABLE 文を使用した変更
BLOB 145
200
データ モデル
CLOB 型
エンティティの関係
関係型 12
関係の定義 17
作成
13
次元 204, 208
住所録の例 14
説明 12
58
145
データのロード
外部表 72
dbload ユーティリティ
72
121
デモンストレーション
属性 22
多対多の関係 19
1 対 1 の関係 19
sales_demo 210, 222
superstores_demo 140
命名 62
19
データ型
各国語可変長文字 (NVARCHAR) 型 54
各国語文字 (NCHAR) 型 53
可変長文字 (CHARACTER VARYING) 型 54
可変長文字 (VARCHAR) 型 54
行 (ROW) 型 148
金額 (MONEY) 型
固定小数点 48
44
44
データベース
外部データベースでのビュー
新規表へのデータの追加 70
26
1 対多の関係
8 バイト整数 (INT8) 型
48
コレクション (COLLECTION) 型 148
参照制約 60
時間隔 (INTERVAL) 型 51
小桁実数 (REAL) 型 46
小桁実数 (SMALLFLOAT) 型 46
シリアル (SERIAL) 型 44
シリアル (SERIAL) 型、表階層 174
スマート ラージ オブジェクト 145
整数 (INTEGER) 型 44
選択 40
ディスティンクト (DISTINCT) 型 144
テキスト (TEXT) 型 56
日時 (DATETIME) 型 50
バイト (BYTE) 型 57
日付 (DATE) 型 49
日付、時間に関する 49
複合データ型 147
浮動小数点 46
不透明 (OPAQUE) 型 144
データベース サーバ管理者 (DBSA)
データベース レベル アクセス権
説明 100
データベース管理者アクセス権
Connect アクセス権 100
108, 109
101
Resource アクセス権 101
データベース管理者 (DBA) 101
ディスティンクト (DISTINCT) 型
キャスト 181, 189
説明 143
テキスト (TEXT) 型
使用 57
制限 153, 160
説明 56
デフォルト ロケール x
デフォルト値、列 59
導出データ、ビューにより作成された 117
ドキュメント ノート xix
ドメイン
定義 28
特性 29
列 40
トランザクション
定義 5
ANSI 対非 ANSI 6
トランザクション ログ機能
高速ロードのためにオフにする 73
バッファ付き 63
索引
249
トランザクション ログ機能 (続き)
ANSI 対非 ANSI 6
CREATE DATABASE 文による作成
ビュー
アクセス権 124
仮想列 121
62
型付き
［ナ行］
修正
名前付き行型
型付き表の作成
命名規則
156
121
重複行の更新
154
123
に行を挿入 122
表示されない列に挿入された NULL
ベースが削除されると削除される
154
122
120
ベースの変更の反映 120
WITH CHECK OPTION キーワードの使用
表
アクセス権 102
インデックス、作成
エンティティを表す
制限 160
説明 160
例 160
外部キー、定義
日時 (DATETIME) 型
説明 50
表示フォーマット
122
定義の変更時の反映
例 153
列定義 158
名前なし行型
52
［ハ行］
排他レベル、ANSI 対非 ANSI 7
バイト (BYTE) 型
使用 57
制限 153, 160
説明 57
ハイブリッド分散スキーム
使用 85
説明 81, 85
ハッシュ分散スキーム
参照： システム定義ハッシュ分散スキーム
バッファ付きログ機能 63
パフォーマンス、バッファ付きログ機能 63
範囲分散スキーム
使用 83
説明 81
日付 (DATE) 型
説明 49
表示フォーマット 50
ビットマップ インデックス、説明 232
250
121
修正の制限
説明 116
キャスト 181
削除 159
使用する場合
制限 155
説明 153
118
行の削除 121
作成 117
IBM Informix データベース設計および実装 ガイド
66
29
30
形なし表への変換 157
型なしから型付きへの変換
関係モデル 27
キー列 29
記述子列 29
削除 66
主キー 29
所有権 102
データのロード 72
名前、シノニム 67
表の作成 64
複合キー、定義 30
表階層
新しい表の追加 175
継承されたプロパティ 170
シリアル (SERIAL) 型 174
説明 169
定義 170
トリガ 174
表の動作の修正 172
表継承、定義 169
標準永続表
説明 231
変更 232
表へのデータの追加 70
157
122
表名のシノニム
分散スキーム (続き)
67
表レベル アクセス権
アクセス権 102
定義と使用
使用 81
任意規則を使用した
範囲規則を使用した
102
Alter アクセス権
104
Index アクセス権 104
References アクセス権 104
ブール データ型
ファクト表
細分性 205
細分性の決定
ハイブリッド
210
使用 85
範囲 81
使用 83
81
フラグメント数の変更
ラウンドロビン 80
使用 83
ペーパー マニュアル
30
82
81
使用 84
定義 78
53
説明 205
フィールド、行 (ROW) 型で 153
副型 163
複合キー
システム定義ハッシュ
82
90
xxi
複合データ型 147
副表 163
浮動小数点 46
並行性
シリアル (SERIAL) 型と 8 バイト シリアル
(SERIAL8) 型の値 44
不透明 (OPAQUE) 型
キャスト 181
説明 144
フラグメント化の向上 79
ヘルプ xxi
変数、構文ダイアグラム内 xvii
太文字 xii
フラグメント
本書の規則
数の変更
説明 78
90
変更 92, 94
フラグメント化
ゴール 79
再初期化 90
式、評価方法 83
スマート ラージ オブジェクトの 89
説明 78
バックアップおよび復元の操作 79
複数のコサーバの間での 80
分散スキームのタイプ 80
ログ 80
DB スライス役割 80
フラグメント表
作成 85
修正 90
1 つのフラグメント化されていない表からの作成
88
フラグメント表の修正 90
分割不可能な属性 23
分散スキーム
式ベース 80
xii
［マ行］
マシン ノート xix
マニュアル、タイプ xviii
オンライン マニュアル xxi
ペーパー マニュアル xxi
マシン ノート xix
マルチセット (MULTISET) 型のコレクション
(COLLECTION) 型 151
モード ANSI キーワード、ログ機能 63
文字 (CHAR) 型 53
文字 (CHAR) 型フィールド長
ANSI 対非 ANSI 7
文字の表記規則 xii
［ヤ行］
ユーザ定義キャスト
データ型間での 188
ユーザ定義データ型
キャスト 180
説明 143
索引
251
ログなし表
ユーザ定義ルーチン
作成
アクセス権の付与 108
セキュリティの目的 98
ユーティリティ プログラム
dbload
73, 221, 228
要件、ソフトウェア
要素型 148
x
［数字］
1 対 1 の関係 17, 19
1 対多の関係 17, 19
［ラ行］
10 進数 (DECIMAL) 型
固定小数点 48
ライト アペンド、説明 230
ラウンドロビン分散スキーム
使用
説明
221, 228
特性 229
ロケール x, 9
浮動小数点 47
10.0 機能、概要 xii
83
80
リスト (LIST) 型のコレクション (COLLECTION) 型
151
リポジトリ、説明 201
リリース ノート xix
リレーショナル データ モデルの作成
10.0 の機能 xii
8 バイト シリアル (SERIAL8) 型
参照制約 60
初期化 45
制限 144, 153, 155, 160
説明 44
26
ルーチン オーバーロード 166
ルーチン レベル アクセス権 108
ルーチン解決 168
表階層
174
8 バイト整数 (INT8) 型
8.5 機能、概要 xi
44
列
定義 27
名前付き行型
名前なし行型
158
160
フラグメント表の修正 90
列レベル アクセス権 105
列レベル暗号化 98
ロール
アクセス権の付与 111
定義 110
命名ルール 111
CREATE ROLE 文 111
GRANT DEFAULT ROLE 文 112
SET ROLE 文 112
sysroleauth システム カタログ表 112
sysusers システム カタログ表 112
ロウ永続表
説明 230
変更 232
ログ機能、タイプ 63
ログ付き表
作成 221, 228
特性 229
252
IBM Informix データベース設計および実装 ガイド
A
ALTER FRAGMENT の MODIFY 節
ALTER FRAGMENT 文
ADD 節 91
ATTACH 節 94
DETACH 節 94
DROP 節 92
INIT 節 90
MODIFY 節 92
ALTER TABLE 文
形なし表への変換 157
型付き表への変換 157
に対するアクセス権 104
表タイプの変更 232
列のデータ型の変更 58
Alter アクセス権 104
ANSI 標準準拠データベース
アクセス権 6
エスケープ文字 8
カーソルの動作 8
作成する理由 4
識別 9
92
ANSI 標準準拠データベース (続き)
所有者名の指定
説明 4
DB スライス、フラグメント化での役割
トランザクション
排他レベル 7
バッファ付きログ機能
6
フラグメント化での役割
78
DBA
参照： データベース管理者
DBDATE 環境変数 50
63
102
文字 (CHAR) 型フィールド長
10 進数 (DECIMAL) 型 8
SQLCODE 8
7
dbexport ユーティリティ 71
dbimport ユーティリティ 71
dbload ユーティリティ、データのロード
DBMONEY 環境変数 49
dbschema ユーティリティ 70
B
DBTIME 環境変数
BLOB 型
説明 145
名前付き行型の制限
SQL の制限 146
155
72
53
DB-Access
データベースの作成
UNLOAD 文 72
70
DEFAULT_ROLE( ) 関数 113
Delete アクセス権 102, 124
DELETE 文
C
アクセス権
CLOB 型
説明 145
名前付き行型の制限
SQL の制限 146
80
DB 領域
選択 63
5
トランザクション ログ機能
表アクセス権
D
6
155
Codd, E. F. 37
Connect アクセス権 100
CREATE DATABASE 文
コマンド スクリプト 69
次元データ モデル 222
リレーショナル データ モデル 62
CREATE FUNCTION 文
キャスト登録の例 194
CREATE INDEX 文 66
CREATE TABLE 文
コマンド スクリプト 69
説明 64
FRAGMENT BY EXPRESSION 節を使用した
CREATE VIEW 文
使用 117
制限 119
WITH CHECK OPTION キーワード 122
CURRENT_ROLE( ) 関数 113
100
に対するアクセス権 102
ビューへ適用 121
DISTINCT キーワード、修正可能なビューでの制限
121
DROP CAST 文、使用
191
E
en_us.8859-1 ロケール x
EXISTS キーワード、条件副問合せでの使用
EXTERNAL ロール 109
123
F
FRAGMENT BY EXPRESSION 節
81
81
G
GK インデックス
参照： 一般化キー インデックス
GL_DATETIME 環境変数 53
GRANT 文
データベース レベル アクセス権
表レベル アクセス権 101
99
索引
253
GROUP BY キーワード、修正可能なビューでの制限
121
R
References アクセス権
104
Resource アクセス権 101
REVOKE 文、アクセス権の付与
I
IFX_EXTEND_ROLE 構成パラメータ
109
Index アクセス権 104
Informix Dynamic Server マニュアル セット
informix ユーザ名 101, 109
xxii
INFORMIXDIR/bin ディレクトリ xi
INIT 節
フラグメント化スキーマの 90
ALTER FRAGMENT
224
210
Select アクセス権
定義 102
ビューを使用した
120
x
N
NODEFDAC 環境変数 102
NOT NULL キーワード、CREATE TABLE 文で使用
64
NULL 値
主キーの制約事項
定義 58
sales_demo データベース
作成 222, 227
ロード 225
SB 領域 146
Insert アクセス権 102, 124
INSERT 文
アクセス権 100, 102
ビューを使用した 122
INSTEAD OF トリガ 122
INTO TEMP キーワード、ビューの制限
S
データ ソース
データ モデル
90
ISO 8859-1 コード セット
99
29
124
列レベル 105
SELECT 文
修正可能なビューでの
121
に対するアクセス権
100, 102
ビューでの 123
SET ENCRYPTION PASSWORD 文 98
SET コレクション (COLLECTION) 型 150
SQL コード xvii
SQLCODE、ANSI 対非 ANSI 8
stores_demo データベース xi
superstores_demo データベース xi, 140
sysfragexprudrdep システム カタログ表 78
sysfragments システム カタログ表 78
syssyntable システム カタログ表 68
O
ON アーカイブ 64
ondblog ユーティリティ 64
onload ユーティリティ 70
onstat ユーティリティ 113
ontape ユーティリティ 64
onunload ユーティリティ 70
onxfer ユーティリティ 71
ORDER BY キーワード、ビューの制限
T
TOC (目次) ノート
U
120
P
PUBLIC キーワード、すべてのユーザに付与されるアク
セス権 101
254
xix
IBM Informix データベース設計および実装 ガイド
UNION キーワード
修正可能なビューでの制限 121
ビュー定義での 120
UNIQUE キーワード
修正可能なビューでの制限 121
CREATE TABLE 文での制約 64
Update アクセス権
定義 102
Update アクセス権 (続き)
ビューを使用した
UPDATE 文
124
に対するアクセス権
ビューへ適用
100, 102
121
USER キーワード 123
USETABLENAME 環境変数
68
W
WHERE キーワード、データ制約の強制 123
WITH CHECK OPTION キーワード、CREATE VIEW
文
122
X
XPS 8.5 の機能
xi
［特殊文字］
::、キャスト演算子
180
索引
255
256
IBM Informix データベース設計および実装 ガイド
򔻐򗗠򙳰
Printed in Japan
GB88-8666-00