| [目次]
第1部 データベース設計
第1章 情報システム化計画
- P－D－Sサイクル
- 計画・実施・評価
第2章 データベース設計
- 設計はデータが中心
- データベース設計の手順
- 要件定義
- データベースの論理構造の設計
- データベースの物理構造の設計
- アプリケーション開発
- チューニング
- 三層スキーマ構造
- 外部層(外部モデル)
- 概念層(論理データモデル)
- 内部層(物理データモデル)
第2部 論理設計
第1章 データベース論理設計の基礎
- 論理設計の目的
- 正規化
- テーブル設計
- 制 約
- ナル値
第2章 論理データベース設計の基本セオリー
- テーブル設計
- フィールドの選択とフィールド属性の決定
- テーブルの構成
- 重複性の排除(正規化)
- キーの検討
- 参照制約の検討
- 正規化
- 正規化のステップ
- 非正規形
- 第1正規形
- 第2正規形
- 第3正規形
- 第4正規形
- 第5正規形
- 正規化の度合
- 正規化の利点
- 制 約
- NOT
NULL(非ナル値)制約
- ユニーク性(一意性)制約
- 主キー制約
- 参照制約
- 検査(チェック)制約
- 省略時(デフォルト)制約
- インデックス
- インデックスの構造と必要性
- インデックスの性質
- ユニーク性
- クラスター化
- インデックスを構成するフィールド数
- データへのアクセス
- インデックスが定義されていない場合
- ユニーク・インデックスに合致した場合
- クラスター化インデックスに合致した場合
- 非クラスター化インデックスに合致する場合
- クラスター化インデックスに合致しない場合
- インデックスへのアクセスだけで完了する
- インデックス設計の手順
- インデックスの必要性の検討
- 基本的なインデックス候補の選択
- 追加インデックス候補の選択
- クラスター化インデックスの検討
- インデックス候補の取捨選択と決定
- 重要な問い合わせについては個別に追加のインデックスを検討する
- インデックスの物理設計を行う
- インデックスの有効性を検証する
- ビューとシノニム
- ビューとは
- ビューを作る理由
- ビューの分類
- 削除可能なビュー
- 更新可能なビュー
- 挿入可能なビュー
- 読み取り専用のビュー
- シノニム
第3章 主要DBMS製品の支援機能
- テーブル
- ORACLEにおける支援機能
- VARCHAR2の使用について
- バイト文字セットと日本語データ・フィールド
- NUMBERの使用について
- SQL
Serverにおける支援機能
- DB2における支援機能
- クラスタリング
- ハッシング
第4章 論理データベース設計の実践テクニック
- ERモデルから論理データベースへ
- ERモデル
- エンティティ(実体)
- リレーションシップ(関連)
- ERモデルの作成
- エンティティ図の作成
- エンティティの洗い出しと関連図の作成
- 核エンティティによる基本キーの決定
- 特質エンティティによる基本キーの決定と外部キーの認識
- N：Mの関係にあるエンティティの間に連関エンティティを作る
- 連関エンティティを見つけて，基本キーの決定と外部キーの認識
- 参照の整合性に基づいて参照制約を決める
- 正規化
- 例題(演習④ 再掲)
- データの分析
- エンティティ分析
- 正規化の検討(演習④ 解答例)
- テーブル設計
- フィールドの候補
- キー・フィールドの選択
- フィールドとして定義しない情報
- フィールドとして定義した方がよい情報
- フィールドの分割/統合
- 頻繁に結合されるフィールドは基本テーブルに含める
- ナル値および可変長フィールドはテーブルの最後のフィールドにする
- 予備フィールドは不要
- フィールドのデータ形式
- DBMSに固有のデータ型は避ける
- 可変長形式は注意が必要である
- データ形式を統一する
- フィールドに適したデータ形式を選択する
- 日付・時刻は場合によっては二重に持つ
第3部 物理設計
第1章 物理データベース設計の基本セオリー
- 物理設計の目的
- 論理設計から物理設計へ
- 物理設計の手順
- データベース関連の定義
- テーブルの定義およびビューの定義
- 権限の定義
- シノニムの定義
- データのロード
- インデックスの定義
- チューニング
- テーブルの定義
- テーブル定義のヒント
- フィールドを定義した順番はアプリケーションとは独立している
- フィールドの使用頻度を考慮する
- 可変長/ナル値を許すフィールドは固定長フィールドの後ろに定義する
- 同時に更新される可能性のあるフィールドはできるだけ隣接させる
- テーブル定義情報の変更がプログラムへ及ぼす影響
- ビューとシノニム
- 定義する時点
- 考慮点
- シノニムの使用(スキーマとオブジェクト)
- インデックス
- インデックスの効果的な使い方
- 作成/消去の時点
- いつ作成するか
- いつ消去するか
- 統計情報の取得時点
- 一般的な考慮点
第2章 主要DBMS製品の支援機能
- データベースの定義
- ORACLEにおける支援機能
- SQL
Serverにおける支援機能
- DB2における支援機能
- テーブルの定義
- ORACLEにおける支援機能
- SQL
Serverにおける支援機能
- DB2における支援機能
- ビュー
- ビューの定義
- ORACLEにおける支援機能
- SQL
Serverにおける支援機能
- DB2における支援機能
- ンデックス
- ORACLEにおける支援機能
- SQL
Serverにおける支援機能
- DB2における支援機能
- 権限の設計
- 権限の種類
- データベース・オブジェクト作成の権限
- ユーザへの特権の授与
- 安全保護機能
- ロール
- 制 約
- 制約の定義
- ORACLEにおける支援機能
- SQL
Serverにおける支援機能
- DB2における支援機能
第4部 パフォーマンス設計
(物理データベース設計の実践テクニック)
第1章 オプティマイザー
- データベース設計
- オプティマイザー
- オプティマイザーの種類
- オプティマイザーの働き
- オプティマイザーの目的と機能
- オプティマイザーの利点
- アクセス・パス・セレクション
- DBMS製品の支援機能
- テーブル設計の検証
- ORACLEにおける支援機能
- SQL
Serverにおける支援機能
- パフォーマンス・モニター
- UPDATE
STATISTICS
- DB2における支援機能
第2章 インデックス
- インデックスの最適化
- インデックス定義フィールドに関する考察
- データ形式の変換が起きないようにする
- 比較の文字ストリングの長さを同じにする
- 算術演算を含むWHERE述部ではインデックスは使われない
- 同じフィールドに対する複数の不等号の指定はBETWEENで表現する
- ワイルドカードを使用する場合の注意
- INが副照会に使われているとインデックスは使われない
- 結合(join)に関する考察
- 複合フィールド・インデックスを作るときは，あらかじめフィールドを隣接させておく
- 更新が頻繁に発生するフィールドにはインデックスを付けない方がよい
- インデックスを付けすぎると更新速度が落ちる
第3章 データベース設計の実際
- データベース設計の範囲
- データベース設計のポイント
- オプティマイザーの機能を把握する
- データベース設計を綿密に行う
- 設計変更に対処できる仕組みを作っておく
- 正規化と冗長化のバランスをはかる
- 実環境に近いデータでパフォーマンスを測定する
- 「ナル値」を効果的に使用する
索 引
|
