II-22-9. RDBを用いた企業DB設計の例

業務分析としてエンティティを洗い出しER図を作成したのち、スキーマとインデクスの設計、分散データベースの設計という企業基幹データベースの設計手順を示す。また物理設計として性能設計や処理効率化検討といった項目についても解説する。

【学習の要点】

* データベース作成を行う業務のエンティティの洗い出しを行い、ER図の作成を行い概念データモデルの設計方法を習得する。

* 概念データモデルからスキーマやインデックスの設計を行い、論理データモデルの設計方法を習得する。

* 論理設計の結果からレコードの構造、順番、アクセスパスなどの設計を行い、物理設計の方法を習得する。

図II-22-9. ER図

【解説】

1) データモデリング

データベースシステムを構築する場合には、現実にある様々な情報から、システムの要件に基づき、構築に必要なデータ項目を探し出して、項目間の関係性をまとめ上げ、より無駄なく集合化して、論理的かつ意味的に正しいデータモデルを組み立てることが必要になる。データモデルを組み立てる行為のことをデータモデリングという。

データモデルの持つ機能としては、データ定義、データ操作、整合性維持の3つがある。

データモデルは、一般に次の3段階を経て完成し、段階を経る毎により詳細化していく手順となる。

* 概念データモデル

システムの要件をコンピュータでの処理を前提に分析し識別し、ER図などで定義した、特定のDBMSに依存しない大まかなデータモデルのことを「概念データモデル」という。

* 論理データモデル

概念データモデルに、システムで必要となるスキーマを作成して、コンピュータに実装可能な形に変換したデータモデルのことを「論理データモデル」という。

スキーマは、表と表内のフィールド、フィールドや表の関係などのデータベースの構造の定義のことである。

論理データモデルは、より詳細なER図などで作成され、DBMSの特性を加味して、それに依存したデータモデルになることが多い。

* 物理データモデル

実装を意識して、データ型や索引までを定義し、CREATE TABLE文などの、DBMSでサポートされている形式で記述可能となるレベルのデータモデルを「物理データモデル」という。

物理データモデルでのデータ定義は、実テーブルを設計することであり、整合性制約の定義、性能向上のための構造定義(インデックス、パラメータ)など、RDBの物理的な内部構造を決定する。

アクセスパスは、データの取得ルートのことをいう。インデックスや抽出条件、結合条件などを見直すことで、よりパフォーマンスの高いアクセスパスとなることを目指す。

2) 分散データベースの設計

異なる場所にデータベースを配置しネットワークで接続されたデータベースシステムのことを分散データベースという。この方法は、ネットワークの負荷低減のために有用である。分散データベースには、非同期型更新や2相コミットなどの方法がある。

* 非同期型更新

分散先のサイトに更新データを適宜送信してデータの同期を取る方法である。同じデータを複数のサイトで同時に更新する必要がある場合は、更新内容に競合が生じる可能性があるため、利用には注意が必要である。

* 2相コミット(2フェーズコミット)

主サイトから分散した処理先のサイトの更新処理がコミット可能か確認し、コミット処理待ちの指示を出すフェーズ(第1フェーズ)と、それぞれのサイトが更新をコミットする指示を出すフェーズ(第2フェーズ)に分けて処理がおこなわれ、第1フェーズの結果を確認し、コミットするかロールバックするかを決定して、処理先のサイトへ指示を出す。比較的競合を防止できるが、ネットワークの負荷は増大しがちになる。

OSS Course Naviのコンテンツは IPA OSS モデルカリキュラムを基としています。