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

IBM Informix
򔻐򗗠򙳰
データベース設計および実装 ガイド
バージョン 9.4
GB88-8634-00
(英文原典：G251-1245-00)
IBM Informix
򔻐򗗠򙳰
データベース設計および実装 ガイド
バージョン 9.4
GB88-8634-00
(英文原典：G251-1245-00)
お願い
本書および本書で紹介する製品をご使用になる前に、221 ページの『特記事項』に記載されている情報をお読み
ください。
本書には、IBM の専有情報が含まれています。その情報は、使用許諾条件に基づき提供され、著作権により保護されて
います。本書に記載される情報には、いかなる製品の保証も含まれていません。また、本書で提供されるいかなる記述
も、製品保証として解釈すべきではありません。
IBM は、お客様が提供するいかなる情報も、お客様に対してなんら義務も負うことのない、自ら適切と信ずる方法で、
使用もしくは配布することができるものとします。
本マニュアルに関するご意見やご感想は、次の URL からお送りください。今後の参考にさせていただきます。
http://www.ibm.com/jp/manuals/main/mail.html
なお、日本 IBM 発行のマニュアルはインターネット経由でもご購入いただけます。詳しくは
http://www.ibm.com/jp/manuals/
の「ご注文について」をご覧ください。
(URL は、変更になる場合があります)
お客様の環境によっては、資料中の円記号がバックスラッシュと表示されたり、バックスラッシュが円記号と表示され
たりする場合があります。
原 典：
G251-1245-00
IBM Informix
Guide to Database Design and Implementation
Version 9.4
発 行：
日本アイ・ビー・エム株式会社
担 当：
ナショナル・ランゲージ・サポート
第1刷 2003.5
この文書では、平成明朝体™W3、平成明朝体™W9、平成角ゴシック体™W3、平成角ゴシック体™W5、および平成角ゴ
（財）日本規格協会と使用契約を締結し使用しているものです。フォ
シック体™W7を使用しています。この(書体*)は、
ントとして無断複製することは禁止されています。
注* 平成明朝体™W3、平成明朝体™W9、平成角ゴシック体™W3、
平成角ゴシック体™W5、平成角ゴシック体™W7
© Copyright International Business Machines Corporation 1996, 2003. All rights reserved.
© Copyright IBM Japan 2003
目次
序 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
本書について . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
対象ユーザ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
必要なソフトウェア . . . . . . . . . . . . . . . . . . . . . . . . . . . x
ロケールについて . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
デモンストレーション データベース . . . . . . . . . . . . . . . . . . . . . . xi
バージョン 9.4 で導入された新しい機能 . . . . . . . . . . . . . . . . . . . . . xii
表記規則 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
文字の表記 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
その他の表記 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
コード例の表記 . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv
関連マニュアル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
参考文献 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
業界標準への対応 . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
第 1 部 データベース設計と実装の基本 . . . . . . . . . . . . . . . . . . 1
第 1 章 データベースの計画 . . . . . . . . . . . . . . . . . . . . . . . . . 3
データベースのデータ モデルの選択 . . . . . . . . . . . . . . . . . . . . . . . 3
ANSI 標準準拠データベースの使用法 . . . . . . . . . . . . . . . . . . . . . . . 4
ANSI 標準準拠データベースと非 ANSI 標準準拠データベースとの相違点 . . . . . . . . . 5
既存のデータベースが ANSI 標準準拠であるかの判断 . . . . . . . . . . . . . . . . 8
使用するデータベース専用の言語処理環境の使用法 (GLS のみ) . . . . . . . . . . . . . . 9
第 2 章 リレーショナル データ モデルの作成 . . . . . . . . . . . . . . . . . . . 11
データ モデルの作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
実体 - 関係データ モデルの概要 . . . . . . . . . . . . . . . . . . . . . . . . 11
主なデータ オブジェクトの識別と定義 . . . . . . . . . . . . . . . . . . . . . . 12
実体の識別 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
関係の定義 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
属性の識別 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
データ オブジェクトの図式化 . . . . . . . . . . . . . . . . . . . . . . . . . 23
E-R ダイアグラムの読取り . . . . . . . . . . . . . . . . . . . . . . . . . 24
住所録の例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
E-R データ オブジェクトの関係構造体への変換 . . . . . . . . . . . . . . . . . . . 26
表、行、列の定義 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
表のキーの決定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
関係の解決 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
m:n 関係の解決. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
その他の特別な関係の解決 . . . . . . . . . . . . . . . . . . . . . . . . . 33
データ モデルの正規化 . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
© Copyright IBM Corp. 1996, 2003
iii
第 1 正規形 . . . .
第 2 正規形 . . . .
第 3 正規形 . . . .
正規化ルールのまとめ
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
34
36
36
37
第 3 章 データ型の選択 . . . . . . . . . . . . . . . . . . . . . . . . . . 39
ドメインの定義 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
データ型 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
データ型の選択 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
数値型 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
日付、時間に関するデータ型 . . . . . . . . . . . . . . . . . . . . . . . . 48
ブールデータ型 (IDS のみ) . . . . . . . . . . . . . . . . . . . . . . . . . 52
文字 (CHARACTER) 型 (GLS のみ) . . . . . . . . . . . . . . . . . . . . . . 52
NULL 値 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
デフォルト値 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
チェック制約 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
参照制約 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
第 4 章 リレーショナルデータモデルの実装 . . . . . . . . . . . . . . . . . . . . 61
データベースの作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
CREATE DATABASE の使用 . . . . . . . . . . . . . . . . . . . . . . . . 61
CREATE TABLE の使用. . . . . . . . . . . . . . . . . . . . . . . . . . 64
CREATE INDEX の使用 . . . . . . . . . . . . . . . . . . . . . . . . . . 66
表名のシノニムの使用 . . . . . . . . . . . . . . . . . . . . . . . . . . 67
シノニム連鎖の使用 . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
コマンド スクリプトの使用 . . . . . . . . . . . . . . . . . . . . . . . . 69
データベースへのデータの追加 . . . . . . . . . . . . . . . . . . . . . . . . 70
他の Informix データベースからのデータの移動 . . . . . . . . . . . . . . . . . . 72
ソースデータを表にロードする . . . . . . . . . . . . . . . . . . . . . . . 72
一括ロード操作の実行 . . . . . . . . . . . . . . . . . . . . . . . . . . 73
第 2 部 データベースの管理 . . . . . . . . . . . . . . . . . . . . . . 75
第 5 章 表フラグメンテーション ストラテジ . . .
フラグメント化とは . . . . . . . . . . . .
フラグメント化を使用する理由 . . . . . . .
フラグメント化の責任者 . . . . . . . . . .
Extended Parallel Server に対する拡張フラグメント化
フラグメント化とロギング . . . . . . . . .
表のフラグメント化のための分散スキーム . . . . .
式ベース分散スキーム . . . . . . . . . .
ラウンド ロビン分散スキーム . . . . . . . .
範囲分散スキーム (XPS のみ) . . . . . . . .
システム定義ハッシュ分散スキーム (XPS のみ) . .
ハイブリッド分散スキーム (XPS のみ) . . . . .
フラグメント表の作成 . . . . . . . . . . .
iv
IBM Informix: データベース設計および実装 ガイド
. . . . . . . . . . . . . . . . 77
. . . . . . . . . . . . . . . . 77
. . . . . . . . . . . . . . . . 78
. . . . . . . . . . . . . . . . 78
. . . . . . . . . . . . . . . . 79
. . . . . . . . . . . . . . . . 79
. . . . . . . . . . . . . . . . 79
. . . . . . . . . . . . . . . . 80
. . . . . . . . . . . . . . . . 82
. . . . . . . . . . . . . . . . 82
. . . . . . . . . . . . . . . . 83
. . . . . . . . . . . . . . . . 84
. . . . . . . . . . . . . . . . 84
フラグメント表を新たに作成する . . . . . . . . . .
フラグメント化されていない表からのフラグメント表の作成 .
フラグメント表内の行 ID . . . . . . . . . . . .
スマート ラージ オブジェクトのフラグメント化 (IDS のみ)
フラグメンテーション ストラテジの修正 . . . . . . . .
フラグメンテーション ストラテジの再初期化 . . . . .
Dynamic Server のフラグメンテーション ストラテジの修正 .
XPS のフラグメンテーション ストラテジの修正 . . . .
フラグメント アクセス権の付与と取消し (IDS のみ) . . . .
第 6 章 データベース サーバのアクセス権の付与と制限.
SQL を使用したデータへのアクセスの制限 . . . . .
データベースへのアクセスの制御 . . . . . . . . .
アクセス権の付与 . . . . . . . . . . . . . .
データベース レベル アクセス権 . . . . . . . .
所有権 . . . . . . . . . . . . . . . . .
表レベル アクセス権 . . . . . . . . . . . .
列レベル アクセス権 . . . . . . . . . . .
型レベル アクセス権 . . . . . . . . . . .
ルーチン レベル アクセス権 . . . . . . . . .
言語レベル アクセス権 . . . . . . . . . . .
アクセス権の自動化 . . . . . . . . . . . .
SPL ルーチンによるデータへのアクセスの制御. . . .
データの読込みの制限 . . . . . . . . . . .
データへの変更の制限 . . . . . . . . . . .
データへの変更の監視 . . . . . . . . . . .
オブジェクト作成の制限 . . . . . . . . . .
ビューの使用 . . . . . . . . . . . . . . .
ビューの作成 . . . . . . . . . . . . . .
ビューに関する制限 . . . . . . . . . . . .
ビューを用いたデータの変更 . . . . . . . . .
アクセス権とビュー . . . . . . . . . . . . .
ビューの作成時のアクセス権 . . . . . . . . .
ビューを使用するときのアクセス権 . . . . . .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
.
.
.
.
.
.
.
.
.
85
86
87
88
89
89
90
91
94
. 95
. 95
. 95
. 96
. 97
. 99
. 99
. 102
. 104
. 105
. 105
. 106
. 109
. 110
. 111
. 111
. 112
. 113
. 114
. 116
. 118
. 120
. 120
. 121
第 3 部 オブジェクト リレーショナル データベース . . . . . . . . . . . . 125
第 7 章 Dynamic Server での拡張データ型の作成と使用. . . . . . . . . . . . . . . 127
Informix のデータ型 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
基本データ型または最小のデータ型 . . . . . . . . . . . . . . . . . . . . . 128
事前定義データ型 . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
拡張データ型 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
スマート ラージ オブジェクト . . . . . . . . . . . . . . . . . . . . . . . . 132
バイナリ ラージ オブジェクト(BLOB) 型 . . . . . . . . . . . . . . . . . . . 132
文字ラージ オブジェクト (CLOB) 型 . . . . . . . . . . . . . . . . . . . . . 132
スマート ラージ オブジェクトの使用 . . . . . . . . . . . . . . . . . . . . . 133
目次
v
スマート ラージ オブジェクトのコピー
複合データ型 . . . . . . . . . .
コレクション (COLLECTION) 型 . .
名前付き行 (ROW) 型 . . . . . .
名前なし行 (ROW) 型 . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
第 8 章 Dynamic Server による型継承と表継承.
継承について . . . . . . . . . . . . .
型継承 . . . . . . . . . . . . . . .
型階層の定義 . . . . . . . . . . . .
型階層内の型に対するルーチンのオーバーロード
継承と型代用性 . . . . . . . . . . .
型階層からの名前付き行 (ROW) 型の削除 . .
表継承 . . . . . . . . . . . . . . .
型階層と表階層との関係 . . . . . . . .
表階層の定義 . . . . . . . . . . . .
表階層内の表の動作の継承 . . . . . . .
表階層内の表の動作の修正 . . . . . . .
表階層内のシリアル (SERIAL) 型 . . . . .
表階層への表の追加 . . . . . . . . . .
表階層内の表の削除 . . . . . . . . . .
表階層内の表の構造の変更 . . . . . . .
表階層内の表の問合せ . . . . . . . . .
表階層内の表のビューの作成 . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
IBM Informix: データベース設計および実装 ガイド
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
134
134
135
140
147
. . . . . . . . . . . . . . . . . 149
. . . . . . . . . . . . . . . . . 149
. . . . . . . . . . . . . . . . . 149
. . . . . . . . . . . . . . . . . 149
. . . . . . . . . . . . . . . . . 152
. . . . . . . . . . . . . . . . . 152
. . . . . . . . . . . . . . . . . 153
. . . . . . . . . . . . . . . . . 154
. . . . . . . . . . . . . . . . . 154
. . . . . . . . . . . . . . . . . 155
. . . . . . . . . . . . . . . . . 156
. . . . . . . . . . . . . . . . . 158
. . . . . . . . . . . . . . . . . 159
. . . . . . . . . . . . . . . . . 160
. . . . . . . . . . . . . . . . . 162
. . . . . . . . . . . . . . . . . 162
. . . . . . . . . . . . . . . . . 162
. . . . . . . . . . . . . . . . . 162
第 9 章 Dynamic Server でのユーザ定義キャストの作成と使用 . . . . . .
キャストとは . . . . . . . . . . . . . . . . . . . . . . . .
ユーザ定義キャストの作成 . . . . . . . . . . . . . . . . . .
キャストの起動 . . . . . . . . . . . . . . . . . . . . . .
ユーザ定義キャストに関する制限 . . . . . . . . . . . . . . . .
行 (ROW) 型のキャスト . . . . . . . . . . . . . . . . . . . .
名前付き行 (ROW) 型と名前なし行 (ROW) 型の間のキャスト . . . . . .
名前なし行 (ROW) 型どうしのキャスト . . . . . . . . . . . . . .
名前付き行 (ROW) 型の間でのキャスト . . . . . . . . . . . . . .
フィールドでの明示的キャストの使用 . . . . . . . . . . . . . . .
行 (ROW) 型の各フィールドのキャスト . . . . . . . . . . . . . .
コレクション (COLLECTION) 型のキャスト. . . . . . . . . . . . . .
コレクション (COLLECTION) 型の変換の制限 . . . . . . . . . . . .
要素型が異なるコレクション . . . . . . . . . . . . . . . . . .
リレーショナル データから マルチセット (MULTISET) 型コレクションへの変換
ディスティンクト型のキャスト . . . . . . . . . . . . . . . . . .
ディスティンクト型での明示的キャストの使用 . . . . . . . . . . . .
ディスティンクト型とソース型の間のキャスト . . . . . . . . . . . .
ディスティンクト型のキャストの追加と削除 . . . . . . . . . . . .
スマート ラージ オブジェクトへのキャスト . . . . . . . . . . . . .
ユーザ定義キャストのキャスト関数の作成 . . . . . . . . . . . . . .
vi
.
.
.
.
.
. . . . . . 165
. . . . . . 165
. . . . . . 166
. . . . . . 166
. . . . . . 167
. . . . . . 167
. . . . . . 168
. . . . . . 169
. . . . . . 169
. . . . . . 170
. . . . . . 171
. . . . . . 171
. . . . . . 172
. . . . . . 172
. . . . . . 173
. . . . . . 174
. . . . . . 174
. . . . . . 175
. . . . . . 176
. . . . . . 176
. . . . . . 177
名前付き行 (ROW) 型間でのキャストの例 .
ディスティンクト型間でのキャストの例 . .
マルチレベル キャスト . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 177
. 178
. 180
第 4 部 次元データベース . . . . . . . . . . . . . . . . . . . . . . . 181
第 10 章 次元データ モデルの作成 . . . . . . . . . . . . . . . . . . . . . . 183
データ ウェアハウスの概要 . . . . . . . . . . . . . . . . . . . . . . . . . 183
次元データベースを作成する理由 . . . . . . . . . . . . . . . . . . . . . . 184
次元データとは . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
次元データ モデルのコンセプト . . . . . . . . . . . . . . . . . . . . . . . . 187
ファクト表 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
データ モデルの次元 . . . . . . . . . . . . . . . . . . . . . . . . . . 189
次元データ モデルの作成 . . . . . . . . . . . . . . . . . . . . . . . . . . 191
ビジネス プロセスの選択 . . . . . . . . . . . . . . . . . . . . . . . . . 191
ビジネス プロセスの要約 . . . . . . . . . . . . . . . . . . . . . . . . . 192
ファクト表の細分性の決定 . . . . . . . . . . . . . . . . . . . . . . . . 193
次元と階層の明確化 . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
ファクト表のメジャー (基準) の選択 . . . . . . . . . . . . . . . . . . . . . 196
正規化の防止 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
次元表の属性の選択 . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
次元データ モデルの共通する問題の処理 . . . . . . . . . . . . . . . . . . . . . 200
次元表の属性数を最小限に抑える . . . . . . . . . . . . . . . . . . . . . . 200
時々変更する次元の処理 . . . . . . . . . . . . . . . . . . . . . . . . . 201
スノーフレーク スキーマの使用 . . . . . . . . . . . . . . . . . . . . . . . 202
第 11 章 次元データベースの実装 (Extended Parallel Server のみ) . . . . . . . . . . . 205
次元データベース sales_demo の実装 . . . . . . . . . . . . . . . . . . . . . . 205
CREATE DATABASE の使用. . . . . . . . . . . . . . . . . . . . . . . . 205
CREATE TABLE 文を使用した次元表およびファクト表の作成 . . . . . . . . . . . . 206
データ ソースからデータベースへのデータのマッピング . . . . . . . . . . . . . . 207
次元データベースへのデータのロード . . . . . . . . . . . . . . . . . . . . . 209
データベース sales_demo の作成 . . . . . . . . . . . . . . . . . . . . . . 211
次元データベースのテスト . . . . . . . . . . . . . . . . . . . . . . . . 211
Extended Parallel Server のログ付き表とログなし表 . . . . . . . . . . . . . . . . . 212
表タイプの選択 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
表の種類の切替え . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
データ ウェアハウス環境のインデックス . . . . . . . . . . . . . . . . . . . . . 216
データ ウェアハウス環境での GK インデックスの使用 . . . . . . . . . . . . . . . . 217
選択での GK インデックスの定義 . . . . . . . . . . . . . . . . . . . . . . 217
式での GK インデックスの定義 . . . . . . . . . . . . . . . . . . . . . . . 217
結合された表での GK インデックスの定義 . . . . . . . . . . . . . . . . . . . 218
第 5 部 付録 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
特記事項
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
目次
. 221
vii
商標 .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 224
索引 .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 225
viii
IBM Informix: データベース設計および実装 ガイド
序
本書について . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
対象ユーザ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
必要なソフトウェア . . . . . . . . . . . . . . . . . . . . . . . . . . . x
ロケールについて . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
デモンストレーション データベース . . . . . . . . . . . . . . . . . . . . . . xi
バージョン 9.4 で導入された新しい機能 . . . . . . . . . . . . . . . . . . . . . xii
表記規則 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
文字の表記 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
その他の表記 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
コメント . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
機能、製品、およびプラットフォーム . . . . . . . . . . . . . . . . . . . . xiv
コード例の表記 . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv
関連マニュアル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
参考文献 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
業界標準への対応 . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
第 1 部 データベース設計と実装の基本
1
第 1 章 データベースの計画 . . . . . . . . . . . . . . . . . . . . . . . . . 3
データベースのデータ モデルの選択 . . . . . . . . . . . . . . . . . . . . . . . 3
ANSI 標準準拠データベースの使用法 . . . . . . . . . . . . . . . . . . . . . . . 4
ANSI 標準準拠データベースと非 ANSI 標準準拠データベースとの相違点 . . . . . . . . . 5
トランザクション . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
トランザクション ログ機能 . . . . . . . . . . . . . . . . . . . . . . . . 6
所有者名の指定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
オブジェクトへのアクセス権 . . . . . . . . . . . . . . . . . . . . . . . 6
デフォルトの排他レベル . . . . . . . . . . . . . . . . . . . . . . . . . 7
文字 (CHARACTER) 型 . . . . . . . . . . . . . . . . . . . . . . . . . 7
10 進数 (DECIMAL) 型 . . . . . . . . . . . . . . . . . . . . . . . . . 7
エスケープ文字 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
カーソルの動作 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
SQL 通信領域の SQLCODE フィールド . . . . . . . . . . . . . . . . . . . . 8
シノニムの動作 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
既存のデータベースが ANSI 標準準拠であるかの判断 . . . . . . . . . . . . . . . . 8
使用するデータベース専用の言語処理環境の使用法 (GLS のみ) . . . . . . . . . . . . . . 9
序の概要
この序では、本書にある情報の概要を説明し、使用される表記を示します。
© Copyright IBM Corp. 1996, 2003
ix
本書について
このマニュアルは、Informix データベースの設計、実装、管理に役立つ情報を提供しま
す。具体的には、データベース設計のさまざまなアプローチを示すデータ モデルについ
て説明し、SQL(Structured Query Language : 構造化問合せ言語) を使用してデータベー
スを実装および管理する方法について示します。
本書のほかにも、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: スタートアップ ガイド」の
参考文献の一覧を参照してください。
必要なソフトウェア
本書は、データベース サーバが以下のいずれかであることを前提としています。
v IBM Informix Extended Parallel Server, バージョン 8.4
v IBM Informix Dynamic Server, バージョン 9.4
x
IBM Informix: データベース設計および実装 ガイド
ロケールについて
IBM Informix 製品は、多くの言語、地域特有の情報、およびコード セットをサポート
します。文字セット、照合、および数値データ、通貨、日付、時刻の表記に関する情報
はすべて、広域言語サポート (GLS) ロケールと呼ばれる 1 つの環境にまとめられてい
ます。
本書の例では、en_us.8859-1 というデフォルト ロケールを使用していることを前提と
しています。このロケールは、日付、時刻、および通貨に対する米国英語の表記をサポ
ートします。またこのロケールは、ASCII コード セット、および é、è、ñ などの 8 ビ
ット文字を含む ISO 8859-1 コードセットをサポートします。
データ、または SQL 識別子でデフォルト以外の文字を使用する場合、または文字デー
タをデフォルト以外の順序で照合する場合、適切なロケールを指定する必要がありま
す。
デフォルト以外のロケールを指定し、さらに構文を追加する方法、および GLS ロケー
ルに関するその他の考慮事項については、「IBM Informix: GLS ユーザーズ ガイド」を
参照してください。
デモンストレーション データベース
データベース サーバ製品に付属する DB–Access ユーティリティには、以下の 1 つ以
上のデモンストレーション データベースが含まれています。
v stores_demo データベースでは、架空のスポーツ用品卸し売り業者の例を使用し
て、関係スキーマについて説明します。 IBM Informix のマニュアルには、
stores_demo データベースに基づく多くの例が含まれています。
Extended Parallel Server
v sales_demo データベースは、データ ウェアハウス アプリケーションの次元スキー
マを説明します。次元データ モデルという概念については、「IBM Informix: データ
ベース設計および実装 ガイド」を参照してください。
Extended Parallel Server の終り
Dynamic Server
v superstores_demo データベースでは、オブジェクト関係スキーマについて説明しま
す。 superstores_demo データベースには、拡張データ型、型と表の継承、および
ユーザ定義ルーチンについての例が含まれています。
Dynamic Server の終り
序
xi
デモンストレーション データベースの構築について詳しくは、「IBM Informix:
DB-Access ユーザーズ ガイド」を参照してください。これらのデータベースとその内容
については、「IBM Informix: SQL ガイド: 参照」を参照してください。
デモンストレーション データベースのインストールに使用するスクリプトは、UNIX プ
ラットフォームの場合は $INFORMIXDIR/bin ディレクトリ、Windows 環境の場合は、
%INFORMIXDIR%\bin ディレクトリにあります。
バージョン 9.4 で導入された新しい機能
IBM Informix Dynamic Server バージョン 9.4 の新機能については、「IBM Informix: ス
タートアップ ガイド」を参照してください。
表記規則
ここでは、このマニュアルで使用される、以下の表記について説明します。表記を覚え
ておくと、このマニュアル、およびほかのマニュアルの内容を理解するのに役に立ちま
す。
以下のような表記があります。
v 文字の表記
v その他の表記
v コマンド行の表記
v コード例の表記
文字の表記
本書では、新しい用語、画面表示、コマンド構文などの表記に、以下の規則を使用しま
す。
xii
表記
意味
KEYWORD
プログラミング言語の文中では、主要素 (キーワード) は、すべて大
文字のセリフ フォントで表記されます。
イタリック
イタリック
イタリック
テキストの場合、新しい用語および強調される単語はイタリックで表
示される。構文およびコード例の場合、ユーザーが指定する変数値は
イタリックで表示される。
ボールド体
ボールド体
プログラム エンティティの名前 (クラス、イベント、および表な
ど)、環境変数、ファイルやパス名、およびインターフェイス エレメ
ント (アイコン、メニュー項目、およびボタンなど) はボールド体で
表示される。
モノスペース
モノスペース
製品によって表示される情報およびユーザが入力した情報は、モノス
ペース タイプフェースで表示される
IBM Informix: データベース設計および実装 ガイド
表記
意味
KEYSTROKE
ユーザが押すキーは、大文字のサンセリフ フォントで表示される。
→
この記号は、メニュー項目を表します。たとえば、
『「Tools」→「Options」を選択』は、「Tools」メニューの
「Options」を選択することを意味します。
ヒント: 文字を「入力」したり、コマンドを「実行」するよう指示された場合は、入力
した後すぐに Enter キーを押してください。テキストを「入力」したり、他の
キーを「押す」よう指示された場合は、Enter キーを押す必要はありません。
その他の表記
本書では、テキストがいくつかの異なるタイプのマークアップによって識別されていま
す。
コメント
コメントのアイコンは、下の例に示すように、3 つのタイプの情報を表します。
警告: 重要な指示、注意、または情報を表します。
重要: 説明されている機能、または操作に関する重要な情報を表します。
ヒント: 説明されている機能の詳細、またはショートカットを表します。
序
xiii
機能、製品、およびプラットフォーム
機能、製品、およびプラットフォームのマークアップは、機能、製品、またはプラット
フォームに特有な情報を表します。マークアップの例を次に示します。
Dynamic Server
IBM Informix Dynamic Server に特有な情報を表します。
Dynamic Server の終り
UNIX のみ
UNIX プラットフォームに特有な情報を表します。
UNIX のみ の終り
Windows のみ
Windows 環境に特有な情報を表します。
Windows のみ の終り
このマークアップは、セクション内の 1 つ以上のパラグラフに適用されます。セクショ
ン全体が特定の製品またはプラットフォームに適用される場合は、そのことが見出しテ
キストの一部として表示されます。
表ソート (Windows のみ)
コード例の表記
本書では、SQL コードの例を使用しています。特に説明がない限り、コードは特定の
IBM Informix アプリケーション開発ツール専用ではありません。
例の中に含まれる SQL 文は、セミコロン (;) で区切られません。たとえば、以下のよ
うなコードの例が使用されます。
CONNECT TO stores_demo
...
DELETE FROM customer
WHERE customer_num = 121
...
COMMIT WORK
DISCONNECT CURRENT
この SQL コードをある製品で使用する場合、製品の構文ルールを適用する必要があり
ます。たとえば、DB–Access を使用する場合、文と文の間はセミコロン (;) で区切る必
xiv
IBM Informix: データベース設計および実装 ガイド
要があります。 SQL API を使用している場合は、 EXEC SQL を各文の先頭に指定
し、各文の末尾にセミコロン (または適切な区切り記号) を指定する必要があります。
ヒント: 前述のコードの例では、アプリケーション全体では必要でも、ここでは説明す
る必要のないコードは、ピリオド (.) で示されています。
特定のアプリケーション開発ツール、または SQL API の SQL 文について詳しくは、
製品に付属するマニュアルを参照してください。
関連マニュアル
IBM Informix Dynamic Server のマニュアルはさまざまな形式で提供されています。
v オンライン マニュアル。 提供されたものと同じオンラインマニュアルを、以下の
IBM Informix Online Documentation サイト
http://www-3.ibm.com/software/data/informix/pubs/library/ から入手することができま
す。この Web サイトでは、章、またはブック全体を印刷することができます。
v オンライン ヘルプ。 この機能は、詳細ヘルプ、エラー メッセージ参照、言語構文
などを提供します。
v ドキュメント ノート、リリース ノート、マシン ノート。 ドキュメント ノート、
リリース ノート、およびマシン ノートは、製品がインストールされているディレク
トリの中にあります。次の表で、これらのファイルを説明します。
UNIX のみ
UNIX プラットフォームでは、以下のオンライン ファイルが
$INFORMIXDIR/release/en_us/0333 ディレクトリにあります。
オンラインファイル
内容
ids_ddi_docnotes_9.40.html
これはこのマニュアルのバージョン用の ドキュ
メント ノート ファイルで、マニュアルに含まれ
ていない機能、またはマニュアルが出版されてか
ら変更された機能を説明します。
ids_unix_release_notes_9.40.html
リリース ノート ファイルには、以前のバージョ
ンの IBM Informix 製品との相違点、およびこの
相違点が現行の製品に与える影響が記載されてい
ます。このファイルには、問題点、および対処方
法も含まれます。
ids_machine_notes_9.40.txt
マシン ノート ファイルには、コンピュータで
IBM Informix 製品を設定および使用するために必
要な作業が記載されています。マシン ノートに
は、製品と同じ名前が付いています。
序
xv
UNIX のみ の終り
Windows のみ
次の項目が Informix フォルダの中にあります。このフォルダを表示するには、タス
ク バーで「スタート」→「プログラム」→「Informix」を選択します。
プログラム グループの項目
説明
ドキュメント ノート
これはドキュメント ノートで、マニュアルに対
する追加項目、または削除された項目を説明しま
す。また、マニュアルに含まれていない機能、ま
たはマニュアルが出版されてから変更された機能
についても説明します。
リリース ノート
この項目には、以前のバージョンの IBM Informix
製品との相違点、およびこの相違点が現行の製品
に与える影響が記載されています。このファイル
には、問題点、および対処方法も含まれます。
マシン ノートは Windows プラットフォームには適用されません。
Windows のみ の終り
v エラー メッセージ。
UNIX のみ
UNIX でエラー メッセージを読むには、finderr コマンドを使用して、エラー メッ
セージをオンラインで表示できます。
UNIX のみ の終り
Windows のみ
Windows 環境でエラー メッセージ、および対処方法を表示するには、「Informix
Error Messages」→「utility」を使用します。このユーティリティを表示するには、
タスク バーで「スタート」→「プログラム」→「Informix」を選択します。
Windows のみ の終り
xvi
IBM Informix: データベース設計および実装 ガイド
参考文献
データベース サーバおよびオペレーティング システムのプラットフォームの概要を示
す資料のリストについては、「IBM Informix: スタートアップ ガイド」を参照してくだ
さい。
業界標準への対応
米国規格協会 (ANSI) は、SQL のための一連の業界標準を確立しました。
IBM Informix SQL を基にした製品は、ISO 9075:1992 と同等の ANSI X3.135-1992 で
公開された SQL-92 基本レベルに準拠しています。また、Informix データベース サー
バの機能の多くは、SQL-92 中間レベル、完全レベル、X/Open SQL CAE (共通アプリ
ケーション環境) 標準に準拠しています。
序
xvii
xviii
IBM Informix: データベース設計および実装 ガイド
第 1 部 データベース設計と実装の基本
© Copyright IBM Corp. 1996, 2003
1
2
IBM Informix: データベース設計および実装 ガイド
第 1 章 データベースの計画
本章の概要
本章では、データベース管理者 (DBA) がデータベースを効果的に計画するために理解
する必要のある問題について説明します。データベースのデータ モデルを選択する方
法、ANSI 標準準拠データベースの使用法、およびデータベースのカスタマイズ済み言
語処理環境の使用法について説明します。
データベースのデータ モデルの選択
IBM Informix 製品を使用してデータベースを作成する前に、どのようなデータ モデル
を使用してデータベースを設計するかを決める必要があります。このマニュアルでは、
次のデータベース モデルについて説明します。
v リレーショナル データ モデル
このデータ モデルは、オンライン トランザクション処理 (OLTP) のデータベース設
計の代表的なモデルです。 OLTP は、非常に小さなトランザクションを 1 つも失う
ことなく処理することを目的にしています。 OLTP データベースは日常的な業務上
の要件に対応するように設計されており、データベースの性能はそのような要件に合
わせて調整されています。このマニュアルの 1 ページの『第 1 部 データベース設計
と実装の基本』では、OLTP 用のリレーショナル データ モデルを作成して実装する
方法について説明しています。 75 ページの『第 2 部 データベースの管理』では、
データベースを管理する方法について説明しています。
Dynamic Server
v オブジェクト リレーショナル データ モデル
オブジェクト リレーショナル データベースは基本的なリレーショナル設計の原理を
採用していますが、リレーショナル データベースの機能を拡張するための拡張デー
タ型、ユーザ定義ルーチン、ユーザ定義キャスト、およびユーザ定義集合などを含ん
でいます。このマニュアルの 125 ページの『第 3 部 オブジェクト リレーショナル
データベース』 では、Dynamic Server の拡張機能を使用してデータベースに格納で
きるデータの種類を拡張し、データの編成およびアクセスをより柔軟に行う方法につ
いて説明しています。
Dynamic Server の終り
v 次元データ モデル
このデータ モデルは、通常、一種のデータ ウェアハウスであるデータ マートを作
成するために使用されます。データ ウェアハウジング環境では、データベースはデ
© Copyright IBM Corp. 1996, 2003
3
ータの抽出と分析のために最適化されています。このような情報処理の種類を、
OLAP (Online Analytical Processing : オンライン分析型処理)、または意思決定支援処
理といいます。このマニュアルの 181 ページの『第 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 オブジェクトへのアクセス権とアクセス
ANSI 規格では、表やシノニムなどのオブジェクトへのアクセス権とアクセスについ
て規定しています。
v 名前排他設定
ANSI 表命名規則により、複数のユーザが 1 つのデータベースで名前の不一致を心配
せずに表を作成できます。
v トランザクション排他設定
Dynamic Server
v データ復旧
4
IBM Informix: データベース設計および実装 ガイド
ANSI 標準準拠データベースは、Dynamic Server のバッファなしログおよび自動トラ
ンザクションを強制します。
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 標準
準拠データベースでは、すべての文が自動的にトランザクションに含まれるため、
BEGIN WORK 文が不要です。トランザクションの終わりは示す必要があるので、
COMMIT WORK または ROLLBACK WORK 文を使用して示します。
トランザクションについて詳しくは、 61 ページの『第 4 章 リレーショナルデータモデ
ルの実装』 および「IBM Informix: SQL ガイド: チュートリアル 」を参照してくださ
い。
第 1 章 データベースの計画
5
トランザクション ログ機能
ANSI 標準準拠データベースは、バッファなしトランザクション ログ機能付きで実行さ
れます。 ANSI 標準準拠データベースでは、ロギング モードをバッファ付きログに変
更することや、ログ機能をオフにすることはできません。
Dynamic Server
ANSI 標準準拠でないデータベースは、バッファ付きログ機能付き、またはバッファな
しログ機能付きで実行できます。バッファなしログではより広範囲なデータ復旧を利用
でき、バッファ付きログではより優れた性能を利用できます。
Dynamic Server の終り
Extended Parallel Server
ANSI 標準準拠でないデータベースは、バッファなしログ機能付きでのみ実行できま
す。バッファなしログではより広範囲なデータ復旧を利用できます。
Extended Parallel Server の終り
詳しくは、「IBM Informix: SQL ガイド: 構文 」にある CREATE DATABASE 文の説
明を参照してください。
所有者名の指定
ANSI 標準準拠データベースでは、所有者名の指定が強制されます。 SQL 文でオブジ
ェクト名を指定するとき、ANSI 標準では、そのオブジェクトの所有者でない限り、名
前に owner というプレフィックスを組み込む必要があります。 owner と name の組合
せは、そのデータベース内で固有である必要があります。そのオブジェクトの所有者で
あれば、データベース サーバはそのユーザ名をデフォルトとして提供します。
ANSI 標準準拠でないデータベースは、所有者名の指定を強制しません。
詳しくは、「IBM Informix: SQL ガイド: 構文 」の『所有者名セグメント』を参照して
ください。
オブジェクトへのアクセス権
ANSI 標準準拠データベースと ANSI 標準準拠でないデータベースでは、データベース
内で表を作成した場合に、デフォルトによって表レベルのアクセス権を付与されるユー
ザが異なります。 ANSI 標準の規定では、データベース サーバは表レベルのアクセス
権を表の所有者だけに (DBA″ 12> と異なる場合は DBA にも) 付与します。しかし、
ANSI 標準準拠でないデータベースでは、アクセス権は public に付与されます。さら
に、データベース サーバでは、ANSI 標準にはない表レベルの 2 つのアクセス権、
Alter と Index を提供します。
6
IBM Informix: データベース設計および実装 ガイド
ユーザ定義ルーチンを実行するには、そのルーチンの Execute アクセス権を持っている
必要があります。 ANSI 標準準拠データベースで所有者アクセス権付きルーチンを作成
すると、そのユーザ定義ルーチンの所有者だけが Execute アクセス権を持ちます。
ANSI 標準準拠でないデータベースで所有者アクセス権付きルーチンを作成すると、デ
ータベース サーバはデフォルトにより public に Execute アクセス権を付与します。
アクセス権について詳しくは、 95 ページの『第 6 章 データベース サーバのアクセス
権の付与と制限』、および「IBM Informix: SQL ガイド: 構文 」にある GRANT 文の
説明を参照してください。
デフォルトの排他レベル
データベースの排他レベルでは、使用しているプログラムがほかのプログラムの並行動
作から分離される程度を規定します。すべての ANSI 標準準拠データベースに対するデ
フォルトの排他レベルは、繰返し可能読込みです。ログを使用する ANSI 標準準拠でな
いデータベースのデフォルトの排他レベルは、確定読込みです。ログを使用しない
ANSI 標準準拠でないデータベースのデフォルトの排他レベルは、非確定読込みです。
排他レベルについては、「IBM Informix: SQL ガイド: チュートリアル 」、および
「IBM Informix: SQL ガイド: 構文 」にある SET TRANSACTION 文と SET
ISOLATION 文の説明を参照してください。
文字 (CHARACTER) 型
データベースが ANSI 標準準拠でないとき、文字 (CHAR) 型フィールド (文字 (CHAR)
型、文字 (CHARACTER) 型、各国語文字 (NCHAR) 型、各国語可変長文字
(NVARCHAR) 型、可変長文字 (VARCHAR) 型、可変長文字 (CHARACTER
VARYING) 型) に、指定されたフィールド長を超える文字列が入力されても、エラーが
出されません。データベース サーバは余分な文字を切り捨てるだけで、エラー メッセ
ージを表示しません。したがって、挿入または更新された値が n バイトを超えている場
合、CHAR(n) 列または変数のデータの意味整合性は強制されません。
ANSI 標準準拠データベースでは、文字 (CHAR) 型フィールド (文字 (CHAR) 型、文字
(CHARACTER) 型、各国語文字 (NCHAR) 型、各国語可変長文字 (NVARCHAR) 型、
可変長文字 (VARCHAR) 型、可変長文字 (CHARACTER VARYING) 型) に、指定され
たフィールド幅を超える文字列が入力された場合、エラーが出されます。
10 進数 (DECIMAL) 型
ANSI 標準準拠データベースでは、10 進数 (DECIMAL) 型に小数点以下桁数は使用され
ません。小数点以下桁数は 0 と見なすことができます。
エスケープ文字
ANSI 標準準拠データベースでは、エスケープ文字はパーセント (%) とアンダスコア
(_) だけをエスケープできます。エスケープ文字を使用して、そのエスケープ文字自体
をエスケープすることもできます。エスケープ文字について詳しくは、「IBM Informix:
SQL ガイド: 構文 」にある『条件セグメント』を参照してください。
第 1 章 データベースの計画
7
カーソルの動作
データベースが ANSI 標準準拠でない場合は、SELECT 文の UPDATE カーソルを宣言
するときに FOR UPDATE キーワードを使用する必要があります。また、SELECT 文は
次の条件を満たす必要があります。
v 単一の表から選択する。
v 集計関数を含まない。
v DISTINCT、GROUP BY、INTO TEMP、ORDER BY、UNION、または UNIQUE 節
およびキーワードを含まない。
ANSI 標準準拠データベースでは、カーソルを宣言するときにキーワード FOR
UPDATE を明示的に使用する必要はありません。 ANSI 標準準拠データベースでは、
すべてのカーソルは、前掲の箇条書きの制約を満たす場合、潜在的に 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 を
使用してプライベート シノニムを示そうとしたりすると、エラーが発生します。
詳しくは、「IBM Informix: SQL ガイド: 構文 」にある CREATE SYNONYM 文の説
明を参照してください。
既存のデータベースが ANSI 標準準拠であるかの判断
次のリストでは、データベースが ANSI 標準準拠であるかどうかを判別するための方法
を 2 つ紹介します。
v データベース sysmaster から、次の文を実行できます。
SELECT name,is_ansi FROM sysmaster:sysdatabases
8
IBM Informix: データベース設計および実装 ガイド
この問合せの結果、データベース サーバ上のデータベースごとに、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 データに英語以外の文字
v ユーザ指定のオブジェクト名に英語以外の文字
v ASCII コード セット以外のソート順序および照合順序に対する準拠
v 辞書や電話帳などで使用される、地域固有の照合順序およびソート順序
GLS 環境変数の説明、および米国英語 (U.S. English) 以外の環境を実装する方法の詳細
については、「IBM Informix: GLS ユーザーズ ガイド 」を参照してください。
第 1 章 データベースの計画
9
10
IBM Informix: データベース設計および実装 ガイド
第 2 章 リレーショナル データ モデルの作成
本章の概要
リレーショナル データベースを作成する最初の手順は、データ モデルを作成すること
です。データ モデルの作成とは、格納する必要のあるデータを正確かつ完全に定義する
ことです。本章では、データをモデル化する方法の概要を説明します。データ モデルの
列固有のプロパティの定義については、 39 ページの『第 3 章 データ型の選択』を参照
してください。本章で説明されるデータ モデルの実装方法を理解するには、 61 ページ
の『第 4 章 リレーショナルデータモデルの実装』を参照してください。
本章の内容を理解するには、SQL とリレーショナル データベース理論に関する基礎知
識が必要です。
データ モデルの作成
データベースを構成するデータの型や必要な編成方法について、すでに何らかの構想を
持っているとします。この情報が、データ モデルを作成する出発点です。形式化された
表記を使用してデータ モデルを作成すると、次の点で役に立ちます。
v データ モデルについて徹底的に考えることができる。
通常、直感的なモデルには、あいまいな点や検討が済んでいない仮定が含まれていま
す。設計を形式化した場合は、これらの仮定が見つかります。
v 他の人でもその設計が理解しやすくなる。
形式化された記述はモデルを明確にするので、他の人が同じ形式でコメントや意見を
述べることができます。
実体 - 関係データ モデルの概要
データのモデル化の形式化された方法には、複数の方法が存在します。それらのどの方
法を使用しても完全で正確なモデル化ができます。何らかの方法を知っている場合は、
ぜひそれを使用してください。
本章では、E-R (entity-relationship: 実体 - 関係 ) データ モデルの概要を説明します。
E-R データ モデル化の方法では、次の手順を使用します。
1. 主なデータベース オブジェクト (実体、関係、および属性) を識別し定義する。
2. E-R アプローチを使用してデータ オブジェクトを図式化する。
3. E-R データ オブジェクトを関係型構造体に変換する。
4. 論理データ モデルを解決する。
© Copyright IBM Corp. 1996, 2003
11
5. 論理データ モデルを正規化する。
本章では、手順 1 から 5 までを説明します。論理データ モデルを物理スキーマに変換
する最終的な手順については、第 4 章で説明されています。
データ モデル化の最終的な結果は、個人用住所録の最終的な表のセットを示す 36 ペー
ジの図 21 と同様のダイヤグラムでエンコードされた、完全に定義されたデータベース
設計となります。この個人用住所録は、本章で例として作成します。これは、1 つの章
で完全に作成できるほどの小さいサイズであり、かつ全体の方法を示すには十分大きな
サイズであるため、デモンストレーション データベースでなくこの住所録を使用しま
す。
主なデータ オブジェクトの識別と定義
データ モデルを作成するには、最初に、主なデータ オブジェクト (実体、関係、およ
び属性) を識別して、定義します。
実体の識別
実体とは、ユーザにとって最も重要であるデータ オブジェクトです。通常、実体はデー
タベースに記録される人、場所、物、事柄などです。データ モデルを言語とした場合、
実体は名詞に相当します。ご使用のソフトウェアに備わっているデモンストレーション
データベースには、customer、orders、items、stock、catalog、cust_calls、call_type、
manufact、および state という実体が含まれています。
実体の選択
データベースについてすぐにいくつかの実体をリストできるはずです。識別可能なすべ
ての実体の予備的なリストを作成します。データベースのユーザとなる可能性のある人
に、データベースに記録すべき事柄について意見を聞くためインタビューを行います。
実体ごとに、「1 つの名前に少なくとも 1 つの住所を関連付ける」などの基本的な特性
を決定します。実体に関して行った決定はすべて、ビジネス ルールとなります。本章で
は、14 ページの住所録の例で、そのビジネス ルールをいくつか示します。
その後、データ モデルを正規化して、実体のいくつかを拡張したり、ほかのデータ オ
ブジェクトにしたりすることができます。詳しくは、34 ページの『データ モデルの正
規化』を参照してください。
実体リスト
実体リストが完成したと思われる場合は、そのリストを調べて各実体が次の特性を持っ
ていることを確認してください。
v 重要である。
データベースのユーザにとって重要で、かつ時間と費用をかけてコンピュータで処理
するだけの価値がある実体のみを取り上げます。
v 一般性がある。
12
IBM Informix: データベース設計および実装 ガイド
個々の実体ではなく、類型のみを取り上げます。たとえば、交響曲は実体ですがベー
トーベンの第 5 交響曲は実体のインスタンスまたは実体のオカレンスです。
v 基本的である。
その実体の説明にほかの実体を必要とせず、独立して存在するもののみを実体として
取り上げます。それを説明するのに何か特徴や記述といったものがほかに必要なもの
は、独立した実体ではありません。たとえば部品番号は、部品と呼ばれる基本実体の
1 つの特徴です。また、他の実体から導出できるものも、実体として取り上げないで
ください。たとえば、合計や平均などの量は SELECT 文で式を使用すれば計算でき
ます。
v 単一のものである。
命名した各実体がそれぞれ単一のクラスを表しているかを確認してください。 1 つ
の実体を、それぞれ固有の特徴を持つ下位のカテゴリに分類することはできません。
14 ページの図 1 の住所録の例では、電話番号は明らかに簡単な実体であり、それぞ
れが異なる特徴を持つ 3 つのカテゴリで実際に構成されています。
これらの条件に合う実体を選ぶことは、決して簡単ではなく、機械的に選ぶことはでき
ません。最善の選択を見つけるには、データベースに格納したいデータの性質について
慎重に検討する必要があります。このような検討を行うことによって、適切なデータ モ
デルを作成することができます。次の節で、住所録の例を詳細に説明します。
住所録の例
例として、個人用の住所録のためのデータベースを作成することを考えてみます。この
データベースのモデルに格納すべき情報は、データベースのユーザが必要とする人と組
織の名前、住所、電話番号です。
最初に実体を定義します。住所録のページをよく調べて、どんな実体があるかを識別し
ます。14 ページの図 1 は、住所録のページの例です。
第 2 章 リレーショナル データ モデルの作成
13
図 1. 住所録の一部
既存のデータの物理的な形は、誤解を招くことがあります。住所録のページおよびエン
トリのレイアウトに惑わされて、住所録の 1 つのエントリを 1 つの実体として指定し
ないように注意してください。住所録では、名前、番号、および住所のフィールドから
なるレコードがアルファベット順に並んでいます。モデル化するのはデータであって、
データの集まりではありません。
実体は一般的で重要か: 見たところ、住所録に記録されている実体には次の項目が
含まれています。
v 人や組織の名前
v 住所
v 電話番号
これらの実体は、前述の基準を満たしているでしょうか。モデルにとって重要であり、
一般性があることは明らかです。
実体は基本的か: 各実体は、他の実体に影響を与えずに個数を変化させることができ
ます。この事実は、基本的かどうかの判定に使用できます。引っ越したり仕事を変えた
14
IBM Informix: データベース設計および実装 ガイド
りしたために電話番号や現住所を持たない人も住所録に記載される場合があります。ま
た、住所録には、複数の人が使用している住所と電話番号が記載されていることもあり
ます。名前、住所、電話番号の 3 つの実体はどれも、独立して個数を変化させることが
できます。これは、これらの実体が基本的であり、他のデータ依存していないことを示
しています。
実体は単一か: 名前は個人名と会社名に分類することができます。このモデルではど
の名前も特に区別しないことにしました。つまり、会社の情報も個人の情報も同じよう
に扱うことにしました。同様に住所も、自宅の住所と会社の住所を区別して扱わずに、1
種類と見なすことにしました。
ただし、複数の種類の電話番号があることになります。人が応答する通常の電話番号、
ファックスにつながるファックス番号、コンピュータにつながるモデム番号です。各種
類の番号について異なる情報を記録することにします。つまり、この 3 種類が異なる実
体となります。
住所録の例では、次の実体を記録することに決定しました。
v 名前
v 住所 (郵送先)
v 電話番号
v ファックス番号
v モデム番号
実体の図式化
E-R ダイヤグラムの使用方法については、本章で後述します。まず、住所録の例の各実
体ごとに長方形ボックスを作成します (図 2 を参照)。 23 ページの『データ オブジェ
クトの図式化』に、実体を関係と結び付ける方法を示してあります。
図 2. 住所録の例における実体
関係の定義
データベースの実体を選択したら、その実体間の関係を考える必要があります。関係は
必ずしも明確ではありませんが、記録する価値のあるものをすべて見つけなければなり
ません。確実にすべての関係を見つけるには、考えられる関係をすべてリストする以外
にありません。実体 A と実体 B のすべてのペアを想定し、「A と B の間にはどのよ
うな関係があるか」について考えます。
第 2 章 リレーショナル データ モデルの作成
15
関係とは、2 つの実体の間の関連です。通常、関係は 2 つの実体を結ぶ動詞や前置詞の
中に含まれます。実体間の関係は、接続性、存在の依存性、および多重度という言葉で
説明されます。
接続性
接続性とは、実体のインスタンスの数を意味します。実体のインスタンスは、実体の特
定のオカレンスです。図 3 に示すように、接続性には 1 対 1 (1:1)、1 対多 (1:n)、多
対多 (m:n) の 3 種類があります。
図 3. 関係における接続性
たとえば住所録の例では、住所は複数の名前と関連がある場合があります。住所の実体
と名前の実体との関係の接続性は、1 対多 (1:n) です。
存在の依存性
存在の依存性は、関係における実体が任意であるか、必須であるかを示します。ビジネ
ス ルールを分析して、実体が関係に存在しなければならないかどうかを確認します。た
とえば、1 つの名前には 1 つの住所が関連付けられていなくてはならないというビジネ
ス ルールがあるとします。このような関連は、名前と住所の実体の間の関係に存在の依
存性が必須であることを示します。存在の依存性が任意である例として、ある人の子供
のあるなしというビジネス ルールを挙げることができます。
多重度
多重度は、実体が関係に現れる回数に制約を適用します。 1 対 1 の関係の多重度は、
常に 1 です。これに対して、1 対 n の関係の多重度は不定です。n は任意の数でかま
いません。 n に上限を設ける必要がある場合は、その関係に多重度を指定します。たと
えば、店舗販売の例では、顧客が 1 回で買える品物の数の上限を指定すると考えられま
す。通常、多重度の制約はアプリケーション プログラムまたは (SPL) を使用して指定
します。
関係の発見
実体間の関係を発見する方法としては、マトリックス形式で 2 つの実体の組合せをリス
トした表を作成するのが便利です。 図 4 のマトリックスは、個人用住所録の実体を反
映しています。
16
IBM Informix: データベース設計および実装 ガイド
図 4. 個人用住所録の実体のマトリックス
マトリックス内の陰をつけた部分は無視することができます。対角線上のセルは検討を
要します。つまり、「A と別の A の間にはどのような関係があるか」を考える必要が
あります。このモデルの場合、その答えは必ず、「関係は 1 つもない」になります。名
前どうしや住所と他の住所の間には関係がありません。少なくとも、このモデルでは記
録する必要があるものは何もありません。 A と別の A の間に関係がある場合は、再帰
的な関係があります。 (33 ページの『その他の特別な関係の解決』を参照してくださ
い。)
関係がないことがはっきりしたすべてのセルについて、マトリックスに「なし」と記入
します。 図 5 に、記入後のマトリックスを示します。
第 2 章 リレーショナル データ モデルの作成
17
図 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 対多と多対多の関係を示しま
す。
18 ページの図 5 に示すように、最初の空白のセルは、名前と住所の間の関係を示して
います。名前と住所という実体の間には、どのような接続性があるでしょうか。「1 つ
の住所にいくつの名前を関連付けることができるか」について考えた結果、名前は住所
を持たない か、またはただ 1 つ の住所を持つことにします。 図 6 に示すように、名
前の向かい側、住所の下に 0-1 と記入します。
18
IBM Informix: データベース設計および実装 ガイド
図 6. 名前と住所の関係
次に、1 つの名前にいくつの住所が関連しているかを考えます。住所は複数の名前と関
連があるということにします。たとえば、同じ会社に勤める人を何人か知っているかも
しれませんし、同じ住所に住んでいる人を複数知っているかもしれません。
住所と関係する名前の数がゼロ という場合はあり得るでしょうか。すなわち、住所だけ
が存在し、その住所に対する名前が存在しないということはあるでしょうか。この場合
は、あり得ると決定しました。 図 7 に示すように、住所の下、名前の向かい側に 0-n
と記入します。
図 7. 住所と名前の関係
関連付けられた名前が 1 つもない住所は存在しないと決定した場合は、0-n ではなく
1-n と記入します。
関係する要素の多重度 (個数) がどちらか一方の実体の側で最大 1 に制限される場合
は、1:n の関係になります。この場合、名前と住所の関係は 1:n の関係です。
ここで、18 ページの図 5 にある次のセルについて検討します。つまり、名前と電話番
号との関係です。1 つの名前と関係する可能性がある電話番号は 1 つだけでしょうか、
それとも 2 つ以上関係することがあるでしょうか。住所録を見ると、一人に対して複数
の電話番号を記入している箇所が見受けられます。多忙なセールス担当者の場合は、自
宅の電話番号、会社の電話番号、ポケット ベルの番号、自動車電話番号などが記入され
第 2 章 リレーショナル データ モデルの作成
19
ています。しかし、電話番号のない名前もあります。 図 8 に示すように、名前の向か
い側、番号 (電話) の下に 0-n と記入します。
図 8. 名前と電話番号の関係
次に、逆方向の関係を検討します。各電話番号と関係する可能性がある名前は、いくつ
あるでしょうか。電話番号には、1 つの名前のみ関係していると決定しました。電話番
号と関係する名前の数がゼロという場合はあり得るでしょうか。誰にも使用されていな
い電話番号を記録する必要はないと決定しました。 図 9 に示すように、番号 (電話) の
下、名前 の向かい側に 1 と記入します。
図 9. 電話番号と名前の関係
以下の要因を考慮して、マトリックスの残りの部分も同じように記入します。
v 名前は、複数のファックス番号と関係する可能性があります。たとえば、会社にはい
くつかのファクシミリがあることがあります。逆に考えると、各ファックス番号は、
複数の名前と関係する可能性があります。たとえば、同じファックス番号を複数の人
が使用することがあります。
v 各モデム番号が関係する名前は、ちょうど 1 つでなければなりません。 (これは意図
的に決めたものです。設計の要件の 1 つと考えてください。) これに対し各名前は、
複数のモデム番号と関係する可能性があります。たとえば、会社のコンピュータは複
数のダイヤル回線に接続されることがあります。
v 電話番号と住所の間には、現実には何らかの関係がありますが、このモデルでは特に
注意するような関係はありません。すでに、間接関係が名前を介して存在していま
す。
20
IBM Informix: データベース設計および実装 ガイド
図 10 に、完成したマトリックスを示します。
図 10. 完成した住所録のマトリックス
マトリックスに示されたそのほかの決定は、ファックス番号とモデム番号、電話番号と
ファックス番号、電話番号とモデム番号それぞれの間に関係が存在しないということで
す。
電話番号とモデム番号の間の関係をサポートしないことなど、こうした決定の一部には
賛成できないものもあるでしょう。しかし、この例では、上記をビジネス ルールとしま
す。
関係の図式化
まず、本節で作成したマトリックスを保存しておきます。 E-R ダイヤグラムの作成方
法については、23 ページの『データ オブジェクトの図式化』で学習します。
属性の識別
実体には、特性や修飾子、品質、数量、機能としての属性が含まれています。属性は、
実体に関する事実または分割できない情報です。実体を表として表現するときに、実体
の属性を新しい列としてモデルに追加します。
実体を識別して初めて、データベース属性が識別できます。実体を決定したら、「各実
体についてどのような特性を知る必要があるか」について考えます。たとえば、実体が
住所の場合は、番地、市区町村、および 郵便番号に関する情報が必要でしょう。住所と
いう実体に関するこれらの特性それぞれが属性となります。
第 2 章 リレーショナル データ モデルの作成
21
実体の属性の選択
属性を選ぶときは、次の条件を満たすものを選んでください。
v 重要性が高いこと
データベースのユーザにとって重要な属性のみを選んでください。
v 直接的であり、導出的ではないこと
たとえば、SELECT 文の記述から導出できるような、既存の属性から導出できる属性
がモデルの一部であってはなりません。データが導出されると、データベースの保守
が複雑になります。
この後の設計段階では、性能改善のために導出される属性の追加を検討する場合があ
ります。しかしこの段階では、導出される属性は除外します。データベース サーバ
の性能を向上させる方法については、「IBM Informix: パフォーマンス ガイド 」を
参照してください。
v 分割できないこと
属性は 1 つの値のみを含むもので、リストや繰り返されるグループを含んだもので
あってはなりません。複合的な値は、個々の属性に分けなければなりません。
v 同じタイプのデータを含んでいること
たとえば、誕生日という属性には日付の値のみを入れて、名前や電話番号入れないは
ずです。
属性の定義方法のルールは、列の定義方法のルールと同じです。列の定義方法の詳細に
ついては、28 ページの『列への制約の適用』を参照してください。
次の属性を住所録の例に追加して、26 ページの図 15に示すようなダイヤグラムを作成
します。
v 住所の実体には、番地、市区町村、都道府県、および郵便番号を追加します。
v 名前の実体には、誕生日、電子メール アドレス、記念日、および子供の名前を追加
します。
v 電話番号の実体には、自動車電話、自宅の電話、および勤務先の電話を区別するため
のタイプを追加します。 1 つの電話番号は、1 つの電話のみに関係します。
v ファックスの実体には、ファクシミリが受信可能な時間帯を追加します。
v モデムの実体には、9,600、14,400、28,800 など、モデムがサポートするボー レート
を追加します。
属性のリスト
ここでは、住所録の例について、必要と思われる実体とともに属性をリストします。 図
11 のようなリストになります。
22
IBM Informix: データベース設計および実装 ガイド
図 11. 住所録の例の属性
実体のオカレンスについて
追加のデータ オブジェクトは、実体のオカレンス (発生数) です。表の各行は、実体の
特定の単一のオカレンスを表しています。たとえば、顧客が実体である場合、顧客表は
顧客の概念を表します。その表では、各行は、たとえば Sue Smith という 1 人の特定
の顧客を表します。実体は表に、属性は列に、実体のオカレンスは行になることを覚え
ておいてください。
データ オブジェクトの図式化
これで、データベース内の実体と関係を理解しました。これは、リレーショナル データ
ベースの設計プロセスで最も重要なことです。実体と関係が決まると、データベース設
計中の思考過程を表す方法が役に立つことがあります。
多くのデータ モデル化の方法で、実体と関係をグラフィカルに表示できます。
IBM Informix のマニュアルでは、C. R. Bachman が開発した E-R ダイヤグラム アプ
ローチが使用されています。 E-R ダイアグラムには次の目的があります。
v 組織の情報ニーズをモデル化する。
v 実体とその関係を示す。
v データ定義 (データ フロー ダイヤグラム) の出発点となる。
v アプリケーション開発者のみならず、データベース管理者やシステム管理者にとって
文書化のためのすぐれた資料となる。
v 物理スキーマに変換できるデータベースの論理設計を作成する。
E-R ダイアグラムにはいくつかのスタイルがあります。好みのスタイルがある場合は、
それを使用してください。 図 12 に、E-R ダイアグラムのサンプルを示します。
第 2 章 リレーショナル データ モデルの作成
23
図 12. 実体 - 関係ダイヤグラムの記号
E-R ダイアグラムでは、ボックスが実体を表します。線は、実体と実体をつなぐ関係を
表します。また、図 13 に、次の性質の関係を表す場合のグラフィック記号の使い方を
示します。
v 接続関係を表す線上の円は、その関係が任意であることを示します。インスタンスが
ゼロの場合があります。
v 接続関係を表す線上の短い棒線は、その実体のちょうど 1 つのインスタンスがほか
の実体に関連付けられていることを示します。棒線は 1 とみなします。
v カラスの足跡は、関係が多数あることを示します。
図 13. 実体 - 関係ダイヤグラムにおける関係の部分
E-R ダイアグラムの読取り
E-R ダイヤグラムは、まず左から右に、次に右から左に読んでいきます。 図 14 にある
名前と住所の関係の場合は、次のように関係を読み取ります。名前は、ゼロまたは正確
に 1 つの住所に関連付けることができます。また、住所は、ゼロ、1 つ、または多数の
名前に関連付けることができます。
24
IBM Informix: データベース設計および実装 ガイド
図 14. 実体 - 関係ダイヤグラムの読み方
住所録の例
図 15 に、実体、関係、および属性を含んだ住所録の例を示します。このダイヤグラム
には、マトリックスを使用して確立する関係が含まれています。ダイアグラムの記号に
ついて学習したら、図 15 の E-R ダイアグラムを 21 ページの図 10 のダイアグラムと
比較してください。両方の図で関係が同じになっているかを確認してください。
21 ページの図 10 に示したようなマトリックスは、それを記入する際、必然的にあり得
るすべての関係を考えなければならないため、初めてモデル設計する場合には有効なツ
ールとなります。ただし、図 15 のように、同じ関係がダイヤグラムに現れる場合は、
この種のダイヤグラムは、既存のモデルを再検討すると読みやすくなります。
第 2 章 リレーショナル データ モデルの作成
25
図 15. 住所録の例における予備的な実体 - 関係ダイアグラム
ダイヤグラムが完成した後に
本章の残りの部分では、以下の作業を実行する方法について説明します。
v 実体、関係、属性を関係構造体に変換する。
v E-R データ モデルを解決する。
v E-R データ モデルを正規化する。
第 4 章に、E-R データ モデルからデータベースを作成する方法を示します。
E-R データ オブジェクトの関係構造体への変換
これまで学習してきたすべてのデータ オブジェクト (実体、関係、属性、および実体の
オカレンス) は、SQL 表、表どうしの結合、列、および行に変換されます。データベー
スの表、列、行は、27 ページの『表、行、列の定義』 に示すルールに従っていなけれ
ばなりません。
データ オブジェクトを正規化する前に、それがこれらのルールを満たしていることを確
認してください。データ オブジェクトを正規化するには、実体、関係、および属性の間
の依存性を分析します。正規化については、34 ページの『データ モデルの正規化』で
説明しています。
26
IBM Informix: データベース設計および実装 ガイド
データ モデルを正規化した後は、SQL 文を使用してデータ モデルに基づくデータベー
スを作成することができます。住所録の例のデータベースを作成し、データベース スキ
ーマを指定する方法については、第 4 章で説明します。
選択した各実体は、モデルにおける表として示されます。表は、抽象概念としての実体
を意味しており、各行は実体の特定の個別オカレンスを表します。さらに、実体の各属
性は表の列で表されます。
以下に E-R データ モデルを含む大部分の関係データ モデル法の基本的な考えかたを
示します。データ モデル設計時にこれらのルールに従って、モデルを正規化するときの
時間と労力を節約してください。
表、行、列の定義
行と列からなる表の概念についてよく理解していることと思います。しかし、正式なデ
ータ モデルの表は下記のルールが要求されます。
v 各行は独立していていなければならない。
表の各行は独立していて、同じ表のほかの行に依存することはありません。したがっ
て、表の内部での行の順番は、モデルでは意味がありません。表のすべての行をラン
ダムな順番に並び替えたとしても、モデルは正しいはずです。
データベースを実装した後では、性能を上げるためにデータベース サーバに要求し
て特定の順序で行を保存することができますが、その順序はモデルには影響を及ぼし
ません。
v 各行は一意でなければならない。
各行には、必ず一意の値を持つ列がなければなりません。この特性を持つ単一の列が
ない場合は、複数の列の値を組にすることで行を識別できるような列の組合せが存在
しなければなりません。
v 各列は独立していなければならない。
表の内部での列の順番は、モデルでは意味がありません。列を並び替えたとしても、
モデルは正しいはずです。
データベースを実装した後では、すべての列を意味するアスタリスクを使用している
プログラムや格納された問合せは列の最終的な順序に依存しますが、その順序はモデ
ルには影響を及ぼしません。
v 各列の値は 1 つの値でなければならない。
各列が格納できるのは、1 つの値のみで、値の並びや繰り返されるグループは、1 つ
の列には格納できません。複数の要素から合成された値は、個々の列に分離する必要
があります。たとえば、本章の例のように、個人の姓と名前を別々の値として取り扱
うことにした場合、姓と名前は 1 つの名前列に一緒に格納するのではなく、別々の
列に格納しなければなりません。
v 各列は一意の名前を持たなければならない。
第 2 章 リレーショナル データ モデルの作成
27
同じ表の内部の 2 つの列が同じ名前を共有することはできません。ただし同様の情
報を含む列を複数作成することはできます。たとえば、住所録の例の名前表には子供
の名前の列があります。それぞれの列に child1、child2 などと名前を付けることがで
きます。
v 各列は単一の型のデータを含んだものでなければならない。
各列は、同じデータ型の情報を格納しなければなりません。たとえば、整数
(INTEGER) 型で示される列には、名前からの文字ではなく数値情報のみを格納しなけ
ればなりません。
配列や順次ファイルとして構成されたデータを扱った経験しかない場合は、これらのル
ールは不自然に思えるかもしれません。しかし、リレーショナル データベースの理論で
は、すべての型のデータは、これらのルールに従った表、行、列のみを使用して表すこ
とができます。多少経験を積めば、これらのルールを機械的に適用できるようになりま
す。
列への制約の適用
CREATE TABLE 文を使用して表と列を定義する場合、各列に制約を加えます。これら
の制約は、列に文字と数のどちらを入れるか、使用する日付の形式などの条件を指定し
ます。属性が想定できるような一式の有効値をドメインで識別する場合は、ドメインに
制約を記述します。
ドメインの特性
表を作成する場合、ドメインの特性を定義します。列には、次のドメイン特性を指定で
きます。
v データ型 (整数 (INTEGER) 型、文字 (CHAR) 型、日付 (DATE) 型など)
v フォーマット (たとえば、yy/mm/dd)
v 範囲 (たとえば、1,000∼5,400)
v 意味 (たとえば、個人の電話番号)
v 許容値 (たとえば、等級 S または U のみ)
v 一意性
v NULL のサポート
v デフォルト値
v 参照制約
ドメインの定義方法については、第 3 章を参照してください。表とデータベースの作成
方法については、第 4 章を参照してください。
表のキーの決定
表の列はキー列か、または記述子列のいずれかです。キー列とは、表の内部の特定の行
を一意に識別する列です。たとえば、社会保障番号は各社員に一意です。記述子列は、
28
IBM Informix: データベース設計および実装 ガイド
表の特定の行の一意ではない特性を指定します。たとえば、Sue という同じ姓を持つ社
員が 2 人いる場合を考えます。この Sue という名前は、1 人の社員の一意の特性では
ありません。表におけるキーには、主キーと外部キーという主なタイプがあります。
主キーと外部キーは、表を作成するときに指定します。主キーと外部キーは、表を物理
的に関係づけるために使用します。次の作業は、各表に主キーを指定することです。つ
まり、行のそれぞれを他の行と区別する何らかの定量化できる表の特性を識別する必要
があります。
主キー
表の主キーとは、行ごとに値が異なる列のことです。主キーの値は行ごとに異なるた
め、主キーは各行を一意に識別します。そのような列が存在しない場合は、値の組合せ
が行ごとに異なるような複数の列の複合が主キーになります。
モデルの表はどれも、主キーを持たなければなりません。このルールは、すべての行は
一意でなくてはならないというルールを自動的に導き出します。必要に応じて、すべて
の列で主キーを構成することもできます。
効率性を高めるため、主キーは、数値データ型 (整数 (INT) 型または小桁整数
(SMALLINT) 型)、シリアル (SERIAL) 型、または 8 バイト シリアル (SERIAL8) 型、
あるいは short 型文字列 (コードに使用) である必要があります。主キーとして長い文
字列を使用しないことをお勧めします。
主キー列では NULL は使用できません。 NULL は比較することができません。つまり
NULL については、「同じ」あるいは「異なる」といった比較はできません。したがっ
て、NULL は行を一意に識別することができません。 NULL が使用できる列を主キー
や主キーの一部として使用することはできません。
実体の中には、カタログ番号や身分証明番号のように、モデルの外部で定義された主キ
ーを持つものもあります。場合によっては、複数の列や列のグループが主キーとして使
用できることもあります。主キーとして使用できる列や列のグループを候補キーと呼び
ます。候補キーは一意性という特性により、SELECT 文の結果が予測できるため、注意
する必要があります。
複合キー: 実体によっては、確かな一意性を欠いたものがあります。たとえば、同姓
同名の人がいる場合があります。別々の本の題名が同じである場合もあります。通常、
このような場合は複数の属性を組み合わせて主キーとして使用できます。名前と住所が
同じという人はめったになく、異なる本でもタイトル、著者および発行日が同じという
こともほとんどあり得ないからです。
システム割当てキー: 通常は、複合キーよりシステム割当て主キーのほうが便利で
す。システム割当てキーは、実体の各インスタンスに付けられる数値またはコードで
す。最も簡単に付けることができるシステム割当てキーは、データベースが自動的に生
成することのできるシリアル番号です。 Informix データベース サーバでは、シリアル
第 2 章 リレーショナル データ モデルの作成
29
番号にシリアル (SERIAL) 型および 8 バイト シリアル (SERIAL8) 型を使用します。
しかし、意味のない数値コードは、データベース利用者には現実的とはいえません。そ
のような場合は、実際のデータに基づいたコードをシステム割当てキーとして使用する
こともできます。たとえば、従業員の識別コードは、個人の頭文字と雇用された日付の
数字を組み合わせて示すことができます。住所録の例では、システム割当て主キーは名
前表で使用されています。
外部キー (結合列)
外部キーとは、ほかの表の主キーと一致する値を持つ表の列または列のグループを指し
ます。外部キーは、表を結合するときに使用します。図 16 は、デモンストレーション
データベースの顧客表と注文表の主キーと外部キーです。
図 16. 顧客/注文関係における主キーと外部キー
ヒント: 表のメンテナンスと使用を容易にするためには、関係を容易に理解できるよう
に主キーと外部キーの名前を選択することが重要です。 図 16 では、主キーと
外部キーの両方の列に同じ名前 customer_num が付けられています。また、
図 16 の列が別々の名前を持つように、customer_custnum と
orders_custnum という名前を付けることもできます。
表から行を削除するときは、外部キーによって制約を受けるので、外部キーに注目する
必要があります。行を削除するときには、その前に外部キーを介してその行を参照して
いる行をすべて削除しておくか、1 つの削除コマンドで主キーと外部キーから行を削除
できる特殊な構文を使用して関係を定義しておく必要があります。データベース サーバ
では、参照整合性に違反する削除は行えません。
参照整合性を保持するには、すべての外部キー列を削除してから、その外部キーが参照
している主キーを削除してください。データベースに参照整合性が課されている場合、
対応する外部キーが存在しているときにデータベース サーバは主キーの削除を許可しま
せん。また、既存の主キーの値を参照しない外部キーの値を追加することもできませ
ん。参照整合性については、「IBM Informix: SQL ガイド: チュートリアル 」で説明し
ます。
住所録のダイヤグラムへのキーの追加
図 17 に、主キーと外部キーの初期選択肢を示します。このダイヤグラムは、いくつか
の重要な決定を反映しています。
30
IBM Informix: データベース設計および実装 ガイド
表名前では、主キー rec_num が選択されています。 rec_num のデータ型はシリアル
(SERIAL) 型です。 rec_num の値は、システムが生成します。表名の他の列または属
性を見ると列に関連付けられたデータ型のほとんどは文字型を基準にしたものであるこ
とがわかります。これらの列はどれも、単独では主キー候補として適切ではありませ
ん。表の要素を組み合わせて複合キーを作成すると、キーは複雑になります。シリアル
(SERIAL) 型で提供されたキーを使用すれば、ほかの表を 名前表と結合することもでき
ます。
電話、ファックス、およびモデムの各表では、電話番号は、主キーとして表示されま
す。これらの表は、キー rec_num を介して名前表に結合されます。
住所表も、システムが生成した id_num という主キーを使用しています。ビジネス ル
ールでは、名前が住所を使用していなくても住所は存在し得ることになっているので、
住所表には主キーが必要です。ビジネス ルールで、名前が住所と関係していないかぎ
り、住所は存在できないと定められている場合は、住所表は外部キー rec_num でのみ
名前表と結合することができます。
図 17. 主キーと外部キーを追加した住所録のダイヤグラム
第 2 章 リレーショナル データ モデルの作成
31
関係の解決
適切なデータ モデルの目的は、データベース サーバが迅速にアクセスできるような構
造体を作成することにあります。関係を解決し、データ モデルを正規化することによ
り、住所録のデータ モデルをさらに改善することができます。ここでは、データベース
の関係を解決する方法と、その理由について説明します。データ モデルの正規化につい
ては、34 ページの『データ モデルの正規化』で説明しています。
m:n 関係の解決
多対多 (m:n) の関係は、モデルとアプリケーション開発過程を複雑にするだけでなく混
乱をもたらします。 m:n 関係を解決する鍵は、2 つの実体を分離して、これらの実体の
間に第 3 の交差実体によって 2 つの 1 対多 (1:n) の関係を作成することにあります。
交差実体には、通常、それが接続する両方の実体の属性が含まれます。
m:n 関係を解決するには、ビジネス ルールをもう一度解析します。関係を正確に図式化
しているでしょうか。住所録の例では、31 ページの図 17 に示すように、名前の実体と
ファックスの実体が m:n の関係になっています。このビジネス ルールでは、「一人の
人がゼロ、1 つまたは複数のファックス番号を持つことができる。1 つのファックス番
号は、複数の人が使用することがある」となっています。電話の実体の主キーとして先
に選択したものに基づいて、m:n 関係は存在しています。
主キーとして指定した電話番号は、 ファックスの実体に 2 回以上現れることがあるの
でファックスの実体には問題があります。これは主キーの条件に違反しています。主キ
ーは一意でなければならないことを思い出してください。
この m:n の関係を解決するために、図 18 に示すように、名前の実体とファックスの実
体との間に交差実体を追加できます。新しい交差実体、ファックス名には、fax_num
と rec_num という 2 つの属性が含まれています。実体の主キーは、これら両方の属
性を複合したものです。個別にみると、各属性は属性が由来する表を参照する外部キー
です。名前表とファックス名表との間の関係は、1:n です。1 つの名前が多くのファッ
クス番号と関係することがあり得るからです。一方、各ファックス名の組合せは、1 つ
の rec_num と関係する可能性があります。各番号は複数のファックス名の組合せと関
係し得るのでファックス表とファックス名表との間の関係は 1:n です。
32
IBM Informix: データベース設計および実装 ガイド
図 18. 多対多 (m:n) 関係の解決
その他の特別な関係の解決
上記以外にも、データベースの円滑な実行を妨げる特別な関係があります。これらの関
係には、次のようなものがあります。
v 複雑な関係
v 再帰的関係
v 冗長な関係
複雑な関係とは、3 つ以上の実体間の関係です。関係が存在するには、すべての実体が
存在しなければなりません。この複雑さを軽減するには、すべての複雑な関係を実体と
して再分類し、元の実体のそれぞれに対する 2 進関係に整理します。
再帰的関係とは、同じ型の実体のオカレンス間の関係です。このタイプの関係はよく見
られるものではありません。再帰的関係の例としては、部品表 (パーツがサブパーツで
構成されている) や組織構造 (ある社員が他の社員を管理する) があります。再帰的関係
を解決しないほうを選択することもできます。再帰的関係の詳しい例については、
「IBM Informix: SQL ガイド: チュートリアル 」を参照してください。
冗長な関係は、複数の関係が同じ概念を表す場合に存在します。冗長な関係は、データ
モデルを複雑にし、開発者がデータ モデルの属性を誤って設定する原因にもなります。
この関係は、E-R ダイヤグラムの中で重複した実体として表されます。たとえば、同じ
第 2 章 リレーショナル データ モデルの作成
33
属性を含む 2 つの実体がある場合があります。冗長な関係を解決するには、データ モ
デルを見直します。同じ属性を含んだ実体が 2 つ以上ないでしょうか。冗長性を解決す
るには、モデルに新しい実体を追加する必要があります。「IBM Informix: パフォーマン
ス ガイド 」に、データ モデルの冗長性に関連するトピックがあります。
データ モデルの正規化
本章の住所録は、よいモデル例です。今のままでもこのモデルをデータベースとして実
現することができますが、アプリケーション開発やデータ操作に、後日問題が発生する
可能性があります。正規化とは、属性を実体と関係付けるルールを適用する形式化され
たアプローチです。
データ モデルを正規化すると、以下の目標が達成できます。
v 設計の柔軟性を向上させる。
v 属性を正しい表に入れる。
v データの冗長性を少なくする。
v プログラムの性能を向上する。
v アプリケーションの保守コストを引き下げる。
v データ構造の安定性を最大限に高める。
正規化は、実体をより適切な物理特性にするためのいくつかの手順で構成されていま
す。これらの手順を正規化ルールといいます。正規形と呼ぶこともあります。正規形に
はいくつかあります。本章では、最初の 3 つの正規形を説明します。各正規形は、直前
の形よりも構造性の高いものにするためにデータを制約します。このため、第 2 正規形
を実現するには第 1 正規形を実現し、第 3 正規形を実現するには第 2 正規形を実現し
なければなりません。
第 1 正規形
実体に反復されるグループがない場合、その実体は第 1 正規形となります。したがっ
て、表に反復される列がない場合、その表は第 1 正規形となります。反復列は、データ
の柔軟性を低下させ、ディスク スペースを浪費し、データの探索を困難にします。 図
19 の住所録の例では、名前表に child1、child2、および child3 という反復列が含まれて
います。
34
IBM Informix: データベース設計および実装 ガイド
図 19. 正規化前の実体名前
現行の表にはいくつかの問題点があります。この表は、子供がいるいないに関わらず、
一人につき 3 人の子供を記録するためのディスク スペースを常に確保しておかなくて
はなりません。記録できる子供の最大数は 3 人ですが、4 人以上の子供がいる人もいる
はずです。また、特定の子供を探す場合、各行につき 3 つの列をすべて探索しなければ
なりません。
反復列をなくして、表を第 1 正規形にするには、図 20に示すように表を 2 つに分割し
ます。反復列を表のどちらかに入れます。 2 つの表間の関連付けは主キーと外部キーを
組み合わせて確立されます。名前表と関連付けられていなければ子供はいないことにな
るので、外部キー rec_num で名前表を参照します。
図 20. 実体名前の第 1 正規形
ここで、31 ページの図 17 で第 1 正規形でないグループを確認します。名前表とモデ
ム表 の関係は、b9600、b14400、b28800 列が反復列と考えられるので、第 1 正規形
ではありません。 b9600、b14400、b28800 列のオカレンスを格納するためにモデム
表に新しい列 b_type を追加します。図 21に、第 1 正規形で正規化されたデータ モデ
ルを示します。
第 2 章 リレーショナル データ モデルの作成
35
図 21. 住所録のデータ モデル
第 2 正規形
すべての属性が全体 (主) キーに依存している場合、その実体は第 2 正規形となりま
す。したがって、表中のすべての列はその表の主キー全体に機能的に依存する必要があ
ります。機能的依存性は、2 つの異なる列内の値の間にリンクが存在することを示して
います。
属性値が列に依存する場合、列の値を変更すると属性値も変わります。属性は列の関数
になります。これを具体的に説明すると、以下のようになります。
v 表に 1 列の主キーがある場合、属性はそのキーに依存していなければならない。
v 表に複合主キーがある場合、属性は、1 つまたは数個の列ではなく、全体としてのす
べての列内の値に依存していなければならない。
v 属性が他の複数の列に依存している場合、その列は候補キーの列でなくてはならな
い。つまり、列はすべての行で一意でなければならない。
モデルを第 2 正規形に変換する場合、データの冗長性が発生し、データの変更が困難に
なる可能性があります。第 1 正規形の表を第 2 正規形の表に変換するには、主キーに
依存していない列を削除します。
第 3 正規形
実体が第 2 正規形であり、かつその属性のすべてが主キーに過渡的に依存していない場
合、実体は第 3 正規形となります。過渡的依存性とは、記述子のキー属性が全体主キー
だけでなく、ほかの記述子キー属性にも依存しており、これらのほかの属性も主キーに
36
IBM Informix: データベース設計および実装 ガイド
依存していることを意味します。 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 章 データ型の選択
本章の概要
データ モデルの作成が済んだら、そのデータ モデルをデータベースおよび表として実
装する必要があります。データ モデルを実装するには、最初に、ドメイン、つまりデー
タ値の集合を列ごとに定義します。この章では、列データ型と制約を定義するときに決
定する必要のある事項について説明します。
2 番目の手順では、第 4 章で説明しているように、CREATE DATABASE 文と
CREATE TABLE 文を使用してモデルを実装し、表にデータを追加します。
ドメインの定義
第 2 章で説明したデータ モデルを完全なものとするには、各列にドメインを 1 つ定義
する必要があります。列のドメインは、列に設定されている制約を記述し、属性 (列)
が想定できる一連の有効値を示します。
ドメインを定義するのは、モデルのデータの意味整合性を保護するためです。つまり、
モデルのデータが現実を反映していることを確実にすることです。電話番号を名前に置
き換えたり、整数値のみ有効なデータに小数値を入力したりすることができると、デー
タ モデルの整合性は保証されなくなります。
ドメインを定義するには、制約 を定義します。データ値は、ドメインの一部を構成する
前にこの制約を満たす必要があります。列のドメインを指定するには、次の制約を使用
します。
v データ型
v デフォルト値
v チェック制約
v 参照制約
データ型
列に対する最初の制約は、列にデータ型を指定することにより課されます。データ型を
選択するとき、そのデータ型によって表すことができる値のみを含むように列を制約し
ます。
それぞれのデータ型は、特定の種類の情報のみ表すことができます。ある列にとっての
正しいデータ型とは、その列に適したデータ値はすべて表現でき、その列に適さない値
はほとんど表現できないデータ型のことです。
© Copyright IBM Corp. 1996, 2003
39
本章では、組込みデータ型について説明します。
Dynamic Server
Dynamic Server がサポートする拡張データ型について詳しくは、 127 ページの『第 7
章 Dynamic Server での拡張データ型の作成と使用』を参照してください。
Dynamic Server の終り
データ型の選択
表内の列ごとにデータ型が必要です。データ型の選択が重要である理由を、次に示しま
す。
v 列に格納できる有効なデータ項目のセットが設定される。
v データに対して実行できる操作の種類が決定される。
たとえば、文字データ型で定義された列に対しては SUM などの集計関数は適用でき
ない。
v ひとつひとつのデータが占有するディスク領域の大きさは、データ型によって決ま
る。
表が小さい場合、何十万行の表の場合ほど、データ項目に割り当てる領域について考
慮する必要はありません。表の行数がそれほど多くなると、4 バイト データ型と 8
バイト データ型の差が重要になってきます。
41 ページの図 22 は、組込みデータ型の選択肢をまとめた決定木を示します。これらの
選択については、以降の項で説明します。
40
IBM Informix: データベース設計および実装 ガイド
図 22. データ型の選択 (1/2)
第 3 章 データ型の選択
41
図 22. データ型の選択 (2/2)
数値型
数値データ型には、カウンタやコードに最適なもの、科学技術分野の数値計算に最適な
もの、金額に最適なものなどがあります。
42
IBM Informix: データベース設計および実装 ガイド
カウンタとコード: 整数 (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) 型を使用する場合の欠点は、格納できる
値の範囲が制限されることです。範囲外の値を格納することはできません。もちろん、
格納すべき最大値と最小値がわかっている場合は、このような制限超過は問題になりま
せん。
Dynamic Server
8 バイト整数 (INT8) 型をサポートするのは Dynamic Server のみです。 8 バイト整数
(INT8) 型は、符号付きバイナリ整数として格納されます。このデータ型では、値ごとに
8 バイトが使用されます。 8 バイト整数 (INT8) 型は、整数 (INTEGER) 型の 2 倍の
領域を占有しますが、8 バイト整数 (INT8) 型には非常に広範囲のデータを表すことが
できるという利点があります。 8 バイト整数 (INT8) 型は、- (263 -1) から 263 -1 まで
の範囲の整数を表すことができます。
Dynamic Server の終り
自動シーケンス: シリアル (SERIAL) 型および 8 バイト シリアル
(SERIAL8) 型
シリアル (SERIAL) 型は、特殊な機能を持つ単なる整数 (INTEGER) 型です。同様に、
8 バイト シリアル (SERIAL8) 型は、特殊な機能を持つ INT8 型です。表に新しい行が
挿入されると必ず、シリアル (SERIAL) 型または 8 バイト シリアル (SERIAL8) 型の
第 3 章 データ型の選択
43
列に対し、データベース サーバは自動的に新しい値を生成します。
Dynamic Server
8 バイト シリアル (SERIAL8) 型をサポートするには Dynamic Server のみです。
Dynamic Server の終り
1 つの表に、複数のシリアル (SERIAL) 型および 8 バイト シリアル (SERIAL8) 型の
列を入れることはできません。値はデータベースにより生成されるため、複数のユーザ
が同時に行を追加している場合でも、追加される行のシリアル値は常に異なります。こ
のような条件下にあるとき、通常のプログラムで一意の数値コードを新しく生成するこ
とは非常に困難なため、この機能はきわめて有益です。
シリアル (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) 型または SERIAL8 型の列は、自動的に一意の列になりません。重
複するシリアル番号が絶対に発生することがないようにするには、一意性制約を設定す
る必要があります。64 ページの『CREATE TABLE の使用』 を参照してください。
DB–Access で対話型スキーマ エディタを使用して表を定義すると、一意性制約がシリ
アル (SERIAL) 型または 8 バイト シリアル (SERIAL8) 型の列に自動的に適用されま
す。
44
IBM Informix: データベース設計および実装 ガイド
シリアル (SERIAL) 型と 8 バイト シリアル (SERIAL8) 型のデータ型には以下の利点
があります。
v システム割当てキーを手軽に作成できます。
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 ¥ 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 つのデータ型の主な違いは精度です。
第 3 章 データ型の選択
45
浮動小数点用のデータ型には次の利点があります。
v 非常に大きな数値や非常に小さな数値を格納し、小数部を持つ数値も格納する。
v 4 バイトまたは 8 バイトで数値を簡潔に表現する。
v 浮動小数点用のデータ型の列では、AVG、MIN などの算術関数や、ソート比較を効
率よく実行できる。
主な欠点は、精度の範囲を超える桁がゼロとして扱われることです。
精度を調整可能な浮動小数点: 10 進数(p)(DECIMAL(p)) 型
10 進数(p)(DECIMAL(p)) 型 データ型は、実数 (FLOAT) 型および小桁実数
(SMALLFLOAT) 型によく似た浮動小数点データ型です。実数型や小桁実数型との主な
違いは、有効桁の桁数 (精度) を指定できることです。 p として表記する精度の範囲は
1 から 32 まで (小桁実数 (SMALLFLOAT) より低い精度から実数 (FLOAT) 型の 2 倍
の精度まで) です。
10 進数 (DECIMAL) 型 (p) の数値の範囲は 10-130 から 10124 までです。 10 進数
(DECIMAL) 型 (p) の数値が使用する格納領域は、その精度 (1 + p/2 バイト (必要に応
じて整数に切り上げられる)) によって異なります。
10 進数(p)(DECIMAL(p)) 型を 10 進数(p,s)(DECIMAL(p,s)) 型 (次のセクションで説明)
と混同しないでください。 10 進数(p)(DECIMAL(p)) 型は、指定された精度のみを持ち
ます。
10 進数(p)(DECIMAL(p)) 型には、実数 (FLOAT) 型に対する以下の利点があります。
v 低精度から高精度まで、アプリケーションにあった精度を設定できる。
v 最大 32 桁の数値を正確に表現できる。
v 占有する記憶域の大きさは、数値の精度に比例する。
v 使用できる精度と値の範囲は、ホスト オペレーティング システムとは無関係に
Informix データベース サーバでサポートされる。
10 進数(p)(DECIMAL(p)) 型には以下の欠点があります。
v 10 進数(p)(DECIMAL(p)) 型の値での算術演算とソートのパフォーマンスは、実数
(FLOAT) 型の値の場合よりも多少低下します。
v 多くのプログラム言語では、10 進数(p)(DECIMAL(p)) 型データ フォーマットは、実
数 (FLOAT) 型および整数 (INTEGER) 型と同じ方法ではサポートされません。プロ
グラムでデータベースから 10 進数(p)(DECIMAL(p)) 型値を抽出する場合は、処理が
行えるようにその値を別の形式に変換する必要があります。
固定精度の数値: 10 進数 (DECIMAL) 型と金額 (MONEY) 型
ほとんどのビジネス アプリケーションが格納しなければならない数値は、整数部と小数
部の桁数が決まっています。たとえば、米国の通貨では小数部が 2 桁で記述されます。
46
IBM Informix: データベース設計および実装 ガイド
通常記録されるトランザクションの種類によって、左側 (整数部) に必要な桁数がわか
ります。家計などでは 5 桁、小規模のビジネスでは 7 桁、国家予算などでは 12 から
13 桁と考えられます。
この種の数値は、値の大きさとは無関係に特定の位置に小数点が固定されるため、固定
小数点数と呼ばれています。 10 進数(p,s)(DECIMAL(p,s)) 型は、10 進数を保持するよ
うに設計されています。この型の列を指定するときには、その精度 (p) を、格納できる
合計桁数として 1 から 32 までの範囲で指定します。また、小数点以下桁数 (s) を、小
数部の桁数として指定します。 (図 23 は、精度と小数点以下桁数の関係を示します。)
小数点以下桁数がゼロになる場合もあり、これはその数値が整数であることを意味して
います。整数のみが格納されるとき、10 進数(p,s)(DECIMAL(p,s)) 型は 32 桁までの整
数を格納できます。
図 23. 精度と小数点以下桁数
10 進数(p) (DECIMAL(p)) 型と同様に、10 進数(p,s)(DECIMAL(p,s)) 型は、その精度に
比例した領域を占有します。各値は、小数点以下桁数が偶数の場合は (p +3)/2 バイトを
占め、小数点以下桁数が奇数の場合は (p + 4)/2 バイトを占め、整数バイトに丸められ
ます。
金額 (MONEY) 型は、10 進数(p,s)(DECIMAL(p,s)) 型と同じですが、追加の機能が 1
つあります。表示のために金額 (MONEY) 型の数値が文字型に変換されるときには必
ず、通貨記号が自動的に追加されます。
整数 (INTEGER) 型および実数 (FLOAT) 型に対する 10 進数(p,s)(DECIMAL(p,s)) 型の
利点は、使用できる精度の幅が広いこと (整数 (INTEGER) 型の 10 桁や実数 (FLOAT)
型 16 桁と比較して最大 32 桁) と、精度と必要な格納量をアプリケーションに応じて
調整できることです。
10 進数(p,s)(DECIMAL(p,s)) 型の欠点は、算術計算の効率が低いことと、プログラミン
グ言語の多くがこの形式の数値をサポートしていないということです。したがって、プ
ログラムでこの数値を抽出する場合、通常は、処理が行えるようにその数値を別の数値
形式に変換しなければなりません。
第 3 章 データ型の選択
47
通貨フォーマットの選択:
広域言語サポート
金額の表しかたは国によって異なります。 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 日午前 0 時を起点として数えた日数を示す符号付き整数として格納
されます。通常、日付型は今世紀の日付を示す正の整数を格納します。
日付 (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) 型の列に対しては迅速に実行されます。
48
IBM Informix: データベース設計および実装 ガイド
日付フォーマットの選択 (広域言語サポートのみ): 日付コンポーネントの表記方
法には多くの種類があります。アプリケーションは日付 (DATE) 型の値を表示すると
き、ユーザが指定した日付フォーマットを参照します。デフォルトのロケールは、次の
ような米国英語の日付フォーマットを指定します。
10/25/2001
この日付フォーマットをカスタマイズするには、適切なロケールを選択するか、環境変
数 DBDATE を設定します。詳しくは、「IBM Informix: SQL ガイド: 参照 」を参照し
てください。
英語以外の言語については、ロケール ファイルの TIME カテゴリで日付型フォーマッ
トを変更することもできます。ロケールの使用方法について詳しくは、「IBM Informix:
GLS ユーザーズ ガイド 」を参照してください。
時刻: 日時 (DATETIME) 型
日時 (DATETIME) 型は、1 A.D から始まる年号の時刻を格納します。実際には、日時
(DATETIME) 型は、それぞれ異なる精度を持つ 28 個のデータ型のファミリです。日時
(DATETIME) 型の列を定義するときは、その精度を指定します。列には、year、month、
day、hour、minute、second、および fraction のリストからいずれかのシーケンスを含め
ることができます。したがって年のみ、月と日のみ、日と単なる時間またはミリ秒まで
指定した時間のみを格納する 日時 (DATETIME) 型の列を定義することができます。日
時 (DATETIME) 型の値のサイズは、49 ページの表 1 に示すように、精度によって 2
から 11 バイトまでの範囲にわたります。
日時 (DATETIME) 型 の利点は、特定の日付と時刻を格納できることです。一般的に、
日時 (DATETIME) 型の列には、日時 (DATETIME) 型の修飾子に応じて、日付 (DATE)
型の列より大きい格納領域が必要です。また、日時 (Datetime) 型の表示フォーマットに
は柔軟性がありません。表示フォーマットの問題を回避する方法について詳しくは、51
ページの『日時 (DATETIME) 型または時間隔 (INTERVAL) 型のフォーマット』を参照
してください。
表 1. 日時 (DATETIME) 型の精度
精度
サイズ*
精度
サイズ*
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
第 3 章 データ型の選択
49
表 1. 日時 (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) 型の値のサイズ範囲は、表 2 に示される公式に応じて 2 か
ら 12 です。
表 2. 時間隔 (INTERVAL) 型の精度
50
精度
サイズ*
精度
サイズ*
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
IBM Informix: データベース設計および実装 ガイド
表 2. 時間隔 (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
英語以外の言語については、ロケール ファイルの TIME カテゴリで日時 (DATETIME)
型フォーマットを変更します。ロケールの使用方法について詳しくは、IBM Informix:
GLS ユーザーズ ガイドを参照してください。
第 3 章 データ型の選択
51
この日時 (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 より短い場合、データベース サーバは
単一バイトの 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 バイトにします。
52
IBM Informix: データベース設計および実装 ガイド
データベース サーバは、各国語文字 (NCHAR) 型 (n) の列のデータを、ロケールが指
定する順序に従ってソートします。たとえば、フランス語のロケールは、文字 ê が値 e
の後、値 f の前にソートされるように指定します。つまり、フランス語のロケールが指
定するソート順は、e、ê、f などです。ロケールの使用方法について詳しくは、
「IBM Informix: GLS ユーザーズ ガイド 」を参照してください。
ヒント: 文字(n)(CHAR(n)) 型と各国語文字(n)(NCHAR(n)) 型 のデータの差は、データ
のソートと比較の方法のみです。文字(n)(CHAR(n)) 型の列には英語以外の文字
を格納できます。ただし、データベース サーバはコード セット順序を使用し
て文字(n)(CHAR(n)) 型の列でソートや比較を行うため、予期した順序での結果
を得ることができない場合もあります。
文字(n)(CHAR(n)) 型または各国語文字(n)(NCHAR(n)) 型の値は、タブと空白を含むこと
はできますが、通常、その他の非印刷文字は含みません。 INSERT 文または UPDATE
文を使用して行を挿入する場合や、ユーティリティ プログラムで行をロードする場合に
は、印字不可能な文字は入力されません。しかし、埋込み SQL を使用するプログラム
によって行を作成する場合は、NULL (2 進のゼロ) 文字以外の任意の文字を挿入できま
す。標準的なプログラムやユーティリティは印字不可能な文字を予測していないため、
印字不可能な文字を文字型の列には格納しないでください。
文字(n)(CHAR(n)) 型または各国語文字(n)(NCHAR(n)) 型のデータの利点は、すべてのデ
ータベース サーバで利用できるということです。文字(n)(CHAR(n)) 型または各国語文
字(n)(NCHAR(n)) 型の欠点は、固定長であるということのみです。データ値の長さが行
ごとに大きく異なる場合は、空白部分が無駄になります。
可変長文字列: 可変長文字(m,r)(CHARACTER VARYING(m,r)) 型、可変長文
字(m,r)(VARCHAR(m,r)) 型、各国語可変長文字(m,r)(NVARCHAR(m,r)) 型、
およびラージ可変長文字 (LVARCHAR) 型
文字型列の項目は、長さが一定でないことがよくあります。多くは平均的な長さで、最
大長のデータはわずかにすぎません。次のデータ型のそれぞれについて、m は最大バイ
ト数、r は最小バイト数を表します。このようなデータを格納する際にディスク領域を
節約するため、次のデータ型が用意されています。
v 可変長文字 (CHARACTER VARYING) 型 (m,r)。可変長文字(m,r)(CHARACTER
VARYING(m,r)) 型には、最大 m バイト、最小 r バイトのシーケンスが含まれま
す。このデータ型は、可変長文字データの ANSI 標準準拠のフォーマットです。可変
長文字(m,r)(CHARACTER VARYING(m,r)) 型は、文字データの比較のためにコード
セット順序をサポートします。
v 可変長文字(m,r)(VARCHAR(m,r)) 型。 可変長文字(m,r) (VARCHAR(m,r)) 型は、可変
長文字データを格納するための Informix 固有のデータ型です。機能的には、可変長
文字(m,r)(CHARACTER VARYING(m,r)) 型と同じです。
v 各国語可変長文字(m,r)(NVARCHAR(m,r)) 型。各国語可変長文字
(m,r)(NVARCHAR(m,r)) 型も、可変長文字データを格納するための Informix 固有のデ
第 3 章 データ型の選択
53
ータ型です。これは、ロケールが指定する順序で文字データを比較します。
Dynamic Server
v ラージ可変長文字 (LVARCHAR) 型。ラージ可変長文字 (LVARCHAR) 型は、256 バ
イトより大きく 2 KB より小さい値の可変長の文字データを格納するための Informix
固有のデータ型です。ラージ可変長文字 (LVARCHAR) 型は、文字データの比較のた
めにコード セット順序をサポートします。
Dynamic Server の終り
ヒント: データの比較方法の差により、各国語可変長文字(m,r)(NVARCHAR(m,r)) 型デ
ータは、可変長文字(m,r) (CHARACTER VARYING(m,r)) 型や可変長文字(m,r)
(VARCHAR(m,r)) 型のデータと区別されます。ロケールがコード セットとソー
ト順を決定する方法について詳しくは、52 ページの『文字データ: 文字
(CHAR) 型 (n) と各国語文字 (NCHAR) 型 (n)』を参照してください。
これらのデータ型の列を定義するとき、バイトの最大 数として m を指定します。挿入
された値が m バイトより少なくても、データベース サーバは単一バイト空白文字を値
に追加しません (文字(n)(CHAR(n)) 型および各国語文字(n)(NCHAR(n)) 型の値の場合は
追加されます)。その代わりに、実際の内容のみを 1 バイト フィールドでディスクに格
納します。 m の上限は、インデックス付き列で 254 バイト、インデックスなしの列で
255 バイトです。
2 番めのパラメータ r は、ディスクに格納される値に必要なバイト数の下限を設定する
オプションの予約長です。値が r バイト未満しか要求しない場合でも、その値を保持す
るために r バイトが割り当てられます。このように下限を設定するのは、行の更新時間
を節約するためです。 (55 ページの『可変長文字と実行時間』を参照してください。)
文字(n)(CHAR(n)) 型に対する変長文字(m,r)(CHARACTER VARYING(m,r)) 型または可
変長文字(m,r)(VARCHAR(m,r)) 型の利点は、以下のとおりです。
v データ項目に必要なバイト数が広範囲に変化したり、少数の項目のみが平均以上のバ
イト数を必要としたりする場合に、ディスク領域を一定に保つ。
v 小規模な表に対する問合せを高速化できる。
これらの利点は、各国語文字(n)(NCHAR(n)) 型と比較した各国語可変長文字
(m,r)(NVARCHAR(m,r)) 型にも当てはまります。
可変長データ型の欠点は次のとおりです。
v 255 バイトを超える長さは許されない。
v 環境によっては表更新の速度が遅くなる。
v すべての Informix データベース サーバで利用できるとは限らない。
54
IBM Informix: データベース設計および実装 ガイド
可変長文字と実行時間
可変長文字(m,r)(CHARACTER VARYING(m,r)) 型、可変長文字(m,r) (VARCHAR(m,r))
型 、または各国語可変長文字(m,r)(NVARCHAR(m,r)) 型のいずれかを使用するとき、表
の行は固定バイト数ではなく可変バイト数を持ちます。表の行がさまざまなバイト数を
持っていると、データベース操作の速度はその影響を受けます。
ディスクの 1 ページにより多くの行が格納されるため、データベース サーバは、行が
固定したバイト数を持っている場合より少ないディスク操作で表を探索することができ
ます。その結果、問合せの実行速度は速くなります。挿入操作と削除操作についても、
同じ理由から多少速くなることがあります。
行を更新する場合、データベース サーバの作業量は、もとの行のバイト数より新しい行
のバイト数に依存します。新しい行のバイト数がもとの行のバイト数以下であれば、実
行時間は固定長の行の場合とそれほど変わりません。しかし、新しい行がもとの行より
かなり多いバイト数を必要とする場合、データベース サーバは多くのディスク操作を何
回も実行しなければならなくなることがあります。したがって、可変長文字
(m,r)(CHARACTER VARYING(m,r)) 型、可変長文字(m,r)(VARCHAR(m,r)) 型、または各
国語可変長文字(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:
管理者ガイド 」を参照してください。
第 3 章 データ型の選択
55
文字(n)(CHAR(n)) 型および可変長文字(m,r)(VARCHAR(m,r)) 型に対するテキスト
(TEXT) 型の利点は、テキスト (TEXT) 型のデータ項目のサイズに制限がないことです
(ただし、データを保持するディスク デバイスの容量まで)。テキスト (TEXT) 型の欠点
は以下のとおりです。
v ディスク ページ全体が割り当てられるため、短いデータの場合はディスク容量が無
駄になります。
v SQL 文でテキスト (TEXT) 型の列の使用方法が制限されます。 (56 ページの『テキ
スト (TEXT) 型とバイト (BYTE) 型の使用方法』を参照してください。)
v すべての Informix データベース サーバで使用できるわけではありません。
バイナリ オブジェクト: バイト (BYTE) 型
バイト (BYTE) 型は、プログラムが生成できるすべてのデータを保持するよう設計され
ています。このデータはたとえば、グラフィック イメージ、プログラム オブジェクト
ファイル、任意のワード プロセッサやスプレッド シートによって保存されたドキュメ
ントなどです。データベース サーバは、バイト (BYTE) 型列にあらゆる長さ、かつあ
らゆる種類のデータを受け入れることができます。
Extended Parallel Server
Extended Parallel Server は列内のバイト (BYTE) 型をサポートしますが、BLOB 領域に
バイト (BYTE) 型の列を格納したり、SPL ルーチンでバイト (BYTE) 型の値を使用す
ることは許可しません。
Extended Parallel Server の終り
テキスト (TEXT) 型の場合と同様に、バイト (BYTE) 型データ項目は通常の行データと
は分離され、ディスク領域の全ディスク ページに格納されるのが普通です。
テキスト (TEXT) 型や文字(n)(CHAR(n)) 型とは対照的に、バイト (BYTE) 型の利点
は、どのようなデータでも受け入れることです。欠点は、テキスト (TEXT) 型の場合と
同じです。
テキスト (TEXT) 型とバイト (BYTE) 型の使用方法
データベース サーバは、テキスト (TEXT) 型およびバイト (BYTE) 型の列を格納およ
び取得します。テキスト (TEXT) 型またはバイト (BYTE) 型の値を取得および格納する
には、通常、IBM Informix ESQL/C などの埋込み SQL をサポートする言語で書かれた
プログラムを使用します。このようなプログラムでは、テキスト (TEXT) 型値やバイト
(BYTE) 型値の取出し、挿入、更新を、順次ファイルの読み書きと似た要領で行うこと
ができます。
SQL 文では、対話型かプログラム式かにかかわらず、以下の場合にテキスト (TEXT)
型またはバイト (BYTE) 型の列は使用できません。
v 算術式やブール式
56
IBM Informix: データベース設計および実装 ガイド
v GROUP BY 節または ORDER BY 節の中
v UNIQUE テスト
v インデックス作成については、単独でも、あるいは複合インデックスの一部としても
使用できません。
対話型で入力するか、またはフォームかレポートに入力する 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 とゼロ値または空白値を混同しないよう
第 3 章 データ型の選択
57
に注意してください。たとえば、次の文を使用すると、データベース stores_demo の
manufact 表に行が 1 行挿入され、lead_time 列の値が NULL になるよう指定されま
す。
INSERT INTO manufact VALUES (’DRM’, ’Drumm’, NULL)
Dynamic Server
コレクション (collection) 型の列は NULL 要素を含むことができません。コレクション
(collection) 型については、第 7 章で説明しています。
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
58
IBM Informix: データベース設計および実装 ガイド
文字型のドメインに対する制約を記述するには、MATCHES 述語やサポートされている
正規表現を使用します。次の例は、電話番号の列のドメインを合衆国内の電話番号の形
式に制限する制約です。
vce_num MATCHES ’[2-9][2-9][0-9]-[0-9][0-9][0-9][0-9]’
チェック制約について詳しくは、「IBM Informix: SQL ガイド: 構文 」に記載されてい
る CREATE TABLE 文および ALTER TABLE 文を参照してください。
参照制約
各表の主キーと外部キーを識別して、列に対する参照制約を設定することができます。
これらのキーを識別する方法については、11 ページの『第 2 章 リレーショナル デー
タ モデルの作成』 を参照してください。
主キーと外部キーに対して列を選択するとき、ほとんどすべてのデータ型の組合せが一
致する必要があります。たとえば、主キーを文字 (CHAR) 型で定義した場合、外部キー
も文字 (CHAR) 型で定義しなければなりません。しかし、ある表の主キーにシリアル
(SERIAL) 型を指定している場合は、関係する外部キーに整数 (INTEGER) 型を指定し
ます。同様に、ある表の主キーに 8 バイト シリアル (SERIAL8) 型を指定するとき、
関係する外部キーに 8 バイト整数 (INT8) 型を指定します。任意の関係内で一緒に使用
できるデータ型の組合せは、次の 2 つだけです。
v シリアル (SERIAL) 型と整数 (INTEGER) 型
Dynamic Server
v 8 バイト シリアル (SERIAL8) 型と 8 バイト整数 (INT8) 型
Dynamic Server の終り
参照制約付きの表を作成する方法について詳しくは、「IBM Informix: SQL ガイド: 構
文 」に記載されている CREATE TABLE 文および ALTER TABLE 文を参照してくだ
さい。
第 3 章 データ型の選択
59
60
IBM Informix: データベース設計および実装 ガイド
第 4 章 リレーショナルデータモデルの実装
本章の概要
本章では、SQL 構文を使用して、第 2 章で説明されているデータ モデルを実装する方
法について説明します。具体的には、データベースと表を作成し、その表にデータを入
力する方法について説明します。また、この章ではデータベース ログ オプション、表
シノニム、コマンド スクリプトについても説明します。
データベースの作成
これで、データモデルをデータベースの表として作成する準備が整いました。作成する
には、CREATE DATABASE 文、CREATE TABLE 文、および CREATE INDEX 文を
使用します。これらの文の構文については、「IBM Informix: SQL ガイド: 構文 」で説
明しています。このセクションでは、CREATE DATABASE 文および CREATE TABLE
文を使用して、データ モデルを実装する方法を説明します。
住所録のデータモデルが、説明のためだけに使用されていることに注意してください。
例を示すために、データモデルは SQL 文に変換されます。
同じデータベースモデルを 2 回以上作成する必要がある場合もあります。モデルを作成
する文を保管して、後からその文を再実行できます。詳しくは、69 ページの『コマンド
スクリプトの使用』を参照してください。
表を作成したら、表にデータの行を入力します。これは、手動か、ユーティリティプロ
グラムを使用するか、または特別にプログラミングすることによって行います。
CREATE DATABASE の使用
データベースは、データ モデルのすべての部分を保持するコンテナです。要素としては
表の他にビュー、インデックス、シノニム、データベースに関連付けられたその他のオ
ブジェクトがあります。これらの要素を作成するには、まずデータベースを作成しなけ
ればなりません。
広域言語サポート
データベース サーバはデータベースを作成するときに、システム カタログにある環境
変数 DB_LOCALE からロケールを取り出してデータベースに格納します。このロケー
ルによって、データベース サーバがデータベースに格納されている文字データを解釈す
る方法が決定されます。デフォルトでは、データベース ロケールは ISO8859-1 コード
セットを使用する米国英語 (U.S. English) ロケールです。代わりのロケールを使用する
© Copyright IBM Corp. 1996, 2003
61
方法については、「IBM Informix: GLS ユーザーズ ガイド 」を参照してください。
広域言語サポート の終り
データベース サーバは、データベースを作成するときに、データベースの存在とそのロ
グ機能のモードを示すレコードをセットアップします。データベース サーバはディスク
領域を直接管理するため、このレコードはオペレーティング システムのコマンドからは
認識できません。
ファイル名の重複の回避
通常、一つのコンピュータ上ではデータベース サーバの一つのコピーのみが実行されて
おり、そのコンピュータのユーザ全員が使用するデータベースを管理しています。デー
タベース サーバが所有しているデータベース名の一覧は一つだけです。各データベース
には、そのデータベース サーバが管理する他のデータベースとは異なる名前をつけなけ
ればなりません。 (データベース サーバのコピーを二つ以上実行することも可能です。
たとえば、データベース サーバの複数のコピーを作成して、操作データから分離した安
全なテスト環境を構築することができます。この場合、データベースを作成するとき
と、このデータベースに後でアクセスするときに、必ず正しいデータベース サーバを使
用してください。)
DB 領域の選択
データベース サーバには、データベースを特定の DB 領域に作成します。 DB 領域は
ディスク領域の一部に名前が付いたものです。特定の DB 領域を使用する必要があるか
どうかはデータベース サーバ管理者に問い合わせてください。データベースを別の DB
領域に置いて、そのデータベースを他のデータベースから分離したり、そのデータベー
スを特定のディスク デバイスに格納したりすることができます。 DB 領域、および
DB 領域とディスク デバイスとの関係について詳しくは、「IBM Informix: 管理者ガイ
ド 」を参照してください。複数の DB 領域にまたがるデータベースの表をフラグメン
ト化する方法については、 183 ページの『第 10 章 次元データ モデルの作成』を参照
してください。
一部の DB 領域は、信頼性を高めるために、ミラーリング、つまり 2 つのディスク デ
バイスに二重化されています。データベースの内容が特別に重要である場合、ミラーリ
ングされた DB 領域にそのデータベースを格納できます。
トランザクションログ機能のタイプの選択
ログ付きデータベースまたはログなしデータベースを指定するには、CREATE
DATABASE 文を使用します。データベース サーバには、トランザクションログ機能に
関して次のような選択肢があります。
v まったくログに記録しない。この選択は推奨されません。ハードウェア障害が原因で
データベースが失われた場合、最後のバックアップ以降に行われたデータ変更がすべ
て失われます。
CREATE DATABASE db_with_no_log
62
IBM Informix: データベース設計および実装 ガイド
ログ機能を選択しない場合に、トランザクション処理に関連する BEGIN WORK 文
や他の SQL 文をデータベースで使用することができません。このような事態は、デ
ータベースを使用するプログラムの処理内容に影響を及ぼします。
Extended Parallel Server
Extended Parallel Server は、ログなしデータベースをサポートしません。ただし、デ
ータベース サーバはログなし表をサポートします。詳しくは、212 ページの
『Extended Parallel Server のログ付き表とログなし表』を参照してください。
Extended Parallel Server の終り
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
ANSI SQL の設計では、バッファ付きログ機能の使用が禁止されています。 ANSI
標準準拠のデータベースを作成した場合は、トランザクションログ機能をオフにする
ことはできません。
Dynamic Server
ANSI 標準準拠でないデータベースの場合は、データベース サーバ管理者 (DBA) は、
トランザクション ログ機能をオン/オフにしたり、バッファ付きログをバッファなしロ
グに変更したりすることができます。たとえば、多くの新規行を挿入する前に、ログ機
能をオフにできます。
IBM Informix Server Administrator (ISA)、または ondblog ユーティリティと ontape
ユーティリティを使用すると、ログ機能状態あるいはバッファリング モードを変更でき
第 4 章 リレーショナルデータモデルの実装
63
ます。これらのツールについて詳しくは、「IBM Informix: Dynamic Server 管理者ガイ
ド 」を参照してください。また、SET LOG 文を使用すれば、バッファ付きログとバッ
ファなしログを切り替えることもできます。 SET LOG について詳しくは、
「IBM Informix: SQL ガイド: 構文 」を参照してください。
Dynamic Server の終り
CREATE TABLE の使用
データモデルで設計した表を作成するには CREATE TABLE 文を使用します。この文
は複雑な形式をしていますが、基本的には表の列のリストです。表の各列について、次
の情報を指定します。
v 列の名前
v データ型 (作成した定義域の中のもの)
この文には、以下の制約の 1 つ以上が含まれる場合もあります。
v 主キー制約
v 外部キー制約
v 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)
);
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),
64
IBM Informix: データベース設計および実装 ガイド
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 領域にフラ
グメント化することができます。 Informix データベース サーバがサポートする各種格
納オプションについて詳しくは、「IBM Informix: SQL ガイド: 構文 」に記載されてい
る CREATE TABLE 文を参照してください。次の節で、1 つの表を複数の DB 領域に
フラグメント化する方法の 1 つを示します。
フラグメント表の作成
データの格納場所を表レベルで制御するには、表を作成するときに FRAGMENT BY 節
を使用します。次の文は、ラウンド ロビン分散スキームに従ってデータを格納するフラ
グメント表を作成します。この例では、データの行は、フラグメント dbspace1、
dbspace2、および dbspace3 にほぼ均等に分散されます。
第 4 章 リレーショナルデータモデルの実装
65
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),
city
CHAR(15),
state
CHAR(2),
zipcode
CHAR(5),
phone
CHAR(18)
);
次の文は、customer 表の lname 列にインデックスを作成する方法を示します。
CREATE INDEX lname_index ON customer (lname);
66
IBM Informix: データベース設計および実装 ガイド
複合インデックス
複数の列を含むインデックスを作成できます。たとえば、次のようなインデックスを作
成できます。
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
つだけ作成し、ソート列が昇順または降順になるように結果のソートを指定する問合せ
のために、そのインデックスを使用できます。
表名のシノニムの使用
シノニムとは、ある名前の代わりに使用できる別の名前のことです。 CREATE
SYNONYM 文を使用すると、表やビューに代替名を与えることができます。
通常、シノニムを使用して現在のデータベースに存在しない表を参照します。たとえ
ば、次のような文を実行すると、customer 表や orders 表の名前に対するシノニムを
作成することができます。
CREATE SYNONYM mcust FOR masterdb@central:customer;
CREATE SYNONYM bords FOR sales@boston:orders;
作成したシノニムは、元の表名を使用している可能性があっても、現行データベースの
すべての場所で使用することができます。以下にシノニムの使用例を示します。
SELECT bords.order_num, mcust.fname, mcust.lname
FROM mcust, bords
WHERE mcust.customer_num = bords.Customer_num
INTO TEMP mycopy;
CREATE SYNONYM 文では、シノニム名を現行データベースの syssyntable システ
ム カタログ表に格納します。現行データベースで作成された問合せであれば、いずれも
このシノニムを使用することができます。
第 4 章 リレーショナルデータモデルの実装
67
短いシノニムを使用すると、問合せを書くのが容易になりますが、シノニムは別の役割
を果たすこともできます。シノニムを使用すると、問合せを変えずに、表を別のデータ
ベースやコンピュータに移動することができます。
たとえば、customer 表と orders 表を参照する問合せが複数あるとします。これらの
問合せは、プログラムやフォーム、レポートに埋め込まれています。これらの表はデモ
ンストレーション データベースの一部で、このデータベースはデータベース サーバ
avignon に置かれています。
ここで、ネットワークに接続された別のコンピュータ (データベース サーバ nantes)
のユーザも、同じプログラム、フォーム、レポートが使用できるようにすると決定した
とします。これらのユーザは、その地域での注文が含まれている orders という名前の
表が入っているデータベースを持っていますが、avignon にある customer 表にアク
セスする必要があります。
これらのユーザにとって、customer 表は外部表です。これは、特殊なバージョンのプ
ログラムやレポート、つまり、customer 表をデータベース サーバ名で修飾するバージ
ョンを作成しなければならない、ということになるのでしょうか。よりよい解決策は、
次の例に示されるように、これらのユーザのデータベースにシノニムを作成することで
す。
DATABASE stores_demo@nantes;
CREATE SYNONYM customer FOR stores_demo@avignon:customer;
格納済みの問合せがご使用のデータベースで実行される場合、名前 customer は実際の
表を参照します。この問合せがその他のデータベースで実行される場合、名前 customer
はシノニムを介して、データベース サーバ avignon にある表の参照となるよう変換さ
れます。
シノニム連鎖の使用
前述の例を続けるために、ネットワークにコンピュータが新たに接続されたと仮定しま
す。そのコンピュータの名前は db_crunch です。 avignon の負荷を軽減するため
に、customer 表などの表は db_crunch に移動されます。表は新しいデータベース サ
ーバ上にとても簡単に再作成できますが、どうすればすべてのアクセスをこの表に向け
ることができますか。一つの方法は、次の例に示すように、シノニムをインストールし
古い表を置き換えることです。
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 内のシノニムは、や
68
IBM Informix: データベース設計および実装 ガイド
はり customer に対する参照をデータベース stores_demo@avignon にリダイレクト
します。そこにある新しいシノニムは、データベース stores_demo@db_crunch に問
合せを送信します。
この例のように、シノニムの連鎖は、1 回の操作ですべてのアクセスを目的の表に向け
たい場合に役立ちます。ただし、できる限り早く全ユーザのデータベースを更新して、
これらのシノニムが目的の表を直接指せるようにしなければなりません。これを行わな
いと、データベース サーバが余分なシノニムを取り扱う場合に、余分なオーバーヘッド
が発生するほか、連鎖内のいずれかのコンピュータがダウンすると、その表を見つけら
れなくなります。
一つのアプリケーションをローカル データベースに対して実行し、後で同じアプリケー
ションを別のコンピュータ上のデータベースに対して実行することもできます。プログ
ラムは、どちらの場合も同じように順調に実行されますが、ネットワーク データベース
上では、実行速度が遅くなることがあります。データ モデルが同じである限り、プログ
ラムではデータベース同士の違いを区別できません。
コマンド スクリプトの使用
対話式に SQL 文を入力して、データベースや表を作成できます。場合によってはこの
操作を 2 回以上繰り返さなければならないことがあります。たとえば、データベースの
再作成は、試験バージョンが正常に動作した後で本稼動バージョンを作成するときに必
要になります。 また、同じデータモデルを複数のコンピュータについて実装しなければ
ならない場合も、データベースの再作成が必要になります。時間を掛けずにエラーの発
生数を減らすには、データベースを作成するためのすべての文をファイルに書き込み、
後でそれらの文を再実行します。
スキーマの保存
dbschema は、データベースの内容を検査し、再作成するために必要なすべての SQL
文を生成するユーティリティです。データベースの最初のバージョンを作成して、希望
どおりのデータベースになるまで変更を加えます。次に dbschema を使用して、その
データベースを二重化するために必要な SQL 文を生成することができます。
dbschema ユーティリティについて詳しくは、「IBM Informix: 移行ガイド 」を参照し
てください。
ファイルの実行
SQL 文を対話式に入力するために使用するプログラム (DB–Access など) は、コマンド
ファイルから実行できます。 DB–Access を開始して、ユーザまたは dbschema が用
意したコマンド ファイルを読み取り、実行できます。詳しくは、「IBM Informix:
DB-Access ユーザーズ ガイド 」を参照してください。
例
ほとんどの IBM Informix データベース サーバ製品は、デモンストレーションデータベ
ースを備えています (このデータベースは本書の例で使用されます)。デモンストレーシ
第 4 章 リレーショナルデータモデルの実装
69
ョン データベースは、このデータベースを作成するために IBM Informix 製品を呼び出
すオペレーティング システムのコマンド スクリプトの形で配布されます。このコマン
ドスクリプトをコピーして、自分のデータモデルを自動作成するための原型として使用
することができます。
データベースへのデータの追加
初期のテストの場合、データベースにデータを追加する最も簡単な方法は、DB–Access
で INSERT 文を入力する方法です。たとえば、デモンストレーション データベースの
manufact 表に行を挿入するには、DB–Access で次のコマンドを入力します。
INSERT INTO manufact VALUES ('MKL', 'Martin', 15);
アプリケーション プログラム (C 言語のアプリケーションなど) を準備する場合は、そ
のアプリケーションを使用してデータベース表に行を挿入できます。
次の表は、データベースへの情報の入力に使用できる IBM Informix ツールのリストで
す。「参照」列の頭字語については、表の後で説明します。
70
IBM Informix: データベース設計および実装 ガイド
ツール
内容
参照
dbaccessdemo
dbaccessdemo_ud
DB–Access
サンプル データベースを作成し、そこにデータ
を追加する。
明示コマンドを入力して、データベースを編集す
る。
明示コマンドを入力して、データベースを編集す
る。
データベース全体または選択されたデータベース
表を、テープまたはディスク上のファイルからコ
ピーする。
データを 1 つ以上のテキスト ファイルから 1
つ以上の既存の表にロードする。
データベース全体、選択された表、または選択さ
れた表から選択された列をコピーする。
テキスト ファイルからデータをロードする。
テキスト ファイルを使用してデータベース全体
をコピーする。
指定された表が更新されるたびに、選択されたデ
ータベースを更新する。
データを Extended Parallel Server から
IBM Informix Dynamic Server へコピーする。
C プログラムに埋め込まれた SQL コマンドを使
用して、データベースを更新する。
Java プログラムに埋め込まれた SQL コマンド
を使用して、データベースを更新する。
非 Informix データベースからデータにアクセス
する。
DB-A SQLR
SQL エディタ
onunload および
onload ユーティリテ
ィ
dbload
ハイ パフォーマンス
ローダ
LOAD UNLOAD
dbexport および
dbimport
Enterprise Replication
onxfer
C アプリケーション
Java アプリケーショ
ン
ゲートウェイ アプリ
ケーション
DB-A SQLS
オンライン
ヘルプ SQLS
MG AR
MG
HPL
SQLS
MG
ER
MG
ESQLC DAPI
DBDK
Java DBDK
GM GU
ニーモニック
「参照」列の説明
SQLR
IBM Informix: SQL ガイド: 参照
SQLS
IBM Informix: SQL ガイド: 構文
MG
IBM Informix: 移行ガイド
AR
IBM Informix: Administrator’s Reference
GM
IBM Informix: Enterprise Gateway Manager User Manual
GU
IBM Informix: Enterprise Gateway User Manual
DBDK
IBM Informix: DataBlade Developers Kit User’s Guide
ESQL/C
IBM Informix: ESQL/C Programmer’s Manual
Java
IBM Informix: J/Foundation Developer’s Guide
HPL
IBM Informix: ハイ パフォーマンス ローダ ユーザーズ ガイド
第 4 章 リレーショナルデータモデルの実装
71
DB-A
IBM Informix: DB-Access ユーザーズ ガイド
ER
IBM Informix: Dynamic Server エンタープライズ レプリケーション
ガイド
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: 管理者ガイド 」を参照してください。
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 部 データベースの管理
第 5 章 表フラグメンテーション ストラテジ
フラグメント化とは . . . . . . . . .
フラグメント化を使用する理由. . . . .
フラグメント化の責任者 . . . . . . .
Extended Parallel Server に対する拡張フラ
グメント化 . . . . . . . . . . .
フラグメント化とロギング . . . . . .
表のフラグメント化のための分散スキーム . .
式ベース分散スキーム. . . . . . . .
範囲規則 . . . . . . . . . . .
任意規則 . . . . . . . . . . .
MOD 関数の使用 (IDS のみ) . . . .
行の挿入と更新 . . . . . . . . .
ラウンド ロビン分散スキーム . . . . .
範囲分散スキーム (XPS のみ) . . . . .
システム定義ハッシュ分散スキーム (XPS
のみ) . . . . . . . . . . . . .
ハイブリッド分散スキーム (XPS のみ) . .
フラグメント表の作成. . . . . . . . .
フラグメント表を新たに作成する . . . .
フラグメント化されていない表からのフラ
グメント表の作成 . . . . . . . . .
複数の非フラグメント表の使用. . . .
単一の非フラグメント表の使用. . . .
フラグメント表内の行 ID . . . . . .
スマート ラージ オブジェクトのフラグメ
ント化 (IDS のみ) . . . . . . . . .
フラグメンテーション ストラテジの修正 . .
フラグメンテーション ストラテジの再初期
化 . . . . . . . . . . . . . .
Dynamic Server のフラグメンテーション
ストラテジの修正 . . . . . . . . .
ADD 節の使用 . . . . . . . . .
DROP 節の使用 . . . . . . . . .
MODIFY 節の使用 . . . . . . . .
XPS のフラグメンテーション ストラテジ
の修正 . . . . . . . . . . . . .
INIT 節の使用 . . . . . . . . .
ATTACH 節と DETACH 節の使用 . .
フラグメント アクセス権の付与と取消し (IDS
のみ) . . . . . . . . . . . . . .
© Copyright IBM Corp. 1996, 2003
77
77
78
78
79
79
79
80
81
81
82
82
82
82
83
84
84
85
86
86
87
87
88
89
89
90
90
91
91
91
92
92
94
第 6 章 データベース サーバのアクセス権の
付与と制限 . . . . . . . . . . . . 95
SQL を使用したデータへのアクセスの制限 . 95
データベースへのアクセスの制御 . . . . . 95
アクセス権の付与 . . . . . . . . . . 96
データベース レベル アクセス権 . . . . 97
Connect アクセス権 . . . . . . . 97
Resource アクセス権 . . . . . . . 98
データベース管理者アクセス権. . . . 98
所有権 . . . . . . . . . . . . . 99
表レベル アクセス権 . . . . . . . . 99
アクセス権 . . . . . . . . . . 99
Index アクセス権、Alter アクセス権、
および References アクセス権. . . . 101
型付き表に対する Under アクセス権
(IDS のみ) . . . . . . . . . . 101
表フラグメントのアクセス権 (IDS の
み) . . . . . . . . . . . . . 102
列レベル アクセス権. . . . . . . . 102
型レベル アクセス権. . . . . . . . 104
ユーザ定義型の Usage アクセス権 . . 104
名前付き行 (ROW) 型の Under アクセ
ス権 . . . . . . . . . . . . 104
ルーチン レベル アクセス権 . . . . . 105
言語レベル アクセス権 . . . . . . . 105
アクセス権の自動化 . . . . . . . . 106
コマンドスクリプトによる自動化 . . 107
ロールの使用 (IDS のみ) . . . . . 107
SPL ルーチンによるデータへのアクセスの制
御 . . . . . . . . . . . . . . . 109
データの読込みの制限 . . . . . . . 110
データへの変更の制限 . . . . . . . 111
データへの変更の監視 . . . . . . . 111
オブジェクト作成の制限 . . . . . . 112
ビューの使用 . . . . . . . . . . . 113
ビューの作成 . . . . . . . . . . 114
型付きビュー (IDS のみ) . . . . . 115
ビューの重複行 . . . . . . . . 116
ビューに関する制限 . . . . . . . . 116
ベースの変更の反映 . . . . . . . 117
ビューを用いたデータの変更 . . . . . 118
75
ビューを用いたデータの削除 . . .
ビューの更新 . . . . . . . .
ビューへの挿入 . . . . . . .
WITH CHECK OPTION キーワードの
使用 . . . . . . . . . . .
PREPARE 文で処理された文をビュー
定義の変更時に再実行 . . . . .
アクセス権とビュー . . . . . . . .
ビューの作成時のアクセス権 . . . .
ビューを使用するときのアクセス権 . .
76
. 118
. 118
. 119
. 119
.
.
.
.
120
120
120
121
IBM Informix: データベース設計および実装 ガイド
第 5 章 表フラグメンテーション ストラテジ
本章の概要
この章では、データベース サーバがサポートするフラグメンテーション ストラテジに
ついて説明し、さまざまなフラグメンテーション ストラテジの例を示します。フラグメ
ント化、表フラグメントのための分散スキーム、フラグメント表の作成と修正、および
フラグメント表へのアクセス権の付与について説明します。
データの競合を少なくし、問合せの性能を向上させるフラグメンテーション ストラテジ
を構築する方法については、「IBM Informix: パフォーマンス ガイド 」を参照してくだ
さい。
フラグメント化とは
フラグメント化とは、データベース サーバ機能の 1 つであり、この機能を使用すれ
ば、表レベルでデータを格納する場所を制御できます。フラグメント化を使用すれば、
何らかのアルゴリズムまたはスキームに基づいて、任意の表内に、行またはインデック
ス キーのグループを定義することができます。各グループまたはフラグメント は、パ
ーティション とも呼ばれ、特定の物理ディスクと関連付けられた別の DB 領域に格納
することができます。 SQL 文を使用して、フラグメントを作成し、それらを DB 領域
に割り当てます。
行またはインデックス キーをフラグメントにグループ化するため使用するスキーマは、
分散スキーム と呼ばれます。分散スキームと、フラグメントを一緒に配置する DB 領
域のセットにより、フラグメンテーション ストラテジが構成されます。フラグメンテー
ション ストラテジの構成に必要な注意点については、「IBM Informix: パフォーマンス
ガイド」を参照してください。
表行、インデックス キー、またはその両方をフラグメント化するかどうかを決め、その
行またはキーを複数のフラグメントに分散する方法を決めたら、この分散を実現するス
キームを決めます。 Informix データベース サーバがサポートしている分散スキームに
ついては、79 ページの『表のフラグメント化のための分散スキーム』を参照してくださ
い。
フラグメント表とインデックスを作成すると、データベース サーバは、各表の格納場所
およびインデックス フラグメントを、その他の関連情報とともに sysfragme nts という
名前のシステム カタログ表に格納します。この表を使用すれば、フラグメント表とイン
デックスに関する情報にアクセスできます。ユーザ定義ルーチンをフラグメント化式の
© Copyright IBM Corp. 1996, 2003
77
一部として使用している場合、その情報は sysfragexprudrdep に記録されます。この
システム カタログ表に格納されている情報について詳しくは、「IBM Informix: SQL ガ
イド: 参照」を参照してください。
エンド ユーザまたはクライアント アプリケーションの観点から見れば、フラグメント
表と、フラグメント化されていない表は同じです。クライアント アプリケーションで
は、フラグメント表内のデータにアクセスできるようにするのに、どのような変更も必
要ありません。
分散スキームによっては、データベース サーバは、どのフラグメントにどのデータが格
納されているかに関する情報を所有しているため、関連のないフラグメントにアクセス
することなく、クライアントからのデータ要求を適切なフラグメントにルーティングす
ることができます。(ただし、ラウンド ロビン分散スキームおよび式に基づく分散スキ
ームの場合、データベース サーバは、クライアントからのデータ要求を適切なフラグメ
ントにルーティングすることはできません。詳しくは、79 ページの『表のフラグメント
化のための分散スキーム』を参照してください。)
フラグメント化を使用する理由
次の目標のうち 1 つでも当てはまるものがあれば、表のフラグメント化を検討してくだ
さい。
v 単一ユーザ応答時間の向上
v 並行性の向上
v 可用性の向上
v バックアップと復元の特性の向上
v データのロードの向上
前記の目標は、それぞれ、最終的に実現するフラグメンテーション ストラテジに独自の
影響を与えます。使用する主要なフラグメント化目標により、フラグメンテーション ス
トラテジの実現方法が決まるか、あるいは少なくとも影響を受けることになります。フ
ラグメント化を使用して前記の目標のどれかが満たされるかどうかを決める場合、フラ
グメント化には何らかの管理活動や監視活動が余分に必要になることを念頭に入れてお
いてください。
前記の目標およびフラグメンテーション ストラテジの組み立て方法の詳細については、
IBM Informix: パフォーマンス ガイドを参照してください。
フラグメント化の責任者
フラグメント化に関して、データベース サーバ管理者の責任と DBA(データベース管理
者) の責任は、一部重複します。 DBA は、表フラグメント化を含めることのできるデ
ータベース スキーマを作成します。一方、データベース サーバ管理者は、フラグメン
ト表が常駐するディスク領域を割り当てることに責任を持ちます。こうした責任は、ど
ちらも単独で実行することはできません。このため、フラグメント化を実装するには、
78
IBM Informix: データベース設計および実装 ガイド
DBA とデータベース サーバ管理者の協力作業が必要になります。このマニュアルで
は、フラグメンテーション ストラテジを実現するのに DBA が実行するタスクについ
てだけ説明します。フラグメンテーション ストラテジを実現するためにデータベース
サーバー管理者が実行するタスクについては、「IBM Informix: 管理者ガイド」および
「IBM Informix: パフォーマンス ガイド」を参照してください。
Extended Parallel Server に対する拡張フラグメント化
Extended Parallel Server は、異なるコサーバに属する複数のディスク間で表とインデッ
クスをフラグメント化することができます。各表フラグメントは、異なるコサーバに属
する複数の物理ディスクと関連付けられた別個の DB 領域に常駐することができます。
DB スライスには、複数のコサーバ間で数多くの DB 領域を管理する機能が備わってい
ます。 DB スライスと DB 領域を作成すると、複数のコサーバ間でフラグメント化さ
れた表とインデックスを作成することができます。
複数のコサーバ間で表をフラグメント化する利点については、「IBM Informix: パフォー
マンス ガイド」を参照してください。 DB スライスと DB 領域の作成方法について
は、「IBM Informix: 管理者ガイド」を参照してください。
フラグメント化とロギング
Dynamic Server
Dynamic Server では、フラグメント表は、ログ付きデータベースにもログなしデータベ
ースにも属することができます。フラグメント化されていない表と同様に、フラグメン
ト表がログなしデータベースの一部になっている場合、障害が発生すると、データの矛
盾が発生する可能性があります。
Dynamic Server の終り
Extended Parallel Server
Extended Parallel Server では、フラグメント表は常時ログ付きデータベースに属しま
す。ただし Extended Parallel Server は、複数のログ付き表タイプとログなし表タイプを
サポートしません。詳しくは、212 ページの『Extended Parallel Server のログ付き表と
ログなし表』を参照してください。
Extended Parallel Server の終り
表のフラグメント化のための分散スキーム
分散スキームとは、行またはインデックスのエントリを複数のフラグメントに分散する
ときにデータベース サーバが使用する方法の 1 つです。 Informix データベース サー
バは、以下の分散スキームをサポートします。
第 5 章 表フラグメンテーション ストラテジ
79
v 式ベース。 この分散スキームは、指定された値を含む行を同じフラグメントに格納
します。各フラグメントに行のセットを割り当てる基準を定義するフラグメント化式
を、範囲規則または任意規則として指定します。残余フラグメントを指定すれば、ほ
かのどのフラグメントの基準とも一致しない行をすべて保持することができます。た
だし、残余フラグメントを指定すると、式に基づく分散スキームの効率が低下しま
す。
v ラウンド ロビン。 この分散スキームは、一連のフラグメントを循環しながら順次に
フラグメントに行を配置することにより、行を均等に分散させます。データベース
サーバはこの規則を内部で定義しています。
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: パフォーマンス ガイド」を参照してください。
式ベース分散スキーム
式ベース分散スキームを使用するには、CREATE TABLE または CREATE INDEX 文
の FRAGMENT BY EXPRESSION 節を使用してください。次の例では、FRAGMENT
BY EXPRESSION 節を使用して、式ベース分散スキームでフラグメント表を作成してい
ます。
80
IBM Informix: データベース設計および実装 ガイド
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 つずつ指定する必要がありま
す。
範囲規則 または 任意規則 を定義することにより、複数のフラグメントに行を分散させ
る方法をデータベース サーバに指示することができます。以降の節では、さまざまな種
類の、式に基づく分散スキームを説明します。
範囲規則
範囲規則は、SQL 関係演算子と論理演算子を使用して、表内の各フラグメントの境界を
定義します。範囲規則には、次の演算子の制限付きセットを使用することができます。
v 関係演算子 >、<、>=、<=
v 論理演算子 AND
範囲規則は、表内の列を 1 列だけ参照することができますが、この列への複数参照は実
行できません。次の例に示すように、表内の各フラグメントに式を 1 つずつ定義しま
す。
FRAGMENT
id_num >
id_num >
id_num >
BY
0
20
40
EXPRESSION
AND id_num <= 20 IN dbsp1,
AND id_num <= 40 IN dbsp2,
IN dbsp3
上の例では、他のフラグメントと重複しない 1 つのフラグメントをそれぞれの式が指定
しています。フラグメントが重複しないことにより、データベースのパフォーマンスが
向上します。 XPS では、フラグメントが重複しないことが必要 です。 XPS でフラグ
メントを使用する方法について詳しくは、「IBM Informix: Extended Parallel Server
Performance Guide」を参照してください。
任意規則
任意規則は、SQL 関係演算子と論理演算子を使用します。範囲規則と違って、任意規則
では、規則を定義するのにどの関係演算子と論理演算子でも使用できます。さらに、こ
の規則では、数多くの表列を参照することができます。次の例のように、通常任意規則
では、データをグループ化するのに論理演算子 OR を使用します。
FRAGMENT BY EXPRESSION
zip_num = 95228 OR zip_num = 95443 IN dbsp2,
zip_num = 91120 OR zip_num = 92310 IN dbsp4,
REMAINDER IN dbsp5
第 5 章 表フラグメンテーション ストラテジ
81
MOD 関数の使用 (IDS のみ)
FRAGMENT BY EXPRESSION 節で MOD 関数を使用して、表内の各行を整数 (ハッ
シュ値) のセットにマッピングすることができます。データベース サーバは、これらの
値を使用して、所定の行を格納するフラグメントを決めます。次の例では、式に基づい
た分散スキームでの MOD 関数の使用方法を示します。
FRAGMENT BY
MOD(id_num,
MOD(id_num,
MOD(id_num,
EXPRESSION
3) = 0 IN dbsp1,
3) = 1 IN dbsp2,
3) = 2 IN dbsp3
行の挿入と更新
行を挿入または更新する場合、データベース サーバは、指定された順序でフラグメント
式を評価して、その行がフラグメントのどれかに属しているかどうかを調べます。属し
ていれば、データベース サーバは、フラグメントの 1 つにその行を挿入するか、フラ
グメントの 1 つでその行を更新します。フラグメントのどれにも属していなければ、そ
の行は残りの節で指定されたフラグメント内に配置されます。分散スキームに残りの節
が含まれていない場合で、その行が既存のどのフラグメント式の基準とも一致しない場
合は、データベース サーバは、エラーを返します。
ラウンド ロビン分散スキーム
ラウンド ロビン分散スキームを指定するには、CREATE TABLE 文の FRAGMENT BY
ROUND ROBIN 節を使用してください。次の文はラウンド ロビン分散スキームでフラ
グメント表を作成します。
CREATE TABLE account_2
...
...
FRAGMENT BY ROUND ROBIN IN dbspace1, dbspace2, dbspace3
データベース サーバは、ラウンド ロビン分散を使用する表に数多くの行を挿入する要
求を受信した場合、各フラグメント内の行の数がほぼ同じ状態になるように行を分散し
ます。ラウンド ロビン分散は、情報を複数のフラグメントに均等に分散させるため、均
等分散とも呼ばれます。表でラウンド ロビン分散を使用する場合、この表に行を分散す
る規則は、データベース サーバの内部規則です。
重要: ラウンド ロビン分散スキームが使用できるのは、表のフラグメント化のみです。
この分散スキームを使用してインデックスをフラグメント化することはできませ
ん。
範囲分散スキーム (XPS のみ)
データ分散が高密度かつ均等であり、フラグメント化列に重複が含まれない場合は、範
囲分散スキームを使用して複数の DB 領域に行を均等に分散させることができます。範
囲分散では、ユーザがフラグメント間の行の分散を決定するために指定する MIN 値と
MAX 値が使用されます。
82
IBM Informix: データベース設計および実装 ガイド
次の文には、範囲分散スキームを指定する FRAGMENT BY RANGE 節が含まれていま
す。
CREATE TABLE cust_account (cust_id INT)
...
...
FRAGMENT BY RANGE (cust_id MIN 1000 MAX 5000)
IN dbsp_1, dbsp_2, dbsp_3, dbsp_4)
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 節に対応する異なる列に対して範囲スキームを指
定できます。ハイブリッド分散スキームで範囲フラグメント化を使用する方法について
は、84 ページの『ハイブリッド分散スキーム (XPS のみ)』を参照してください。
システム定義ハッシュ分散スキーム (XPS のみ)
データベース サーバは、システム定義ハッシュ アルゴリズムを使用して、指定のキー
をハッシングすることにより、データを均等に分散させます。システム定義ハッシュ ア
ルゴリズムでフラグメント化を行うことで、データを均等に分散できるだけでなく、ハ
ッシングされたキーを使用する問合せに対するフラグメントを自動的に除去できます。
複数の表に対してハッシュ フラグメント化を使用すれば、問合せで表を結合するときに
フラグメントを除去でき、また、ローカル コサーバにより多くの処理をさせることがで
きます。
システム定義ハッシュ分散スキームは、複数のフラグメントにデータを均等に分散させ
るのに望ましい方法ですが、以下の場合はほかの方法をとることをお勧めします。
v 範囲問合せを使用する場合
範囲分散スキームを使用する方がフラグメントの除去がより効果的になり、問合せの
性能が向上します。
v 指定の列に含まれる重複値が非常に不均等であるか、または、異なる値の数が非常に
少ない場合
第 5 章 表フラグメンテーション ストラテジ
83
いずれの状態も、データ スキューが生じて、一部のフラグメントがその他のフラグ
メントより大きくなることがあります。データ スキューが生じると、データベース
サーバが処理のために必要とするデータの量が、一部のフラグメントでは多く、その
他のフラグメントでは少なくなるため、性能の不均等化につながります。
システム定義ハッシュ分散スキームを指定するには、次のように 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: パフォーマンス ガイド」を参照してください。
84
IBM Informix: データベース設計および実装 ガイド
フラグメント表を新たに作成する
フラグメント表を作成するには、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 を使用してフラグメントを定義することにします。
第 5 章 表フラグメンテーション ストラテジ
85
次の例は、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 つのフラグメント表に変換したいと思うはずです。
この方法について、次の項で説明します。セクション 86 ページの『複数の非フラグ
メント表の使用』 の指示に従ってください。
v 既存の大規模な表をフラグメント化する
セクション 87 ページの『単一の非フラグメント表の使用』 の指示に従ってくださ
い。
変換を行う前に、新しく作成したフラグメント表を格納するための適切な数の DB 領域
を設定しておく必要があります。
複数の非フラグメント表の使用
複数のフラグメント化されていない表を結合して、1 つのフラグメント表にすることが
できます。フラグメント化されていない表の構造は同一でなければならず、別々の DB
領域に格納されていなければなりません。フラグメント化されていない表を結合するに
は、ALTER FRAGMENT 文で ATTACH 節を使用します。
たとえば、3 つの非フラグメント表 account1、account2、および account3 があるとしま
す。そしてそれぞれを DB 領域 dbspace1、dbspace2、および dbspace3 に格納するとし
ます。 3 つの表の構造はすべて同じであり、この 3 つの表を 1 つの表に結合し、その
表を共通列 acc_num に基づく式でフラグメント化します。
86
IBM Informix: データベース設計および実装 ガイド
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: パフォーマンス ガイド」を参照してください。
単一の非フラグメント表の使用
非フラグメント表からフラグメント表を作成するには、 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
Extended Parallel Server では、列の値を使用してフラグメント表の行を識別する必要が
あります。データベース サーバは、フラグメント表の行 ID をサポートしません。
第 5 章 表フラグメンテーション ストラテジ
87
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;
88
IBM Informix: データベース設計および実装 ガイド
フラグメンテーション ストラテジの修正
フラグメント表を変更するには 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 を作成し、その後で次の
文を実行します。
第 5 章 表フラグメンテーション ストラテジ
89
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 つ追加するオプション
が含まれています。
90
IBM Informix: データベース設計および実装 ガイド
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 節
第 5 章 表フラグメンテーション ストラテジ
91
ハッシュ フラグメント化を使用する表では、INIT オプションのみがサポートされてい
ます。
Extended Parallel Server は ADD 、DROP、および MODIFY オプション、ALTER
FRAGMENT ON INDEX 文または明示的な行 ID 列をサポートしていません。追加、
削除、修正の操作を処理するには、ADD、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;
92
IBM Informix: データベース設計および実装 ガイド
次の文は、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 を削除するには、次の
文を実行します。
第 5 章 表フラグメンテーション ストラテジ
93
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 つのアクセス権すべてを 1 度に付与したい場合は、
GRANT FRAGMENT 文でキーワード ALL を使用します。ただし、フラグメントを含
む表の名前を指定しただけでは、フラグメントアクセス権を付与することはできませ
ん。特定のフラグメントを指定する必要があります。
挿入、更新、削除の各アクセス権を取り消す場合は、REVOKE FRAGMENT 文を使用し
ます。この文は、1 人以上のユーザから、フラグメント表の 1 つ以上のフラグメントに
対するアクセス権を取り消します。表に対して現在存在しているアクセス権をすべて取
り消したい場合は、キーワード ALL を使用することができます。コマンドにフラグメ
ントを指定しないと、表のすべてのフラグメントに対して現在許可されているアクセス
権が取り消されます。
詳しくは、「IBM Informix: SQL ガイド: 構文」の GRANT FRAGMENT 文、REVOKE
FRAGMENT 文、および SET 文の説明を参照してください。
94
IBM Informix: データベース設計および実装 ガイド
第 6 章 データベース サーバのアクセス権の付与と制限
本章の概要
この章では、データベースへのアクセスの制御方法について説明します。データベース
によっては、すべてのユーザがすべてのデータにアクセスできる場合もあります。それ
以外のデータベースでは、ユーザによっては、データの一部またはすべてへのアクセス
が拒否されます。
SQL を使用したデータへのアクセスの制限
データへのアクセスは次のようなレベルで制限することができます。
v GRANT 文と REVOKE 文を使用して、データベースや特定の表に対するアクセス権
を付与したり拒否したりすることができます。また、データベースの利用の仕方を制
御することもできます。
v CREATE PROCEDURE 文 または CREATE FUNCTION 文を使用して、ユーザ定義
ルーチンを記述およびコンパイルすることができます。ユーザ定義ルーチンは、デー
タベース表の読込み、変更、および作成をすることができるユーザの制御と監視を行
います。
v
CREATE VIEW 文を使用して、データの制限付きビューや修正済みビューを作成す
ることができます。制限は特定の列を除く縦方向または特定の行を除く横方向に適用
することができます (両方向でも行えます)。
v GRANT 文と CREATE VIEW 文を結合して、ユーザが変更できる表の部分やデータ
の内容を的確に制御することができます。
データベースへのアクセスの制御
通常のデータベース アクセス権のメカニズムでは、96 ページの『アクセス権の付与』
で説明する GRANT 文と REVOKE 文がベースになります。ただし、状況によってはオ
ペレーティングシステムの機能を、データベースへのアクセスを制御するもう 1 つの方
法として使用できることもあります。
オペレーティングシステムがアクセスを制御するかどうかに関係なく、データベース全
体の内容の機密レベルが高い場合は、コンピュータに固定されているパブリックディス
ク上へ書込みを行うのは望ましいことではありません。データの機密を保護しなければ
ならないときは、通常のソフトウェア制御を使わないようにすることができます。
© Copyright IBM Corp. 1996, 2003
95
ユーザ自身または別の正当なユーザがデータベースを使用していないときは、そのデー
タベースをオンラインで使用可能にしておく必要はありません。次のいずれかの方法を
使用して、アクセス不能にすることができますが、手間のかかり具合は、方法ごとに異
なります。
v 物理媒体をコンピュータから切り離して、別の場所に保管する。ディスク自体がリム
ーバブルでない場合は、ディスクドライブがリムーバブルです。
v データベース ディレクトリをテープにコピーして、テープを保管する。
v 暗号化ユーティリティを使用して、データベースファイルをコピーする。暗号化バー
ジョンのみを保持します。
重要: 2 番目と 3 番目の方法では、コピーした後に、消去ファイルを NULL データで
上書きするプログラムを使用して、必ず元のデータベースファイルを消去しなけ
ればなりません。
データベースディレクトリ全体を削除する代わりに、個々の表のファイルをコピーして
から消去することもできます。インデックスファイルにはインデックス付き列からのデ
ータのコピーが含まれているので注意が必要です。表ファイルだけではなく、インデッ
クスファイルも削除して消去します。
アクセス権の付与
データベースを使用する許可のことをアクセス権と呼びます。たとえば、データベース
を使用する許可を Connect アクセス権と呼び、表に行を挿入する許可を Insert アクセ
ス権と呼びます。 GRANT 文を使用すると、データベース、表、ビュー、またはプロシ
ジャへのアクセス権を付与したり、あるロール (データベース サーバ管理の役割分担)
をユーザやほかのロールに付与したりできます。 REVOKE 文を使用すると、データベ
ース、表、ビュー、またはプロシジャへのアクセス権を取り消したり、あるロールをユ
ーザやほかのロールから取り消したりできます。
Dynamic Server
ロール とは、payroll など、DBA が割り当てる分類または作業タスクです。ロールを
割り当てるとアクセス権の管理に便利に使用できます。
Dynamic Server の終り
次に示すアクセス権のグループによって、ユーザがデータに対して実行できるアクショ
ンを制御します。
v データベース レベル アクセス権
v 所有アクセス権
v 表レベル アクセス権
96
IBM Informix: データベース設計および実装 ガイド
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 ア
クセス権を付与し、他のユーザには付与しません。
ユーザと public: アクセス権は名前を指定して単一のユーザに付与するか、public
という名前ですべてのユーザに付与します。 public に付与されるアクセス権は、デフ
ォルトアクセス権として機能します。
第 6 章 データベース サーバのアクセス権の付与と制限
97
文を実行する前に、必要なアクセス権がユーザに与えられているかどうかがデータベー
ス サーバによって判定されます。この情報はシステム カタログに格納されています。
詳しくは、100 ページの『システム カタログ表内のアクセス権』を参照してください。
データベース サーバは、まず最初に、アクセスを要求しているユーザに付与されている
アクセス権を探索します。要求しているアクセス権が見つかった場合は、その情報を使
用します。次に、制限の緩いアクセス権が public に付与されているかどうかがチェッ
クされます。付与されている場合は、制限の緩いアクセス権がデータベース サーバによ
って使用されます。そのユーザにアクセス権がまったく付与されていなければ、データ
ベース サーバは public に付与されているアクセス権を探します。妥当なアクセス権が
見つかれば、それが使用されます。
したがって、すべてのユーザに最小限のレベルのアクセス権を設定するには、アクセス
権を public に付与してください。特定の事情でそのアクセス権を無効にするには、よ
り高いレベルの個別アクセス権をユーザに付与します。
Resource アクセス権
Resource アクセス権は、Connect アクセス権と同じ権限を持っています。また、
Resource アクセス権を持っているユーザは、新しい永久表、インデックス、および SPL
ルーチンを作成することもできます。したがって、永続割当てディスク領域を作成でき
ます。
データベース管理者アクセス権
最高位のレベルのデータベース アクセス権はデータベース管理者つまり DBA が保有
します。つまり、データベースの作成者は、必然的に DBA になります。 DBA アクセ
ス権の所有者は次の機能を実行することができます。
v DROP DATABASE 文、START DATABASE 文、および ROLLFORWARD
DATABASE 文を実行する。
v 所有者が誰であるかにかかわらず、オブジェクトを削除したり変更したりする。
v 他のユーザが所有する表、ビュー、およびインデックスを作成する。
v データベース アクセス権 (DBA アクセス権を含む) を別のユーザに付与する。
v システムカタログ表の NEXT SIZE (この属性に限る) を変更して、systables 以外
のすべてのシステムカタログ表の行の挿入、削除、更新を行う。
警告: DBA アクセス権を持っているユーザは、ほとんどのシステム カタログ表を修正
できますが、それらのシステム カタログ表で行の更新、削除、または挿入を行わ
ないように強く推奨します。システムカタログ表を変更すると、データベースの
整合性が失われてしまう可能性があります。 ALTER TABLE 文を使用して、シ
ステム カタログ表の追加エクステントのサイズを変更することはできません。
98
IBM Informix: データベース設計および実装 ガイド
所有権
データベースと、その中のすべての表、ビュー、インデックス、プロシジャおよびシノ
ニムには所有者が設定されています。 DBA としてのアクセス権を持っているユーザ
は、他のユーザが所有するオブジェクトも作成することができますが、通常は、オブジ
ェクトを作成したユーザが、そのオブジェクトの所有者になります。
オブジェクトの所有者は、そのオブジェクトに対するすべての権限を持っていて、他の
アクセス権を持っていなくても、そのオブジェクトの変更や削除を実行することができ
ます。
Extended Parallel Server
一般化キー (GK) インデックスの場合、所有権が処理される方法は、その他のオブジェ
クトの場合と多少異なります。表の作成者以外の人物が GK インデックスを作成したと
しても、GK インデックスの FROM 節に表示される表はいずれも、GK インデックス
が削除されるまで削除できません。詳しくは、217 ページの『データ ウェアハウス環境
での GK インデックスの使用』を参照してください。
Extended Parallel Server の終り
表レベル アクセス権
表ごとに 7 種類のアクセス権を適用して、所有者のアクセス権を所有者でないユーザに
許可することができます。そのうちの 4 つ、つまり、Select アクセス権、Insert アクセ
ス権、Delete アクセス権、Update アクセス権は、表の内容に対するアクセスを制御しま
す。 Index アクセス権はインデックスの作成を制御します。 Alter アクセス権は、表定
義を変更する許可を制御します。 References アクセス権は、表に対して参照制約を指定
するための許可を制御します。
ANSI 標準準拠データベースでは、表の所有者のみにアクセス権が与えられます。それ
以外のデータベースでは、表作成の一環として、Alter アクセス権と References アクセ
ス権以外のすべての表アクセス権が、データベース サーバによって自動的に public に
付与されます。すべての表アクセス権を public に自動的に付与した場合は、Connect
アクセス権を持っていれば、どのユーザでも新しく作成された表にアクセスできます。
そうしたくない場合 (この表にアクセスできてはならないユーザが Connect アクセス権
を持っている場合) は、表の作成後に、public からの表に対するアクセス権をすべて取
り消す必要があります。
アクセス権
4 つのアクセス権によって、ユーザによる表へのアクセスの仕方を制御します。表の所
有者として、次のアクセス権を個々に付与したり、取り消したりすることができます。
v Select アクセス権では、一時表への取り出しなどの選択操作を実行することができま
す。
第 6 章 データベース サーバのアクセス権の付与と制限
99
v Insert アクセス権では、新しい行を追加することができます。
v Update アクセス権では、既存の行を変更することができます。
v Delete アクセス権では、行を削除することができます。
Select アクセス権は、ユーザが表の内容を抽出するのに必要です。ただし、Select アク
セス権は、他のアクセス権の前提条件ではありません。ユーザは、Select アクセス権を
持っていなくても、Insert アクセス権や Update アクセス権を持つことができます。
たとえば、アプリケーションに使用状況表が設定されている場合があります。その場合
は、ある特定のプログラムが開始されるたびに行が使用状況表に挿入され、その行が使
用されたことが記録されます。プログラムは、終了前にその行を更新して実行時間を表
示したり、そのユーザが実行した作業のカウントを記録します。
プログラムのすべてのユーザがこの使用状況表で行を挿入、または更新できるようにす
る場合は、その表に対する Insert アクセス権と Update アクセス権を public に付与し
ます。しかし、Select アクセス権は限られたユーザにのみ付与するものとします。
システム カタログ表内のアクセス権: アクセス権は、システムカタログ表に記録
されています。 Connect アクセス権を持つすべてのユーザは、システムカタログ表につ
いて問合せを行い、どんなアクセス権が誰に付与されているかを判別することができま
す。
データベース アクセス権は sysusers システム カタログ表に記録されています。この
表では、主キーはユーザ ID になっており、またそれ以外の列のみにアクセス権レベル
を表す単一文字 C、R、または D が含まれています。キーワード PUBLIC にアクセス
権が付与されていることは、ユーザ名 public (小文字) で分かります。
表レベルアクセス権は、表番号、権限授与者、および被権限授与者からなる複合主キー
を使用する systabauth に記録されています。列 tabauth では、図 24のダイヤグラム
が示しているリスト内で、アクセス権が符号化されます。
図 24. 符号化されたアクセス権のリスト
ハイフン (--) は、付与されていないアクセス権を表すので、すべてのアクセス権が付与
されている場合は su-idxar と表します。 -u------ は、Update アクセス権のみが付与
されていることを表します。通常、コード文字には小文字が使用されますが、GRANT
文でキーワード WITH GRANT OPTION を使用するときは大文字になります。
100
IBM Informix: データベース設計および実装 ガイド
3 つ目の位置にアスタリスク (*) が記されている場合は、その表と被権限授与者に何ら
かの列レベルアクセス権が存在しています。特定のアクセス権は syscolauth に記録さ
れます。その主キーは、表番号、権限授与者、被権限授与者、および列番号から成る複
合主キーです。属性は、s、u、または r の 3 文字で、アクセス権の型を示します。
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
第 6 章 データベース サーバのアクセス権の付与と制限
101
UNDER 節を使用して表を継承階層構造内に作成する方法については、154 ページの
『表継承』を参照してください。
表フラグメントのアクセス権 (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
)
この表には機密データが含まれているので、作成直後に次の文を実行します。
102
IBM Informix: データベース設計および実装 ガイド
REVOKE ALL ON hr_data FROM PUBLIC
人事部内の限られたメンバーとすべてのマネージャに対して、次の文を実行します。
GRANT SELECT ON hr_data TO harold_r
このようにして、限られたユーザが列すべてを見ることを許可します。マネージャのビ
ューをその部下だけに制限する方法については、この章の最終節を参照してください。
勤務評価を行う重役に対しては、次のような文を実行できます。
GRANT UPDATE (performance_level, performance_notes)
ON hr_data TO wallace_s, margot_t
この文を使用して、部下の評価を管理職が入力できるようにします。人事部長、または
給与レベルを変更できる資格があるユーザに対してのみ、次のような文を実行します。
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’
第 6 章 データベース サーバのアクセス権の付与と制限
103
型レベル アクセス権
Dynamic Server は、ユーザ定義データ型をサポートしています。ユーザ定義データ型が
作成されると、DBA またはそのデータ型の所有者のみが、その型の使用者を制御する
型レベル アクセス権を適用できます。 Dynamic Server は、次の型レベル アクセス権
をサポートしています。
v Usage アクセス権。ユーザ定義データ型を使用できる権限を制御します。
v Under アクセス権。名前付き行 (ROW) 型を継承階層構造の上位型として定義できる
権限を制御します。
ユーザ定義型の Usage アクセス権
不透明 (OPAQUE) 型、ディスティンクト (DISTINCT) 型、または名前付き行 (ROW)
型を誰が使用できるかを制御するには、データ型に Usage アクセス権を指定します。
Usage アクセス権を使用すると、DBA またはデータ型の所有者は、列、プログラム変
数 (または名前付き行 (ROW) 型の場合は表やビュー) にデータ型を割り当てる権限、
またはデータ型にキャストを割り当てるユーザの権限を制限できます。 Usage アクセス
権は、データ型が作成されると自動的に public に付与されます (ANSI 標準準拠デー
タベースの場合を除きます)。 ANSI 標準準拠データベースでは、データ型に対する
Usage アクセス権はそのデータ型の所有者に対して付与されます。
不透明 (OPAQUE) 型、ディスティンクト (DISTINCT) 型、または名前付き行 (ROW)
型を使用できるユーザを制限するには、まず public の Usage アクセス権を取り消し、
次に Usage アクセス権を付与するユーザの名前を指定する必要があります。たとえば、
circle という名前のデータ型の使用をあるユーザのグループだけに制限する場合、次の
文を実行します。
REVOKE USAGE ON circle
FROM PUBLIC;
GRANT USAGE ON circle
TO dawns, stevep, terryk, camber;
名前付き行 (ROW) 型の Under アクセス権
名前付き行 (ROW) 型に対して、Under アクセス権を付与、または取り消すことができ
ます。これにより、ユーザーが名前付き行 (ROW) 型を継承階層構造内で別の名前付き
行 (ROW) 型の上位型として割り当てられる能力を制御します。 Under アクセス権は、
名前付き行 (ROW) 型が作成されると自動的に public に付与されます。ただし、ANSI
標準準拠データベースの場合は違います。 ANSI 標準準拠データベースでは、名前付き
行 (ROW) 型に対する Under アクセス権はそのデータ型の所有者に対して付与されま
す。
特定のユーザが名前付き行 (ROW) 型を継承階層構造内の上位型として定義する権限を
制限するには、まず public の Under アクセス権を取り消してから、Under アクセス権
104
IBM Informix: データベース設計および実装 ガイド
を付与するユーザ名を指定します。たとえば、限られたユーザのグループだけが名前付
き行 (ROW) 型 person_t を継承階層構造内の上位型として使用できるようにする場
合、次の文を使用します。
REVOKE UNDER ON person_t
FROM PUBLIC;
GRANT UNDER ON person_t
TO howie, jhana, alison
UNDER 節を使用して名前付き行 (ROW) 型を継承階層構造内に作成する方法について
は、149 ページの『型継承』を参照してください。
ルーチン レベル アクセス権
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 を使用すると、ユーザは UDR をストアド プロシジャ言語 (SPL)、C
、および Java で作成することができます 。 UDR を作成するには、ユーザはデータベ
ース内における RESOURCE アクセス権を持っている必要があります。さらに、C また
は Java 言語で UDR を作成する場合は、ユーザが C または Java 言語に対する Usage
アクセス権も持っている必要があります。
デフォルトでは、UDR に対する言語の Usage アクセス権は、ユーザ informix と、
DBA アクセス権を持つユーザに付与されます。ただし、ユーザ informix のみが言語の
第 6 章 データベース サーバのアクセス権の付与と制限
105
Usage アクセス権を他のユーザに付与できます。 DBA アクセス権を持つユーザは、言
語の Usage アクセス権を持っていますが、これらの権限を他のユーザに付与することは
できません。
次の文は、ユーザ informix が UDR を C で作成する権限をユーザ mays、jones、
freeman に付与する方法を示します。
GRANT USAGE ON LANGUAGE C TO mays, jones, freeman
SPL ルーチンの Usage アクセス権は、デフォルトで public に付与されます。
たとえば、SPL ルーチンに対するデフォルトの Usage アクセス権が PUBLIC から取り
消されたとします。次の文は、DBA アクセス権を持つユーザが SPL ルーチンに対する
Usage アクセス権をユーザ franklin、reeves、および wilson に付与する方法を示しま
す。
GRANT USAGE ON LANGUAGE SPL TO franklin, reeves, wilson
アクセス権の自動化
この設計方法では、データベースを最初にセットアップするときに、かなりの数の
GRANT 文を実行しなければならない場合があります。また、ユーザの業務内容が変更
されるごとに、常にアクセス権を管理する必要があります。たとえば、人事部のある社
員が解雇された場合は、できる限り早く Update アクセス権を取り消す必要がありま
す。 そのような措置をとらないと、この解雇された社員によって次のような文が実行さ
れてしまう可能性があります。
UPDATE hr_data
SET (emp_name, hire_date, dept_num) = (NULL, NULL, 0)
機密データが含まれているモデルでは、必要に応じて毎日または毎時間ごとにアクセス
権を少しずつ変更しなければならない場合があります。アクセス権の変更が必要になる
場合は、アクセス権を保守しやすいように自動化ツールを用意することができます。
最初の手順としては、表の構造ではなく、ユーザの仕事内容に基づいてアクセス権クラ
スを指定しなければなりません。たとえば、マネージャには次のアクセス権が必要で
す。
v この例で示された hr_data 表に対する Select アクセス権と限定的な Update アクセ
ス権
v このデータベースと他のデータベースに対する Connect アクセス権
v それらのデータベース内の複数の表に対するある程度のアクセス権
マネージャが幹部に昇進したり、フィールド オフィスに出向したりした場合は、それま
でのアクセス権をすべて取り消して、新しい一連のアクセス権を付与する必要がありま
す。
106
IBM Informix: データベース設計および実装 ガイド
サポートするアクセス権クラスを定義して、アクセス権を与えなければならないデータ
ベース、表および列を、それぞれのクラスごとに指定してください。次に、クラスごと
に 2 つの自動化ルーチン、つまりユーザにクラスを付与するためのルーチンとそのクラ
スを取り消すためのルーチンを設定します。
コマンドスクリプトによる自動化
使用するオペレーティングシステムは、コマンドスクリプトの自動実行をサポートして
いるはずです。ほとんどの操作環境では、DB–Access などの対話型 SQL ツールでコマ
ンドと SQL 文を受け付けて、コマンド行から実行できるようになっています。この 2
つの機能を組み合わせて、アクセス権の保守を自動化することができます。
詳細は、使用するオペレーティング システム、および使用している対話型 SQL ツール
によって異なります。次の機能を実行するスクリプトを作成する必要があります。
v アクセス権が変更されるユーザ ID をパラメータとして解釈する。
v そのユーザ ID を含むようにカスタマイズされた GRANT 文または REVOKE 文の
ファイルを作成する。
v データベースを選択し、作成された GRANT 文または REVOKE 文のファイルを実
行するように指示するパラメータを指定して、対話型 SQL ツール (DB–Access など)
を起動する。
このようにすれば、ユーザのアクセス権クラスの変更操作を減らして、1 つまたは 2 つ
のコマンドにすることができます。
ロールの使用 (IDS のみ)
ユーザのアクセス権を場合に応じて簡単に変更するもう 1 つの方法は、ロールを使用す
ることです。データベース環境でのロールの概念は、オペレーティングシステムでのグ
ループの概念に似ています。ロールとは、一つのデータベース機能であり、DBA はこ
の機能を使用し、クラスのメンバとして扱うことによって、多くのユーザのアクセス権
を標準化したり変更したりすることができます。
たとえば、社内のニュースやメッセージを扱うデータベースに対して接続アクセス権、
挿入アクセス権、および削除アクセス権を付与する news_mes というロールを作成する
ことができます。新たに従業員が入社しても、その従業員をロール news_mes に追加す
るだけで済みます。この新しい従業員は、ロール news_mes のアクセス権を獲得しま
す。このプロセスは、その逆の働きもします。つまり、news_mes のすべてのメンバーの
アクセス権を変更するには、そのロールのアクセス権を変更します。
ロールの作成: ロール作成プロセスを開始するには、ロールの名前、および付与する
接続とアクセス権を決定します。接続とアクセス権は、まったくの自由裁量によって判
断するわけですが、ロールを命名するときに考慮しなければならないいくつかの要素が
あります。次の語は、ロールの名前に使用しないでください。
第 6 章 データベース サーバのアクセス権の付与と制限
107
alter
default
index
null
resource
connect
DBA
delete
execute
insert
none
public
references
select
update
ロール名は、データベース内の既存のロール名と異なっている必要があります。またサ
ーバ コンピュータにとって既知となっているネットワーク ユーザも含め、オペレーテ
ィング システムにとって既知のユーザ名とも異なっていなければなりません。自分のロ
ール名が一意であることを確認するには、次のシステムカタログ表だけではなく、デー
タベースを現在使用している共有メモリ構造体のユーザの名前をチェックします。
v sysusers
v systabauth
v syscolauth
v sysprocauth
v sysfragauth
v sysroleauth
状況が逆で、ユーザをデータベースに追加しているときには、そのユーザ名が既存のロ
ール名と同じになっていないかをチェックしてください。
ロール名を承認した後は、CREATE ROLE 文を使用して、新しいロールを作成します。
ロールを作成すると、デフォルトでは、ロール管理用のすべてのアクセス権が DBA.に
与えられます。
重要: ロールの有効範囲は現行データベースだけです。そのため、SET ROLE 文を実行
すると、そのロールは現行データベースだけに設定されます。
ユーザのアクセス権の操作と、あるロールのほかのロールへの付与: DBA であ
る場合は、GRANT 文を使用して、ロール アクセス権をユーザに付与することができま
す。また、アクセス権を他のユーザに付与するオプションをユーザに提供することもで
きます。これを行うには、GRANT 文の WITH GRANT OPTION 節を使用します。
WITH GRANT OPTION 節を使用できるのは、アクセス権をユーザに付与するときに限
られます。
たとえば、次の問合せは、オプション grantable を指定してロールへのアクセス権を付
与しているので、エラーが戻されます。
GRANT SELECT on tab1 to rol1
WITH GRANT OPTION
重要: アクセス権をロールに付与するときは、GRANT 文の WITH GRANT OPTION 節
を使用しないでください。ユーザのみが、アクセス権を他のユーザに付与するこ
とができます。
108
IBM Informix: データベース設計および実装 ガイド
ロール アクセス権を付与するときは、GRANT 文でユーザ名の代わりにロール名を使用
することができます。あるロールを別のロールに付与することもできます。たとえば、
ロール A がロール B に付与されているとします。その場合は、ユーザがロール B を
有効化すると、ロール A とロール B の両方からアクセス権がユーザに与えられます。
ただし、ロール付与のサイクルを推移させることはできません。ロール A をロール B
に付与して、ロール B をロール C に付与し、さらに C を A に付与するとエラーが
戻されます。
アクセス権を変更する必要がある場合は、REVOKE 文を使用して既存のアクセス権を削
除してから、GRANT 文を使用して新しいアクセス権を追加します。
ユーザによるロールの有効化の必要性: DBA がアクセス権を付与してユーザをロ
ールに追加した後、データベースセッションで SET ROLE 文を使用して、ロールを有
効化しなければなりません。ロールを有効化しない限りは、public に関連付けられたア
クセス権、または、オブジェクトの所有者であるという理由で直接付与されたアクセス
権に限定されます。
ロールでのメンバシップの確認とロールの削除: どのユーザがロールに含まれて
いるのかわからない状態になる場合があります。この場合は、ロールを作成していない
か、ロールを作成したユーザが有効でないことが考えられます。システム カタログ表
sysroleauth とシステム カタログ表 sysusers に対して問合せを行って、どの表に対
してどのユーザがアクセスを許可されているか、さらにロールがいくつ存在しているか
を確認してください。
どのユーザがどのロールのメンバーなのかがわかると、すでに一部のロールが不要であ
ることに気付く場合があります。ロールを削除するには、DROP ROLE 文を使用しま
す。ただし、ロールを削除するには、次の条件を満たしていなければなりません。
v システム カタログ表 sysusers にロールとしてリストされているロールのみを削除
することができます。
v ロールを削除するには、DBA としてのアクセス権を持っているか、あるいはロール
を削除するために付与できるロールのオプションを与えられていなければなりませ
ん。
SPL ルーチンによるデータへのアクセスの制御
SPL ルーチンを使用して、データベース内の個々の表または列へのアクセスを制御する
ことができます。ルーチンを使用して、さまざまな段階のアクセス制御を実行すること
ができます。 SPL の強力な機能の一つとして、SPL ルーチンを DBA アクセス権付き
ルーチンとして指定できる機能があります。 DBA アクセス権付きルーチンを作成する
と、ほとんどの、あるいはまったく表アクセス権を持たないユーザが、ルーチンの実行
時に DBA アクセス権を獲得します。このルーチンでは、限られた範囲内で、ユーザは
第 6 章 データベース サーバのアクセス権の付与と制限
109
一時的な DBA アクセス権を使用してタスクを実行することができます。 DBA アクセ
ス権付きルーチンを使用することにより、次のタスクを実行できます。
v 個々のユーザが表から読み込める情報の量を制限します。
v データベースに対するあらゆる変更を制限して、表全体が空にされたり、誤って変更
されるようなことがないようにします。
v 削除や挿入などの、表に対する変更のクラス全体を監視します。
v SPL ルーチン内で行われるあらゆるオブジェクトの作成 (データ定義) を制限して、
表、インデックス、およびビューの作成方法を完全に制御できるようにします。
SPL のルーチンについて詳しくは、「IBM Informix: SQL ガイド: チュートリアル」を
参照してください。
データの読込みの制限
次の例のルーチンでは、ユーザには SQL 構文が見えませんが、ユーザが customer 表
に対して Select アクセス権を持っている必要があります。何をユーザが選択できるかを
制限する場合は、次の環境で機能するようなルーチンを作成します。
v 自身が、データベースの DBA である。
v ユーザが、データベースに対する Connect アクセス権を持っている。そして、表に対
する SELECT アクセス権は持っていない。
v DBA キーワードを使用して、SPL ルーチン (または SPL ルーチンのセット) を作成
する。
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;
110
IBM Informix: データベース設計および実装 ガイド
データへの変更の制限
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;
データへの変更の監視
SPL ルーチンを使用して、データベースに加えられた変更のレコードを作成することが
できます。特定のユーザが行った変更を記録したり、変更が行われるたびにレコードを
作成したりすることができます。
単一のユーザがデータベースに対して行うすべての変更を監視することができます。そ
れぞれのユーザによる変更を追跡する SPL ルーチンを使用して、すべての変更の経路
を指定します。ユーザ acctclrk がデータベースに変更を加えるたびに記録したい場合
は、次のアクセス権でデータベースをセットアップします。
v 自身が、データベースの DBA である。
v 他のすべてのユーザが、データベースに対する Connect アクセス権を持っている。
Resource アクセス権は持っていないと考えられる。保護されている表に対しては、
Delete アクセス権 (この例の場合) を持っていない。
v DBA キーワードを使用して、SPL ルーチンを作成する。
v SPL ルーチンが削除を実行し、特定のユーザによる変更を記録する。
次の例のような SPL ルーチンを作成します。このルーチンでは、ユーザ指定の顧客番
号を使用して表を更新します。ユーザが acctclrk である場合は、削除のレコードはフ
第 6 章 データベース サーバのアクセス権の付与と制限
111
ァイル updates に入れられます。
UNIX のみ
CREATE DBA PROCEDURE delete_customer(cnum INT)
DEFINE username CHAR(8);
DELETE FROM customer
WHERE customer_num = cnum;
IF username = ’acctclrk’ THEN
SYSTEM ’echo Delete from customer by acctclrk >>
/mis/records/updates’ ;
END IF
END PROCEDURE;
プロシジャを用いて行われた削除をすべて監視するには、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;
UNIX のみ の終り
オブジェクト作成の制限
作成されるオブジェクト、およびその作成方法を抑制するには、次の設定で SPL ルー
チンを使用します。
v 自身が、データベースの DBA である。
v 他のすべてのユーザが、データベースに対する Connect アクセス権を持ている。
Resource アクセス権は持っていない。
v DBA キーワードを使用して、SPL ルーチン (または SPL ルーチンのセット) を作成
する。
v 自身の SPL ルーチン (または SPL ルーチンのセット) が、定義したとおりに表、イ
ンデックス、およびビューを作成する。そのようなルーチンを使用して、トレーニン
グ データベース環境をセットアップできる。
112
IBM Informix: データベース設計および実装 ガイド
次の例が示しているように、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 の場合は、このプ
ロシジャを実行するユーザは誰でも、二つの表とインデックスを所有することになりま
す。
ビューの使用
ビュー とは、合成した表のようなものです。ビューは、表ではないものを表であるかの
ように問合せることができ、場合によっては、表であるかのように更新することもでき
ます。しかし、ビューは表ではありません。実際の表と他のビューに存在するデータの
集合体です。
ビューの基本となるのは SELECT 文です。ビューを作成するときは、ビューのアクセ
ス時にビューの内容を生成する SELECT 文を定義します。ユーザは、SELECT 文を使
用したビューの問合せも行います。データベース サーバはユーザの SELECT 文をビュ
ーに対して定義した SELECT 文 とマージして、その結合された文を実際に実行するこ
ともあります。ビューのパフォーマンスについては、「IBM Informix: パフォーマンス
ガイド」を参照してください。
ビューの内容を決定する SELECT 文の作成者は、ビューを次のいずれかの目的に使用
することができます。
v ユーザを表の特定の列に制限する。
指定するのは、ビュー内の選択リスト内で許可されている列のみです。
v ユーザを表の特定の行に制限する。
許可された行のみを戻すように WHERE 節を指定する。
v 挿入する値または更新する値の範囲に制約を加える。
第 6 章 データベース サーバのアクセス権の付与と制限
113
WITH CHECK OPTION (119 ページを参照) を使用して、制約を強制することができ
ます。
v 冗長データをデータベースに格納せずに、導出データにアクセスできるようにする。
ビュー内の選択リストにデータを導出する式を書きます。ビューに対して問合せを行
うたびに、そのデータが新たに導出されます。導出されたデータは常に最新ですが、
冗長性はデータモデルに導入されません。
v 複雑な SELECT 文の詳細を隠す。
ビュー内の複数表結合による複雑性を隠し、ユーザとアプリケーションプログラマに
とって繰返しが不要になるようにします。
ビューの作成
次の例では、データベース stores_demo の表をベースにしてビューを作成します。
CREATE VIEW name_only AS
SELECT customer_num, fname, lname FROM customer
このビューは表の 3 つの列のみを表出させます。しかし、WHERE 節が含まれていない
ので、表示できる行は制限しません。
次の例は二つの表の結合をベースにしています。
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 を使用して、すべての行に完全な州名が格納されているかのように、住所
を抽出することができます。次の二つの問合せは同等です。
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 文を使用することができません。ビューを用いたデータの修正方法につい
ては、118を参照してください。
次の例は、ビューに表示できる行を制限します。
CREATE VIEW no_cal_cust AS
SELECT * FROM customer WHERE NOT state = ’CA’
114
IBM Informix: データベース設計および実装 ガイド
このビューは、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
型付きビューを作成すると、ビューが表示するデータは型付き行 (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() 関数に解決されます。
第 6 章 データベース サーバのアクセス権の付与と制限
115
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 文などのオブジェクトにしたりすることはでき
ません。また、ビューの列の名前を RENAME COLUMN 文で変更することもできませ
ん。ビューの定義に関する何かを変更するには、ビューをいったん削除してから再度作
成しなければなりません。
ユーザの問合せとマージしなければならないので、ビューのベースになる SELECT 文
には次の節やキーワードを含めないようにしてください。
116
INTO TEMP
ユーザの問合せには INTO TEMP 節が含まれている可能性がありま
す。ビューにも INTO TEMP 節が含まれていると、データの格納先が
不明になります。
ORDER BY 節
ユーザの問合せには ORDER BY 節が含まれている可能性がありま
す。ビューにも ORDER BY 節が含まれていると、列の選択やソート
方向が矛盾する場合があります。
IBM Informix: データベース設計および実装 ガイド
ビューのベースとなる SELECT 文には、UNION キーワードを指定することができま
す。そうした場合は、データベース サーバはそのビューを暗黙的一時表に格納します
が、この一時表でユニオンが必要に応じて評価されます。ユーザの問合せでは、この一
時表を基本表として使用します。
ベースの変更の反映
ビューのベースになっている表やビューを変更する方法はいくつかあります。ビューに
は、ほとんどの変更が自動的に反映されます。
表やビューが削除されると、同じデータベース内でその表やビューに依存しているビュ
ーも自動的に削除されます。
ビューの定義を変更する唯一の方法は、そのビューを削除して再度作成することです。
したがって、他のビューが依存しているビューの定義を変更する場合は、他のビューも
再度作成しなければなりません (すべて削除されているからです)。
表の名前を変更すると、同じデータベース内でその表に依存しているビューも、その新
しい名前を使用できるように変更されます。また、列の名前を変更すると、同じデータ
ベース内でその表に依存しているビューも、その固有の列を選択できるように更新され
ます。ただし、ビュー自体の中の列名は変更されません。この例では、customer 表に
ついて次のビューを再呼出しします。
CREATE VIEW name_only AS
SELECT customer_num, fname, lname FROM customer
ここで、customer 表が次の方法で変更されると仮定します。
RENAME COLUMN customer.lname TO surname
顧客の名字を直接選択するには、ここで新しい列名を選択しなければなりません。しか
し、ビューを介して見た場合には、列の名前は変わりません。次の二つの問合せは同等
です。
SELECT fname, surname FROM customer
SELECT fname, lname FROM name_only
列を削除して表を変更しても、ビューは変更されません。ビューが使用されていると、
エラー -217 (問合せのどの表にも、列 (%s) が見つかりません (または SLV が未定
義)。) が返されます。ビューが変更されないのは、列を削除してから同じ名前の新しい
列を追加することによって、列の順序を変更できるからです。これを行うと、その表を
ベースにしているビューが、引き続き機能します。列の元の順序が維持されます。
データベース サーバでは、ビューのベースとして、外部データベース内の表とビューを
使用することができます。他のデータベースの表とビューを変更しても、ビューには反
映されません。そのような変更は、誰かがビューに対する問合せを行って、外部表が変
更されているというエラーを受け取るまで分からない場合があります。
第 6 章 データベース サーバのアクセス権の付与と制限
117
ビューを用いたデータの変更
ビューは、表であるかのように変更することができます。使用する SELECT 文によっ
て、変更できるビューと変更できないビューがあります。制限は DELETE 文、
UPDATE 文、または INSERT 文を使用するかによって異なります。
ビューにビューを定義した SELECT 文に次の項目が含まれていなかった場合、そのビ
ューは修正可能 です。
v 複数の表の結合
v 集計関数または GROUP BY 節
v DISTINCT キーワードまたはそのシノニム UNIQUE
v UNION キーワード
ビューにこれらの要素がまったくなければ、ビューの各行が一つの表の 1 行に確実に対
応します。
ビューを用いたデータの削除
修正可能なビューでは、表と同様に DELETE 文を使用することができます。データベ
ース サーバは、ベースにしている表の固有の行を削除します。
ビューの更新
修正可能なビューでは、表と同様に UPDATE 文を使用することができます。ただし、
データベース サーバでは導出列の更新がサポートされていません。導出 列とは、
CREATE VIEW 文の選択リスト内の式で作成された列のことです (例: order_date +
30)。
次の例は、導出列と、それに対して受け入れることができる UPDATE 文が含まれてい
る、修正可能なビューを示しています。
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 は式を表しているため更新できません (データベース サーバ
は原則的に見ても、式で指定されている二つの列間で更新値の分散する方法を判定でき
ません)。ただし、導出列が SET 節で指定されていなければ、ビューが表であるかのよ
うに更新を実行することができます。
ビューは、基礎となる表の行が一意であっても重複行を返すことがあります。ある重複
行を別の重複行と区別することはできません。一連の重複行のいずれか一つを更新する
と (たとえば、カーソルを使用して、WHERE CURRENT を更新する)、基礎表のどの行
で更新を受け取るのかが分からなくなることがあります。
118
IBM Informix: データベース設計および実装 ガイド
ビューへの挿入
ビューが修正可能であり、かつ導出列が含まれていない場合、ビューに行を挿入するこ
とができます。二番目の制限が設けられているのは、挿入された行はすべての列の値を
表す必要があり、データベース サーバは、挿入された値を式を用いて分散させる方法を
認識できないからです。前の例に示すように、response ビューに挿入を試みると失敗
します。
修正可能なビューに導出列が含まれていなければ、あたかも表であるかのように、その
ビューに挿入することができます。ただし、データベース サーバは、ビューによって表
出されない列の値として NULL を使用します。そのような列に NULL を使用できない
場合は、エラーが発生して挿入に失敗します。
WITH CHECK OPTION キーワードの使用
ビューの条件を満たさない行、つまりビューで見ることができない行をビューに挿入す
ることができます。また、ビューの行を更新して、その行がビューの条件を満たさない
ようにすることもできます。
ビューの行が更新され、ビューの条件が満たされなくなることを回避するため、ビュー
の作成時に WITH CHECK OPTION キーワードを追加してください。この節を使用す
ると、挿入されたそれぞれの行や、更新されたそれぞれの行を検査して、ビューの
WHERE 節によって設定されている条件を満たしていることを確認するように、データ
ベース サーバに指示が出されます。条件が満たされていないと、データベース サーバ
はエラーメッセージを表示して、その操作を拒否します。
重要: ビュー定義に 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
第 6 章 データベース サーバのアクセス権の付与と制限
119
tony による前の更新は、エラーとして拒否されます。
WITH CHECK OPTION 機能を使用して、ブール式として記述できるあらゆる種類のデ
ータ制約を実行することができます。次の例では、データに対するすべての論理制約
が、WHERE 節の条件として表される表のビューを作成することができます。次に表に
対するすべての変更が、ビューを用いて行われるように要求することができます。
CREATE VIEW order_insert AS
SELECT * FROM orders O
WHERE order_date = TODAY -- no back-dated entries
AND EXISTS -- ensure valid foreign key
(SELECT * FROM customer C
WHERE O.customer_num = C.customer_num)
AND ship_weight < 1000 -- reasonableness checks
AND ship_charge < 1000
WITH CHECK OPTION
データベース サーバは既存の行を抽出するときに有効になる可能性がある EXISTS や
他のテストの影響で orders からのデータ表示の効率が悪くなります。ただし、orders
への挿入が、このビューのみを用いて行われる場合は (しかも、まだ整合性制約を使用
して、データを制約していない場合)、日付をさかのぼって挿入したり、無効な顧客番
号、過度の積込重量、および積出費などを挿入したりすることはできません。
PREPARE 文で処理された文をビュー定義の変更時に再実行
データベース サーバは、ビューで SELECT 文を PREPARE 文で処理するとき、その時
点で存在するビューの定義を使用します。あるビューで SELECT 文を PREPARE 文で
処理した後にそのビューの定義が変更されると、PREPARE 文で処理された文の実行結
果が不正になることがあります。新しいビュー定義が反映されないためです。 SQL エ
ラーは生成されません。
アクセス権とビュー
ビューを作成するときに、データベース サーバは、基礎となる表とビューに対するユー
ザのアクセス権をテストします。ビューを使用する場合は、そのビューに関するユーザ
のアクセス権だけがテストされます。
ビューの作成時のアクセス権
データベース サーバは、ビュー定義で SELECT 文を実行するために必要となるすべて
のアクセス権をユーザが持っているかどうかをテストします。必要なアクセス権がない
と、ビューは作成されません。
このテストによって、表に対するビューの作成と、ビューに対する問合せを実行して
も、ユーザは表に不正にアクセスすることができなくなります。
120
IBM Informix: データベース設計および実装 ガイド
ユーザがビューを作成した後は、そのビューの作成者であり所有者でもあるユーザに
は、少なくともビューに対する Select アクセス権がデータベース サーバによって付与
されます。新しく作成する表の場合のように、自動的に public にアクセス権が付与さ
れるわけではありません。
データベース サーバは、ビュー定義を検査して、そのビューが修正可能であるかどうか
を確認します。ビューが修正可能な場合は、データベース サーバによって、そのビュー
に対する Insert アクセス権、Delete アクセス権、および Update アクセス権が付与され
ますが、その場合は基礎となる表またはビューに対しても、それらのアクセス権がユー
ザに付与されていることが前提になります。つまり、新しいビューが修正可能である場
合には、データベース サーバは、Insert アクセス権、Delete アクセス権、Update アク
セス権を基礎となる表またはビューからコピーして、新しい表に対して付与します。基
礎表に対して Insert アクセス権しか持っていない場合は、ビューに対しても Insert アク
セス権のみが付与されます。
このテストによって、ユーザは、まだ付与されていないアクセス権に、ビューを使用し
てアクセスすることができなくなります。
ビューを変更したりインデックス付けすることはできないので、Alter アクセス権と
Index アクセス権がビューに対して与えられることはありません。
ビューを使用するときのアクセス権
ビューを使用しようとすると、データベース サーバは、そのビューに対して付与されて
いるアクセス権のみをテストします。基礎となっている表へのアクセス権はテストしま
せん。
ビューを作成した場合は、前のパラグラフで述べたアクセス権が与えられます。作成者
でない場合は、WITH GRANT OPTION アクセス権を持っていた作成者などが付与した
アクセス権が与えられることになります。
したがって、表を作成して、その表に対するパブリックアクセスを取り消すことができ
ます。このようにして、ビューを用いて次の表に対するアクセス権を付与することがで
きます。次の表はその定義を示しています。
CREATE TABLE hr_data
(
emp_key INTEGER,
emp_name CHAR(40),
hire_date DATE,
dept_num SMALLINT,
user-id CHAR(18),
salary DECIMAL(8,2),
performance_level CHAR(1),
performance_notes TEXT
)
第 6 章 データベース サーバのアクセス権の付与と制限
121
102 ページの『列レベル アクセス権』では、hr_data 表にアクセス権を直接付与する
方法を示しています。次の例では、別の方法がとられています。表の作成時に、次の文
が実行されたものとします。
REVOKE ALL ON hr_data FROM PUBLIC
このような文は、ANSI 標準準拠データベースでは不要です。ここで、さまざまなクラ
スのユーザに対して一連のビューを作成します。機密性のある列に対する読込み専用ア
クセス権を持っているべきユーザには、次のビューを作成します。
CREATE VIEW hr_public AS
SELECT emp_key, emp_name, hire_date, dept_num, user_id
FROM hr_data
このビューに対して Select アクセス権を付与されているユーザは、機密性のないデータ
を見ることはできますが、更新することはできません。新しい行を入力しなければなら
ない人事部の社員に対しては、次の例に示されているように、別のビューを作成しま
す。
CREATE VIEW hr_enter AS
SELECT emp_key, emp_name, hire_date, dept_num
FROM hr_data
これらのユーザには、このビューに対する Select アクセス権と Insert アクセス権を付
与します。表とビューの作成者として、その表とビューに対する Insert アクセス権を持
っているので、その表に対するアクセス権を持たない他のユーザに、ビューに対する
Insert アクセス権を付与することができます。
新しいユーザ ID を入力したり更新したりする MIS 部門の社員に代わって、次の例が
示しているように、別のビューを作成します。
CREATE VIEW hr_MIS AS
SELECT emp_key, emp_name, user_id
FROM hr_data
このビューは、部門番号と採用日を表出させないという点で、前のビューとは異なって
います。
なお、マネージャは、あらゆる列へのアクセス権だけではなく、自分の部下に限って勤
務評価データを更新できる必要があります。これらの要求を満たすには、それぞれの従
業員の部門番号とコンピュータユーザ ID が記述されている表 hr_data を作成しま
す。管理職自身も、管理している部門のメンバであるというルールを忘れてはなりませ
ん。そこで、次のビューによって、自分の部下のみを反映する行に管理職を限定しま
す。
122
IBM Informix: データベース設計および実装 ガイド
CREATE VIEW hr_mgr_data AS
SELECT * FROM hr_data
WHERE dept_num =
(SELECT dept_num FROM hr_data
WHERE user_id = USER)
AND NOT user_id = USER
最後の条件は、マネージャが表内の自分の行に対して更新のアクセス権を持たないよう
にするために必要です。したがって、次の文が示しているように、このビューでは、一
定の列に対してのみ、Update アクセス権を安全にマネージャに付与することができま
す。
GRANT SELECT, UPDATE (performance_level, performance_notes)
ON hr_mgr_data TO peter_m
第 6 章 データベース サーバのアクセス権の付与と制限
123
124
IBM Informix: データベース設計および実装 ガイド
第 3 部 オブジェクト リレーショナル データベース
第 7 章 Dynamic Server での拡張データ
型の作成と使用 . . . . . . . . . .
Informix のデータ型 . . . . . . . . .
基本データ型または最小のデータ型 . . .
事前定義データ型 . . . . . . . . .
ブール (BOOLEAN) 型とラージ可変長
文字 (LVARCHAR) 型 . . . . . .
バイナリ ラージ オブジェクト
(BLOB) 型と文字ラージ オブジェクト
(CLOB) 型 . . . . . . . . . .
その他の事前定義データ型 . . . . .
拡張データ型 . . . . . . . . . .
複合データ型 . . . . . . . . .
ユーザ定義データ型 . . . . . . .
ディスティンクト (DISTINCT) 型 . .
不透明 (OPAQUE) 型 . . . . . .
DataBlade データ型 . . . . . . .
スマート ラージ オブジェクト . . . . .
バイナリ ラージ オブジェクト(BLOB) 型
文字ラージ オブジェクト (CLOB) 型 . .
スマート ラージ オブジェクトの使用 . .
スマート ラージ オブジェクトのコピー
複合データ型 . . . . . . . . . . .
コレクション (COLLECTION) 型 . . .
コレクションの NULL 値 . . . . .
セット (SET) 型のコレクション
(COLLECTION) 型の使用 . . . . .
マルチセット (MULTISET) 型のコレク
ション (COLLECTION) 型の使用 . .
リスト (LIST) 型のコレクション
(COLLECTION) 型の使用 . . . . .
コレクション (COLLECTION) 型の入
れ子 . . . . . . . . . . . .
既存の表へのコレクション
(COLLECTION) 型の追加 . . . . .
コレクション (COLLECTION) 型に関
する制限 . . . . . . . . . . .
名前付き行 (ROW) 型 . . . . . . .
名前付き行 (ROW) 型を使用する場合
名前付き行 (ROW) 型の名前の選択
名前付き行 (ROW) 型の制限 . . . .
© Copyright IBM Corp. 1996, 2003
127
127
128
128
129
129
129
129
130
130
130
131
131
132
132
132
133
134
134
135
136
137
138
138
139
139
140
140
141
141
142
名前付き行 (ROW) 型を使用した型付
き表の作成 . . . . . . . . .
表の型の変更 . . . . . . . .
名前付き行 (ROW) 型を使用した列の
作成 . . . . . . . . . . .
別の行 (ROW) 型の中での名前付き行
(ROW) 型の使用 . . . . . . .
名前付き行 (ROW) 型の削除 . . .
名前なし行 (ROW) 型 . . . . . .
. 143
. 144
. 145
. 146
. 146
. 147
第 8 章 Dynamic Server による型継承と
表継承 . . . . . . . . . . . . .
継承について . . . . . . . . . . .
型継承 . . . . . . . . . . . . .
型階層の定義 . . . . . . . . . .
型階層内の型に対するルーチンのオーバー
ロード . . . . . . . . . . . .
継承と型代用性 . . . . . . . . .
型階層からの名前付き行 (ROW) 型の削除
表継承 . . . . . . . . . . . . .
型階層と表階層との関係 . . . . . .
表階層の定義 . . . . . . . . . .
表階層内の表の動作の継承 . . . . . .
表階層内の表の動作の修正 . . . . . .
表階層内の表に関する制約 . . . . .
表階層内の表へのインデックスの追加
表階層内の表のトリガ . . . . . .
表階層内のシリアル (SERIAL) 型 . . .
表階層への表の追加 . . . . . . . .
表階層内の表の削除 . . . . . . . .
表階層内の表の構造の変更 . . . . . .
表階層内の表の問合せ . . . . . . .
表階層内の表のビューの作成 . . . . .
152
152
153
154
154
155
156
158
158
158
159
159
160
162
162
162
162
第 9 章 Dynamic Server でのユーザ定義
キャストの作成と使用 . . . . . . .
キャストとは . . . . . . . . . .
ユーザ定義キャストの作成 . . . . .
キャストの起動 . . . . . . . .
ユーザ定義キャストに関する制限 . .
行 (ROW) 型のキャスト . . . . . .
165
165
166
166
167
167
.
.
.
.
.
.
149
149
149
149
125
名前付き行 (ROW) 型と名前なし行
(ROW) 型の間のキャスト . . . . . .
名前なし行 (ROW) 型どうしのキャスト
名前付き行 (ROW) 型の間でのキャスト
フィールドでの明示的キャストの使用 . .
名前なし行 (ROW) 型のフィールドの
明示的キャスト . . . . . . . .
名前付き行 (ROW) 型のフィールドの
明示的キャスト . . . . . . . .
行 (ROW) 型の各フィールドのキャスト
コレクション (COLLECTION) 型のキャスト
コレクション (COLLECTION) 型の変換の
制限 . . . . . . . . . . . . .
要素型が異なるコレクション . . . . .
要素型に暗黙的キャストを使用する
要素型の変換に明示的キャストを使用
する . . . . . . . . . . . .
リレーショナル データから マルチセット
(MULTISET) 型コレクションへの変換 . .
ディスティンクト型のキャスト . . . . .
ディスティンクト型での明示的キャストの
使用 . . . . . . . . . . . . .
ディスティンクト型とソース型の間のキャ
スト . . . . . . . . . . . . .
ディスティンクト型のキャストの追加と削
除 . . . . . . . . . . . . . .
スマート ラージ オブジェクトへのキャスト
ユーザ定義キャストのキャスト関数の作成
名前付き行 (ROW) 型間でのキャストの例
ディスティンクト型間でのキャストの例
マルチレベル キャスト . . . . . . .
126
168
169
169
170
170
170
171
171
172
172
173
173
173
174
174
175
176
176
177
177
178
180
IBM Informix: データベース設計および実装 ガイド
第 7 章 Dynamic Server での拡張データ型の作成と使用
本章の概要
この章では、拡張データ型について説明します。拡張データ型を使用すると、オブジェ
クト リレーショナル データベースを作成できます。オブジェクト リレーショナルとい
う用語は、特定のデータベース設計方法またはモデルに関連付けられたものではなく、
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には、表の列に格納されるデータの型
に応じて、適切なデータ型を選択するためのチャートが示されています。 128 ページの
図 25 は、データベース サーバがデータ型を管理する方法を反映するデータ型の階層を
示しています。
© Copyright IBM Corp. 1996, 2003
127
図 25. Informix のデータ型
基本データ型または最小のデータ型
すべての Informix データベース サーバは、基本 データ型、または 最小の データ型を
サポートしています。これらの型は SELECT 文で指定できる最小単位であるため、基
本的であるといえます。拡張データ型と事前定義データ型をサポートしているのは、
Dynamic Server のみです。事前定義型は別のカテゴリにありますが、これは事前定義型
には拡張データ型との共通特性があるものの、事前定義型はデータベース サーバによっ
て提供されるためです。
基本データ型については、 39 ページの『第 3 章 データ型の選択』を参照してくださ
い。
事前定義データ型
データベース サーバは、基本データ型を提供しているのと同様に、事前定義データ型を
提供しています。ただし、事前定義データ型には、拡張データ型との共通特性がありま
す。
128
IBM Informix: データベース設計および実装 ガイド
ブール (BOOLEAN) 型とラージ可変長文字 (LVARCHAR) 型
ブール (BOOLEAN) 型とラージ可変長文字 (LVARCHAR) 型は、組込みデータ型と同
様に動作しますが、これらの型はシステム カタログ表で拡張データ型として定義される
という点で組込みデータ型とは異なります。
詳しくは、39 ページの『第 3 章 データ型の選択』および「IBM Informix: SQL ガイド
: 参照」のシステム カタログ表の説明を参照してください。
バイナリ ラージ オブジェクト (BLOB) 型と文字ラージ オブジェクト
(CLOB) 型
バイナリ ラージ オブジェクト (BLOB) 型と文字ラージ オブジェクト (CLOB) 型は基
本データ型ではありません。これは、バイナリ ラージ オブジェクト (BLOB) 型または
文字ラージ オブジェクト (CLOB) 型からユーザがデータへランダムにアクセスできる
ためです。バイナリ ラージ オブジェクト (BLOB) 型および文字ラージ オブジェクト
(CLOB) 型の列を持つ表を作成することができますが、作成した列に直接データを挿入
することはできません。データを挿入、操作するには、関数を使用する必要がありま
す。
詳しくは、132 ページの『スマート ラージ オブジェクト』を参照してください。
その他の事前定義データ型
BLOB 型、ブール (BOOLEAN) 型、CLOB 型、およびラージ可変長文字 (LVARCHAR)
型を除き、通常、事前定義データ型は表の列のデータ型とはなりません。代わりに、事
前定義データ型は、複合データ型、事前定義データ型、およびユーザ定義ルーチンと関
連付けられた関数で使用されます。次の表は残りの事前定義データ型のリストです。
clientbinval
indexkeyarray
sendrecv
ifx_lo_spec
ifx_lo_stat
impexp
impexpbin
lolist
pointer
rtnparamtypes
selfuncargs
stat
stream
これらの事前定義データ型について詳しくは、「IBM Informix: ユーザ定義ルーチンおよ
びデータ タイプ 開発者ガイド」を参照してください。
拡張データ型
拡張データ型により、組込みデータ型では容易に表すことができないデータを表現する
データ型を作成することができます。ただし、分散トランザクションでは拡張データ型
を使用できません。 図 26 は拡張データ型を示しています。
第 7 章 Dynamic Server での拡張データ型の作成と使用
129
図 26. 拡張データ型
複合データ型
複合データ型は、すべてのデータが 1 種類の型 (LIST、SET、および MULTISET) であ
るデータ オブジェクトのコレクション、または異なる型のオブジェクトのグループ (名
前付き行と名前なし行) です。
ユーザ定義データ型
拡張データ型は、データベース サーバから提供されないデータ型です。ユーザは、デー
タベース サーバが不透明 (OPAQUE) 型、またはディスティンクト (DISTINCT) 型を管
理するために必要なすべての情報を指定する必要があります。
ディスティンクト (DISTINCT) 型
ディスティンクト (DISTINCT) 型は、カプセル化されたデータ型で、CREATE
DISTINCT TYPE 文で作成します。ディスティンクト (DISTINCT) 型は、基になったデ
ータ型と表現は同じですが、性質は異なります。ディスティンクト (DISTINCT) 型は、
130
IBM Informix: データベース設計および実装 ガイド
組込み型、不透明 (OPAQUE) 型、名前付き行 (ROW) 型、またはほかのディスティン
クト (DISTINCT) 型から作成できます。ディスティンクト (DISTINCT) 型は、次のデー
タ型からは作成できません。
v シリアル (SERIAL) 型
v 8 バイト シリアル (SERIAL8) 型
v コレクション (COLLECTION) 型
v 名前なし行 (ROW) 型
ディスティンクト (DISTINCT) 型はソース データ型の構造体を継承するので、ディス
ティンクト (DISTINCT) 型を作成するときにはデータ型の構造体が暗黙的に定義されま
す。ディスティンクト (DISTINCT) 型を操作する関数、演算子、および集合を定義する
こともできます。
ディスティンクト (DISTINCT) 型については、174 ページの『ディスティンクト型のキ
ャスト』、「IBM Informix: SQL ガイド: 構文」、および「IBM Informix: SQL ガイド:
参照」を参照してください。
不透明 (OPAQUE) 型
不透明 (OPAQUE) 型は、カプセル化されたデータ型で、CREATE OPAQUE TYPE 文
で作成します。不透明 (OPAQUE) 型を作成するときは、データ型の構造体、その不透
明 (OPAQUE) 型を操作する関数、演算子、および集合も明示的に定義する必要があり
ます。不透明型 (OPAQUE) 型は、列およびプログラム変数を定義するときに使用でき
ます。方法は、組込み型を使用する場合と同様です。
不透明 (OPAQUE) 型の作成については、「IBM Informix: ユーザ定義ルーチンおよびデ
ータ タイプ 開発者ガイド」および「IBM Informix: SQL ガイド: 構文」を参照してく
ださい。
DataBlade データ型
130 ページの図 26 のダイヤグラムには、実際にはデータ型ではありませんが、
DataBlade データ型が記述されています。 DataBlade とは、ユーザ定義データ型とユー
ザ定義ルーチンのセットで、特殊アプリケーション用のツールを提供しています。たと
えば、イメージ管理、時系列、および天体観測のためのツールは、それぞれ異なる
DataBlade が提供しています。このようなアプリケーションでは、不透明 (OPAQUE) 型
と同時に他のユーザ定義データ型が必要になることが多くあります。 DataBlade の開発
については、「IBM Informix: DataBlade API Programmer’s Guide」および DataBlade
Developers Kit を参照してください。 IBM が提供している DataBlades に関する情報に
ついては、御社の顧客担当者にお問合せください。
第 7 章 Dynamic Server での拡張データ型の作成と使用
131
スマート ラージ オブジェクト
スマート ラージ オブジェクト とは、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: 管理者ガイ
ド 」を参照してください)。
文字ラージ オブジェクト (CLOB) 型はテキスト (TEXT) 型に似ていますが、文字ラー
ジ オブジェクト (CLOB) 型には次の利点があります。
v アプリケーション プログラムは、CLOB オブジェクトの任意の部分に対し、読出し
または書込みができます。
v アプリケーション プログラムが CLOB オブジェクトの任意の部分にアクセスできる
ことにより、アクセス時間が大幅に高速化されます。
132
IBM Informix: データベース設計および実装 ガイド
v デフォルト特性のオーバーライドが、比較的簡単に行えます。データベース管理者
は、SB 領域のデフォルト特性を列レベルで上書きすることができます。アプリケー
ション プログラマは、CLOB オブジェクトを作成するときには、列のデフォルト特
性の一部をオーバーライドすることができます。
v 等演算子 (=) を使用して、2 つの CLOB の値が等しいかどうかをテストできます。
v CLOB オブジェクトは、システム障害が発生した場合にリカバリすることが可能であ
り、また DBA またはアプリケーション プログラマがトランザクション排他設定モ
ードを指定した場合はそれに従います。ただし、CLOB オブジェクトを復旧するに
は、データベース システムに、CLOB オブジェクトの処理に十分な大きさのバッフ
ァを提供できるリソースが必要です。
v 文字ラージ オブジェクト (CLOB) 型を使用すると、ユーザ定義のデータ型を格納す
る大きな領域を提供できます。
v DataBlade の開発者は、文字ラージ オブジェクト (CLOB) 型のインデックスを作成
できます。
文字ラージ オブジェクト (CLOB) 型の欠点は次のとおりです。
v ディスク ページ全体が割り当てられるため、短いデータの場合はディスク容量が無
駄になります。
v SQL 文での CLOB 列の使用には制約があります。 (133 ページの『スマート ラージ
オブジェクトの使用』を参照してください。)
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 列は次のようになります。
第 7 章 Dynamic Server での拡張データ型の作成と使用
133
v DEFAULT NULL 節を付けて表を作成すると、デフォルト値として NULL 値を指定
できます。
v 表の作成時に NOT NULL 制約を使用すると、NULL 値を不許可にできます。
v IS [NOT] NULL 述部を使用することにより、テストすることができます。
ESQL/C プログラムから ifx_lo_stat() 関数を使用すると、BLOB データまたは CLOB
データの長さを判断できます。
スマート ラージ オブジェクトのコピー
Dynamic Server には SQL 文から呼び出してスマート ラージ オブジェクトをインポー
トおよびエクスポートできる関数が提供されています。 表 3 にスマート ラージ オブ
ジェクト関数を示します。
表 3. スマート ラージ オブジェクトを扱う SQL 関数
関数名
内容
FILETOBLOB()
FILETOCLOB()
LOCOPY()
ファイルを BLOB 列にコピーします。
ファイルを CLOB 列にコピーします。
BLOB データまたは CLOB データを別の BLOB または
CLOB 列にコピーします
BLOB データまたは CLOB データをファイルにコピーしま
す
LOTOFILE()
スマート ラージ オブジェクト関数の詳細および構文については、「IBM Informix: SQL
ガイド: 構文」の式セグメントの説明を参照してください。
重要: BLOB 型と CLOB 型との間でのキャストは許可されていません。
複合データ型
複合データ型は、通常、ほかの既存のデータ型の複合です。たとえば、組み込み型、不
透明 (OPAQUE) 型、ディスティンクト (DISTINCT) 型、またはほかの複合型をコンポ
ーネントに含む複合データ型を作成できます。ユーザ定義型に比べ、複合データ型に
は、ユーザが複合データ型の各コンポーネントにアクセスし、操作できるという重要な
利点があります。
これに対し、組込み型とユーザ定義型は、独立した (カプセル化された) 型です。その
ため、不透明 (OPAQUE) 型のコンポーネントの値にアクセスするには、不透明
(OPAQUE) 型に定義した関数を使うのが唯一の方法です。
図 27 に、Dynamic Server がサポートする複合データ型、および複合データ型の作成に
使用する構文を示します。
134
IBM Informix: データベース設計および実装 ガイド
図 27. 複合データ型
図 27 で示す複合データ型により、次の拡張データ型がサポートされます。
v コレクション (COLLECTION) 型。コレクション (COLLECTION) 型は、データのコ
レクションを表セルに格納したり、操作する必要がある場合に使用できます。コレク
ション (COLLECTION) 型は、列に割り当てることができます。
v 行 (ROW) 型。行 (ROW) 型は、一般的に複数のフィールドを含みます。列または変
数に複数の種類のデータを格納するときに、行 (ROW) 型を作成できます。行
(ROW) 型には、名前付き行 (ROW) 型と名前なし行 (ROW) 型の 2 種類がありま
す。名前なし行 (ROW) 型は、列および変数に割り当てることができます。名前付き
行 (ROW) 型は、列、変数、表、またはビューに割り当てることができます。名前付
き行 (ROW) 型を表に割り当てると、表は型付き表になります。型付き表の主な利点
は、継承階層構造を定義するのに使用できるということです。
この章で説明する複合データ型で SELECT、INSERT、UPDATE、および DELETE の操
作を実行する方法について詳しくは、「IBM Informix: SQL ガイド: チュートリアル」
を参照してください。
コレクション (COLLECTION) 型
コレクション (COLLECTION) 型により、データのコレクションを表の 1 つの行に格納
して操作することができます。コレクション (COLLECTION) 型には 2 つのコンポーネ
ントがあります。 1 つはそのコレクション (COLLECTION) 型がセット (SET) 型、マ
ルチセット (MULTISET) 型、またはリスト (LIST) 型のいずれであるかを決定する型コ
ンストラクタ で、もう 1 つはそのコレクションに含めることができるデータ型を指定
する要素型 です。 (セット (SET) 型、マルチセット (MULTISET) 型、リスト (LIST)
型 の各コレクション (COLLECTION) 型については、次の節で詳しく説明します)。
コレクションの要素は、ほとんどすべてのデータ型をとることができます。 (例外の一
覧については、140 ページの『コレクション (COLLECTION) 型に関する制限』を参
照)。コレクションの要素 とは、コレクションが含む値です。次の値を含むコレクショ
ンを考えます。 {'blue', 'green', 'yellow', and 'red'}。ここで 'blue' はコレクシ
ョン中の単一の要素を表します。コレクションの各要素は、同じ型にする必要がありま
す。たとえば、要素型が整数 (INTEGER) 型のコレクションに含めることができるの
は、整数の値だけです。
第 7 章 Dynamic Server での拡張データ型の作成と使用
135
コレクションの要素型は、1 つのデータ型 (列) を表すことも、複数のデータ型 (行) を
表すこともできます。次の例で、列 col_1 は整数の SET を表します。
col_1 SET(INTEGER NOT NULL)
複数のデータ型を含むコレクション (COLLECTION) 型を定義するには、名前付き行
(ROW) 型、または名前なし行 (ROW) 型を使用します。次の例で、列 col_2 はフィー
ルド name およびフィールド salary を含む行のセット (SET) 型を表します。
col_2 SET(ROW(name VARCHAR(20), salary INTEGER) NOT NULL)
重要: コレクション (COLLECTION) 型を定義する場合は、型定義の一部として NOT
NULL 制約を含める必要があります。コレクション (COLLECTION) 型には、ほ
かの列制約は許されません。
列をコレクション (COLLECTION) 型として定義すると、コレクションに対して次の操
作を実行できるようになります。
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;
136
IBM Informix: データベース設計および実装 ガイド
しかし、次の各文ではコレクション要素が 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 表の各行には、従業員の情報と共に、従業員の扶養家族の名前お
よび生年月日のコレクションが含まれます。たとえば、扶養家族がいない従業員の場
第 7 章 Dynamic Server での拡張データ型の作成と使用
137
合、列 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) 型の使い方を説明します。営業部が営業部員ごとの月別総売り上げ高を
記録する必要があるとします。営業部員ごとの月別総売り上げ高を含む表の列は、リス
ト (LIST) 型を使用して定義できます。次の例で作成される表の列 month_sales はリ
スト (LIST) 型です。リスト (LIST) 型の最初のエントリ (要素) には、順序を示す位置
138
IBM Informix: データベース設計および実装 ガイド
として 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) 型に変換することはできません。
コレクション (COLLECTION) 型の列の追加と削除について詳しくは、「IBM Informix:
SQL ガイド: 構文」の ALTER TABLE 文の説明を参照してください。
第 7 章 Dynamic Server での拡張データ型の作成と使用
139
コレクション (COLLECTION) 型に関する制限
次のデータ型は、コレクションの要素型としては使用できません。
v テキスト (TEXT) 型
v バイト (BYTE) 型
v シリアル (SERIAL) 型
v 8 バイト シリアル (SERIAL8) 型
CREATE INDEX 文では、コレクション (COLLECTION) 型のインデックスを作成する
ことも、コレクション (COLLECTION) 型の列の関数インデックスを作成することもで
きません。
名前付き行 (ROW) 型
名前付き行 (ROW) 型 は、単一名で定義されたフィールドのグループです。フィールド
は、行 (ROW) 型のコンポーネントを指します。列と混同しないように注意してくださ
い。列は、表にだけ関連付けられます。名前付き行 (ROW) 型のフィールドは、C 言語
の構造体のフィールド、またはオブジェクト指向プログラミングのクラスのメンバに似
ています。名前付き行 (ROW) 型を作成した後、行 (ROW) 型に割り当てた名前によっ
て、データベースの中で一意の型が表されます。名前付き行 (ROW) 型を作成するに
は、行 (ROW) 型の名前と、その行 (ROW) 型を構成するフィールドの名前とデータ型
を指定します。次の例で、person_t という名前付き行 (ROW) 型を作成する方法を示
します。
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 が含まれます。名前付き行 (ROW) 型を作成すると、ほかの
データ型を使用するのと同じように、この型を使用できます。 person_t は、ほかのデ
ータ型が使用できるすべての場所で使用できます。次の CREATE TABLE 文では、
person_t データ型を使用しています。
CREATE TABLE
(
sport
sportnum
member
since
paidup
)
140
sport_club
CHAR(20),
INT,
person_t,
DATE,
BOOLEAN
IBM Informix: データベース設計および実装 ガイド
行 (ROW) 型のフィールドを定義するときには、ほとんどのデータ型を使用することが
できます。行 (ROW) 型がサポートしないデータ型については、142 ページの『名前付
き行 (ROW) 型の制限』を参照してください。
名前付き行 (ROW) 型の作成に使用する構文については、「IBM Informix: SQL ガイド:
構文」の CREATE ROW TYPE 文の説明を参照してください。行 (ROW) 型の値をキ
ャストする方法については、 165 ページの『第 9 章 Dynamic Server でのユーザ定義キ
ャストの作成と使用』を参照してください。
名前付き行 (ROW) 型を使用する場合
名前付き行 (ROW) 型は、Dynamic Server で新しいデータ型を作成する方法の 1 つで
す。名前付き行 (ROW) 型を作成するときは、データベース サーバが理解できるデータ
型で、フィールドのテンプレートを定義します。このように、行 (ROW) 型のフィール
ド定義は、表の列定義と似ています。どちらの場合も、データベース サーバが認識でき
るデータ型で構築します。
ユーザがアクセスする必要のあるコンポーネント値のコンテナとして機能する型が必要
な場合は、名前付き行 (ROW) 型を作成できます。たとえば、ユーザが直接、住所の値
の個々のコンポーネント値、つまり町名、市、州、および郵便番号にアクセスする必要
がある場合は、住所の値をサポートする名前付き行 (ROW) 型を作成できます。 address
型を名前付き行 (ROW) 型として作成すると、ユーザはいつでも、それぞれのフィール
ドに直接アクセスできます。
それに対し、住所の値を扱う不透明 (OPAQUE) 型を作成すると、住所情報はすべて
C-language 言語のデータ構造体に格納されます。不透明 (OPAQUE) 型のコンポーネン
ト値はカプセル化されるので、コンポーネント値を町名、市、州、郵便番号に展開する
関数を定義する必要があります。このように、不透明 (OPAQUE) 型は名前付き行
(ROW) 型よりも定義および使用方法が複雑な型です。
データ型を定義する前に、その型が単に、ユーザが直接アクセスできる値のグループの
コンテナであるかどうかを判断します。この説明に当てはまる場合、名前付き行 (ROW)
型を使用します。
名前付き行 (ROW) 型の名前の選択
SQL 識別子の命名規則に違反しない限り、名前付き行 (ROW) 型にはどんな名前でも付
けられます。 SQL 識別子の命名規則については、「IBM Informix: SQL ガイド: 構文」
の識別子セグメントの説明を参照してください。型名と表名を混同しないように、この
マニュアルの例では、行 (ROW) 型の名前の末尾に文字列 _t を付けることにより、名
前付き行 (ROW) 型であることを示します。
名前付き行 (ROW) 型を作成するには、Resource アクセス権が必要です。データ型はす
べて、同じネーム スペースを共有します。名前付き行 (ROW) 型に割り当てる名前は、
データベースに存在するほかのデータ型と違うものにしてください。 ANSI 準拠データ
第 7 章 Dynamic Server での拡張データ型の作成と使用
141
ベースでは、owner.type の組合せをデータベース内で一意にする必要があります。
ANSI 標準準拠でないデータベースでは、名前をデータベースで一意にする必要があり
ます。
重要: 名前付き行 (ROW) 型に USAGE アクセス権を付与しないと、ユーザはこの型を
使用することができません。名前付き行 (ROW) 型のアクセス権の付与と取消し
については、 205 ページの『第 11 章 次元データベースの実装 (Extended Parallel
Server のみ)』 を参照してください。
名前付き行 (ROW) 型の制限
本節では、名前付き行 (ROW) 型を使用するときに適用される制限について説明しま
す。
データ型に関する制限: ラージ オブジェクトの列を含む型付き表を作成する場合
は、テキスト (TEXT) 型またはバイト (BYTE) 型ではなく、BLOB 型または CLOB 型
を使用することをお勧めします。下位方向の互換性のために、テキスト (TEXT) 型また
はバイト (BYTE) 型のフィールドを含む名前付き行 (ROW) 型を作成したり、これらの
型を使って既存の型なし表を型付き表に再生したりできます。しかし、テキスト
(TEXT) 型やバイト (BYTE) 型のフィールドを含む名前付き行 (ROW) 型を使用して型
付き表を作成することはできますが、このような行 (ROW) 型を列として使用すること
はできません。バイナリ ラージ オブジェクト (BLOB) 型または文字ラージ オブジェ
クト (CLOB) 型のフィールドを含む名前付き行 (ROW) 型は、型付き表または列に割り
当てることができます。
制約に関する制限: CREATE ROW TYPE 文で、名前付き行 (ROW) 型のフィール
ドに対して指定できるのは、NOT NULL 制約のみです。ほかの制約は、CREATE
TABLE 文で定義する必要があります。詳しくは、「IBM Informix: SQL ガイド: 構文」
の CREATE TABLE 文の説明を参照してください。
インデックスに関する制限: CREATE INDEX 文を使用して名前付き行 (ROW) 型
列のインデックスを作成することはできません。しかし、ユーザ定義ルーチンを使用し
て、行 (ROW) 型列の関数インデックスを作成することはできます。
シリアル (SERIAL) 型に関する制限: 表の列型として、シリアル (SERIAL) 型ま
たは 8 バイト シリアル (SERIAL8) 型を含む名前付き行 (ROW) 型は使用できませ
ん。次の文は、データベース サーバが表を作成しようとしたときに、エラーを戻しま
す。
CREATE ROW TYPE row_t (s_col SERIAL)
CREATE TABLE bad_tab (col1 row_t)
しかし、シリアル (SERIAL) 型または 8 バイト シリアル (SERIAL8) 型を含む名前付
き行 (ROW) 型を使用して、型付き表を作成することはできます。
142
IBM Informix: データベース設計および実装 ガイド
表階層構造におけるシリアル (SERIAL) 型および SERIAL8 型の使用と動作について
は、159 ページの『表階層内のシリアル (SERIAL) 型』を参照してください。
名前付き行 (ROW) 型を使用した型付き表の作成
表は、型付き表または型なし表として作成できます。型付き表 は、名前付き行 (ROW)
型が割り当てられた表です。型なし表 は、名前付き行 (ROW) 型が割り当てられていな
い表です。 CREATE ROW TYPE 文は、名前付き行 (ROW) 型を作成しますが、行
(ROW) 型のインスタンスの記憶域は割り当てません。名前付き行 (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 型のインスタンスが格納されます。厳密に言えば、型付き表の各行
に、表に割り当てられた名前付き行 (ROW) 型のインスタンスが格納されます。前の例
で、person_t 型のフィールドは、person 表の列を定義します。
重要: 名前付き行 (ROW) 型を作成する順序は重要です。名前付き行 (ROW) 型を使用
して型付き表を定義する前に、その型が存在している必要があります。
型付き表へのデータ挿入は、型なし表へのデータ挿入と同様に行います。型付き表にデ
ータを挿入すると、行 (ROW) 型のインスタンスが作成され、表に挿入されます。次の
例で、person 表に行を挿入する方法を示します。
INSERT INTO person
VALUES (’Brown, James’, ’13 First St.’, ’San Carlos’, ’CA’, 94070,
’01/04/1940’)
INSERT 文により、person_t 型のインスタンスが作成され、表に挿入されます。名前
付き行 (ROW) 型に定義した列に対して挿入、更新、および削除を行う方法について詳
しくは、「IBM Informix: SQL ガイド: チュートリアル」を参照してください。
1 つの名前付き行 (ROW) 型を使用して、複数の型付き表を作成できます。この場合、
表の名前は一意ですが、すべての表が同じ型を共有します。
重要: 一時表である型付き表を作成することはできません。
第 7 章 Dynamic Server での拡張データ型の作成と使用
143
データ モデルを実装するときに型付き表を使用する利点については、149 ページの『型
継承』を参照してください。
表の型の変更
型なし表に比べ、型付き表には、継承階層構造で使用できるという利点があります。一
般に、継承によって表は別の表の表現および動作を取得することができます。詳しく
は、149 ページの『継承について』を参照してください。
ALTER TABLE 文の DROP 節および ADD 節により、型付き表と型なし表の変換を行
うことができます。 ADD または DROP のどちらの操作を行っても、表に格納されて
いるデータへの影響はありません。
型なし表から型付き表への変換: 既存の型なし表を型付き表に変換するには、
ALTER TABLE 文を使用します。たとえば、次の型なし表について考えます。
CREATE TABLE manager
(
name
VARCHAR(30),
department VARCHAR(20),
salary
INTEGER
);
型なし表を型付き表に変換するには、名前付き行 (ROW) 型のフィールド名とフィール
ド型の両方を、既存の表の列名と列型に一致させる必要があります。たとえば、
manager 表を型付き表にするには、まず、表の列定義に一致する名前付き行 (ROW)
型を作成する必要があります。次の文は、manager 表の列に一致するフィールド名と
フィールド型を含む manager_t 型を作成します。
CREATE ROW TYPE manager_t
(
name
VARCHAR(30),
department VARCHAR(20),
salary
INTEGER
);
既存の型なし表に割り当てる名前付き行 (ROW) 型を作成した後、ALTER TABLE 文を
使用して、型を表に割り当てます。次の文は、manager 表を変更し、型 manager_t
の型付き表にします。
ALTER TABLE manager ADD TYPE manager_t
新しい manager 表は、古い表と同じ列とデータ型を含みながら、型付き表の利点も提
供します。
型付き表から型なし表への変換: 型付き表を型なし表へ変換する場合も、ALTER
TABLE 文を使用します。
ALTER TABLE manager DROP TYPE
144
IBM Informix: データベース設計および実装 ガイド
ヒント: 型付き表へ列を追加するには、型の削除、列の追加、表への型の追加を行う 3
つの ALTER TABLE 文が必要です。
名前付き行 (ROW) 型を使用した列の作成
型付き表と型なし表のどちらにも、名前付き行 (ROW) 型に定義した列を含めることが
できます。名前付き行 (ROW) 型に定義した列は、型付き表、または型なし表のどちら
の列でも同じように動作します。次の例で、最初の文は名前付き行 (ROW) 型
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);
強い型指定は、名前付き行 (ROW) 型の挿入または更新には適用されません。行の値を
確実に名前付き行 (ROW) 型の値にするには、前の例で示したように、名前付き行
(ROW) 型に明示的にキャストし、名前付き行 (ROW) 型の値を生成する必要がありま
す。 INSERT 文は、3 つの値を挿入します。そのうち 1 つは、4 つの値を含む行
(ROW) 型の値です。厳密に言えば、この操作は列 name と列 salary に分割できない
値を挿入し、address_t 型のインスタンスを作成して列 address に挿入します。
行 (ROW) 型に定義した列に対して挿入、更新、および削除を行う方法について詳しく
は、「IBM Informix: SQL ガイド: チュートリアル」を参照してください。
第 7 章 Dynamic Server での拡張データ型の作成と使用
145
別の行 (ROW) 型の中での名前付き行 (ROW) 型の使用
名前付き行 (ROW) 型は、別の行 (ROW) 型のフィールドのデータ型として使用できま
す。入れ子行 (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 に含まれるフィールドのデータ型として使用することは
できません。
名前付き行 (ROW) 型の削除
名前付き行 (ROW) 型を削除するには、DROP ROW TYPE 文を使用します。型を削除
できるのは、依存性がない場合だけです。次の条件に 1 つでも当てはまる場合、その名
前付き行 (ROW) 型は削除できません。
v 現在、表に割り当てられている
v 現在、型が表の列に割り当てられている。
v 現在、型が別の行 (ROW) 型のフィールドに割り当てられている。
次の例で、person_t 型を削除する方法を示します。
DROP ROW TYPE person_t restrict;
名前付き行 (ROW) 型を型階層から削除する方法については、153 ページの『型階層か
らの名前付き行 (ROW) 型の削除』を参照してください。
146
IBM Informix: データベース設計および実装 ガイド
名前なし行 (ROW) 型
名前なし行 (ROW) 型 は、ROW コンストラクタで作成する型付きフィールドのグルー
プです。名前付き行 (ROW) 型と名前なし行 (ROW) 型の重要な違いは、名前なし行
(ROW) 型は表に割り当てることができない、という点です。名前なし行 (ROW) 型は、
列またはフィールドの型定義にだけ使用します。また、名前なし行 (ROW) 型は構造体
だけで識別されます。これに対し、名前付き行 (ROW) 型は名前で識別されます。行
(ROW) 型の構造体は、フィールドの数とデータ型で構成されます。
次の文は、2 つの名前なし行 (ROW) 型を student 表の列に割り当てます。
CREATE TABLE student
(
s_name ROW(f_name VARCHAR(20), m_init CHAR(1),
l_name VARCHAR(20) NOT NULL),
s_address ROW(street VARCHAR(20), city VARCHAR(20),
state CHAR(2), zip VARCHAR(9))
);
student 表の列 s_name と列 s_address には、それぞれ複数のフィールドが含まれ
ています。名前なし行 (ROW) 型のフィールドは、それぞれ異なるデータ型にできま
す。 student 表の列は 2 つのみですが、名前なし行 (ROW) 型によって 7 つのフィ
ールド、すなわち f_name、m_init、l_name、street、city、state、および zip が定義
されます。
次の例で、INSERT 文を使用して student 表にデータを挿入する方法を示します。
INSERT INTO student
VALUES (ROW(’Jim’, ’K’, ’Johnson’), ROW(’10 Grove St.’,
’Eldorado’, ’CA’, 94108))
行 (ROW) 型に定義した列を修正する方法について詳しくは、「IBM Informix: SQL ガ
イド: チュートリアル」を参照してください。
2 つの名前なし行 (ROW) 型が同じ数のフィールドを含み、対応するフィールドが同じ
型である場合、データベース サーバはこの 2 つを区別しません。名前なし行 (ROW)
型の型チェックでは、フィールド名は無関係です。たとえば、データベース サーバは次
の名前なし行 (ROW) 型を区別しません。
ROW(a INTEGER, b CHAR(4));
ROW(x INTEGER, y CHAR(4));
名前なし行 (ROW) 型の構文については、「IBM Informix: SQL ガイド: 構文」を参照
してください。行 (ROW) 型の値をキャストする方法については、 165 ページの『第 9
章 Dynamic Server でのユーザ定義キャストの作成と使用』を参照してください。
次のデータ型は、名前なし行 (ROW) 型のフィールド型には使用できません。
v シリアル (SERIAL) 型
v 8 バイト シリアル (SERIAL8) 型
第 7 章 Dynamic Server での拡張データ型の作成と使用
147
v バイト (BYTE) 型
v テキスト (TEXT) 型
これらの型が名前なし行 (ROW) 型のフィールド定義で指定されると、データベース サ
ーバはエラーを戻します。
148
IBM Informix: データベース設計および実装 ガイド
第 8 章 Dynamic Server による型継承と表継承
本章の概要
この章では、型継承と表継承について説明し、型階層と表階層を作成して各階層内の型
と表を修正する方法について取り上げます。
継承について
継承 は、ある型や表が、別の型や表のプロパティを取得できるようにする処理です。プ
ロパティを継承する型を副型、表を副表 と呼びます。プロパティが継承される型を上位
型、表を上位表 と呼びます。継承では差分修正を実行できるため、型や表は、プロパテ
ィの全般的なセットを継承して、それぞれに固有のプロパティを追加できます。継承を
使用しての修正は、継承された上位型や上位表が修正によって変更されない程度に行い
ます。
Dynamic Server は、名前付き行 (ROW) 型と型付き表に対してのみ継承をサポートして
います。 Dynamic Server では、単一継承のみがサポートされています。単一継承 で
は、それぞれの副型や副表に上位型や上位表が 1 つずつしかありません。
型継承
型継承は名前付き行 (ROW) 型だけに適用されます。継承を使用して、名前付き行
(ROW) 型を型階層 にグループ化できます。型階層では、それぞれの副型が、その副型
の上位に定義されている上位型の表現 (データ フィールド) と動作 (UDR、集合、およ
び演算子) を継承します。型階層には、次の利点があります。
v データ モデルのモジュール実装が容易になります。
v スキーマ コンポーネントを一貫して再使用できるようになります。
v 誤ってデータ フィールドを除外することがなくなります。
v 別のデータ型に定義されている UDR の継承が可能になります。
型階層の定義
150 ページの図 28 に、3 つの名前付き行 (ROW) 型を持つ単純な型階層の例を示しま
す。
© Copyright IBM Corp. 1996, 2003
149
図 28. 型階層の例
この型階層の最上位にある上位型には、その下にある副型すべてが継承するフィールド
のグループが含まれています。上位型が存在しないと、その副型を作成できません。次
の例では、150 ページの図 28 の型階層の上位型 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 を追加します。
CREATE ROW TYPE employee_t
(
salary
INTEGER,
manager VARCHAR(30)
)
UNDER person_t;
重要: 上位型のプロパティを継承する副型を作成するには、その上位型に対する
UNDER アクセス権を持っている必要があります。 UNDER アクセス権について
は、 205 ページの『第 11 章 次元データベースの実装 (Extended Parallel Server
のみ)』を参照してください。
150 ページの図 28 の型階層では、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 にはありません。
150
IBM Informix: データベース設計および実装 ガイド
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 のインスタンスには適用されません。
前述の型階層は、各副型が単一の上位型から継承する単一継承の例でした。図 29 に、
単一の上位型に対して複数の副型を定義する方法を示します。単一継承では、1 つしか
ない上位型から各副型が継承する必要がありますが、定義する型階層の深さと幅にはほ
とんど制限がありません。
図 29. ツリー構造体の型階層の例
すべての階層において、最上位にある型を最上位型と呼びます。 図 29 では、person_t
がこの階層の最上位型です。最上位型を除く階層内のすべての型が、同時に上位型にも
副型にもなる可能性があります。たとえば、customer_t は person_t の副型であり、
us_customer_t の上位型でもあります。階層の下位にある副型には最上位型のプロパ
ティが含まれますが、最上位型のプロパティを直接継承するわけではありません。たと
えば、us_customer_t の上位型は customer_t の 1 つだけですが、customer_t 自体
第 8 章 Dynamic Server による型継承と表継承
151
が person_t の副型であるため、customer_t が person_t から継承するフィールドと
ルーチンは、us_customer_t にも継承されます。
型階層内の型に対するルーチンのオーバーロード
ルーチン オーバーロード とは、1 つの名前を複数のルーチンに割り当てて、それらの
ルーチンが操作できる異なる型の引数を指定する機能のことです。型階層では、副型は
その上位型に定義されているルーチンを自動的に継承します。ただし、新しいルーチン
を副型に定義して、継承されたルーチンを同じ名前でオーバーライドすることができま
す。たとえば、型 person_t のインスタンスの姓と誕生日を戻す getinfo() ルーチン
を、型 person_t に対して作成するとします。この場合、employee_t のインスタンス
の姓と給与を戻す別の getinfo() ルーチンを型 employee_t に対して登録できます。
図 30 に示すように、ルーチンをオーバーロードすることにより、型階層内の各タイプ
に対してルーチンをカスタマイズすることができます。
図 30. 型階層内のルーチン オーバーロードの例
ルーチンをオーバーロードすると、型階層内のさまざまな型に対して同じ名前でも引数
が異なるルーチンが複数定義されます。その場合、指定する引数によって、実行される
ルーチンが決定します。たとえば、型 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()
152
IBM Informix: データベース設計および実装 ガイド
ルーチンが登録されていないときに型 employee_t の引数を指定して p_info() を起動
すると、このルーチンは、型 employee_t のインスタンスの名前と誕生日のフィールド
(person_t から継承された) を戻します。この動作が可能であるのは、employee_t が
上位型 person_t から関数を継承するためです。
通常、データベース サーバは、ルーチンの評価を行う場合、ルーチンの起動時に指定さ
れたルーチン名と引数に一致するシグネチャを検索します。そのようなルーチンが見つ
かると、データベース サーバはそのルーチンを使用します。正確に一致するルーチンが
見つからない場合、データベース サーバは、同じ名前を持ち、ルーチンが起動されたと
きに指定された引数型の上位型である引数型を持つルーチンを検索します。 153 ページ
の図 31 で、副型 sales_rep_t の引数を使用して get() ルーチンが呼び出されたとき
に、データベース サーバが使用できるルーチンを検索するプロセスを示します。
sales_rep_t 型には get() ルーチンが定義されていませんが、データベース サーバは
階層内の上位型に定義されている get() ルーチンを見つけるまで検索します。この場
合、sales_rep_t にもその上位型 employee_t にも get() ルーチンは定義されていま
せん。しかし person_t にルーチンが定義されているため、このルーチンが起動されて
sales_rep_t のインスタンス上で動作します。
図 31. データベース サーバによる型階層内のルーチンの検索の例
データベース サーバが使用できるルーチンを検索するプロセスをルーチン分析 と呼び
ます。ルーチン分析について詳しくは、「IBM Informix: ユーザ定義ルーチンおよびデー
タ タイプ 開発者ガイド」を参照してください。
型階層からの名前付き行 (ROW) 型の削除
型階層から名前付き行 (ROW) 型を削除するには、DROP ROW TYPE 文を使用しま
す。ただし、依存性のない型しか削除できません。次の条件のどちらかにあてはまる場
合、名前付き行 (ROW) 型は削除できません。
v 現在、表に割り当てられている
v 別の型の上位型になっている
次の例では、型 sales_rep_t を削除する方法を示します。
DROP ROW TYPE games_t RESTRICT;
第 8 章 Dynamic Server による型継承と表継承
153
上位型を削除するには、まず、その上位型からプロパティを継承する副型をそれぞれ削
除する必要があります。作成したときと逆の順序で、型階層内の型を削除します。たと
えば、図 31 の型 person_t を削除するには、まず、次の順序で person_t の副型を削除
する必要があります。
DROP ROW TYPE sale_rep_t RESTRICT;
DROP ROW TYPE employee_t RESTRICT;
DROP ROW TYPE person_t RESTRICT;
重要: 型を削除するには、データベース管理者、またはその型の所有者である必要があ
ります。
表継承
名前付き行 (ROW) 型に定義されている表しか、表継承をサポートしていません。表継
承とは、ある表が表階層でその表の上位にある上位表から動作 (制約、格納オプショ
ン、トリガ) を継承できるようにするプロパティです。表階層とは、表の間に定義でき
る関係のことで、それにより副表が上位表の動作を継承します。表継承には、次の利点
があります。
v データ モデルのモジュール実装が容易になります。
v スキーマ コンポーネントを一貫して再使用できるようになります。
v 表階層内の表のいくつかまたはすべてを範囲に持つ問合せを作成できるようになりま
す。
表階層では、副表は、次のプロパティをその上位表から自動的に継承します。
v すべての制約定義 (主キー制約、一意性制約、および参照制約)
v 格納オプション
v すべてのトリガ
v インデックス
v アクセス方法
型階層と表階層との関係
表階層内の表はすべて、対応する型階層内の名前付き行 (ROW) 型に割り当てられてい
る必要があります。図 32 に、型階層と表階層の関係の例を示します。
154
IBM Informix: データベース設計および実装 ガイド
図 32. 型階層と表階層の関係の例
名前付き行 (ROW) 型が、表階層内の表と必ずしも 1 対 1 の関係を持たない型階層を
定義することもできます。図 33 に、一部の名前付き行 (ROW) 型だけを表に割り当て
る型階層の作成方法を示します。
図 33. 一部の名前付き行 (ROW) 型だけを表に割り当てる継承階層構造の例
表階層の定義
表を定義するために使用する型は、表を作成する前に存在している必要があります。同
様に、型階層を定義してからでなければ、対応する表階層を定義することはできませ
ん。表階層内の特定の副表と上位表との間の関係を確立するには、キーワード UNDER
を使用します。次の CREATE TABLE 文は、155 ページの図 32 の単純な表階層を定義
します。この節の例では、型 person_t、employee_t、および sales_rep_t が既に存
在することを前提にしています。
第 8 章 Dynamic Server による型継承と表継承
155
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 型への継承と同様に行われる必要があります。
副表は、上位表に追加された継承可能なプロパティすべてを自動的に継承します。した
がって、上位表のプロパティは常に追加および変更が可能で、副表はそれらの変更を自
動的に継承します。詳しくは、158 ページの『表階層内の表の動作の修正』を参照して
ください。
重要: 上位表のプロパティを継承する副表を作成するには、その上位表に対する
UNDER アクセス権を持っている必要があります。詳しくは、101 ページの『型
付き表に対する 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;
156
IBM Informix: データベース設計および実装 ガイド
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
また、表階層には、ある 1 つの副表に定義する動作で、上位表から継承した異なる動作
を無効にできるような副表が含まれることがあります。次のような表階層を考えてみま
しょう。この表階層は、employee 表で新しい格納オプションが追加されている以外
は、前の例で使用したものと同じです。
CREATE TABLE person OF TYPE person_t
(PRIMARY KEY (name))
FRAGMENT BY EXPRESSION
name < ’n’ IN person1,
name >= ’n’ IN person2;
CREATE TABLE employee OF TYPE employee_t
(CHECK(salary > 34000))
FRAGMENT BY EXPRESSION
name < ’n’ IN employ1,
name >= ’n’ IN employ2
UNDER person;
CREATE TABLE sales_rep OF TYPE sales_rep_t
LOCK MODE ROW
UNDER employee;
ここでも、employee 表と sales_rep 表が person 表の主キー名を継承します。ただ
し、employee 表のフラグメンテーション ストラテジが person テーブルのフラグメ
ンテーション ストラテジをオーバーライドします。したがって、employee 表と
sales_rep 表は共に、DB 領域 employ1 と employ2 にデータを格納し、person 表
は DB 領域 person1 と person2 にデータを格納します。
第 8 章 Dynamic Server による型継承と表継承
157
表階層内の表の動作の修正
いったん表階層を定義すると、既存の表の構造 (列) は修正できません。ただし、階層
内の表の動作を修正することはできます。 158 ページの表 4 に、表階層内で修正でき
る表の動作と、その修正に使用する構文を示します。
表 4. 表階層内で修正できる表の動作
表の動作
構文
注意事項
制約定義
ALTER TABLE
制約を追加または削除するには、ADD
CONSTRAINT 節または DROP CONSTRAINT 節を
使用します。詳しくは、158 ページの『表階層内の
表に関する制約』を参照してください。
インデックス
CREATE INDEX、ALTER
INDEX
詳しくは、158 ページの『表階層内の表へのインデ
ックスの追加』および「IBM Informix: SQL ガイド:
構文」の CREATE INDEX 文および ALTER
INDEX 文の説明を参照してください。
トリガ
CREATE/DROP TRIGGER
継承されたトリガは削除できません。ただし、上位
表からトリガを削除したり、副表にトリガを追加し
て継承されたトリガを無効にしたりすることはでき
ます。上位表や副表のトリガを修正する方法につい
ては、159 ページの『表階層内の表のトリガ』を参
照してください。トリガを作成する方法について
は、「IBM Informix: SQL ガイド: チュートリア
ル」を参照してください。
階層内の上位表を修正すると、既存の副表はすべて新しい表の動作を自動的に継承しま
す。
重要: ALTER TABLE 文を使用して表階層内の表を修正する場合に使用できるのは、
ADD CONSTRAINT 節、DROP CONSTRAINT 節、MODIFY NEXT SIZE 節、
および LOCK MODE 節のみです。
表階層内の表に関する制約
制約の変更または削除は、その制約が定義されている表でしか実行することができませ
ん。継承された制約については、副表から削除も変更もできません。ただし、副表で新
しい制約を追加することはできます。また、ある表に追加制約を定義すると、その制約
を定義した表から継承を行う副表によって、その追加制約が継承されます。制約は加算
的であるため、継承された制約のすべて、および現在の (追加された) 制約のすべてが
適用されます。
表階層内の表へのインデックスの追加
階層内の上位表にインデックスを定義すると、その上位表の下位に定義するすべての副
表もまた、そのインデックスを継承します。表 tab_a、tab_b、および tab_c を含む表
158
IBM Informix: データベース設計および実装 ガイド
階層において、tab_a が tab_b の上位表で、tab_b が tab_c の上位表である場合を想
定します。tab_b の列にインデックスを作成すると、そのインデックスは tab_b と
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;
第 8 章 Dynamic Server による型継承と表継承
159
parent_tab 表には、シリアル (SERIAL) 型は含まれません。 child1_tab はこの階層
内でシリアル (SERIAL) 型カウンタを初めて使用します。 child2_tab はシリアル
(SERIAL) 型列を child1_tab から継承し、8 バイト シリアル (SERIAL8) 型列を追加
します。 child3_tab はシリアル (SERIAL) 型列と 8 バイト シリアル (SERIAL8) 型
列の両方を継承します。
階層内のいずれかの表の s_col 列または s8_col 列に 値 0 が挿入されると、単調に
増加する値が挿入されます。この場合、どの表に挿入されたのかは関係ありません。
CREATE ROW TYPE 文で、シリアル (SERIAL) 型または 8 バイト シリアル
(SERIAL8) 型の開始カウンタ値を設定することはできません。表階層内のシリアル
(SERIAL) 型列または 8 バイト シリアル (SERIAL8) 型列の開始値を設定するには、
ALTER TABLE 文を使用します。次の文は、表階層内の任意の場所に挿入される次のシ
リアル (SERIAL) 型値と 8 バイト シリアル (SERIAL8) 型値を修正して表を変更する
方法を示しています。
ALTER TABLE child3_tab
MODIFY (s_col SERIAL(100), s8_col SERIAL8 (200))
前述の動作を除いて、型なし表のシリアル (SERIAL) 型列と 8 バイト シリアル
(SERIAL8) 型列に適用される規則はすべて、その表階層内のシリアル (SERIAL) 型列と
8 バイト シリアル (SERIAL8) 型列にも適用されます。詳しくは、 39 ページの『第 3
章 データ型の選択』および「IBM Informix: SQL ガイド: 参照」を参照してください。
表階層への表の追加
表階層を定義した後で、ALTER TABLE 文を使用してその階層内の表の列を追加、削
除、または修正することはできません。ただし、既存の継承関係が侵害されない場合に
限り、新しい副型と副表を既存の階層に追加できます。 図 34 に、型、およびその型に
対応する表を既存の階層に追加する方法の 1 例を示します。破線は、追加された副型と
副表を示します。
160
IBM Informix: データベース設計および実装 ガイド
図 34. 既存の継承階層に副型と副表を追加する方法の例
次の文は、図 34 の継承階層に型と表を追加する方法を示します。
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;
また、既存の上位型およびそれに並列する上位表から、分岐する副型と副表を追加する
こともできます。 図 35 に customer_t 型と customer 表を既存の階層に追加する方
法を示します。この例では、customer 表と employee 表の両方が person 表からプ
ロパティを継承します。
図 35. 既存の上位型と上位表の下位に型と表を追加する方法の例
次の文は、customer_t 型と customer 表をそれぞれ person_t 型と person 表の下
位に作成します。
第 8 章 Dynamic Server による型継承と表継承
161
CREATE ROW TYPE customer_t (cust_num INTEGER) UNDER person_t;
CREATE TABLE customer OF TYPE customer_t UNDER person;
表階層内の表の削除
ある表と、その表に対応する名前付き行 (ROW) 型に依存性がない場合、つまり上位表
および上位型となっていない場合は、それらの表と型を削除することができます。表を
先に削除してからでないと型を削除できません。表の削除に関する一般情報について
は、「IBM Informix: SQL ガイド: 構文」の DROP TABLE 文に関する説明を参照して
ください。名前付き行 (ROW) 型の削除方法については、146 ページの『名前付き行
(ROW) 型の削除』を参照してください。
表階層内の表の構造の変更
ALTER TABLE 文を使用して表階層内の表の列を追加、削除、または修正することはで
きません。 ALTER TABLE 文を使用して制約を追加、削除、または修正することは で
きます。
表階層内の表の列を追加、削除、または修正する (あるいはその他の方法で表の構造を
変更する) 処理には、時間がかかる場合があります。
表階層内の表の構造を変更するには:
1. 修正するすべての副表と上位表からデータをダウンロードします。
2. 副表と副型を削除します。
3. アンロードされたデータ ファイルを修正します。
4. 上位表を修正します。
5. 副型と副表を再作成します。
6. データをアップロードします。
表階層内の表の問合せ
表階層を使用すると、上位表とその副表を対象とする SELECT 文、UPDATE 文、また
は DELETE 文を 1 つの SQL コマンドで構築できます。たとえば、表階層内の任意の
上位表に対する問合せは、その上位表の列すべてのデータ、およびその上位表から副表
が継承する列すべてのデータを戻します。問合せ結果を表階層内の表 1 つに制限するに
は、ONLY キーワードを問合せに含める必要があります。表階層内の表のデータを問い
合わせて修正する方法の詳細については、「IBM Informix: SQL ガイド: チュートリア
ル」を参照してください。
表階層内の表のビューの作成
ビューは、表階層内のどの表に基づいても作成できます。たとえば、次の文は 155 ペー
ジの図 32 で示す表階層の最上位表である person 表のビューを作成します。
CREATE VIEW name_view AS SELECT name FROM person
162
IBM Informix: データベース設計および実装 ガイド
person 表が上位表であるため、ビュー name_view には person 表、employee
表、および sales_rep 表の name 列からのデータが表示されます。 person 表から
のデータのみを表示するビューを作成するには、次の例に示すように ONLY キーワー
ドを使用します。
CREATE VIEW name_view AS SELECT name FROM ONLY(person)
重要: 上位表に定義されているビューに対して挿入や更新を実行することはできませ
ん。これはデータベース サーバが表階層内で新しい行を挿入する位置を判断でき
ないためです。
型付きビューの作成方法については、115 ページの『型付きビュー (IDS のみ)』を参照
してください。
第 8 章 Dynamic Server による型継承と表継承
163
164
IBM Informix: データベース設計および実装 ガイド
第 9 章 Dynamic Server でのユーザ定義キャストの作成と使
用
本章の概要
この章では、ユーザ定義キャストについて説明し、実行時キャストを使用して拡張デー
タ型のデータ変換を実行する方法を説明します。
キャストとは
キャストは、あるデータ型の値を別のデータ型に変換するメカニズムです。キャストに
より、異なるデータ型の値を比較したり、あるデータ型の値を別のデータ型の値と置き
換えたりすることができます。 Dynamic Server は次の種類の式によるキャストをサポ
ートしています。
v 列式
v 定数式
v 関数式
v SPL 変数
v ホスト変数 (ESQL)
v 文の局所変数 (SLV) 式
あるデータ型の値を別のデータ型に変換するには、データベースまたはデータベース サ
ーバにキャストが必要です。Dynamic Server では、次の種類のキャストをサポートしま
す。
v 組込みキャスト。組込みキャスト は、データベース サーバに組み込まれているキャ
ストです。組込みキャストは、異なる組込みデータ型間の変換を自動的に実行しま
す。
v ユーザ定義キャスト。ユーザ定義キャストでは、多くの場合、あるデータ型から別の
データ型への変換を処理するキャスト関数 が必要になります。ユーザ定義キャスト
を登録し、使用するには、CREATE CAST 文を使用する必要があります。
CREATE CAST 文でキャストを作成するときに、EXPLICIT キーワードを含めると、ユ
ーザ定義キャストは明示的 になります。デフォルトは、明示的です。明示的キャスト
は、自動的には起動しません。明示的キャストを起動するには、キーワード
CAST...AS、または、キャスト演算子である二重コロン (::) を使用する必要がありま
す。
© Copyright IBM Corp. 1996, 2003
165
CREATE CAST 文でキャストを作成するときに、IMPLICIT キーワードを含めると、ユ
ーザ定義キャストは暗黙的 になります。データベース サーバは、実行時に、自動的に
暗黙的キャストを起動してデータ変換を実行します。
キャストはすべて syscasts システム カタログ表に組み込まれます。 syscasts につ
いて詳しくは、「IBM Informix: SQL ガイド: 参照」を参照してください。
ユーザ定義キャストの作成
2 つのデータ型間の変換を実行する組込みキャストがデータベース サーバで提供されな
い場合、データ型変換を処理するユーザ定義キャストを作成できます。ユーザ定義キャ
ストは、一般に、次の拡張データ型のデータ型変換を提供するのに使用します。
v 不透明 (OPAQUE) 型。不透明 (OPAQUE) 型の開発者は、不透明 (OPAQUE) 型の内
部表現および外部表現の変換を処理するキャストを定義する必要があります。不透明
(OPAQUE) 型のキャストを作成し、登録する方法については、「IBM Informix: ユー
ザ定義ルーチンおよびデータ タイプ 開発者ガイド」を参照してください。
v ディスティンクト (DISTINCT) 型。ディスティンクト (DISTINCT) 型とソース型を
直接比較することはできません。しかし、ディスティンクト型からソース型、および
ソース型からディスティンクト型への明示的キャストは Dynamic Server によって自
動的に登録されます。ディスティンクト型は、ソース型に定義されたキャストを継承
しません。また、ディスティンクト型に定義するユーザ定義キャストは、ソース型に
は使用できません。ディスティンクト型のキャストを作成し、使用する方法の詳細と
例については、177 ページの『ユーザ定義キャストのキャスト関数の作成』 を参照
してください。
v 名前付き行 (ROW) 型。名前付き行 (ROW) 型は、ほとんどの場合、キャストを作成
することなく別の行 (ROW) 型の値に明示的にキャストすることができます。ただし
一部のデータ型では、名前付き行 (ROW) 型との間で値を変換するためには、まず変
換を処理するキャストを作成する必要があります。
ユーザ定義キャストを作成し、使用する方法の例については、 178 ページの『ディステ
ィンクト型間でのキャストの例』を参照してください。 CREATE CAST 文の構文につ
いては、「IBM Informix: SQL ガイド: 構文」を参照してください。
キャストの起動
組込みキャスト、およびユーザ定義の暗黙的キャストの場合、データベース サーバは自
動的に (暗黙的に) データ変換を処理するキャストを起動します。たとえば、式を明示
的にキャストせずに、整数 (INT) 型の値を小桁整数 (SMALLINT) 型、実数 (FLOAT)
型、または文字 (CHAR) 型の値と比較することができます。これは、データベース サ
ーバに用意されているシステム定義キャストが、これらの組込みデータ型間での変換を
ユーザに見えることなく処理するためです。
166
IBM Informix: データベース設計および実装 ガイド
2 つのデータ型間の変換を処理する明示的なユーザ定義キャストを定義する場合、キー
ワード CAST...AS、またはキャスト演算子である二重コロン (::) で、キャストを明示的
に起動する必要があります。次の部分的な例で、明示的キャストを起動する 2 つの方法
を示します。
... WHERE new_col = CAST(old_col AS newtype)
... WHERE new_col = old_col::newtype
ユーザ定義キャストに関する制限
2 つの組込みデータ型間のユーザ定義キャストは作成できません。次のデータ型を 1 つ
でも含むユーザ定義キャストも作成できません。
v コレクション (COLLECTION) 型: リスト (LIST) 型、マルチセット (MULTISET)
型、またはセット (SET) 型
v 名前なし行 (ROW) 型
v スマート ラージ オブジェクト型: CLOB 型または BLOB 型
v シンプル ラージ オブジェクト: テキスト (TEXT) 型またはバイト (BYTE) 型
一般的に、2 つのデータ型間のキャストでは、それぞれのデータ型のコンポーネント値
の個数は一致している必要があります。たとえば、行 (ROW) 型のフィールドと不透明
(OPAQUE) 型のフィールドが対応していれば、その行 (ROW) 型と不透明 (OPAQUE)
型の間のキャストは可能です。格納構造が同じ 2 つのデータ型の間で変換を実行する場
合は、キャスト関数なしで CREATE CAST 文を使用できます。そうでない場合、キャ
スト関数を作成し、CREATE CAST 文で登録する必要があります。キャスト関数を使用
してユーザ定義キャストを作成する方法の例については、 177 ページの『ユーザ定義キ
ャストのキャスト関数の作成』 を参照してください。
行 (ROW) 型のキャスト
名前付きと名前なしの 2 つの行 (ROW) 型の値は、両方の行 (ROW) 型のフィールドの
個数が同じで、かつ次の条件のいずれか 1 つに当てはまる場合にのみ、比較または置換
を行うことができます。
v 2 つの行 (ROW) 型の対応するフィールドがすべて同じデータ型である。
フィールドの個数が同じで、対応するフィールドのデータ型も同じ場合、その 2 つ
の行 (ROW) 型は 構造的に等価だと見なされます。
v 2 つの名前付き行 (ROW) 型を比較するときに変換を実行する、ユーザ定義キャスト
が存在する。
v データ型が異なる対応フィールドの値に対して必要な変換を実行する、システム定義
のキャスト、またはユーザ定義キャストが存在する。
対応するフィールドが同じデータ型でない場合、システム定義キャストまたはユーザ
定義キャストを使用して、フィールドのデータ変換を処理できます。
第 9 章 Dynamic Server でのユーザ定義キャストの作成と使用
167
各フィールドのデータ変換を処理する組込みキャストがあれば、ある行 (ROW) 型の値
を、ほかの行 (ROW) 型に明示的にキャストできます。ただし、両方の行 (ROW) 型が
どちらも名前なし行 (ROW) 型の場合は除きます。この場合、明示的キャストは必要あ
りません。
フィールド変換を処理する組込みキャストがない場合、フィールド変換を処理するユー
ザ定義キャストを作成できます。キャストは、暗黙的なものにも、明示的なものにもで
きます。
一般的に、行 (ROW) 型を別の行 (ROW) 型にキャストする場合、明示的キャストまた
は暗黙的キャストで、それぞれのフィールド変換を処理します。対応するフィールドの
変換に明示的キャストが必要な場合、キャストされたフィールドの値は、対応するフィ
ールドの値に正確に一致する必要があります。明示的にキャストされた値に、データベ
ース サーバが追加の暗黙的キャストを適用することはありません。
名前付き行 (ROW) 型と名前なし行 (ROW) 型の間のキャスト
名前付き行 (ROW) 型の値を名前なし行 (ROW) 型の値と比較するには、明示的キャス
トを使用します。次の名前付き行 (ROW) 型と表を作成するとします。
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) 型に変換する明示的キャストを使用する必要があ
ります。次の問合せで、名前なし行 (ROW) 型の ret_info 列は、名前付き行 (ROW)
型の info_t に明示的にキャストされます。
SELECT cust_info
FROM customer, retailer
WHERE cust_info = ret_info::info_t
一般的に、名前付き行 (ROW) 型と名前なし行 (ROW) 型の間で変換を実行するには、
一方の行 (ROW) 型をもう一方の行 (ROW) 型に明示的にキャストする必要がありま
す。明示的キャストは、どちらの方向にも実行できます。名前付き行 (ROW) 型を名前
なし行 (ROW) 型にキャストすることも、名前なし行 (ROW) 型を名前付き行 (ROW)
型にキャストすることもできます。次の文は、前の例と同じ結果を戻します。ただし、
この例では、名前付き行 (ROW) 型が名前なし行 (ROW) 型に明示的にキャストされま
す。
168
IBM Informix: データベース設計および実装 ガイド
SELECT cust_info
FROM customer, retailer
WHERE cust_info::ROW(a CHAR(1), b CHAR(20)) = ret_info
名前なし行 (ROW) 型どうしのキャスト
構造的に等価な 2 つの名前なし行 (ROW) 型は、明示的キャストを行わなくても比較で
きます。両方の行 (ROW) 型のフィールドの個数が同じで、かつデータ型が異なる対応
フィールドの値を変換するキャストが存在する場合も、名前なし行 (ROW) 型と別の名
前なし行 (ROW) 型を比較できます。つまり、フィールド変換を処理するキャストが、
すべてシステム定義キャストまたは暗黙的キャストであれば、ある名前なし行 (ROW)
型から別の名前なし行 (ROW) 型へのキャストは暗黙的です。そうでない場合、名前な
し行 (ROW) 型を別の行 (ROW) 型と比較するには、明示的にキャストする必要があり
ます。
次の prices 表を作成するとします。
CREATE TABLE prices
(col1 ROW(a SMALLINT, b FLOAT)
col2 ROW(x INT, y REAL) )
対応するフィールド間の変換を実行する組込みキャストがあれば、2 つの名前なし行
(ROW) 型の値は明示的キャストなしで比較できます。そのため、次の問合せでは col1
と col2 の値を比較する明示的キャストは必要ありません。
SELECT * FROM prices WHERE col1 = col2
この例では、データ ベースサーバは暗黙的に組込みキャストを起動し、小桁整数
(SMALLINT) 型のフィールド値を整数 (INT) 型に、小桁実数 (REAL) 型のフィールド
を実数 (FLOAT) 型に変換します。
2 つの行 (ROW) 型の対応するフィールドが互いに暗黙的にキャストできない場合、こ
の 2 つの型の間で変換を処理するユーザ定義キャストがあれば、明示的にキャストでき
ます。
名前付き行 (ROW) 型の間でのキャスト
名前付き行 (ROW) 型は、強い型指定です。つまり、2 つの名前付き行 (ROW) 型が構
造的に等価であっても、データベース サーバはその 2 つの行 (ROW) 型を別々の型と
して認識します。そのため、2 つの名前付き行 (ROW) 型間の比較を実行する前に、ユ
ーザ定義キャストを作成し、登録する必要があります。 2 つの名前付き行 (ROW) 型間
の変換を処理するキャストを作成し、使用する方法の例については、177 ページの『名
前付き行 (ROW) 型間でのキャストの例』を参照してください。
第 9 章 Dynamic Server でのユーザ定義キャストの作成と使用
169
フィールドでの明示的キャストの使用
フィールドに異なるデータ型を含む、名前付きと名前なしの 2 つの行 (ROW) 型の間で
明示的にキャストをするには、対応するフィールド データ型の変換を処理するシステム
定義またはユーザ定義キャストが必要となります。
2 つの行 (ROW) 型の間で明示的にキャストするとき、データベース サーバはフィール
ド データ型の変換を処理するのに必要な明示的キャストを自動的に起動します。つま
り、行 (ROW) 型値の明示的キャストを実行するとき、行 (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);
名前なし行 (ROW) 型のフィールドの明示的キャスト
2 つの行 (ROW) 型間の変換に、特定のフィールド値を変換する明示的キャストが含ま
れる場合、行 (ROW) 型値は明示的にキャストできますが、個々のフィールドを明示的
にキャストする必要はありません。
次の文で、tab1 表に値を挿入する方法を示します。
INSERT INTO tab1 VALUES (ROW( 3, 5.66::FLOAT::d_float))
tab1 の col1 の値を tab2 の col2 に挿入するには、行の値を明示的にキャストする
必要があります。データベース サーバは、tab1 の d_float ディスティンクト型と表
tab2 の実数 (FLOAT) 型の変換を、自動的には処理しません。
INSERT INTO tab2 SELECT col1::ROW(a INT, b FLOAT) FROM tab1
この例で、フィールド b を変換するのに使用するキャストは、明示的です。d_float か
ら実数 (FLOAT) 型への変換には、明示的キャストが必要です。ディスティンクト型を
ソース型に変換するには、明示的キャストが必要です。
一般的に、1 つ以上のフィールドが明示的キャストを使用する 2 つの名前なし行
(ROW) 型の間でキャストをするには、フィールド レベルではなく、行 (ROW) 型レベ
ルで明示的にキャストする必要があります。
名前付き行 (ROW) 型のフィールドの明示的キャスト
ある値を名前付き行 (ROW) 型として明示的にキャストするとき、データベース サーバ
は、フィールド値をターゲット データ型に変換するのに使用する暗黙的キャストまたは
170
IBM Informix: データベース設計および実装 ガイド
明示的キャストを自動的に起動します。次の文では、col1 を型 row_t に明示的にキャ
ストすることにより、実数 (FLOAT) 型のフィールド値を d_float に変換する明示的キ
ャストが自動的に起動します。
INSERT INTO tab3 SELECT col2::row_t FROM tab2
次の INSERT 文には row_t 型への明示的キャストが含まれています。行 (ROW) 型へ
の明示的キャストにより、型 row_t のフィールド b を実数 (FLOAT) 型から d_float
に変換する明示的キャストも起動します。一般的に、行 (ROW) 型への明示的キャスト
は、行 (ROW) 型に含まれる、深さが 1 レベルのフィールドの明示的キャストも起動し
て変換を処理します。
INSERT INTO tab3 VALUES (ROW(5, 6.55::FLOAT)::row_t)
次の文も有効で、前の文と同じ結果を戻します。ただし、この文は値 row_t を tab3
表に挿入するときに実行される明示的キャストを、すべて示しています。
INSERT INTO tab3 VALUES (ROW(5, 6.55::float::d_float)::row_t)
前の例で、行 (ROW) 型のフィールド b の変換には、2 レベルのキャストが必要で
す。データベース サーバは、小数点を含む値をすべて、10 進数 (DECIMAL) 型として
処理します。また、10 進数 (DECIMAL) 型と d_float 型の間には暗黙的キャストがあ
りません。そのため、2 レベルのキャストが必要です。
行 (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) 型のいずれかとなっている必要があります。
第 9 章 Dynamic Server でのユーザ定義キャストの作成と使用
171
v すべてのコンポーネント型が同じ場合、2 つの要素型は等価です。たとえば、一方の
コレクション (COLLECTION) 型の要素型が行 (ROW) 型の場合、もう一方のコレク
ション (COLLECTION) 型も、フィールドの数とデータ型が同じである行 (ROW) 型
です。
v データベースには、データ型が異なる要素型の、任意のまたはすべてのコンポーネン
トの間で変換を実行するキャストが存在します。
対応する要素型のデータ型が異なる場合、Dynamic Server は、組込みキャストまたは
ユーザ定義キャストを使用して要素型のデータ変換を処理できます。
データベース サーバがコレクション (COLLECTION) 型の値を挿入、更新、または比較
するとき、要素型レベルで型チェックが発生します。そのため、2 つのコレクション
(COLLECTION) 型間のキャストでは、要素型レベルでデータ変換を実行します。コレク
ションに格納された実データは、特定の要素型のデータであるためです。
次の型と表は、このセクションのコレクション (COLLECTION) 型のキャストの例で使
用します。
CREATE DISTINCT TYPE my_int AS INT;
CREATE
CREATE
CREATE
CREATE
CREATE
TABLE
TABLE
TABLE
TABLE
TABLE
set_tab1 (col1
set_tab2 (col2
set_tab3 (col3
list_tab (col4
m_set_tab(col5
SET(my_int NOT NULL));
SET(INT NOT NULL));
SET(FLOAT NOT NULL));
LIST(INT NOT NULL));
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 つのコレクション間で変
換を行う方法は、それぞれのコレクションの要素型、および、要素型が異なる場合にデ
ータベース サーバが一方の要素型をもう一方の要素型に変換するのに使用するキャスト
の種類に依存します。
172
IBM Informix: データベース設計および実装 ガイド
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) 型に明示
的にキャストする必要があります。次の例では、整数 (INT) 型 と my_int の要素型の
変換に、明示的キャストが必要です。ディスティンクト型とソース型のキャストは、常
に明示的です。
次の INSERT 文は、set_tab2 表から要素を抽出し、その要素を set_tab1 表をに挿入
するものです。 set_tab2 のコレクション列の要素型は 整数 (INT) 型で、set_tab1 の
コレクション列の要素型は my_int です。整数 (INT) 型 と my_int の要素型の変換に
明示的キャストが必要なので、コレクション (COLLECTION) 型を明示的にキャストす
る必要があります。
INSERT INTO set_tab1 SELECT col2::SET(my_int NOT NULL)
FROM set_tab2
コレクション (COLLECTION) 型の明示的キャストを実行するには、コンストラクタ セ
ット (SET) 型、マルチセット (MULTISET) 型、またはリスト (LIST) 型)、要素型、お
よび NOT NULL キーワードを含める必要があります。
リレーショナル データから マルチセット (MULTISET) 型コレクションへの変
換
関係表からのデータがある場合、コレクション副問合せを使用して、行の値をマルチセ
ット (MULTISET) 型のコレクションにキャストできます。次の表を作成するとしま
す。
CREATE TABLE tab_a ( a_col INTEGER);
CREATE TABLE tab_b (ms_col MULTISET(ROW(a INT) NOT NULL) );
第 9 章 Dynamic Server でのユーザ定義キャストの作成と使用
173
次の例で、コレクション副問合せを使用して tab_a 表の整数 (INT) 型の値の行をマル
チセット (MULTISET) 型のコレクションに変換する方法を示します。 tab_a のすべて
の行をマルチセット (MULTISET) 型のコレクションに変換し、tab_b 表に挿入しま
す。
INSERT INTO tab_b VALUES (
(MULTISET (SELECT a_col FROM tab_a)))
ディスティンクト型のキャスト
ディスティンクト型では、ディスティンクト型がソース型として使用する組込み型の組
込みキャストは、一切継承されません。そのため、組込みデータ型をほかのデータ型に
暗黙的に変換する組込みキャストを、組込み型をソース型として使用するディスティン
クト型で利用することはできません。しかし、組込み型のディスティンクト型を作成す
るとき、データベース サーバは、ディスティンクト型から組込み型への変換、および組
込み型からディスティンクト型への変換を処理する 2 つの明示的キャストを提供しま
す。
ディスティンクト型での明示的キャストの使用
ディスティンクト型の値とソース型の値を比較または置換するには、一方の型をもう一
方の型に明示的にキャストする必要があります。たとえば、ソース型の値でディスティ
ンクト型列の挿入または更新をするには、その値を明示的にディスティンクト型にキャ
ストする必要があります。
次のように、整数 (INTEGER) 型を基にしたディスティンクト型 int_type 型と、型
int_type の列がある表を、次のように作成するとします。
CREATE DISTINCT TYPE int_type AS INTEGER;
CREATE TABLE tab_z(col1 int_type);
tab_z 表に値を挿入するには、次のように、col1 列の値を int_type に明示的にキャス
トする必要があります。
INSERT INTO tab_z VALUES (35::int_type)
次のように、10 進数 (NUMERIC) 型を基にしたディスティンクト型 num_type と、型
num_type の列がある表を作成するとします。
CREATE DISTINCT TYPE num_type AS NUMERIC;
CREATE TABLE tab_x (col1 num_type);
ディスティンクト型 num_type は、10 進数 (NUMERIC) 型のデータに存在するシステ
ム定義キャストを継承しません。そのため、次の挿入には 2 レベルのキャストが必要で
す。最初のキャストで、値 35 を整数 (INT) 型から 10 進数 (NUMERIC) 型に変換
し、2 番目のキャストで 10 進数 (NUMERIC) 型から num_type に変換します。
INSERT INTO tab_x VALUES (35::NUMERIC::num_type)
174
IBM Informix: データベース設計および実装 ガイド
次の、tab_x 表に対する INSERT 文はエラーを戻します。整数 (INT) 型から
num_type に直接変換するキャストは存在しません。
INSERT INTO tab_x VALUES (70::num_type) -- returns error
ディスティンクト型とソース型の間のキャスト
ディスティンクト型のデータ表現はソース型と同じですが、ディスティンクト型をソー
ス型と直接比較することはできません。そのため、ディスティンクト型を作成したとき
に、Dynamic Server によって次の明示的キャストが自動的に登録されます。
v ディスティンクト型からソース型へのキャスト
v ソース型からディスティンクト型へのキャスト
2 つのディスティンクト型を作成すると想定します。 1 つは映画のタイトル、もう 1
つは音楽録音物のタイトルを処理します。可変長文字 (VARCHAR) 型を基にしたディス
ティンクト型は次のように作成します。
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)
);
ディスティンクト型とソース型を比較するには、一方のデータ型からもう一方に明示的
キャストを実行する必要があります。たとえば、ビデオとレーザディスクの両方で入手
できる映画を調べる場合を想定します。次の文は、ディスティンクト型 (music_type)
の値をそのソース型である可変長文字 (VARCHAR) 型の値と比較するために、WHERE
節での明示的キャストを必要とします。この例では、ソース型をディスティンクト型に
明示的にキャストします。
SELECT video FROM entertainment
WHERE video = laser_disc::movie_type
しかし、次の文で示すように、ディスティンクト型をソース型に明示的にキャストする
こともできます。
SELECT video FROM entertainment
WHERE video::VARCHAR(30) = laser_disc
同じソース型に定義した 2 つのディスティンクト型の間で変換を実行するには、ターゲ
ットとなるディスティンクト型にキャストする前に、ソース型に戻す中間キャストを行
う必要があります 。次の文では、music_type の値を movie_type の値を比較してい
ます。
第 9 章 Dynamic Server でのユーザ定義キャストの作成と使用
175
SELECT video FROM entertainment
WHERE video = compact_disc::VARCHAR(30)::movie_type
ディスティンクト型のキャストの追加と削除
ディスティンクト型に強い型指定を適用するために、データベース サーバはディスティ
ンクト型とソース型の間の変換を処理する明示的キャストを提供します。しかし、ディ
スティンクト型の作成者は、既存の明示的キャストを削除して暗黙的キャストを作成で
きます。これにより、ディスティンクト型とソース型の変換に明示的キャストが不要に
なります。
重要: データベース サーバが提供するディスティンクト型とソース型の間の明示的キャ
ストを削除して、代わりにこれらのデータ型変換を処理する暗黙的キャストを作
成すると、ディスティンクト型のもつ独自性が損なわれます。
次の 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 つのデータ型間の変換を実行するキャストがデータベースに存在している場合、その
データ型間のキャストは作成できません。
ディスティンクト型とソース型の間の変換を実行する暗黙的キャストを作成すると、こ
の 2 つの型を、明示的キャストを行うことなく比較できます。次の文では、video 列
と laser_disc 列の比較には、変換が必要となります。暗黙的キャストを作成したの
で、可変長文字 (VARCHAR) 型 と movie_type の間の変換は暗黙的です。
SELECT video FROM entertainment
WHERE video = laser_disc
スマート ラージ オブジェクトへのキャスト
データベース サーバが提供しているキャストにより、テキスト (TEXT) 型およびバイ
ト (BYTE) 型のオブジェクトを BLOB 型および CLOB 型のデータに変換することが
できます。この機能により、既存のデータベースのバイト (BYTE) 型およびテキスト
(TEXT) 型のデータを BLOB 列および CLOB 列に移行できます。
176
IBM Informix: データベース設計および実装 ガイド
次の例は、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) 型の値に変換するキャストを提供していません。
ユーザ定義キャストのキャスト関数の作成
データベースに、不透明 (OPAQUE) 型、ディスティンクト型、または名前付き行
(ROW) 型が含まれている場合、異なるデータ型間の変換ができるユーザ定義キャストを
作成する必要が生じることがあります。格納構造が同じ 2 つのデータ型の間で変換を実
行する場合は、キャスト関数なしで CREATE CAST 文を使用できます。しかし、場合
によっては、キャスト関数を作成してからキャストとして登録する必要があります。次
の場合には、キャスト関数を作成する必要があります。
v 格納構造が異なる 2 つのデータ型間の変換
v データ変換を意味のあるものにするために、値の操作を含む変換
次のセクションでは、キャスト関数を必要とするユーザ定義キャストを作成する方法を
示します。
名前付き行 (ROW) 型間でのキャストの例
次の例に示す名前付き行 (ROW) 型と表を作成すると想定します。名前付き行 (ROW)
型は構造的に等価ですが、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 つの名前付き行 (ROW) 型間の変換を処理するには、まず、ユーザ定義キャストを作
成する必要があります。次の例は、キャスト関数を作成し、型 writer_t から editor_t
への変換を処理するキャストとして登録します。
CREATE FUNCTION cast_rt (w writer_t)
RETURNS editor_t
RETURN (ROW(w.name, w.depart)::editor_t);
第 9 章 Dynamic Server でのユーザ定義キャストの作成と使用
177
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;
もちろん、キャスト演算子 :: を使用して、同じキャストを実行することもできます。こ
れを次の例で示します。
SELECT book_title FROM projects
WHERE writer::editor_t = editor;
ディスティンクト型間でのキャストの例
通貨を表すディスティンクト型、dollar、yen、および sterling を定義するとします。
2 つの通貨間の比較には、金額に為替レートをかける必要があります。そのため、ある
データ型からほかのデータ型へのキャストを処理するだけではなく、比較する値の為替
レートも計算するキャスト関数を作成する必要があります。
次の例は、同じソース型である実数 (DOUBLE PRECISION) 型を基にした 3 つのディ
スティンクト型を定義する方法を示しています。
CREATE DISTINCT TYPE dollar AS DOUBLE PRECISION;
CREATE DISTINCT TYPE yen AS DOUBLE PRECISION;
CREATE DISTINCT TYPE sterling AS DOUBLE PRECISION;
ディスティンクト型を定義した後は、比較可能な製品のメーカー価格を提供する表を作
成できます。次の例では、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
の値を適切なディスティンクト型にキャストできます。
INSERT INTO manufact_price
VALUES (’baseball’, 5.00::DOUBLE PRECISION::dollar,
510.00::DOUBLE PRECISION::yen,
3.50::DOUBLE PRECISION::sterling);
178
IBM Informix: データベース設計および実装 ガイド
ディスティンクト型は、ソース型で利用できる組込みキャストを継承しないので、前の
INSERT 文はそれぞれ 2 つのキャストを必要とします。それぞれの INSERT 文で、内
部キャストは 10 進数 (DECIMAL) 型を実数 (DOUBLE PRECISION) 型に変換し、外
部キャストは実数 (DOUBLE PRECISION) 型を適切なディスティンクト型 (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;
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;
第 9 章 Dynamic Server でのユーザ定義キャストの作成と使用
179
マルチレベル キャスト
マルチレベル キャストとは、あるデータ型の値をターゲット データ型に変換するため
に、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 値を導出しま
す。
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 値の比較を可能にしています。
180
IBM Informix: データベース設計および実装 ガイド
第 4 部 次元データベース
第 10 章 次元データ モデルの作成 . . .
データ ウェアハウスの概要 . . . . . .
次元データベースを作成する理由 . . .
次元データとは . . . . . . . . .
次元データ モデルのコンセプト . . . . .
ファクト表 . . . . . . . . . . .
データ モデルの次元. . . . . . . .
次元要素 . . . . . . . . . . .
次元属性 . . . . . . . . . . .
次元表 . . . . . . . . . . .
次元データ モデルの作成 . . . . . . .
ビジネス プロセスの選択 . . . . . .
ビジネス プロセスの要約 . . . . . .
ファクト表の細分性の決定 . . . . . .
細分性のデータベース サイズへの影響
力 . . . . . . . . . . . . .
ビジネスプロセスを使用しての細分性
の決定 . . . . . . . . . . .
次元と階層の明確化 . . . . . . . .
ファクト表のメジャー (基準) の選択 . .
ファクト表を次元表と結合するキーの
使用 . . . . . . . . . . . .
正規化の防止 . . . . . . . . . .
次元表の属性の選択 . . . . . . . .
次元データ モデルの共通する問題の処理
次元表の属性数を最小限に抑える . . .
時々変更する次元の処理 . . . . . .
スノーフレーク スキーマの使用 . . . .
第 11 章 次元データベースの実装
(Extended Parallel Server のみ) . . . .
次元データベース sales_demo の実装 . . .
CREATE DATABASE の使用 . . . . .
CREATE TABLE 文を使用した次元表およ
びファクト表の作成 . . . . . . . .
データ ソースからデータベースへのデー
タのマッピング . . . . . . . . .
次元データベースへのデータのロード . .
データベース sales_demo の作成 . . . .
次元データベースのテスト . . . . . .
© Copyright IBM Corp. 1996, 2003
183
183
184
185
187
188
189
189
190
190
191
191
192
193
193
Extended Parallel Server のログ付き表とログ
なし表 . . . . . . . . . . . . .
表タイプの選択 . . . . . . . . .
スクラッチ一時表と Temp 一時表 . .
ロウ永続表 . . . . . . . . . .
静的永続表 . . . . . . . . . .
オペレーショナル永続表 . . . . .
標準永続表 . . . . . . . . . .
表の種類の切替え . . . . . . . . .
データ ウェアハウス環境のインデックス
データ ウェアハウス環境での GK インデッ
クスの使用 . . . . . . . . . . . .
選択での GK インデックスの定義 . . .
式での GK インデックスの定義 . . . .
結合された表での GK インデックスの定
義 . . . . . . . . . . . . . .
212
212
213
214
214
215
215
215
216
217
217
217
218
193
194
196
197
198
198
200
200
201
202
205
205
205
206
207
209
211
211
181
182
IBM Informix: データベース設計および実装 ガイド
第 10 章 次元データ モデルの作成
本章の概要
この章では、次元データ モデルのコンセプトおよびテクニックを紹介し、簡単な次元デ
ータ モデルの作成方法を説明します。 第 11 章では SQL を使用して次元データ モデ
ルを実装する方法を説明します。
大規模なデータ ウェアハウスについては、次元データ モデルはリレーショナル データ
モデルよりも管理が困難です。このため、データ ウェアハウスでは通常、リレーショナ
ル データ モデルに基づいています。しかし、次元データ モデルは、データ ウェアハ
ウスのサブセットであるデータ マートを作成する場合に特に適しています。
この章で取り扱う次元データ モデルの一般原則は、Dynamic Server や、Extended
Parallel Server で作成するデータベースに適用されます。どのデータベース サーバを使
用して次元データベースを作成するかを、単一の要素だけで決定することはできませ
ん。しかし、大規模なスケーラブル ウェアハウスは Extended Parallel Server で作成
し、小型のウェアハウス、OLTP システム、および運用システムは Dynamic Server で
作成することを想定しています。
次元データ モデルのコンセプトを理解するには、SQL やリレーショナル データベース
の理論についての基本的な知識が必要です。この章では、データ ウェアハウスのコンセ
プトを要約し、簡単な次元データ モデルを説明するにすぎません。
データ ウェアハウスの概要
データ ウェアハウスという用語は、最も広い意味では、きわめて多くの履歴データを格
納しているデータベースのことを指します。データは一連のスナップショットとして格
納され、そのスナップショットの各レコードは、ある特定の時点でのデータを表わしま
す。このデータ スナップショットで、ユーザが履歴を再作成したり、何らかの時点と別
の時点との間で正確な比較をしたりできます。データ ウェアハウスは、ウェアハウスに
ロードされる前に抽出するデータを統合し、変換します。データ ウェアハウスの第一の
長所は、格納されている膨大な情報に簡単にアクセスしたり、分析したりできることで
す。
データ ウェアハウスという用語が、人によっては違うことを意味することがあるため、
このマニュアルでは、データ ウェアハウスとデータ ウェアハウス環境という包括的な
用語を使用して、データを格納するために使用する次のフォーマットをいいます。
v データ ウェアハウス
© Copyright IBM Corp. 1996, 2003
183
データ抽出のために最適化されたデータベースです。データをトランザクション レ
ベルで格納するのではなく、あるレベルのデータを要約します。日常の操作を自動化
する従来の OLTP データベースとは違い、データ ウェアハウスは長期にわたってエ
ンタープライズ全体のパフォーマンスを評価できる意思決定支援環境を提供します。
通常、リレーショナル データ モデルを使用して、データ ウェアハウスを作成しま
す。
v データ マート
小型のデータベースに格納され、エンタープライズ全体の戦略計画ではなく特定の目
的またはデータ サブジェクトを指向する、データ ウェアハウスのサブセットです。
データ マートには、操作データ、要約データ、スペーシャル (地理空間) データ、メ
タデータを組み込むことができます。通常、次元データ モデルを使用して、データ
マートを作成します。
v 操作データ ストア
意思決定を行うときに 1 度に 1 つまたは 2 つのレコードを参照するように最適化
されたサブジェクト指向のシステムです。操作データ ストアは、タイムリーで、現
行の統合データを含んでいるハイブリッド形式のデータ ウェアハウスです。データ
には通常、トランザクションよりも高いレベルの細分性があります。操作データは事
務的な日常の意思決定に使用できます。このデータは、データ ウェアハウスの共通
データ ソースとしての役割を果たすことができます。
v リポジトリ
リポジトリは、複数のデータ ソースを結合して、1 つの正規化されたデータベース
にします。リポジトリ内のレコードは、頻繁に更新されます。データは、履歴データ
ではなく、操作データです。特定のシステム要件によっては、特定の意思決定の問合
せにリポジトリが使用できます。リポジトリは、操作処理用の統合化されたエンタプ
ライズ全体のデータ ソースを必要とする企業のニーズに適合しています。
次元データベースを作成する理由
リレーショナル データベースは通常、オンライン トランザクション処理 (OLTP) 用に
最適化されています。 OLTP システムは、業務上の日常的な操作ニーズを満たすように
設計され、データベースのパフォーマンスはそのような操作上のニーズに合わせて調整
されます。したがって、リレーショナル データベースでは少数のレコードなら迅速に検
索できますが、大量のレコードを検索し、急いで要約する場合には、速度が遅くなるこ
とがあります。 OLTP システムの欠点となる可能性があるのは、次の点です。
v ビジネス エンタープライズ全体では、データに一貫性がない場合があります。
v データへのアクセスが複雑になる可能性があります。
これとは対照的に、次元データベースは、ビジネスの動向や予測の分析を支援するよう
に設計され、調整されています。このような情報処理の種類を、OLAP (Online
Analytical Processing : オンライン分析型処理)、または意思決定支援処理といいます。
OLAP は、データベース設計者が情報処理への次元的なアプローチのことをいうときに
使用する用語でもあります。
184
IBM Informix: データベース設計および実装 ガイド
次元データベースは、データ抽出と分析のために最適化されています。データベースに
ロードした新しいデータは通常、多くの場合は複数のソースから、バッチで更新されま
す。 OLTP システムが、受注入力のような特定の処理を中心にデータを整理する傾向に
あるのに対し、次元データベースはサブジェクト指向の傾向にあり、「どんな製品が売
れ筋か、どんな時期に製品が一番売れるか、どこの地区の販売が弱いか」といった質問
に答えることを目的としています。
次の表に、OLTP データベースと OLAP データベースとの主な違いを要約します。
リレーショナル データベース (OLTP)
次元データベース (OLAP)
データを細分化
データを要約
現行のデータ
履歴データ
1 度に 1 つのレコードを処理
1 度に多数のレコードを処理
処理指向
サブジェクト指向
高構造化反復処理向けに設計
高構造化されていない分析処理向けに設計
リレーショナル テクノロジによって企業が解決をはかろうとする問題の多くは、元来、
多次元的なものです。たとえば、地域ごとの製品の売上げ、製品ごとの地域の売上げな
どの要約を作成する SQL では、従来のリレーショナル データベースでの処理に何時間
もかかるかもしれません。しかし、次元データベースでは、同じ問合せが一瞬のうちに
処理できます。
次元データとは
従来のリレーショナル データベースは、レコードのリストを中心として整理されていま
す。各レコードには、属性 (フィールド) に整理された関連情報が組み込まれていま
す。デモンストレーション データベース stores_demo の customer 表はその代表例
であり、名前、会社、住所、電話番号などのフィールドが入っています。この表には複
数のフィールドに情報がありますが、表の各行には 1 件の顧客が属しているにすぎませ
ん。顧客名と、たとえば電話番号のようなほかのフィールドを持つ 2 次元的なマトリッ
クスを作成する場合、1 対 1 の対応しか表現できません。表 5 に、1 対 1 の対応だけ
があるフィールドを使用した表を示します。
表 5. フィールドが 1 対 1 で対応している表
顧客
電話番号--->
Ludwig Pauli
Carole Sadler
Philip Currie
408-789-8075
-------------------------------
---------------415-822-1289
----------------
------------------------------414-328-4543
第 10 章 次元データ モデルの作成
185
このマトリックスの前記の customer 表からフィールドを任意に組合わせることはでき
ますが、1 対 1 の対応で常に終わるため、この表には多次元性がなく、次元データベー
スには不向きであることがわかります。
そこで、表のフィールド間に 1 対 1 よりも多くの対応が含まれているリレーショナル
データベースを考えてみます。国内の各地域の製品売上げについての売上げデータを含
んだ表を作成するとします。説明を簡単にするために、この会社には 3 種類の製品があ
って、3 つの地域で販売しているとします。表 6 に、このデータをリレーショナル表に
格納する方法を示します。
表 6. 簡単なリレーショナル表
製品
サッカーボール
サッカーボール
サッカーボール
テニスラケット
テニスラケット
テニスラケット
野球ボール
野球ボール
野球ボール
地域
東部
西部
中央
東部
西部
中央
東部
西部
中央
販売数量
2300
4000
5600
5500
8000
2300
10000
22000
34000
186 ページの表 6 の表によると、1 地域で複数の製品が販売され、また 1 製品が複数
の地域で販売されています。したがって、この表には多次元的な表現が適しています。
表 7 に、製品と地域データの多対多の関係を、よりうまく表現している 2 次元的なマ
トリックスを示します。
←製品
表 7. 簡単な 2 次元的な例
地域→
サッカーボール
テニスラケット
野球ボール
中央
5600
2300
34000
東部
2300
5500
10000
西部
4000
8000
22000
このデータを表 6の 3 つのフィールドのあるリレーショナル表にすることはできます
が、データは表 7の 2 次元的なマトリックスのほうがより自然です。
従来のリレーショナル表よりも、次元表のほうがパフォーマンスは良くなります。次元
的なアプローチによって、要約したり、比較したりするデータへのアクセスが簡単にな
ります。たとえば、次元表を使用して、西部で販売されている製品の数を問い合せる場
合は、データベース サーバが west 列を検索し、その列のすべての行の合計を計算し
ます。リレーショナル表で同じ問合せを実行する場合、データベース サーバは region
列が west になる行を検索、抽出してから、そのデータを集計します。この種の問合せ
186
IBM Informix: データベース設計および実装 ガイド
では、次元表を使用すると、リレーショナル表が west のレコードすべてを検索するた
めに要するほんのわずかな間に、west 列のすべての値を合計できます。
次元データ モデルのコンセプト
次元データベースを作成するには、次元データ モデルから着手します。次元データ モ
デルは、データベースを作成するための方法を簡単かつ理解しやすくします。次元デー
タベースは、どの次元にもアクセスできる、3 次元または 4 次元のデータベース キュ
ーブ (立方体) と考えることができます。次元データベースを作成するには、データを
視覚化するモデルが必要です。
ユーザの業務は異なる市場で製品を販売することであり、時経過のパフォーマンスを評
価するとします。このビジネス プロセスを、時間、製品、および市場という各次元が含
まれているデータのキューブ (立方体) と考えるのは簡単です。図 36 は、この次元モデ
ルを示しています。キューブ (立方体) の各線に沿ったさまざまな交差部分には、この
ビジネスのメジャー (基準) が含まれています。このメジャー (基準) は、製品、市場、
および時間データという特定の組み合わせに対応します。
図 36. 時間、製品、および市場の次元のあるビジネスの次元モデル
次元モデルは、スター結合スキーマともいいます。このモデルのダイアグラムが、中央
に表があり、その周囲にほかの表が配置されていて星のように見えるために、データベ
ース設計者はこの名前を使用しています。このスキーマによる表は中央の表だけで、ほ
かのすべての表は複数結合によって接続されます。この中央の表を ファクト表 とい
い、他の表を 次元表 といいます。すべての次元表には、次元表とファクト表とを結ぶ
連結部が、問合せには関係なく、1 つだけあります。図 37 に、異なる市場で製品を販
売し、時経過による業績を評価するあるビジネスの簡単な次元モデルを示します。
第 10 章 次元データ モデルの作成
187
図 37. 代表的な次元モデル
ファクト表
ファクト表 は、ビジネスのメジャー (基準) を格納し、各次元表の最低レベルのキー値
を示します。メジャー (基準) は、サブジェクトについての量的なデータ、または実際
のデータです。メジャー (基準) は通常、数値であり、質問の量 や 数 に対応します。
メジャー (基準) の例には、価格、製品の売上げ、製品の在庫、収益などがあります。
メジャー (基準) は、表内の列に基づくこともでき、算出されることもできます。
表 8 に、販売数量の合計、収益、ある日のあるアカウントへのある製品の販売利益がメ
ジャー (基準) となっているファクト表を示します。
表 8. サンプル レコードによるファクト表
製品コード
アカウント
コード
日コード
販売数量
収益
利益
1
5
32104
1
82.12
27.12
3
17
33111
2
171.12
66.00
1
13
32567
1
82.12
27.12
ファクト表を設計する前に、そのファクト表の細分性を決定する必要があります。細分
性は、そのファクト表の個々の低レベル レコードを定義する方法に対応します。細分性
は、個別のトランザクション、毎日のスナップショット、あるいは毎月のスナップショ
188
IBM Informix: データベース設計および実装 ガイド
ットであったりします。 表 8 のファクト表には、各アカウントに販売した製品ごとに
毎日 1 行が組み込まれています。したがって、このファクト表の細分性は、アカウント
別、日別の製品として表現します。
データ モデルの次元
次元は、実世界での 1 セットのオブジェクト、またはイベントを表します。データ モ
デルのために明確にした各次元は、次元表として実装しなければなりません。次元と
は、ファクト表のメジャー (基準) を意味あるものにする修飾子です。 次元は質問の何
が、いつ、どこでという局面に答えるからです。たとえば、次元をゴシック体で示して
いる次のビジネス上の質問を考えてください。
v 昨年 はどのアカウント が最高の利益を生み出しましたか。
v ベンダ ごとの利益はどのようでしたか。
v 各製品 はどのくらいの数量が売れましたか。
上記の質問のうち、収益、利益、および販売数量は次元ではなくメジャー (基準) であ
り、数量データまたは実際のデータを表します。
次元要素
次元では、さまざまなレベルの要約に複数の次元要素 を定義できます。たとえば、販売
組織の構造に関連するすべての要素が 1 つの次元を構築していることがあります。図
38 に、アカウント次元が定義する次元要素を示します。
図 38. アカウント次元における次元要素
次元は、関連要素の階層から構築されています。次元と次元の間には階層的な関係があ
るので、ユーザは、前の詳細レベルよりも高いレベル にあるデータにアクセスしたり
(ロール アップする)、 低いレベルにあるデータにアクセスしたりする (ドリル ダウン
する) 問合せを構築することができます。図 38 に、次元要素の階層的関係を示しま
す。アカウントはテリトリにロール アップし、テリトリは地域にロール アップしま
す。ユーザは、抽出するデータに応じて、異なるレベルの次元で問合せができます。た
とえば、ユーザがすべての地域に対する問合せを実行してから、詳細な情報を得るため
にテリトリまたはアカウントのレベルまでドリル ダウンする場合があります。
第 10 章 次元データ モデルの作成
189
次元要素は通常、ほかの表との連結を容易にするため、数値コードまたは短い文字列と
してデータベースに格納されます。
各次元要素では、次元が複数の次元要素を定義するのと同じ方法で、複数の次元属性が
定義できます。
次元属性
次元属性とは、次元表の列のことをいいます。各属性は、次元階層内の要約のあるレベ
ルのことをいいます。次元要素が次元表内の階層的な関係を定義するのに対して、属性
はユーザがよく知っている用語で次元要素を表します。図 39 に、アカウント次元の次
元要素と対応する属性を示します。
図 39. 次元要素に対応する属性
次元属性は次元内の項目を記述するため、テキストの場合に最も便利です。
ヒント: 設計プロセスにある間に、生産データ ソースからの数値データ フィールドが
計測済みのファクトなのか属性なのかがわからないことがあります。一般に、
サンプリングを行うたびに数値データ フィールドが変化する計測値の場合は、
ファクトです。ほぼ一定の何かを個別に評価した説明の場合は、次元属性で
す。
次元表
次元表は、ビジネスの次元についての説明をテキスト形式で格納する表です。次元表に
は、適切な場合、階層の各レベルの要素と属性が含まれています。データ分析に必要な
最低レベルの詳細によって、その階層の最低レベルが決定します。この基本レベルより
も高いレベルが冗長データを格納します。この正規化されていない表では、問合せに必
要な結合部分の数が低減して、ユーザが高いレベルに問合せしてから詳細レベルにドリ
ル ダウンすることが簡単になります。ドリル ダウン という用語は、次元表の行ヘッダ
を問合せに追加することを意味します。 表 9に、アカウント次元を基にした次元表の例
を示します。
190
IBM Informix: データベース設計および実装 ガイド
表 9. 次元表の例
アカウント
コード
アカウント名
テリトリ
営業員
地域
地域
サイズ
地域
管理者
1
Jane’s Mfg.
101
B. Adams
中西部
50 以上
T. Sent
2
TBD Sales
101
B. Adams
中西部
50 以上
T. Sent
3
Molly’s Wares
101
B. Adams
中西部
50 以上
T. Sent
4
The Golf Co.
201
T. Scott
中西部
50 以上
T. Sent
次元データ モデルの作成
次元データ モデルを作成するには、データベース設計を完成させるために必要な意思決
定を概説する方法論が必要です。この方法論では、トップダウン (上から下へ) のアプ
ローチを使用します。 それは、データを収集する組織の主要プロセスを最初に明確にす
るからです。組織が使用している既存の情報ソースから着手することがデータベース設
計者にとっての重要なタスクです。プロセスが明確になったら、各ビジネス プロセスか
ら 1 つまたは複数のファクト表を作成します。次の手順では、データ モデルを作成す
るために使用する方法論を説明します。
次元データベースを作成するには:
1. モデル化するサブジェクト分野を分析するために使用するビジネス プロセスを選択
します。
2. ファクト表の細分性を決定します。
3. 各ファクト表の次元と階層を明確にします。
4. ファクト表のメジャー (基準) を明確にします。
5. 各次元表の属性を決定します。
6. ユーザにデータ モデルを確認させます。
次元データベースは、複数のビジネス モデルにもとづいていたり、多くのファクト表を
持っていたりしますが、このセクションで説明するデータ モデルは単一のビジネス プ
ロセスに基づいており、ファクト表も 1 つです。
ビジネス プロセスの選択
ビジネス プロセスは、従来のシステムが支援する組織において重要なオペレーションで
す。このシステムからデータを収集して、次元データベースに使用します。ビジネス プ
ロセスでは、それらのデータを使用してエンドユーザが何を行うのか、どこから来たデ
ータなのか、そのデータを意味あるものにするにはどうやって変換するのかを明確にし
ます。財務、売上げ分析、市場分析、顧客プロファイルなど、数多くのソースから情報
が発生します。次のリストは、どんなデータを次元データベースに組み込むかを判断す
るために使用するかもしれないさまざまなビジネス プロセスを示しています。
第 10 章 次元データ モデルの作成
191
v 販売
v 出荷
v 在庫
v 注文
v 送り状
ビジネス プロセスの要約
たとえば、もっと効率的なマーケティング戦略を開発できるように、ユーザの組織が顧
客の購買動向を製品ラインと地域ごとに分析するとします。このシナリオでは、データ
モデルの対象エリアは販売です。
多くのインタビューを行い、販売ビジネス プロセスを完全に分析してから、ユーザの組
織は次の情報を収集するとします。
v 顧客ベースの情報が変化しました。
以前は、営業地区を都市ごとに分割していました。現在、顧客のベースは 2 つの地
域に対応しています。地域 1 としてカリフォルニア州、地域 2 としてその他の州で
す。
v 次のレポートは、マーケティング上で最も重要です。
– ベンダ当たりの製品別の毎月の収益、コスト、純利益
– 製品、地域、月別の収益と販売数量
– 毎月の顧客収益
– ベンダ当たりの四半期の収益
v 販売分析のほとんどは月ごとの結果に基づくものですが、後で、週ごと、または会計
期間ごとに売り上げを分析することができます。
v データ入力システムは、リレーショナル データベースにあります。
作業用のデータ モデルを開発するには、販売情報のリレーショナル データベースに
次のプロパティがあると想定できます。
– データベース stores_demo は、マーケティング部門が使用する収益データの多く
を提供します。
– 分析担当者が使用する製品コードは、カタログ番号として catalog 表に格納され
ています。
– 製品ライン コードは、ストック番号として stock 表に格納されています。製品ラ
イン名は、説明として格納されています。
– 製品階層はやや複雑です。各製品ラインには多くの製品があり、各メーカーにも多
くの製品があります。
v 各製品のコスト データはすべて、異なる購買システムの costs.lst というフラット
ファイルに格納されています。
v 顧客データは、データベース stores_demo に格納されています。
192
IBM Informix: データベース設計および実装 ガイド
地域情報は、このデータベースにまだ追加されていません。
次元モデルの重要な特性は、このモデルが内部の表名や列名ではなく、エンド ユーザが
よく知っているビジネス ラベルを使用しているということです。ビジネス プロセスが
完了すれば、次元データ モデルのメジャー (基準)、次元、および関係を作成するため
に必要なすべての情報が入手できます。この次元データ モデルを使用して、第 11 章
で説明するデータベース sales_demo 実装します。
デモンストレーション データベース stores_demo は、この章で開発する次元データ
モデルの主要なデータ ソースです。データベース sales_demo の表を移植するために
使用するデータ ソースについての詳細は、 207 ページの『データ ソースからデータベ
ースへのデータのマッピング』を参照してください。
ファクト表の細分性の決定
対象分野についての関連情報をすべてそろえたら、設計プロセスでの次の手順はファク
ト表の細分性を決定することです。これを行うには、ファクト表に個別の低いレベルの
どんなレコードを組み込むかを決定する必要があります。ファクト表の細分性を作り上
げる構成要素は、データ モデルの次元と直接一致します。したがって、ファクト表の細
分性を定義するときは、データ モデルの次元を明確にします。
細分性のデータベース サイズへの影響力
ファクト表の細分性は、データベースに必要な格納領域量も決定します。たとえば、フ
ァクト表について考えられる次の細分性を考えてください。
v 日別地域別の製品
v 月別地域別の製品
日別地域別の製品という細分性を持つデータベースのサイズは、月別地域別の製品とい
う細分性を持ったデータベースよりもはるかに大きくなります。これは、トランザクシ
ョンの月次要約ではなく、毎日のトランザクションそれぞれについてのレコードがデー
タベースに組み込まれるからです。細分性が細かすぎると自然と膨大なデータベースに
なってしまう可能性があるため、ファクト表の細分性は注意して決定する必要がありま
す。反対に、細分性を大まかにしすぎると、ユーザがデータベースに対して意味のある
問合せを行うのに十分な詳細が得られないことになります。
ビジネスプロセスを使用しての細分性の決定
ビジネス プロセスから収集した情報を入念に検討することによって、ファクト表の細分
性を決定するには何が必要かがわかります。要約すると、もっと効率的なマーケティン
グ戦略が開発できるように、ユーザの組織は顧客の購買動向を製品ライン別と地区別に
分析するということです。
製品別顧客: ファクト表の細分性は常に、対応する各次元の最低のレベルを表わしま
す。ビジネス プロセスからの情報を検討すれば、ファクト表の顧客と製品の次元につい
ての細分性が明らかになります。顧客と製品はこれ以上細分化できません。これらは既
第 10 章 次元データ モデルの作成
193
に、ファクト表の各レコードの最低のレベルを表しています。製品が複数のコンポーネ
ントで構成されている場合もあるので、製品は、さらに製品コンポーネントのレベルに
まで細分化できることもあります。
製品別地区別の顧客: ユーザの組織が分析する顧客購買動向には地理的な構成要素が
含まれているため、この場合も、地域情報については最低レベルを決定する必要があり
ます。ビジネス プロセスでは、これまでは販売地区は市区町村別に分割されていました
が、ユーザの組織では現在、顧客ベースの 2 つの地域を区別しています。地域 1 はカ
リフォルニア州、地域 2 はその他の州です。しかし、最低のレベルには販売地区データ
も組み込まれているため、地区が地理的情報の最低レベルを表し、ファクト表の細分性
をさらに定義する第 3 の構成要素となっています。
製品別地区別日別の顧客: 顧客購買動向は常に時経過によって発生するため、ファ
クト表の細分性には時間要素を組み込む必要があります。ユーザの組織では、週、会計
期間、月、四半期、年およびごとにレポートを作成するように決定したとします。最低
レベルでは、基本の細分性である「日」を選択します。この細分性により、火曜日の売
り上げと金曜日の売り上げを比較したり、毎月の最初の日の売り上げを比較したりする
ことができます。ファクト表の細分性は、これで完成しました。
日の細分性を選択するという決定は、time 次元表の各レコードが日を表わすことを意味
します。格納要件という点から見ると、毎日のデータが 10 年分あっても、約 3,650 レ
コードにすぎず、比較的小さな次元表といえます。
次元と階層の明確化
ファクト表の細分性を決定したら、データ モデルの主要な次元を明確にするのは簡単で
す。これは、細分性を定義する各コンポーネントが次元に対応しているからです。図 40
は、ファクト表の細分性とデータ モデルの次元との関係を示しています。
図 40. データ モデルの次元に対応するファクト表の細分性
データ モデルの次元 (顧客、製品、地理、時間) を正しい位置に使用すると、スキーマ
ダイアグラムが形になってきます。
ヒント: この時点で、ファクト表の主要な細分性にさらに次元を追加できます。この場
合、新しい次元は主要次元を組み合わせる際に単一の値しかとれません。次元
を追加したためにさらにレコードが生成され、細分性に違反することが確認さ
194
IBM Informix: データベース設計および実装 ガイド
れた場合は、ファクト表の細分性を変更して、追加した次元が納まるようにす
る必要があります。このデータ モデルについては、追加的な次元を追加する必
要はありません。
この時点で、各次元の次元要素と階層がマップできるようになりました。 図 41は、次
元、次元要素、および固有の階層間の関係を示しています。
図 41. 次元、次元要素、および固有の階層間の関係
第 10 章 次元データ モデルの作成
195
ほとんどの場合、次元要素では、各次元についての考えられる最低の細分性を表現する
必要があります。 これは、問合せが個別の低いレベルのレコードにアクセスするからで
はなく、問合せには厳密な方法でデータベースを検索する必要があるからです。つま
り、データ ウェアハウス環境が提起する問題が通常、大まかなものであったとしてもま
だ、これらの質問は製品詳細の最低レベルに依存します。
ファクト表のメジャー (基準) の選択
データ モデルのメジャー (基準) には、データそのものだけでなく、既存のデータから
計算する新しい値も含まれます。そのため、メジャー (基準) を調べると、ファクト表
の細分性だけでなく次元の数も調整する必要がでてくる場合もあります。
データ モデルを設計するときに必要なもう 1 つの重要な決定事項は、計算結果をファ
クト表に格納するか、これらの値を実行時に導出するかです。
答えなければならない質問は、「ビジネスを分析するのにどんなメジャー (基準) を使
用するか」です。メジャー (基準) は、どれくらいの量、またはどれくらいの数かを示
す量的なデータか、実際のデータであることを思い出してください。販売ビジネス プロ
セスの分析から集めた情報は、次のリストのメジャー (基準) になります。
v 収益
v コスト
v 販売数量
v 純利益
これらのメジャーを使用して、図 42 のファクト表が完成します。
196
IBM Informix: データベース設計および実装 ガイド
図 42. 各次元表を参照する販売ファクト表
ファクト表を次元表と結合するキーの使用
さしあたり、197 ページの図 42 のスキーマは、データベースの論理設計と物理設計の
両方が示されていると考えてください。データベースには次の 5 つの表が含まれていま
す。
v Sales ファクト表
v Product 次元表
v Time 次元表
v Customer 次元表
v Geography 次元表
各次元表には、主キー (製品、時間コード、顧客、地域コード) が含まれていて、ファ
クト表では対応する列は外部キーです。ファクト表には、これら 4 つの外部キーの組み
合わせである主 (複合) キーもあります。原則として、ファクト表の各外部キーには、
次元表にそれと 1 対になるキーがなければなりません。さらに、複合キーを備えている
次元データベースの表は、ファクト表である必要があります。 つまりこれは、多数対多
数の関係を表わす次元データベースの各表がファクト表であることを意味します。
第 10 章 次元データ モデルの作成
197
ヒント: 主キーは、短い数値データ型 (整数 (INT) 型、小桁整数 (SMALLINT) 型、シ
リアル (SERIAL) 型) または (コードに使用するような) 短い文字列にします。
長い文字列を主キーとして使用しないようにしてください。
正規化の防止
ファクト表の 4 つの外部キーは、きちんと管理された連続整数である場合、ファクト表
の 4 つのキーすべてに対して 16 バイト (時間、製品、顧客、および地理について 4
バイトずつ) まで小さくして予約できます。ファクト表の 4 つのメジャー (基準) が各
4-byte バイトの整数列であれば、別に 16 バイトだけを予約する必要しかありません。
したがって、ファクト表の各レコードは 32 バイトになるにすぎません。何十億の列の
あるファクト表でも、約 32 GB の基本データ スペースしか必要としません。
コンパクトなキーやデータを使用している、記憶量の少ないファクト表が次元データベ
ースの典型です。次元モデルのファクト表は元来、高度に正規化されています。ファク
ト表の 4 つのキー間のきわめて複雑な多数対多数の関係はこれ以上正規化できません。
4 つの次元表に相互間系がないからです。 実際には、各製品は、各地区のすべての顧客
に対して毎日販売されています。
ファクト表は、次元データベースで一番大きな表です。次元表は通常、ファクト表より
もかなり小さいため、データベースのディスク領域を計算するときには次元表を無視す
ることができます。ディスク領域を節約するためだけに次元データベースのどんな表で
も正規化するという努力は、的を射ていません。さらに、正規化された次元表は、ユー
ザが単一の次元表を探索して制約を設定したり、便利な行ヘッダを選択したりする能力
を低減します。
次元表の属性の選択
ファクト表が完成したら、各次元表の次元属性を決定できます。属性を選択する方法を
説明するために、時間次元を考えてみましょう。販売ビジネス プロセスのデータ モデ
ルは、time 次元表の各レコードが日を表わすように、時間次元に対応する日の細分性を
定義します。この表の各フィールドは、そのレコードが表わしている特定日によって定
義されることを覚えておいてください。
また、販売ビジネス プロセスの分析で、マーケティング部門が月次、四半期、年次のレ
ポートを必要としていることも示されているため、時間次元には、日、月、四半期、年
という要素が含まれます。各要素には、長い文字列を含んでいる列値を回避するため
に、その要素とコード属性を説明する属性が割り当てられています。表 10 は、time 次
元表の属性と、表の各フィールドのサンプル値を示しています。
198
IBM Informix: データベース設計および実装 ガイド
表 10. 時間次元の属性
時間
注文日
コード
35276
07/31/1999
35277
08/01/1999
35278
08/02/1999
月コード
月
7
8
8
july
aug
aug
四半期
コード
3
3
3
四半期
年
third q
third q
third q
1999
1999
1999
199 ページの表 10 では、割り当てる属性名は、エンド ユーザがデータベース上で問合
せを簡単に作成できるような、なじみのあるビジネス用語とすべきであることを示して
います。図 43 では、各次元表に定義されている属性すべてを備えた販売ビジネス プロ
セスの完ぺきなデータ モデルを示します。
図 43. 販売ビジネス プロセスの完ぺきな次元データ モデル
ヒント: 各次元表に定義する属性の数は一般に、最低限に保つべきです。属性が多すぎ
る次元表は、行を過度に大きくしたり、パフォーマンスを劣化させたりするこ
とがあります。詳しくは、200 ページの『次元表の属性数を最小限に抑える』
を参照してください。
第 10 章 次元データ モデルの作成
199
次元データ モデルの共通する問題の処理
これまでのセクションで説明してきた次元モデルは、次元データ モデルの最も基本的な
コンセプトとテクニックを説明するものにすぎません。エンタープライズのビジネス上
のニーズを明確にするために作成するデータ モデルには、通常、データベースからでき
る限り最高の問合せパフォーマンスを得るために解決する必要のある、さらなる問題や
困難が含まれています。この節では、次元データ モデルを作成するときに最も共通して
発生する問題の解決に使用できるさまざまな方法を説明します。
次元表の属性数を最小限に抑える
顧客情報や製品情報が入っている次元表には、ゆうに 50∼100 個の属性があったり、行
が数百万あったりします。しかし、属性が多すぎる次元表は、行を過度に大きくした
り、パフォーマンスを劣化させたりすることがあります。このため、特定の属性のグル
ープを次元表から切り離して、小次元表という別個の表に配置することもあります。小
次元表は、大きな次元表から切り離された小さな属性グループから構成されます。次の
特性のどちらかを持つ属性に小次元表を作成できます。
v 問合せの制約として、フィールドをほとんど使用しない。
v フィールドを頻繁に比較し合う。
図 44 は、顧客表から切り離された人口情報についての小次元表を示しています。
図 44. 人口情報の小次元表
ファクト表と顧客表の両方の外部キーとして、人口キーを人口表に格納できます。これ
により、人口表をファクト表に直接結合できます。また、直接顧客表と一緒に人口キー
を使用して、人口属性を閲覧することもできます。
200
IBM Informix: データベース設計および実装 ガイド
時々変更する次元の処理
OLTP システムとは対照的に、ほとんど更新されない次元データベースでは、ほとんど
の次元は時がたっても比較的変化しません。販売地区または地域、あるいは会社の名前
や住所にはほとんど変更がないからです。しかし、履歴比較を行うには、これらの変更
は、それが発生した時点で処理する必要があります。図 45 は、変更が加えられた次元
の例を示しています。
図 45. 変更した次元
次元に発生した変更を処理するには、次の 3 種類の方法が使用できます。
v 次元列に格納されている値を変更します。
図 45には、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 についての情報を含んでいるレコードには、元
の住所と現在の住所の両方の値が含まれます。
第 10 章 次元データ モデルの作成
201
スノーフレーク スキーマの使用
スノーフレーク スキーマは、スター スキーマの変形であり、かなり大きな次元表を複
数の表に正規化します。ファクト表の集合体を使用している場合に大きな次元表の結合
を避けたい場合は、階層のある次元をスノーフレーク構造に分解することができます。
たとえば、製品次元表から切り離すブランド情報がある場合は、ブランドごとの単一の
行から構成されていて、製品次元表よりも大幅に行数の少ないブランド スノーフレーク
が作成できます。図 46 は、ブランド要素と製品ライン要素のスノーフレークと、
brand_agg 集合表を示しています。
図 46. スノーフレーク スキーマの例
ブランド コードとブランド当たりの総収益から構成される集合 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 文を使用して、重複行を除去します。
次元表が比較的小さくて、スノーフレーク スキーマが不要であっても、数百万行もある
顧客や製品の次元表のあるような小売業や通信販売ビジネスでは、スノーフレーク スキ
ーマを使用するとパフォーマンスが大幅に向上します。
202
IBM Informix: データベース設計および実装 ガイド
集合表が利用できない場合、スノーフレーク スキーマで正規化された次元要素に結合す
る何らかのものは現在、次の問合せが示すように 3 方向結合である必要があります。 3
方向結合によって、次元データベースのパフォーマンス上の長所が幾分損なわれてしま
います。
SELECT brand.brand_name, SUM(sales.revenue)
FROM product, brand, sales
WHERE product.brand_code = brand.brand_code
AND brand.brand_name = ’Alltemp’
GROUP BY brand_name
第 10 章 次元データ モデルの作成
203
204
IBM Informix: データベース設計および実装 ガイド
第 11 章 次元データベースの実装 (Extended Parallel
Server のみ)
本章の概要
この章では、SQL を使用して、第 10 章で説明した次元データ モデルを実装する方法
について説明します。このデータベースは、データ ウェアハウス環境を説明するための
単なる例です。例として示すために、説明は SQL 文に翻訳してあります。
この章では、Extended Parallel Server で利用できる、データベース sales_demo につ
いて説明します。この章では、データ ウェアハウジングや大規模なデータベース アプ
リケーションのニーズに適した Extended Parallel Server 特有の表の種類とインデックス
についても説明します。
次元データベース sales_demo の実装
この節では、第 10 章 で説明したデータ モデルから次元データベースを作成するため
に使用できる SQL 文について説明します。対話型 SQL を使用して、データベースを
作成するための文を 1 つずつ書けます。または、スクリプトを実行して、データベース
の実装に必要なすべての文を自動的に実行できます。 CREATE DATABASE 文と
CREATE TABLE 文は、データベース内の表としてデータ モデルを作成します。デー
タベースを作成した後、LOAD 文と INSERT 文を使用して表を構築できます。
CREATE DATABASE の使用
データベース内に表やオブジェクトを作成するには、まずデータベースを作成する必要
があります。
Informix データベース サーバでデータベースを作成する場合、サーバは、データベース
が存在していることとデータベースのロギング モードを示すレコードを設定します。デ
ータベース サーバはディスク領域を直接管理するので、これらのレコードはオペレーテ
ィング システムのコマンドでは見ることができません。
Extended Parallel Serverを使用してデータベースを作成すると、ログ機能は常にオンにな
ります。ただし、データベースにログなし表を作成することもできます。詳しくは、212
ページの『Extended Parallel Server のログ付き表とログなし表』を参照してください。
次の文で、sales_demo というデータベースを作成するのに使用する構文を示します。
CREATE DATABASE sales_demo
© Copyright IBM Corp. 1996, 2003
205
CREATE TABLE 文を使用した次元表およびファクト表の作成
この節では、次元データベース sales_demo の表を作成するために使用する CREATE
TABLE 文について説明します。
参照整合性は、もちろん、次元データベースにとって重要な要件です。しかし、次に示
すデータベース sales_demo のスキーマでは、ファクト表と次元表の間に存在する主
キーと外部キーの関係を定義していません。このスキーマでそのような主キーと外部キ
ーとの関係を定義していない理由は、データをロードする際にデータベース サーバが制
約確認を実行しなければ、ロードのパフォーマンスが大幅に向上するためです。データ
ウェアハウス環境で特定の時間内に数十から数百 GB のデータをロードする必要が頻繁
にある場合、データをロードするパフォーマンスは、データベースをウェアハウス環境
に実装する方法を決定するにあたって重要な要素になります。稼働中のデータ マートと
してデータベース sales_demo が実装されていることを想定した場合、ファクト表と
次元表との間の参照整合性を保つために、データベース サーバではなくデータ抽出ツー
ルが使用されます。
ヒント: 表を作成してロードした後で、参照整合性を保つために、ALTER TABLE 文を
使用して主キー制約と外部キー制約を表に追加できます。この方法は、高速ロ
ード モードの場合にだけ必要です。制約とインデックスが必要で、ロードする
前に削除するのに手間がかかる場合には精細ロード モードが最適なオプション
です。
以下の文は、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),
206
IBM Informix: データベース設計および実装 ガイド
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)
);
ヒント: 最も便利なメジャー (ファクト) は加算的な数値です。データ ウェアハウス環
境では、データベースのサイズが非常に大きいため、ファクト表に対するほと
んどすべての問合せで、その答えを構築するために数千から数百万のレコード
が必要になります。そのようなレコードを圧縮するために使用できる唯一の方
法は、レコードを集約することです。 sales 表では、メジャーの各列が数値デ
ータ型で定義されているので、units_sold、revenue、cost、net_profit の各
列から答えを容易に作成できます。
ユーザの便宜のために、ファイル createdw.sql には、上記の CREATE TABLE 文が
すべて含まれています。
データ ソースからデータベースへのデータのマッピング
デモンストレーション データベース stores_demo は、データベース sales_demo の
主データ ソースです。
208 ページの表 11 は、データ ウェアハウスのビジネス用語とデータ ソースとの関係
を表しています。その表は、データベース sales_demo のそれぞれの列と表のデータ
ソースも表しています。
第 11 章 次元データベースの実装 (Extended Parallel Server のみ)
207
表 11. データ ウェアハウスのビジネス用語とデータ ソースの関係
ビジネス用語
データ ソース
Sales ファクト表
製品コード
顧客コード
地区コード
時間コード
収益
stores_demo:items.total_price
販売数量
stores_demo:items.quantity
コスト
costs.lst (per unit)
純利益
計算結果: 収益 - コスト
Product 次元表
製品
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
Customer 次元表
顧客
stores_demo:orders.customer_num
顧客名
stores_demo:customer.fname +
stores_demo:customer.lname
会社名
stores_demo:customer.company
Geography 次元表
地区コード
生成される
地区
stores_demo:customer.city
州
stores_demo:customer.state
州名
stores_demo.state.sname
地域
導出される: If state = ″CA″ THEN
region = 1, ELSE region = 2
208
Time 次元表
時間コード
注文日
月
生成される
stores_demo:orders.order_date
derived from order date generated
四半期
derived from order date generated
年
注文日から導出される
IBM Informix: データベース設計および実装 ガイド
表.列名
sales.product_code
sales.customer_code
sales.district_code
sales.time_code
sales.revenue
sales.units_sold
sales.cost
sales.net_profit
product.product_code
product.product_name
product.product_line_code
product.product_line_name
product.vendor_code
product.vendor_name
customer.customer_code
customer.customer_name
customer.company_name
geography.district_code
geography.district_name
geography.state_code
geography.state_name
geography.region
time.time_code
time.order_date
time.month_name
time.month.code
time.quarter_name
time.quarter_code
time.year
接尾辞 .unl を持ついくつかのファイルには、データベース sales_demo 内にロードさ
れたデータが含まれています。データベースを作成してロードする SQL 文を含むファ
イルには、接尾辞 .sql が付いています。
UNIX のみ
UNIX 上でデータベース サーバを実行している場合、*.sql および *.unl ファイルには
ディレクトリ $INFORMIXDIR/demo/dbaccess からアクセスできます。
UNIX のみ の終り
Windows NT のみ
Windows NT 上でデータベース サーバを実行している場合、*.sql および *.unl ファイ
ルにはディレクトリ %INFORMIXDIR%\demo\dbaccess からアクセスできます。
Windows NT のみ の終り
次元データベースへのデータのロード
次元 データベースを実装する場合に重要なことは、効果的なロード方法を立案して文章
化することです。この節では、データベース sales_demo の表を構築するために使用で
きる LOAD 文と INSERT 文について説明します。
ヒント: 稼動中のデータ ウェアハウジング環境では、通常、LOAD 文または INSERT
文を使用して Informix データベースとの大量のデータのロードを実行すること
はありません。
Informix データベース サーバには、データのロードとアンロードを行うさまざまな高性
能な機能があります。
Extended Parallel Server を使用してデータベースを作成する場合は、外部表 を使用して
高性能なロードとアンロードを実行できます。
高性能なロードについては、「IBM Informix: 管理者ガイド」または「IBM Informix:
high-performance loader documentation」を参照してください。
次の文は、sales 表内にロードされる各行の時間コードの確定に使用できるように、最
初に time 表にデータをロードします。
LOAD FROM ’time.unl’ INSERT INTO time
次の文は geography 表 にデータをロードします。 geography 表にデータをロード
すると、その地区コード データを、sales 表にロードするために使用できます。
第 11 章 次元データベースの実装 (Extended Parallel Server のみ)
209
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,
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
210
IBM Informix: データベース設計および実装 ガイド
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 問合せを作成すると、ビジネス プロセスのサマリにリストされる標準レポートに
必要なデータを抽出できます (192 ページの『ビジネス プロセスの要約』を参照)。以
下のアドホック問合せを使用して、次元データベースが適切に実装されていることをテ
ストします。
次の文は、各ベンダの製品ラインごとに、毎月の収益、コスト、および純利益の値を返
します。
SELECT vendor_name, product_line_name, month_name,
SUM(revenue) total_revenue, SUM(cost) total_cost,
SUM(net_profit) total_profit
FROM product, time, sales
WHERE product.product_code = sales.product_code
AND time.time_code = sales.time_code
GROUP BY vendor_name, product_line_name, month_name
ORDER BY vendor_name, product_line_name;
次の文は、製品別、地域別、月別の収益と販売数量の値を返します。
SELECT product_name, region, month_name,
SUM(revenue), SUM(units_sold)
FROM product, geography, time, sales
WHERE product.product_code = sales.product_code
AND geography.district_code = sales.district_code
AND time.time_code = sales.time_code
GROUP BY product_name, region, month_name
ORDER BY product_name, region;
次の文は、毎月の顧客収益の値を返します。
SELECT customer_name, company_name, month_name,
SUM(revenue)
FROM customer, time, sales
WHERE customer.customer_code = sales.customer_code
AND time.time_code = sales.time_code
GROUP BY customer_name, company_name, month_name
ORDER BY customer_name;
第 11 章 次元データベースの実装 (Extended Parallel Server のみ)
211
次の文は、ベンダ別の四半期ごとの収益の値を返します。
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 標準永続表 (ログ付き)
v スクラッチ一時表 (ログなし)
v Temp 一時表 (ログ付き)
表の種類を指定せずに CREATE TABLE 文を発行すると、標準永続表が作成されま
す。表タイプを変更するには、ALTER TABLE 文を使用します。構文について詳しく
は、「IBM Informix: SQL ガイド: 構文」を参照してください。
重要: コサーバが一時領域として使用およびアクセスできるのは、そのコサーバが所有
する DB 領域のみです。一時表では永続表と同様に DB 領域内を明示的にフラ
グメント化できますが、コサーバは、そのコサーバ自体が管理するフラグメント
内にだけデータを挿入できます。
表タイプの選択
データ ウェアハウス環境の個々の表では、要求される条件がそれぞれ異なることが多く
あります。以下の質問に答えていくと、使用する適切な表の種類を決定しやすくなりま
す。
v 表にインデックスは必要ですか?
v 表に定義する必要のある制約は?
v 表のリフレッシュまたは更新の周期は?
212
IBM Informix: データベース設計および実装 ガイド
v 表は読取り専用表ですか?
v 表のログを記録する必要はありますか?
表 12 では、Extended Parallel Server がサポートする 6 種類の表の属性を一覧表示して
おり、外部表を使用してこれらの種類の表にデータをロードする方法を示しています。
この表の情報を使用して、使用する表に固有の必要条件に一致する表の種類を選択して
ください。
表 12. Extended Parallel Server の表の種類の特性
永続性
ログ付き
インデッ
クス
簡単な
追加の使用
ロール
バック可能
回復機能
アーカイブ
からの復元
スクラッチ
なし
なし
なし
あり
なし
なし
なし
高速または精細
ロード モード
Temp
なし
あり
あり
あり
あり
なし
なし
高速または精細
ロード モード
ロウ
あり
なし
なし
あり
なし
なし
なし
高速または精細
ロード モード
種類
外部表ロード
モード
静的
あり
なし
あり
なし
なし
なし
なし
なし
オペレーショナ
ル
あり
あり
あり
あり
あり
あり
なし
高速または精細
ロード モード
標準
あり
あり
あり
なし
あり
あり
あり
精細ロード モー
ド
スクラッチ一時表と Temp 一時表
スクラッチ表とは、インデックス、制約、ロール バック機能のいずれもサポートしてい
ないログなし一時表です。
Temp 表は、簡単な追加のようなバルク操作もサポートするログ付き一時表です。エク
スプレス モードのロードでは、バッファ キャッシュをバイパスする簡単な追加を使用
します。簡単な追加では、バッファ管理に関連するオーバーヘッドはなくなりますが、
データのログは記録しません)。 Temp 表は、インデックス、制約、およびロール バッ
ク機能をサポートしています。
ヒント: SELECT...INTO TEMP および SELECT...INTO SCRATCH 文は、通常の挿入と
同様に、複数のコサーバ上で並列になります。 SELECT...INTO TEMP 文と
SELECT...INTO SCRATCH 文により、複数のノードにフラグメント一時表が明
示的に作成された場合、Extended Parallel Server はそれらのフラグメント一時
表を自動的にサポートします。
Extended Parallel Server は、以下の基準に従って明示的な一時表を作成します。
v Temp 表またはスクラッチ表を構築するために使用する問合せによって行が生成され
ない場合、データベース サーバはフラグメント化されていない空の表を作成しま
す。
第 11 章 次元データベースの実装 (Extended Parallel Server のみ)
213
v 問合せによって生成される行が 8 KB を超えない場合、一時表は 1 つの DB 領域内
に常駐します。
v そのような行が 8 KB を超える場合、Extended Parallel Server は複数のフラグメント
を作成し、ラウンド ロビン フラグメンテーション スキーマを使用してそれらのフ
ラグメントを構築します。
ロウ永続表
ロウ表は、簡単な追加を使用するログなし永続表です。エクスプレス モードのロードで
は、バッファ キャッシュをバイパスする簡単な追加を使用します。ロウ表には、エクス
プレス モードでデータをロードできます。エクスプレス モードのロードについては、
「IBM Informix: 管理者の参照」を参照してください。
ロウ表は、更新、挿入、削除をサポートしますが、それらのログは記録しません。ロウ
表は、インデックス、参照制約、ロール バック機能、回復機能、アーカイブからの復元
機能のいずれもサポートしていません。
最初のデータのロードとスクラビングにロウ表を使用します。それらの手順を完了した
ら、より高いレベルに表を変更します。たとえば、ロウ表にロードしているときにエラ
ーか障害が発生すると、その結果のデータは、障害が発生した時点にディスク上にあっ
たデータになります。
データ ウェアハウス環境では、以下の両方の条件に当てはまる場合、ファクト表をロウ
表として作成できます。
v いくつかの機構によっては制約やインデックスが必要なことがあるが、そのような制
約もインデックスもファクト表で指定する必要がない。
v ファクト表を作成することにもファクト表にデータをロードすることにもコストがか
からない。ファクト表は、意思決定支援のために便利ですが必須ではない。 データ
が損失したら、容易にデータを表に再ロードできる。
静的永続表
静的表は、ログなしの読取り専用永続表で、挿入、更新、削除のいずれの操作もサポー
トしていません。挿入、更新、削除のいずれの操作も表で実行しない場合は、静的表と
して表を作成できます。静的表では、非クラスタ インデックスや参照制約を作成したり
ドロップしたりできます。 なぜなら、そのような操作は、データに影響を与えないため
です。
静的表では、ロール バック機能、回復機能、アーカイブからの復元機能のいずれもサポ
ートしていません。静的表の利点は、読み取り専用であるために、問合せの実行時にデ
ータベース サーバが簡単な走査を使用できることと、サーバがロックするのを防げるこ
とです。
ヒント: GK インデックスを使用する表を作成する場合、静的表は重要です。これは、
静的表が GK インデックスをサポートする唯一の表タイプであるためです。
214
IBM Informix: データベース設計および実装 ガイド
オペレーショナル永続表
オペレーショナル表は、ログ付き永続表で、簡単な追加を使用しますがレコード単位の
ログは記録しません。オペレーショナル表では、高速更新の操作を実行できます。
オペレーショナル表では、操作をロール バックしたり、障害から回復したりできます
が、ロードされる大量の挿入レコードはログに記録されないので、ログのアーカイブか
ら確実に復元することはできません。オペレーショナル表を使用するのは、ほかのソー
スからデータを導出するために、復元機能は重要でない場合で、ロール バック機能も回
復機能も必要ない場合です。
周期的にデータがリフレッシュされるので、ファクト表をオペレーショナル表として作
成できます。オペレーショナル表では、インデックスも制約もない場合に高速ロード モ
ードをサポートし、データは回復可能です。
標準永続表
Extended Parallel Server の標準表は、Dynamic Server で作成するログ付きデータベース
の表と同じです。すべての操作はレコード単位でログに記録されるので、標準表はアー
カイブから復元できます。標準表は、回復機能とロール バック機能をサポートしていま
す。
表の更新とリフレッシュの周期が頻繁でない場合、標準表で表を作成できます。 リフレ
ッシュ周期の間に制約とインデックスを削除する必要がないためです。インデックス
は、作成に時間と手間がかかりますが必要です。
ヒント: 標準表では簡単な追加を使用しないので、外部表を使用してロードを実行する
場合には高速ロード モードを使用できません。
表の種類の切替え
ALTER TABLE コマンドを使用して、永続表のタイプを切り替えます。変更する表が、
新しい表の種類の制限事項を満たしていない場合、変更は失敗し、説明のエラー メッセ
ージが表示されます。表の変更には、次の制限事項が適用されます。
v 表の種類を RAW に変更する前に、インデックスと参照制約を削除する必要がありま
す。
v 変更した表が完全回復機能の制限事項に適合するよう、表タイプを STANDARD タイ
プに変更する前にレベル 0 のアーカイブを実行する必要があります。
v Temp 一時表やスクラッチ一時表は変更できません。
第 11 章 次元データベースの実装 (Extended Parallel Server のみ)
215
データ ウェアハウス環境のインデックス
従来の B-tree ツリー インデックスに加えて、Extended Parallel Server は次のようなイ
ンデックスを提供します。 これらのインデックスを使用すると、データ ウェアハウス
環境でのアドホック問合せのパフォーマンスを向上できます。
v ビットマップ インデックス
ビットマップ インデックスは、B ツリー インデックスの特別なバリエーションで
す。ビットマップ インデックスは、既婚と未婚の別、または性別など、種類が少な
い値のうちの 1 つを含む列のインデックスを作成する場合に使用できます。値の重
複が多いので、ビットマップ インデックスは、列が含む値ごとに圧縮したビットマ
ップを格納します。ビットマップ インデックスを使用すると、同じキーを含む行間
の距離が減少するので格納効率が向上します。
次の両方の条件に当てはまる場合にビットマップ インデックスを使用できます。
– インデックス内のキー値に、多くの重複があります。
– 表走査のパフォーマンスを向上するためにオプティマイザが使用できるインデック
スが、表内の複数の列に付いています。
v 一般化キー (GK) インデックス
GK インデックスを使用すると、式の結果、データ セットの選択、または結合された
表からのデータ セットの積を、B-tree ツリー インデックスまたはビットマップ イ
ンデックス内のキーとして格納できます。 これは、1 つまたは複数の大規模表での
特定の問合せに便利です。
GK インデックスを作成する場合は、そこに含まれるすべての表は静的表でなければ
なりません。
また、インデックス機能の効率を向上させるために、Extended Parallel Server は次の機
能をサポートしています。
v 同一の表アクセスに使用できるように複数のインデックスを自動的に結合します。
複数列インデックスを単一列インデックスと結合できます。
v スキップ走査というアクセス方法で表を読み取ります。
表の行を走査する場合、データベース サーバはインデックスが示す行だけを読み取
ります。 その場合、行がデータベース内にある順序で行を読み取ります。スキップ
走査 アクセス方法では、1 つのページが 2 度読み取られることはありません。各ペ
ージは、ランダムにではなく順番に読み取られるので、入出力リソースの要件は減少
します。スキップ走査では、インデックス列でのフィルタ処理が不要になるので、
CPU 要件も減少します。
v ハッシュ半結合を使用して、複数表結合を処理する作業を減らします。
ハッシュ半結合は、1 つの大きな (ファクト) 表が多くの小さな (次元) 表に結合され
るスター スキーマに対する問合せなどで特に便利です。ハッシュ半結合では、結合
を開始する前に、効率的に行の数をできる限り減らすことができます。
216
IBM Informix: データベース設計および実装 ガイド
データベースに対して実行する問合せの種類を解析することは、作成するインデックス
の種類を決めるためにも役立ちます。問合せのパフォーマンスを向上させるために使用
できるインデックスおよびインデックス作成方法については、「IBM Informix: パフォー
マンス ガイド 」を参照してください。
データ ウェアハウス環境での GK インデックスの使用
特定の種類の問合せを表で頻繁に使用する場合は、GK インデックスを作成すると便利
です。以下の例では、1 つまたは複数の大きな表での問合せ用に GK インデックスを作
成して使用する方法について説明しています。この例では、データベース sales_demo
の表に基づいて説明しています。
選択での GK インデックスの定義
州 "CA" となる値を戻す、sales ファクト表での典型的な問合せについて考えます。こ
のような種類の問合せのパフォーマンスを向上するために、GK インデックスを作成す
ると 1 つの SELECT 文の結果をインデックス内の 1 つのキーとして格納できます。
次の文はインデックス state_idx を作成します。インデックス state_idx は、地域デー
タによって検索を制限する問合せのパフォーマンスを向上できます。
CREATE GK INDEX state_idx ON geography
(SELECT district_code FROM geography
WHERE state_code = "CA");
データベース サーバは、州="CA" の場合に製品別、地域別、月別の収益と売り上げ数
量を戻す、次のような種類の問合せにインデックス state_idx を使用できます。データ
ベース サーバで、州 = "CA" の場合に 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);
第 11 章 次元データベースの実装 (Extended Parallel Server のみ)
217
データベース サーバは、製品の購入に $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;
218
IBM Informix: データベース設計および実装 ガイド
第 5 部 付録
© Copyright IBM Corp. 1996, 2003
219
220
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, 2003
221
本プログラムのライセンス保持者で、(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 が小売り価格として提示しているもので、現行価
格であり、通知なしに変更されるものです。卸価格は、異なる場合があります。
本書には、日常の業務処理で用いられるデータや報告書の例が含まれています。より具
体性を与えるために、それらの例には、個人、企業、ブランド、あるいは製品などの名
前が含まれている場合があります。これらの名称はすべて架空のものであり、名称や住
所が類似する企業が実在しているとしても、それは偶然にすぎません。
著作権使用許諾:
本書には、様々なオペレーティング・プラットフォームでのプログラミング手法を例示
するサンプル・アプリケーション・プログラムがソース言語で掲載されています。お客
222
IBM Informix: データベース設計および実装 ガイド
様は、サンプル・プログラムが書かれているオペレーティング・プラットフォームのア
プリケーション・プログラミング・インターフェースに準拠したアプリケーション・プ
ログラムの開発、使用、販売、配布を目的として、いかなる形式においても、IBM に対
価を支払うことなくこれを複製し、改変し、配布することができます。このサンプル・
プログラムは、あらゆる条件下における完全なテストを経ていません。従って IBM
は、これらのサンプル・プログラムについて信頼性、利便性もしくは機能性があること
をほのめかしたり、保証することはできません。お客様は、IBM のアプリケーション・
プログラミング・インターフェースに準拠したアプリケーション・プログラムの開発、
使用、販売、配布を目的として、いかなる形式においても、 IBM に対価を支払うこと
なくこれを複製し、改変し、配布することができます。
それぞれの複製物、サンプル・プログラムのいかなる部分、またはすべての派生的創作
物にも、次のように、著作権表示を入れていただく必要があります。
© (お客様の会社名) (西暦年). このコードの一部は、IBM Corp. のサンプル・プログ
ラムから取られています。 © Copyright IBM Corp. (年を入力してください。) All
rights reserved.
この情報をソフトコピーでご覧になっている場合は、写真やカラーの図表は表示されな
い場合があります。
特記事項
223
商標
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 の商標または登録商標です。
Java およびすべての Java 関連の商標およびロゴは、Sun Microsystems, Inc. の米国およ
びその他の国における商標または登録商標です。
Windows、Windows NT および Excel は、Microsoft Corporation の米国およびその他の
国における商標です。
UNIX は、The Open Group がライセンスしている米国およびその他の国における登録
商標です。
本書で言及しているその他の会社名、製品名およびサービス名はそれぞれ各社の商標ま
たは登録商標です。
224
IBM Informix: データベース設計および実装 ガイド
索引
日本語, 数字, 英字, 特殊文字の
順に配列されています。なお, 濁
音と半濁音は清音と同等に扱わ
れています。
［ア行］
アーカイブ、およびフラグメント化
78
アイコン
機能 xiv
警告
重要
xiii
xiii
製品 xiv
ヒント xiv
プラットフォーム
xiv
105
システム カタログ内の符号化
100
実行 105
自動化 106
データベース レベル 97
データベース管理者 98
ビューでの 121
ビューと 120
ビューの作成に必要な 120
表レベル 99
付与 96
ユーザと public 97
ルーチン レベル 105
列レベル 102
ANSI 対非 ANSI 6
Connect 97
Delete 99, 121
Insert 99, 121
Resource 98
Select 99, 102, 121
Update 99, 121
© Copyright IBM Corp. 1996, 2003
型階層 (続き)
146
コレクション (COLLECTION) 型
139
意味整合性 39
一時表 213
行 (ROW) 型の削除
作成 149
description
153
149
型継承、説明 149
型コンストラクタ 135
型代用性 153
一般化キー インデックス
所有権 99
型付き表
データ ウェアハウス
定義
217
結合された表での
式での 217
選択での 217
218
インデックス
一般化キー
アクセス権 99
インデックス 101
型付き表 101
言語
入れ子
行 (ROW) 型
216, 217
双方向トラバース 67
データ ウェアハウジング環境
216
名前付き行 (ROW) 型の制限
142
ビットマップ、説明 216
CREATE INDEX 文 66
オペレーショナル表 215
オンライン トランザクション処理
(OLTP) 184
オンライン ヘルプ xv
オンライン マニュアル xv
オンライン分析型処理 (OLAP) 184
［カ行］
カーソルの動作
ANSI 対非 ANSI 8
外部キー 30
外部表、データのロード 72, 78
階層
参照： 行 (ROW) 型
参照： 継承
参照： 表階層
型階層
オーバーロード ルーチン 149
型なし表からの作成 144
定義 143
参照： フラグメント表
型なし表
型付き表への変換
定義 143
144
各国語可変長文字 (NVARCHAR) 型
53
各国語文字 (NCHAR) 型 52
過渡的依存性
36
可変長文字 (CHARACTER
VARYING) 型 53
可変長文字 (VARCHAR) 型
53
可用性、フラグメント化による向上
78
環境、米国英語 (U.S. English) 以外
9
関係
オプション 16
再帰的 33
実体 12
冗長 34
接続性 16, 18
属性 22
存在の依存性 16
多重度 20
多重度の制約 16
多対多 16, 18
多対多、解決 32
データ モデルでの定義 15
必須 16
複雑な 33
マトリックスを使用して発見 16
225
関係 (続き)
入れ子にした 146
カテゴリ 135
関係におけるオプションの実体
関係における接続性
関係の解決
16
16, 18
関係における必須の実体
関係モデル
16
キャスト
167, 171
業界標準、対応
表示フォーマット
xvii
関数的依存関係 36
簡単な追加、説明 213
キー
48
101
単一 149
表階層 154
結合、修正可能なビューでの制限
118
記述子列 29
規則
表記 xii
言語アクセス権 105
コード セット
デフォルト 9
コード、サンプル、∼の規則
コード例の表記 xiv
xiv
暗黙的、定義
演算子 165
広域言語サポート (GLS)
固定小数点 47
165
起動 166, 167
行 (ROW) 型 167
組込み 165
コレクション (COLLECTION) 型
171
コレクション (COLLECTION) 型
の要素 173
削除 176
ディスティンクト型 166, 174
名前付き行 (ROW) 型 166, 171
名前なし行 (ROW) 型フィールド
170
明示的、定義 165
ユーザ定義 165, 177
CAST AS キーワード 165
description 165
行
関係モデルにおける
定義 27
行 ID 88
226
27
xiv
xi
コマンド スクリプト、データベース
の作成 69
コメントのアイコン xiii
コレクション (COLLECTION) 型
暗黙的キャスト 173
入れ子にした 139
型コンストラクタ 135
型チェック 172
キャスト 171
キャストの制限 172
異なる要素型 172
制限 140
明示的キャスト 173
要素型 135
［サ行］
再帰的関係 18, 33
細分性、ファクト表 189
参照整合性、主キーと外部キーの定
義 30
IBM Informix: データベース設計および実装 ガイド
範囲規則を使用した
description 80
次元データ モデル
作成
次元
主 29
複合 29
キー列 29
機能アイコン
キャスト
165
式ベース分散スキーム
使用 80
任意規則 81
階層構造内のアクセス権
型 149
型代用性 153
30
51
式、キャストで使用できる
均一分散 82
金額 (MONEY) 型
表示フォーマット
警告アイコン xiii
継承 149
59
時間隔 (INTERVAL) 型
説明 50
説明 47
32
説明 11
表、行、および列の定義のルール
27
外部
参照制約
データ型に関する考慮事項
行 (ROW) 型
1 対 1 16, 18
1 対多 16, 18
81
191
189
次元表 190
次元要素 189
実装する 205
小次元表 200
ファクト表 188
メジャー (基準)、定義 188
次元データベース、sales_demo 206
次元表
説明
190
属性の選択 198
システム カタログ表
アクセス権 100
syscolauth 100
sysfragexprudrdep 78
sysfragments 78
systabauth 100
sysusers 100
システム定義ハッシュ分散スキーム
使用 83
description 80
システム要件
ソフトウェア x
データベース x
事前定義データ型 129
実数 (FLOAT) 型 45
実体
オカレンス 23
住所録の例 15
選択の基準 15
属性 22
定義 12
表で表す 29
正規化 (続き)
実体 - 関係ダイアグラム
説明 23
読取り 24
第 3 正規形 36
データ モデルの
シノニム
連鎖
外部表を使用したロード
34
ルール 34, 37
8
正規形 34
整数 (INTEGER) 型
集計関数、修正可能なビューでの制
静的表 214
限 118
重要なパラグラフ、アイコン
主キー
製品アイコン xiv
制約
多重度 16
システム割当て
定義 29
複合 29
xiii
30
参照： 次元データ モデル
43
ドメインの定義 39
名前付き行 (ROW) 型の制限
142
セキュリティ
149
上位表 149
小桁実数 (SMALLFLOAT) 型 45
小桁整数 (SMALLINT) 型 43
アクセスの制限 113, 114, 120
オペレーティング システム機能
の使用 95
小次元表、説明 200
冗長な関係 34
所有権 99
挿入された値の制約 113, 119
データベース レベル アクセス権
95
所有者名の指定
ANSI 対非 ANSI
6
シリアル (SERIAL) 型
開始点のリセット 101
参照制約 59
主キーとしての 29
初期化 44
制限 131, 140, 142, 147
説明 44
表階層 159
スクラッチ表 213
スター結合スキーマ
説明 187
参照： 次元データ モデル
スマート ラージ オブジェクト
インポートとエクスポート 134
コピー用関数 134
フラグメント化 88
description 132
SB 領域の記憶域 133
SQL での対話型使用 133
SQL の制限 133
正規化
第 1 正規形 34
第 2 正規形 36
データベースをアクセス不能にす
る 95
表レベル アクセス権 102
ユーザ定義ルーチンを使用しての
95
操作データ ストア
属性
識別 21
重要な特質 22
分割不可能 22
存在の依存性 16
72
dbload ユーティリティを使用した
ロード 72
データ ウェアハウジング モデル
利点 34
68
ANSI 標準準拠データベースで
シノニムの連鎖 68
上位型
データ
184
［タ行］
第 1 正規形 34
第 2 正規形 36
第 3 正規形 36
対応
業界標準への xvii
代用性 153
多重度
関係における 20
制約 16
多対多の関係 16, 18, 32
単一継承 149
データ ウェアハウス、説明
データ マート、説明 184
データ モデル
関係型 11
関係の定義
作成 25
次元
183
15
187, 191
実体の関係
住所録の例
説明 11
12
13
属性 21
多対多の関係 18
1 対 1 の関係 18
1 対多の関係
18
データ型
各国語可変長文字 (NVARCHAR)
型 53
各国語文字 (NCHAR) 型 52
可変長文字 (CHARACTER
VARYING) 型 53
可変長文字 (VARCHAR) 型 53
行 (ROW) 型 135
金額 (MONEY) 型 47
固定小数点 47
コレクション (COLLECTION) 型
135
参照制約 59
時間隔 (INTERVAL) 型 50
小桁実数 (REAL) 型 45
小桁実数 (SMALLFLOAT) 型 45
シリアル (SERIAL) 型 44
シリアル (SERIAL) 型、表階層
159
スマート ラージ オブジェクト
132
整数 (INTEGER) 型 43
選択 40
ディスティンクト (DISTINCT) 型
131
テキスト (TEXT) 型 55
索引
227
データ型 (続き)
デフォルト値、列
バイト (BYTE) 型 (続き)
58
日時 (DATETIME) 型 49
バイト (BYTE) 型 56
導出データ、ビューにより作成され
た 114
バイナリ ラージ オブジェクト
ドキュメント ノート
(BLOB)
日付 (DATE) 型 48
日付、時間に関する 48
複合型
目 xvi
ドメイン
131
文字ラージ オブジェクト (CLOB)
型 132
10 進数 (DECIMAL) 型 46, 47
description
SQL の制限 133
ハイブリッド分散スキーム
使用 84
定義 5
ANSI 対非 ANSI 5
トランザクション ログ機能
description 80, 84
ハッシュ分散スキーム
参照： システム定義ハッシュ分
散スキーム
高速ロードのためにオフにする
44
8 バイト整数 (INT8) 型 43
ALTER TABLE 文を使用した変
73
バッファ付き 63
ANSI 対非 ANSI 6
dbload ユーティリティ
データベース
機能 63
範囲分散スキーム
使用 82
description
名前付き行 (ROW) 型
型付き表の作成 143
新規表へのデータの追加 70
デモンストレーション
sales_demo 193, 206
superstores_demo 127
命名 62
データベース レベル アクセス権
データベース管理者アクセス権
98
Connect アクセス権 97
description 97
Resource アクセス権 98
データベース管理者 (DBA) 98
ディスティンクト (DISTINCT) 型
description 130
ディスティンクト型
キャスト 166, 174
テキスト (TEXT) 型
使用 56
制限 140, 147
説明 55
デフォルト ロケール xi
キャスト 166
削除 146
使用する場合 141
制限 142
命名規則 141
列定義 145
例 140
description 140
名前なし行 (ROW) 型
制限 147
例 147
description 147
日時 (DATETIME) 型
説明 49
表示フォーマット 51
［ハ行］
排他レベル、ANSI 対非 ANSI
バイト (BYTE) 型
使用 56
IBM Informix: データベース設計および実装 ガイド
80
日付 (DATE) 型
説明 48
表示フォーマット
［ナ行］
外部データベースでのビュー
117
228
バッファ付きログ機能 63
パフォーマンス、バッファ付きログ
CREATE DATABASE 文による作
成 61
72
132
特性 28
列 39
トランザクション
8 バイト シリアル (SERIAL8) 型
更 57
データのロード
外部表 72
(BLOB) 型
名前付き行 (ROW) 型の制限
142
定義 28
134
浮動小数点 45
不透明 (OPAQUE) 型
文字 (CHAR) 型 52
140, 147
56
バイナリ ラージ オブジェクト
xv
ドキュメント ノート、プログラム項
132
制限
説明
7
49
ビットマップ インデックス、説明
216
必要性、ソフトウェア x
必要なソフトウェア x
ビュー
アクセス権 120
仮想列 118
型付き 115
行の削除 118
作成 114
修正 118
修正の制限 118
重複行の更新 118
定義の変更時の反映 120
に行を挿入 119
表示されない列に挿入された
NULL 119
ベースが削除されると削除される
117
ベースの変更の反映 117
description 113
ビュー (続き)
フィールド、行 (ROW) 型で
WITH CHECK OPTION キーワー
ドの使用 119
表
複合データ型
アクセス権
99
インデックス、作成 66
外部キー、定義 30
形なし表への変換
記述子列 29
削除 66
実体を表す 29
主キー
表の作成 64
複合キー、定義
表階層
使用 84
範囲 80
使用
134
82
フラグメント数の変更
浮動小数点 45
不透明 (OPAQUE) 型
ラウンド ロビン
使用 82
89
80
並行性
166
description 131
フラグメント
フラグメント数の変更
89
変更 91, 93
description 77
フラグメント化
シリアル (SERIAL) 型と 8 バイ
ト シリアル (SERIAL8) 型の値
44
フラグメント化の向上
ヘルプ xv
ボールド体 xii
78
ゴール 78
29
所有権 99
データのロード
名前、シノニム
144
分散スキーム (続き)
副表 149
キャスト
144
型なしから型付きへの変換
関係モデル 27
キー列 29
140
副型 149
複合キー 29
再初期化 89
式、評価方法 82
スマート ラージ オブジェクトの
72
67
88
バックアップおよび復元の操作
78
29
新しい表の追加 160
継承されたプロパティ
155
シリアル (SERIAL) 型 159
定義 155
トリガ 159
表の動作の修正 158
description 154
表継承、定義 154
標準永続表
説明 215
変更 215
表へのデータの追加 70
表名のシノニム 67
表レベル アクセス権
アクセス権 99
定義と使用 99
Alter アクセス権 101
Index アクセス権 101
References アクセス権 101
ヒント アイコン xiv
ブールデータ型 52
ファクト表
細分性 189
細分性の決定 193
説明 188
複数のコサーバの間での 79
分散スキームのタイプ 79
ログ 79
DB スライス役割
79
description 77
フラグメント表
作成 84
修正 89
1 つのフラグメント化されていな
い表からの作成 87
フラグメント表の修正 89
プラットフォーム アイコン xiv
プログラム グループ
ドキュメント ノート xvi
リリース ノート xvi
分割不可能な属性 22
分散スキーム
式ベース 80
使用 80
任意規則を使用した 81
範囲規則を使用した 81
システム定義ハッシュ 80
使用 83
定義 77
ハイブリッド 80
［マ行］
マシン ノート xv
マニュアル、種類 xv
ドキュメント ノート
マシン ノート xv
xv
リリース ノート xv
マルチセット (MULTISET) 型のコレ
クション (COLLECTION) 型 138
モード ANSI キーワード、ログ機能
63
文字 (CHAR) 型 52
文字 (CHAR) 型フィールド長
ANSI 対非 ANSI 7
文字ラージ オブジェクト (CLOB) 型
説明 132
名前付き行 (ROW) 型の制限
142
SQL の制限 133
［ヤ行］
ユーザ定義キャスト
データ型間での 174
ユーザ定義データ型
キャスト 166
description 130
ユーザ定義ルーチン
アクセス権の付与 105
セキュリティの目的 95
索引
229
ユーティリティ プログラム
dbload 73, 205, 212
要素型 135
ロケール
ラウンド ロビン分散スキーム
使用 82
description 80
リスト (LIST) 型のコレクション
(COLLECTION) 型 138
リポジトリ、説明 184
リリース ノート xv
排他レベル
1 対多の関係 16, 18
10 進数 (DECIMAL) 型
バッファ付きログ機能
表アクセス権 99
固定小数点
制限 131, 140, 142, 147
説明 44
表階層 159
ルーチン オーバーロード 152
ルーチン レベル アクセス権 105
ルーチン分析 153
列
145
147
フラグメント表の修正 89
列レベル アクセス権 102
ロール
アクセス権の付与 108
定義 107
命名ルール 107
CREATE ROLE 文 108
SET ROLE 文 109
sysroleauth システム カタログ表
109
sysusers システム カタログ表
109
ロウ永続表
説明 214
変更 215
ログ機能、タイプ 63
ログ付き表
作成 205, 212
特性 212
ログなし表
作成 205, 212
特性 212
8 バイト整数 (INT8) 型
9.4 機能、概要 xii
9.4 の機能 xii
43
A
ALTER FRAGMENT の MODIFY 節
91
ALTER FRAGMENT 文
ADD 節 90
ATTACH 節 93
DETACH 節 93
DROP 節 91
INIT 節 89
MODIFY 節 91
ALTER TABLE 文
形なし表への変換 144
型付き表への変換 144
に対するアクセス権 101
表タイプの変更 215
列のデータ型の変更 57
Alter アクセス権 101
ANSI 標準準拠
レベル xvii
ANSI 標準準拠データベース
アクセス権 6
エスケープ文字 7
カーソルの動作 8
作成する理由 4
識別 8
所有者名の指定 6
IBM Informix: データベース設計および実装 ガイド
6
7
63
文字 (CHAR) 型フィールド長
47
10 進数 (DECIMAL) 型
SQLCODE 8
浮動小数点 46
8 バイト シリアル (SERIAL8) 型
参照制約 59
初期化 44
xvi
リレーショナル データ モデルの作
成 25
5
トランザクション ログ機能
1 対 1 の関係 16, 18
リリース ノート、プログラム項目
230
説明 4
トランザクション
［数字］
［ラ行］
定義 27
名前付き行 (ROW) 型
名前なし行 (ROW) 型
ANSI 標準準拠データベース (続き)
xi, 9
7
7
C
Codd, E. F. 37
Connect アクセス権
97
CREATE DATABASE 文
コマンド スクリプト 69
次元データ モデル 205
リレーショナル データ モデル
61
CREATE FUNCTION 文
キャスト登録の例 179
CREATE INDEX 文 66
CREATE TABLE 文
コマンド スクリプト 69
説明 64
FRAGMENT BY EXPRESSION
節を使用した 81
CREATE VIEW 文
使用 114
制限 116
WITH CHECK OPTION キーワー
ド 119
D
DB スライス、フラグメント化での
役割 79
DB 領域
選択 62
DB スライス、フラグメント化で
の役割 77
DBA
参照： データベース管理者
DBDATE 環境変数 49
dbload ユーティリティ、データのロ
ード 72
DBMONEY 環境変数
DBTIME 環境変数
SB 領域
フラグメント化スキーマの
定義
Delete アクセス権
アクセス権
69
DELETE 文
アクセス権 97
に対するアクセス権
制限 116
ISO 8859-1 コード セット
DROP CAST 文、使用
176
E
N
SQL コード xiv
SQLCODE、ANSI 対非 ANSI
NOT NULL キーワード、CREATE
TABLE 文で使用 64
stores_demo データベース xi
superstores_demo データベース
NULL 値
主キーの制約事項
127
sysfragexprudrdep システム カタログ
表 78
29
定義 57
en_us.8859-1 ロケール xi
EXISTS キーワード、条件副問合せ
120
限 116
P
G
GK インデックス
参照： 一般化キー インデックス
GL_DATETIME 環境変数 52
GRANT 文
データベース レベル アクセス権
96
表レベル アクセス権 98
GROUP BY キーワード、修正可能な
ビューでの制限 118
PUBLIC キーワード、すべてのユー
ザに付与されるアクセス権 97
R
References アクセス権 101
Resource アクセス権 98
REVOKE 文、アクセス権の付与
I
xii
xi,
U
UNION キーワード
修正可能なビューでの制限
118
ビュー定義での 117
UNIQUE キーワード
修正可能なビューでの制限 118
CREATE TABLE 文での制約 64
Update アクセス権
定義 99
ビューを使用した 121
UPDATE 文
に対するアクセス権 97, 99
ビューへ適用 118
96
W
S
Index アクセス権 101
INFORMIXDIR/bin ディレクトリ
64
ontape ユーティリティ 64
ORDER BY キーワード、ビューの制
finderr ユーティリティ xvi
FRAGMENT BY EXPRESSION 節
81
8
sysfragments システム カタログ表
78
syssyntable システム カタログ表 67
O
ON アーカイブ 64
ondblog ユーティリティ
F
修正可能なビューでの 118
に対するアクセス権 97, 99
ビューでの 120
SET コレクション (COLLECTION)
型 137
xi
99
ビューへ適用 118
DISTINCT キーワード、修正可能な
ビューでの制限 118
121
SELECT 文
97, 99
ビューを使用した 119
INTO TEMP キーワード、ビューの
99, 121
99
ビューを使用した
列レベル 102
INSERT 文
データベースの作成
UNLOAD 文 72
133
Select アクセス権
89
ALTER FRAGMENT 89
Insert アクセス権 99, 121
48
52
DB-Access
での使用
INIT 節
sales_demo データベース
作成 206, 211
データ ソース 207
データ モデル 193
ロード 209
WHERE キーワード、データ制約の
強制 120
WITH CHECK OPTION キーワー
ド、CREATE VIEW 文 119
索引
231
X
X/Open 準拠レベル
xvii
［特殊文字］
::、キャスト演算子
232
165
IBM Informix: データベース設計および実装 ガイド
򔻐򗗠򙳰
Printed in Japan
GB88-8634-00
򔻐򗗠򙳰
IBM Informix
Spine information:
データベース設計および実装 ガイド
バージョン 9.4