Informix Guide to Database Design and Implementation

Informix Guide to
Database Design and
Implementation
®
Informix Dynamic Server, Version 7.3
Informix Dynamic Server with Advanced Decision Support and Extended Parallel Options, Version 8.2
Informix Dynamic Server, Developer Edition, Version 7.3
Informix Dynamic Server, Workgroup Edition, Version 7.3
September 1998
Part No. 000-4364-8
Informix のソフトウェアおよびユーザ・マニュアルは「現状のまま」提供され、商品性の黙示的な保証およ
び特定の目的への適合性の黙示的な保証など、明示的か黙示的かを問わず、いかなる種類の保証も提供され
ません。Informix のソフトウェアおよびユーザマニュアルの品質と性能についてのリスクは、すべて、お客
様の負担です。Informix のソフトウェアおよびユーザ・マニュアルに欠陥があった場合には、すべての必要
なサービス、修理または修正のための費用は、すべて、
（Informix または Informix の正規取扱店ではなく）お
客様の負担となります。いかなる場合においても、Informix は Informix または Informix の正規代理店そうし
た損害の可能性を知らされていた場合であっても、Informix のソフトウェアまたはユーザ・マニュアルの使
用または使用不能から生じた、利益の喪失、節約の喪失あるいは他の偶発的または結果的な損害など、いか
なる損害についても責任を負わず、また第三者からのいかなる請求についても責任を負いません。加えて、
Informix は、厳格責任あるいは Informix の過失に基づく請求で Informix のソフトウェアまたはユーザ・マニュ
アルの使用または使用不能から生じた一切の請求についても責任を負いません。管轄地によっては、黙示的
な保証の排除を認めていない管轄地もあり、その場合には上記の排除の全部または一部が適用されないこと
もあります。この保証は、お客様に特定の法的な権利を付与するものですが、管轄地によって異なる、その
他の権利がお客様に認められることもあります。
すべての権利は Informix に保留されます。本書についての著作権で保護される本書のいかなる部分も、グ
ラフィック、電子的方法、あるいは、コピー機、記録装置、テープ、情報記憶媒体、検索システムなどの機
械的方法など、形態あるいは方法を問わず、発行元の許可を得ないで、複製または使用することはできませ
ん。
発行者： INFORMIX Press
Informix Software, Inc.
4100 Bohannon Drive
Menlo Park, CA 94025-1032
Answers OnLine、INFORMIX、Informix、Illustra、C-ISAM、DataBlade、Dynamic Server、Gateway および
NewEra は Inormix Software の登録商標です。
その他の名前やマークはすべて、それぞれの所有者の登録商標または商標である可能性があります。
権利制限
Informix のソフトウェアおよび付随する資料は、制限された権利のもとに提供されます。政府による使用、
複製、または開示については、DFARS 252.227-7013 の Rights in Technical Data and Computer Software Clause
( 技術データおよびコンピュータ・ソフトウェアについての権利）に関するサブパラグラフ (c)(1)(ii) または
48CFR52.227-19 の Commercial Computer Software-Restricted Rights( 商用コンピュータ・ソフトウェア - 制限さ
れた権利）に関するサブパラグラフ (c)(1) および (2) の適用がある部分（および政府契約に規定されたその他
の適用のライセンス規定）に限定された制限が適用されます。
Copyright © 1981-1998 by Informix Software, Inc.
ii
Informix Guide to Database Design and Implementation
目次
目次
序
このマニュアルについて . . . . . .
対象ユーザ . . . . . . .
ソフトウェアの要件 . . . . .
使用するロケール . . . . .
デモンストレーションデータベース
. . . .
. . .
. . .
. . .
. . .
序3
序4
序4
序5
序5
新機能 . . . . . . . . . . . . . . . . . . . . . . .
バージョン 7.3 の新機能 . . . . . . . . . . . . .
バージョン 8.2 の新機能 . . . . . . . . . . . . .
序6
序6
序6
表記上のきまり . . . .
文字の表記 . . .
アイコンの表記 . .
サンプルコードの表記
.
.
.
.
.
.
.
.
.
.
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
関連マニュアル . . . . . . . . . . . . . . .
オンライン マニュアル . . . . . . . . .
ペーパーマニュアル . . . . . . . . . .
エラー メッセージ ファイル . . . . . . .
ドキュメントノート、リリースノート、マシンノート
参考文献 . . . . . . . . . . . . .
.
.
.
.
.
.
業界標準への準拠
.
.
.
.
.
.
. . 序7
.
序8
.
序9
. 序 11
.
.
.
.
.
.
. .
.
.
.
.
.
序 12
序 12
序 13
序 13
序 14
序 15
. .
.
. .
.
. . 序 16
. .
.
. .
.
. .
1-3
ANSI 標準準拠データベースの使用法 . . . . . . . . . . . .
データベースの ANSI 標準準拠への設定 . . . . . . . .
既存のデータベースが ANSI 標準準拠であるかの判断 . . . .
1-4
1-5
1-5
セクション I
第1章
.
.
.
.
.
.
.
.
.
.
. .
. .
.
. .
.
. .
データベース設計と実装の基礎
データベースの設計
データベースのデータ モデルの選択 . .
.
. .
ANSI 標準準拠のデータベースと ANSI 標準準拠でない
データベースとの相違点. . . . . . . . . .
ご使用のデータベース向け専用言語環境の使用法 .
第2章
.
. .
1-10
. .
.
. .
.
. .
. .
.
. .
2-3
実体 - 関係データモデルの概要
. .
.
. .
.
. .
. .
.
. .
2-4
. .
. .
. .
. .
. .
. .
. .
.
2-5
2-5
2-9
2-17
データオブジェクトの図式化 . . . . . . . . . . . . . . .
E-R 図の読み方 . . . . . . . . . . . . . . .
住所録の例 . . . . . . . . . . . . . . . .
2-19
2-20
2-21
E-R データオブジェクトの関係構造体への変換 . . . . . . . . .
表、行、列の定義 . . . . . . . . . . . . . .
表のキーの決定 . . . . . . . . . . . . . . .
2-22
2-23
2-25
関係の解決 . . . . . . . . . . . . . . . . . . . . .
m:n 関係の解決 . . . . . . . . . . . . . . .
その他の特別な関係の解決 . . . . . . . . . . .
2-29
2-29
2-30
データモデルの正規化 . . . . . . . . . .
第 1 正規形 . . . . . . . . . . . . .
第 2 正規形 . . . . . . . . . . .
第 3 正規形 . . . . . . . . . . .
正規化ルールのまとめ . . . . . . . .
2-31
2-32
2-34
2-34
2-35
.
. .
. .
. .
. .
. . .
. . .
. . .
. .
. . .
. . .
. .
. .
. .
. . . .
. . . .
. . .
. . .
. . .
データ型の選択
.
.
.
.
.
.
.
.
.
.
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
. .
. .
. .
. .
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . . .
. . . .
. . . .
. . . .
. . . .
.
.
.
.
. .
.
.
.
.
.
.
.
.
.
. .
.
.
.
.
3-3
3-4
3-23
3-23
3-24
.
.
.
.
.
. .
.
.
.
.
4-3
4-4
4-6
4-8
4-9
リレーショナルデータモデルの実装
データベースの作成 . . . . . . .
CREATE DATABASE 文の使用方法
CREATE TABLE 文の使用方法 .
表名でのシノニムの使用方法 . .
シノニム連鎖の使用方法 . . .
iv
. .
データモデルを作成する理由 . .
ドメインの定義 . . . . .
データ型 . . . . .
NULL 値 . . . . .
デフォルト値 . . .
検査制約 . . . . .
第4章
. .
リレーショナルデータモデルの作成
主なデータオブジェクトの識別と定義 . . .
実体の識別 . . . . . . . . . . .
関係の定義 . . . . . . . . . . .
属性の識別 . . . . . . . . .
第3章
1-6
Informix Guide to Database Design and Implementation
.
.
.
.
.
コマンドスクリプトの使用方法.
データの初期入力. . . . .
第5章
. . .
. . .
. . .
. . .
. . .
. . .
.
.
4-11
4-12
断片化戦略
断片化とは . . . . . . . . . . . . . . . . . . .
Dynamic Server with AD and XP Options の断片化の機能強化
断片化を使用する理由 . . . . . . . . . . .
断片化の責任者 . . . . . . . . . . . . .
断片化とログ . . . . . . . . . . . . . .
. . .
. .
. .
. .
. .
表断片化に対する分散スキーム . . . . . . . . . . . .
ラウンドロビン分散スキーム . . . . . . . . . .
式に基づいた分散スキーム . . . . . . . . . . .
システム定義ハッシュ分散スキーム . . . . . . . .
ハイブリッド分散スキーム . . . . . . . . . . .
データベース サーバが検索からフラグメントを除去できる場合
.
.
.
.
.
.
.
5-3
5-6
5-6
5-8
5-8
5-9
5-11
5-11
5-13
5-14
5-15
断片化された表の作成 . . . . . . . . . . . . . . . . . . 5-26
断片化された表を新たに作成する . . . . . . . . . . 5-27
断片化されていない表からの断片化された表の作成. . . . . 5-28
断片化された表の更新 . . . . . . . . . . . . . . . . . . 5-30
断片化戦略の変更. . . . . . . . . . . . . . . 5-30
一時表の断片化 . . . . . . . . . . . . . . . . . . . . 5-37
Dynamic Server with AD and XP Options の一時表の断片化 . . . 5-37
表インデックスの断片化
添付インデックス.
独立インデックス.
行識別子 . . .
.
.
.
.
.
.
.
.
.
. . . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
.
.
.
.
.
.
.
.
. . .
. .
. .
. .
5-39
5-39
5-40
5-41
断片化された表に格納されているデータへのアクセス . . . . . . 5-42
行識別子の代わりに主キーを使用する. . . . . . . . . 5-42
セクション II
第6章
データ ウェアハウジング
次元データモデルの作成
データ ウェアハウスの概要 . . . . . . . . . . . . . . . .
次元データベースを作成する理由 . . . . . . . . . .
次元データとは . . . . . . . . . . . . . . .
6-4
6-5
6-6
次元データ モデルのコンセプト . . . . . . . . . . . . . . 6-9
ファクト表. . . . . . . . . . . . . . . . . 6-11
データ モデルの次元 . . . . . . . . . . . . . . 6-12
目次
v
次元データ モデルの作成 . . . . . .
ビジネス プロセスの選択 . . . .
ビジネス プロセスの要約 . . . .
ファクト表の細分性の決定 . . .
次元と階層の明確化 . . . . .
ファクト表のメジャー ( 基準 ) の選択
正規化の阻止 . . . . . . .
次元表の属性の選択 . . . . .
第7章
.
.
.
.
.
.
.
.
. . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
.
.
.
.
.
.
.
6-15
6-16
6-16
6-18
6-20
6-22
6-25
6-26
次元データ モデルの共通する問題の処理 . . . . . . .
次元表の属性数を最低限に抑える . . . . . .
時々変更する次元の処理 . . . . . . . . .
スノーフレーク スキーマの使用 . . . . . . .
.
.
.
.
.
.
.
.
. .
.
.
.
6-28
6-28
6-30
6-32
. .
.
.
.
.
.
.
7-3
7-3
7-4
7-6
7-9
7-11
7-12
Dynamic Server with AD and XP Options のログ付き表とログなし表 . .
表の種類の選択 . . . . . . . . . . . . . . .
表の種類の切替え . . . . . . . . . . . . . .
7-13
7-14
7-18
データ ウェアハウス環境のインデックス . . . . . . . . . . .
データ ウェアハウス環境での GK インデックスの使用 . . .
7-18
7-20
多次元データモデルの実装
次元データベースの実装 . . . . . . . . . . . . . .
CREATE DATABASE 文の使用 . . . . . . . . .
CREATE TABLE 文を使用した次元表およびファクト表の作成
データ ソースからデータベースへのデータのマッピング .
次元データベースへのデータのロード . . . . . . .
コマンド ファイルを使用したデータベース sales_demo の作成
次元データベースのテスト . . . . . . . . . .
セクション III データベースの管理
第8章
データベースサーバのアクセス権の付与と制限
データベースへのアクセスの制御 . . . . . . . . . . . . .
機密データの保護 . . . . . . . . . . . . . .
アクセス権の付与 . . . . . . . .
データベースレベルアクセス権 .
所有者の権限 . . . . . .
表レベルアクセス権 . . . .
列レベルアクセス権 . . . .
プロシジャレベルアクセス権 . .
アクセス権の自動化 . . . .
vi
Informix Guide to Database Design and Implementation
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
.
.
.
.
.
.
8-4
8-4
8-5
8-5
8-7
8-8
8-10
8-12
8-13
ストアドプロシジャによるデータへのアクセスの制御
データの読込みの制限 . . . . . . . .
データへの変更の制限 . . . . . . . .
データへの変更の監視 . . . . . . . .
オブジェクト作成の制限. . . . . . . .
.
.
.
.
. .
.
.
.
.
.
.
.
.
.
. . .
. .
. .
. .
. .
8-17
8-18
8-19
8-20
8-21
ビューの使用 . . . . . . . . . . . . . . . . . . . . . 8-22
ビューの作成 . . . . . . . . . . . . . . . . 8-23
ビューを用いたデータの変更 . . . . . . . . . . . 8-26
アクセス権とビュー . . . . . . . . . . . . . . . . . . 8-30
ビューの作成時のアクセス権 . . . . . . . . . . . 8-30
ビューを使用するときのアクセス権 . . . . . . . . . 8-31
索引
目次
vii
序
序
このマニュアルについて . . . .
対象ユーザ . . . . . . .
ソフトウェアの要件 . . . .
使用するロケール . . . . .
デモンストレーションデータベース
新機能 . . . . . . . .
バージョン 7.3 の新機能 .
バージョン 8.2 の新機能 .
.
.
.
.
.
. . .
. . .
. . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . .
. . .
. . .
表記上のきまり . . . . . . . . . . .
文字の表記 . . . . . . . . . . .
アイコンの表記 . . . . . . . . . .
コメントアイコン . . . . . . . .
機能と製品とプラットフォームのアイコン.
準拠アイコン . . . . . . . . .
サンプルコードの表記 . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . .
. . .
. . .
. . .
. . .
. . .
. .
. .
. .
.
.
.
.
.
.
.
序
序
序
序
序
3
4
4
5
5
序 6
序 6
序 6
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 序 7
. 序 8
. 序 9
. 序 9
. 序 10
. 序 11
. 序 11
関連マニュアル . . . . . . . . . . . . .
オンライン マニュアル . . . . . . . . . .
ペーパーマニュアル . . . . . . . . . .
エラー メッセージ ファイル . . . . . . . .
ドキュメントノート、リリースノート、マシンノート
参考文献 . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
業界標準への準拠
. .
. .
. . .
. . .
. . .
. . .
序
序
序
序
序
序
12
12
13
13
14
15
. . 序 16
序 2 Informix Guide to Database Design and Implementation
この章では、このマニュアルで提供する情報の概要とそこで使用されている表記の
規約について説明します。
このマニュアルについて
このマニュアルには、Informix データベースの設計、実装、管理に役立つ情報が書か
れています。データベース設計のさまざまなアプローチを実例で示したデータ モデ
ルを収録しているほか、構造化問合せ言語 (SQL) を使用した、データベースの実装
方法および管理方法について説明しています。
構造化問合せ言語 (SQL) を Informix で実装する方法を説明したマニュアルは複数あ
りますが、このマニュアルはそのうちの一つです。このマニュアルでは、SQL デー
タ定義文でデータベースを実装する方法を説明します。
『Informix Guide to SQL:
Tutorial』では、SQL の基本的なものや高度なものを使用して、データベースの
データにアクセスし、このデータを操作する方法を説明しています。また、
『Informix Guide to SQL: Syntax』には、SQL およびストアド プロシジャ言語 (SPL) の
全構文についての説明が示されています。
『Informix Guide to SQL: Reference』では、
SQL 文以外で SQL に関わるレファレンス情報が提供されます。
序 3
対象ユーザ
対象ユーザ
このマニュアルは、次のユーザを対象に書かれています。
■
データベース管理者
■
データベース サーバ管理者
■
データベース アプリケーション プログラマ
このマニュアルでは、読者に次の知識と経験があるものと想定しています。
■
使用しているコンピュータとオペレーティング システム、およびそのオペ
レーティング システムが提供するユーティリティについての実践的な知識
■
リレーショナル データベースを使用して作業した経験またはデータベース
概念の理解
■
コンピュータ プログラミングの経験
リレーショナル データベース、SQL、またはオペレーティング システムに関する経
験が豊富でない場合、それを補うためのマニュアルの一覧については、使用してい
るデータベース サーバの『Getting Started』マニュアルを参照してください。
ソフトウェアの要件
このマニュアルでは、データベース サーバとして、次の製品のどれかを使用してい
ることを前提としています。
序
■
Informix Dynamic Server バージョン 7.3
■
Informix Dynamic Server with Advanced Decision Support and Extended Parallel
Options バージョン 8.2
■
Informix Dynamic Server Developer Edition バージョン 7.3
■
Informix Dynamic Server Workgroup Edition バージョン 7.3
4 Informix Guide to Database Design and Implementation
使用するロケール
使用するロケール
Informix 製品は、数多くの言語、文化、およびコード セットをサポートしていま
す。文化の違いに基づく情報はすべて、広域言語サポート (GLS) ロケールという単
一の環境にまとめられています。
このマニュアルでは、デフォルト ロケールの en_us.8859-1 を使用していることを前
提としています。このロケールは、日付、時刻、および通貨に関しては米国英語形
式の表記法をサポートしています。さらに、このロケールは、ISO 8859-1 コード
セットをサポートしています。このコード セットには、ASCII コード セット以外に
も、é、è、ñ などの数多くの 8 ビット文字が含まれています。
データまたは SQL 識別子でデフォルト以外の文字を使用する場合や、デフォルト
以外の文字データ照合規則に従う場合は、デフォルト以外の適切なロケールを指定
する必要があります。
デモンストレーションデータベース
Informix データベースサーバ製品付属の DB-Access ユーティリティには、デモンス
トレーションデータベース stores7 が入っています。これは、架空のスポーツ用品卸
売店に関する情報が収められたデータベースです。DB-Access とともに提供される
SQL スクリプトを使用すると、sales_demo と呼ばれる第 2 のデータベースを導出す
ることができます。このデータベースは、データ ウェアハウス アプリケーション
の次元スキーマを説明するものです。デモンストレーションアプリケーションを構
成するサンプルのコマンドファイルも含まれています。
このマニュアル内のほとんどの例は、デモンストレーションデータベース stores7 に
基づいています。
『Informix Guide to SQL: Reference』の付録 A に、データベース
stores7 についての詳しい説明と内容の一覧があります。
デモンストレーション データベースのインストールに使用するスクリプトは、
UNIX プラットフォームでは、ディレクトリ $INFORMIXDIR/bin にあり、
Windows NT プラットフォームでは、ディレクトリ %INFORMIXDIR%¥bin にありま
す。デモンストレーション データベース stores7 の構築方法についての詳しい説明
は、
『DB-Access User Manual』を参照してください。データベース sales_demo の構
築方法の説明は、第 7 章「多次元データモデルの実装」を参照してください。
序 5
新機能
新機能
データベース サーバの新しい機能のうち、このマニュアルで取り上げるものについ
ては、次に挙げる章で説明されています。新しい機能を包括した一覧については、
ご使用のデータベース サーバのリリース ノートを参照してください。
バージョン 7.3 の新機能
Informix Dynamic Server バージョン 7.3 の新機能のほとんどは、次の 5 つに主に分類
されます。
■
信頼性、可用性、および保守性
■
パフォーマンス
■
Windows NT 固有の機能
■
アプリケーションの移行
■
管理容易性
これらの追加機能は、接続、レプリケーションおよび光ディスク記憶サブシステム
に影響を与えます。
このマニュアルでは、CREATE VIEW 文の機能拡張について説明します。これはア
プリケーションの移行に関連する機能です。
バージョン 8.2 の新機能
このマニュアルには、Dynamic Server with AD and XP Options バージョン 8.2 で実装
された、次の新機能についての情報が書かれています。
序
■
複数のコンピュータでの表データの断片化機能の強化
■
データ ウェアハウス アプリケーションをサポートするインデックス機能
の強化
■
広域言語サポート (GLS)
6 Informix Guide to Database Design and Implementation
表記上のきまり
このマニュアルでは、Dynamic Server with AD and XP Options バージョン 8.1 で導入
された次の機能についても説明しています。
■
複数のコンピュータ間での表データの断片化
■
複数のコンピュータで使用するための新結合方式
■
ログなし表
■
ハイパフォーマンスのロードおよびアンロードのための外部表
■
格納領域の集中型管理のための DB スライス
■
CREATE VIEW 文の機能拡張
表記上のきまり
ここでは、このマニュアルで使用されている表記上のきまりを説明します。この表
記上のきまりを覚えておくと、このマニュアルや他の Informix マニュアルの内容を
理解しやすくなります。
以下のような表記上のきまりがあります。
■
文字の表記
■
アイコンの表記
■
サンプルコードの表記
序 7
文字の表記
文字の表記
このマニュアルでは、画面表示、コマンド構文などに以下のような標準的な表記を
使用しています。
表記
意味
computer
製品が表示する情報や、ユーザが入力する情報は、サンセリ
フフォントで表記します。
KEYWORD
キーワードはすべて、大文字のセリフ フォントで表記します。
♦
この記号は、機能固有の情報、プラットフォーム固有の情報、
または準拠固有の情報が表内または項内に現れた場合に、そ
の情報の終わりを示します。
➞
この記号は、メニュー項目を示します。たとえば、
「Tools➞Options を選択します」は、Tools メニューから
Options 項目を選択することを意味します。
ヒント : テキストを「入力」するように指示されている場合は、入力後に Return
キーを押してください。テキストを「タイプ」するように指示されている場合は、
Return キーを押す必要はありません。
序
8 Informix Guide to Database Design and Implementation
アイコンの表記
アイコンの表記
このマニュアルには、いろいろなアイコンを伴ったテキストがあります。ここで
は、これらのアイコンについて説明します。
コメントアイコン
コメントアイコンには、警告、重要な表記、あるいはヒントを示します。この情報
は常に太字で印刷されています。
アイコン
説明
警告アイコンは、重要な指示、注意、情報を示します。
重要アイコンは、説明されている機能や操作に関する、
重要な情報を示します。
ヒントアイコンは、説明されている機能に関する、追加
情報や省略方法を示します。
序 9
アイコンの表記
機能と製品とプラットフォームのアイコン
機能製品とプラットフォームのアイコンは、そのパラグラフが機能製品またはプ
ラットフォーム固有の情報を説明していることを表しています。
アイコン
AD/XP
E/C
GLS
IDS
UNIX
W/D
WIN NT
説明
Dynamic Server with AD and XP Options に固有の情報を示し
ます。
INFORMIX-ESQL/C 製品に固有の情報を示します。
Informix 広域言語サポート (GLS) の機能に関連する情報
を示します。
Dynamic Server、およびその各エディションに固有の情報
を示します。ただし、このアイコンがついた項は、
Informix Dynamic Server のみに当てはまり、Informix
Dynamic Server、Workgroup Edition と Developer Edition に
は当てはまらないことがあります。そのような場合は、
その旨明示されます。
UNIX プラットフォームに固有の情報を示します。
Informix Dynamic Server、Workgroup Edition と Developer
Edition に固有の情報を示します。
Windows NT 環境に固有の情報を示します。
これらのアイコンは、表内の行や、一つまたは複数のパラグラフ、あるいは項全体
に適用されます。あるアイコンが項の見出しの隣に表示されている場合、示されて
いる機能、製品、またはプラットフォームに当てはまる情報は、それ以後の見出し
のうち、そのアイコンの付いた見出しと同じレベルまたはそれ以上のレベルの見出
しで終わりになります。記号 ♦ は、機能固有の情報や、製品固有の情報、または
プラットフォーム固有の情報が表内の行または項内のパラグラフ群に現れる場合
に、その情報の終わりを示します。
序
10
Informix Guide to Database Design and Implementation
サンプルコードの表記
準拠アイコン
準拠アイコンは、標準に準拠するための指針を含んでいるパラグラフを示します。
アイコン
ANSI
+
X/O
説明
ANSI 標準準拠データベースに固有の情報を示します。
ANSI SQL-92 エントリ レベルの標準 SQL に対する
Informix の拡張機能である情報を示します。
X/Open に準拠する機能を示します。
これらのアイコンは、表内の行や、一つまたは複数のパラグラフ、あるいは項全体
に適用されます。あるアイコンが項の見出しの隣に表示されている場合、準拠の情
報は、それ以後の見出しのうち、そのアイコンの付いた見出しと同じレベルまたは
それ以上のレベルの見出しで終わりになります。記号 ♦ は、準拠の情報が表内の
行または項内のパラグラフ群に現れる場合に、その情報の終わりを示します。
サンプルコードの表記
このマニュアルでは SQL コードを使用した例が多数示されています。特に明記さ
れている場合を除き、このコードはほとんどの Informix アプリケーション開発支援
ツールに対応しています。SQL 文のリストのみが例示されている場合、文の区切り
にセミコロン (;) は指定されていません。
たとえば、次の例のようなコードになっています。
CONNECT TO stores7
.
.
.
DELETE FROM customer
WHERE customer_num = 121
.
.
.
COMMIT WORK
DISCONNECT CURRENT
序
11
関連マニュアル
この SQL コードを特定の製品で使用するには、その製品用の構文規則を適用する
必要があります。たとえば、DB-Access の問合せ言語オプションを使用している場
合は、複数の文はセミコロンで区切る必要があります。SQL API を使用している場
合は、各文の先頭で EXEC SQL を使用し、各文の終わりでセミコロン ( または他の
適切な区切り記号 ) を使用する必要があります。
ヒント : コード例中の省略点の部分には、実際のアプリケーションではもっと多く
のコードが追加されますが、ここでの説明には必要ないので省略してあることを示
しています。
特定のアプリケーション開発支援ツールまたは SQL の API での SQL 文の使用につ
いての詳細は、ご使用の製品のマニュアルを参照してください。
関連マニュアル
関連情報については、次の種類のマニュアルを参照してください。
■
オンライン マニュアル
■
ペーパー マニュアル
■
エラー メッセージ ファイル
■
ドキュメント ノート、リリース ノート、マシン ノート
■
参考文献
オンライン マニュアル
Informix 製品には、電子形式の Informix マニュアルが格納された Answers OnLine CD
が添付されています。このマニュアルは、インストールすることも、CD に直接ア
クセスすることもできます。オンライン マニュアルのインストール、読取り、およ
び印刷の各方法については、Answers OnLine に添付されているインストール説明書
を参照してください。
序
12
Informix Guide to Database Design and Implementation
ペーパーマニュアル
ペーパーマニュアル
Informix Dynamic Server マニュアル セットでは、Informix Dynamic Server、その SQL
の実装、およびその関連するアプリケーション プログラミング インターフェイス
について説明しています。さらに、Informix Dynamic Server キットには、各キット
の各種コンポーネントをサポートするマニュアルが含まれています。
Informix Dynamic Server マニュアルセットの各マニュアルと Informix Dynamic Server
キットのマニュアルの概要については、
『Getting Started with Informix Dynamic
Server』を参照してください。
エラー メッセージ ファイル
Informix ソフトウェア製品では、Informix エラー メッセージとその対処方法がすべ
て格納されたテキスト ファイル提供しています。これらのエラー メッセージにつ
いての詳細は、Answers OnLine にある『Informix Error Messages』を参照してくださ
い。
UNIX
UNIX でこれらのエラー メッセージを読むには、次のコマンドを使用します。
コマンド
説明
finderr
エラー メッセージをオンラインで表
示します。
rofferr
エラー メッセージを出力用に整形処
理を行います。
♦
WIN NT
Windows NT でエラー メッセージやその対処方法を読むには、Informix Find Error
ユーティリティを使用します。このユーティリティを表示するには、タスク バーか
ら [ スタート ] ➞ [ プログラム ] ➞ [Informix] を選択してください。 ♦
序
13
ドキュメントノート、リリースノート、マシンノート
ドキュメントノート、リリースノート、マシンノート
ペーパー マニュアルのほか、このマニュアルの情報を補足するオンライン ファイ
ルがあり、以降の項ではこのオンライン ファイルを説明します。このファイルをよ
く読んでから、データベース サーバの使用を開始してください。これらのファイル
には、アプリケーションと性能の問題に関する重要な情報が格納されています。
UNIX
UNIX プラットフォームでは、ディレクトリ $INFORMIXDIR/release/en_us/0333 に、
次のオンライン ファイルがあります。
オンライン
ファイル
用途
DDIDOC_x.y
このマニュアルのバージョン用のドキュメント ノート ファイ
ルでは、このマニュアルに記載されていない機能や、このマ
ニュアルの発行後に変更された機能について説明しています。
ファイル名に付いている x.y をご使用のデータベース サーバの
バージョン番号に置き換えると、このマニュアルのドキュメ
ント ノート ファイルの名前になります。
SERVERS_x.y
リリース ノート ファイルは、以前のバージョンの Informix 製
品との違い、およびこの違いが現在の製品に与える影響につ
いて説明しています。このファイルには、すでにわかってい
る問題やその対処方法についての情報も含まれています。
ファイル名に付いている x.y をご使用のデータベース サーバの
バージョン番号に置き換えると、このマニュアルのリリース
ノート ファイルの名前になります。
IDS_x.y
マシン ノート ファイルは、コンピュータにインストールされ
ている Informix 製品の構成、および使用に必要な特殊操作につ
いて説明しています。マシン ノートには、製品と同じ名前が
付いています。ファイル名に付いている x.y をご使用のデータ
ベース サーバのバージョン番号に置き換えると、このマニュ
アルのマシン ノート ファイルの名前になります。
♦
序
14
Informix Guide to Database Design and Implementation
参考文献
WIN NT
Informix フォルダには、次の項目があります。このフォルダを表示するには、タス
ク バーから [ スタート ]➞[ プログラム ]➞[Informix] を選択してください。
項目
説明
ドキュメント ノート
この項目には、マニュアルに対する追加事項や修正事
項が含まれており、さらにマニュアルに記載されてい
ない機能や、マニュアルの発行後に変更された機能に
関する情報も含まれています。
リリース ノート
この項目は、旧バージョンの Informix 製品との機能上
の差違、およびこの差違が現バージョンに与える影響
について説明しています。このファイルでは、すでに
わかっている問題とその対処方法も示しています。
マシン ノートは Windows NT プラットフォームには適用されません。 ♦
参考文献
以下の文献には、このマニュアルで説明する内容について、追加情報が収められて
います。データベース サーバやオペレーティング システム プラットフォームにつ
いての入門書の一覧については、
『Getting Started』マニュアルを参照してください。
データベース設計に対する基本的な概念や取組み方についてさらに詳しく知りたい
場合は、次の文献をお薦めします。
■
『Database Modeling and Design, The Entity-Relationship Approach』Toby
J.Teorey 著 (Morgan Kauffman Publishers, Inc.、1990 年 )
■
『Handbook of Relational Database Design』Candace C.Fleming、Barbara von
Halle 共著 (Addison-Wesley Publishing Company、1989 年 )
データ ウェアハウスのデータベース設計に興味をお持ちの場合、次の文献をお薦め
します。
■
『The Data Warehouse Toolkit』Ralph Kimball 著
(John Wiley & Sons, Inc.、1996 年 )
■
『Building the Data Warehouse』W.H. Inmon 著
(John Wiley & Sons, Inc.、1996 年 )
序
15
業界標準への準拠
業界標準への準拠
ANSI( 米国規格協会 ) は SQL に関する業界標準を定めています。Informix の SQL
ベースの製品は、SQL-92 エントリレベル (ANSI X3.135-1992) に完全準拠しており、
この SQL-92 は ISO 9075:1992 と全く同じものです。また、Informix データベース
サーバの多数の機能も、SQL-92 の暫定レベルおよび X/Open SQL CAE( 共通アプリ
ケーション環境 ) 標準に準拠しています。
序
16
Informix Guide to Database Design and Implementation
セクション I
データベース設計と実装の基
礎
第1章
データベースの設計
データベースのデータ モデルの選択 . .
. . .
. . .
ANSI 標準準拠データベースの使用法 . . . . . . .
データベースの ANSI 標準準拠への設定 . . . . .
既存のデータベースが ANSI 標準準拠であるかの判断.
ANSI 標準準拠のデータベースと ANSI 標準準拠でない
データベースとの相違点 . . . . . . . .
トランザクション . . . . . . . . . .
トランザクション ログ機能 . . . . . . .
所有者名の指定. . . . . . . . . . .
オブジェクトへのアクセス権. . . . . . .
デフォルトの排他レベル . . . . . . . .
文字データ型 . . . . . . . . . . .
10 進数データ型 . . . . . . . . . .
エスケープ文字. . . . . . . . . . .
カーソルの動作. . . . . . . . . . .
SQL 通信領域の SQLCODE フィールド . . . .
ANSI 標準準拠データベースで使用できる SQL 文.
シノニムの動作. . . . . . . . . . .
ご使用のデータベース向け専用言語環境の使用法 .
. . .
. .
1-3
.
.
.
. . .
. . .
. . .
. .
. .
. .
1-4
1-5
1-5
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . .
.
.
.
.
.
.
.
.
.
.
.
.
.
1-6
1-6
1-7
1-7
1-7
1-8
1-8
1-8
1-9
1-9
1-9
1-10
1-10
. .
1-10
1-2
Informix Guide to Database Design and Implementation
この章では、データベース管理者 (DBA) が効果的にデータベースを計画するために
理解する必要がある次の項目について説明します。
■
データベースのデータ モデルの選択
■
ANSI 標準準拠データベースの使用法
■
ご使用のデータベース専用の言語環境の使用法
データベースのデータ モデルの選択
Informix 製品を使用してデータベースを作成する前に、どのようなデータ モデルを
使用してデータベースを設計するかを決める必要があります。このマニュアルで
は、データベース設計に使用できる 2 つのデータ モデルについて説明します。
1 番目のデータ モデルは、オンライン トランザクション処理 (OLTP) の代表的な
データベース設計に使用される従来型の関係データ モデルです。トランザクション
処理の目的は、非常に小さなトランザクションを 1 つも失わずに大量に処理するこ
とです。OLTP データベースは日常的な業務上の操作要件に対応するように設計さ
れており、データベースの性能はそのような操作要件に合わせて調整されていま
す。このマニュアルのセクション I「データベース設計と実装の基礎」では、OLTP
用の関係データ モデルを作成して実装する方法について説明しています。
2 番目のデータ モデルは、データベース ウェアハウジングの基本的なデータベース
設計に使用される次元データ モデルです。データ ウェアハウジング環境では、
データベースはデータの抽出と分析のために最適化されています。このような情報
処理の種類を、オンライン分析型処理 (OLAP) または意思決定支援処理といいます。
セクション II「データ ウェアハウジング」では、OLAP 用の次元データ モデルを作
成して実装する方法について説明しています。
データベースの設計
1-3
ANSI 標準準拠データベースの使用法
データベース設計に使用するデータ モデルだけでなく、次の項目についても決定す
る必要があります。これらの項目しだいで、データベースを使用するアプリケー
ションで利用できる機能が決まります。
■
データベースを収容するのは、次のどのデータベース サーバか。Informix
Dynamic Server、Informix Dynamic Server、Workgroup Edition と Developer
Edition、または Informix Dynamic Server with Advanced Decision Support and
Extended Parallel Options。
■
データベースは ANSI 標準に準拠する必要があるか。
■
データベースでは、英語以外の言語の文字を表の中で使用するか。
この章では、これらの項目について説明し、これらの項目がデータベースに与える
影響についてまとめています。
ANSI 標準準拠データベースの使用法
CREATE DATABASE 文でキーワード MODE ANSI を使用すると、ANSI 標準準拠
データベースが作成されます。ANSI 標準準拠のデータベースと ANSI 標準準拠で
ないデータベースとの相違点については、1-6 ページを参照してください。
ANSI 標準準拠データデースを作成する理由を次に示します。
■
オブジェクトへのアクセス権とアクセス
ANSI 規格では、表やシノニムなどのオブジェクトへのアクセス権とアク
セスについて規定しています。ただし、ANSI 標準準拠データベースを作
成すれば、そのデータベースが常に ANSI/ISO SQL-92 規格に準拠するとは
限りません (CREATE INDEX など、ANSI 標準に準拠していない操作を
ANSI 標準準拠データベース上で実行すると警告が表示されますが、アプ
リケーション プログラムはその操作を禁止していません )。
■
名前排他設定
ANSI 表命名規則により、複数のユーザが 1 つのデータベースで名前の不
一致を心配せずに表を作成できます。
1-4
Informix Guide to Database Design and Implementation
データベースの ANSI 標準準拠への設定
■
トランザクション排他設定
■
データ復旧
ANSI 標準準拠データベースでは、バッファなしログと自動トランザクションが
Dynamic Server に対して強制されます。
データベースの ANSI 標準準拠への設定
キーワード MODE ANSI を使用してデータベースを作成すると、そのデータベース
は ANSI 標準準拠と見なされます。ANSI 標準準拠データベースでは、ロギング
モードをバッファ付きログに変更することも、ログをオフにすることもできませ
ん。
既存のデータベースが ANSI 標準準拠であるかの判断
データベースが ANSI 標準準拠かどうかを判断する方法を次に示します。
■
デフォルトのデータベース サーバが Dynamic Server の場合、ON-Monitor
ユーティリティを使用すると、そのサーバ上にあるすべてのデータベース
をリストできます。[Staus] メニューの [Databases] オプションを使用すると
そのリストが表示されます。ANSI 標準準拠データベースは、リストのロ
グ状態列に U* と表記されています。
■
デフォルトのデータベース サーバが高度意思決定支援オプションおよび拡
張並列オプション付きの Informix Dynamic Server の場合、Informix
Enterprise Command Center(IECC) を使用すると、そのサーバ上にあるすべ
てのデータベースをリストできます。
■
INFORMIX-ESQL/C などの SQL API を使用している場合は、SQL 通信領域
(SQLCA) をテストできます。特に、DATABASE 文または CONNECT 文を
使用して ANSI 標準準拠データベースを開いた直後に、SQLCAWARN 構
造体の 3 番目の要素には W が含まれます。SQLCA については、『Informix
Guide to SQL: Tutorial』または SQL API のマニュアルを参照してください。
データベースの設計
1-5
ANSI 標準準拠のデータベースと ANSI 標準準拠でない データベースとの相違点
ANSI 標準準拠のデータベースと ANSI 標準準拠でない
データベースとの相違点
作成時にキーワード MODE ANSI を使用して ANSI 標準準拠に設定したデータベー
スと ANSI 標準準拠でないデータベースとの間には、次のような点に違いがありま
す。
■
トランザクション
■
トランザクション ログ機能
■
所有者名の指定
■
オブジェクトへのアクセス権
■
デフォルトの排他レベル
■
文字データ型
■
10 進数データ型
■
エスケープ文字
■
カーソルの動作
■
SQLCA の SQLCODE
■
使用できる SQL 文
■
シノニムの動作
トランザクション
ANSI 標準準拠データベースで使用するすべての SQL 文は、自動的にトランザク
ションに含まれます。ANSI 標準準拠でないデータベースでは、トランザクション
処理を使用するかどうかを選択できます。
ANSI 標準準拠でないデータベースでは、1 つのトランザクションは BEGIN WORK
文で始まり、COMMIT WORK 文または ROLLBACK WORK 文で終わります。しか
し、ANSI 標準準拠データベースでは、すべての文が自動的にトランザクションに
含まれるので、BEGIN WORK 文は不要です。トランザクションの終わりの
COMMIT WORK 文また ROLLBACK WORK 文は必要です。
トランザクションについての詳細は、
『Informix Guide to SQL: Tutorial』、およびこの
マニュアルの第 4 章「リレーショナルデータモデルの実装」を参照してください。
1-6
Informix Guide to Database Design and Implementation
ANSI 標準準拠のデータベースと ANSI 標準準拠でない データベースとの相違点
トランザクション ログ機能
Dynamic Server および Dynamic Server with AD and XP Options 上の ANSI 標準準拠
データベースはすべてバッファなしトランザクション ログ機能を使用して実行され
ます。
IDS
AD/XP
ANSI 標準準拠でないデータベースは、バッファ付きログまたはバッファなしログの
どちらかを使用して実行できます。バッファなしログではより広範囲なデータ復旧
を利用でき、バッファ付きログではより優れた性能を利用できます。 ♦
ANSI 標準準拠でないデータベースでは、バッファなしログしか使用できません。
バッファなしログでは、より広範囲なデータ復旧を利用できます。 ♦
詳細については、
『Informix Guide to SQL: Syntax』の CREATE DATABASE 文の説明
を参照してください。
所有者名の指定
ANSI 標準準拠データベースでは、所有者名の指定が強制されます。SQL 文でオブ
ジェクト名を指定する場合、ANSI 標準では、そのオブジェクトの所有者でなけれ
ば、名前にプレフィックス < 所有者 >. を付けることが要求されます。< 所有者 > と
< 名前 > の組み合わせは、そのデータベース内で一意である必要があります。その
オブジェクトの所有者であれば、データベース サーバはそのユーザ名をデフォルト
として提供します。
ANSI 標準準拠でないデータベースでは、所有者名の指定は強制されません。
詳細については、
『Informix Guide to SQL: Syntax』の所有者名セグメントを参照して
ください。
オブジェクトへのアクセス権
ANSI 標準準拠データベースと ANSI 標準準拠でないデータベースでは、データ
ベース内で表を作成した場合に、デフォルトによって表レベルのアクセス権を付与
されるユーザが異なります。ANSI 標準の規定では、データベース サーバは表レベ
ルのアクセス権を表の所有者だけに (DBA と異なる場合は DBA にも ) 付与します。
しかし、ANSI 標準準拠でないデータベースでは、アクセス権は public に付与され
ます。さらに、Informix では、ANSI 標準にはない表レベルの 2 つのアクセス権、
Alter と Index を提供します。
表レベルのアクセス権を付与する方法についての詳細は、このマニュアルの第 8 章
「データベースサーバのアクセス権の付与と制限」
、および『Informix Guide to SQL:
Syntax』の GRANT 文の説明を参照してください。
データベースの設計
1-7
ANSI 標準準拠のデータベースと ANSI 標準準拠でない データベースとの相違点
ストアド プロシジャを実行するには、そのプロシジャの Execute アクセス権を持っ
ている必要があります。ANSI 標準準拠データベースで所有者アクセス権付きスト
アド プロシジャを作成すると、そのプロシジャの所有者だけが Execute アクセス権
を持ちます。ANSI 標準準拠でないデータベースで所有者アクセス権付きストアド
プロシジャを作成すると、データベース サーバはデフォルトにより public に
Execute アクセス権を付与します。
ストアド プロシジャのアクセス権についての詳細は、
『Informix Guide to SQL:
Tutorial』を参照してください。
デフォルトの排他レベル
データベースの排他レベルでは、使用しているプログラムがほかのプログラムの並
行動作から分離される程度を規定します。すべての ANSI 標準準拠データベースに
対するデフォルトの排他レベルは、繰返し可能読込みです。ログを使用する場合、
ANSI 標準準拠でないデータベースのデフォルトの排他レベルは、Dynamic Server お
よび Dynamic Server with AD and XP Options では、確定読込みです。ログを使用しな
い場合、ANSI 標準準拠でないデータベースのデフォルトの排他レベルは、非確定
読込みです。
排他レベルについては、
『Informix Guide to SQL: Tutorial』、および『Informix Guide to
SQL: Syntax』の SET TRANSACTION 文と SET ISOLATION 文の説明を参照してく
ださい。
文字データ型
ANSI 標準準拠データベースでは、規定のフィールド幅より長い文字列が文字
フィールド (CHAR、CHARACTER、VARCHAR、NCHAR、NVARCHAR、
CHARACTER VARYING) に入力されると、エラーが発生します。
10 進数データ型
ANSI 標準準拠データベースでは、DECIMAL データ型に小数点以下桁数は使用さ
れません。小数点以下桁数は 0 と見なすことができます。
1-8
Informix Guide to Database Design and Implementation
ANSI 標準準拠のデータベースと ANSI 標準準拠でない データベースとの相違点
エスケープ文字
ANSI 標準準拠データベースでは、エスケープ文字はパーセント (%) とアンダスコ
ア (_) だけをエスケープできます。エスケープ文字を使用して、そのエスケープ文
字自体をエスケープすることもできます。詳細については、
『Informix Guide to SQL:
Syntax』の条件セグメントを参照してください。
カーソルの動作
データベースが ANSI 準拠でない場合、SELECT 文の UPDATE カーソルを宣言する
ときに、キーワード FOR UPDATE を使用する必要があります。また、SELECT 文
は次の条件を満たす必要があります。
■
単一の表から選択する。
■
集計関数を含まない。
■
DISTINCT、GROUP BY、INTO TEMP、ORDER BY、UNION、UNIQUE の
節やキーワードを含まない。
ANSI 標準準拠データベースでは、カーソルを宣言するときにキーワード FOR
UPDATE を明示的に使用する必要はありません。ANSI 標準準拠データベースでは、
すべてのカーソルは、前掲の箇条書きの制約を満たす場合、潜在的に UPDATE
カーソルです。DECLARE 文でキーワード FOR READ ONLY を指定すると、カーソ
ルを読取り専用に指定できます。
詳細については、
『Informix Guide to SQL: Syntax』の DECLARE 文の説明を参照して
ください。
SQL 通信領域の SQLCODE フィールド
DELETE、INSERT INTO < 表名 > SELECT、SELECT...INTO TEMP、UPDATE のい
ずれの文の探索条件も満たす行がない場合、データベース サーバは、データベース
が ANSI 標準準拠のときは SQLCODE を 100 に設定し、データベースが標準準拠で
ないときは SQLCODE を 0 に設定します。
詳細については、
『Informix Guide to SQL: Tutorial』の SQLCODE の説明を参照して
ください。
データベースの設計
1-9
ご使用のデータベース向け専用言語環境の使用法
ANSI 標準準拠データベースで使用できる SQL 文
アプリケーションで ANSI 標準準拠データベースとともに使用することが許される
SQL 文には、制限がありません。ANSI 標準準拠のデータベースでも ANSI 標準準
拠でないデータベースでも、Informix の拡張機能を使用できます。
シノニムの動作
ANSI 標準準拠データベースでは、シノニムは常にプライベートです。ANSI 標準準
拠データベースで、パブリック シノニムを作成しようとしたり、キーワード
PRIVATE を使用してプライベート シノニムを示そうとしたりすると、エラーが発
生します。
GLS
ご使用のデータベース向け専用言語環境の使用法
広域言語サポート (GLS) を使用すると、Informix バージョン 7.2 以降の製品では、
さまざまなロケールが使用できます。GLS ロケールは、特定の言語または文化向け
の規約を定義している環境です。
ヒント : バージョン 7.2 以降の製品では、
各国語サポート (NLS) およびアジア言語サ
ポート (ALS) が GLS に置き換えられています。
デフォルトにより、Informix 製品は米国英語 ASCII コード セットを使用して、
ASCII 照合順序の米国英語環境で実行されます。次の機能のいずれかを使用する場
合は、デフォルトでないロケールに対応するように環境を設定します。
■
データに英語以外の文字
■
ユーザ指定のオブジェクト名に英語以外の文字
■
ASCII コード セット以外のソート順序および照合順序に対する準拠
■
辞書や電話帳などで使用される、文化固有の照合順序およびソート順序
GLS 環境変数の説明、および米国英語でない環境の実装方法の詳細については、
『Informix Guide to GLS Functionality』を参照してください。
1-10
Informix Guide to Database Design and Implementation
第2章
リレーショナルデータモデル
の作成
データモデルを作成する理由 .
. . .
. . .
. . .
. . .
. .
2-3
実体 - 関係データモデルの概要
. . .
. . .
. . .
. . .
. .
2-4
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
主なデータオブジェクトの識別と定義
実体の識別 . . . . . . . .
実体の選択 . . . . . .
実体リスト . . . . . .
住所録の例 . . . . . .
実体の図式化 . . . . .
関係の定義 . . . . . . . .
接続性 . . . . . . . .
存在の依存性 . . . . . .
濃度 . . . . . . . . .
関係の発見 . . . . . .
関係の図式化 . . . . .
属性の識別 . . . . . . .
実体の属性の選択 . . . .
属性の列挙 . . . . . .
実体のオカレンスについて .
データオブジェクトの図式化 .
E-R 図の読み方 . . . .
住所録の例 . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . .
. . .
. . .
. .
. .
. .
. .
. .
. .
. . .
. . .
. . .
. . .
. .
. .
. .
. .
. .
. . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . .
. . .
. . .
E-R データオブジェクトの関係構造体への変換
表、行、列の定義 . . . . . . .
列への制約の適用 . . . . . .
表のキーの決定 . . . . . . . .
主キー . . . . . . . . .
外部キー ( 結合列 ) . . . . . . .
住所録の図へのキーの追加 . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
.
.
.
.
. .
. .
. .
. .
.
.
.
.
.
. .
. . .
. . .
. . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . .
. . .
. . .
.
.
.
.
.
. . . .
. . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
.
.
.
.
. .
. .
. .
. .
.
.
.
.
.
. .
2-5
2-5
2-5
2-6
2-7
2-9
2-9
2-10
2-10
2-11
2-11
2-16
2-17
2-17
2-18
2-18
. .
. .
. .
2-19
2-20
2-21
.
.
.
.
.
2-22
2-23
2-24
2-25
2-25
2-27
2-28
.
.
.
.
.
. .
. .
関係の解決 . . . . . . . . . . . . . . . . . . . .
m:n 関係の解決 . . . . . . . . . . . . . . . . . .
その他の特別な関係の解決 . . . . . . . . . . . . . .
2-29
2-29
2-30
データモデルの正規化 .
第 1 正規形 . . . .
第 2 正規形 . . .
第 3 正規形 . . .
正規化ルールのまとめ
2-2
.
.
.
.
.
. . . .
. . . . .
. . . .
. . . .
. . . .
.
.
.
.
.
.
.
.
.
.
Informix Guide to Database Design and Implementation
.
. .
.
.
.
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
.
. .
.
.
.
.
.
. .
. .
. .
. .
.
.
.
.
.
2-31
2-32
2-34
2-34
2-35
従来型のリレーショナルデータベースを作成する最初の手順は、データモデルを作
成することです。データモデルの作成とは、格納する必要のあるデータを正確かつ
完全に定義することです。この章では、データをモデル化する一つの方法につい
て、その概要を説明します。第 3 章「データ型の選択」では、データ モデルを完成
するために定義する列固有のプロパティについて説明します。第 4 章「リレーショ
ナルデータモデルの実装」では、この章で説明するデータ モデルの実装方法につい
て説明します。
この章の内容を理解するには、SQL とリレーショナルデータベース理論に関する基
礎知識が必要です。
データモデルを作成する理由
データベースを構成するデータの型や必要な編成方法について、すでに何らかの構
想を持っているとします。この情報が、データモデルを作成する出発点です。ある
種の形式化された表記法を使用してデータモデルを作成する場合、設計する際に次
の二つの点で役に立ちます。
■
データモデルについて徹底的に考えることができる。
通常、直感的なモデルには、あいまいな点や検討が済んでいない仮定が含
まれています。設計を形式化した場合は、これらの仮定が見つかります。
■
他の人でもその設計が理解しやすくなる。
形式化された記述はモデルを明確にするので、他の人が同じ形式でコメン
トや意見を述べることができます。
リレーショナルデータモデルの作成
2-3
実体 - 関係データモデルの概要
実体 - 関係データモデルの概要
データのモデル化の形式化された方法には、複数の方法が存在します。それらのど
の方法を使用しても完全で正確なモデル化ができます。何らかの方法を知っている
場合は、ぜひそれを使用してください。
この章では、実体 - 関係 (E-R) データモデルの概要を説明します。これは、Informix
トレーニングコースで取り上げているモデル化の方法です。E-R データモデル化の
方法では次の手順を使用します。
1.
主なデータベースオブジェクト ( 実体、関係、および属性 ) を識別し定義
する。
2.
E-R アプローチを使用して、データオブジェクトを図に作成する。
3.
E-R データオブジェクトを関係型構造に変換する。
4.
論理データモデルを解決する。
5.
論理データモデルを正規化する。
この章では、手順 1 から 5 までを説明します。論理データモデルを物理スキーマに
変換する最終的な手順については、第 4 章「リレーショナルデータモデルの実装」
を参照してください。
データモデル化の最終的な結果は、2-33 ページの図 2-21 と同様なダイヤグラムで
エンコードされた、個人用住所録の最終的な表のセットを示す完全に定義された
データベース設計となります。この個人用住所録は、この章で例として作成しま
す。これは、一つの章で完全に作成できるほどの小さいサイズであり、かつ全体の
方法を示すには十分大きなサイズなので、デモンストレーションデータベースでな
くこの住所録を使用します。
2-4
Informix Guide to Database Design and Implementation
主なデータオブジェクトの識別と定義
主なデータオブジェクトの識別と定義
データモデルを作成するには、最初に、主なデータオブジェクトを識別し、定義し
ます。主なデータオブジェクトとは、実体、関係および属性です。
実体の識別
実体とは、ユーザが大きな関心を持っている主なデータオブジェクトの一つです。
通常、実体はデータベースに記録される人、場所、物、事柄などです。データモデ
ルを言語とした場合、実体は名詞に相当します。デモンストレーションデータベー
スには、顧客、注文、品目、在庫、カタログ、cust_calls、call_type、メーカー、州
といった実体が含まれています。
実体の選択
データベースについてすぐにいくつかの実体を列挙できるはずです。識別可能なす
べての実体の予備的なリストを作成します。データベースのユーザとなる可能性の
ある人に、データベースに記録すべき事柄について意見を聞くためインタビューを
行います。
「一つの名前に少なくとも一つの住所を関連付けなければならない」と
いうように、各実体の基本的な特性を決定します。実体に関する決定事項はすべて
ビジネスルールになります。2-7 ページの「住所録の例」に、この章の例で使用す
るビジネスルールをいくつか例示してあります。
その後、データモデルを正規化して、実体のいくつかを拡張または他のデータオブ
ジェクトにすることができます。詳細は、2-31 ページの「データモデルの正規化」
を参照してください。
リレーショナルデータモデルの作成
2-5
実体の識別
実体リスト
実体リストが完成したと思われる場合は、そのリストを調べて各実体が次の特性を
持っていることを確認してください。
■
重要である。
データベースのユーザにとって重要で、かつ時間と費用をかけてコン
ピュータで処理するだけの価値がある実体のみを取り上げます。
■
一般性がある。
個々の実体ではなく、類型のみを取り上げます。たとえば、交響曲は実体
ですがベートーベンの第 5 交響曲は交響曲の実現値です。
■
基本的である。
他の実体に依存せずに独立して存在するもののみを実体として取り上げま
す。それを説明するのに何か特長や記述といったものがほかに必要なもの
は、独立した実体ではありません。たとえば、部品番号は部品という基本
的実体の一つの特長です。また、他の実体から導出できるものも、実体と
して取り上げないでください。たとえば、合計や平均などの量は SELECT
文で式を使用すれば計算できます。
■
単一のものである。
命名した各実体がそれぞれ単一のクラスを表しているかを確認してくださ
い。一つの実体を、それぞれ固有の特長を持つ下位のカテゴリに分類する
ことはできません。住所録モデルでは (2-7 ページの「住所録の例」を参照
)、電話番号は明らかに簡単な実体であり、それぞれが異なる機能を持つ 3
つのカテゴリで実際に構成されます。
これらの条件に合う実体を選ぶことは、決して簡単ではなく、機械的に選ぶことは
できません。最善の選択を見つけるには、データベースに格納したいデータの性質
について慎重に検討する必要があります。このような検討を行うことによって、適
切なデータモデルを作成することができます。次の項で、住所録の例を詳細に説明
します。
2-6
Informix Guide to Database Design and Implementation
実体の識別
住所録の例
例として、個人用の住所録のためのデータベースを作成することを考えてみます。
このデータベースのモデルに格納すべき情報は、データベースのユーザが必要とす
る人と組織の名前、住所、電話番号です。
最初に実体を定義します。住所録のページをよく調べて、どんな実体があるかを識
別します。図 2-1 は、住所録のページの例です。
図 2-1
住所録の一部
NAME
PHONE
NAME
PHONE
Thomas Morrison 503-776-3428
Catherine Morgan 206-789-5396
ADDRESS
ADDRESS
866 Gage Rd.
Klamath Falls
OR 97601
429 Bridge Way
NAME
Seattle, WA 98103
PHONE
Thomas Morrison
ADDRESS
866 Gage Rd.
Klamath Falls
OR 97601
NAME
Thomas Morrison
ADDRESS
866 Gage Rd.
Klamath Falls
OR 97601
PHONE
N
O
NAME
PHONE
P
Norman Dearborn 206 598Q
8189
ADDRESS
R
Morganthaler Industries
S
T
12558 E. 10th Ave. Seattle, WA
NAME
PHONE U
Thomas Morrison 503-256-6031 V
ADDRESS
W
866 Gage Rd.
X
Klamath Falls, OR 97601
Y
Z
リレーショナルデータモデルの作成
2-7
実体の識別
既存のデータの物理的な形は、誤解を招くことがあります。住所録のページと項目
のレイアウトに惑わされて、住所録の一つのエントリを一つの実体として指定しな
いように注意してください。住所録のエントリは、アルファベット順に並べられ、
名前、電話番号、住所の欄を持っています。モデル化するのはデータであって、
データの集まりではありません。
実体は一般的で重要か
見たところ、住所録に記録されている実体には次の項目が含まれています。
■
人や組織の名前
■
住所
■
電話番号
これらの実体は、前述の基準を満たしているでしょうか。モデルにとして重要であ
り、一般性があることは明らかです。
実体は基本的か
各実体は、他の実体に影響を与えずに個数を変化させることができます。この事実
は、基本的かどうかの判定に使用できます。引っ越したり仕事を変えたりしたため
に電話番号や現住所を持たない人も住所録に記載される場合があります。また、住
所録には、複数の人が使用している住所と電話番号が記載されていることもありま
す。名前、住所、電話番号の 3 つの実体はどれも、独立して個数を変化させること
ができます。これは、これらの実体が基本的であり、他のデータ依存していないこ
とを示しています。
実体は単一か
名前は個人名と会社名に分類することができます。このモデルではどの名前も特に
区別しないことにしました。つまり、会社の情報も個人の情報も同じように扱うこ
とにしました。同様に住所も、自宅の住所と会社の住所を区別して扱わずに、1 種
類と見なすことにしました。
ただし、複数の種類の電話番号があることになります。人が応答する通常の電話番
号、ファックスにつながるファックス番号、コンピュータにつながるモデム番号で
す。各種類の番号について異なる情報を記録することにします。つまり、この 3 種
類が異なる実体となります。
2-8
Informix Guide to Database Design and Implementation
関係の定義
住所録の例では、次の実体を記録することに決定しました。
■
名前
■
住所 ( 郵送先 )
■
電話番号
■
ファックス番号
■
モデム番号
実体の図式化
E-R 図の使用方法については、この章で後述します。まず、図 2-2 に示すように、
住所録の例における各実体について、独立した長方形のボックスを作成します。実
体と関係を結び付ける方法については、2-19 ページの「データオブジェクトの図式
化」で示します。
名前
住所
電話番号
ファックス
番号
モデム
番号
図 2-2
住所録の例における
実体
関係の定義
データベースの実体を選択したら、その実体間の関係を考える必要があります。関
係は必ずしも明確ではありませんが、記録する価値のあるものをすべて見つけなけ
ればなりません。確実にすべての関係を見つけるには、考えられる関係をすべて列
挙する以外にありません。実体 A と実体 B のすべての組合せを想定し、
「A と B の
間にはどのような関係があるか」について考えます。
関係とは、二つの実体の間の関連です。通常、関係は二つの実体を結ぶ動詞や前置
詞の中に含まれます。実体間の関係は、接続性、存在の依存性、さらに濃度に分け
られます。
リレーショナルデータモデルの作成
2-9
関係の定義
接続性
接続性とは、実体の実現値の数を意味します。実体の実現値は、実体の特定のオカ
レンスです。図 2-3 に示すように、接続性には 1 対 1(1:1)、1 対多 (1:n)、多対多
(m:n) の 3 種類があります。
図 2-3
関係における接続性
1対1
1 対多
多対多
たとえば住所録の例では、住所は複数の名前と関連がある場合があります。名前と
住所との関連の接続性は、1 対多 (1:n) です。
存在の依存性
存在の依存性は、関係における実体が任意であるか、必須であるかを示します。ビ
ジネスルールを分析して、実体が関係に存在しなければならないかどうかを確認し
ます。たとえば、一つの名前には一つの住所が関連付けられていなくてはならない
というビジネスルールがあるとします。このような関連は、名前と住所の実体の間
の関係に存在の依存性が必須であることを示します。存在の依存性が任意である例
として、ある人の子供のあるなしというビジネスルールを挙げることができます。
2-10
Informix Guide to Database Design and Implementation
関係の定義
濃度
濃度は、実体が関係に現れる回数に制約を適用します。1 対 1 の関係の濃度は、常
に 1 です。これに対して、1 対 n の関係の濃度は不定です。n は任意の数でかまい
ません。n に上限を設ける必要がある場合は、その関係に濃度を指定します。たと
えば、店舗販売の例では、顧客が 1 回で買える品物の数の上限を指定すると考えら
れます。普通、濃度の制約はアプリケーションプログラムまたはストアドプロシ
ジャを使用して指定します。
濃度の詳細については、E-R データのモデル化についての参考書を参照してくださ
い。
関係の発見
実体間の関係を発見する方法としては、マトリックス形式で二つの実体の組合せを
列挙した表を作成するのが便利です。図 2-4 に示したマトリックスは、個人用住所
録の実体に関するものです。
名前
住所
電話番号
ファックス
番号
モデム
番号
図 2-4
個人用住所録の実体の
マトリックス
名前
住所
電話番号
ファックス
番号
モデム
番号
リレーショナルデータモデルの作成
2-11
関係の定義
マトリックス内の陰をつけた部分は無視することができます。対角線上のセルは検
討を要します。つまり、
「実体 A の実現値と実体 A の別の実現値の間にはどんな関
係があるか」を考えなければなりません。このモデルの場合、その答えは、
「関係
は一つもない」になります。名前どうしや住所と他の住所の間には関係がありませ
ん。少なくとも、このモデルでは記録する必要があるものは何もありません。A の
実現値と A の別の実現値の間に関係がある場合は、再帰的な関係があるといいます
(2-30 ページの「その他の特別な関係の解決」を参照してください ) 。
関係がないことがはっきりしたセルには、関係なしと記入します。図 2-5 に、現行
のマトリックスを示します。
住所
名前
名前
電話番号
ファック
ス番号
モデム
番号
図 2-5
初期の関係を示した
マトリックス
関係なし
住所
関係なし
電話番号
ファックス
番号
関係なし
関係なし
関係なし
モデム
番号
自分自身との間に関係がある実体はありませんが、他のモデルでは同一の実体の間
に関係が生じます。たとえば、社員という実体では、ある社員は別の社員の上司に
なることがあります。別の例としては、部品という実体があります。ある部品が別
の部品の構成要素になることがあります。
2-12
Informix Guide to Database Design and Implementation
関係の定義
残った空白のセルには、上端の見出しの実体と左端の見出しの実体の間に存在する
接続関係の種類を書き込みます。関係には、次のような種類があります。
■
1 対 1 の関係 (1:1) 実体 A の一つの要素と関係する実体B の要素は一つのみで
す。実体 B の各要素から見ても、関係する要素は一つのみです。
■
1対多の関係(1:n) 実体Aのただ一つの要素に実体Bの複数の要素が関係しま
す。または、実体 B のただ一つの要素に実体 A の複数の要素が関係しま
す。
■
多対多の関係 (m:n) 実体 A の一つの要素と関係する実体 B の要素は複数あり
ます。また、実体 B の一つの要素と関係する実体 A の要素も複数ありま
す。
1 対多の関係がもっとも一般的です。住所録モデルの例では、1 対多と多対多の関
係を示します。
2-12 ページの図 2-5 に示すように、最初の空白のセルは、名前と住所の間の関係を
示しています。名前と住所という実体の間には、どのような接続性があるでしょう
か。
「一つの住所にいくつの名前を関連付けることができるか」について考えた結
果、名前は住所を持たないか、またはただ一つの住所を持つことにします。図 2-6
に示すように、名前の向かい側、住所の下に 0-1 と記入します。
名前
名前
関係なし
住所
図 2-6
名前と住所の関係
0-1
次に、一つの名前にいくつの住所が関連しているかを考えます。住所は複数の名前
と関連があるということにします。たとえば、同じ会社に勤める人を何人か知って
いるかもしれませんし、同じ住所に住んでいる人を複数知っているかもしれませ
ん。
リレーショナルデータモデルの作成
2-13
関係の定義
住所と関連する名前の数がゼロということはあり得るでしょうか。すなわち、住所
だけが存在し、その住所に対する名前が存在しないということはあるでしょうか。
この場合は、あり得ると決定しました。図 2-7 に示すように、住所の下、名前の向
かい側に 0-n と記入します。
図 2-7
住所と名前の関係
住所
関係なし
0-n
0-1
名前
名前
関連付けられた名前が一つもない住所は存在しないと決定した場合は、0-n ではな
く 1-n と記入します。
関係する要素の濃度 ( 個数 ) がどちらか一方の実体の側で最大 1 に制限される場合
は、1:n の関係になります。この場合、名前と住所の関係は 1:n の関係です。
今度は、2-12 ページの図 2-5 にある次のセルの名前と電話番号の関係を検討しま
す。一つの名前と関係する可能性がある電話番号は一つだけでしょうか、それとも
二つ以上関係することがあるでしょうか。住所録を見ると、一人に対して複数の電
話番号を記入している箇所が見受けられます。多忙なセールス担当者の場合は、自
宅の電話番号、会社の電話番号、ポケットベルの番号、自動車電話番号などが記入
されています。しかし、電話番号のない名前もあります。この場合は、図 2-8 に示
すように、名前の向かい側、電話番号の下に 0-n と記入します。
名前
2-14
名前
住所
電話番号
関係なし
0-n
0-1
0-n
Informix Guide to Database Design and Implementation
図 2-8
名前と電話番号の関係
関係の定義
次に、逆方向の関係を検討します。各電話番号と関係する可能性がある名前は、い
くつあるでしょうか。電話番号には、一つの名前のみ関係していると決定しまし
た。電話番号と関係する名前の数がゼロという場合はあり得るでしょうか。誰にも
使用されていない電話番号を記録する必要はないと決定しました。図 2-9 に示すよ
うに、電話番号 ( 音声 ) の下、名前の向かい側に 1 と記入します。
図 2-9
電話番号と名前の関係
名前
名前
住所
電話番号
関係なし
0-n
0-1
1
0-n
以下の要因を考慮して、マトリックスの残りの部分も同じように記入します。
■
名前は、複数のファックス番号と関係する可能性があります。たとえば、
会社にはいくつかのファクシミリがあることがあります。逆に考えると、
各ファックス番号は、複数の名前と関係する可能性があります。たとえ
ば、同じファックス番号を複数の人が使用することがあります。
■
各モデム番号が関係する名前は、ちょうど一つでなければなりません。( こ
れは意図的に決めたものです。設計の要件の一つと考えてください。) こ
れに対し各名前は、複数のモデム番号と関係する可能性があります。たと
えば、会社のコンピュータは複数のダイヤル回線に接続されることがあり
ます。
■
電話番号と住所の間には、現実には何らかの関係がありますが、このモデ
ルでは特に注意するような関係はありません。すでに名前によって間接的
な関係が示されています。
リレーショナルデータモデルの作成
2-15
関係の定義
図 2-10 に、完全なマトリックスを示します。
名前
住所
名前
住所
電話番号
ファックス
番号
モデム
番号
関係なし
0-n
0-1
1
0-n
1-n
0-n
1
0-n
関係なし
関係なし
関係なし
関係なし
関係なし
関係なし
関係なし
関係なし
関係なし
電話番号
ファックス
番号
図 2-10
完成した住所録の
マトリックス
関係なし
モデム
番号
マトリックスに示されたその他の決定は、ファックス番号とモデム番号、電話番号
とファックス番号、電話番号とモデム番号のように、それぞれの間に関係が存在し
ないということです。
マトリックスの決定のなかには、電話番号とモデム番号の間の関係をサポートして
いないなど、同意できないかも知れませんがこれがビジネスルールです。
関係の図式化
まず、この節で作成したマトリックスを保存しておきます。E-R 図の作成方法につ
いては、2-19 ページの「データオブジェクトの図式化」で学習します。
2-16
Informix Guide to Database Design and Implementation
属性の識別
属性の識別
実体には、特性や変更子、特質、数量や特長としての属性が含まれています。属性
は、実体に関する事実または分割できない情報です。実体を表として表現するとき
に、実体の属性を新しい列としてモデルに追加します。
実体を識別して初めて、データベース属性が識別できます。実体を決定したら、
「各実体についてどのような特性を知る必要があるか」について考えます。たとえ
ば、実体が住所であれば、通り、市、郵便番号などを知る必要があるでしょう。住
所という実体に関するこれらの特性それぞれが属性となります。
実体の属性の選択
属性を選ぶときは、次の条件を満たすものを選んでください。
■
重要性が高いこと
データベースのユーザにとって重要な属性のみを選んでください。
■
直接的であり、導出的ではないこと
たとえば、SELECT 文の記述から導出できるような、既存の属性から導出
できる属性がモデルの一部であってはなりません。データが導出される
と、データベースの保守が複雑になります。
この後の設計段階では、性能改善のために導出される属性の追加を検討す
る場合があります。しかしこの段階では、導出される属性は除外します。
データベースサーバの性能の改善方法については、
『Performance Guide』を
参照してください。
■
分割できないこと
属性は一つの値のみを含むもので、リストや繰り返されるグループを含ん
だものであってはなりません。複合的な値は、個々の属性に分けなければ
なりません。
■
同じタイプのデータを含んでいること
たとえば、誕生日という属性には日付の値のみを入れて、名前や電話番号
入れないはずです。
属性の定義方法のルールは、列の定義方法のルールと同じです。列の定義方法につ
いての詳細は、2-24 ページの「列への制約の適用」を参照してください。
リレーショナルデータモデルの作成
2-17
属性の識別
次の属性を住所録の例に追加して、2-21 ページの図 2-15 に示すような図を作成し
ます。
■
町名、市町村名、および郵便番号を住所の実体に追加します。
■
名前の実体には、誕生日、電子メールの宛先、記念日、および子供の名前
を追加します。
■
電話番号の実体には、自動車電話、自宅の電話、および勤務先の電話を区
別するためのタイプを追加します。一つの電話番号は、一つの電話のみに
関係します。
■
ファックスの実体には、ファクシミリが受信可能な時間帯を追加します。
■
モデムの実体には、9,600-、14,400-、28,800- など、モデムがサポートする
ボーレートを追加します。
属性の列挙
ここでは、住所録の例について、必要と思われる実体とともに属性を列挙します。
図 2-11 のような属性が列挙されるでしょう。
名前
fname
lname
bdate
anniv
email
child1
child2
child3
住所
street
city
state
zipcode
電話番号
vce_num
vce_type
ファックス番号
fax_num
oper_from
oper_till
モデム番号
図 2-11
住所録の例の属性
mdm_num
b9600
b14400
b28800
実体のオカレンスについて
追加のデータオブジェクトは、実体のオカレンス ( 発生数 ) です。表の各行は、実
体の特定の単一のオカレンスを表しています。たとえば、顧客が実体である場合、
顧客表は顧客の概念を表します。その表では、各行は、たとえば Sue Smith という 1
人の顧客を表します。実体は表に、属性は列に、実体のオカレンスは行になること
をおぼえておいてください。
2-18
Informix Guide to Database Design and Implementation
データオブジェクトの図式化
データオブジェクトの図式化
これまで、データベースにおける実体と関係について説明してきました。それはリ
レーショナルデータベース設計過程でもっとも重要な部分です。実体と関係が決ま
ると、データベース設計中の思考過程を表す方法が役に立つことがあります。
大部分のデータモデル化の方法には、実体と関係を図式的に表す何らかの手段が用
意されています。Informix では、C. R. Bachman が開発した E-R 図のアプローチを使
用しています。E-R 図の目的は、以下のとおりです。
■
組織の情報ニーズをモデル化する。
■
実体とその関係を示す。
■
データ定義 ( データ流れ図 ) の出発点となる。
■
アプリケーション開発者のみならず、データベース管理者やシステム管理
者にとって文書化のためのすぐれた資料となる。
■
物理スキーマに変換できるデータベースの論理設計を作成する。
E-R 図には、いくつかのスタイルが存在します。好みのスタイルがある場合は、そ
れを使用してください。E-R 図の例を図 2-12 に示します。
名前
住所
実体
図 2-12
実体 - 関係図の記号
実体
関係
リレーショナルデータモデルの作成
2-19
E-R 図の読み方
E-R 図では、ボックスは実体を表します。線は、実体と実体をつなぐ関係を表しま
す。また、図 2-13 に、次の性質の関係を表す場合のグラフィック記号の使い方を示
します。
■
接続関係を表す線上の円は、
その関係が任意であることを示す ( 実現値がゼ
ロの場合がある )。
■
接続関係を表す線上の短い棒線は、その実体のちょうど一つの実現値が他
の実体に関連付けられていることを示す ( 棒線は 1 とみなす )。
■
カラスの足跡は、関係が多数あることを示す。
任意性
図 2-13
実体 - 関係図における
関係の部分
任意性
住
名前
多数
ちょうど
一つ
E-R 図の読み方
E-R 図は、まず左から右に、次に右から左に読んでいきます。図 2-14 のような名前
/ 住所関係の場合は、次のように読んでいきます。名前は、ゼロまたはちょうど一
つの住所に関係することができます。また、住所は、ゼロ、一つ、または多数の名
前と関係することができます。
図 2-14
実体 - 関係図の読み方
ゼロまたは
ちょうど
一つ
名前
住所
ゼロまたは多数
2-20
Informix Guide to Database Design and Implementation
住所録の例
住所録の例
図 2-15 に、実体、関係、属性を含んだ住所録の例を示します。この図には、マト
リックスを使用して確立する関係が含まれています。図中のシンボルの意味を理解
した後、図 2-15 の E-R 図を 2-16 ページの図 2-10 マトリックスと比較してくださ
い。両方の図で関係が同じになっているかを確認してください。
2-16 ページの図 2-10 に示したようなマトリックスは、それを記入する際、必然的
にあり得るすべての関係を考えなければならないため、初めてモデル設計する場合
には有効なツールとなります。ただし、図 2-15 のように、同じ関係が図に現れる場
合は、この種の図は、既存のモデルを再検討すると読みやすくなります。
図 2-15
住所録の例の予備的
実体 - 関係図
名前
lname
fname
bdate
anniv
email
child1
child2
child3
電話番号
vce_num
vce_type
住所
street
city
state
zipcode
ファックス
番号
fax_num
oper_from
oper_till
モデム番号
mdm_num
b9600
b14400
b28800
リレーショナルデータモデルの作成
2-21
E-R データオブジェクトの関係構造体への変換
図が完成した後に
この章の残りの部分では、以下の作業を実行する方法について説明します。
■
実体、関係、属性を関係構造体に変換する。
■
E-R データモデルを解決する。
■
E-R データモデルを正規化する。
E-R データモデルからデータベースを作成する方法については、第 4 章「リレー
ショナルデータモデルの実装」で説明します。
E-R データオブジェクトの関係構造体への変換
これまで学習してきたすべてのデータオブジェクト ( 実体、関係、属性、および実
体のオカレンス ) は、SQL 表、表どうしの結合、列、および行に変換されます。
データベースの表、列、行は、2-23 ページの「表、行、列の定義」に示すルールに
従っていなければなりません。
データオブジェクトを正規化する前に、それがこれらのルールを満たしていること
を確認してください。データオブジェクトを正規化するには、実体、関係、および
属性の間の依存性を分析します。正規化については、2-31 ページの「データモデル
の正規化」を参照してください。
データモデルを正規化した後は、SQL 文を使用してデータモデルに基づくデータ
ベースを作成することができます。住所録の例のデータベースを作成し、データ
ベーススキーマを指定する方法については、第 4 章「リレーショナルデータモデル
の実装」で説明します。
選択した各実体は、モデルにおける表として示されます。表は、抽象概念としての
実体を意味しており、各行は実体の特定の個別のオカレンスを表します。さらに、
実体の各属性は表の列で表されます。
以下に E-R データモデルを含む大部分の関係データモデル法の基本的な考えかたを
示します。データモデル設計時にこれらのルールに従って、モデルを正規化すると
きの時間と労力を節約してください。
2-22
Informix Guide to Database Design and Implementation
表、行、列の定義
表、行、列の定義
すでに、読者は、行および列からなる表という概念に精通していることと思いま
す。しかし、正式なデータモデルの表は下記のルールが要求されます。
■
各行は独立していていなければならない。
表の各行は独立していて、同じ表の他の行に依存することはありません。
したがって、表の内部での行の順番は、モデルでは意味がありません。表
のすべての行をランダムな順番に並び替えたとしても、モデルは正しいは
ずです。
データベースを実装した後では、性能を上げるためにデータベースサーバ
に要求して特定の順序で行を保存することができますが、その順序はモデ
ルには影響を及ぼしません。
■
各行は一意でなければならない。
各行には、必ず一意の値を持つ列がなければなりません。この特性を持つ
単一の列がない場合は、複数の列の値を組にすることで行を識別できるよ
うな列の組合せが存在しなければなりません。
■
各列は独立していなければならない。
表の内部での列の順番は、モデルでは意味がありません。列を並び替えた
としても、モデルは正しいはずです。
データベースを実装した後では、すべての列を意味するアスタリスクを使
用しているプログラムや埋め込まれた問合せは列の最終的な順序に依存し
ますが、その順序はモデルには影響を及ぼしません。
■
各列の値は一の値でなければならない。
各列の格納できるのは、一つの値のみで、値の並びや繰り返されるグルー
プは、一つの列には格納できません。複数の要素から合成された値は、
個々の列に分離する必要があります。たとえば、この章の例のように、個
人の姓と名前を別々の値として取り扱うことにした場合、姓と名前は一つ
の列にいっしょに格納するのではなく、別々の列に格納しなければなりま
せん。
リレーショナルデータモデルの作成
2-23
表、行、列の定義
■
各列は一意の名前を持たなければならない。
同じ表の内部の二つの列が同じ名前を共有することはできません。ただし
同様な情報を含む列を複数作成することはできます。たとえば、住所録の
例の表名前には子供の名前の列があります。この場合、各列の名前は
child1 child2 などとします。
■
各列は単一の型のデータを含んだものでなければならない。
各列は、同じデータ型の情報を格納しなければなりません。たとえば、整
数 (INTEGER) 型で示される列には、名前からの文字ではなく数値情報の
みを格納しなければなりません。
配列やシーケンシャルファイルとして構成されたデータを扱った経験しかない場合
は、これらのルールは不自然に思えるかもしれません。しかし、リレーショナル
データベースの理論では、すべての型のデータは、これらのルールに従った表、
行、列のみを使用して表すことができます。多少経験を積めば、これらのルールを
機械的に適用できるようになります。
列への制約の適用
CREATE TABLE 文を使用して表と列を定義する場合、各列に制約を加えます。こ
れらの制約は、列に文字と数のどちらを入れるか、使用する日付の形式などの条件
を指定します。属性を決定できるような一式の有効な値をドメインで識別する場合
は、ドメインに制約を記述します。列のドメイン特性は、以下の項目で構成されて
います。
2-24
■
データ型 ( 整数 (INTEGER) 型、文字 (CHAR) 型、日付 (DATE) 型など )
■
フォーマット ( たとえば、yy/mm/dd)
■
範囲 ( たとえば、1,000 ∼ 5,400)
■
意味 ( たとえば、個人の電話番号 )
■
許容値 ( たとえば、等級 S または U のみ )
■
一意性
■
NULL のサポート
■
デフォルト値
■
参照制約
Informix Guide to Database Design and Implementation
表のキーの決定
表を作成する場合、ドメインの特性を定義します。ドメインの定義方法について
は、第 3 章「データ型の選択」を参照してください。表とデータベースの作成につ
いては、第 4 章「リレーショナルデータモデルの実装」を参照してください。
表のキーの決定
表の列は、キー列または記述子列のどちらかです。キー列とは、表の内部の特定の
行を一意に識別する列です。たとえば、社会保険番号は各社員にとって一意です。
記述子列は、表の特定の行の一意ではない特性を指定します。たとえば、Sue とい
う同じ姓を持つ社員が二人いる場合を考えます。この Sue という名前は、1 人の社
員の一意な特性ではありません。表におけるキーには、主キーと外部キーという主
なタイプがあります。
主キーと外部キーは、表を作成するときに指定します。主キーと外部キーは、表を
物理的に関係づけるために使用します。次の作業は、各表に主キーを指定すること
です。つまり、行のそれぞれを他の行と区別する何らかの定量化できる表の特性を
識別する必要があります。
主キー
表の主キーとは、行ごとに値が異なる列のことです。主キーの値は行ごとに異なる
ため、主キーは各行を一意に識別します。そのような列が存在しない場合は、値の
組合せが行ごとに異なるような複数の列の組合せが主キーになります。
モデルの表はどれも、主キーを持たなければなりません。このルールは、すべての
行は一意でなくてはならないというルールを自動的に導き出します。必要に応じ
て、すべての列で主キーを構成することもできます。
主キーは、数値データ型 ( 整数 (INT) 型または小桁整数 (SMALLINT) 型 )、シリア
ル (SERIAL) 型または短い文字列 ( コードに使用 ) とします。長い文字列を主キーと
して使用しないことをお勧めします。
主キー列では NULL は使用できません。NULL は比較することができません。つま
り NULL については、
「同じ」あるいは「異なる」といった比較はできません。し
たがって、NULL は行を一意に識別することができません。NULL が使用できる列
を主キーや主キーの一部として使用することはできません。
リレーショナルデータモデルの作成
2-25
表のキーの決定
実体の中には、カタログ番号や身分証明番号のように、モデルの外部で定義された
主キーを持つものもあります。これはユーザが割り当てたキーです。
場合によっては、複数の列や列のグループが主キーとして使用できることもありま
す。主キーとして使用できる列や列のグループを候補キーと呼びます。候補キーは
一意性という特性のため、SELECT 文の結果が予測できるため、注意する必要があ
ります。候補キーの列を選択すると、その結果には重複行が含まれていないことが
わかっているので、SELECT 文を実行した結果は選択した候補キーを主キーとする
一つの表になります。
複合キー
実体によっては、確かな一意性を欠いたものがあります。たとえば、同姓同名の人
がいる場合があります。別々の本が題名同じである場合もあります。通常、このよ
うな場合は複数の属性を組み合せて主キーとして使用できます。名前と住所が同じ
という人はめったになく、異なる本でもタイトル、著者および発行日が同じという
こともほとんどあり得ないからです。
システム割当てキー
通常は、複合キーよりシステム割当て主キーのほうが便利です。システム割当キー
は、実体の各実現値に付けられる数値またはコードです。もっとも簡単に付けるこ
とができるシステム割当てキーは、データベースが自動的に生成することのできる
シリアル番号です。Informix では、シリアル番号のためにシリアル (SERIAL) 型を使
用します。しかし、意味のない数値コードは、データベース利用者には現実的とは
いえません。そのような場合は、実際のデータに基づいたコードをシステム割当て
キーとして使用することもできます。たとえば、従業員の識別コードは、個人の頭
文字と雇用された日付の数字を組み合わせて示すことができます。住所録の例で
は、システム割当て主キーは表名で使用されています。
2-26
Informix Guide to Database Design and Implementation
表のキーの決定
外部キー ( 結合列 )
表の外部キーとは、他の表の主キーの値を持つ列または列の組のことです。外部
キーは、表を結合するときに使用します。図 2-16 は、デモンストレーションデータ
ベースの顧客表と注文表の主キーと外部キーです。
注文
顧客
customer_num
主キー
order_num
customer_num
図 2-16
顧客 / 注文関係におけ
る主キーと外部キー
外部キー
表から行を削除するときは、外部キーによって制約を受けるので、外部キーに注目
する必要があります。行を削除するときには、その前に外部キーを介してその行を
参照している行をすべて削除しておくか、一つの削除コマンドで主キーと外部キー
から行を削除できる特殊な構文を使用して関係を定義しておく必要があります。
データベースサーバでは、参照整合性に違反する削除は行えません。
参照整合性を保持するには、すべての外部キー列を削除してから、その外部キーが
参照している主キーを削除してください。データベースに参照整合性が課されてい
る場合、対応する外部キーが存在しているときにデータベースサーバは主キーの削
除を許可しません。また、既存の主キーの値を参照しない外部キーの値を追加する
こともできません。参照整合性については、
『Informix Guide to SQL: Tutorial』を参
照してください。
リレーショナルデータモデルの作成
2-27
表のキーの決定
住所録の図へのキーの追加
2-28 ページの図 2-17、最初に選択された主キーおよび外部キーを示します。この図
は、いくつかの重要な決定を反映しています。
表名前では、主キー rec_num が選択されています。rec_num はシリアル (SERIAL)
型です。rec_num の値は、システムが生成します。表名前の他の列または属性を見
ると列に関連付けられたデータ型のほとんどは文字型を基準にしたものであること
がわかります。これらの列はどれも、単独では主キー候補として適切ではありませ
ん。表の要素を組み合わせて複合キーを作成すると、キーは複雑になります。シリ
アル (SERIAL) 型のデータ型を使用すれば、他の表を表名前に結合する場合にも使
用できるようなキーを得ることができます。
表電話、ファックス、モデムでは、電話番号が主キーとして示されています。これ
らの表は、キー rec_num を介して表名前に結合されます。
表住所も、システムが生成した id_num という主キーを使用しています。ビジネス
ルールでは、名前が住所を使用していなくても住所は存在し得ることになっている
ので、表住所には主キーが必要です。ビジネスルールで、名前が住所と関係してい
ないかぎり、住所は存在できないと定められている場合は、表住所は外部キー
rec_num でのみ表名前と結合することができます。
図 2-17
主キーと外部キーを
追加した住所録の図
名前
rec_num PK
lname
fname
bdate
anniv
email
child1
child2
child3
電話
vce_num PK
rec_num FK
vce_type
2-28
住所
id_num PK
rec_num FK
street
city
state
zipcode
ファックス
fax_num PK
rec_num FK
oper_from
oper_till
モデム
mdm_num PK
rec_num FK
b9600
b14400
b28800
Informix Guide to Database Design and Implementation
PK= 主キー
FK= 外部キー
関係の解決
関係の解決
適切なデータモデルの目的は、データベースサーバが迅速にアクセスできるような
構造体を作成することにあります。関係を解決し、データモデルを正規化すること
により、住所録のデータモデルをさらに改善することができます。ここでは、デー
タベースの関係を解決する方法と、その理由について説明します。データモデルの
正規化については、2-31 ページの「データモデルの正規化」で説明します。
m:n 関係の解決
多対多 (m:n) の関係は、モデルとアプリケーション開発過程を複雑にするだけでな
く混乱をもたらします。m:n 関係を解決する鍵は、二つの実体を分離して、これら
の実体の間に第 3 の交差実体によって二つの 1 対多 (1:n) の関係を作成することに
あります。交差実体には、通常、それが接続する両方の実体の属性が含まれます。
m:n 関係を解決するには、ビジネスルールをもう一度解析します。関係を正確に図
式化しているでしょうか。住所録の例では、2-28 ページの図 2-17 に示すように、
名前実体とファックス実体間の関係を m:n にしました。ビジネスルールは、以下の
ように定めています。
「ある人はゼロ、一つまたは複数のファックス番号を持つこ
とができる。一つのファックス番号は、複数の人が使用することがある」
。実体電
話の主キーとして先に選択したものに基づいて、m:n 関係は存在しています。
主キーとして指定した電話番号は、実体ファックスに 2 回以上現れることがあるの
で実体ファックスには問題があります。これは主キーの条件に違反しています。主
キーは一意でなければならないことを思い出してください。
このような m:n の関係を解決するには、図 2-18 に示すように、名前実体とファック
ス実体の間に交差実体を追加します。新しい交差実体、ファックス名には、
fax_num と rec_num という二つの属性が含まれています。実体の主キーは、これら
両方の属性を複合したものです。個別にみると、各属性は属性が由来する表を参照
する外部キーです。表名前と表ファックス名との間の関係は、1:n です。一つの名
前が多くのファックス番号と関係することがあり得るからです。一方、各ファック
ス名の組合せは、一つの rec_num と関係する可能性があります。各番号は複数の
ファックス名の組合せと関係し得るので表ファックスと表ファックス名との間の関
係は 1:n です。
リレーショナルデータモデルの作成
2-29
その他の特別な関係の解決
名前
rec_num PK
lname
fname
bdate
anniv
email
child1
child2
child3
rec_num PK
lname
fname
bdate
anniv
email
child1
child2
child3
交差
実体
ファックス名
fax_num PK FK
rec_num PK FK
図 2-18
多対多 (m:n) 関係の解
決
ファックス
ファックス
fax_num PK
rec_num FK
oper_from
oper_till
PK= 主キー
FK= 外部キー
fax_num PK
oper_from
oper_till
前
後
その他の特別な関係の解決
上記以外にも、データベースの円滑な実行を妨げる特別な関係があります。これら
の関係には、次のようなものがあります。
■
複雑な関係
■
再帰的関係
■
冗長な関係
複雑な関係とは、3 つ以上の実体の間の関係です。関係が存在するには、すべての
実体が存在しなければなりません。この複雑さを軽減するには、すべての複雑な関
係を実体として再分類し、元の実体のそれぞれに対する 2 進関係に整理します。
再帰的関係とは、同じ型の実体のオカレンスの間の関係です。このタイプの関係は
よく見られるものではありません。再帰的関係の例としては、部品表 ( パーツがサ
ブパーツで構成されている ) や組織構造 ( ある社員が他の社員を管理する ) があり
ます。再帰的関係の詳しい例については、
『Informix Guide to SQL: Tutorial』を参照
してください。再帰的関係を解決しないほうを選択することもできます。
2-30
Informix Guide to Database Design and Implementation
データモデルの正規化
冗長な関係は、複数の関係が同じ概念を表す場合に存在します。冗長な関係は、
データモデルを複雑にし、開発者がデータモデルの属性を誤って設定する原因にも
なります。この関係は、E-R 図の中で重複した実体として表されます。たとえば、
同じ属性を含む二つの実体がある場合があります。冗長な関係を解決するには、
データモデルを見直します。同じ属性を含んだ実体が二つ以上ないでしょうか。冗
長性を解決するには、モデルに新しい実体を追加する必要があるかも知れません。
データモデルの冗長性についての詳細は、
『Performance Guide』を参照してくださ
い。
データモデルの正規化
この章の住所録は、よいモデル例です。今のままでもこのモデルをデータベースと
して実現することができますが、アプリケーション開発やデータ操作に、後日問題
が発生する可能性があります。正規化とは、属性を実体と関係づけるためのルール
を適用する、形式化されたアプローチです。
データモデルを正規化すると、以下の目標が達成できます。
■
設計の柔軟性を向上させる。
■
属性を正しい表に入れる。
■
データの冗長性を少なくする。
■
プログラムの性能を向上する。
■
アプリケーションの保守コストを引き下げる。
■
データ構造の安定性を最大限に高める。
正規化は、実体をより適切な物理特性にするためのいくつかの手順で構成されてい
ます。これらの手順を正規化ルールといいます。正規形と呼ぶこともあります。正
規形にはいくつかあります。この章では、最初の 3 つの正規形を説明します。各正
規形は、直前の形よりも構造性の高いものにするためにデータを制約します。この
ため、第 2 正規形を実現するには第 1 正規形を実現し、第 3 正規形を実現するには
第 2 正規形を実現しなければなりません。
リレーショナルデータモデルの作成
2-31
第 1 正規形
第 1 正規形
実体に反復されるグループがない場合、その実体は第 1 正規形となります。した
がって、表に反復される列がない場合、その表は第 1 正規形となります。反復列
は、データの柔軟性を低下させ、ディスクスペースをむだ使いし、データの探索を
困難にします。図 2-19 の住所録の例では、表名前に反復列 child1、child2、child3 が
含まれています。
図 2-19
正規化前の実体名前
名前
lname
fname
bdate
anniv
email
child1
child2
反復列
child3
反復列 反復列
現行の表にはいくつかの問題点があります。この表は、ある人に子供がいるいない
に関わらず、一人につき 3 人の子供を記録するためのディスクスペースを常に確保
しておかなくてはなりません。記録できる子供の最大数は 3 人ですが、4 人以上の
子供がいる知人もいるはずです。また、特定の子供を探す場合、各行につき 3 つの
列をすべて探索しなければなりません。
反復列をなくして、表を第 1 正規形にするには、次に示すように表を二つに分割し
ます。反復列を表のどちらかに入れます。二つの表間の関連付けは主キーと外部
キーを組み合わせて確立されます。表名前と関連付けられていなければ子供はいな
いことになるので、外部キー rec_num で表名前を参照します。
図 2-20
実体名前の第 1 正規形
名前
rec_num
lname
fname
bdate anniv
rec_num
child_name
email
主キー
子供
外部キー
2-32
Informix Guide to Database Design and Implementation
第 1 正規形
ここで、2-28 ページの図 2-17 の、第 1 正規形になっていないグループを確認して
ください。名前 / モデム関係は、列 b9600、b14400、b28800 が反復列と考えられる
ので、第 1 正規形ではありません。列 b9600、b14400、b28800 のオカレンスを格納
するために表モデムに新しい列 b_type を追加します。図 2-21 に、第 1 正規形で正
規化されたデータモデルを示します。
名前
rec_num PK
lname
fname
bdate
anniv
email
電話
vce_num PK
rec_num
vce_type
図 2-21
住所録のデータモデル
子供
rec_num FK
child_name
住所
id_num PK
rec_num FK
street
city
state
zipcode
ファックス名
fax_num PK FK
rec_num PK FK
ファックス
fax_num PK
oper_from
oper_till
モデム
mdm_num PK
rec_num FK
b_type
PK= 主キー
FK= 外部キー
リレーショナルデータモデルの作成
2-33
第 2 正規形
第 2 正規形
実体が第 1 正規形であり、かつその属性のすべてが全体 ( 主 ) キーに依存している
場合、その実体は第 2 正規形であるといいます。したがって、表中のすべての列は
その表の全体的な主キーに機能的に依存します。機能的依存性は、二つの異なる列
内の値の間にリンクが存在することを示しています。
属性値が列に依存する場合、列の値を変更すると属性値も変わります。属性は列の
関数になります。これを具体的に説明すると、以下のようになります。
■
表に 1 列の主キーがある場合、属性はそのキーに依存していなければなら
ない。
■
表に複合主キーがある場合、属性は、一つまたは数個の列ではなく、全体
としてのすべての列内の値に依存していなければならない。
■
属性が他の複数の列に依存している場合、その列は候補キーの列でなくて
はならない。つまり、列はすべての行で一意でなければならない。
モデルを第 2 正規形に変換する場合、データの冗長性が発生し、データの変更が困
難になる可能性があります。第 1 正規形の表を第 2 正規形の表に変換するには、主
キーに依存していない列を削除します。
第 3 正規形
実体が第 2 正規形であり、かつその属性のすべてが主キーに過渡的に依存していな
い場合、実体は第 3 正規形であるといいます。過渡的依存性とは、記述子のキー属
性が全体主キーだけでなく、他の記述子キー属性にも依存しており、この他の属性
が主キーに依存していることを意味します。SQL の用語では、第 3 正規形とは、表
内の列が、主キーに依存する記述子の列に依存していないことを意味します。
第 3 正規形に変換するには、他の記述子キー属性に依存している属性を削除しま
す。
2-34
Informix Guide to Database Design and Implementation
正規化ルールのまとめ
正規化ルールのまとめ
ここでは、以下の正規形について説明しました。
■
第 1 正規形 : 表に反復列が含まれていない場合、その表は第 1 正規形です。
■
第2正規形: 表が第1正規形であり、
かつ全体(主)キーに依存している列のみ
を含んでいる場合、その表は第 2 正規形です。
■
第 3 正規形 : 表が第 2 正規形であり、かつ主キーに過渡的にも依存していな
い列だけが含まれている場合、その表は第 3 正規形です。
これらのルールに従っている場合、リレーショナルデータベースの創案者である E.
F.Codd に従えば、モデルの表は第 3 正規形です。表が第 3 正規形ではない場合は、
モデルに冗長なデータが存在するか、表を更新しようとするときに問題が発生する
可能性があります。
これらのルールを維持している属性を見つけることができない場合、次のいずれか
のエラーが発生している可能性があります。
■
その属性は明確に定義されていない。
■
その属性は直接的でなく導出される属性である。
■
その属性は、実際には属性ではなく、実体か関係である。
■
モデルから脱落した実体や関係がある。
リレーショナルデータモデルの作成
2-35
第3章
データ型の選択
ドメインの定義 . . . . . . .
データ型 . . . . . . . .
データ型の選択. . . . .
数値データ型 . . . . .
日付、時間に関するデータ型.
文字型 . . . . . . .
データ型の変更. . . . .
NULL 値 . . . . . . . .
デフォルト値 . . . . . .
検査制約 . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3-3
3-4
3-4
3-7
3-12
3-17
3-23
3-23
3-23
3-24
3-2
Informix Guide to Database Design and Implementation
データモデルの作成が終わると、それをデータベースとデータベースに含まれる表
として実装することになります。データモデルを実装するには、最初に、ドメイ
ン、つまりデータ値の集合を列ごとに定義します。この章では、列データ型と制約
を定義するときに決定する必要のある事項について説明します。
次の手順では（第 4 章を参照）
、CREATE DATABASE 文と CREATE TABLE 文を使
用して、モデルを実装し表にデータを初期入力します。
ドメインの定義
第 2 章「リレーショナルデータモデルの作成」で説明したデータ型をさらに完全な
ものとするには、表の各列に対してドメインを定義する必要があります。列のドメ
インは列に設定されている制約を記述し、属性または列が想定できる一連の有効な
値を示します。
ドメインを定義するのは、データの意味整合性を保護するためです。つまり、モデ
ルのデータが現実を反映していることを確実にすることです。電話番号を名前に置
き換えたり、整数値のみ有効なデータに小数値を入力したりすることができると、
データモデルの整合性は保証されなくなります。
ドメインを定義するには、まず、データ値がドメインの部分を構成する前に満たさ
なければならない制約を定義します。列のドメインを指定するには、次の制約を使
用します。
■
データ型
■
デフォルト型
■
検査制約
各表の主キーと外部キーを識別して、列に対する参照制約を設定することができま
す。これらのキーを識別する方法についての詳細は、第 2 章「リレーショナルデー
タモデルの作成」を参照してください。
データ型の選択
3-3
データ型
データ型
列に対する最初の制約は、列にデータ型を指定することにより課されます。列の
データ型を指定すると、その列にはそのデータ型の値のみ格納できるように制約す
ることになります。
それぞれのデータ型は、特定の種類の情報のみ表すことができます。ある列にとっ
ての正しいデータ型とは、その列に適したデータ値はすべて表現でき、その列に適
さない値はほとんど表現できないデータ型のことです。
データ型の選択
表内のすべての列は、データベースサーバがサポートしているデータ型から選択し
たデータ型を持っていなければなりません。データ型の選択が重要である理由を、
次に示します。
■
列のデータ型を選択すると、その列に格納できる有効なデータ項目の集合
である基本ドメインが確立される。
■
データに対して実行できる操作の種類が決定される。たとえば、文字デー
タ型で定義された列に対しては SUM などの集計関数は適用できない。
■
一つ一つのデータが占有するディスク領域の大きさは、データ型によって
決まる。行数が 10 あるいは数千の小さな表の場合、データ項目に割り当
てる領域の大きさを考慮する必要がない。表の行数が多くなると、4 バイ
トと 8 バイトの差が重要になってくる。
参照制約でのデータ型の使用方法
主キーと外部キーに対して列を選択するとき、ほとんどすべてのデータ型の組み合
わせが一致する必要があります。たとえば、主キーを文字 (CHAR) 型で定義した場
合外部キーも文字 (CHAR) 型で定義しなければなりません。しかし、ある表の主
キーにシリアル (SERIAL) 型を指定している場合は、関係する外部キーに整数
(INTEGER) 型を指定します。シリアル (SERIAL) 型と整数 (INTEGER) 型のみが、関
係の中で混在することができるデータ型の組み合わせです。
3-5 ページの図 3-1 に、データ型間の選択を要約したデシジョンツリーを示します。
これらの選択については、以降の項で説明します。
3-4
Informix Guide to Database Design and Implementation
データ型
図 3-1
データ型の選択
データ項目は純粋な数
値である
はい
いいえ
はい
すべての数値が整数で
ある
いいえ
すべての数値が -215 から
215-1 までの間にある
いいえ
小桁整数
(SMALLINT) 型
すべての数値が -231 から
-231-1 までの間にある
いいえ
10 進数 (DECIMAL(p,0)) 型
整数
(INTEGER) 型
10 進数 (DECIMAL(p,s)) 型
最大桁数が 8 桁以下である
いいえ
はい
はい
小数点以下の精度が固
定されている
いいえ
はい
はい
小桁実数 (SMALLFLOAT) 型
最大桁数が 16 桁以下である はい
いいえ
実数 (FLOAT) 型
10 進数 (DECIMAL(p)) 型
(1 / 2)
データ型の選択
3-5
データ型
データは時を表すもの
である
はい
いいえ
時間を表すか時刻を表す
時刻
日付のみである
いいえ
時間
時間隔
(INTERVAL) 型
はい
日付 (DATE) 型
日時 (DATETIME) 型
データに英字以外の文
字が含まれている
はい
いいえ
データの長さは大きく
変化しない
はい
いいえ
各国語文字
(NCHAR(n)) 型
各国語可変長文字
(NVARCHAR(m,r)) 型
データは ASCII 文字
列である
はい
いいえ
データの長さは大きく
変化しない
はい
いいえ
255 バイト以上の長さ
が必要である
いいえ
長さが 32,511 バイト以 はい
下である
はい いいえ
CHARACTER VARYING(m,r)
または VARCHAR(m,r)
バイト (BYTE) 型
文字
(CHAR(n)) 型
テキスト (TEXT) 型
(2 / 2)
3-6
Informix Guide to Database Design and Implementation
データ型
数値データ型
Informix データベースサーバでは、8 種類の数値データ型が用意されています。カ
ウンタやコードに適したもの、科学技術分野の数値計算に適したもの、金額に適し
たものなどがあります。
カウンタとコード : 整数 (INTEGER) 型と小桁整数 (SMALLINT) 型
整数 (INTEGER) 型と小桁整数 (SMALLINT) 型は、桁数の少ない整数を格納する
データ型です。カウント値、順序番号、数値による識別コード、格納される値の最
大値と最小値があらかじめわかっている整数値などを格納する列に指定するのに適
しています。
この二つのデータ型の値は、両方ともに 2 進数の整数として格納されます。整数
(INTEGER) 型の値は 32 ビット長で、-231 から 231-1 の範囲にある整数を表すことが
できます。
小桁整数型の値は、16 ビット長です。これらは、-32,767 から 32,767 の範囲にある
値を表すことができます。
整数型と小桁整数型には次の利点があります。
■
占有する領域が小さい ( 小桁整数型の場合は一つの値あたり 2 バイト、整数
型の場合は一つの値あたり 4 バイトを占有する )。
■
これらのデータ型の列に対しては、SUM や MAX などの算術式、ソートや
比較を実行できる。
整数 (INTEGER) 型および小桁整数 (SMALLINT) 型を使用する場合の不利な点は、
格納できる値の範囲が制限されることです。範囲外の値を格納することはできませ
ん。もちろん、格納すべき最大値と最小値がわかっている場合は、このような制限
超過は問題になりません。
通し番号の自動生成 : シリアル (SERIAL) 型
シリアル (SERIAL) 型は、特別の機能を持った整数型です。表に新しい行が挿入さ
れるとき、シリアル型の列については、データベースサーバが自動的に新しい値 (
通し番号 ) を生成します。各表は、シリアル型の列を 1 列のみ持つことができます。
シリアル型の列の値はデータベースにより生成されるため、複数のユーザが同時に
行を挿入している場合でも、挿入される行のシリアル型の列には常に違う値が入り
ます。このような条件下にあるとき、通常のプログラムで一意の数値コードを新し
く生成することは非常に困難なため、この機能はきわめて有益です。
データ型の選択
3-7
データ型
データベースサーバは、231 を表に挿入する時点までにすべての正のシリアル番号
を使用します。正のシリアル番号をすべて使い切るには、単一のアプリケーション
が 68 年間毎秒 1 行を挿入するか、68 のアプリケーションが 1 年間毎秒 1 行挿入す
る必要があるため、正のシリアル番号の不足が問題になることはほとんどありませ
ん。正のシリアル番号がすべて使用されてしまうと、データベースサーバは引き続
き新しい数値を生成します。データベースサーバでは、整数の最大値を符号付きの
整数として扱います。データベースサーバでは正の値のみを使用するため、1 から
始まる整数値が繰り返し生成されることになります。
データベースサーバでは、常に増加するように通し番号を生成します。表から削除
された行の通し番号が再び使用されることはありません。シリアル (SERIAL) 型の
列でソートされる行は、それらの行が作成された順序で返されます。これは、シリ
アル型だけの特徴です。
IDS
CREATE TABLE 文を使用して、シリアル (SERIAL) 型の列に開始値を指定すること
ができます。したがって、表ごとに開始値の異なるシステム割当てキーを自動的に
生成することができます。このマニュアルで例として使用しているデモンストレー
ションデータベースでは、このデータ型が使用されています。たとえば、顧客番号
が 101 から、また注文番号が 1001 から始まっています。この小規模の業者が登録
する顧客の数が 899 を超えない限り、顧客番号も 3 桁以内に納まり、注文番号は 4
桁になります。 ♦
シリアル型の列は、自動的には一意の列になりません。重複するシリアル番号が絶
対に発生することがないようにするには、一意性制約を設定する必要があります
(4-6 ページの「CREATE TABLE 文の使用方法」を参照してください )。DB-Access
やリレーショナルオブジェクトマネージャを使用して表を定義すると、すべてのシ
リアル (SERIAL) 型列に一意性制約が自動的に適用されます。
シリアル型には次のような利点があります。
■
システム割当てキーを手軽に作成できる。
■
複数のユーザが同時に表を更新している場合でも、一意の数値コードを生
成する。
■
生成される数値の範囲を表ごとに変えることができる。
シリアル型には次のような欠点があります。
3-8
■
各表には、シリアル型で許されている列が 1 列のみである。
■
生成されるのは任意数のみである。
Informix Guide to Database Design and Implementation
データ型
次に生成される通し番号の変更
シリアル型列の開始値は、この列が作成されるときに設定されます (4-6 ページの
「CREATE TABLE 文の使用方法」を参照 )。列の作成後に、ALTER TABLE 文を使用
すれば、データベースサーバが次に作成する値を別の値に設定できます。
列の現行の最大値より小さい値を次の値にすることはできません。このようにする
と、データベースサーバが状況次第で重複する数値を生成してしまうためです。し
かし、最大値より大きい場合どのような値でも次の値として設定できるため、間を
空けて通し番号を生成することができます。
近似値 : 実数 (FLOAT) 型と小桁実数 (SMALLFLOAT) 型
科学技術や統計のアプリケーションで扱われる数値の多くは、有効数字が数桁のみ
で、数値の大きさが数値の正確な桁数と同じくらいに重要です。
浮動小数点データ型はこのような種類のアプリケーションのために用意されていま
す。整数でも小数部を含む数値でも、あらゆる数値を表現でき、数値の大きさの範
囲は宇宙的規模から顕微鏡的規模に及びます。たとえば、地球から太陽までの平均
距離 (1.5 × 109 メートル ) も、プランク定数 (6.625 × 10-27) も簡単に表現できます。
ただし、このデータ型は、精度に限りがあります。浮動小数点数は、数値の最上位
の数字のみ保持します。格納可能な桁数以下の数値ならば正確に格納されます。し
かし、格納可能な桁数を超える数値は、近似値の形、つまり最下位の数字がゼロと
して扱われる形で格納されます。
このような不正確さは多くのユーザにとって有益ですが、最下位の数字がゼロに
なってはならない金額や他の量を記録するのに浮動小数点を使用してはなりませ
ん。
浮動小数点用のデータ型には 2 種類のサイズがあります。実数 (FLOAT) 型は、倍
精度の 2 進の浮動小数点数を格納するためのデータ型で、C 言語に実装されていま
す。通常、実数 (FLOAT) 型の値には最大 8 バイトが必要です。小桁実数 (REAL) 型
とも呼ばれる小桁実数 (SMALLFLOAT) 型は、通常、最大 4 バイトを必要とする単
精度の 2 進浮動小数点数です。この二つのデータ型の主な違いは精度です。実数型
の列が約 16 桁を保持するのに対し、小桁実数型の列は約 8 桁を保持のみです。
データ型の選択
3-9
データ型
浮動小数点用のデータ型には次の利点があります。
■
非常に大きな数値や非常に小さな数値を格納し、小数部を持つ数値も格納
する。
■
4 バイトまたは 8 バイトで数値を簡潔に表現する。
■
浮動小数点用のデータ型の列に対しては、AVG や MIN などの算術関数や、
ソート、比較を効率よく実行できる。
主な欠点は、精度の範囲を超える桁がゼロとして扱われることです。
精度を調整可能な浮動小数点数 :10 進数 (DECIMAL(p)) 型
DECIMAL(p) データ型は、実数 (FLOAT) 型や小桁実数 (SMALLFLOAT) 型に似た浮
動小数点データ型です。実数型や小桁実数型との主な違いは、有効数字の桁数 ( 精
度 ) を指定できることです。p で表される桁数は 1 から 32 の範囲をとることがで
き、最小有効桁数 ( 精度 ) は小桁実数 (SMALLFLOAT) 型より少なく、最大有効桁
数 ( 精度 ) は実数 (FLOAT) 型の 2 倍です。
DECIMAL(p) の数値の大きさの範囲は、10-129 から 10125 です。
10 進数型には固定小数点形式のものもあり、混乱しやすいので注意が必要です。こ
の項で説明している DECIMAL(p) は、精度のみを指定する 10 進数型です。
DECIMAL(p) の数値が占める記憶域の大きさは、精度によって変わります。各数値
が占める領域は、1+p/2 バイトです ( 小数点以下の端数は切り上げられます )。
DECIMAL(p) は、実数 (FLOAT) 型に対し次のような利点があります。
3-10
■
低精度から高精度まで、アプリケーションにあった精度を設定できる。
■
最大 32 桁の数値を正確に表現できる。
■
占有する記憶域の大きさは、数値の精度に比例する。
■
使用できる精度と値の範囲は、ホストオペレーティングシステムとは無関
係に Informix データベースサーバでサポートされる。
Informix Guide to Database Design and Implementation
データ型
DECIMAL(p) データ型の欠点は次のとおりです。
■
実数 (FLOAT) 型の値の場合
10 進数 (DECIMAL(p)) 型の値の計算やソートは、
よりいくらか遅くなる。
■
多くのプログラミング言語では、実数 (FLOAT) 型や整数 (INTEGER) 型がサ
ポートされているのと同じ方法では、DECIMAL(p) データ型はサポートさ
れていない。プログラムでデータベースから DECIMAL(p) の値を抽出する
場合は、処理が行えるようにその値を別の形式に変換する必要がある。
固定小数点数 :10 進数 (DECIMAL) 型と金額 (MONEY) 型
ほとんどのビジネスアプリケーションが格納しなければならない数値は、整数部と
小数部の桁数が決まっています。このような数値の例としてもっとも一般的なもの
は金額です。米国などのいくつかの国々の通貨は、小数部が 2 桁で記述されます。
通常記録されるトランザクションの種類によって、左側 ( 整数部 ) に必要な桁数は
わかっています。おそらく、家計などでは 5 桁、小規模のビジネスでは 7 桁、国家
予算などでは 12 から 13 桁でしょう。
この種の数値は、値の大きさとは無関係に特定の位置に小数点が固定されるため、
固定小数点数と呼ばれています。DECIMAL(p,s) データ型は、10 進数を格納するた
めのデータ型です。この型の列を指定する場合、格納できる合計桁数として 1 から
32 までの精度 (p) を指定することができます。小数点以下桁数 (s) を小数点の右側
の桁数として指定します ( 図 3-2 に、精度と小数点以下桁数の関係を示しています
)。小数点以下桁数がゼロになる場合もあり、これはその数値が整数であることを意
味しています。整数のみが格納される場合、DECIMAL(p,s) は最大 32 桁までの整数
の格納方法を示します。
図 3-2
精度と小数点以下桁数
精度 8 桁
DECIMAL(8,3)
31964.535
小数点以下 3 桁
データ型の選択
3-11
データ型
DECIMAL(p) データ型と同様に、DECIMAL(p,s) もその精度に比例した領域を必要
とします。値が占める領域の大きさは、(p+3)/2 バイト ( 小数点以下の桁数が偶数の
場合 ) か、または (p+4)/2 バイト ( 小数点以下の桁数が奇数の場合 ) で、整数バイト
になるまで切り上げられます。
金額 (MONEY) 型は、DECIMAL(p,s) と同じです。ただし、機能が一つ追加されて
います。表示のために金額型の数値が文字型に変換されるときには、通貨記号が自
動的に追加されます。
整数 (INTEGER) 型や実数 (FLOAT) 型に対する DECIMAL(p,s) の利点は、整数
(INTEGER) 型の 10 桁や実数 (FLOAT) 型の 16 桁に比べて最大 32 桁という多数の有
効桁数を使用することができ、精度と必要な記憶域の大きさの両方をアプリケー
ションに合わせて調整できるということです。
DECIMAL(p,s) の欠点は、計算の効率が低いことと、多くのプログラムはこの形式
の数値をサポートしていないということです。したがって、プログラムでこの数値
を抽出する場合、通常は、処理が行えるようにその数値を別の数値形式に変換しな
ければなりません。
通貨フォーマットの選択
GLS
金額の表しかたは国によって異なります。Informix データベースサーバでは、金額
(MONEY) 型の値を表示する場合、ユーザが指定した通貨形式を参照します。デ
フォルトのロケールは、次のような形式の米国英語の通貨フォーマットです。
$7,822.45
英語以外のロケールについては、ロケールファイルの MONETARY カテゴリで通貨
形式を変更することができます。ロケールの使用方法についての詳細は、
『Informix
Guide to GLS Functionality』を参照してください。 ♦
通貨形式をカスタマイズするためには、適切なロケールを選択、もしくは、環境変
数 DBMONEY を設定します。詳細は、
『Informix Guide to SQL: Reference』を参照し
てください。
日付、時間に関するデータ型
Informix データベースサーバでは、時間を記録するために 3 種類のデータ型をサ
ポートしています。DATE データ型は日付を格納します。DATETIME データ型は、
時刻を年から 1 秒以下 ( 小数で表現される ) までの精度で記録します。INTERVAL
データ型はある時点からある時点までの時間の間隔、つまり継続時間を格納しま
す。
3-12
Informix Guide to Database Design and Implementation
データ型
日付 : 日付 (DATE) 型
DATE データ型は日付を格納します。DATE の値は、実際には 1899 年 12 月 31 日
午前 0 時を起点として数えた日数を示す符号付き整数として格納されます。通常、
日付型は今世紀の日付を示す正の整数を格納します。
DATE フォーマットは、はるか未来 (58,000 世紀 ) までの日付に対応できる精度を
持っています。負の DATE 値は、起点 (1899 年 12 月 31 日午前 0 時 ) から昔にさか
のぼって数えた日数を意味します。つまり、DATE 値 -1 は 1899 年 12 月 30 日を示
します。
DATE 値は整数のため、Informix データベースサーバで算術式に使用できます。たと
えば、DATE 型列の平均を求めたり、日付型の列に 7 や 365 を加算することができ
ます。さらに、DATE の値を操作するための特別な関数が豊富に用意されています
( 詳細は、『Informix Guide to SQL: Syntax』を参照してください )。
DATE データ型は、項目一つにつき 4 バイトを占有します。算術関数や比較は、
DATE の列に対しては迅速に実行されます。
GLS
日付型フォーマットの選択
日付コンポーネントの表記方法には多くの種類があります。Informix データベース
サーバでは、DATE の値を表示する場合、ユーザが指定した日付型フォーマットを
参照します。デフォルトのロケールは、次のような形式の米国英語の日付型フォー
マットです。
10/25/95
この日付型フォーマットをカスタマイズするには、適切なロケールを選択するか、
環境変数 DBDATE を設定します。詳細は、『Informix Guide to SQL: Reference』を参
照してください。
英語以外の言語については、ロケールファイルの TIME カテゴリで日付型フォー
マットを変更することもできます。ロケールの使用方法についての詳細は、
『Informix Guide to GLS Functionality』を参照してください。
データ型の選択
3-13
データ型
時刻 : 日時 (DATETIME) 型
DATETIME データ型は、西暦 1 年から開始する任意の時刻を格納します。
DATETIME 型は、実際には、精度が異なる 28 種類のデータ型に対する総称です。
DATETIME の列を定義するときには、その精度を指定します。列には、年、月、
日、時間、分、秒および小数から任意のシーケンスを選択して格納することができ
ます。したがって年のみ、月と日のみ、日と単なる時間またはミリ秒まで指定した
時間のみを格納する DATETIME の列を定義することができます。DATETIME の値
のサイズは、図 3-3 に示すように、精度によって 2 から 11 バイトまでの範囲にわた
ります。
DATETIME の利点は、DATETIME が特定の日付と時刻を格納できることです。
DATETIME 列は DATE 列よりも格納領域を多く必要とするのが普通ですが、これ
は使用する DATETIME 修飾子によって異なります。また、DATETIME では、その
表示フォーマットは柔軟性に欠けています。表示フォーマットを変更するには、
3-16 ページの「日時 (DATETIME) 型や時間隔 (INTERVAL) 型のフォーマット」を
参照してください。
精度
サイズ *
精度
サイズ *
year to year
year to month
year to day
year to hour
year to minute
year to second
year to fraction(f)
month to month
month to day
month to hour
month to minute
month to second
month to fraction(f)
day to day
3
4
5
6
7
8
8+f/2
2
3
4
5
6
6+f/2
2
day to hour
day to minute
day to second
day to fraction(f)
hour to hour
hour to minute
hour to second
hour to fraction(f)
minute to minute
minute to second
minute to fraction(f)
second to second
second to fraction(f)
fraction to fraction(f)
3
4
5
5+f/2
2
3
4
4+f/2
2
3
3+f/2
2
2+f/2
1+f/2
* f が奇数の場合は、バイト数は偶数になるように切り上げられます。
3-14
Informix Guide to Database Design and Implementation
図 3-3
日時 (DATETIME) 型の
精度
データ型
継続時間 : 時間隔 (INTERVAL) 型
INTERVAL データ型とは、継続時間、つまり、時間の長さを格納します。二つの
DATETIME 値の差が、その間の時間の長さを表す INTERVAL の値になります。違
いがわかりやすくなるように、例をいくつか示します。
■
ある女性社員が、
1997 年 1 月 21 日 (DATE または DATETIME) に入社しまし
た。
■
彼女は 254 日間勤務しました (INTERVAL の値、TODAY 関数と開始の DATE
または DATETIME の値間の差 )。
■
毎日 9:00 に勤務を開始しました (DATETIME の値 )。
■
昼食に45 分間(別のINTERVALの値) とり
1日8時間(INTERVALの値) 働き、
ます。
■
彼女が勤務を終了する時間は 17 時 45 分 ( 勤務開始時刻を示す DATETIME の
値と二つの INTERVAL の値の合計 ) です。
DATETIME と同様に、INTERVAL は異なる精度を持つ型の集合です。INTERVAL
の値は、年数や月数を表すことができます。また日数、時間数、分数、秒数、秒以
下の数を表すこともできます。18 桁の精度が可能です。INTERVAL の値のサイズ
は、図 3-4 に示すように、公式によって 2 から 12 バイトまでの範囲にわたります。
精度
サイズ *
精度
サイズ *
year(p) to year
year(p) to month
month(p) to month
day(p) to day
day(p) to hour
day(p) to minute
day(p) to second
day(p) to fraction(f)
hour(p) to hour
1+p/2
2+p/2
1+p/2
1+p/2
2+p/2
3+p/2
4+p/2
5+(p+f)/2
1+p/2
hour(p) to minute
hour(p) to second
hour(p) to fraction(f)
minute(p) to minute
minute(p) to second
minute(p) to fraction(f)
second(p) to second
second(p) to fraction(f)
fraction to fraction(f)
2+p/2
3+p/2
4+(p+f)/2
1+p/2
2+p/2
3+(p+f)/2
1+p/2
2+(p+f)/2
1+f/2
図 3-4
時間隔 (INTERVAL)
データ型の精度
* バイト数は偶数になるように切り上げられます。
データ型の選択
3-15
データ型
INTERVAL の値は、正のことも負のこともあります。時間隔 (INTERVAL) 型の値
は加算や減算に使用したり、他の値を掛けたり他の値で割ったりすることもできま
す。日付 (DATE) 型や日時 (DATETIME) 型の値に対しては、このような演算はでき
ません。
「4 月 23 日までの日数の半分は何日か」という問いは理にかなっています
が、
「4 月 23 日の半分は何日か」という問いは無意味です。
日時 (DATETIME) 型や時間隔 (INTERVAL) 型のフォーマット
データベースサーバは常に、INTERVAL や DATETIME の値のコンポーネントを
「年 - 月 - 日時 : 分 : 秒 . 小数秒」のフォーマットで表示します。DATE の値を
フォーマットするとき、オペレーティングシステムに定義された日付型フォーマッ
トは参照されません。
DATETIME の値の日付部分を、システムに定義されているフォーマットで表示す
る場合は、SELECT 文を使用します。次の例に示すように、EXTEND 関数を使用し
てコンポーネントフィールドを分離し、分離したコンポーネントフィールドを
MDY() 関数で DATE に変換します。
SELECT ... MDY (
EXTEND (DATE_RECEIVED, MONTH TO MONTH),
EXTEND (DATE_RECEIVED, DAY TO DAY),
EXTEND (DATE_RECEIVED, YEAR TO YEAR) )
FROM RECEIPTS ...
GLS
日時 (DATETIME) 型フォーマットの選択
Informix データベースサーバでは、DATETIME の値を表示する場合、ユーザが指定
した DATETIME フォーマットを参照します。デフォルトのロケールは、次のよう
な形式の米国英語の DATETIME フォーマットです。
1998-10-25 18:02:13
英語以外の言語については、ロケールファイルの TIME カテゴリで DATETIME
フォーマットを変更することができます。ロケールの使用方法についての詳細は、
『Informix Guide to GLS Functionality』を参照してください。
この DATETIME フォーマットをカスタマイズするには、適切なロケールを選択す
るか、環境変数 GL_DATETIME または DBTIME を設定します。これらの環境変数
についての詳細は、
『Informix Guide to GLS Functionality』を参照してください。
3-16
Informix Guide to Database Design and Implementation
データ型
GLS
文字型
データベースサーバでは、文字 (CHAR) 型、各国語文字 (NCHAR) 型、特殊用途の
文字データ型である各国語可変長文字 (NVARCHAR) 型などの文字型をサポートし
ています。
文字データ : 文字 (CHAR(n)) 型と各国語文字 (NCHAR(n)) 型
CHAR(n) データ型は、n バイトのシーケンスを格納します。これらの文字には英語
と英語以外の文字を混在させることができ、1 バイトまたは複数バイト ( アジア諸
語 ) のいずれかになります。長さ n は、1 から 32,767 の範囲で指定できます。
データベース サーバが CHAR(n) 値を抽出したり格納したりする場合は、正確に n
バイトが転送されます。挿入される値が n バイトよりも短い場合、データベース
サーバは 1 バイトの ASCII 空白文字を使用して、その値を n バイトまで拡張しま
す。挿入される値が n バイトを超過する場合、データベース サーバはエラー メッ
セージを表示させずに超過する分の文字を切り捨てます。したがって、挿入または
更新された値が n バイトを超過していても、CHAR(n) 列および変数データの意味整
合性が強制的に適用されることはありません。
文字 (CHAR) 型列のデータは、コードセットの順序でソートされます。たとえば、
ASCII コードセットでは、a はコードセット値 97、b は 98 などのように値を持って
います。データベースサーバは、CHAR(n) データをこの順序でソートします。
各国語文字 (NCHAR(n)) 型にも連続する n バイトが含まれています。これらの文字
には英語と英語以外の文字を混在させることができ、1 バイトまたは複数バイト (
アジア諸語 ) のいずれかになります。n という長さには CHAR(n) と同じ制限があり
ます。各国語文字 (NCHAR(n)) 型の値が抽出または格納される場合は、正確に n バ
イトが転送されます。データに複数バイトの文字が含まれている場合、転送される
文字数はバイト数より小さくなります。挿入される値が n バイトよりも短い場合、
データベースサーバは 1 バイトの ASCII 空白文字を使用して、その値を n バイトま
で拡張します。
ヒント : データベースサーバは、
ロケールの定義に従って 1 バイトまたは複数バイト
の空白で拡張された値を受け入れます。
データ型の選択
3-17
データ型
データベースサーバは、各国語文字 (NCHAR(n)) 型の列をロケールが指定する順序
でソートします。たとえば、フランス語のロケールでは、ê は e の後、ƒ の前にソー
トされるように指定しています。つまり、フランス語のロケールによって決定され
るソート順序は、e、ê 、ƒ の順になります。ロケールの使用方法についての詳細は、
『Informix Guide to GLS Functionality』を参照してください。
ヒント: CHAR(n)のデータと各国語文字(NCHAR(n))型のデータの違いはソートと比
較の方法です。CHAR(n) 列には英語以外の文字を格納することができます。ただ
し、データベースサーバはコードセット順序を使用して CHAR(n) 列のソートや比
較を行うため、予期した順序の結果が得られない場合もあります。
または各国語文字 (NCHAR(n)) 型の値にはタブと空白を含めてもかまいませんが、
この他の印字不可能な文字は含めないでください。INSERT 文や UPDATE 文を使用
して行を挿入する場合や、ユーティリティプログラムで行をロードする場合には、
印字不可能な文字は入力されません。しかし、埋込み SQL を使用するプログラム
によって行を作成する場合は、NULL(2 進のゼロ ) 文字以外の任意の文字を挿入で
きます。標準的なプログラムやユーティリティは印字不可能な文字を予測していな
いため、印字不可能な文字を文字型の列には格納しないでください。
CHAR(n) や各国語文字 (NCHAR(n)) 型の利点は、すべてのデータベースサーバで使
用できるということです。文字 (CHAR) 型や各国語文字 (NCHAR(n)) 型の唯一の欠
点は固定長であるということです。データ値の長さが行ごとに大きく異なる場合
は、空白部分が無駄になります。
可変長文字 : CHARACTER VARYING(m,r)、可変長文字 (VARCHAR(m,r)) 型、
および各国語可変長文字 (NVARCHAR(m,r)) 型
次のデータ型のそれぞれについて、m は最大バイト数、r は最小バイト数を表しま
す。
ヒント : 可変長文字 CHARACTER VARYING(m,r) データ型は ANSI 標準準拠です。
可変長文字 (VARCHAR(m,r)) 型は Informix データ型です。
3-18
Informix Guide to Database Design and Implementation
データ型
文字型の列に格納されるデータは、長さが一定でないことがよくあります。多くは
平均的な長さで、最大長のデータはわずかにすぎません。このようなデータを格納
する際にディスク領域を節約するため、次のデータ型が用意されています。
■
CHARACTER VARYING(m,r) 。CHARACTER VARYING(m,r) データ型は、
最大 m バイト、最小 r バイトのシーケンスを格納します。このデータ型
は、可変長文字データの ANSI 標準準拠のフォーマットです。可変長文字
CHARACTER VARYING (m,r) は、文字データの比較にコードセット順序を
サポートしています。
■
可変長文字 (VARCHAR(m,r)) 型。可変長文字 (VARCHAR (m,r)) 型は、可変長
の文字列データのための Informix 固有のデータ型です。機能的には可変長
文字 CHARACTER VARYING(m,r) と同じです。
■
各国語可変長文字 (NVARCHAR(m,r)) 型 。各国語可変長文字 (NVARCHAR
(m,r)) 型も、可変長の文字列データのための Informix 固有のデータ型です。
これは、ロケールが指定する順序で文字データを比較します。
ヒント : このデータ比較方法の違いによって、各国語可変長文字 (NVARCHAR(m,r))
型のデータと可変長文字 CHARACTER VARYING(m,r) や可変長文字
(VARCHAR(m,r)) 型のデータが区別されます。ロケールによって決定されるコード
セットとソート順序については、3-17 ページの「文字データ : 文字 (CHAR(n)) 型と
各国語文字 (NCHAR(n)) 型」を参照してください。
これらのデータ型の列を定義する場合、最大バイト数として m を指定します。挿入
される値が m バイトより少ないバイト数で構成されている場合も、CHAR(n) や各
国語文字 (NCHAR(n)) 型の値のように、データベースサーバが 1 バイトの空白でそ
の値を拡張することはありません。その代わりに、実際の内容のみを 1 バイト
フィールドでディスクに格納します。インデックス付き列の上限は 254 バイト、イ
ンデックスなしの列の上限は 255 バイトです。
2 番目のパラメータ r は、ディスクに格納される値に必要なバイト数の下限を設定
するオプションの予約長です。値が r バイトより少ないバイト数のみ必要とする場
合でも、その値を保持するために常に r バイトが割り当てられます。このように下
限を設定するのは、行の更新時間を節約するためです。(3-20 ページの「可変長文
字と実行時間」を参照してください。)
可変長文字 CHARACTER VARYING (m,r) または可変長文字 (VARCHAR (m,r)) 型は、
CHAR(n) と比較して次の利点があります。
■
データ項目に必要なバイト数が広範囲に変化したり、少数の項目のみが平
均以上のバイト数を必要としたりする場合に、ディスク領域を一定に保
つ。
■
小規模な表に対する問合せを高速化できる。
データ型の選択
3-19
データ型
これらの利点は、各国語文字 (NCHAR(n)) 型よりも各国語可変長文字
(NVARCHAR(m,r)) 型に当てはまる特長です。
可変長データ型の欠点は次のとおりです。
■
255 バイトを超える長さは許されない。
■
環境によっては表更新の速度が遅くなる。
■
Informix データベースサーバでは使用できない。♦
可変長文字と実行時間
可変長文字 CHARACTER VARYING(m,r)、可変長文字 (VARCHAR(m,r)) 型、各国語
可変長文字 (NVARCHAR(m,r)) 型のいずれかを使用すると、表の行は固定したバイ
ト数の代わりにさまざまなバイト数を持つことになります。表の行がさまざまなバ
イト数を持っていると、データベース操作の速度はその影響を受けます。
ディスクの 1 ページにより多くの行が格納されるため、データベースサーバは、行
が固定したバイト数を持っている場合より少ないディスク操作で表を探索すること
ができます。その結果、問合せの実行速度は速くなります。挿入操作と削除操作に
ついても、同じ理由から多少速くなることがあります。
行を更新する場合、データベースサーバの作業量は、もとの行のバイト数より新し
い行のバイト数に依存します。新しい行のバイト数がもとの行のバイト数以下であ
れば、実行時間は固定長の行の場合とそれほど変わりません。しかし、新しい行が
もとの行よりかなり多いバイト数を必要とする場合、データベースサーバは多くの
ディスク操作を何回も実行しなければならなくなることがあります。したがって、
CHARACTER VARYING (m,r)、可変長文字 (VARCHAR (m,r) ) 型、各国語可変長文
字 (NVARCHAR(m,r)) 型のデータを使用している表の更新は、固定長フィールドの
更新より速度が遅くなる場合もあります。
このような状況を改善するには、r にデータ項目の高い比率を含むバイト数を設定
することです。これにより、ほとんどの行は予約長を使用するようになり、埋め込
みで無駄になる領域はわずかになります。更新が遅くなるのは、予約バイト数を使
用している値が予約バイト数より長いバイト数を使用している値と置換される場合
のみです。
3-20
Informix Guide to Database Design and Implementation
データ型
ラージキャラクタオブジェクト : テキスト (TEXT) 型
テキスト (TEXT) 型は、テキストデータを格納するためのデータ型です。ビジネス
フォーム、プログラムのソースファイルやデータファイル、メモなどの自己完結型
の文書の格納に適しています。テキスト (TEXT) 型の項目には任意のデータを格納
できますが、Informix ツールではテキスト (TEXT) 型の項目は印字可能であることを
前提にしているため、このデータ型は印字可能な ASCII テキストでなければならな
いという制約があります。
AD/XP
Dynamic Server with AD and XP Options は列でのテキスト (TEXT) データ型をサポート
します。ただし、BLOB 領域にテキスト (TEXT) 型列を格納することも、ストアド
プロシジャのテキスト (TEXT) 型値を使用することもできません。 ♦
テキスト (TEXT) 型の値は、その行の他の列の値と一緒には格納されません。テキ
スト型の列の値に対しては、ディスクページ全体が割り当てられ、そのページは通
常は、行の他の値が格納される領域とは別のところに確保されます。( 詳細につい
ては、お手持ちの『Administrator’s Guide』を参照してください。)
CHAR(n) と VARCHAR(m,r) に対するテキスト (TEXT) 型の利点は、ディスク容量の
範囲内であれば、格納可能なテキストの長さに制限がないことです。テキスト
(TEXT) 型の欠点は以下のとおりです。
■
ディスクページ全体が割り当てられるため、短いデータの場合はディスク
容量が無駄になる。
■
SQL 文でのテキスト (TEXT) 型の列の使用には制約がある (omu を参照 )。
■
Informix データベースサーバでは使用できない。
バイナリー オブジェクト : バイト (BYTE) 型
バイト (BYTE) データ型は、プログラムが生成するあらゆるデータを保持するよう
設計されています。ここで言うデータとは、グラフィック イメージ、プログラムの
オブジェクト ファイル、任意のワード プロセッサやスプレッド シートが保存した
ドキュメントを指します。データベース サーバは、バイト (BYTE) 型列にあらゆる
長さ、かつあらゆる種類のデータを受け入れることができます。
AD/XP
Dynamic Server with AD and XP Options は、列でバイト (BYTE) データ型をサポートし
ます。ただし、BLOB 領域にバイト (BYTE) 型列を格納することも、ストアド プロ
シジャでバイト (BYTE) 型値を使用することもできません。 ♦
テキスト (TEXT) 型の場合と同様に、バイト (BYTE) 型データ項目は通常の行デー
タとは分離され、ディスク領域の全ディスク ページに格納されるのが普通です。
データ型の選択
3-21
データ型
バイト (BYTE) データ型の利点は、テキスト (TEXT) 型や CHAR(n) とは異なり、あ
らゆるデータを受け入れることができるという点にあります。欠点は、テキスト
(TEXT) データ型の場合と同じです。
テキスト (TEXT) とバイト (BYTE) の各データ型の使用方法
テキスト (TEXT) データ型とバイト (BYTE) データ型の列は、ひとまとめにしてバ
イナリラージオブジェクト (BLOB) と総称されます。BLOB については、データ
ベースサーバは格納と取出しだけを行います。通常、テキスト (TEXT) 型値やバイ
ト (BYTE) 型値は、INFORMIX-ESQL/C のような埋込み SQL がサポートしている言
語を使用して作成されたプログラムで取り出され格納されます。このようなプログ
ラムでは、テキスト (TEXT) 型値やバイト (BYTE) 型値の取出し、挿入、更新を、
順次ファイルの読み書きと似た要領で行うことができます。
対話的に実行する SQL 文でも、プログラムに埋め込んで使用する SQL 文でもテキ
スト (TEXT) 型列やバイト (BYTE) 型列は次の箇所では使用できません。
■
算術式やブール式
■
GROUP BY 節や ORDER BY 節
■
UNIQUE 検査
■
インデックス作成については、単独でも、あるいは複合インデックスの一
部としても使用できません。
対話形式で入力される SELECT 文、またはフォームやレポート内の SELECT 文で
は、テキスト (TEXT) 型値やバイト (BYTE) 型値は、次のことが可能になります。
■
名前によって選択できる。部分文字列指定を使用すると、値の一部を取り
出すことができる。
■
LENGTH(< 列 >) 関数を選択すると、その値の長さを戻してもらえる。
■
IS [NOT] NULL 述語を使用することによって、NULL が入っているかどうか
を検査できる。
対話的な INSERT 文では、VALUES 節を使用してテキスト (TEXT) 型値やバイト
(BYTE) 型値を入力することができますが、列に与えることのできる値は NULL の
みです。SELECT 文から取り出した値を使う INSERT 文を使用すれば、別の表のテ
キスト (TEXT) 型値やバイト (BYTE) 型値の値をコピーできます。
対話的な UPDATE 文では、テキスト (TEXT) 型列やバイト (BYTE) 型列を更新して
NULL にしたり、テキスト (TEXT) 型列やバイト (BYTE) 型列を返す副問合わせに
したりすることができます。
3-22
Informix Guide to Database Design and Implementation
NULL 値
データ型の変更
表を作成した後で、ALTER TABLE 文を使用して列に関連付けられたデータ型を変
更することができます。このような変更が必要な場合もありますが、なるべく避け
てください。理由は次のとおりです。
■
データ型を変更するには、データベースサーバは表をコピーして作成し直
さなければなりません。大きな表の場合、コピーと再作成には多大な時間
とディスク領域が必要です。
■
データ型を変更すると、情報を消失することがあります。たとえば、文字
型の列の長さを短くすると、長い値は一部が切り捨てられてしまいます。
数値型の列の精度を低くした場合には、下位の桁が切り捨てられてしまい
ます。
■
既存のプログラム、フォーム、レポート、格納済みの問合せも場合によっ
ては変更が必要になります。
NULL 値
表内の列が NULL を含むように設計することができます。NULL とは、未知のまた
は使用されていない列に対する値のことです。たとえば、第 2 章「リレーショナル
データモデルの作成」の住所録の例では表名前の列 anniv 列に NULL を格納できま
す。記念日がわからない場合は、指定しないでおきます。NULL とゼロ値または空
白値を混同しないように注意してください。
デフォルト値
デフォルト値とは、INSERT 文の中で明示的な値が指定されていない場合に列に挿
入される値のことです。デフォルト値にできるのは、ユーザが定義するリテラル文
字列か、次の SQL の NULL、定数式の定義のうちの一つです。
✮
USER
✮
CURRENT
✮
TODAY
✮
DBSERVERNAME
データ型の選択
3-23
検査制約
デフォルト値を必要としない列もありますが、データモデルを操作していると、デ
フォルト値を使用することによってデータ入力にかかる時間が節約できる場合や、
データ入力エラーを防ぐことができる場合があるということがわかります。たとえ
ば住所録のモデルには列 State があります。この列のデータを見ると、住所の 50
パーセント以上の州がカリフォルニア州であることがわかります。時間を節約する
ためには、文字列「CA」を列 State のデフォルト値として指定します。
検査制約
検査制約によってデータ値に対して条件や要件を指定してからでなければ、
INSERT 文または UPDATE 文の実行中に列を割り当てることはできません。挿入や
更新を行っているときに、表に対して定義した検査制約のいずれかについて行の評
価が偽と判定されると、データベースサーバはエラーを返します。制約を定義する
には、CREATE TABLE 文または ALTER TABLE 文を使用します。たとえば、次の
例は、整数型の列のドメインについての制約で、範囲を制約します。
Customer_Number >= 50000 AND Customer_Number <= 99999
文字型のドメインに対する制約を記述するには、MATCHES 述語やサポートされて
いる正規表現を使用します。次の例は、電話番号の列のドメインを合衆国内の電話
番号の形式に制限する制約です。
vce_num MATCHES ’[2-9][2-9][0-9]-[0-9][0-9][0-9][0-9]’
検査制約についての詳細は、
『Informix Guide to SQL: Syntax』の CREATE TABLE 文
と ALTER TABLE 文を参照してください。
3-24
Informix Guide to Database Design and Implementation
第4章
リレーショナルデータモデル
の実装
データベースの作成 . . . . . . . . . .
CREATE DATABASE 文の使用方法 . . . .
同じ名前の使用は避ける . . . . . .
DB 領域の選択 . . . . . . . . .
トランザクションログ機能のタイプの選択.
CREATE TABLE 文の使用方法 . . . . .
表名でのシノニムの使用方法 . . . . . .
シノニム連鎖の使用方法 . . . . . . .
コマンドスクリプトの使用方法 . . . . .
スキーマの保存. . . . . . . . .
ファイルの実行. . . . . . . . .
デモンストレーションデータベース. . .
データの初期入力 . . . . . . . . .
ソースデータを表にロードする . . . .
一括カード操作の実行. . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4-3
4-4
4-4
4-5
4-5
4-6
4-8
4-9
4-11
4-11
4-11
4-11
4-12
4-12
4-13
4-2
Informix Guide to Database Design and Implementation
この章では、SQL 構文を使用して、第 2 章「リレーショナルデータモデルの作成」
に述べられているデータ モデルを実装する方法について説明します。言い換える
と、この章では、一つのデータベースといくつかの表を作成し、その表をデータで
埋める方法について示します。また、この章ではデータベース ログ オプション、
表シノニム、コマンド スクリプトについても説明します。
データベースの作成
これで、データモデルをデータベースの表として作成する準備が整いました。実際
のデータベースを作成する作業では、CREATE DATABASE 文、CREATE TABLE
文、あるいは CREATE INDEX 文を使用します。
『Informix Guide to SQL: Syntax』で
は、これらの文の構文を詳しく説明しています。ここでは、データモデルを実装す
る場合の CREATE DATABASE 文と CREATE TABLE 文の使用方法を説明します。
住所録のデータモデルが、説明のためだけに使用されていることに注意してくださ
い。例を示すために、データモデルは SQL 文に変換されます。
同じデータベースモデルを 2 回以上作成する必要がある場合もあります。そのよう
な場合、そのモデルを作成する文をファイルに格納しておいて自動的に実行するこ
とができます。詳細は、4-11 ページの「コマンドスクリプトの使用方法」を参照し
てください。
表を作成したら、表にデータの行を入力します。これは、手動か、ユーティリティ
プログラムを使用するか、または特別にプログラミングすることによって行いま
す。
リレーショナルデータモデルの実装
4-3
CREATE DATABASE 文の使用方法
CREATE DATABASE 文の使用方法
データベースは、データモデルのすべての部分を保持する容器です。要素としては
表の他にビュー、インデックス、シノニム、データベースに関連付けられたその他
のオブジェクトがあります。これらの要素を作成するには、まずデータベースを作
成しなければなりません。
GLS
データベースサーバはデータベースを作成するときに、システムカタログにある環
境変数 DB_LOCALE から取り出したデータベースのロケールを格納します。このロ
ケールによって、データベースサーバがデータベースに格納されている文字データ
を解釈する方法が決定されます。デフォルトでは、データベースのロケールは、
ISO 8859-1 コードセットを使用する米国英語のロケールです。別のロケール使用に
ついての詳細は、
『Informix Guide to GLS Functionality』を参照してください。 ♦
データベースサーバは、データベースを作成するときに、データベースの存在とそ
のログ機能のモードを示すレコードをセットアップします。しかし、データベース
サーバはディスク領域を直接管理するため、これらのレコードはオペレーティング
システムのコマンドからはわかりません。
同じ名前の使用は避ける
通常、一つのコンピュータ上ではデータベースサーバの一つのコピーのみが実行さ
れており、そのコンピュータのユーザ全員が使用するデータベースを管理していま
す。データベースサーバが所有しているデータベース名の一覧は一つだけです。各
データベースには、そのデータベースサーバが管理する他のデータベースとは異な
る名前をつけなければなりません。( データベースサーバのコピーを二つ以上実行
することも可能です。たとえば、実際に使用するデータとは別にテスト用の安全な
環境を作成する場合に、データベースサーバのコピーを複数実行することがありま
す。この場合、データベースを作成するときと、このデータベースに後でアクセス
するときに、必ず正しいデータベースサーバを使用してください。)
4-4
Informix Guide to Database Design and Implementation
CREATE DATABASE 文の使用方法
DB 領域の選択
データベースサーバには、データベースを特定の DB 領域に作成するためのオプ
ションがあります。DB 領域はディスク領域の一部に名前が付いたものです。特定
の DB 領域を使用する必要があるかどうかはデータベースサーバ管理者に問い合わ
せてください。データベースを特定の DB 領域に置くと、そのデータベースを他の
データベースから分離したり、そのデータベースを特定のディスク装置に格納した
りすることができます。DB 領域について、および DB 領域とディスク装置との関
係については、
『Administrator’s Guide』を参照してください。複数の DB 領域にま
たがるデータベースの表を断片化する方法については、このマニュアルの第 5 章
「断片化戦略」を参照してください。
一部の DB 領域はミラーリングされています ( 信頼性の向上のために同じデータを
2 台のディスク装置にコピーすることをミラーリングといいます )。内容が特に重要
なデータベースは、ミラーリングされた DB 領域に格納することができます。
トランザクションログ機能のタイプの選択
CREATE DATABASE 文を使用して、ログ付きデータベースあるいはログなしデー
タベースを指定します。データベースサーバには、トランザクションログ機能に関
して次のような選択肢があります。
■
ログ機能をまったく使用しない。この選択はお勧めできません。ハード
ウェア障害が原因でデータベースが失われた場合、最後のバックアップ以
降に行われたデータ変更がすべて失われます。
CREATE DATABASE db_with_no_log
ログ機能を選択しない場合に、トランザクション処理に関連する BEGIN WORK 文
や他の SQL 文をデータベースで使用することができません。このような事態は、
データベースを使用するプログラムの処理内容に影響を及ぼします。
AD/XP
Dynamic Server with AD and XP Options では、ログなしデータベースはサポートしま
せん。ただし、ログなし表はサポートします。ログなし表についての詳細は、7-13
ページの「Dynamic Server with AD and XP Options のログ付き表とログなし表」を参
照してください。 ♦
リレーショナルデータモデルの実装
4-5
CREATE TABLE 文の使用方法
■
通常 ( バッファなし ) のログ機能。この選択は適切であるとはいえません。
障害が発生した場合は、コミットしていないトランザクションのみが失わ
れます。
■
バッファ付きログ機能。データベースを失っても、最新の変更のわずかな
部分を失うのみで、ほとんどの場合まったく失われません。リスクが少な
い代わりに、変更時の性能はほとんど改善されません。
CREATE DATABASE a_logged_db WITH LOG
CREATE DATABASE buf_log_db WITH BUFFERED LOG
バッファ付きログ機能は頻繁に更新されるデータベースに最適ですが、更
新速度が重要になる場合は、クラッシュが発生したときに他のデータから
更新を再作成することができます。バッファ付きログ機能と通常のバッ
ファなしログ機能間の切換えは SET LOG 文を使用して行います。
■
ANSI 標準準拠のログ機能。このログ機能は通常のバッファなしログ機能と
同じですが、トランザクション処理に対する ANSI 規則も適用されます。
ANSI 標準準拠のログ機能の詳細は、『Getting Started』を参照してくださ
い。
CREATE DATABASE std_rules_db WITH LOG MODE ANSI
ANSI 標準の SQL では、バッファ付きログ機能は使用できません。ANSI
標準準拠のデータベースを作成した場合は、トランザクションログ機能を
オフにすることはできません。
データベース サーバ管理者は、後からトランザクション ログをオンにもオフにも
できます (ANSI モードの場合を除く )。たとえば、管理者はトランザクション ログ
をオフにした後で、新しい行を挿入することができます。ANSI 標準準拠でない
データベースに対してログをオフにする方法については、
『Administrator’s Guide』
を参照してください。
CREATE TABLE 文の使用方法
データモデルで設計した表を作成するには CREATE TABLE 文を使用します。
CREATE TABLE 文の記述は複雑になる場合もありますが、基本的には表の列を並
べたものにすぎません。表の各列について、次の情報を指定します。
4-6
■
列の名前
■
データ型 ( 作成した定義域の中のもの )
■
列が主キーの場合は、制約を表すキーワード PRIMARY KEY
Informix Guide to Database Design and Implementation
CREATE TABLE 文の使用方法
■
列が外部キーの場合は、制約を表すキーワード FOREIGN KEY
■
列が主キーではなく、NULL を許さない列の場合は、制約を表すキーワー
ド NOT NULL
■
列が主キーではなく、値の重複を許さない列の場合は、制約を表すキー
ワード UNIQUE
■
列がデフォルト値を持つ場合は、制約を表すキーワード DEFAULT
■
列が検査制約を持つ場合は、制約を表すキーワード CHECK
簡単にいうと、CREATE TABLE 文は、2-33 ページの図 2-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),
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)
);
リレーショナルデータモデルの実装
4-7
表名でのシノニムの使用方法
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
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
4-8
Informix Guide to Database Design and Implementation
シノニム連鎖の使用方法
CREATE SYNONYM 文では、シノニム名を現行データベースのシステム カタログ
表 syssyntable に格納します。現行データベースで作成された問合せであれば、いず
れもこのシノニムを使用することができます。
短いシノニムを使用すると、問合せを書くのが容易になりますが、シノニムは別の
役割を果たすこともできます。シノニムを使用すると、問合せを変えずに、表を別
のデータベースやコンピュータに移動することができます。
たとえば、表 customer と表 orders を参照する問合せが複数あるとします。これらの
問合せは、プログラムやフォーム、レポートに埋め込まれています。これらの表は
デモンストレーション データベースの一部で、このデータベースはデータベース
サーバ avignon に置かれています。
ここで、ネットワークに接続された別のコンピュータ ( データベース サーバ nantes)
のユーザも、同じプログラム、フォーム、レポートが使用できるようにすると決定
したとします。これらのユーザは、その地域での注文が含まれている orders という
名前の表が入っているデータベースを持っていますが、avignon にある表 customer
にアクセスする必要があります。
データベース サーバ nantes のユーザにとって、表 customer は外部表です。これは、
特殊なバージョンのプログラムやレポート、つまり、表 customer をデータベース
サーバ名で修飾するバージョンを作成しなければならない、ということになるので
しょうか。もっとよい解決策は、次の例に示すように、これらのユーザのデータ
ベースにシノニムを作成することです。
DATABASE stores7@nantes;
CREATE SYNONYM customer FOR stores7@avignon:customer;
格納済みの問合せがご使用のデータベースで実行される場合、名前 customer は実際
の表を参照します。この問合せがその他のデータベースで実行される場合、名前
customer はシノニムを介して、データベース サーバ avignon にある表の参照となる
よう変換されます。
シノニム連鎖の使用方法
前述の例を続けるために、ネットワークにコンピュータが新たに接続されたと仮定
します。そのコンピュータの名前は db_crunch です。avignon の負荷を減らすため
に、表 customer などの表は db_crunch に移動することにします。表 customer は新し
いデータベース サーバ上で簡単に再作成できますが、すべてのアクセスをこの表に
向けるにはどうすればよいでしょうか。一つの方法は、次の例に示すように、シノ
ニムをインストールし古い表を置き換えることです。
DATABASE stores7@avignon EXCLUSIVE;
RENAME TABLE customer TO old_cust;
CREATE SYNONYM customer FOR stores7@db_crunch:customer;
CLOSE DATABASE;
リレーショナルデータモデルの実装
4-9
シノニム連鎖の使用方法
stores7@avignon 内で問合せを実行すると、表 customer に対する参照によって、シ
ノニムが見つかり、新しいコンピュータ上のバージョンに向けられます。また、こ
のような宛先変更は、前述の例におけるデータベース サーバ nantes から実行される
問合せに対しても起こります。データベース stores7@nantes のシノニムによって、
表 customer への参照は、いまだにデータベース stores7@avignon に向けられていま
すが、新しいシノニムによって、その問合せはデータベース store7@db_crunch に送
られます。
この例のように、シノニムの連鎖は、1 回の操作ですべてのアクセスを目的の表に
向けたい場合に役立ちます。ただし、できる限り早く全ユーザのデータベースを更
新して、これらのシノニムが目的の表を直接指せるようにしなければなりません。
これを行わないと、データベース サーバが余分なシノニムを取り扱う場合に、余分
なオーバーヘッドが発生するほか、連鎖内のいずれかのコンピュータがダウンする
と、その表を見つけられなくなります。
一つのアプリケーションをローカル データベースに対して実行し、後で同じアプリ
ケーションを別のコンピュータ上のデータベースに対して実行することもできま
す。プログラムは、どちらの場合も同じように順調に実行されますが、ネットワー
ク データベース上では、実行速度が遅くなることがあります。データ モデルが同
じである限り、プログラムでは、ローカル データベース サーバとリモート データ
ベース サーバを区別することはできません。
4-10
Informix Guide to Database Design and Implementation
コマンドスクリプトの使用方法
コマンドスクリプトの使用方法
データベースと表は、文を対話的に入力することによって作成できます。場合に
よってはこの操作を 2 回以上繰り返さなければならないことがあります。
たとえば、データベースの再作成は、試験バージョンが正常に動作した後で本稼動
バージョンを作成するときに必要になります。また、同じデータモデルを複数のコ
ンピュータについて実装しなければならない場合も、データベースの再作成が必要
になります。このような場合、データベースを作成するすべての文をファイルに書
き込んでおき自動的に実行するようにすれば、時間を節約できるとともに、エラー
の発生を減らすことができます。
スキーマの保存
データモデルを実装する文は、手動で書き込むこともできますが、プログラムでこ
の作業を行うことも可能です。dbschema は、データベースの内容を検査し、再作成
するために必要なすべての文を生成するユーティリティです。データベースの最初
のバージョンは、対話的に作成できます。対話的に修正を加えて必要なデータベー
スが完成したあとに dbschema を使用すれば、そのデータベースの再作成に必要な
SQL 文を生成できます。dbschema ユーティリティについては『Informix Migration
Guide』を参照してください。
ファイルの実行
DB-Access やリレーショナルオブジェクトマネージャなどの、SQL 文を対話形式で
入力するのに使用するプログラムは、コマンドファイルで操作することができま
す。DB-Access やリレーショナルオブジェクトマネージャを起動し、ユーザや
dbschema ユーティリティが作成したコマンドファイルを読み込ませて実行させるこ
とができます。詳細は『DB-Access User Manual』やリレーショナルオブジェクトマ
ネージャのマニュアルを参照してください。
デモンストレーションデータベース
ほとんどの Informix データベースサーバ製品は、デモンストレーションデータベー
スを備えています ( このデータベースは本書の例で使用されます )。デモンスト
レーションデータベースは、このデータベースを作成するために製品を呼び出すオ
ペレーティングシステムのコマンドスクリプトの形で配布されます。このコマンド
スクリプトをコピーして、自分のデータモデルを自動作成するための原型として使
用することができます。
リレーショナルデータモデルの実装
4-11
データの初期入力
データの初期入力
初期テストを行う際、対話形式で表にデータを入力するもっとも簡単な方法は、
DB-Access またはリレーショナルオブジェクトマネージャで INSERT 文を入力する
ことです。デモンストレーションデータベースの表 manufact に行を入力するには、
DB-Access で次のコマンドを入力します。
INSERT INTO manufact VALUES (’MKL’, ’Martin’, 15)
別の言語で作成したアプリケーションプログラムがあれば、そのプログラムを使用
して行を入力することができます。
大きな表に初期の行を入力する場合、別のデータベースやオペレーティングシステ
ムファイルの表に格納されているデータを持ってくるという方法もよく取られま
す。その場合は、そのデータを新しいデータベースに一括して挿入することができ
ます。そのデータが他の Informix データベースに格納されている場合は、数通りの
方法でそのデータを取り出すことができます。
データベースの INSERT 文の一部で、別のデータベースサーバ上の他のデータベー
スにある目的のデータを選択することができます。次の例に示すように、デモンス
トレーションデータベースの表 items の情報を選択できます。
INSERT INTO newtable
SELECT item_num, order_num, quantity, stock_num,
manu_code, total_price
FROM stores7@otherserver:items
ソースデータを表にロードする
別の種類のファイルやデータベースがデータの元である場合は、それをフラットな
テキストファイルに変換する方法を探す必要があります。フラットなテキストファ
イルとは、印刷不可能な文字を含まないファイルで、ファイルの各テキスト行が表
の 1 行の内容を表しているものです。
データをファイルに格納した後は、dbload ユーティリティを使用してそのデータを
表にロードすることができます。dbload ユーティリティについての詳細は、
『Informix Migration Guide』を参照してください。DB-Access の LOAD 文も、フラッ
トなテキストファイルから行をロードすることができます。LOAD 文と UNLOAD
文についての詳細は、
『Informix Guide to SQL: Syntax』を参照してください。
AD/XP
4-12
データをファイルに格納した後は、外部表を使用して、そのデータを表にロードす
ることができます。外部表についての詳細は、お手持ちの『Administrator’s Guide』
を参照してください。 ♦
Informix Guide to Database Design and Implementation
データの初期入力
一括カード操作の実行
数百行や数千行の行を挿入する場合は、トランザクションログ機能をオフにするこ
とで、時間を大幅に短縮できます。ただし、このような挿入操作をトランザクショ
ンログに記録しても意味がありません。障害が発生して操作結果が失われても、簡
単に復元できるからです。大量のデータを一括ロードする手順を次に示します。
■
そのデータベースを他のユーザが使用している可能性が少しでもある場合
は、DATABASE EXCLUSIVE 文でそのデータベースに排他ロックを設定し
ます。
■
管理者に依頼してデータベースのログ機能をオフにしてください。
既存のログはデータベースを現在の状態に復旧するのに使用できるため、
データベースが失われた場合、行を復旧するために繰り返して大量挿入を
行うことができます。
Dynamic Server with AD and XP Options のログ機能をオフにすることはでき
ません。しかし、データベースにログなし表（フォーマットされていない
永続表または静的永続表）を作成することができます。 ♦
AD/XP
■
表にデータをロードする文かユーティリティを実行します。
■
新しくロードされたデータベースをバックアップします。
管理者に依頼して全バックアップまたは差分バックアップを行うか、
onunload ユーティリティを使用して使用中のデータベースだけのバイナリ
コピーをとってください。
■
トランザクションログ機能を復元し、データベースの排他ロックを解除し
ます。
データベースにデータを初期入力する手順は、オペレーティングシステムコマンド
のスクリプトに格納することができます。ON-Monitor に相当するコマンド行を起動
することによって、データベースサーバ管理者コマンドの実行を自動化することが
できます。
リレーショナルデータモデルの実装
4-13
第5章
断片化戦略
断片化とは . . . . . . . . . . . . . . .
Dynamic Server with AD and XP Options の断片化の機能強化
断片化を使用する理由 . . . . . . . . . . .
断片化の責任者 . . . . . . . . . . . . .
断片化とログ . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
表断片化に対する分散スキーム . . . . . . . . . . . .
ラウンドロビン分散スキーム . . . . . . . . . . . .
式に基づいた分散スキーム . . . . . . . . . . . .
範囲規則. . . . . . . . . . . . . . . . .
任意規則. . . . . . . . . . . . . . . . .
式に基づいた分散スキームでの MOD 関数の使用方法 . . .
式に基づいたフラグメントの行の挿入と更新 . . . . . .
システム定義ハッシュ分散スキーム . . . . . . . . . .
ハイブリッド分散スキーム . . . . . . . . . . . .
データベース サーバが検索からフラグメントを除去できる場合 . .
フラグメント除去の問合せ式. . . . . . . . . . .
フラグメント除去の式に基づいた分散スキーム . . . . .
Dynamic Server のフラグメント除去の要約 . . . . . . .
Dynamic Server with AD and XP Options のフラグメント除去の要約
.
.
.
.
.
.
.
.
.
.
5-3
5-6
5-6
5-8
5-8
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5-9
5-11
5-11
5-12
5-12
5-13
5-13
5-13
5-14
5-15
5-16
5-16
5-20
5-21
断片化された表の作成 . . . . . . . . . . . . .
断片化された表を新たに作成する . . . . . . . . .
断片化されていない表からの断片化された表の作成 . . .
複数の断片化されていない表からの表の作成 . . . .
1 つの断片化されていない表からの断片化された表の作成
5-2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5-26
5-27
5-28
5-29
5-29
断片化された表の更新 . . . . . . . . . . . . . . . .
断片化戦略の変更 . . . . . . . . . . . . . . . .
断片化機構を完全に再初期化するために INIT 節を使用する方法. .
MODIFY 節を使用して、Dynamic Server の既存の断片化戦略を変更
する方法 . . . . . . . . . . . . . . .
ATTACH と DETACH を使用して Dynamic Server with AD and XP
Options の既存の断片化戦略を変更する方法 . . . . .
新規フラグメントの追加 . . . . . . . . . . . . .
フラグメントの削除. . . . . . . . . . . . . . .
.
.
.
5-30
5-30
5-31
.
5-32
.
.
.
5-33
5-34
5-35
一時表の断片化 . . . . . . . . . . . . . . . . .
Dynamic Server with AD and XP Options の一時表の断片化 . . . .
ユーザ固有の断片化戦略の定義 . . . . . . . . . .
Dynamic Server with AD and XP Options に動的に断片化戦略を定義
させる方法 . . . . . . . . . . . . . .
. .
. .
. .
5-37
5-37
5-37
. .
5-38
表インデックスの断片化 . . . . . . . .
添付インデックス . . . . . . . .
独立インデックス . . . . . . . .
行識別子 . . . . . . . . . . .
行識別子列の作成 . . . . . . .
行識別子列を作成すると何が実行されるか
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5-39
5-39
5-40
5-41
5-41
5-42
断片化された表に格納されているデータへのアクセス
行識別子の代わりに主キーを使用する . . .
Dynamic Server の断片化された表の行識別子
断片化された表の行識別子列の作成 . . .
フラグメントアクセス権の付与と取消し. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5-42
5-42
5-43
5-43
5-44
Informix Guide to Database Design and Implementation
この章では、ご使用のデータベース サーバでサポートされている各種断片化戦略に
ついて説明します。また、断片化戦略を実現する方法についても説明します。次の
トピックについて説明します。
■
断片化とは
■
表フラグメントに応じた分散スキーム
■
断片化された表の作成
■
断片化された表の変更
■
一時表の断片化
■
表インデックスの断片化
■
断片化された表に格納されているデータへのアクセス
この章に記載されている情報は、次のデータベース サーバだけに適用されます。
■
Informix Dynamic Server
■
Informix Dynamic Server with Advanced Decision Support and Extended Parallel
Options
断片化戦略を組み立てる方法については、お手持ちの『Performance Guide』を参照
してください。
断片化とは
断片化とは、データベース サーバ機能の 1 つであり、この機能を使用すれば、表レ
ベルでデータを格納する場所を制御できます。断片化を使用すれば、何らかのアル
ゴリズムまたはスキームに基づいて、任意の表内に、行またはインデックス キーの
グループを定義することができます。各グループまたはフラグメント ( パーティ
ションと呼ばれることもある ) は、特定物理ディスクと関連付けられている別個の
DB 領域に格納することができます。フラグメントを作成したら、SQL 文で、その
フラグメントを DB 領域に割り当てます。
断片化戦略
5-3
断片化とは
行またはインデックス キーをグループ化してしフラグメントにするときに使用する
スキームは、分散スキームと呼ばれます。この分散スキームと、フラグメントを一
緒に配置する DB 領域のセットにより、断片化戦略が構成されます。断片化戦略を
組み立てるときに必要な意思決定については、お手持ちの『Performance Guide』を
参照してください。
表行、インデックス キー、またはその両方を断片化するかどうかを決め、その行ま
たはキーを複数のフラグメントに分散する方法を決めたら、この分散を実現するス
キームを決めます。
データベース サーバは、次の分散スキームをサポートしています。
■
ラウンドロビン分散スキーム この型の断片化では、フラグメント内に
順々に行を配置し、一連のフラグメントを循環して、行を均等に分散しま
す。
INSERT 文では、データベース サーバは、乱数に基づいてハッシュ関数を
使用して、行を配置するフラグメントを特定します。
INSERT カーソルでは、データベース サーバは、ランダムに決めたフラグ
メントに最初の行を配置し、次の順次フラグメントに 2 番目の行をという
ように順次配置していきます。フラグメントの 1 つがいっぱいであれば、
そのフラグメントはスキップされます。
AD/XP
■
式に基づいた分散スキーム この型の断片化では、指定の値が含まれてい
る行は、同じフラグメントに配置されます。各フラグメントに行のセット
を割り当てる基準を定義する断片化式を範囲規則または任意規則として指
定します。残余フラグメントを指定すれば、ほかのどのフラグメントの基
準とも一致しない行をすべて保持することができます。ただし、残余フラ
グメントを指定すると、式に基づいた分散スキームの効率が低下します。
■
システム定義ハッシュ分散スキーム この型の断片化では、内部システム
定義規則を使用して、各フラグメント内に同数の行を保持することを目的
として行を分散します。
■
ハイブリッド分散スキーム この型の断片化では、2 つの分散スキームが
組み合わされます。主分散スキームでは、DB スライスが選択されます。
副分散スキームでは、DB スライス内の特定 DB 領域に行が配置されます。
DB 領域は、通常、各種コサーバ上に常駐しています。 ♦
エンド ユーザまたはクライアント アプリケーションの観点から見れば、断片化さ
れた表と、断片化されていない表は同じです。クライアント アプリケーションで
は、断片化された表内のデータにアクセスできるようにするのに、どのような変更
も必要ありません。
5-4
Informix Guide to Database Design and Implementation
断片化とは
データベース サーバは、各表フラグメントとインデックス フラグメントの位置を、
ほかの関連情報とともに、sysfragments と命名されたシステム カタログ表に格納し
ます。この表を使用すれば、断片化された表とインデックスに関する情報にアクセ
スできます。このシステム カタログ表に格納されている情報のリストについての詳
細は、
『Informix Guide to SQL: Reference』を参照してください。
データベース サーバは、どのフラグメントにどのデータが格納されているかに関す
る情報を使用できるため、関連フラグメントにアクセスしなくても、データのクラ
イアント要求を、適切なフラグメントにルーティングすることができます。図 5-1
を参照してください ( ただし、ラウンドロビン分散スキーム、またはすべての式分
散スキームでは、この文は当てはまりません。詳細は、5-9 ページの「表断片化に
対する分散スキーム」を参照してください )。
クライアント アプ
リケーション
クライアント
図 5-1
クライアント アプリ
ケーションからのデー
タ要求のデータベース
サーバによるルーティ
ング
クライアント
クライアント
アプリケーショ
ンの観点から見
た表
データベース
サーバの観点か
ら見た表
ディスク
断片化戦略
5-5
Dynamic Server with AD and XP Options の断片化の機能強化
AD/XP
Dynamic Server with AD and XP Options の断片化の機能強化
Dynamic Server with AD and XP Options は、異なるコサーバに属する複数のディスク
間で表を断片化することができます。各表フラグメントは、異なるコサーバに属す
る複数の物理ディスクと関連付けられた別個の DB 領域に常駐することができま
す。DB スライスには、複数のコサーバ間で数多くの DB 領域を管理する機構が備
わっています。DB スライスと DB 領域を作成すると、複数のコサーバ間で断片化
された表を作成することができます。
複数のコサーバ間で表を断片化する利点については、お手持ちの『Performance
Guide』を参照してください。DB スライスと DB 領域の作成方法については、お手
持ちの『Administrator’s Guide』を参照してください。
断片化を使用する理由
次の目標のうち 1 つでも当てはまるものがあれば、表の断片化を検討してくださ
い。
■
単一ユーザ応答時間の向上
並列データベース問合せ (PDQ) とともに断片化を使用して、複数のディス
ク (Dynamic Server と Dynamic Server with AD and XP Options)、または複数
のコサーバ (Dynamic Server with AD and XP Options) に分散しているフラグ
メントを並列で走査すると、個々の問合せの性能を向上させることができ
ます。PDQ については、お手持ちの『Administrator’s Guide』を参照してく
ださい。PDQ と断片化の性能問題については、お手持ちの『Performance
Guide』を参照してください。
■
同時実行性の向上
断片化を使用すれば、大型で使用頻度の高い表に配置されているデータの
競合を減らすことができます。断片化を使用すると競合が減るのは、各フ
ラグメントが別個の入出力デバイスに常駐するからです。また、データ
ベース サーバは、適切なフラグメントに問合せを送ります。
5-6
Informix Guide to Database Design and Implementation
断片化を使用する理由
■
可用性の向上
断片化を使用すれば、データの可用性を向上させることができます。断片
化が使用できなくなっても、データベース サーバは、まだ、残余フラグメ
ントにアクセスできます。アクセスできないフラグメントをスキップする
方法については、お手持ちの『Administrator’s Guide』を参照してくださ
い。
■
バックアップと復元の特性の向上
断片化を使用すると、バックアップと復元の細分性をよりきめ細かくする
ことができます。この細分性を使用することにより、バックアップと復元
の操作にかかる時間を短くすることができます。さらに、ON-Bar または
ON-Archive を使用すれば、バックアップと復元の操作を並列に実行して、
性能を向上させることができます。ON-Bar バックアップと復元のシステ
ムについての詳細は、お手持ちの『Backup and Restore Guide』を参照して
ください。
ON-Archive についての詳細は、お手持ちの『Archive and Backup Guide』を
参照してください。 ♦
IDS
AD/XP
■
データ ロード性能の向上
非常に大規模なデータベースをロードする性能を向上させるには、外部表
とともに断片化を使用します。外部表を使用してデータベースをロードす
る方法についての詳細は、お手持ちの『Administrator’s Guide』を参照して
ください。
Dynamic Server with AD and XP Options は、外部表を使用して、複数のコ
サーバ間で断片化された表をロードする場合、データをフラグメントに並
列にロードするようにスレッドを割り当てます。フラグメント ( 別のコ
サーバに配置された ) を表に追加すると、そのたびに、ほぼ線形の性能向
上が期待できます。 ♦
前記の目標は、それぞれ、最終的に実現する断片化戦略に独自の影響を与えます。
これらの目標についての詳細は、お手持ちの『Performance Guide』の断片化戦略の
立て方に関する説明を参照してください。
使用する主要な断片化目標により、断片化戦略の実現方法が決まるか、あるいは少
なくとも影響を受けることになります。
断片化を使用して前記の目標のどれかが満たされるかどうかを決める場合、断片化
には何らかの管理活動や監視活動が余分に必要になることを念頭に入れておいてく
ださい。
断片化戦略
5-7
断片化の責任者
断片化の責任者
断片化に関して、データベース サーバ管理者の責任とデータベース管理者 (DBA)
の責任は、一部重複します。DBA は、データベース スキーマを作成します。この
スキーマには、表フラグメントを含めることができます。一方、データベース サー
バ管理者は、断片化された表が常駐するディスク領域を割り当てることに責任を持
ちます。こうした責任は、どちらも単独に実行することはできません。このため、
断片化を実現するには、データベース サーバ管理者と DBA の協力作業が必要にな
ります。このマニュアルでは、断片化戦略を実現するのに DBA が実行するタスク
についてだけ説明します。断片化戦略を実現するのにデータベース サーバ管理者が
実行するタスクについては、お手持ちの『Administrator’s Guide』と『Performance
Guide』を参照してください。
断片化とログ
IDS
Dynamic Server では、断片化された表は、ログ付きデータベースにもログなしデー
タベースにも属することができます。断片化されていない表と同様に、断片化され
た表がログなしデータベースの一部になっている場合、障害が発生すると、データ
の矛盾が発生する可能性があります。 ♦
AD/XP
Dynamic Server with AD and XP Options では、断片化された表は必ず、ログを使用す
るデータベースに属します。Dynamic Server with AD and XP Options では、複数のロ
グ付き表型とログなし表型はサポートされていません。詳細は、7-13 ページの
「Dynamic Server with AD and XP Options のログ付き表とログなし表」を参照してくだ
さい。 ♦
5-8
Informix Guide to Database Design and Implementation
表断片化に対する分散スキーム
表断片化に対する分散スキーム
分散スキームとは、行またはインデックスのエントリを複数のフラグメントに分散
するときにデータベース サーバが使用する方法の 1 つです。Dynamic Server、およ
び Dynamic Server with AD and XP Options は、種々の分散スキームをサポートしま
す。
IDS
図 5-2 に、Dynamic Server がサポートしている分散スキームを示します。
図 5-2
Dynamic Server の分散スキームと断片化規則
分散スキーム
ラウンドロビン
式に基づいた
Dynamic Server は内部的
に規則を定義する。
ユーザは、規則を定義し、
CREATE TABLE 文と CREATE
INDEX 文の一部としてこの規則を
指定する。
ユーザは次の型の規則を定義できる。
範囲規則
任意規則
♦
断片化戦略
5-9
表断片化に対する分散スキーム
AD/XP
図 5-3 に、Dynamic Server with AD and XP Options がサポートしている分散スキームを
示します。
図 5-3
Dynamic Server with AD and XP Options の分散スキームと断片化規則
分散スキーム
ラウンドロビン
式に基づいた
システム定義ハッシュ
ハイブリッド
Dynamic Server は内部的
に規則を定義する。
ユーザは、規則を定義し、
CREATE TABLE 文と
CREATE INDEX 文の一部と
してこの規則を指定する。
ユーザは次の型のどちら
かの規則を定義できる。
範囲規則
任意規則
データベース サーバは内
部的に規則を定義する。
システム定義ハッシュ分
散スキームと式に基づい
た分散スキームを組み合
わせる。
♦
以降の項では、ご使用のデータベース サーバに使用できる分散スキームについて説
明します。
分散スキームに応じた SQL 構文についての詳細は、
『Informix Guide to SQL: Syntax』
の CREATE TABLE 文と CREATE INDEX 文を参照してください。
断片化戦略を組み立てる方法については、お手持ちの『Performance Guide』を参照
してください。
5-10
Informix Guide to Database Design and Implementation
ラウンドロビン分散スキーム
ラウンドロビン分散スキーム
ラウンドロビン分散スキームを指定するには、次のように CREATE TABLE 文の
FRAGMENT BY ROUND ROBIN 節を使用してください。
CREATE TABLE account...FRAGMENT BY ROUND ROBIN IN dbspace1, dbspace2, dbspace3
データベース サーバは、ラウンドロビン分散を使用する表に数多くの行を挿入する
要求を受信した場合、各フラグメント内の行の数がほぼ同じ状態になるように行を
分散します。ラウンドロビン分散は、情報が複数のフラグメントに均等に分散され
るため、均等分散とも呼ばれます。表でラウンドロビン分散を使用する場合、この
表に行を分散する規則は、データベース サーバの内部規則です。
重要 : ラウンドロビン分散スキームは、表行の断片化だけに使用できます。表イン
デックスの断片化には使用できません。5-39 ページの「表インデックスの断片化」
を参照してください。
式に基づいた分散スキーム
式に基づいた分散スキームを使用するには、CREATE TABLE 文または CREATE
INDEX 文の FRAGMENT BY EXPRESSION 節を使用してください。この節は、次の
フォームをとります。
CREATE TABLE tablename ... FRAGMENT BY EXPRESSION
<expression_1> IN dbspace_1
<expression_2> IN dbspace_2
.
.
.
<expression_n> IN dbspace_n;
CREATE TABLE 文または CREATE INDEX 文の FRAGMENT BY EXPRESSION 節を
使用して、断片化された表を作成する場合には、作成する表のフラグメントごとに
条件を 1 つ指定する必要があります。
範囲規則または任意規則を定義すると、複数のフラグメントに行をどのように分散
すればよいか、データベース サーバに示すことができます。以降の項では、式に基
づいた分散スキームの 3 つの型をすべて説明します。
断片化戦略
5-11
式に基づいた分散スキーム
範囲規則
範囲規則は、SQL 関係演算子と論理演算子を使用して、表内の各フラグメントの境
界を定義します。範囲規則には、次の演算子の制限付きセットを使用することがで
きます。
■
関係演算子 >、<、>=、<=
■
論理演算子 AND
範囲規則は、表内の列を 1 列だけ参照することができますが、この列への複数参照
は実行できません。次の例に記載されているように、表内のフラグメントごとに式
を 1 つ定義します。
.
.
.
FRAGMENT BY EXPRESSION
id_num > 0 AND id_num <= 20 IN dbsp1,
id_num > 20 AND id_num <= 40 IN dbsp2,
id_num > 40 IN dbsp3
任意規則
任意規則は、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-12
Informix Guide to Database Design and Implementation
システム定義ハッシュ分散スキーム
IDS
式に基づいた分散スキームでの MOD 関数の使用方法
Dynamic Server では、FRAGMENT BY EXPRESSION 節で MOD 関数を使用して、表
内の各行を整数 ( ハッシュ値 ) のセットにマッピングすることができます。データ
ベース サーバは、これらの値を使用して、所定の行を格納するフラグメントを決め
ます。次の例では、式に基づいた分散スキームでの MOD 関数の使用方法を示しま
す。
.
.
.
FRAGMENT BY EXPRESSION
MOD(id_num, 3) = 0 IN dbsp1,
MOD(id_num, 3) = 1 IN dbsp2,
MOD(id_num, 3) = 2 IN dbsp3
式に基づいたフラグメントの行の挿入と更新
行を挿入または更新する場合、データベース サーバは、指定された順序でフラグメ
ント式を評価して、その行がフラグメントのどれかに属しているかどうかを調べま
す。属していれば、データベース サーバは、フラグメントの 1 つにその行を挿入す
るか、フラグメントの 1 つでその行を更新します。フラグメントのどれにも属して
いなければ、その行は残りの節で指定されたフラグメント内に配置されます。分散
スキームに残りの節が含まれていない場合で、その行が既存のどのフラグメント式
の基準とも一致しない場合は、データベース サーバは、エラーを返します。
AD/XP
システム定義ハッシュ分散スキーム
システム定義ハッシュ分散スキームでは、Dynamic Server with AD and XP Options は、
フラグメントにほぼ同数の行が保持されるように、レコードを挿入して行を分散さ
せるときに、指定の DB 領域間で負荷平衡をとります。
システム定義ハッシュ分散スキームを指定するには、次のように、CREATE TABLE
文で FRAGMENT BY HASH 節を使用してください。
CREATE TABLE tablename...FRAGMENT BY HASH (column list)
IN dbspace1, dbspace2, dbspace3
断片化戦略
5-13
ハイブリッド分散スキーム
システム定義ハッシュ分散スキームでは、フラグメントを配置する DB 領域を少な
くとも 2 つ指定するか、DB スライスを 1 つ指定してください。
また、システム定義ハッシュ分散スキームに複合キーを指定することもできます。
Dynamic Server with AD and XP Options では、ある表がシステム定義ハッシュで断片
化される場合に、この表に数多くの行を挿入する要求を受信すると、各フラグメン
ト内の行の数がほぼ同じ状態になるように行を分散します。システム定義ハッシュ
で断片化された複数の表に行を分散する規則は、Dynamic Server with AD and XP
Options の内部的な規則です。
ヒント : 非常に大規模なデータベースを数多くのコサーバ間で断片化することがあ
ります。この場合、2 つの表の結合に使用されるキーに関するシステム定義ハッ
シュによって断片化することをお勧めします。コサーバ間やコサーバ結合間での表
の断片化については、お手持ちの『Performance Guide』を参照してください。
システム定義ハッシュ分散スキームの SQL 構文については、
『Informix Guide to
SQL: Syntax』の ALTER FRAGMENT 文と CREATE TABLE 文を参照してください。
AD/XP
ハイブリッド分散スキーム
ハイブリッド分散スキームは、システム定義ハッシュ分散スキームと式に基づいた
分散スキームを組み合わせたものです。ハイブリッド分散スキームを指定するに
は、CREATE TABLE 文の FRAGMENT BY HYBRID 節を使用してください。この節
は、次のフォームをとります。
... FRAGMENT BY HYBRID (column list)
EXPRESSION
<expression_1> IN dbslice_1,
<expression_2> IN dbslice_2,
.
.
.
<expression_n> IN dbslice_n
5-14
Informix Guide to Database Design and Implementation
データベース サーバが検索からフラグメントを除去できる場合
データベース サーバは、ハイブリッド断片化を使用する表に数多くの行を挿入する
要求を受信すると、次のように、その行を分散します。
■
ハイブリッド分散スキームの式に基づいた部分を使用して、その行を格納
する DB スライスを決定します。
■
ハイブリッド分散スキームのハッシュ部分を使用して、その行を格納する (
事前に決定された DB スライスの )DB 領域を決定します。
次の CREATE TABLE 文には、表の 2 つの列に基づくハイブリッド分散スキームが
使用されています。表に値を挿入すると、データベース サーバは、col_2 の値を使
用して、その行を格納する DB スライスを決定します。データベース サーバは、
col_1 に対してハッシュ値を生成して、その行を格納する DB スライス内の DB 領域
を決定します。
CREATE TABLE my_table (col_1 INT, col_2 DATE, col_3 CHAR(4))
HYBRID (col_1) EXPRESSION
col_2 < '01/01/1996' IN dbsl_1,
col_2 >= '01/01/1996' AND col_2 < '01/01/1997' IN dbsl_2,
REMAINDER IN dbsl_3;
データベース サーバが検索からフラグメントを除去できる場
合
適切な分散スキームを使用すると、データベース サーバは、検索からフラグメント
を除去してから、実際の検索を実行することができます。この機能を使用すれば、
性能を大幅に向上させ、フラグメントが常駐しているディスクの競合を減らすこと
ができます。
データベース サーバが検索からフラグメントを除去できるかどうかは、次の 2 つの
要因によって異なります。
■
問合せ式のフォーム (WHERE 節内の式 )
■
検索されている表の分散スキーム
断片化戦略
5-15
データベース サーバが検索からフラグメントを除去できる場合
フラグメント除去の問合せ式
次の 2 種類の問合せ式を使用すれば、フラグメントを除去することができます。
■
範囲式
■
等式
次の問合せ式テンプレートがあるとします。
column operator value
範囲式は、関係演算子 (<、>、<=、>=) を使用し、等式は等演算子 (=、IN) を使用し
ます。どちらの問合せ式でも、その値は、リテラル、ホスト変数、ストアド プロシ
ジャ変数、または非相関副問合せである必要があります。
AD/XP
Dynamic Server with AD and XP Options では、範囲式または等式内の値は、リテラル
またはホスト変数である必要があります。この値は、ストアド プロシジャまたは非
相関副問合せとすることはできません。 ♦
フラグメント除去の式に基づいた分散スキーム
ラウンドロビン分散スキームを使用して表を断片化する場合、データベース サーバ
は、フラグメントを除去できません。さらに、使用するデータベース サーバによっ
ては、式に基づいた分散スキームを使用しても、必ずしも、同じフラグメント除去
動作が実行されるとは限りません。以降の項では、特定の断片化規則とフラグメン
ト除去動作との間の関係について説明します。
5-16
Informix Guide to Database Design and Implementation
データベース サーバが検索からフラグメントを除去できる場合
単一列に基づく非重複フラグメント
単一列で非重複フラグメントを作成する断片化規則では、等式による問合せだけで
なく範囲式による問合せに対しても、フラグメントを除去することができます。図
5-4 に、単一列で非重複フラグメントを作成する断片化規則の例を示します。
図 5-4
単一列に基づく非重複
フラグメント例の図
.
.
.
FRAGMENT BY EXPRESSION
a <= 8 OR a IN (9,10) IN dbsp1,
10 < a <= 20 IN dbsp2,
a IN (21,22, 23) IN dbsp3,
a > 23 IN dbsp4;
a <= 8 OR a IN (9,10)
10 < a <=20
10
a IN (21,22,23)
20
23
a > 23
列a
非重複フラグメントを作成するには、単一列に基づく範囲規則または任意規則を使
用してください。AND、IN、OR、および BETWEEN だけでなく関係演算子も使用
できます。ただし、BETWEEN 演算子を使用するときには注意してください。デー
タベース サーバは、キーワード BETWEEN を構文解析する場合、値の範囲内に、
指定したエンド ポイントを含みます。
Dynamic Server では、単一列で非重複フラグメントを作成する断片化規則は、フラ
グメント除去の観点から見て望ましい断片化規則です。というのは、範囲式と等式
を使用すれば、Dynamic Server が、問合せからフラグメントを除去できるからです。
データベース サーバが必ずしも残余フラグメントを除去できるとは限らないので、
式では REMAINDER 節を使用しないでください。 ♦
断片化戦略
5-17
データベース サーバが検索からフラグメントを除去できる場合
単一列に基づく重複フラグメント
このカテゴリの断片化規則に対して制限があるのは、その断片化規則が単一の列に
基づいていることだけです。フラグメントは、重複や非連続の状態になることもあ
ります。単一列に基づく範囲規則または任意規則を使用することができます。図
5-5 に、この型の断片化規則の例を示します。
図 5-5
単一列に基づく重複フ
ラグメント例の図
.
.
.
FRAGMENT BY EXPRESSION
a <= 8 OR a IN (9,10,21,22,23) IN dbsp1,
a > 10 IN dbsp2;
a <= 8 OR a IN (9,10, 21, 22, 23)
10
20
23
列a
a > 10
この型の分散スキームを使用すると、データベース サーバは、式が適合する最初の
DB 領域に行をロードします。
IDS
このカテゴリの断片化規則の場合、Dynamic Server は、等検索ではフラグメントを
除去できますが、範囲検索ではフラグメントを除去できません。ただし、等検索で
フラグメントを除去する機能が役に立つのは、INSERT 演算子すべてと、UPDATE
演算子の多くで、等検索が実行されるからです。
単一列に基づく重複フラグメントを受け入れることができるのは、連続値を使用し
て非重複フラグメントを作成する式を使用できない場合です。たとえば、時間の経
過とともに表が大きくなるとします。この場合、式に基づいた分散スキームで
MOD 関数を使用すれば、同じくらいのサイズのフラグメントを保持することがで
きます。このように MOD 関数を使用する場合、各フラグメントの値は連続しない
ため、式に基づいた分散スキームは、このカテゴリに分類されます。 ♦
5-18
Informix Guide to Database Design and Implementation
データベース サーバが検索からフラグメントを除去できる場合
Dynamic Server with AD and XP Options は、等検索または範囲検索でフラグメントを
除去することができます。 ♦
AD/XP
非重複フラグメント、複数列
このカテゴリの断片化規則では、任意規則を使用して、複数の列に基づく非重複フ
ラグメントを定義します。これは、単一列に基づく式を使用しても十分な細分性を
得ることができない場合に、選ぶことができます。図 5-6 に、2 つの列に基づく非
重複フラグメントの例を示します。 .
図 5-6
2 つの列に基づく非重
複フラグメント例の図
.
.
.
FRAGMENT BY EXPRESSION
0 < a <= 10 AND b IN ('E', 'F','G') IN dbsp1,
0 < a <= 10 AND b IN ('H', 'I','J') IN dbsp2,
10 < a <= 20 AND b IN ('E', 'F','G') IN dbsp3,
10 < a <= 20 AND b IN ('H', 'I','J') IN dbsp4,
20 < a <= 30 AND b IN ('E', 'F','G') IN dbsp5,
20 < a <= 30 AND b IN ('H', 'I','J') IN dbsp6;
列b
b IN ('H', 'I','J')
b IN ('E', 'F','G')
0 < a <= 10
10 < a <= 20
20 < a <= 30
列a
断片化戦略
5-19
データベース サーバが検索からフラグメントを除去できる場合
この型の分散スキームの場合、Dynamic Server は、等検索ではフラグメントを除去
できますが、範囲検索ではフラグメントを除去できません。この場合も先の場合と
同じように、等検索でフラグメントを除去する機能が役に立つのは、INSERT 演算
子すべてと、UPDATE 演算子の多くで、等検索が実行されるからです。データベー
ス サーバが、必ずしも、残余フラグメントを除去できるとは限らないので、式では
REMAINDER 節を使用しないでください。 ♦
IDS
この型の分散スキームの場合、Dynamic Server with AD and XP Options は、等検索や
範囲検索でフラグメントを除去できます。また、Dynamic Server with AD and XP
Options は、残余フラグメントを除去することもできます。 ♦
IDS
Dynamic Server のフラグメント除去の要約
IDS
図 5-7 に、分散スキームと問合せ式の各種組みあわせに対応する Dynamic Server フ
ラグメント除去動作を要約します。
図 5-7
Dynamic Server のフラグメント除去動作
分散スキーム
問合せの範囲式
問合せの等式
単一列に基づく非重複フラグメント
フラグメントを除去できる
フラグメントを除去できる
単一列に基づく重複または非連続フラグメ
ント
フラグメントを除去できな
い
フラグメントを除去できる
複数列に基づく非重複フラグメント
フラグメントを除去できな
い
フラグメントを除去できる
図 5-7 は、Dynamic Server がフラグメントを除去することを示します。しかし、除
去できるフラグメント ( もしあれば ) は、問合せの WHERE 節が特定します。たと
えば、次の式を使用して断片化される表があるとします。
.
.
.
FRAGMENT BY EXPRESSION
column_a > 100 AND column_b < 0 IN dbsp1,
column_a <= 100 AND column_b < 0 IN dbsp2,
column_b >= 0 IN dbsp3
5-20
Informix Guide to Database Design and Implementation
データベース サーバが検索からフラグメントを除去できる場合
WHERE 節に次の式が指定されている場合、Dynamic Server は、検索からどのフラ
グメントも除去できません。
column_a = 5 OR column_b = -50
WHERE 節に次の式が指定されている場合、Dynamic Server は、最後のフラグメン
トを除去します。
column_b = -50
WHERE 節に次の式が指定されている場合、Dynamic Server は、最初と最後のフラ
グメントを除去します。
column_a = 5 AND column_b = -50
詳細は、
『Informix Guide to SQL: Syntax』の CREATE TABLE 文の FRAGMENT BY 節
を参照してください。
AD/XP
Dynamic Server with AD and XP Options のフラグメント除去の要約
Dynamic Server with AD and XP Options は、WHERE 節で次の演算子の組合わせを使
用すれば、問合せで、1 列または 2 列のフラグメント除去を処理することができま
す。
<, <=, >, >=, !=, IN
AND, OR, NOT
IS NULL, IS NOT NULL
MATCH, LIKE (where pattern has a fixed prefix)
Dynamic Server with AD and XP Options は、すべての列型でフラグメント除去をサ
ポートします。ただし、バイト (BYTE) データ型とテキスト (TEXT) データ型で定
義された列は除きます。5-22 ページの図 5-8 に、分散スキームと問合せ式の各種組
みあわせに対応した、Dynamic Server with AD and XP Options のフラグメント除去動
作を要約します。
断片化戦略
5-21
データベース サーバが検索からフラグメントを除去できる場合
図 5-8
Dynamic Server with AD and XP Options のフラグメント除去動作
分散スキーム
問合せの範囲式
問合せの等式
1 つまたは 2 つの列に基づく非重複フラグメ フラグメントを除去できる
ント
フラグメントを除去できる
1 つまたは 2 つの列に基づく重複または非連 フラグメントを除去できる
続フラグメント
フラグメントを除去できる
ハイブリッド ( ハッシュおよび式に基づい
た)
フラグメントを除去できる
フラグメントを除去できる
フラグメントの REMAINDER 節
フラグメントを除去できる
フラグメントを除去できる
システム定義ハッシュ
フラグメントを除去できな
い
フラグメントを除去できる
式に基づいた分散スキームと問合せ式
図 5-8 は、Dynamic Server with AD and XP Options が分散スキームと範囲式または等
式のほとんどの組合せでフラグメントを除去できることを示します。しかし、除去
できるフラグメントは、該当する問合せの WHERE 節が特定します。たとえば、次
の式を使用して断片化される表があるとします。
.
.
.
FRAGMENT BY EXPRESSION
column_a > 100 AND column_b < 0 IN dbspace_1,
column_a <= 100 AND column_b < 0 IN dbspace_2,
column_b >= 0 IN dbspace_3,
REMAINDER IN dbspace_4
WHERE 節に次の式が指定されている場合、Dynamic Server with AD and XP Options
は、3 番目と 4 番目のフラグメントを除去します。
column_b <= -10
WHERE 節に次の式が指定されている場合、Dynamic Server with AD and XP Options
は、最初、2 番目、および 4 番目のフラグメントを除去します。
column_a <= 100 AND column_b = -50
5-22
Informix Guide to Database Design and Implementation
データベース サーバが検索からフラグメントを除去できる場合
WHERE 節に次の式が指定されている場合、Dynamic Server with AD and XP Options
は、最初と 2 番目のフラグメントを除去します。
column_a IS NULL
詳細は、
『Informix Guide to SQL: Syntax』の CREATE TABLE 文の FRAGMENT BY 節
を参照してください。
システム定義ハッシュ分散スキームと問合せ式
Dynamic Server with AD and XP Options では、システム定義ハッシュ分散スキームを
使用して、WHERE 節に等式が指定されている場合に、フラグメントを除去するこ
とができます。
たとえば、次の表を作成して、DB スライス内にある複数の DB 領域間で表を断片
化するシステム定義のハッシュ分散スキームを作成するとします。
CREATE TABLE account
(account_num integer,
account_bal integer,
account_date date,
account_name char(30)
) FRAGMENT BY HASH(account_num)
IN acct_dbslc;
データベース サーバは、WHERE 節に次の式のような範囲式が指定されている場合
は、検索からどのフラグメントも除去することはできません。
account_num >= 11111 AND 12345 <= account_num
ただし、データベース サーバは、WHERE 節に次の式のような等式が指定されてい
る場合は、検索からどのフラグメントでも除去することができます。
account_num = 12345
この場合、DB スライス内の DB 領域は、1 つを除いてすべて、検索から削除されま
す。
断片化戦略
5-23
データベース サーバが検索からフラグメントを除去できる場合
ハイブリッド分散スキームと問合せ式
Dynamic Server with AD and XP Options では、ハイブリッド分散スキームを使用して、
システム定義ハッシュ分散スキーム、式に基づいた分散スキーム、またはその両方
の分散スキームに基づいたフラグメントを除去することができます。
たとえば、次のハイブリッド分散スキームを使用して、前述の例から表 account を
作成するとします。
FRAGMENT BY HYBRID (HASH (account_num)) EXPRESSION
account_date < ‘01/01/1996’ IN acct_dbslc1
account_date < ‘02/01/1996’ IN acct_dbslc2
.
.
.
account_date < ‘12/01/1996’ IN acct_dbslc12
図 5-9 に、12 個ある DB スライスのそれぞれに DB 領域をレイアウトする方法を示
します。
図 5-9
Dynamic Server with AD and XP Options でのハイブリッド断片化とフラグメント除去
DB 領域 1.1
acct_dbslc12
acct_dbslc2 acct_dbslc1
コサーバ 1
DB 領域 2.1
.
.
.
DB 領域 12.1
...
コサーバ 2
DB 領域 1.6
DB 領域 2.6
.
.
.
DB 領域 12.6
DB 領域 1.2
DB 領域 2.2
.
.
.
DB 領域 1.7
...
DB 領域 1.5
DB 領域 2.7
...
DB 領域 2.5
.
.
.
DB 領域 12.2 DB 領域 12.7
.
.
.
...
Hash (account_num)
5-24
コサーバ n
Informix Guide to Database Design and Implementation
DB 領域 12.5
DB 領域 1.10
DB 領域 2.10
.
.
.
DB 領域 12.10
データベース サーバが検索からフラグメントを除去できる場合
ハイブリッド分散スキームを定義した場合、データベース サーバは、システム定義
ハッシュ分散スキーム、式に基づいた分散スキーム、またはその両方の分散スキー
ムに基づいたフラグメントを検索から除去することができます。
次の式にあるように、WHERE 節にこのハッシュ列を対象とする範囲式が指定され
ている場合、データベース サーバは、ハッシュ分散スキームで定義されているフラ
グメントを除去できません。
account_num >= 11111 AND 12345 <= account_num
ただし、データベース サーバは、WHERE 節に次の式のどれかの組合せが指定され
ている場合は、検索からどのフラグメントでも除去できます。
■
次の式のような、ハッシュ列に関する等式
■
式に基づいた分散スキームに使用される列に関する等式
account_num = 12345
account_date = ‘01/01/1996’
■
式に基づいた分散スキームに使用される列を対象とする範囲式
account_date >= ‘01/01/1996’
AND ‘03/01/1996’ <= account_date
問合せ内の WHERE 節に次の式が指定されているとします。
account_date IN (‘01/01/1996’,‘01/02/1996’,‘01/03/1996’)
AND account_num = 12345
断片化戦略
5-25
断片化された表の作成
この問合せ式では、Dynamic Server with AD and XP Options は、検索から、4 番目∼
12 番目までの DB スライスを除去し、DB 領域は 3 つ ( 残っている 3 つの DB スラ
イスで、DB スライスごとに DB 領域が 1 ずつ ) を除く全部を除去します。ページ
5-26 ページの図 5-10 の影付き領域は、データベース サーバが検索から除去するフ
ラグメントを示します。
図 5-10
ハイブリッド断片化でのフラグメント除去の例
DB 領域 1.1
acct_dbslc3
acct_dbslc2 acct_dbslc1
コサーバ 1
DB 領域 1.6
コサーバ 2
DB 領域 1.2
...
DB 領域 1.7
...
account_date IN '01/01/1996'
DB 領域 2.1
DB 領域 2.6
DB 領域 2.2
DB 領域 2.7
...
DB 領域 3.1
DB 領域 3.6
DB 領域 3.2
DB 領域 3.7
...
account_date IN '01/02/1996'
account_date IN '01/03/1996'
account_num = 12345
断片化された表の作成
ここでは、SQL 文を使用して断片化された表を作成および管理する方法を説明しま
す。表を作成すると同時に表を断片化することも、既存の断片化されていない表を
断片化することもできます。これらについての概要は、以降の節で説明します。断
片化された表の作成に使用する SQL 文の構文についての詳細は、
『Informix Guide to
SQL: Syntax』を参照してください。
断片化された表を作成する前に、適切な断片化戦略を決めておく必要があります。
断片化戦略を組み立てる方法については、データベースサーバのパフォーマンスガ
イドを参照してください。
5-26
Informix Guide to Database Design and Implementation
断片化された表を新たに作成する
断片化された表を新たに作成する
断片化された表を作成するには、CREATE TABLE 文で FRAGMENT BY 節を使用し
ます。デモンストレーションデータベースの表 orders に似た、断片化された表を作
成するとします。3 つのフラグメントを持ったラウンドロビンアルゴリズム分散ス
キームを取ることにします。データベースサーバ管理者に相談して、3 つの 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
IDS
これとは別に、Dynamic Server データベースに表が常駐している場合には、式に基
づいた分散スキームを使用して表を作成することもできます。式に基づいた分散ス
キームを作成するには、CREATE TABLE 文で FRAGMENT BY EXPRESSION 節を
使用します。表 my_orders に 30,000 行あり、これを dbspace1、dbspace2、dbspace3
に格納される 3 つのフラグメントに均等に分散することにします。また、列
order_num を使用して、式のフラグメントを定義することにします。
次の例に示すような式を定義することができます。
CREATE TABLE my_orders (order_num SERIAL, ...)
FRAGMENT BY EXPRESSION
order_num < 10000 IN dbspace1,
order_num < 20000 IN dbspace2,
order_num >= 20000 IN dbspace3
♦
AD/XP
表 my_orders が Dynamic Server with AD and XP Options データベースに常駐している場
合は、システム定義ハッシュ分散スキームで表を作成して、複数のフラグメント間
で均等分散を実行することができます。表 my_orders に 120,000 行があり、これを
dbspace1 ∼ dbspace6 に格納される 6 つのフラグメントに均等に分散することにしま
す。SERIAL 列 order_num を使用してフラグメントを定義することにします。
断片化戦略
5-27
断片化されていない表からの断片化された表の作成
次の例に、FRAGMENT BY HASH 節を使用して、システム定義ハッシュ分散スキー
ムで表を定義する方法を示します。
CREATE TABLE my_orders (order_num SERIAL, ...)
FRAGMENT BY HASH (order_num) IN
dbspace1,
dbspace2,
dbspace3,
dbspace4,
dbspace5,
dbspace6
断片化された表と断片化されていない表の SERIAL 列値間に相違が発生することが
あります。Dynamic Server with AD and XP Options は、フラグメント内で、順番に
SERIAL 値を割り当てます。ただし、フラグメントに、非連続範囲の値が含まれて
いることがあります。こうした値はどれも指定できません。Dynamic Server with AD
and XP Options は、こうした範囲を制御して、範囲が重複しないことだけを保証し
ます。
ヒント : Dynamic Server with AD and XP Options では、DB 領域または DB スライスに
表フラグメントを格納することができます。 ♦
断片化されていない表からの断片化された表の作成
次のような場合には、断片化されていない表を断片化された表に変換する必要があ
ります。
■
アプリケーションで実行されたバージョンの表を断片化するとき。
いくつかの小さな表を大きな 1 つの断片化された表に変換したいと思うは
ずです。この方法について、次の項で説明します。
■
既存の大規模な表を断片化するとき。
5-29 ページの「1 つの断片化されていない表からの断片化された表の作成」
を参照してください。
変換を行う前に、新しく作成した断片化された表を格納するための適切な数の DB
領域を設定しておく必要があります。
5-28
Informix Guide to Database Design and Implementation
断片化されていない表からの断片化された表の作成
複数の断片化されていない表からの表の作成
複数の断片化されていない表を結合して、1 つの断片化された表にすることができ
ます。断片化されていない表の構造は同一でなければならず、別々の DB 領域に格
納されていなければなりません。断片化されていない表を結合するには、ALTER
FRAGMENT 文で ATTACH 節を使用します。
たとえば、account1、account2、account3 の 3 つの断片化されていない表があるとし
ます。そして、それぞれを DB 領域 dbspace1、dbspace2、dbspace3 に格納するとし
ます。3 つの表の構造はすべて同じで、この 3 つの表を 1 つの表に結合し、その表
は共通列 acc_num の式で断片化するものとします。
acc_num の式が 1120 以下である行を、dbspace1 に格納されているフラグメントに格
納したいとします。acc_num が 1121 以上 2000 までの行は dbspace2 に格納します。
また、acc_num が 2001 以上の行は 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 節の使用方法については、
『Performance Guide』を参照してください。
1 つの断片化されていない表からの断片化された表の作成
断片化されていない表から断片化された表を作成するには、ALTER FRAGMENT 文
の INIT 節を使用します。たとえば、表 orders をラウンドロビンで断片化された表
に変換するとします。次に示す SQL 文で変換します。
ALTER FRAGMENT ON TABLE orders INIT FRAGMENT BY ROUND ROBIN
IN dbspace1, dbspace2, dbspace3
断片化されていない表に対する既存のインデックスは、その表と同じ断片化戦略で
断片化されます。
断片化戦略
5-29
断片化された表の更新
断片化された表の更新
断片化された表を変更するには 2 種類の一般的な方法があります。1 番目は、断片
化されていない表に対する変更方法です。この変更方法には、列の追加、列の削
除、列のデータ型の変更などがあります。これらの変更方法では、断片化されてい
ない表で使用する SQL 文と同じ SQL 文を使用します。
2 番目の変更方法は、断片化戦略に対する変更方法です。ここでは、SQL 文を使用
した、断片化戦略の変更方法を説明します。
断片化戦略の変更
フラグメンテーションを実装した後に、断片化戦略を変更しなければならない場合
があります。最も頻繁にあるのは、内部問合せの並列化または相互問合せの並列化
でフラグメンテーションを使用する場合に断片化戦略を変更する必要が生じる場合
です。このような場合に、断片化戦略の変更は、データベースサーバシステムの性
能を向上する方法の 1 つとして使用できます。
AD/XP
Dynamic Server with AD and XP Options では、ALTER FRAGMENT ON TABLE 文の
ATTACH、DETATCH、および INIT の各オプションをサポートしています (HASH
断片化を使用する表は、オプション INIT しかサポートしていません )。Dynamic
Server with AD and XP Options では、ADD、DROP、および MODIFY の各オプション
をサポートしていません。ただし、追加、削除、または変更の各操作を処理すると
きには、ADD、DROP、および MODIFY の代わりに、サポートされているオプショ
ンを使用することができます。サポートされているオプションの構文については、
『Informix Guide to SQL: Syntax』の ALTER FRAGMENT 文を参照してください。
ALTER FRAGMENT 文の ATTACH と DETATCH の各節を使用して性能を向上させ
る方法については、お手持ちの『Performance Guide』を参照してください。
重要 : Dynamic Server with AD and XP Options では、ALTER FRAGMENT ON
INDEX 文または明示的な ROWIDS 列をサポートしていません。 ♦
5-30
Informix Guide to Database Design and Implementation
断片化戦略の変更
断片化機構を完全に再初期化するために INIT 節を使用する方法
断片化戦略を完全に再初期化するために INIT 節を使用することができます。たと
えば最初に、次の CREATE TABLE 文を使用して断片化された表を作成したとしま
す。
CREATE TABLE account (acc_num INTEGER, ...)
FRAGMENT BY EXPRESSION
acc_num <= 1120 in dbspace1,
acc_num > 1120 and acc_num < 2000 in dbspace2,
REMAINDER IN dbspace3
しかし、この分散スキームで作業を始めてから数ケ月後、dbspace2 に含まれるフラ
グメントの行数が他の 2 つのフラグメントの行数の 2 倍になっていることが判明し
ました。この不均衡は、dbspace2 を含むディスクが入出力のボトルネックになる原
因となります。
そこで、この状況を改善するため、分散を変更して各フラグメントの行数を平均化
します。3 つのフラグメントの代わりに 4 つのフラグメント含むように分散スキー
ムを変更することにします。新しい DB 領域 dbspace2a は、以前に dbspace2 に格納
されていた行の最初の半分を格納する新しいフラグメントを含めるためのもので
す。dbspace2 のフラグメントには、以前に格納されていた行の残りの半分が含まれ
ます。
新しい分散スキームを実装するには、まず DB 領域 dbspace2a を作成します。その
後、次の文を実行します。
ALTER FRAGMENT ON TABLE account INIT
FRAGMENT BY EXPRESSION
acc_num <= 1120 in dbspace1,
acc_num > 1120 and acc_num <= 1500 in dbspace2a,
acc_num > 1500 and acc_num < 2000 in dbspace2,
REMAINDER IN dbspace3
この文を実行するとすぐに、データベースサーバによって前の断片化戦略が破棄さ
れ、表に格納されていた行は、新しい断片化戦略に従って再分散化されます。
AD/XP
Dynamic Server with AD and XP Options では、データ移動が発生するのは、INIT 節を
使用する場合に限られます。データベース サーバは、新規断片化スキームで表のコ
ピーを作成し、元の表から新規表に行を挿入します。♦
断片化戦略
5-31
断片化戦略の変更
また、ALTER FRAGMENT 文の INIT 節を使用して、次のことが行えます。
■
1 つの断片化されていない表を断片化された表に変換する。
■
断片化された表を断片化されていない表に変換する。
■
何らかの戦略で断片化された表を、別の断片化戦略に変換する。
詳細は、
『Informix Guide to SQL: Syntax』の「ALTER FRAGMENT 文」を参照してく
ださい。
IDS
MODIFY 節を使用して、Dynamic Server の既存の断片化戦略を変更
する方法
Dynamic Server では、MODIFY 節を指定した ALTER FRAGMENT 文を使用して、既
存の断片化戦略で 1 つまたは複数の式を変更してください。
まず、次の断片化された表を作成するとします。
CREATE TABLE account (acc_num INT, ...)
FRAGMENT BY EXPRESSION
acc_num <= 1120 IN dbspace1,
acc_num > 1120 AND acc_num < 2000 IN dbspace2,
REMAINDER IN dbspace3
次の ALTER FRAGMENT 文を実行した場合、0 以下の値のアカウント番号が、
dbspace1 にあるフラグメントに格納されていないことを確認します。
ALTER FRAGMENT ON TABLE account
MODIFY dbspace1 TO acc_num > 0 AND acc_num <=1120
MODIFY 節を使用しても、分散スキームに含まれているフラグメントの数を変更す
ることはできません。その代わりに、ALTER FRAGMENT の INIT 節または ADD 節
を使用してください。
5-32
Informix Guide to Database Design and Implementation
断片化戦略の変更
AD/XP
ATTACH と DETACH を使用して Dynamic Server with AD and XP
Options の既存の断片化戦略を変更する方法
Dynamic Server with AD and XP Options では、ALTER FRAGMENT 文を使用して、既
存の断片化戦略を変更してください。データを移動する必要がない場合は、次のオ
プションが指定された ALTER FRAGMENT 文を使用して、既存のフラグメントの
式を変更することができます。
■
DETACH 節を使用して、変更したい式のあるフラグメントを削除します。
■
ATTACH 節を使用して、新しい式でフラグメントを再確保します。
まず、次の断片化された表を作成するとします。
CREATE TABLE account (acc_num INT, ...)
FRAGMENT BY EXPRESSION
acc_num <= 1120 IN dbspace1,
acc_num > 1120 AND acc_num < 2000 IN dbspace2,
REMAINDER IN dbspace3
次の文は、dbspace1 に含まれているフラグメントを変更して、0 以下の値のアカウ
ント番号がこのフラグメントに格納されないようにします。
ALTER FRAGMENT ON TABLE account
DETACH dbspace1 det_tab;
CREATE TABLE new_tab (acc_num INT, ...)
FRAGMENT BY EXPRESSION
acc_num > 0 AND acc_num <=1120 IN dbspace1;
ALTER FRAGMENT ON TABLE account
ATTACH account, new_tab
INSERT INTO account SELECT * FROM det_tab;
DROP TABLE det_tab;
ヒント : 既存の断片化戦略を変更するのにデータの移動が必要な場合は、ALTER
FRAGMENT 文の INIT 節を使用してください。
断片化戦略
5-33
断片化戦略の変更
新規フラグメントの追加
断片化戦略を定義する場合、1 つまたは複数のフラグメントの追加が必要になるこ
とがあります。Dynamic Server with AD and XP Options、および Dynamic Server は、
ALTER FRAGMENT 文の各種オプションを使用して、表に新規フラグメントを追加
します。以降の項では、表にフラグメントを追加する方法について説明します。
ADD 節を使用して Dynamic Server のフラグメントを追加する方法
IDS
Dynamic Server では、ALTER FRAGMENT 文の ADD 節を使用すれば、表に新規フ
ラグメントを追加することができます。次の文を使用して作成した表にフラグメン
トを追加するとします。
CREATE TABLE sales (acc_num INT, ...)
FRAGMENT BY ROUND ROBIN IN dbspace1, dbspace2, dbspace3
新規フラグメント dbspace4 を表 sales に追加するには、次の文を実行します。
ALTER FRAGMENT ON TABLE sales ADD dbspace4
断片化戦略が式に基づいている場合は、ALTER FRAGMENT 文の ADD 節には、既
存の DB 領域の前または後に DB 領域を 1 つ追加するオプションが含まれています。
詳細は、
『Informix Guide to SQL: Syntax』の ALTER FRAGMENT 文を参照してくだ
さい。
AD/XP
ATTACH節を使用してDynamic Server with AD and XP Optionsのフラグメントを
追加する方法
フラグメント間でのデータ移動を必要としない場合には、ALTER FRAGMENT 文の
ATTACH 節を使用して、表に新規フラグメントを追加することができます。次の文
を使用して作成した表にフラグメントを追加するとします。
CREATE TABLE sales (acc_num INT, ...)
FRAGMENT BY ROUND ROBIN IN dbspace1, dbspace2, dbspace3
5-34
Informix Guide to Database Design and Implementation
断片化戦略の変更
新規フラグメント 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 領域、す
なわち sales の 3 つの DB 領域と new_tab の DB 領域に断片化します。表 new_tab は
使い果たされます。
重要 : 表にハッシュ断片化が指定されている場合には、ATTACH 節を指定した
ALTER TABLE 文を使用することはできません。ただし、ハッシュ断片化が指定さ
れた表では、INIT 節を指定した ALTER TABLE 文を使用できます。
ATTACH 節の使用方法についての詳細は、『Informix Guide to SQL: Syntax』の
ALTER FRAGMENT 文を参照してください。
フラグメントの削除
断片化戦略を定義する場合、1 つまたは複数のフラグメントの削除が必要になるこ
とがあります。Dynamic Server with AD and XP Options および Dynamic Server は、
ALTER FRAGMENT 文の各種オプションを使用して、表からフラグメントを削除し
ます。以降の項では、表からフラグメントを削除する方法について説明します。
IDS
DROP 節を使用してフラグメントを削除する方法
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
断片化戦略
5-35
断片化戦略の変更
この文を実行すると、dbspace3 内の行はすべて、残っている DB 領域の dbspace1 と
dbspace2 に移動されます。
DROP 節についての詳細は、『Informix Guide to SQL: Syntax』の ALTER FRAGMENT
文を参照してください。
AD/XP
DETACH 節を使用してフラグメントを削除する方法
Dynamic Server with AD and XP Options では、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 を削除するに
は、次の文を実行してください。
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 文を使用して削除します。
重要 : 表にハッシュ断片化が指定されている場合には、DETACH 節を指定した
ALTER FRAGMENT 文を使用することはできません。ただし、ハッシュ断片化が指
定された表では、INIT 節を指定した ALTER FRAGMENT 文を使用できます。
DETACH 節の使用方法についての詳細は、『Informix Guide to SQL: Syntax』の
ALTER FRAGMENT 文を参照してください。
5-36
Informix Guide to Database Design and Implementation
一時表の断片化
一時表の断片化
一時表を作成する場合には、この一時表を断片化することができます。データベー
ス サーバは、一時表の削除と同時に、その一時表用に作成されたフラグメントを削
除します。一時表の断片化に対しては、一時表の断片化戦略を変更できない ( 永続
表では断片化戦略を変更できるが ) という制限があります。
IDS
AD/XP
Dynamic Server では、CREATE TABLE 文の TEMP TABLE 節を使用すると、断片化さ
れた一時表を作成することができます。 ♦
Dynamic Server with AD and XP Options の一時表の断片化
Dynamic Server with AD and XP Options を使用すれば、種々のコサーバに属している
複数のディスク間で、明示的な一時表を断片化することができます。明示的な一時
表とは、次の SQL 文のどちらかを使用して作成した一時表を指します。
■
CREATE TABLE 文の TEMP TABLE オプションまたは SCRATCH TABLE オ
プション
■
SELECT 文の INTO TEMP 節または INTO SCRATCH 節
重要 : コサーバは、一時スペースのコサーバ専用 DB 領域だけを使用でき、この DB
領域だけにアクセスできます。一時表は、永続表と同じように、複数の DB 領域間
で明示的に断片化することができます。ただし、コサーバは、管理するフラグメン
ト内にだけデータを挿入します。
明示的な一時表に、ユーザ固有の断片化戦略を定義することも、Dynamic Server
with AD and XP Options に動的に断片化戦略を決めさせることもできます。詳細は、
お手持ちの『Performance Guide』を参照してください。
ユーザ固有の断片化戦略の定義
一時表を作成するには、CREATE TABLE 文の TEMP TABLE 節または SCRATCH
TABLE 節を使用します。TEMP 表または SCRATCH 表を断片化するには、
FRAGMENT BY 節を使用して、分散スキームと、一時表に使用する DB 領域または
DB スライスを指定してください。
断片化戦略
5-37
Dynamic Server with AD and XP Options の一時表の断片化
Dynamic Server with AD and XP Options に動的に断片化戦略を定義
させる方法
Dynamic Server with AD and XP Options は、次の型の問合せの実行中に、断片化戦略
を作成し決定します。
SELECT * FROM customer INTO SCRATCH temp_table
または
SELECT * FROM customer INTO TEMP temp_table
前述の問合せに応答して作成された明示的な一時表は、フレックス ( フレキシブル
な ) 一時表と呼ばれます。フレックス一時表は、ラウンドロビン分散スキームで断
片化されます。列名とデータ型については、明示的な一時表ではわかっている必要
があっても、フレックス一時表ではわかっている必要はありません。
SELECT...INTO TEMP 構文を使用した場合、Dynamic Server with AD and XP Options
では、DB 領域と DB スライスを使用して一時表を格納するときには、フレックス
一時表演算子を使用して格納方法を最適化します。フレックス演算子は、
(PDQ_PRIORITY が 0 であっても ) フラグメントへの挿入を並列で実行します。問
合わせまたはセグメントの並列化により、フレックス SQL 挿入演算子のインスタ
ンスの数が決まります。各フレックス一時表演算子は、Dynamic Server with AD and
XP Options が、フレックス一時表のフラグメントを格納する候補として選択したコ
サーバ上で実行されます。
重要 : フレキシブルな一時表の機能は、
複数の DB 領域のデータを格納および検索す
る場合、これらの DB 領域を管理する各種コサーバ上で、SQL 演算子を使用してこ
の操作を実行します。コサーバは、その専用 DB 領域だけを使用しそこにアクセス
することができます。
各フレックス演算子が、フレックス一時表のデータを受信すると、Dynamic Server
with AD and XP Options は、使用可能な DB 領域の 1 つにフラグメントを作成し
DBSPACETEMP の値に基づいて )、そのフラグメントにデータを少量追加します。
その DB 領域が一杯になると、Dynamic Server with AD and XP Options は、別の DB
領域に一時表のフラグメントを作成します。さらに、SQL 演算子は、引き続き、
データをこの一時表に追加します。フレックス挿入演算子のインスタンスは、デー
タを受信しなければ、フラグメントを作成しません。
5-38
Informix Guide to Database Design and Implementation
表インデックスの断片化
表インデックスの断片化
表データと表インデックスはどちらも断片化することができます。インデックスの
断片化戦略は、表データ断片化戦略と同じにすること ( 添付インデックス ) も、表
データ戦略から独立させること ( 独立インデックス ) もできます。
添付インデックス
添付インデックスとは、明示的な格納オプションを使用せずに作成したインデック
スを指します。添付インデックスでは、インデックス フラグメントの数は、データ
フラグメントの数と同じになります。断片化された表上にインデックスを作成する
が、該当するインデックスの分散スキームは指定しない場合、デフォルトでは、
データベース サーバが、表と同じ分散スキームに基づいてインデックスを断片化し
ます。もっと具体的に言えば、データベース サーバは、表データと同じ規則を使用
してインデックス キーをフラグメントに分散し、対応する表データと同じ DB 領域
にそのインデックス キーを配置します。
IDS
Dynamic Server では、断片化されていない表の添付インデックスは、表データと同
じ表領域に格納されます。このため、インデックス ページは、データ ページでイ
ンタリーブされます。ただし、断片化された表の添付インデックスは、表データと
異なる表領域に格納されます。このため、インデックスと表データは、同じ DB 領
域を共有しますが、インデックス ページは、データ ページでインタリーブされま
せん。 ♦
断片化戦略
5-39
独立インデックス
添付インデックス ( 断片化されている表
Dynamic Server with AD and XP Options では、
に対するものも断片化されていない表に対するものも ) は、表データと異なる表領
域に格納されます。このため、インデックスと表データは同じ DB 領域を共有しま
すが、インデックス ページはデータ ページでインタリーブされません。5-40 ペー
ジの図 5-11 に、Dynamic Server with AD and XP Options の断片化された表に添付され
るインデックスの格納スキームを示します。
AD/XP
図 5-11
Dynamic Server with AD and XP Options の断片化された表に添付されるインデックスの格納スキーム
コサーバ 1
DB 領域 1
データ
コサーバ 2
DB 領域 2
インデッ
クス
データ
インデッ
クス
...
コサーバ n
...
DB 領域 n
...
データ
インデッ
クス
♦
独立インデックス
インデックス用の断片化スキームは、表データ用の断片化スキームと異なることも
あります。独立インデックスとは、表フラグメントから独立した断片化戦略を使用
するインデックスを指します。CREATE INDEX 文の FRAGMENT BY 節を使用すれ
ば、任意の表に対するインデックスを断片化することができます。
Dynamic Server では、式に基づいた分散スキームを使用すれば、任意の表に対する
独立インデックスを作成することができます。ただし、インデックスに対しては、
ラウンドロビン分散スキームは使用できません。
IDS
ALTER FRAGMENT ON INDEX 文を使用すれば、断片化されたインデックスの断片
化戦略を変更することができます。 ♦
AD/XP
5-40
Dynamic Server with AD and XP Options では、式に基づいた分散スキーム、システム
定義分散スキーム、またはハイブリッド分散スキームを使用すれば、任意の表の独
立インデックスを作成することができます。ただし、インデックスに対しては、ラ
ウンドロビン分散スキームは使用できません。
Informix Guide to Database Design and Implementation
行識別子
Dynamic Server with AD and XP Options では、ALTER FRAGMENT ON INDEX をサ
ポートしていません。断片化されたインデックスの断片化戦略を変更するには、ま
ず、DROP INDEX 文を使用してインデックスを削除した後、CREATE INDEX 文を
使用して、新規断片化戦略によりインデックスを再作成する必要があります。 ♦
断片化された表のインデックスが断片化されないようにしたい場合は、CREATE
INDEX...IN DBSPACE 文を使用して、別々の DB 領域にインデックスを配置するこ
とができます。
インデックス断片化についての詳細は、お手持ちの『Performance Guide』と
『Informix Guide to SQL: Syntax』を参照してください。
行識別子
行識別子とは、行の物理的位置を定義する整数を指します。断片化されていない表
にある行の行識別子は、一意な定数値です。これとは対照的に、断片化された表に
ある行には行識別子は割り当てられません。行を参照する場合には、主キー値を使
用することをお勧めします。主キーは、SQL の ANSI 仕様で定義されています。主
キーを使用すると、アプリケーションの移植性が向上します。
IDS
アプリケーションで、断片化された表の行識別子を参照する必要がある場合、この
アプリケーションに対処するには、Dynamic Server を使用すると、断片化された表
の行識別子列を明示的に作成することができます。明示的に作成された行識別子列
を使用して行にアクセスすると、主キーを使用してアクセスするより時間がかかり
ます。
行識別子列の作成
行識別子列を作成するには、次の SQL 構文を使用してください。
■
CREATE TABLE 文の WITH ROWIDS 節
■
ALTER TABLE 文の ADD ROWIDS 節
■
ALTER FRAGMENT 文の INIT 節
行識別子列は、作成または変更する表にある列の 1 つとして指定することによっ
て、作成することはできません。
断片化戦略
5-41
断片化された表に格納されているデータへのアクセス
行識別子列を作成すると何が実行されるか
行識別子列を作成すると、データベース サーバは、次の動作を実行します。
■
表内の各行に 4 バイトの一意値を追加する。
■
行識別子で表のデータにアクセスするときに使用する内部インデックスを
作成する。
■
内部インデックス用に、カタログ表 sysfragments に行を 1 行挿入する。 ♦
断片化された表に格納されているデータへのアク
セス
複数の方法を使用して、断片化されていない表に格納されている行にアクセスする
ことができます。アクセスする行の行識別子を参照するのも 1 つの方法です。
IDS
Dynamic Server では、断片化された表に格納されている行を行識別子により参照す
る場合は、行識別子列を明示的に作成する必要があります。行識別子列の作成につ
いては、5-43 ページの「断片化された表の行識別子列の作成」を参照してくださ
い。ユーザ アプリケーションが、断片化された表の行識別子を参照しようとしたと
きに、その断片化された表に、ユーザが明示的に作成した行識別子が指定されてい
ないことがあります。この場合、データベース サーバは適切なエラー メッセージ
を表示し、アプリケーションの実行は停止されます。 ♦
AD/XP
Dynamic Server with AD and XP Options では、断片化された表での行識別子をサポー
トしていません。行を識別するには、行の列値を使用する必要があります。 ♦
行識別子の代わりに主キーを使用する
INFORMIX では、アプリケーションにアクセスする方法として、行識別子ではなく
主キーを使用することをお勧めします。主キーは SQL の ANSI 仕様で定義されてい
るため、主キーを使用してデータにアクセスすることで、アプリケーションの移植
性が高まります。
データにアクセスするための主キーの定義方法と使用方法の詳細は、
『Informix
Guide to SQL: Reference』と『Informix Guide to SQL: Syntax』を参照してください。
5-42
Informix Guide to Database Design and Implementation
行識別子の代わりに主キーを使用する
IDS
Dynamic Server の断片化された表の行識別子
アプリケーションの観点からみると、断片化された表のなかの行識別子列の機能は
断片化されていない表の行識別子の機能と同じです。しかし、断片化されていない
表の行識別子とは異なり、データベースサーバは、インデックスを使用して行識別
子を物理的な位置にマッピングします。行識別子による断片化された表のデータへ
のアクセスは行識別子による断片化されていない表のデータへのアクセスに比べ
て、かなり遅くなります。行識別子による断片化された表のデータへのアクセスの
速度は、主キーを使用したアクセスに及びません。さらに、主キーでアクセスする
ことによって、多くの状況下で性能が飛躍的に向上し、特に、並列アクセスのとき
に顕著です。
データベースサーバは、行識別子の列を使用して断片化された表の行にアクセスす
る場合、行にアクセスする前にインデックスを使用してその行の物理アドレスを探
します。断片化されていない表では、データベースサーバはインデックスを検索せ
ずに、直接物理アクセスを行います。その結果として、行識別子を使用して断片化
された表の行をアクセスすると、断片化されていない表の行をアクセスするときに
比べて少し長くかかります。また、断片化された表の行識別子インデックスを管理
しているため、挿入処理と削除処理の性能改善にも少し効果があります。
断片化された表の行識別子列の作成
何らかの理由でアプリケーションが行識別子の列を使用して断片化された表のデー
タにアクセスする必要がある場合は、断片化された表に対する行識別子の列を作成
しなければなりません。
この列は、表を作成したときに、CREATE TABLE 文の WITH ROWIDS 節を使用し
て作成することができます。CREATE TABLE...WITH ROWIDS 文を発行すると、
データベースサーバによって行識別子列が作成され、断片化された表の各行に、4
バイトずつ追加されます。さらに、データベースサーバは、行識別子によって表内
のデータにアクセスするために使用する内部インデックスを作成します。行識別子
列が作成された後、データベースサーバによって sysfragments カタログ表に行が挿
入されます。これは、行識別子列の存在と属性を示すものです。
断片化された表を作成した後で、行識別子の列が必要であると判明した場合には、
ALTER TABLE 文の ADD ROWIDS 節か ALTER FRAGMENT 文の INIT 節を使用し
ます。
断片化戦略
5-43
行識別子の代わりに主キーを使用する
断片化された表の行識別子列を削除するには、ALTER TABLE 文の DROP ROWIDS
節を使用します。詳細は、
『Informix Guide to SQL: Syntax』の「ALTER TABLE 文」
を参照してください。
行識別子列は、作成または変更する表内の列の 1 つとして指定して、作成または追
加することはできません。たとえば、次の文を実行するとエラーになります。
CREATE TABLE test_table (rowid INTEGER, ....)
この場合、次のようなエラーが返されます。
-227 DDL options on rowid are prohibited. error.
フラグメントアクセス権の付与と取消し
有益なフラグメントアクセス権を付与したい場合は、データ分散を制御する戦略を
持つ必要があります。式によるデータレコードの断片化は、このような有益な戦略
の 1 つです。ラウンドロビンアルゴリズムによるデータレコード分散戦略は、新し
いデータレコードが次のフラグメントに追加されるため、有益な戦略ではありませ
ん。この分散戦略は、データ分散を追跡する有効な方法をすべて無効にしてしまう
ため、フラグメントアクセス権が実際に使用されることはなくなってしまいます。
式を基にした分散とラウンドロビンアルゴリズムによる分散の間にはこのような違
いがあるため、GRANT FRAGMENT 文と REVOKE FRAGMENT 文は式戦略で断片
化された表にのみ適用されます。
重要 : ラウンドロビンアルゴリズム戦略で断片化された表に対して、GRANT
FRAGMENT 文や REVOKE FRAGMENT 文を発行すると、コマンドは失敗し、エ
ラーメッセージが返されます。
断片化された表を作成する場合、デフォルトのフラグメントアクセス権はありませ
ん。GRANT FRAGMENT 文を使用して、1 つ以上のフラグメントに対する挿入、更
新、削除のアクセス権を付与します。3 つのアクセス権すべてを 1 度に付与したい
場合は、GRANT FRAGMENT 文でキーワード ALL を使用します。ただし、フラグ
メントを含む表の名前を指定しただけでは、フラグメントアクセス権を付与するこ
とはできません。特定のフラグメントを指定する必要があります。
5-44
Informix Guide to Database Design and Implementation
行識別子の代わりに主キーを使用する
挿入、更新、削除の各アクセス権を取り消す場合は、REVOKE FRAGMENT 文を使
用します。この文は、1 人以上のユーザから、断片化された表の 1 つ以上のフラグ
メントに対するアクセス権を取り消します。表に対して現在存在しているアクセス
権をすべて取り消したい場合は、キーワード ALL を使用することができます。コ
マンドにフラグメントを指定しないと、表のすべてのフラグメントに対して現在許
可されているアクセス権がすべて取り消されます。
詳細は、
『Informix Guide to SQL: Syntax』の GRANT FRAGMENT 文、REVOKE
FRAGMENT 文、SET 文を参照してください。
AD/XP
Dynamic Server with AD and XP Options では、GRANT FRAGMENT 文と REVOKE
FRAGMENT 文をサポートしません。 ♦
断片化戦略
5-45
セクション II
データ ウェアハウジング
第6章
次元データモデルの作成
データ ウェアハウスの概要. . . . .
次元データベースを作成する理由 .
次元データとは . . . . . . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. .
. .
. .
次元データ モデルのコンセプト
ファクト表 . . . . .
データ モデルの次元 . .
次元要素. . . . .
次元属性. . . . .
次元表 . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6-9
6-11
6-12
6-12
6-13
6-14
次元データ モデルの作成 . . . . . . . .
ビジネス プロセスの選択 . . . . . . .
ビジネス プロセスの要約 . . . . . . .
ファクト表の細分性の決定 . . . . . .
細分性のデータベース サイズへの影響力 .
ビジネスプロセスを使用しての細分性の決定
次元と階層の明確化 . . . . . . . .
ファクト表のメジャー ( 基準 ) の選択 . . .
ファクト表を次元表と結合するキーの使用.
正規化の阻止 . . . . . . . . . .
次元表の属性の選択 . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6-15
6-16
6-16
6-18
6-18
6-18
6-20
6-22
6-24
6-25
6-26
次元データ モデルの共通する問題の処理.
次元表の属性数を最低限に抑える .
時々変更する次元の処理 . . . .
スノーフレーク スキーマの使用 . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6-28
6-28
6-30
6-32
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6-4
6-5
6-6
6-2
Informix Guide to Database Design and Implementation
この章では、次元データ モデルのコンセプトおよびテクニックを紹介し、簡単な次
元データ モデルの作成方法を説明します。第 7 章では、SQL を使用して、この次元
データを実装する方法を説明します。この章の内容は、次のとおりです。
■
データ ウェアハウスの概要
■
次元データ モデルのコンセプト
■
次元データ モデルの作成
■
次元データ モデルの共通する問題の処理
大規模なデータウェアハウスについては、次元データ モデルはリレーショナル
データ モデルよりも管理が困難です。このため、データ ウェアハウスでは通常、
リレーショナル データ モデルに基づいています。しかし、次元データ モデルは、
データ ウェアハウスのサブセットであるデータ マートを作成する場合に特に適し
ています。
この章で取り扱う次元データ モデルの一般原則は、Informix Dynamic Server や、
Informix Dynamic Server with Advanced Decision Support and Extended Parallel Options で
作成するデータベースに適用されます。どのデータベース サーバを使用して次元
データベースを作成するかを単一の要素だけで決定することはできませんが、大規
模なスケーラブル ウェアハウスは Dynamic Server with AD and XP Options で作成し、
小型のウェアハウス、OLTP システム、および運用システムは Dynamic Server で作
成するように想定しています。
次元データ モデルのコンセプトを理解するには、SQL やリレーショナル データ
ベースの理論についての基本的な知識が必要です。この章では、データ ウェアハウ
スのコンセプトを要約し、簡単な次元データ モデルを説明するにすぎませ
ん。Informix では、次元データ モデルのより高度なコンセプトやテクニックを学ぶ
には、この章を読んでから、序 15 ページ「参考文献」に紹介されている書籍を読
まれることをお勧めします。
次元データ モデルの作成
6-3
データ ウェアハウスの概要
データ ウェアハウスの概要
データ ウェアハウスという用語の最も広い意味では、きわめて多くの履歴データを
格納しているデータベースのことをいうために使用されてきました。データは一連
のスナップショットとして格納され、そのスナップショットの各レコードは、ある
特定の時点でのデータを表わします。このデータ スナップショットで、ユーザが履
歴を再作成したり、何らかの時点と別の時点との間で正確な比較をしたりできま
す。データ ウェアハウスは、ウェアハウスにロードされる前に抽出するデータを統
合し、変換します。データ ウェアハウスの第一の長所は、格納されている膨大な情
報に簡単にアクセスしたり、分析したりできることです。
データ ウェアハウスという用語が、人によっては違うことを意味することがあるた
め、このマニュアルでは、データ ウェアハウスとデータ ウェアハウス環境という
包括的な用語を使用して、データを格納するために使用する次のフォーマットをい
います。
■
データ ウェアハウス
データ抽出のために最適化されたデータベースです。データをトランザク
ション レベルで格納するのではなく、あるレベルのデータを要約します。
日常の自動操作を自動化する従来の OLTP データベースとは違い、データ
ウェアハウスでは、時間の経過に従ってエンタプライズ全体のパフォーマ
ンスが評価できる意思決定支援環境を提供します。通常、リレーショナル
データ モデルを使用して、データ ウェアハウスを作成します。
■
データ マート
小型のデータベースに格納され、エンタプライズ全体の戦略計画ではなく
て特定の目的またはデータ サブジェクトを指向するデータ ウェアハウス
のサブセットです。データ マートには、操作データ、要約データ、スペー
シャル ( 地理空間 ) データ、メタデータを組み込むことができます。通常、
次元データ モデルを使用して、データ マートを作成します。
■
操作データ ストア
意思決定を行うときに 1 度に 1 つまたは 2 つのレコードを参照するように
最適化されたサブジェクト指向のシステムです。操作データ ストアは、タ
イムリーで、現行の統合データを含んでいるハイブリッド形式のデータ
ウェアハウスです。データには通常、トランザクションよりも高いレベル
の細分性があります。操作データは事務的な日常の意思決定に使用できま
す。このデータは、データ ウェアハウスの共通データ ソースとしての役
割を果たすことができます。
6-4
Informix Guide to Database Design and Implementation
次元データベースを作成する理由
■
リポジトリ
リポジトリは、複数のデータ ソースを結合して、1 つの正規化されたデー
タベースにします。リポジトリ内のレコードは、頻繁に更新されます。
データは、履歴データではなく、操作データです。特定のシステム要件に
よっては、特定の意思決定の問合せにリポジトリが使用できます。リポジ
トリは、操作処理用の統合化されたエンタプライズ全体のデータ ソースを
必要とする企業のニーズに適合しています。
次元データベースを作成する理由
リレーショナル データベースは通常、オンライン トランザクション処理 (OLTP) 向
けに最適化されています。OLTP システムは、業務上の日常的な操作ニーズを満た
すように設計され、データベースのパフォーマンスはそのような操作上のニーズに
合わせて調整されます。したがって、リレーショナル データベースでは少数のレ
コードなら迅速に検索できますが、大量のレコードを検索し、急いで要約する場合
には、速度が遅くなることがあります。OLTP システムにあり得る欠点は、次のと
おりです。
■
ビジネス エンタプライズ全体では、データに一貫性がない場合がありま
す。
■
データへのアクセスが複雑になる可能性があります。
これとは対照的に、次元データベースは、ビジネスの動向や予測の分析を支援する
ように設計され、調整されています。この種の情報処理は、オンライン分析型処理
(OLAP) または意思決定支援処理として知られています。OLAP は、データベース設
計者が情報処理への次元的なアプローチのことをいうときに使用する用語でもあり
ます。
次元データベースは、データ抽出と分析のために最適化されています。データベー
スにロードした新しいデータは通常、多くの場合は複数のソースから、バッチで更
新されます。OLTP システムが、受注入力のような特定の処理を中心にデータを整
理する傾向にあるのに対して、次元データベースはサブジェクト指向の傾向にあっ
て、
「どんな製品が売れ筋か、どんな時期に製品が一番売れるか、どこの地区の販
売が弱いか」といった質問に答えることを目的としています。
次元データ モデルの作成
6-5
次元データとは
次の表に、OLTP データベースと OLAP データベースとの主な違いを要約します。
リレーショナル データベース (OLTP)
次元データベース (OLAP)
データを細分化
データを要約
現行のデータ
履歴データ
1 度に 1 つのレコードを処理
1 度に多数のレコードを処理
処理指向
サブジェクト指向
高構造化反復処理向けに設計
高構造化されていない分析処理向けに
設計
リレーショナル テクノロジによって企業が解決をはかろうとする問題の多くは、元
来、多次元的なものです。たとえば、地域ごとの製品の売上げ、製品ごとの地域の
売上げなどの要約を作成する SQL では、従来のリレーショナル データベースでの
処理に何時間もかかるかもしれません。しかし、次元データベースでは、同じ問合
せが一瞬のうちに処理できます。
次元データとは
従来のリレーショナル データベースは、レコードのリストを中心として整理されて
います。各レコードには、属性 ( フィールド ) に整理された関連情報が組み込まれ
ています。デモンストレーション データベース stores7 の表 customer はその代表例
であり、名前、会社、住所、電話番号などのためのフィールドが入っています。こ
の表には複数のフィールドに情報がありますが、表の各行には 1 件の顧客が属して
いるにすぎません。顧客名と、たとえば電話番号のようなほかのフィールドを使用
して 2 次元的なマトリクスを作成する場合には、1 対 1 の対応だけしかできないこ
とがわかります。6-7 ページの図 6-1 に、1 対 1 の対応だけがあるフィールドを使用
した表を示します。
6-6
Informix Guide to Database Design and Implementation
次元データとは
図 6-1
フィールド間に 1 対 1 の対応がある表
顧客
電話番号 --->
Ludwig Pauli
408-789-8075
----------------
----------------
Carole Sadler
----------------
415-822-1289
----------------
Philip Currie
----------------
----------------
414-328-4543
このマトリクスの前記の表 customer からフィールドを任意に組合わせることはでき
ますが、1 対 1 の対応で常に終わるため、この表には多次元性がなく、次元データ
ベースには不向きであることがわかります。
そこで、表のフィールド間に 1 対 1 よりも多くの対応が含まれているリレーショナ
ル データベースを考えてみます。国内の各地域の製品売上げについての売上げデー
タを含んだ表を作成するとします。簡単に説明するために、この会社には 3 種類の
製品があって、3 つの地域で販売しているとします。図 6-2 に、このデータをリ
レーショナル表に格納する方法を示します。
製品
地域
販売数量
サッカーボール
東部
2300
サッカーボール
西部
4000
サッカーボール
中央
5600
テニスラケット
東部
5500
テニスラケット
西部
8000
テニスラケット
中央
2300
野球ボール
東部
10000
野球ボール
西部
22000
野球ボール
中央
34000
図 6-2
簡単なリレーショナル表
次元データ モデルの作成
6-7
次元データとは
製品
6-7 ページの図 6-2 の表には、1 地域当たり 1 製品以上あり、かつ 1 製品当たり 1 地
域以上があるために、表そのものが多次元的な表現になります。図 6-3 に、製品と
地域データの多数対多数の関係をうまく表わす 2 次元的なマトリクスを示します。
地域
中央
東部
西部
サッカーボール
5600
2300
4000
テニスラケット
2300
5500
8000
野球ボール
34000
10000
22000
図 6-3
簡単な 2 次元的な例
このデータをなんとかして図 6-2 の 3 つのフィールドのあるリレーショナル表にす
ることはできますが、データは図 6-3 の 2 次元的なマトリクスのほうがより自然で
す。
従来のリレーショナル表よりも次元表のほうがパフォーマンス上の長所が大きくな
ります。次元的なアプローチによって、要約したり、比較したりするデータへのア
クセスが簡単になります。たとえば、次元表を使用して、西部で販売されている製
品の数を問い合せる場合は、データベース サーバが列 west を検索し、その列のす
べての行の合計を計算します。リレーショナル表で同じ問合せを実行するには、
データベース サーバが列 region が west になる各行を検索、抽出してから、そのデー
タを統合します。この種の問合せでは、次元表では、リレーショナル表が west のレ
コードすべてを検索するために要するほんのわずかな間に、列 west のすべての値が
合計できます。
6-8
Informix Guide to Database Design and Implementation
次元データ モデルのコンセプト
次元データ モデルのコンセプト
次元データベースを作成するには、次元データ モデルから着手します。次元データ
モデルは、データベースを作成するための方法を簡単かつ理解しやすくします。次
元データベースを 3 次元または 4 次元のデータベース キューブ ( 立方体 ) と考える
と、ユーザはどの次元に接しているデータベースの部分にもアクセスできます。次
元データベースを作成するには、データを視覚化するモデルが必要です。
ユーザの業務は異なる市場で製品を販売することであり、時経過のパフォーマンス
を評価するとします。このビジネス プロセスを、時間、製品、および市場という各
次元が含まれているデータのキューブ ( 立方体 ) と考えるのは簡単です。図 6-4 は、
この次元モデルを示しています。キューブ ( 立方体 ) の各線に沿ったさまざまな交
差部分には、このビジネスのメジャー ( 基準 ) が含まれています。このメジャー (
基準 ) は、製品、市場、および時間データという特定の組み合わせに対応します。
図 6-4
時間、製品、および
市場の次元のあるビ
ジネスの次元モデル
間
市場
時
製品
次元データ モデルの作成
6-9
次元データ モデルのコンセプト
次元モデルは、スター ジョイン スキーマともいいます。このモデルのダイアグラ
ムが、中央に表があり、その周囲にほかの表が配置されていて星のように見えるた
めに、データベース設計者はこの名前を使用しています。この中央の表をファクト
表といい、ほかの表を次元表といいます。すべての次元表には、次元表とファクト
表とを結ぶ連結部が、問合せには関係なく、１つだけあります。図 6-5 に、異なる
市場で製品を販売し、時経過による業績を評価するあるビジネスの簡単な次元モデ
ルを示します。
図 6-5
代表的な次元モデル
時間の次元
time_key
day_of_week
month
quarter
year
holiday_flag
販売ファクト表
製品の次元
time_key
product_key
store_key
dollars_sold
units_sold
dollars_cost
product_key
description
brand
category
店舗の次元
store_key
store_name
address
floor_plan_type
6-10
Informix Guide to Database Design and Implementation
ファクト表
ファクト表
ファクト表は、ビジネスのメジャー ( 基準 ) を格納し、各次元表の最低レベルの
キー値を示します。メジャー ( 基準 ) は、サブジェクトについての量的なデータあ
るいは実際のデータです。メジャー ( 基準 ) は通常、数値であり、質問の量や数に
対応します。メジャー ( 基準 ) の例には、価格、製品の売上げ、製品の在庫、収益
などがあります。メジャー ( 基準 ) は、表内の列に基づくこともでき、算出される
こともできます。
図 6-6 に、販売数量の合計、収益、ある日のあるアカウントへのある製品の販売利
益がメジャー ( 基準 ) となっているファクト表を示します。
図 6-6
サンプルレコードに
よるファクト表
製品コード
アカウント
コード
日付コード
販売数量
収益
利益
1
5
32104
1
82.12
27.12
3
17
33111
2
171.12
66.00
1
13
32567
1
82.12
27.12
ファクト表を設計する前に、そのファクト表の細分性を決定する必要があります。
細分性は、個別のトランザクション、毎日のスナップショット、あるいは毎月のス
ナップショットであったりします。図 6-6 のファクト表には、各アカウントに販売
した製品ごとに毎日 1 行が組み込まれています。したがって、このファクト表の細
分性は、アカウント別日別の製品として表現します。
次元データ モデルの作成
6-11
データ モデルの次元
データ モデルの次元
次元は、実世界での 1 セットのオブジェクト、またはイベントを表わします。デー
タ モデルのために明確にした各次元は、次元表として実装しなければなりません。
次元とは、ファクト表のメジャー ( 基準 ) を意味あるものにする修飾子です。次元
は質問の何が、いつ、どこでという局面に答えるからです。たとえば、次元をゴ
シック体で示している次のビジネス上の質問を考えてください。
■
昨年はどんなアカウントが最高の収益を生み出したか。
■
ベンダごとの利益はどうか。
■
各製品は、どれくらいの数量が売れたか。
上記の質問のうち、収益、利益、および販売数量が次元ではなくメジャー ( 基準 )
であり、数量データまたは実際のデータをそれぞれが表わしています。
次元要素
ある次元では、さまざまなレベルの要約に複数の次元要素が定義できます。たとえ
ば、販売組織の構造に関連するすべての要素が 1 つの次元を構築していることがあ
ります。図 6-7 に、アカウント次元が定義する次元要素を示します。
図 6-7
アカウント次元にお
ける次元要素
アカウント次元
地域
次元要素
テリトリ
アカウント
6-12
Informix Guide to Database Design and Implementation
データ モデルの次元
次元は、関連要素の階層から構築されています。次元の階層的な局面によって、
ユーザは前の詳細レベルよりも高いレベル ( ロール アップする ) や下いレベル ( ド
リル ダウンする ) にあるデータにアクセスする問合せが構築できます。図 6-7 に、
次元要素の階層的関係を示します。アカウントはテリトリにロール アップし、テリ
トリは地域にロール アップします。ユーザは、抽出するデータに応じて、異なるレ
ベルの次元で問合せができます。たとえば、ユーザがすべての地域に対する問合せ
を実行してから、もっと詳細な情報を得るためにテリトリまたはアカウントのレベ
ルまでドリル ダウンする場合があります。
次元要素は通常、ほかの表との連結を容易にするため、数値コードまたは短い文字
列としてデータベースに格納されます。
各次元要素では、次元が複数の次元要素を定義するのと同じ方法で、複数の次元属
性が定義できます。
次元属性
次元属性とは、次元表の列のことをいいます。各属性は、次元階層内の要約のある
レベルのことをいいます。次元要素が次元表内の階層的な関係を定義するのに対し
て、属性はユーザがよく知っている用語で次元要素を表します。図 6-8 に、アカウ
ント次元の次元要素と対応する属性を示します。
次元要素
地域
テリトリ
次元属性
図 6-8
次元要素に対応する
属性
地域
地域サイズ
地域管理者
テリトリ
営業員
アカウント
アカウント コード
アカウント名
次元データ モデルの作成
6-13
データ モデルの次元
次元属性は次元内の項目を記述するため、テキストの場合がもっとも便利です。
ヒント : 設計プロセスにある間に、生産データ ソースからの数値データ フィール
ドが計測済みのファクトなのか属性なのかがわからないことがあります。一般に、
サンプリングを行うたびに数値データ フィールドが変化する計測値の場合は、ファ
クトです。ほぼ一定の何かを個別に評価した説明の場合は、次元属性です。
次元表
次元表は、ビジネスの次元についてのテキストの説明を格納する表です。次元表に
は、適切な場合、階層の各レベルの要素と属性が含まれています。データ分析に必
要な最低レベルの詳細によって、その階層の最低レベルが決定します。この基本レ
ベルよりも高いレベルが冗長データを格納します。この正規化されていない表で
は、問合せに必要な結合部分の数が低減して、ユーザが高いレベルに問合せしてか
ら詳細レベルにドリル ダウンすることが簡単になります。ドリル ダウンという用
語は、次元表から問合せに対して行ヘッダを追加することを意味します。図 6-9 に、
アカウント次元を基盤とする次元表の例を示します。
図 6-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
6-14
Informix Guide to Database Design and Implementation
次元データ モデルの作成
次元データ モデルの作成
次元データ モデルを作成するには、データベース設計を完成させるために必要な意
思決定を概説する方法論が必要です。この方法論では、トップダウン ( 上から下へ
) のアプローチを使用します。それは、データを収集する組織の主要プロセスを最
初に明確にするからです。組織が使用している既存の情報ソースから着手すること
がデータベース設計者にとっての重要なタスクです。プロセスが明確になったら、
各ビジネス プロセスから 1 つまたは複数のファクト表を作成します。次の手順で
は、データ モデルを作成するために使用する方法論を説明します。
次元データベースを作成するには
1.
モデル化するサブジェクト分野を分析するために使用するビジネス プロセ
スを選択します。
2.
ファクト表の細分性を決定します。
3.
各ファクト表の次元と階層を明確にします。
4.
ファクト表のメジャー ( 基準 ) を明確にします。
5.
各次元表の属性を決定します。
6.
ユーザにデータ モデルを確認させます。
次元データベースは、複数のビジネス モデルにもとづいていたり、多くのファクト
表を持っていたりしますが、この節で説明するデータ モデルは単一のビジネス プ
ロセスに基づいており、ファクト表も 1 つです。
次元データ モデルの作成
6-15
ビジネス プロセスの選択
ビジネス プロセスの選択
ビジネス プロセスは、従来のシステムが支援する組織において重要なオペレーショ
ンです。このシステムからデータを収集して、次元データベースに使用します。ビ
ジネス プロセスでは、それらのデータを使用してエンドユーザが何を行うのか、ど
こから来たデータなのか、そのデータを意味あるものにするにはどうやって変換す
るのかを明確にします。財務、売上げ分析、市場分析、顧客プロファイルなど、数
多くのソースから情報が発生します。次のリストは、どんなデータを次元データ
ベースに組み込むかを判断するために使用するかもしれないさまざまなビジネス プ
ロセスを示しています。
■
販売
■
出荷
■
在庫
■
受注
■
請求
ビジネス プロセスの要約
たとえば、もっと効率的なマーケティング戦略を開発できるように、ユーザの組織
が顧客の購買動向を製品ラインと地域ごとに分析するとします。このシナリオで
は、データ モデルの対象エリアは販売です。
多くのインタビューを行い、販売ビジネス プロセスを完全に分析してから、ユーザ
の組織は次の情報を収集するとします。
■
顧客ベースの情報が変化しました。
以前は、営業地区を都市ごとに分割していました。現在、顧客のベース
は、2 つの地域に対応しています。地域 1 としてカリフォルニアと地域 2
としてその他の州です。
■
■
6-16
次のレポートは、マーケティング上で最も重要です。
❑
ベンダ当たりの製品別の毎月の収益、コスト、純利益
❑
製品、地域、月別の収益と販売数量
❑
毎月の顧客収益
❑
ベンダ当たりの四半期の収益
販売分析のほとんどは月ごとの結果に基づいていますが、後日には、週ご
と、または会計期間ごとに売上げを分析するように選択できます。
Informix Guide to Database Design and Implementation
ビジネス プロセスの要約
■
データ入力システムは、リレーショナル データベースにあります。
作業用のデータ モデルを開発するには、販売情報のリレーショナル デー
タベースに次のプロパティがあると想定できます。
❑
データベース stores7 は、マーケティング部門が使用する収益データの
多くを提供します。
❑
分析担当者が使用する製品コードは、カタログ番号として表 catalog に
格納されています。
❑
製品ラインコードは、ストック番号として表 stock に格納されていま
す。製品ライン名は、説明として格納されています。
❑
製品階層はやや複雑です。各製品ラインには多くの製品があり、各
メーカーにも多くの製品があります。
■
各製品のコスト データはすべて、異なる購買システムの costs.lst というフ
ラット ファイルに格納されています。
■
顧客データは、データベース stores7 に格納されています。
地域情報は、このデータベースにまだ追加されていません。
次元モデルの重要な特性は、このモデルが内部の表名や列名ではなく、エンド ユー
ザがよく知っているビジネス ラベルを使用していることです。ビジネス プロセス
が完了すれば、次元データ モデルのメジャー ( 基準 )、次元、および関係を作成す
るために必要なすべての情報が入手できているはずです。この次元データ モデルを
使用して、第 7 章で説明するデータベース sales_demo を実装します。
次元データベース stores7 は、この章で開発する次元データ モデルの主要なデータ
ソースです。データベース sales_demo の表を移植するために使用するデータ ソース
についての詳細は、7-6 ページの「データ ソースからデータベースへのデータの
マッピング」を参照してください。
次元データ モデルの作成
6-17
ファクト表の細分性の決定
ファクト表の細分性の決定
対象分野についての関連情報がすべてそろったら、設計プロセスでの次の手順は
ファクト表の細分性を決定することです。これを行うには、ファクト表に個別の低
いレベルのどんなレコードを組み込むかを決定する必要があります。ファクト表の
細分性を作り上げる構成要素は、データ モデルの次元と直接一致します。したがっ
て、ファクト表の細分性を定義するときは、データ モデルの次元を明確にします。
細分性のデータベース サイズへの影響力
ファクト表の細分性は、データベースに必要な格納領域量も決定します。たとえ
ば、ファクト表について考えられる次の細分性を考えてください。
■
日別地域別の製品
■
月別地域別の製品
日別地域別の製品という細分性を持つデータベースのサイズは、月別地域別の製品
という細分性を持ったデータベースよりもはるかに大きくなります。これは、トラ
ンザクションの月次要約とは対照的に、毎日のトランザクションそれぞれについて
のレコードがデータベースに組み込まれるからです。細分性が細かすぎると自然と
膨大なデータベースになってしまう可能性があるため、ファクト表の細分性は注意
して決定する必要があります。反対に、細分性を大まかにしすぎると、ユーザが
データベースに対して意味のある問合せを行うのに十分な詳細が得られないことに
なります。
ビジネスプロセスを使用しての細分性の決定
ビジネス プロセスから収集した情報を入念に検討することによって、ファクト表の
細分性を決定するには何が必要かがわかります。要約すると、もっと効率的なマー
ケティング戦略が開発できるように、ユーザの組織は顧客の購買動向を製品ライン
別と地区別に分析するということです。
6-18
Informix Guide to Database Design and Implementation
ファクト表の細分性の決定
製品別顧客
ファクト表の細分性は常に、対応する各次元の最低のレベルを表わします。ビジネ
ス プロセスからの情報を検討すれば、ファクト表の顧客と製品の次元についての細
分性が明らかになります。顧客と製品については、これ以上は正当に細かくできま
せん。顧客と製品はすでに、ファクト表の個別レコードの最低レベルを表わしてい
ます ( 製品は複数の構成要素から構成されていることもあるため、製品構成要素の
レベルまで、さらに細かくできる場合もあります )。
製品別地区別の顧客
ユーザの組織が分析する顧客購買動向には地理的な構成要素が含まれているため、
この場合も、地域情報については最低レベルを決定する必要があります。ビジネス
プロセスでは、これまでは販売地区が都市によって分割されていましたが、ユーザ
の組織では現在、顧客ベースの 2 つの地域間で区別が行われています。地域 1 とし
てカリフォルニア州と地域 2 としてその他の州です。しかしそれでも、最低のレベ
ルでは、ユーザの組織では今でも販売地区データを組み込んでいるため、地区は地
理的情報の最低レベルを表わしており、ファクト表の細分性をさらに定義する第 3
の構成要素となっています。
製品別地区別日別の顧客
顧客購買動向は常に時経過によって発生するため、ファクト表の細分性には時間要
素を組み込む必要があります。ユーザの組織では、週、会計期間、月、四半期、年
およびごとにレポートを作成するように決定したとします。最低レベルでは、おそ
らく基本の細分性である「日」を選択します。この細分性では、ユーザの会社では
火曜日の売上げと金曜日の売上げを比較したり、毎月の最初の日の売上げを比較し
たりなどができます。ファクト表の細分性は、これで完成しました。
日の細分性を選択するという決定は、次元表 time の各レコードが日を表わすことを
意味します。格納要件という点から見ると、毎日のデータが 10 年分あっても、約
3,650 レコードにすぎず、比較的小さな次元表といえます。
次元データ モデルの作成
6-19
次元と階層の明確化
次元と階層の明確化
ファクト表の細分性を決定したら、データ モデルの主要な次元を明確にするのは簡
単です。これは、細分性を定義する各構成要素が次元に対応しているからです。図
6-10 は、ファクト表の細分性とデータ モデルの次元との関係を示しています。
ファクト表の細分性
次元 :
図 6-10
データ モデルの次元
に対応するファクト
表の細分性
製品別地区別日別の顧客
顧客
製品
地理
時間
データ モデルの次元 ( 顧客、製品、地理、時間 ) を正しい位置に使用すると、ス
キーマ ダイアグラムが形になってきます。
ヒント : この時点で、ファクト表の主要な細分性に更に次元を追加できます。この
場合、新しい次元は主要次元の各組合わせにおいて単一の値しかとれません。追加
した次元がさらにレコードを発生させることになって、細分性に違反していること
を確認した場合は、ファクト表の細分性を改訂して、追加した次元が納まるように
する必要があります。このデータ モデルについては、追加した次元を追加する必要
はありません。
6-20
Informix Guide to Database Design and Implementation
次元と階層の明確化
この時点で、各次元の次元要素と階層がマップできます。6-21 ページの図 6-11 は、
次元、次元要素、および固有の階層間の関係を示しています。
次元要素
属性
ベンダ
ベンダ
図 6-11
次元、次元要素、お
よび固有の階層間の
関係
製品
製品名
製品ライン
製品ライン名
製品
顧客
顧客名
企業
地域
州
州名
地区
地区名
年
四半期
月
日
受注日
次元データ モデルの作成
6-21
ファクト表のメジャー ( 基準 ) の選択
ほとんどの場合、次元要素では、各次元についての考えられる最低の細分性を表現
する必要があります。これは、問合せが個別の低いレベルのレコードにアクセスす
るからではなく、問合せには厳密な方法でデータベースを検索する必要があるから
です。つまり、データ ウェアハウス環境が提起する問題が通常、大まかなもので
あったとしてもまだ、これらの質問は製品詳細の最低レベルに依存します。
ファクト表のメジャー ( 基準 ) の選択
データ モデルのメジャー ( 基準 ) には、データそのものだけでなく、既存のデータ
から計算する新しい値も含まれます。そのため、メジャー ( 基準 ) を調べると、
ファクト表の細分性だけでなく次元の数も調整する必要がでてくる場合もありま
す。
データ モデルを設計するときに必要なもう 1 つの重要な決定事項は、計算結果を
ファクト表に格納するか、これらの値を実行時に導出するかです。
最初に答えなければならない質問は、
「ビジネスを分析するのにどんなメジャー ( 基
準 ) を使用するか」です。メジャー ( 基準 ) は、どれくらいの量、またはどれくら
いの数かを示す量的なデータか、実際のデータであることを思い出してください。
販売ビジネス プロセスの分析から集めた情報は、次のリストのメジャー ( 基準 ) に
なります。
6-22
■
収益
■
コスト
■
販売数量
■
純利益
Informix Guide to Database Design and Implementation
ファクト表のメジャー ( 基準 ) の選択
これらのメジャーを使用して、図 6-12 のファクト表が完成します。
図 6-12
各次元表を参照する
販売ファクト表
製品次元
時間次元
時間コード
製品コード
販売ファクト表
製品コード
時間コード
地区コード
顧客コード
地理次元
地区コード
収益
コスト
販売数量
純利益
顧客次元
顧客コード
次元データ モデルの作成
6-23
ファクト表のメジャー ( 基準 ) の選択
ファクト表を次元表と結合するキーの使用
さしあたり、6-23 ページの図 6-12 のスキーマは、データベースの論理設計と物理
設計の両方が示されていると考えてください。データベースには次の 5 つの表が含
まれています。
■
販売ファクト表
■
製品次元表
■
時間次元表
■
顧客次元表
■
地理次元表
各次元表には、主キー ( 製品、時間コード、顧客、地域コード ) が含まれていて、
ファクト表では対応する列は外部キーです。ファクト表には、これら 4 つの外部
キーの組み合わせである主 ( 複合 ) キーもあります。原則として、ファクト表の各
外部キーには、次元表にそれと 1 対になるキーがなければなりません。さらに、複
合キーを備えている次元データベースの表は、ファクト表である必要があります。
つまりこれは、多数対多数の関係を表わす次元データベースの各表がファクト表で
あることを意味します。
ヒント : 主キーは、INT、SMALLINT、SERIAL といった短い数値データ型か、コー
ドで使用するような短い文字列であるべきです。Informix では、長い文字列を主キー
として使用しないようにお勧めします。
6-24
Informix Guide to Database Design and Implementation
正規化の阻止
正規化の阻止
ファクト表の 4 つの外部キーは、きちんと管理された連続整数である場合、ファク
ト表の 4 つのキーすべてに対して 16 バイト ( 時間、製品、顧客、および地理につい
て 4 バイトずつ ) まで小さくして予約できます。ファクト表の 4 つのメジャー ( 基
準 ) が各 4 バイトの整数列であれば、別に 16 バイトだけを予約する必要しかありま
せん。したがって、ファクト表の各レコードは 32 バイトになるにすぎません。何
十億の列のあるファクト表でも、約 32 ギガバイトの主データ空間が必要になるだ
けです。
コンパクトなキーやデータを使用している、記憶量の少ないファクト表が次元デー
タベースの典型です。次元モデルのファクト表は元来、高度に正規化されていま
す。ファクト表の 4 つのキー間のきわめて複雑な多数対多数の関係はこれ以上正規
化できません。4 つの次元表に相互間系がないからです。実際には、各製品は、各
地区のすべての顧客に対して毎日販売されています。
ファクト表は、次元データベースで一番大きな表です。次元表は通常、ファクト表
よりもかなり小さいため、データベースのディスク領域を計算するときには次元表
を無視することができます。ディスク領域を節約するためだけに次元データベース
のどんな表でも正規化するという努力は、的を得ていません。さらに、正規化され
た次元表は、ユーザが単一の次元表を探索して制約を設定したり、便利な行ヘッダ
を選択したりする能力を低減します。
次元データ モデルの作成
6-25
次元表の属性の選択
次元表の属性の選択
ファクト表が完成したら、各次元表の次元属性が決定できます。属性を選択する方
法を説明するために、時間次元を考えてみましょう。販売ビジネス プロセスのデー
タ モデルは、次元表 time の各レコードが日を表わすように、時間次元に対応する
日の細分性を定義します。この表の各フィールドは、そのレコードが表わしている
特定日によって定義されることを覚えておいてください。
販売ビジネス プロセスの分析では、マーケティング部門が月次、四半期、年次のレ
ポートを必要としていることも示しているため、時間次元には、日、月、四半期、
年という要素が含まれます。各要素には、長い文字列を含んでいる列値を回避する
ために、その要素とコード属性を説明する属性が割り当てられています。図 6-13
は、次元表 time の属性と、表の各フィールドのサンプル値を示しています。
図 6-13
時間次元の属性
時間コード
受注日
月コード
月
四半期コード
半期
年
35276
07/31/1996
7
july
3
third q
1996
35277
08/01/1996
8
aug
3
third q
1996
35278
08/02/1996
8
aug
3
third q
1996
6-26
Informix Guide to Database Design and Implementation
次元表の属性の選択
6-26 ページの図 6-13 では、割り当てる属性名は、エンド ユーザがデータベース上
で問合せを簡単に作成できるような、なじみのあるビジネス用語であるべきことを
示しています。図 6-14 では、各次元表に定義されている属性すべてを備えた販売ビ
ジネス プロセスの完璧なデータ モデルを示します。
製品次元
時間次元
製品コード
時間コード
製品名
ベンダ
ベンダ名
製品ライン
製品ライン名
受注日
月
四半期
年
販売ファクト表
製品コード
図 6-14
販売ビジネス プロセ
スの完璧な次元
データ モデル
時間コード
地区コード
顧客コード
地理次元
収益
コスト
販売数量
純利益
顧客次元
地区コード
顧客コード
地区
州
州名
地域
顧客名
会社
ヒント : 各次元表に定義する属性の数は一般に、最低限に保つべきです。属性が多
すぎる次元表は、行を過度に大きくしたり、パフォーマンスを劣化させたりするこ
とがあります。詳細は、6-28 ページの「次元表の属性数を最低限に抑える」を参照
してください。
次元データ モデルの作成
6-27
次元データ モデルの共通する問題の処理
次元データ モデルの共通する問題の処理
これまでの節で説明してきた次元モデルは、次元データ モデルの最も基本的なコン
セプトとテクニックを説明するものにすぎません。エンタプライズのビジネス上の
ニーズを明確にするために作成するデータ モデルには、通常、データベースからで
きる限り最高の問合せパフォーマンスを得るために解決する必要のある、さらなる
問題や困難が含まれています。この節では、次元データ モデルを作成するときに最
も共通して発生する問題の解決に使用できるさまざまな方法を説明します。
次元表の属性数を最低限に抑える
顧客情報や製品情報が入っている次元表には、ゆうに 50 ∼ 100 個の属性があった
り、行が数百万あったりします。しかし、属性が多すぎる次元表は、行を過度に大
きくしたり、パフォーマンスを劣化させたりすることがあります。このため、特定
の属性のグループを次元表から切り離して、小次元表という別個の表にそれらを配
置することもあります。小次元表は、大きな次元表から切り離された小さな属性グ
ループから構成されます。次の特性のどちらかを持つ属性に小次元表を作成するこ
とを選択するかもしれません。
6-28
■
問合せの制約として、フィールドをほとんど使用しない。
■
フィールドを頻繁に比較し合う。
Informix Guide to Database Design and Implementation
次元表の属性数を最低限に抑える
図 6-15 は、顧客表から切り離された人口情報についての小次元表を示しています。
図 6-15
人口情報についての
小次元表
顧客表
顧客コード
顧客名
人口コード
.
.
.
ファクト表
顧客コード
人口コード
.
.
.
人口表
人口コード
収入レベル
配偶者の有無
.
.
.
次元データ モデルの作成
6-29
時々変更する次元の処理
人口表では、ファクト表にも、顧客表にも、外部キーとして人口キーが格納できま
す。これによって、人口表を直接ファクト表に結合することができます。また、直
接顧客表と一緒に人口キーを使用して、人口属性を閲覧することもできます。
時々変更する次元の処理
OLTP システムとは対照的に、ほとんど更新されない次元表では、ほとんどの次元
は時が経っても比較的変化しません。販売地区または地域、あるいは会社の名前や
住所にはほとんど変更がないからです。しかし、履歴比較を行うには、これらの変
更は、それが発生した時点で処理する必要があります。図 6-16 は、変更が加えられ
た次元の例を示しています。
図 6-16
変更した次元
顧客
101
Bill Adams
The Sports Palace
Des Plaines
Il
.
.
.
6-30
Informix Guide to Database Design and Implementation
移動 !
Arlington Heights
時々変更する次元の処理
次元に発生した変更を処理するには、次の 3 種類の方法が使用できます。
■
次元列に格納されている値を変更します。
6-30 ページの図 6-16 には、顧客次元表の Bill Adams のレコードが更新さ
れて、新しい住所である Arlington Heights が示されています。この時点
で、この顧客のこれまでの販売履歴のすべてが、Park Ridge ではなくて、
Arlington Heights の地区と関連付けられています。
■
新しい値や一般化キーを使用して 2 番目の次元レコードを作成します。
この方法は、効率的に履歴を区分わけします。顧客次元表はこの時点で、
Bill Adams についての 2 つの履歴を含んでいます。キー 101 のある以前の
レコードが残り、この時点ではファクト表のレコードも以前のレコードに
関連付けられています。新しいレコードも Bill Adams の顧客表に追加され
て、以前のキーと、たとえば 101.01 といったバージョンの桁から構成され
る新しいキーがついています。Bill Adams のファクト表に追加された後続
のすべてのレコードが、この新しいキーと関連付けられます。
■
影響を受ける属性の次元表に新しいフィールドを追加して、以前の属性の
名前を変更します。
新しい値についての以前の履歴を追跡したり、以前の履歴の新しい値を追
跡したりする必要がない限り、この方法はほとんど使用されません。顧客
表は、current address という名前の新しい属性を取得し、以前の属性は
original address に変更します。Bill Adams についての情報を含んでいるレ
コードには、元の住所と現在の住所の両方の値が含まれます。
次元データ モデルの作成
6-31
スノーフレーク スキーマの使用
スノーフレーク スキーマの使用
スノーフレーク スキーマは、スター スキーマの変形であり、かなり大きな次元表
を複数の表に正規化します。ファクト表の集合体を使用している場合に大きな次元
表の結合を避けたい場合は、階層のある次元をスノーフレーク構造に分解すること
ができます。たとえば、製品次元表から切り離すブランド情報がある場合は、ブラ
ンドごとの単一の行から構成されていて、製品次元表よりも大幅に行数の少ないブ
ランド スノーフレークが作成できます。図 6-17 は、ブランド要素と製品ライン要
素のスノーフレークと、集合表 brand_agg を示しています。
販売ファクト表
ブランド表
ブランドコード
ブランド名
ブランド管理者
製品表
製品コード
製品コード
時間コード
製品名
.
.
.
アカウント コード
顧客コード
ブランド コード
製品ライン コード
製品ライン表
6-32
収益
コスト
販売数量
純利益
集合表 Brand_Agg
製品ライン コード
brand code
製品ライン名
ライン管理者
総収益
総コスト
Informix Guide to Database Design and Implementation
図 6-17
スノーフレーク ス
キーマの例
スノーフレーク スキーマの使用
ブランド コードとブランド当たりの総収益から構成される集合 brand_agg を作成す
る場合は、スノーフレーク スキーマを使用すると、次の表 brand と brand_agg の問
合せが示すように、より大きな表 sales との結合が避けられます。
SELECT brand.brand_name, brand_agg.total_revenue
FROM brand, brand_agg
WHERE brand.brand_code = brand_agg.brand_code
AND brand.brand_name = 'Anza'
スノーフレーク次元表を使用しない場合、すべてのブランドと製品ラインの属性を
含んでいる可能性のある、きわめて大きな次元表である表 product 全体に SELECT
UNIQUE 文または SELECT DISTINCT 文を使用して、重複行を除去します。
次元表が比較的小さくて、スノーフレーク スキーマが不要であっても、数百万行も
ある顧客や製品の次元表のあるような小売業や通信販売ビジネスでは、スノーフ
レーク スキーマを使用するとパフォーマンスが大幅に向上します。
集合表が利用できない場合、スノーフレーク スキーマで正規化された次元要素に結
合する何らかのものは現在、次の問合せが示すように 3 方向結合である必要があり
ます。3 方向結合によって、次元データベースのパフォーマンス上の長所が幾分損
なわれてしまいます。
SELECT brand.brand_name, SUM(sales.revenue)
FROM product, brand, sales
WHERE product.brand_code = brand.brand_code
AND brand.brand_name = 'Alltemp'
GROUP BY brand_name
次元データ モデルの作成
6-33
第7章
多次元データモデルの実装
次元データベースの実装 . . . . . . . . . . . .
CREATE DATABASE 文の使用 . . . . . . . . .
CREATE TABLE 文を使用した次元表およびファクト表の作成
データ ソースからデータベースへのデータのマッピング . .
次元データベースへのデータのロード . . . . . . .
コマンド ファイルを使用したデータベース sales_demo の作成
次元データベースのテスト . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7-3
7-3
7-4
7-6
7-9
7-11
7-12
Dynamic Server with AD and XP Options のログ付き表とログなし表
表の種類の選択 . . . . . . . . . . . . . .
スクラッチ表と Temp 表 . . . . . . . . . .
ロウ永続表 . . . . . . . . . . . . . .
静的永続表 . . . . . . . . . . . . . .
オペレーショナル永続表 . . . . . . . . . .
標準永続表 . . . . . . . . . . . . . .
表の種類の切替え . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7-13
7-14
7-15
7-16
7-16
7-17
7-17
7-18
データ ウェアハウス環境のインデックス. . . . . .
データ ウェアハウス環境での GK インデックスの使用
選択での GK インデックスの定義 . . . . .
式での GK インデックスの定義 . . . . . .
結合された表での GK インデックスの定義 . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7-18
7-20
7-20
7-21
7-21
.
.
.
.
.
.
.
.
.
.
7-2
Informix Guide to Database Design and Implementation
この章では、SQL を使用して、第 6 章で説明した次元データ モデルを実装する方法
について説明します。このデータベースは、データ ウェアハウス環境を説明するた
めの単なる例です。例として示すために、説明は SQL 文に翻訳してあります。
この章では、データ ウェアハウジングや大規模なデータベース アプリケーション
のニーズに適したInformix Dynamic Server with Advanced Decision Support and Extended
Parallel Options 用の表の種類とインデックスについても説明します。
次元データベースの実装
この節では、第 6 章で説明したデータ モデルから次元データベースを作成するため
に使用できる SQL 文について説明します。対話型 SQL を使用すると、データベー
スを作成するための個々の文を書き込むことができます。または、コマンド スクリ
プトを実行して、データベースの実装に必要なすべての文を自動的に実行できま
す。CREATE DATABASE 文と CREATE TABLE 文は、データベース内の表として
データ モデルを作成します。いったんデータベースを作成すると、LOAD 文と
INSERT 文を使用して表を構築できます。
CREATE DATABASE 文の使用
データベース内に表やオブジェクトを作成するには、まずデータベースを作成する
必要があります。
Informix データベース サーバでデータベースを作成する場合、サーバは、データ
ベースが存在していることとデータベースのロギング モードを示すレコードを設定
します。データベース サーバはディスク領域を直接管理するので、これらのレコー
ドはオペレーティング システムのコマンドでは見れません。
IDS
Informix Dynamic Server を使用してデータベースを作成する場合は、ログ機能をオ
フにできます。 ♦
多次元データモデルの実装
7-3
CREATE TABLE 文を使用した次元表およびファクト表の作成
AD/XP
Dynamic Server with AD and XP Options を使用してデータベースを作成すると、ログ
機能は常にオンになります。次の文は、ログ機能付きのデータベース sales_demo を
作成します。
CREATE DATABASE sales_demo
Dynamic Server with AD and XP Options を使用して作成するデータベースはすべてロ
グ付きデータベースになりますが、そのデータベース内にログなし表を作成するこ
とができます。Dynamic Server with AD and XP Options がサポートするログ付き表と
ログなし表については、7-13 ページの「Dynamic Server with AD and XP Options のロ
グ付き表とログなし表」を参照してください。 ♦
CREATE TABLE 文を使用した次元表およびファクト表の作成
この節では、次元データベース sales_demo の表を作成するために使用する CREATE
TABLE 文について説明します。
参照整合性は、もちろん、次元データベースの重要な条件ですが、データベース
sales_demo に関する以下のスキーマでは、ファクト表と次元表との間に存在する主
キーと外部キーの関係を定義していません。このスキーマでそのような主キーと外
部キーとの関係を定義していない理由は、データをロードする際にデータベース
サーバが制約確認を実行しなければ、ロードのパフォーマンスが大幅に向上するた
めです。データ ウェアハウス環境で特定の時間内に数十から数百ギガバイトのデー
タをロードする必要が頻繁にある場合、データをロードするパフォーマンスは、
データベースをウェアハウス環境に実装する方法を決定するにあたって重要な要素
になります。稼働中のデータ マートとしてデータベース sales_demo が実装されてい
ることを想定した場合、ファクト表と次元表との間の参照整合性を保つために、
データベース サーバではなくデータ抽出ツールが使用されます。
ヒント : 表を作成してロードした後で、参照整合性を保つために、ALTER TABLE
文を使用して主キー制約と外部キー制約を表に追加できます。この方法は、高速
ロード モードの場合にだけ必要です。制約とインデックスが必要で、ロードする前
に削除するのに手間がかかる場合には精細ロード モードが最適なオプションです。
7-4
Informix Guide to Database Design and Implementation
CREATE TABLE 文を使用した次元表およびファクト表の作成
以下の文は、表 time、geography、product、および customer を作成します。これらの
表は、ファクト表 sales に対する次元表です。シリアル (SERIAL) 型のフィールド
は、表 geography の列 district_code の主キーとして機能します。
CREATE TABLE time
(
time_code INT,
order_date DATE,
month_code SMALLINT,
month_name CHAR(10),
quarter_code SMALLINT,
quarter_name CHAR(10),
year INTEGER
);
CREATE TABLE geography (
district_code SERIAL,
district_name CHAR(15),
state_code CHAR(2),
state_name CHAR(18),
region SMALLINT
);
CREATE TABLE product (
product_code INTEGER,
product_name CHAR(31),
vendor_code CHAR(3),
vendor_name CHAR(15),
product_line_code SMALLINT,
product_line_name CHAR(15)
);
CREATE TABLE customer (
customer_code INTEGER,
customer_name CHAR(31),
company_name CHAR(20));
多次元データモデルの実装
7-5
データ ソースからデータベースへのデータのマッピング
ファクト表 sales には、それぞれの次元表へのポインタがあります。たとえば、
customer_code は表 customer を参照し、district_code は表 geography を参照します。表
sales には、売上数量、売上高、コスト、および純利益のメジャー ( 基準 ) も含まれ
ています。
CREATE TABLE sales
(
customer_code INTEGER,
district_code SMALLINT,
time_code INTEGER,
product_code INTEGER,
units_sold SMALLINT,
revenue MONEY(8,2),
cost MONEY(8,2),
net_profit MONEY(8,2)
);
ヒント : 最も便利なメジャー( ファクト ) は加算的な数値です。データ ウェアハウス
環境ではデータベースのサイズが非常に大きいため、ファクト表に対するほとんど
すべての問合せで、その答えを構築するために数千から数百万のレコードが必要に
なります。そのようなレコードを圧縮するために使用できる唯一の方法は、レコー
ドを集約することです。表 sales では、メジャーの各列が数値データ型で定義され
ているので、units_sold、revenue、cost、net_profit の各列から答えを容易に作成で
きます。
ファイル createdw.sql には、上記の CREATE TABLE 文がすべて含まれています。
UNIX
UNIX オペレーティング システム上でデータベース サーバを実行している場合、
ファイル createdw.sql にはディレクトリ $INFORMIXDIR/demo/dbaccess からアクセス
できます。 ♦
WIN NT
Windows NT オペレーティング システム上でデータベース サーバを実行している場
合、ファイル createdw.sql にはディレクトリ %INFORMIXDIR%¥demo¥dbaccess から
アクセスできます。 ♦
データ ソースからデータベースへのデータのマッピング
デモンストレーション データベース stores7 は、データベース sales_demo の主デー
タ ソースです。
7-7 ページの図 7-1 は、データ ウェアハウスのビジネス用語とデータ ソースとの関
係を表しています。その表は、データベース sales_demo のそれぞれの列と表のデー
タ ソースも表しています。
7-6
Informix Guide to Database Design and Implementation
データ ソースからデータベースへのデータのマッピング
図 7-1
データ ウェアハウスのビジネス用語とデータ ソースの関係
ビジネス用語
データ ソース
表 . 列名
ファクト表 sales
製品コード
sales.product_code
顧客コード
sales.customer_code
地区コード
sales.district_code
時間コード
sales.time_code
収益
stores7:items.total_price
sales.revenue
売上数量
stores7:items.quantity
sales.units_sold
コスト
costs.lst (per unit)
sales.cost
純利益
計算結果 : 収益 - コスト
sales.net_profit
製品
stores7:catalog.catalog_num
product.product_code
製品名
stores7:stock.manu_code および
stores7:stock.description
product.product_name
製品ライン
stores7:orders.stock_num
product.product_line_code
製品ライン名
stores7:stock.description
product.product_line_name
ベンダ
stores7:orders.manu_code
product.vendor_code
ベンダ名
stores7:manufact.manu_name
product.vendor_name
顧客
stores7:orders.customer_num
customer.customer_code
顧客名
stores7:customer.fname および
stores7:customer.lname
customer.customer_name
会社名
stores7:customer.company
customer.company_name
次元表 product
次元表 customer
(1/2)
多次元データモデルの実装
7-7
データ ソースからデータベースへのデータのマッピング
ビジネス用語
データ ソース
表 . 列名
地区コード
生成される
geography.district_code
地区
stores7:customer.city
geography.district_name
州
stores7:customer.state
geography.state_code
州名
stores7.state.sname
geography.state_name
地方
導出される : If state = "CA"
THEN region = 1, ELSE region =
2
geography.region
時間コード
生成される
time.time_code
注文日
stores7:orders.order_date
time.order_date
月
生成された注文日から導出さ
れる
time.month_name
time.month.code
四半期
derived from order date generated time.quarter_name
time.quarter_code
年
注文日から導出される
次元表 geography
次元表 time
time.year
(2/2)
接尾辞 .unl を持ついくつかのファイルには、データベース sales_demo 内にロードさ
れたデータが含まれています。データベースを作成してロードする SQL 文を含む
ファイルには、接尾辞 .sql が付いています。
UNIX
UNIX オペレーティング システム上でデータベース サーバを実行している場合、
ファイル *.sql および *.unl にはディレクトリ $INFORMIXDIR/demo/dbaccess からア
クセスできます。 ♦
WIN NT
Windows NT オペレーティング システム上でデータベース サーバを実行している場
合、ファイル *.sql および *.unl にはディレクトリ %INFORMIXDIR%¥demo¥dbaccess
からアクセスできます。 ♦
接尾辞 .sql を持つファイルには、コマンド ファイルとして DB-Access からもアクセ
スできます。
7-8
Informix Guide to Database Design and Implementation
次元データベースへのデータのロード
次元データベースへのデータのロード
次元データベースを実装する場合に重要なことは、効果的なロード方法を立案して
文章化することです。この節では、データベース sales_demo の表を構築するために
使用できる LOAD 文と INSERT 文について説明します。
ヒント : 稼働中のデータ ウェアハウス環境では、大量のデータを Informix データ
ベースにロードしたり Informix データベースからロードしたりする場合に、通常は
LOAD 文も INSERT 文も使用しません。Dynamic Server および Dynamic Server
with AD and XP Options は、データのハイパフォーマンスなロードとアンロードの
ための別の機能を提供します。
IDS
AD/XP
Dynamic Server を使用してデータベースを作成する場合は、ハイパフォーマンス
ローダ (HPL) を使用してハイパフォーマンスなロードとアンロードを実行できま
す。 ♦
Dynamic Server with AD and XP Options を使用してデータベースを作成する場合は、
外部表を使用してハイパフォーマンスなロードとアンロードを実行できます。 ♦
ハイパフォーマンスなロードについては、
『Administrator’s Guide』またはハイパ
フォーマンスローダのマニュアルを参照してください。
次の文は、表 sales 内にロードされる各行の時間コードの確定に使用できるように、
最初に表 time にデータをロードします。
LOAD FROM 'time.unl'
INSERT INTO time;
次の文は表 geography にデータをロードします。表 geography にデータをロードする
と、その地区コード データを、表 sales にロードするために使用できます。
INSERT INTO geography(district_name, state_code,
state_name)
SELECT DISTINCT c.city, s.code, s.sname
FROM stores7:customer c, stores7: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';
多次元データモデルの実装
7-9
次元データベースへのデータのロード
次の文は、表 customer にデータをロードします。
INSERT INTO customer
(customer_code, customer_name, company_name)
SELECT c.customer_num, trim(c.fname) ||' '|| c.lname,
c.company
FROM stores7: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 stores7:catalog a, stores7:manufact m,
stores7:stock s
WHERE a.stock_num = s.stock_num
AND a.manu_code = s.manu_code
AND s.manu_code = m.manu_code;
次の文は、ファクト表 sales の 1 つの行に、各製品の顧客別、日付別、地区別のデー
タをロードします。表 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 stores7:customer c, geography g, time t,
product p,stores7:items i, stores7:orders o, cost x
WHERE c.customer_num = o.customer_num
AND o.order_num = i.order_num
AND p.product_line_code = i.stock_num
AND p.vendor_code = i.manu_code
AND t.order_date = o.order_date
AND p.product_code = x.product_code
AND c.city = g.district_name
GROUP BY 1,2,3,4;
ファイル loaddw.sql には、上記の INSERT 文と LOAD 文がすべて含まれています。
ファイル loaddw.sql はディレクトリ $INFORMIXDIR/demo/dbaccess 内にあります。
7-10
Informix Guide to Database Design and Implementation
コマンド ファイルを使用したデータベース sales_demo の作成
コマンド ファイルを使用したデータベース sales_demo の作
成
コマンド ファイルを使用してデータベース sales_demo の表を構築できます。データ
ベース sales_demo を実装するには、ファイル createdw.sql と loaddw.sql を実行しま
す。
次元データベース sales_demo ではデータベース stores7 のデータを使用するので、
データベース sales_demo を実装するには、次元データベース sales_demo とデータ
ベース stores7 の両方を作成する必要があります。
データベース sales_demo を構築するには
1.
ご使用の Informix 製品がインストールされているディレクトリ名が含まれ
るように環境変数 INFORMIXDIR を設定します。
2.
環境変数 INFORMIXSERVER を、デフォルトのデータベース サーバ名に設
定します。
3.
次のコマンドを入力して、Informix 製品がインストールされているディレク
トリを現行ディレクトリにします。
4.
次のコマンドを入力して、データベース stores7 を作成し、デモンストレー
ション データベースの例を現行ディレクトリにコピーします。
cd $INFORMIXDIR
dbaccessdemo7
5.
次のコマンドを実行して、データベース sales_demo を作成します。
6.
次のコマンド ファイルを実行して、データベース sales_demo にデータを
ロードします。
dbaccess stores7 createdw.sql
dbaccess sales_demo loaddw.sql
データベース stores7 は、データベース sales_demo にデータをロードするた
めに必ず存在している必要があります。なぜなら、ファイル loaddw.sql は、
stores7 の表 items および表 orders に行を追加するためです。これにより、
表 items および表 orders を使用してデータベース sales_demo 内の表にデー
タをロードできます。
重要 : ファイル loaddw.sql を実行するとデータベース stores7 のデータが変更され
るので、この変更されたデータベース stores7 での問合せ結果は、Informix のマニュ
アルで説明されている、stores7 のデータに基づく SQL の例とは異なることがあり
ます。
多次元データモデルの実装
7-11
次元データベースのテスト
次元データベースのテスト
SQL 問合せを作成すると、ビジネス プロセスのまとめにリストされている標準レ
ポートのために必要なデータを抽出できます (6-16 ページの「ビジネス プロセスの
要約」を参照してください )。以下のアド ホックな問合せを使用して、次元データ
ベースが適切に実装されていることをテストします。
次の文は、各ベンダの製品ラインごとに、毎月の収益、コスト、および純利益の値
を返します。
SELECT vendor_name, product_line_name, month_name,
SUM(revenue) total_revenue, SUM(cost) total_cost,
SUM(net_profit) total_profit
FROM product, time, sales
WHERE product.product_code = sales.product_code
AND time.time_code = sales.time_code
GROUP BY vendor_name, product_line_name, month_name
ORDER BY vendor_name, product_line_name;
次の文は、製品別、地方別、月別の収益と売上数量の値を返します。
SELECT product_name, region, month_name,
SUM(revenue), SUM(units_sold)
FROM product, geography, time, sales
WHERE product.product_code = sales.product_code
AND geography.district_code = sales.district_code
AND time.time_code = sales.time_code
GROUP BY product_name, region, month_name
ORDER BY product_name, region;
次の文は、毎月の顧客収益の値を返します。
SELECT customer_name, company_name, month_name,
SUM(revenue)
FROM customer, time, sales
WHERE customer.customer_code = sales.customer_code
AND time.time_code = sales.time_code
GROUP BY customer_name, company_name, month_name
ORDER BY customer_name;
次の文は、ベンダ別の四半期ごとの収益の値を返します。
SELECT vendor_name, year, quarter_name, SUM(revenue)
FROM product, time, sales
WHERE product.product_code = sales.product_code
AND time.time_code = sales.time_code
GROUP BY vendor_name, year, quarter_name
ORDER BY vendor_name, year;
7-12
Informix Guide to Database Design and Implementation
Dynamic Server with AD and XP Options のログ付き表とログなし表
AD/XP
Dynamic Server with AD and XP Options のログ付
き表とログなし表
この節では、Dynamic Server with AD and XP Options のさまざまな表の種類について
説明します。それらの表は、データ ウェアハウス環境で使用すると特に便利です。
Dynamic Server が表のログを記録するのと同様に、Dynamic Server with AD and XP
Options はデフォルトにより表のログを記録します。しかし、大量のデータがある
一方で挿入、更新、削除がほとんどないデータ ウェアハウス環境やアプリケーショ
ンでは、同一のデータベース内にログ付き表とログなし表との組合せが必要なこと
が多くあります。多くの場合、一時表は、データベース セッションが終了すると持
続しないので不適切です。ログ付き表とログなし表の両方の必要条件を満たすため
に、Dynamic Server with AD and XP Options では次の種類の永続表と一時表をサポー
トしています。
■
ロウ永続表 ( ログなし )
■
静的永続表 ( ログなし )
■
オペレーショナル永続表 ( ログ付き )
■
標準永続表 ( ログ付き )
■
スクラッチ一時表 ( ログなし )
■
Temp 一時表 ( ログ付き )
表の種類を指定せずに CREATE TABLE 文を発行すると、標準永続表が作成されま
す。
これらの表を作成するために使用する構文については、
『Informix Guide to SQL:
Syntax』の CREATE TABLE 文を参照してください。表の種類を変更するために使
用する構文については、
『Informix Guide to SQL: Syntax』の ALTER TABLE 文を参照
してください。
重要 : コサーバが一時領域として使用したりアクセスしたりできるのは、そのコ
サーバ自体の DB 領域だけです。一時表では永続表と同様に DB 領域内を明示的に
フラグメント化できますが、コサーバは、そのコサーバ自体が管理するフラグメン
ト内にだけデータを挿入できます。
多次元データモデルの実装
7-13
表の種類の選択
表の種類の選択
データ ウェアハウス環境の個々の表では、要求される条件がそれぞれ異なることが
多くあります。以下の質問に答えていくと、使用する適切な表の種類を決定しやす
くなります。
■
表にインデックスは必要ですか ?
■
表に定義する必要のある制約は ?
■
表のリフレッシュまたは更新の周期は ?
■
表は読取り専用表ですか ?
■
表のログを記録する必要はありますか ?
図 7-2 では、Dynamic Server with AD and XP Options がサポートする 6 種類の表の属
性を一覧表示しており、外部表を使用してこれらの種類の表にデータをロードする
方法を示しています。この表の情報を使用して、使用する表に固有の必要条件に一
致する表の種類を選択してください。
図 7-2
Dynamic Server with AD and XP Options の表の種類の特性
種類
永続性
ログ
付き
インデッ
クス
簡単な
追加の
使用
ロール
バック
機能
回復機能
アーカイ
ブからの
復元機能
外部表のロー
ド モード
スクラッチ
なし
なし
なし
あり
なし
なし
なし
高速または
精細ロード
モード
Temp
なし
あり
あり
あり
あり
なし
なし
高速または
精細ロード
モード
ロウ
あり
なし
なし
あり
なし
なし
なし
高速または
精細ロード
モード
(1/2)
7-14
Informix Guide to Database Design and Implementation
表の種類の選択
種類
ログ
付き
永続性
インデッ
クス
簡単な
追加の
使用
ロール
バック
機能
回復機能
アーカイ
ブからの
復元機能
外部表のロー
ド モード
静的
あり
なし
あり
なし
なし
なし
なし
なし
オペレーショ
ナル
あり
あり
あり
あり
あり
あり
なし
高速または
精細ロード
モード
標準
あり
あり
あり
なし
あり
あり
あり
精細ロード
モード
(2/2)
スクラッチ表と Temp 表
スクラッチ表とは、インデックス、制約、ロールバック機能のいずれもサポートし
ていないログなし一時表です。
Temp 表はログ付き表ですが、簡単な追加などの一括操作もサポートしています (
高速モードのロードでは、バッファ キャッシュをバイパスする簡単な追加を使用し
ます。簡単な追加では、バッファ管理に関連するオーバーヘッドはなくなります
が、データのログは記録しません )。Temp 表は、インデックス、制約、およびロー
ルバック機能をサポートしています。
ヒント : INTO TEMP 節を指定した SELECT 文と INTO SCRATCH 節を指定した
SELECT 文は、通常の挿入と同様に、複数のコサーバ上で並列になります。INTO
TEMP 節を指定した SELECT 文と INTO SCRATCH 節を指定した SELECT 文を使
用してフラグメント一時表が明示的に作成された場合、Dynamic Server with AD
and XP Options はそれらのフラグメント一時表を自動的にサポートします。
Dynamic Server with AD and XP Options は、以下の基準に従って明示的な一時表を作
成します。
■
表 TEMP を構築するために使用する問合せによって行が生成されない場
合、データベース サーバは、フラグメント化されていない空の表を作成し
ます。
■
問合せによって生成される行が 8 キロバイトを超えない場合、
一時表は 1 つ
の DB 領域内に常駐します。
■
そのような行が 8 キロバイトを超える場合、Dynamic Server with AD and XP
Options は複数のフラグメントを作成し、ラウンドロビン フラグメンテー
ション スキーマを使用してそれらのフラグメントを構築します。
多次元データモデルの実装
7-15
表の種類の選択
ロウ永続表
ロウ表は、簡単な追加を使用するログなし永続表です。高速モードのロードでは、
バッファ キャッシュをバイパスする簡単な追加を使用します。ロウ表には、高速
モードでデータをロードできます。高速モードのロードについては、
『Administrator’s Guide』を参照してください。
ロウ表は、更新、挿入、削除をサポートしますが、それらのログは記録しません。
ロウ表は、インデックス、参照制約、ロールバック機能、回復機能、アーカイブか
らの復元機能のいずれもサポートしていません。
最初のデータのロードとスクラビングにロウ表を使用します。それらの手順を完了
したら、より高いレベルに表を変更します。たとえば、ロウ表にロードしていると
きにエラーか障害が発生すると、その結果のデータは、障害が発生した時点にディ
スク上にあったデータになります。
データ ウェアハウス環境では、以下の両方の条件に当てはまる場合、ファクト表を
ロウ表として作成できます。
■
いくつかの機構によっては制約やインデックスが必要なことがあるが、そ
のような制約もインデックスもファクト表で指定する必要がない。
■
ファクト表を作成することにもファクト表にデータをロードすることにも
コストがかからない。ファクト表は、意思決定支援のために便利ですが必
須ではない。データが損失したら、容易にデータを表に再ロードできる。
静的永続表
静的表は、ログなしの読取り専用永続表で、挿入、更新、削除のいずれの操作もサ
ポートしていません。挿入、更新、削除のいずれの操作も表で実行しない場合は、
静的表として表を作成できます。静的表では、非クラスタ インデックスや参照制約
を作成したりドロップしたりできます。なぜなら、そのような操作は、データに影
響を与えないためです。
静的表では、ロールバック機能、回復機能、アーカイブからの復元機能のいずれも
サポートしていません。静的表の利点は、読取り専用であるために、問合せの実行
時にサーバが簡単な走査を使用できることと、サーバがロックするのを防ぐことが
できることです。
ヒント : GK インデックスを使用する表を作成する場合、静的表は重要です。静的
表は、GK インデックスをサポートする唯一の表の種類であるためです。
7-16
Informix Guide to Database Design and Implementation
表の種類の選択
オペレーショナル永続表
オペレーショナル表は、ログ付き永続表で、簡単な追加を使用しますがレコード単
位のログは記録しません。オペレーショナル表では、高速更新の操作を実行できま
す。
オペレーショナル表では、操作をロールバックしたり、障害から回復したりできま
すが、ロードされる大量の挿入レコードはログに記録されないので、ログのアーカ
イブから確実に復元することはできません。オペレーショナル表を使用するのは、
ほかのソースからデータを導出するために、復元機能は重要でない場合で、ロール
バック機能も回復機能も必要ない場合です。
周期的にデータがリフレッシュされるので、ファクト表をオペレーショナル表とし
て作成できます。オペレーショナル表では、インデックスも制約もない場合に高速
ロード モードをサポートし、データは回復可能です。
標準永続表
標準表は、Dynamic Server を使用して作成するログ付きデータベース内の表と同じ
です。すべての操作はレコード単位でログに記録されるので、標準表はアーカイブ
から復元できます。標準表は、回復機能とロールバック機能をサポートしていま
す。
表の更新とリフレッシュの周期が頻繁でない場合、標準表で表を作成できます。リ
フレッシュ周期の間に制約とインデックスをドロップする必要がないためです。イ
ンデックスは、作成に時間と手間がかかりますが必要です。
ヒント : 標準表では簡単な追加を使用しないので、外部表を使用してロードを実行
する場合に高速ロード モードを使用できません。
多次元データモデルの実装
7-17
表の種類の切替え
表の種類の切替え
ALTER TABLE コマンドを使用して、永続表の種類を切り替えます。変更する表が、
新しい表の種類の制限事項を満たしていない場合、変更は失敗し、説明のエラー
メッセージが表示されます。表の変更には、次の制限事項が適用されます。
AD/XP
■
表の種類を RAW に変更する前に、インデックスと参照制約を削除する必
要があります。
■
変更した表が完全回復機能の制限事項を満たすように、表の種類を
STANDARD に変更する前にレベル 0 のアーカイブを実行する必要があり
ます。
■
Temp 表やスクラッチ一時表を変更することはできません。
データ ウェアハウス環境のインデックス
従来の B ツリー インデックスに加えて、Dynamic Server with AD and XP Options は次
のようなインデックスを提供します。これらのインデックスを使用すると、データ
ウェアハウス環境でのアド ホック問合せのパフォーマンスを向上できます。
■
ビットマップ インデックス
ビットマップ インデックスは、従来の B ツリー インデックスよりも少な
いディスク容量を使用します。ビットマップ インデックスを使用すると、
同じキーを含む行間の距離が減少するので格納効率が向上します。
次の両方の条件に当てはまる場合にビットマップ インデックスを使用でき
ます。
■
❑
インデックス内のキー値に、多くの重複があります。
❑
表走査のパフォーマンスを向上するためにオプティマイザが使用でき
るインデックスが、表内の複数の列に付いています。
一般化キー (GK) インデックス
GK インデックスを使用すると、式の結果、データ セットの選択、または
結合された表からのデータ セットの積を、B ツリー インデックスまたは
ビットマップ インデックス内のキーとして格納できます。これは、1 つま
たは複数の大規模表での特定の問合せに便利です。
GK インデックスを作成する場合は、含まれるすべての表は静的表である
必要があります。
7-18
Informix Guide to Database Design and Implementation
データ ウェアハウス環境のインデックス
インデックス機能の効率を向上するために、Dynamic Server with AD and XP Options
は次の機能をサポートしています。
■
同一の表アクセスに使用できるように複数のインデックスを自動的に結合
します。
複数列インデックスを単一列インデックスと結合できます。
■
スキップ走査というアクセス方法で表を読み取ります。
表の行を走査する場合、データベース サーバはインデックスが示す行だけ
を読み取ります。その場合、行がデータベース内にある順序で行を読み取
ります。スキップ走査アクセス方法では、1 つのページを 2 度読み取るこ
とはありません。各ページは、ランダムにではなく順次に読み取られるの
で、入出力資源の要件は減少します。スキップ走査では、インデックス列
でのフィルタ処理が不要になるので、CPU 要件も減少します。
■
ハッシュ半結合を使用して、複数表結合を処理する作業を減らします。
ハッシュ半結合は、1 つの大きな ( ファクト ) 表が多くの小さな ( 次元 ) 表
に結合されるスター スキーマに対する問合せなどで特に便利です。ハッ
シュ結合では、結合が開始する前に、効率的に行の数をできるかぎり減ら
すことができます。
データベースに対して実行する問合せの種類を解析することは、作成するインデッ
クスの種類を決めるためにも役立ちます。問合せのパフォーマンスを向上するため
に使用できるインデックスおよびインデックス作成方法については、
『Performance
Guide』を参照してください。
多次元データモデルの実装
7-19
データ ウェアハウス環境での GK インデックスの使用
データ ウェアハウス環境での GK インデックスの使用
特定の種類の問合せを表で頻繁に使用する場合は、GK インデックスを作成すると
便利です。以下の例では、1 つまたは複数の大きな表での問合せ用に GK インデッ
クスを作成して使用する方法について説明しています。この例では、データベース
sales_demo の表に基づいて説明しています。
選択での GK インデックスの定義
ファクト表 sales での典型的な問合せが、州が "CA" となる値を返すと想定します。
このような種類の問合せのパフォーマンスを向上するために、GK インデックスを
作成すると 1 つの SELECT 文の結果をインデックス内の 1 つのキーとして格納でき
ます。次の文はインデックス state_idx を作成します。インデックス state_idx は、地
域データによる検索を制限する問合せのパフォーマンスを向上できます。
CREATE GK INDEX state_idx on geography
(SELECT district_code FROM geography
WHERE state_code = "CA")
データベース サーバは、州が "CA" の場合に製品別、地方別、月別の売上高と売上
数量を返す、次のような種類の問合せにインデックス state_idx を使用できます。
データベース サーバは、州が "CA" の場合に表 geography から行を抽出するためにイ
ンデックス state_idx を使用して、問合せ全体のパフォーマンスを向上します。
SELECT product_name, region, month_name, SUM(revenue),
SUM(units_sold)
FROM product, geography, time, sales
WHERE product.product_code = sales.product_code AND
geography.district_code = sales.district_code AND
state_code = "CA" AND time.time_code = sales.time_code
GROUP BY product_name, region, month_name
ORDER BY product_name, region;
7-20
Informix Guide to Database Design and Implementation
データ ウェアハウス環境での GK インデックスの使用
式での GK インデックスの定義
ある式の結果をインデックス内の 1 つのキーとして格納するために GK インデック
スを作成できます。次の文はインデックス cost_idx を作成します。インデックス
cost_idx を使用すると、販売した製品のコストを含む表 sales に対する問合せのパ
フォーマンスを向上できます。
CREATE GK INDEX cost_idx on sales
(SELECT units_sold * cost FROM sales);
データベース サーバは、製品の購入に $10,000.00 を超える金額を使った顧客名を返
す、次のような種類の問合せにインデックス cost_idx を使用できます。
SELECT customer_name
FROM sales, customer
WHERE sales.customer_code = customer.customer_code
AND units_sold * cost > 10000.00;
結合された表での GK インデックスの定義
結合された表からのデータ セットの積の結果をインデックス内のキーとして格納す
るために GK インデックスを作成できます。表 sales の各エントリ用に、次元表 time
からの年のデータに 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
多次元データモデルの実装
7-21
セクション lll
データベースの管理
第8章
データベースサーバのアクセ
ス権の付与と制限
データベースへのアクセスの制御 . . . . . . . . . . . . . .
機密データの保護 . . . . . . . . . . . . . . . . .
8-4
8-4
アクセス権の付与 . . . . . . . . . . . . . . . . .
データベースレベルアクセス権 . . . . . . . . . . . .
接続アクセス権. . . . . . . . . . . . . . . .
リソースアクセス権 . . . . . . . . . . . . . .
データベース管理者としてのアクセス権 . . . . . . . .
所有者の権限 . . . . . . . . . . . . . . . . .
表レベルアクセス権 . . . . . . . . . . . . . . .
アクセス権 . . . . . . . . . . . . . . . . .
インデックスアクセス権、変更アクセス権、および参照アクセス権
列レベルアクセス権 . . . . . . . . . . . . . . .
プロシジャレベルアクセス権 . . . . . . . . . . . . .
アクセス権の自動化 . . . . . . . . . . . . . . .
コマンドスクリプトによる自動化 . . . . . . . . . .
Dynamic Server を使用した役割の使用 . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8-5
8-5
8-5
8-6
8-7
8-7
8-8
8-8
8-10
8-10
8-12
8-13
8-14
8-14
ストアドプロシジャによるデータへのアクセスの制御 .
データの読込みの制限 . . . . . . . . .
データへの変更の制限 . . . . . . . . .
データへの変更の監視 . . . . . . . . .
オブジェクト作成の制限 . . . . . . . .
.
.
.
.
.
8-17
8-18
8-19
8-20
8-21
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
8-22
8-23
8-24
8-25
8-25
ビューの使用 . . . . .
ビューの作成 . . .
ビューの重複行. .
ビューに対する制限
ベースの変更の反映
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ビューを用いたデータの変更 . . . . .
ビューを用いたデータの削除 . . . .
ビューの更新. . . . . . . . .
ビューへの挿入 . . . . . . . .
WITH CHECK OPTION キーワードの使用
アクセス権とビュー . . . . . . .
ビューの作成時のアクセス権 . . .
ビューを使用するときのアクセス権 .
8-2
.
.
.
.
.
. . .
. . .
. . .
Informix Guide to Database Design and Implementation
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . .
. . .
. . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . .
. . .
. . .
.
.
.
.
.
.
.
.
.
.
8-26
8-27
8-27
8-28
8-29
. .
. .
. .
8-30
8-30
8-31
この章ではデータベースのアクセスの制御について説明します。どのユーザでもす
べてのデータにアクセスできるデータベースもありますが、一方では一部のユーザ
がデータの一部または全体へのアクセスを拒否できるデータベースもあります。こ
の章ではデータへのアクセスが次のようなレベルで制限することができる点につい
て説明します。
■
GRANT 文と REVOKE 文を使用して、データベースや特定の表に対するア
クセス権を付与したり拒否したりすることができます。また、データベー
スの利用の仕方を制御することもできます。
■
CREATE PROCEDURE 文を使用して、ストアドプロシジャを記述およびコ
ンパイルすることができます。ストアドプロシジャは、データベース表を
読み込んだり、変更したり作成したりできるユーザの制御と監視を行いま
す。
■
CREATE VIEW 文を使用して、データの制限済みビューや変更済みビュー
を準備することができます。制限は特定の列を除く縦方向または特定の行
を除く横方向に適用することができます ( 両方向でも行えます )。
■
GRANT 文と CREATE VIEW 文を結合して、ユーザが変更できる表の部分や
データの内容を的確に制御することができます。
データベースサーバのアクセス権の付与と制限
8-3
データベースへのアクセスの制御
データベースへのアクセスの制御
通常のデータベースアクセス権の仕組みでは GRANT 文と REVOKE 文がベースに
なります。詳細は、8-5 ページの「アクセス権の付与」で説明します。ただし、状況
によってはオペレーティングシステムの機能を、データベースへのアクセスを制御
するもう一つの方法として使用できることもあります。
機密データの保護
オペレーティングシステムがアクセスを制御するかどうかに関係なく、データベー
ス全体の内容の機密レベルが高い場合は、コンピュータに固定されているパブリッ
クディスク上には書き込みたくないでしょう。データの機密を保護しなければなら
ないときは、通常のソフトウェア制御を使わないようにすることができます。
ユーザ自身または別の正当なユーザがデータベースを使用していないときは、その
データベースをオンラインで使用可能にしておく必要はありません。次のいずれか
の方法を使用して、アクセス不能にすることができますが、手間のかかり具合は、
方法ごとに異なります。
■
物理媒体をコンピュータから切り離して、別の場所に保管する。ディスク
自体がリムーバブルでない場合は、ディスクドライブがリムーバブルで
す。
■
データベースディレクトリをテープにコピーして、テープを保管する。
■
暗号化ユーティリティを使用して、データベースファイルをコピーする。
暗号化バージョンのみを保持します。
重要 : 2 番目と 3 番目の方法では、コピーした後に、消去ファイルを NULL データで
上書きするプログラムを使用して、必ず元のデータベースファイルを消去しなけれ
ばなりません。
データベースディレクトリ全体を削除する代わりに、個々の表のファイルをコピー
してから消去することもできます。インデックスファイルにはインデックス付き列
からのデータのコピーが含まれていることを忘れてはなりません。表ファイルだけ
ではなく、インデックスファイルも削除して消去します。
8-4
Informix Guide to Database Design and Implementation
アクセス権の付与
アクセス権の付与
データベースを使用する許可のことをアクセス権と呼びます。たとえば、データ
ベースを使用する許可を接続アクセス権と呼び、表に行を挿入する許可を挿入のア
クセス権と呼びます。GRANT 文を使用すると、データベース、表、ビュー、また
はプロシジャへのアクセス権を付与したり、ユーザに役割を付与したりできます。
REVOKE 文を使用すると、データベース、表、ビュー、またはプロシジャへのアク
セス権を取り消したり、ユーザから役割を取り消したりできます。役割とは、
payroll など、DBA が割り当てる作業タスクの分類です。役割を割り当てるとアク
セス権の管理に便利に使用できます。
AD/XP
Informix Dynamic Server with Advanced Decision Support and Extended Parallel Options は
役割をサポートしていません。 ♦
二つのグループのアクセス権によって、ユーザがデータに対して実行できるアク
ションを制御します。二つのグループとは、データベース全体に影響を与えるデー
タベースレベルアクセス権と、個々の表と関係のある表レベルアクセス権です。こ
れらのアクセス権のグループの他に、プロシジャレベルアクセス権によって誰がプ
ロシジャを実行できるかが決まります。
GRANT 文と REVOKE 文の構文については『Informix Guide to SQL: Syntax』を参照
してください。
データベースレベルアクセス権
3 つのレベルのデータベースアクセス権で、誰がデータベースにアクセスできるか
を総体的に制御します。
接続アクセス権
最低限のアクセス権レベルとして、表の問合せや変更を行う基本的能力をユーザに
与える接続アクセス権があります。接続アクセス権を持っているユーザは次の機能
を実行することができます。
■
必要な表レベルアクセス権を持っているという条件で SELECT 文、INSERT
文、UPDATE 文および DELETE 文を実行する。
■
必要な表レベルアクセス権を持っているという条件で、ストアドプロシ
ジャを実行する。
データベースサーバのアクセス権の付与と制限
8-5
データベースレベルアクセス権
■
ビューがベースにしている表に対して問合せを行う許可が与えられている
という条件でビューを作成する。
■
一時表を作成して、その一時表に対するインデックスを作成する。
この接続アクセス権を持っていないユーザは、データベースにアクセスできませ
ん。通常、機密度の高いデータや個人データの含まれていないデータベースでは、
データベースの作成直後に GRANT CONNECT TO PUBLIC というアクセス権を与え
ます。
接続アクセス権を public に付与しないと、接続アクセス権を明示的に付与された
ユーザのみが、データベースサーバによってデータベースにアクセスできます。限
られたユーザのみがアクセス権を持つ必要がある場合は、それらのユーザに接続ア
クセス権を付与し、他のユーザには付与しません。
ユーザとパブリック
アクセス権は名前を指定して単一のユーザに付与するか、public という名前ですべ
てのユーザに付与します。public に付与されるアクセス権は、デフォルトアクセス
権として機能します。
文を実行する前に、必要なアクセス権がユーザに与えられているかどうかがデータ
ベースサーバによって判定されます。この情報はシステムカタログに入っていま
す。8-9 ページの「システムカタログ内のアクセス権」を参照してください。
データベースサーバは、まず最初に、アクセスを要求しているユーザに付与されて
いるアクセス権を探索します。要求しているアクセス権が見つかった場合は、その
情報を使用します。次に、制限の緩いアクセス権が public に付与されているかどう
かがチェックされます。付与されている場合は、制限の緩いアクセス権がデータ
ベースサーバによって使用されます。そのユーザにアクセス権がまったく付与され
ていなければ、データベースサーバは public に付与されているアクセス権を探しま
す。妥当なアクセス権が見つかれば、それが使用されます。
したがって、すべてのユーザに最小限のレベルのアクセス権を設定するには、アク
セス権を public に付与してください。特定の事情でそのアクセス権を無効にするに
は、より高いレベルの個別アクセス権をユーザに付与します。
リソースアクセス権
リソースアクセス権は、接続アクセス権と同じ権限を持っています。また、リソー
スアクセス権を持っているユーザは、新しい永久表、インデックス、ストアドプロ
シジャなどを作成することもできます。したがって、永続割当てディスク領域を作
成できます。
8-6
Informix Guide to Database Design and Implementation
所有者の権限
データベース管理者としてのアクセス権
最高位のレベルのデータベースアクセス権はデータベース管理者つまり DBA が保
有します。つまり、データベースの作成者は、必然的に DBA になります。DBA と
してのアクセス権の所有者は、次の機能を実行することができます。
■
DROP DATABASE 文、START DATABASE 文、および ROLLFORWARD
DATABASE 文を実行する。
■
所有者が誰であるかにかかわらず、オブジェクトを削除したり変更したり
する。
■
他のユーザが所有する表、ビュー、およびインデックスを作成する。
■
データベースアクセス権 (DBA としてのアクセス権も含む ) を別のユーザに
付与する。
■
システムカタログ表の NEXT SIZE（この属性に限る ) を変更して、systables
以外のすべてのシステムカタログ表の行の挿入、削除、更新を行う。
警告 : DBA としてのアクセス権を持っているユーザは、ほとんどのシステムカタロ
グ表を変更することができますが、Informix では、それらのシステムカタログ表で行
の更新、削除、または挿入を行わないように強く忠告しています。システムカタロ
グ表を変更すると、データベースの整合性が失われてしまう可能性があります。た
だし、ALTER TABLE 文を使用して、システムカタログ表の追加エクステントのサ
イズを変更することはできません。
所有者の権限
データベースと、その中のすべての表、ビュー、インデックス、プロシジャおよび
シノニムには所有者が設定されています。DBA としてのアクセス権を持っている
ユーザは、他のユーザが所有するオブジェクトも作成することができますが、通常
は、オブジェクトを作成したユーザが、そのオブジェクトの所有者になります。
オブジェクトの所有者は、そのオブジェクトに対するすべての権限を持っていて、
他のアクセス権を持っていなくても、そのオブジェクトの変更や削除を実行するこ
とができます。
AD/XP
GK インデックスの場合、所有権は、ほかのオブジェクトの場合とは多少異なる方
法で処理されます。どんな表でも、GK インデックスの FROM 節に現れる場合は、
たとえその表の作成者でない人が GK インデックスを作成したとしても、その GK
インデックスを削除するまで、削除することはできません。 ♦
データベースサーバのアクセス権の付与と制限
8-7
表レベルアクセス権
表レベルアクセス権
表ごとに 7 種類のアクセス権を適用して、所有者のアクセス権を所有者でないユー
ザに許可することができます。そのうちの 4 つ、つまり、選択アクセス権、挿入ア
クセス権、削除アクセス権、更新アクセス権は、表の内容に対するアクセスを制御
します。インデックスアクセス権はインデックスの作成を制御します。変更アクセ
ス権は、表定義を変更する許可を制御します。参照アクセス権は、表に対して参照
制約を指定するための許可を制御します。
ANSI 標準準拠データベースでは、表の所有者のみにアクセス権が与えられます。
それ以外のデータベースでは、表作成の一環として、変更アクセス権と参照アクセ
ス権以外のすべての表アクセス権が、データベースサーバによって自動的に public
に付与されます。すべての表アクセス権を public に自動的に付与した場合は、接続
アクセス権を持っていれば、どのユーザでも新しく作成された表にアクセスできま
す。そうしたくない場合 ( この表にアクセスできてはならないユーザが接続アクセ
ス権を持っている場合 ) は、表の作成後に、public からの表に対するアクセス権を
すべて取り消さなければなりません。
アクセス権
4 つのアクセス権によって、ユーザによる表へのアクセスの仕方を制御します。表
の所有者として、次のアクセス権を個々に付与したり、取り消したりすることがで
きます。
■
選択アクセス権では、一時表への取り出しなどの選択操作を実行すること
ができます。
■
挿入アクセス権では、新しい行を追加することができます。
■
更新アクセス権では、既存の行を変更することができます。
■
削除アクセス権では、行を削除することができます。
選択アクセス権は、ユーザが表の内容を抽出するのに必要です。ただし、選択アク
セス権は、他のアクセス権の前提条件ではありません。ユーザは、選択アクセス権
を持っていなくても、挿入アクセス権や更新アクセス権を持つことができます。
たとえば、アプリケーションに使用状況表が設定されている場合があります。その
場合は、ある特定のプログラムが開始されるたびに行が使用状況表に挿入され、そ
の行が使用されたことが記録されます。プログラムは、終了前にその行を更新して
実行時間を表示したり、そのユーザが実行した作業のカウントを記録します。
プログラムのすべてのユーザがこの使用状況表で行を挿入、または更新できるよう
にする場合は、その表に対する挿入アクセス権と更新アクセス権を public に付与し
ます。しかし、選択アクセス権は限られたユーザにのみ付与するものとします。
8-8
Informix Guide to Database Design and Implementation
表レベルアクセス権
システムカタログ内のアクセス権
アクセス権は、システムカタログ表に記録されています。接続アクセス権を持つす
べてのユーザは、システムカタログ表について問合せを行い、どんなアクセス権が
誰に付与されているかを判別することができます。
データベースアクセス権は表 sysusers に記録されていて、この表では主キーはユー
ザ ID になっています。また、それ以外の列のみにアクセス権レベルを表す単一文
字、C、R または D が含まれています。キーワード PUBLIC にアクセス権が付与さ
れていることは、ユーザ名 public( 小文字 ) で分かります。
表レベルアクセス権は、表番号、権限授与者、および被権限授与者からなる複合主
キーを使用する systabauth に記録されています。列 tabauth では、図 8-1 のダイヤグ
ラムが示しているリスト内で、アクセス権が符号化されます。
無条件更新
無条件選択
挿入
インデックス
su-idxar
図 8-1
符号化されたアクセ
ス権のリスト
参照
変更
* 列アクセス権が付与されている場合
削除
ハイフン (--) は、付与されていないアクセス権を表すので、すべてのアクセス権が
付与されている場合は su-idxar と表します。-u------ は、更新アクセス権のみが付与
されていることを表します。通常、コード文字には小文字が使用されますが、
GRANT 文でキーワード WITH GRANT OPTION を使用するときは大文字になりま
す。
3 つ目の位置にアスタリスク (*) が記されている場合は、その表と被権限授与者に
何らかの列レベルアクセス権が存在しています。特定のアクセス権は syscolauth に
記録されます。その主キーは、表番号、権限授与者、被権限授与者、および列番号
から成る複合主キーです。唯一の属性は、アクセス権のタイプを示す s、u または r
という 3 文字のリストです。
データベースサーバのアクセス権の付与と制限
8-9
列レベルアクセス権
インデックスアクセス権、変更アクセス権、および参照アクセス権
インデックスアクセス権の保持者は、表に対してインデックスを作成したり変更し
たりすることができます。インデックスアクセス権は、選択アクセス権、挿入アク
セス権、更新アクセス権および削除アクセス権と同じように、表の作成時に自動的
に public に付与されます。
インデックスアクセス権は、どのユーザに対しても付与することができますが、
ユーザが実際にアクセスするには、リソースデータベースアクセス権も必要です。
したがって、インデックスアクセス権は自動的に付与されますが (ANSI 標準準拠
データベースの場合を除く )、データベースに対して接続アクセス権しか持ってい
ないユーザは、インデックスアクセス権を実際に使用することはできません。イン
デックスは大きなディスク領域を占める可能性があるので、こうした制限は妥当だ
と言えます。
変更アクセス権の保有者は、表に対して ALTER TABLE 文を使用し ( 列を追加した
り削除したりする権限も含む )、シリアル (SERIAL) 型列の開始点をリセットしたり
することができます。変更アクセス権は、データモデルを十分に理解していて、そ
の権限を慎重に使用するユーザにのみ付与します。
参照アクセス権を使用すると、表に対する参照制約を強制することができます。変
更アクセス権と同じように、参照アクセス権はデータモデルを十分に理解している
ユーザにだけ付与してください。
列レベルアクセス権
特定の列の名前を使用して、選択アクセス権、更新アクセス権、および参照アクセ
ス権を修飾することができます。特定の列名を指定することで、表に対する非常に
具体的なアクセス権を付与することができます。特定の列のみの確認、特定の列の
みの更新、あるいは、特定の列に対する参照制約の強制をユーザが行えるようにす
ることができます。
8-10
Informix Guide to Database Design and Implementation
列レベルアクセス権
GRANT 文と REVOKE 文を使用すると、表データの作成および表データへのアクセ
スが制限できます。この機能によって、従業員の給与、勤務評価などの機密性の高
い属性を特定のユーザのみが確認できるようにするにはどうすべきかという問題が
解決します。具体的に説明できるように、従業員データの表が次の例に示すように
定義されていると仮定します。
CREATE TABLE hr_data
(
emp_key INTEGER,
emp_name CHAR(40),
hire_date DATE,
dept_num SMALLINT,
user-id CHAR(18),
salary DECIMAL(8,2)
performance_level CHAR(1),
performance_notes TEXT
)
この表には機密データが含まれているので、作成直後に次の文を実行します。
REVOKE ALL ON hr_data FROM PUBLIC
人事 (Human Resources) 部内の限られたユーザとすべてのマネージャに対して、次
の文を実行します。
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
データベースサーバのアクセス権の付与と制限
8-11
プロシジャレベルアクセス権
この文では、機密性のない列を保守できる権限が、ある一定のユーザに与えられま
すが、勤務評定や給与を変更する権限をそれらのユーザに付与することは拒否され
ます。コンピュータのユーザ 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’
プロシジャレベルアクセス権
プロシジャに実行アクセス権を適用して、非所有者にプロシジャの実行許可を与え
ることができます。ANSI 標準に準拠しないデータベースでプロシジャを作成する
と、デフォルトのプロシジャレベルアクセス権は PUBLIC になります。つまり、実
行アクセス権を ( 最初に取り消さない限り ) 特定のユーザに付与する必要はありま
せん。ANSI 標準準拠データベースでプロシジャを作成すると、デフォルト時に実
行アクセス権が他のユーザに与えられることはありません。したがって、特定の
ユーザに実行アクセス権を付与しなければなりません。次の例は、ユーザ orion に
実行アクセス権を付与して、read-address という名前のストアドプロシジャを orion
が使用できるようにします。
GRANT EXECUTE ON read_address TO orion;
プロシジャレベルアクセス権は、システムカタログ表 sysprocauth に記録されます。
表 sysprocauth は、プロシジャ番号、権限授与者、および被権限授与者から成る主
キーを使用します。列 procauth では、実行アクセス権は小文字 e によって示されま
す。また、WITH GRANT オプションで実行アクセス権が付与されている場合は、
このアクセス権は大文字 E で表されます。
8-12
Informix Guide to Database Design and Implementation
アクセス権の自動化
プロシジャレベルアクセス権についての詳細は、
『Informix Guide to SQL: Tutorial』
を参照してください。
アクセス権の自動化
この設計方法では、データベースを最初にセットアップするときに、かなりの数の
GRANT 文を実行しなければならない場合があります。また、ユーザの仕事が変わ
るにしたがって、アクセス権を常に保守する必要があります。たとえば、人事部の
一般社員が解雇された場合は、できる限り早く更新アクセス権を取り消す必要があ
ります。そのような措置をとらない場合は、この解雇された社員によって次のよう
な文が実行されてしまう可能性があります。
UPDATE hr_data
SET (emp_name, hire_date, dept_num) = (NULL, NULL, 0)
機密データが含まれているモデルでは、必要に応じて毎日または毎時間ごとにアク
セス権を少しずつ変更しなければならない場合があります。アクセス権の変更が必
要になる場合は、アクセス権を保守しやすいように自動化ツールを用意することが
できます。
最初の手順としては、表の構造ではなく、ユーザの仕事内容に基づいてアクセス権
クラスを指定しなければなりません。たとえば、マネージャには次のアクセス権が
必要です。
■
仮定的な表 hr_data に対する選択アクセス権と限定的な更新アクセス権
■
このデータベースと他のデータベースに対する接続アクセス権
■
それらのデータベース内の複数の表に対するある程度のアクセス権
マネージャが幹部に昇進したり、フィールドオフィスに出向した場合は、それまで
のアクセス権をすべて取り消して、新しい一組のアクセス権を付与しなければなり
ません。
サポートするアクセス権クラスを定義して、アクセス権を与えなければならない
データベース、表および列を、それぞれのクラスごとに指定してください。次に、
各クラスごとの二つの自動化手順、つまりユーザにクラスを付与するための手順と
それを取り消すための手順を考えます。
データベースサーバのアクセス権の付与と制限
8-13
アクセス権の自動化
コマンドスクリプトによる自動化
使用するオペレーティングシステムは、コマンドスクリプトの自動実行をサポート
しているはずです。ほとんどの操作環境では、DB-Access やリレーショナルオブ
ジェクトマネージャなどの対話型 SQL ツールでコマンドと SQL 文を受け付けて、
コマンドラインから実行できるようになっています。この二つの機能を組み合わせ
て、アクセス権の保守を自動化することができます。
詳細については、使用するオペレーティングシステム、および、DB-Access または
リレーショナルオブジェクトマネージャのバージョンによって異なります。つま
り、次の機能を実行するコマンドスクリプトを作成する必要があります。
■
アクセス権が変更されるユーザ ID をパラメータとして解釈する。
■
そのユーザ ID を含むようにカスタマイズされた GRANT 文または REVOKE
文のファイルを作成する。
■
データベースを選択して、作成された GRANT 文または REVOKE 文のファ
イルを実行するように指示するパラメータを指定し、DB-Access または、
リレーショナルオブジェクトマネージャを起動する。
このようにすれば、ユーザのアクセス権クラスの変更操作を減らして、一つまたは
二つのコマンドにすることができます。
IDS
Dynamic Server を使用した役割の使用
ユーザのアクセス権を場合に応じて簡単に変更するもう一つの方法は、役割を使用
することです。データベース環境での役割の概念は、オペレーティングシステムで
のグループの概念に似ています。役割とは、一つのデータベース機能であり、DBA
はこの機能を使用し、クラスのメンバとして扱うことによって、多くのユーザのア
クセス権を標準化したり変更したりすることができます。
たとえば、社内のニュースやメッセージを扱うデータベースに対して接続アクセス
権、挿入アクセス権、および削除アクセス権を付与する news_mes という役割を作
成することができます。新たに従業員が入社しても、その従業員を役割 news_mes
に追加するだけで済みます。この新しい従業員は、役割 news_mes のアクセス権を
獲得します。このプロセスは、その逆の働きもします。つまり、news_mes のすべ
てのメンバのアクセス権を変更するには、その役割のアクセス権を変更します。
8-14
Informix Guide to Database Design and Implementation
アクセス権の自動化
役割の使用
役割作成プロセスを開始するには、付与したい接続とアクセス権とともに、役割の
名前を決定します。接続とアクセス権は、まったくの自由裁量によって判断するわ
けですが、役割を命名するときに考慮しなければならないいくつかの要素がありま
す。次の語は、役割の名前に使用してはなりません。
alter
connect
DBA
default
delete
execute
index
insert
none
null
public
references
resource
select
update
役割名は、データベース内の既存の役割名と異なっていなければなりません。また
サーバマシンにとって既知となっているネットワークユーザも含め、オペレーティ
ングシステムにとって既知のユーザ名とも異なっていなければなりません。自分の
役割名が一意であることを確認するには、次のシステムカタログ表だけではなく、
データベースを現在使用している共有メモリ構造体のユーザの名前をチェックしま
す。
■
sysusers
■
systabauth
■
syscolauth
■
sysprocauth
■
sysfragauth
■
sysroleauth
状況が逆で、ユーザをデータベースに追加しているときには、そのユーザ名が既存
の役割名と同じになっていないかをチェックしてください。
役割名を承認した後は、CREATE ROLE 文を使用して、新しい役割を作成します。
役割を作成すると、デフォルトでは、役割管理用のすべてのアクセス権が DBA に
与えられます。
重要 : 役割の有効範囲は現行データベースだけです。そのため、SET ROLE 文を実
行すると、その役割は現行データベースだけに設定されます。
データベースサーバのアクセス権の付与と制限
8-15
アクセス権の自動化
ユーザのアクセス権の操作と他の役割への役割の付与
DBA は GRANT 文を使用して、役割アクセス権をユーザに付与することができま
す。また、アクセス権を他のユーザに付与するオプションをユーザに提供すること
もできます。それには、GRANT 文の WITH GRANT OPTION 節を使用します。
WITH GRANT OPTION 節を使用できるのは、アクセス権をユーザに付与するときに
限られます。
たとえば、次の問合せは、オプション grantable を指定して役割へのアクセス権を付
与しているので、エラーが返されます。
GRANT SELECT on tab1 to rol1
WITH GRANT OPTION
重要 : アクセス権を役割に付与するときに GRANT 文の WITH GRANT OPTION 節を
使用してはなりません。ユーザのみが、アクセス権を他のユーザに付与することが
できます。
役割アクセス権を付与するときは、GRANT 文でユーザ名の代わりに役割名を使用
することができます。役割を別の役割に付与することもできます。たとえば、役割
A が役割 B に付与されているとします。その場合は、ユーザが役割 B を有効化する
と、役割 A と役割 B の両方からアクセス権がユーザに与えられます。
ただし、役割付与のサイクルを推移させることはできません。役割 A を役割 B に
付与して、役割 B を役割 C に付与し、さらに C を A に付与するとエラーが返され
ます。
アクセス権を変更する必要がある場合は、REVOKE 文を使用して、既存のアクセス
権を削除してから、GRANT 文を使用して、新しいアクセス権を追加します。
ユーザによる役割の有効化の必要性
DBA がアクセス権を付与してユーザを役割に追加した後、データベースセッショ
ンで SET ROLE 文を使用して、役割を有効化しなければなりません。役割を有効化
しない限りは、public に関連付けられたアクセス権、または、オブジェクトの所有
者であるという理由で直接付与されたアクセス権に限定されます。
8-16
Informix Guide to Database Design and Implementation
ストアドプロシジャによるデータへのアクセスの制御
役割でのメンバシップの確認と役割の削除
どのユーザが役割に含まれているのかわからない状態になる場合があります。この
場合は、役割を作成していないか、役割を作成したユーザが有効でないことが考え
られます。表 sysroleauth と表 sysusers に対して問合せを行って、どの表に対してど
のユーザがアクセスを許可されているか、さらに役割がいくつ存在しているかを確
認してください。
どのユーザがどの役割のメンバーなのかがわかると、すでに一部の役割が不要であ
ることに気付く場合があります。役割の削除には、DROP ROLE 文を使用します。
ただし、役割を削除するには、次の条件を満たしていなければなりません。
■
カタログ表sysusersに役割としてリストされている役割のみを破壊すること
ができます。
■
役割を削除するには、DBA としてのアクセス権を持っているか、あるいは
役割を削除するために付与できる役割のオプションを与えられていなけれ
ばなりません。
ストアドプロシジャによるデータへのアクセスの
制御
ストアドプロシジャを使用して、データベース内の個々の表または列へのアクセス
を制御することができます。プロシジャを用いて、さまざまなレベルのアクセス制
御を行うことができます ( ストアドプロシジャについては、『Informix Guide to SQL:
Tutorial』に詳しく説明されています )。SPL( ストアドプロシジャ言語 ) の便利な機
能は、ストアドプロシジャを DBA アクセス権付きストアドプロシジャとして指定
する機能です。DBA アクセス権付きストアドプロシジャを作成すると、ほとんど
あるいはまったく表アクセス権がないユーザが、プロシジャの実行時に DBA とし
てのアクセス権を獲得するのを許可できます。このプロシジャで、ユーザが一時的
な DBA アクセス権を使って実行できるのは、限られたタスクのみです。DBA アク
セス権付き機能を使用した場合は、次のタスクを実行することができます。
■
個々のユーザが表から読み込める情報の量を制限します。
■
データベースに対するあらゆる変更を制限して、表全体が空にされたり、
誤って変更されるようなことがないようにします。
データベースサーバのアクセス権の付与と制限
8-17
データの読込みの制限
■
削除や挿入などの、表に対する変更のクラス全体を監視します。
■
ストアドプロシジャ内で行われるあらゆるオブジェクトの作成(データ定義
) を制限して、表、インデックス、およびビューの作成方法を完全に制御
できるようにします。
データの読込みの制限
次の例では、ユーザには SQL 構文が見えませんが、ユーザが表 customer に対して
選択アクセス権を持っている必要があります。何をユーザが選択できるかを制限し
たい場合は、次の環境で機能するようなプロシジャを作成します。
■
自分自身が、データベースの DBA である。
■
ユーザが、データベースに対する接続アクセス権を持っている。そして、
表に対する選択アクセス権は持っていない。
■
キーワード DBA を使用して、ストアドプロシジャ ( またはストアドプロシ
ジャのセット ) が作成されている。
■
ストアドプロシジャ ( またはストアドプロシジャのセット ) が、ユーザに代
わって表から読み込む。
顧客の名前、住所および電話番号のみをユーザが読めるようにする場合は、次の例
に示すようにプロシジャを変更します。
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;
8-18
Informix Guide to Database Design and Implementation
データへの変更の制限
データへの変更の制限
ストアドプロシジャを使用して、表に加えられた変更を制限することができます。
ストアドプロシジャを使用して、すべての変更の経路を指定します。直接変更を加
えるユーザではなく、ストアドプロシジャが変更を行います。ユーザによる動作を
1 回に一つずつの行の削除に制限して、表内のすべての行が誤って削除されないよ
うにするには、次のようなアクセス権でデータベースをセットアップします。
■
自分自身が、データベースの DBA である。
■
すべてのユーザが、データベースに対する接続アクセス権を持っている。
リソースアクセス権を持っている場合がある。保護されている表に対して
は、削除アクセス権 ( この例の場合 ) を持っていない。
■
キーワード DBA を使用して、ストアドプロシジャを作成する。
■
ストアドプロシジャが削除を実行する。
次のようなストアドプロシジャを作成します。このストアドプロシジャは、ユーザ
が指定する customer_num 付きの WHERE 節を使用して、表 customer から行を削除
します。
CREATE DBA PROCEDURE delete_customer(cnum INT)
DELETE FROM customer
WHERE customer_num = cnum;
END PROCEDURE;
データベースサーバのアクセス権の付与と制限
8-19
データへの変更の監視
データへの変更の監視
ストアドプロシジャを使用して、データベースに加えられた変更の記録を作成する
ことができます。特定のユーザが行った変更を記録したり、変更が行われるたびに
記録を作成したりすることができます。
単一のユーザがデータベースに対して行うすべての変更を監視することができま
す。ただ、それぞれのユーザによる変更を追跡するストアドプロシジャを使用し
て、すべての変更の経路を指定するのみです。ユーザ acctclrk がデータベースに変
更を加えるたびに記録したい場合は、次のアクセス権でデータベースをセットアッ
プします。
■
自分自身が、データベースの DBA である。
■
他のすべてのユーザが、データベースに対する接続アクセス権を持ってい
る。リソースアクセス権を持っている場合もあります。保護されている表
に対しては、削除アクセス権 ( この例の場合 ) を持っていない。
■
キーワード DBA を使用して、ストアドプロシジャを作成する。
■
ストアドプロシジャが削除を実行し、特定のユーザによる変更を記録す
る。
次のようなストアドプロシジャを作成します。このプロシジャは、表の更新時に
ユーザが指定する顧客番号を使用します。ユーザが偶然 acctclrk である場合は、削
除のレコードはファイル updates に入れられます。
UNIX
CREATE DBA PROCEDURE delete_customer(cnum INT)
DEFINE username CHAR(8);
DELETE FROM customer
WHERE customer_num = cnum;
IF username = ’acctclrk’ THEN
SYSTEM ’echo Delete from customer by acctclrk >> /mis/records/updates’ ;
END IF
END PROCEDURE;
8-20
Informix Guide to Database Design and Implementation
オブジェクト作成の制限
プロシジャを用いて行われた削除をすべて監視するには、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;
♦
オブジェクト作成の制限
作成するオブジェクトとそれらの作成方法を制限するには、次のような設定の範囲
内でストアドプロシジャを使用します。
■
自分自身が、データベースの DBA である。
■
他のすべてのユーザが、データベースに対する接続アクセス権を持てい
る。リソースアクセス権は持っていない。
■
キーワード DBA を使用して、ストアドプロシジャ ( またはストアドプロシ
ジャのセット ) を作成する。
■
ストアドプロシジャ ( またはストアドプロシジャのセット ) が、表、イン
デックス、ビューを定義したとおりに作成する。そのようなプロシジャを
使用して、トレーニングデータベース環境をセットアップできる。
次の例が示しているように、プロシジャには、一つまたは複数の表や、関連付けら
れているインデックスの作成を含めることができます。
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;
データベースサーバのアクセス権の付与と制限
8-21
ビューの使用
プロシジャ all_objects を使用して表に対する列の追加を制御するには、データベー
スに対するリソースアクセス権をすべてのユーザから取り消します。プロシジャの
外で SQL 文を使用して、ユーザが表、インデックスまたはビューを作成しようと
しても、その操作は許可されません。また、ユーザがプロシジャを実行するとき
は、一時的な DBA アクセス権が与えられるので、たとえば CREATE TABLE 文な
どは成功します。また、追加するそれぞれの列には必ず制約が設定されます。さら
にユーザが作成したオブジェクトは、そのユーザによって所有されます。プロシ
ジャ all_objects の場合は、このプロシジャを実行するユーザは誰でも、二つの表と
インデックスを所有することになります。
ビューの使用
ビューとは、合成された表のようなものです。ビューは、表ではないものを表であ
るかのように問い合わせることができ、場合によっては、表であるかのように更新
することもできます。しかし、ビューは表ではありません。実際の表と他のビュー
に存在するデータの集合体です。
ビューのベースになるのは SELECT 文です。ビューを作成するときは、ビューのア
クセス時にビューの内容を生成する SELECT 文を定義します。ユーザは、SELECT
文を使用したビューの問合せも行います。データベースサーバは、ユーザの
SELECT 文を、ビューに対して定義した SELECT 文とマージして、その結合された
文を実際に実行します。
その結果、表のような外観になります。表に非常によく似ているため、ビューの
ベースとして他のビューを使用したり、表と他のビューの結合をベースにしたりす
ることができます。
ビューの内容を決定する SELECT 文の作成者は、ビューを次のいずれかの目的に使
用することができます。
■
ユーザを表の特定の列に制限する。
指定するのは、ビュー内の選択リスト内で許可されている列のみです。
■
ユーザを表の特定の行に制限する。
許可された行のみを返す WHERE 節を指定します。
■
挿入する値または更新する値の範囲に制約を加える。
キーワード WITH CHECK OPTION(8-29 ページの「WITH CHECK OPTION
キーワードの使用」を参照 ) を使用して、制約を強制することができます。
8-22
Informix Guide to Database Design and Implementation
ビューの作成
■
冗長データをデータベースに格納せずに、導出データにアクセスできるよ
うにする。
ビュー内の選択リストにデータを導出する式を書きます。ビューに対して
問合せを行うたびに、そのデータが新たに導出されます。導出されたデー
タは常に最新ですが、冗長性はデータモデルに導入されません。
■
複雑な SELECT 文の詳細を隠す。
ビュー内の複数表結合による複雑性を隠し、ユーザとアプリケーションプ
ログラマにとって繰返しが不要になるようにします。
ビューの作成
次の例は、デモンストレーションデータベースの表をベースにしてビューを作成し
ます。
CREATE VIEW name_only AS
SELECT customer_num, fname, lname FROM customer
このビューは表の 3 つの列のみを表出させます。しかし、WHERE 節が含まれてい
ないので、表示できる行は制限しません。
GLS
次の例は、ISO 8859-1 コードセットを使用する米語ロケール以外のロケールが有効
化されている場合に使用できる表をベースにして、ビューを作成します。この例で
は、ビュー名、列名および表名に英字以外の文字が含まれています。
CREATE VIEW çà_va AS
SELECT numéro, nom FROM abonnés;
♦
次の例は二つの表の結合をベースにしています。
CREATE VIEW full_addr AS
SELECT address1, address2, city, state.sname, zipcode
FROM customer, state
WHERE customer.state = state.code
データベースサーバのアクセス権の付与と制限
8-23
ビューの作成
州名の表によって、データベースの冗長性が軽減されます。つまり、完全な州名を
格納するのは 1 回だけでよいので、Minnesota などの長い州名の場合は便利です。
このビュー full_addr を使用して、すべての行に完全な州名が格納されているかのよ
うに、住所を抽出することができます。次の二つの問合せは同等です。
SELECT * FROM full_addr WHERE customer_num = 105
SELECT address1, address2, city, state.sname, zipcode
FROM customer, state
WHERE customer.state = state.code
AND customer_num = 105
ただし、結合に基づくビューを定義するときは注意しなければなりません。そのよ
うなビューは変更不能です。つまり、それらのビューに UPDATE 文、DELETE 文
または INSERT 文を使用することはできません。ビューを用いたデータの修正方法
については、8-26 ページを参照してください。
次の例は、ビューに表示できる行を制限します。
CREATE VIEW no_cal_cust AS
SELECT * FROM customer WHERE NOT state = ’CA’
このビューは、表 customer のすべての列を表出させますが、特定の行に限られま
す。次の例は、ユーザに関連のある行にユーザを限定するビューです。
CREATE VIEW my_calls AS
SELECT * FROM cust_calls WHERE user_id = USER
表 cust_calls のすべての列が表示されますが、問合せを実行できるユーザのユーザ
ID が記述されている行のみで使用できます。
ビューの重複行
基礎となる表に一意の行しか含まれていない場合も、ビューでは重複行が作成され
る可能性があります。ビューの SELECT 文が重複行を返すことができる場合は、
ビュー自体が重複行を含んでいるように見えることがあります。
この問題を防止する方法は二つあります。そのうちの一つはビューの選択リストに
キーワード DISTINCT を指定することです。ただし、キーワード DISTINCT を指定
すると、ビューを用いたデータの変更が行えなくなります。もう一つの方法として
は一意となるように制約される列または列のグループを必ず選択するようにします
( 主キーまたは候補キーの列を選択すると、必ず一意な行のみが返されるようにな
ります。これらのキーについての詳細は、第 2 章「リレーショナルデータモデルの
作成」を参照してください )。
8-24
Informix Guide to Database Design and Implementation
ビューの作成
ビューに対する制限
ビューは、実際には表ではないので、ビューにインデックスを付けたり、ビューを
ALTER TABLE 文や RENAME TABLE 文などのオブジェクトにしたりすることはで
きません。また、ビューの列の名前を RENAME COLUMN 文で変更することもでき
ません。ビューの定義に関する何かを変更するには、ビューをいったん削除してか
ら再度作成しなければなりません。
ユーザの問合せとマージしなければならないので、ビューのベースになる SELECT
文には次の節やキーワードを含めないようにしてください。
INTO TEMP 節 ユーザの問合せには INTO TEMP 節が含まれている可能性がありま
す。ビューにも INTO TEMP 節が含まれていると、データの格納先
が不明になります。
ORDER BY 節 ユーザの問合せには ORDER BY 節が含まれている可能性がありま
す。ビューにも ORDER BY 節が含まれていると、列の選択やソー
ト方向が矛盾する場合があります。
ビューの基となる SELECT 文には、キーワード UNION を指定することができま
す。そうした場合は、データベース サーバはそのビューを暗黙的一時表に格納しま
すが、この一時表でユニオンが必要に応じて評価されます。ユーザの問合せでは、
この一時表を基本表として使用します。 ♦
ベースの変更の反映
ビューのベースになっている表やビューを変更する方法はいくつかあります。
ビューには、ほとんどの変更が自動的に反映されます。
表やビューが削除されると、同じデータベース内でその表やビューに依存している
ビューも自動的に削除されます。
ビューの定義を変更する唯一の方法は、そのビューを削除して再度作成することで
す。したがって、他のビューが依存しているビューの定義を変更する場合は、他の
ビューも再度作成しなければなりません ( すべて削除されているからです )。
表の名前を変更すると、同じデータベース内でその表に依存しているビューも、そ
の新しい名前を使用できるように変更されます。また、列の名前を変更すると、同
じデータベース内でその表に依存しているビューも、その固有の列を選択できるよ
うに更新されます。ただし、ビュー自体の中の列名は変更されません。この例の場
合は、表 customer に対して次のビューを再呼出ししてください。
CREATE VIEW name_only AS
SELECT customer_num, fname, lname FROM customer
データベースサーバのアクセス権の付与と制限
8-25
ビューを用いたデータの変更
ここで、表 customer が次の方法で変更されると仮定します。
RENAME COLUMN customer.lname TO surname
顧客の名字を直接選択するには、ここで新しい列名を選択しなければなりません。
しかし、ビューを介して見た場合には、列の名前は変わりません。次の二つの問合
せは同等です。
SELECT fname, surname FROM customer
SELECT fname, lname FROM name_only
列を削除して表を変更しても、ビューは変更されません。ビューが使用されている
と、エラー -217(Column not found in any table in the query) が返されます。ビューが
変更されないのは、列を削除してから同じ名前の新しい列を追加することによっ
て、列の順序を変更できるからです。これを行うと、その表をベースにしている
ビューが、引き続き機能します。列の元の順序が維持されます。
データベースサーバでは、ビューのベースとして、外部データベース内の表と
ビューを使用することができます。他のデータベースの表とビューを変更しても、
ビューには反映されません。そのような変更は、誰かがビューに対する問合せを
行って、外部表が変更されているというエラーを受け取るまで分からない場合があ
ります。
ビューを用いたデータの変更
ビューは、表であるかのように変更することができます。使用する SELECT 文に
よって、変更できるビューと変更できないビューがあります。制限は、DELETE
文、UPDATE 文または INSERT 文を使用するかどうかによって異なります。
SELECT 文に次の機能や特性が含まれている場合は、ビューに対して変更を行うこ
とはできません。
■
複数の表の結合
データベースサーバが、変更したデータを結合された表に正しく分散させ
ようとすると、さまざまな問題が起こります。
■
集計関数または GROUP BY 節
ビューの行が、多数の結合されたデータ行を表すことになります。データ
ベースサーバは、変更されたデータをそれらの行に分散することができま
せん。
8-26
Informix Guide to Database Design and Implementation
ビューを用いたデータの変更
■
キーワード DISTINCT またはそのシノニム UNIQUE
ビューの行は、多くの重複行からの選択要素を表すことになります。デー
タベースサーバは、元の行のうちのどの行が、その変更を受け取らなけれ
ばならないかを認識することができません。
■
キーワード UNION
ビューの行には、その行を生成した表を識別するためのタグは付いていま
せん。したがって、データベース サーバでは、更新や削除の操作の場合
は、更新または削除する必要のある行が含まれる表を識別できません。挿
入の操作の場合は、行の挿入先の表を識別できません。
ビューにこれらの要素がまったくなければ、ビューの各行が一つの表の 1 行に確実
に対応します。そのようなビューは変更可能です ( もちろん、ビューを変更できる
のは、妥当なアクセス権を持っている特定のユーザのみです。ビューに対するアク
セス権についての詳細は、8-30 ページの「ビューの作成時のアクセス権」以降を参
照してください )。
ビューを用いたデータの削除
変更可能なビューでは、あたかも表であるかのように DELETE 文を使用することが
できます。データベースサーバは、ベースにしている表の固有の行を削除します。
ビューの更新
変更可能なビューは、あたかも表であるかのように UPDATE 文を使用することが
できます。ただし、変更可能なビューには、導出列がまだ含まれている場合があり
ます。つまり、CREATE VIEW 文の選択リスト内の式で作成された列のことです。
導出列 ( 仮想列と呼ばれる場合もある ) は更新できません。
定数値を含む単純な列の算術的な組合せから列が導出されている場合、( たとえば
order_date + 30)、原則的にはデータベースサーバで式の逆算方法 ( この場合は更新
値から 30 を減算する ) を判定して、更新を実行することができます。しかし、さら
に複雑な式もあり、そういった式のほとんどは簡単には逆算できません。したがっ
てデータベースサーバは、導出列の更新をサポートしません。
データベースサーバのアクセス権の付与と制限
8-27
ビューを用いたデータの変更
次の例は、導出列と、それに対して受け入れることができる UPDATE 文が含まれ
ている、変更可能なビューを示しています。
CREATE VIEW call_response(user_id,received,resolved,duration) AS
SELECT user_id, call_dtime, res_dtime, res_dtime
- call_dtime
FROM cust_calls
WHERE user_id = USER;
UPDATE call_response SET resolved = TODAY
WHERE resolved IS NULL;
このビューの列 duration は式を表しているため更新できません ( データベースサー
バは原則的に見ても、式で指定されている二つの列間で更新値の分散する方法を判
定できません )。ただし、導出列が SET 節で指定されていなければ、ビューが表で
あるかのように更新を実行することができます。
ビューは、基礎となる表の行が一意であっても重複行を返すことがあります。ある
重複行を別の重複行と区別することはできません。一連の重複行のいずれか一つを
更新すると ( たとえば、カーソルを使用して、WHERE CURRENT を更新する )、基
礎表のどの行で更新を受け取るのかが分からなくなることがあります。
ビューへの挿入
ビューが変更可能であり、導出列が含まれていなければ、ビューに行を挿入するこ
とができます。二番目の制限が設けられているのは、挿入された行はすべての列の
値を表す必要があり、データベースサーバは、挿入された値を式を用いて分散させ
る方法を認識できないからです。前の例に示すように、ビュー call_response に挿入
しようとすると失敗します。
変更可能なビューに導出列が含まれていなければ、あたかも表であるかのように、
そのビューに挿入することができます。ただし、データベースサーバは、ビューに
よって表出されない列の値としてナルを使用します。そのような列にナルを使用で
きない場合は、エラーが発生して挿入に失敗します。
8-28
Informix Guide to Database Design and Implementation
ビューを用いたデータの変更
WITH CHECK OPTION キーワードの使用
ビューの条件を満たさない行、つまりビューで見ることができない行をビューに挿
入することができます。また、ビューの行を更新して、その行がビューの条件を満
たさないようにすることもできます。
ビューの行が更新されて、ビューの条件が満たされないようになることを防止する
ために、ビューの作成時に WITH CHECK OPTION 節を追加することができます。
この節を使用すると、挿入されたそれぞれの行や、更新されたそれぞれの行を検査
して、ビューの WHERE 節によって設定されている条件を満たしていることを確認
するように、データベースサーバに指示が出されます。条件が満たされていない
と、データベースサーバはエラーメッセージを表示して、その操作を拒否します。
重要 : ビュー定義に演算子 UNION が含まれている場合、WITH CHECK OPTION 節を
指定することはできません。
前の例では、次の例に示すように call_response という名前のビューが定義されてい
ます。
CREATE VIEW call_response (user_id,received, resolved, duration) AS
SELECT user_id,call_dtime,res_dtime,res_dtime - call_dtime
FROM cust_calls
WHERE user_id = USER
ビューの列 user_id は、次の例に示すように更新することができます。
UPDATE call_response SET user_id = ’lenora’
WHERE received BETWEEN TODAY AND TODAY - 7
このビューには、user_id が USER と等しくなる行が必要です。tony という名前の
ユーザがこの更新を実行すると、更新された行がビューに表示されなくなります。
しかし、次の例に示すようにビューを作成することができます。
CREATE VIEW call_response (user_id,received,resolved,duration) AS
SELECT user_id, call_dtime, res_dtime, res_dtime - call_dtime
FROM cust_calls
WHERE user_id = USER
WITH CHECK OPTION
tony による前の更新は、エラーとして拒否されます。
データベースサーバのアクセス権の付与と制限
8-29
アクセス権とビュー
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 への挿入が、このビューのみを用いて行われる場合は ( しかも、まだ整合性
制約を使用して、データを制約していない場合 )、日付をさかのぼって挿入したり、
無効な顧客番号、過度の積込重量、および積出費などを挿入したりすることはでき
ません。
アクセス権とビュー
ビューを作成するときに、データベースサーバは、基礎となる表とビューに対する
ユーザのアクセス権をテストします。ビューを使用すると、そのビューに関する
ユーザのアクセス権だけがテストされます。
ビューの作成時のアクセス権
データベースサーバは、ビュー定義で SELECT 文を実行するために必要となるすべ
てのアクセス権をユーザが持っているかどうかをテストします。必要なアクセス権
がないと、ビューは作成されません。
このテストによって、表に対するビューの作成と、ビューに対する問合せを実行し
ても、ユーザは表に不正にアクセスすることができなくなります。
ユーザがビューを作成した後は、そのビューの作成者であり所有者でもあるユーザ
には、少なくともビューに対する選択アクセス権がデータベースサーバによって付
与されます。新しく作成する表の場合のように、自動的に public にアクセス権が付
与されるわけではありません。
8-30
Informix Guide to Database Design and Implementation
ビューを使用するときのアクセス権
データベースサーバは、ビュー定義を検査して、そのビューが変更可能であるかど
うかを確認します。ビューが変更可能な場合は、データベースサーバによって、そ
のビューに対する挿入アクセス権、削除アクセス権、および更新アクセス権が付与
されますが、その場合は基礎となる表またはビューに対しても、それらのアクセス
権がユーザに付与されていることが前提になります。つまり、新しいビューが変更
可能である場合には、データベースサーバは、挿入アクセス権、削除アクセス権、
更新アクセス権を基礎となる表またはビューからコピーして、新しい表に対して付
与します。基礎表に対して挿入アクセス権しか持っていない場合は、ビューに対し
ても挿入アクセス権のみが付与されます。
このテストによって、ユーザは、まだ付与されていないアクセス権に、ビューを使
用してアクセスすることができなくなります。
ビューを変更したりインデックス付けすることはできないので、変更アクセス権と
インデックスアクセス権がビューに対して与えられることはありません。
ビューを使用するときのアクセス権
ビューを使用しようとすると、データベースサーバは、そのビューに対して付与さ
れているアクセス権のみをテストします。ベースになっている表へのアクセス権は
検査しません。
ビューを作成した場合は、前のパラグラフで述べたアクセス権が与えられます。作
成者でない場合は、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
)
データベースサーバのアクセス権の付与と制限
8-31
ビューを使用するときのアクセス権
8-10 ページの「列レベルアクセス権」では、表 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
このビューに対して選択アクセス権を付与されているユーザは、機密性のないデー
タを見ることはできますが、更新することはできません。新しい行を入力しなけれ
ばならない人事部の社員に対しては、次の例に示されているように、別のビューを
作成します。
CREATE VIEW hr_enter AS
SELECT emp_key, emp_name, hire_date, dept_num
FROM hr_data
これらのユーザには、このビューに対する選択アクセス権と挿入アクセス権を付与
します。表とビューの作成者として、その表とビューに対する挿入アクセス権を
持っているので、その表に対するアクセス権を持たない他のユーザに、ビューに対
する挿入アクセス権を付与することができます。
新しいユーザ ID を入力したり更新したりする MIS 部門の社員に代わって、次の例
が示しているように、別のビューを作成します。
CREATE VIEW hr_MIS AS
SELECT emp_key, emp_name, user_id
FROM hr_data
このビューは、部門番号と採用日を表出させないという点で、前のビューとは異
なっています。
8-32
Informix Guide to Database Design and Implementation
ビューを使用するときのアクセス権
なお、マネージャは、あらゆる列へのアクセス権だけではなく、自分の部下に限っ
て勤務評価データを更新できる必要があります。これらの要求を満たすには、それ
ぞれの従業員の部門番号とコンピュータユーザ ID が記述されている表、hr_data を
作成します。管理職自身も、管理している部門のメンバであるというルールを忘れ
てはなりません。そこで、次のビューによって、自分の部下のみを反映する行に管
理職を限定します。
CREATE VIEW hr_mgr_data AS
SELECT * FROM hr_data
WHERE dept_num =
(SELECT dept_num FROM hr_data
WHERE user_id = USER)
AND NOT user_id = USER
最後の条件は、マネージャが表内の自分の行に対して更新アクセス権を持たないよ
うにするために必要です。したがって、次の文が示しているように、このビューで
は、一定の列に対してのみ、更新アクセス権を安全にマネージャに付与することが
できます。
GRANT SELECT, UPDATE (performance_level, performance_notes)
ON hr_mgr_data TO peter_m
データベースサーバのアクセス権の付与と制限
8-33
索引
索引
数字
1 対 1 の関係 2-10, 2-13
1 対多の関係 2-10, 2-13
10 進数 (DECIMAL) データ型
固定小数点 3-11
浮動小数点 3-10
浮動少数点 3-10
A
ADD ROWID 節、ALTER TABLE
の 5-43
ALTER FRAGMENT 文
ADD 節付きの 5-34
ATTACH 節付きの 5-35
DETACH 節 5-36
DROP 節 5-35
INIT 節 5-31
INIT 節の使用方法 5-31
MODIFY 節 5-32
行識別子列の追加 5-43
ALTER TABLE 文
ADD ROWIDS 節 5-43
DROP ROWIDS 節 5-44
アクセス権 8-10
表の種類の切替え 7-18
列データ型の変更 3-23
ANSI 標準準拠
アイコン 序 11
説明 1-4
判断 1-5
レベル 序 16
ANSI 標準準拠データベース
アクセス権 1-7
効果
10 進数データ型 1-8
SQLCODE 1-9
エスケープ文字 1-9
オブジェクトへのアクセス
権 1-7
カーソルの動作 1-9
所有者名の指定 1-7
デフォルトの排他レベル 1-8
トランザクション 1-6
トランザクションログ機能 1-7
作成の理由 1-4
使用できる SQL 文 1-10
所有者名の指定 1-7
設定 1-5
バッファ付きログ機能の制限 4-6
表アクセス権 8-8
C
Codd、E. F. 2-35
CREATE DATABASE 文 4-4
コマンドスクリプトでの 4-11
実装
次元データモデル 7-3
CREATE TABLE 文
FRAGMENT BY EXPRESSION 節
で 5-11
SCRATCH 5-37
TEMP 5-37
WITH ROWIDS 節 5-43
コマンドスクリプトでの 4-11
シリアル (SERIAL) 型の開始値の
設定 3-8
説明 4-6
CREATE VIEW 文
WITH CHECK OPTION キーワー
ド 8-29
使用 8-23
制限 8-25
D
DB スライス、断片化での役割 5-6
DB 領域
CREATE DATABASE 文を使用し
ての選択 4-5
断片化での役割 5-3
DB-Access
∼を使用したデータベースの作
成 4-11
LOAD 文 4-12
DBDATE 環境変数 3-13
dbload ユーティリティ、表への
データのロード 4-12
DBMONEY 環境変数 3-12
dbschema ユーティリティ 4-11
DBSPACETEMP 環境変数 5-38
DBSPACETEMP 構成パラメー
タ 5-38
DBTIME 環境変数 3-16
DELETE 文
アクセス権 8-5, 8-8
ビューへの適用 8-27
DISTINCT キーワード、変更可能
なビューでの制限 8-27
DROP ROWIDS 節、ALTER TABLE
の 5-44
Dynamic Server with AD and XP
Options 3-21
E
en_us.8859-1 ロケール 序 5
EXISTS キーワード、副問合せ条件
での使用 8-30
F
finderr ユーティリティ 序 13
FRAGMENT BY EXPRESSION 節、
CREATE TABLE 文の
5-11
G
GL_DATETIME 環境変数 3-16
GRANT 文
データベースレベルのアクセス
権 8-5
表レベルアクセス権 8-7
GROUP BY キーワード、変更可能
なビューでの制限 8-26
ORDER BY キーワード、ビューで
の制限 8-25
P
PDQ( 並列データベース問合せ )、
断片化とともに使用 5-6
PUBLIC キーワード、すべての
ユーザに付与されるアクセス
権 8-6
I
INFORMIXDIR/bin ディレクトリ 序
5
INIT 節、ALTER FRAGMENT
の 5-31
INSERT 文
アクセス権 8-5, 8-8
ビューを使用した 8-28
INTO TEMP キーワード、ビューで
の制限 8-25
ISO 8859-1 コードセット 序 5
M
MODE ANSI キーワード
ANSI 標準準拠の設定 1-6
ANSI 標準準拠のログ機能 4-6
MODIFY 節、ALTER FRAGMENT
の 5-32
N
NLS、バージョン 7.2 製品との互換
性 1-10
NOT NULL キーワード、CREATE
TABLE 文での使用 4-6
NULL 値
主キーでの制限 2-25
定義 3-23
O
ON-Archive、バックアップと復元
の操作 5-7
ON-BAR、バックアップと復元の
操作 5-7
索引 2 Informix Guige to Database Design and Implementation
R
REVOKE 文、アクセス権の付
与 8-5 – 8-14
S
sales_demo データベース
SQL 文の使用
作成 7-4
ロード 7-9
コマンドファイルを使用した作
成 7-11
データソース 7-6
SELECT 文
アクセス権 8-5, 8-8
変更可能なビューでの 8-26
SET LOG 文、バッファ付きとバッ
ファなし 4-6
stores7 データベース 序 5
sysfragments 表 5-5
syssyntable システムカタログ表 4-9
T
Temp 表 7-15
U
UNION キーワード
ビュー定義での 8-25
変更可能ビューでの制限 8-27
UNIQUE キーワード
CREATE TABLE 文における制
約 4-6
変更可能なビューでの制限 8-27
UPDATE 文
アクセス権 8-5, 8-8
ビューへの適用 8-27
リソース 8-6
列レベル 8-10
アジア言語サポート、バージョン
7.2 製品との互換性 1-10
W
い
WHERE キーワード、データ制約
の実行 8-30
WITH CHECK OPTION キーワー
ド、CREATE VIEW 文の 8-29
WITH ROWIDS 節、CREATE
TABLE 文の 5-43
一時表
および断片化 5-37
フレキシブルな 5-38
明示的 5-37
一般化キーインデックス
定義
結合された表での 7-21
式での 7-21
選択での 7-20
意味整合性 3-3
インデックス
一般化キー
定義 7-20
説明 7-18
データウェアハウス環境 7-18
添付∼の定義 5-39
独立∼の定義 5-40
ビットマップ、説明 7-18
表インデックスの断片化 5-39
インデックスアクセス権 8-10
X
X/Open 準拠、レベル 序 16
あ
アーカイブ、および断片化 5-7
アイコン
機能 序 10
コメント 序 9
準拠 序 11
製品 序 10
プラットフォーム 序 10
アクセス権 8-8
ANSI 標準準拠データベース 1-7
DBA 8-7
インデックス 8-10
更新 8-31, 8-8
削除 8-8, 8-31
システムカタログで符号化され
た 8-9
実行 8-12
自動化 8-13
接続 8-5
選択 8-8, 8-10, 8-30
挿入 8-8, 8-31
データベース管理者 8-7
ビューおよび 8-30 – 8-33
ビューでの 8-31
ビューを作成する必要性 8-30
表レベル 8-8
付与 8-5 – 8-14
プロシジャレベル 8-12
え
エラーメッセージファイル 序 13
お
オペレーショナル表 7-17
オンライントランザクション処理
(OLTP) の説明 6-5
オンライン分析型処理 (OLAP) の
説明 6-5
オンラインマニュアル 序 12
か
外部キー 2-27
外部表、データのロード 5-7
外部表を使用してのデータのロー
ド 4-12, 7-9
拡張機能、SQL への
ANSI 標準準拠データベースで
の 1-10
表す記号 序 11
各国語可変長文字 (NVARCHAR)
データ型 3-18
各国語文字 (NCHAR) データ型 3-17
可変長文字 (CHARACTER
VARYING) データ型 3-18
可変長文字 (VARCHAR) データ
型 3-18
可用性、断片化による向上 5-7
環境、米国英語以外の 1-10
関係
1 対 1 2-10, 2-13
1 対多 2-10, 2-13
再帰的 2-30
実体 2-6
冗長な 2-31
接続性 2-10, 2-13
属性 2-17
存在の依存性 2-10
多対多 2-10, 2-13
多対多∼の解決 2-29
データモデルでの定義 2-9
任意 2-10
濃度 2-15
濃度の制約 2-11
必須 2-10
複雑な 2-30
マトリックスを使用した発
見 2-11
簡単な追加、説明 7-15
き
キー
外部 2-27
主 2-25
複合 2-26
キー列 2-25
記述子列 2-25
機能アイコン 序 10
機能、製品 序 6
機能的依存性 2-34
行
定義 2-23
リレーショナルモデルの 2-23
索引 3
業界標準への準拠 序 16
行識別子
説明 5-41
断片化された表での 5-41, 5-43
断片化された表での削除 5-43
断片化された表での作成 5-43
金額 (MONEY) データ型
国際通貨形式 3-12
説明 3-11
表示フォーマット 3-12
均等分散 5-11
け
結合、変更可能なビューでの制
限 8-26
こ
広域言語サポート (GLS)
説明 序 5
ロケールの使用 1-10
更新アクセス権
定義 8-8
ビューを使用した 8-31
更新、断片化された表の 5-30
候補キー 2-26
コードセット 1-10
固定小数点 3-11
コマンドスクリプト、データベー
スの作成 4-11
コメントアイコン 序 9
さ
再帰的関係 2-12, 2-30
細分性、ファクト表の 6-11
削除アクセス権 8-8, 8-31
参考文献 序 15
参照アクセス権 8-10
参照整合性、主キーと外部キーの
定義 2-27
サンプルコードの表記 序 11
し
時間隔 (INTERVAL) データ型
説明 3-15
表示フォーマット 3-16
式に基づいた分散スキーム
およびフラグメント除去 5-16
使用 5-11
説明 5-4
任意規則 5-12
範囲規則 5-12
式フラグメント、検索方法 5-15
次元データベース、sales_demo 7-4
次元データモデル
作成 6-15 – 6-27
次元 6-12
次元表 6-14
次元要素 6-12
実装 7-3
ファクト表 6-11
メジャーの定義 6-11
次元表
説明 6-14
属性の選択 6-26
システムカタログ
∼内のアクセス権 8-9
syscolauth 8-9
systabauth 8-9
sysusers 8-9
表 sysfragments 5-5
システム定義ハッシュ分散スキー
ム
使用 5-13
説明 5-4
実数 (FLOAT) データ型 3-9
実装
リレーショナルデータモデル
の 4-4
実体
関連する属性 2-17
住所録例での 2-9
重要性 2-6
選択の基準 2-8
定義 2-5
ビジネスルール 2-5
表により表される 2-25
命名 2-5
実体 - 関係図
記号の意味 2-19
接続性 2-20
説明 2-19
読み方 2-20
索引 4 Informix Guige to Database Design and Implementation
実体のオカレンス、定義 2-18
シノニム
ANSI 標準準拠データベースで
の 1-10
連鎖 4-9
シノニム、表名に対する 4-8
集計関数、変更可能なビューでの
制限 8-26
主キー
制限 2-25
断片化された表での使用 5-42
定義 2-25
主キー制約、複合 2-26
準拠
アイコン 序 11
業界標準への 序 16
小桁実数 (SMALLFLOAT) データ
型 3-9
小桁整数 (SMALLINT) データ
型 3-7
冗長な関係 2-31
初期入力、表の 4-12
所有権 8-7
シリアル (SERIAL) データ型 3-7
す
スクラッチ表 7-15
スタージョインスキーマの説
明 6-10
ストアドプロシジャ
アクセス権の付与 8-12
セキュリティの目的 8-3
せ
正規化
第 1 正規形 2-32
第 2 正規形 2-34
第 3 正規形 2-34
データモデルの 2-31
利点 2-31
ルール 2-31
ルールのまとめ 2-35
正規形 2-31
整数 (INTEGER) データ型 3-7
静的表 7-16
性能、バッファ付きログ機能 4-6
製品アイコン 序 10
制約
ドメインの定義 3-3
濃度 2-11
セキュリティ
アクセスを行に制限する 8-22,
8-24
アクセスを列に制限する 8-22,
8-23
オペレーティングシステム機能の
使用 8-4
ストアドプロシジャを使用し
た 8-3
挿入値に制約を加える 8-22
挿入値の抑制 8-29
データベースレベルアクセス
権 8-4
データベースをアクセス不能にす
る 8-4
ビューへのアクセスの制限 8-30
表レベルアクセス権 8-10
接続アクセス権 8-5
接続性、関係における 2-10, 2-13,
2-20
設定、ANSI 標準準拠の 1-6
選択アクセス権
定義 8-8
ビューを使用した 8-30
列レベル 8-10
そ
操作データストアの説明 6-4
挿入アクセス権 8-8, 8-31
属性
∼の重要性 2-17
識別 2-17
分割できない 2-17
ソフトウェアの要件 序 4
存在の依存性 2-10
た
第 1 正規形 2-32
第 2 正規形 2-34
第 3 正規形 2-34
多対多の関係 2-10, 2-13, 2-29
断片化
DB スライス役割 5-6
PDQ とともに 5-6
一時表 5-37
行識別子および 5-41
再初期化 5-31
式の評価方法 5-13
主キーの使用 5-41
説明 5-3
等検索 5-16
バックアップと復元の操作 5-7
範囲検索 5-16
表インデックスの 5-39
複数のコサーバ間での 5-6
フラグメントの除去 5-15
分散スキーム 5-9
変更 5-30
明示的な行識別子列の作成 5-41
目標 5-6
ログ 5-8
断片化された表
行識別子の使用 5-43
更新 5-30
作成 5-28
作成方法 5-26
主キーの使用 5-42
断片化されていない表からの作
成 5-29
データへのアクセス 5-42
複数の断片化されていない表から
の作成 5-29
フラグメントの削除 5-35
フラグメントの追加 5-34
断片化された表のデータへのアク
セス 5-42
て
データ
dbload ユーティリティを使用して
のロード 4-12
外部表を使用してのロード 4-12
データウェアハウスの説明 6-4
データ型
10 進数 (DECIMAL) 3-10, 3-11
ALTER TABLE 文を使用しての変
更 3-23
INTEGER 3-7
SERIAL 3-7
各国語可変長文字
(NVARCHAR) 3-18
各国語文字 (NCHAR) 3-17
可変長文字 (CHARACTER
VARYING) 3-18
可変長文字 (VARCHAR) 3-18
金額 (MONEY) 3-11
固定小数点 3-11
時間隔 (INTERVAL) 3-15
小桁実数 (REAL) 3-9
小桁実数 (SMALLFLOAT) 3-9
数値 3-7
テキスト (TEXT) 3-21
日時 (DATETIME) 3-14
バイト (BYTE) 3-21
日付 (DATE) 3-13
日付、時間に関する 3-12
浮動小数点 3-9
文字 (CHAR) 3-17
データ、断片化された表でのアク
セス 5-42
データベース
外部データベースに関するビュー
を可能にする 8-26
新規表の初期入力 4-12
命名 4-4
データベース管理者 (DBA) 8-7
データベースサーバ、外部データ
ベースに関するビューを可能に
する 8-26
データベースレベルアクセス権
接続アクセス権 8-5
データベース管理者アクセス
権 8-7
リソースアクセス権 8-6
データマートの説明 6-4
データモデル
1 対 1 の関係 2-13
1 対多の関係 2-13
関係の定義 2-9
作成
次元 6-15 – 6-27
リレーショナル 2-3 – 2-21
次元 6-9
実体 - 関係 2-5
住所録の例 2-7
説明 2-3
属性 2-17
多対多の関係 2-13
索引 5
リレーショナル 2-3
テキスト (TEXT) データ型
使用方法 3-22
説明 3-21
デフォルト値
定義 3-23
列に対する指定 3-24
デフォルトロケール 序 5
デモンストレーションデータベー
ス序5
国際日付および時刻のフォーマッ
ト 3-16
説明 3-14
表示フォーマット 3-16
任意の実体、関係における 2-10
の
濃度
関係における 2-15
制約 2-11
と
透過的依存性 2-34
同時実行性
断片化による向上 5-6
導出データ、ビューによる生
成 8-23
ドキュメントノート
格納場所 序 14
プログラム項目 序 15
ドキュメントの種類
エラーメッセージファイル 序 13
オンラインマニュアル 序 12
参考文献 序 15
ドキュメントノート 序 14
ペーパーマニュアル 序 13
マシンノート 序 14
リリースノート 序 14
ドメイン
制約 3-3
定義 2-24
特性 2-24, 3-3
列の 3-3
トランザクション、ANSI 標準準拠
データベース、効果 1-6
トランザクションログ機能
ANSI 標準準拠データベース、効
果 1-7
CREATE DATABASE 文を使用し
ての確立 4-4
バッファ付き 4-6
ローディングを速くするためにオ
フにする 4-13
に
日時 (DATETIME) データ型
は
排他レベル、ANSI 標準準拠データ
ベースのデフォルト 1-8
バイト (BYTE) データ型
使用方法 3-22
説明 3-21
ハイパフォーマンスローダ (HPL)
を使用したデータのロード 7-9
ハイブリッド分散スキーム
説明 5-4, 5-14
バックアップと復元の操作、断片
化 5-7
バッファ付きログ機能 4-6
バッファなしログ機能 4-6
判断、ANSI 標準準拠の 1-5
ひ
日付 (DATE) データ型
説明 3-13
表示フォーマット 3-13
フォーマットのカスタマイ
ズ 3-13
必須の実体、関係における 2-10
ビットマップインデックス、説
明 7-18
ビュー
∼への行の挿入 8-28
WITH CHECK OPTION キーワー
ドの使用 8-29
アクセス権 8-30 – 8-33
仮想列 8-27
行の削除 8-27
作成 8-23
索引 6 Informix Guige to Database Design and Implementation
使用時のアクセス権 8-31
説明 8-22
重複行の更新 8-28
表出されない列に挿入されるナ
ル 8-28
ベースが削除されると削除 8-25
ベース変更の影響 8-25
変更 8-26 – 8-30
変更における制限 8-26
表
∼の主キー 2-25
∼名でのシノニム 4-8
外部キー、定義 2-27
キー列 2-25
記述子列 2-25
候補キー、定義 2-26
実体を表す 2-25
所有権 8-7
データのロード 4-12
表の作成 4-6
複合キー、定義 2-26
リレーショナルモデルの 2-23
表インデックス断片化 5-39
表記上のきまり
アイコン 序 9
サンプルコード 序 11
文字の表記 序 8
標準永続表
説明 7-17
変更 7-18
表フラグメントの削除 5-35
表フラグメントの追加 5-34
表レベルアクセス権
アクセス権 8-8
インデックスアクセス権 8-10
参照アクセス権 8-10
定義と使用 8-8
変更アクセス権 8-10
ふ
ファクト表
∼の細分性 6-11
細分性の決定 6-18
説明 6-11
複合キー 2-26
浮動少数点 3-9
フラグメント
∼数の変更 5-31
検索から除去する場合 5-15
削除 5-35
説明 5-3
単一列に基づく非重複フラグメン
ト 5-17
追加 5-34
複数列に基づく非重複フラグメン
ト 5-19
変更 5-32, 5-33
フラグメント式、任意式 5-12
フラグメント除去
式に基づいた分散スキーム 5-22
ハイブリッド分散スキーム 5-24
フラグメント除去動作
Dynamic Server 5-20
プラットフォームアイコン 序 10
フレックス一時表 5-38
断片化 5-38
定義 5-38
フレックス一時表演算子 5-38
フレックス演算子 5-38
プログラムグループ
ドキュメントノート 序 15
リリースノート 序 15
プロシジャレベルアクセス権 8-12
分割できない属性 2-17
分散スキーム
型
Dynamic Server 5-9
Dynamic Server with AD and XP
Options 5-10
式に基づいた
使用 5-11
任意規則 5-12
範囲規則 5-12
フラグメント除去 5-22
システム定義ハッシュ
使用 5-13
説明 5-4
説明 5-4
ハイブリッド
使用 5-14
説明 5-4
フラグメント除去 5-24
フラグメント数の変更 5-31
ラウンドロビン
使用 5-11
説明 5-4
へ
り
ペーパーマニュアル 序 13
変更アクセス権 8-10
変更、断片化戦略の 5-30
リソースアクセス権 8-6
リポジトリの説明 6-5
リリースノート
格納場所 序 14
プログラム項目 序 15
リレーショナルデータモデルの作
成 2-3 – 2-21
リレーショナルモデル
1 対 1 の関係 2-13
1 対多の関係 2-13
実体 2-5
表、行、列の定義ルール 2-23
説明 2-3
属性 2-17
多対多の関係 2-13
データの正規化 2-31
関係の解決 2-29
ま
マシンノート 序 14
め
メッセージファイル、エラーメッ
セージ 序 13
も
文字 (CHAR) データ型 3-17
や
役割
CREATE ROLE 文を使用した作
成 8-15
GRANT 文を使用したアクセス権
の付与 8-16
SET ROLE 文を使用した有効
化 8-16
sysroleauth 表 8-17
sysusers 表 8-17
定義 8-14
命名の規則 8-15
ゆ
ユーティリティプログラム
dbload 4-13, 7-3, 7-4, 7-9, 7-13
dbschema 4-11
ら
ラウンドロビン分散スキーム
および INSERT カーソル 5-4
および INSERT 文 5-4
使用 5-11
説明 5-4
れ
列
断片化された表の列の変更 5-30
定義 2-23
列レベルアクセス権 8-10
連鎖、シノニムの 4-9
ろ
ロウ永続表
説明 7-16
変更 7-18
ロード、データの
dbload ユーティリティを使用して
の 4-12
外部表を使用しての 4-12
ログ機能
データベースサーバに対する選
択 4-5
バッファ付き 4-6
バッファなし 4-6
ログ付き表
作成 7-13
特性 7-14
ログなし表
作成 7-13
特性 7-14
索引 7
ロケール 序 5, 1-10
索引 8 Informix Guige to Database Design and Implementation